System hanging using CSB5 chip with 2.8.1

System hanging using CSB5 chip with 2.8.1

[Don Jessup]

  When doing a sensors-detect the system just ends up hanging.
  

  1. Output from sensors-detect.
  2. output from lsmod
  3. output from lspci, I don't know if it is a 
       pci problem but here is info anyway
  4. output from i2cdetect, which also caused the system to hang
  5. Motherboard type: Super X5DL8-GG
  6. Sensors Version: 2.8.1
  7. Kernel Version: 2.4.22 with 2.8.1 patch 
  8. Numbers of the ServerWork Chip on the Super X5DL8-GG mother board
     SWC-S137440-P01
     0243PU603
  

This is output of sensors-detect after the system hangs.
1. #############################################################
  
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.

 BIOS vendor (ACPI): AMI
 System vendor (DMI): Supermicro                                        .
 BIOS version (DMI): 0700xx
 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): YES
Probing for PCI bus adapters...
Use driver `i2c-piix4' for device 00:0f.0: ServerWorks CSB5 South Bridge
Probe succesfully concluded.

 We will now try to load each adapter module in turn.
Load `i2c-piix4' (say NO if built into your kernel)? (YES/no): YES
Module loaded succesfully.
 Do you now want to be prompted for non-detectable adapters? (yes/NO): NO
 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 not loaded. Do you want to load it now? (YES/no): YES
 Module loaded succesfully.

 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 PIIX4 adapter at 0580 (Non-I2C SMBus adapter)
Do you want to scan it? (YES/no/selectively): selectively
Please enter one or more addresses not to scan. Separate them with comma's.
You can specify a range by using dashes. Addresses may be decimal (like 54)
or hexadecimal (like 0x33).
Addresses: 0x69


2. #############################################################

Module                  Size  Used by    Tainted: PF
i2c-dev                 5184   0  (unused)
i2c-piix4               4488   0  (unused)
dmi_scan                2148   0  [i2c-piix4]
i2c-core               20324   0  [i2c-dev i2c-piix4]
iscsih                110200   0  (unused)
vtarget               239328   0  [iscsih]
sd_mod                 13068   0  (autoclean) (unused)
mptstm                 24688   1  [vtarget]
mptbase                36000   1  [mptstm]
dmdbcdrv               31168   0
ioMetaDevice           92512   0  [vtarget mptstm]
mapdevice              29912   0  (unused)
3w-xxxx                37344   0
autofs                 12372   0  (autoclean) (unused)
tg3                    46344   0  (unused)
e1000                  68192   1
ipt_REJECT              4024   6  (autoclean)
iptable_filter          2316   1  (autoclean)
ip_tables              15072   2  [ipt_REJECT iptable_filter]
microcode               4540   0  (autoclean)
ide-scsi               11280   0
scsi_mod              104212   5  [iscsih vtarget sd_mod 3w-xxxx ide-scsi]
ide-cd                 33632   0
cdrom                  30976   0  [ide-cd]
keybdev                 2688   0  (unused)
mousedev                5300   1
hid                    23172   0  (unused)
input                   5568   0  [keybdev mousedev hid]
usb-ohci               20520   0  (unused)
usbcore                72768   1  [dmdbcdrv hid usb-ohci]
ext3                   64996   6
jbd                    48724   6  [ext3]
raid1                  14604   6


3. ##############################################################

