linux-kernel - Re: i2c-i801 hangs indefinitely on IBM x3550

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.20.1607011455120.12974@math.ut.ee>
Date:	Fri, 1 Jul 2016 15:02:58 +0300 (EEST)
From:	Meelis Roos <mroos@...ux.ee>
To:	Jean Delvare <jdelvare@...e.de>
cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-i2c@...r.kernel.org, Wolfram Sang <wsa@...-dreams.de>
Subject: Re: i2c-i801 hangs indefinitely on IBM x3550

> > Tried latest Debian kernel (3.10-3-amd64) and latest upstream kernel 
> > (3.12-rc2) on a decommisioned IBM x3550 server. i2c-i801 is autoloaded 
> > but all access to it seems to wait forever, including stopping reboot 
> > from happening because modprobe is still running and blocked on this.
> > 
> > 00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09)
> >         Subsystem: IBM Device 02dd
> >         Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
> >         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
> >         Interrupt: pin B routed to IRQ 20
> >         Region 4: I/O ports at 0440 [size=32]
> >         Kernel driver in use: i801_smbus
> > 
> > 
> > [    3.028771] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
> > [...]
> > [  240.172009] INFO: task modprobe:267 blocked for more than 120 seconds.
> 
> Most likely SMBus interrupts do not work properly on this machine.
> Since then a number of improvements have been committed to the i2c-i801
> driver to detect and workaround corner cases in this area. If you still
> have this machine, you may want to try to upgrade to kernel v3.19 or
> later and see if it helps.

The machine is still alive and kicking with latest 4.7-rc4+. However, I 
do not remember the exact scenario  for testing.

Ran sensors, this works:

$ sensors
i5k_amb-isa-0000
Adapter: ISA adapter
Ch. 0 DIMM 0:  +38.5°C  (low  = +104.0°C, high = +124.0°C)
Ch. 0 DIMM 1:  +33.0°C  (low  = +100.0°C, high = +124.0°C)
Ch. 1 DIMM 0:  +42.5°C  (low  = +101.0°C, high = +124.0°C)
Ch. 1 DIMM 1:  +36.5°C  (low  = +99.5°C, high = +124.0°C)
Ch. 2 DIMM 0:  +58.0°C  (low  = +127.5°C, high = +127.5°C)
Ch. 3 DIMM 0:  +18.0°C  (low  = +127.5°C, high = +127.5°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +43.0°C  (high = +86.0°C, crit = +100.0°C)
Core 1:       +45.0°C  (high = +86.0°C, crit = +100.0°C)

aem1-isa-0000
Adapter: ISA adapter
power1:      188.16 W  (interval =   1.00 s)
energy1:     720.82 MJ

aem2-isa-0001
Adapter: ISA adapter
temp1:        +31.0°C  
temp2:        +20.0°C  
power1:      126.22 W  (interval =   1.00 s)
power2:      200.69 W  (interval =   1.00 s)
power3:       26.00 W  
power4:      374.00 W  
power5:      347.00 W  
power6:      265.40 W  
power7:      240.40 W  
energy1:     217.21 MJ
energy2:     720.82 MJ

ibmpex-isa-0000
Adapter: ISA adapter
temp1:         +0.0°C  
temp2:         +0.0°C  
temp3:         +0.0°C  
temp4:         +0.0°C  
power1:      131.00 W  (lowest =   7.00 W, highest = 186.90 W)
power2:      133.00 W  (lowest =   8.50 W, highest = 159.10 W)
power3:      132.60 W  (lowest =   8.70 W, highest = 155.80 W)
power4:      132.70 W  (lowest =   8.80 W, highest = 156.00 W)
power5:      127.10 W  (lowest =   8.80 W, highest = 155.00 W)
power6:      123.90 W  (lowest =   8.90 W, highest = 151.40 W)
power7:      123.30 W  (lowest =   9.00 W, highest = 148.40 W)
power8:      123.00 W  (lowest =   9.30 W, highest = 146.40 W)
power9:      208.00 W  (lowest =  67.00 W, highest = 267.00 W)
power10:     206.00 W  (lowest =  68.00 W, highest = 232.00 W)
power11:     196.00 W  (lowest =  81.00 W, highest = 227.00 W)

But the hwmon sensors seem to be prom ohter places than i2c.

mroos@...50:/sys/bus/i2c/devices$ ls -al
total 0
drwxr-xr-x 2 root root 0 Jul  1 14:50 .
drwxr-xr-x 4 root root 0 Jul  1 14:50 ..
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-0 -> ../../../devices/pci0000:00/0000:00:1f.3/i2c-0
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:01:01.0/i2c-1
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:01:01.0/i2c-2
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-3 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:01:01.0/i2c-3
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-4 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:01:01.0/i2c-4

So no i2c client drivers.

devices/pci0000:00/0000:00:1f.3/i2c-0 is i801_smbus.

modprobe eeprom + decode-dimms shows not dimm info but here is some i2c 
device now:
lrwxrwxrwx 1 root root 0 Jul  1 14:51 1-0050 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:01:01.0/i2c-1/1-0050
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-0 -> ../../../devices/pci0000:00/0000:00:1f.3/i2c-0
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:01:01.0/i2c-1
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:01:01.0/i2c-2
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-3 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:01:01.0/i2c-3
lrwxrwxrwx 1 root root 0 Jul  1 14:50 i2c-4 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:01:01.0/i2c-4

However, this seems to be attached to ATi graphics so probably DDC.

Reboot is working fine.

SO how do I see if os working? Nothing in dmesg, reboot works so seems 
OK?


-- 
Meelis Roos (mroos@...ux.ee)