Fatal trap 19: non-maskable interrupt trap while in kernel mode

[Simon 'corecode' Schubert]

On 05.11.2004, at 20:01, Gabor MICSKO wrote:
could you try a more recent -stable snapshot? 1.0a-release is pretty
outdated now.
I tried LATEST-Stable.iso

Results are here:
[...]
fwohci0: <Texas Instruments TSB43AB21/A/AI/A-EP> mem
0xd0000000-0xd0003fff,0xd0008000-0xd00087ff irq 11 at device 6.0 on 
pci0
installed MI handler for int 11
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
stack pointer           = 0x10:0xc0682c24
frame pointer           = 0x10:0xc0682c44
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, IOPL = 0
current process         = 0 (swapper)
current thread          = pri 12
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
fwohci_pci_attach(c604af18,c604af18,c604ae40,c0682cb4,0) at
fwohci_pci_attach+0x1eb
[etc]

[shnipp]
fwohci0: <Texas Instruments TSB43AB21/A/AI/A-EP> mem
0xd0000000-0xd0003fff,0xd0008000-0xd00087ff irq 11 at device 6.0 on 
pci0
installed MI handler for int 11
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
stack pointer           = 0x10:0xc0682c24
frame pointer           = 0x10:0xc0682c44
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, IOPL = 0
current process         = 0 (swapper)
current thread          = pri 12
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
fwohci_pci_attach(c604af18,c604af18,c604ae40,c0682cb4,0) at
fwohci_pci_attach+0x1eb
[etc]

now, despite the NMI handler telling us about RAM parity errors... this 
looks really reproducable. And from inspection, this must happen 
somewhere in there:

[fwohci.c#fwohci_init()]
        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);
i don't have firewire, so i can't check what should happen. Maybe 
firewire controllers of the type `Texas Instruments 
TSB43AB21/A/AI/A-EP' need special quirks?

cheers
  simon
--
/"\
\ /
 \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News
Attachment:
PGP.sig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00003.pgp
Type: application/octet-stream
Size: 186 bytes
Desc: "Description: This is a digitally signed message part"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20041105/4c3485e7/attachment-0020.obj>