[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081220205808.GA4465@8bytes.org>
Date: Sat, 20 Dec 2008 21:58:08 +0100
From: Joerg Roedel <joro@...tes.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [git pull] x86 fixes
On Sat, Dec 20, 2008 at 11:16:01AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 20 Dec 2008, Ingo Molnar wrote:
> >
> > Joerg Roedel (3):
> > AMD IOMMU: panic if completion wait loop fails
>
> What's the advantage to this, especially this late in the game?
>
> Now, I tried to google for the message (while ignoring the patches), and
> as far as I can tell, it has never happened that google has noticed. But
> still, why was this pushed as a "fix"?
Google won't tell because the hardware is not yet for sale. The story
behind this patch is, it happened that the completion wait loop failed in
my tests.
And when it fails then for sure because some error occured and the AMD
IOMMU stopped fetching commands from the command buffer (the reason why
it stopped fetching commands for me is also fixed with another patch in
this pull request, but there may be other reasons like internal errors).
But it is important that the IOMMU fetches commands because they are
needed to flush the IOTLB. If we can't flush the IOTLB we get data
corruption sooner or later. So I decided its better to panic in this
situation.
There is another way to handle this by resetting the command buffer. But
that is more code (basically code to flush the IOMMU cache for
everything we have under control with the IOMMU). Too much for inclusion
that late in the release cycle. I will prepare that for one of the
future merge windows.
For now, the best 'fix' in this situation is to panic before data
corruption can happen.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists