>During boot-up, 'current' (which eventually evaluates to
>an offset of register struct thread_info *__current_thread_info
>__asm__("$28");) is null plus the offset, in sock_alloc,
>obviously making the kernel take a big dive.
> Are there any obvious reasons why this would evaluate
I've seen similar things when investigating a kernel locking hard during boot.
The two causes I found were:
- Interrupts being enabled before the interrupt handlers are installed and
- CP0 register being corrupted, leaving the CP0_STATUS CU0 bit unset. This leads
the exception routines (normally the interrupt handler) to think the exception
occured in usermode code and trying to derefence the 'current' pointer, but it
still NULL during the early kernel initialisation. I think this situation causes
a nested stream of TLB faults.
One way to diagnose 1 is to force the CP0_BEV to be left on during the early
kernel initialisation. This should force any exceptions such as an interrupt to
go to your boot rom exception handlers, which will probably dump out the cause
and location of the exception.
I eventually traced problem (2) back to a hardware problem hitting the
blast_icache() routine. See my post with the subject 'mips32_flush_cache routine
corrupts CP0_STATUS with gcc-2.96' on this mailing list for further details.