After shutdown/restart, ath10k sometimes stops receiving packets

[Michal Kazior]

On 13 June 2014 01:37, Avery Pennarun <apenwarr at gmail.com> wrote:
> Hi all,
>
> We are experiencing a relatively-rare-but-not-rare-enough case which
> has approximately these steps:
>
> - run a wifi AP for a while with a station or two connected
> - shut down hostapd (stations all get disconnected of course)

Did you make sure you had no interface up and running? Did the
hardware go through warm/cold reset?


> - restart hostapd (perhaps on another channel or with different settings)
>
> After that, an external wifi sniffer can see beacons being transmitted
> by the AP as expected, but all packets from stations trying to connect
> are ignored.  In particular, Probe requests are not answered, and Auth
> requests do not even receive a wifi ACK.

This means WMI is working (each beacon is submitted via WMI). This
also implies CE works.

But if there are no ACKs this suggest HW must've been instructed to
ignore frames somehow.

(..) After taking a look I think wmi_vdev_start_request_cmd isn't
really handled properly for 10.x firmware. I'm guessing this ABI issue
might be the problem.

10.x firmware has:
  struct wmi_channel chan;
  __le32 vdev_id;
  __le32 requestor_id;
  __le32 num_noa_descriptors;
  __le32 disable_hw_ack;
  struct wmi_p2p_noa_descriptor noa_descriptors[2];

disable_hw_ack overlaps with dtim_period. Perhaps that's the problem.

It's intriguing how this hasn't manifested itself until now..


> Restarting hostapd doesn't fix it.  However, rmmoding and modprobing
> the ath10k_pci module does fix it.

Did the hardware go through warm or cold reset?


> This is with a mindspeed c2k host processor, 3.2 kernel, and modules
> backported by backports from kvalo's ath-next as of
> v3.15-rc1-237-gd9bc4b9 (roughly 2014-04-29).  Firmware is
> 10.1.467.2-1.
>
> Has anyone else seen this?  Any suggestions where to look to narrow
> down the problem?

I haven't seen anything like this.

For one reloading the driver may tickle cfg80211 and regulatory
updates but I just can't imagine how that could cripple ACKing.


> I can't exactly produce it on demand yet, but if someone suggests
> things to look for when it happens, it occurs often enough that I
> should be able tor run those things.

You might want to print out the vdev_start command's dtim_period
(which overlaps with 10.x's disable_hw_ack) before it is sent to fw
and compare the value for when ACKing works and when it doesn't.


Michał