Spamming logs on firmware crash.

[Ben Greear]

Looks like my firmware died horribly and cannot recover.  That happens,
and I'm not sure what to do about it, but maybe we can at least not spam
the logs endlessly with this sort of thing?

I'd actually like some way to indicate to user-space that a reboot
is required (since warm/cold start have failed to recover the firmware).

May be a udev event?  I could also do an ethtool stat that could
be polled....

[253648.757661] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.757663] systemd-journald[353]: /dev/kmsg buffer overrun, some messages lost.
[253648.757664] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.757668] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.757673] ath10086] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758091] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758095] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758099] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758103] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758108] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758112] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758116] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758119] systemd-journald[353]: /dev/kmsg buffer overrun, some messages lost.
[253648.758120] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758124] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758128] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758131] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758134] systemd-journald[353]: /dev/kmsg buffer overrun, some messages lost.
[253648.758136] ath10k_pci 0000:04:00.0: boot target indicator ffffffff
[253648.758140] ath10k_pci 0000:04:00.0: boot target indicator ffffffff


Kernel is Linux ath10k-2220 3.17.0-rc2-wl-ath+, has some of my patches,
and was using my CT firmware.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com