Subject: 4.99.16 panics on TS7250 (was: Re: panic trying to add missing SDRAM
To: M. Warner Losh <>
From: Anders Lindgren <>
List: port-arm
Date: 04/09/2007 17:27:33
On Mon, 9 Apr 2007, M. Warner Losh wrote:

> In message: <>
>            Anders Lindgren <> 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
> cycle.
> 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.

Best regards,