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>