On Mon, Feb 8, 2010 at 5:40 PM, ewe2 <ewe...@gmail.com> wrote: > On Tue, Feb 9, 2010 at 8:53 AM, Jurij Smakov <ju...@wooyd.org> wrote: >> On Fri, Feb 05, 2010 at 09:10:04AM -0500, Yan Morissette wrote: >>> Every single time I try to install Debian with the sparc netboot image >>> (Of course, I'm using latest), after one to a few dialogs (usually >>> right after selecting country, sometimes after locale and sometimes >>> after DHCP config) the V120 crashes with the following being sent out >>> the LOM port: >>> >>> [ 254.915075] Unable to handle kernel NULL pointer dereference >>> [ 254.915075] Unable to handle kernel NULL pointer dereference >>> [ 255.109349] tsk->{mm,active_mm}->context = 0000000000000ad8 >>> [ 255.109349] tsk->{mm,active_mm}->context = 0000000000000ad8 >>> [ 255.302290] tsk->{mm,active_mm}->pgd = fffff8001d838000 >>> [ 255.302290] tsk->{mm,active_mm}->pgd = fffff8001d838000 >>> [ 255.486760] Kernel panic - not syncing: Aiee, killing interrupt handler! >>> [ 255.486760] Kernel panic - not syncing: Aiee, killing interrupt handler! >>> [ 255.707837] Press Stop-A (L1-A) to return to the boot prom >>> [ 255.707837] Press Stop-A (L1-A) to return to the boot prom >>> >>> I tried searching the mailing lists and google, the only thing I've >>> found points to this being about usb-storage, but I have no idea how >>> to disable this or fix this problem. >> >> It's a bit strange that the messages do not include any information on >> the address where NULL pointer dereference takes place, without it >> it's pretty hard to tell what happens. If you are able to return to >> the PROM 'ok' prompt after these messages, you can try to get a stack >> trace using 'ctrace' and register dump using '.registers' commands. If >> they are reproducible from one crash to another, then we should be >> able to track down the location of the crash using it. > > Any ideas how to get to that prompt? How would you do that on a pc at > keyboard? > > -- > Emacs vs. Vi flamewars are a pointless waste of time. Nano is the best > This is a completely headless machine, so I don't actually have any Sun keyboard to hit STOP+A or L1+A. I used minicom's break here, and here's output.
ok ctrace PC: f0056fe4 Last leaf: jmpl f00618b8 from 54caf4 0 w %o0-%o7: (420000 96 f0000000 fffff8001fe93cb8 29e1 800000026228f0b8 fffc5681 54c) Fast Data Access MMU Miss ok .registers Normal Alternate MMU Vector 0: 0 0 0 0 1: 0 fffdc6d0 410010 ff3c5c76f7ffc838 2: 0 f0000000 3ffffe00001 794000 3: 7de52e 0 e000000000788036 79beb0 4: fffff8001f038bc0 0 fffff80000790000 400000 5: 18 f e000000000788036 0 6: fffff8001d828000 fffff8001d828000 3ffffe00001 7afbe0 7: 0 3840 4000 b5bd1dd63fd72dbe %PC f0056fe4 %nPC f0056fe8 %TBA 420000 %CCR 88 XCC:Nzvc ICC:Nzvc ok I'm not quite sure how to interpret that "Fast Data Access MMU Miss" right there. :( It mostly usually happens when someone messes up and uses set instead of setenv in OpenBoot, but I have no idea what it's doing here. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org