[lm-sensors] asb100 not working in kernel 2.6.16

[lm-sensors] asb100 not working in kernel 2.6.16

[Paulo Roma Cavalcanti]

I have been using lm_sensors for a long time
on an Asus P4S333 motherboard.
However, they are no longer working with the 2.6.16
kernel series. During the boot there is a message
saying it cannot find any i2c information.

Interesting is that the modules are loaded:

eeprom                  7249  0
asb100                 20437  0
hwmon_vid               2881  1 asb100
hwmon                   3269  1 asb100
i2c_sis96x              5829  0
i2c_core               21697  3 eeprom,asb100,i2c_sis96x
rfcomm                 36821  0
l2cap                  24641  5 rfcomm

But if I try to read the sensors, I get:

Can't access procfs/sysfs file
Unable to find i2c bus information;
For 2.6 kernels, make sure you have mounted sysfs and libsensors
was compiled with sysfs support!
For older kernels, make sure you have done 'modprobe i2c-proc'!

My system is a Fedora 4 with latest lm_sensors from ATrpms.

Linux version 2.6.16-1.2096_FC4 (bhcompile at hs20-bc1-4.build.redhat.com)

I am loading the modules below in /etc/sysconfig/lm_sensors:

MODULE_0=i2c-sis96x
MODULE_1=asb100
MODULE_2îprom

They work very well with kernel 2.6.15 and below, only.

I appreciate any suggestion.

Thank you.

/Paulo Roma

[lm-sensors] asb100 not working in kernel 2.6.16

[Mark M. Hoffman]

Hi Paulo:

* Paulo Roma Cavalcanti <crotalus at superig.com.br> [2006-04-21 20:06:17 -0300]:
> I have been using lm_sensors for a long time
> on an Asus P4S333 motherboard.
> However, they are no longer working with the 2.6.16
> kernel series. During the boot there is a message
> saying it cannot find any i2c information.

This is in fact the same board I used to develop both the sis96x and asb100
drivers in the first place.

> Interesting is that the modules are loaded:
> 
> eeprom                  7249  0
> asb100                 20437  0
> hwmon_vid               2881  1 asb100
> hwmon                   3269  1 asb100
> i2c_sis96x              5829  0
> i2c_core               21697  3 eeprom,asb100,i2c_sis96x
> rfcomm                 36821  0
> l2cap                  24641  5 rfcomm
> 
> But if I try to read the sensors, I get:
> 
> Can't access procfs/sysfs file
> Unable to find i2c bus information;
> For 2.6 kernels, make sure you have mounted sysfs and libsensors
> was compiled with sysfs support!
> For older kernels, make sure you have done 'modprobe i2c-proc'!
> 
> My system is a Fedora 4 with latest lm_sensors from ATrpms.
> 
> Linux version 2.6.16-1.2096_FC4 (bhcompile at hs20-bc1-4.build.redhat.com)

I just booted my P4S333 with this kernel under FC4... same result.  Oddly
enough, it works just fine with a vanilla 2.6.16.

Paulo: if you run 'lspci' I think you will find device "00:02.1" to be
missing.  This is the problem.  Somehow, the vendor kernel does not do
the PCI quirk properly to "unhide" that device.  I will look into it
further tomorrow... but at least, the workaround is to use a vanilla
kernel.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] asb100 not working in kernel 2.6.16

[Mark M. Hoffman]

Hi Paulo:

> * Paulo Roma Cavalcanti <crotalus at superig.com.br> [2006-04-21 20:06:17 -0300]:
> > I have been using lm_sensors for a long time
> > on an Asus P4S333 motherboard.
> > However, they are no longer working with the 2.6.16
> > kernel series. During the boot there is a message
> > saying it cannot find any i2c information.

