On Mon, Sep 21, 2009 at 1:04 PM, Luca Tettamanti <kronos.it@xxxxxxxxx> wrote: > Il Sun, Sep 20, 2009 at 04:51:10PM -0600, Robert Hancock ha scritto: >> On Sun, Sep 20, 2009 at 12:58 PM, Luca Tettamanti <kronos.it@xxxxxxxxx> wrote: >> >> >> I'm guessing this board uses a different format than what the driver >> >> >> is expecting. I'm attaching the gzipped decompiled DSDT from the >> >> >> board, hopefully it's useful to somebody.. >> >> > >> >> > Please try the following patch, it should detect the proper buffer size. >> >> > >> >> >> >> Obviously something not quite right: >> > >> > Ah yes, the pointer for the output buffer was pointing to the wrong >> > variable. Sorry for that ;) >> >> Cool, seems to be working. > > Excellent :) > >> Though the high and critical temperatures >> seem a bit odd, but maybe that's what the BIOS actually reports: > [...] >> CPU Temperature: +32.5°C (high = +45.0°C, crit = +45.5°C) >> MB Temperature: +31.0°C (high = +45.0°C, crit = +46.0°C) > > The limits are declared in the DSDT, the driver doesn't do any > calculation. > It's possible that Asus changed the encoding (again); so far I've been > unable to locate a "version" field that would allow the driver to detect > a change in the data structures. > > I've got a new patch for you: instead of probing and preallocating the > buffer this version lets ACPI code do the allocation; the return value > is cached anyway, so there won't be a big number of allocations. > Can you please test and see if it works? Yes, this version still works.. -- 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
