Subject: 4.99.16 panics on TS7250 (was: Re: panic trying to add missing SDRAM
To: M. Warner Losh <firstname.lastname@example.org>
From: Anders Lindgren <email@example.com>
Date: 04/09/2007 17:27:33
On Mon, 9 Apr 2007, M. Warner Losh wrote:
> In message: <Pine.GSO.firstname.lastname@example.org>
> Anders Lindgren <email@example.com> writes:
> : This is insane; I now reliably get the same Mutex error booting an
> : *unmodified* kernel. The unmodified kernel worked before I started playing
> : with the startup code, but now I consistently get a "locking against
> : myself" panic, despite having reverted all my changes and rebuilt the
> : kernel from scratch.
> I'm unsure what you are doing at the lowest level, but I've seen weird
In this case I was only adding some more entries to the L1 page table set
up in the startup-code, by copying & modifying the existing code that sets
up the section mappings for the first 8MB of SDRAM.
> behavior like this before. Have you tried resetting the board by
> turning it off for at least a minute? I've had bad kernels cause
> corruption in memory that somehow keeps things bad until a power
> I've more typically seen this in boot blocks where the SRAM in the
> part I was working on persisted after reset.
> It is a long shot...
Yep, tried that too just for the heck of it. As expected, it didn't make a
Hrrm.. I just tried changing rc.conf back to its original state -- and
voilą: If I say rc_configured=NO, I successfully drop into single user and
can type "/bin/ksh" for shell and poke around, running vi, setting date
via ntpdate etc.
When I reboot with rc_configured changed to YES, I get the lock error
again... presumably I just missed that the first time and started poking
around the startup code immediately after the first successful boot
(although I could swear I tried rebooting too ;-) )...
This all suggests that 4.99.16 is simply broken -- at least on TS7250.
The kernel I am booting (via RedBoot TFTP) is the netbsd-epe0.bin one.