Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 102104 - madwifi-driver-0.1_pre20050809.ebuild kills wifi cards
Summary: madwifi-driver-0.1_pre20050809.ebuild kills wifi cards
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Mobile Herd (OBSOLETE)
URL:
Whiteboard:
Keywords: InVCS
: 102842 (view as bug list)
Depends on:
Blocks: 110791
  Show dependency tree
 
Reported: 2005-08-11 04:32 UTC by Chris Bainbridge (RETIRED)
Modified: 2006-01-17 07:20 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Bainbridge (RETIRED) gentoo-dev 2005-08-11 04:32:01 UTC
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 Stefan Schweizer (RETIRED) gentoo-dev 2005-08-11 05:04:51 UTC
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 Chris Bainbridge (RETIRED) gentoo-dev 2005-08-11 05:34:29 UTC
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 Henrik Brix Andersen 2005-08-11 05:37:52 UTC
Have you tried a cold restart?
Comment 4 Stefan Schweizer (RETIRED) gentoo-dev 2005-08-11 05:39:31 UTC
Can you please report it to the madwifi mailing list?
Did you reset the card by replugging or rebooting after downgrading?
Comment 5 Chris Bainbridge (RETIRED) gentoo-dev 2005-08-11 07:11:51 UTC
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 Stefan Schweizer (RETIRED) gentoo-dev 2005-08-11 08:00:02 UTC
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 Chris Bainbridge (RETIRED) gentoo-dev 2005-08-11 09:00:05 UTC
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 Tuan Van (RETIRED) gentoo-dev 2005-08-11 10:30:55 UTC
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 Chris Bainbridge (RETIRED) gentoo-dev 2005-08-11 11:16:14 UTC
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 Henrik Brix Andersen 2005-08-11 14:30:38 UTC
I'll take care of wpa_supplicant.
Comment 11 Calvin Walton 2005-08-11 18:20:24 UTC
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 Chris Bainbridge (RETIRED) gentoo-dev 2005-08-12 03:04:28 UTC
Either that or the madwifi/wpa_supplicant versions should be forced to match by
adding madwifi as a DEPEND of wpa_supplicant.
Comment 13 Roy Marples (RETIRED) gentoo-dev 2005-08-12 14:45:56 UTC
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 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2005-08-12 15:31:06 UTC
(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 Chris Bainbridge (RETIRED) gentoo-dev 2005-08-13 03:31:34 UTC
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 Chris Bainbridge (RETIRED) gentoo-dev 2005-08-13 04:16:49 UTC
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 Ryan Hill (RETIRED) gentoo-dev 2005-08-13 16:38:26 UTC
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 Stefan Schweizer (RETIRED) gentoo-dev 2005-08-13 22:38:19 UTC
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 Henrik Brix Andersen 2005-08-14 03:50:35 UTC
So perhaps we should add net-wireless/madwifi-driver-0.1_pre20050809 to the
global package mask?

genstef, what do you think?
Comment 20 Stefan Schweizer (RETIRED) gentoo-dev 2005-08-14 09:36:01 UTC
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 Henrik Brix Andersen 2005-08-17 09:06:33 UTC
*** Bug 102842 has been marked as a duplicate of this bug. ***
Comment 22 Michael Thalmeier 2005-10-05 11:54:39 UTC
Loading the kernel modules md5 and aes_i586 before loading ath_pci solved the
issue for me.
Comment 23 Ryan Hill (RETIRED) gentoo-dev 2005-10-29 12:03:12 UTC
wpa_supplicant-0.4.6 fixes this bug for me.
Comment 24 Henrik Brix Andersen 2005-10-29 12:08:43 UTC
(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 Ryan Hill (RETIRED) gentoo-dev 2005-10-29 12:25:45 UTC
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 Jose Maria Alvarez 2005-10-29 17:27:31 UTC
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 Roy Marples (RETIRED) gentoo-dev 2005-10-30 22:39:14 UTC
> 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 Ryan Hill (RETIRED) gentoo-dev 2005-11-06 17:57:33 UTC
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 Steffen Schwientek 2005-11-20 09:48:18 UTC
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 Stefan Schweizer (RETIRED) gentoo-dev 2005-11-20 09:55:54 UTC
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 Henrik Brix Andersen 2006-01-17 07:20:08 UTC
Fixed in net-wireless/madwifi-driver-0.1401.20060117.