2012/12/10 Christian Schulte <c...@schulte.it>:
> Am 12/10/12 05:00, schrieb Vadim Zhukov:
>> 10.12.2012 1:43 пользователь "Christian Schulte" <c...@schulte.it> написал:
>>>
>>> Am 12/09/12 20:58, schrieb Vadim Zhukov:
>>>> Hello all.
>>>>
>>>> This is a bit improved version of the patch showed up on tech@ in...
>>>> er-r-r... don't mind. This makes my ThinkPad usable under high load
>>>> for more than a year, and should not cause problems mentioned before
>>>> (spinning higher and lower constantly) by using two temperature marks
>>>> instead of one.
>>>>
>>>> I also found that disengaged mode should be enabled separately off
>>>> other modes, so now Alexander Polyakov's X100e should behave correctly.
>>>>
>>>> Any ThinkPad users willing to test?
>>>
>>> Hello,
>>>
>>> I am using a previous version of the patch with some temperature
>>> constants modified to match the temperatures my R60 produces. My R60
>>> overheats (screen starts to flicker - system freezes) even when running
>>> the fan in disengaged mode constantly. I bet the patch will only
>>> increase the time it takes for the system to overheat. Ever run at 100%
>>> load for a few hours with a disengaged fan without problems ?
>>
>> Well, I didn't need disengaged mode on X60 Tablet, it overhearted rarely,
>> especially if you clean up fan at least once a year. And X201i with i5 runs
>> fine with this patch, if you doesn't place it on the wool. Could you please
>> show "dmesg" and "sysctl hw.sensors" output from your system with any
>> version of the patch being applied?
>>
>
> I did not manage to solve the thermal problems I am having with the R60
> in any way. Without your patch, I cannot use the machine for more than
> 10 minutes without overheating even when nearly idle. It also happened
> when the machine was brandnew. The problem was there right from the
> start. Replaced the fan two times already due to defects.
>
> With the latest patch applied I noticed the following:
>
> hw.sensors.acpithinkpad0.fan0=2652 RPM
> hw.sensors.acpithinkpad0.raw0=128 (fan mode: disengaged), WARNING
>
> It reads (fan mode: disengaged) although the fan isn't spinning
> full-speed. It does start spinning full-speed when getting hot. So the
> fan-mode string seems to not get updated correctly when switching from
> disengaged mode back to auto or somethng like that.
Thanks, somehow I missed the obvious path in the source...
> dmesg and sysctl hw.sensors with your latest patch applied.
Thanks again.
> Script started on Mon Dec 10 05:44:39 2012
> # uptime
> 5:44AM up 5:30, 0 users, load averages: 0.12, 0.20, 0.26
> # dmesg
> OpenBSD 5.2-current (GENERIC.MP) #1: Mon Dec 10 00:05:29 CET 2012
> r...@r60.schulte.it:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz ("GenuineIntel" 686-class)
> 1.83 GHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF
>
> real mem = 3219517440 (3070MB)
> avail mem = 3155935232 (3009MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 08/28/09, BIOS32 rev. 0 @ 0xfd690,
> SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
> bios0: vendor LENOVO version "7CETD3WW (2.23 )" date 08/28/2009
> bios0: LENOVO 9461DXG
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT
> SSDT SSDT SSDT
> acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4)
> EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3)
> HDEF(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: apic clock running at 166MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz ("GenuineIntel" 686-class)
> 1.83 GHz
> cpu1:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF
>
> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 20, 24 pins
> ioapic0: misconfigured as apic 2, remapped to apid 1
> acpimcfg0 at acpi0 addr 0xf0000000, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (AGP_)
> acpiprt2 at acpi0: bus 2 (EXP0)
> acpiprt3 at acpi0: bus 3 (EXP1)
> acpiprt4 at acpi0: bus 4 (EXP2)
> acpiprt5 at acpi0: bus 12 (EXP3)
> acpiprt6 at acpi0: bus 21 (PCI1)
> acpicpu0 at acpi0: C3, C2, C1, PSS
> acpicpu1 at acpi0: C3, C2, C1, PSS
> acpipwrres0 at acpi0: PUBS
> acpitz0 at acpi0: critical temperature is 127 degC
> acpitz1 at acpi0: critical temperature is 100 degC
I'm thinking about looking for acpitz* internals critical temperature
in acpithinkpad_attach(), and using it for heuristics to detect high
and low temperature marks. But direct messing with acpitz(4)
structures is indeed ugly... Can any kernel drivers hacker give an
advice here, please?
--
WBR,
Vadim Zhukov
