* Re: ACPI: Uninitialized spinlocks & Unable to dump stack
2007-08-01 5:48 ACPI: Uninitialized spinlocks & Unable to dump stack Christoph Lameter
@ 2007-08-01 12:18 ` Kenji Kaneshige
2007-08-01 13:33 ` Jes Sorensen
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Kenji Kaneshige @ 2007-08-01 12:18 UTC (permalink / raw)
To: linux-ia64
2007-07-31 (火) の 22:48 -0700 に Christoph Lameter さんは書きました:
> With todays git I get (sn2_defconfig w/ spinlock debuggin):
(snip.)
> ACPI: Error parsing MADT - no IOSAPIC entries
> register_intr: No IOSAPIC for GSI 52
> BUG: spinlock bad magic on CPU#0, swapper/0
> lock: a000000100bf66d0, .magic: 00000000, .owner: <none>/-1, .owner_cpu:
> 0
> unwind: cannot stack reg state!
>
> Call Trace:
> [<a000000100013900>] show_stack+0x40/0xa0
(snip.)
Hi,
I don't know why no IOSAPIC entries was found on your system.
But I think the cause of this stack trace is a bug in the code
path of interrupt registering failure. Here is a patch to fix
this bug. Could you try that?
Thanks,
Kenji Kaneshige
---
Fix wrong access to irq_desc[] in iosapic_register_intr().
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
---
arch/ia64/kernel/iosapic.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6.23-rc1/arch/ia64/kernel/iosapic.c
=================================--- linux-2.6.23-rc1.orig/arch/ia64/kernel/iosapic.c
+++ linux-2.6.23-rc1/arch/ia64/kernel/iosapic.c
@@ -794,8 +794,9 @@ iosapic_register_intr (unsigned int gsi,
err = register_intr(gsi, irq, IOSAPIC_LOWEST_PRIORITY,
polarity, trigger);
if (err < 0) {
+ spin_unlock(&irq_desc[irq].lock);
irq = err;
- goto unlock_all;
+ goto unlock_iosapic_lock;
}
/*
@@ -811,7 +812,7 @@ iosapic_register_intr (unsigned int gsi,
gsi, (trigger = IOSAPIC_EDGE ? "edge" : "level"),
(polarity = IOSAPIC_POL_HIGH ? "high" : "low"),
cpu_logical_id(dest), dest, irq_to_vector(irq));
- unlock_all:
+
spin_unlock(&irq_desc[irq].lock);
unlock_iosapic_lock:
spin_unlock_irqrestore(&iosapic_lock, flags);
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: ACPI: Uninitialized spinlocks & Unable to dump stack
2007-08-01 5:48 ACPI: Uninitialized spinlocks & Unable to dump stack Christoph Lameter
2007-08-01 12:18 ` Kenji Kaneshige
@ 2007-08-01 13:33 ` Jes Sorensen
2007-08-01 16:00 ` Russ Anderson
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Jes Sorensen @ 2007-08-01 13:33 UTC (permalink / raw)
To: linux-ia64
>>>>> "Kenji" = Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> writes:
Kenji> Hi,
Kenji> I don't know why no IOSAPIC entries was found on your system.
Kenji> But I think the cause of this stack trace is a bug in the code
Kenji> path of interrupt registering failure. Here is a patch to fix
Kenji> this bug. Could you try that?
Hi Kenji,
The answer to your first comment is simple - we don't have any in the
system :-)
Cheers,
Jes
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: ACPI: Uninitialized spinlocks & Unable to dump stack
2007-08-01 5:48 ACPI: Uninitialized spinlocks & Unable to dump stack Christoph Lameter
2007-08-01 12:18 ` Kenji Kaneshige
2007-08-01 13:33 ` Jes Sorensen
@ 2007-08-01 16:00 ` Russ Anderson
2007-08-01 20:02 ` Christoph Lameter
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Russ Anderson @ 2007-08-01 16:00 UTC (permalink / raw)
To: linux-ia64
Kenji Kaneshige wrote:
>
> 2007-07-31 (火) の 22:48 -0700 に Christoph Lameter さんは書きました:
> > With todays git I get (sn2_defconfig w/ spinlock debuggin):
>
> (snip.)
>
> > ACPI: Error parsing MADT - no IOSAPIC entries
> > register_intr: No IOSAPIC for GSI 52
> > BUG: spinlock bad magic on CPU#0, swapper/0
> > lock: a000000100bf66d0, .magic: 00000000, .owner: <none>/-1, .owner_cpu:
> > 0
> > unwind: cannot stack reg state!
> >
> > Call Trace:
> > [<a000000100013900>] show_stack+0x40/0xa0
>
> (snip.)
>
> Hi,
>
> I don't know why no IOSAPIC entries was found on your system.
> But I think the cause of this stack trace is a bug in the code
> path of interrupt registering failure. Here is a patch to fix
> this bug. Could you try that?
The good news is you patch gets rid of the spinlock BUG.
The bad news is the kernel boot on SN2 still hangs in udevsettle.
> Thanks,
> Kenji Kaneshige
>
> ---
>
> Fix wrong access to irq_desc[] in iosapic_register_intr().
>
> Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
>
> ---
> arch/ia64/kernel/iosapic.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.23-rc1/arch/ia64/kernel/iosapic.c
> =================================> --- linux-2.6.23-rc1.orig/arch/ia64/kernel/iosapic.c
> +++ linux-2.6.23-rc1/arch/ia64/kernel/iosapic.c
> @@ -794,8 +794,9 @@ iosapic_register_intr (unsigned int gsi,
> err = register_intr(gsi, irq, IOSAPIC_LOWEST_PRIORITY,
> polarity, trigger);
> if (err < 0) {
> + spin_unlock(&irq_desc[irq].lock);
> irq = err;
> - goto unlock_all;
> + goto unlock_iosapic_lock;
> }
>
> /*
> @@ -811,7 +812,7 @@ iosapic_register_intr (unsigned int gsi,
> gsi, (trigger = IOSAPIC_EDGE ? "edge" : "level"),
> (polarity = IOSAPIC_POL_HIGH ? "high" : "low"),
> cpu_logical_id(dest), dest, irq_to_vector(irq));
> - unlock_all:
> +
> spin_unlock(&irq_desc[irq].lock);
> unlock_iosapic_lock:
> spin_unlock_irqrestore(&iosapic_lock, flags);
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@sgi.com
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: ACPI: Uninitialized spinlocks & Unable to dump stack
2007-08-01 5:48 ACPI: Uninitialized spinlocks & Unable to dump stack Christoph Lameter
` (2 preceding siblings ...)
2007-08-01 16:00 ` Russ Anderson
@ 2007-08-01 20:02 ` Christoph Lameter
2007-08-01 20:34 ` Russ Anderson
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Christoph Lameter @ 2007-08-01 20:02 UTC (permalink / raw)
To: linux-ia64
On Wed, 1 Aug 2007, Russ Anderson wrote:
> The bad news is the kernel boot on SN2 still hangs in udevsettle.
We found two problems with clocks that account for the udevsettle hang.
Kenji's patch is still necessary to get rid of the spinlock problems.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: ACPI: Uninitialized spinlocks & Unable to dump stack
2007-08-01 5:48 ACPI: Uninitialized spinlocks & Unable to dump stack Christoph Lameter
` (3 preceding siblings ...)
2007-08-01 20:02 ` Christoph Lameter
@ 2007-08-01 20:34 ` Russ Anderson
2007-08-02 1:06 ` Keith Rich
2007-08-02 1:37 ` Keith Rich
6 siblings, 0 replies; 8+ messages in thread
From: Russ Anderson @ 2007-08-01 20:34 UTC (permalink / raw)
To: linux-ia64
Christoph Lameter wrote:
>
> On Wed, 1 Aug 2007, Russ Anderson wrote:
>
> > The bad news is the kernel boot on SN2 still hangs in udevsettle.
>
> We found two problems with clocks that account for the udevsettle hang.
>
> Kenji's patch is still necessary to get rid of the spinlock problems.
Thanks Christoph & Kenji!
With those two patches the kernel boots on SN2.
Life is good.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc rja@sgi.com
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: ACPI: Uninitialized spinlocks & Unable to dump stack
2007-08-01 5:48 ACPI: Uninitialized spinlocks & Unable to dump stack Christoph Lameter
` (4 preceding siblings ...)
2007-08-01 20:34 ` Russ Anderson
@ 2007-08-02 1:06 ` Keith Rich
2007-08-02 1:37 ` Keith Rich
6 siblings, 0 replies; 8+ messages in thread
From: Keith Rich @ 2007-08-02 1:06 UTC (permalink / raw)
To: linux-ia64
> With those two patches the kernel boots on SN2.
> Life is good.
Yes, I can boot on SN2 now with these two patches also. However,
I didn't really expect to see no udev messages in boot.log
wine3:/var/log # grep udev boot.msg
wine3:/var/log #
wine3:/var/log # grep udev boot.omsg
<notice>boot.udev start
Starting udevd done
<notice>'boot.udev start' exits with status 0
Waiting for udev to settle...
Waiting for udev to settle...
udev on /dev type tmpfs (rw)
<notice>boot.udev_retry start
<notice>'boot.udev_retry start' exits with status 0
I also didn't expect to see no usb recognized on this system,
but this problem did not show up on a second system I tried,
so that deserves further observation.
Keith
wine3:/var/log # lsusb
wine3:/var/log #
wine3:/var/log # grep usb boot.msg
wine3:/var/log #
wine3:/var/log # grep usb boot.omsg
<6>usbcore: registered new driver usbfs
<6>usbcore: registered new driver hub
<6>usb usb1: new device found, idVendor\000, idProduct\000
<6>usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb1: Product: EHCI Host Controller
<6>usb usb1: Manufacturer: Linux 2.6.16.27-0.6-default ehci_hcd
<6>usb usb1: SerialNumber: 0001:01:01.2
<6>usb usb1: configuration #1 chosen from 1 choice
<6>usb usb2: new device found, idVendor\000, idProduct\000
<6>usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb2: Product: OHCI Host Controller
<6>usb usb2: Manufacturer: Linux 2.6.16.27-0.6-default ohci_hcd
<6>usb usb2: SerialNumber: 0001:01:01.0
<6>usb usb2: configuration #1 chosen from 1 choice
<6>usb usb3: new device found, idVendor\000, idProduct\000
<6>usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1
<6>usb usb3: Product: OHCI Host Controller
<6>usb usb3: Manufacturer: Linux 2.6.16.27-0.6-default ohci_hcd
<6>usb usb3: SerialNumber: 0001:01:01.1
<6>usb usb3: configuration #1 chosen from 1 choice
<6>usb 2-1: new low speed USB device using ohci_hcd and address 2
<6>usb 2-1: new device found, idVendor\x04a5, idProductp03
<6>usb 2-1: new device strings: Mfr=4, Product , SerialNumber=0
<6>usb 2-1: Product: Generic USB Keyboard
<6>usb 2-1: Manufacturer: NOVATEK
<6>usb 2-1: configuration #1 chosen from 1 choice
<6>usb 3-1: new low speed USB device using ohci_hcd and address 2
<6>usb 3-1: new device found, idVendor\x046d, idProduct¿00
<6>usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0
<6>usb 3-1: Product: N43
<6>usb 3-1: Manufacturer: Logitech
<6>usb 3-1: configuration #1 chosen from 1 choice
<6>usbcore: registered new driver hiddev
<6>input: USB HID v1.10 Keyboard [NOVATEK Generic USB Keyboard] on usb-0001:01:01.0-1
<6>input: USB HID v1.00 Mouse [Logitech N43] on usb-0001:01:01.1-1
<6>usbcore: registered new driver usbhid
<6>drivers/usb/input/hid-core.c: v2.6:USB HID core driver
wine3:/var/log #
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: ACPI: Uninitialized spinlocks & Unable to dump stack
2007-08-01 5:48 ACPI: Uninitialized spinlocks & Unable to dump stack Christoph Lameter
` (5 preceding siblings ...)
2007-08-02 1:06 ` Keith Rich
@ 2007-08-02 1:37 ` Keith Rich
6 siblings, 0 replies; 8+ messages in thread
From: Keith Rich @ 2007-08-02 1:37 UTC (permalink / raw)
To: linux-ia64
> I didn't really expect to see no udev messages in boot.log
> wine3:/var/log # grep udev boot.msg
> wine3:/var/log #
I see this same behaviour on x86_64 as well as ia64.
Keith
^ permalink raw reply [flat|nested] 8+ messages in thread