[lm-sensors] Kernel hangs with i2c-i801 driver?

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi,

Last night I reported ticket #2116[1] which is related to the kernel
hanging when attempting to set the sensor limits with sensors -s. I
started reading on the list of other open tickets on other chips to
see if I could find something similar, and I found ticket #2111[2]
reported by Keith.

The common thing between botf our problems is that:

1. We both use kernel 2.6.14 (either 2.6.14 or 2.6.14.2).
2. We both use the i2c-i801 driver.
3. We both have SMP enabled kernels running on P4 CPUs with HT enabled.

In my case I have the w83792d driver for my sensor chip while Keith is
using the lm85 driver. But since we both experience the same lockup
under the same conditions I'm more suspicious of the i2c-i801 driver
and how that driver is behaving in kernel 2.6.14 on SMP systems. Any
other experience where this driver is find under these conditions?

Please CC me as I'm not on the list.

Thanks
Daniel Nilsson

[1]: http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket!16
[2]: http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket!11

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Jean Delvare]

Hi Daniel, Keith,

On 2005-11-23, Daniel Nilsson wrote:
> Last night I reported ticket #2116[1] which is related to the kernel
> hanging when attempting to set the sensor limits with sensors -s. I
> started reading on the list of other open tickets on other chips to
> see if I could find something similar, and I found ticket #2111[2]
> reported by Keith.
>
> The common thing between both our problems is that:
>
> 1. We both use kernel 2.6.14 (either 2.6.14 or 2.6.14.2).
> 2. We both use the i2c-i801 driver.
> 3. We both have SMP enabled kernels running on P4 CPUs with HT enabled.

4. You both have the eeprom module loaded.

> In my case I have the w83792d driver for my sensor chip while Keith is
> using the lm85 driver. But since we both experience the same lockup
> under the same conditions I'm more suspicious of the i2c-i801 driver
> and how that driver is behaving in kernel 2.6.14 on SMP systems. Any
> other experience where this driver is find under these conditions?

No other report I can think of. Most reported problems of "sensors -s"
causing problems are either CPU throttling or instant power-off, not
lockups.

The i2c-i801 did not receive any recent change which could explain the
problem, and the driver is widely used (including by me on UP) so it is
certainly not fundamentally broken. It must have been widely tested on
SMP systems too. You have an ICH7 though, which is one of the most
recent incarnation of the i801, and this one may not have received
extended testing. Keith, is it an ICH7 on your system too, or another
incarnation?

"sensors -s" does too many things so it'll be hard to find out what
exactly causes the hang. Could be any write on the bus, or a specific
limit change. Better would be to try writing to the /sysfs files
directly, manually, and see if any write causes the problem, or only to
certain files.

Please also try to reproduce the hang without loading the eeprom driver.
I would additionally be interested in the SMBus topology (output of
"i2cdetect 0" to start with, or whatever the bus number is for
i2c-i801). Do you happen to know if the SMBus on that board is
multiplexed or shared with another bus type.?

--
Jean Delvare

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi Jean,

On Wed, Nov 23, 2005 at 01:18:32PM +0100, Jean Delvare wrote:
> "sensors -s" does too many things so it'll be hard to find out what
> exactly causes the hang. Could be any write on the bus, or a specific
> limit change. Better would be to try writing to the /sysfs files
> directly, manually, and see if any write causes the problem, or only to
> certain files.

I will try this later, probably tomorrow since I only have remote
access right now and no way to reset the machine :-( Should I attempt
to write arbitrary values to all writeable files under
/sys/bus/i2c/devices/0-002c/ ?

> Please also try to reproduce the hang without loading the eeprom
> driver.

Ok, I'll include that in the testing proposed above.

> I would additionally be interested in the SMBus topology (output of
> "i2cdetect 0" to start with, or whatever the bus number is for
> i2c-i801).

i2c-i801 is bus 0 on my machine, the only i2c bus.

oden:~# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          XX XX XX XX XX 08 XX XX XX XX XX XX XX 
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 
20: XX XX XX XX XX XX XX XX XX XX XX XX UU XX XX XX 
30: XX 31 XX 33 XX XX XX XX XX XX XX XX XX XX XX XX 
40: XX XX XX XX 44 XX XX XX UU XX XX XX UU XX XX XX 
50: XX UU XX UU XX XX XX XX XX XX XX XX XX XX XX XX 
60: 60 61 XX XX XX XX XX XX XX 69 XX XX XX XX XX XX 
70: XX XX XX XX XX XX XX XX                         

> Do you happen to know if the SMBus on that board is
> multiplexed or shared with another bus type.?

Well, I'm not sure. What I can tell though is that sensors-detect
suggested to insert the it87 driver as well. If I do, I get the
message:

it87: Found IT8712F chip at 0x290, revision 7

in the kernel log. The output of sensors then reads:

oden:~# sensors
it8712-isa-0290
Adapter: ISA adapter
VCore 1:   +1.26 V  (min =  +4.08 V, max =  +4.08 V)   ALARM
VCore 2:   +1.47 V  (min =  +4.08 V, max =  +4.08 V)   ALARM
+3.3V:     +6.59 V  (min =  +8.16 V, max =  +8.16 V)   ALARM
+5V:       +6.85 V  (min =  +6.85 V, max =  +6.85 V)   ALARM
+12V:     +11.58 V  (min = +16.32 V, max = +16.32 V)   ALARM
-12V:     -13.86 V  (min =  +3.93 V, max =  +3.93 V)   ALARM
-5V:       -8.51 V  (min =  +4.03 V, max =  +4.03 V)   ALARM
Stdby:     +5.56 V  (min =  +6.85 V, max =  +6.85 V)   ALARM
VBat:      +3.17 V
fan1:        0 RPM  (min =    0 RPM, div = 8)          
fan2:        0 RPM  (min =    0 RPM, div = 8)          
fan3:       -1 RPM  (min =    0 RPM, div = 8)          
M/B Temp:    +80?C  (low  =    -1?C, high =    -1?C)   sensor = thermistor   
CPU Temp:    +64?C  (low  =    -1?C, high =    -1?C)   sensor = diode   
Temp3:       +75?C  (low  =    -1?C, high =    -1?C)   sensor = thermistor   

I'm not sure if there is a second I2C master on the bus or if the same
master is also mapped to the ISA bus address space somehow? Except for
that, I don't know how to answer the question...

-- 
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Keith]

--- Jean Delvare <khali@linux-fr.org> wrote:

> The i2c-i801 did not receive any recent change which
> could explain the
> problem, and the driver is widely used (including by
> me on UP) so it is
> certainly not fundamentally broken. It must have
> been widely tested on
> SMP systems too. You have an ICH7 though, which is
> one of the most
> recent incarnation of the i801, and this one may not
> have received
> extended testing. Keith, is it an ICH7 on your
> system too, or another
> incarnation?


Hiya fellas.  Sorry I'm not on the list either but
will be eventually.  Anyway I haven't done anything
sensor-related lately, but here's what lspci has to
say (sorry if the lines wrap; yahoo mail is
braindead):


00:00.0 Host bridge: Intel Corporation 82875P/E7210
Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82875P Processor
to AGP Controller (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge
(rev c2)
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER
(ICH5/ICH5R) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801EB/ER
(ICH5/ICH5R) IDE Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801EB
(ICH5) SATA Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801EB/ER
(ICH5/ICH5R) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation
NV43 [GeForce 6600/GeForce 6600 GT] (rev a2)
02:01.0 SCSI storage controller: Adaptec AIC-7892A
U160/m (rev 02)
02:02.0 Multimedia audio controller: Creative Labs SB
Live! EMU10k1 (rev 08)
02:02.1 Input device controller: Creative Labs SB
Live! MIDI/Game Port (rev 08)
02:0c.0 Ethernet controller: Intel Corporation 82540EM
Gigabit Ethernet Controller (rev 02)


> Please also try to reproduce the hang without
> loading the eeprom driver.


Haven't tried this yet but will this weekend.


> I would additionally be interested in the SMBus
> topology (output of
> "i2cdetect 0" to start with, or whatever the bus
> number is for
> i2c-i801). Do you happen to know if the SMBus on
> that board is
> multiplexed or shared with another bus type.?


I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          XX XX XX XX XX 08 XX XX XX XX XX XX XX 
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX UU XX 
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 
40: XX XX XX XX 44 XX XX XX XX XX XX XX XX XX XX XX 
50: 50 51 52 53 XX XX XX XX XX XX XX XX XX XX XX XX 
60: XX 61 XX XX 64 XX XX XX XX 69 XX XX XX XX XX XX 
70: XX XX XX XX XX XX XX XX







	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Henrique de Moraes Holschuh]

On Wed, 23 Nov 2005, Keith wrote:
Keith, can you run dmidecode as root and see if your board identifies itself?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Jean Delvare]

Hi Daniel,

On 2005-11-23, Daniel Nilsson wrote:
> (...) Should I attempt
> to write arbitrary values to all writeable files under
> /sys/bus/i2c/devices/0-002c/ ?

Yes, one at a time.

I would start by writing safe values to the limit files: 0 to min voltage
limits, 10000 to max voltage limits (the driver will automatically trim
down to the max possible limit), 100000 to max temperature limits,
etc... The idea is to find out whether the write transactions themselves
are causing problems (unlikely) or if the problem is triggered by an
alarm condition which results from setting some limits too tight. If the
safe writes seem to work OK, try more dangerous ones and see when it
breaks.

I seem to understand that "sensors -s" does not always hang. This will
probably make the investigation harder. I admit I don't have much idea
what we are trying to demonstrate at this point, just trying to gather
enough data to have better ideas.

If you could try an older kernel (for example 2.6.13.4) and see if you
have the problem there too, that would be interesting. Just because the
i2c-i801 driver didn't change doesn't mean that nothing in the kernel
did change. If the monitoring chip is generating some hardware interrupt
on alarm conditions, the i2c-i801 driver may not be involved at all.

Oh, another thing to try I forgot to mention (for Keith too) would be to
run an UP kernel on the same hardware and see if the problem disappears.
It would be nice if we can at least assert that SMP is one triggering
factor.

>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          XX XX XX XX XX 08 XX XX XX XX XX XX XX
> 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 20: XX XX XX XX XX XX XX XX XX XX XX XX UU XX XX XX
> 30: XX 31 XX 33 XX XX XX XX XX XX XX XX XX XX XX XX
> 40: XX XX XX XX 44 XX XX XX UU XX XX XX UU XX XX XX
> 50: XX UU XX UU XX XX XX XX XX XX XX XX XX XX XX XX
> 60: 60 61 XX XX XX XX XX XX XX 69 XX XX XX XX XX XX
> 70: XX XX XX XX XX XX XX XX

SMBus 2.0, nothing unusual here.

> (...) What I can tell though is that sensors-detect
> suggested to insert the it87 driver as well. If I do, I get the
> message:
>
> it87: Found IT8712F chip at 0x290, revision 7
>
> in the kernel log. The output of sensors then reads:
>
> oden:~# sensors
> it8712-isa-0290
> Adapter: ISA adapter
> VCore 1:   +1.26 V  (min =  +4.08 V, max =  +4.08 V)   ALARM
> VCore 2:   +1.47 V  (min =  +4.08 V, max =  +4.08 V)   ALARM
> +3.3V:     +6.59 V  (min =  +8.16 V, max =  +8.16 V)   ALARM
> +5V:       +6.85 V  (min =  +6.85 V, max =  +6.85 V)   ALARM
> +12V:     +11.58 V  (min = +16.32 V, max = +16.32 V)   ALARM
> -12V:     -13.86 V  (min =  +3.93 V, max =  +3.93 V)   ALARM
> -5V:       -8.51 V  (min =  +4.03 V, max =  +4.03 V)   ALARM
> Stdby:     +5.56 V  (min =  +6.85 V, max =  +6.85 V)   ALARM
> VBat:      +3.17 V
> fan1:        0 RPM  (min =    0 RPM, div = 8)
> fan2:        0 RPM  (min =    0 RPM, div = 8)
> fan3:       -1 RPM  (min =    0 RPM, div = 8)
> M/B Temp:    +80?C  (low  =    -1?C, high =    -1?C)   sensor = thermistor
> CPU Temp:    +64?C  (low  =    -1?C, high =    -1?C)   sensor = diode
> Temp3:       +75?C  (low  =    -1?C, high =    -1?C)   sensor = thermistor
>
> I'm not sure if there is a second I2C master on the bus or if the same
> master is also mapped to the ISA bus address space somehow? Except for
> that, I don't know how to answer the question...

No, the IT8712F is essentially a Super-I/O chip with a flash interface
and some legacy I/O functions (serial ports, floppy disk drive
controller etc...) which happens to incorporate hardware monitoring
functions. But the presence of a Winbond W83792D chip and the totally
bogus values you get from the IT8712F chip make it clear that the
motherboard manufacturer decided to add a dedicated chip for hardware
monitoring rather than to use the IT8712F features. Just don't load the
it87 driver at all.

Can you please just provide the output of "isadump 0x295 0x296" to rule
out the possibility that the IT8712F chips was connected to the SMBus
with the same address the W83792D chip uses? Unlikely, but you never
know...

--
Jean Delvare

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Keith]

--- Henrique de Moraes Holschuh <hmh@debian.org>
wrote:
> On Wed, 23 Nov 2005, Keith wrote:
> Keith, can you run dmidecode as root and see if your
> board identifies itself?

Sure.  The output is long so here's a URL:

http://valaran.com/~kw/lms/dmidecode.txt






		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Keith]

--- Jean Delvare <khali@linux-fr.org> wrote:
> I would start by writing safe values to the limit
> files: 0 to min voltage
> limits, 10000 to max voltage limits (the driver will
> automatically trim
> down to the max possible limit), 100000 to max
> temperature limits,
> etc... The idea is to find out whether the write
> transactions themselves
> are causing problems (unlikely) or if the problem is
> triggered by an
> alarm condition which results from setting some
> limits too tight. If the
> safe writes seem to work OK, try more dangerous ones
> and see when it
> breaks.


Hm it's worth noting now (and I should've put it in
the ticket) that after the first time the system froze
from a ``sensors -s'', I was able to reboot
(subsequent times I was not able to; had to pull the
battery to clear whatever was fouled) and the BIOS log
mentioned something along the lines of the CPU
overheating.  So maybe the limits were set too tight. 
I then set the upper limit (temp1_max) higher but it
made no difference.  However I didn't touch the
"Board" and "Remote" limits...
 

> I seem to understand that "sensors -s" does not
> always hang. 


This is true.  I had it run to completion (got the
bash prompt back) once, and then it hung.


> If you could try an older kernel (for example
> 2.6.13.4) and see if you
> have the problem there too, that would be
> interesting. Just because the
> i2c-i801 driver didn't change doesn't mean that
> nothing in the kernel
> did change. If the monitoring chip is generating
> some hardware interrupt
> on alarm conditions, the i2c-i801 driver may not be
> involved at all.
> 
> Oh, another thing to try I forgot to mention (for
> Keith too) would be to
> run an UP kernel on the same hardware and see if the
> problem disappears.
> It would be nice if we can at least assert that SMP
> is one triggering
> factor.


I'll try both of these over the next few days.

 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Jean Delvare]

Hi Keith,

> > Keith, is it an ICH7 on your system too, or another
> > incarnation?
> (...)
> 00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus
> Controller (rev 02)

OK, that's an ICH5, so it's a different model. The ICH5 is out there
since quite some times now, we probably would know if the i2c-i801
driver didn't support it properly, including on SMP.

The pretty much rules out the i2c-i801 driver guilt IMHO, on its own at
least.

>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          XX XX XX XX XX 08 XX XX XX XX XX XX XX
> 10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX UU XX
> 30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
> 40: XX XX XX XX 44 XX XX XX XX XX XX XX XX XX XX XX
> 50: 50 51 52 53 XX XX XX XX XX XX XX XX XX XX XX XX
> 60: XX 61 XX XX 64 XX XX XX XX 69 XX XX XX XX XX XX
> 70: XX XX XX XX XX XX XX XX

I am really curious what the device at 0x64 can be. We don't know of any
device living at that address.

--
Jean Delvare

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Henrique de Moraes Holschuh]

On Wed, 23 Nov 2005, Keith wrote:
> http://valaran.com/~kw/lms/dmidecode.txt

Thanks.  It doesn't help much, but at least I am sure it is not a board I've
come across before.

I have a board here with a 80875P and a ADM1027 from Intel. We shall see in
about 5 days if 2.6.14.3 + lm-sensors works fine or not in another testcase
(mine).  2.6.13 sure does work right.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Henrique de Moraes Holschuh]

On Wed, 23 Nov 2005, Jean Delvare wrote:
> driver didn't support it properly, including on SMP.

I use a 80875P+lm85 under SMT (using a SMP kernel) all the time, and
stress-test it a lot. If 2.6.8-2.6.13 had any easy-to-hit problems with the
SMBus i2c driver for the 80875P, I'd have hit it.

> The pretty much rules out the i2c-i801 driver guilt IMHO, on its own at
> least.

Yeah, it would have to be a corner case, or something else equally rare.

> > 60: XX 61 XX XX 64 XX XX XX XX 69 XX XX XX XX XX XX
> > 70: XX XX XX XX XX XX XX XX
> 
> I am really curious what the device at 0x64 can be. We don't know of any
> device living at that address.

And that 0x61? What would be that one?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Jean Delvare]

Hi Henrique,

> > > 60: XX 61 XX XX 64 XX XX XX XX 69 XX XX XX XX XX XX
> > > 70: XX XX XX XX XX XX XX XX
> > 
> > I am really curious what the device at 0x64 can be. We don't know of any
> > device living at that address.
> 
> And that 0x61? What would be that one?

It's tagged "SMBus Device Default Address" in the SMBus 2.0
specification. It seems to be part of the address resolution protocol
together with 0x08 (Host Address) and maybe 0x44 (not mentionned in the
specification but almost always seen on SMBus 2.0 busses.)

I'd guess that a responsive 0x61 address means that at least one device
on the bus is waiting to be given an address, but actually I don't know
much about SMBus ARP and we don't support it at the moment. There is an
experimental driver for 2.4 (smbus-arp) but it's more or less
abandonned. I wish I had an SMBus 2.0 system myself to experiment with,
but unfortunately even the most recent systems I have don't support
SMBus 2.0.

-- 
Jean Delvare

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Henrique de Moraes Holschuh]

