Re: Fatal trap 19: non-maskable interrupt trap while in kernel m
:Type '?' for a list of commands, 'help' for more detailed help.
:OK boot -Dh
:...
:fwohci0: OHCI version 1.10 (ROM=1)
:NMI ISA b1, EISA ff
:RAM parity error, likely hardware failure.
:
:Fatal trap 19: non-maskable interrupt trap while in kernel mode
:instruction pointer = 0x8:0xc01e3b6e
:...
:interrupt mask = net tty bio cam
:kernel: type 19 trap, code=0
:Stopped at fwohci_init+0xfa: movl %ecx,%edi
:db> tr
:fwohci_init(c9823000,c604af18) at fwohci_init+0xfa
Ok. Hmm. It fails in the same place. The code in question is this:
....
/* Available Isochrounous DMA channel probe */
OWRITE(sc, OHCI_IT_MASK, 0xffffffff);
OWRITE(sc, OHCI_IR_MASK, 0xffffffff);
reg = OREAD(sc, OHCI_IT_MASK) & OREAD(sc, OHCI_IR_MASK);
OWRITE(sc, OHCI_IT_MASKCLR, 0xffffffff);
OWRITE(sc, OHCI_IR_MASKCLR, 0xffffffff);
for (i = 0; i < 0x20; i++)
if ((reg & (1 << i)) == 0)
break;
....
It fails just after the OREAD's. My guess is that something in the
fwohci init code is blowing up the system hardware.
OpenBSD has similar but slightly different initialization code, but the
differences shouldn't account for the failure.
The question is... when you booted up OpenBSD did it probe the firewire
interface at all?
NetBSD also has similar code, but in NetBSD's case it also clears the
command pointers after probing the transmit bitmap. But this occurs
after the crash point.
In anycase, my guess is that if you do not use firewire you can compile
up a DragonFly kernel that does not probe the firewire controller and
it will work. It is clearly *NOT* a ram problem... it's definitely a
firewire initialization issue that is causing the firewire hardware to
blow up the system bus.
If you have the ability to compile up DragonFly kernels with some patches
and want to try to get the firewire working I could put together a patch
for you to try.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 5 之 24 篇)：