Xilleon port from 2.4.5 to top of tree, asm("$28") problem

Xilleon port from 2.4.5 to top of tree, asm("$28") problem

[Rob Lembree]

Hi there,

	I'm the person who did the initial port of Linux 
to the ATI Xilleon chip (4KC based, little endian).  At the
time, we did the port to 2.4.5, and everything works
swimmingly. I'm now preparing to submit this for inclusion
to this source tree, and have come across a weird problem. 
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
to null?

thanks,
rob

-- 

Rob Lembree                        Metro Link Incorporated
29 Milk St.			     lembree@metrolink.com
Nashua, NH 03064-1651             http://www.metrolink.com
Phone:  954.660.2460               Alternate: 603.577.9714
PGP: 1F EE F8 58 30 F1 B1 20       C5 4F 12 21 AD 0D 6B 29

Re: Xilleon port from 2.4.5 to top of tree, asm("$28") problem

[Jon Burgess]

>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
>to null?

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
working.

- 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.

      Jon Burgess