Hello, Ever since kernel version 2.6.32, when I try to bring up my Intel WiFi 5100 interface(with wicd or network-manager), I get a hard lock withing a second or so. All the 2.6.31.x kernels work correctly but ever since 2.6.32, I get the hard lock. The last version with which I tested is 2.6.36.2 and the problem still occurred. Using trial and error, I managed to find the exact commit that breaks things in the git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git tree. It's commit id : 5c3cc2084dd9dc26b258f88abb629550090956e0 With the previous commit in the tree (851b147e4411df6a1e7e90e2a609773c277eefd2) everything works fine. Here is a uname -a of a kernel that works correctly : Linux shinny 2.6.31.13 #4 SMP Thu Aug 5 18:03:57 EDT 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20GHz GenuineIntel GNU/Linux Also, this is the part of the output of lspci -vv that lists information about the WiFi card : 0d:00.0 Network controller: Intel Corporation WiFi Link 5100 Subsystem: Intel Corporation WiFi Link 5100 AGN Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 30 Region 0: Memory at f0300000 (64-bit, non-prefetchable) [size=8K] Capabilities: <access denied> Kernel driver in use: iwlagn Kernel modules: iwlagn Since this causes a hard lock, I'm not quite sure how I can provide more information. Running dmesg in a tight loop managed to produce some output from iwlagn before the system is completely frozen, but nothing looked revealing. I will try to take a picture of the information displayed there and add it to this bug report. Thank you for your help!
My Intel 5100 card works very well with kernel 2.6.37 and the latest linux-firmware package.
(In reply to comment #0) > Using trial and error, I managed to find the exact commit that breaks things > in > the git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > tree. > It's commit id : 5c3cc2084dd9dc26b258f88abb629550090956e0 > > With the previous commit in the tree > (851b147e4411df6a1e7e90e2a609773c277eefd2) > everything works fine. Bad commit is a merge, it corporate many individual commits. Could you be so kind, and bisect problem further: [linux-2.6.32.y]$ git bisect start [linux-2.6.32.y]$ git bisect bad 5c3cc2084dd9dc26b258f88abb629550090956e0 [linux-2.6.32.y]$ git bisect good 851b147e4411df6a1e7e90e2a609773c277eefd2 It should be 6 more steps, to find real bad commit.
prozzaks@gmail.com, please respond to comment 2.
Sorry for the long delay for the reply. I tested numerous kernels and here are some of the results. I included the last known working kernel revision and all the tests until I confirmed the hard lock. However, starting at revision ca386f3137eb68621fadba546d9eb35ac2f82de3, there is no Hard-lock, but the Wifi no longer works correctly. 1a9b6679adfb8ef1f1f3dbb7ebd2ee72e2ea4b56 p54: generate channel list dynamically Hard-lock 596a07c18b35c9df2fb212856241ae0dfe3162b9 cfg80211: fix more bugs in mlme handling Not tested 930c06f27120fa8cf0bfb6fa000a701cfaf01ed6 rt2x00: Implement set_tim callback for all drivers Not tested 48ab905d1a81b7df33a33def04a890e4e0c51460 nl80211: report BSS status Not tested 4697fe4f78df14d37cffa7e8d27cbb02a351c139 cfg80211: fix wext setting SSID Not tested 908d4369a394e816767d566d9c3d15a5af8c1c55 cfg80211: don't look at wdev->ssid for giwessid Not tested 4b14c96dfbf068acb85c3fa2446b3949c0230deb mac80211_hwsim: report fixed signal strength Not tested c56c5714f12808e3f702817e72a78dd12f1704eb cfg80211: fix wext stats Does not lock on wpa_supplicant, systematically loses connection when trying to dhcpcd wlan0 and hard-lock on CTRL-C wpa_supplicant ca3dbc20d47ae43c201c215259d078e227bfcf01 cfg80211: update misleading comment Not tested a43816df2a1a61effcb701037bdf63621d066182 mac80211: mesh: fix two small problems Not tested ec3f149017ef3fd21343b1dcec3589eec6ba5dd5 cfg80211: fix a locking bug bad : Does not lock on wpa_supplicant, systematically loses connection when trying to dhcpcd wlan0 and hard-lock on CTRL-C wpa_supplicant b291ba11181d46dfbd2d7a5c00a5f3335228191e mac80211: monitor the connection bad : Does not lock on wpa_supplicant, systematically loses connection when trying to dhcpcd wlan0 and hard-lock on CTRL-C wpa_supplicant ca386f3137eb68621fadba546d9eb35ac2f82de3 mac80211: fix multi-use timer No hard-lock, but doesn't work 01a7e08436929271c6173b5daf3e193ef5b3561a iwlagn: fix minimum number of queues setting Works perfectly
ca386f3137eb68621fadba546d9eb35ac2f82de3 mac80211: fix multi-use timer No hard-lock, but doesn't work 01a7e08436929271c6173b5daf3e193ef5b3561a iwlagn: fix minimum number of queues setting Works perfectly and after commit#01a7e08436929271c6173b5daf3e193ef5b3561a, everything works again? I am confuse, is there a issue? Thanks Wey
Commit 01a7e08436929271c6173b5daf3e193ef5b3561a is older than ca386f3137eb68621fadba546d9eb35ac2f82de3. In my previous post, the oldest commit is at the bottom and the newest is at the top. In other words, it doesn't work ever since commit ca386f3137eb68621fadba546d9eb35ac2f82de3. Cheers, Prozzaks
commit ca386f3137eb68621fadba546d9eb35ac2f82de3 Author: Johannes Berg <johannes@sipsolutions.net> Date: Fri Jul 10 02:39:48 2009 +0200 mac80211: fix multi-use timer We have, sometimes, multiple things that want to run but don't have their own timer. Introduce a new function to mac80211's mlme run_again() that makes sure that the timer will run again at the _first_ needed time, use that function and also properly reprogram the timer once it fired. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
oops misread #7, re-opening
Closing as obsolete, if this is still seen on modern kernels please update