From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9) Gecko/20010507 Description of problem: On Red Hat 6.2, restores on this laptop hung until I gave the pcmcia drivers the option cs_irq=11 (the notebook defaults to 9, which is the same IRQ as just about everything else...) On Red Hat 7.1, with the 2.4 kernel, the yenta_socket driver (which replaces the i82365 driver) does not offer a similar option. Looking through similar bugzilla tickets, I came across two possible solutions, neither entirely successful. The first was to set the kernel option pci=irqmask=0xf2ff to mask out irq9. It doesn't seem to successfully mask the irq. The other solution was to downgrade the apmd package to that from Red Hat 7.0. Interestingly, with that driver I could safely suspend in single-user mode but not in multi-user mode. (Suspending with the correct 7.1 apmd package always fails, single-user mode included.) That's as far as I've gotten debugging the problem. If I could just force the yenta driver to irq11 or irq10, I'm confident that the problem would be solved. Then again, I've been wrong before. How reproducible: Always Steps to Reproduce: 1.hit suspend (either to disk or to memory) 2.turn the laptop on, or hit a key to restore from memory 3.watch it freeze Actual Results: Laptop freezes Expected Results: Should have restored and continued to operate. Additional info: related output from dmesg: Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Found IRQ 9 for device 00:0a.0 PCI: The same IRQ used for device 00:08.1 Yenta IRQ list 0cb8, PCI irq9 Socket status: 30000416 cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x140-0x147 0x170-0x177 0x370-0x37f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. cs: memory probe 0xa0000000-0xa0ffffff: clean.
Does it work if you stop cardmgr and unload the yenta module before the suspend ?
Geez. Yes, it does. Also, I was wrong about single-user mode: it works with no apm loaded (the default), not with the older one loaded. OK, so it may not be PCMCIA issues, maybe some other APM problem. Sorry about that. Urk.
Well, you know have a workaround; putting the stop / unload in a presuspend script and restarting it in a postsuspend-script will make it work. That doesn't mean it's a fix: in a perfect world this would not be needed. It seems the IRQ yentasocket choses is "unfortionate" for other people too, this needs looking into. Why this blocks suspend is a mystory so far; Linux is very happy to share IRQs.
Oops, I was unclear. Even removing the pcmcia driver, it still freezes. Sorry for the confusion.
So it works before yenta_socket is ever loaded, but fails once you've loaded and unloaded it... hrmm
After updating to the 2.4.3-12 kernel package, this problem has gone away. Suspend and resume now work just fine, even with PCMCIA loaded.
I have a similar problem using RH 7.2 on my laptop. Although, as a work around, it seems that I can eject the PCMCIA card, suspend, then resume (with the card out, I need to try putting the card in before resuming still). However, As I use a PCMCIA Network card I need to restart the network every time. I found one note on the web suggesting a fix - downgrade pcmcia-cs to the one supplied with RH 7.0! I don't like that solution. The author said he hadn't tested the pcmcia-cs package that comes with 7.3 or 8, so he wasn't sure if the problem was fixed. So, I tried upgrading my pcmcia-cs to the version that comes with RH8.0, after reconfiguring, reinstalling, etc. pcmcia-cs and wlan-ng (I need it for my wireless card at home), I still have the same problem. I'll see what happens when I resume with the card in, but I'm not optimistic.
Just an update, I have been able to suspend to RAM reliably now for quite some time. I just have to make sure that I do not have any networked drives mounted before I suspend. I have not been suspending to disk for a couple of reasons, one, I don't remember it being as reliable, and 2, it takes almost as long to turn back on as a full system shutdown.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/