Re: interrupt routing problem?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:>BTW, none of this corrects the problem, as the controller stays locked
:>up. The only thing found to always work to fix it is:
:>
:>ifconfig em0 down
:>ifconfig em1 down
:>ifconfig em0 up
:>ifconfig em1 up
:
:Matt, do you have anything that I can look at to see what might be wrong
:with the MB? I never got anyone in FreeBSD to give a hoot about it. The
:info I have is:
:
:- at high speeds, the em transmit interface gets locked. Since this never
:happens in device_polling mode, my assumption is that the interrupts
:aren't working properly
:- There are 2 on-board NICs and 2 NICS in a PCI-X slot. When passing
:data through the 2 PCI-X slots, the lockup occurs within seconds. When
:using the onboard NICs, it takes a long time, perhaps an hour, before
:a problem occurs. The difference between the on-board NICs and
:the PCI-X nics are that the onboard NICs are running in 32bit/33Mhz
:mode while the PCI-X NICs are running 64bit/66Mhz mode.
:- all NICs are em driver.
:
:I have to try linux on this machine. Its a supermicro MB and they
:claim to have no info on problems with the hardware.

    Hmm.  If the machine itself is not dying then there's a chance we 
    can find the problem, but it isn't going to be easy.

    The first thing to do is to try to narrow the problem down to a single
    device, for example one of the PCI-X nics.  Recreate the problem and
    then generate a crash dump of the machine by ctl-alt-esc'ing into the
    debugger and panicing the box.  You may have to turn off buffer flushing
    on panic (sysctl kern.sync_on_panic=0).

    We currently have some issues with gdb'ing kernel cores that may make
    it more difficult to track the problem down.  Joerg has been working on
    them.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>