On Sat, Jun 3, 2017 at 2:57 AM, Oleksij Rempel <linux@xxxxxxxxxxxxxxxx> wrote: > Hm... this function and file: > linux/drivers/net/wireless/ath/ath9k/common-beacon.c > didn't changed since 2015. So, it should be some thing different. > Can you run > git bisect to find exact patch caused this regression? > That was the first time I experienced the x/0 issue and don't know how I'd reproduce it. > Yes, this is "normal" problem. The firmware has no error handler for PCI > bus related exceptions. So if we filed to read PCI bus first time, we > have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot > and provide an kernel "firmware panic!" message. > Every one who can or will to fix this, is welcome. > Thanks for that explanation. I'm not sure it's something I could tackle though. My best bet in the meantime is to coax systemd to restart the services when the device pops up. However, every attempt has failed so far. > It is possible. If adapter is used in AP mode, then lots of WiFi noise > is dumped over this interface. I assume the reproducibility depends on > external environment, not internal. > I find this quite believable. I have 2.4ghz happening with the TP-Link, ZTE Mobley, bluetooth, logitech unifying, usb 3.0. Though all 4 devices are going through the USB 2.0 port, and the tp-link and mobley have long usb cables in the attic and the hub connects through a 2m usb extension. So yeah, I've got a lot of variables in play.
