On 31 March 2014 18:56, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > This came from a customer (demo) system. Firmware is 10.1.389 based, modified > by us. It has lots of known issues, but I haven't seen the warning > below before, and not sure it is specifically a bug with ath10k or not. Hmm.. > Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108) > Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108) > Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108) > Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108) > Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108) > Mar 31 13:49:54 ct521-5332 kernel: ath10k: could not start hw scan (-108) -108 = ESHUTDOWN. This can be a result of calling ath10k_halt() IOW driver is stopping by mac80211 request or ath10k_core_restart() was called. I suppose the latter is the case here. ath10k_halt() calls ieee80211_scan_completed(hw, true) if necessary. But since it only sets 1 or 2 bits in local->scanning in mac80211 and schedules local->scan_work I suspect you can end up having local->restart_work scheduled sooner in some cases (both use different workqueues: scan_work uses per-hw queue, restart_work uses global system queue) and see the following: > Mar 31 13:49:54 ct521-5332 kernel: ieee80211_restart_work called with hardware scan in progress > Mar 31 13:49:54 ct521-5332 kernel: Modules linked in: nf_nat_ipv4 nf_nat fuse 8021q mrp garp stp llc macvlan pktgen coretemp hwmon sunrpc ipv6 uinput > snd_hda_codec_realtek snd_hda_codec_generic ath10k_pci ath10k_core snd_hda_intel mac80211 snd_hda_codec snd_hwdep snd_seq snd_seq_device iTCO_wdt e1000e > microcode ath gpio_ich snd_pcm iTCO_vendor_support ppdev ptp snd_timer parport_pc snd cfg80211 parport serio_raw pps_core soundcore pcspkr i2c_i801 lpc_ich i915 > drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: iptable_nat] > Mar 31 13:49:54 ct521-5332 kernel: CPU: 0 PID: 11818 Comm: kworker/0:0 Tainted: G WC 3.14.0-rc7-wl-ath+ #4 > Mar 31 13:49:54 ct521-5332 kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M., BIOS 4.6.3 09/05/2011 > Mar 31 13:49:54 ct521-5332 kernel: Workqueue: events ieee80211_restart_work [mac80211] > Mar 31 13:49:54 ct521-5332 kernel: 0000000000000009 ffff8800bd865d68 ffffffff815ab0a5 ffff88022bc0ec38 > Mar 31 13:49:54 ct521-5332 kernel: ffff8800bd865db8 ffff8800bd865da8 ffffffff810c1aa8 ffff8800bd865d88 > Mar 31 13:49:54 ct521-5332 kernel: ffffffffa03858ce ffff8802214d5650 ffff8802214d45e0 ffff8802214d5650 > Mar 31 13:49:54 ct521-5332 kernel: Call Trace: > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff815ab0a5>] dump_stack+0x4e/0x71 > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810c1aa8>] warn_slowpath_common+0x77/0x91 > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffffa03858ce>] ? ieee80211_restart_work+0x49/0x68 [mac80211] > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810c1b56>] warn_slowpath_fmt+0x41/0x43 > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffffa03858ce>] ieee80211_restart_work+0x49/0x68 [mac80211] > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d52af>] process_one_work+0x162/0x216 > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d5724>] worker_thread+0x12f/0x1fd > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d55f5>] ? rescuer_thread+0x268/0x268 > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810d55f5>] ? rescuer_thread+0x268/0x268 > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810da37f>] kthread+0xa0/0xa8 > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810da2df>] ? __kthread_parkme+0x5c/0x5c > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff815b5b4c>] ret_from_fork+0x7c/0xb0 > Mar 31 13:49:54 ct521-5332 kernel: [<ffffffff810da2df>] ? __kthread_parkme+0x5c/0x5c > Mar 31 13:49:54 ct521-5332 kernel: ---[ end trace fd8ccdaa79168e68 ]--- It seems to me that any mac80211-driver can hit this as long as it requests a restart during a scan while something queued via ieee80211_queue_work() blocks (that something could be driver worker) long enough. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
