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