Recently, I made some changes to two of my (ancient Intel TR-440BX) ISP-1100
servers, added RAM in one, upgraded BIOS on both.
Strangely, only the one with the upgraded RAM is now giving problems with the SMB (i.e. PIIX4) interface while attempting to
monitor the on-board Heceta-II device (volts, fans, temps).
With a slightly rewritten 'testsmb' command from the xmbmon sources, I can tell that the bus is getting written to even though the
process using the SMB interface has long since died. Only some part of the kernel can be doing this ..
[EMAIL PROTECTED]:/home/imb/xmbmon205# ./testsmb
bus=0x00:dev=0x07:fun=0x03 ---> chip=0x71138086 [0x90] SMBase=0x00000441
SMBHSTSTS: 0x01 < busy
SMBHSTCNT: 0x09 < byte read or write, irq enable
[EMAIL PROTECTED]:/home/imb/xmbmon205# ./testsmb
bus=0x00:dev=0x07:fun=0x03 ---> chip=0x71138086 [0x90] SMBase=0x00000441
SMBHSTSTS: 0x14 < not busy, command failed, device error
SMBHSTCNT: 0x08 < byte read or write
[EMAIL PROTECTED]:/home/imb/xmbmon205# ./testsmb
bus=0x00:dev=0x07:fun=0x03 ---> chip=0x71138086 [0x90] SMBase=0x00000441
SMBHSTSTS: 0x01 < busy
SMBHSTCNT: 0x08 < byte read or write
So .. my question is .. if a write to /dev/smbX fails, is there a time-out mechanism on the transaction (I can find a kernel code
path that would :-() or do I have to power-cycle the box? :-( :-(
Is there a mechanism by which I can reset the devices on /dev/smb0 (only PIIX4 and Heceta-II in this case) without power-cycling
the machine?
Speculation: there may still be an obscure race condition that caused an interrupt to be asserted by the PIIX4 prior to the SMB
interface completing the command it was given .. as the Intel AppNotes mention .. but I have yet to prove that ..
--
Michael Butler, CISSP
Security Architect
Protected Networks
http://www.protected-networks.net
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