On Wed, 23 Nov 2005, Jean Delvare wrote:
> abandonned. I wish I had an SMBus 2.0 system myself to experiment with,
> but unfortunately even the most recent systems I have don't support
> SMBus 2.0.

Well, I suppose this means there is a device in that bus doing it, because I
have the same SMBus controller and there is no such 0x61 (neither is there a
0x64) device in the scan report.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Mark M. Hoffman]

Hello:

* Henrique de Moraes Holschuh <hmh@debian.org> [2005-11-23 17:02:33 -0200]:
> On Wed, 23 Nov 2005, Jean Delvare wrote:
> > driver didn't support it properly, including on SMP.
> 
> I use a 80875P+lm85 under SMT (using a SMP kernel) all the time, and
> stress-test it a lot. If 2.6.8-2.6.13 had any easy-to-hit problems with the
> SMBus i2c driver for the 80875P, I'd have hit it.

I also have an i875 SMT/SMP; I've never seen 'sensors -s' hang like that
either.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Mark M. Hoffman]

Hello:

* Henrique de Moraes Holschuh <hmh@debian.org> [2005-11-23 23:57:57 -0200]:
> On Wed, 23 Nov 2005, Jean Delvare wrote:
> > abandonned. I wish I had an SMBus 2.0 system myself to experiment with,
> > but unfortunately even the most recent systems I have don't support
> > SMBus 2.0.
> 
> Well, I suppose this means there is a device in that bus doing it, because I

Correct.

> have the same SMBus controller and there is no such 0x61 (neither is there a
> 0x64) device in the scan report.

If a device supports SMBus 2.0, it will answer on 0x61.  In fact, there may
be *multiple* devices answering on 0x61... which is perfectly normal, until
the host assigns them all individual addresses.

But as was mentioned, that is not supported in Linux at the moment.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Rudolf Marek]

Hello all,

I have a theory that changing limit values will assert SMI interrupt and SMI code will hang the machine.
Maybe the interrupt is raised via SMBALERT line which can be disabled in the i2c-i801.c driver.

Eventualy i think if we switch the interrupt generation to IRQ9 so inux should report
"IRQ9 nobody cared" instead of crarsh ... if I'm correct with the SMI assumption.

you can try to:
setpci  -s 0:1f.3 40.b=1

This will set the SMB routing interrupt to IRQ9 (or some other but not on SMI)

and then repeat with sensors -s
This is a bit dangerous so please do it with filesystems mouted RO.

If you get instead of crash no crash and/or some message in dmesg we have won :)

Ruik

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi Jean,

On Wed, Nov 23, 2005 at 03:51:57PM +0100, Jean Delvare wrote:
> On 2005-11-23, Daniel Nilsson wrote:
> > (...) Should I attempt
> > to write arbitrary values to all writeable files under
> > /sys/bus/i2c/devices/0-002c/ ?
> 
> Yes, one at a time.
> 
> I would start by writing safe values to the limit files: 0 to min voltage
> limits, 10000 to max voltage limits (the driver will automatically trim
> down to the max possible limit), 100000 to max temperature limits,
> etc... The idea is to find out whether the write transactions themselves
> are causing problems (unlikely) or if the problem is triggered by an
> alarm condition which results from setting some limits too tight. If the
> safe writes seem to work OK, try more dangerous ones and see when it
> breaks.

Ok, I've tried this manually and can't reproduce the problem. As I
mentioned in my other e-mail I will attempt to script in order to try
more combinations unless someone has any better suggestions.

> I seem to understand that "sensors -s" does not always hang. This will
> probably make the investigation harder. I admit I don't have much idea
> what we are trying to demonstrate at this point, just trying to gather
> enough data to have better ideas.

Correct, it does not always hang.

> If you could try an older kernel (for example 2.6.13.4) and see if you
> have the problem there too, that would be interesting. Just because the
> i2c-i801 driver didn't change doesn't mean that nothing in the kernel
> did change. If the monitoring chip is generating some hardware interrupt
> on alarm conditions, the i2c-i801 driver may not be involved at all.
> 
> Oh, another thing to try I forgot to mention (for Keith too) would be to
> run an UP kernel on the same hardware and see if the problem disappears.
> It would be nice if we can at least assert that SMP is one triggering
> factor.

Yes, I can try both of these once I'm able to reproduce :-)


> No, the IT8712F is essentially a Super-I/O chip with a flash interface
> and some legacy I/O functions (serial ports, floppy disk drive
> controller etc...) which happens to incorporate hardware monitoring
> functions. But the presence of a Winbond W83792D chip and the totally
> bogus values you get from the IT8712F chip make it clear that the
> motherboard manufacturer decided to add a dedicated chip for hardware
> monitoring rather than to use the IT8712F features. Just don't load the
> it87 driver at all.
> 
> Can you please just provide the output of "isadump 0x295 0x296" to rule
> out the possibility that the IT8712F chips was connected to the SMBus
> with the same address the W83792D chip uses? Unlikely, but you never
> know...

Sure, here it is:

isadump 0x295 0x296
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x295 and data register 0x296.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 19 10 ff 00 00 00 00 00 00 00 00 5b 00 ff ff 00
10: ff ff ff 37 b0 01 01 00 ff ff 00 ff ff ff ff ff
20: ff ff ff ff ff ff ff ff c7 80 80 80 ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff ff ff ff ff 2d ff ff ff ff ff ff ff
50: 00 00 7f 7f 7f ff 56 56 90 56 fe 12 00 00 00 00
60: 7f 7f 7f 00 00 7f ff ff 7f 7f 7f 00 00 7f ff ff
70: 7f 7f 7f 00 00 7f ff ff ff ff ff ff ff ff ff ff
80: 00 00 00 00 ff ff ff ff 40 40 ff ff ff ff ff ff
90: 7f 7f 7f 00 00 7f ff ff 7f 7f 7f 00 00 7f ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff


-- 
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Jean Delvare]

Hi Daniel,

> > Can you please just provide the output of "isadump 0x295 0x296" to rule
> > out the possibility that the IT8712F chips was connected to the SMBus
> > with the same address the W83792D chip uses? Unlikely, but you never
> > know...
> 
> Sure, here it is:
> 
> isadump 0x295 0x296
> WARNING! Running this program can cause system crashes, data loss and worse!
> I will probe address register 0x295 and data register 0x296.
> Continue? [Y/n]
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00: 19 10 ff 00 00 00 00 00 00 00 00 5b 00 ff ff 00
> 10: ff ff ff 37 b0 01 01 00 ff ff 00 ff ff ff ff ff
> 20: ff ff ff ff ff ff ff ff c7 80 80 80 ff ff ff ff
> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> 40: ff ff ff ff ff ff ff ff 2d ff ff ff ff ff ff ff

It would show at 0x2d, so it cannot conflict with your Winbond chip
(which is at 0x2c).

Anyway, I'm not even sure recent IT8712F chips really have an SMBus
interface. Later datasheets don't mention it anymore. We'll probably
drop SMBus interface support from the it87 driver at some point in the
future. ISA access is faster and always works (or can be made to work.)

Thanks,
-- 
Jean Delvare

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Jean Delvare]

Hi Rudolf, Daniel,

On 2005-11-28, Rudolf Marek wrote:
> (...)Please can you provide the dump after cold boot and BEFORE loading
> the w83792d driver?
>
> i2cdump 0 0x2c

That's a very good idea, I guess we should have asked for that earlier.
This will let us check how the W83792D chip is configured on your board.
Let's just hope that the BIOS did initialize it properly.

> You may extend this from:
> 
> +	if ( val1 & 0x04 )
> +		device_create_file_fan(new_client, 7);
>
> add:
>
> - 	device_create_file_fan(new_client, 6);
> +	if ( val1 & 0x40 )
> +		device_create_file_fan(new_client, 6);
>
> Because fan6 and fan7 - mean their pins are programmable so correct would
> be to create their files when they actual outputs are really used for
> fans...

Same is true for fan4 and fan5 according to the datasheet, they can be
used as GPIO pins. Register to check is 0x1A, mask 0x40 for fan4 and
0x20 for fan5.

It would be great to have a patch for the w83792d driver in Linux 2.6
which fixes all these issues, so that Daniel can at least test a driver
with no known issuee. Yuan, sorry we are lagging behind about the
w83792d driver. I was taking care about the w83627hf because I'm more
familiar with it, and thought Rudolf would take care of the w83792d but
he's busy with his master thesis these days. If you can resubmit a
patch including all your previous fixes plus the fan4, fan5 and fan6
checks, I'll make sure to review it quickly. Not sure I'll be able to
get it into Linux 2.6.15 but we can try.

The "sensors" program will need to be modified not to complain about
missing fan4, fan5, fan6 and fan7 entries, as the Linux 2.6 driver will
no more always create them. This change should be trivial. Can anyone
send a patch?

Daniel, we are progressing but I still have no clear idea about what
exactly is causing the hang. One interesting test would be to try direct
SMBus writes without using the w83792d driver. If you can reproduce the
hang, then the w83792d driver is not faulty. If you cannot, they we
probably have a bug in the w83792d driver. This wouldn't be all that
surprising, the driver is relatively new and the chip is quite complex.

You can use the i2cset program to write to the W83792D chip directly. You
can try using the following commands in your script, without loading the
w83792d driver. Let us know if it hangs of not.

i2cset -y 0 0x2c 0x2b 0xff # in0_max
i2cset -y 0 0x2c 0x2c 0x00 # in0_min
i2cset -y 0 0x2c 0x2d 0xff # in1_max
i2cset -y 0 0x2c 0x2e 0x00 # in1_min
i2cset -y 0 0x2c 0x2f 0xff # in2_max
i2cset -y 0 0x2c 0x30 0x00 # in2_min
i2cset -y 0 0x2c 0x31 0xff # in3_max
i2cset -y 0 0x2c 0x32 0x00 # in3_min
i2cset -y 0 0x2c 0x33 0xff # in4_max
i2cset -y 0 0x2c 0x34 0x00 # in4_min
i2cset -y 0 0x2c 0x35 0xff # in5_max
i2cset -y 0 0x2c 0x36 0x00 # in5_min
i2cset -y 0 0x2c 0x37 0xff # in6_max
i2cset -y 0 0x2c 0x38 0x00 # in6_min
i2cset -y 0 0x2c 0xb4 0xff # in7_max
i2cset -y 0 0x2c 0xb5 0x00 # in7_min
i2cset -y 0 0x2c 0xb6 0xff # in8_max
i2cset -y 0 0x2c 0xb7 0x00 # in8_min
i2cset -y 0 0x2c 0x39 0x7f # temp1_max
i2cset -y 0 0x2c 0x3a 0x00 # temp1_min
i2cset -y 0 0x2c 0xc3 0x7c # temp2_max_hyst
i2cset -y 0 0x2c 0xc5 0x7f # temp2_max
i2cset -y 0 0x2c 0xcb 0x7c # temp3_max_hyst
i2cset -y 0 0x2c 0xcd 0x7f # temp3_max
i2cset -y 0 0x2c 0x3b 0xff # fan1_min
i2cset -y 0 0x2c 0x3c 0xff # fan2_min
i2cset -y 0 0x2c 0x3d 0xff # fan3_min
i2cset -y 0 0x2c 0xbb 0xff # fan4_min
i2cset -y 0 0x2c 0xbc 0xff # fan5_min
i2cset -y 0 0x2c 0xbd 0xff # fan6_min
i2cset -y 0 0x2c 0xbf 0xff # fan7_min

Thanks,
--
Jean Delvare

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi All,

Thanks for the help to far! I have some new data to show...

On Mon, Nov 28, 2005 at 10:40:44AM +0100, Rudolf Marek wrote:
> > I tried executing 'setpci  -s 0:1f.3 40.b=1', that command completed
> > without complaining but I didn't see any difference in the
> > behaviour. But I don't know how to verify that the setpci command
> > actually did what you were expecting it to do.
> 
> This just disables the smbalert signal. Maybe the output from a chip is routed
> to other pin. Please can you provide the dump after cold boot and BEFORE loading
> the w83792d driver?
> 
> i2cdump 0 0x2c

Ok, after a cold boot and before loading the driver:

oden:~# i2cdump 0 0x2c
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x2c, mode byte
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 bf 00 00 63 00 ff 04 00 f5 00 8f 80    ..dd?..c..?.?.??
20: d3 d4 b9 b8 b8 b9 cd 17 41 ff 75 ff 00 96 64 d7    ????????A.u..?d?
30: af d9 b1 d9 b1 d7 af ff 00 25 00 f0 f0 f0 bf bf    ???????..%.?????
40: 03 00 00 00 70 ff ff bb 2c 13 40 c3 51 ff 80 5c    ?...p..?,?@?Q.?\
50: ff ff ff ff ff ff ff ff 7a 40 ff bb bb c1 05 7f    ........z@.?????
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 81 8f 81 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
90: 00 00 00 81 8f ff 00 00 11 ff 3c 00 0f 01 01 ff    ...??...?.<.???.
a0: 81 81 81 8f 8f 8f 8f ff 3e 42 00 e0 ff ff 00 00    ???????.>B.?....
b0: d3 ca ff ff ff 00 e2 b9 ff ff ff f0 f0 f0 00 ff    ??....??...???..
c0: 28 80 02 39 00 3c 00 ff 2e 80 00 5d 00 60 00 ff    (??9.<...?.].`..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
f0: ff ff 00 ff 00 01 00 00 ff 02 ff 00 00 00 00 ff    .....?...?......

> 
> We have a patch from Yuan, I hope it is not malformed by my stupid mail client.
> [snip]
> Because fan6 and fan7 - mean their pins are programmable so correct
> would be to create their files when they actual outputs are really
> used for fans...

I applied the patch, the only real difference I can see is that the
/sys/bus/i2c/devices/0-002c/fan7_* nodes are no longer created. But
the system hangs just the same anyway, the only difference is that no
write to fan7_* limits is happening:

Setting /sys/bus/i2c/devices/0-002c/in8_min to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in7_min to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in6_min to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in5_min to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in4_min to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in3_min to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in2_min to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in1_min to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in0_min to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in8_max to 10000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in7_max to 10000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in6_max to 10000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in5_max to 10000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in4_max to 10000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in3_max to 10000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in2_max to 10000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in1_max to 10000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/in0_max to 10000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/temp3_max to 100000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/temp2_max to 100000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/temp1_max to 100000 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/temp3_max_hyst to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/temp2_max_hyst to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/temp1_max_hyst to 0 , sleeping 1s...ok.
Setting /sys/bus/i2c/devices/0-002c/fan6_min to 0 , <system hangs>

Regards
-- 
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi All,

On Mon, Nov 28, 2005 at 01:31:34PM +0100, Jean Delvare wrote:
> > - 	device_create_file_fan(new_client, 6);
> > +	if ( val1 & 0x40 )
> > +		device_create_file_fan(new_client, 6);
> >
> > Because fan6 and fan7 - mean their pins are programmable so correct would
> > be to create their files when they actual outputs are really used for
> > fans...
> 
> Same is true for fan4 and fan5 according to the datasheet, they can be
> used as GPIO pins. Register to check is 0x1A, mask 0x40 for fan4 and
> 0x20 for fan5.

This is the complete patch I've been using against what is in kernel
2.6.14, it should include the previous changes as well as the above
checks for fan4 and fan5 (if I understood the datasheet and your
comments correctly):

--- w83792d.c.orig	2005-11-28 19:15:13.000000000 +0100
+++ w83792d.c	2005-11-28 19:16:05.000000000 +0100
@@ -193,6 +193,7 @@
 	  0xE2 }	/* (bit3-0) SmartFanII: Fan3 Level 3 */
 };
 
+#define W83792D_REG_GPIO		0x1A
 #define W83792D_REG_CONFIG		0x40
 #define W83792D_REG_VID_FANDIV		0x47
 #define W83792D_REG_CHIPID		0x49
@@ -257,7 +258,7 @@
 {
 	int i;
 	val = SENSORS_LIMIT(val, 1, 128) >> 1;
-	for (i = 0; i < 6; i++) {
+	for (i = 0; i < 7; i++) {
 		if (val = 0)
 			break;
 		val >>= 1;
@@ -1284,9 +1285,9 @@
 	w83792d_init_client(new_client);
 
 	/* A few vars need to be filled upon startup */
-	for (i = 1; i <= 7; i++) {
-		data->fan_min[i - 1] = w83792d_read_value(new_client,
-					W83792D_REG_FAN_MIN[i]);
+	for (i = 0; i < 7; i++) {
+	  data->fan_min[i] = w83792d_read_value(new_client,
+						W83792D_REG_FAN_MIN[i]);
 	}
 
 	/* Register sysfs hooks */
@@ -1308,10 +1309,20 @@
 	device_create_file_fan(new_client, 1);
 	device_create_file_fan(new_client, 2);
 	device_create_file_fan(new_client, 3);
-	device_create_file_fan(new_client, 4);
-	device_create_file_fan(new_client, 5);
-	device_create_file_fan(new_client, 6);
-	device_create_file_fan(new_client, 7);
+
+	/* Read GPIO register to check if inputs for fan 4,5 are used as GPIO */
+	val1 = w83792d_read_value(new_client, W83792D_REG_GPIO);
+	if (!( val1 & 0x40 ))
+	  device_create_file_fan(new_client, 4);
+	if (!( val1 & 0x20 ))
+	  device_create_file_fan(new_client, 5);
+
+	val1 = w83792d_read_value(new_client, W83792D_REG_PIN);
+	if ( val1 & 0x40 )
+	  device_create_file_fan(new_client, 6);
+	if ( val1 & 0x04 )
+	  device_create_file_fan(new_client, 7);
+
 
 	device_create_file_temp1(new_client);		/* Temp1 */
 	device_create_file_temp_add(new_client, 2);	/* Temp2 */

> Daniel, we are progressing but I still have no clear idea about what
> exactly is causing the hang. One interesting test would be to try direct
> SMBus writes without using the w83792d driver. If you can reproduce the
> hang, then the w83792d driver is not faulty. If you cannot, they we
> probably have a bug in the w83792d driver. This wouldn't be all that
> surprising, the driver is relatively new and the chip is quite complex.
> 
> You can use the i2cset program to write to the W83792D chip directly. You
> can try using the following commands in your script, without loading the
> w83792d driver. Let us know if it hangs of not.
> 
> i2cset -y 0 0x2c 0x2b 0xff # in0_max
> i2cset -y 0 0x2c 0x2c 0x00 # in0_min
> i2cset -y 0 0x2c 0x2d 0xff # in1_max
> i2cset -y 0 0x2c 0x2e 0x00 # in1_min
> i2cset -y 0 0x2c 0x2f 0xff # in2_max
> i2cset -y 0 0x2c 0x30 0x00 # in2_min
> i2cset -y 0 0x2c 0x31 0xff # in3_max
> i2cset -y 0 0x2c 0x32 0x00 # in3_min
> i2cset -y 0 0x2c 0x33 0xff # in4_max
> i2cset -y 0 0x2c 0x34 0x00 # in4_min
> i2cset -y 0 0x2c 0x35 0xff # in5_max
> i2cset -y 0 0x2c 0x36 0x00 # in5_min
> i2cset -y 0 0x2c 0x37 0xff # in6_max
> i2cset -y 0 0x2c 0x38 0x00 # in6_min
> i2cset -y 0 0x2c 0xb4 0xff # in7_max
> i2cset -y 0 0x2c 0xb5 0x00 # in7_min
> i2cset -y 0 0x2c 0xb6 0xff # in8_max
> i2cset -y 0 0x2c 0xb7 0x00 # in8_min
> i2cset -y 0 0x2c 0x39 0x7f # temp1_max
> i2cset -y 0 0x2c 0x3a 0x00 # temp1_min
> i2cset -y 0 0x2c 0xc3 0x7c # temp2_max_hyst
> i2cset -y 0 0x2c 0xc5 0x7f # temp2_max
> i2cset -y 0 0x2c 0xcb 0x7c # temp3_max_hyst
> i2cset -y 0 0x2c 0xcd 0x7f # temp3_max
> i2cset -y 0 0x2c 0x3b 0xff # fan1_min
> i2cset -y 0 0x2c 0x3c 0xff # fan2_min
> i2cset -y 0 0x2c 0x3d 0xff # fan3_min
> i2cset -y 0 0x2c 0xbb 0xff # fan4_min
> i2cset -y 0 0x2c 0xbc 0xff # fan5_min
> i2cset -y 0 0x2c 0xbd 0xff # fan6_min
> i2cset -y 0 0x2c 0xbf 0xff # fan7_min

[snip]

So I tried the direct SMBus writes without even loading the w83792d
driver after a reboot. The machine still hangs... I don't get the hang
at the exact same place, but the order in which you have the writes
suggested is slighly different then my own scripts so that probably
doesn't say much.

This is the output of the script:

oden:~# ./set_safe_direct.sh
+ i2cset -y 0 0x2c 0x2b 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x2c 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0x2d 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x2e 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0x2f 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x30 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0x31 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x32 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0x33 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x34 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0x35 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x36 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0x37 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x38 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0xb4 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0xb5 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0xb6 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0xb7 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0x39 0x7f
No size specified (using byte-data access)
Value 0x7f written, readback matched
+ i2cset -y 0 0x2c 0x3a 0x00
No size specified (using byte-data access)
Value 0x00 written, readback matched
+ i2cset -y 0 0x2c 0xc3 0x7c
No size specified (using byte-data access)
Value 0x7c written, readback matched
+ i2cset -y 0 0x2c 0xc5 0x7f
No size specified (using byte-data access)
Value 0x7f written, readback matched
+ i2cset -y 0 0x2c 0xcb 0x7c
No size specified (using byte-data access)
Value 0x7c written, readback matched
+ i2cset -y 0 0x2c 0xcd 0x7f
No size specified (using byte-data access)
Value 0x7f written, readback matched
+ i2cset -y 0 0x2c 0x3b 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x3c 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x3d 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0xbb 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0xbc 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0xbd 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0xbf 0xff
No size specified (using byte-data access)
<here the machine hangs>

I guess we can rule out the w83792d driver since that one isn't even
loaded at this point.

Best regards
-- 
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Jean Delvare]

Hi Daniel,

On 2005-11-28, Daniel Nilsson wrote:
> This is the complete patch I've been using against what is in kernel
> 2.6.14, it should include the previous changes as well as the above
> checks for fan4 and fan5 (if I understood the datasheet and your
> comments correctly):

Yes that's correct and mostly similar to what Yuan posted. I'll apply
Yuan's version which is better shaped.

> So I tried the direct SMBus writes without even loading the w83792d
> driver after a reboot. The machine still hangs... I don't get the hang
> at the exact same place, but the order in which you have the writes
> suggested is slighly different then my own scripts so that probably
> doesn't say much.
> (...)
> + i2cset -y 0 0x2c 0xbd 0xff
> No size specified (using byte-data access)
> Value 0xff written, readback matched
> + i2cset -y 0 0x2c 0xbf 0xff
> No size specified (using byte-data access)
> <here the machine hangs>
>
> I guess we can rule out the w83792d driver since that one isn't even
> loaded at this point.

Yup, that was pretty much the aim of this test.

Now... I have to admit I am out of ideas at this point. Maybe you can try
enabling kernel debugging (Detect Soft Lockups, Spinlock debugging...)
and see if something shows. But that's a blind shot.

It would be interesting to know if the W83792D chip on your motherboard
is only wired to the Intel 82801 chip via SMBus, or if it is also wired
to the CPU or anything else, and how. But I guess you don't have any
wiring diagram? These are rather hard to find unless you have very good
relations with the board manufacturer.

What really puzzles me is that the values we are writing to the registers
are NOT supposed to trigger any kind of alarm. The i2cset command which
caused the trouble above is writing the same value the target register
already had. I really can't see how anything is supposed to happen as a
result :(

--
Jean Delvare

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Rudolf Marek]

Hello all,


> Now... I have to admit I am out of ideas at this point. Maybe you can try
> enabling kernel debugging (Detect Soft Lockups, Spinlock debugging...)
> and see if something shows. But that's a blind shot.

Never give up, never surrender :) Lets focus on SMI. This should disable
the SMI from this chip. So we can at least eliminate this source.
OVT# is also unused so this should point if you have HW or SW (bus driver)
problem.

Please can you try with this sequence, which is same except of new first
line.

Quoting Jean:

You can use the i2cset program to write to the W83792D chip directly. You
can try using the following commands in your script, without loading the
w83792d driver. Let us know if it hangs of not.

i2cset -y 0 0x2c 0x40 0x1  # DISABLE SMI
i2cset -y 0 0x2c 0x2b 0xff # in0_max
i2cset -y 0 0x2c 0x2c 0x00 # in0_min
i2cset -y 0 0x2c 0x2d 0xff # in1_max
i2cset -y 0 0x2c 0x2e 0x00 # in1_min
i2cset -y 0 0x2c 0x2f 0xff # in2_max
i2cset -y 0 0x2c 0x30 0x00 # in2_min
i2cset -y 0 0x2c 0x31 0xff # in3_max
i2cset -y 0 0x2c 0x32 0x00 # in3_min
i2cset -y 0 0x2c 0x33 0xff # in4_max
i2cset -y 0 0x2c 0x34 0x00 # in4_min
i2cset -y 0 0x2c 0x35 0xff # in5_max
i2cset -y 0 0x2c 0x36 0x00 # in5_min
i2cset -y 0 0x2c 0x37 0xff # in6_max
i2cset -y 0 0x2c 0x38 0x00 # in6_min
i2cset -y 0 0x2c 0xb4 0xff # in7_max
i2cset -y 0 0x2c 0xb5 0x00 # in7_min
i2cset -y 0 0x2c 0xb6 0xff # in8_max
i2cset -y 0 0x2c 0xb7 0x00 # in8_min
i2cset -y 0 0x2c 0x39 0x7f # temp1_max
i2cset -y 0 0x2c 0x3a 0x00 # temp1_min
i2cset -y 0 0x2c 0xc3 0x7c # temp2_max_hyst
i2cset -y 0 0x2c 0xc5 0x7f # temp2_max
i2cset -y 0 0x2c 0xcb 0x7c # temp3_max_hyst
i2cset -y 0 0x2c 0xcd 0x7f # temp3_max
i2cset -y 0 0x2c 0x3b 0xff # fan1_min
i2cset -y 0 0x2c 0x3c 0xff # fan2_min
i2cset -y 0 0x2c 0x3d 0xff # fan3_min
i2cset -y 0 0x2c 0xbb 0xff # fan4_min
i2cset -y 0 0x2c 0xbc 0xff # fan5_min
i2cset -y 0 0x2c 0xbd 0xff # fan6_min
i2cset -y 0 0x2c 0xbf 0xff # fan7_min

This should completly disable the SMI.	Lets see how it works :)

Regards
Rudolf

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi Rudolf,

On Wed, Nov 30, 2005 at 11:11:00PM +0100, Rudolf Marek wrote:
> Never give up, never surrender :) Lets focus on SMI. This should disable
> the SMI from this chip. So we can at least eliminate this source.
> OVT# is also unused so this should point if you have HW or SW (bus driver)
> problem.

That's the spirit :-)

> Please can you try with this sequence, which is same except of new first
> line.
> 
> Quoting Jean:
> 
> You can use the i2cset program to write to the W83792D chip directly. You
> can try using the following commands in your script, without loading the
> w83792d driver. Let us know if it hangs of not.
> 
> i2cset -y 0 0x2c 0x40 0x1  # DISABLE SMI
> i2cset -y 0 0x2c 0x2b 0xff # in0_max
> ... 
> This should completly disable the SMI.	Lets see how it works :)

Ok, I've tried this and a few other things. First of all, I can't shut
off SMI which seems really odd.

The first time a ran this sequence I got this result and the machine
did not hang:

oden:~# ./set_safe_direct_wo_smi.sh
+ i2cset -y 0 0x2c 0x40 0x1
No size specified (using byte-data access)
Warning - data mismatch - wrote 0x01, read back 0x06
+ i2cset -y 0 0x2c 0x2b 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x2c 0x00
[all the remaining writes succeeded]

The second time I got this result and the machine did still not hang:

oden:~# ./set_safe_direct_wo_smi.sh
+ i2cset -y 0 0x2c 0x40 0x1
No size specified (using byte-data access)
Warning - data mismatch - wrote 0x01, read back 0x03
+ i2cset -y 0 0x2c 0x2b 0xff
No size specified (using byte-data access)
Value 0xff written, readback matched
+ i2cset -y 0 0x2c 0x2c 0x00
[all the remaining writes succeeded]

Finally the third time the machine just got this far and then hung:

oden:~# ./set_safe_direct_wo_smi.sh
+ i2cset -y 0 0x2c 0x40 0x1
No size specified (using byte-data access)


So according to the datasheet writing 0x01 to this register should
shut off EN_SMI, but that doesn't seem to work since the readback
still shows 0x03 (should be 0x01, right?). I've been trying all sorts
of things to disable this EN_SMI bit but I can't seem to do it.

For example, writing 0x80 should re-init the whole chip:

oden:~# i2cset -y 0 0x2c 0x40 0x80
No size specified (using byte-data access)
Warning - data mismatch - wrote 0x80, read back 0x03

But that still has the EN_SMI bit set??? It shouldn't according to my
datasheet at least, that bit should be reset to '0'...

I've also played around in the BIOS for a while, there seems to be
some king of "MiniBMC" functionality in the BIOS that is logging
overtemp events someplace. That log was filled with events since BIOS
enabled all fan monitors by default. I've shut off all those monitors
and even the whole MiniBMC funtionality but I still get the same hangs
when writing the sensor limits. I honestly don't know if there is some
other device on this bus that is communicating with the w82792d chip
to read these levels as well that might be interfering here. Since
this MiniBMC thing might be of interest I actually wrote Gigabyte
support about this whole issue, I'm keeping my fingers crossed but I
doubt that the question will reach the appropriate people at Gigabyte.

One more thing I observed;

oden:~# i2cdump -y 0 0x2c
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 bf 00 00 63 00 ff 00 00 f5 00 8f 80    ..dd?..c....?.??
20: d3 d4 b9 b9 b8 b8 cd 15 ff ff ff ff 00 96 64 d7    ????????.....?d?
30: af d9 b1 d9 b1 d7 af ff 00 25 00 f0 f0 f0 2f 39    ???????..%.???/9
40: 03 00 00 00 00 ff ff 11 2c 13 40 c3 51 ff 80 5c    ?......?,?@?Q.?\
50: ff ff ff ff ff ff ff ff 7a 60 ff 11 11 c1 05 7f    ........z`.?????
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 01 8f 01 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
90: 00 00 00 01 8f ff 00 00 11 ff 3c 00 00 01 01 ff    ...??...?.<..??.
a0: 01 01 01 8f 8f 8f 8f ff 3e e2 00 e0 ff ff 00 00    ???????.>?.?....
b0: d3 cb ff ff ff 00 e2 b9 ff ff ff f0 f0 f0 ff ff    ??....??...???..
c0: f2 80 02 39 00 3c 00 ff 2c 00 00 5d 00 60 00 ff    ???9.<..,..].`..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
f0: ff ff 80 ff 00 01 00 00 ff 02 ff 00 00 00 00 ff    ..?..?...?......

Look at index 49, it says "13". According to the datasheet I have a
revision C chip should have "12". Is this a newer chip then what the
datasheet covers? In this case there might be some confusion on
disabling SMI...

Yuan, could you offer some help and guidance as to why the EN_SMI bit
can't be turned off and what this revision "13" chip is? My
motherboard is a Gigabyte GA-4MXSV by the way.

Regards
-- 
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Rudolf Marek]

Hello,

Now I'm suspecting the  miniBMC is watching the chip ;)

Please have you some CD with windows health utillity?
Can you share output of sensors-detect with us?
(please use CVS version of it, you dont need to install just run ./sensors-detect)

Also can you confirm if you have onboard the PC87431 chip?

Thanks,

Regards
Rudolf

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

On Fri, Dec 02, 2005 at 09:57:51AM +0100, Rudolf Marek wrote:
> Hello,
> 
> Now I'm suspecting the  miniBMC is watching the chip ;)

Hmm, I thought so for a while as well. Now I'm not that sure any
longer...

> Please have you some CD with windows health utillity?

Sorry, no. I actually don't even have Windows on this machine at
all... I suppose I could add another drive to the system and install
Windows just for this purpose, but that it quite the task to I'd
rather avoid it unless you know this will tell us something that is
impossible to get some other way...

> Can you share output of sensors-detect with us?
> (please use CVS version of it, you dont need to install just run ./sensors-detect)
> 

Sure, that's a lot easier...

# sensors-detect revision 1.404 (2005/11/26 11:28:44)

This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.

It is generally safe and recommended to accept the default answers to all
questions, unless you know what you're doing.

 We can start with probing for (PCI) I2C or SMBus adapters.
 You do not need any special privileges for this.
 Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-i801' for device 00:1f.3: Intel ICH7
Probe succesfully concluded.

We will now try to load each adapter module in turn.
Module `i2c-i801' already loaded.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.

 To continue, we need module `i2c-dev' to be loaded.
 If it is built-in into your kernel, you can safely skip this.
i2c-dev is already loaded.

 We are now going to do the adapter probings. Some adapters may hang halfway
 through; we can't really help that. Also, some chips will be double detected;
 we choose the one with the highest confidence value in that case.
 If you found that the adapter hung after probing a certain address, you can
 specify that address to remain unprobed. That often
 includes address 0x69 (clock chip).

Next adapter: SMBus I801 adapter at 3080
Do you want to scan it? (YES/no/selectively):
Client found at address 0x08
Client found at address 0x2c
Probing for `Myson MTP008'... Failed!
Probing for `National Semiconductor LM78'... Failed!
Probing for `National Semiconductor LM78-J'... Failed!
Probing for `National Semiconductor LM79'... Failed!
Probing for `National Semiconductor LM80'... Failed!
Probing for `National Semiconductor LM85 or LM96000'... Failed!
Probing for `Analog Devices ADM1027, ADT7460 or ADT7463'... Failed!
Probing for `SMSC EMC6D100, EMC6D101 or EMC6D102'... Failed!
Probing for `Analog Devices ADT7476'... Failed!
Probing for `National Semiconductor LM87'... Failed!
Probing for `National Semiconductor LM93'... Failed!
Probing for `Winbond W83781D'... Failed!
Probing for `Winbond W83782D'... Failed!
Probing for `Winbond W83791D'... Failed!
Probing for `Winbond W83792D'... Success!
    (confidence 7, driver `w83792d'), other addresses: 0x48 0x4c
Probing for `Winbond W83791SD'... Failed!
Probing for `Winbond W83627HF'... Failed!
Probing for `Winbond W83627EHF'... Failed!
Probing for `Asus AS99127F (rev.1)'... Failed!
Probing for `Asus AS99127F (rev.2)'... Failed!
Probing for `Asus ASB100 Bach'... Failed!
Probing for `Genesys Logic GL518SM Revision 0x00'... Failed!
Probing for `Genesys Logic GL518SM Revision 0x80'... Failed!
Probing for `Genesys Logic GL520SM'... Failed!
Probing for `Analog Devices ADM9240'... Failed!
Probing for `Dallas Semiconductor DS1780'... Failed!
Probing for `National Semiconductor LM81'... Failed!
Probing for `Analog Devices ADM1026'... Failed!
Probing for `Analog Devices ADM1025'... Failed!
Probing for `Philips NE1619'... Failed!
Probing for `Analog Devices ADM1024'... Failed!
Probing for `Analog Devices ADM1029'... Failed!
Probing for `Analog Devices ADM1030'... Failed!
Probing for `Analog Devices ADM1031'... Failed!
Probing for `Analog Devices ADM1022'... Failed!
Probing for `Texas Instruments THMC50'... Failed!
Probing for `ITE IT8712F'... Failed!
Probing for `ALi M5879'... Failed!
Probing for `SMSC LPC47M15x, LPC47M192 or LPC47M997'... Failed!
Client found at address 0x31
Client found at address 0x33
Client found at address 0x44
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Client found at address 0x48
Probing for `National Semiconductor LM75'... Failed!
Probing for `National Semiconductor LM77'... Failed!
Probing for `Dallas Semiconductor DS1621'... Failed!
Probing for `Maxim MAX6650/MAX6651'... Failed!
Probing for `National Semiconductor LM92'... Failed!
Probing for `National Semiconductor LM76'... Failed!
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Client found at address 0x4c
Probing for `National Semiconductor LM75'... Failed!
Probing for `Dallas Semiconductor DS1621'... Failed!
Probing for `Analog Devices ADM1021'... Failed!
Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
Probing for `Maxim MAX1617'... Failed!
Probing for `Maxim MAX1617A'... Failed!
Probing for `TI THMC10'... Failed!
Probing for `National Semiconductor LM84'... Failed!
Probing for `Genesys Logic GL523SM'... Failed!
Probing for `Onsemi MC1066'... Failed!
Probing for `Maxim MAX1619'... Failed!
Probing for `National Semiconductor LM82/LM83'... Failed!
Probing for `National Semiconductor LM90'... Failed!
Probing for `National Semiconductor LM89/LM99'... Failed!
Probing for `National Semiconductor LM86'... Failed!
Probing for `Analog Devices ADM1032'... Failed!
Probing for `Maxim MAX6657/MAX6658/MAX6659'... Failed!
Probing for `National Semiconductor LM63'... Failed!
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
Probing for `Analog Devices ADT7461'... Failed!
Client found at address 0x51
Probing for `SPD EEPROM'... Success!
    (confidence 8, driver `eeprom')
Client found at address 0x53
Probing for `SPD EEPROM'... Success!
    (confidence 8, driver `eeprom')
Client found at address 0x60
Client found at address 0x61
Probing for `SMBus 2.0 ARP-Capable Device'... Success!
    (confidence 1, driver `smbus-arp')
Client found at address 0x69

Some chips are also accessible through the ISA bus. ISA probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.

Do you want to scan the ISA bus? (YES/no):
Probing for `National Semiconductor LM78'
  Trying address 0x0290... Failed!
Probing for `National Semiconductor LM78-J'
  Trying address 0x0290... Failed!
Probing for `National Semiconductor LM79'
  Trying address 0x0290... Failed!
Probing for `Winbond W83781D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83782D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627HF'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627EHF'
  Trying address 0x0290... Failed!
Probing for `Winbond W83697HF'
  Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
  Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
  Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
  Trying general detect... Failed!
Probing for `ITE IT8712F'
  Trying address 0x0290... Success!
    (confidence 8, driver `it87')
Probing for `ITE IT8705F / SiS 950'
  Trying address 0x0290... Failed!
Probing for `IPMI BMC KCS'
  Trying address 0x0ca0... Failed!
Probing for `IPMI BMC SMIC'
  Trying address 0x0ca8... Failed!

Some Super I/O chips may also contain sensors. Super I/O probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.

Do you want to scan for Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
  Failed! (0x8712)
Probing for `ITE 8705F Super IO Sensors'
  Failed! (0x8712)
Probing for `ITE 8712F Super IO Sensors'
  Success... found at address 0x0290
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (skipping family)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
  Failed! (skipping family)

Do you want to scan for secondary Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
  Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (skipping family)
Probing for `Winbond W83627EHF/EHG Super IO Sensors'
  Failed! (skipping family)

 Now follows a summary of the probes I have just done.
 Just press ENTER to continue:

Driver `w83792d' (should be inserted):
  Detects correctly:
  * Bus `SMBus I801 adapter at 3080'
    Busdriver `i2c-i801', I2C address 0x2c (and 0x48 0x4c)
    Chip `Winbond W83792D' (confidence: 7)

Driver `eeprom' (should be inserted):
  Detects correctly:
  * Bus `SMBus I801 adapter at 3080'
    Busdriver `i2c-i801', I2C address 0x51
    Chip `SPD EEPROM' (confidence: 8)
  * Bus `SMBus I801 adapter at 3080'
    Busdriver `i2c-i801', I2C address 0x53
    Chip `SPD EEPROM' (confidence: 8)

Driver `smbus-arp' (should be inserted):
  Detects correctly:
  * Bus `SMBus I801 adapter at 3080'
    Busdriver `i2c-i801', I2C address 0x61
    Chip `SMBus 2.0 ARP-Capable Device' (confidence: 1)

Driver `it87' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0290 (Busdriver `i2c-isa')
    Chip `ITE 8712F Super IO Sensors' (confidence: 9)


 I will now generate the commands needed to load the I2C modules.
 Sometimes, a chip is available both through the ISA bus and an I2C bus.
 ISA bus access is faster, but you need to load an additional driver module
 for it. If you have the choice, do you want to use the ISA bus or the
 I2C/SMBus (ISA/smbus)?

To make the sensors modules behave correctly, add these lines to
/etc/modules.conf:

#----cut here----
# I2C module options
alias char-major-89 i2c-dev
#----cut here----

To load everything that is needed, add this to some /etc/rc* file:

#----cut here----
# I2C adapter drivers
modprobe i2c-i801
modprobe i2c-isa
# I2C chip drivers
modprobe w83792d
modprobe eeprom
# Warning: the required module smbus-arp is not currently installed on your system.
# For status of 2.6 kernel ports see http://secure.netroedge.com/~lm78/supported.html
# If driver is built-in to the kernel, or unavailable, comment out the following line.
modprobe smbus-arp
modprobe it87
# sleep 2 # optional
/usr/local/bin/sensors -s # recommended
#----cut here----

WARNING! If you have some things built into your kernel, the list above
will contain too many modules. Skip the appropriate ones! You really should
try these commands right now to make sure everything is working properly.
Monitoring programs won't work until it's done.

Do you want to generate /etc/sysconfig/lm_sensors? (yes/NO):


> Also can you confirm if you have onboard the PC87431 chip?

I've been looking, but I can't find such a chip... I actually don't
think that this mini BMC think is more then a software feature of the
BIOS that can read the sensor limits. But then again I may be wrong...

Here's a pointer to the manual:

http://us.giga-byte.com/Download/Download.asp?DownloadPath=/Server/FileList/Manual/4mxsv_1001.pdf

This is from the manual:

Hardware Monitor 

*Winbond 83792D controller

*Enhanced features with CPU Vcore, 1.5V reference, VCC3 (3.3V),
 VCC5V, +12V, 2.5V,VBAT3V, +5V SB, CPU Temperature, and
 System Temperature Values viewing by

*Support basic ASF remote transaction through CSA Bus with hardware
 circuit

BIOS 

*Phoenix BIOS on 8Mb flash RAM

*Software mini BMC

Note that second bullet under Hardware Monitor actually ends in
"by"... I don't know what this CSA bus thing is though?

I received an answer from Gigabyte, they told me to refer to the
system block diagram in the manual for the W83792D chip is connected
in my system. Well that's not very useful since the W82792D isn't even
on the system block diagram...

Thanks
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Rudolf Marek]

Hello Yuan,

Please can you help (and new datasheet would be nice too :) ?
I'm afraid that I cant move any further without your help.

Thanks
Regards
Rudolf

Daniel Nilsson wrote:
> Hi Rudolf,
> 
> On Wed, Nov 30, 2005 at 11:11:00PM +0100, Rudolf Marek wrote:
> 
>>Never give up, never surrender :) Lets focus on SMI. This should disable
>>the SMI from this chip. So we can at least eliminate this source.
>>OVT# is also unused so this should point if you have HW or SW (bus driver)
>>problem.
> 
> 
> That's the spirit :-)
> 
> 
>>Please can you try with this sequence, which is same except of new first
>>line.
>>
>>Quoting Jean:
>>
>>You can use the i2cset program to write to the W83792D chip directly. You
>>can try using the following commands in your script, without loading the
>>w83792d driver. Let us know if it hangs of not.
>>
>>i2cset -y 0 0x2c 0x40 0x1  # DISABLE SMI
>>i2cset -y 0 0x2c 0x2b 0xff # in0_max
>>... 
>>This should completly disable the SMI.	Lets see how it works :)
> 
> 
> Ok, I've tried this and a few other things. First of all, I can't shut
> off SMI which seems really odd.
> 
> The first time a ran this sequence I got this result and the machine
> did not hang:
> 
> oden:~# ./set_safe_direct_wo_smi.sh
> + i2cset -y 0 0x2c 0x40 0x1
> No size specified (using byte-data access)
> Warning - data mismatch - wrote 0x01, read back 0x06
> + i2cset -y 0 0x2c 0x2b 0xff
> No size specified (using byte-data access)
> Value 0xff written, readback matched
> + i2cset -y 0 0x2c 0x2c 0x00
> [all the remaining writes succeeded]
> 
> The second time I got this result and the machine did still not hang:
> 
> oden:~# ./set_safe_direct_wo_smi.sh
> + i2cset -y 0 0x2c 0x40 0x1
> No size specified (using byte-data access)
> Warning - data mismatch - wrote 0x01, read back 0x03
> + i2cset -y 0 0x2c 0x2b 0xff
> No size specified (using byte-data access)
> Value 0xff written, readback matched
> + i2cset -y 0 0x2c 0x2c 0x00
> [all the remaining writes succeeded]
> 
> Finally the third time the machine just got this far and then hung:
> 
> oden:~# ./set_safe_direct_wo_smi.sh
> + i2cset -y 0 0x2c 0x40 0x1
> No size specified (using byte-data access)
> 
> 
> So according to the datasheet writing 0x01 to this register should
> shut off EN_SMI, but that doesn't seem to work since the readback
> still shows 0x03 (should be 0x01, right?). I've been trying all sorts
> of things to disable this EN_SMI bit but I can't seem to do it.
> 
> For example, writing 0x80 should re-init the whole chip:
> 
> oden:~# i2cset -y 0 0x2c 0x40 0x80
> No size specified (using byte-data access)
> Warning - data mismatch - wrote 0x80, read back 0x03
> 
> But that still has the EN_SMI bit set??? It shouldn't according to my
> datasheet at least, that bit should be reset to '0'...
> 
> I've also played around in the BIOS for a while, there seems to be
> some king of "MiniBMC" functionality in the BIOS that is logging
> overtemp events someplace. That log was filled with events since BIOS
> enabled all fan monitors by default. I've shut off all those monitors
> and even the whole MiniBMC funtionality but I still get the same hangs
> when writing the sensor limits. I honestly don't know if there is some
> other device on this bus that is communicating with the w82792d chip
> to read these levels as well that might be interfering here. Since
> this MiniBMC thing might be of interest I actually wrote Gigabyte
> support about this whole issue, I'm keeping my fingers crossed but I
> doubt that the question will reach the appropriate people at Gigabyte.
> 
> One more thing I observed;
> 
> oden:~# i2cdump -y 0 0x2c
> No size specified (using byte-data access)
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
> 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
> 10: 00 00 64 64 bf 00 00 63 00 ff 00 00 f5 00 8f 80    ..dd?..c....?.??
> 20: d3 d4 b9 b9 b8 b8 cd 15 ff ff ff ff 00 96 64 d7    ????????.....?d?
> 30: af d9 b1 d9 b1 d7 af ff 00 25 00 f0 f0 f0 2f 39    ???????..%.???/9
> 40: 03 00 00 00 00 ff ff 11 2c 13 40 c3 51 ff 80 5c    ?......?,?@?Q.?\
> 50: ff ff ff ff ff ff ff ff 7a 60 ff 11 11 c1 05 7f    ........z`.?????
> 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> 80: 01 8f 01 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
> 90: 00 00 00 01 8f ff 00 00 11 ff 3c 00 00 01 01 ff    ...??...?.<..??.
> a0: 01 01 01 8f 8f 8f 8f ff 3e e2 00 e0 ff ff 00 00    ???????.>?.?....
> b0: d3 cb ff ff ff 00 e2 b9 ff ff ff f0 f0 f0 ff ff    ??....??...???..
> c0: f2 80 02 39 00 3c 00 ff 2c 00 00 5d 00 60 00 ff    ???9.<..,..].`..
> d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
> e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
> f0: ff ff 80 ff 00 01 00 00 ff 02 ff 00 00 00 00 ff    ..?..?...?......
> 
> Look at index 49, it says "13". According to the datasheet I have a
> revision C chip should have "12". Is this a newer chip then what the
> datasheet covers? In this case there might be some confusion on
> disabling SMI...
> 
> Yuan, could you offer some help and guidance as to why the EN_SMI bit
> can't be turned off and what this revision "13" chip is? My
> motherboard is a Gigabyte GA-4MXSV by the way.
> 
> Regards

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Ymu]

Hi Rudolf, Daniel,

I have gone through the topic just now, sorry I have no much idea about
it :(
The mail has been sent to HW engineers and asks them if there is newer
datasheet.

Best Regards
Yuan Mu

> -----Original Message-----
> From: Rudolf Marek [mailto:r.marek@sh.cvut.cz]
> Sent: Monday, December 05, 2005 3:19 PM
> To: PI14 YMU
> Cc: Daniel Nilsson; LM Sensors
> Subject: Re: [lm-sensors] Kernel hangs with i2c-i801 driver?
> 
> Hello Yuan,
> 
> Please can you help (and new datasheet would be nice too :) ?
> I'm afraid that I cant move any further without your help.
> 
> Thanks
> Regards
> Rudolf
> 
> Daniel Nilsson wrote:
> > Hi Rudolf,
> >
> > On Wed, Nov 30, 2005 at 11:11:00PM +0100, Rudolf Marek wrote:
> >
> >>Never give up, never surrender :) Lets focus on SMI. This should
disable
> >>the SMI from this chip. So we can at least eliminate this source.
> >>OVT# is also unused so this should point if you have HW or SW (bus
driver)
> >>problem.
> >
> >
> > That's the spirit :-)
> >
> >
> >>Please can you try with this sequence, which is same except of new
first
> >>line.
> >>
> >>Quoting Jean:
> >>
> >>You can use the i2cset program to write to the W83792D chip
directly. You
> >>can try using the following commands in your script, without loading
the
> >>w83792d driver. Let us know if it hangs of not.
> >>
> >>i2cset -y 0 0x2c 0x40 0x1  # DISABLE SMI
> >>i2cset -y 0 0x2c 0x2b 0xff # in0_max
> >>...
> >>This should completly disable the SMI.	Lets see how it works :)
> >
> >
> > Ok, I've tried this and a few other things. First of all, I can't
shut
> > off SMI which seems really odd.
> >
> > The first time a ran this sequence I got this result and the machine
> > did not hang:
> >
> > oden:~# ./set_safe_direct_wo_smi.sh
> > + i2cset -y 0 0x2c 0x40 0x1
> > No size specified (using byte-data access)
> > Warning - data mismatch - wrote 0x01, read back 0x06
> > + i2cset -y 0 0x2c 0x2b 0xff
> > No size specified (using byte-data access)
> > Value 0xff written, readback matched
> > + i2cset -y 0 0x2c 0x2c 0x00
> > [all the remaining writes succeeded]
> >
> > The second time I got this result and the machine did still not
hang:
> >
> > oden:~# ./set_safe_direct_wo_smi.sh
> > + i2cset -y 0 0x2c 0x40 0x1
> > No size specified (using byte-data access)
> > Warning - data mismatch - wrote 0x01, read back 0x03
> > + i2cset -y 0 0x2c 0x2b 0xff
> > No size specified (using byte-data access)
> > Value 0xff written, readback matched
> > + i2cset -y 0 0x2c 0x2c 0x00
> > [all the remaining writes succeeded]
> >
> > Finally the third time the machine just got this far and then hung:
> >
> > oden:~# ./set_safe_direct_wo_smi.sh
> > + i2cset -y 0 0x2c 0x40 0x1
> > No size specified (using byte-data access)
> >
> >
> > So according to the datasheet writing 0x01 to this register should
> > shut off EN_SMI, but that doesn't seem to work since the readback
> > still shows 0x03 (should be 0x01, right?). I've been trying all
sorts
> > of things to disable this EN_SMI bit but I can't seem to do it.
> >
> > For example, writing 0x80 should re-init the whole chip:
> >
> > oden:~# i2cset -y 0 0x2c 0x40 0x80
> > No size specified (using byte-data access)
> > Warning - data mismatch - wrote 0x80, read back 0x03
> >
> > But that still has the EN_SMI bit set??? It shouldn't according to
my
> > datasheet at least, that bit should be reset to '0'...
> >
> > I've also played around in the BIOS for a while, there seems to be
> > some king of "MiniBMC" functionality in the BIOS that is logging
> > overtemp events someplace. That log was filled with events since
BIOS
> > enabled all fan monitors by default. I've shut off all those
monitors
> > and even the whole MiniBMC funtionality but I still get the same
hangs
> > when writing the sensor limits. I honestly don't know if there is
some
> > other device on this bus that is communicating with the w82792d chip
> > to read these levels as well that might be interfering here. Since
> > this MiniBMC thing might be of interest I actually wrote Gigabyte
> > support about this whole issue, I'm keeping my fingers crossed but I
> > doubt that the question will reach the appropriate people at
Gigabyte.
> >
> > One more thing I observed;
> >
> > oden:~# i2cdump -y 0 0x2c
> > No size specified (using byte-data access)
> >      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
0123456789abcdef
> > 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
> > 10: 00 00 64 64 bf 00 00 63 00 ff 00 00 f5 00 8f 80
..dd?..c....?.??
> > 20: d3 d4 b9 b9 b8 b8 cd 15 ff ff ff ff 00 96 64 d7
????????.....?d?
> > 30: af d9 b1 d9 b1 d7 af ff 00 25 00 f0 f0 f0 2f 39
???????..%.???/9
> > 40: 03 00 00 00 00 ff ff 11 2c 13 40 c3 51 ff 80 5c
?......?,?@?Q.?\
> > 50: ff ff ff ff ff ff ff ff 7a 60 ff 11 11 c1 05 7f
........z`.?????
> > 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
> > 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
> > 80: 01 8f 01 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a
????....??..<<??
> > 90: 00 00 00 01 8f ff 00 00 11 ff 3c 00 00 01 01 ff
...??...?.<..??.
> > a0: 01 01 01 8f 8f 8f 8f ff 3e e2 00 e0 ff ff 00 00
???????.>?.?....
> > b0: d3 cb ff ff ff 00 e2 b9 ff ff ff f0 f0 f0 ff ff
??....??...???..
> > c0: f2 80 02 39 00 3c 00 ff 2c 00 00 5d 00 60 00 ff
???9.<..,..].`..
> > d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
................
> > e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff
???(<P(<P(<P....
> > f0: ff ff 80 ff 00 01 00 00 ff 02 ff 00 00 00 00 ff
..?..?...?......
> >
> > Look at index 49, it says "13". According to the datasheet I have a
> > revision C chip should have "12". Is this a newer chip then what the
> > datasheet covers? In this case there might be some confusion on
> > disabling SMI...
> >
> > Yuan, could you offer some help and guidance as to why the EN_SMI
bit
> > can't be turned off and what this revision "13" chip is? My
> > motherboard is a Gigabyte GA-4MXSV by the way.
> >
> > Regards

==============================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such  a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.
==============================================If your computer is unable to decode Chinese font, please ignore the following message.It essentially repeats the statement in English given above.本信件內所含華邦電子的財產性機密性資訊, 僅授權原發信人指定之收信人取閱\之用. 假使您並非被指定之收信人或因任何原因在未經授權的情形之下收到本信件, 請您告知原發信人並立即將信件從電腦與網路伺服器中予以消除. 對於您的合作, 我們先此致謝. 特此提醒, 任何未經授權擅自使用華邦電子的機密資訊的行為是被嚴格禁止的. 信件與華邦電子營業無關之內容,不得視為華邦電子之立場或意見.

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

On Mon, Dec 05, 2005 at 06:14:27PM +0800, Ymu at Winbond.com.tw wrote:
> Hi Rudolf, Daniel,
> 
> I have gone through the topic just now, sorry I have no much idea about
> it :(

Yuan,

I appreciate any help you can offer on this matter, it seems hard to
solve without further knownledge about the hardware.

Is there a chance that you have test hardware available with the
w83792d chip where you could try to run the same commands that I did?

First of all, what does a dump look like in your case?

i2cdump -y 0 0x2c

Then, what happens if you try to reset the EN_SMI bit?

i2cset -y 0 0x2c 0x40 0x1
i2cdump -y 0 0x2c

Finally, what happens if you re-init the chip?

i2cset -y 0 0x2c 0x40 0x80
i2cdump -y 0 0x2c

On my system, the bus number is 0 and the address is 0x2c so you
probably need to adjust those to match your setup...


> The mail has been sent to HW engineers and asks them if there is newer
> datasheet.

Great, thanks. We'll be looking for that datasheet.

Best Regards
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Ymu]

Hi Daniel,

> Is there a chance that you have test hardware available with the
> w83792d chip where you could try to run the same commands that I did?
> 
Yes, I have a board on hand; it's a C version chip.

> First of all, what does a dump look like in your case?
> 
> i2cdump -y 0 0x2c
> 

[root at oapcsh00279 proc]# i2cdump -y 0 0x2f
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 ad 00 00 78 00 ff 00 00 d5 00 e2 b3    ..dd?..x....?.??
20: be be d0 c9 5c a3 d1 25 7f ff ff d7 a5 b5 83 ff    ????\??%?..????.
30: 00 ff 00 ff 00 ff 00 ff 00 7f 00 ff ff ff aa b5    .........?....??
40: 01 00 00 00 00 ff ff 72 2f 12 73 84 01 ff 80 5c    ?......r/?s??.?\
50: ff ff ff ff ff ff ff ff 7a 60 ff 77 77 01 05 7f    ........z`.ww???
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 01 8f 01 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
90: 00 00 00 01 8f ff 00 00 11 ff 3c 00 00 01 07 ff    ...??...?.<..??.
a0: 01 01 01 8f 8f 8f 8f ff c4 02 00 00 ff ff 00 00    ???????.??......
b0: cc c0 ff ff ff 00 ff 00 ff ff ff ff ff ff ff ff    ??..............
c0: 23 00 00 4b 00 50 00 ff 0e 00 00 4b 00 50 00 ff    #..K.P..?..K.P..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
f0: ff ff 80 ff 00 01 00 04 ff 02 ff 00 00 00 00 ff    ..?..?.?.?......

> Then, what happens if you try to reset the EN_SMI bit?
> 
> i2cset -y 0 0x2c 0x40 0x1
> i2cdump -y 0 0x2c

The value of 0x40 is 0x1 now, so I run commands below.

[root at oapcsh00279 proc]# i2cset -y 0 0x2f 0x40 0x3
No size specified (using byte-data access)
Value 0x03 written, readback matched
[root at oapcsh00279 proc]# i2cset -y 0 0x2f 0x40 0x7
No size specified (using byte-data access)
Value 0x07 written, readback matched
[root at oapcsh00279 proc]# i2cdump -y 0 0x2f
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 ad 00 00 78 00 ff 00 00 d5 00 e2 b3    ..dd?..x....?.??
20: be be d0 c9 5c a3 d1 25 7f ff ff d7 a5 b5 83 ff    ????\??%?..????.
30: 00 ff 00 ff 00 ff 00 ff 00 7f 00 ff ff ff ba b9    .........?....??
40: 07 00 00 00 00 ff ff 72 2f 12 73 84 01 ff 80 5c    ?......r/?s??.?\
50: ff ff ff ff ff ff ff ff 7a 60 ff 77 77 01 05 7f    ........z`.ww???
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 01 8f 01 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
90: 00 00 00 01 8f ff 00 00 11 ff 3c 00 00 01 07 ff    ...??...?.<..??.
a0: 01 01 01 8f 8f 8f 8f ff c4 02 00 00 ff ff 00 00    ???????.??......
b0: cd c0 ff ff ff 00 ff 00 ff ff ff ff ff ff ff ff    ??..............
c0: 23 80 00 4b 00 50 00 ff 0e 80 00 4b 00 50 00 ff    #?.K.P..??.K.P..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
f0: ff ff 80 ff 00 01 00 04 ff 02 ff 00 00 00 00 ff    ..?..?.?.?......

[root at oapcsh00279 proc]# i2cset -y 0 0x2f 0x40 0x1
No size specified (using byte-data access)
Value 0x01 written, readback matched
[root at oapcsh00279 proc]# i2cdump -y 0 0x2f
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 ad 00 00 78 00 ff 00 00 d5 00 e2 b3    ..dd?..x....?.??
20: be be d0 c9 5c a3 d1 25 7f ff ff d7 a5 b5 83 ff    ????\??%?..????.
30: 00 ff 00 ff 00 ff 00 ff 00 7f 00 ff ff ff 6a b9    .........?....j?
40: 01 00 00 00 00 ff ff 72 2f 12 73 84 01 ff 80 5c    ?......r/?s??.?\
50: ff ff ff ff ff ff ff ff 7a 60 ff 77 77 01 05 7f    ........z`.ww???
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 01 8f 01 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
90: 00 00 00 01 8f ff 00 00 11 ff 3c 00 00 01 07 ff    ...??...?.<..??.
a0: 01 01 01 8f 8f 8f 8f ff c4 02 00 00 ff ff 00 00    ???????.??......
b0: cc c0 ff ff ff 00 ff 00 ff ff ff ff ff ff ff ff    ??..............
c0: 25 00 00 4b 00 50 00 ff 0e 80 00 4b 00 50 00 ff    %..K.P..??.K.P..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
f0: ff ff 80 ff 00 01 00 04 ff 02 ff 00 00 00 00 ff    ..?..?.?.?......

> Finally, what happens if you re-init the chip?
> 
> i2cset -y 0 0x2c 0x40 0x80
> i2cdump -y 0 0x2c
>
[root at oapcsh00279 proc]# i2cset -y 0 0x2f 0x40 0x80
No size specified (using byte-data access)
Warning - data mismatch - wrote 0x80, read back 0x01
[root at oapcsh00279 proc]# i2cdump -y 0 0x2f
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 ad 00 00 78 00 ff 00 00 d5 00 e2 b3    ..dd?..x....?.??
20: be be d0 c9 5c a3 d1 25 fe ff ff d7 a5 b5 83 ff    ????\??%?..????.
30: 00 ff 00 ff 00 ff 00 ff 00 7f 00 ff ff ff ba b5    .........?....??
40: 01 02 00 00 00 ff ff 11 2f 12 73 84 01 ff 80 5c    ??.....?/?s??.?\
50: ff ff ff ff ff ff ff ff 7a 60 ff 11 11 01 05 7f    ........z`.?????
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 01 8f 01 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
90: 00 00 00 01 8f ff 00 00 11 ff 3c 00 00 01 01 ff    ...??...?.<..??.
a0: 01 01 01 8f 8f 8f 8f ff c4 02 00 00 ff ff 00 00    ???????.??......
b0: cc c0 ff ff ff 00 ff 00 ff ff ff ff ff ff ff ff    ??..............
c0: 23 80 00 4b 00 50 00 ff 0f 80 00 4b 00 50 00 ff    #?.K.P..??.K.P..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
f0: ff ff 80 ff 00 01 00 04 ff 02 ff 00 00 00 00 ff    ..?..?.?.?......


Best Regards
Yuan Mu



==============================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such  a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.
==============================================If your computer is unable to decode Chinese font, please ignore the following message.It essentially repeats the statement in English given above.本信件內所含華邦電子的財產性機密性資訊, 僅授權原發信人指定之收信人取閱\之用. 假使您並非被指定之收信人或因任何原因在未經授權的情形之下收到本信件, 請您告知原發信人並立即將信件從電腦與網路伺服器中予以消除. 對於您的合作, 我們先此致謝. 特此提醒, 任何未經授權擅自使用華邦電子的機密資訊的行為是被嚴格禁止的. 信件與華邦電子營業無關之內容,不得視為華邦電子之立場或意見.

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi Yuan, Rudolf,

Quoting Ymu at Winbond.com.tw:

>> Is there a chance that you have test hardware available with the
>> w83792d chip where you could try to run the same commands that I did?
>>
> Yes, I have a board on hand; it's a C version chip.

Your chip seems to behave differently from mine, but then again it is has '12'
as revision ID where my chip has '13'. So I guess we still need to wait for
that updated datasheet to understand if there are programming differences.

Meanwhile, I wrote back to Gigabyte support and got a slightly better answer
this time...

Quoting Gigabyte support:

"Hi Daniel,

We are sorry for the late reply. Here are some of the answers from our R&D
department:

The interrupt pin of the W83792D is connected to one of the GPIO pin of south
bridge. And that GPIO can trigger SMI.

If the sensor limit interrupt enable bit is enabled and the sensor reading is
beyond its limit, the chip will assert the interrupt pin.

The BIOS logs the events and does fan controls based on the interrupts of
w83792. But BIOS always enables interrupt of W83792 even when miniBMC is
disabled because BIOS needs it for fan controls.

Attached a simple diagram to show you how the W83792D chip is connected 
to south
bridge.

Best regards,

GBT Tech Support"

The picture attached is a very simple drawing showing the south bridge in one
box and the w83792d in another box. There is one arrow from the south 
bridge to
the w83792d labelled "SMI bus" and the there is one arrow from the w83792d to
the south bridge labelled interrupt.

Does this provide any more insight? Could this be more of an issue with the
interrupt coming into the south bridge causing a hang since no code is
servicing that interrupt? I don't know the kernel that well to guess any
further though...

Regards
Daniel Nilsson

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Ymu]

Hi Rudolf, Jean,

Can you give some hints now?
Frankly I have no idea about this issue yet.
It seems the SMI caused system hang?


Hi Daniel,
Yesterday I send the new datasheet to you.
I received the reject mail from Jean just now, so let assume you have
received the datasheet now :)
In that mail I mentioned the SMI#/IRQ mask registers, how about set
these mask? I'm trying to disable SMI.
I'm hoping to get the read back value of these commands.

i2cset -y 0 0x2c 0x43 0xff
i2cset -y 0 0x2c 0x44 0x7f
i2cset -y 0 0x2c 0x9c 0xff

If it does not work, let use following command to try other SMI mode.
Now the mode of your board is two time interrupt mode.
i2cset -y 0 0x2c 0x4c 0x01 #comparator interrupt mode
or
i2cset -y 0 0x2c 0x4c 0x81 #One time interrupt mode

Or BIOS will not let us do this too.... I don't know.

Or the SMI is triggered by fan limit/ voltage limit... The fan 4/5/6 low
limit of your MB is not 0.
Try to set all your fan limit value to zero.
i2cset -y 0 0x2c 0x3b 0xff
i2cset -y 0 0x2c 0x3c 0xff
i2cset -y 0 0x2c 0x3d 0xff
i2cset -y 0 0x2c 0xbb 0xff
i2cset -y 0 0x2c 0xbc 0xff
i2cset -y 0 0x2c 0xbd 0xff
i2cset -y 0 0x2c 0xbf 0xff


> >> Is there a chance that you have test hardware available with the
> >> w83792d chip where you could try to run the same commands that I
did?
> >>
> > Yes, I have a board on hand; it's a C version chip.
> 
> Your chip seems to behave differently from mine, but then again it is
has '12'
> as revision ID where my chip has '13'. So I guess we still need to
wait for
> that updated datasheet to understand if there are programming
differences.
>
Yes, yours is different from mine. But I can not find more useful
comments from the new datasheet... can you?

> The picture attached is a very simple drawing showing the south bridge
in one
> box and the w83792d in another box. There is one arrow from the south
> bridge to
> the w83792d labelled "SMI bus" and the there is one arrow from the
w83792d to
> the south bridge labelled interrupt.
>

Sorry I don't know how and why the arrow is from south bridge to w83792d
:(


Best Regards
Yuan Mu


==============================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such  a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.
==============================================If your computer is unable to decode Chinese font, please ignore the following message.It essentially repeats the statement in English given above.本信件內所含華邦電子的財產性機密性資訊, 僅授權原發信人指定之收信人取閱\之用. 假使您並非被指定之收信人或因任何原因在未經授權的情形之下收到本信件, 請您告知原發信人並立即將信件從電腦與網路伺服器中予以消除. 對於您的合作, 我們先此致謝. 特此提醒, 任何未經授權擅自使用華邦電子的機密資訊的行為是被嚴格禁止的. 信件與華邦電子營業無關之內容,不得視為華邦電子之立場或意見.

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Henrique de Moraes Holschuh]

On Wed, 07 Dec 2005, Daniel Nilsson wrote:
> The BIOS logs the events and does fan controls based on the interrupts of
> w83792. But BIOS always enables interrupt of W83792 even when miniBMC is
> disabled because BIOS needs it for fan controls.

Maybe I am asking something too stupid, but what would happen if there is a
race condition between the linux kernel and the BIOS APM code and both try
to access the chip at the same time?  A Linux kernel spinlock won't protect
the chip against rogue hardware access by the BIOS, unless that GPIO
interrupt is disabled in the South Bridge.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

On Wed, Dec 07, 2005 at 05:59:50PM +0800, Ymu at Winbond.com.tw wrote:
> Hi Rudolf, Jean,
> 
> Can you give some hints now?
> Frankly I have no idea about this issue yet.
> It seems the SMI caused system hang?
> 
> 
> Hi Daniel,
> Yesterday I send the new datasheet to you.
> I received the reject mail from Jean just now, so let assume you have
> received the datasheet now :)
> In that mail I mentioned the SMI#/IRQ mask registers, how about set
> these mask? I'm trying to disable SMI.
> I'm hoping to get the read back value of these commands.
> 
> i2cset -y 0 0x2c 0x43 0xff
> i2cset -y 0 0x2c 0x44 0x7f
> i2cset -y 0 0x2c 0x9c 0xff

Hi Yuan,

Setting those 3 registers to mask off the interrupts worked, I have
the following register values after setting the masks:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 64 64 bf 00 00 63 00 ff 04 00 f5 00 8f b3    ..dd?..c..?.?.??
20: d4 d4 b9 b9 b7 b8 ce 18 42 ff 74 ff 00 96 64 d7    ????????B.t..?d?
30: af d9 b1 d9 b1 d7 af ff 00 25 00 f0 f0 f0 67 30    ???????..%.???g0
40: 03 00 00 ff 7f ff ff bb 2c 13 40 c3 51 ff 80 5c    ?...?..?,?@?Q.?\
50: ff ff ff ff ff ff ff ff 7a 40 ff bb bb c1 05 7f    ........z at .?????
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 81 8f 81 8f 00 00 00 00 11 11 ff ff 3c 3c 0a 0a    ????....??..<<??
90: 00 00 00 81 8f ff 00 00 11 ff 3c 00 ff 01 01 ff    ...??...?.<..??.
a0: 81 81 81 8f 8f 8f 8f ff 3e 42 00 e0 ff ff 00 00    ???????.>B.?....
b0: d3 cb ff ff ff 00 e2 b9 ff ff ff f0 f0 f0 ff ff    ??....??...???..
c0: 29 80 02 39 00 3c 00 ff 30 00 00 5d 00 60 00 ff    )??9.<..0..].`..
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: 8b 8b 8b 28 3c 50 28 3c 50 28 3c 50 ff ff ff ff    ???(<P(<P(<P....
f0: ff ff 00 ff 00 01 00 00 ff 02 ff 00 00 00 00 ff    .....?...?......

With the masks in place, I'm able to set all the sensor limits without
the machine hanging. I reproduced the hand to make sure that setting
those 3 registers actually did have an effect and it seem like that is
the case.


> If it does not work, let use following command to try other SMI mode.
> Now the mode of your board is two time interrupt mode.
> i2cset -y 0 0x2c 0x4c 0x01 #comparator interrupt mode

Tried this one as well, that did not solve the issue with the system
hanging but the register write did succeed. When performing this test
I did not change the mask registers though so that seems to still
point in the direction that it is the interrupt that is causing the hang.

> i2cset -y 0 0x2c 0x4c 0x81 #One time interrupt mode

Same result as above, system still hangs.

> Or BIOS will not let us do this too.... I don't know.
> 
> Or the SMI is triggered by fan limit/ voltage limit... The fan 4/5/6 low
> limit of your MB is not 0.
> Try to set all your fan limit value to zero.
> i2cset -y 0 0x2c 0x3b 0xff
> i2cset -y 0 0x2c 0x3c 0xff
> i2cset -y 0 0x2c 0x3d 0xff
> i2cset -y 0 0x2c 0xbb 0xff
> i2cset -y 0 0x2c 0xbc 0xff
> i2cset -y 0 0x2c 0xbd 0xff
> i2cset -y 0 0x2c 0xbf 0xff

This also seems to avoid the hang. After setting the above registers I
can proceed to set the other sensor limits.

My conclusion from this is that it is probably the interrupt that is
causing the system to hang and we can work around that in this case by
masking off those interrupts. I suppose this could be done in the
w83792d driver since that will prevent the hang from occuring once
that driver is loaded.

Now, thinking a little further here though, this motherboard and
potentially other motherboards comes with all these sensor interrupts
armed and all that seems to be required is for one fan to stop in the
system and the kernel will hang if the w83792d driver hasn't been
loaded... That's not a good thing... Wouldn't a better solution be for
the kernel to be able to survive this SMI interrupt? I really don't
know much about the complexity of that though, I did notice however
that Dell seems to support SMI on some of their servers with the
dcdbas driver.

Thanks!
Daniel

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Ymu]

> -----Original Message-----
> From: lm-sensors-bounces at lm-sensors.org
[mailto:lm-sensors-bounces at lm-sensors.org] On Behalf Of Henrique de
Moraes Holschuh
> Sent: Wednesday, December 07, 2005 7:08 PM
> To: lm-sensors at lm-sensors.org
> Subject: Re: [lm-sensors] Kernel hangs with i2c-i801 driver?
> 
> On Wed, 07 Dec 2005, Daniel Nilsson wrote:
> > The BIOS logs the events and does fan controls based on the
interrupts of
> > w83792. But BIOS always enables interrupt of W83792 even when
miniBMC is
> > disabled because BIOS needs it for fan controls.
> 
> Maybe I am asking something too stupid, but what would happen if there
is a
> race condition between the linux kernel and the BIOS APM code and both
try
> to access the chip at the same time?  A Linux kernel spinlock won't
protect
> the chip against rogue hardware access by the BIOS, unless that GPIO
> interrupt is disabled in the South Bridge.
> 
> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh
> 
Hello Henrique,

Thanks for your comments.
Just as what you described,
It seems that all hang happened when we access the chip (sensors -s
command or i2cset command).
Do you think it's should be the faulty of the man made BIOS?
If so, I'm quiet agree with you ;)

Best Regards
Yuan Mu



==============================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such  a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.
==============================================If your computer is unable to decode Chinese font, please ignore the following message.It essentially repeats the statement in English given above.本信件內所含華邦電子的財產性機密性資訊, 僅授權原發信人指定之收信人取閱\之用. 假使您並非被指定之收信人或因任何原因在未經授權的情形之下收到本信件, 請您告知原發信人並立即將信件從電腦與網路伺服器中予以消除. 對於您的合作, 我們先此致謝. 特此提醒, 任何未經授權擅自使用華邦電子的機密資訊的行為是被嚴格禁止的. 信件與華邦電子營業無關之內容,不得視為華邦電子之立場或意見.

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Jean Delvare]

Hi Daniel,

> Quoting Gigabyte support:
> 
> "Hi Daniel,
> 
> We are sorry for the late reply. Here are some of the answers from our R&D
> department:
> 
> The interrupt pin of the W83792D is connected to one of the GPIO pin of south
> bridge. And that GPIO can trigger SMI.
> 
> If the sensor limit interrupt enable bit is enabled and the sensor reading is
> beyond its limit, the chip will assert the interrupt pin.
> 
> The BIOS logs the events and does fan controls based on the interrupts of
> w83792. But BIOS always enables interrupt of W83792 even when miniBMC is
> disabled because BIOS needs it for fan controls.
> 
> Attached a simple diagram to show you how the W83792D chip is connected 
> to south
> bridge.
> 
> Best regards,
> 
> GBT Tech Support"

Wow, this is way better than they used me to. I'll try to remember
that. This doesn't help me as an individual, but at least they seem to
provide some useful technical detail.

> The picture attached is a very simple drawing showing the south bridge in one
> box and the w83792d in another box. There is one arrow from the south 
> bridge to
> the w83792d labelled "SMI bus" and the there is one arrow from the w83792d to
> the south bridge labelled interrupt.
> 
> Does this provide any more insight? Could this be more of an issue with the
> interrupt coming into the south bridge causing a hang since no code is
> servicing that interrupt? I don't know the kernel that well to guess any
> further though...

I don't know much either, but the schematics would need to mention pin
numbers or names so that we know *which* GPIOs of the i801 are
involved. Is that the case? Without that information, it probably
doesn't help us much.

-- 
Jean Delvare

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Henrique de Moraes Holschuh]

On Thu, 08 Dec 2005, Ymu at Winbond.com.tw wrote:
> Do you think it's should be the faulty of the man made BIOS?

Actually, no.  It's just that we have to make sure nobody else is bothering
the chip while we are.

Of course, if the hardware only had atomic operations, that would be even
better ;-)  (not that this is always possible with i2c, but still...)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Ymu]