00:00.0 Class 0600: 1166:0014 (rev 31)
00:00.1 Class 0600: 1166:0014
00:00.2 Class 0600: 1166:0014
00:02.0 Class 0300: 1002:4752 (rev 27)
00:04.0 Class 0200: 8086:100e (rev 02)
00:0f.0 Class 0601: 1166:0201 (rev 93)
00:0f.1 Class 0101: 1166:0212 (rev 93)
00:0f.2 Class 0c03: 1166:0220 (rev 05)
00:0f.3 Class 0600: 1166:0225
00:10.0 Class 0600: 1166:0101 (rev 03)
00:10.2 Class 0600: 1166:0101 (rev 03)
00:11.0 Class 0600: 1166:0101 (rev 03)
00:11.2 Class 0600: 1166:0101 (rev 03)
01:02.0 Class 0c04: 1000:0622 (rev 02)
01:02.1 Class 0c04: 1000:0622 (rev 02)
01:03.0 Class 0200: 14e4:16a7 (rev 02)
02:02.0 Class 0104: 13c1:1001 (rev 01)
02:03.0 Class 0104: 13c1:1001 (rev 01)
03:02.0 Class 0104: 13c1:1001 (rev 01)
03:03.0 Class 0104: 13c1:1001 (rev 01)
04:03.0 Class 0100: 9005:801f (rev 03)
04:03.1 Class 0100: 9005:801f (rev 03)


4. ##############################################################

  WARNING! This program can confuse your I2C bus, cause data loss and worse!
  I will probe file /dev/i2c-0
  You have five seconds to reconsider and press CTRL-C!

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f


==Don Jessup
Asaca/Shibasoku Corp. of America
400 Corporate Circle, Unit G
Golden, CO  80401
303-278-1111 X232
donj@asaca.com
http://www.asaca.com

System hanging using CSB5 chip with 2.8.1

[Jean Delvare]

>   When doing a sensors-detect the system just ends up hanging.
> (...)
>   6. Sensors Version: 2.8.1

