Re: Sparc architecture requalification
On Mon, 22 May 2006, Gustavo Franco wrote:
Is there a simple way to reproduce this critical bug in a ultra1
(yeah!) ? Btw, i've some suggestions to easily identify and backport
the .17-rcX fix:
No, it's not easy. Neither I nor Clint Adams were able to reproduce it
locally on similar machines. Yet it was killing two different buildds
every time it tried to build openoffice and other large packages. So far
the only person who can reproduce it reliably (even with 2.6.17-rc3) is
Blars Blarson. If you are lucky (for some values of lucky :-), you can hit
another bug which probably affects ultra1: esp scsi driver is busted and
dies with DMA errors on any significant disk activity. Martin Habets is
currently looking into it.
- Ask David S. Miller <davem at sunset dot davemloft dot net>
He's aware of this problem.
- If he can't tell us the exact commit, we can isolate the problem
using git bisect[0]
In a ultra1 the bisect game wll took ages for me, so i couldn't do
that, just reproduce the bug with a older kernel and test a patched
.16.
So far there was only tentative agreement to adopt 2.6.16 for etch (at
least, that's my perception of the situation). Certain arguments against
2.6.16 were presented on debian-kernel mailing list. For sparc, 2.6.16 is
a lose-lose situation, because a) the status of the 2.6.16 kernel with
respect to SMP crash is largely unknown, and testing it out extensively on
buildds is not very feasible; and b) 2.6.17 is the first kernel which
contains the support for Sun's new Niagara processor. That support is not
trivially backportable, so if 2.6.16 is adopted as the etch kernel, we
might have to copy over the whole sparc64 directory from 2.6.17 and hope
that we can make it work.
Best regards,
Jurij Smakov jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
Reply to: