Date: Mon, 09 Feb 2004 18:11:53 +1000 From: Peter Grehan <grehan@freebsd.org> To: Suleiman Souhlal <refugee@segfaulted.com> Cc: freebsd-ppc@freebsd.org Subject: Re: Alu Powerbook Message-ID: <402740C9.1050506@freebsd.org> In-Reply-To: <20040209023918.079ec9f5@zZzZ.segfaulted.com> References: <20040206000245.20a84f0c@zZzZ.segfaulted.com> <40232DA3.5090508@freebsd.org> <20040206013218.4eb1cd37@zZzZ.segfaulted.com> <40235C60.9010509@freebsd.org> <20040206115743.2f6ad7af@zZzZ.segfaulted.com> <402450B7.9030106@freebsd.org> <20040208224036.6f1fb172@zZzZ.segfaulted.com> <402731BD.3070703@freebsd.org> <20040209023918.079ec9f5@zZzZ.segfaulted.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Suleiman,
>> Also, I suspect that OpenFirmware may clear the bit anyways.
>>Did the initial probe show this bit being set in the HID ?
>
> You are right. It is not shown as being set in the HID.
No problems, the test will be useful for systems that may
have a processor upgrade or firmware that doesn't implement
the errata.
> As for going in single/multi user, I have no idea what could be wrong.
> The scheduler still seems to switch between processes, after the 'hang'.
My only guess is that the user program may have corrupted code
and is sitting in a tight loop. I thought this may be due to
L3 cache problems, but it also occurs on systems that don't have
any L3 cache (e.g. ibook). So, I'm stumped. Just to make sure,
is your system a 17" PowerBook 2003 G4 GeForce440Go ? This
one requires L3 to be disabled on the Yellowdog Linux support page.
With some luck I'll have access to a new 12" iBook in the next
few weeks to do some debugging, but in the meantime if you want
to have a go at doing some detective work my suggestions are:
- write a small init that does nothing other than opening
/dev/console and doing a write(2) to it; note if that
makes more progress than the real init.
- enable syscall/signal tracing by setting KTR_SYSC and KTR_SIG at the
loader prompt
OK set debug.ktr.mask=0x2400
This may show if the process is caught in an endless signal-handling
loop, and also if it gets to issue any syscalls.
later,
Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?402740C9.1050506>