linux-mips
[Top] [All Lists]

Re: Tester with IP27/IP30 needed

To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Subject: Re: Tester with IP27/IP30 needed
From: Ralf Baechle <ralf@linux-mips.org>
Date: Tue, 15 Jan 2008 18:18:12 +0000
Cc: linux-mips@linux-mips.org
In-reply-to: <20080115135300.GB5189@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20080115112420.GA7347@alpha.franken.de> <20080115131145.GA5189@linux-mips.org> <20080115135300.GB5189@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.17 (2007-11-01)
On Tue, Jan 15, 2008 at 01:53:00PM +0000, Ralf Baechle wrote:

> > > we are facing a strange problem with lenny/sid chroots on IP28. The
> > > machine locks up after issuing a few ls/ps commands in a chroot
> > > bash. This only happens with a lenny/sid chroot, but not with etch.
> > > The major difference is probably the updare to glibc2.7. Since
> > > IP28 isn't really a nice R10k machine, it would be good, if someone
> > > with a working IP27/IP30 could try a lenny/sid chroot and tell us,
> > > if it's working/not working.
> > 
> > Which CPU revision do you hit these problems on?
> 
> On IRC Thomas said it's rev 2.5.
> 
> R10000 upto version 2.6 has a broken store conditional so needs
> R10000_LLSC_WAR enabled.  The sympthom is that SC succeed even though
> it should have failed so for example two multiple competing CPUs can
> take a spinlock.  There is an erratum for this one.
> 
> Another bug is when a rdhwr $29 opcode is encountered in a branch delay
> slot.  This will result in the CPU stopping execution of instructions
> but an NMI can recover it.  For emulation performance reasons gcc no
> longer places rdhwr $29 in delay slots, so this one is no longer
> encountered in C code but still could be in assembler code.  This one
> isn't covered by any errata.
> 
> There seem to be more funnies but to the best I can say they were never
> officially documented in errata either.

So I tested the rootfs provided by Florian and more or less as expected
it immediately took out the 2 CPU R10000 v2.7 Origin I was testing on.
Seems like only one CPU stopped, as the machine was pinging and reacts
to NMIs.  So could well be the effect I observed ages ago when trying to
convert to glibc 2.4.

  Ralf

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