[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hello,

I'm having problems with lm_sensors on the motherboard Supermicro X6DH8-G2+
sensors-detect gives me the output attached in the textfile
sensors-detect-output.txt

As soon as I execute the recommended 'modprobe smbus-arp' I receive the
following message:
FATAL: Module smbus_arp not found.

When I execute sensors, I receive the following:
===========================
[root at matrix ~]# sensors
eeprom-i2c-0-57
Adapter: SMBus I801 adapter at 1100
Unknown EEPROM type (8)

eeprom-i2c-0-53
Adapter: SMBus I801 adapter at 1100
Unknown EEPROM type (8)
===========================

I also attached sensors.conf from /etc for reference.
I'm using xen-3.0.2 with kernel 2.6.16 and all Hardware Monitoring and
i2c stuff compiled as modules (as being done in the standard kernel).
My distribution is CentOS-4.4 hence my sensors version is
'lm_sensors-2.8.7-2.40.3'
sensors doesn't run either with the non-xen kernel, i.e. the stock
kernel that came with CentOS-4.4: kernel-2.6.9-42.0.2.EL

Is there any way to get sensors on the mainboard running?

BTW, what Power supply do you recommend if I've got a 2U chassis with 4
Fans, 4 SATA II drives, an SATA Backplane, Dual Xeon 3.6 GHz, 4 GB RAM,
eRIC remote console card, a double layer DVD writer and 3ware
9550SXU-4LP. Is a 510W power supply from Emacs P2G-6510P sufficient?

Thanks in advance!

Regards - Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sensors-detect-output.txt
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061001/7f29c188/attachment-0001.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sensors.conf
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061001/7f29c188/attachment-0001.pl 

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

Hi Michael,

> I'm having problems with lm_sensors on the motherboard Supermicro X6DH8-G2+
> sensors-detect gives me the output attached in the textfile
> sensors-detect-output.txt
> 
> As soon as I execute the recommended 'modprobe smbus-arp' I receive the
> following message:
> FATAL: Module smbus_arp not found.

Forget about smbus-arp, it's an old experimental module which was never
ported to Linux 2.6 (and never will be.)

> When I execute sensors, I receive the following:
> ===========================
> [root at matrix ~]# sensors
> eeprom-i2c-0-57
> Adapter: SMBus I801 adapter at 1100
> Unknown EEPROM type (8)
> 
> eeprom-i2c-0-53
> Adapter: SMBus I801 adapter at 1100
> Unknown EEPROM type (8)
> ===========================

You must be using an old version of lm_sensors. Type 8 is DDR2 SDRAM,
which is supported for quite some time now.

> I also attached sensors.conf from /etc for reference.

Not really helpful, we distribute the file, so we know what's inside,
and this file isn't relevant at this point anyway, as you don't even
have a hardware monitoring driver loaded.

> I'm using xen-3.0.2 with kernel 2.6.16 and all Hardware Monitoring and
> i2c stuff compiled as modules (as being done in the standard kernel).
> My distribution is CentOS-4.4 hence my sensors version is
> 'lm_sensors-2.8.7-2.40.3'

This is quite old, and your hardware is brand new. This just can't work.

> sensors doesn't run either with the non-xen kernel, i.e. the stock
> kernel that came with CentOS-4.4: kernel-2.6.9-42.0.2.EL
> 
> Is there any way to get sensors on the mainboard running?

> [root at matrix ~]# sensors-detect
> 
> 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): YES
> Probing for PCI bus adapters...
> Use driver `i2c-i801' for device 00:1f.3: Intel 82801EB ICH5
> Probe succesfully concluded.
> 
> We will now try to load each adapter module in turn.
> Load `i2c-i801' (say NO if built into your kernel)? (YES/no): YES
> Module loaded succesfully.
> 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 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 I801 adapter at 1100 (Algorithm unavailable)
> Do you want to scan it? (YES/no/selectively): YES
> Client found at address 0x08
> Client found at address 0x2e
> 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'... Failed!
> Probing for `Analog Devices ADM1027, ADT7460 or ADT7463'... Failed!
> Probing for `SMSC EMC6D100 or EMC6D101'... Failed!
> Probing for `Analog Devices ADT7467'... Failed!
> Probing for `National Semiconductor LM87'... Failed!
> Probing for `Winbond W83781D'... Failed!
> Probing for `Winbond W83782D'... Failed!
> Probing for `Winbond W83791D'... Failed!
> Probing for `Winbond W83627HF'... Failed!
> Probing for `Asus AS99127F (rev.1)'... Failed!
> Probing for `Asus AS99127F (rev.2)'... Failed!
> Probing for `Asus ASB100 Bach'... Failed!
> Probing for `Winbond W83L785TS-S'... 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 `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 `Analog Devices ADM1028'... Failed!
> Probing for `ITE IT8705F / IT8712F / SiS 950'... Failed!
> Client found at address 0x30
> Client found at address 0x33
> Client found at address 0x37
> Client found at address 0x44
> Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!
> Client found at address 0x53
> Probing for `SPD EEPROM'... Success!
>     (confidence 8, driver `eeprom')
> Client found at address 0x57
> Probing for `SPD EEPROM'... Success!
>     (confidence 8, driver `eeprom')
> Probing for `Sony Vaio EEPROM'... Failed!
> 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
> Client found at address 0x6c
> Client found at address 0x6e
> 
> 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): YES
> 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 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 IT8705F / IT8712F / 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): YES
> Probing for `ITE 8702F Super IO Sensors'
>   Failed! (0xf211)
> Probing for `ITE 8705F Super IO Sensors'
>   Failed! (0xf211)
> Probing for `ITE 8712F Super IO Sensors'
>   Failed! (0xf211)
> Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87360 Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87363 Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87364 Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87365 Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87365 Super IO Voltage Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87365 Super IO Thermal Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87366 Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87366 Super IO Voltage Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87366 Super IO Thermal Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87372 Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC87373 Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `Nat. Semi. PC8741x Super IO'
>   Failed! (0xf2)
> Probing for `SMSC 47B27x Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `SMSC 47M10x/13x Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `SMSC 47M14x Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `SMSC 47M15x/192 Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `SMSC 47S42x Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `SMSC 47S45x Super IO Fan Sensors'
>   Failed! (0xf2)
> Probing for `SMSC 47M172 Super IO'
>   Failed! (0xf2)
> Probing for `VT1211 Super IO Sensors'
>   Failed! (0xf2)
> Probing for `Winbond W83627HF Super IO Sensors'
>   Failed! (0xf2)
> Probing for `Winbond W83627THF Super IO Sensors'
>   Failed! (0xf2)
> Probing for `Winbond W83637HF Super IO Sensors'
>   Failed! (0xf2)
> Probing for `Winbond W83697HF Super IO Sensors'
>   Failed! (0xf2)
> Probing for `Winbond W83697SF/UF Super IO PWM'
>   Failed! (0xf2)
> Probing for `Winbond W83L517D Super IO'
>   Failed! (0xf2)
> 
> Do you want to scan for secondary Super I/O sensors? (YES/no): YES
> Probing for `ITE 8702F Super IO Sensors'
>   Failed! (0xe111)
> Probing for `ITE 8705F Super IO Sensors'
>   Failed! (0xe111)
> Probing for `ITE 8712F Super IO Sensors'
>   Failed! (0xe111)
> Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87360 Super IO Fan Sensors'
>   Success... but not activated
> Probing for `Nat. Semi. PC87363 Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87364 Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87365 Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87365 Super IO Voltage Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87365 Super IO Thermal Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87366 Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87366 Super IO Voltage Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87366 Super IO Thermal Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87372 Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC87373 Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `Nat. Semi. PC8741x Super IO'
>   Failed! (0xe1)
> Probing for `SMSC 47B27x Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `SMSC 47M10x/13x Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `SMSC 47M14x Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `SMSC 47M15x/192 Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `SMSC 47S42x Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `SMSC 47S45x Super IO Fan Sensors'
>   Failed! (0xe1)
> Probing for `SMSC 47M172 Super IO'
>   Failed! (0xe1)
> Probing for `VT1211 Super IO Sensors'
>   Failed! (0xe1)
> Probing for `Winbond W83627HF Super IO Sensors'
>   Failed! (0xe1)
> Probing for `Winbond W83627THF Super IO Sensors'
>   Failed! (0xe1)
> Probing for `Winbond W83637HF Super IO Sensors'
>   Failed! (0xe1)
> Probing for `Winbond W83697HF Super IO Sensors'
>   Failed! (0xe1)
> Probing for `Winbond W83697SF/UF Super IO PWM'
>   Failed! (0xe1)
> Probing for `Winbond W83L517D Super IO'
>   Failed! (0xe1)
> 
>  Now follows a summary of the probes I have just done.
>  Just press ENTER to continue:
> 
> Driver `eeprom' (should be inserted):
>   Detects correctly:
>   * Bus `SMBus I801 adapter at 1100' (Algorithm unavailable)
>     Busdriver `i2c-i801', I2C address 0x53
>     Chip `SPD EEPROM' (confidence: 8)
>   * Bus `SMBus I801 adapter at 1100' (Algorithm unavailable)
>     Busdriver `i2c-i801', I2C address 0x57
>     Chip `SPD EEPROM' (confidence: 8)
> 
> Driver `smbus-arp' (should be inserted):
>   Detects correctly:
>   * Bus `SMBus I801 adapter at 1100' (Algorithm unavailable)
>     Busdriver `i2c-i801', I2C address 0x61
>     Chip `SMBus 2.0 ARP-Capable Device' (confidence: 1)

