After rmmod/modprobe for ath5k it's falling out with "failed to wakeup the MAC chip"

ath5k has come a long way.  Is this still a problem for you?

Closing based on lack of response...

Still a problem for me, at least. 2.6.27 with wireless-testing from December.

This is still a problem with 2.6.28. I remove the wifi driver when not in use (e.g. traveling, or using ethernet), and when I attempt to re-insert ath5k I get:

ath5k_pci 0000:03:00.0: PCI INT A disabled
ath5k_pci 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ath5k_pci 0000:03:00.0: registered as 'phy2'
ath5k phy2: failed to wakeup the MAC Chip
ath5k_pci 0000:03:00.0: PCI INT A disabled
ath5k_pci: probe of 0000:03:00.0 failed with error -5

ifconfig wlan1 up gives:
ath5k phy1: failed to wakeup the MAC Chip
ath5k phy1: can't reset hardware (-5)

Please let me know if there is some way I can give more useful data. I am brand new to kernel debugging/bug_reporting but I would be more than happy to help.

Thanks,
-Ian Page Hands

p.s. Oh this bug may be easier to recreate if one were to:
1. remove ath5k
2. suspend to ram
3. resume
4. re-add ath5k

p.p.s The open (or reopen) option went away when I logged in, should I create a new bug?

I get a similar problem (in 2.6.27-9). After resume, ksoftirqd/1 99% of cpu. In dmesg:

[ 8680.578320] ------------[ cut here ]------------
[ 8680.578331] WARNING: at /build/buildd/linux-backports-modules-2.6.27-2.6.27/debian/build/build-generic/compat-wireless-2.6/net/mac80211/rx.c:2200 __lbm_cw_ieee80211_rx+0x19f/0x600 [lbm_cw_mac80211]()
[ 8680.578334] Modules linked in: ipv6 af_packet binfmt_misc ppdev vmnet vmblock vmci vmmon acpi_cpufreq cpufreq_ondemand cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative freq_table pci_slot sbs sbshc container wmi iptable_filter ip_tables x_tables arc4 ecb crypto_blkcipher ath5k lbm_cw_mac80211 lbm_cw_cfg80211 parport_pc lp parport joydev snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy evdev uvcvideo pcspkr psmouse serio_raw compat_ioctl32 videodev v4l1_compat snd_seq_oss snd_seq_midi video fglrx(P) output snd_rawmidi snd_seq_midi_event snd_seq battery ac snd_timer snd_seq_device snd asus_laptop led_class soundcore button snd_page_alloc sis190 mii shpchp pci_hotplug sis_agp agpgart ext3 jbd mbcache sd_mod crc_t10dif usbhid hid usb_storage sr_mod cdrom sg sata_sis ata_generic libusual pata_acpi pata_sis ohci_hcd ehci_hcd libata usbcore scsi_mod dock thermal processor fan fbcon tileblit font bitblit softcursor fuse
[ 8680.578425] Pid: 4, comm: ksoftirqd/0 Tainted: P 2.6.27-9-generic #1
[ 8680.578429] [<c037c4b6>] ? printk+0x1d/0x1f
[ 8680.578438] [<c0131de9>] warn_on_slowpath+0x59/0x90
[ 8680.578447] [<c013c7a4>] ? del_timer+0x54/0x60
[ 8680.578453] [<c0137418>] ? raise_softirq_irqoff+0x8/0x70
[ 8680.578458] [<f88be781>] ? __scsi_done+0x41/0x50 [scsi_mod]
[ 8680.578478] [<f88be7ab>] ? scsi_done+0x1b/0x30 [scsi_mod]
[ 8680.578490] [<f8893417>] ? ata_scsi_translate+0xf7/0x150 [libata]
[ 8680.578507] [<c024ae8e>] ? cfq_dispatch_requests+0xe/0x260
[ 8680.578515] [<f88be790>] ? scsi_done+0x0/0x30 [scsi_mod]
[ 8680.578526] [<c037e6dd>] ? _spin_lock+0xd/0x10
[ 8680.578531] [<c024e580>] ? kobject_put+0x20/0x50
[ 8680.578536] [<f88bea06>] ? scsi_dispatch_cmd+0xf6/0x280 [scsi_mod]
[ 8680.578548] [<f8c549af>] __lbm_cw_ieee80211_rx+0x19f/0x600 [lbm_cw_mac80211]
[ 8680.578560] [<f88c5ed7>] ? scsi_request_fn+0xa7/0x440 [scsi_mod]
[ 8680.578574] [<c02eae1c>] ? skb_put+0xc/0xa0
[ 8680.578580] [<f8c2ac83>] ath5k_tasklet_rx+0x2e3/0x550 [ath5k]
[ 8680.578588] [<c0137258>] tasklet_action+0x78/0x100
[ 8680.578592] [<c0137682>] __do_softirq+0x92/0x120
[ 8680.578595] [<c013776d>] do_softirq+0x5d/0x60
[ 8680.578598] [<c0137802>] ksoftirqd+0x92/0x120
[ 8680.578601] [<c0137770>] ? ksoftirqd+0x0/0x120
[ 8680.578605] [<c0147141>] kthread+0x41/0x80
[ 8680.578609] [<c0147100>] ? kthread+0x0/0x80
[ 8680.578613] [<c0105297>] kernel_thread_helper+0x7/0x10
[ 8680.578618] =======================
[ 8680.578620] ---[ end trace 79ed1c5ac603e4a1 ]---

