[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problem with a SunFire V120 -- Kernel panics when trying to install



On Tue, Feb 9, 2010 at 12:26 PM, Yan Morissette <n30h4v3n@gmail.com> wrote:
> On Mon, Feb 8, 2010 at 5:40 PM, ewe2 <ewetoo@gmail.com> wrote:
>> On Tue, Feb 9, 2010 at 8:53 AM, Jurij Smakov <jurij@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.

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


Reply to: