netdev
[Top] [All Lists]

Re: Mystery packet killing tg3

To: Andi Kleen <ak@xxxxxx>
Subject: Re: Mystery packet killing tg3
From: Peter Buckingham <peter@xxxxxxxxxxxx>
Date: Thu, 05 May 2005 12:02:15 -0700
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, jgarzik@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050505185635.GE24386@xxxxxx>
References: <20050502162405.65dfb4a9@xxxxxxxxxxxxxxxxxxxxx> <20050502200251.38271b61.davem@xxxxxxxxxxxxx> <m14qdiyhcn.fsf@xxxxxx> <42791825.2080204@xxxxxxxxxxxx> <20050505114327.GA51761@xxxxxx> <427A5363.2080703@xxxxxxxxxxxx> <20050505180609.GB24386@xxxxxx> <427A6426.40104@xxxxxxxxxxxx> <20050505183144.GD24386@xxxxxx> <427A6898.4070804@xxxxxxxxxxxx> <20050505185635.GE24386@xxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Debian Thunderbird 1.0.2 (X11/20050331)
Andi Kleen wrote:
With iommu=force or CONFIG_IOMMU_DEBUG all IO is foced through the IOMMU.

okay, that's definitely bad...

Hmm - if you want to hack the kernel you could add udelay()s
to the no IOMMU paths in arch/x86_64/kernel/pci-gart.c and see if that cures the problem too. If yes then the timing
theory would be proved.
Actually the IOMMU code does more than just delaying, it also
does config space accesses which might flush or synchronize
things in the PCI bridges. Perhaps adding some dummy access
for that would be good too.

okay, i'll start to take a look at this, but it'll probably be a little while before i can really get to it. i'll let you know what i find out.

The dmesg looks similar to the previous one from the IOMMU
code perspective.

it actually looks like it's configure correctly now (at least from agp-gart messages), before we were getting errors. i guess the bios guys finally got it right ;-)

thanks,

peter

<Prev in Thread] Current Thread [Next in Thread>