[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