From: Takao Indoh <indou.takao@jp.fujitsu.com>
To: dwmw2@infradead.org
Cc: iommu@lists.linux-foundation.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] intel-iommu: Synchronize gcmd value with global command register
Date: Mon, 08 Apr 2013 17:57:07 +0900 [thread overview]
Message-ID: <51628663.9040604@jp.fujitsu.com> (raw)
In-Reply-To: <1365085489.28127.64.camel@i7.infradead.org>
(2013/04/04 23:24), David Woodhouse wrote:
> On Thu, 2013-04-04 at 14:48 +0900, Takao Indoh wrote:
>>
>> - DMAR fault messages floods and second kernel does not boot. Recently I
>> saw similar report. https://lkml.org/lkml/2013/3/8/120
>
> Right. So the fix for that is to make the subsequent errors silent,
> until/unless we actually get a request to create a mapping for the given
> device.
>
>> - igb driver detectes error on linkup and kdump via network fails.
>
> That's a driver bug, IIRC. It was failing to completely reset the
> hardware. It's fixed now, isn't it?
No, it can be reproduced with latest kernel(3.9.0-rc6).
>
>> - On a certain platform, though kdump itself works, PCIe error like
>> Unexpected Completion is detected and it gets hardware degraded.
>
> More information required.
When I tested intel_iommu on a certain machine, the following error
message was logged in its firmware, and I/O board got abnormal status.
05:00.0 is igb, so I think this was caused by DMA error on igb. This
occurs before igb driver loading, so this cannot be fixed in driver.
PCI: Unexpected Completion Bus: 5 Device: 0x00 Function: 0x00
Anyway, I'm thinking we should introduce something framework to clean
all devices to stop DMA at boot time rather than dealing with the
problem in each driver. And one of the way I found is resetting devcies
by PCIe layer. If DMAR is disabled in init_dmars(), we can have a
chance to handle devices to stop DMA in PCI layer, like qci-quirk. This
is one of the reason why I propose this patch.
Thanks,
Takao Indoh
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-04-08 8:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 1:32 [PATCH] intel-iommu: Synchronize gcmd value with global command register Takao Indoh
2013-03-26 14:46 ` Joerg Roedel
2013-03-27 5:02 ` Takao Indoh
2013-03-27 10:31 ` Joerg Roedel
2013-04-01 5:45 ` Takao Indoh
2013-04-02 14:05 ` Joerg Roedel
2013-04-03 7:11 ` Takao Indoh
2013-04-03 8:24 ` David Woodhouse
2013-04-04 5:48 ` Takao Indoh
2013-04-04 14:24 ` David Woodhouse
2013-04-08 8:57 ` Takao Indoh [this message]
2013-04-05 11:06 ` Joerg Roedel
2013-04-10 4:47 ` Takao Indoh
2013-04-15 9:00 ` Takao Indoh
2013-04-15 10:18 ` Joerg Roedel
2013-04-17 8:48 ` Takao Indoh
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=51628663.9040604@jp.fujitsu.com \
--to=indou.takao@jp.fujitsu.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@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