On Fri, May 25, 2007 at 06:38:15AM +0000, Pavel Machek wrote: > Hi! > > Because, as Len has pointed out, you end up with two different ideas > > about what the trip points are - the kernel's and the hardware's. That > > works fine until some event in the firmware either forcibly > > resynchronises the two or makes assumptions about the spec-compliance of > > the interpreter. > > ...and suggested workaround is to drive fans directly from userspace, > which not only violates the specs and has all the problems with > desynchronized state, but ALSO FAILS TO WORK IN PRACTICE. I don't think that's obviously true. 11.3.2 of the 3.0 spec states: "A package consisting of references to all active cooling devices that should be engaged when the associated active cooling threshold (_ACx) is exceeded." (referring to _ALx objects). > > The interface would need to be more complicated than that if you wanted > > to be able to implement hysteresis, and there's the potential for > > hardware damage if paramaters are set inappropriately. Even then, > > there's no easy way of programatically determining whether it would work > > on any given hardware. > > Not sure why you try to scare people with 'hardware damage'. HP XE3 > bios already _was_ damaging hardware (it cooked the hard drive using > cpu as a heater), and no acpi magic can damage correctly working > machine. Given that this presumably didn't occur under Windows, I think it would be significantly better to figure out why and then fix that. Alternatively, if the firmware tables are actually genuinely broken in a way that's impossible to repair, you can replace the table. That has the advantage that there's no risk of the platform and the OS becoming confused. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
