Free Ultra2 in Silicon Valley, USA

Marius Strobl marius at
Mon Nov 3 14:30:45 PST 2008

On Fri, Oct 31, 2008 at 08:18:27AM -0500, Mark Linimon wrote:
> On Fri, Oct 31, 2008 at 06:02:28AM -0700, mdh wrote:
> > A dual CPU Ultra2 is going to be a lot more powerful than an Ultra5.
> Hmm, ok, didn't know that.  If no-one else claims it first, perhaps
> I can claim it for the build cluster and pull one of the Ultra 5s.
> I intend to be out in for meetBSD.
> > E4500's can be relatively beefy.
> We could have gotten our hands on some more of them in but the
> problem is who wants to pay for the power :-(  Really, their time has
> come and gone.
> > OK, this is probably way over my head, but I'll bite - what exactly
> > happens if you don't breakpoint through it?  
> .
> This appears to be some kind of race condition; my guess from fooling
> around with it is that some interrupt is enabled, and then fires, before
> the setup to handle it is finished.  (Note that the same kernel runs
> fine on the 100s).  By stepping through it, you can see it fail at
> different locations; without stepping through it, it is always at
> the same.
> Unfortunately my notes are at home and that machine is unreachable ATM.

It's more likely that a device is exceeding the mapping
provided, which causes the uncorrectable DMA error
interrupt and in turn happens in different locations
depending on how far the CPU has progressed since the
transfer request was issued to the device. Anyway,
the panic message provided isn't enough info to even
guess what the real cause is. I think the easiest way
to proceed would be to remove the remaining NIC (is
there a reason you disabled gem(4) for the on-board
ones?) and mass storage controller drivers one by one
and see when the panic goes away. I'd begin with just
disabling ATAPI DMA (meanwhile done by the sparc64
loader by default) though as ata(4) has a known issue
causing data corruption with the ALI M5229 and ATAPI
DMA on sparc64, which isn't impossible to be related
with your problem. That said, my T1 AC200 is running
fine and I've never seen such a problem with it...


More information about the freebsd-sparc64 mailing list