Created attachment 324778 [details]
dmesg output up to hang
Description of problem:
Complete system hang after NM connects to my wireless network
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot in level 5
2. Login to system
3. NM connects to wireless network
System hang after connection is made
Normal functioning system after wireless connection is ready
System: Asus R50A UMPC
Wireless driver: libertas_sdio
Encryption used: WPA-PSK
When using the wireless card from the shell in level 3 (manual connection with wpa_supplicant) the wireless connection works flawlessly. I can even download and install 150MB of updates without problem.
When in X NM shows my and other neighbouring networks with their signal levels just fine. But after the connection is made, complete system hang.
When giving NM the wrong password for my network, it tries to connect and fails (obviously). System keeps working normally after that.
Current running kernel is actually: kernel-184.108.40.206-117.fc10.i686
If the box ever hangs, it's a kernel problem, not a NetworkManager problem. The issue is likely that the driver/hardware don't properly handle concurrent requests sometimes, and I know that's the case because I'm also the libertas driver maintainer upstream :)
What exact Libertas 8686 firmware version are you running, and where did you get it from?
I guess you are right it being a kernel problem :). I hope this is fixable.
I've downloaded the firmware directly from the Marvell site (filename: SD-8686-LINUX26-SYSKT-9.70.3.p24-26409.P45-GPL.zip). The driver reports it as:
libertas: 00:19:88:05:7e:84, fw 9.70.3p24, cap 0x00000303
I could not find any other version on the net.
BTW building and testing a out-of-kernel driver to test is not a problem :)
sha1sum's of the firmware files are:
I did some more testing. Enabling libertas debugging does not really help, the generated messages cannot be captured :(. I've also tried a connection with any encryption, the system still hangs solid after the IP address is registered.
BTW I tried a prerelease of Ubunty Jaunty (build 5-dec-08), the results are exactly the same. The also use a 2.6.27 kernel.
Anyway to move this further?
Sorry to see this bug is not being picked up yet...
With the latest rawhide the problem still persists. The wireless adapter still works great when started from the command line but with NM it locks up the system after the connection is completed.
BTW the hard lock prevents me from getting anything useful from the log messages.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Does this happen on later kernels, specifically 2.6.29 and later?
Sorry, I no longer have the hardware. So I am not able to test it further. I guess this bug can be closed.
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.