[help] strange fan problems, partially solved in DSDT

[help] strange fan problems, partially solved in DSDT

[Leo Antunes]

[-- Attachment #1: Type: text/plain, Size: 4101 bytes --]

Hi,

I'll try describing my problem in detail to hopefully avoid
back-and-forth questions, please excuse my prolixity.

I have a Toshiba L300 21C (output dmidecode attached) with an Insyde H2O
(latest version from Toshiba as of today), which according to their site
is an EFI implementation, but which looks and behaves like a legacy
BIOS, so I assume it's a thin CSM on top of EFI.

Linux booted OK, but had a non-working thermal zone which always replied
a temperature of 0C (though the coretemp module worked ok) and an
apparently non-working fan interface which always seemed ON and didn't
respond to
'echo 3 > /proc/acpi/fan/FAN/state' (kernel logged the usual "failed to
transition to D3" message).
The fan also didn't seem to react to the processor temperature, suddenly
springing to full-power when it reached the 80C trip point (which wasn't
even reported in trip_points) and never switching off again.

These problems manifested with 2.6.2{6,8,9-rc7}.

I suspected there could be some problems in the thermal zone definition
so I tried the DSDT (both original and new version attached).
This was my first attempt at reading the ACPI spec and coding ASL, so
please bear with me if my assumptions are completely off-mark.

Opening the DSDT it became obvious that the FAN declaration was bogus,
always returning ON and not implementing the _ON and _OFF methods.
The next step was debugging the temperature problem, since it seemed to
be an awful big chunk of code to be simply useless, and the fan problem
seemed harder to find now that I didn't know where else to look.
While I was stumbling with the _TMP method and adding debugging output
all around the code, the fan suddenly became responsive during one of
the boot cycles.
I traced it back to reading from any field inside the EC
OperationRegion, through a "Store(\_SB.PCI0.LPC.EC0.FNST, Debug)" (I
started with FNST because it looked like it might mean "fan status", but
reading from other fields also reliably triggered the same behavior).
FNST itself seems to return 0 in all situations I tried, so I still
don't know what it actually stands for.

At this point I also got the _TMP method working, albeit with an
apparent temperature skew of a few degrees in relation to the temps
reported by coretemp, but this wasn't so important as the fan problem.

Debugging blindly a bit further I noticed whenever the fan crossed the
35C/50C/60C/80C barriers (again: not the same as trip_points) the _Q11
method got called and this seemed to adjust the fan speed to whatever
speed was appropriate.
Changing just the "Store(\_SB.PCI0.LPC.EC0.FNST, Debug)" line to read
from some other value not inside the EC made this stop working.

Another interesting characteristic: it stopped working after a full
suspend-resume cycle, but continued to work when put through all the
test levels in /sys/power/pm-test, only stopping when we actually cut
the power and entered S3 proper.

To "fix" this I made the fan's _PSC method call _Q11() and read from the
EC, which seemed to keep things working through suspend-resume.

Right now everything seems to be working almost perfectly, though I have
seen the fan control stop working and only jerk back into action after a
suspend-resume cycle, without being able to reproduce the failure reliably.
I'm totally aware that this is far from a perfect solution and was - in
fact - just a fluke.

My questions are:
- am I right in assuming the EC could be playing behind ACPI's back and
controlling the fan speed by itself, only depending on ACPI to react
when issued the _Q11 event? Or did I completely misunderstand the way
the _Qxx methods are supposed to work?

- should this problem be understood as a failure in the DSDT for not
explicitly initializing something; a failure in ACPI for not implicitly
initializing something or a failure in the hardware/BIOS for depending
on partially non-ACPI behavior to control fan speed?

- what would be the "least wrong" way of solving this problem?

Cheers and thanks for the lesson (if anyone had the patience to read
this whole thing... :) )

-- 
*Leo Antunes*






[-- Attachment #2: dsdt.working.dsl.gz --]
[-- Type: application/x-gzip, Size: 26631 bytes --]

[-- Attachment #3: dsdt.orig.dsl.gz --]
[-- Type: application/x-gzip, Size: 26264 bytes --]

[-- Attachment #4: dmidecode.dump --]
[-- Type: text/plain, Size: 11483 bytes --]

# dmidecode 2.9
SMBIOS 2.4 present.
35 structures occupying 1489 bytes.
Table at 0x000E8150.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: INSYDE
	Version: 1.60
	Release Date: 12/23/2008
	ROM Size: 1024 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
		Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
		5.25"/360 KB floppy services are supported (int 13h)
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 KB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		8042 keyboard services are supported (int 9h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		Targeted content distribution is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: TOSHIBA
	Product Name: Satellite L300
	Version: PSLB8E-0H301VGR
	Serial Number: 19027396Q
	UUID: 0A80D6A0-D6C5-11DD-A70E-001E338F4BA5
	Wake-up Type: Power Switch
	SKU Number: Montevina_Fab
	Family: Intel_Mobile

Handle 0x0002, DMI type 2, 16 bytes
Base Board Information
	Manufacturer: TOSHIBA
	Product Name: Portable PC
	Version: Base Board Version
	Serial Number: Base Board Serial Number
	Asset Tag: Base Board Asset Tag
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Base Board Chassis Location
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: Chassis Manufacturer
	Type: Notebook
	Lock: Not Present
	Version: Chassis Version
	Serial Number: Chassis Serial Number
	Asset Tag: No Asset Tag
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0

Handle 0x0004, DMI type 5, 20 bytes
Memory Controller Information
	Error Detecting Method: None
	Error Correcting Capabilities:
		None
	Supported Interleave: One-way Interleave
	Current Interleave: One-way Interleave
	Maximum Memory Module Size: 4096 MB
	Maximum Total Memory Size: 8192 MB
	Supported Speeds:
		Other
	Supported Memory Types:
		Other
	Memory Module Voltage: Unknown
	Associated Memory Slots: 2
		0x0000
		0x0000
	Enabled Error Correcting Capabilities:
		None

Handle 0x0005, DMI type 9, 13 bytes
System Slot Information
	Designation: J6B2
	Type: x16 PCI Express
	Current Usage: Available
	Length: Other
	ID: 0
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x0006, DMI type 9, 13 bytes
System Slot Information
	Designation: J6B1
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 0
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x0007, DMI type 9, 13 bytes
System Slot Information
	Designation: J6C2
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 1
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x0008, DMI type 9, 13 bytes
System Slot Information
	Designation: J7B1
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 2
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x0009, DMI type 9, 13 bytes
System Slot Information
	Designation: J8B3
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 3
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x000A, DMI type 9, 13 bytes
System Slot Information
	Designation: J8D1
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 4
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x000B, DMI type 11, 5 bytes
OEM Strings
	String 1: SSLB8E0H301VGR
	String 2:              
	String 3:              
	String 4:              
	String 5: SSLB8E0H301VGR

Handle 0x000C, DMI type 12, 5 bytes
System Configuration Options
	Option 1: NVR:00707002
	Option 2: DSN:K61DT8C2BKT4        
	Option 3: DSN:16HTF25664HY-800E1E81D8954 
	Option 4: DSN:4D0F3E37

Handle 0x000D, DMI type 15, 29 bytes
System Event Log
	Area Length: 32672 bytes
	Header Start Offset: 0x0000
	Data Start Offset: 0x0000
	Access Method: General-purpose non-volatile data functions
	Access Address: 0x0000
	Status: Valid, Not Full
	Change Token: 0x12345678
	Header Format: OEM-specific
	Supported Log Type Descriptors: 3
	Descriptor 1: POST memory resize
	Data Format 1: None
	Descriptor 2: POST error
	Data Format 2: POST results bitmap
	Descriptor 3: Log area reset/cleared
	Data Format 3: None

Handle 0x000E, DMI type 21, 7 bytes
Built-in Pointing Device
	Type: Touch Pad
	Interface: PS/2
	Buttons: 4

Handle 0x000F, DMI type 27, 14 bytes
Cooling Device
	Type: Fan
	Status: OK
	OEM-specific Information: 0x00000000
	Nominal Speed: 43690 rpm

Handle 0x0010, DMI type 32, 20 bytes
System Boot Information
	Status: No errors detected

Handle 0x0011, DMI type 39, 22 bytes
System Power Supply
	Location: OEM_Define0
	Name: OEM_Define1
	Manufacturer: OEM_Define2
	Serial Number: OEM_Define2
	Asset Tag: OEM_Define3
	Model Part Number: OEM_Define4
	Revision: OEM_Define5
	Max Power Capacity: 0.075 W
	Status: Present, OK
	Type: Regulator
	Input Voltage Range Switching: Auto-switch
	Plugged: No
	Hot Replaceable: No

Handle 0x0012, DMI type 129, 5 bytes
OEM-specific Type
	Header and Data:
		81 05 12 00 4F
	Strings:
		em Test 1
		Oem Test 2

Handle 0x0013, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 8 GB
	Error Information Handle: No Error
	Number Of Devices: 2

Handle 0x0014, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM0
	Bank Connections: 0 0
	Current Speed: 1 ns
	Type: None
	Installed Size: 2048 MB (Single-bank Connection)
	Enabled Size: 2048 MB (Single-bank Connection)
	Error Status: OK

Handle 0x0015, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0013
	Error Information Handle: 0x0016
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: None
	Locator: DIMM0
	Bank Locator: BANK 0
	Type: DDR2
	Type Detail: Synchronous
	Speed: 667 MHz (1.5 ns)
	Manufacturer: Micron
	Serial Number: E81D8978
	Asset Tag: Unknown
	Part Number: 787878787878787878787878787878787878

Handle 0x0016, DMI type 18, 23 bytes
32-bit Memory Error Information
	Type: OK
	Granularity: Unknown
	Operation: Unknown
	Vendor Syndrome: Unknown
	Memory Array Address: Unknown
	Device Address: Unknown
	Resolution: Unknown

Handle 0x0017, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0015
	Memory Array Mapped Address Handle: 0x001D
	Partition Row Position: Unknown
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0018, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM2
	Bank Connections: 0 0
	Current Speed: 1 ns
	Type: None
	Installed Size: 2048 MB (Single-bank Connection)
	Enabled Size: 2048 MB (Single-bank Connection)
	Error Status: OK

Handle 0x0019, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0013
	Error Information Handle: 0x001A
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: None
	Locator: DIMM2
	Bank Locator: BANK 2
	Type: DDR2
	Type Detail: Synchronous
	Speed: 667 MHz (1.5 ns)
	Manufacturer: Micron
	Serial Number: E7236BD9
	Asset Tag: Unknown
	Part Number: D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9D9

Handle 0x001A, DMI type 18, 23 bytes
32-bit Memory Error Information
	Type: OK
	Granularity: Unknown
	Operation: Unknown
	Vendor Syndrome: Unknown
	Memory Array Address: Unknown
	Device Address: Unknown
	Resolution: Unknown

Handle 0x001B, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0019
	Memory Array Mapped Address Handle: 0x001D
	Partition Row Position: Unknown
	Interleave Position: 2
	Interleaved Data Depth: 1

Handle 0x001C, DMI type 18, 23 bytes
32-bit Memory Error Information
	Type: OK
	Granularity: Unknown
	Operation: Unknown
	Vendor Syndrome: Unknown
	Memory Array Address: Unknown
	Device Address: Unknown
	Resolution: Unknown

Handle 0x001D, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Array Handle: 0x0013
	Partition Width: 0

Handle 0x001E, DMI type 4, 35 bytes
Processor Information
	Socket Designation: CPU
	Type: Central Processor
	Family: Pentium M
	Manufacturer: Intel(R) Corporation
	ID: FD 06 00 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 15, Stepping 13
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (Fast floating-point save and restore)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Hyper-threading technology)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz
	Voltage: 1.6 V
	External Clock: 667 MHz
	Max Speed: 2166 MHz
	Current Speed: 1000 MHz
	Status: Populated, Enabled
	Upgrade: <OUT OF SPEC>
	L1 Cache Handle: 0x0021
	L2 Cache Handle: 0x001F
	L3 Cache Handle: Not Provided
	Serial Number: Not Specified
	Asset Tag: FFFF
	Part Number: Not Specified

Handle 0x001F, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 1024 KB
	Maximum Size: 1024 KB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 4-way Set-associative

Handle 0x0020, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 KB
	Maximum Size: 32 KB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Instruction
	Associativity: 8-way Set-associative

Handle 0x0021, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 KB
	Maximum Size: 32 KB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Data
	Associativity: 8-way Set-associative

Handle 0x0022, DMI type 127, 4 bytes
End Of Table

Re: [help] strange fan problems, partially solved in DSDT

[Zhang Rui]

On Fri, 2009-03-06 at 19:59 +0800, Leo Antunes wrote:
> 
> Linux booted OK, but had a non-working thermal zone which always replied
> a temperature of 0C (though the coretemp module worked ok) and an
> apparently non-working fan interface which always seemed ON and didn't
> respond to
> 'echo 3 > /proc/acpi/fan/FAN/state' (kernel logged the usual "failed to
> transition to D3" message).
> The fan also didn't seem to react to the processor temperature, suddenly
> springing to full-power when it reached the 80C trip point (which wasn't
> even reported in trip_points) and never switching off again.
> 
> These problems manifested with 2.6.2{6,8,9-rc7}.
so the problem exists in all the kernels you have tried, right?

> 
> I suspected there could be some problems in the thermal zone definition
> so I tried the DSDT (both original and new version attached).
> This was my first attempt at reading the ACPI spec and coding ASL, so
> please bear with me if my assumptions are completely off-mark.
> 
> Opening the DSDT it became obvious that the FAN declaration was bogus,
> always returning ON and not implementing the _ON and _OFF methods.
You are right that bogus ACPI fan implemented on this laptop.
This means that the FAN are not controlled via ACPI, but via BIOS or
something else, like EC in this case.

> The next step was debugging the temperature problem, since it seemed to
> be an awful big chunk of code to be simply useless, and the fan problem
> seemed harder to find now that I didn't know where else to look.
> While I was stumbling with the _TMP method and adding debugging output
> all around the code, the fan suddenly became responsive during one of
> the boot cycles.
> I traced it back to reading from any field inside the EC
> OperationRegion, through a "Store(\_SB.PCI0.LPC.EC0.FNST, Debug)" (I
> started with FNST because it looked like it might mean "fan status", but
> reading from other fields also reliably triggered the same behavior).
> FNST itself seems to return 0 in all situations I tried, so I still
> don't know what it actually stands for.
> 
> At this point I also got the _TMP method working, albeit with an
> apparent temperature skew of a few degrees in relation to the temps
> reported by coretemp, but this wasn't so important as the fan problem.
> 
> Debugging blindly a bit further I noticed whenever the fan crossed the
> 35C/50C/60C/80C barriers (again: not the same as trip_points) the _Q11
> method got called and this seemed to adjust the fan speed to whatever
> speed was appropriate.
> Changing just the "Store(\_SB.PCI0.LPC.EC0.FNST, Debug)" line to read
> from some other value not inside the EC made this stop working.
> 
Interesting.
Alexey may have some comments on this.

> Another interesting characteristic: it stopped working after a full
> suspend-resume cycle, but continued to work when put through all the
> test levels in /sys/power/pm-test, only stopping when we actually cut
> the power and entered S3 proper.
> 
> To "fix" this I made the fan's _PSC method call _Q11() and read from the
> EC, which seemed to keep things working through suspend-resume.
> 
> Right now everything seems to be working almost perfectly, though I have
> seen the fan control stop working and only jerk back into action after a
> suspend-resume cycle, without being able to reproduce the failure reliably.
> I'm totally aware that this is far from a perfect solution and was - in
> fact - just a fluke.
> 
> My questions are:
> - am I right in assuming the EC could be playing behind ACPI's back and
> controlling the fan speed by itself, only depending on ACPI to react
> when issued the _Q11 event?
I think so, EC needs a notification (ACPI interrupt) to change the fan
speed when temperature changes.

>  Or did I completely misunderstand the way
> the _Qxx methods are supposed to work?
> 
> - should this problem be understood as a failure in the DSDT for not
> explicitly initializing something; a failure in ACPI for not implicitly
> initializing something or a failure in the hardware/BIOS for depending
> on partially non-ACPI behavior to control fan speed?
Not sure it's a hardware/software problem.
I don't know what difference "Store(\_SB.PCI0.LPC.EC0.FNST, Debug)"
brings us.
Alexey, can you have a look at this problem please?

thanks,
rui

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [help] strange fan problems, partially solved in DSDT

[Leo Antunes]

hi,

On Mon, Mar 9, 2009 at 4:18 AM, Zhang Rui <rui.zhang@intel.com> wrote:
>
> > The fan also didn't seem to react to the processor temperature, suddenly
> > springing to full-power when it reached the 80C trip point (which wasn't
> > even reported in trip_points) and never switching off again.
> >
> > These problems manifested with 2.6.2{6,8,9-rc7}.
> so the problem exists in all the kernels you have tried, right?

Yes, exactly, but I have only tried the described "solution" with
2.6.29-rc{5,6,7}.

> > My questions are:
> > - am I right in assuming the EC could be playing behind ACPI's back and
> > controlling the fan speed by itself, only depending on ACPI to react
> > when issued the _Q11 event?
> I think so, EC needs a notification (ACPI interrupt) to change the fan
> speed when temperature changes.

Pardon my ignorance, but what's actually generating these interrupts?
If ACPI's not even aware of the right trip points, I'd assume it's
something not directly connected to it asking the ACPI code to fiddle
with bits in the EC, but then why doesn't the BIOS implement it
completely out of sight? And more importantly, without depending on
the OS implementation for it.
Is there a point I'm not seeing in this, or are the BIOS-maker's
decisions also unclear to you?

> > - should this problem be understood as a failure in the DSDT for not
> > explicitly initializing something; a failure in ACPI for not implicitly
> > initializing something or a failure in the hardware/BIOS for depending
> > on partially non-ACPI behavior to control fan speed?
> Not sure it's a hardware/software problem.
> I don't know what difference "Store(\_SB.PCI0.LPC.EC0.FNST, Debug)"
> brings us.
> Alexey, can you have a look at this problem please?

Thanks for the help!

Cheers

--
Leo Antunes
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html