Probably caused by a bad wordaround introduced in the i2c-piix4 module.
I commited a fix to our CVS repository a few years ago. Please check
lm_sensors2 out (see
http://secure.netroedge.com/~lm78/download.html#cvs) and give it a try
(don't forget to unload old modules before trying to load them anew).

You do not need to change anything to i2c, updating lm_sensors2 is
enough.

If it still doesn't work, let us know.

And if it does work, let us know too, please :)

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

System hanging using CSB5 chip with 2.8.1 - No longer

[Don Jessup]

  Thanks Jean,
 
   Using both latest cvs i2c and lm_sensors2.  I was able to get it to work.

  
  I do however have another problem.  I using a dual xeon cpu Super X5DL8-GG 
  motherboard and according to the "sensors"  program one of the CPUs is 
  reporting
  back some invalid numbers as when compared to the BIOS.  For instance, when
  looking at the chip ( sensor information is below )  lm87-i2c-0-2d the fan1
is 
  reporting back 0 RPMs but looking at the
  motherboard I can see that it is clearly spinning.  When viewing the BIOS
  fan RPM info two values are reported, one for each CPU.  How do I get the
  lm87-i2c-0-2d report identical information as lm87-i2c-0-2e chip.  


  I also notice that several of the voltage values for lm87-i2c-0-2d chip
  is different then lm87-i2c-0-2e.  The BIOS only reports only one set of
  voltage values for both CPUs( is this typical of a dual motherboard system?)
  The voltage values that are reported by the BIOS are almost identicle to the
  values reported by lm87-i2c-0-2e.  Can I safely assume that voltage values
  reported by lm87-i2c-0-2d can be ignored?  


   After reading the documentation for both chips it is still not clear to
   me what is the difference between the chips adm1021* and lm87* CPU
   temperatures. Any ideas?
  

   

  The i2c and lm_sensors2 I'm using is out of CVS as of Nov 25.  I'm running
  2.4.22 kernel with 2.8.1 patch.   


  1.  lsmod output.  I have loaded the adm1021 module with
      force_adm1021=0,0x18,0,0x29

  2.  output from sensors.  

  3.  I'm using the default sensors.conf

 1.  lsmod info 
###############################################################################
[root@Hercules sensors]# lsmod
Module                  Size  Used by    Not tainted
lm87                    7328   0  (unused)
adm1021                 6996   0  (unused)
i2c-proc                8084   1  [lm87 adm1021]
i2c-piix4               4584   0
dmi_scan                2148   0  [i2c-piix4]
i2c-core               20324   0  [lm87 adm1021 i2c-proc i2c-piix4]
autofs                 12756   0  (autoclean) (unused)
tg3                    48552   0  (unused)
e1000                  68768   1
ipt_REJECT              4024   6  (autoclean)
iptable_filter          2316   1  (autoclean)
ip_tables              15840   2  [ipt_REJECT iptable_filter]
microcode               5056   0  (autoclean)
ide-scsi               11408   0
scsi_mod              107412   1  [ide-scsi]
ide-cd                 33728   0
cdrom                  31424   0  [ide-cd]
keybdev                 2688   0  (unused)
mousedev                5400   1
hid                    23236   0  (unused)
input                   5984   0  [keybdev mousedev hid]
usb-ohci               21288   0  (unused)
usbcore                76352   1  [hid usb-ohci]
ext3                   67940   6
jbd                    52880   6  [ext3]
raid1                  15724   6

2  sensors info
##############################################################################
[root@Hercules sensors]# sensors
adm1021-i2c-0-18
Adapter: SMBus PIIX4 adapter at 0580
Algorithm: Non-I2C SMBus adapter
Board:       +31?C  (low  =   -55?C, high =  +127?C)
CPU:         +33?C  (low  =    +0?C, high =   +85?C)
die_code:  255

adm1021-i2c-0-29
Adapter: SMBus PIIX4 adapter at 0580
Algorithm: Non-I2C SMBus adapter
Board:       +31?C  (low  =   -55?C, high =  +127?C)
CPU:         +34?C  (low  =    +0?C, high =   +85?C)
die_code:  255

lm87-i2c-0-2d
Adapter: SMBus PIIX4 adapter at 0580
Algorithm: Non-I2C SMBus adapter
2.5V:      +0.00 V  (min =  +0.00 V, max =  +0.00 V)
Vccp1:     +0.00 V  (min =  +0.00 V, max =  +0.00 V)
3.3V:      +3.26 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
5V:        +2.99 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
12V:      +12.12 V  (min =  +0.00 V, max =  +0.00 V)   ALARM
Vccp2:     +0.00 V  (min =  +0.00 V, max =  +0.00 V)
fan1:        0 RPM  (min = 2848 RPM, div = 2)          ALARM
fan2:        0 RPM  (min = 2848 RPM, div = 2)          ALARM
temp1:       +39?C  (low  =    +0?C, high =   +65?C)
CPU_Temp:   +128?C  (low  =    +0?C, high =    +0?C)    FAULT
vid:       +2.05 V

lm87-i2c-0-2e
Adapter: SMBus PIIX4 adapter at 0580
Algorithm: Non-I2C SMBus adapter
2.5V:      +2.52 V  (min =  +2.12 V, max =  +2.87 V)
Vccp1:     +1.47 V  (min =  +0.98 V, max =  +1.99 V)
3.3V:      +3.26 V  (min =  +2.80 V, max =  +3.78 V)
5V:        +4.94 V  (min =  +4.24 V, max =  +5.75 V)
12V:      +12.00 V  (min = +10.18 V, max = +13.81 V)
Vccp2:     +1.50 V  (min =  +1.26 V, max =  +1.71 V)
fan1:     5400 RPM  (min = 2848 RPM, div = 2)
fan2:     5487 RPM  (min = 2848 RPM, div = 2)
temp1:       +37?C  (low  =    +0?C, high =   +65?C)
CPU_Temp:   +128?C  (low  =   +80?C, high =   +85?C)    FAULT
vid:       +1.35 V




--- Jean Delvare <khali@linux-fr.org> wrote:
> 
> >   When doing a sensors-detect the system just ends up hanging.
> > (...)
> >   6. Sensors Version: 2.8.1
> 
> Probably caused by a bad wordaround introduced in the i2c-piix4 module.
> I commited a fix to our CVS repository a few years ago. Please check
> lm_sensors2 out (see
> http://secure.netroedge.com/~lm78/download.html#cvs) and give it a try
> (don't forget to unload old modules before trying to load them anew).
> 
> You do not need to change anything to i2c, updating lm_sensors2 is
> enough.
> 
> If it still doesn't work, let us know.
> 
> And if it does work, let us know too, please :)
> 
> -- 
> Jean Delvare
> http://www.ensicaen.ismra.fr/~delvare/
> 
> 
> 
> 


==Don Jessup
Asaca/Shibasoku Corp. of America
400 Corporate Circle, Unit G
Golden, CO  80401
303-278-1111 X232
donj@asaca.com
http://www.asaca.com

System hanging using CSB5 chip with 2.8.1 - No longer

[Jean Delvare]

> I do however have another problem.  I using a dual xeon cpu Super
> X5DL8-GG motherboard and according to the "sensors"  program one of
> the CPUs is reporting back some invalid numbers as when compared to
> the BIOS.  For instance, when looking at the chip ( sensor information
> is below ) lm87-i2c-0-2d the fan1 is reporting back 0 RPMs but looking
> at the motherboard I can see that it is clearly spinning. When
> viewing the BIOS fan RPM info two values are reported, one for each
> CPU.  How do I get the lm87-i2c-0-2d report identical information as
> lm87-i2c-0-2e chip.

Frankly, I don't think this is an LM87 at 0x2d. The one at 0x2e seems to
be valid, but the data at 0x2d is just crap.

> I also notice that several of the voltage values for lm87-i2c-0-2d
> chip is different then lm87-i2c-0-2e.  The BIOS only reports only
> one set of voltage values for both CPUs( is this typical of a dual
> motherboard system?) The voltage values that are reported by the
> BIOS are almost identicle to the values reported by lm87-i2c-0-2e. 
> Can I safely assume that voltage values reported by lm87-i2c-0-2d
> can be ignored?

Apart from temp1, there's nothing valid at 0x2d. I'm not an expert in
dual-cpu systems (never owned one myself) but it doesn't make sense to
have two sets of voltage measurements on such systems. I would bet there
is a single chipset for theses (at 0x2e obviously).

> After reading the documentation for both chips it is still not
> clear to me what is the difference between the chips adm1021* and
> lm87* CPU temperatures. Any ideas?

The LM87 at 0x2e is your main monitoring chipset. Since it doesn't
provide external channels for temperature measurement, the board maker
added a temperature-only chipset for each CPU. These are the two ADM1021
chipsets.

>   1.  lsmod output.  I have loaded the adm1021 module with
>       force_adm1021=0,0x18,0,0x29

Why did you use that force parameter? Was it suggested by
sensors-detect?

I'd be interested in a full sensors-detect log (after you unloaded all
chip drivers, of course). Also, if you provide dumps for your four
chips, I will take a look into that and maybe tell you more about
what's on your motherboard exactly.

i2cdump 0 0x18
i2cdump 0 0x29
i2cdump 0 0x2d
i2cdump 0 0x2e

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

System hanging using CSB5 chip with 2.8.1 - No longer

[Don Jessup]

> Why did you use that force parameter? Was it suggested by
> sensors-detect?

    The adm1021 text file in lm_sensors2/doc/chips suggest to get Xeon
   support that I should use the force_adm1021 module parameter.  Is this
   correct ?  Should I just use the module without any parameters?
  

> I'd be interested in a full sensors-detect log (after you unloaded all
> chip drivers, of course). Also, if you provide dumps for your four
> chips, I will take a look into that and maybe tell you more about
> what's on your motherboard exactly.
> 
> i2cdump 0 0x18
> i2cdump 0 0x29
> i2cdump 0 0x2d
> i2cdump 0 0x2e


   I have included 9 log files in this e-mail.
    This first file being the sensors-detect.log. The next 4 are i2cdump with 
   out force_adm1021 as a module paramter.  The next 4 are i2cdump with  the
   force_adm1021 as a module parameter.  


   Thank You again for your help.
     
    

