/dev/smb issue?

[Michael Butler]

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 ..

imb at aaron:/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
imb at aaron:/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
imb at aaron:/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