Bug 10325 - ath5k failed to resume/initialize
ath5k failed to resume/initialize
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Product: Drivers
Classification: Unclassified
Component: network-wireless
All Linux
: P1 high
Assigned To: drivers_network-wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2008-03-25 13:15 UTC by Artem Goncharov
Modified: 2012-03-29 17:09 UTC (History)
9 users (show)

See Also:
Kernel Version: 2.6.25-rc6
Tree: Mainline
Regression: No


Attachments

Description Artem Goncharov 2008-03-25 13:15:53 UTC
Latest working kernel version:
   none
Earliest failing kernel version:
Distribution:
Hardware Environment:
   AR5006EG 802.11 b/g Wireless PCI Express Adapter
Software Environment:
Problem Description:
   such messages in dmesg from the very beginning:

ath5k_pci 0000:02:00.0: registered as 'phy0'
ath5k phy0: failed to resume the MAC Chip
ath5k_pci: probe of 0000:02:00.0 failed with error -5


How can I help in investigating problem?
Comment 1 Artem Goncharov 2008-03-25 13:18:56 UTC
After rmmod/modprobe for ath5k it's falling out with "failed to wakeup the MAC chip"
Comment 2 John W. Linville 2008-08-14 11:03:59 UTC
ath5k has come a long way.  Is this still a problem for you?
Comment 3 John W. Linville 2008-09-30 07:03:38 UTC
Closing based on lack of response...
Comment 4 Rich Ercolani 2008-12-10 09:20:11 UTC
Still a problem for me, at least. 2.6.27 with wireless-testing from December.
Comment 5 Ian Page Hands 2009-01-18 08:42:07 UTC
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?
Comment 6 HMT 2009-02-12 06:30:13 UTC
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 ]---
Comment 7 vinvin 2009-03-17 07:21:23 UTC
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.
Comment 8 Bob Copeland 2009-03-17 19:20:12 UTC
(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). 
Comment 9 Bob Copeland 2009-03-17 19:31:52 UTC
(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.
Comment 10 vinvin 2009-03-18 02:25:26 UTC
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.
Comment 11 vinvin 2009-04-11 11:18:12 UTC
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!
Comment 12 Thomas Mudrunka 2011-05-02 23:13:57 UTC
btw try adding nohz=off to kernel options in GRUB/LILO if problem will appear again...
Comment 13 Kristoffer Grundström 2012-03-14 02:50:57 UTC
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

Note You need to log in before you can comment on or make changes to this bug.