[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1288101532.3169.114.camel@edumazet-laptop>
Date: Tue, 26 Oct 2010 15:58:52 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Joe Buehler <aspam@....net>
Cc: netdev@...r.kernel.org
Subject: Re: kernel panic in fib_rules_lookup [2.6.27.7 vendor-patched]
Le mardi 26 octobre 2010 à 09:53 -0400, Joe Buehler a écrit :
> Eric Dumazet wrote:
>
> > Well, it would be surprising this being wrong and crash only once in a
> > while in fib_rules_lookup
>
> > Did you tried my last patch ?
>
> There was a patch to the kernel by David Daney back in January to
> improve performance of Octeon memory barriers. The patch changes the
> generic MIPS barrier code to introduce optimizations for Octeon. The
> LINUX version I am using is from the Octeon SDK and appears to have an
> early version of this patch. It's broken however -- the Jan patch has
> proper SYNCW instructions in smp_wmb while the SDK version does not.
>
> I have made your changes but will also fold in this change, then start
> some load testing.
>
> The real-time scheduler is broken in the LINUX I am using -- I get
> kernel crashes -- and I would be most happy if the SYNCW fix fixed that
> also.
>
> Joe Buehler
>
Just to make sure, you do use two "syncw", not only one ?
/*
* We actually use two syncw instructions in a row when we need a write
* memory barrier. This is because the CN3XXX series of Octeons have
* errata Core-401. This can cause a single syncw to not enforce
* ordering under very rare conditions. Even if it is rare, better safe
* than sorry.
*/
#define CVMX_SYNCW asm volatile ("syncw\n\tsyncw" : : : "memory")
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists