From: Ben Greear <greearb@candelatech.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
netdev <netdev@vger.kernel.org>
Subject: Re: How to debug DMAR errors?
Date: Fri, 14 Apr 2017 09:19:36 -0700 [thread overview]
Message-ID: <fdbc5502-e388-b614-4f09-fa7de9a4f40e@candelatech.com> (raw)
In-Reply-To: <CAKgT0UcEKTsc6-tSHXMHFybnE4NQASKWHziq2SV+spOCLJGH-g@mail.gmail.com>
On 04/14/2017 08:45 AM, Alexander Duyck wrote:
> On Thu, Apr 13, 2017 at 11:12 AM, Ben Greear <greearb@candelatech.com> wrote:
>> Hello,
>>
>> I have been seeing a regular occurrence of DMAR errors, looking something
>> like this when testing my ath10k driver/firmware under some specific loads
>> (maximum receive of 512 byte frames in AP mode):
>>
>> DMAR: DRHD: handling fault status reg 3
>> DMAR: [DMA Read] Request device [05:00.0] fault addr fd99f000 [fault reason
>> 06] PTE Read access is not set
>> ath10k_pci 0000:05:00.0: firmware crashed! (uuid
>> 594b1393-ae35-42b5-9dec-74ff0c6791ff)
>>
>> So, I am wondering if there is any way I can get more information about what
>> this fd99f000 address
>> is?
>>
>> Once this problem hits, the entire OS locks hard (not even sysrq-boot will
>> do anything),
>> so I guess I would need the DMAR logic to print out more info on that
>> address somehow.
>>
>> Thanks,
>> Ben
>
> There isn't much more info to give you. The problem is that the device
> at 5:00.0 attempted to read at fd99f000 even though it didn't have
> permissions. In response this should trigger a PCI Master Abort
> message to that function. It looks like the firmware for the device
> doesn't handle that and so that is likely why things got hung.
>
> Really you would need to interrogate the ath10k_pci to see if there
> is/was a mapping somewhere for that address and what it was supposed
> to be used for.
I'm working on a hook in DMAR logic to call into ath10k_pci when the
error is seen, so the ath10k can dump debug info, including recent DMA
addresses.
My code is an awful hack so far, but if someone could add a clean way to register
DMAR error callbacks, I think that would be very welcome. It might could tie into
automated dma map/unmap debugging logic, and at the least, someone could write custom debugging callbacks
for the driver(s) in question.
Thanks,
Ben
>
> - Alex
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2017-04-14 16:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-13 18:12 How to debug DMAR errors? Ben Greear
[not found] ` <a21d8845-ae8d-fae0-b1b4-7bf6751b04b5-my8/4N5VtI7c+919tysfdA@public.gmane.org>
2017-04-14 15:45 ` Alexander Duyck
2017-04-14 16:19 ` Ben Greear [this message]
2017-04-14 16:24 ` Alexander Duyck
[not found] ` <CAKgT0UcPCMvs2OFkWGTs_TbKoxkLcnxjodroMDo82W4ptCfu3Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-14 16:41 ` Ben Greear
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fdbc5502-e388-b614-4f09-fa7de9a4f40e@candelatech.com \
--to=greearb@candelatech.com \
--cc=alexander.duyck@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).