Mailinglist Archive: opensuse-bugs (6458 mails)
| < Previous | Next > |
[Bug 259992] kernel acpi read wrong temperature - critical shutdown
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Tue, 29 May 2007 11:43:45 -0600 (MDT)
- Message-id: <20070529174345.1B72E25C88C@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=259992
trenn@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |ASSIGNED
Info Provider|shanti@xxxxxxx |
------- Comment #22 from trenn@xxxxxxxxxx 2007-05-29 11:43 MST -------
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?
Can you come up with a list of modules that access smbus/i2c bus and could
interfere with ACPI, pls.
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?
Jean, I did a quick check of the DSDT, this machine is hopeless to run ACPI and
it87 module.
This functions all access the device:
- SFAN, FON, FOFF, RTMP, STHY, STOS, SCFG
It also looks like the it87 addresses seem not to be used by default, but I
would not trust this assumption.
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?)
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.
--
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.
trenn@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |ASSIGNED
Info Provider|shanti@xxxxxxx |
------- Comment #22 from trenn@xxxxxxxxxx 2007-05-29 11:43 MST -------
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?
Can you come up with a list of modules that access smbus/i2c bus and could
interfere with ACPI, pls.
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?
Jean, I did a quick check of the DSDT, this machine is hopeless to run ACPI and
it87 module.
This functions all access the device:
- SFAN, FON, FOFF, RTMP, STHY, STOS, SCFG
It also looks like the it87 addresses seem not to be used by default, but I
would not trust this assumption.
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?)
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.
--
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.
| < Previous | Next > |