ACPI: Uninitialized spinlocks & Unable to dump stack

ACPI: Uninitialized spinlocks & Unable to dump stack

[Christoph Lameter]

With todays git I get (sn2_defconfig w/ spinlock debuggin):

Uncompressing Linux... done
Linux version 2.6.23-rc1 (clameter@schroedinger) (gcc version 4.1.2 
20061115 (prerelease) (Debian 4.1.1-21)) #3 SMP PREEMPT Tue Jul 31 
22:42:03 PDT 2007
EFI v1.10 by INTEL: SALsystab=0x3002a09000 ACPI 2.0=0x3002a097f0
console [sn_sal0] enabled
ACPI: RSDP 3002A097F0, 0024 (r2    SGI)
ACPI: XSDT 3002A0E320, 0044 (r1    SGI  XSDTSN2    10001           5C)
ACPI: APIC 3002A09890, 008C (r1    SGI  APICSN2    10001            1)
ACPI: SRAT 3002A09930, 0150 (r1    SGI  SRATSN2    10001            1)
ACPI: SLIT 3002A09A90, 003C (r1    SGI  SLITSN2    10001            1)
ACPI: FACP 3002A09B30, 00F4 (r3    SGI  FACPSN2    30001            1)
ACPI: DSDT 3002A0D8A0, 0024 (r2    SGI  DSDTSN2    20001          9BA)
ACPI: FACS 3002A09AE0, 0040
Number of logical nodes in system = 4
Number of memory chunks in system = 4
SAL 2.9: SGI SN2 version 4.80
SAL Platform features: ITC_Drift
SAL: AP wakeup using external interrupt vector 0x12
No logical to physical processor mapping available
ACPI: Local APIC address c0000000fee00000
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
                                sp 00000100b67a80 bsp 00000100b610b8
unwind: cannot stack reg state!
 [<a000000100013990>] dump_stack+0x30/0x60
                                sp 00000100b67c50 bsp 00000100b610a0
unwind: cannot stack reg state!
 [<a000000100433010>] spin_bug+0x110/0x180
                                sp 00000100b67c50 bsp 00000100b61068
unwind: cannot stack reg state!
 [<a0000001004330d0>] _raw_spin_unlock+0x50/0x120
                                sp 00000100b67c50 bsp 00000100b61038
unwind: cannot stack reg state!
 [<a0000001007eb560>] _spin_unlock+0x20/0xa0
                                sp 00000100b67c50 bsp 00000100b61018
unwind: cannot stack reg state!
 [<a00000010004ec40>] iosapic_register_intr+0xb40/0xba0
                                sp 00000100b67c50 bsp 00000100b60fa8
unwind: cannot stack reg state!
 [<a00000010000a5e0>] acpi_register_gsi+0xc0/0xe0

Re: ACPI: Uninitialized spinlocks & Unable to dump stack

[Kenji Kaneshige]

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

Re: ACPI: Uninitialized spinlocks & Unable to dump stack

[Jes Sorensen]

>>>>> "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

Re: ACPI: Uninitialized spinlocks & Unable to dump stack

[Russ Anderson]

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

Re: ACPI: Uninitialized spinlocks & Unable to dump stack

[Christoph Lameter]

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.

Re: ACPI: Uninitialized spinlocks & Unable to dump stack

[Russ Anderson]

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

Re: ACPI: Uninitialized spinlocks & Unable to dump stack

[Keith Rich]

> 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

Re: ACPI: Uninitialized spinlocks & Unable to dump stack

[Keith Rich]

> 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