[Prism54-devel] [Bug 130] New: S3 wakeup messes up prism54
bugzilla-daemon at mcgrof.com
bugzilla-daemon at mcgrof.com
Sat Aug 6 07:38:59 UTC 2005
http://prism54.org/cgi-bin/bugzilla/show_bug.cgi?id=130
Summary: S3 wakeup messes up prism54
Product: prim54
Version: 1.2
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Device Driver
AssignedTo: prism54-devel at prism54.org
ReportedBy: sanjoy at mrao.cam.ac.uk
Now that S3 sleep/wake is quite usable I'm pushing my luck and hoping that the
network state will be saved and restored (like on iBook's!). If I suspend while
the network is running, it hangs stopping tasks, so that pushes my luck too far.
But as a step in that direction, if I 'ifdown eth0' but leave the prism54 module
loaded, then I can suspend and resume without hanging but the card comes back in
a funny state. As the Thinkpad's suspend light starts blinking during the
wakeup, the wlan card's light blinks a few times and then turns on and stays on,
even though it's not connected to any network (and isn't even trying to
connect). Before going to sleep, the card's light was off, just as it always is
when I insert the card (it only turns on when
The card is then not in a happy state. If I tell it about a known good wireless
network, e.g. iwconfig eth0 essid WLAN, it doesn't associate. If I do 'cardctl
eject', that process hangs in 'D' state waiting for the use count to drop from
5. From the syslog/dmesg:
kernel: unregister_netdevice: waiting for eth0 to become free. Usage count = 5
But it never gets free.
If instead of messing about with cardtl, I remove the module, physically eject
and insert the card, then the card works fine. I'm writing this bug report
using it that way. Or, if I remove the module before the sleep, all is also
well (but that means no chance of ever preserving and restoring the network state).
With the right combination of bad things after the suspend/resume, which I
haven't been able to reproduce (but roughly 'ifup eth0' with the card in the bad
state), I get
eth0: timeout waiting for mgmt response 1000, triggering device
or
eth0: mgt_commit_list: failure. oid=ff020008 err=-110
eth0: mgt_commit_list: failure. oid=19000001 err=-12
I'm happy to try patches or otherwise debug.
Hardware: TP 600X, wlan card: Intersil ISL3890 [Prism GT/Prism Duette]
Kernel: 2.6.13-rc5-git3
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the Prism54-devel
mailing list