Hello Henrique,
> > Do you think it's should be the faulty of the man made BIOS?
> 
> Actually, no.  It's just that we have to make sure nobody else is
bothering
> the chip while we are.

Hmm, what should we do to make sure it in this case...

> 
> Of course, if the hardware only had atomic operations, that would be
even
> better ;-)  (not that this is always possible with i2c, but still...)
Yes, it would be much better, but I don't think it's possible :(

Best Regards
Yuan Mu

==============================================The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such  a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.
==============================================If your computer is unable to decode Chinese font, please ignore the following message.It essentially repeats the statement in English given above.本信件內所含華邦電子的財產性機密性資訊, 僅授權原發信人指定之收信人取閱\之用. 假使您並非被指定之收信人或因任何原因在未經授權的情形之下收到本信件, 請您告知原發信人並立即將信件從電腦與網路伺服器中予以消除. 對於您的合作, 我們先此致謝. 特此提醒, 任何未經授權擅自使用華邦電子的機密資訊的行為是被嚴格禁止的. 信件與華邦電子營業無關之內容,不得視為華邦電子之立場或意見.

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi Jean,

On Thu, Dec 08, 2005 at 10:22:40PM +0100, Jean Delvare wrote:
> 
> > The picture attached is a very simple drawing showing the south bridge in one
> > box and the w83792d in another box. There is one arrow from the south 
> > bridge to
> > the w83792d labelled "SMI bus" and the there is one arrow from the w83792d to
> > the south bridge labelled interrupt.
> > 
> > Does this provide any more insight? Could this be more of an issue with the
> > interrupt coming into the south bridge causing a hang since no code is
> > servicing that interrupt? I don't know the kernel that well to guess any
> > further though...
> 
> I don't know much either, but the schematics would need to mention pin
> numbers or names so that we know *which* GPIOs of the i801 are
> involved. Is that the case? Without that information, it probably
> doesn't help us much.

The simple drawings didn't have either pin names or numbers so I wrote
back to GBT support asking for this additional piece of information.

Now, assuming that we have this piece of information, how would we use
it? I guess we could disable that GPIO somehow, but that fix is very
specific to this motherboard... Isn't it likely that other motherboard
would need some similar patch to prevent this kind of issue?

I guess what I'm wondering is, is it hard to support the SMI
functionality and would that be a more generic solution that would
make the kernel survive the SMI? Or is the issue rather with a GPIO
setup as an interrupt triggering an interrupt for which there is no
handler installed?

Regards
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Henrique de Moraes Holschuh]