This is still not working with 2.6.28.7.

A simple way to reproduce is:

echo 0 > /sys/class/rfkill/rfkill0/state
echo 1 > /sys/class/rfkill/rfkill0/state

When device reappears, the driver is not able to init it, with the same error than the first report of this bug. If the driver is unloaded before, between, or after these to commands, and reloaded at any time, this doesn't change anything, still the same error.

(In reply to comment #6)
> I get a similar problem (in 2.6.27-9). After resume, ksoftirqd/1 99% of cpu.
> In
> dmesg:
> 
> [ 8680.578320] ------------[ cut here ]------------
> [ 8680.578331] WARNING: at
>
> /build/buildd/linux-backports-modules-2.6.27-2.6.27/debian/build/build-generic/compat-wireless-2.6/net/mac80211/rx.c:2200
> __lbm_cw_ieee80211_rx+0x19f/0x600 [lbm_cw_mac80211]()

This is some other problem, and not an issue with kernel.org kernels (lbm_XXX is a giveaway that you're loading backport modules from your distro - so you need to file a bug with them.  Sometimes you can have a mismatch and load the distro module with kernel.org kernel which will cause lots of similar crashes). 

(In reply to comment #7)
> This is still not working with 2.6.28.7.
> 
> A simple way to reproduce is:
> 
> echo 0 > /sys/class/rfkill/rfkill0/state
> echo 1 > /sys/class/rfkill/rfkill0/state
> 
> When device reappears, the driver is not able to init it, with the same error
> than the first report of this bug. If the driver is unloaded before, between,
> or after these to commands, and reloaded at any time, this doesn't change
> anything, still the same error.

What kind of hardware is this?  eeepc?  (what version #?) The problem seems to be that some laptops do rfkill by pci hotplug, so as far as ath5k knows, the hardware is completely gone when it reprobes.

Yes it is eeepc 900, sorry.
The first time, the driver says:

ath5k_pci 0000:01:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ath5k_pci 0000:01:00.0: setting latency timer to 64
ath5k_pci 0000:01:00.0: registered as 'phy0'
ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)

I don't have any idea about how the rfkill is made on this laptop.

It seems this has been fixed in 2.6.29.1. I am able to do rfkill and wake it up and scan and connect again.
Thank you all!

btw try adding nohz=off to kernel options in GRUB/LILO if problem will appear again...

I get this problem as well in Mageia 1 and in Mageia 2 (The unstable development version).

https://bugs.mageia.org/show_bug.cgi?id=2366