Yes, windows returns zero in this case, with no error. Therefore, we have achieved windows compatibility, which is one of the main goals for ACPICA at this time. >-----Original Message----- >From: Zhang, Rui >Sent: Wednesday, October 08, 2008 11:45 PM >To: Len Brown; Moore, Robert >Cc: Matthew Garrett; Gandalf Kristensen; linux-acpi@xxxxxxxxxxxxxxx; Rafael >J. Wysocki; Lin, Ming M >Subject: Re: Buggy BIOS on the HP TX2500-series > >On Wed, 2008-10-08 at 23:36 -0700, Zhang Rui wrote: >> On Wed, 2008-10-08 at 19:04 -0700, Len Brown wrote: >> > >> > On Thu, 9 Oct 2008, Matthew Garrett wrote: >> > >> > > On Thu, Oct 09, 2008 at 08:59:15AM +0800, Zhang Rui wrote: >> > > > On Wed, 2008-10-08 at 12:26 -0700, Matthew Garrett wrote: >> > > > > A patch went into the kernel earlier this year to ignore critical >trip >> > > > > points that were below 0. >> > > > well, I think this patch is wrong. >> > > > a critical trip point below 0 Celsius doesn't mean it's invalid. >> > > >> > > I think it's pretty clear that a critical trip point below 0 celsius >> > > means that the critical trip point is invalid, >> well, I agree that this workaround can work here. >> But I think the proper way to fix this issue is that, >> ACPICA returns some error code(AE_BAD_DATA) like it did before, >> and the thermal driver knows that it got an invalid value and >> should take it carefully. >Bob, do you mean Windows return 0 in this case? > >> or else we may still get potential problems, e.g. what if there >> is no return value of _PSV method. >If it's true, then we don't need to waste our time on this. >it won't happen because windows doesn't work either in this case, unless >it workarounds this problem again like it has done for _CRT, right? > >thanks, >rui >> >> > though I agree that >> > > ignoring the entire thermal zone as a result is somewhat unfortunate. >> > > >> > > > windows can work well on this laptop. >> > > > please look at: >> > > > http://bugzilla.kernel.org/show_bug.cgi?id=10686#c13 >> > > > IMO, we need to fix the ACPICA code first of all. >> > > > >> > > > Ming, what do you think of the patch in comment #15 and #16? >> > > >> > > We could quibble over the technical correctness of this approach, but >it >> > > seems to behave in exactly the same way - ie, Linux will ignore the >> > > thermal zone? The existing code seems fine, other than the fact that >a >> > > bad _CRT will result everything failing. I think we'd be better off >just >> > > losing the return -ENODEV there and try to use as much of the thermal >> > > information as we can. >> > >> > right, when we put in the workaround we observed that a bad _CRT >> > would delete an entire thermal zone, and that could be a big >> > problem on a box with active cooling on that thermal zone. >> Hmm, I think a patch like this is enough to fix this problem. >> >> >> ignore invalid critical trip point. >> >> Signed-off-by: Zhang Rui <rui.zhang@xxxxxxxxx> >> --- >> drivers/acpi/thermal.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> Index: linux-2.6/drivers/acpi/thermal.c >> =================================================================== >> --- linux-2.6.orig/drivers/acpi/thermal.c >> +++ linux-2.6/drivers/acpi/thermal.c >> @@ -373,9 +373,8 @@ static int acpi_thermal_trips_update(str >> if (ACPI_FAILURE(status) || >> tz->trips.critical.temperature <= 2732) { >> tz->trips.critical.flags.valid = 0; >> - ACPI_EXCEPTION((AE_INFO, status, >> + ACPI_DEBUG_PRINT((ACPI_DB_WARN, >> "No or invalid critical >threshold")); >> - return -ENODEV; >> } else { >> tz->trips.critical.flags.valid = 1; >> ACPI_DEBUG_PRINT((ACPI_DB_INFO, >> >> >> -- >> 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 -- 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
