Created attachment 125173 [details]
log portion

Created attachment 125174 [details]
possible fix/patch (to be cleaned up)

see also bug#246966 comments #12-#16

Created attachment 125923 [details]
NM log portion showing above patch working

Just as small addition.. that show the previously sent patch working.
Now (with the patch active) the wireless device (ipw3945) stays working.. while without i always need a rcnetwork restart get it back working.

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.

I guess you either see a totally different patch than i do (in comment #2) or you have a interesting definition of the term "rescan" .. especially as the patch just retries to set the wlan-nic's essid if that failed with -EAGAIN.
Calling messages like "nm_device_802_11_wireless_set_essid(): error setting ESSID to '' for device eth1: Resource temporarily unavailable" cosmetic if due to this afterwards no network connection can get established until one does a "rcnetwork restart" is also "interesting".

The logs of this special machine (and NM/openSuSE version-combination) don't exist anymore in the meantime (as it now took quite a while (> 1 month)) .. but i guess it should be reproduceable for you with any R60/T60 or even X60 having a ipw3945 and 10.3 installed.
If thats not possible for you i'll recheck with my manager if i may bail you out.

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.

as already written above.. the logs don't exist anymore and further the machine is not available anymore in the meantime 

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.

I saw similar results on the machine that you set me for testing 255765. Here are the relevant log entries:

Apr 27 14:32:44 coolx60 NetworkManager: <info>  Waking up from sleep.
Apr 27 14:32:44 coolx60 NetworkManager: <info>  Deactivating device eth1.
Apr 27 14:32:44 coolx60 NetworkManager: <WARN>  nm_device_802_11_wireless_set_es
sid(): error setting ESSID to '' for device eth1: Resource temporarily unavailab
le
Apr 27 14:32:44 coolx60 NetworkManager: <WARN>  nm_device_802_11_wireless_set_we
p_enc_key(): error setting key for device eth1: Resource temporarily unavailable
Apr 27 14:32:44 coolx60 NetworkManager: <WARN>  nm_device_802_11_wireless_get_mo
de(): error getting card mode on eth1: Resource temporarily unavailable
Apr 27 14:32:44 coolx60 NetworkManager: <WARN>  nm_device_802_11_wireless_set_mo
de(): error setting card eth1 to Infrastructure mode: Resource temporarily unava
ilable
Apr 27 14:32:44 coolx60 NetworkManager: <info>  Deactivating device eth0.

When I saw these errors in the log file, NetworkManager never added the wireless device back to it's device list. Why that happens, see the second problem described at https://bugzilla.novell.com/show_bug.cgi?id=255765#c50 . Did you see the same behavior? Your patch from comment #2 would fix it indeed, but only because of sleep(2) line in there - it would give the driver more time for setup.

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.

*** This bug has been marked as a duplicate of bug 232420 ***