svn commit: r198868 - in head/sys: amd64/amd64 i386/i386

[Kostik Belousov]

On Wed, Nov 04, 2009 at 05:06:36PM +0100, Attilio Rao wrote:
> 2009/11/4, Kostik Belousov <kostikbel at gmail.com>:
> > On Wed, Nov 04, 2009 at 01:49:41PM +0100, Attilio Rao wrote:
> > > 2009/11/4 Ed Schouten <ed at 80386.nl>:
> > > > Hi Attilio,
> > > >
> > > > * Attilio Rao <attilio at FreeBSD.org> wrote:
> > > >> Opteron rev E family of processor expose a bug where, in very rare
> > > >> ocassions, memory barriers semantic is not honoured by the hardware
> > > >> itself. As a result, some random breakage can happen in uninvestigable
> > > >> ways (for further explanation see at the content of the commit itself).
> > > >
> > > > Ooh. Sounds like an interesting bug.
> > > >
> > > > The bug doesn't manifest itself on UP, right? If so, maybe we should add
> > > > some very short instructions to the warning on how to disable SMP.
> > >
> > > Due to the semantic of the bug, I think that it can manifest itself on
> > > UP and a memory barrier failing on UP means that PREEMPTION can blow
> > > up. Considering this I wouldn't suggest anything different between the
> > > UP vs SMP case.
> >
> > CPU is always self-consistent, isn't it ?
> >
> > Also, I very much dislike idea of making our kernel a collection of
> > references to the man pages and URLs, esp. when URL point to the
> > resource not controlled by the project.
> 
> Ok, as long as you are in favor of stripping the URL, I'm fine with it.

I like des' proposal to have kernel config option to enable compile-time
workaround. This is how freebsd handled cyrix CPUs and Pentium f0 0f bug.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20091104/5aedb4a5/attachment.pgp