==Don Jessup
Asaca/Shibasoku Corp. of America
400 Corporate Circle, Unit G
Golden, CO  80401
303-278-1111 X232
donj@asaca.com
http://www.asaca.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sensors-detect.log
Type: application/octet-stream
Size: 11515 bytes
Desc: sensors-detect.log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031201/747d4c44/sensors-detect.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2cdump-withParam-0-0x18.log
Type: application/octet-stream
Size: 1224 bytes
Desc: i2cdump-withParam-0-0x18.log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031201/747d4c44/i2cdump-withParam-0-0x18.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2cdump-withParam-0-0x29.log
Type: application/octet-stream
Size: 1224 bytes
Desc: i2cdump-withParam-0-0x29.log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031201/747d4c44/i2cdump-withParam-0-0x29.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2cdump-withParam-0-0x2d.log
Type: application/octet-stream
Size: 1224 bytes
Desc: i2cdump-withParam-0-0x2d.log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031201/747d4c44/i2cdump-withParam-0-0x2d.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2cdump-withParam-0-0x2e.log
Type: application/octet-stream
Size: 1224 bytes
Desc: i2cdump-withParam-0-0x2e.log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031201/747d4c44/i2cdump-withParam-0-0x2e.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2cdump-wOutParam-0-0x18.log
Type: application/octet-stream
Size: 1224 bytes
Desc: i2cdump-wOutParam-0-0x18.log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031201/747d4c44/i2cdump-wOutParam-0-0x18.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2cdump-wOutParam-0-0x29.log
Type: application/octet-stream
Size: 1224 bytes
Desc: i2cdump-wOutParam-0-0x29.log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031201/747d4c44/i2cdump-wOutParam-0-0x29.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2cdump-wOutParam-0-0x2d.log
Type: application/octet-stream
Size: 1224 bytes
Desc: i2cdump-wOutParam-0-0x2d.log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031201/747d4c44/i2cdump-wOutParam-0-0x2d.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2cdump-wOutParam-0-0x2e.log
Type: application/octet-stream
Size: 1224 bytes
Desc: i2cdump-wOutParam-0-0x2e.log
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031201/747d4c44/i2cdump-wOutParam-0-0x2e.obj