This is an old version of sensors-detect, no wonder it doesn't detect
your sensors. Please try again with the version of sensors-detect which
comes with the freshly released lm_sensors 2.10.1.

I think I've seen this motherboard before, so I guess it'll find a
National Semiconductor LM93 for the temperatures and voltages, and a
National Semiconductor PC87427 Super-I/O chip for the fans. Status for
these chips is as follows:

* A driver for the LM93 chip exists but wasn't officially ported to
Linux 2.6. There was a preliminary port posted to this list at the
times of ~ 2.6.10, but it was never properly reviewed due to lack of
time.

* We have a datasheet for the PC87427 but no public driver yet. I've
been working on the fan support though, I have a preliminary driver
waiting for testers.

> BTW, what Power supply do you recommend if I've got a 2U chassis with 4
> Fans, 4 SATA II drives, an SATA Backplane, Dual Xeon 3.6 GHz, 4 GB RAM,
> eRIC remote console card, a double layer DVD writer and 3ware
> 9550SXU-4LP. Is a 510W power supply from Emacs P2G-6510P sufficient?

No idea, sorry. The motherboard maker should tell you.

-- 
Jean Delvare

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hi Jean, hi list,

thanks for your reply.

Jean Delvare wrote:
> You must be using an old version of lm_sensors. Type 8 is DDR2 SDRAM,
> which is supported for quite some time now.
>   
ok, no discussion - I uninstalled the old thing. :)
> This is an old version of sensors-detect, no wonder it doesn't detect
> your sensors. Please try again with the version of sensors-detect which
> comes with the freshly released lm_sensors 2.10.1.
>
> I think I've seen this motherboard before, so I guess it'll find a
> National Semiconductor LM93 for the temperatures and voltages, and a
> National Semiconductor PC87427 Super-I/O chip for the fans. Status for
> these chips is as follows:
>
> * A driver for the LM93 chip exists but wasn't officially ported to
> Linux 2.6. There was a preliminary port posted to this list at the
> times of ~ 2.6.10, but it was never properly reviewed due to lack of
> time.
>
> * We have a datasheet for the PC87427 but no public driver yet. I've
> been working on the fan support though, I have a preliminary driver
> waiting for testers.
>   
Version 2.10.1 gives me the following output:
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
Driver `lm93' (should be inserted):
  Detects correctly:
  * Bus `SMBus I801 adapter at 1100'
    Busdriver `i2c-i801', I2C address 0x2e
    Chip `National Semiconductor LM93' (confidence: 5)

Driver `eeprom' (should be inserted):
  Detects correctly:
  * Bus `SMBus I801 adapter at 1100'
    Busdriver `i2c-i801', I2C address 0x53
    Chip `eeprom' (confidence: 6)
  * Bus `SMBus I801 adapter at 1100'
    Busdriver `i2c-i801', I2C address 0x57
    Chip `eeprom' (confidence: 6)

  EEPROMs are *NOT* sensors! They are data storage chips commonly
  found on memory modules (SPD), in monitors (EDID), or in some
  laptops, for example.

Driver `to-be-written' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0840 (Busdriver `i2c-isa')
    Chip `Nat. Semi. PC87427 Super IO Fan Sensors' (confidence: 9)
  * ISA bus address 0x0880 (Busdriver `i2c-isa')
    Chip `Nat. Semi. PC87427 Super IO Health Sensors' (confidence: 9)

I will now generate the commands needed to load the required modules.
Just press ENTER to continue:

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
# Chip drivers
# Warning: the required module lm93 is not currently installed
# on your system. For status of 2.6 kernel ports check
# http://www.lm-sensors.org/wiki/Devices. If driver is built
# into the kernel, or unavailable, comment out the following line.
modprobe lm93
modprobe eeprom
# no driver for Nat. Semi. PC87427 Super IO Fan Sensors yet
# sleep 2 # optional
/usr/local/bin/sensors -s # recommended
#----cut here----
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----

Well, the trouble is of course, that there's no module lm93.

This is what Supermicro support has mailed me as a response to my
question as posted into the list. They called it "X6DH8-G2 SDK file",
but I'm sorry, I don't understand the things written here. Maybe that's
the data sheet you were talking about.
(Getting the response from the Supermicro support guy made me feel like
walking into a grocery store asking for some exotic product and
receiving a construction plan for the atoms to be compound in order to
build that product). :-)

X6DH8-G2_X6DH8-XG2.txt:
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
Bus Type = I/O Mapping and SMBus
One NS87427, One LM93

NS87427
===============================
Fan: I/O Based: 0840h, Bank Select Register: Base + 0Fh
Fan1 Fan Speed, Base + 12h, Base + 13h,   Bank 0
Fan2 Fan Speed, Base + 12h, Base + 13h,   Bank 1
Fan3 Fan Speed, Base + 12h, Base + 13h,   Bank 2
Fan4 Fan Speed, Base + 12h, Base + 13h,   Bank 3
Fan5 Fan Speed, Base + 12h, Base + 13h,   Bank 4
Fan6 Fan Speed, Base + 12h, Base + 13h,   Bank 6
CPU1 Fan Speed, Base + 12h, Base + 13h,   Bank 7
CPU2 Fan Speed, Base + 12h, Base + 13h,   Bank 5

Chassis Intrusion: I/O Based: 0800h, Bank Select Register: Base + 0Fh
Chassis Intrusion: Base + 0Ch,   All Bank

Power Supply Failure, GP57


LM93, Slave Address=0x2e (0x5C in 8-Bit format)
===============================
CPU1 Core Voltage, Offset 0x5c       
CPU2 Core Voltage, Offset 0x5d
+3.3V Voltage, Offset 0x5e
+5V Voltage, Offset 0x5f
+12V Voltage, Offset 0x56       
-12V Voltage, Offset 0x64
CPU1 Temperature, Offset 0x50       
CPU2 Temperature, Offset 0x51       
System Temperature, Offset 0x52
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----

I can test your driver for the PC87427 if you like to. My only
constraint is that I have to put the server into production very soon
(in about one or two weeks).

TIA
ciao - Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

Michael,

> I can test your driver for the PC87427 if you like to. My only
> constraint is that I have to put the server into production very soon
> (in about one or two weeks).

Here you go. I attached the driver itself, and a Makefile to compile it
off-tree. Just type "make modules" to build the driver and "make
modules_install" to install it. Then "modprobe pc87427" should work.
Let me know if not.

Once the driver is loaded you should have fan interface files
under /sys/class/hwmon/hwmon0/device. The driver reports the current
fan speed, the low limit speed, and two alarm flags per fan: fan too
slow (fanX_alarm) and fan stalled/missing (fanX_fault).

Please report how it works for you! Thanks.

-- 
Jean Delvare
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Makefile
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061006/44ed7712/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pc87427.c
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061006/44ed7712/attachment.c 

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

> Here you go. I attached the driver itself, and a Makefile to compile it
> off-tree. Just type "make modules" to build the driver and "make
> modules_install" to install it. Then "modprobe pc87427" should work.
> Let me know if not.
> 
> Once the driver is loaded you should have fan interface files
> under /sys/class/hwmon/hwmon0/device. The driver reports the current
> fan speed, the low limit speed, and two alarm flags per fan: fan too
> slow (fanX_alarm) and fan stalled/missing (fanX_fault).
> 
> Please report how it works for you! Thanks.

BTW, lm-sensors SVN now has userspace support for that new driver too,
so you can pick it and install it:
http://dl.lm-sensors.org/lm-sensors/snapshots/lm-sensors-r4197-20061007.tar.bz2

-- 
Jean Delvare

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Jean Delvare schrieb:
> Here you go. I attached the driver itself, and a Makefile to compile it
> off-tree. Just type "make modules" to build the driver and "make
> modules_install" to install it. Then "modprobe pc87427" should work.
> Let me know if not.
>
> Once the driver is loaded you should have fan interface files
>   
Hi Jean,

first of all thanks for letting me try the driver!
Unfortunately, I can't modprobe the driver:
[root at matrix PC87427]# make
  CC [M]  /root/software/PC87427/pc87427.o
  Building modules, stage 2.
  MODPOST
  CC      /root/software/PC87427/pc87427.mod.o
  LD [M]  /root/software/PC87427/pc87427.ko
[root at matrix PC87427]# make modules_install
cp pc87427.ko /lib/modules/2.6.16-xen/kernel/drivers/hwmon
depmod -a -F /lib/modules/2.6.16-xen/build/System.map 2.6.16-xen
[root at matrix PC87427]# modprobe -v pc87427
insmod /lib/modules/2.6.16-xen/kernel/drivers/hwmon/pc87427.ko
FATAL: Error inserting pc87427
(/lib/modules/2.6.16-xen/kernel/drivers/hwmon/pc87427.ko): Invalid
module format

Have you got an idea what's going wrong?
TIA - Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

Morgen Michael,

> first of all thanks for letting me try the driver!
> Unfortunately, I can't modprobe the driver:
> [root at matrix PC87427]# make
>   CC [M]  /root/software/PC87427/pc87427.o
>   Building modules, stage 2.
>   MODPOST
>   CC      /root/software/PC87427/pc87427.mod.o
>   LD [M]  /root/software/PC87427/pc87427.ko
> [root at matrix PC87427]# make modules_install
> cp pc87427.ko /lib/modules/2.6.16-xen/kernel/drivers/hwmon
> depmod -a -F /lib/modules/2.6.16-xen/build/System.map 2.6.16-xen
> [root at matrix PC87427]# modprobe -v pc87427
> insmod /lib/modules/2.6.16-xen/kernel/drivers/hwmon/pc87427.ko
> FATAL: Error inserting pc87427
> (/lib/modules/2.6.16-xen/kernel/drivers/hwmon/pc87427.ko): Invalid
> module format
> 
> Have you got an idea what's going wrong?

I'm having similar problem with another tester for another driver
off-list. It's usually a matter of adding some flag at compilation
time. Any hint in the logs (dmesg or /var/log/messages)? Is this a
64-bit system?

-- 
Jean Delvare

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Jean Delvare schrieb:
>> [root at matrix PC87427]# modprobe -v pc87427
>> insmod /lib/modules/2.6.16-xen/kernel/drivers/hwmon/pc87427.ko
>> FATAL: Error inserting pc87427
>> (/lib/modules/2.6.16-xen/kernel/drivers/hwmon/pc87427.ko): Invalid
>> module format
>> Have you got an idea what's going wrong?
>>
>>     
>
> I'm having similar problem with another tester for another driver
> off-list. It's usually a matter of adding some flag at compilation
> time. Any hint in the logs (dmesg or /var/log/messages)? Is this a
> 64-bit system?
>   
Salut Jean,

thanks a lot for the hint, I didn't see the syslog - it seems to work
well now:
Oct  8 11:59:50 matrix kernel: overflow in relocation type 10 val
ffffffff881b6ec8
Oct  8 11:59:50 matrix kernel: `pc87427' likely not compiled with
-mcmodel=kernel

