From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9)
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
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.
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.
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
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
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/