Do we already know whether the problem is the SMI interrupt itself, or in
the BIOS (it crashes because there are other users of the chip), or in the
chip (it heavily opposes being accessed by two threads at once at
innoportune times)?

IMHO we can work around the problem without that information (which means no
more crashing, that's good), but we need to pinpoint the culprit to provide
the proper *fix*.

If it is a SMI interrupt problem, the correct fix is to teach linux to
handle SMI interrupts and have that generic code always enabled. This is
probable desireable anyway, if it is possible to do so.

IMHO if it is a chip/BIOS issue, the fix either belongs into lm-sensors
(chip specific: disable all interrupt sources if during startup we detect
that SMI interrupt generation is enabled) or to the quirks layer (machine:
disable SMI interrupts on this motherboard).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Rudolf Marek]

Hello all

> The simple drawings didn't have either pin names or numbers so I wrote
> back to GBT support asking for this additional piece of information.
> 
> Now, assuming that we have this piece of information, how would we use
> it? I guess we could disable that GPIO somehow, but that fix is very
> specific to this motherboard... Isn't it likely that other motherboard
> would need some similar patch to prevent this kind of issue?

Yes this is verys specific to this motherboard, question is

1) why the SMI is generated when setting limits?
   (Possible answer like Yuan suggested that the fans limit are above zero? (and readings are 0)
   But this whould mean that actually writing to registeters will somehow do SMI which is I must admit strange
   Unfortunately I'm very busy this weeks so I dont have much time left to dig in the chip dumps.
   Perhaps someone else could spot why the SMI is generated?

2) why it hangs

