Re: 2.6.10-rc2-mm2: spinlock problem in arch/i386/kernel/time.c onresume

[Andrew Morton]

Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>
> When I resume my laptop (ThinkPad X31) from a APM sleep, it crashes on
> resume.
> 
> On resume, it prints on the console:
>         
>         arch/i396/kernel/time.c:178: spin_lock(arch/i386/kernel/time.c:c0347f28) is already locked by arch/i386/kernel/time.c/310
>         arch/i386/kernel/time.c:317 spin_unlock(arch/i386/kernel/time.c:c0347f28) is not locked
>         PCI: Enabling device 0000:00:1f.5 (0000 -> 0003)
>         
> and is then completely locked up. c0347f28 maps to rtc_lock.

I can't imagine how that could happen.  I wonder if the spinlock debugging
could be making a mistake.

> .config & lspci attached

I have but a lowly A21P.  With my .config it APM resumes happily.  With
yours it refuses to even suspend.  And:



hdc: DMA disabled
e100: Intel(R) PRO/100 Network Driver, 3.2.3-k2-NAPI
e100: Copyright(c) 1999-2004 Intel Corporation
PCI: Found IRQ 11 for device 0000:00:03.0
PCI: Sharing IRQ 11 with 0000:00:03.1
irq 11: nobody cared!
 [<c010393d>] dump_stack+0x19/0x20
 [<c013cb73>] __report_bad_irq+0x33/0x9c
 [<c013cc58>] note_interrupt+0x50/0x7c
 [<c013c2c2>] __do_IRQ+0x226/0x2c3
 [<c0104bd7>] do_IRQ+0x67/0x90
 =======================
 [<c0103416>] common_interrupt+0x1a/0x20
 [<c0104ce6>] do_softirq+0x3a/0x4c
 =======================
 [<c012114a>] irq_exit+0x2a/0x34
 [<c0104bef>] do_IRQ+0x7f/0x90
 [<c0103416>] common_interrupt+0x1a/0x20
 [<c0156e4b>] get_vm_area+0x2b/0x30
 [<c0114ff7>] __ioremap+0xa3/0xe0
 [<d082073f>] e100_probe+0x257/0x620 [e100]
 [<c01e2899>] pci_device_probe_static+0x2d/0x48
 [<c01e28d4>] __pci_device_probe+0x20/0x3c
 [<c01e290e>] pci_device_probe+0x1e/0x3c
 [<c021fb7d>] driver_probe_device+0x3d/0x64
 [<c021fc60>] driver_attach+0x3c/0x74
 [<c02200ce>] bus_add_driver+0x82/0xc0
 [<c022064f>] driver_register+0x43/0x50
 [<c01e2b4b>] pci_register_driver+0x8f/0xb0
 [<d0826044>] e100_init_module+0x44/0x48 [e100]
 [<c013a047>] sys_init_module+0x1d3/0x2ac
 [<c0102aa7>] syscall_call+0x7/0xb
handlers:
[<c025eea0>] (yenta_interrupt+0x0/0x30)
[<c025eea0>] (yenta_interrupt+0x0/0x30)
Disabling IRQ #11
e100: eth0: e100_probe: addr 0xf0120000, irq 11, MAC addr 00:10:A4:92:1E:06
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x3b8-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
e100: Intel(R) PRO/100 Network Driver, 3.2.3-k2-NAPI
e100: Copyright(c) 1999-2004 Intel Corporation
PCI: Found IRQ 11 for device 0000:00:03.0
PCI: Sharing IRQ 11 with 0000:00:03.1
e100: eth0: e100_probe: addr 0xf0120000, irq 11, MAC addr 00:10:A4:92:1E:06
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
localhost:/home/akpm> cat /proc/interrupts
           CPU0       
  0:     237701          XT-PIC  timer
  1:         92          XT-PIC  i8042
  2:          0          XT-PIC  cascade
 11:     100633          XT-PIC  yenta, yenta, eth0
 12:        198          XT-PIC  i8042
 14:       2750          XT-PIC  ide0
 15:         25          XT-PIC  ide1
NMI:          0 
LOC:          0 
ERR:          0
MIS:          0

Yet the ethernet still works.  Presumably the e100 initialisation went and
reenabled it.   Let me try reverting your e100 patch...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/