* Mark M. Hoffman <mhoffman at lightlink.com> [2006-04-22 14:35:15 -0400]:
> This is in fact the same board I used to develop both the sis96x and asb100
> drivers in the first place.
> 
> > Interesting is that the modules are loaded:
> > 
> > eeprom                  7249  0
> > asb100                 20437  0
> > hwmon_vid               2881  1 asb100
> > hwmon                   3269  1 asb100
> > i2c_sis96x              5829  0
> > i2c_core               21697  3 eeprom,asb100,i2c_sis96x
> > rfcomm                 36821  0
> > l2cap                  24641  5 rfcomm
> > 
> > But if I try to read the sensors, I get:
> > 
> > Can't access procfs/sysfs file
> > Unable to find i2c bus information;
> > For 2.6 kernels, make sure you have mounted sysfs and libsensors
> > was compiled with sysfs support!
> > For older kernels, make sure you have done 'modprobe i2c-proc'!
> > 
> > My system is a Fedora 4 with latest lm_sensors from ATrpms.
> > 
> > Linux version 2.6.16-1.2096_FC4 (bhcompile at hs20-bc1-4.build.redhat.com)
> 
> I just booted my P4S333 with this kernel under FC4... same result.  Oddly
> enough, it works just fine with a vanilla 2.6.16.
> 
> Paulo: if you run 'lspci' I think you will find device "00:02.1" to be
> missing.  This is the problem.  Somehow, the vendor kernel does not do
> the PCI quirk properly to "unhide" that device.  I will look into it
> further tomorrow... but at least, the workaround is to use a vanilla
> kernel.

Here's the problem:  two PCI quirks (drivers/pci/quirks.c) are required for
the SMBus device on this board.  The first is quirk_sis_503(), which twiddles
some bits so that the south bridge has the proper name: 

	00:02.0 Class 0601: 1039:0961

The second quirk is quirk_sis_96x_smbus(), which will only run if the above
device is found.

But in the FC4 kernel, the second quirk is processed first... so 1039:0961
is not yet available.  If you look at System.map, for some reason the 
SMBus quirks come first in the link order... even though those are declared
after the 503 quirk in the same file.  

[mark at mars boot]$ cat System.map-2.6.16-1.2096_FC4 | grep __pci_fixup_ | grep PCI_VENDOR_ID_SI | sort
c03589ac r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_LPCquirk_sis_96x_smbus
c03589b4 r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_963quirk_sis_96x_smbus
c03589bc r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_962quirk_sis_96x_smbus
c03589c4 r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_961quirk_sis_96x_smbus
c03589cc r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_503quirk_sis_503

So, two possibilities: 

1) We can't depend on the link order, so the quirks need to be fixed.

2) We *can* depend on link order, but FC4 breaks it somehow.

I'm going to file a bug in FC bugzilla, and copy this message into it.
We'll see what they think.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] asb100 not working in kernel 2.6.16

[Paulo Roma Cavalcanti]