> I guess what I'm wondering is, is it hard to support the SMI
> functionality and would that be a more generic solution that would
> make the kernel survive the SMI? Or is the issue rather with a GPIO
> setup as an interrupt triggering an interrupt for which there is no
> handler installed?

SMI is a very special interrupt. It is completly transparent to operating system. When
SMI will come it will switch the processor to so called System Management Mode.
It is similar to real mode but limited to small piece of memory. Even you cant find
the SMM routine in memory because it its "hidden" bellow the video RAM (0x0A0000) (ususally)
If this routine has a bug it will hang...

You can spot the SMI only by measuring clock in system. You wont notice if smi ever occured.
(SMI is rather anoying for realtime stuff on x86)

Lets try:

Generate the SMI from other source than the fans limits (if it hangs too)
Then we will know if the complete handler is wrong or only parts.

Also are you using HIGHMEM support in kernel? I guess this might be right reason why it fails
(Due to 4MB PAE)

If so please disable and try all stuff again. If it wont freeze we spot the bug.

So what to do:
1) why is SMI generated when writing limits?
2) if SMI fan event is specific to hang or any other SMI will hang too.
3) what about highmem?

Regards
Rudolf

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi All,

On Sat, Dec 10, 2005 at 10:14:30AM +0100, Rudolf Marek wrote:
> 
> Lets try:
> 
> Generate the SMI from other source than the fans limits (if it hangs too)
> Then we will know if the complete handler is wrong or only parts.

So I've done some more debugging, but things are looking pretty
strange. First of all, I'm setting all the fan limits to 0xff as far
as I can tell which should mean that I will accept an inifinite amount
of time between each pulse or in other words 0 fan speed. So I don't
follow what you mean by setting the limits to 0? Isn't that what I'm
doing now in the script? At least according to 'sensors' that is the
effect of writing 0xff to all the fan speed limit registers.

> Also are you using HIGHMEM support in kernel? I guess this might be
> right reason why it fails (Due to 4MB PAE)

I am using HIGHMEM support and I tried to disable it, didn't notice a
difference in behaviour... 

> So what to do:
> 1) why is SMI generated when writing limits?
> 2) if SMI fan event is specific to hang or any other SMI will hang too.
> 3) what about highmem?

I've also noticed that register at 0x40 is programmed to 0x03 after a
reboot which emans that the interrupt output is active (supposedly the
one connected to the GPIO that Gigabyte mentions in their mail). But
EN_SMI# output is disabled. So I guess that the chip isn't setup to
generate an SMI event on it's own but rather through that GPIO pin
somehow.

I enabled that EN_SMI# output and now I can reproduce the freeze
easily by setting a voltage limit to low:

oden:~# i2cset -y 0 0x2c 0x2b 0xff # in0_max
No size specified (using byte-data access)
Value 0xff written, readback matched
oden:~# i2cset -y 0 0x2c 0x40 0x7 # enable EN_SMI#
No size specified (using byte-data access)
Value 0x07 written, readback matched
oden:~# i2cset -y 0 0x2c 0x2b 0x10 # in0_max
No size specified (using byte-data access)
[machine freezes]

I guess this proves the point that it's not the fan event that causes
the hang but rather any SMI event? Is the SMI code installed by the
BIOS?

Regards
-- 
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi Jean,

On Thu, Dec 08, 2005 at 10:22:40PM +0100, Jean Delvare wrote:
> 
> > The picture attached is a very simple drawing showing the south bridge in one
> > box and the w83792d in another box. There is one arrow from the south 
> > bridge to
> > the w83792d labelled "SMI bus" and the there is one arrow from the w83792d to
> > the south bridge labelled interrupt.
> > 
> > Does this provide any more insight? Could this be more of an issue with the
> > interrupt coming into the south bridge causing a hang since no code is
> > servicing that interrupt? I don't know the kernel that well to guess any
> > further though...
> 
> I don't know much either, but the schematics would need to mention pin
> numbers or names so that we know *which* GPIOs of the i801 are
> involved. Is that the case? Without that information, it probably
> doesn't help us much.

I've got another answer fro GBT Support:

"We are sorry for the late response. Here is an answer from our R&D team:
The GPI7 is the interrupt pin of 83792. Please disable the SMI bus of
GPI7 from South bridge.

Hope this helps.

Best regards,

GBT Tech Support"

I actually didn't expect to get this questin answered from GBT, not
that the answers are that exhaustive but at least we are getting bits
and pieces here and there...

So I assume we are talking about GPI7 on my ICH7R bridge. In the
datasheet,

http://download.intel.com/design/chipsets/datashts/30701301.pdf

of the ICH7R I understand that this pins can be set to cause either
SCI and/or SMI#. This should be programmed by the BIOS though, right?
Linux should be messing around with these chipset registers?
Regardless, the register of interrest I think is the one in chapter
10.8.1.5. Now how would I read the value in that register from user
space in Linux? It says that the registers that this specific register
is part of is distributed within PCI Device 31:Function 0 space as
well as a separate I/O range but this still doesn't tell me much on
how to read it...

Thanks!
Daniel

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Henrique de Moraes Holschuh]

On Thu, 15 Dec 2005, Daniel Nilsson wrote:
> SCI and/or SMI#. This should be programmed by the BIOS though, right?
> Linux should be messing around with these chipset registers?

Yes, it can mess with anything as long as it doesn't get it wrong.  In this
case, that means you need a quirk keyed for the specific motherboards that
have that SMI setup.  And that code is not going to be added to any i2c or
hwmon module, of course.  It lives elsewhere in the Kernel.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Rudolf Marek]

> I've got another answer fro GBT Support:
> 
> "We are sorry for the late response. Here is an answer from our R&D team:
> The GPI7 is the interrupt pin of 83792. Please disable the SMI bus of
> GPI7 from South bridge.
> 
> Hope this helps.
> 
> Best regards,
> 
> GBT Tech Support"
> 
> I actually didn't expect to get this questin answered from GBT, not
> that the answers are that exhaustive but at least we are getting bits
> and pieces here and there...
> 
> So I assume we are talking about GPI7 on my ICH7R bridge. In the
> datasheet,
> 
> http://download.intel.com/design/chipsets/datashts/30701301.pdf
> 
> of the ICH7R I understand that this pins can be set to cause either
> SCI and/or SMI#. This should be programmed by the BIOS though, right?
> Linux should be messing around with these chipset registers?

Linux should not unless there is something wrong like this...

The real question is WHAT is failing. What exactly in the SMM mode handler will fail...
This is very hard to debug, perhaps with the need of real hardware debugger.

So we have two ways how to handle this:

Method 1) to disable the SMI via GPI7

we need to know:
 1) how to identify this motherboard, (DMI, PCI subsystem ID (subsystem ID is needed to ask them))
 2) will the disabled SMI affect the emergency shutdown of CPU?
   (we can answer this by ourselfs, I think the W83792D has OVT pin for this)
    Better to have it confirmed.

 3) then we will develop a patch to quirks.c

Method 2) try to uncover why the SMI failes
   This is very difficult. Maybe we can ask them for some special bios version
   with modified SMM handler to see if it fails too.

   We can ask them to provide the SMM BIOS handler code and try to look around...

   Are you using USB keyboard or mouse?
   (SMM is used for emulation this devices as legacy PS/2)

So question is what to try....

Maybe we can disable the GPI7 and see if there are no hangs. If so then we can try to find real reason. If it fails
we can implement method1.

> Regardless, the register of interrest I think is the one in chapter
> 10.8.1.5. Now how would I read the value in that register from user
> space in Linux? It says that the registers that this specific register
> is part of is distributed within PCI Device 31:Function 0 space as
> well as a separate I/O range but this still doesn't tell me much on
> how to read it...


PCI space => lspci -x -x -x
IO space => isadump -f

So for our case

lspci -x -x -x

Is enough. (enough is even the listing from PCI Device 31:Function 0)

Regards
Rudolf

BTW: Intel left little secret in that datasheet look to page 54 (printed) to the picture...
     There is free space in righ bottom corner. Now use mouse to copy that area and you will be surprised ;)
     Well not so much  but it is funny way to hide information rather then delete.

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi All,

Sorry for the delay, I'm on vacation and I only have remote access to the
machine right now so I'm cautious what I experiement with since I can't press
the reset button:-)

Quoting Rudolf Marek <r.marek at sh.cvut.cz>:

> The real question is WHAT is failing. What exactly in the SMM mode 
> handler will fail...
> This is very hard to debug, perhaps with the need of real hardware debugger.
>
> So we have two ways how to handle this:
>
> Method 1) to disable the SMI via GPI7

This is probably fine for me, though it feels like putting a patch on the
sympton instead of the cause. But I realize fixing the cause might be
impossible without access to the BIOS source code and a hardware debugger.

> we need to know:
> 1) how to identify this motherboard, (DMI, PCI subsystem ID 
> (subsystem ID is needed to ask them))
> 2) will the disabled SMI affect the emergency shutdown of CPU?
>   (we can answer this by ourselfs, I think the W83792D has OVT pin for this)
>    Better to have it confirmed.
>
> 3) then we will develop a patch to quirks.c

I can ask this from Gigabyte once we know this is the approach we want 
to take.

> Method 2) try to uncover why the SMI failes
>   This is very difficult. Maybe we can ask them for some special bios version
>   with modified SMM handler to see if it fails too.
>
>   We can ask them to provide the SMM BIOS handler code and try to 
> look around...

I suppose we could ask this but maybe I should just ask them to reproduce the
problem on Linux themselves and tell me why it fails? In order to do so though
I feel like we need to be pretty sure that the bug is not in Linux code but in
code installed by their BIOS. Is there a way to prove that?

>   Are you using USB keyboard or mouse?
>   (SMM is used for emulation this devices as legacy PS/2)

No, the keyboard and mouse are both connected to PS/2 ports.

> So question is what to try....
>
> Maybe we can disable the GPI7 and see if there are no hangs. If so 
> then we can try to find real reason. If it fails
> we can implement method1.

This sounds like a reasonable approach, how do I write to the PCI 
registers from
user space?

>> Regardless, the register of interrest I think is the one in chapter
>> 10.8.1.5. Now how would I read the value in that register from user
>> space in Linux? It says that the registers that this specific register
>> is part of is distributed within PCI Device 31:Function 0 space as
>> well as a separate I/O range but this still doesn't tell me much on
>> how to read it...
>
>
> PCI space => lspci -x -x -x
> IO space => isadump -f

Here's the dump:

0000:00:1f.0 ISA bridge: Intel Corp.: Unknown device 27b8 (rev 01)
00: 86 80 b8 27 47 01 10 02 01 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 b0 27
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 10 00 00 80 00 00 00 81 11 00 00 10 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 8a 8a 8a 8a d0 00 00 00 8a 80 80 85 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 10 00 0f 3f 00 00 00 00 00 00 00 00 91 02 04 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 20 06 00 00 08 00 00 00 13 00 00 00 00 03 00 00
b0: 00 00 f0 00 00 00 00 00 00 40 01 18 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 33 22 11 00 67 45 00 00 cf ff 00 00 00 00 00 00
e0: 09 00 0c 10 00 00 20 00 00 00 00 00 00 00 00 00
f0: 01 c0 d1 fe 00 00 00 00 86 0f 01 00 00 00 00 00

So the 32 bit value for register GPIO_ROUT @ offset B8h-BBh should be 
0x18014000
if I understand correctly. That would indicate that GPIO7 is configured for
SMI# which is what Gigabyte claims as well. Not sure I got the bytes swapped
correctly though... Now, how do I write these register?

Thanks!

Daniel Nilsson


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Rudolf Marek]

Daniel Nilsson wrote:
> Hi All,
> 
> Sorry for the delay, I'm on vacation and I only have remote access to the
> machine right now so I'm cautious what I experiement with since I can't
> press
> the reset button:-)

Never mind.
> This is probably fine for me, though it feels like putting a patch on the
> sympton instead of the cause. But I realize fixing the cause might be
> impossible without access to the BIOS source code and a hardware debugger.

Yep.

> I suppose we could ask this but maybe I should just ask them to
> reproduce the
> problem on Linux themselves and tell me why it fails? In order to do so
> though
> I feel like we need to be pretty sure that the bug is not in Linux code
> but in
> code installed by their BIOS. Is there a way to prove that?

SMI is completly transparent to OS. In fact you as OS dont notice, you cant catch it. It is simply out of OS control.

>> Maybe we can disable the GPI7 and see if there are no hangs. If so
>> then we can try to find real reason. If it fails
>> we can implement method1.
> 
> 
> This sounds like a reasonable approach, how do I write to the PCI
> registers from
> user space?

There is setpci command.

> Here's the dump:
> 
> 0000:00:1f.0 ISA bridge: Intel Corp.: Unknown device 27b8 (rev 01)
> 00: 86 80 b8 27 47 01 10 02 01 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 b0 27
> 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
> 40: 01 10 00 00 80 00 00 00 81 11 00 00 10 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 8a 8a 8a 8a d0 00 00 00 8a 80 80 85 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 10 00 0f 3f 00 00 00 00 00 00 00 00 91 02 04 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 20 06 00 00 08 00 00 00 13 00 00 00 00 03 00 00
> b0: 00 00 f0 00 00 00 00 00 00 40 01 18 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 33 22 11 00 67 45 00 00 cf ff 00 00 00 00 00 00
> e0: 09 00 0c 10 00 00 20 00 00 00 00 00 00 00 00 00
> f0: 01 c0 d1 fe 00 00 00 00 86 0f 01 00 00 00 00 00
> 
> So the 32 bit value for register GPIO_ROUT @ offset B8h-BBh should be
> 0x18014000

00 40 01 18 =>  18014000 GP7 is bit 15:14 -> 0100 0000 0000 0000 -> 01 -> SMI# ;)

> if I understand correctly. That would indicate that GPIO7 is configured for
> SMI# which is what Gigabyte claims as well. Not sure I got the bytes
> swapped
> correctly though... 

Yes you did.

Now, how do I write these register?

setpci -s 00:1f.0 b8.l\x18010000

You can check it via lspci if it has been changed.

When done, please test the stuff once again. If it is OK then please provide:
lspci -v -v -v (of all devices) and also output of dmidecode utility.
We will need this for the fix the symptom.

Best would be if Gigabyte can bit investigate what went really wrong...

Regards
Rudolf

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi All,

Back from vacationing, time to get this issue resolved :-)

On Thu, Dec 29, 2005 at 06:49:45PM +0100, Rudolf Marek wrote:
> > I suppose we could ask this but maybe I should just ask them to
> > reproduce the
> > problem on Linux themselves and tell me why it fails? In order to do so
> > though
> > I feel like we need to be pretty sure that the bug is not in Linux code
> > but in
> > code installed by their BIOS. Is there a way to prove that?
> 
> SMI is completly transparent to OS. In fact you as OS dont notice,
> you cant catch it. It is simply out of OS control.

Sounds like I should put some pressure on Gigabyte to fix the route
cause, I don't think we will be able to do so but since this is a
server motherboard one would think the Gigabyte should be interested
in fixing the root cause... I'll try and let you all know how that goes.

> > Here's the dump:
> > 
> > 0000:00:1f.0 ISA bridge: Intel Corp.: Unknown device 27b8 (rev 01)
> > 00: 86 80 b8 27 47 01 10 02 01 00 01 06 00 00 80 00
> > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 b0 27
> > 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
> > 40: 01 10 00 00 80 00 00 00 81 11 00 00 10 00 00 00
> > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 60: 8a 8a 8a 8a d0 00 00 00 8a 80 80 85 00 00 00 00
> > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 80: 10 00 0f 3f 00 00 00 00 00 00 00 00 91 02 04 00
> > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > a0: 20 06 00 00 08 00 00 00 13 00 00 00 00 03 00 00
> > b0: 00 00 f0 00 00 00 00 00 00 40 01 18 00 00 00 00
> > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > d0: 33 22 11 00 67 45 00 00 cf ff 00 00 00 00 00 00
> > e0: 09 00 0c 10 00 00 20 00 00 00 00 00 00 00 00 00
> > f0: 01 c0 d1 fe 00 00 00 00 86 0f 01 00 00 00 00 00
> > 
> > So the 32 bit value for register GPIO_ROUT @ offset B8h-BBh should be
> > 0x18014000
> 
> 00 40 01 18 =>  18014000 GP7 is bit 15:14 -> 0100 0000 0000 0000 -> 01 -> SMI# ;)
> 
> > if I understand correctly. That would indicate that GPIO7 is configured for
> > SMI# which is what Gigabyte claims as well. Not sure I got the bytes
> > swapped
> > correctly though... 
> 
> Yes you did.
> 
> Now, how do I write these register?
> 
> setpci -s 00:1f.0 b8.l\x18010000
> 
> You can check it via lspci if it has been changed.

So setpci seems to work:

0000:00:1f.0 ISA bridge: Intel Corp.: Unknown device 27b8 (rev 01)
00: 86 80 b8 27 47 01 10 02 01 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 58 14 b0 27
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
40: 01 10 00 00 80 00 00 00 81 11 00 00 10 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 8a 8a 8a 8a d0 00 00 00 8a 80 80 85 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 10 00 0f 3f 00 00 00 00 00 00 00 00 91 02 04 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 20 06 00 00 08 00 00 00 13 00 00 00 00 03 00 00
b0: 00 00 f0 00 00 00 00 00 00 00 01 18 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 33 22 11 00 67 45 00 00 cf ff 00 00 00 00 00 00
e0: 09 00 0c 10 00 00 20 00 00 00 00 00 00 00 00 00
f0: 01 c0 d1 fe 00 00 00 00 86 0f 01 00 00 00 00 00

> When done, please test the stuff once again. If it is OK then please provide:
> lspci -v -v -v (of all devices) and also output of dmidecode utility.
> We will need this for the fix the symptom.

After shutting off that bit 14 for enabling SMI on GPIO7 that machine
does not hang any longer! I've tried a couple things that used to make
the machine hang and none of them did any harm any longer! To prove
that a different way I re-enabled that bit again using 

setpci -s 00:1f.0 b8.l\x18014000

