https://bugzilla.novell.com/show_bug.cgi?id=255666 ------- Comment #1 from fseidel@novell.com 2007-03-18 06:22 MST ------- Created an attachment (id=125173) --> (https://bugzilla.novell.com/attachment.cgi?id=125173&action=view) log portion -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=255666 ------- Comment #3 from fseidel@novell.com 2007-03-18 06:26 MST ------- see also bug#246966 comments #12-#16 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=255666 tambet@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |fseidel@novell.com ------- Comment #5 from tambet@novell.com 2007-04-24 07:51 MST ------- Can you please attach the full log of NM waking up from sleep? The log from comment #1 has only a couple of useless lines (these are cosmetic only). Here's what happens when NM wakes up from sleep: * Remove old devices (devices that were available before suspend). That triggers the deactivation of each device again, and the log from comment #1 has errors from that state only. * Get a new list of devices from HAL. Initiate a wireless scan for each wireless device. * Once the scan is done and NM gets a list of available APs, check if any of the scanned AP's match saved "good" APs and if so, activate the good AP. So there's no need to force a rescan on resume, since NM starts scanning on every added device already. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=255666 ------- Comment #7 from tambet@novell.com 2007-04-24 09:09 MST ------- I'm sorry that I tried to unsuccessfully describe of what is happening, but you are missing the point. Please add the log files here, thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=255666 ------- Comment #10 from tambet@novell.com 2007-04-25 04:25 MST ------- As I said in comment #5, these errors are cosmetic and do not cause any issues. Let's try this again: When NM gets the sleep request, it doesn't fully release the devices, there's not enough time. When NM is awaken, it continues the release of it's devices. That's where these errors from comment #1 are from. It doesn't really matter at this point, since the devices might not even be physically connected at that point. The whole drill happens only to have one code path for releasing a device. After all the previous devices are released, NM asks HAL for the current list of available network devices and starts a scan for each wireless device. So, it doesn't matter if the shutdown of the device fails with these errors, because when adding a device, it is always configured as it was never seen before. The real bug is in device initialization somewhere, not in device release. The patch from comment #2 only masks the actual issue by waiting long enough to give the driver a chance to finish with whatever it's doing on resume. There would still be a bug when a card is inserted at some point and NM notices it before it's done with whatever initialization it's doing on startup. It's still some ioctl failing on startup, but I don't know which one. The device is queried by wireless extensions and it might be a a missing EAGAIN handling either in NM or wireless extensions. So please, don't take it personally that I do not approve the patch, it's just not correct. It might fix the problem for you, but it's not correct in general. If we do not have the ability to reproduce it, we might as well close it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.novell.com/show_bug.cgi?id=255666 ------- Comment #13 from jmichael@novell.com 2007-05-24 19:18 MST ------- When I've seen this problem, it's only been when I'm resuming while near the same network I suspended from. I believe what's happening is that the ipw3945 driver remembers the last essid it was associated with so when the machine comes out of suspend, the ipw3945 automagically reassociates with that network and when NM comes along and says "hey, associate with this essid!", the ipw3945 driver is already associated with it so the driver doesn't give any sort of "hey, now i'm associated with that essid you asked for!" event and NM thinks that the association failed. When that happens, if I use iwconfig to manually set the essid to something else, NM will be able to correctly associate with the network. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.