so I added -mcmodel=kernel to the Makefile's CFLAGS, which made the
modprobe working.

for i in /sys/class/hwmon/hwmon0/device/fan[1-8]_*; do echo $i; cat $i; done
[root at matrix PC87427]# /sys/class/hwmon/hwmon0/device/fan1_alarm
0
/sys/class/hwmon/hwmon0/device/fan1_fault
0
/sys/class/hwmon/hwmon0/device/fan1_input
3668
/sys/class/hwmon/hwmon0/device/fan1_min
712
/sys/class/hwmon/hwmon0/device/fan2_alarm
0
/sys/class/hwmon/hwmon0/device/fan2_fault
0
/sys/class/hwmon/hwmon0/device/fan2_input
3383
/sys/class/hwmon/hwmon0/device/fan2_min
712
/sys/class/hwmon/hwmon0/device/fan3_alarm
0
/sys/class/hwmon/hwmon0/device/fan3_fault
0
/sys/class/hwmon/hwmon0/device/fan3_input
3391
/sys/class/hwmon/hwmon0/device/fan3_min
712
/sys/class/hwmon/hwmon0/device/fan4_alarm
0
/sys/class/hwmon/hwmon0/device/fan4_fault
0
/sys/class/hwmon/hwmon0/device/fan4_input
3366
/sys/class/hwmon/hwmon0/device/fan4_min
712
/sys/class/hwmon/hwmon0/device/fan5_alarm
0
/sys/class/hwmon/hwmon0/device/fan5_fault
1
/sys/class/hwmon/hwmon0/device/fan5_input
0
/sys/class/hwmon/hwmon0/device/fan5_min
712
/sys/class/hwmon/hwmon0/device/fan6_alarm
0
/sys/class/hwmon/hwmon0/device/fan6_fault
0
/sys/class/hwmon/hwmon0/device/fan6_input
2848
/sys/class/hwmon/hwmon0/device/fan6_min
712
/sys/class/hwmon/hwmon0/device/fan7_alarm
0
/sys/class/hwmon/hwmon0/device/fan7_fault
1
/sys/class/hwmon/hwmon0/device/fan7_input
0
/sys/class/hwmon/hwmon0/device/fan7_min
712
/sys/class/hwmon/hwmon0/device/fan8_alarm
0
/sys/class/hwmon/hwmon0/device/fan8_fault
0
/sys/class/hwmon/hwmon0/device/fan8_input
2800
/sys/class/hwmon/hwmon0/device/fan8_min
712

(there's no fans 5 and 7 installed as there's no more room in the chassis).

Perfect - thanks a lot again!
Although this is already sufficient to monitor I'll try the userspace
lm-sensors part and I'll give you feedback on that.

Kind Regards - Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hi,

Jean Delvare wrote:
> BTW, lm-sensors SVN now has userspace support for that new driver too,
> so you can pick it and install it:
> http://dl.lm-sensors.org/lm-sensors/snapshots/lm-sensors-r4197-20061007.tar.bz2
>   
Is there a working, more current spec file available around for building
the package as an rpm? There's old ones included in the snapshot
http://dl.lm-sensors.org/lm-sensors/snapshots/lm-sensors-r4197-20061007.tar.bz2
(versions 2.5.0 and 2.8.3)
(My distribution is a centos-4.4)
I tried the one from the centos-4.4 src rpm, but evidently this didn't
work because of all the patches bundled with it.

The sensors-detect recognizes the chip:
Found `Nat. Semi. PC87427 Super IO Fan Sensors'             Success!
    (address 0x840, driver `pc87427')
Found `Nat. Semi. PC87427 Super IO Health Sensors'          Success!
    (address 0x880, driver `to-be-written')
