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.
Just a reminder though, our 2.6.25 and later kernels have 'ath5k' which replaces Madwifi, but 4.1 has Madwifi as a throwback in case ath5k does not work (you will need to make some changes in the BootManager to disable ath5k and enable Madwifi).
Comments:Posted on 2 Sep 2008, 15:59 by downsouth
Seems to be an ongoing issue - in pup 2.171 (my eee version), I also had to blacklist ath_pci, and use ndiswrapper (188.8.131.52 kernel) for wireless.
Posted on 2 Sep 2008, 16:16 by BarryK
ath_pci does not work on my laptop. I think there are reports on the forum that there are some people for whom it does work ...I wonder though, maybe we should do a poll. If it it turns out that it works for say one person and doesn't work for 10, then I would vote for having it blacklisted by default.
Posted on 2 Sep 2008, 20:00 by 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:
Posted on 3 Sep 2008, 7:44 by downsouth
Thanks for that tempestuous. I blacklisted ath_pci when I had issues. Did the same before with bcm43xx on my Compaq 502 laptop, and ndiswrapper worked. Once things work, I don't usually look further, as my senior mind 'buffer overflows' fairly easily. Just felt I should note the ath_pci issue as not being new, nor kernel specific (& I like Pup 2.17.1)