site  contact  subhomenews

Madwifi and 4.1retro

September 02, 2008 — BarryK
I got a very odd bug with Madwifi. I don't know if this only applies to 4.1retro and the kernel.

I earlier reported that my PCMCIA-USB adapter card works fine in 4.1retro. That was the first build, and I only had the modules that came with the kernel, no 3rd-party modules.

Yesterday I compiled all the 3rd-party modules, Madwifi included, and built 4.1retro again. Booted it, this time my PCMCIA-USB card did not work. Nor did my SD card. I tested with 'hotplug2stdout' and found that these interfaces were dead, no kernel uvents generated.

I traced it down to the Madwifi 'ath_pci.ko' module. If I blacklist it, then load it manually later, then my PCMCIA card and SD card work. Weird, as far as I can make out, ath_pci is grabbing control of PCI hardware interfaces and preventing the other interfaces from working.

I tested this hypothesis by putting a hack into /sbin/pup_event_backend_modprobe. This is the script that 'udevd' calls everytime it wants to load a module. The hack is that if the module is 'ath_pci' then 'sleep 5'.
This does not slow down bootup because of the way udevd works. The udevd daemon spawns multiple modprobe executions, attempting to boot as fast as possible, so the "modprobe ath_pci" is just one parallel process.

Anyway, the hack worked, so I have put it in as a permanent feature. It seems likely that this bug applies to later kernels also.



ath5k unreliable
Username: tempestuous
"From all the posts I have noted on the forum it appears that the ath_pci driver is a clear winner over the new ath5k driver. Of course, we're talking about the 2.6.25.x kernel. I see on the web that the ath5k module is finally reported as working and reliable in kernel 2.6.27. downsouth, you should know from all the Eee posts on the forum that the Eee requires a non-standard variant of the ath_pci (MADWiFi) driver. This special variant is available for Puppy 2.12-2.16 here: and for Puppy 3.x/4.0 here:

Tags: puppy