Mark M. Hoffman wrote:
> Hi Paulo:
> 
>> * Paulo Roma Cavalcanti <crotalus at superig.com.br> [2006-04-21 20:06:17 -0300]:
>>> I have been using lm_sensors for a long time
>>> on an Asus P4S333 motherboard.
>>> However, they are no longer working with the 2.6.16
>>> kernel series. During the boot there is a message
>>> saying it cannot find any i2c information.
> 
> * Mark M. Hoffman <mhoffman at lightlink.com> [2006-04-22 14:35:15 -0400]:
>> This is in fact the same board I used to develop both the sis96x and asb100
>> drivers in the first place.
>>
>>> Interesting is that the modules are loaded:
>>>
>>> eeprom                  7249  0
>>> asb100                 20437  0
>>> hwmon_vid               2881  1 asb100
>>> hwmon                   3269  1 asb100
>>> i2c_sis96x              5829  0
>>> i2c_core               21697  3 eeprom,asb100,i2c_sis96x
>>> rfcomm                 36821  0
>>> l2cap                  24641  5 rfcomm
>>>
>>> But if I try to read the sensors, I get:
>>>
>>> Can't access procfs/sysfs file
>>> Unable to find i2c bus information;
>>> For 2.6 kernels, make sure you have mounted sysfs and libsensors
>>> was compiled with sysfs support!
>>> For older kernels, make sure you have done 'modprobe i2c-proc'!
>>>
>>> My system is a Fedora 4 with latest lm_sensors from ATrpms.
>>>
>>> Linux version 2.6.16-1.2096_FC4 (bhcompile at hs20-bc1-4.build.redhat.com)
>> I just booted my P4S333 with this kernel under FC4... same result.  Oddly
>> enough, it works just fine with a vanilla 2.6.16.
>>
>> Paulo: if you run 'lspci' I think you will find device "00:02.1" to be
>> missing.  This is the problem.  Somehow, the vendor kernel does not do
>> the PCI quirk properly to "unhide" that device.  I will look into it
>> further tomorrow... but at least, the workaround is to use a vanilla
>> kernel.
> 
> Here's the problem:  two PCI quirks (drivers/pci/quirks.c) are required for
> the SMBus device on this board.  The first is quirk_sis_503(), which twiddles
> some bits so that the south bridge has the proper name: 
> 
> 	00:02.0 Class 0601: 1039:0961
> 
> The second quirk is quirk_sis_96x_smbus(), which will only run if the above
> device is found.
> 
> But in the FC4 kernel, the second quirk is processed first... so 1039:0961
> is not yet available.  If you look at System.map, for some reason the 
> SMBus quirks come first in the link order... even though those are declared
> after the 503 quirk in the same file.  
> 
> [mark at mars boot]$ cat System.map-2.6.16-1.2096_FC4 | grep __pci_fixup_ | grep PCI_VENDOR_ID_SI | sort
> c03589ac r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_LPCquirk_sis_96x_smbus
> c03589b4 r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_963quirk_sis_96x_smbus
> c03589bc r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_962quirk_sis_96x_smbus
> c03589c4 r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_961quirk_sis_96x_smbus
> c03589cc r __pci_fixup_PCI_VENDOR_ID_SIPCI_DEVICE_ID_SI_503quirk_sis_503
> 
> So, two possibilities: 
> 
> 1) We can't depend on the link order, so the quirks need to be fixed.
> 
> 2) We *can* depend on link order, but FC4 breaks it somehow.
> 
> I'm going to file a bug in FC bugzilla, and copy this message into it.
> We'll see what they think.
> 
> Regards,
> 

Thanks, Mark.

That is an interesting problem, anyway.
I noticed the malfunctioning some time ago
in the previous kernel, 2069,
but I was busy fixing other things.

Almost all of my computers use Intel motherboards,
and they do not suffer this problem. But
from what I understood, it can happen with other
hardware too. The amazing fact is, like you said,
that a Vanilla kernel is unaffected.

So the question is: why Fedora behaves differently?
Maybe with your bug report they fix it for the
next kernel release.

Cheers,

/Paulo Roma.

[lm-sensors] asb100 not working in kernel 2.6.16

[Jean Delvare]

Hi Mark, Paulo,

Mark M. Hoffman wrote:
> So, two possibilities: 
> 
> 1) We can't depend on the link order, so the quirks need to be fixed.
> 
> 2) We *can* depend on link order, but FC4 breaks it somehow.

Since 2.6.17-rc1, there is a new kernel option available for arch
x86_64:

config REORDER
	bool "Function reordering"
	default n
	help
         This option enables the toolchain to reorder functions for a more 
         optimal TLB usage. If you have pretty much any version of binutils, 
	 this can increase your kernel build time by roughly one minute.

This option does the following (in arch/x86_64/Makefile)
cflags-$(CONFIG_REORDER) += -ffunction-sections

I understand that you are investigating an issue on 2.6.16, arch i386,
so this doesn't apply directly, but maybe the latest FC4 kernels use a
similar compilation flag for arch i386?

-- 
Jean Delvare