https://bugzilla.novell.com/show_bug.cgi?id=259992 ------- Comment #23 from jdelvare@novell.com 2007-05-30 02:51 MST ------- (In reply to comment #22)
Jean, IMO we have to set sensor modules to unsupported and must somehow make sure they get not loaded (for ACPI archs), but still let people a chance to load them manually. How are those modules loaded?
The hardware monitoring drivers are already all unsupported.
Can you come up with a list of modules that access smbus/i2c bus and could interfere with ACPI, pls.
Virtually all of them can. Note that the it87 driver doesn't even touch smbus/i2c in this case. So the list you want is all smbus/i2c master drivers _and_ all non-i2c-based hardware monitoring drivers, limited to devices which can be found on ACPI-enabled systems: i2c-ali1535 i2c-ali1563 i2c-ali15x3 i2c-amd756 i2c-amd756-s4882 i2c-amd8111 i2c-i801 i2c-nforce2 i2c-piix4 i2c-sis5595 i2c-sis630 i2c-sis96x i2c-viapro abituguru f71805f hdaps it87 k8temp pc87360 pc87427 sis5595 smsc47b397 smsc47m1 via686a vt1211 vt8231 w83627ehf w83627hf That's a pretty long list, isn't it? Note: of these, the smsc47m1, vt8231 and via686a are probably less risky than the others because their access is stateless. So even if ACPI is accessing these devices, the drivers shouldn't get in the way. Shouldn't...
How does the modules get loaded? I can't find any autoloading in kernel (quick look, I might have overseen something), does this work that you run some userspace hwmon-test app, that one writes /etc/sysconfig/lm_sensors with suggestions which modules to load via /etc/init.d/hwmon (re-)start?
The only hardware monitoring modules which autload are k8temp, sis5595, via686a and vt8231, because they are PCI devices. All SMBus master drivers listed above autoload too, again because they are PCI devices. For the other hardware monitoring drivers, they are loaded by /etc/rc.d/lm_sensors based on the list found in /etc/sysconfig/lm_sensors. This configuration file is generated by /usr/sbin/sensors-detect. One thing that could be done would be to add an ACPI check in sensors-detect, so that we can warn the user that a conflict could happen. However, only checking for the presence of ACPI would result in many false positives. So ideally we would need a way to determine if a given DSDT contains functions which access the I/O ports of the devices detected by sensors-detect. But I guess this would be pretty hard to automatize. Another (hopefully temporary) approach is to add DMI-based blacklists to individual SMBus and hardware monitoring drivers. If the list of motherboards with a conflict is small enough, it might work. If not, it might become quickly unmaintainable :(
Jean, I did a quick check of the DSDT, this machine is hopeless to run ACPI and it87 module.
I agree.
This functions all access the device: - SFAN, FON, FOFF, RTMP, STHY, STOS, SCFG
Are these functions called if neither the "fan" nor "thermal" drivers are loaded? My guess is that Christoph would rather use the it87 driver than the less featured ACPI drivers.
It also looks like the it87 addresses seem not to be used by default, but I would not trust this assumption.
I don't understand what you mean here. Can you please explain?
Next thing is, that the above functions are all in _SI scope, but are not assigned to a specific ACPI device. That means writting an ACPI driver for it87 could get difficult and all this looks very machine/BIOS/vendor specific... (on the other hands side I am sure I already have seen the SFAN method, looks like one need a acer-acpi module including this or it could be added to asus-acpi or whatever machine this is, what kind of machine/model is this?)
Please remember I am no ACPI expert. What is the "_SI scope"?
IMO it87 module must vanish anyway (or must not get loaded for ACPI machines) and we need something ACPI (probably also BIOS/vendor/model) specific.
ACPI was supposed to be a standard, and now I seem to understand that we would need to write a dedicated driver for every motherboard vendor, or maybe even every motherboard model out there? *sigh* The it87 driver is supporting the ITE IT87xxF/FG chips on _all_ motherboard models. But sure, just do it. The problem right now is that the ACPI people keep complaining that non-ACPI hardware monitoring drivers are causing trouble, but users keep using them because ACPI doesn't offer anything next to what lm-sensors has been providing for years. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.