System hanging using CSB5 chip with 2.8.1 - No longer

[Jean Delvare]

(MDS, question for you below.)

> > Why did you use that force parameter? Was it suggested by
> > sensors-detect?
> 
> The adm1021 text file in lm_sensors2/doc/chips suggest to get Xeon
> support that I should use the force_adm1021 module parameter.  Is
> this correct ?  Should I just use the module without any
> parameters?

Probably something left from the past, I don't think it's true anymore.
Sensors-detect will detect these as MAX1617 chips, and the adm1021
drivers should load without the force parameter.

What's more, we now have another driver, xeontemp, which I think is the
right driver to use in this case. Read doc/xeontemp for details.

Looks like our adm1021 driver doc needs an update. Mark, if you confirm
my analysis is correct, I'll update the docs.

Also, Mark, sensors-detect doesn't know about xeontemp. Is it because
it's difficult to differenciate from the MAX1617? According to the docs,
the temperature readings are not exaclty the same, so maybe we could use
some heuristics?

> I have included 9 log files in this e-mail.
> This first file being the sensors-detect.log. The next 4 are
> i2cdump without force_adm1021 as a module paramter.  The next 4 are
> i2cdump with  the force_adm1021 as a module parameter.

The force parameter doesn't do anything here. This parameter skips
detection while loading a driver. I2cdump reads the chips directly, it
doesn't use the driver (actually you are supposed to unload chip drivers
before dumping their contents).

The chips at 0x18 and 0x29 could be MAX167 chips (or Xeon, if this is a
xeon system, in which case you should really give a try to the xeontemp
driver instead of the adm1021 driver).

The chips at 0x2d and 0x2e could be LM87 (I don't know that chip very
well but sensors-detect seems to be fairly confident).

All you have to do is load the drivers, run "sensors -s" and tweak
things to fix your needs, I think.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

System hanging using CSB5 chip with 2.8.1 - No longer

[Philip Pokorny]

Some Xeons have honest to goodness, real live, actual MAX1617 chips on 
them.  Others Xeons made around the same time have other ADM1021 
compatible chips on them.  They are mounted on the CPU substrate along 
with the processor information EEPROM that is part of that generation of 
Xeon CPU's.

