First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 102104
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Mobile Herd <mobile@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Chris Bainbridge (RETIRED) <chrb@gentoo.org>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 102104 depends on: Show dependency tree
Show dependency graph
Bug 102104 blocks: 110791
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2005-08-11 04:32 0000
I updated to the new 0.1_pre20050809 version. Upon reboot, activating wifi
produces a kernel fault. I try downgrading back to 0.1_pre20050420, but IT
DOESNT WORK. It worked last night, so what has the new madwifi release done to
kill my wifi? I can only imagine it's done some kind of firmware upgrade that
affects the card itself?

I am not the only one experiencing this problem, there are already several
reports on the forums from yesterday of people with dead downgrading-doesnt-work
wifi: http://forums.gentoo.org/viewtopic-t-368886.html

The error I get starting wpa_supplicant is:

skb_over_panic: text:f9920cad len:53 put:53 head:f730c800 data:f730c800
tail:f730c800 end:f730c880 dev:<NULL>
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:93!
invalid operand: 0000 [#1]
PREEMPT
Modules linked in: rfcomm l2cap snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device snd_intel8x0 snd_ac97_codec loop kqemu fglrx rtc hci_usb
bluetooth ehci_hcd uhci_hcd usbcore dm_crypt dm_mod snd_pcm_oss snd_pcm
snd_timer snd_page_alloc snd_mixer_oss snd ath_pci ath_rate_sample wlan_xauth
wlan_wep wlan_tkip wlan_ccmp wlan_acl ath_rate_onoe wlan ath_hal
speedstep_centrino freq_table cpufreq_ondemand cpufreq_performance
cpufreq_conservative
CPU:    0
EIP:    0060:[<c029caff>]    Tainted: P      VLI
EFLAGS: 00210296   (2.6.12)
EIP is at skb_over_panic+0x5f/0x80
eax: 00000074   ebx: f730c800   ecx: f74a0060   edx: 00000000
esi: c030692c   edi: 00000035   ebp: f6c3dd58   esp: f6c3dce8
ds: 007b   es: 007b   ss: 0068
Process wpa_supplicant (pid: 6536, threadinfo=f6c3c000 task=f74a0060)
Stack: c03222a0 f9920cad 00000035 00000035 f730c800 f730c800 f730c800 f730c880
       c030692c c1d24340 00002068 f9920cb2 00000000 00000000 f7246620 f7246620
       f991ba16 f7246000 00000000 f993a6a6 f724c000 37218000 0000000f 00000002
Call Trace:
 [<f9920cad>] ieee80211_getmgtframe+0xad/0xc0 [wlan]
 [<f9920cb2>] ieee80211_getmgtframe+0xb2/0xc0 [wlan]
 [<f991ba16>] ieee80211_send_mgmt+0xa26/0xb50 [wlan]
 [<f993a6a6>] ath_startrecv+0xa6/0x110 [ath_pci]
 [<f991d581>] ieee80211_newstate+0x1c1/0x520 [wlan]
 [<f98f7a8b>] zz016e648a+0x1f/0x94 [ath_hal]
 [<f993abf2>] ath_newstate+0x1b2/0x400 [ath_pci]
 [<f98f7e57>] zz00b70923+0x43/0x60 [ath_hal]
 [<f991719e>] ieee80211_next_scan+0x10e/0x160 [wlan]
 [<f991707b>] ieee80211_begin_scan+0xab/0xc0 [wlan]
 [<f991d52f>] ieee80211_newstate+0x16f/0x520 [wlan]
 [<f98f7a8b>] zz016e648a+0x1f/0x94 [ath_hal]
 [<f993abf2>] ath_newstate+0x1b2/0x400 [ath_pci]
 [<f993456a>] ath_init+0x14a/0x210 [ath_pci]
 [<c02a2034>] dev_open+0x74/0x90
 [<c02a3438>] dev_change_flags+0x48/0x110
 [<c02d84c9>] devinet_ioctl+0x239/0x560
 [<c02da717>] inet_ioctl+0x67/0xb0
 [<c0299440>] sock_ioctl+0xd0/0x200
 [<c0299370>] sock_ioctl+0x0/0x200
 [<c0162e37>] do_ioctl+0x77/0x90
 [<c0162fde>] vfs_ioctl+0x5e/0x1d0
 [<c01465da>] do_munmap+0xfa/0x130
 [<c016318d>] sys_ioctl+0x3d/0x70
 [<c0102feb>] sysenter_past_esp+0x54/0x75
Code: 00 00 89 5c 24 14 8b 98 88 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 60 89 4c
24 04 c7 04 24 a0 22 32 c0 89 44 24 08 e8 21 b6 e7 ff <0f> 0b 5d 00 e6 05 32 c0
8b 5c 24 24 8b 74 24 28 83 c4 2c c3 8d

2.6.12 kernel. wpa_supplicant-0.4.3-r1.

------- Comment #1 From Stefan Schweizer 2005-08-11 05:04:51 0000 -------
This happens only with wpa-supplicant?

Can you please try to increase or decrease the version by renaming?

unmergeing files from /lib/modules does not work because it's in kind of a
confprotect, you need to remove them manually before upgrading/downgrading madwifi.

Oh, and you can go to the madwifi mailinglist and beg them to do a release,
because a cvs snapshot often works only partially :(

------- Comment #2 From Chris Bainbridge (RETIRED) 2005-08-11 05:34:29 0000 -------
I need wpa_supplicant to authenticate to the AP, so I can't test anything else.

unmerged, rm /lib/modules/2.6.12/net/* and emerged pre20050809. Crash.

unmerged, rm /lib/modules/2.6.12/net/* and emerged pre20050420. Crash.

Again with the February snapshot. Same crash.

The 20050809 release must've done something that is affecting operation of the
previous releases, because they were working. Either the releases rely on
something common that has been modified, like the kernel sources, or the
hardware has been broken.

Argh. 

------- Comment #3 From Henrik Brix Andersen 2005-08-11 05:37:52 0000 -------
Have you tried a cold restart?

------- Comment #4 From Stefan Schweizer 2005-08-11 05:39:31 0000 -------
Can you please report it to the madwifi mailing list?
Did you reset the card by replugging or rebooting after downgrading?

------- Comment #5 From Chris Bainbridge (RETIRED) 2005-08-11 07:11:51 0000 -------
I rebooted in between each test. I just tried a cold boot and got the same
crash. I'm going to check out a new cvs tree, and if that fails I'll try the
mailing list.

------- Comment #6 From Stefan Schweizer 2005-08-11 08:00:02 0000 -------
I just investigated a bit further and found out that the compiled modules
differ
between just "make; make install" and how the ebuild does it.
Also the ebuild installs ath_rate_amrr.ko and ath_rate_onoe.ko which is not
installed by a normal "make".
Can you please try a manual (i.e. without ebuild) make and try to remove these
two modules from an ebuild-make?

------- Comment #7 From Chris Bainbridge (RETIRED) 2005-08-11 09:00:05 0000 -------
I have it working again. This is what I did:

rm -rf /lib/modules/
rebuild and re-install kernel bzimage and modules_install
emerge madwifi-driver-0.1_20050420
remove all modules from /etc/modules.autoload.d/kernel-2.6 that the ebuild tells
you to add, replace with just 'ath_pci' (maybe not necessary, but cleaner)
modules-update
reboot
it should now work.

20050809 snapshot (built from ebuild) and todays cvs (built from source) give
the same errors:

/sbin/wpa_supplicant -dd  -Dmadwifi -c/etc/wpa_supplicant.conf -iath0
ioctl[SIOCSIWPMKSA]: Operation not supported
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long
ioctl[SIOCSIWENCODEEXT]: Operation not supported
ioctl[IEEE80211_IOCTL_SETMLME]: Argument list too long
.... repeats

I have a feeling something wasn't updated before and it was that ioctl with the
long argument list that was crashing the kernel.

If run from net.ath0 start it will timeout (probably what the forum poster was
seeing).

I'd recommend masking this snapshot as it seems broken.

------- Comment #8 From Tuan Van 2005-08-11 10:30:55 0000 -------
may be bump wpa_supplicant to the current madwifi version? I used the snapshot
dated 07-26-05 without any problem and I don't see much different with 08-09
snapshot. I'll try the new snapshot as soon as I get home and report back.

------- Comment #9 From Chris Bainbridge (RETIRED) 2005-08-11 11:16:14 0000 -------
Ah, I didn't realise wpa_supplicant builds with the cvs snapshot of madwifi! I
changed the snapshot version in the wpa_supplicant ebuild and suddenly it works
- I have the madwifi-20050809 with wpa_supplicant-0.4.3.. there are errors about
unsupported ioctls but it does work. Can someone fix the wpa_supplicant ebuild
then? Thanks.

------- Comment #10 From Henrik Brix Andersen 2005-08-11 14:30:38 0000 -------
I'll take care of wpa_supplicant.

------- Comment #11 From Calvin Walton 2005-08-11 18:20:24 0000 -------
Perhaps it would be best for wpa_supplicant to use headers from the installed
version of the madwifi drivers? A note could be added the the madwifi-drivers
package to remind people that they may need to recompile wpa_supplicant.

------- Comment #12 From Chris Bainbridge (RETIRED) 2005-08-12 03:04:28 0000 -------
Either that or the madwifi/wpa_supplicant versions should be forced to match by
adding madwifi as a DEPEND of wpa_supplicant.

------- Comment #13 From Roy Marples (RETIRED) 2005-08-12 14:45:56 0000 -------
Just a quick note to say that I cannot get this snap (20050809) to work with
wpa_supplicant for love nor money. It gets as far as GROUP_HANDSHAKE and then
bails. Running with -dd shows no debug information - just ioctl warnings.

Reverting to the prior snapshot worked.

Note to ebuild devs. For some reason I have to remove
/lib/modules/<KERNEL-VERSION> before emerging madwifi-driver and then
wpa_supplicant otherwise reverting fails. Well, the emerge works, but the end
product does not. Removing the installed modules and then emerging always works
- but not with this new snap.

------- Comment #14 From Raphael Marichez 2005-08-12 15:31:06 0000 -------
(In reply to comment #13)
> Just a quick note to say that I cannot get this snap (20050809) to work with
> wpa_supplicant for love nor money. It gets as far as GROUP_HANDSHAKE and then
> bails. Running with -dd shows no debug information - just ioctl warnings.
> 
> Reverting to the prior snapshot worked.
> 

Well, same thing.
I use a dlink DWL-G650 with WPA-PSK TKIP (so with wlan_tkip.ko)

in the beginning, i couldn't have my card working at all, even i came back to
madwifi-driver-20050420. (like Chris)
In fact, i don't know why, as for today, modprobe doesn't load the good modules
(it loads ath_rate_sample whereas i need ath_rate_onoe), then modprobe segfaults
and causes a kernel Oops.
Indeed : if i load the modules manually with insmod, and if i load
ath_rate_sample in place of ath_rate_onoe, i have a segfault and kernel Oops
when insmoding ath_pci too. This happens with both madwifi-driver-20050420
madwifi-driver-20050809.

Then i came back to madwifi-driver-20050420 and i load ath_rate_onoe manually :
this is the only way my card work.
insmod wlan.ko
insmod wlan_tkip.ko
insmod ath_hal.ko
insmod ath_rate_onoe.ko
insmod ath_pci.ko

madwifi-driver-20050809 does NOT work for me, wpa_supplicant timeouts. In some
certain configuration (e.g. without re-emerging wpa_supplicant), i have this
message :
Aug 12 23:24:44 ganesh kernel: [17179753.284000] pci: Bound Device 0000:02:00.0
to Driver ath_pci
Aug 12 23:24:46 ganesh kernel: [17179755.576000] no rates yet! mode 0
Aug 12 23:24:46 ganesh kernel: [17179755.764000] no rates yet! mode 0
Aug 12 23:24:46 ganesh kernel: [17179755.844000] no rates yet! mode 0
Aug 12 23:24:46 ganesh kernel: [17179755.848000] no rates yet! mode 0
(...)
maybe it could help :/

in this case, "rmmod ath_pci" always leads to a segfault and a kernel Oops.

Note that, again, you *must* re-emerging wpa_supplicant after each change of
madwifi-driver (except if you use quickpkg) : without this, i can't connect to
my access point, and rmmod may lead to a segfault and a kernel Oops.

i used :
madwifi-driver-0.1_pre20050420 + wpa_supplicant-0.4.3 (old ebuild)
madwifi-driver-0.1_pre20050420 + wpa_supplicant-0.4.3-r1
and
madwifi-driver-0.1_pre20050809 + wpa_supplicant-0.4.3-r1


finally, i've had to put this line in my /etc/portage/package.mask :
>net-wireless/madwifi-driver-0.1_pre20050420

I would like to lower the severity of this bug from "critical" to "major"
because it does NOT kill any wifi-card, and "critical" is rather.... for very
important issues

good luck ! :)

------- Comment #15 From Chris Bainbridge (RETIRED) 2005-08-13 03:31:34 0000 -------
Downgrading to major .. when I put critical I had no working wifi and no
downgrading, I was imagining a LG cdrom scenario.. ;-)

I too have had to downgrade to 20050420. The new 20050809 release with fixed
wpa_supplicant build works fine with some access points, but not with others.
There's no debugging or errors output.. wpa_supplicant appears to connect to the
AP ok, but dhcpcd can't get an IP address. But it only happens with some APs. Weird.

------- Comment #16 From Chris Bainbridge (RETIRED) 2005-08-13 04:16:49 0000 -------
The downgraded version doesnt work because the new ebuild leaves
/lib/modules/2.6.12/net/ath_rate_sample.ko around. So:

rm /lib/modules/2.6.12/net/ath_rate_sample.ko
modules-update

Should be sufficient to get the downgraded version working again.

------- Comment #17 From Ryan Hill 2005-08-13 16:38:26 0000 -------
i was very suprised to see the update of this package in portage.  i've been
following the madwifi devel list and can tell you that the current cvs is
nowhere close to stable.

i have the same problem as comment #13 and #14.

0000:02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg
NIC (rev 01)

no debug info. =/

------- Comment #18 From Stefan Schweizer 2005-08-13 22:38:19 0000 -------
Well, I can kinda workround this problem by putting the new version in
package.mask globally. Do you have any better idea?

As it stands the madwifi snapshot is unstable and afaik they are not planning to
go for stability :(

------- Comment #19 From Henrik Brix Andersen 2005-08-14 03:50:35 0000 -------
So perhaps we should add net-wireless/madwifi-driver-0.1_pre20050809 to the
global package mask?

genstef, what do you think?

------- Comment #20 From Stefan Schweizer 2005-08-14 09:36:01 0000 -------
Added to package.mask.

You can version-bump the ebuild yourself if you like and please send any of your
bugreports to the madwifi mailing list.

I will resolve this as UPSTREAM, because we wait for upstream to produce a more
stable driver.

Thanks to all who have commented here.

------- Comment #21 From Henrik Brix Andersen 2005-08-17 09:06:33 0000 -------
*** Bug 102842 has been marked as a duplicate of this bug. ***

------- Comment #22 From Michael Thalmeier 2005-10-05 11:54:39 0000 -------
Loading the kernel modules md5 and aes_i586 before loading ath_pci solved the
issue for me.

------- Comment #23 From Ryan Hill 2005-10-29 12:03:12 0000 -------
wpa_supplicant-0.4.6 fixes this bug for me.

------- Comment #24 From Henrik Brix Andersen 2005-10-29 12:08:43 0000 -------
(In reply to comment #23)
> wpa_supplicant-0.4.6 fixes this bug for me.

So you're saying that net-wireless/madwifi-driver-0.1_pre20050809-r1 and
net-wireless/wpa_supplicant-0.4.6 works for you regardless of the load order
mentioned i comment #22?

If so, we should unmask net-wireless/madwifi-driver-0.1_pre20050809-r1 and add a
note to the ebuild that it requires >=net-wireless/wpa_supplicant-0.4.6 for WPA
support.

------- Comment #25 From Ryan Hill 2005-10-29 12:25:45 0000 -------
correct.  i load the ath_hal, wlan, and ath_pci modules in that order.  i have
md5 built into the kernel but not CONFIG_CRYPTO_AES_586.  my AP is set up using
WPA-PSK if that helps.

------- Comment #26 From Jose Maria Alvarez 2005-10-29 17:27:31 0000 -------
I would also want to add that this madwifi snapshot makes samba not to work
correctly with windows XP machines (connections reseted). I've compiled a new
CVS snapshot on my own and now i don't have this behaviour. I'm using 2.6.14 and
wpa_supplicant-0.4.6.

------- Comment #27 From Roy Marples (RETIRED) 2005-10-30 22:39:14 0000 -------
> So you're saying that net-wireless/madwifi-driver-0.1_pre20050809-r1 and
> net-wireless/wpa_supplicant-0.4.6 works for you regardless of the load order
> mentioned i comment #22?
> 
> If so, we should unmask net-wireless/madwifi-driver-0.1_pre20050809-r1 and add a
> note to the ebuild that it requires >=net-wireless/wpa_supplicant-0.4.6 for WPA
> support.

Please don't - I still can't get this madwifi snap to work using WPA/PSK at all.
I've tried the removing the above mention kernel enc modules, compiled into
kernel, not used at all, altered the madwifi module insert order, etc.

------- Comment #28 From Ryan Hill 2005-11-06 17:57:33 0000 -------
looks like i spoke too soon.  i have no troubles connecting to my AP the first
time, but after that if take the connection down i can't bring it back up unless
i do a full reboot.  it associates and handshakes with the router but then just
times out. moving back to the previous madwifi-driver and wpa_supplicant fixes
it. =/

------- Comment #29 From Steffen Schwientek 2005-11-20 09:48:18 0000 -------
Madwifi changed the API in there newest SVN. I had a lot of work to get my 
madwifi-card running again. All avaible ebuilds doesn't work with the newer 
kernels. 
Here What I have done: 
Download latest svn from madwifi 
Download latest cvs from hostap/wpa_supplicant 
 
1) Compiled and intalled madwifi (Madwifi sources required later, so don't 
delete them) 
2) COmpiled and install wpa_supplicant (enable madwifi sources in defconfig at 
the wpa_supplicant source) 
3) create an ath interface with: wlanconfig ath create wlandev wifi0 wlanmode 
sta   
4)running wpa_supplicant on the new interface  
5) ifconfig ath0 up (I done an simple) dhcpcd ath0 
 
No all I need is to automate these steps and an ebuild... 

------- Comment #30 From Stefan Schweizer 2005-11-20 09:55:54 0000 -------
Steffen: there is an ebuild for the madwifi-part .. it is package.masked
currently due to configuration changes.

For WPA there is an ebuild proposed in http://bugs.gentoo.org/show_bug.cgi?id=112420
but it has not made it into gentoo cvs yet

------- Comment #31 From Henrik Brix Andersen 2006-01-17 07:20:08 0000 -------
Fixed in net-wireless/madwifi-driver-0.1401.20060117.

First Last Prev Next    No search results available      Search page      Enter new bug