madwifi does not unload after resume

madwifi hasn't been updated in weeks. This works fine with my Atheros card -- I
unload and reload ath_pci around suspend/resume. Does running sudo ifconfig
ath0 down, before you try to remove it, help?

Which verison of linux-restricted are you using?

chuck

I'm very sorry, I think I misdiagnosed my problem.
I'm still using 2.6.10-2, (linux-image and -restricted modules) and suffering
from swsusp not reenabling my IRQ routing correctly.
I'm upgrading to latest 2.6.10-4 image with corresponding -restricted and will
reinvestagate this problem again.

I installed latest 2.6.10-4.
Steps to reproduce the problem:
Booting and loggin in, networking with madwifi doing fine
suspending via swsusp
resuming from suspend
trying to do any networking results in these messages in /var/log/kern.log:
Feb 28 09:15:50 localhost kernel: unregister_netdevice: waiting for ath0 to
become free. Usage count = 1

Perhaps of interest could be my kernel command line: root=/dev/hda2 ro nolapic
acpi=noirq usepirqmask routeirq resume=/dev/hda3 vga=0x317 quiet splash

I'm on a Thinkpad R40 B3G 2772, I figured these option out for getting swsup
working at all.
Please tell me what more information I could provide to diagnose the problem.

Ok, I think I may have seen this before. Can you edit /etc/acpi/prepare.sh and
change

# And shut them down
for x in $INTERFACES; do
    ifdown $x;
    ifconfig $x down;
done

to

# And shut them down
for x in $INTERFACES; do
    ifdown $x;
done

killall dhclient

for x in $INTERFACES; do
    ifconfig $x down;
done

then reboot and try suspend/resume?

I tried that, but symptoms didn't change.
I tried several boot options, but madwifi is unusable after suspend anymore :(
This worked before for me, so I will do more investigation what could have changed.

Now I'm also considering hardware damage as possible cause :(

I did some more research: Unloading of ath-pci seems to success only once, after
reloading it another time, a `modprobe -r ath-pci` fails with the process
getting stuck in state 'D', leaving the rest of the system nearly unusable,
because the process 'x-session-manager' gets also in state 'D' afterwards.

Dmesg is emitting these lines:
kernel: unregister_netdevice: waiting for ethw to become free. Usage count = 7

If you ifconfig down the interface before unloading it and make sure that there
are no dhclient processes running, does it work?

In my tests I always made sure that neither dhclient nor wpa_supplicant is
running (by killing them) and downed the interface with ifconfig ath0 down manually.
Somethings very weird is going on here...

Ok, it sounds very much like a madwifi bug. Could you possibly bring this up on
their dev lists? (I can't find a handy bugtracker for them)

I reinstalled completly from hoary current install cd, and restored my local
configuration step by step.
Now I'm using a different Kernel command line: root=/dev/hda2 ro noapic nolapic
acpi=noirq vga=0x317 pci=routeirq quiet splash

I cannot tell for sure what the culprit was, but I think this is was a local
configuration problem, so I'm closing this bug.