So it's basically impossible to tell a Xeon TEMP sensor from a MAX1617 
since they are in fact the same chip.  The Xeon Temperature sensors spec 
is just a stripped down register spec for the ADM1021 that says the 
"on-board" or "built-in" sensor registers are "reserved".  That way 
Intel could substitute whatever ADM1021 compatible chip was cheapest at 
the time when they built the CPU's.

The only reason to have the xeontemp driver is if, when Intel built your 
particular Xeon's, they didn't use any of the ADM1021 compatible chips 
that the ADM1021 driver recognizes.  In that case, using the xeontemp 
driver will get you the temperatures you want without potentially 
messing up something in the sensor.  I had a pair of Xeons that had 
sensors that weren't recognized, but I've long since stopped using them.

Unfortunately, the 533MHz FSB Xeon's, dropped the on-board sensor chip. 
 So these new Xeons require a sensor on the motherboard to be connected 
to the thermal diode to read the temperature.  But these 533MHz capable 
motherboards can also accept 400MHz CPU's with the on-board sensor so it 
gets confusing in a hury for motherboard vendors, user and us.

I would suggest that we say:

If you have 400MHz FSB P4 Xeon CPU's, you should have an on-CPU ADM1021 
compatible sensor at 0x18 or 0x19.  In that case, use the ADM1021 driver 
if it detects a chip at that address.  The CPU DIE temperature (Tj) will 
be the "REMOTE" temperature from this sensor.  The "Board" or "built-in" 
temperature from the ADM1021 will be the temperature of the ADM1021 
compatible itself which is one of the chips you see on the side of the CPU.

If you have sensors at 0x18 and 0x19 that are not detected by the 
ADM1021, and you have 400MHz Xeons, then you may want to try the 
xeontemp driver.

If you have 533MHZ FSB Xeons, then you do *not* have an on-board thermal 
sensor and you should look for CPU temperatures from the other sensors 
on your motherboard. (Winbond chip for example).

-------
That's my two cents.
:v)

Jean Delvare wrote:

>(MDS, question for you below.)
>
>  
>
>>>Why did you use that force parameter? Was it suggested by
>>>sensors-detect?
>>>      
>>>
>>The adm1021 text file in lm_sensors2/doc/chips suggest to get Xeon
>>support that I should use the force_adm1021 module parameter.  Is
>>this correct ?  Should I just use the module without any
>>parameters?
>>    
>>
>
>Probably something left from the past, I don't think it's true anymore.
>Sensors-detect will detect these as MAX1617 chips, and the adm1021
>drivers should load without the force parameter.
>
>What's more, we now have another driver, xeontemp, which I think is the
>right driver to use in this case. Read doc/xeontemp for details.
>
>Looks like our adm1021 driver doc needs an update. Mark, if you confirm
>my analysis is correct, I'll update the docs.
>
>Also, Mark, sensors-detect doesn't know about xeontemp. Is it because
>it's difficult to differenciate from the MAX1617? According to the docs,
>the temperature readings are not exaclty the same, so maybe we could use
>some heuristics?
>
>  
>
>>I have included 9 log files in this e-mail.
>>This first file being the sensors-detect.log. The next 4 are
>>i2cdump without force_adm1021 as a module paramter.  The next 4 are
>>i2cdump with  the force_adm1021 as a module parameter.
>>    
>>
>
>The force parameter doesn't do anything here. This parameter skips
>detection while loading a driver. I2cdump reads the chips directly, it
>doesn't use the driver (actually you are supposed to unload chip drivers
>before dumping their contents).
>
>The chips at 0x18 and 0x29 could be MAX167 chips (or Xeon, if this is a
>xeon system, in which case you should really give a try to the xeontemp
>driver instead of the adm1021 driver).
>
>The chips at 0x2d and 0x2e could be LM87 (I don't know that chip very
>well but sensors-detect seems to be fairly confident).
>
>All you have to do is load the drivers, run "sensors -s" and tweak
>things to fix your needs, I think.
>
>  
>

