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