> So, in short, problem is that if you leave prism54 card in, even
> with module removed, swsusp hangs, right?
Right, in some circumstances. To narrow them down I spent many hours
rebooting into combinations of runlevels and loaded modules. It is
reproducible even in single-user mode. The various permutations, all
from booting single user with almost no modules loaded (cmdline:
idebus=66 apm=off acpi=force pci=noacpi single)
card: prism54 card/xircom Ethernet+modem card/no card
cardctl eject: done before the hibernate/ not done before the hibernate
The one combination that always breaks is to have the prism54 card in,
then do 'cardctl eject', which always produces:
[4295438.170000] PCMCIA: socket e233c02c: *** DANGER *** unable to
remove socket power
If I then use a simple hibernate script (basically just unload
prism54, then echo disk > /sys/power/state), swsusp doesn't write the
pages. These are the only modules loaded before the swsusp begins:
pcmcia 34276 0
crc32 3808 1 pcmcia
intel_agp 20188 1
firmware_class 7936 1 pcmcia
yenta_socket 23244 3
rsrc_nonstatic 11776 1 yenta_socket
pcmcia_core 39508 3 pcmcia,yenta_socket,rsrc_nonstatic
agpgart 29800 1 intel_agp
If I don't do 'cardctl eject', or do 'cardctl eject' and 'cardctl
insert', then run the hibernate script (which unloads prism54), it
hibernates fine.
With no card in the slot, all is well.
With the xircom card in the slot, hibernation works fine if I don't do
'cardctl eject' first. If I do 'cardctl eject' that produces the same
DANGER message as with the prism54 card. But hibernation still works,
although it seems a bit suspect: As it is hibernating, messages appear
about it enabling eth0.
Here's the lspci for the xircom card:
0000:06:00.0 Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)
0000:06:00.1 Serial controller: Xircom Cardbus Ethernet + 56k Modem
(rev 03) (prog-if 02 [16550])
And lspci -vv for the prism54:
0000:06:00.0 Network controller: Intersil Corporation Intersil ISL3890
[Prism GT/Prism Duette] (rev 01)
Subsystem: Intersil Corporation: Unknown device 0000
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 24800000 (32-bit, non-prefetchable)
[size=8K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
I also noticed the familiar 'irq 9: nobody cared' messages in the
dmesg log, which may be related to the problems above:
[4296190.977000] suspend: (pages needed: 5792 + 512 free: 141637)
[4296190.977000] alloc_pagedir(): nr_pages = 5792
[4296190.977000] create_pbe_list(): initialized 5792 PBEs
[4296190.977000] copy_data_pages(): pages to copy: 5792
[4296190.977000] [nosave pfn 0x3b1]<7>[nosave pfn
0x3b2]<3>[4296242.039000] irq 9: nobody cared (try booting with the
"irqpoll" option)
[4296242.039000] [<c013e22a>] __report_bad_irq+0x2a/0xa0
[4296242.039000] [<c013da10>] handle_IRQ_event+0x30/0x70
[4296242.039000] [<c013e340>] note_interrupt+0x80/0xf0
[4296242.039000] [<c013db84>] __do_IRQ+0x134/0x140
[4296242.039000] [<c0104c83>] do_IRQ+0x23/0x40
[4296242.039000] [<c01033e2>] common_interrupt+0x1a/0x20
[4296242.039000] [<c01208e3>] __do_softirq+0x43/0xb0
[4296242.039000] [<c012097d>] do_softirq+0x2d/0x30
[4296242.039000] [<c0120a57>] irq_exit+0x37/0x40
[4296242.039000] [<c0104c88>] do_IRQ+0x28/0x40
[4296242.039000] [<c01033e2>] common_interrupt+0x1a/0x20
[4296242.039000] [<c013ba00>] swsusp_suspend+0x50/0xc0
[4296242.039000] [<c013c7a1>] pm_suspend_disk+0x61/0xd0
[4296242.039000] [<c013a226>] enter_state+0xa6/0xb0
[4296242.039000] [<c013a362>] state_store+0x92/0x9e
[4296242.039000] [<c0199fdd>] subsys_attr_store+0x3d/0x50
[4296242.039000] [<c019a28e>] flush_write_buffer+0x3e/0x50
[4296242.039000] [<c019a2f4>] sysfs_write_file+0x54/0x80
[4296242.039000] [<c0160026>] vfs_write+0xb6/0x180
[4296242.039000] [<c01601c1>] sys_write+0x51/0x80
[4296242.039000] [<c0103225>] syscall_call+0x7/0xb
[4296242.039000] handlers:
[4296242.039000] [<c01f0789>] (acpi_irq+0x0/0x16)
[4296242.039000] Disabling IRQ #9
The lspci -vv has this, so somebody should care about irq 9!
0000:00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 03)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV-
VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 9
> Perhaps the patch from Daniel Ritz to free the yenta IRQ on suspend
> (attached) will help?
I will try that next.
-Sanjoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |