http://bugzilla.kernel.org/show_bug.cgi?id=6315
------- Additional Comments From [EMAIL PROTECTED] 2007-03-08 09:15 -------
> First of all, keep in mind that grep's syntax for alternatives is more
> like "ACPI \(read\|write\)".
I used egrep of course :-)
> Which drivers were loaded when you did you tests? You need to load the
> thermal, fan and i2c-i801 drivers to see something, and possibly also
> the toshiba-specific acpi driver.
All of these were loaded.
> You need to ensure that the i2c-i801 driver is working (i.e. the unhiding
> quirk worked.) You should see it in /proc/ioports:
I have:
d880-d89f : 0000:00:1f.3
d880-d89f : motherboard
d880-d89f : i801_smbus
Also, 'sensors' works and gives correct output (showing changing limits for
different FAN speeds, i.e. when a limit is reached and a new level is
entered).
> If thermal isn't polling by default (check
> /proc/acpi/thermal_zone/*/polling_frequency) you may need to read from
> /proc/acpi/thermal_zone/*/temperature to trigger a resource access.
The contents of that directory are:
* /proc/acpi/thermal_zone/THRM/cooling_mode
<setting not supported>
cooling mode: passive
* /proc/acpi/thermal_zone/THRM/polling_frequency
<polling disabled>
* /proc/acpi/thermal_zone/THRM/state
state: ok
* /proc/acpi/thermal_zone/THRM/temperature
temperature: 63 C
* /proc/acpi/thermal_zone/THRM/trip_points
critical (S5): 93 C
passive: 92 C: tc1=9 tc2=2 tsp=1800 devices=0xdeb96ea0
active[0]: 92 C: devices=0xdeb96928
active[1]: 92 C: devices=0xdeb96928
Seems like polling is not supported? However, reading temperature does
nothing.
> Or maybe you need to load your laptop's CPU up to the point the fan
> will kick in or on the contrary let it idle so the fan stops (your
> comment #22 suggests this.)
Tried that several times. Also tried suspending to RAM and resuming.
> So please leave the patch in place and use your laptop with all drivers
> loaded, maybe the resource conflict only happens on specific events.
I've double checked that your patch was applied (it was). I just can't seem to
trigger the events you're looking for. Not sure if that is good or bad :-P
Indeed for #22 it was trivial to trigger the conflict and I'm sure I've done
the same now as then. Could it be that the problem has already been solved
somehow? Would it maybe make sense to again apply the patch that showed the
debugging from #21/#22?
I have now tested with a quickly compiled 2.6.20 kernel on a partition I
normally only use as chroot. I don't really want to boot my regular working
partition with that kernel.
If you think that would be useful, I can compile a 2.6.20.1 kernel with your
patch and boot that on my regular partition. However, I'm also quite busy with
the RC2 release of the Debian Installer (which is a requirement for releasing
Etch).
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
