Bugzilla – Bug 146880
ipw2100 drivers in kernel 2.6.13-15 and 15.7 lock up the system with LEAP
Last modified: 2006-02-13 16:41:09 UTC
The current kernel causes a system lockup when used with ipw2100 and LEAP with WPA_SUPPLICANT. The kernel-of-the-day (2.6.16+) has the updated ipw2100 drivers, which don't have this problem. (tested and verified). If I do the obvious (use the ipw2100 source files from the kernel-of-the-day and put them into the kernel-source for current kernel) then I can't depend on using the update system. Besides, they require that I install a buttload of -devel packages ;-) The kernel-of-the-day kernel, while it works, causes subdomain to fail. (subdomainfs is not supported in it). So, any chance of getting a 2.6.13-15.8 from you guys with the updated ipw2100 drivers? Please?
Created attachment 65811 [details] This is the patch I submitted to mainline This is the fix for the direct_scan lockup that went into mainline.
Joachim, can you please apply this patch to wireless-tools in 10.0 and submit this to autobuild? It should fix the lockup problem - but maybe you want to build a test kernel first - your call. Please reassign back to me if the fix doesn't help.
The ipw2100 driver version in the KOTD was 1.1.3, and it worked. According to James Ketrenos (from Intel), it added support for the function that the system was failing on. Anyhow, it worked. Latest from ipw2100.sf.net is 1.1.4. Does this patch update to that or does it patch the 1.1.0 that was in the 2.6.13-15.7 kernel source? Anyhow, many thanks for jumping on this so quickly.
BTW, this patch seems specific to ipw2200, not ipw2100. Will it work for both?
The patch is indeed for ipw2200 only. ipw2100 prior to 1.1.4 doesn't support LEAP authentication, but it shouldn't hang the system if you try to use it. Could you specify what is the behaviour of the system during that lockup? (Is the system completely frozen? Or just wpa_supplicant and networking-related apps? Something another?)
Actually, the WPA does the LEAP for me, and it does a good job at it. It was one of the SCIO commands which was failing prior to 1.1.3. (I will attach my ifcfg-wlan and my /etc/wpa_supplicant.conf. The system did an entire 100% lockup. I have talked with James Katrenos from Intel about this, and the lockup has occured to others, not just me. The driver version in the current kernel causes this. To get subdomain working again, I took my kernel back down to current 10.0 levels, and immediately got the lockups again. I had to comment out the LEAP network definition from /etc/wpa_supplicant.conf, and for now must use Windows to connect wirelessly when I leave my desk. Let's not worry so much at the moment about re-creation. It happens, and has happened to others. The real question, at least in my mind, is this: is an ipw2100 driver update to 1.1.4 too much for a 10.0 kernel update? I'm selfish - I don't want to wait for 10.2, etc. The firmware stays the same - only the ipw2100 driver needs updated, so theoretically it would be a simple re-compile to create 2.6.13-15.8. Just my 2 cents worth.
Created attachment 66038 [details] Wlan ifcfg file
Created attachment 66040 [details] wpa_supplicant configuration Both home and work networks are currently commented out. SCPM profile Home activates the home network. SCPM Work used to activate the LEAP network, but has now been commented out.
It's unlikely that the project manager will agree on updating the driver in SL10.0. It is IMHO not a critical bug as we don't officially support LEAP. But no one stops you from using a newer kernel on your 10.0 system. And SL10.1 isn't far away. :-) But nevertheless, Andreas has to decide on the update issue.
No, we will not update 10.0. But please check that this works in 10.1!
I had other issues with Subdomain (lotsa fun with Mozilla saves). So, if I don't need subdomain, I can freely update the kernel. I am now using 2.6.16-rc2-git5-20060209165635-default. If this is what is going into 10.1, then ipw2100/ieee80211 are the correct versions to work with LEAP and WEP and multiple network {} definitions in /etc/wpa_supplicant. Given AJ's comment from above, I am moving this to WONTFIX.