Date: Thu, 21 Dec 2006 20:16:33 -0800 From: Peter Grehan <grehan@freebsd.org> To: Andrew Turner <andrew@fubar.geek.nz> Cc: freebsd-ppc@freebsd.org Subject: Re: FreeBSD on an Efika Message-ID: <458B5C21.907@freebsd.org> In-Reply-To: <20061221233622.60ca5eb3@hermies.int.fubar.geek.nz> References: <20061218104841.72ba51ea@hermies.int.fubar.geek.nz> <4585CCC1.7050005@freebsd.org> <20061218222327.308dca53@hermies.int.fubar.geek.nz> <4586CA29.10803@freebsd.org> <20061219113230.34182787@hermies.int.fubar.geek.nz> <4587316C.1070500@freebsd.org> <20061220192614.04c53dbf@hermies.int.fubar.geek.nz> <45898F1F.402@freebsd.org> <20061221233622.60ca5eb3@hermies.int.fubar.geek.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Andrew,
>> I'll have a look at this today. Debugging could be difficult. When
>>you get the crash, is there a panic backtrace ? The SRR* registers
>>should be printed if that is the case.
>
> I get no output on either the screen or the serial line. After about
> 30s the computer reboots. It prints around 80 chars of a mixture of
> ASCII and binary and enters SmartFirmware (Open Firmware implementation)
Alright, no clues there :(
I went through the TLB data-load miss exception handler and it looks
fine. Once upon a time there was a bdneq macro in locore.S :)
Here's my suggested strategy:
- stick with the msgbuf-removed printf so you can get console output.
- write your favourite 0xdeadbeef-style pattern into the first word of
the physical address of the message buffer.
- read it back through the virtual address and verify that it is this
pattern.
- write a different pattern to the phys address and verify it again
thorugh the virt address.
If it hangs on the second read as before, then it's time to try
something different:
- create an exception handler that is identical to the existing
trapcode asm, but with 3 additional instructions prepended to clear the
GPR0-3 shadowing
mfmsr %r0
xoris %r0,%r0,PSL_TGPR@h
mtmsr %r0
/* fall through to trapcode */
- copy this to the TLB miss exception vectors. On a trap, you will
now end up in powerpc/trap.c:trap(), and can put in code to catch the
TLB miss vectors. At this point, it's worth dumping the DCMP, DMISS,
HASH1 and HASH2 spr's using the C-callable mfspr() routine. You can then
try implementing the TLB load routine in C, and verify that it does what
you think.
If this eventually works (and it will only work until the loading of
the stack in the low-level trapcode itself has a TLB miss), it's then
time to return to the ASM code.
One other way to verify that the ASM code did the right thing is to
examine the PTE in the pteg table and see if it's R bit was set: the ASM
code for the data-miss routine does this.
later,
Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?458B5C21.907>