Bug 41390

Summary:	suspend on resume hangs due to pcmcia irq issues
Product:	[Retired] Red Hat Linux	Reporter:	jon
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Brock Organ <borgan>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.2	CC:	hrt
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-09-30 15:39:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description jon 2001-05-19 18:34:52 UTC

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.

Comment 1 Arjan van de Ven 2001-05-19 18:45:01 UTC

Does it work if you stop cardmgr and unload the yenta module before the suspend
?

Comment 2 jon 2001-05-19 19:28:04 UTC

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.

Comment 3 Arjan van de Ven 2001-05-19 19:32:20 UTC

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.

Comment 4 jon 2001-05-19 19:36:06 UTC

Oops, I was unclear. Even removing the pcmcia driver, it still freezes.

Sorry for the confusion.

Comment 5 Arjan van de Ven 2001-05-19 19:38:03 UTC

So it works before yenta_socket is ever loaded, but fails once you've loaded and
unloaded it... hrmm

Comment 6 jon 2001-07-23 15:53:14 UTC

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.

Comment 7 Need Real Name 2003-02-25 21:42:30 UTC

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.

Comment 8 Need Real Name 2003-06-15 15:43:39 UTC

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.

Comment 9 Bugzilla owner 2004-09-30 15:39:00 UTC

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/