On Mon, 9 Apr 2007, M. Warner Losh wrote:

> In message: <Pine.GSO.4.60.0704091602120.4637@igloo.df.lth.se>
>            Anders Lindgren <ali@df.lth.se> 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 
difference.

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,
/ali:)