Re: acpi_tz0: _TMP value is absurd Message
B J wrote: I have a Compaq Presario SR2180NX, which uses a P5LP-LE motherboard. When I bought the machine second hand three years ago, I originally installed and ran FreeBSD 5.5 without the error message. I recall that it began appearing after I installed and ran 6.3, though I don't think it did under 6.2. I still receive the message now that I'm running FreeBSD 8.0. I've looked at some of the ACPI code file and didn't notice anything obvious which might be responsible for the error message. A quick solution I've used is running a file with: hw.acpi.thermal.user_override: 0 - 1 hw.acpi.thermal.polling_rate: 10 - 1800 hw.acpi.thermal.user_override: 1 - 0 shortly after logging in as root. The message still appears but not as often, though it doesn't fix the whatever causes the error. I've installed FreeBSD on two different models of IBM ThinkPad without the error, leading me to believe that the ACPI code might not be completely compatible with the P5LP-LE motherboard. My question is what to do next. Is there a permanent solution to this or do I have to keep using the quick fix? Any advice would be appreciated. Thank you. BMJ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org Hi BJ I made a similar problem go away on my Compaq nc6320 by installing a custom ASL, see http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html and http://lists.freebsd.org/pipermail/freebsd-acpi/2009-March/005562.html My issue was with _CRT not _TMP. The whole thread is long but it's got some useful background. Basically you create an ASL (see handbook), figure out exactly where _TMP is set, figure out what alternative values set it to a non-absurd value. Testing the alternative values is trial and error and involves installing a modified AML (see handbook) and rebooting. best of luck and when you get a working modified AML keep it somewhere for when you reinstall... Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: acpi_tz0: _TMP value is absurd Message
snip I've looked at some of the ACPI code file and didn't notice anything obvious which might be responsible for the error message. A quick solution I've used is running a file with: hw.acpi.thermal.user_override: 0 - 1 hw.acpi.thermal.polling_rate: 10 - 1800 hw.acpi.thermal.user_override: 1 - 0 shortly after logging in as root. The message still appears but not as often, though it doesn't fix the whatever causes the error. snip I made a similar problem go away on my Compaq nc6320 by installing a custom ASL, see http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html and http://lists.freebsd.org/pipermail/freebsd-acpi/2009-March/005562.html My issue was with _CRT not _TMP. The whole thread is long but it's got some useful background. Basically you create an ASL (see handbook), figure out exactly where _TMP is set, figure out what alternative values set it to a non-absurd value. Testing the alternative values is trial and error and involves installing a modified AML (see handbook) and rebooting. I created an ASL file and located what appeared to be the code block where that value was set. I followed the statements and nothing appeared to be unusual. (Of course, I might have missed something because I don't have much experience with ACPI programming.) One thing I did notice, however, is when I compiled that file and got two errors arising from: Store (Local0, Local0) where Local0 hadn't been defined in that part of the code. I have no idea how that came about, but it successfully compiled after I commented out that statement. (A bug in the original code, perhaps?) best of luck and when you get a working modified AML keep it somewhere for when you reinstall... Agreed. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: acpi_tz0: _TMP value is absurd Message
B J wrote: snip I created an ASL file and located what appeared to be the code block where that value was set. I followed the statements and nothing appeared to be unusual. (Of course, I might have missed something because I don't have much experience with ACPI programming.) I was able to set the temperature of hw.acpi.thermal.tz0._CRT by changing hex values in my ASL, but _CRT is hard coded whereas _TMP is set dynamically (in my ASL). There is also a problem that the value of _CRT is output by sysctl so I could watch the results of my changes, whereas _TMP is not. Which is not much help to you sorry. One thing I did notice, however, is when I compiled that file and got two errors arising from: Store (Local0, Local0) where Local0 hadn't been defined in that part of the code. I have no idea how that came about, but it successfully compiled after I commented out that statement. (A bug in the original code, perhaps?) What happens if you recompile an unmodified ASL? I believe there is an issue that there are 2 compilers, one by microsoft, one by intel and the intel one sticks to the acpi standard whereas the MS one allows bugs. If a manufacturer only tests their acpi tables with the MS one they can have bugs. You could always write to HP and tell them it is broken and ask them to fix it haha. Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: acpi_tz0: _TMP value is absurd Message
snip I was able to set the temperature of hw.acpi.thermal.tz0._CRT by changing hex values in my ASL, but _CRT is hard coded whereas _TMP is set dynamically (in my ASL). There is also a problem that the value of _CRT is output by sysctl so I could watch the results of my changes, whereas _TMP is not. Which is not much help to you sorry. I noticed that _TMP can't be modified through sysctl. One thing I did notice, however, is when I compiled that file and got two errors arising from: Store (Local0, Local0) where Local0 hadn't been defined in that part of the code. I have no idea how that came about, but it successfully compiled after I commented out that statement. (A bug in the original code, perhaps?) What happens if you recompile an unmodified ASL? I got those 2 errors plus a warning. I believe there is an issue that there are 2 compilers, one by microsoft, one by intel and the intel one sticks to the acpi standard whereas the MS one allows bugs. If a manufacturer only tests their acpi tables with the MS one they can have bugs. You could always write to HP and tell them it is broken and ask them to fix it haha. I bought the machine second-hand from a dealer that was going out of business. It came with Vista installed so, presumably, the motherboard might have been set accordingly. Updating the BIOS might help, but I removed Vista when I started tinkering with FreeBSD, which might make that operation a touch difficult. The main reason I'm concerned about this bug is that I'm planning on building my own machine and possibly running FreeBSD on it for my research. I'd hate to put something together, install FreeBSD, and have nothing but bugs like this to contend with. BTW, I read through the entire thread. I added the sysctl statements I mentioned in my original message and now the error message appears only every half hour. It's not a proper fix but it reduces the aggravation of having it displayed as often as it was before. Thanks. BMJ snip P.S. The version of ACPI is the same one that came originally with the image file that I downloaded off the FreeBSD site. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: acpi_tz0: _TMP value is absurd Message
B J wrote: snip One thing I did notice, however, is when I compiled that file and got two errors arising from: Store (Local0, Local0) where Local0 hadn't been defined in that part of the code. I have no idea how that came about, but it successfully compiled after I commented out that statement. (A bug in the original code, perhaps?) What happens if you recompile an unmodified ASL? I got those 2 errors plus a warning. By errors do you mean that you can't recompile unless you comment out the statement? Ie are the errors fatal? I bought the machine second-hand from a dealer that was going out of business. It came with Vista installed so, presumably, the motherboard might have been set accordingly. Updating the BIOS might help, but I removed Vista when I started tinkering with FreeBSD, which might make that operation a touch difficult. Updating the BIOS might help, didn't for me though. If you want to try it, google for a MS-DOS boot disk image to download, either for floppy disk or CDROM depending on what hardware you have. The main reason I'm concerned about this bug is that I'm planning on building my own machine and possibly running FreeBSD on it for my research. I'd hate to put something together, install FreeBSD, and have nothing but bugs like this to contend with. This is a bug introduced by the crappy manufacturer not FreeBSD. The acpidump/iasl combo is FreeBSD's way of working round it. You might want to try on the acpi mailing list if you want to investigate further. I think the acpi section in the handbook says they like to know about such problems. I don't think it is a common problem. If you are buying a new motherboard you should be able to find something without this problem. Check the hardware notes http://www.freebsd.org/releases/8.0R/hardware.html Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: acpi_tz0: _TMP value is absurd Message
snip One thing I did notice, however, is when I compiled that file and got two errors arising from: Store (Local0, Local0) where Local0 hadn't been defined in that part of the code. I have no idea how that came about, but it successfully compiled after I commented out that statement. (A bug in the original code, perhaps?) What happens if you recompile an unmodified ASL? I got those 2 errors plus a warning. By errors do you mean that you can't recompile unless you comment out the statement? Ie are the errors fatal? All attempts to compile the code unless I did that failed. Other occurrences of Local0 result from operations such as Boolean logical tests. At the points where those statements are, something which defines that variable doesn't exist. Something obviously slipped through the compilation. I've seen that once in a while with other compilers that I've used. I bought the machine second-hand from a dealer that was going out of business. It came with Vista installed so, presumably, the motherboard might have been set accordingly. Updating the BIOS might help, but I removed Vista when I started tinkering with FreeBSD, which might make that operation a touch difficult. Updating the BIOS might help, didn't for me though. If you want to try it, google for a MS-DOS boot disk image to download, either for floppy disk or CDROM depending on what hardware you have. OK. I'll look for something like that. The main reason I'm concerned about this bug is that I'm planning on building my own machine and possibly running FreeBSD on it for my research. I'd hate to put something together, install FreeBSD, and have nothing but bugs like this to contend with. This is a bug introduced by the crappy manufacturer not FreeBSD. I first noticed the bug after I went from, as I remember, 6.2 to 6.3. I think the board was made by a major manufacturer. On the other hand, a problem like this is something I'll have to watch for when I finally get around to building my computer. The acpidump/iasl combo is FreeBSD's way of working round it. You might want to try on the acpi mailing list if you want to investigate further. Thanks. I'll sign up for it if I'm not already. I think the acpi section in the handbook says they like to know about such problems. I don't think it is a common problem. If you are buying a new motherboard you should be able to find something without this problem. Check the hardware notes http://www.freebsd.org/releases/8.0R/hardware.html Thanks for the tip. BMJ snip ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
