Message-ID: <AANLkTinEH+WAEUoWNYKxz6oRk7HAATG1p7CXMAx8Ss-V@mail.gmail.com>
Date:	Sun, 6 Feb 2011 00:20:36 +0000
From:	Matt <jackdachef@...il.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	linux-kernel@...r.kernel.org, David Miller <davem@...emloft.net>,
	geert@...ux-m68k.org, "R. Herbst" <ruediger.herbst@...glemail.com>
Subject: Re: Sun GEM PPC32 Bug?

On Sat, Feb 5, 2011 at 11:39 PM, Benjamin Herrenschmidt
<benh@...nel.crashing.org> wrote:
> On Sat, 2011-02-05 at 19:35 +0100, R. Herbst wrote:
>> > I think we're simply not resetting enough when the RX FIFO overflow
>> > happens.
>> >
>> > Just for fun I checked the OpenBSD GEM driver to see what they do.
>> > When an overflow occurs, they bump the statistic, record the current
>> > read and write fifo pointer registers, and schedule a watchdog timer
>> > for 400ms into the future.
>> >
>> > If the watchdog timer sees that the RX FIFO overflow bit is still set
>> > in the RX status register, and the RX FIFO read and write pointers
>> > have not changed, it resets the entire chip.
>> >
>> > We unconditionally reset the RX MAC when an overflow occurs, that may
>> > simply not be enough to unwedge this thing.
>
> Right. It would be quite easy for us to do the same thing. Interestingly
> enough, I have never observed this behaviour on any of my machines (a
> wide range of 32-bit and 64-bit Apple machines).
>
> Also, Apple's own driver does things differently. In case of overflow
> interrupt, it seems to only bump some statistics. However, it has a
> timeout if no packets have been received for a while (5 seconds) and the
> Rx fifo overflow bit is set. In that case, they restart the receiver
> (and the receiver only).
>
> Their sequence for restarting the receiver however is a tad different
> than ours (mostly slightly different ordering of things), it's hard to
> tell whether that's relevant or not, but some of the things do make
> sense, such as they stop the DMA before resetting the MAC and restart it
> after re-enabling the MAC.
>
> If I find some time tonight, else tomorrow, I'll whip up a couple of
> patches:
>
>  - One simpler re-arranging our Rx reset sequence and adding a test for
> the overflow bit at the end, printing out the results, etc...
>
>  - One that basically always reset the chip on overflow.
>
> From there we can decide what works and maybe add a bit of a timeout
> to the second approach if needed etc... but how often does that overflow
> happens in practice ?
>
> Cheers,
> Ben.
>
>
>

Well,

according to this post:
http://forums.gentoo.org/viewtopic-p-6565281.html#6565281

>Okay... Es muss ein Kernelproblem sein. Mit SFTP bekomme ich nur einen Datendurchsatz von ca. 40MBit hin. Da kommen dann die Probleme nicht vor.
>Mit FTP direkt habe ich einen Datendurchsatz von ca. 180MBit/s, dann rasseln wieder die Kernelmeldungen ohne Ende.

it doesn't appear when using sftp (only achieving 40 MBit/s
throughput), whereas kernel messages continuously seem to appear when
using FTP with a throughput of around 180 MBit/s


this also seems to apply to recent kernels (2.6.37-ish) according to
http://forums.gentoo.org/viewtopic-p-6564885.html#6564885

>Erstmal vielen dank für diesen Tipp. Leider hat auch das nichts an meinem Netzwerkproblem geämdert. Zieht das System immer noch bei Netzwerklast ins verderben. FREEZE.
>Werde jetzt mal einen uraltkernel probieren. Vielleicht hilft ja das. Früher ging das System ja mal sehr gut mit Linux.

I don't know what Ruediger exactly means with "freeze"

@Ruediger:

did I miss anything ?

does magic sysrq key still work for you ?



This remembers me of a similar problem I had with the sky2-driver and
the 88E8053 chipset, for several kernel-releases it seems to reset
itself fine now :)

Regards

Matt
--
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