On Tue, 2010-11-30 at 19:34 +0100, Marc Dequènes wrote: > Package: linux-2.6 > Version: 2.6.32-28 > Severity: normal > > Coin, > > My box was running 2.6.32-3-amd64 (2.6.32-9) when today a power outage > happened. Later, the boot blocked at the "Loading kernel modules" stage > with the modprobe command blocked when loading ipmi_si (i still could see > the blocked process after a Ctrl-C and having back a shell). It waited > more than an hour on this stage without any better result. There has been only one change to this driver between version 2.6.32-9 and 2.6.32-28 and it has nothing to do with initialisation. It is possible that this bug is only triggered by a reboot without turning the power off. So, to use a cliché, have you tried turning it off and on again? > In the kernel logs i found: > Nov 30 13:34:14 Orfeo kernel: [ 65.944753] ipmi message handler version 39.2 > Nov 30 13:34:14 Orfeo kernel: [ 65.947138] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca2, slave address 0x20, irq 0 > Nov 30 13:34:14 Orfeo kernel: [ 506.440019] ipmi_si: There appears to be no BMC at this location > Nov 30 13:36:09 Orfeo kernel: [ 947.045526] ipmi_smic_drv: smic hosed: state = SMIC_OP_OK, status != SMIC_SC_SMS_READY > Nov 30 13:36:09 Orfeo kernel: [ 947.097592] ipmi_si: Unable to find any System Interface(s) > Nov 30 13:36:09 Orfeo kernel: [ 947.173857] ipmi device interface > Nov 30 15:59:16 Orfeo kernel: [ 17.428166] ipmi message handler version 39.2 > Nov 30 15:59:16 Orfeo kernel: [ 17.430656] ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca2, slave address 0x20, irq 0 > > dmidecode gives the following info on IPMI: > Handle 0x003F, DMI type 38, 16 bytes > IPMI Device Information > Interface Type: KCS (Keyboard Control Style) > Specification Version: 2.0 > I2C Slave Address: 0x10 > NV Storage Device Address: 0 > Base Address: 0x0000000000000CA2 (I/O) > > Even if a hardware problem is perhaps the cause, the module should not > block after not finding any device. Moreover, it looks at address 0x20, > while the SMBIOS reports 0x10 (via dmidecode), so the problem perhaps > lies here. [...] I don't think so. For some reason, dmidecode divides the specified I2C address by 2 before displaying it. This has no basis in the SMBIOS specification and is probably a bug in dmidecode. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part