which caused the machine to hang right away (ie, the setpci command
didn't return). Looks like we might have a workaround!

The output of dmidecode and lspci -v -v -v is attached since it is
rather long. 

Best Regards
-- 
Daniel Nilsson
-------------- next part --------------
oden:~# dmidecode
# dmidecode 2.6
SMBIOS 2.3 present.
52 structures occupying 1994 bytes.
Table at 0x000F0440.
Handle 0x0000
        DMI type 0, 20 bytes.
        BIOS Information
                Vendor: Phoenix Technologies LTD
                Version: F2
                Release Date: 09/28/2005
                Address: 0xE5470
                Runtime Size: 109456 bytes
                ROM Size: 1024 kB
                Characteristics:
                        PCI is supported
                        PNP is supported
                        BIOS is upgradeable
                        BIOS shadowing is allowed
                        ESCD support is available
                        Boot from CD is supported
                        Selectable boot is supported
                        EDD is supported
                        Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
                        Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
                        3.5"/720 KB floppy services are supported (int 13h)
                        3.5"/2.88 MB floppy services are supported (int 13h)
                        8042 keyboard services are supported (int 9h)
                        Serial services are supported (int 14h)
                        Printer services are supported (int 17h)
                        ACPI is supported
                        USB legacy is supported
                        LS-120 boot is supported
                        BIOS boot specification is supported
                        Function key-initiated network boot is supported
Handle 0x0001
        DMI type 1, 25 bytes.
        System Information
                Manufacturer: GIGABYTE
                Product Name: R114
                Version: Revision A
                Serial Number: 012345678912
                UUID: 00148525-4510-0000-0000-000000000000
                Wake-up Type: Unknown
Handle 0x0002
        DMI type 2, 8 bytes.
        Base Board Information
                Manufacturer: GIGABYTE
                Product Name: R114
                Version: None
                Serial Number: 000000000000
Handle 0x0003
        DMI type 3, 17 bytes.
        Chassis Information
                Manufacturer: GIGABYTE
                Type: Other
                Lock: Not Present
                Version: None
                Serial Number:
                Asset Tag: No Asset Tag
                Boot-up State: Safe
                Power Supply State: Safe
                Thermal State: Safe
                Security Status: None
                OEM Information: 0x00000000
Handle 0x0004
        DMI type 4, 35 bytes.
        Processor Information
                Socket Designation: CPU#1
                Type: Central Processor
                Family: Pentium 4
                Manufacturer: Intel Corporation
                ID: 43 0F 00 00 FF FB EB BF
                Signature: Type 0, Family 15, Model 4, Stepping 3
                Flags:
                        FPU (Floating-point unit on-chip)
                        VME (Virtual mode extension)
                        DE (Debugging extension)
                        PSE (Page size extension)
                        TSC (Time stamp counter)
                        MSR (Model specific registers)
                        PAE (Physical address extension)
                        MCE (Machine check exception)
                        CX8 (CMPXCHG8 instruction supported)
                        APIC (On-chip APIC hardware supported)
                        SEP (Fast system call)
                        MTRR (Memory type range registers)
                        PGE (Page global enable)
                        MCA (Machine check architecture)
                        CMOV (Conditional move instruction supported)
                        PAT (Page attribute table)
                        PSE-36 (36-bit page size extension)
                        CLFSH (CLFLUSH instruction supported)
                        DS (Debug store)
                        ACPI (ACPI supported)
                        MMX (MMX technology supported)
                        FXSR (Fast floating-point save and restore)
                        SSE (Streaming SIMD extensions)
                        SSE2 (Streaming SIMD extensions 2)
                        SS (Self-snoop)
                        HTT (Hyper-threading technology)
                        TM (Thermal monitor supported)
                        PBE (Pending break enabled)
                Version: Intel(R) Pentium(R) 4 CPU 3.00GHz
                Voltage: 1.2 V
                External Clock: 200 MHz
                Max Speed: 3800 MHz
                Current Speed: 3000 MHz
                Status: Populated, Enabled
                Upgrade: Socket 478
                L1 Cache Handle: 0x0005
                L2 Cache Handle: 0x0006
                L3 Cache Handle: Not Provided
                Serial Number:
                Asset Tag:
                Part Number:
Handle 0x0005
        DMI type 7, 19 bytes.
        Cache Information
                Socket Designation: L1 Cache for CPU#1
                Configuration: Enabled, Not Socketed, Level 1
                Operational Mode: Write Back
                Location: Internal
                Installed Size: 16 KB
                Maximum Size: 16 KB
                Supported SRAM Types:
                        Burst
                        Synchronous
                Installed SRAM Type: Synchronous
                Speed: Unknown
                Error Correction Type: Parity
                System Type: Data
                Associativity: 4-way Set-associative
Handle 0x0006
        DMI type 7, 19 bytes.
        Cache Information
                Socket Designation: L2 Cache for CPU#1
                Configuration: Enabled, Not Socketed, Level 2
                Operational Mode: Write Back
                Location: Internal
                Installed Size: 2048 KB
                Maximum Size: 2048 KB
                Supported SRAM Types:
                        Burst
                        Synchronous
                Installed SRAM Type: Burst
                Speed: Unknown
                Error Correction Type: Single-bit ECC
                System Type: Unknown
                Associativity: 8-way Set-associative
Handle 0x0007
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: Not Specified
                Internal Connector Type: None
                External Reference Designator: 1(Serial ICON)
                External Connector Type: DB-9 male
                Port Type: Serial Port 16550A Compatible
Handle 0x0008
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: COM2
                Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
                External Reference Designator: 2(Serial ICON)
                External Connector Type: DB-9 male
                Port Type: Serial Port 16550A Compatible
Handle 0x0009
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: Not Specified
                Internal Connector Type: None
                External Reference Designator: (Parallel ICON)
                External Connector Type: DB-25 female
                Port Type: Parallel Port ECP/EPP
Handle 0x000A
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: Not Specified
                Internal Connector Type: None
                External Reference Designator: (Keyboard ICON)
                External Connector Type: PS/2
                Port Type: Keyboard Port
Handle 0x000B
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: Not Specified
                Internal Connector Type: None
                External Reference Designator: (Mouse ICON)
                External Connector Type: PS/2
                Port Type: Mouse Port
Handle 0x000C
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: FDC1
                Internal Connector Type: On Board Floppy
                External Reference Designator: (Floppy ICON)
                External Connector Type: None
                Port Type: Other
Handle 0x000D
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: IDE1
                Internal Connector Type: On Board IDE
                External Reference Designator: 1(IDE ICON)
                External Connector Type: None
                Port Type: Other
Handle 0x000E
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: SATA1
                Internal Connector Type: Other
                External Reference Designator: 1(S-ATA ICON)
                External Connector Type: None
                Port Type: Other
Handle 0x000F
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: SATA2
                Internal Connector Type: Other
                External Reference Designator: 2(S-ATA ICON)
                External Connector Type: None
                Port Type: Other
Handle 0x0010
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: SATA3
                Internal Connector Type: Other
                External Reference Designator: 3(S-ATA ICON)
                External Connector Type: None
                Port Type: Other
Handle 0x0011
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: SATA4
                Internal Connector Type: Other
                External Reference Designator: 4(S-ATA ICON)
                External Connector Type: None
                Port Type: Other
Handle 0x0012
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: Not Specified
                Internal Connector Type: None
                External Reference Designator: 1(Network ICON)
                External Connector Type: RJ-45
                Port Type: Network Port
Handle 0x0013
        DMI type 126, 9 bytes.
        Inactive
Handle 0x0014
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: Not Specified
                Internal Connector Type: None
                External Reference Designator: 1(USB ICON)
                External Connector Type: Access Bus (USB)
                Port Type: USB
Handle 0x0015
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: Not Specified
                Internal Connector Type: None
                External Reference Designator: 2(USB ICON)
                External Connector Type: Access Bus (USB)
                Port Type: USB
Handle 0x0016
        DMI type 126, 9 bytes.
        Inactive
Handle 0x0017
        DMI type 8, 9 bytes.
        Port Connector Information
                Internal Reference Designator: Not Specified
                Internal Connector Type: None
                External Reference Designator: (Video ICON)
                External Connector Type: DB-15 female
                Port Type: Video Port
Handle 0x0018
        DMI type 9, 13 bytes.
        System Slot Information
                Designation: PCI-1
                Type: 64-bit PCI-X
                Current Usage: In Use
                Length: Long
                ID: 1
                Characteristics:
                        3.3 V is provided
                        PME signal is supported
                        SMBus signal is supported
Handle 0x0019
        DMI type 9, 13 bytes.
        System Slot Information
                Designation: PCI-2
                Type: 64-bit PCI-X
                Current Usage: Available
                Length: Long
                ID: 2
                Characteristics:
                        3.3 V is provided
                        PME signal is supported
                        SMBus signal is supported
Handle 0x001A
        DMI type 9, 13 bytes.
        System Slot Information
                Designation: PCI-3
                Type: Other
                Current Usage: Available
                Length: Short
                Characteristics: Unknown
Handle 0x001B
        DMI type 9, 13 bytes.
        System Slot Information
                Designation: PCI-4
                Type: Other
                Current Usage: Unknown
                Length: Short
                Characteristics: Unknown
Handle 0x001C
        DMI type 9, 13 bytes.
        System Slot Information
                Designation: PCI-5
                Type: 32-bit PCI
                Current Usage: Available
                Length: Short
                ID: 5
                Characteristics:
                        5.0 V is provided
                        PME signal is supported
                        SMBus signal is supported
Handle 0x001D
        DMI type 10, 8 bytes.
        On Board Device 1 Information
                Type: Ethernet
                Status: Enabled
                Description: LAN1
        On Board Device 2 Information
                Type: Video
                Status: Enabled
                Description: VGA
Handle 0x001E
        DMI type 126, 6 bytes.
        Inactive
Handle 0x001F
        DMI type 11, 5 bytes.
        OEM Strings
                String 1:
                String 2:
Handle 0x0020
        DMI type 12, 5 bytes.
        System Configuration Options
                Option 1: RECOVERY: Close to run BIOS recovery
                Option 2: PASSWORD: Close to clear Password
                Option 3: TIME_HL: Close to stop FRB3 Timer
                Option 4: CLR_CMOS1: Close to clear CMOS
Handle 0x0021
        DMI type 13, 22 bytes.
        BIOS Language Information
                Installable Languages: 5
                        en|US|iso8859-1
                        fr|FR|iso8859-1
                        de|DE|iso8859-1
                        es|ES|iso8859-1
                        it|IT|iso8859-1
                Currently Installed Language: en|US|iso8859-1
Handle 0x0022
        DMI type 16, 15 bytes.
        Physical Memory Array
                Location: System Board Or Motherboard
                Use: System Memory
                Error Correction Type: Single-bit ECC
                Maximum Capacity: 4 GB
                Error Information Handle: No Error
                Number Of Devices: 4
Handle 0x0023
        DMI type 17, 27 bytes.
        Memory Device
                Array Handle: 0x0022
                Error Information Handle: No Error
                Total Width: Unknown
                Data Width: Unknown
                Size: No Module Installed
                Form Factor: DIMM
                Set: 1
                Locator: DIMM 1
                Bank Locator: BANK 1
                Type: Other
                Type Detail: Synchronous
                Speed: Unknown
                Manufacturer:
                Serial Number:
                Asset Tag:
                Part Number:
Handle 0x0024
        DMI type 17, 27 bytes.
        Memory Device
                Array Handle: 0x0022
                Error Information Handle: No Error
                Total Width: 72 bits
                Data Width: 64 bits
                Size: 512 MB
                Form Factor: DIMM
                Set: 2
                Locator: DIMM 2
                Bank Locator: BANK 2
                Type: Other
                Type Detail: Synchronous
                Speed: 533 MHz (1.9 ns)
                Manufacturer:
                Serial Number:
                Asset Tag:
                Part Number:
Handle 0x0025
        DMI type 17, 27 bytes.
        Memory Device
                Array Handle: 0x0022
                Error Information Handle: No Error
                Total Width: Unknown
                Data Width: Unknown
                Size: No Module Installed
                Form Factor: DIMM
                Set: 3
                Locator: DIMM 3
                Bank Locator: BANK 3
                Type: Other
                Type Detail: Synchronous
                Speed: Unknown
                Manufacturer:
                Serial Number:
                Asset Tag:
                Part Number:
Handle 0x0026
        DMI type 17, 27 bytes.
        Memory Device
                Array Handle: 0x0022
                Error Information Handle: No Error
                Total Width: 72 bits
                Data Width: 64 bits
                Size: 512 MB
                Form Factor: DIMM
                Set: 4
                Locator: DIMM 4
                Bank Locator: BANK 4
                Type: Other
                Type Detail: Synchronous
                Speed: 533 MHz (1.9 ns)
                Manufacturer:
                Serial Number:
                Asset Tag:
                Part Number:
Handle 0x0027
        DMI type 126, 23 bytes.
        Inactive
Handle 0x0028
        DMI type 18, 23 bytes.
        32-bit Memory Error Information
                Type: OK
                Granularity: Unknown
                Operation: Unknown
                Vendor Syndrome: Unknown
                Memory Array Address: Unknown
                Device Address: Unknown
                Resolution: Unknown
Handle 0x0029
        DMI type 126, 23 bytes.
        Inactive
Handle 0x002A
        DMI type 18, 23 bytes.
        32-bit Memory Error Information
                Type: OK
                Granularity: Unknown
                Operation: Unknown
                Vendor Syndrome: Unknown
                Memory Array Address: Unknown
                Device Address: Unknown
                Resolution: Unknown
Handle 0x002B
        DMI type 19, 15 bytes.
        Memory Array Mapped Address
                Starting Address: 0x00000000000
                Ending Address: 0x0003FFFFFFF
                Range Size: 1 GB
                Physical Array Handle: 0x0022
                Partition Width: 0
Handle 0x002C
        DMI type 20, 19 bytes.
        Memory Device Mapped Address
                Starting Address: 0x00000000000
                Ending Address: 0x000000003FF
                Range Size: 1 kB
                Physical Device Handle: 0x0023
                Memory Array Mapped Address Handle: 0x002B
                Partition Row Position: Unknown
                Interleave Position: Unknown
                Interleaved Data Depth: Unknown
Handle 0x002D
        DMI type 20, 19 bytes.
        Memory Device Mapped Address
                Starting Address: 0x00000000000
                Ending Address: 0x0001FFFFFFF
                Range Size: 512 MB
                Physical Device Handle: 0x0024
                Memory Array Mapped Address Handle: 0x002B
                Partition Row Position: Unknown
                Interleave Position: Unknown
                Interleaved Data Depth: Unknown
Handle 0x002E
        DMI type 20, 19 bytes.
        Memory Device Mapped Address
                Starting Address: 0x0001FFFFC00
                Ending Address: 0x0001FFFFFFF
                Range Size: 1 kB
                Physical Device Handle: 0x0025
                Memory Array Mapped Address Handle: 0x002B
                Partition Row Position: Unknown
                Interleave Position: Unknown
                Interleaved Data Depth: Unknown
Handle 0x002F
        DMI type 20, 19 bytes.
        Memory Device Mapped Address
                Starting Address: 0x00020000000
                Ending Address: 0x0003FFFFFFF
                Range Size: 512 MB
                Physical Device Handle: 0x0026
                Memory Array Mapped Address Handle: 0x002B
                Partition Row Position: Unknown
                Interleave Position: Unknown
                Interleaved Data Depth: Unknown
Handle 0x0030
        DMI type 24, 5 bytes.
        Hardware Security
                Power-On Password Status: Disabled
                Keyboard Password Status: Unknown
                Administrator Password Status: Disabled
                Front Panel Reset Status: Unknown
Handle 0x0031
        DMI type 32, 11 bytes.
        System Boot Information
                Status: No errors detected
Handle 0x0032
        DMI type 34, 11 bytes.
        Management Device
                Description: Winbond W83792D
                Type: Other
                Address: 0x0000005C
                Address Type: SMBus
Handle 0x0033
        DMI type 127, 4 bytes.
        End Of Table
-------------- next part --------------
oden:~# lspci -v -v -v
0000:00:00.0 Host bridge: Intel Corp.: Unknown device 2778 (rev 81)
        Subsystem: Giga-byte Technology: Unknown device 2778
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSELúst >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Capabilities: [e0] #09 [4109]

0000:00:01.0 PCI bridge: Intel Corp.: Unknown device 2779 (rev 81) (prog-if 00 [Normal decode])
        Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x08 (32 bytes)
        Bus: primary\0, secondary\x01, subordinate\x01, sec-latency=0
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: fff00000-000fffff
        Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
        BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
        Capabilities: [88] #0d [0000]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable-
                Address: 00000000  Data: 0000
        Capabilities: [a0] #10 [0141]

0000:00:1c.0 PCI bridge: Intel Corp.: Unknown device 27d0 (rev 01) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x08 (32 bytes)
        Bus: primary\0, secondary\x02, subordinate\x03, sec-latency=0
        I/O behind bridge: 00004000-00004fff
        Memory behind bridge: d8000000-d89fffff
        Prefetchable memory behind bridge: 0000000050000000-0000000050000000
        BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
        Capabilities: [40] #10 [0141]
        Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
                Address: fee02004  Data: 40c1
        Capabilities: [90] #0d [0000]
        Capabilities: [a0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:1c.4 PCI bridge: Intel Corp.: Unknown device 27e0 (rev 01) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x08 (32 bytes)
        Bus: primary\0, secondary\x04, subordinate\x04, sec-latency=0
        I/O behind bridge: 00005000-00005fff
        Memory behind bridge: d8a00000-d8afffff
        Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
        BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
        Capabilities: [40] #10 [0141]
        Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
                Address: fee02004  Data: 40c9
        Capabilities: [90] #0d [0000]
        Capabilities: [a0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:1c.5 PCI bridge: Intel Corp.: Unknown device 27e2 (rev 01) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x08 (32 bytes)
        Bus: primary\0, secondary\x05, subordinate\x05, sec-latency=0
        I/O behind bridge: 00006000-00006fff
        Memory behind bridge: d8b00000-d8bfffff
        Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
        BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
        Capabilities: [40] #10 [0141]
        Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+
                Address: fee02004  Data: 40d1
        Capabilities: [90] #0d [0000]
        Capabilities: [a0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:1d.0 USB Controller: Intel Corp.: Unknown device 27c8 (rev 01) (prog-if 00 [UHCI])
        Subsystem: Giga-byte Technology: Unknown device 27c8
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 233
        Region 4: I/O ports at 3000 [size2]

0000:00:1d.1 USB Controller: Intel Corp.: Unknown device 27c9 (rev 01) (prog-if 00 [UHCI])
        Subsystem: Giga-byte Technology: Unknown device 27c9
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 217
        Region 4: I/O ports at 3020 [size2]

0000:00:1d.2 USB Controller: Intel Corp.: Unknown device 27ca (rev 01) (prog-if 00 [UHCI])
        Subsystem: Giga-byte Technology: Unknown device 27ca
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin C routed to IRQ 50
        Region 4: I/O ports at 3040 [size2]

0000:00:1d.3 USB Controller: Intel Corp.: Unknown device 27cb (rev 01) (prog-if 00 [UHCI])
        Subsystem: Giga-byte Technology: Unknown device 27cb
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin D routed to IRQ 169
        Region 4: I/O ports at 3060 [size2]

0000:00:1d.7 USB Controller: Intel Corp.: Unknown device 27cc (rev 01) (prog-if 20 [EHCI])
        Subsystem: Giga-byte Technology: Unknown device 27cc
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 233
        Region 0: Memory at d8f00000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent75mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] #0a [20a0]

0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev e1) (prog-if 01 [Subtractive decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary\0, secondary
, subordinate
, sec-latency2
        I/O behind bridge: 00007000-00007fff
        Memory behind bridge: d8c00000-d8cfffff
        Prefetchable memory behind bridge: 00000000d0000000-00000000d7f00000
        BridgeCtl: Parity+ SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
        Capabilities: [50] #0d [0000]

0000:00:1f.0 ISA bridge: Intel Corp.: Unknown device 27b8 (rev 01)
        Subsystem: Giga-byte Technology: Unknown device 27b0
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [e0] #09 [100c]

0000:00:1f.2 IDE interface: Intel Corp.: Unknown device 27c0 (rev 01) (prog-if 80 [Master])
        Subsystem: Giga-byte Technology: Unknown device 27c0
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 217
        Region 0: I/O ports at <unassigned>
        Region 1: I/O ports at <unassigned>
        Region 2: I/O ports at <unassigned>
        Region 3: I/O ports at <unassigned>
        Region 4: I/O ports at 30b0 [size\x16]
        Capabilities: [70] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:1f.3 SMBus: Intel Corp.: Unknown device 27da (rev 01)
        Subsystem: Giga-byte Technology: Unknown device 27da
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin B routed to IRQ 10
        Region 4: I/O ports at 3080 [size2]

0000:02:00.0 PCI bridge: Intel Corp. PCI Bridge Hub (rev 09) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x10 (64 bytes)
        Bus: primary\x02, secondary\x03, subordinate\x03, sec-latencyH
        I/O behind bridge: 00004000-00004fff
        Memory behind bridge: d8000000-d88fffff
        Prefetchable memory behind bridge: 0000000050000000-0000000050000000
        BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
        Capabilities: [44] #10 [0071]
        Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [6c] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [d8]
0000:02:00.1 PIC: Intel Corp. PCI Bridge Hub I/OxAPIC Interrupt Controller A (rev 09) (prog-if 20 [IO(X)-APIC])
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Region 0: Memory at d8900000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] #10 [0001]
        Capabilities: [6c] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:03:01.0 RAID bus controller: 3ware Inc 3ware 7000-series ATA-RAID (rev 01)
        Subsystem: 3ware Inc 3ware Inc 3ware 7xxx/8xxx-series PATA/SATA-RAID
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 72 (2250ns min), Cache Line Size: 0x08 (32 bytes)
        Interrupt: pin A routed to IRQ 225
        Region 0: I/O ports at 4000 [size\x16]
        Region 1: Memory at d8800000 (32-bit, non-prefetchable) [size\x16]
        Region 2: Memory at d8000000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at 50000000 [disabled] [sizedK]
        Capabilities: [40] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:04:00.0 Ethernet controller: Intel Corp.: Unknown device 108b (rev 03)
        Subsystem: Giga-byte Technology: Unknown device 108b
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x10 (64 bytes)
        Interrupt: pin A routed to IRQ 58
        Region 0: Memory at d8a00000 (32-bit, non-prefetchable) [size\x128K]
        Region 2: I/O ports at 5000 [size2]
        Capabilities: [c8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+
                Address: 00000000fee01004  Data: 403a
        Capabilities: [e0] #10 [0001]

0000:05:00.0 Ethernet controller: Intel Corp.: Unknown device 108b (rev 03)
        Subsystem: Giga-byte Technology: Unknown device 108b
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSELúst >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x10 (64 bytes)
        Interrupt: pin A routed to IRQ 66
        Region 0: Memory at d8b00000 (32-bit, non-prefetchable) [size\x128K]
        Region 2: I/O ports at 6000 [size2]
        Capabilities: [c8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+
                Address: 00000000fee02004  Data: 4042
        Capabilities: [e0] #10 [0001]

0000:0a:03.0 VGA compatible controller: ATI Technologies Inc: Unknown device 515e (rev 01) (prog-if 00 [VGA])
        Subsystem: Giga-byte Technology: Unknown device 515e
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 66 (2000ns min), Cache Line Size: 0x08 (32 bytes)
        Interrupt: pin A routed to IRQ 74
        Region 0: Memory at d0000000 (32-bit, prefetchable) [size\x128M]
        Region 1: I/O ports at 7000 [size%6]
        Region 2: Memory at d8c00000 (32-bit, non-prefetchable) [sizedK]
        Expansion ROM at d8c20000 [disabled] [size\x128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Rudolf Marek]

Hi all,

> Back from vacationing, time to get this issue resolved :-)
Good.

> Sounds like I should put some pressure on Gigabyte to fix the route
> cause, I don't think we will be able to do so but since this is a
> server motherboard one would think the Gigabyte should be interested
> in fixing the root cause... I'll try and let you all know how that goes.
>

OK thanks. I'm just curious how did you contact them via standard support for on their pages?
Maybe you have some VIP support?
> So setpci seems to work:
Good.
> After shutting off that bit 14 for enabling SMI on GPIO7 that machine
> does not hang any longer! I've tried a couple things that used to make
> the machine hang and none of them did any harm any longer! To prove
> that a different way I re-enabled that bit again using 
> 
> setpci -s 00:1f.0 b8.l\x18014000
> 
> which caused the machine to hang right away (ie, the setpci command
> didn't return). Looks like we might have a workaround!

Perhaps the SMI was already asserted so it just went through when it was enabled.

> 
> The output of dmidecode and lspci -v -v -v is attached since it is
> rather long. 
> 

Good thanks.

> oden:~# dmidecode
OT: Gods should not have broken SMI...

I have developed a quirk to linux kernel. Please see the attachment. It compiles and thats all I know ;)
If it works you should see in kernel syslog/messages that the Gigabyte motherboard was detected (see the code for
actual messages)

If it produces correct message please try to hang it again. If it produces correct message and hangs I missed something
in the PCI handling routine. (But I think it should be OK)

If you cant see any message it means that the DMI detection is not working. Please look to dmi.h file and
find a combination that works for you (hint: use the dmidecode output to get values)
(for example leave only the manufacturer field or try different macro DMI_MATCH(something else here)

The patch is against 2.6.15 but it should work with earlier versions too.
It will work in both 32 bit and 64bit kernel mode.

Lycka till ;)

Thanks,

Regads
Rudolf
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: giga_smi
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060107/0a70dfe1/giga_smi.pl

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi All,

On Sat, Jan 07, 2006 at 09:42:44PM +0100, Rudolf Marek wrote:
> OK thanks. I'm just curious how did you contact them via standard
> support for on their pages?  Maybe you have some VIP support?

No, just standard support... I'm surprised to get an answer actually,
which probably speaks more about my low expectations on these kinds of
support sites;

http://tw.giga-byte.com/Company/ContactUs/contact_us.htm


> > After shutting off that bit 14 for enabling SMI on GPIO7 that machine
> > does not hang any longer! I've tried a couple things that used to make
> > the machine hang and none of them did any harm any longer! To prove
> > that a different way I re-enabled that bit again using 
> > 
> > setpci -s 00:1f.0 b8.l\x18014000
> > 
> > which caused the machine to hang right away (ie, the setpci command
> > didn't return). Looks like we might have a workaround!
> 
> Perhaps the SMI was already asserted so it just went through when it was enabled.

Yes, that is my theory as well.

> 
> I have developed a quirk to linux kernel. Please see the
> attachment. It compiles and thats all I know ;) If it works you
> should see in kernel syslog/messages that the Gigabyte motherboard
> was detected (see the code for actual messages)

Well I can tell that is works too! 

dmesg | grep -i giga
Gigabyte GA-4MXSV motherboard detected:<4>Disabling SMI routing from W83792D.

While looking for this I also noticed that the following quirk is
activated on this motherboard:

PCI: PXH quirk detected, disabling MSI for SHPC device

But I concluded that MSI in this regard is the interrupt handling used
on PCI-Express which should be completely irrelevant to the problems
we have been debugging here.

> If it produces correct message please try to hang it again. If it
> produces correct message and hangs I missed something in the PCI
> handling routine. (But I think it should be OK)

It works fine, it is detected and bit 14 is cleared. The machine does
not hang any longer.

> The patch is against 2.6.15 but it should work with earlier versions too.
> It will work in both 32 bit and 64bit kernel mode.

I used it against 2.6.14 to not introduce a new kernel version in the
mix. Applied and compiled just fine.

> Lycka till ;)

Tack s? mycket f?r hj?lpen :-)

Now this pretty much solved this issue for me, but I'm wondering if we
should give Gigabyte a week or two to respond to my request to have
them debug the root cause? If they don't want to do that I guess we
could consider this patch to be required in order to use the sensor
devices on this motherboard....

Best Reagards
-- 
Daniel Nilsson

[lm-sensors] Kernel hangs with i2c-i801 driver?

[Daniel Nilsson]

Hi All,

On Sun, Jan 08, 2006 at 03:31:59PM +0100, Daniel Nilsson wrote:
> Now this pretty much solved this issue for me, but I'm wondering if we
> should give Gigabyte a week or two to respond to my request to have
> them debug the root cause? If they don't want to do that I guess we
> could consider this patch to be required in order to use the sensor
> devices on this motherboard....

So I received another answer from Gigabyte, but not a very conclusive
one;

"Hi Daniel,

Thank you for the feedback and offer. We have forwarded your message
and request to our headquarters but have not heard any response from
them yet.

Thus, we are not sure if they plan to disable GPI7 SMI code excution
in the future BIOS release. Becuase it might affect other functions
when the codes are disabled.

We will keep you informed if we received a new BIOS release to work
around this issue. Otherwise, please check our web site for new
versions periodically.

Best regards,

GBT Tech Support"

Sounds like they want to close the ticket... I guess we could still
wait for a new more weeks before submitting the patch, but I'm not
sure that will pay off. Maybe Gigabyte is off investigating this? Who
knows...

Regards
-- 
Daniel Nilsson