On Tue, Feb 9, 2010 at 12:26 PM, Yan Morissette <[email protected]> wrote: > On Mon, Feb 8, 2010 at 5:40 PM, ewe2 <[email protected]> wrote: >> On Tue, Feb 9, 2010 at 8:53 AM, Jurij Smakov <[email protected]> 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.
Excellent, I'll give it a go myself and see if I get similar results. -- Emacs vs. Vi flamewars are a pointless waste of time. Nano is the best -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
