Andi Kleen wrote:
in Linux. Apparently in some cases sata_nv does DMA on an already freed and then
reused mapping.
Any data or additional info on that? Did you discover this by tracking
the DMA API software routines, or something lower level (like a bus
analyzer)?
libata handles all the
> Andi, have you had a look at this? I'm a bit surprised at the lack of
> reaction to this find..
FYI the problem is still being analysed behind the scenes. Chip's patch didn't
fix
it in all cases unfortunately -- it just changed the timing enough to make it
happen
less often. The latest
Andi, have you had a look at this? I'm a bit surprised at the lack of
reaction to this find..
FYI the problem is still being analysed behind the scenes. Chip's patch didn't
fix
it in all cases unfortunately -- it just changed the timing enough to make it
happen
less often. The latest
Andi Kleen wrote:
in Linux. Apparently in some cases sata_nv does DMA on an already freed and then
reused mapping.
Any data or additional info on that? Did you discover this by tracking
the DMA API software routines, or something lower level (like a bus
analyzer)?
libata handles all the
Chip Coldwell wrote:
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from
Chip Coldwell wrote:
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from
On Wed, 17 Jan 2007, Andi Kleen wrote:
> On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
> > On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
> > > I agree,... it seems drastic, but this is the only really secure
> > > solution.
> >
> > I'd like to here from
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he
On Thursday 18 January 2007 22:00, Erik Andersen wrote:
> I just tried again and while using iommu=soft does avoid the
> corruption problem, as with previous kernels with 2.6.20-rc5
> using iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
This must be some separate bug and needs to be
On Friday 19 January 2007 08:57, Chip Coldwell wrote:
> But it still might be a reasonable thing to do to test the theory that
> the problem is cache coherency across the graphics aperture, even if
> it isn't a long-term solution for the problem.
I suspect it would disturb timing so badly that
On Thu, 18 Jan 2007, Andi Kleen wrote:
The Northbridge guarantees coherency over the aperture, but
only if the caching attributes match.
That's interesting. Makes sense, I suppose.
You would need to change_page_attr() every kernel address that is mapped into
the IOMMU to use an uncached
On Thu, Jan 18, 2007 at 10:29:14AM +0100, joachim wrote:
> Not only has it only been on Nvidia chipsets but we have only seen
> reports on the Nvidia CK804 SATA controller.
People have reported problems with other controllers. I have one here
I can test given a day or so.
I don't think it's
On Thu, Jan 18, 2007 at 04:00:28AM -0700, Erik Andersen wrote:
> I just tried again and while using iommu=soft does avoid the
> corruption problem, as with previous kernels with 2.6.20-rc5 using
> iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
i would file a separate bug about that,
Erik Andersen wrote:
> I just tried again and while using iommu=soft does avoid the
> corruption problem, as with previous kernels with 2.6.20-rc5
> using iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
> I still have to disable memhole and lose 1 GB. :-(
Please add this to the
joachim wrote:
> Not only has it only been on Nvidia chipsets but we have only seen
> reports on the Nvidia CK804 SATA controller. Please write in or add
> yourself to the bugzilla entry [1] and tell us which hardware you have
> if you get 4kB pagesize corruption and it goes away with
On Wed Jan 17, 2007 at 08:29:53AM +1100, Andi Kleen wrote:
> AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
> although there were similar problems on VIA in the past too.
> Unless a good workaround comes around soon I'll probably default
> to iommu=soft on Nvidia.
I just
Andi Kleen <[EMAIL PROTECTED]> wrote on 22:29 16/01/2007 +0100 :
> AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
> although there were similar problems on VIA in the past too.
> Unless a good workaround comes around soon I'll probably default
> to iommu=soft on Nvidia.
>
Andi Kleen [EMAIL PROTECTED] wrote on 22:29 16/01/2007 +0100 :
AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
although there were similar problems on VIA in the past too.
Unless a good workaround comes around soon I'll probably default
to iommu=soft on Nvidia.
-Andi
On Wed Jan 17, 2007 at 08:29:53AM +1100, Andi Kleen wrote:
AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
although there were similar problems on VIA in the past too.
Unless a good workaround comes around soon I'll probably default
to iommu=soft on Nvidia.
I just tried
joachim wrote:
Not only has it only been on Nvidia chipsets but we have only seen
reports on the Nvidia CK804 SATA controller. Please write in or add
yourself to the bugzilla entry [1] and tell us which hardware you have
if you get 4kB pagesize corruption and it goes away with iommu=soft.
How
Erik Andersen wrote:
I just tried again and while using iommu=soft does avoid the
corruption problem, as with previous kernels with 2.6.20-rc5
using iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
I still have to disable memhole and lose 1 GB. :-(
Please add this to the bugreport
On Thu, Jan 18, 2007 at 04:00:28AM -0700, Erik Andersen wrote:
I just tried again and while using iommu=soft does avoid the
corruption problem, as with previous kernels with 2.6.20-rc5 using
iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
i would file a separate bug about that,
On Thu, Jan 18, 2007 at 10:29:14AM +0100, joachim wrote:
Not only has it only been on Nvidia chipsets but we have only seen
reports on the Nvidia CK804 SATA controller.
People have reported problems with other controllers. I have one here
I can test given a day or so.
I don't think it's SATA
On Thu, 18 Jan 2007, Andi Kleen wrote:
The Northbridge guarantees coherency over the aperture, but
only if the caching attributes match.
That's interesting. Makes sense, I suppose.
You would need to change_page_attr() every kernel address that is mapped into
the IOMMU to use an uncached
On Friday 19 January 2007 08:57, Chip Coldwell wrote:
But it still might be a reasonable thing to do to test the theory that
the problem is cache coherency across the graphics aperture, even if
it isn't a long-term solution for the problem.
I suspect it would disturb timing so badly that it
On Thursday 18 January 2007 22:00, Erik Andersen wrote:
I just tried again and while using iommu=soft does avoid the
corruption problem, as with previous kernels with 2.6.20-rc5
using iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
This must be some separate bug and needs to be
> We've just verified that configuring the graphics aperture to be
> write-combining instead of write-back using an MTRR also solves the
> problem. It appears to be a cache incoherency issue in the graphics
> aperture.
Interesting.
Unfortunately it is also not correct. It was intentional to
On Wed, 17 Jan 2007, Chip Coldwell wrote:
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about
On Wed, 17 Jan 2007, Chip Coldwell wrote:
On Wed, 17 Jan 2007, Andi Kleen wrote:
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
We've just verified that configuring the graphics aperture to be
write-combining instead of write-back using an MTRR also solves the
problem. It appears to be a cache incoherency issue in the graphics
aperture.
Interesting.
Unfortunately it is also not correct. It was intentional to
mark
Andi Kleen wrote:
> AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
> although there were similar problems on VIA in the past too.
> Unless a good workaround comes around soon I'll probably default
> to iommu=soft on Nvidia.
I've just read the posts about AMDs and NVIDIAs
Chris Wedgwood wrote:
> I'd like to here from Andi how he feels about this? It seems like a
> somewhat drastic solution in some ways given a lot of hardware doesn't
> seem to be affected (or maybe in those cases it's just really hard to
> hit, I don't know).
>
Yes this might be true,.. those
> I'd like to here from Andi how he feels about this? It seems like a
> somewhat drastic solution in some ways given a lot of hardware doesn't
> seem to be affected (or maybe in those cases it's just really hard to
> hit, I don't know).
>
> > Well we can hope that Nvidia will find out more
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
> On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
> > I agree,... it seems drastic, but this is the only really secure
> > solution.
>
> I'd like to here from Andi how he feels about this? It seems like a
>
On Tue, Jan 16, 2007 at 09:31:31PM +0100, Krzysztof Halasa wrote:
> Do you (someone) have (maintain) a list of affected systems,
> including motherboard type and possibly version, BIOS version and
> CPU type? A similar list of unaffected systems with 4GB+ RAM could
> be useful, too.
All I know
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
> I agree,... it seems drastic, but this is the only really secure
> solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
Chris Wedgwood <[EMAIL PROTECTED]> writes:
> right now i'm thinking if we can't figure out which cpu/bios
> combinations are safe we might almost be better off doing iommu=soft
> for *all* k8 stuff except for those that are whitelisted; though this
> seems extremely drastic
Do you (someone) have
Arkadiusz Miskiewicz wrote:
> FYI it seems that I was also hit by this bug with qlogic fc card + adaptec
> taro raid controller on Thunder K8SRE S2891 mainboard with nvidia chipset on
> it.
>
>
On Tuesday 16 January 2007 19:01, Chris Wedgwood wrote:
> On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote:
> > >If one use iommu=soft the sata_nv will continue to use the new code
> > >for the ADMA, right?
> >
> > Right, that shouldn't affect it.
>
> right now i'm thinking if we
Chris Wedgwood wrote:
> right now i'm thinking if we can't figure out which cpu/bios
> combinations are safe we might almost be better off doing iommu=soft
> for *all* k8 stuff except for those that are whitelisted; though this
> seems extremely drastic
>
I agree,... it seems drastic, but this
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote:
> >If one use iommu=soft the sata_nv will continue to use the new code
> >for the ADMA, right?
>
> Right, that shouldn't affect it.
right now i'm thinking if we can't figure out which cpu/bios
combinations are safe we might almost
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote:
If one use iommu=soft the sata_nv will continue to use the new code
for the ADMA, right?
Right, that shouldn't affect it.
right now i'm thinking if we can't figure out which cpu/bios
combinations are safe we might almost be
Chris Wedgwood wrote:
right now i'm thinking if we can't figure out which cpu/bios
combinations are safe we might almost be better off doing iommu=soft
for *all* k8 stuff except for those that are whitelisted; though this
seems extremely drastic
I agree,... it seems drastic, but this is
On Tuesday 16 January 2007 19:01, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote:
If one use iommu=soft the sata_nv will continue to use the new code
for the ADMA, right?
Right, that shouldn't affect it.
right now i'm thinking if we can't figure out
Arkadiusz Miskiewicz wrote:
FYI it seems that I was also hit by this bug with qlogic fc card + adaptec
taro raid controller on Thunder K8SRE S2891 mainboard with nvidia chipset on
it.
Chris Wedgwood [EMAIL PROTECTED] writes:
right now i'm thinking if we can't figure out which cpu/bios
combinations are safe we might almost be better off doing iommu=soft
for *all* k8 stuff except for those that are whitelisted; though this
seems extremely drastic
Do you (someone) have
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem
On Tue, Jan 16, 2007 at 09:31:31PM +0100, Krzysztof Halasa wrote:
Do you (someone) have (maintain) a list of affected systems,
including motherboard type and possibly version, BIOS version and
CPU type? A similar list of unaffected systems with 4GB+ RAM could
be useful, too.
All I know is
On Wednesday 17 January 2007 07:31, Chris Wedgwood wrote:
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
I agree,... it seems drastic, but this is the only really secure
solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem to be affected (or maybe in those cases it's just really hard to
hit, I don't know).
Well we can hope that Nvidia will find out more (though I'm
Chris Wedgwood wrote:
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem to be affected (or maybe in those cases it's just really hard to
hit, I don't know).
Yes this might be true,.. those who
Andi Kleen wrote:
AMD is looking at the issue. Only Nvidia chipsets seem to be affected,
although there were similar problems on VIA in the past too.
Unless a good workaround comes around soon I'll probably default
to iommu=soft on Nvidia.
I've just read the posts about AMDs and NVIDIAs effort
54 matches
Mail list logo
