| Message ID | 20130215073210.GM7867@spo001.leaseweb.com |
|---|---|
| State | New |
| Headers | show |
On 02/15/2013 02:32 AM, Wim Van Sebroeck wrote: > Hi Joseph, > >> A bug was opened against the Ubuntu kernel[0]. It was found that >> reverting the following commit resolved this bug: >> >> commit 740fbddf5c3f9ad8b23c5d917ba1cc7e376a5104 >> Author: Takahisa Tanaka <mc74hc00@gmail.com> >> Date: Sun Dec 2 14:33:18 2012 +0900 >> >> watchdog: sp5100_tco: Add SB8x0 chipset support >> >> >> The regression was introduced as of v3.8-rc1. >> >> I see that you are the author of this patch, so I wanted to run this by >> you. I was thinking of requesting a revert for v3.8, but I wanted to >> get your feedback first. > Please check out the attached patches first (They are allready in linux-next). Thanks for the feedback, Wim. I'll let you know if the patches resolve this bug. > > Other references: > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 > > Kind regards, > Wim. >
Hi Joseph, 2013/2/15 Joseph Salisbury <joseph.salisbury@canonical.com>: > On 02/15/2013 02:32 AM, Wim Van Sebroeck wrote: >> >> Hi Joseph, >> >>> A bug was opened against the Ubuntu kernel[0]. It was found that >>> reverting the following commit resolved this bug: >>> >>> commit 740fbddf5c3f9ad8b23c5d917ba1cc7e376a5104 >>> Author: Takahisa Tanaka <mc74hc00@gmail.com> >>> Date: Sun Dec 2 14:33:18 2012 +0900 >>> >>> watchdog: sp5100_tco: Add SB8x0 chipset support >>> >>> >>> The regression was introduced as of v3.8-rc1. >>> >>> I see that you are the author of this patch, so I wanted to run this by >>> you. I was thinking of requesting a revert for v3.8, but I wanted to >>> get your feedback first. >> >> Please check out the attached patches first (They are allready in >> linux-next). > > Thanks for the feedback, Wim. I'll let you know if the patches resolve this > bug. > > >> >> Other references: >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 >> >> Kind regards, >> Wim. Thank you for your information, and sorry for the late reply. I think that I will get rid of code that re-programming the chipset registers, if my patch set doesn't resolve the problem. I'm waiting for your reply at the moment. Regards, Takahisa
On 02/17/2013 04:44 AM, Tanaka Takahisa wrote: > Hi Joseph, > > 2013/2/15 Joseph Salisbury <joseph.salisbury@canonical.com>: >> On 02/15/2013 02:32 AM, Wim Van Sebroeck wrote: >>> Hi Joseph, >>> >>>> A bug was opened against the Ubuntu kernel[0]. It was found that >>>> reverting the following commit resolved this bug: >>>> >>>> commit 740fbddf5c3f9ad8b23c5d917ba1cc7e376a5104 >>>> Author: Takahisa Tanaka <mc74hc00@gmail.com> >>>> Date: Sun Dec 2 14:33:18 2012 +0900 >>>> >>>> watchdog: sp5100_tco: Add SB8x0 chipset support >>>> >>>> >>>> The regression was introduced as of v3.8-rc1. >>>> >>>> I see that you are the author of this patch, so I wanted to run this by >>>> you. I was thinking of requesting a revert for v3.8, but I wanted to >>>> get your feedback first. >>> Please check out the attached patches first (They are allready in >>> linux-next). >> Thanks for the feedback, Wim. I'll let you know if the patches resolve this >> bug. >> >> >>> Other references: >>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 >>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 >>> >>> Kind regards, >>> Wim. > Thank you for your information, and sorry for the late reply. > > I think that I will get rid of code that re-programming the chipset > registers, if my patch set doesn't resolve the problem. > I'm waiting for your reply at the moment. > > > Regards, > Takahisa Hi Takahisa, The bug report tested a kernel with the patches. However, he reports the kernel panic still occurs[0]. Thanks, Joe [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116835
I've requested a digital image or screen capture of the panic. Is there any additional debug information you thing would be helpful? Thanks, Joe On Sun, Feb 17, 2013 at 10:13 PM, Joseph Salisbury <joseph.salisbury@canonical.com> wrote: > On 02/17/2013 04:44 AM, Tanaka Takahisa wrote: >> >> Hi Joseph, >> >> 2013/2/15 Joseph Salisbury <joseph.salisbury@canonical.com>: >>> >>> On 02/15/2013 02:32 AM, Wim Van Sebroeck wrote: >>>> >>>> Hi Joseph, >>>> >>>>> A bug was opened against the Ubuntu kernel[0]. It was found that >>>>> reverting the following commit resolved this bug: >>>>> >>>>> commit 740fbddf5c3f9ad8b23c5d917ba1cc7e376a5104 >>>>> Author: Takahisa Tanaka <mc74hc00@gmail.com> >>>>> Date: Sun Dec 2 14:33:18 2012 +0900 >>>>> >>>>> watchdog: sp5100_tco: Add SB8x0 chipset support >>>>> >>>>> >>>>> The regression was introduced as of v3.8-rc1. >>>>> >>>>> I see that you are the author of this patch, so I wanted to run this by >>>>> you. I was thinking of requesting a revert for v3.8, but I wanted to >>>>> get your feedback first. >>>> >>>> Please check out the attached patches first (They are allready in >>>> linux-next). >>> >>> Thanks for the feedback, Wim. I'll let you know if the patches resolve >>> this >>> bug. >>> >>> >>>> Other references: >>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 >>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 >>>> >>>> Kind regards, >>>> Wim. >> >> Thank you for your information, and sorry for the late reply. >> >> I think that I will get rid of code that re-programming the chipset >> registers, if my patch set doesn't resolve the problem. >> I'm waiting for your reply at the moment. >> >> >> Regards, >> Takahisa > > Hi Takahisa, > > The bug report tested a kernel with the patches. However, he reports the > kernel panic still occurs[0]. > > Thanks, > > Joe > > [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116835 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
Hi Joseph, Thanks a lot for your help. >The bug report tested a kernel with the patches. However, he reports the kernel panic still occurs[0]. I understood. I guess this problem conflicts with the watchdog MMIO address (*) written in SB700 chipset and other resource. So, I made a patch which gets rid of the code considered to cause the problem. If this patch is applied, although the SP5100 and SB7x0 chipsets can't use watchdog function any longer, I'm sure attached patch resolve the problem. The SB800 or later chipsets can be used as before. (*)This address is obtained from allocate_resource() function. I'm sorry to trouble you, but Would you confirm whether attached patch solves a problem? If there is no problem in this patch, I will submit this patch to a linux-watchdog community. > I've requested a digital image or screen capture of the panic. Is > there any additional debug information you thing would be helpful? I'm interested in the I/O resource of PC in which the problem has occurred, So, I want the result of 'cat /proc/iomem'. When 'cat /proc/iomem' is performed, I don't care about whether sp5100_tco driver is loaded. Thanks in advance. Takahisa
On 02/18/2013 12:14 PM, Tanaka Takahisa wrote: > Hi Joseph, > > Thanks a lot for your help. > >> The bug report tested a kernel with the patches. However, he reports the kernel panic still occurs[0]. > I understood. I guess this problem conflicts with the watchdog MMIO > address (*) written in SB700 chipset and other resource. So, I made a > patch which gets rid of the code considered to cause the problem. If > this patch is applied, although the SP5100 and SB7x0 chipsets can't > use watchdog function any longer, I'm sure attached patch resolve the > problem. The SB800 or later chipsets can be used as before. > (*)This address is obtained from allocate_resource() function. > > I'm sorry to trouble you, but Would you confirm whether attached patch > solves a problem? > If there is no problem in this patch, I will submit this patch to a > linux-watchdog community. This patch did resolve the issue. The bug reporter states the panic no longer happens and the system boots. Thanks so much for your assistance. > > >> I've requested a digital image or screen capture of the panic. Is >> there any additional debug information you thing would be helpful? > I'm interested in the I/O resource of PC in which the problem has > occurred, So, I want the result of 'cat /proc/iomem'. When 'cat > /proc/iomem' is performed, I don't care about whether sp5100_tco > driver is loaded. The I/O data can be seen at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116835/+attachment/3540738/+files/iomem.txt > > > Thanks in advance. > Takahisa
Hi Joseph, Thank you for testing! I will submit this patch to the linux-watchdog community after adding commit log to patch. 2013/2/22 Joseph Salisbury <joseph.salisbury@canonical.com>: > The I/O data can be seen at: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116835/+attachment/3540738/+files/iomem.txt In the case of SP5100 and SB7x0 chipset, the sp5100_tco driver overwrites a free resource I/O memory address obtained by allocate_resource() to the MMIO address registers for watchdog timer. In the case of M3A78-CM, the sp5100_tco driver was using 0xfed45000 as a MMIO address. Since 0xfed45000 is the free I/O memory resource address, this is the expected behavior. [ 18.852540] sp5100_tco: Using 0xfed45000 for watchdog MMIO address However, Rewriting the MMIO address registers for the watchdog timer must have generated the problem. I think that the problem has occurred with the chipset or the BIOS layer. So, It's difficult for me to investigate the problem, and the problem is critical. Thus, I decided to delete the concerned codes. Regards, Takahisa
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c index 2b0e000..5dfe86e 100644 --- a/drivers/watchdog/sp5100_tco.c +++ b/drivers/watchdog/sp5100_tco.c @@ -500,14 +500,15 @@ static unsigned char sp5100_tco_setupdevice(void) /* Restore to the low three bits, if chipset is SB8x0(or later) */ if (sp5100_tco_pci->revision >= 0x40) { u8 reserved_bit; - reserved_bit = inb(base_addr) & 0x7; + outb(base_addr+0, index_reg); + reserved_bit = inb(data_reg) & 0x7; val |= (u32)reserved_bit; } /* Re-programming the watchdog timer base address */ outb(base_addr+0, index_reg); /* Low three bits of BASE are reserved */ - outb((val >> 0) & 0xf8, data_reg); + outb((val >> 0) & 0xff, data_reg); outb(base_addr+1, index_reg); outb((val >> 8) & 0xff, data_reg); outb(base_addr+2, index_reg);