Driver `pc87427' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0840 (Busdriver `i2c-isa')
    Chip `Nat. Semi. PC87427 Super IO Fan Sensors' (confidence: 9)

Driver `to-be-written' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0880 (Busdriver `i2c-isa')
    Chip `Nat. Semi. PC87427 Super IO Health Sensors' (confidence: 9)

[root at matrix lm-sensors-r4197-20061007/prog/sensors]# ./sensors
pc87427-isa-0840
Adapter: ISA adapter

Regards - Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

Hallo Michael,

> Jean Delvare wrote:
> > BTW, lm-sensors SVN now has userspace support for that new driver too,
> > so you can pick it and install it:
> > http://dl.lm-sensors.org/lm-sensors/snapshots/lm-sensors-r4197-20061007.tar.bz2
> >   
> Is there a working, more current spec file available around for building
> the package as an rpm? There's old ones included in the snapshot
> http://dl.lm-sensors.org/lm-sensors/snapshots/lm-sensors-r4197-20061007.tar.bz2
> (versions 2.5.0 and 2.8.3)
> (My distribution is a centos-4.4)
> I tried the one from the centos-4.4 src rpm, but evidently this didn't
> work because of all the patches bundled with it.

Indeed I see that our spec files are completely out-of-date. And nobody
complained as far as I can remember, so I guess people simply don't
care. In most cases, if you use an rpm-based distribution nowadays,
you'll simply install the packages that come with the distribution
itself, rather than building your own.

If you really want to repackage a rpm based on a different package
version, I guess you're better starting from the .spec file that your
distribution is using for lm_sensors. As you mentioned, you'll have to
deal with extra patches, but either these patches fix things we have
already fixed upstream by now and you can drop them, or they add things
which are specific to your distribution, and you will want these
changes in your package.

Given that every distribution is different, and different versions of
rpm support a different set of features, I fail to see the point in
shipping .spec files at all. They are better maintained by each
distribution. So I propose that we simply delete this RPM directory
from both our i2c and lm-sensors trees. Objections anyone?

> The sensors-detect recognizes the chip:
> Found `Nat. Semi. PC87427 Super IO Fan Sensors'             Success!
>     (address 0x840, driver `pc87427')
> Found `Nat. Semi. PC87427 Super IO Health Sensors'          Success!
>     (address 0x880, driver `to-be-written')
> 
> Driver `pc87427' (should be inserted):
>   Detects correctly:
>   * ISA bus address 0x0840 (Busdriver `i2c-isa')
>     Chip `Nat. Semi. PC87427 Super IO Fan Sensors' (confidence: 9)
> 
> Driver `to-be-written' (should be inserted):
>   Detects correctly:
>   * ISA bus address 0x0880 (Busdriver `i2c-isa')
>     Chip `Nat. Semi. PC87427 Super IO Health Sensors' (confidence: 9)

Good.

> [root at matrix lm-sensors-r4197-20061007/prog/sensors]# ./sensors
> pc87427-isa-0840
> Adapter: ISA adapter

Not so good. You should see all the values here. I suspect your new
"sensors" links with an old libsensors. You can check with "sensors -v"
or "ldd sensors".

If you did not install libsensors yet, this is expected. You can force
the new libsensors to be used by adding
$HOME/lm-sensors-r4197-20061007/lib to $LD_LIBRARY_PATH (and exporting
it if needs be.)

Or you can install the library to /usr/local/lib, in which case you'll
need to make sure that /etc/ld.so.conf contains this directory. And you
may have to disable the one in /usr/lib to make sure it doesn't get in
the way.

Hope that helps,
-- 
Jean Delvare

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hello Jean,

Jean Delvare wrote:
> Given that every distribution is different, and different versions of
> rpm support a different set of features, I fail to see the point in
> shipping .spec files at all. They are better maintained by each
> distribution. 
That sounds logical.
> So I propose that we simply delete this RPM directory
> from both our i2c and lm-sensors trees. Objections anyone?
>   
maybe you can keep it somehow as a contrib element, I think that adds
quite some value to every tar ball. :)
>> [root at matrix lm-sensors-r4197-20061007/prog/sensors]# ./sensors
>> pc87427-isa-0840
>> Adapter: ISA adapter
>>     
>
> Not so good. You should see all the values here. I suspect your new
> "sensors" links with an old libsensors. You can check with "sensors -v"
> or "ldd sensors".
>   
ok, sorry for the confusion, that's because I just started sensors from
the build tree. I didn't want to install the thing without an rpm.
Anyways, I grabbed the spec file from centos and built my own rpm,
without the patches. :)

-----8<-----8<-----8<-----SNIP-----8<-----8<-----8<-----
[root at matrix ~]# sensors
pc87427-isa-0840
Adapter: ISA adapter
fan1:     3678 RPM  (min =  712 RPM)
fan2:     3391 RPM  (min =  712 RPM)
fan3:     3400 RPM  (min =  712 RPM)
fan4:     3366 RPM  (min =  712 RPM)
fan5:        0 RPM  (min =  712 RPM)          FAULT
fan6:     2896 RPM  (min =  712 RPM)
fan7:        0 RPM  (min =  712 RPM)          FAULT
fan8:     2812 RPM  (min =  712 RPM)

-----8<-----8<-----8<-----SNIP-----8<-----8<-----8<-----
[root at matrix ~]# rpm -qi lm_sensors
Name        : lm_sensors                   Relocations: (not relocatable)
Version     : 2.10.1                            Vendor: (none)
Release     : 1.0.0                         Build Date: So 08 Okt 2006
14:27:46 CEST
Install Date: So 08 Okt 2006 14:29:34 CEST      Build Host: matrix
Group       : Applications/System           Source RPM:
lm_sensors-2.10.1-1.0.0.src.rpm
Size        : 1925845                          License: GPL
Signature   : (none)
URL         : http://secure.netroedge.com/~lm78/
Summary     : Hardware monitoring tools.
Description :
The lm_sensors package includes a collection of modules for general SMBus
access and hardware monitoring.  NOTE: this requires special support which
is not in standard 2.2-vintage kernels.

-----8<-----8<-----8<-----SNIP-----8<-----8<-----8<-----

Question: Shouldn't the libs as defined in lm_sensors Makefile go to
something more architecture specific?
I changed my local copy of the Makefile from the snapshot to the
following in order to comply with rpm's strict architecture handling.
That allowed me too build the x86_64 package.

BTW, I attached my .spec file, maybe somebody has some use for it. It
only works with the patch applied as shown below.

Instructions:
get
http://dl.lm-sensors.org/lm-sensors/snapshots/lm-sensors-r4197-20061007.tar.bz2
tar xjvf lm-sensors-r4197-20061007.tar.bz2
mv lm-sensors-r4197-20061007 lm_sensors-2.10.1
cd lm_sensors-2.10.1
cp prog/init/lm_sensors.sysconfig /usr/src/redhat/SOURCES
cp prog/init/lm_sensors.init /usr/src/redhat/SOURCES
patch -p1 < patchfile (see patch listed below)
cd ..
tar czvf lm_sensors-2.10.1.tar.gz lm_sensors-2.10.1
put lm_sensors-2.10.1.tar.gz under /usr/src/redhat/SOURCES
put spec file under /usr/src/redhat/SPECS
rpmbuild -ba lm_sensors.spec
cross fingers

Please note: These installations instructions are just from my memory,
they don't claim to comply to any standard neither lm_sensors' nor
centos' standars. I just wanted to make it work under centos without
having files lying around that I can't remove properly should I ever
uninstall or upgrade lm_sensors.

Thanks for your help so far!

Greetings - Michael

[root at matrix SOURCES]# diff -Naur lm-sensors-r4197-20061007/Makefile
lm_sensors-2.10.1/Makefile
--- lm-sensors-r4197-20061007/Makefile 2006-09-17 23:01:35.000000000 +0200
+++ lm_sensors-2.10.1/Makefile 2006-10-08 14:05:31.000000000 +0200
@@ -113,9 +113,16 @@
 # configuration file is found
 ETCDIR := /etc

+# determine machine type (hardware)
+MACHINE := $(shell uname -m)
+
 # You should not need to change this. It is the directory into which the
 # library files (both static and shared) will be installed.
-LIBDIR := $(PREFIX)/lib
+ifeq ($(MACHINE),x86_64)
+    LIBDIR := $(PREFIX)/lib64
+else
+    LIBDIR := $(PREFIX)/lib
+endif

 EXLDFLAGS := -Wl,-rpath,$(LIBDIR)

@@ -143,8 +150,6 @@
 # manual pages will be installed.
 MANDIR := $(PREFIX)/man

-MACHINE := $(shell uname -m)
-
 # Extra non-default programs to build; e.g., sensord
 # PROG_EXTRA := sensord


-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lm_sensors.spec
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061008/54f92c71/attachment-0001.pl 

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

> Jean Delvare wrote:
> > Given that every distribution is different, and different versions of
> > rpm support a different set of features, I fail to see the point in
> > shipping .spec files at all. They are better maintained by each
> > distribution. 
>
> That sounds logical.
>
> > So I propose that we simply delete this RPM directory
> > from both our i2c and lm-sensors trees. Objections anyone?
> 
> maybe you can keep it somehow as a contrib element, I think that adds
> quite some value to every tar ball. :)

Well, is is already kept as a contrib element. But I fail to see the
added value as it is not maintained and certainly won't work with any
recent distribution. Yourself, you finally started from the CentOS spec
file rather than ours.

My "Objections anyone?" was essentially an "Is someone volunteering to
maintain these spec files?" And if nobody shows up, the files are gone
soon.

> -----8<-----8<-----8<-----SNIP-----8<-----8<-----8<-----
> [root at matrix ~]# sensors
> pc87427-isa-0840
> Adapter: ISA adapter
> fan1:     3678 RPM  (min =  712 RPM)
> fan2:     3391 RPM  (min =  712 RPM)
> fan3:     3400 RPM  (min =  712 RPM)
> fan4:     3366 RPM  (min =  712 RPM)
> fan5:        0 RPM  (min =  712 RPM)          FAULT
> fan6:     2896 RPM  (min =  712 RPM)
> fan7:        0 RPM  (min =  712 RPM)          FAULT
> fan8:     2812 RPM  (min =  712 RPM)
> 
> -----8<-----8<-----8<-----SNIP-----8<-----8<-----8<-----

Nice! So it finally works :)

Now you can write a sensors.conf file for this board. You should be
able to find the labels by comparing with what the BIOS is displaying.
As for the low limit values, the choice is up to you. 712 RPM looks a
bit too low IMHO.

> Question: Shouldn't the libs as defined in lm_sensors Makefile go to
> something more architecture specific?
> I changed my local copy of the Makefile from the snapshot to the
> following in order to comply with rpm's strict architecture handling.
> That allowed me too build the x86_64 package.

I see what you mean. I'm surprised that all 64-bit distributions went
for "lib64" for 64-bit libraries. 32-bit distributions were using
"lib", not "lib32", so it would have been much more logical (IMHO) to
keep "lib" for the native libraries, and to use "lib32" for the 32-bit
compatibility ones. In a decade I guess everyone will have given up the
32-bit compatibility, and we'll either be stuck with a meaningless
"lib64", or we'll change it back to just "lib" and it'll be a mess :(

Anyway, things are what they are today, so we should probably do what
you propose and install into lib64 on x86_64, to make users and
distibutions happier. I'll apply your patch to our repository unless
someone objects.

Thanks,
-- 
Jean Delvare

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hi Jean,

Jean Delvare wrote:
> Well, is is already kept as a contrib element. But I fail to see the
> added value as it is not maintained and certainly won't work with any
> recent distribution. Yourself, you finally started from the CentOS spec
> file rather than ours.
>   
You're right - and even with that solution I'll be alone with regards to
the CentOS community as CentOS more or less strictly follows the
upstream provider. Maybe someone's interested to include it in some
extras tree there, at CentOS. But you are right, the right place is not
in lm_sensors as one software project can't take care of all the distris
out in the world.
> My "Objections anyone?" was essentially an "Is someone volunteering to
> maintain these spec files?" And if nobody shows up, the files are gone
> soon.
>   
From the above point of view - delete it.
> Nice! So it finally works :)
>   
yes, success stories are written in mailing lists. :)
> Now you can write a sensors.conf file for this board. You should be
> able to find the labels by comparing with what the BIOS is displaying.
> As for the low limit values, the choice is up to you. 712 RPM looks a
> bit too low IMHO.
>   

[root at matrix ~]# sensors
pc87427-isa-0840
Adapter: ISA adapter
case-fan1:3678 RPM  (min = 2000 RPM)
case-fan2:3391 RPM  (min = 2000 RPM)
case-fan3:3400 RPM  (min = 2000 RPM)
case-fan4:3366 RPM  (min = 2000 RPM)
not-inst:    0 RPM  (min =    0 RPM)          FAULT
CPU0-fan: 2915 RPM  (min = 2000 RPM)
not-inst:    0 RPM  (min =    0 RPM)          FAULT
CPU1-fan: 2830 RPM  (min = 2000 RPM)

[root at matrix ~]# tail -n 17 /etc/sensors.conf
chip "pc87427-*"
   label fan1 "case-fan1"
   label fan2 "case-fan2"
   label fan3 "case-fan3"
   label fan4 "case-fan4"
   label fan5 "not-inst"
   label fan6 "CPU0-fan"
   label fan7 "not-inst"
   label fan8 "CPU1-fan"
   set fan1_min 2000
   set fan2_min 2000
   set fan3_min 2000
   set fan4_min 2000
   set fan5_min 0
   set fan6_min 2000
   set fan7_min 0
   set fan8_min 2000

JFYI, if I put fan[1-4]_min on 3000, the fans start running at about
4500RPM, giving quite a cool ambiance in the chassis. :)
2000 should be enough.

Have a good time!
Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

Michael,

> [root at matrix ~]# sensors
> pc87427-isa-0840
> Adapter: ISA adapter
> case-fan1:3678 RPM  (min = 2000 RPM)
> case-fan2:3391 RPM  (min = 2000 RPM)
> case-fan3:3400 RPM  (min = 2000 RPM)
> case-fan4:3366 RPM  (min = 2000 RPM)
> not-inst:    0 RPM  (min =    0 RPM)          FAULT
> CPU0-fan: 2915 RPM  (min = 2000 RPM)
> not-inst:    0 RPM  (min =    0 RPM)          FAULT
> CPU1-fan: 2830 RPM  (min = 2000 RPM)

You can add the following to your configuration file:

   ignore fan5
   ignore fan7

That way the unused fan inputs won't even show in the output, making it
a bit more user-friendly.

> [root at matrix ~]# tail -n 17 /etc/sensors.conf
> chip "pc87427-*"
>    label fan1 "case-fan1"
>    label fan2 "case-fan2"
>    label fan3 "case-fan3"
>    label fan4 "case-fan4"
>    label fan5 "not-inst"
>    label fan6 "CPU0-fan"
>    label fan7 "not-inst"
>    label fan8 "CPU1-fan"
>    set fan1_min 2000
>    set fan2_min 2000
>    set fan3_min 2000
>    set fan4_min 2000
>    set fan5_min 0
>    set fan6_min 2000
>    set fan7_min 0
>    set fan8_min 2000

I'd suggest that you get rid of the default configuration file
completely and write one from scratch with simply the section above,
libsensors will perform much better.

> JFYI, if I put fan[1-4]_min on 3000, the fans start running at about
> 4500RPM, giving quite a cool ambiance in the chassis. :)
> 2000 should be enough.

I have been playing a bit with a similar board lately and noticed the
same. The low limits seem to somehow influence the fan speeds. I know
that the PC87427 has fan speed control features, but I didn't read the
datasheet in its entirety so I don't know how it works exactly. At any
rate this behvior differers completely from what other chips do.
Usually the low limits simply trigger alarms when crossed, and do not
influence the speed itself.

OK, now that it works, I will have to clean up the driver to make it
suitable for upstream submission. In particular this implies converting
the driver from an i2c-isa driver to a platform driver. Will you be
able to test this second variant of the driver?

Thanks,
-- 
Jean Delvare

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hello Jean,

Jean Delvare wrote:
> OK, now that it works, I will have to clean up the driver to make it
> suitable for upstream submission. In particular this implies converting
> the driver from an i2c-isa driver to a platform driver. Will you be
> able to test this second variant of the driver?
>   
Sure, if it's not too much work. :)
Regards - Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

Hi Michael,

> Jean Delvare wrote:
> > OK, now that it works, I will have to clean up the driver to make it
> > suitable for upstream submission. In particular this implies converting
> > the driver from an i2c-isa driver to a platform driver. Will you be
> > able to test this second variant of the driver?
>
> Sure, if it's not too much work. :)

Well hopefully this new version of the driver will just work. However,
be aware that, contrary to the previous version, I couldn't give a try
to this one, so you're the first tester. This means there could be a
couple sharp edges left, please let me know if you notice anything
wrong.

The changes are essentially in the way the driver is registered, so
basically, if you are able to load, unload and reload the driver, and
everything still works, it's a good sign that the conversion is a
success. You should also see the reserved I/O region in /proc/ioports
as "pc87427 FMC".

Please give it a try and report!

Thanks,
-- 
Jean Delvare
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pc87427.c
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061009/fdef6935/attachment.c 

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hi Jean,

Jean Delvare wrote:
> Well hopefully this new version of the driver will just work. However,
> be aware that, contrary to the previous version, I couldn't give a try
> to this one, so you're the first tester. This means there could be a
> couple sharp edges left, please let me know if you notice anything
> wrong.
>
> The changes are essentially in the way the driver is registered, so
> basically, if you are able to load, unload and reload the driver, and
> everything still works, it's a good sign that the conversion is a
> success. You should also see the reserved I/O region in /proc/ioports
> as "pc87427 FMC".
>
> Please give it a try and report!
>   

I tried it - i.e. I replaced pc87427.c in a copy of the directory
containing the old pc87427.c
But I regret to report a failure. I try to document the relevant things...

(SENSORS-DETECT)
# sensors-detect revision 4196 (2006-10-06 11:27:56 +0200)
...
Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-i801' for device 0000:00:1f.3: Intel 82801EB ICH5

We will now try to load each adapter module in turn.
Load `i2c-i801' (say NO if built into your kernel)? (YES/no):
FATAL: Module i2c_i801 not found.
Loading failed... skipping.
...
Found `Nat. Semi. PC87427 Super IO Fan Sensors'             Success!
    (address 0x840, driver `pc87427')
Found `Nat. Semi. PC87427 Super IO Health Sensors'          Success!
    (address 0x880, driver `to-be-written')
...
Driver `pc87427' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0840 (Busdriver `i2c-isa')
    Chip `Nat. Semi. PC87427 Super IO Fan Sensors' (confidence: 9)

Driver `to-be-written' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0880 (Busdriver `i2c-isa')
    Chip `Nat. Semi. PC87427 Super IO Health Sensors' (confidence: 9)
...
To load everything that is needed, add this to some /etc/rc* file:

#----cut here----
# I2C adapter drivers
modprobe i2c-isa
# Chip drivers
modprobe pc87427
# no driver for Nat. Semi. PC87427 Super IO Health Sensors yet
# sleep 2 # optional
/usr/local/bin/sensors -s # recommended
#----cut here----
...
(MK tries it)
[root at matrix PC87427-platform-driver]# modprobe i2c-isa
[root at matrix PC87427-platform-driver]# modprobe pc87427
[root at matrix PC87427-platform-driver]# /usr/local/bin/sensors -s #
recommended
No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.
...
(MK)
Nothing happens yet in syslog or dmesg
As soon as I execute 'sensors' with the config below, I'll reveice these
lines in dmesg:
(DMESG)
pc87427: readall_fan: dataÿff88003d5e2a40, nr=0
pc87427: readall_fan: dataÿff88003d5e2a40, nr=1
pc87427: readall_fan: dataÿff88003d5e2a40, nr=2
pc87427: readall_fan: dataÿff88003d5e2a40, nr=3
pc87427: readall_fan: dataÿff88003d5e2a40, nr=4
pc87427: readall_fan: dataÿff88003d5e2a40, nr=5
pc87427: readall_fan: dataÿff88003d5e2a40, nr=6
pc87427: readall_fan: dataÿff88003d5e2a40, nr=7

(my /etc/sensors.conf:)
chip "pc87427-*"
   label fan1 "case-fan1"
   label fan2 "case-fan2"
   label fan3 "case-fan3"
   label fan4 "case-fan4"
   label fan5 "not-inst"
   label fan6 "CPU0-fan"
   label fan7 "not-inst"
   label fan8 "CPU1-fan"
   set fan1_min 2000
   set fan2_min 2000
   set fan3_min 2000
   set fan4_min 2000
   ignore fan5
   set fan6_min 2000
   ignore fan7
   set fan8_min 2000

(cat /proc/ioports)
[root at matrix PC87427-platform-driver]# cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
03c0-03df : vga+
03f6-03f6 : ide0
0840-085f : pc87427 FMC
0cf8-0cff : PCI conf1
1000-107f : 0000:00:1f.0
  1000-107f : motherboard
    1000-1003 : PM1a_EVT_BLK
    1004-1005 : PM1a_CNT_BLK
    1008-100b : PM_TMR
    1020-1020 : PM2_CNT_BLK
    1028-102f : GPE0_BLK
1100-111f : 0000:00:1f.3
1180-11bf : 0000:00:1f.0
  1180-11bf : motherboard
1400-141f : 0000:00:1d.0
  1400-141f : uhci_hcd
1420-143f : 0000:00:1d.1
  1420-143f : uhci_hcd
1440-145f : 0000:00:1d.2
  1440-145f : uhci_hcd
1460-147f : 0000:00:1d.3
  1460-147f : uhci_hcd
14a0-14af : 0000:00:1f.1
  14a0-14a7 : ide0
  14a8-14af : ide1
2000-3fff : PCI Bus #02
  2000-2fff : PCI Bus #03
    2000-20ff : 0000:03:02.0
    2400-24ff : 0000:03:02.0
    2800-28ff : 0000:03:02.1
    2c00-2cff : 0000:03:02.1
  3000-3fff : PCI Bus #04
    3000-303f : 0000:04:01.0
      3000-303f : 3w-9xxx
    3040-307f : 0000:04:02.0
      3040-307f : e1000
    3080-30bf : 0000:04:02.1
      3080-30bf : e1000
4000-4fff : PCI Bus #07
  4000-40ff : 0000:07:01.0
fe00-fe00 : motherboard

(MK)
I hope, I didn't miss anything ...

By the way, I found that sensors-detect now detects a PC87360:
Found `Nat. Semi. PC87360 Super IO Fan Sensors'
    (but not activated)
If I try a 'modprobe pc87360' I get
FATAL: Error inserting pc87360
(/lib/modules/2.6.16-xen/kernel/drivers/hwmon/pc87360.ko): No such device
pc87360: Device 0x09 not activated
pc87360: No active logical device, module not inserted.

I don't know if it's somehow related. I think, it finds it at least
since the snapshot you published recently. It definitely didn't
recognize before.

Tell me if I can do / find out more for you...

Regards - Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

> Hi Jean,
> 
> Jean Delvare wrote:
> > Well hopefully this new version of the driver will just work. However,
> > be aware that, contrary to the previous version, I couldn't give a try
> > to this one, so you're the first tester. This means there could be a
> > couple sharp edges left, please let me know if you notice anything
> > wrong.
> >
> > The changes are essentially in the way the driver is registered, so
> > basically, if you are able to load, unload and reload the driver, and
> > everything still works, it's a good sign that the conversion is a
> > success. You should also see the reserved I/O region in /proc/ioports
> > as "pc87427 FMC".
> >
> > Please give it a try and report!
> >   
> 
> I tried it - i.e. I replaced pc87427.c in a copy of the directory
> containing the old pc87427.c
> But I regret to report a failure. I try to document the relevant things...

Is the attached version any better? I had forgotten to create the
"name" attribute file, and libsensors needs it. This is fixed now,
hopefully this is all that was missing.

> By the way, I found that sensors-detect now detects a PC87360:
> Found `Nat. Semi. PC87360 Super IO Fan Sensors'
>     (but not activated)
> If I try a 'modprobe pc87360' I get
> FATAL: Error inserting pc87360
> (/lib/modules/2.6.16-xen/kernel/drivers/hwmon/pc87360.ko): No such device
> pc87360: Device 0x09 not activated
> pc87360: No active logical device, module not inserted.
> 
> I don't know if it's somehow related. I think, it finds it at least
> since the snapshot you published recently. It definitely didn't
> recognize before.

I have seen the same of the test system I had access to. I know for
sure that there is no such chip on the board, this is a misdetection.
Just ignore it. I can't tell why you didn't see it before.

-- 
Jean Delvare
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pc87427.c
Url: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20061009/46037df5/attachment-0001.c 

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hi Jean,

Jean Delvare wrote:
>> I tried it - i.e. I replaced pc87427.c in a copy of the directory
>> containing the old pc87427.c
>> But I regret to report a failure. I try to document the relevant things...
>>     
>
> Is the attached version any better? I had forgotten to create the
> "name" attribute file, and libsensors needs it. This is fixed now,
> hopefully this is all that was missing.
>
>   
Yeah, it seems 2b perfect like this - thank you very much for your effort!

[root at matrix PC87427-platform-driver]# sensors
pc87427-isa-0840
Adapter: ISA adapter
case-fan1:3698 RPM  (min = 2000 RPM)
case-fan2:3400 RPM  (min = 2000 RPM)
case-fan3:3400 RPM  (min = 2000 RPM)
case-fan4:3375 RPM  (min = 2000 RPM)
CPU0-fan: 3075 RPM  (min = 2000 RPM)
CPU1-fan: 2934 RPM  (min = 2000 RPM)

[root at matrix PC87427-platform-driver]# dmesg | tail -n 8
pc87427: readall_fan: dataÿff88003f09e540, nr=0
pc87427: readall_fan: dataÿff88003f09e540, nr=1
pc87427: readall_fan: dataÿff88003f09e540, nr=2
pc87427: readall_fan: dataÿff88003f09e540, nr=3
pc87427: readall_fan: dataÿff88003f09e540, nr=4
pc87427: readall_fan: dataÿff88003f09e540, nr=5
pc87427: readall_fan: dataÿff88003f09e540, nr=6
pc87427: readall_fan: dataÿff88003f09e540, nr=7

Salut
Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

Hallo Michael,

> Jean Delvare wrote:
> > Is the attached version any better? I had forgotten to create the
> > "name" attribute file, and libsensors needs it. This is fixed now,
> > hopefully this is all that was missing.
>
> Yeah, it seems 2b perfect like this - thank you very much for your effort!

Thanks for testing :)

> [root at matrix PC87427-platform-driver]# sensors
> pc87427-isa-0840
> Adapter: ISA adapter
> case-fan1:3698 RPM  (min = 2000 RPM)
> case-fan2:3400 RPM  (min = 2000 RPM)
> case-fan3:3400 RPM  (min = 2000 RPM)
> case-fan4:3375 RPM  (min = 2000 RPM)
> CPU0-fan: 3075 RPM  (min = 2000 RPM)
> CPU1-fan: 2934 RPM  (min = 2000 RPM)

Looks alright. Did you try unloading and reloading the driver a couple
time? If everything works OK for you I'll push the driver into -mm
soon, so that it can receive wider testing.

> [root at matrix PC87427-platform-driver]# dmesg | tail -n 8
> pc87427: readall_fan: dataÿff88003f09e540, nr=0
> pc87427: readall_fan: dataÿff88003f09e540, nr=1
> pc87427: readall_fan: dataÿff88003f09e540, nr=2
> pc87427: readall_fan: dataÿff88003f09e540, nr=3
> pc87427: readall_fan: dataÿff88003f09e540, nr=4
> pc87427: readall_fan: dataÿff88003f09e540, nr=5
> pc87427: readall_fan: dataÿff88003f09e540, nr=6
> pc87427: readall_fan: dataÿff88003f09e540, nr=7

These are temporary debugging messages which I put in there to
investigate an older bug, which of course never happened again. You can
get rid of them by removing -DDEBUG in the Makefile and building the
driver again. You can also replace -g with -O2 for faster and smaller
code.

Thanks,
-- 
Jean Delvare

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hi Jean,

Jean Delvare schrieb:
> Looks alright. Did you try unloading and reloading the driver a couple
> time? If everything works OK for you I'll push the driver into -mm
> soon, so that it can receive wider testing.
>   

sorry, it took a bit ... not because I tested for so long time... ;-)
I've been modprobe'ing und rmmod'ing the driver constantly for an hour
or so (every few seconds, with 'watch') and I can still receive the
expected results without any flaw, nothing irregular, no strange syslog
messages etc.

>> [root at matrix PC87427-platform-driver]# dmesg | tail -n 8
>> pc87427: readall_fan: dataÿff88003f09e540, nr=0
>> pc87427: readall_fan: dataÿff88003f09e540, nr=1
>> pc87427: readall_fan: dataÿff88003f09e540, nr=2
>> pc87427: readall_fan: dataÿff88003f09e540, nr=3
>> pc87427: readall_fan: dataÿff88003f09e540, nr=4
>> pc87427: readall_fan: dataÿff88003f09e540, nr=5
>> pc87427: readall_fan: dataÿff88003f09e540, nr=6
>> pc87427: readall_fan: dataÿff88003f09e540, nr=7
>>     
>
> These are temporary debugging messages which I put in there to
> investigate an older bug, which of course never happened again. You can
> get rid of them by removing -DDEBUG in the Makefile and building the
> driver again. You can also replace -g with -O2 for faster and smaller
> code.
>   

Debugging messages are gone now.
Thanks & have a nice weekend

Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Michael Kress wrote:
> sorry, it took a bit ... not because I tested for so long time... ;-)
> I've been modprobe'ing und rmmod'ing the driver constantly for an hour
> or so (every few seconds, with 'watch') and I can still receive the
> expected results without any flaw, nothing irregular, no strange syslog
> messages etc.
>   

woops, that was a bit too quick - I got that after calling 'sensors'
every 3 seconds for the whole afternoon:

Oct 14 17:19:14 matrix kernel: general protection fault: 0000 [1] SMP
Oct 14 17:19:14 matrix kernel: CPU 0
Oct 14 17:19:14 matrix kernel: Modules linked in: xfs exportfs pc87427
hwmon i2c_isa i2c_core xt_physdev iptable_filter ip_tables x_tables
bridge ipv6 autofs4 sunrpc pcmcia yenta_socket rsrc_nonstatic
pcmcia_core joydev video thermal processor fan container button battery
ac uhci_hcd ehci_hcd e1000 dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod
3w_9xxx aic79xx scsi_transport_spi sd_mod
Oct 14 17:19:14 matrix kernel: Pid: 16330, comm: sensors Not tainted
2.6.16-xen #2
Oct 14 17:19:14 matrix kernel: RIP: e030:[<ffffffff80178679>]
<ffffffff80178679>{vfs_read+281}
Oct 14 17:19:14 matrix kernel: RSP: e02b:ffff88003b5adf18  EFLAGS: 00010202
Oct 14 17:19:14 matrix kernel: RAX: 0000000000000002 RBX:
4c0841894c01894c RCX: 0000000000000000
Oct 14 17:19:14 matrix kernel: RDX: 0000000000000002 RSI:
0000000000000001 RDI: ffff8800352fe1e0
Oct 14 17:19:14 matrix kernel: RBP: 0000000000000002 R08:
00000000fffffffb R09: 0000000000000000
Oct 14 17:19:14 matrix kernel: R10: 00000000ffffffff R11:
0000000000000000 R12: 0000000000000001
Oct 14 17:19:14 matrix kernel: R13: 00002ba7142df000 R14:
ffff88003b5adf50 R15: 000000000054ff10
Oct 14 17:19:14 matrix kernel: FS:  00002ba7141d98a0(0000)
GS:ffffffff8049b000(0000) knlGS:0000000000000000
Oct 14 17:19:14 matrix kernel: CS:  e033 DS: 0000 ES: 0000
Oct 14 17:19:14 matrix kernel: Process sensors (pid: 16330, threadinfo
ffff88003b5ac000, task ffff88003fec8970)
Oct 14 17:19:14 matrix kernel: Stack: ffff880000e3fc80 0000000000001000
00002ba7142df000 fffffffffffffff7
Oct 14 17:19:15 matrix kernel:        0000000000000000 ffffffff80178a23
0000000000000000 0000000000000002
Oct 14 17:19:15 matrix kernel:        0000000000001000 000000000054ff10
Oct 14 17:19:15 matrix kernel: Call Trace:
<ffffffff80178a23>{sys_read+83} <ffffffff8010b206>{system_call+134}
Oct 14 17:19:16 matrix kernel:        <ffffffff8010b180>{system_call+0}
Oct 14 17:19:16 matrix kernel:
Oct 14 17:19:16 matrix kernel: Code: 4c 8b 6b 10 48 89 df 41 0f b7 45 4c
25 00 f0 00 00 3d 00 40
Oct 14 17:19:16 matrix kernel: RIP <ffffffff80178679>{vfs_read+281} RSP
<ffff88003b5adf18>

But it only appeared once, I normally load the module once, then I call
it every 3 sec over the whole day. The only difference today: I loaded
the module lots of times today.
Another difference: I activated MSI in the kernel in order to solve this
problem: http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0101.html
CONFIG_PCI_MSI=y

Salut - Michael


-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hi,

Michael Kress wrote:
> But it only appeared once, I normally load the module once, then I call
> it every 3 sec over the whole day. The only difference today: I loaded
> the module lots of times today.
> Another difference: I activated MSI in the kernel in order to solve this
> problem: http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0101.html
> CONFIG_PCI_MSI=y
>   

I recompiled the kernel without CONFIG_PCI_MSI and the same thing
happened. It's absoluteley the same config as before...

Oct 15 09:57:13 matrix kernel: general protection fault: 0000 [1] SMP
Oct 15 09:57:13 matrix kernel: CPU 0
Oct 15 09:57:13 matrix kernel: Modules linked in: pc87427 hwmon i2c_isa
i2c_core xt_physdev iptable_filter ip_tables x_tables bridge ipv6
autofs4 sunrpc pcmcia yenta_socket rsrc_nonstatic pcmcia_core joydev
video thermal processor fan container button battery ac uhci_hcd
ehci_hcd e1000 dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod 3w_9xxx
aic79xx scsi_transport_spi sd_mod
Oct 15 09:57:13 matrix kernel: Pid: 9044, comm: sensors Not tainted
2.6.16-xen #1
Oct 15 09:57:13 matrix kernel: RIP: e030:[<ffffffff80178679>]
<ffffffff80178679>{vfs_read+281}
Oct 15 09:57:13 matrix kernel: RSP: e02b:ffff880028b99f18  EFLAGS: 00010202
Oct 15 09:57:13 matrix kernel: RAX: 0000000000000002 RBX:
4c0841894c01894c RCX: 0000000000000000
Oct 15 09:57:13 matrix kernel: RDX: 0000000000000002 RSI:
0000000000000001 RDI: ffff88003dd64260
Oct 15 09:57:13 matrix kernel: RBP: 0000000000000002 R08:
00000000fffffffb R09: 0000000000000000
Oct 15 09:57:13 matrix kernel: R10: 00000000ffffffff R11:
0000000000000000 R12: 0000000000000001
Oct 15 09:57:13 matrix kernel: R13: 00002b0dfe3ca000 R14:
ffff880028b99f50 R15: 000000000054ff10
Oct 15 09:57:13 matrix kernel: FS:  00002b0dfe2c48a0(0000)
GS:ffffffff8049a000(0000) knlGS:0000000000000000
Oct 15 09:57:13 matrix kernel: CS:  e033 DS: 0000 ES: 0000
Oct 15 09:57:13 matrix kernel: Process sensors (pid: 9044, threadinfo
ffff880028b98000, task ffff88003ea530e0)
Oct 15 09:57:13 matrix kernel: Stack: ffff88003fec2180 0000000000001000
00002b0dfe3ca000 fffffffffffffff7
Oct 15 09:57:13 matrix kernel:        0000000000000000 ffffffff80178a23
0000000000000000 0000000000000002
Oct 15 09:57:14 matrix kernel:        0000000000001000 000000000054ff10
Oct 15 09:57:14 matrix kernel: Call Trace:
<ffffffff80178a23>{sys_read+83} <ffffffff8010b206>{system_call+134}
Oct 15 09:57:14 matrix kernel:        <ffffffff8010b180>{system_call+0}
Oct 15 09:57:14 matrix kernel:
Oct 15 09:57:14 matrix kernel: Code: 4c 8b 6b 10 48 89 df 41 0f b7 45 4c
25 00 f0 00 00 3d 00 40
Oct 15 09:57:14 matrix kernel: RIP <ffffffff80178679>{vfs_read+281} RSP
<ffff880028b99f18>

dmesg outputs the same, sensors is running every 3 secs, so must be
something else.
It doesn't really disturb me as the rest of the system really stays
stable and sensors still displays the fan speeds, but maybe you'd like
to find the reason why.

Salut - Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

Hi Michael,

Michael Kress wrote:
> > But it only appeared once, I normally load the module once, then I call
> > it every 3 sec over the whole day. The only difference today: I loaded
> > the module lots of times today.
> > Another difference: I activated MSI in the kernel in order to solve this
> > problem: http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0101.html
> > CONFIG_PCI_MSI=y
> 
> I recompiled the kernel without CONFIG_PCI_MSI and the same thing
> happened. It's absoluteley the same config as before...

Did you also cycle the pc87427 module several times this time?

> Oct 15 09:57:13 matrix kernel: general protection fault: 0000 [1] SMP
> Oct 15 09:57:13 matrix kernel: CPU 0
> Oct 15 09:57:13 matrix kernel: Modules linked in: pc87427 hwmon i2c_isa
> i2c_core xt_physdev iptable_filter ip_tables x_tables bridge ipv6
> autofs4 sunrpc pcmcia yenta_socket rsrc_nonstatic pcmcia_core joydev
> video thermal processor fan container button battery ac uhci_hcd
> ehci_hcd e1000 dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod 3w_9xxx
> aic79xx scsi_transport_spi sd_mod
> Oct 15 09:57:13 matrix kernel: Pid: 9044, comm: sensors Not tainted
> 2.6.16-xen #1
> Oct 15 09:57:13 matrix kernel: RIP: e030:[<ffffffff80178679>]
> <ffffffff80178679>{vfs_read+281}
> Oct 15 09:57:13 matrix kernel: RSP: e02b:ffff880028b99f18  EFLAGS: 00010202
> Oct 15 09:57:13 matrix kernel: RAX: 0000000000000002 RBX:
> 4c0841894c01894c RCX: 0000000000000000
> Oct 15 09:57:13 matrix kernel: RDX: 0000000000000002 RSI:
> 0000000000000001 RDI: ffff88003dd64260
> Oct 15 09:57:13 matrix kernel: RBP: 0000000000000002 R08:
> 00000000fffffffb R09: 0000000000000000
> Oct 15 09:57:13 matrix kernel: R10: 00000000ffffffff R11:
> 0000000000000000 R12: 0000000000000001
> Oct 15 09:57:13 matrix kernel: R13: 00002b0dfe3ca000 R14:
> ffff880028b99f50 R15: 000000000054ff10
> Oct 15 09:57:13 matrix kernel: FS:  00002b0dfe2c48a0(0000)
> GS:ffffffff8049a000(0000) knlGS:0000000000000000
> Oct 15 09:57:13 matrix kernel: CS:  e033 DS: 0000 ES: 0000
> Oct 15 09:57:13 matrix kernel: Process sensors (pid: 9044, threadinfo
> ffff880028b98000, task ffff88003ea530e0)
> Oct 15 09:57:13 matrix kernel: Stack: ffff88003fec2180 0000000000001000
> 00002b0dfe3ca000 fffffffffffffff7
> Oct 15 09:57:13 matrix kernel:        0000000000000000 ffffffff80178a23
> 0000000000000000 0000000000000002
> Oct 15 09:57:14 matrix kernel:        0000000000001000 000000000054ff10
> Oct 15 09:57:14 matrix kernel: Call Trace:
> <ffffffff80178a23>{sys_read+83} <ffffffff8010b206>{system_call+134}
> Oct 15 09:57:14 matrix kernel:        <ffffffff8010b180>{system_call+0}
> Oct 15 09:57:14 matrix kernel:
> Oct 15 09:57:14 matrix kernel: Code: 4c 8b 6b 10 48 89 df 41 0f b7 45 4c
> 25 00 f0 00 00 3d 00 40
> Oct 15 09:57:14 matrix kernel: RIP <ffffffff80178679>{vfs_read+281} RSP
> <ffff880028b99f18>
> 
> dmesg outputs the same, sensors is running every 3 secs, so must be
> something else.
> It doesn't really disturb me as the rest of the system really stays
> stable and sensors still displays the fan speeds, but maybe you'd like
> to find the reason why.

Well the problem occurs in vfs_read(), so even before reaching the
pc87427 code. I don't quite see how my driver could be responsible.

You could try repeatedly reading other random sysfs files instead, to
see if you can reproduce the problem.

Which 2.6.16 kernel are you using exactly? The 2.6.16.y series was
quite long, please make sure you are using one of the latest updates.

If this is an SMP and/or PREEMPT kernel, you may want to try UP and/or
non-PREEMPT to see if it makes a difference.

-- 
Jean Delvare

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Michael Kress]

Hi Jean,

Jean Delvare wrote:
>> I recompiled the kernel without CONFIG_PCI_MSI and the same thing
>> happened. It's absoluteley the same config as before...
>>     
>
> Did you also cycle the pc87427 module several times this time?
>   

No, I just loaded it once.

> Well the problem occurs in vfs_read(), so even before reaching the
> pc87427 code. I don't quite see how my driver could be responsible.
>
> You could try repeatedly reading other random sysfs files instead, to
> see if you can reproduce the problem.
>
> Which 2.6.16 kernel are you using exactly? The 2.6.16.y series was
> quite long, please make sure you are using one of the latest updates.
>
> If this is an SMP and/or PREEMPT kernel, you may want to try UP and/or
> non-PREEMPT to see if it makes a difference.
>   
It's the one that's being downloaded with xen-3.0.2, i.e.
linux-2.6.16.tar.bz2
I tried it with the stock kernel from CentOS (kernel-2.6.9-42.0.3.EL)
but pc87427 doesn't compile with that, although there's lots of stuff
back-patched.
I can't get another kernel than 2.6.16, because all the xen patches rely
on this version and I need xen.
I will try the newest from the 2.6.16.y series, give me another day to
try it, I think xen provided the oldest 2.6.16 one it could find. I'll
tell you if I got further with that.
Maybe it's also related with the "nobody cared" phenomena from
http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0101.html - I
suspect the irq issue to be Supermicro related.

Salut - Michael

-- 
Michael Kress, kress at hal.saar.de
http://www.michael-kress.de / http://kress.net
P E N G U I N S   A R E   C O O L

[lm-sensors] Supermicro X6DH8-G2+ / sensors not working

[Jean Delvare]

Hi Michael,

On Sun, 15 Oct 2006 22:56:40 +0200, Michael Kress wrote:
> Jean Delvare wrote:
> > Well the problem occurs in vfs_read(), so even before reaching the
> > pc87427 code. I don't quite see how my driver could be responsible.
> >
> > You could try repeatedly reading other random sysfs files instead, to
> > see if you can reproduce the problem.
> >
> > Which 2.6.16 kernel are you using exactly? The 2.6.16.y series was
> > quite long, please make sure you are using one of the latest updates.
> >
> > If this is an SMP and/or PREEMPT kernel, you may want to try UP and/or
> > non-PREEMPT to see if it makes a difference.
> >   
> It's the one that's being downloaded with xen-3.0.2, i.e.
> linux-2.6.16.tar.bz2
> I tried it with the stock kernel from CentOS (kernel-2.6.9-42.0.3.EL)
> but pc87427 doesn't compile with that, although there's lots of stuff
> back-patched.

The previous version of the pc87427 driver (i2c-isa-based) should work
on 2.6.9 with minor adjustments, but I admit I'm not really interested
in you testing this, as the version of the driver which will be merged
is the platform-based one anyway.

> I can't get another kernel than 2.6.16, because all the xen patches rely
> on this version and I need xen.
> I will try the newest from the 2.6.16.y series, give me another day to
> try it, I think xen provided the oldest 2.6.16 one it could find. I'll
> tell you if I got further with that.

OK, thanks.

> Maybe it's also related with the "nobody cared" phenomena from
> http://www.ussg.iu.edu/hypermail/linux/kernel/0610.1/0101.html - I
> suspect the irq issue to be Supermicro related.

I see no relation between the two problems.

Anyway my plan is now to get my pc87427 driver in -mm. If others report
the same problem you had, we'll have more data points to investigate.

Thanks,
-- 
Jean Delvare