System hanging using CSB5 chip with 2.8.1 - No longer

[Mark Studebaker]

Jean Delvare wrote:
> 
> (MDS, question for you below.)
> 
> > > Why did you use that force parameter? Was it suggested by
> > > sensors-detect?
> >
> > The adm1021 text file in lm_sensors2/doc/chips suggest to get Xeon
> > support that I should use the force_adm1021 module parameter.  Is
> > this correct ?  Should I just use the module without any
> > parameters?
> 
> Probably something left from the past, I don't think it's true anymore.
> Sensors-detect will detect these as MAX1617 chips, and the adm1021
> drivers should load without the force parameter.
> 
> What's more, we now have another driver, xeontemp, which I think is the
> right driver to use in this case. Read doc/xeontemp for details.
> 
> Looks like our adm1021 driver doc needs an update. Mark, if you confirm
> my analysis is correct, I'll update the docs.
> 
> Also, Mark, sensors-detect doesn't know about xeontemp. Is it because
> it's difficult to differenciate from the MAX1617? According to the docs,
> the temperature readings are not exaclty the same, so maybe we could use
> some heuristics?


Correct, correct, correct.

Only caveat is I wrote the xeontemp module and can't test it,
and I've received zero reports about it, good or bad.

So if you would please try it and report results, that would be great.

mds

System hanging using CSB5 chip with 2.8.1 - No longer

[Mark Studebaker]

Thanks Philip.

I wrote the xeontemp driver as a one-temperature driver,
since it was confusing to people using the adm1021 driver that they
had to ignore the local temp and look at the remote temp.

Khali, I'll update the docs myself using Philip's info,
to make recommendations.

Discrimination may be possible between a one-temperature xeon
and a two-temperature xeon with embedded adm1021,
if we could count on the unused registers being someting constant.

mds


