Patchwork [v3.8,Regression] watchdog: sp5100_tco: Add SB8x0 chipset support

login
register
mail settings
Submitter Wim Van Sebroeck
Date Feb. 15, 2013, 7:32 a.m.
Message ID <20130215073210.GM7867@spo001.leaseweb.com>
Download mbox | patch
Permalink /patch/220694/
State New
Headers show

Comments

Wim Van Sebroeck - Feb. 15, 2013, 7:32 a.m.
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).

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.
From mc74hc00@gmail.com Mon Jan 14 03:02:20 2013
Return-path: <mc74hc00@gmail.com>
Envelope-to: wim@infomag.iguana.be
Delivery-date: Mon, 14 Jan 2013 03:02:20 +0100
Received: from ylaen.iguana.be ([178.21.116.169])
	by spo001.leaseweb.com with esmtp (Exim 4.50)
	id 1TuZNU-0006Zi-0P
	for wim@infomag.iguana.be; Mon, 14 Jan 2013 03:02:20 +0100
Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45])
	by ylaen.iguana.be (Postfix) with ESMTP id 939FC174278
	for <wim@iguana.be>; Mon, 14 Jan 2013 03:02:19 +0100 (CET)
Received: by mail-pb0-f45.google.com with SMTP id mc8so1875722pbc.32
        for <wim@iguana.be>; Sun, 13 Jan 2013 18:02:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=x-received:from:to:cc:subject:date:message-id:x-mailer;
        bh=Al12X3CF48UZXAYSA0AbzpLWDndmh59rkg9CMqG3eKs=;
        b=BN3M1HJsUrmYnOe3KiT2w9jZTOWHevYNdIbLumjQWul8MbPVI1WDie98dgoG21C18P
         BuaHoo82fmCZBViD0qyuQz0RI0vySln5olsfpBsCKJVWTFDSAAg/kysHmcqOVp6sWpDI
         VPSe22vIVgxiNtqK0BdwGLjyvhQJ7Cgnv/3CrIa4h1HUfP8hKMwy/9V6SCe4VRpt7bOZ
         ZqTxpMfQ95pesNTKJuZEx2vqL5LM2WMVqUhneVR1dG4ceFTbOZ3xF57waoUEszGFlrmq
         0owzHTSi1BVF1wlxEfYXPuSie/gS2Yl9AGqHoaXm3DN3aSXwXbqnIK5VdUi/3Cir7CUK
         zj3Q==
X-Received: by 10.66.83.165 with SMTP id r5mr229452746pay.3.1358128938114;
        Sun, 13 Jan 2013 18:02:18 -0800 (PST)
Received: from localhost (p7204-ipngn2902marunouchi.tokyo.ocn.ne.jp. [180.47.244.204])
        by mx.google.com with ESMTPS id qh4sm7226051pbb.9.2013.01.13.18.02.14
        (version=TLSv1.2 cipher=RC4-SHA bits=128/128);
        Sun, 13 Jan 2013 18:02:16 -0800 (PST)
From: Takahisa Tanaka <mc74hc00@gmail.com>
To: linux-watchdog@vger.kernel.org
Cc: Wim Van Sebroeck <wim@iguana.be>,
	Paul Menzel <paulepanter@users.sourceforge.net>,
	Arkadiusz Miskiewicz <arekm@maven.pl>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jonathan Nieder <jrnieder@gmail.com>,
	linux-kernel@vger.kernel.org,
	Florian Mickler <florian@mickler.org>,
	Takahisa Tanaka <mc74hc00@gmail.com>
Subject: [PATCH 1/2] watchdog: sp5100_tco: Fix wrong indirect I/O access for getting value of reserved bits
Date: Mon, 14 Jan 2013 11:01:57 +0900
Message-Id: <1358128918-4415-1-git-send-email-mc74hc00@gmail.com>
X-Mailer: git-send-email 1.7.11.7
Content-Length: 1656
Lines: 42

In case of SB800 or later chipset and re-programming MMIO address(*),
sp5100_tco module may read incorrect value of reserved bit, because the module
reads a value from an incorrect I/O address. However, this bug doesn't cause
a problem, because when re-programming MMIO address, by chance the module
writes zero (this is BIOS's default value) to the low three bits of register.
* In most cases, PC with SB8x0 or later chipset doesn't need to re-programming
  MMIO address, because such PC can enable AcpiMmio and can use 0xfed80b00 for
  watchdog register base address.

This patch fixes this bug.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176
Signed-off-by: Takahisa Tanaka <mc74hc00@gmail.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
---
 drivers/watchdog/sp5100_tco.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
Joseph Salisbury - Feb. 15, 2013, 2:54 p.m.
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.
>
Tanaka Takahisa - Feb. 17, 2013, 9:44 a.m.
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
Joseph Salisbury - Feb. 18, 2013, 3:13 a.m.
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
Joseph Salisbury - Feb. 18, 2013, 7:26 a.m.
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/
Tanaka Takahisa - Feb. 18, 2013, 5:14 p.m.
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
Joseph Salisbury - Feb. 22, 2013, 12:04 a.m.
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
Tanaka Takahisa - Feb. 23, 2013, 6:14 a.m.
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

Patch

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);