ath10k driver crashes whenever firmware crashes on ARM SoC

Avery Pennarun apenwarr at gmail.com
Tue Jan 28 15:55:28 EST 2014


On Tue, Jan 28, 2014 at 3:28 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> Can you put a sleep in before the initial write?

I've tried adding printks and various things before the write, and it
didn't seem to help.

I also noticed that iowrite32() contains a write barrier, and
ioread32() contains a read barrier, but they're structured like this:

iowrite32() { wmb(); write32(); }
ioread32() { read32(); rmb(); }

Which means that actually the write32() and read32() do not have
barriers between them.  I think that might be a problem, but adding
the barriers didn't help either.

> There are hardware bugs that are.. delicate. What you should do is find what
> kind of reporting you can pull out of the pcie endpoint the nic is connected
> to in order to see why it threw a fatal error. Then at least we can poke it
> further.

Ok.  I'm going to see if I can hunt down a PCIe bus analyzer and find
out what the deal is.

> Its also worth asking the qca hardware team about this. They'll likely want
> to know what the pcie errors are so please figure that out.

Thanks for the advice!

Are other people not seeing this?  Or are they just trying not to
crash the firmware so they don't have to care? :)

Thanks,

Avery



More information about the ath10k mailing list