Philip Pokorny wrote:
> 
> Some Xeons have honest to goodness, real live, actual MAX1617 chips on
> them.  Others Xeons made around the same time have other ADM1021
> compatible chips on them.  They are mounted on the CPU substrate along
> with the processor information EEPROM that is part of that generation of
> Xeon CPU's.
> 
> So it's basically impossible to tell a Xeon TEMP sensor from a MAX1617
> since they are in fact the same chip.  The Xeon Temperature sensors spec
> is just a stripped down register spec for the ADM1021 that says the
> "on-board" or "built-in" sensor registers are "reserved".  That way
> Intel could substitute whatever ADM1021 compatible chip was cheapest at
> the time when they built the CPU's.
> 
> The only reason to have the xeontemp driver is if, when Intel built your
> particular Xeon's, they didn't use any of the ADM1021 compatible chips
> that the ADM1021 driver recognizes.  In that case, using the xeontemp
> driver will get you the temperatures you want without potentially
> messing up something in the sensor.  I had a pair of Xeons that had
> sensors that weren't recognized, but I've long since stopped using them.
> 
> Unfortunately, the 533MHz FSB Xeon's, dropped the on-board sensor chip.
>  So these new Xeons require a sensor on the motherboard to be connected
> to the thermal diode to read the temperature.  But these 533MHz capable
> motherboards can also accept 400MHz CPU's with the on-board sensor so it
> gets confusing in a hury for motherboard vendors, user and us.
> 
> I would suggest that we say:
> 
> If you have 400MHz FSB P4 Xeon CPU's, you should have an on-CPU ADM1021
> compatible sensor at 0x18 or 0x19.  In that case, use the ADM1021 driver
> if it detects a chip at that address.  The CPU DIE temperature (Tj) will
> be the "REMOTE" temperature from this sensor.  The "Board" or "built-in"
> temperature from the ADM1021 will be the temperature of the ADM1021
> compatible itself which is one of the chips you see on the side of the CPU.
> 
> If you have sensors at 0x18 and 0x19 that are not detected by the
> ADM1021, and you have 400MHz Xeons, then you may want to try the
> xeontemp driver.
> 
> If you have 533MHZ FSB Xeons, then you do *not* have an on-board thermal
> sensor and you should look for CPU temperatures from the other sensors
> on your motherboard. (Winbond chip for example).
> 
> -------
> That's my two cents.
> :v)
> 
> Jean Delvare wrote:
> 
> >(MDS, question for you below.)
> >
> >
> >
> >>>Why did you use that force parameter? Was it suggested by
> >>>sensors-detect?
> >>>
> >>>
> >>The adm1021 text file in lm_sensors2/doc/chips suggest to get Xeon
> >>support that I should use the force_adm1021 module parameter.  Is
> >>this correct ?  Should I just use the module without any
> >>parameters?
> >>
> >>
> >
> >Probably something left from the past, I don't think it's true anymore.
> >Sensors-detect will detect these as MAX1617 chips, and the adm1021
> >drivers should load without the force parameter.
> >
> >What's more, we now have another driver, xeontemp, which I think is the
> >right driver to use in this case. Read doc/xeontemp for details.
> >
> >Looks like our adm1021 driver doc needs an update. Mark, if you confirm
> >my analysis is correct, I'll update the docs.
> >
> >Also, Mark, sensors-detect doesn't know about xeontemp. Is it because
> >it's difficult to differenciate from the MAX1617? According to the docs,
> >the temperature readings are not exaclty the same, so maybe we could use
> >some heuristics?
> >
> >
> >
> >>I have included 9 log files in this e-mail.
> >>This first file being the sensors-detect.log. The next 4 are
> >>i2cdump without force_adm1021 as a module paramter.  The next 4 are
> >>i2cdump with  the force_adm1021 as a module parameter.
> >>
> >>
> >
> >The force parameter doesn't do anything here. This parameter skips
> >detection while loading a driver. I2cdump reads the chips directly, it
> >doesn't use the driver (actually you are supposed to unload chip drivers
> >before dumping their contents).
> >
> >The chips at 0x18 and 0x29 could be MAX167 chips (or Xeon, if this is a
> >xeon system, in which case you should really give a try to the xeontemp
> >driver instead of the adm1021 driver).
> >
> >The chips at 0x2d and 0x2e could be LM87 (I don't know that chip very
> >well but sensors-detect seems to be fairly confident).
> >
> >All you have to do is load the drivers, run "sensors -s" and tweak
> >things to fix your needs, I think.
> >
> >
> >

System hanging using CSB5 chip with 2.8.1 - No longer

[Jean Delvare]

> I wrote the xeontemp driver as a one-temperature driver,
> since it was confusing to people using the adm1021 driver that they
> had to ignore the local temp and look at the remote temp.

Did you really write (I mean, cut and paste) a new driver just so that
people wouldn't have to add an ignore statement in their config file?
This is bad. A comment in both sensors.conf.eg and doc/chips/adm1021
should be sufficent.

> Khali, I'll update the docs myself using Philip's info,
> to make recommendations.

Maybe you could mention that dual-Xeon systems will have a second
adm1021-compatible chip at 0x29 or so?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

System hanging using CSB5 chip with 2.8.1 - No longer

[Mark Studebaker]

Jean Delvare wrote:
> 
> > I wrote the xeontemp driver as a one-temperature driver,
> > since it was confusing to people using the adm1021 driver that they
> > had to ignore the local temp and look at the remote temp.
> 
> Did you really write (I mean, cut and paste) a new driver just so that
> people wouldn't have to add an ignore statement in their config file?
> This is bad. A comment in both sensors.conf.eg and doc/chips/adm1021
> should be sufficent.
> 

I disagree (about the "bad" part - it was a cut and paste for sure).
adm1021 was at the limit for number of chips in SENSORS_INSMOD_x.
Making a new driver is a prerequisite for having better detection
in sensors-detect and recommending the correct driver,
without the user having to edit sensors.conf.
The new driver matches the xeon datasheet - exactly one sensor. Not two.

> > Khali, I'll update the docs myself using Philip's info,
> > to make recommendations.
> 
> Maybe you could mention that dual-Xeon systems will have a second
> adm1021-compatible chip at 0x29 or so?

ok