Panic when changing ath10k channel

[Michal Kazior]

On 12 May 2014 22:00, Ben Greear <greearb at candelatech.com> wrote:
> We saw this on a Fedora 14 system (with 3.14.3+ kernel, and our firmware).
>
> Our kernel is a mix of local patches and kvalo's ath.git and 3.14.3.
>
> Don't think I've seen this one before, not sure if it is reproducible,
> but in general this system has been more touchy than most for some
> reason...

Could it be it supports multiple MSI interrupt allocation while your
other systems don't?


> -------- Original Message --------
> Subject: F14 panic when changing ath10k channel
> Date: Mon, 12 May 2014 12:21:48 -0700
> From: Isaac Konikoff <konikofi at candelatech.com>
> To: 'Ben Greear' <greearb at candelatech.com>
>
> ------------[ cut here ]------------
> WARNING: CPU: 2 PID: 3277 at
> /home/greearb/git/linux-3.14.dev.y/kernel/irq/manage.c:1249
> __free_irq+0x96/0x199()

Were there any other messages preceeding this I wonder?


> Trying to free already-free IRQ 18
> Modules linked in: iptable_raw xt_CT nf_nat_ipv4 nf_nat fuse 8021q mrp
> garp stp llc macvlan wanlink(O) pktgen coretemp hwmon nfsv3 nfs_acl nfs
> fscache lockd sunrpc ipv6 uinput snd_hda_codec_realtek
> snd_hda_codec_generic ath10k_pci snd_hda_intel ath9k ath10k_core
> snd_hda_codec mac80211 snd_hwdep ath9k_common snd_seq ath9k_hw
> snd_seq_device e1000e snd_pcm ath iTCO_wdt gpio_ich ppdev
> iTCO_vendor_support microcode parport_pc cfg80211 snd_timer i2c_i801
> pcspkr serio_raw parport snd ptp lpc_ich soundcore pps_core i915
> drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: iptable_nat]
> CPU: 2 PID: 3277 Comm: ip Tainted: G         C O 3.14.3+ #24
> 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
>  00000000000004e1 ffff8802191b9368 ffffffff815bd318 00000000000004e1
>  ffff8802191b93b8 ffff8802191b93a8 ffffffff810addce 00000000810ef18f
>  ffffffff810f1e3c 0000000000000000 ffff880221f7d600 0000000000000012
> Call Trace:
>  [<ffffffff815bd318>] dump_stack+0x51/0x79
>  [<ffffffff810addce>] warn_slowpath_common+0x77/0x91
>  [<ffffffff810f1e3c>] ? __free_irq+0x96/0x199
>  [<ffffffff810ade7c>] warn_slowpath_fmt+0x41/0x43
>  [<ffffffff810f1e3c>] __free_irq+0x96/0x199
>  [<ffffffff810f1fb1>] free_irq+0x72/0x8b

I've found only one case the double free_irq() can happen in vanilla
ath10k. hif_stop() is called two times if init_connect_htc() hits
timeout failpath.

This seems to be only reproducible on systems capable of allocating
multiple MSI interrupts for ath10k.

A quick fix would be to reset ar_pci->num_msi_intrs to 0 in
ath10k_pci_free_irq(). This will stop the double free_irq() from
happening albeit the early pci handler will be remapped (harmless and
it already happens on with single MSI interrupt and legacy interrupt).

I'll try to patch it later properly.


>  [<ffffffffa05565eb>] ath10k_pci_hif_stop+0x78/0x16b [ath10k_pci]
>  [<ffffffffa04f7b08>] ath10k_htc_stop+0x35/0x3a [ath10k_core]
>  [<ffffffffa04f6101>] ath10k_core_stop+0x2a/0x42 [ath10k_core]
>  [<ffffffffa04f1cbd>] ath10k_halt+0xc2/0x11a [ath10k_core]
>  [<ffffffffa04f1d4c>] ath10k_stop+0x37/0x88 [ath10k_core]
>  [<ffffffffa0403f0d>] ieee80211_stop_device+0x47/0x74 [mac80211]
>  [<ffffffffa03f08a4>] ieee80211_do_stop+0x61e/0x658 [mac80211]

I have to assume this is a result of some of your local patches since
I was unable to find how this could come about during driver teardown.


Michał