Re: ACPI
Quinn Ellis wrote: Hello list. I am running FreeBSD 5.3 AMD64. It however, won't boot when I leave ACPI installed. Is this a bios issue? (Epox 8kda3+ AMD64). Thanks Quinn ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" I would say yes, but who could really say? You haven't given alot of detail. That said I have an epox(socket A nforce2) and it seems they use the microsoft acpi stuff, which sucks. I have sent some problems reports to them, even one with a phatched asl I did myself. I got no real response, they said we support windows, not linux. Hold on, LINUX! I told I run FreeBSD! O well, I would recommend staying away from epox if you wnat to run a non-ms os. Have you tried the acpidump yet? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi shutdown
Florian Hengstberger wrote: Hi! I have a standard pc-style computer, how do I enable acpi?s automatic shutdown (adding something to /boot/loader.conf ?) so that I don?t have to press the power button in then end? Thanx Florian How are you shutting down the computer? What does "shutdown -p now" do when called from the console, as root? KDK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI Eror
Michael Alestock <[EMAIL PROTECTED]> writes: > I just installed FreeBSD-5.4-Release on my Toshiba Satellite A105 laptop > and keep getting this rather annoying error every so often > > ACPI-0370: *** Error: No installed handler for fixed event [0004] > > I Googled around and seems as though the best remedy is to just upgrade > to FreeBSD-6.0. > > Is there any way around this (error) or should I just go ahead and > upgrade to 6.0 ?? > > Thanks for the help. You could write a new event handler yourself, but if you want improved ACPI support, it seems silly to do anything *but* upgrade to 6.1. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi question
Hello Dan, there is a separate list on ACPI: [EMAIL PROTECTED] May you wish to subscribe to it. Regards, Oliver Fischer Dan Cojocar wrote: Hello, I noticed that my hw.acpi.thermal.tz0.active is set -1 and i can't change this value, what is this meaning? Thanks, Dan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI temperature
2009/11/29 Steven Friedrich : > I booted my HP Pavilion zd8215us and I immediately invoked chkCPUTemperature. > The first temp reported was 52C, which is 125.6F. This leads me to believe > that acpi has an anomaly regarding temperature measurement. The ambient temp > was 71F (21.6C). The machine had been off for over eight hours. > I'm not sure. My laptop shows about 59C as soon as I can log in, in a room kept around 16C ambient. It rather quickly drops to <40C if I let it idle with powerd doing its thing. -- -- ___ 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 temperature
On Sunday 29 November 2009 11:03:28 am you wrote: > 2009/11/29 Steven Friedrich : > > I booted my HP Pavilion zd8215us and I immediately invoked > > chkCPUTemperature. The first temp reported was 52C, which is 125.6F. This > > leads me to believe that acpi has an anomaly regarding temperature > > measurement. The ambient temp was 71F (21.6C). The machine had been off > > for over eight hours. > > I'm not sure. My laptop shows about 59C as soon as I can > log in, in a room kept around 16C ambient. It rather quickly > drops to <40C if I let it idle with powerd doing its thing. > Thanks for the response. One question though, what OS are you running. The reason I ask is because I want to discover if it's FreeBSD specific or possibly affecting Linux distros as well. And if you're running FreeBSD, which version. ___ 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 temperature
2009/11/29 Steven Friedrich : > On Sunday 29 November 2009 11:03:28 am you wrote: >> 2009/11/29 Steven Friedrich : >> > I booted my HP Pavilion zd8215us and I immediately invoked >> > chkCPUTemperature. The first temp reported was 52C, which is 125.6F. This >> > leads me to believe that acpi has an anomaly regarding temperature >> > measurement. The ambient temp was 71F (21.6C). The machine had been off >> > for over eight hours. >> >> I'm not sure. My laptop shows about 59C as soon as I can >> log in, in a room kept around 16C ambient. It rather quickly >> drops to <40C if I let it idle with powerd doing its thing. >> > Thanks for the response. One question though, what OS are you running. > > The reason I ask is because I want to discover if it's FreeBSD specific or > possibly affecting Linux distros as well. And if you're running FreeBSD, which > version. > I think CPU use/temp during boot-up _could_ vary a lot from one operating system to another, I don't know that it must, though, since the whole business is arcane and full of magic (much like poutine). FreeBSD 8.0-RELEASE #1: Mon Nov 23 13:47:06 EST 2009 amd64 It's a turion x2 of 1990MHz I only had windows on long enough to burn one CD back in February, so I have not the least clue how it behaved (besides terribly). I can't find any way to get the actual temperature values under Opensolaris, but I do dual boot. It spends so much time starting so many mind-bogglingly worthless services prior to giving me a log-in prompt that I'm not sure the comparison is fair. The fan usually kick into high prior to the log-in prompt, though. Opensolaris is pretty horrible in terms of performance and battery life compared to FreeBSD. It's also like a strange, alien wasteland what with bash & gnome & other linuxisms, except pfexec. pfexec rocks. -- -- ___ 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 temperature
On Monday 30 November 2009 04:59:51 pm you wrote: > 2009/11/29 Steven Friedrich : > > On Sunday 29 November 2009 11:03:28 am you wrote: > >> 2009/11/29 Steven Friedrich : > >> > I booted my HP Pavilion zd8215us and I immediately invoked > >> > chkCPUTemperature. The first temp reported was 52C, which is 125.6F. > >> > This leads me to believe that acpi has an anomaly regarding > >> > temperature measurement. The ambient temp was 71F (21.6C). The machine > >> > had been off for over eight hours. > >> > >> I'm not sure. My laptop shows about 59C as soon as I can > >> log in, in a room kept around 16C ambient. It rather quickly > >> drops to <40C if I let it idle with powerd doing its thing. > > > > Thanks for the response. One question though, what OS are you running. > > > > The reason I ask is because I want to discover if it's FreeBSD specific > > or possibly affecting Linux distros as well. And if you're running > > FreeBSD, which version. > > I think CPU use/temp during boot-up _could_ vary a lot from > one operating system to another, I don't know that it must, > though, since the whole business is arcane and full of magic > (much like poutine). > > FreeBSD 8.0-RELEASE #1: Mon Nov 23 13:47:06 EST 2009 > amd64 > > It's a turion x2 of 1990MHz > > I only had windows on long enough to burn one CD back in > February, so I have not the least clue how it behaved (besides > terribly). > > I can't find any way to get the actual temperature values under > Opensolaris, but I do dual boot. It spends so much time starting > so many mind-bogglingly worthless services prior to giving me > a log-in prompt that I'm not sure the comparison is fair. The fan > usually kick into high prior to the log-in prompt, though. > > Opensolaris is pretty horrible in terms of performance and battery > life compared to FreeBSD. It's also like a strange, alien wasteland > what with bash & gnome & other linuxisms, except pfexec. > pfexec rocks. > I wasn't thinking that the actual temperature varied from one OS to another, I was thinking that Linux might have a different version of ACPI or that FreeBSD might have a bug that Linux doesn't. ___ 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 / APM Question
Here is output :- rackserver# sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.reset_video: 1 hw.acpi.cpu.cx_supported: C1/0 C2/90 C3/900 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% 0.00% 0.00% hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.tz0.temperature: 32.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 50.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 60.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > I am running 6.0 on a little rackserver. > Alot of the time its inactive and I was > wondering about trying to setup ACPI > the main reason being to spin down the > disc / PSU so its a bit quieter (its in my > office) I would require it to wake on > LAN activity. How feasable is this > and what steps do I need to take > to set it up ? > > I am reading acpiconf man right now > but I suspect more is required. > > I have set the BIOS to WOL, spin > down disc after 15 mins and ACPI > suspend type to S1. > > Just tested acpiconf -s 4 and it > shuts the system down completely? > > Any help appreciated - Thanks! > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI Blacklist question
- Original Message - From: "Markie" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 11, 2004 7:24 PM Subject: ACPI Blacklist question | Hello, | | I'm not sure whether I should have posted this to questions or current (since | it's an issue with a recent current) or some other list, but hear me out and | perhaps point me in the right direction? | | I recently upgraded a play about box from an older current to one .. a day | before the preemption issues arose. All is well, except I found the box would no | longer shutdown automatically using shutdown -p and hitting the power button | would just put the box into a sort of suspend or sleep state. | | Well, just now I looked at dmesg and came across this message "ACPI disabled by | blacklist. Contact your BIOS vendor.".. I believe this is most likely the | cause. I can't remember exactly what BIOS or motherboard is in there but I can | have a look if that is needed. Can anyone tell me why it's been blacklisted I meant why it MIGHT have been blacklisted, oops! | anyway? I didn't used to have any problems with it at all on the older CURRENT. | In fact I was quite impressed that I could turn it off, cleanly, by just hitting | the power button! I'll mess around and see if I can get ACPI loaded anyway | somehow and see if there's any ill effects with it. I set hint.acpi.0.disabled="0" in /boot/device.hints and it seems fine, just like with the previous current. It shutdown via the power button and switches off automatically again anyway :-) | | Well anyway, thanks in advance! | | | ___ | [EMAIL PROTECTED] mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-questions | To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI error message
In freebsd-questions Digest, Vol 341, Issue 3, Message: 2 On Tue, 14 Dec 2010 14:26:35 +0100 Davide Petilli <7h3.k3r...@gmail.com> wrote: > During the boot I can see these error mesages related to acpi. > I've built my kernel but the error messages come up on the default kernel > too. > Does anyone know what is it and how to solve this? > I tried to figure it out by myself without succes. > > These are the relevant parts of my dmesg: > - > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > unknown: I/O range not supported > ACPI Error: No handler for Region [RAM_] (0xc2cff5c0) [EmbeddedControl] > (20100331/evregion-487) > ACPI Error: Region EmbeddedControl(0x3) has no handler (20100331/exfldio-383) > ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] > (Node 0xc2cdd5c0), AE_NOT_EXIST > ACPI Error (uteval-0318): Method execution failed [\\_SB_.BAT0._STA] (Node > 0xc2cdd5c0), AE_NOT_EXIST > ACPI Error: No handler for Region [RAM_] (0xc2cff5c0) [EmbeddedControl] > (20100331/evregion-487) > ACPI Error: Region EmbeddedControl(0x3) has no handler (20100331/exfldio-383) > ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.BAT0._STA] > (Node 0xc2cdd5c0), AE_NOT_EXIST > ACPI Error (uteval-0318): Method execution failed [\\_SB_.BAT0._STA] (Node > 0xc2cdd5c0), AE_NOT_EXIST > - > > My platform: > > FreeBSD Dragon 8.1-RELEASE FreeBSD 8.1-RELEASE #3: Sun Dec 12 > 01:10:45 CET 2010 r...@dragon:/usr/obj/usr/src/sys/DRAGON i386 You should try posting this to the freebsd-acpi list instead, including the full /var/run/dmesg.boot and details of your hardware (make, model); I've not seen an 'INSYDE' ACPI BIOS before, but others may know of it. The first ACPI Error message indicates not being able to access the Embedded Controller (EC), which among other problems that may cause, is why ACPI can't get information on your battery status [\\_SB_.BAT0._STA] There have been recent commits to acpi_ec.c and other ACPI code - you could try booting 8.2-BETA1 from a CD or memstick to see if that helps? - otherwise you're likely to be asked to provide info on your machine's ASL etc. Best to be well prepared first by studying: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html cheers, Ian ___ 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 error message
On Wed, Dec 15, 2010 at 01:54:09PM +1100, Ian Smith wrote: > the full /var/run/dmesg.boot and details of your hardware (make, model); > I've not seen an 'INSYDE' ACPI BIOS before, but others may know of it. > > The first ACPI Error message indicates not being able to access the > Embedded Controller (EC), which among other problems that may cause, is > why ACPI can't get information on your battery status [\\_SB_.BAT0._STA] > > There have been recent commits to acpi_ec.c and other ACPI code - you > could try booting 8.2-BETA1 from a CD or memstick to see if that helps? > - otherwise you're likely to be asked to provide info on your machine's > ASL etc. Best to be well prepared first by studying: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html > > cheers, Ian Thank you very much! I'll study the linked resource well, next I'll post on the acpi mailing list. Regards -- Davide Petili - "k3rn31" Potenza, Italy FreeBSD, Mac OSX, GNU/Debian. Geek since birth. ___ 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 & battery issues
Sorry for the top post - I'm on my mobile. I get the same messages with the stock acpi on a Lenovo S10e. Someone on the acpi list (who's name I forget) wrote a patch which removes the error. If you think it might help I'll root it out and forward it on. Regards, Peter Harrison www.4harrisons.blogspot.com - From: "Eitan Adler" Subject:ACPI & battery issues Date: 02nd October 2010 15:43 I see ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] (20100331/evregion-588) ACPI Error (psparse-0633): Method parse/execution failed [\\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc6adba60), AE_NO_HARDWARE_RESPONSE repeatedly in dmesg sysctl's relating to battery information is also slow: % time sysctl hw.acpi.battery.state hw.acpi.battery.state: 7 sysctl hw.acpi.battery.state 0.00s user 2.18s system 72% cpu 3.006 total % time sysctl hw.acpi.battery hw.acpi.battery.life: -1 hw.acpi.battery.time: -1 hw.acpi.battery.state: 7 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 sysctl hw.acpi.battery 0.00s user 6.58s system 67% cpu 9.779 total also note that the life and time are both negative one. This is on a Lenovo G530 laptop. -- Eitan Adler ___ 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" ___ 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 & battery issues
On Sat, Oct 2, 2010 at 4:01 PM, wrote: > I get the same messages with the stock acpi on a Lenovo S10e. Someone on the > acpi list (who's name I forget) wrote a patch which removes the error. If you > think it might help I'll root it out and forward it on. I'll be happy to take a look at the patch and see if it solves my problem. does the patch just remove the error message or solve a specific problem that might be causing the issue? > ... > I see > ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for > [EmbeddedControl] (20100331/evregion-588) > ACPI Error (psparse-0633): Method parse/execution failed > [\\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc6adba60), > AE_NO_HARDWARE_RESPONSE > > repeatedly in dmesg > > sysctl's relating to battery information is also slow: > % time sysctl hw.acpi.battery.state > hw.acpi.battery.state: 7 > sysctl hw.acpi.battery.state 0.00s user 2.18s system 72% cpu 3.006 total > > % time sysctl hw.acpi.battery > hw.acpi.battery.life: -1 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 7 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > sysctl hw.acpi.battery 0.00s user 6.58s system 67% cpu 9.779 total > > also note that the life and time are both negative one. > > This is on a Lenovo G530 laptop. -- Eitan Adler ___ 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 & battery issues
2010/10/2 Eitan Adler : > On Sat, Oct 2, 2010 at 4:01 PM, wrote: >> I get the same messages with the stock acpi on a Lenovo S10e. Someone on the >> acpi list (who's name I forget) wrote a patch which removes the error. If >> you think it might help I'll root it out and forward it on. > > > I'll be happy to take a look at the patch and see if it solves my > problem. does the patch just remove the error message or solve a > specific problem that might be causing the issue? > > > > >> > ... >> I see >> ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for >> [EmbeddedControl] (20100331/evregion-588) >> ACPI Error (psparse-0633): Method parse/execution failed >> [\\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc6adba60), >> AE_NO_HARDWARE_RESPONSE >> >> repeatedly in dmesg >> >> sysctl's relating to battery information is also slow: >> % time sysctl hw.acpi.battery.state >> hw.acpi.battery.state: 7 >> sysctl hw.acpi.battery.state 0.00s user 2.18s system 72% cpu 3.006 total >> >> % time sysctl hw.acpi.battery >> hw.acpi.battery.life: -1 >> hw.acpi.battery.time: -1 >> hw.acpi.battery.state: 7 >> hw.acpi.battery.units: 1 >> hw.acpi.battery.info_expire: 5 >> sysctl hw.acpi.battery 0.00s user 6.58s system 67% cpu 9.779 total >> >> also note that the life and time are both negative one. >> >> This is on a Lenovo G530 laptop. > -- I always heard that Lenovo/IBM has a great support for open source systems, it seems not. Sad. By the way, you should try to update the bios to the last version, it may helps sometimes. Cheers, -- Demelier David ___ 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 & battery issues
In freebsd-questions Digest, Vol 330, Issue 10, Message: 5 On Sat, 2 Oct 2010 10:42:23 -0400 Eitan Adler wrote: > I see > ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for > [EmbeddedControl] (20100331/evregion-588) > ACPI Error (psparse-0633): Method parse/execution failed > [\\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc6adba60), > AE_NO_HARDWARE_RESPONSE > > repeatedly in dmesg > > sysctl's relating to battery information is also slow: > % time sysctl hw.acpi.battery.state > hw.acpi.battery.state: 7 > sysctl hw.acpi.battery.state 0.00s user 2.18s system 72% cpu 3.006 total > > % time sysctl hw.acpi.battery > hw.acpi.battery.life: -1 > hw.acpi.battery.time: -1 > hw.acpi.battery.state: 7 > hw.acpi.battery.units: 1 > hw.acpi.battery.info_expire: 5 > sysctl hw.acpi.battery 0.00s user 6.58s system 67% cpu 9.779 total > > also note that the life and time are both negative one. > > This is on a Lenovo G530 laptop. The Embedded Controller timed out so battery info is unknown / bogus, which appears quite likely the issue reported here: http://www.freebsd.org/cgi/query-pr.cgi?pr=150517 If you're sure you have the latest Lenovo BIOS/EC updates, try posting your report above to the freebsd-acpi list, also providing OS version (uname -a) and contents of /var/run/dmesg.boot Good luck, Ian ___ 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 & battery issues
I was told to bring this to acpi@'s attention On Sun, Oct 3, 2010 at 10:47 AM, Ian Smith wrote: > In freebsd-questions Digest, Vol 330, Issue 10, Message: 5 > On Sat, 2 Oct 2010 10:42:23 -0400 Eitan Adler wrote: > > > I see > > ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for > > [EmbeddedControl] (20100331/evregion-588) > > ACPI Error (psparse-0633): Method parse/execution failed > > [\\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc6adba60), > > AE_NO_HARDWARE_RESPONSE > > > > repeatedly in dmesg > > > > sysctl's relating to battery information is also slow: > > % time sysctl hw.acpi.battery.state > > hw.acpi.battery.state: 7 > > sysctl hw.acpi.battery.state 0.00s user 2.18s system 72% cpu 3.006 total > > > > % time sysctl hw.acpi.battery > > hw.acpi.battery.life: -1 > > hw.acpi.battery.time: -1 > > hw.acpi.battery.state: 7 > > hw.acpi.battery.units: 1 > > hw.acpi.battery.info_expire: 5 > > sysctl hw.acpi.battery 0.00s user 6.58s system 67% cpu 9.779 total > > > > also note that the life and time are both negative one. > > > > This is on a Lenovo G530 laptop. > > The Embedded Controller timed out so battery info is unknown / bogus, > which appears quite likely the issue reported here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=150517 It might be the same issue - but I am able to use shutdown -p to shutdown. > > If you're sure you have the latest Lenovo BIOS/EC updates, try posting > your report above to the freebsd-acpi list, also providing OS version > (uname -a) and contents of /var/run/dmesg.boot I'm unsure if I have the latest BIOS, however the vendor's only update tool requires windows - which I don't have a copy of to run it. Machine info: FreeBSD AlphaBeta.local 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 http://isis.poly.edu/~eitan/files/dmesg.boot If its relevant here is acpidump -dt http://isis.poly.edu/~eitan/files/AlphaBeta.acpidump.asl.gz -- Eitan Adler ___ 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 & battery issues
Saturday, 2 October 2010 at 17:01:41 -0400, Eitan Adler said: > On Sat, Oct 2, 2010 at 4:01 PM, wrote: > > I get the same messages with the stock acpi on a Lenovo S10e. Someone on > > the acpi list (who's name I forget) wrote a patch which removes the error. > > If you think it might help I'll root it out and forward it on. > > > I'll be happy to take a look at the patch and see if it solves my > problem. does the patch just remove the error message or solve a > specific problem that might be causing the issue? Eitan, I've attached the patch - this came from David Naylor on the ACPI list. If I understand what he told me at the time, it doesn't fix the problem entirely - but I can't pretend I understand ACPI. I know it means that on my S10e I no longer get spammed with ACPI errors - and that my battery status and shutdown work properly. The patch applies to /usr/src/sys/dev/acpica/acpi_ec.c It needs some new entries in /boot/loader.conf to adjust the timeouts and delays - which you can tinker with. The settings given are what works for me - but search the acpi list archives for David's original email: debug.acpi.ec.delay="200" debug.acpi.ec.gpe="1" debug.acpi.ec.timeout="100" Hope it helps, Peter Harrison. > > > > > > > ... > > I see > > ACPI Exception: AE_NO_HARDWARE_RESPONSE, Returned by Handler for > > [EmbeddedControl] (20100331/evregion-588) > > ACPI Error (psparse-0633): Method parse/execution failed > > [\\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc6adba60), > > AE_NO_HARDWARE_RESPONSE > > > > repeatedly in dmesg > > > > sysctl's relating to battery information is also slow: > > % time sysctl hw.acpi.battery.state > > hw.acpi.battery.state: 7 > > sysctl hw.acpi.battery.state 0.00s user 2.18s system 72% cpu 3.006 total > > > > % time sysctl hw.acpi.battery > > hw.acpi.battery.life: -1 > > hw.acpi.battery.time: -1 > > hw.acpi.battery.state: 7 > > hw.acpi.battery.units: 1 > > hw.acpi.battery.info_expire: 5 > > sysctl hw.acpi.battery 0.00s user 6.58s system 67% cpu 9.779 total > > > > also note that the life and time are both negative one. > > > > This is on a Lenovo G530 laptop. > -- > Eitan Adler ___ 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 & battery issues
> Eitan, > > I've attached the patch - this came from David Naylor on the ACPI list. If I > understand what he told me at the time, it doesn't fix the problem entirely - > but I can't pretend I understand ACPI. I know it means that on my S10e I no > longer get spammed with ACPI errors - and that my battery status and shutdown > work properly. > > The patch applies to /usr/src/sys/dev/acpica/acpi_ec.c > > It needs some new entries in /boot/loader.conf to adjust the timeouts and > delays - which you can tinker with. The settings given are what works for me > - but search the acpi list archives for David's original email: > > debug.acpi.ec.delay="200" > debug.acpi.ec.gpe="1" > debug.acpi.ec.timeout="100" > > Hope it helps, > > > > Peter Harrison. Thanks for the patch. Unfortunately the hard drive in the laptop in question broke and I'm waiting for a replacement. I will test it when I reinstall freeBSD though. Thanks for the patch. -- Eitan Adler ___ 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 won't shutdown
On Monday 04 September 2006 06:17, bsd wrote: > Hello, > > I have configured a new server and everything goes find but ACPI. > > When Shutting down the server I have these messages : > > … > All buffers synced. > Uptime: 5m2s > mpt0: Unhandled Event Notify Frame. Event 0x30 > mpt1: Unhandled Event Notify Frame. Event 0x30 > Shutting down ACPI > > > Then nothing !! > > Computer seems to freeze for an infinite amount of time. I have to > manually shutdown the computer with the Power button ! > > > Any idea ? > tell is a little about your hardware? i have a system that does this exact same behavior. mine is; supermicro 370DE6 dual pentium 3 1000 2048MB ECC-Reg'd PC133 an older samsung cdrw (this is the only ide device in the system) 3ware 6800 raid controller with 3 raid units (20GB R1, 80GB R1, 335GB R5) my system exhibits the exact sme behavior you describe, but i too have no idea why. system has always had no trouble with acpi cheers, jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI won't shutdown
On Mon, Sep 04, 2006 at 01:17:12PM +0200, bsd wrote: > Computer seems to freeze for an infinite amount of time. I have to > manually shutdown the computer with the Power button ! Did you try with 'halt -p'? If it doesn't work, can you give more infos on your system? Bye. -- * Pillon Matteo ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI won't shutdown
On Monday 04 September 2006 08:35, Matteo Pillon wrote: > On Mon, Sep 04, 2006 at 01:17:12PM +0200, bsd wrote: > > Computer seems to freeze for an infinite amount of time. I have to > > manually shutdown the computer with the Power button ! > > Did you try with 'halt -p'? > > If it doesn't work, can you give more infos on your system? > > Bye. im not the original-poster, but my system with the exact same behavior, is always shutdown with a 'shutdown -p now'. thanks, jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI won't shutdown
Ok, Sorry for the delay. My hardware is quite complicated. Briefly : This is a bi-xeon with Intel motherboard (Intel Server Board SE7520AF2). I have two ATA RAID controler : - A mirror of 2 disks for the system. - One 3ware Model 9500S-12, 12 ports --> for the data (partition in 2 --> one RAID mirror 2 disks - one RAID 5 4 disks + one sapre). Here is the output of dmesg : Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-RELEASE-p5 #0: Mon Sep 4 00:05:26 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP acpi_alloc_wakeup_handler: can't alloc wake memory Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Features=0xbfebfbff,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x641d> AMD Features=0x2000 Logical CPUs per core: 2 real memory = 3757965312 (3583 MB) avail memory = 3678593024 (3508 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard ioapic3 irqs 72-95 on motherboard ioapic4 irqs 96-119 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 1.0 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci7: on pcib1 pcib2: at device 0.0 on pci7 pci9: on pcib2 3ware device driver for 9000 series storage controllers, version: 3.60.02.012 twa0: <3ware 9000 series Storage Controller> port 0xd800-0xd8ff mem 0xfe9ffc00-0xfe9ffcff,0xfb80-0xfbff irq 24 at device 1.0 on pci9 twa0: [FAST] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9500S-12, 12 ports, Firmware FE9X 2.04.00.003, BIOS BE9X 2.03.01.047 pci7: at device 0.1 (no driver attached) pcib3: at device 0.2 on pci7 pci8: on pcib3 em0: port 0xc800-0xc83f mem 0xfe8c-0xfe8d irq 52 at device 4.0 on pci8 em0: Ethernet address: 00:07:e9:31:c0:d4 em1: port 0xcc00-0xcc3f mem 0xfe8e-0xfe8f irq 53 at device 4.1 on pci8 em1: Ethernet address: 00:07:e9:31:c0:d5 pci7: at device 0.3 (no driver attached) pcib4: irq 16 at device 4.0 on pci0 pci6: on pcib4 pcib5: irq 16 at device 6.0 on pci0 pci5: on pcib5 pcib6: irq 16 at device 7.0 on pci0 pci2: on pcib6 pcib7: at device 0.0 on pci2 pci4: on pcib7 mpt0: port 0xb400-0xb4ff mem 0xfe6d-0xfe6d,0xfe6c-0xfe6c irq 72 at device 5.0 on pci4 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.12.0 mpt0: Unhandled Event Notify Frame. Event 0xa. mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (6 Max) mpt1: port 0xb800-0xb8ff mem 0xfe6f-0xfe6f,0xfe6e-0xfe6e irq 73 at device 5.1 on pci4 mpt1: [GIANT-LOCKED] mpt1: MPI Version=1.2.12.0 mpt1: Unhandled Event Notify Frame. Event 0xa. mpt1: Capabilities: ( RAID-1E RAID-1 SAFTE ) mpt1: 0 Active Volumes (0 Max) mpt1: 0 Hidden Drive Members (0 Max) pci2: at device 0.1 (no driver attached) pcib8: at device 0.2 on pci2 pci3: on pcib8 pci2: at device 0.3 (no driver attached) uhci0: port 0xe400-0xe41f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe800-0xe81f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xec00-0xec1f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfebffc00-0xfebf irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib9: at device 30.0 on pci0 pci1: on pcib9 pci1: at device 12.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31
Re: ACPI and 4.9?
On Tue, Jan 06, 2004 at 04:49:54PM -0600, Eric F Crist wrote: > Hello List, > > I have ACPI working on a desktop running 5.1 and everything works great. If I > press the power button, the system shutsdown correctly, the monitor shuts off > after 30 minutes, etc. I have a laptop that I'm not using 5.1, but 4.9 > instead (for reasons, see previous posts re: mouse). According to the > FreeBSD handbook, I can implement ACPI in 4.9 (rather than APM) by simply > adding device acpi to the kernel configuration. I tried this and get: > > device acpi unknown Close, but no cigar. It's device acpica Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
RE: ACPI and 4.9?
It's not device acpi. It is: device acpica _ Take advantage of our limited-time introductory offer for dial-up Internet access. http://join.msn.com/?page=dept/dialup ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and 4.9?
On Wednesday 07 January 2004 10:02 am, Lord Sith wrote: > It's not > > device acpi. > > > It is: > > device acpica Do I have to remove device apm? Also, once I compile with device acpica, is there a port I have to install for acpiconf and the other configuration programs? -- Eric F Crist AdTech Integrated Systems, Inc (612) 998-3588 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and 4.9?
On Wed, Jan 07, 2004 at 11:37:01AM -0600, Eric F Crist wrote: > On Wednesday 07 January 2004 10:02 am, Lord Sith wrote: > > device acpica > Do I have to remove device apm? Also, once I compile with device acpica, is > there a port I have to install for acpiconf and the other configuration > programs? You don't *have* to remove it from your kernel, but you might as well, because it won't work with acpica in there. Note too that I've found acpica can cause some other devices not to work as well: % grep 'could not\|cannot' /var/run/dmesg.boot viapropm0: could not allocate bus space fdc0: cannot reserve I/O port range The devel/acpicatools port gets you: % pkg_info -L acpicatools\* Information for acpicatools-20030523.0: Files: /usr/local/bin/acpicadb /usr/local/bin/iasl /usr/local/bin/acpidump /usr/local/man/man8/acpidump.8.gz And that's the only acpi related port available. I guess you need 5.x for acpiconf(8). There's a bunch of acpi sysctls you could play with, but I've no idea what could be done using them. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: ACPI on 6.0-RC1
On 10/20/05, J.D. Bronson <[EMAIL PROTECTED]> wrote: > acpi0: reservation of fec01000, 1000 (3) failed > acpi0: reservation of fee0, 1000 (3) failed > > I notice that in 'dmesg' - but this machine has been running fine for > days under a good load. > > Is this anything to be concerned (or fixed) about though? There is alot of good information about acpi here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html One of the things mentioned is that you have the latest BIOS on your machine, but there is much more useful information aswell. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI disables network (why?)
On Friday 31 March 2006 19:16, Peter wrote: > I've been meaning to ask this one for awhile. > > I'm running 5.4-STABLE and I cannot use my network card *without* > booting with ACPI enabled. The net contains trouble with people > having this type of issue with Realtek cards and ACPI *enabled*. I > have a Gigabyte m/b with an onbard adapter that is assigned the sk > driver. > > So the symptom is "watchdog timeout" during DHCP discovery at the > boot stage. My networking is non-functional if I try to boot with > ACPI. > > dmesg says (during a successful boot): > > pcib2: at device 14.0 on pci0 > pci2: on pcib2 > skc0: port 0xc000-0xc0ff mem > 0xfb00-0xfb003fff irq 19 at device 11.0 on pci2 > skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) > sk0: on skc0 > sk0: Ethernet address: 00:0f:ea:ec:f1:4e > miibus0: on sk0 > e1000phy0: on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseTX-FDX, auto > > Any ideas? > > __ One thing you can check for in DMESG is irq storms, throttling offending device. If you see that, it means you've got devices that don't want to share an irq, and you'll have to shuffle the cards on the pci bus until that clears up. Don ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI disables network (why?)
--- "Donald J. O'Neill" <[EMAIL PROTECTED]> wrote: > On Friday 31 March 2006 19:16, Peter wrote: > > I've been meaning to ask this one for awhile. > > > > I'm running 5.4-STABLE and I cannot use my network card *without* > > booting with ACPI enabled. The net contains trouble with people > > having this type of issue with Realtek cards and ACPI *enabled*. I > > have a Gigabyte m/b with an onbard adapter that is assigned the sk > > driver. > > > > So the symptom is "watchdog timeout" during DHCP discovery at the > > boot stage. My networking is non-functional if I try to boot with > > ACPI. > > > > dmesg says (during a successful boot): > > > > pcib2: at device 14.0 on pci0 > > pci2: on pcib2 > > skc0: port 0xc000-0xc0ff mem > > 0xfb00-0xfb003fff irq 19 at device 11.0 on pci2 > > skc0: Marvell Yukon Lite Gigabit Ethernet rev. (0x9) > > sk0: on skc0 > > sk0: Ethernet address: 00:0f:ea:ec:f1:4e > > miibus0: on sk0 > > e1000phy0: on miibus0 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > > 1000baseTX-FDX, auto > > > > Any ideas? > > > > __ > > One thing you can check for in DMESG is irq storms, throttling > offending device. If you see that, it means you've got devices that don't want > to share an irq, and you'll have to shuffle the cards on the pci bus until that clears up. Here is what I have for "irq". It looks like irq 22 is being overused. $ dmesg | grep irq ioapic0 irqs 0-23 on motherboard ohci0: mem 0xfc003000-0xfc003fff irq 22 at device 2.0 on pci0 ohci1: mem 0xfc004000-0xfc004fff irq 21 at device 2.1 on pci0 ehci0: mem 0xfc005000-0xfc0050ff irq 20 at device 2.2 on pci0 pcm0: port 0xe000-0xe07f,0xdc00-0xdcff mem 0xfc001000-0xfc001fff irq 22 at device 6.0 on pci0 nvidia0: mem 0xe000-0xefff,0xf800-0xf8ff irq 16 at device 0.0 on pci1 skc0: port 0xc000-0xc0ff mem 0xfb00-0xfb003fff irq 19 at device 11.0 on pci2 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI disables network (why?)
On Friday 31 March 2006 21:59, Peter wrote: > Here is what I have for "irq". It looks like irq 22 is being > overused. > > $ dmesg | grep irq > ioapic0 irqs 0-23 on motherboard > ohci0: mem 0xfc003000-0xfc003fff irq > 22 at device 2.0 on pci0 > ohci1: mem 0xfc004000-0xfc004fff irq > 21 at device 2.1 on pci0 > ehci0: mem 0xfc005000-0xfc0050ff > irq 20 at device 2.2 on pci0 > pcm0: port 0xe000-0xe07f,0xdc00-0xdcff mem > 0xfc001000-0xfc001fff irq 22 at device 6.0 on pci0 > nvidia0: mem > 0xe000-0xefff,0xf800-0xf8ff irq 16 at device 0.0 on > pci1 > skc0: port 0xc000-0xc0ff mem > 0xfb00-0xfb003fff irq 19 at device 11.0 on pci2 > fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on > acpi0 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 > on acpi0 > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > ppc0: port 0x378-0x37f irq 7 on > acpi0 atkbdc0: port 0x64,0x60 irq 1 on > acpi0 atkbd0: irq 1 on atkbdc0 > > __ Not necessarily, I counted two uses. On one of my computers, irq 19 is used 4 times. There's only so many irq's available, sometimes some of them are shared. The problem is when some devices don't want to share. Do 'dmesg | grep storm', and 'dmesg | grep throt' that will tell you what irq has the problem and something is being shutdown. Then you can do 'dmesg | grep ' to find what devices are using that irq and determine what to do. With my computers I have found a bad usb mouse (dam' microsloth product, should have known better), some devices that couldn't be plugged into the usb2.0 ports I have, they had to be plugged into usb1.1 ports only, a modem that I thought was shot but would work like a champ by repositioning it on the pci bus, and some NICs that would work best by repositioning. I also found out, what FreeBSD likes, Windows XP doesn't necessarily like. After I got everything straightened around for FreeBSD-STABLE, Windows XP took a 1/2 hour to come up, booting up with the XP install disc took about the same. It still did it after a fresh install of XP. so, I told my wife: "Windows is shot, Microsoft wans me to call them to get a new number which won't help. You don't do anything on Windows that you can't do as well as or better on FreeBSD. I can't tell exactly what's wrong, Microsoft doesn't want me to know, FreeBSD thinks I want to know. I'm pulling the plug on windows and their money grubbing ways. By the way, I do give FreeBSD lessons, but pay attention or you'll have to learn on your own." Yeah, one less Windows XP installation to worry about. Of course, I didn't figure out a reason (for myself) for what was happening with Windows XP till later. You're probably going to have to put your NIC in a different slot. Don ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI disables network (why?)
--- "Donald J. O'Neill" <[EMAIL PROTECTED]> wrote: [...] Thanks for your insights. > There's only so many irq's available, sometimes some of > them are shared. The problem is when some devices don't want to > share. > > Do 'dmesg | grep storm', and 'dmesg | grep throt' that will tell you > what irq has the problem and something is being shutdown. No matches there. > You're probably going to have to put your NIC in a different slot. My adapter is onboard! -- Peter __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi, wi0 and apm.
Hi. You need to edit "/boot/device.hints" and, at the line that is about disabling "apm", and for which the actual value is "1", change it for "0". ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi module build fails
On Sun, 13 Aug 2006 05:53:37 +0200 "Dimitar Vasilev" <[EMAIL PROTECTED]> wrote: > /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c: > In function ` > acpi_sleep_machdep': > /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c:285: > error: `a > cpi_resume_beep' undeclared (first use in this function) > /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c:285: > error: (E > ach undeclared identifier is reported only once > /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c:285: > error: fo > r each function it appears in.) > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > 99%ed-externs -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Winline -Wcast-qual -fformat-extensions > -std=c99 -Wsystem-headers -Werror -Wall -Wno-f > ormat-y2k -Wno-uninitialized -c > /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c > /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c: > In function `acpi_sleep_machdep': > /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c:285: > error: `acpi_resume_beep' undeclared (first use in this > function) > /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c:285: > error: (Each undeclared identifier is reported only once > /usr/src/sys/modules/acpi/acpi/../../../i386/acpica/acpi_wakeup.c:285: > error: for each function it appears in.) > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/GENERIC. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > [EMAIL PROTECTED]:/usr/src/# ^Gexit > > Branch - 6.1-stable > > This persists from 1 day - i have cvsuped from different > servers around the globe, including cvsup from scratch. > > The statement on line 285 is > > if (acpi_resume_beep) > timeout(acpi_stop_beep, NULL, 3 * hz); > > return (ret); > } > > Anyone knows how to fix this ? C is not my strong side. > Thanks, G'day Dimitar, Please see my previous post on the subject "`acpi_resume_beep' undeclared (first use in this function)" (though note that I believe that the problem is in version 1.39.2.2 of /usr/src/sys/i386/acpica/acpi_wakeup.c (as opposed to 1.39.2.1, as I previously incorrectly stated). Note also that this question really belongs on -stable, too :-) I CCed Nate Lawson (the commiter of the update I think caused the problem) on the replay in question, so I imagine this'll be sorted soon. > -- > Димитър Василев > Dimitar Vassilev > > GnuPG key ID: 0x4B8DB525 > Keyserver: pgp.mit.edu > Key fingerprint: D88A 3B92 DED5 917E 341E D62F 8C51 5FC4 4B8D > B525 -- Nick Withers email: [EMAIL PROTECTED] WWW: http://nickwithers.com Mobile: +61 414 397 446 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi module build fails
G'day Dimitar, Please see my previous post on the subject "`acpi_resume_beep' undeclared (first use in this function)" (though note that I believe that the problem is in version 1.39.2.2 of /usr/src/sys/i386/acpica/acpi_wakeup.c (as opposed to 1.39.2.1, as I previously incorrectly stated). Note also that this question really belongs on -stable, too :-) I CCed Nate Lawson (the commiter of the update I think caused the problem) on the replay in question, so I imagine this'll be sorted soon. > -- > Димитър Василев > Dimitar Vassilev > > GnuPG key ID: 0x4B8DB525 > Keyserver: pgp.mit.edu > Key fingerprint: D88A 3B92 DED5 917E 341E D62F 8C51 5FC4 4B8D > B525 -- Nick Withers email: [EMAIL PROTECTED] WWW: http://nickwithers.com Mobile: +61 414 397 446 Thanks. Saw it after I sent the letter. Waiting for fix. Have a nice weekend -- Димитър Василев Dimitar Vassilev GnuPG key ID: 0x4B8DB525 Keyserver: pgp.mit.edu Key fingerprint: D88A 3B92 DED5 917E 341E D62F 8C51 5FC4 4B8D B525 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi module build fails
> Date: Sun, 13 Aug 2006 05:53:37 +0200 > From: "Dimitar Vasilev" <[EMAIL PROTECTED]> > Subject: acpi module build fails > To: "FreeBSD Questions" <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-5; format=flowed > > Branch - 6.1-stable > > This persists from 1 day - i have cvsuped from different servers around the > globe, including cvsup from scratch. > > The statement on line 285 is > > if (acpi_resume_beep) > timeout(acpi_stop_beep, NULL, 3 * hz); > > return (ret); > } > > Anyone knows how to fix this ? C is not my strong side. > Thanks, It looks like acpi_wakeup.c had changes to beep on restart merged in, but the required changes to acpi_machdep.c aren't in the tagged release. I fixed this by setting my cvsup tag to *default release=cvs tag=RELENG_6_1 deleting /usr/src/sys, cvsupping again. This gets you to a working version (frozen, so you are less likely to be caught by similar updates on the STABLE release line). -- Jim Segrave [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi and boot problem
leo fante <[EMAIL PROTECTED]> writes: > Hi > I've installed freebsd 6.1 on an old pc on which I've configured several > services. Everything worked fine since last week when the motherboard died. > I've replaced the mobo and found that now the acpi could work (with the old > motherboard > the installation disabled the acpi at boot since the mainboard was > blacklisted). > > Since the old mobo was blacklisted the options on the menu were > 1 default > 2 boot with acpi > > Now I would like to have the acpi enabled by default at boot time on the > beastie menu. > 1 default > 2 boot without acpi > > reading the man of loader.conf I've added hint.acpi.0.disabled="0" > and now the pc boots with with acpi enabled but without having > the correct options in the boot menu. > > How I could fix the menu? >From a quick look at /boot/beastie.4th, I think that setting acpi_load in your loader.conf will do the job. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi and boot problem
>>From a quick look at /boot/beastie.4th, I think that setting acpi_load in your loader.conf will do the job. also it is written in loader.help but I've already tried and it doesn't work. thanks anyway for the advice ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi laptop fan control
epilogue <[EMAIL PROTECTED]> writes: > i'm hoping that someone here might have a suggestion for a longstanding > and nagging little problem - my laptop fan /never/ shuts off. > > the machine is a Compal N30W, which is the OEM version of the Dell > Inspiron 5000. i'm running 5.3 and have the latest BIOS. I had a similar problem on my old Toshiba Portege 3110CT, which i fixed by putting hw.acpi.cpu.cx_lowest=C1 in /etc/sysctl.conf and devd_enable="NO" in /etc/rc.conf. I don't know if it will fix your problem and even on my own laptop it's probably not the correct way to fix it, but it works for me. :) -- Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI kills USB mouse
Robert William Vesterman wrote: Hi, I've been having a hard time getting my USB mouse to work. Tonight, I accidentally booted without ACPI support, and the USB mouse magically worked. I tried booting with and without ACPI support several times thereafter, and each time, the USB mouse worked if and only if I hadn't booted with ACPI support. Is this a known problem? Is there a workaround? Is there any sort of information I can gather that might help to narrow down the problem? This is with 5.3-RELEASE, by the way. Thanks in advance for any help. Bob Vesterman. It is known (at least by myself) that the FreeBSD ACPI support can break all sorts of things if it doesn't happen to agree with your hardware. I think the known workaround is booting with support disabled. -Tabor Kelly ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi laptop fan control
On 01 Dec 2004 08:44:37 +0100 Christian Laursen <[EMAIL PROTECTED]> wrote: > epilogue <[EMAIL PROTECTED]> writes: > > > i'm hoping that someone here might have a suggestion for a > > longstanding and nagging little problem - my laptop fan /never/ > > shuts off. > > > > the machine is a Compal N30W, which is the OEM version of the Dell > > Inspiron 5000. i'm running 5.3 and have the latest BIOS. hello christian, thank you for sharing your solutino. i gave it a try, but did not observe any change in behaviour. everyone, i would very much appreciate any other suggestions that might be offered. the OP can be found here : http://lists.freebsd.org/pipermail/freebsd-questions/2004-November/066592.html and here: http://lists.freebsd.org/pipermail/freebsd-mobile/2004-November/005310.html thanks again, epi > I had a similar problem on my old Toshiba Portege 3110CT, which i > fixed by putting > > hw.acpi.cpu.cx_lowest=C1 > > in /etc/sysctl.conf > > and > > devd_enable="NO" > > in /etc/rc.conf. > > I don't know if it will fix your problem and even on my own laptop > it's probably not the correct way to fix it, but it works for me. :) > > -- > Christian Laursen > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi: throttle state in 6.0
On Saturday 24 December 2005 20:01, Niklas Nielsen wrote: > First of all - Merry Christmas :) > > I am new on the list (and dane) - so please bare with me. > > I noticed, when upgrading from 5.4 to 6.0 - that > hw.acpi.cpu.throttle_statedon't appear in > 6.0. > I have a IBM ThinkPad T40 with a centrino CPU. > > Is there another way to throttle down the CPU in 6.0? This can be done dynamically by powerd(8) or manually with the dev.cpu.0.freq sysctl. Regarding the latter method, the dev.cpu.0.freq_levels sysctl displays the available frequencies detected for the processor. -- Eric pgphUZclesgl5.pgp Description: PGP signature
Re: ACPI and APM on 5.3
[EMAIL PROTECTED] wrote: In attempting to get sound working on a Dell 7500 Inspiron (cira 1994) I tried many combinations of ACPI and APM thinking that my sound problems stemmed from interrupt or irq/pnp problems. That turned out not to be the case. Now everything is working, but I am using a combination of the two as documented below. Did I just 'luck out' or does apmd (sorta) by design work with the environment it finds? - /boot/loader.conf snd_maestro_load="YES" /etc/rc.conf apm_enable="YES" apmd_enable="YES" kldstat Id Refs AddressSize Name 19 0xc040 5cdad0 kernel 21 0xc09ce000 7200 snd_maestro.ko 32 0xc09d6000 1d4fcsound.ko 4 14 0xc09f4000 537f0acpi.ko 51 0xc169 17000linux.ko So apm.ko is not loaded. However everything works. I got to this configuration by accident (i.e., I forgot rc.conf). 'apm -l' works, 'apm -z' works and I can resume okay. FWIW... I have experienced the same thing on my Dell Inspiron 5100. I'm not currently running it that way, but was. Until I read that ACPI and APM will not run together. Supposedly the last one up notices the first and bails. So I opted for ACPI... which has left me wishing I was back with both even though they are not supposed to work together. I'm interested too, in other's opinions/explanations of this phenomenon. _ Douglas Denault http://www.safeport.com [EMAIL PROTECTED] Voice: 301-469-8766 Fax: 301-469-0601 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Regards, Eric ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and APM on 5.3
I finally got around to cleaning up rc.conf, now using only acpi. 'acpiconf -s 1' works. Resume is _much_ faster. That only leaves me with a couple of acpi boot errors to clean up (they do not affect anything AFAIK) and to set rc.resume to restore the network connection. I have some glitches that were also present (or worse) using apm. I would assume all this works much better on newer hardware. On Fri, 31 Dec 2004, Eric Schuele wrote: > [EMAIL PROTECTED] wrote: > > In attempting to get sound working on a Dell 7500 Inspiron (cira 1994) I > > tried > > many combinations of ACPI and APM thinking that my sound problems stemmed > > from > > interrupt or irq/pnp problems. That turned out not to be the case. Now > > everything is working, but I am using a combination of the two as documented > > below. > > > > Did I just 'luck out' or does apmd (sorta) by design work with the > > environment > > it finds? > > [cut] > FWIW... > I have experienced the same thing on my Dell Inspiron 5100. I'm not > currently running it that way, but was. Until I read that ACPI and APM > will not run together. Supposedly the last one up notices the first and > bails. So I opted for ACPI... which has left me wishing I was back with > both even though they are not supposed to work together. > > I'm interested too, in other's opinions/explanations of this phenomenon. > > Regards, > Eric _ Douglas Denault http://www.safeport.com [EMAIL PROTECTED] Voice: 301-469-8766 Fax: 301-469-0601 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI and APM on 5.3
[EMAIL PROTECTED] wrote: I finally got around to cleaning up rc.conf, now using only acpi. 'acpiconf -s 1' works. Resume is _much_ faster. That only leaves me with a couple of acpi 'acpiconf -s 1' works well for me too on my laptop while using only acpi. However 'acpiconf -s 3' causes an immediate reboot of the machine. No errors... nothing logged. Just blip... and a fresh POST of the machine. Its immediate... doesn't think twice. Haven't had much time to look into it. boot errors to clean up (they do not affect anything AFAIK) and to set rc.resume to restore the network connection. I have some glitches that were also present (or worse) using apm. I would assume all this works much better on newer hardware. On Fri, 31 Dec 2004, Eric Schuele wrote: [EMAIL PROTECTED] wrote: In attempting to get sound working on a Dell 7500 Inspiron (cira 1994) I tried many combinations of ACPI and APM thinking that my sound problems stemmed from interrupt or irq/pnp problems. That turned out not to be the case. Now everything is working, but I am using a combination of the two as documented below. Did I just 'luck out' or does apmd (sorta) by design work with the environment it finds? [cut] FWIW... I have experienced the same thing on my Dell Inspiron 5100. I'm not currently running it that way, but was. Until I read that ACPI and APM will not run together. Supposedly the last one up notices the first and bails. So I opted for ACPI... which has left me wishing I was back with both even though they are not supposed to work together. I'm interested too, in other's opinions/explanations of this phenomenon. Regards, Eric _ Douglas Denault http://www.safeport.com [EMAIL PROTECTED] Voice: 301-469-8766 Fax: 301-469-0601 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Regards, Eric ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
What's changed re: ACPI for 6.0??
Hi list I don't ask too many questions, but after scratching my head a bit, trawling through Google, some of the mailing list archives, /usr/src/UPDATING, and most of the contents of /sys/i386/conf, I'm still not sure what's up; however, I've ascertained that PEBKAC instead of the kernel code, which ought to be good news to those concerned with R.E. (had one "aha!" moment prior to hitting SEND on that e-mail) I just updated from 5.4 -> 6.0BETA5 about a week and a half ago. On 5.4, ACPI and "shutdown -p" Just Worked. On 6.0, it didn't: link_elf: symbol ioapic_enable_mixed_mode undefined KLD file acpi.ko - could not finalize loading However, a hour ago or so, I figured "what the heck, let's just put `device acpi` back into the kernel. Make, Make installkernel, and all's peachy. :-) So, what did I miss? I'd like to think that it was just that the documentation wasn't up to date with the code, but more likely it's just that my brain isn't working properly. If I could beg enlightenment for my sanity and also for future reference, what's changed/what did I miss? Donning my asbestos leotards, Kevin Kinsey DaleCo, S.P. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI? problem with release 8.0
I desperately need to make some progress on this issue. Is it likely that the issue is real rather than hardware or disk corruption? Earlier releases are operating OK on the same machine. I have now confirmed that: debug.acpi.disabled=acad button cpu lid thermal timer video still leaves the system crashing and powering down when idle for a while. And the more extensive: debug.acpi.disabled=acad bus children button cmbat cpu ec isa lid pci pci_link sysresource thermal timer video does the same. I don't really need power management but with acpi disabled the disks are not visible to the system. Are there sysctl variables that can influence this behaviour? Currently I believe we have: hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: NONE hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 machdep.idle: amdc1e machdep.idle_available: spin, amdc1e, hlt, acpi, However on the earlier RELEASEs that work I note we do not have machdep.idle or machdep.idle_available. Instead I find: machdep.cpu_idle_hlt: 1 machdep.hlt_cpus: 0 Although I've not been able to relate this directly to my problem from Googling it seems that there some issues with amdc1e under BSD, Linux and perhaps Windows. But all the references seem to amd c1e are related to systems in 64 bit mode while I am running (or trying to run) i386 so I wonder why I have: machdep.idle: amdc1e Maybe my problem is not acpi as such but this idle mode. My thought is to change this to machdep.idle: hlt or even machdep.idle: acpi Any comments or ideas please! Thank you for your attention. Malcolm Kay On Sat, 10 Apr 2010 05:22 pm, Malcolm Kay wrote: > My machine had two SATA 300GB drives > (WDC WD3200KS-00PFB0 21.00M21) one carrying FreeBSD > RELEASE-6.3 and the other RELEASE-7.0 all of which worked OK. > > Recently added SATA 1TB (WDC WD10EADS-00P8B0 01.00A01) and > installed RELEASE 8.0 thereon. When I boot to RELEASE 8.0 > I find after some time, few minutes to rather more minutes > the system just powers down without warning or any obvious > cause. It seems to mostly happen when the system is relatively > quiet. > > Suspecting the ACPI I added: > hint.acpi.0.disabled=1 > to loader.conf. > I then found RELEASE 8.0 would not boot -- or at least > it was unable to mount root. I get a "mountroot>" prompt > but this seemed not to accept anything I could think of, > and "?" to list available targets yielded nothing. Rebooting > and overriding this with option 2 (enable ACPI) in the boot > menu took me back to a bootable but fragile system. > > Changing the loader.conf entry to: > debug.acpi.disabled=all > had the same effect as the hint.acpi.0.disabled=1. > > I then thought to be somewhat selective with > debug.acpi.disabled and intended to try: > debug.acpi.disabled=acad button cpu lid thermal timer video > only now as I write this I discover I actually entered: > debug.acpi.disabled=acadbutton cpu lid thermal timer video > > Now the RELEASE-8.0 booted but remained fragile. > > I've repaired this last entry and will proceed to try it. > Meanwhile I feel I am fumbling about in the dark without > sufficient (or any real) knowledge of the range of tasks > performed by ACPI. > > Is my guess that I have an interaction problem between ACPI > and RELEASE-8.0 a reasonable one? Where can I go from here? > > The system uses a Gigabyte GA-M55SLI-S4 mother board and the > prcessor is AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ > > Please offer suggestions or comments. > > Malcolm Kay > > > ___ > 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" ___ 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? problem with release 8.0
On Mon, Apr 12, 2010 at 1:01 AM, Malcolm Kay wrote: > I desperately need to make some progress on this issue. > > Is it likely that the issue is real rather than hardware > or disk corruption? Earlier releases are operating OK on the same > machine. > > I have now confirmed that: > debug.acpi.disabled=acad button cpu lid thermal timer video > still leaves the system crashing and powering down when idle for > a while. And the more extensive: > debug.acpi.disabled=acad bus children button cmbat cpu ec isa > lid pci pci_link sysresource thermal timer video > does the same. > > I don't really need power management but with acpi disabled the > disks are not visible to the system. > > Are there sysctl variables that can influence this behaviour? > Currently I believe we have: > > hw.acpi.supported_sleep_state: S1 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: NONE > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 0 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 > machdep.idle: amdc1e > machdep.idle_available: spin, amdc1e, hlt, acpi, > > However on the earlier RELEASEs that work I note we do not have > machdep.idle or machdep.idle_available. Instead I find: > machdep.cpu_idle_hlt: 1 > machdep.hlt_cpus: 0 > > Although I've not been able to relate this directly to my problem > from Googling it seems that there some issues with amdc1e under > BSD, Linux and perhaps Windows. But all the references seem to > amd c1e are related to systems in 64 bit mode while I am running > (or trying to run) i386 so I wonder why I have: > machdep.idle: amdc1e > > Maybe my problem is not acpi as such but this idle mode. > > My thought is to change this to > machdep.idle: hlt > or even > machdep.idle: acpi > > Any comments or ideas please! > > Thank you for your attention. > Is there anything in /var/log/messages which indicates the cause? Can you monitor cpu temp? -- Adam Vande More ___ 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? problem with release 8.0
In freebsd-questions Digest, Vol 306, Issue 1, Message: 18 On Mon, 12 Apr 2010 15:31:33 +0930 Malcolm Kay wrote: > I desperately need to make some progress on this issue. Then I suggest taking it to freebsd-acpi@ without passing go .. maybe with a bit more data to hand, as outlined in the ACPI debugging section of the handbook. > Is it likely that the issue is real rather than hardware > or disk corruption? Earlier releases are operating OK on the same > machine. Sounds like a real issue, but I don't know the hardware. Does it have the latest available BIOS update? If not, that's step one. Will it stay up long enough to get a verbose dmesg off it? Do you have a verbose dmesg from an earlier working release for comparison? > I have now confirmed that: > debug.acpi.disabled=acad button cpu lid thermal timer video > still leaves the system crashing and powering down when idle for > a while. And the more extensive: > debug.acpi.disabled=acad bus children button cmbat cpu ec isa > lid pci pci_link sysresource thermal timer video > does the same. > > I don't really need power management but with acpi disabled the > disks are not visible to the system. ACPI needs to work on modern hardware, no question. > Are there sysctl variables that can influence this behaviour? > Currently I believe we have: > > hw.acpi.supported_sleep_state: S1 S4 S5 > hw.acpi.power_button_state: S5 > hw.acpi.sleep_button_state: S1 > hw.acpi.lid_switch_state: NONE > hw.acpi.standby_state: S1 > hw.acpi.suspend_state: NONE > hw.acpi.sleep_delay: 1 > hw.acpi.s4bios: 0 > hw.acpi.verbose: 0 May help to set hw.acpi.verbose=1 in /boot/loader.conf while debugging; especially useful after verbose boot for detail in dmesg and messages. > hw.acpi.disable_on_reboot: 0 > hw.acpi.handle_reboot: 0 > hw.acpi.reset_video: 0 > hw.acpi.cpu.cx_lowest: C1 Is that with acpi.thermal disabled? If so, showing hw.acpi and debug.acpi with everything enabled might provide more clues. > machdep.idle: amdc1e > machdep.idle_available: spin, amdc1e, hlt, acpi, > > However on the earlier RELEASEs that work I note we do not have > machdep.idle or machdep.idle_available. Instead I find: > machdep.cpu_idle_hlt: 1 > machdep.hlt_cpus: 0 > > Although I've not been able to relate this directly to my problem > from Googling it seems that there some issues with amdc1e under > BSD, Linux and perhaps Windows. But all the references seem to > amd c1e are related to systems in 64 bit mode while I am running > (or trying to run) i386 so I wonder why I have: > machdep.idle: amdc1e > > Maybe my problem is not acpi as such but this idle mode. Could well be. Someone on acpi@ will know about amdc1e, I don't, but any BIOS setting re C1E could be relevant to this. > My thought is to change this to > machdep.idle: hlt > or even > machdep.idle: acpi Maybe try setting it to acpi first (without any disabled parts) and try? Can't do any worse than crash the same? > Any comments or ideas please! > > Thank you for your attention. > > Malcolm Kay > > On Sat, 10 Apr 2010 05:22 pm, Malcolm Kay wrote: > > My machine had two SATA 300GB drives > > (WDC WD3200KS-00PFB0 21.00M21) one carrying FreeBSD > > RELEASE-6.3 and the other RELEASE-7.0 all of which worked OK. > > > > Recently added SATA 1TB (WDC WD10EADS-00P8B0 01.00A01) and > > installed RELEASE 8.0 thereon. When I boot to RELEASE 8.0 > > I find after some time, few minutes to rather more minutes > > the system just powers down without warning or any obvious > > cause. It seems to mostly happen when the system is relatively > > quiet. Adam's suggestion to check that esp. CPU temperature is within spec is worth checking; if you don't have any thermal zones in your ACPI I'd be surprised, and maybe concerned. A finger on the heatsink is next best. > > Suspecting the ACPI I added: > > hint.acpi.0.disabled=1 > > to loader.conf. > > I then found RELEASE 8.0 would not boot -- or at least > > it was unable to mount root. I get a "mountroot>" prompt > > but this seemed not to accept anything I could think of, > > and "?" to list available targets yielded nothing. Rebooting > > and overriding this with option 2 (enable ACPI) in the boot > > menu took me back to a bootable but fragile system. > > > > Changing the loader.conf entry to: > > debug.acpi.disabled=all > > had the same effect as the hint.acpi.0.disabled=1. As it should. > > I then thought to be somewhat selective with > > debug.acpi.disabled and intended to try: > > debug.acpi.disabled=acad button cpu lid thermal timer video > > only now as I write this I discover I actually entered: > > debug.acpi.disabled=acadbutton cpu lid thermal timer video > > > > Now the RELEASE-8.0 booted but remained fragile. > > > > I've repaired this last entry and will proceed to try it. > > Meanwhile I feel I am fumbling about in the dark without > > sufficient (or any re
Re: ACPI? problem with release 8.0
On Mon, 12 Apr 2010 04:40 pm, Adam Vande More wrote: > On Mon, Apr 12, 2010 at 1:01 AM, Malcolm Kay > > wrote: > > I desperately need to make some progress on this issue. > > > > Is it likely that the issue is real rather than hardware > > or disk corruption? Earlier releases are operating OK on the > > same machine. > > > > I have now confirmed that: > > debug.acpi.disabled=acad button cpu lid thermal timer video > > still leaves the system crashing and powering down when idle > > for a while. And the more extensive: > > debug.acpi.disabled=acad bus children button cmbat cpu ec > > isa lid pci pci_link sysresource thermal timer video > > does the same. > > > > I don't really need power management but with acpi disabled > > the disks are not visible to the system. > > > > Are there sysctl variables that can influence this > > behaviour? Currently I believe we have: > > > > hw.acpi.supported_sleep_state: S1 S4 S5 > > hw.acpi.power_button_state: S5 > > hw.acpi.sleep_button_state: S1 > > hw.acpi.lid_switch_state: NONE > > hw.acpi.standby_state: S1 > > hw.acpi.suspend_state: NONE > > hw.acpi.sleep_delay: 1 > > hw.acpi.s4bios: 0 > > hw.acpi.verbose: 0 > > hw.acpi.disable_on_reboot: 0 > > hw.acpi.handle_reboot: 0 > > hw.acpi.reset_video: 0 > > hw.acpi.cpu.cx_lowest: C1 > > machdep.idle: amdc1e > > machdep.idle_available: spin, amdc1e, hlt, acpi, > > > > However on the earlier RELEASEs that work I note we do not > > have machdep.idle or machdep.idle_available. Instead I find: > > machdep.cpu_idle_hlt: 1 > > machdep.hlt_cpus: 0 > > > > Although I've not been able to relate this directly to my > > problem from Googling it seems that there some issues with > > amdc1e under BSD, Linux and perhaps Windows. But all the > > references seem to amd c1e are related to systems in 64 bit > > mode while I am running (or trying to run) i386 so I wonder > > why I have: > > machdep.idle: amdc1e > > > > Maybe my problem is not acpi as such but this idle mode. > > > > My thought is to change this to > > machdep.idle: hlt > > or even > > machdep.idle: acpi > > > > Any comments or ideas please! > > > > Thank you for your attention. > > Is there anything in /var/log/messages which indicates the > cause? Can you monitor cpu temp? No clues in messages -- seems to just power down without any warning. I don't seem to have any thermal monitoring readily available except in the BIOS screens -- which seem to indicate everything is fine. But I guess this is not really indicative of what is happening with a running system. But the same machine has run earlier versions of FreeBSD staying up months at a time and only going down on power failures or on odd occassions I might want to look at BIOS settings or some such, so I feel fairly confident it is not a thermal issue. Hmm, I think there might be a BIOS setting to switch on health reporting which I expect would show up under sysctl. Thanks for the contribution. The more I think about it the more I believe the issue is connected with machdep.idle: amdc1e I am going to try changing this. Thanks and regards, Malcolm ___ 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? problem with release 8.0
On Tue, 13 Apr 2010 04:03 am, Ian Smith wrote: > In freebsd-questions Digest, Vol 306, Issue 1, Message: 18 > > On Mon, 12 Apr 2010 15:31:33 +0930 Malcolm Kay wrote: > > I desperately need to make some progress on this issue. > > Then I suggest taking it to freebsd-acpi@ without passing go > .. maybe with a bit more data to hand, as outlined in the ACPI > debugging section of the handbook. Yes, I have now realised this; but now somewhat reticent to move there now and be criticised for cross-posting > > > Is it likely that the issue is real rather than hardware > > or disk corruption? Earlier releases are operating OK on > > the same machine. > > Sounds like a real issue, but I don't know the hardware. Does > it have the latest available BIOS update? If not, that's step > one. Will it stay up long enough to get a verbose dmesg off > it? Do you have a verbose dmesg from an earlier working > release for comparison? Probably not; I have considered it. But the manufacturer's site warns not to upgrade unless you have identifyable problems (or something similar). And since earlier release work well I'm not anxious to open a new can of worms. If I become sufficiently desparate I'll try it. > > > I have now confirmed that: > > debug.acpi.disabled=acad button cpu lid thermal timer > > video still leaves the system crashing and powering down > > when idle for a while. And the more extensive: > > debug.acpi.disabled=acad bus children button cmbat cpu ec > > isa lid pci pci_link sysresource thermal timer video > > does the same. > > > > I don't really need power management but with acpi disabled > > the disks are not visible to the system. > > ACPI needs to work on modern hardware, no question. > > > Are there sysctl variables that can influence this > > behaviour? Currently I believe we have: > > > > hw.acpi.supported_sleep_state: S1 S4 S5 > > hw.acpi.power_button_state: S5 > > hw.acpi.sleep_button_state: S1 > > hw.acpi.lid_switch_state: NONE > > hw.acpi.standby_state: S1 > > hw.acpi.suspend_state: NONE > > hw.acpi.sleep_delay: 1 > > hw.acpi.s4bios: 0 > > hw.acpi.verbose: 0 > > May help to set hw.acpi.verbose=1 in /boot/loader.conf while > debugging; especially useful after verbose boot for detail in > dmesg and messages. Looks as though it might be useful, but I'm starting to believe acpi itself may not be the problem > > > hw.acpi.disable_on_reboot: 0 > > hw.acpi.handle_reboot: 0 > > hw.acpi.reset_video: 0 > > hw.acpi.cpu.cx_lowest: C1 > > Is that with acpi.thermal disabled? No, this is run with acpi as default configured. Boot | login as root | sysctl -a > sysctl.dump | shutdown -p now (Get out before crash so that I don't get into trouble with fsck on reboot, yes it runs in the background but takes forever.) Rebooting in FreeBSD 7.0 I can now mount the 8.0 partitions and look at the dump in my own time -- and also prepare these emails. (Fsck also runs under 7.0 on the 8.0 partitions if 8.0 was allowed to crash.) > If so, showing hw.acpi > and debug.acpi with everything enabled might provide more > clues. OK > > > machdep.idle: amdc1e > > machdep.idle_available: spin, amdc1e, hlt, acpi, > > > > However on the earlier RELEASEs that work I note we do not > > have machdep.idle or machdep.idle_available. Instead I > > find: machdep.cpu_idle_hlt: 1 > > machdep.hlt_cpus: 0 > > > > Although I've not been able to relate this directly to my > > problem from Googling it seems that there some issues with > > amdc1e under BSD, Linux and perhaps Windows. But all the > > references seem to amd c1e are related to systems in 64 bit > > mode while I am running (or trying to run) i386 so I wonder > > why I have: > > machdep.idle: amdc1e > > > > Maybe my problem is not acpi as such but this idle mode. > > Could well be. Someone on acpi@ will know about amdc1e, I > don't, but any BIOS setting re C1E could be relevant to this. > > > My thought is to change this to > > machdep.idle: hlt > > or even > > machdep.idle: acpi > > Maybe try setting it to acpi first (without any disabled > parts) and try? Can't do any worse than crash the same? I think this should be my next task. I have on hand another machine (not mine) running realease 8.0 but using an Intel Core i7 processor. This shows machdep.idle: acpi machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, > > > Any comments or ideas please! > > > > Thank you for your attention. > > > > Malcolm Kay > > > > On Sat, 10 Apr 2010 05:22 pm, Malcolm Kay wrote: > > > My machine had two SATA 300GB drives > > > (WDC WD3200KS-00PFB0 21.00M21) one carrying FreeBSD > > > RELEASE-6.3 and the other RELEASE-7.0 all of which worked > > > OK. > > > > > > Recently added SATA 1TB (WDC WD10EADS-00P8B0 01.00A01) > > > and installed RELEASE 8.0 thereon. When I boot to RELEASE > > > 8.0 I find after some time, few minutes to rather more > > > minutes the system just powers down without warning or > >
Re: acpi woes and dead filesystem
On Dec 8, 2006, at 1:21 PM, Steve Franks wrote: Now, I'm a bit of a tree-hugger, see, so I tend to like to suspend my computers insted of leaving them on perpetually. You might try turning them off entirely...? As such, tried acpiconf -s3 initially (others say unsupported). Seemed to go down ok, but coming back up it reboots every time. Ho hum. So I follow the handbook and go apm -Z, but that barely saves any power (can still hear disk, fan, etc, although screen blanks (apm -z also casues a reboot) Try updating your BIOS. Try to verify that all of the hardware you have installed actually supports going into power-saving mode-- I was surprised to discover that, for instance, some USB devices will prevent the system from entering S3 power-save mode. You might also try tweaking the BIOS settings, and see whether you can get S1 mode working first, before trying to get the deeper S3 mode going. Reanabled acpi -s3, lo, it appears to work, except, first time, only X comes back (not vtty's). Second time X doesn't come back either. Try ctl-alt-del, try suspend button, etc, no choice but to power down. I should mention at this point, that being paranoid, I habitually set all my fstab's to rw,sync, not just rw, which makes my next finding somewhat suprising to me: Upon power up, I am informed my filesystem is toast, and all I get is a shell. Did running "fsck" by hand fix it? Note that you really ought to mention some basic details, such as which version of FreeBSD you are running, and what your hardware is... My question: besides searching for sympathy, does anyone know how to truly protect a system against unplanned powerdown and/or crash during disk acess? By using an external UPS, or a high quality RAID system which includes an internal battery to ensure the disk cache gets flushed -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI trouble FreeBSD 7.0 STABLE
On Sunday 02 March 2008 09:19:43 budsz wrote: > Hi, > > Yesterday, I try to CVSUP/make world from FreeBSD 6.3 STABLE to > FreeBSD 7.0 STABLE: I got strange debug message here: > > Mar 2 14:14:14 gw-core-iixrouter kernel: acpi: suspend request > ignored (not ready yet) > Mar 2 14:14:14 gw-core-iixrouter kernel: acpi: request to enter state > S5 failed (err 6) > Mar 2 14:14:15 gw-core-iixrouter kernel: acpi: suspend request > ignored (not ready yet) > Mar 2 14:14:15 gw-core-iixrouter kernel: acpi: request to enter state > S5 failed (err 6) > Mar 2 14:14:16 gw-core-iixrouter kernel: acpi: suspend request > ignored (not ready yet) > Mar 2 14:14:16 gw-core-iixrouter kernel: acpi: request to enter state > S5 failed (err 6) > Mar 2 14:14:17 gw-core-iixrouter kernel: acpi: suspend request > ignored (not ready yet) > Mar 2 14:14:17 gw-core-iixrouter kernel: acpi: request to enter state > S5 failed (err 6) > Mar 2 14:14:18 gw-core-iixrouter kernel: acpi: suspend request > ignored (not ready yet) > Mar 2 14:14:18 gw-core-iixrouter kernel: acpi: request to enter state > S5 failed (err 6) > Mar 2 14:14:18 gw-core-iixrouter kernel: acpi: suspend request > ignored (not ready yet) > Mar 2 14:14:18 gw-core-iixrouter kernel: acpi: request to enter state > S5 failed (err 6) > Mar 2 14:14:19 gw-core-iixrouter syslogd: exiting on signal 15 That's a shutdown invoked by someone pressing and holding the powerbutton, or a loose/stuck powerbutton, that keeps sending "I'm pressed" to the kernel. -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI S3 compatible video card?
Andrew Gallatin wrote: > Does anybody have suggestions as to a cheap, AGP based video card > which is known to suspend/resume correctly and has DVI output? > > I'm currently using an "ATI Technologies Inc Rage 128 Pro Ultra TF rev > 0", and the screen fails to come back when I resume the machine (an > Intel D845EBG2 based desktop). > > Since I need to get a new card, I want to ensure I get one which is > known to work with ACPI. > > Thanks, > > Drew I think the ATI Radeon DDR (7500) will do this, and they are quite cheap now ... if you can find them. BTW ... this is a candidate for freebsd-questions rather than freebsd-current. Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI not working for shutdown -p
On Mon, 20 Sep 2004 13:23:32 -0600, Jason Porter <[EMAIL PROTECTED]> wrote: > I had things working just fine before, then I rebuild my kernel and I > don't know what happened, but I can't get ACPI to turn off the computer > anymore. I'm running a 5.3BETA3 from Sept 9 and I'm on an ASUS A7S333. > I'll include the dmesg report, if anyone has any questions, let me > know, thanks. > > Copyright (c) 1992-2004 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >The Regents of the University of California. All rights reserved. > FreeBSD 5.3-BETA3 #4: Mon Sep 20 12:32:23 MDT 2004 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DESKTOP > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(TM) XP 1800+ (1529.51-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 > > Features=0x383fbff > AMD Features=0xc048 > real memory = 268419072 (255 MB) > avail memory = 257183744 (245 MB) > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 > cpu0: on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > ACPI link \\_SB_.LNKH has invalid initial irq 9, ignoring > ACPI link \\_SB_.LNKD has invalid initial irq 9, ignoring You have a broken ACPI. Hard luck Regards S. -- Subhro Sankha Kar School of Information Technology Block AQ-13/1 Sector V ZIP 700091 India ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI not working for shutdown -p
Jason Porter <[EMAIL PROTECTED]> writes: > I had things working just fine before, then I rebuild my kernel and I > don't know what happened, but I can't get ACPI to turn off the computer > anymore. I'm running a 5.3BETA3 from Sept 9 and I'm on an ASUS A7S333. > I'll include the dmesg report, if anyone has any questions, let me > know, thanks. Try adding the following line to /boot/loader.conf.local and see if that helps, I've needed this line with an A7V600-X but haven't recently (in BETA) checked if it's still needed (dual-boot machine which usually sees reboot, not halt -p): hw.acpi.disable_on_poweroff="0" -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI not working for shutdown -p
Nope, still no go. It gives me a timeout whenever it tries to shutdown, I don't know if that has anything to do with the timeout tables, I'd assume so, but I haven't the slightest idea on how to fix that. I'm still confused as to why it doesn't work on FreeBSD, but the Windows drive I have shuts down the machine just fine. Oh well. Thanks for the help though. Matthias Andree wrote: Jason Porter <[EMAIL PROTECTED]> writes: I had things working just fine before, then I rebuild my kernel and I don't know what happened, but I can't get ACPI to turn off the computer anymore. I'm running a 5.3BETA3 from Sept 9 and I'm on an ASUS A7S333. I'll include the dmesg report, if anyone has any questions, let me know, thanks. Try adding the following line to /boot/loader.conf.local and see if that helps, I've needed this line with an A7V600-X but haven't recently (in BETA) checked if it's still needed (dual-boot machine which usually sees reboot, not halt -p): hw.acpi.disable_on_poweroff="0" -Jason Porter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI issue on my Toshiba laptop
On Sunday 01 March 2009 19:25:44 "Michael A. Alestock" wrote: > Hi all, > > As you're already aware, there've been known issues with ACPI running on > some laptops. For instance, mine is a Toshiba Satellite A105-S2051. > When I first installed FreeBSD v6.3 I would get the following error... > > *** ACPI-0370: Error - No installed handler for fixed event *** > > >From here, I wouldn't be able to use my built-in LAN or Atheros 5212 > > wireless because of constant WATCHDOG: DEVICE TIMEOUT error messages. > However, I later found out that by disabling the ACPI by placing two > lines in your /boot/device.hints or /boot/loader.conf files, > > hint.apic.0.disabled="1" > hint.acpi.0.disabled="1" > > you would be able to use both the wireless and LAN without the ACPI > running. This has been the case for me for a while, and everything was > going great until lastnight That's the drawback of work-arounds: bugs don't get fixed. Your best bet is to post relevant information [1] to freebsd-acpi list and possibly -mobile with respect to ath. [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ 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 problem on dell latitude d830
Ouyang Xueyu writes: > Hello! > > I`ve just installed freebsd 8.2 i386 stable on a Dell Latitude D830. > I`m using gnome 2 with HAL and DBUS successfully. > > My notebook is not able to go into sleeping mode, it doesn`t work when I use > "acpiconf -s 3" or "acpiconf -s 4". Mode S3 gets it into sleep mode, but it > freezes > after wake-up with a distorted screen. > In mode S4 (suspend-to-disk) it isn`t even able to > get into sleeping mode. I want to initiate S4 state by closing the lid. I have a Latitude D630, which is basically the smaller brother of the D830. When it ran FreeBSD I had success in getting the D630 to sleep (s3) and resume. This was a while ago on 8-STABLE with amd64. At least back then, you would need an amd64 install to get this working (something with acpi being better in amd64 then it was in i386). I am not sure that is still the case, but I would not be surprised if it is. However, before you run off and reinstall: (again back then) both the bge and wpi driver (i.e. LAN and WLAN) did not work properly after resuming. This basically made sleeping the laptop useless. I'm not sure this is such good news, but I hope it is informative. If you manage to get it working let me know. Regards, -- - Frank ___ 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 questions about press power button
Re: freebsd-questions Digest, Vol 326, Issue 11, Message: 19
On Sun, 5 Sep 2010 19:04:51 +0800 dave jones wrote:
> I'm running FreeBSD 8 on my desktop. I want to write a file or do something
> when I or someone presses power button. In devd.conf, I added the
> following lines
> for testing:
>
> notify 10 {
> match "system" "ACPI";
> match "subsystem" "Button";
> matcho "notify""0x00"
> action "echo hello world";
> };
>
> But it doesn't work. Would anyone tell me how to do? Thanks.
I'm not sure this will do what you want anyway; devd will handle the
notify but won't replace the normal action itself, ie it might power
down (hopefully running shutdown actions, synching disks etc), however
'matcho' won't match 'match' :) and that line needs a trailing ';'.
Whether or not it powers down (perhaps depending on BIOS setting, ie
instant-off or 4-second-delay), it may be more useful logging it, say:
action "logger -p kern.emerg 'power button pressed!'";
cheers, Ian
___
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 questions about press power button
2010/9/5 dave jones :
> Hello,
>
> I'm running FreeBSD 8 on my desktop. I want to write a file or do something
> when I or someone presses power button. In devd.conf, I added the
> following lines
> for testing:
>
> notify 10 {
> match "system" "ACPI";
> match "subsystem" "Button";
> matcho "notify" "0x00"
> action "echo hello world";
> };
>
> But it doesn't work. Would anyone tell me how to do? Thanks.
>
> Regards,
> Dave.
> ___
> 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"
>
I think, you must first disable this setting because S5 is the default
behavior when pressing the power button, it calls /etc/rc.shutdown.
hw.acpi.power_button_state: S5
Disable it with sysctl hw.acpi.power_button_state=NONE and add this
line to /etc/sysctl.conf. And then maybe the power button will be
released for an other purpose?
Kind regards.
--
Demelier David
___
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: Standby, sleep, suspend and resume
On Sat, 25 Nov 2006, Erik Norgaard wrote:
Hi:
I have the following sysctl parameters:
hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S3
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
First, I'd like that the screen is switched off when the lid closes, so I
assume that I should set hw.acpi.lid_switch_state to something, but I don't
know what.
Second: Is there a way to manually toggle the sleep state so I can create a
menu item "sleep" or "standby"?
Last: When the laptop goes into some suspend mode - I don't know which - I
don't know how to bring it back alive except for rebooting. What is the
secret key combination? (typically).
Thanks, Erik
These are my settings. This is for a thinkpad T42p, your settings may be
slightly different.
sysctl:
hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S3
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 3
/boot/loader.conf
snd_ich_load="YES"
if_ipw_load="YES"
wlan_load="YES"
wlan_wep_load="YES"
acpi_ibm_load="YES" < for thinkpad
If I close the lid the T42p goes to standby, opening wakes up. The sleep button
fn-F4 does a suspend, again opening the lid does a resume. I have not figured
out suspend to disk but for my purposes suspend draws power so slowly, I have
not bothered.
It may be that you do need something set for hw.acpi.lid_switch_state, I do not.
Resume does not correctly redraw the X-windows background, but it writing this I
noticed I put:
notify 10 {
match "system" "ACPI";
match "subsystem" "Lid";
action "/usr/X11R6/bin/xrandr -display :0.0 -s 0";
};
inside of the comments in /etc/devd.conf.
I got most of my information from:
http://www.cs.ucr.edu/~trep/tsrT40freebsd.html
google
various Linux sites talking about thinkpads
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI: Standby, sleep, suspend and resume
On Sat, 25 Nov 2006, doug wrote:
On Sat, 25 Nov 2006, Erik Norgaard wrote:
Hi:
I have the following sysctl parameters:
hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S3
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
First, I'd like that the screen is switched off when the lid closes, so I
assume that I should set hw.acpi.lid_switch_state to something, but I don't
know what.
Second: Is there a way to manually toggle the sleep state so I can create a
menu item "sleep" or "standby"?
Last: When the laptop goes into some suspend mode - I don't know which - I
don't know how to bring it back alive except for rebooting. What is the
secret key combination? (typically).
Thanks, Erik
These are my settings. This is for a thinkpad T42p, your settings may be
slightly different.
sysctl:
hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S3
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 3
/boot/loader.conf
snd_ich_load="YES"
if_ipw_load="YES"
wlan_load="YES"
wlan_wep_load="YES"
acpi_ibm_load="YES" < for thinkpad
If I close the lid the T42p goes to standby, opening wakes up. The sleep
button fn-F4 does a suspend, again opening the lid does a resume. I have not
figured out suspend to disk but for my purposes suspend draws power so
slowly, I have not bothered.
It may be that you do need something set for hw.acpi.lid_switch_state, I do
not. Resume does not correctly redraw the X-windows background, but it
writing this I noticed I put:
notify 10 {
match "system" "ACPI";
match "subsystem" "Lid";
action "/usr/X11R6/bin/xrandr -display :0.0 -s 0";
};
inside of the comments in /etc/devd.conf.
I got most of my information from:
http://www.cs.ucr.edu/~trep/tsrT40freebsd.html
google
various Linux sites talking about thinkpads
The devd.conf change works. Trying to help you helped me. I hope this
information aids you as well. Without the xrandr, I got black and white stripes
randomly for the background.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI slowing CPU... or something else
On Wed, 25 Jul 2007, Garrett Cooper wrote:
> V.I.Victor wrote:
>> I've two 5.4 desktop boxes. Pretty much the same installation; both
>> from the same CD, same apps, no monitor/keyboard, 1-user logged-on via
>> ssh (command-line only w/no gui) and otherwise lightly loaded.
>>
>> Box_A: CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU)
>> avail memory = 121630720 (115 MB)
>> ACPI disabled by blacklist.
>>
>> Box_B: CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.19-MHz 686-class CPU)
>> avail memory = 252186624 (240 MB)
>> cpu0: on acpi0
>> acpi_throttle0: on cpu0
>>...
> Yes. On my virtual machine with ACPI:
>
> dev.cpu.0.freq: 2653
> dev.cpu.0.freq_levels: 2653/-1 2321/-1 1989/-1 1658/-1 1326/-1 994/-1 663/-1
> 331/-1
>
> [EMAIL PROTECTED] ~]# dmesg | grep 26
> FreeBSD 7.0-CURRENT #5: Tue Jul 17 08:22:26 UTC 2007
> CPU: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz (2666.79-MHz K8-class
> CPU)
> Timecounter "TSC" frequency 2666794890 Hz quality 800
>
> What are the following sysctls set to?
>
> kern.clockrate
> hw.acpi.cpu.cx_lowest
> dev.cpu.0.cx_lowest
> dev.cpu.0.cx_usage
Thanks for the reply! I don't seem to have the last 2 you've asked about.
'sysctl -a | egrep "clockrate|cpu"' reported the following:
kern.clockrate: { hz = 100, tick = 1, profhz = 1024, stathz = 128 }
kern.threads.virtual_cpu: 1
kern.ccpu: 1948
kern.smp.maxcpus: 1
kern.smp.cpus: 1
hw.ncpu: 1
hw.clockrate: 1794
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu.cx_usage: 100.00%
machdep.cpu_idle_hlt: 1
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1796
dev.cpu.0.freq_levels: 1796/-1 1571/-1 1347/-1 1122/-1 898/-1 673/-1 449/-1
224/-1
dev.acpi_throttle.0.%parent: cpu0
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI slowing CPU... or something else
V.I.Victor wrote: I've two 5.4 desktop boxes. Pretty much the same installation; both from the same CD, same apps, no monitor/keyboard, 1-user logged-on via ssh (command-line only w/no gui) and otherwise lightly loaded. Box_A: CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU) avail memory = 121630720 (115 MB) ACPI disabled by blacklist. Box_B: CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.19-MHz 686-class CPU) avail memory = 252186624 (240 MB) cpu0: on acpi0 acpi_throttle0: on cpu0 When running the following segment of a small gawk program: cnt=0; s=systime(); while(s==systime()) ; # next second s=systime(); while(s==systime()) cnt++; # count for 1-sec Box_A(600M) always reports 'cnt' between 31 to 32. Box_B(1800M) has been as low as 167000 and never higher than 254000. So -- Box_B is 3-times faster than Box_A but runs the segment (at best) about 20% more slowly! Yesterday was when I saw the Box_B(1800M) 167000-ish numbers. Today after seeing an increase to the 25-ish numbers, I started to read-up on ACPI. sysctl -a | grep cpu.*freq reports: dev.cpu.0.freq: 1796 dev.cpu.0.freq_levels: 1796/-1 1571/-1 1347/-1 1122/-1 898/-1 \ 673/-1 449/-1 224/-1 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 If I understand the 'sysctl' output, Box_B is running (now) at 1796-MHz. And for Box_B cnt==252433; for Box_A cnt==318942. Any opinions on what's going on and/or what I'm not understanding? Thanks! Yes. On my virtual machine with ACPI: dev.cpu.0.freq: 2653 dev.cpu.0.freq_levels: 2653/-1 2321/-1 1989/-1 1658/-1 1326/-1 994/-1 663/-1 331/-1 [EMAIL PROTECTED] ~]# dmesg | grep 26 FreeBSD 7.0-CURRENT #5: Tue Jul 17 08:22:26 UTC 2007 CPU: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz (2666.79-MHz K8-class CPU) Timecounter "TSC" frequency 2666794890 Hz quality 800 What are the following sysctls set to? kern.clockrate hw.acpi.cpu.cx_lowest dev.cpu.0.cx_lowest dev.cpu.0.cx_usage -Garrett ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI slowing CPU... or something else
On Wed, 25 Jul 2007 [EMAIL PROTECTED] wrote:
>On Wed, 25 Jul 2007, V.I.Victor wrote:
>
>> On Wed, 25 Jul 2007, Garrett Cooper wrote:
>>
>>> V.I.Victor wrote:
I've two 5.4 desktop boxes. Pretty much the same installation; both
from the same CD, same apps, no monitor/keyboard, 1-user logged-on via
ssh (command-line only w/no gui) and otherwise lightly loaded.
Box_A: CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU)
avail memory = 121630720 (115 MB)
ACPI disabled by blacklist.
Box_B: CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.19-MHz 686-class CPU)
avail memory = 252186624 (240 MB)
cpu0: on acpi0
acpi_throttle0: on cpu0
...
>>
>>> Yes. On my virtual machine with ACPI:
>>>
>>> dev.cpu.0.freq: 2653
>>> dev.cpu.0.freq_levels: 2653/-1 2321/-1 1989/-1 1658/-1 1326/-1 994/-1 663/-1
>>> 331/-1
>>>
>>> [EMAIL PROTECTED] ~]# dmesg | grep 26
>>> FreeBSD 7.0-CURRENT #5: Tue Jul 17 08:22:26 UTC 2007
>>> CPU: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz (2666.79-MHz K8-class
>>> CPU)
>>> Timecounter "TSC" frequency 2666794890 Hz quality 800
>>>
>>> What are the following sysctls set to?
>>>
>>> kern.clockrate
>>> hw.acpi.cpu.cx_lowest
>>> dev.cpu.0.cx_lowest
>>> dev.cpu.0.cx_usage
>>
>> Thanks for the reply! I don't seem to have the last 2 you've asked about.
>>
>> 'sysctl -a | egrep "clockrate|cpu"' reported the following:
>>
>> kern.clockrate: { hz = 100, tick = 1, profhz = 1024, stathz = 128 }
>> kern.threads.virtual_cpu: 1
>> kern.ccpu: 1948
>> kern.smp.maxcpus: 1
>> kern.smp.cpus: 1
>> hw.ncpu: 1
>> hw.clockrate: 1794
>> hw.acpi.cpu.cx_supported: C1/0
>> hw.acpi.cpu.cx_lowest: C1
>> hw.acpi.cpu.cx_usage: 100.00%
>> machdep.cpu_idle_hlt: 1
>> dev.cpu.0.%desc: ACPI CPU
>> dev.cpu.0.%driver: cpu
>> dev.cpu.0.%location: handle=\_PR_.CPU0
>> dev.cpu.0.%pnpinfo: _HID=none _UID=0
>> dev.cpu.0.%parent: acpi0
>> dev.cpu.0.freq: 1796
>> dev.cpu.0.freq_levels: 1796/-1 1571/-1 1347/-1 1122/-1 898/-1 673/-1 449/-1
>> 224/-1
>> dev.acpi_throttle.0.%parent: cpu0
>> dev.cpufreq.0.%driver: cpufreq
>> dev.cpufreq.0.%parent: cpu0
>
>
>
> Do you have SMP enabled?
No. Both boxes have pretty minimal, basic installations.
> You also might be able to tune the kernel clock rate to obtain better
> performance; I forget what the values were for sysctl, but if you search
> around the current@ archives a bit, there was a discussion involving VMware
> and clock tuning approximately 2-3 months ago which details this issue, and
> possible solutions.
Perhaps tuning could help. I'll check the archives.
However, it just seems to me that the 1.8 GHz box ought to perform the simple
prog (orig post) at least as fast as the 6 MHz box.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI slowing CPU... or something else
On Wed, 25 Jul 2007, V.I.Victor wrote:
On Wed, 25 Jul 2007 [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, V.I.Victor wrote:
On Wed, 25 Jul 2007, Garrett Cooper wrote:
V.I.Victor wrote:
I've two 5.4 desktop boxes. Pretty much the same installation; both
from the same CD, same apps, no monitor/keyboard, 1-user logged-on via
ssh (command-line only w/no gui) and otherwise lightly loaded.
Box_A: CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU)
avail memory = 121630720 (115 MB)
ACPI disabled by blacklist.
Box_B: CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.19-MHz 686-class CPU)
avail memory = 252186624 (240 MB)
cpu0: on acpi0
acpi_throttle0: on cpu0
...
Yes. On my virtual machine with ACPI:
dev.cpu.0.freq: 2653
dev.cpu.0.freq_levels: 2653/-1 2321/-1 1989/-1 1658/-1 1326/-1 994/-1 663/-1
331/-1
[EMAIL PROTECTED] ~]# dmesg | grep 26
FreeBSD 7.0-CURRENT #5: Tue Jul 17 08:22:26 UTC 2007
CPU: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz (2666.79-MHz K8-class
CPU)
Timecounter "TSC" frequency 2666794890 Hz quality 800
What are the following sysctls set to?
kern.clockrate
hw.acpi.cpu.cx_lowest
dev.cpu.0.cx_lowest
dev.cpu.0.cx_usage
Thanks for the reply! I don't seem to have the last 2 you've asked about.
'sysctl -a | egrep "clockrate|cpu"' reported the following:
kern.clockrate: { hz = 100, tick = 1, profhz = 1024, stathz = 128 }
kern.threads.virtual_cpu: 1
kern.ccpu: 1948
kern.smp.maxcpus: 1
kern.smp.cpus: 1
hw.ncpu: 1
hw.clockrate: 1794
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu.cx_usage: 100.00%
machdep.cpu_idle_hlt: 1
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1796
dev.cpu.0.freq_levels: 1796/-1 1571/-1 1347/-1 1122/-1 898/-1 673/-1 449/-1
224/-1
dev.acpi_throttle.0.%parent: cpu0
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
Do you have SMP enabled?
No. Both boxes have pretty minimal, basic installations.
You also might be able to tune the kernel clock rate to obtain better
performance; I forget what the values were for sysctl, but if you search
around the current@ archives a bit, there was a discussion involving VMware
and clock tuning approximately 2-3 months ago which details this issue, and
possible solutions.
Perhaps tuning could help. I'll check the archives.
However, it just seems to me that the 1.8 GHz box ought to perform the simple
prog (orig post) at least as fast as the 6 MHz box.
Depends on:
1. What you're trying to do.
2. What your programs are optimized for.
3. Additional factors (I/O, load, etc).
4. Hardware attached to each machine. Some examples...
a. Comparing a SCSI disk vs a PATA disk.
b. Clockspeed applied to the RAM on one machine isn't equal to the other.
c. Motherboard manufacturers -- some manufacturers have done a shoddy job
with memory handling, BIOS manufacturing, and other critical stats in the past.
Try disabling ACPI on the P4 though and see what happens. I will say though,
the Willamette (1st gen P4) chips weren't Intel's finest desktop chip; some
people went far enough to complain that the Willamette series was nothing more
than overclocked Coppermines, i.e. P3's. I haven't taken a look at the
architectures and compared them, so those may be empty claims.
You'll get performance with a Northwood or Prescott series P4 processor though,
in particular the later revisions of both chips, once they introduced
Hyperthreading.
And remember, operating frequency of a CPU doesn't mean everything; it's just a
ballpark figure for performance ;).
Finally, quite a few advancements have been made going from 5.4 to 6.2. I'd say
give 6.2 (and soon 7-BETA/-RELEASE) a try before ruling out a major problem
with your PC(s), or FreeBSD (overall).
-Garrett
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI slowing CPU... or something else
On Wed, 25 Jul 2007, V.I.Victor wrote:
On Wed, 25 Jul 2007, Garrett Cooper wrote:
V.I.Victor wrote:
I've two 5.4 desktop boxes. Pretty much the same installation; both
from the same CD, same apps, no monitor/keyboard, 1-user logged-on via
ssh (command-line only w/no gui) and otherwise lightly loaded.
Box_A: CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU)
avail memory = 121630720 (115 MB)
ACPI disabled by blacklist.
Box_B: CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.19-MHz 686-class CPU)
avail memory = 252186624 (240 MB)
cpu0: on acpi0
acpi_throttle0: on cpu0
...
Yes. On my virtual machine with ACPI:
dev.cpu.0.freq: 2653
dev.cpu.0.freq_levels: 2653/-1 2321/-1 1989/-1 1658/-1 1326/-1 994/-1 663/-1
331/-1
[EMAIL PROTECTED] ~]# dmesg | grep 26
FreeBSD 7.0-CURRENT #5: Tue Jul 17 08:22:26 UTC 2007
CPU: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz (2666.79-MHz K8-class
CPU)
Timecounter "TSC" frequency 2666794890 Hz quality 800
What are the following sysctls set to?
kern.clockrate
hw.acpi.cpu.cx_lowest
dev.cpu.0.cx_lowest
dev.cpu.0.cx_usage
Thanks for the reply! I don't seem to have the last 2 you've asked about.
'sysctl -a | egrep "clockrate|cpu"' reported the following:
kern.clockrate: { hz = 100, tick = 1, profhz = 1024, stathz = 128 }
kern.threads.virtual_cpu: 1
kern.ccpu: 1948
kern.smp.maxcpus: 1
kern.smp.cpus: 1
hw.ncpu: 1
hw.clockrate: 1794
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu.cx_usage: 100.00%
machdep.cpu_idle_hlt: 1
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1796
dev.cpu.0.freq_levels: 1796/-1 1571/-1 1347/-1 1122/-1 898/-1 673/-1 449/-1
224/-1
dev.acpi_throttle.0.%parent: cpu0
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
Do you have SMP enabled? If so, please realize that you won't benefit from it
at all because the chip you have (Willamette) doesn't support SMP
(Hyperthreading or multi-core processing). In fact this may hinder your
processing a bit, because I believe that adding SMP adds more complicated
algorithms and additional job constraints to the kernel scheduler; I could be
incorrect though.
You also might be able to tune the kernel clock rate to obtain better
performance; I forget what the values were for sysctl, but if you search around
the current@ archives a bit, there was a discussion involving VMware and clock
tuning approximately 2-3 months ago which details this issue, and possible
solutions.
-Garrett
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI slowing CPU... or something else
V.I.Victor wrote: > I was wondering about the "truth-of-clockspeed." Perhaps the 1800-MHz only > applies to CPU internal cache, etc. while the external bus-clocking is down > at 500-MHz or so. Sounds like a typical marketing ploy! > > About disabling the ACPI... Can I do it *safely* via the remote-ssh > connection? Or do I need to be at the box w/ keyboard and monitor? What > I've read makes it seem that the ACPI is set at boot-time. > > > > > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > > If you don't mind rebooting the remote machine, add: hint.acpi.0.disabled="1" to /boot/device.hints and reboot ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI slowing CPU... or something else
On Thu, 26 Jul 2007, V.I.Victor wrote: On Thu, 26 Jul 2007, Manolis Kiagias wrote: V.I.Victor wrote: I was wondering about the "truth-of-clockspeed." Perhaps the 1800-MHz only applies to CPU internal cache, etc. while the external bus-clocking is down at 500-MHz or so. Sounds like a typical marketing ploy! About disabling the ACPI... Can I do it *safely* via the remote-ssh connection? Or do I need to be at the box w/ keyboard and monitor? What I've read makes it seem that the ACPI is set at boot-time. If you don't mind rebooting the remote machine, add: hint.acpi.0.disabled="1" to /boot/device.hints and reboot Although I've re-booted remotely, I've never done it after a boot modification. It's probably prudent to wait 'til the weekend to try this -- mistakes are easier to deal with! Thanks for the info. All that rebooting remotely in this case will result in is ACPI being disabled :).. you should be able to disable ACPI from the BIOS as well, if you like. -Garrett ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI slowing CPU... or something else
On Wed, 25 Jul 2007 [EMAIL PROTECTED] wrote:
>On Wed, 25 Jul 2007, V.I.Victor wrote:
>
>> On Wed, 25 Jul 2007 [EMAIL PROTECTED] wrote:
>>
>>> On Wed, 25 Jul 2007, V.I.Victor wrote:
>>>
On Wed, 25 Jul 2007, Garrett Cooper wrote:
> V.I.Victor wrote:
>> I've two 5.4 desktop boxes. Pretty much the same installation; both
>> from the same CD, same apps, no monitor/keyboard, 1-user logged-on via
>> ssh (command-line only w/no gui) and otherwise lightly loaded.
>>
>> Box_A: CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU)
>> avail memory = 121630720 (115 MB)
>> ACPI disabled by blacklist.
>>
>> Box_B: CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1794.19-MHz 686-class
>> CPU)
>> avail memory = 252186624 (240 MB)
>> cpu0: on acpi0
>> acpi_throttle0: on cpu0
>> ...
> Yes. On my virtual machine with ACPI:
>
> dev.cpu.0.freq: 2653
> dev.cpu.0.freq_levels: 2653/-1 2321/-1 1989/-1 1658/-1 1326/-1 994/-1
> 663/-1
> 331/-1
>
> [EMAIL PROTECTED] ~]# dmesg | grep 26
> FreeBSD 7.0-CURRENT #5: Tue Jul 17 08:22:26 UTC 2007
> CPU: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz (2666.79-MHz K8-class
> CPU)
> Timecounter "TSC" frequency 2666794890 Hz quality 800
>
> What are the following sysctls set to?
>
> kern.clockrate
> hw.acpi.cpu.cx_lowest
> dev.cpu.0.cx_lowest
> dev.cpu.0.cx_usage
Thanks for the reply! I don't seem to have the last 2 you've asked about.
'sysctl -a | egrep "clockrate|cpu"' reported the following:
kern.clockrate: { hz = 100, tick = 1, profhz = 1024, stathz = 128 }
kern.threads.virtual_cpu: 1
kern.ccpu: 1948
kern.smp.maxcpus: 1
kern.smp.cpus: 1
hw.ncpu: 1
hw.clockrate: 1794
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu.cx_usage: 100.00%
machdep.cpu_idle_hlt: 1
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1796
dev.cpu.0.freq_levels: 1796/-1 1571/-1 1347/-1 1122/-1 898/-1 673/-1
449/-1 224/-1
dev.acpi_throttle.0.%parent: cpu0
dev.cpufreq.0.%driver: cpufreq
dev.cpufreq.0.%parent: cpu0
>>>
>>>
>>>
>>> Do you have SMP enabled?
>>
>> No. Both boxes have pretty minimal, basic installations.
>>
>>> You also might be able to tune the kernel clock rate to obtain better
>>> performance; I forget what the values were for sysctl, but if you search
>>> around the current@ archives a bit, there was a discussion involving VMware
>>> and clock tuning approximately 2-3 months ago which details this issue, and
>>> possible solutions.
>>
>> Perhaps tuning could help. I'll check the archives.
>>
>> However, it just seems to me that the 1.8 GHz box ought to perform the
>> simple prog (orig post) at least as fast as the 6 MHz box.
>
> Depends on:
> 1. What you're trying to do.
> 2. What your programs are optimized for.
> 3. Additional factors (I/O, load, etc).
> 4. Hardware attached to each machine. Some examples...
> a. Comparing a SCSI disk vs a PATA disk.
> b. Clockspeed applied to the RAM on one machine isn't equal to the other.
> c. Motherboard manufacturers -- some manufacturers have done a shoddy job
> with memory handling, BIOS manufacturing, and other critical stats in the
> past.
>
> Try disabling ACPI on the P4 though and see what happens. I will say though,
> the Willamette (1st gen P4) chips weren't Intel's finest desktop chip; some
> people went far enough to complain that the Willamette series was nothing
> more than overclocked Coppermines, i.e. P3's. I haven't taken a look at the
> architectures and compared them, so those may be empty claims.
I was wondering about the "truth-of-clockspeed." Perhaps the 1800-MHz only
applies to CPU internal cache, etc. while the external bus-clocking is down at
500-MHz or so. Sounds like a typical marketing ploy!
About disabling the ACPI... Can I do it *safely* via the remote-ssh
connection? Or do I need to be at the box w/ keyboard and monitor? What I've
read makes it seem that the ACPI is set at boot-time.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI slowing CPU... or something else
On Thu, 26 Jul 2007, Manolis Kiagias wrote: > V.I.Victor wrote: I was wondering about the "truth-of-clockspeed." >> Perhaps the 1800-MHz only applies to CPU internal cache, etc. while >> the external bus-clocking is down at 500-MHz or so. Sounds like a >> typical marketing ploy! >> >> About disabling the ACPI... Can I do it *safely* via the remote-ssh >> connection? Or do I need to be at the box w/ keyboard and monitor? >> What I've read makes it seem that the ACPI is set at boot-time. >> > If you don't mind rebooting the remote machine, add: > > hint.acpi.0.disabled="1" > > to /boot/device.hints and reboot Although I've re-booted remotely, I've never done it after a boot modification. It's probably prudent to wait 'til the weekend to try this -- mistakes are easier to deal with! Thanks for the info. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI isn't loaded anymore on boot
On Saturday 22 July 2006 07:24, Frank Steinborn wrote: > Hello, > > after rebuilding a new kernel (though I'm in doubt it has to do with > that), the ACPI module isn't loaded any longer automatically on boot. > If I boot the old GENERIC, it won't load the module either. > > I have no clue at the moment, any hints? :-) > > Thanks in advance, > Frank > ___ i dont know whats causing the problem, but i have a newer hp computer, and my only option to have acpi is to add this to /boot/loader.conf: acpi_load="YES" otherwise, i get the same thing (doesnt work no matter what kernel i load). hth, jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI? problem with release 8.0 | Perhaps solved?
My RELEASE-8.0 has now been up for about 2hr, not long enough to be sure the difficulty is circumvented, but long enough to look promising. Previously RELEASE-8.0 has not stayed up more than about 4min. I tried setting machdep.idle to acpi and then to hlt without success. But I now have set machdep.idle=spin. Discovered there can be some problem in trying to set this too early -- in particular in loader.conf -- presumably because acpi.ko is not yet loaded. I ended up making sure everything was ready by putting: #!/bin/sh echo "setting machdep.idle=spin" /sbin/sysctl machdep.idle=spin in /etc/rc.local To check what is happening I've created /usr/local/bin/sysctldump.sh as: #!/bin/sh [ -f /tmp/sysctl.dump.4 ] && mv -f /tmp/sysctl.dump.4 /tmp/sysctl.dump.5 [ -f /tmp/sysctl.dump.3 ] && mv -f /tmp/sysctl.dump.3 /tmp/sysctl.dump.4 [ -f /tmp/sysctl.dump.2 ] && mv -f /tmp/sysctl.dump.2 /tmp/sysctl.dump.3 [ -f /tmp/sysctl.dump.1 ] && mv -f /tmp/sysctl.dump.1 /tmp/sysctl.dump.2 [ -f /tmp/sysctl.dump ] && mv -f /tmp/sysctl.dump /tmp/sysctl.dump.1 sysctl -ao > /tmp/sysctl.dump and adding: #sysctl dump 1-59/2 * * * * root /usr/local/bin/sysctldump.sh to /etc/crontab. I feel somewhat concerned that this cronjob may be sufficiently frequent to prevent the system looking for the idle state and thus circumventing the problem in same other way. So I'm not yet convinced that I have a real solution. I'll try removing the cronjob. Thanks again for your attention, Regards, Malcolm Kay On Tue, 13 Apr 2010 02:38 pm, Malcolm Kay wrote: > On Tue, 13 Apr 2010 04:03 am, Ian Smith wrote: > > In freebsd-questions Digest, Vol 306, Issue 1, Message: 18 > > > > On Mon, 12 Apr 2010 15:31:33 +0930 Malcolm Kay > > wrote: > > > I desperately need to make some progress on this issue. > > > > Then I suggest taking it to freebsd-acpi@ without passing go > > .. maybe with a bit more data to hand, as outlined in the > > ACPI debugging section of the handbook. > > Yes, I have now realised this; but now somewhat reticent to > move there now and be criticised for cross-posting > > > > Is it likely that the issue is real rather than hardware > > > or disk corruption? Earlier releases are operating OK on > > > the same machine. > > > > Sounds like a real issue, but I don't know the hardware. > > Does it have the latest available BIOS update? If not, > > that's step one. Will it stay up long enough to get a > > verbose dmesg off it? Do you have a verbose dmesg from an > > earlier working release for comparison? > > Probably not; I have considered it. > But the manufacturer's site warns not to upgrade unless you > have identifyable problems (or something similar). > And since earlier release work well I'm not anxious to open a > new can of worms. If I become sufficiently desparate I'll try > it. > > > > I have now confirmed that: > > > debug.acpi.disabled=acad button cpu lid thermal timer > > > video still leaves the system crashing and powering down > > > when idle for a while. And the more extensive: > > > debug.acpi.disabled=acad bus children button cmbat cpu > > > ec isa lid pci pci_link sysresource thermal timer video > > > does the same. > > > > > > I don't really need power management but with acpi > > > disabled the disks are not visible to the system. > > > > ACPI needs to work on modern hardware, no question. > > > > > Are there sysctl variables that can influence this > > > behaviour? Currently I believe we have: > > > > > > hw.acpi.supported_sleep_state: S1 S4 S5 > > > hw.acpi.power_button_state: S5 > > > hw.acpi.sleep_button_state: S1 > > > hw.acpi.lid_switch_state: NONE > > > hw.acpi.standby_state: S1 > > > hw.acpi.suspend_state: NONE > > > hw.acpi.sleep_delay: 1 > > > hw.acpi.s4bios: 0 > > > hw.acpi.verbose: 0 > > > > May help to set hw.acpi.verbose=1 in /boot/loader.conf while > > debugging; especially useful after verbose boot for detail > > in dmesg and messages. > > Looks as though it might be useful, but I'm starting to > believe acpi itself may not be the problem > > > > hw.acpi.disable_on_reboot: 0 > > > hw.acpi.handle_reboot: 0 > > > hw.acpi.reset_video: 0 > > > hw.acpi.cpu.cx_lowest: C1 > > > > Is that with acpi.thermal disabled? > > No, this is run with acpi as default configured. > Boot | login as root | sysctl -a > sysctl.dump | shutdown -p > now (Get out before crash so that I don't get into trouble > with fsck on reboot, yes it runs in the background but takes > forever.) > > Rebooting in FreeBSD 7.0 I can now mount the 8.0 partitions > and look at the dump in my own time -- and also prepare these > emails. (Fsck also runs under 7.0 on the 8.0 partitions if 8.0 > was allowed to crash.) > > > If so, showing hw.acpi > > and debug.acpi with everything enabled might provide more > > clues. > > OK > > > > machdep.idle: amdc1e > > > machdep.idle_available: spin, amdc1e, hlt, acpi, > > > > > > However on the earlier RELEASEs that
Re: ACPI? problem with release 8.0 | Perhaps solved?
On Fri, 16 Apr 2010 17:13:48 +0930, Malcolm Kay wrote: > My RELEASE-8.0 has now been up for about 2hr, not > long enough to be sure the difficulty is circumvented, > but long enough to look promising. Previously RELEASE-8.0 > has not stayed up more than about 4min. Sounds promising .. > I tried setting machdep.idle to acpi and then to hlt without > success. But I now have set machdep.idle=spin. Wow, ok. I only have a vague idea of how these work, but having to change this definitely indicates a bug somewhere; whether your BIOS settings or ACPI implementation or kernel or what else, I've no idea. > Discovered there can be some problem in trying to set this > too early -- in particular in loader.conf -- presumably because > acpi.ko is not yet loaded. I ended up making sure everything was > ready by putting: Don't presume too easily .. acpi.ko gets loaded really early, it's needed fired up even before scanning busses and initialising most devices. A verbose dmesg.boot should give some indication to anyone familiar with what should be. An acpidump may be useful too. Can you put files up anywhere to fetch? If not, you can mail me them, they're each too big to attach to -questions. The usual deal on acpi@ is to put up URL(s) to such files; I'd be happy to host them here. But you really should take this afresh to acpi@ .. they don't bite, the worst that can happen is they'll ignore you :) and with a new message with the concise story to date, I'd expect someone to take an interest; maybe just to say 'turn this off|on' or or 'that was fixed in -stable last month' or 'try this patch' or 'show us your [whatever]' .. >#!/bin/sh >echo "setting machdep.idle=spin" >/sbin/sysctl machdep.idle=spin > in /etc/rc.local Ok. dmesg.boot then will show what happens before that gets switched. If you enable console.log in syslog.conf that change will show up there after boot messages, maybe other useful stuff, but at least show dmesg. > To check what is happening I've created /usr/local/bin/sysctldump.sh as: >#!/bin/sh >[ -f /tmp/sysctl.dump.4 ] && mv -f /tmp/sysctl.dump.4 /tmp/sysctl.dump.5 >[ -f /tmp/sysctl.dump.3 ] && mv -f /tmp/sysctl.dump.3 /tmp/sysctl.dump.4 >[ -f /tmp/sysctl.dump.2 ] && mv -f /tmp/sysctl.dump.2 /tmp/sysctl.dump.3 >[ -f /tmp/sysctl.dump.1 ] && mv -f /tmp/sysctl.dump.1 /tmp/sysctl.dump.2 >[ -f /tmp/sysctl.dump ] && mv -f /tmp/sysctl.dump /tmp/sysctl.dump.1 >sysctl -ao > /tmp/sysctl.dump > and adding: >#sysctl dump >1-59/2 * * * * root /usr/local/bin/sysctldump.sh > to /etc/crontab. sysctl -ao is likely Way Too Much Information, though I suppose diffs between them might show something useful changing over time. 'sysctl hw dev acpi' is probably plenty to chew on. > I feel somewhat concerned that this cronjob may be sufficiently frequent to > prevent the system looking for the idle state and thus circumventing the > problem in same other way. So I'm not yet convinced that I have a real > solution. We're not talking about idle in the sense top shows you - this is about the kernel having nothing to do for perhaps hundreds of microseconds so entering a microsleep state. The old 386s just had the HLT instruction which had the CPU wait for an interrupt (to save power). These days there are multiple C-states with varying levels of power reduction with different latencies, ie times to wake up, usually managed by ACPI. I suspect 'spin' just loops awaiting an interrupt, staying busy? C1E is one such newer state. I know nothing about it, but that's what your system thought it should use the amdc1e cpufreq? driver for, so your problem definitely seems related to that. This clearly is within the ambit of the acpi@ list, and most of those folks seem rarely to have the sort of spare time needed to follow -questions. Also at least check the change log between your BIOS and the latest; if there's anything related to C states or similar, you should try it; they always say not to do it unless you need to - you might need to, and that might be all you need to do. > I'll try removing the cronjob. > > Thanks again for your attention, > Regards, > > Malcolm Kay Thanks for cc'ing me, I read -digests which can take half a day and make replying a bit tedious, not to mention breaking list threading. cheers, Ian [..] ___ 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 HD spin down and CPU sleep
On Tue, Jun 2, 2009 at 11:17 PM, mojo fms wrote: > How would I configure freebsd 7.1 (7.2 upgrade in the future) to sleep the > HD's and maybe sleep the CPU after an idle time out? I am trying to save > power and I would like it to wake on network requests and HD needs. I read > the handbook and looked at the acpiconf man page and such but I have not > seen anything about doing this really. > > Thanks > ataidle in ports for the HDD powerd in base for the CPU (if the CPU supports it) ___ 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 HD spin down and CPU sleep
2009/6/3 Tim Judd : > On Tue, Jun 2, 2009 at 11:17 PM, mojo fms wrote: > >> How would I configure freebsd 7.1 (7.2 upgrade in the future) to sleep the >> HD's and maybe sleep the CPU after an idle time out? I am trying to save >> power and I would like it to wake on network requests and HD needs. I read >> the handbook and looked at the acpiconf man page and such but I have not >> seen anything about doing this really. >> >> Thanks >> > > ataidle in ports for the HDD > > powerd in base for the CPU (if the CPU supports it) Or, for hard drives, I have in my rc.local /sbin/atacontrol spindown ad1 3600 from base system. Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? ___ 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 lock in the last "halt" process
--- bsd <[EMAIL PROTECTED]> wrote: > Hello, > > I have configured with a 6.1 RELEASE FreeBSD. > > When I am trying to shut down the computer - I reach > the prompt - all > processes seems to halt correctly - then the server > seems to be > stucked with the ACPI process indefinitely ?? > > First of all I don't know what ACPI is related to ? > > Second how could I avoid that problem in the future > ? > > > > --- > > Here are the info related to acpi on my dmesg log : > > > acpi_alloc_wakeup_handler: can't alloc wake memory > > acpi0: on motherboard > > acpi0: Power Button (fixed) > > acpi_timer0: <24-bit timer at 3.579545MHz> port > 0x408-0x40b on acpi0 > > cpu0: on acpi0 > > acpi_throttle0: on cpu0 > > cpu1: on acpi0 > > cpu2: on acpi0 > > cpu3: on acpi0 > > pcib0: port 0xcf8-0xcff on > acpi0 > > acpi_button0: on acpi0 > > sio0: <16550A-compatible COM port> port > 0x3f8-0x3ff irq 4 flags > > 0x10 on acpi0 > > atkbdc0: port > 0x60,0x64 irq 1 on acpi0 > > > Thanks. > > > «?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§ > > Gregober ---> PGP ID --> 0x1BA3C2FD > bsd @at@ todoo.biz > > «?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§ > > > P "Please consider your environmental responsibility > before printing > this e-mail" > > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > what kind of computer is this? Do you have the latest BIOS installed on the computer in question? What BIOS version are you using? Did the machine do this on other releases or is this the first FreeBSD it has seen? ACPI is the most current flashier version of APM with some PNP thrown in; in laymens terms... It configures devices, provides power management, and allows the computer to setup hardware so specific versions of windows can or cannot use certain resources on the machine. Sometimes this does cause issues with the non-windows users because devices are left unconfigured or features disabled. Sometimes this leaves the hardcore users rewriting their ACPI to include support for FreeBSD natively or fix the errors that came with the ACPI from the OEM. shutdown puts in a system call to ACPI to shutoff the computer. That is why it matters. It seems like your system should shutdown properly due to the power button fixed line above. At least it not being able to properly shutdown is a known issue with the machine. Does the computer hard lock or do you mean you get stuck at a # prompt but no powerdown? shutdown now will bring you to single user mode shutdown -p now should (only in linux does it not for me...)shutdown the machine. to avoid this problem in the future you should fill in some of these blanks. Describe what: > > When I am trying to shut down the computer - I reach > the prompt - all > processes seems to halt correctly - then the server > seems to be > stucked with the ACPI process indefinitely ?? means exactly. I know its tricky to get verbatium what is going on, but when does it die? I had a dell with this problem, had to update the bios and turn on acpi for it to work right, would only halt the machine for me (shutdown -h now [turns off pc in linux... sorry tux is a new enemy...]) also a uname -a may be a nice thing to include. -brian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI Problem: "acpi_tz0:_TMP value is absurd"
I located a file for upgrading the BIOS for my Compaq machine but it requires Windows to install it. I deleted the Windows that came with the machine several months ago, so, for now, that option is out. I created a file with the following commands: sysctl hw.acpi.thermal.user_override=1 sysctl hw.acpi.thermal.polling_rate=1800 sysctl hw.acpi.thermal.user_override=0 and run it right after logging in as root using: source where is the file name. The message: acpi_tz0: _TMP value is absurd, ignored (-269.8C) still appears, but not as often. I could, of course, adjust it later if temperature might become a problem but, for now, the machine isn't on long enough for that to be a concern. It still doesn't fix the problem of an incorrect temperature, but at least I can read my monitor without it being cluttered with those messages. BMJ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ACPI causing trouble for X in 5.2
Trey Sizemore wrote: >> Jaroslaw Nozderko wrote: >> >>> OS: FreeBSD 5.2-RC2 (MAC - biba,mls) >>> >>> Hi, >>> >>> I have problem with X on 5.2-RC2. Sometimes the whole >>> system hangs when I start X by startx or 'setpmac mls/equal startx' >>> (with MAC policies loaded). In about 30% of attempts it hangs on >>> XFree startup messages and hard reset is required. >>> The problem occurs a little bit too often for some unrelated >>> accident and it doesn't occur at all on 5.1-RELEASE (the same >>> hardware and configuration). >>> >>> Does anyone have similar problem ? >>> >>> Regards, >>> Jarek >>> >>> >>> >> Yes, see my post from earlier today called "Can't shutdown, logout, or >> restart cleanly." I have not run 5.1-RELEASE before, so I can't say >> if it didn't happen there, but it definitely happens with >> 5.2-CURRENT. I'm at my wit's end trying to find out why! >> >Per a post I received on bsdforums.com, try booting up with ACPI turned >off. This can be done in 5.1 and later by choosing option 2 in the >boot >menu (Boot FreeBSD with ACPI disabled). Once I did this, it worked >like >a champ. I'm not sure why earlier versions may not have been affected >by this or if it only affects certain hardware. >Let me know if this worked for you. I have the same problem on two builds of 5.2, one is a Sony Vaio PCG-F360 Laptop (PII 400MHz) and the other is a newer P4 system with Asus mother board. Both worked fine with 5.1 and both broke with 5.2. I was able to work around this problem by booting up with ACPI disabled. Is there a known issue with ACPI that is being worked on for 5.2 or did someone already submit a bug report? Thanks, David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ACPI causing trouble for X in 5.2
On Fri, 16 Jan 2004, David Cramblett wrote: > >>> I have problem with X on 5.2-RC2. Sometimes the whole > >>> system hangs when I start X by startx or 'setpmac mls/equal startx' > >>> (with MAC policies loaded). In about 30% of attempts it hangs on > >>> XFree startup messages and hard reset is required. > >>> The problem occurs a little bit too often for some unrelated > >>> accident and it doesn't occur at all on 5.1-RELEASE (the same > >>> hardware and configuration). > >>> > >>> Does anyone have similar problem ? > >>> > >>> > >> Yes, see my post from earlier today called "Can't shutdown, logout, or > >> restart cleanly." I have not run 5.1-RELEASE before, so I can't say > >> if it didn't happen there, but it definitely happens with > >> 5.2-CURRENT. I'm at my wit's end trying to find out why! > >> > >Per a post I received on bsdforums.com, try booting up with ACPI turned > >off. This can be done in 5.1 and later by choosing option 2 in the >boot > >menu (Boot FreeBSD with ACPI disabled). Once I did this, it worked >like > >a champ. I'm not sure why earlier versions may not have been affected > >by this or if it only affects certain hardware. > > >Let me know if this worked for you. > > I have the same problem on two builds of 5.2, one is a Sony Vaio > PCG-F360 Laptop (PII 400MHz) and the other is a newer P4 system with > Asus mother board. Both worked fine with 5.1 and both broke with 5.2. > I was able to work around this problem by booting up with ACPI disabled. > Is there a known issue with ACPI that is being worked on for 5.2 or > did someone already submit a bug report? Thanks, David I was seeing this on my Dell Latitude notebook from a couple of years ago (C600). I found that the problem "went away" when I switched off either ACPI or device apic, so it looks like it's basically an interrupt problem of some sort. I'm running with the r128 kernel module for DRI, and John Baldwin suggested that it might be part of the problem. I've also been experiencing continuing ATA problems, so it may well be that a combination of ACPI and apic changes has resulted in improper handling/routing/... of interrupts on the box. You might want to check and see if there are any BIOS upgrades available for your system -- as ACPI support evolves, older systems with more questionable ACPI sometimes work less well. A number of vendors have released BIOS updates to address this. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI causing trouble for X in 5.2
Robert Watson wrote: On Fri, 16 Jan 2004, David Cramblett wrote: >>> I have problem with X on 5.2-RC2. Sometimes the whole >>> system hangs when I start X by startx or 'setpmac mls/equal startx' >>> (with MAC policies loaded). In about 30% of attempts it hangs on >>> XFree startup messages and hard reset is required. >>> The problem occurs a little bit too often for some unrelated >>> accident and it doesn't occur at all on 5.1-RELEASE (the same >>> hardware and configuration). >>> >>> Does anyone have similar problem ? >>> >>> >> Yes, see my post from earlier today called "Can't shutdown, logout, or >> restart cleanly." I have not run 5.1-RELEASE before, so I can't say >> if it didn't happen there, but it definitely happens with >> 5.2-CURRENT. I'm at my wit's end trying to find out why! >> >Per a post I received on bsdforums.com, try booting up with ACPI turned >off. This can be done in 5.1 and later by choosing option 2 in the >boot >menu (Boot FreeBSD with ACPI disabled). Once I did this, it worked >like >a champ. I'm not sure why earlier versions may not have been affected >by this or if it only affects certain hardware. >Let me know if this worked for you. I have the same problem on two builds of 5.2, one is a Sony Vaio PCG-F360 Laptop (PII 400MHz) and the other is a newer P4 system with Asus mother board. Both worked fine with 5.1 and both broke with 5.2. I was able to work around this problem by booting up with ACPI disabled. Is there a known issue with ACPI that is being worked on for 5.2 or did someone already submit a bug report? Thanks, David I was seeing this on my Dell Latitude notebook from a couple of years ago (C600). I found that the problem "went away" when I switched off either ACPI or device apic, so it looks like it's basically an interrupt problem of some sort. I'm running with the r128 kernel module for DRI, and John Baldwin suggested that it might be part of the problem. I've also been experiencing continuing ATA problems, so it may well be that a combination of ACPI and apic changes has resulted in improper handling/routing/... of interrupts on the box. You might want to check and see if there are any BIOS upgrades available for your system -- as ACPI support evolves, older systems with more questionable ACPI sometimes work less well. A number of vendors have released BIOS updates to address this. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research Seems kinda strange that it would work fine in 5.1 and then break in 5.2, if it were hardware/bios related. Keep in mind, one of my systems is less than a year old P4 system (you seem to just be referencing my older laptop), so were not just talking about old pre-ACPI hardware/bios either. I may be wrong, but it seems something has changed for ACPI between 5.1 and 5.2, either in the FreeBSD implementation or in the specification that would require a BIOS update on my newer hardware and make the older hardware need it disabled. -- David Cramblett Multnomah Education Service District phn 503-257-1535 fax 503-257-1538 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI causing trouble for X in 5.2
David Cramblett wrote: Robert Watson wrote: On Fri, 16 Jan 2004, David Cramblett wrote: I have problem with X on 5.2-RC2. Sometimes the whole system hangs when I start X by startx or 'setpmac mls/equal startx' (with MAC policies loaded). In about 30% of attempts it hangs on XFree startup messages and hard reset is required. The problem occurs a little bit too often for some unrelated accident and it doesn't occur at all on 5.1-RELEASE (the same hardware and configuration). Does anyone have similar problem ? Yes, see my post from earlier today called "Can't shutdown, logout, or restart cleanly." I have not run 5.1-RELEASE before, so I can't say if it didn't happen there, but it definitely happens with 5.2-CURRENT. I'm at my wit's end trying to find out why! Per a post I received on bsdforums.com, try booting up with ACPI turned off. This can be done in 5.1 and later by choosing option 2 in the >boot menu (Boot FreeBSD with ACPI disabled). Once I did this, it worked >like a champ. I'm not sure why earlier versions may not have been affected by this or if it only affects certain hardware. Let me know if this worked for you. I have the same problem on two builds of 5.2, one is a Sony Vaio PCG-F360 Laptop (PII 400MHz) and the other is a newer P4 system with Asus mother board. Both worked fine with 5.1 and both broke with 5.2. I was able to work around this problem by booting up with ACPI disabled. Is there a known issue with ACPI that is being worked on for 5.2 or did someone already submit a bug report? Thanks, David I was seeing this on my Dell Latitude notebook from a couple of years ago (C600). I found that the problem "went away" when I switched off either ACPI or device apic, so it looks like it's basically an interrupt problem of some sort. I'm running with the r128 kernel module for DRI, and John Baldwin suggested that it might be part of the problem. I've also been experiencing continuing ATA problems, so it may well be that a combination of ACPI and apic changes has resulted in improper handling/routing/... of interrupts on the box. You might want to check and see if there are any BIOS upgrades available for your system -- as ACPI support evolves, older systems with more questionable ACPI sometimes work less well. A number of vendors have released BIOS updates to address this. Seems kinda strange that it would work fine in 5.1 and then break in 5.2, if it were hardware/bios related. Keep in mind, one of my systems is less than a year old P4 system (you seem to just be referencing my older laptop), so were not just talking about old pre-ACPI hardware/bios either. I may be wrong, but it seems something has changed for ACPI between 5.1 and 5.2, either in the FreeBSD implementation or in the specification that would require a BIOS update on my newer hardware and make the older hardware need it disabled. In November John Baldwin changed how interrupts are handled and this shook up ACPI support for a lot of people. I've created the following in an effort to help people sort through the difficulties: http://bis.midco.net/pmes/acpi.html Pete... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI on FreeBSD-4.9-RELEASE, silly question
On Wed, Oct 29, 2003 at 08:23:08PM +0100, Juan Rodriguez Hervella wrote: > I've just added the "device acpica" to my kernel, > and after rebooting it seems to be working well. > > What I haven't found is any tool to use this. I > see that FreeBSD-5.1 has "acpiconf" and > "acpidump", but it seems that FreeBSD-4.9 doesn't > have them. ports: devel/acpicatools should be something that interests you. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: ACPI on FreeBSD-4.9-RELEASE, silly question
On Wednesday 29 October 2003 21:02, Matthew Seaman wrote: > On Wed, Oct 29, 2003 at 08:23:08PM +0100, Juan Rodriguez Hervella wrote: > > I've just added the "device acpica" to my kernel, > > and after rebooting it seems to be working well. > > > > What I haven't found is any tool to use this. I > > see that FreeBSD-5.1 has "acpiconf" and > > "acpidump", but it seems that FreeBSD-4.9 doesn't > > have them. > > ports: devel/acpicatools should be something that interests you. > > Cheers, > > Matthew I've just installed "acpicatools-20030523.0" package using "portinstall" and there are only 2 commands: acpidump acpicadb (this doesn't have man page !!) So... I still don't have "acpiconf" Should I wait until KDE-3.2 ? I've just wanted to test this on my new laptop, but it's not very importantjust I was curious because I don't know what's exactly this stuff of acpi... :) Thanks! -- JFRH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI suspend/resume on RELENG_7 vs. Dell Inspiron XPS
On Tue, Nov 18, 2008 at 02:57:15AM -0600, Scott Bennett wrote: > I have a Dell Inspiron XPS (3.4 GHz P4 Prescott) that will be four years > old in a few more days. Currently, I'm running 6.3 (mostly), but I intend to > install 7.1 once it has been released. One thing that has never worked for me > under FreeBSD on this machine is the standby stuff (suspend/resume, etc.). > Does anyone know whether this will finally work right under RELENG_7 > (especially 7.1-RELEASE)? I'd recommend posting the issue you have to freebsd-acpi. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI CA Embedded Controller (EC) error messages MSI notebook
Pietro Cerutti-4 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Alexander Sack wrote:
> | Hello Folks:
> |
> | I have a MSI-1710A ("Megabook") which is Athlon X2 Turon based
> | notebook (4GB RAM,
> |
> | Anyway during a 7.0-RELEASE-amd64 boot up I see:
> |
> | ACPI Error (evregion-0427): No handler for Region [EC__]
> | (0xff00011cf680) [EmbeddedControl] [20070320]
> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> | ACPI Error (psparse-0626): Method parse/execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (uteval-0309): Method execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (evregion-0427): No handler for Region [EC__]
> | (0xff00011cf680) [EmbeddedControl] [20070320]
> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> | ACPI Error (psparse-0626): Method parse/execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (uteval-0309): Method execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (evregion-0427): No handler for Region [EC__]
> | (0xff00011cf680) [EmbeddedControl] [20070320]
> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> | ACPI Error (psparse-0626): Method parse/execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (uteval-0309): Method execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (evregion-0427): No handler for Region [EC__]
> | (0xff00011cf680) [EmbeddedControl] [20070320]
> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> | ACPI Error (psparse-0626): Method parse/execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (uteval-0309): Method execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (evregion-0427): No handler for Region [EC__]
> | (0xff00011cf680) [EmbeddedControl] [20070320]
> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> | ACPI Error (psparse-0626): Method parse/execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (uteval-0309): Method execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (evregion-0427): No handler for Region [EC__]
> | (0xff00011cf680) [EmbeddedControl] [20070320]
> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> | ACPI Error (psparse-0626): Method parse/execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (uteval-0309): Method execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (evregion-0427): No handler for Region [EC__]
> | (0xff00011cf680) [EmbeddedControl] [20070320]
> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
> [20070320]
> | ACPI Error (psparse-0626): Method parse/execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> | ACPI Error (uteval-0309): Method execution failed
> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
> | AE_NOT_EXIST
> |
> | After looking at my ASL code, I noticed that YES this code was
> | generated by the MSFT devkit which means its probably NOT spec
> | compliant.
> |
> | RSDT: Length=64, Revision=1, Checksum=83,
> | OEMID=MSI_NB, OEM Table ID=MEGABOOK, OEM Revision=0x7000725,
> | Creator ID=MSFT, Creator Revision=0x97
> | Entries={ 0xcffc0200, 0xcffc0390, 0xcffc03f0, 0xcffc0430,
> | 0xcffce040, 0xcffc42f0, 0xcffc4330 }
> |
> | The pertinent section (DSDT) condensed is:
> |
> | _SB.PCI0.SBRG:
> |
> | Device (EC) {
> | Device (BAT1) {
> | Name (_HID, EisaId ("PNP0C0A"))
> | Name (_UID, One)
> | Name (_PCL, Package (0x01)
> | {
> | _SB
> | })
> | Method (_STA, 0, NotSerialized)
> | {
> |If (MYEC)
> |{
> | If (MBTS)
> | {
> | Return (0x1F)
> | }
> | Else
> | {
> | Return (0x0F)
> | }
> |}
> |Else
> |{
> | Return (0x0F)
> |}
> | }
> | }
> |
> | I've read http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html
> | which is very helpful. In any event
Re: ACPI CA Embedded Controller (EC) error messages MSI notebook
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Alexander Sack wrote:
|
|
| Pietro Cerutti-4 wrote:
|> -BEGIN PGP SIGNED MESSAGE-
|> Hash: SHA512
|>
|> Alexander Sack wrote:
|> | Hello Folks:
|> |
|> | I have a MSI-1710A ("Megabook") which is Athlon X2 Turon based
|> | notebook (4GB RAM,
|> |
|> | Anyway during a 7.0-RELEASE-amd64 boot up I see:
|> |
|> | ACPI Error (evregion-0427): No handler for Region [EC__]
|> | (0xff00011cf680) [EmbeddedControl] [20070320]
|> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
|> [20070320]
|> | ACPI Error (psparse-0626): Method parse/execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (uteval-0309): Method execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (evregion-0427): No handler for Region [EC__]
|> | (0xff00011cf680) [EmbeddedControl] [20070320]
|> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
|> [20070320]
|> | ACPI Error (psparse-0626): Method parse/execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (uteval-0309): Method execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (evregion-0427): No handler for Region [EC__]
|> | (0xff00011cf680) [EmbeddedControl] [20070320]
|> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
|> [20070320]
|> | ACPI Error (psparse-0626): Method parse/execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (uteval-0309): Method execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (evregion-0427): No handler for Region [EC__]
|> | (0xff00011cf680) [EmbeddedControl] [20070320]
|> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
|> [20070320]
|> | ACPI Error (psparse-0626): Method parse/execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (uteval-0309): Method execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (evregion-0427): No handler for Region [EC__]
|> | (0xff00011cf680) [EmbeddedControl] [20070320]
|> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
|> [20070320]
|> | ACPI Error (psparse-0626): Method parse/execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (uteval-0309): Method execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (evregion-0427): No handler for Region [EC__]
|> | (0xff00011cf680) [EmbeddedControl] [20070320]
|> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
|> [20070320]
|> | ACPI Error (psparse-0626): Method parse/execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (uteval-0309): Method execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (evregion-0427): No handler for Region [EC__]
|> | (0xff00011cf680) [EmbeddedControl] [20070320]
|> | ACPI Error (exfldio-0390): Region EmbeddedControl(3) has no handler
|> [20070320]
|> | ACPI Error (psparse-0626): Method parse/execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> | ACPI Error (uteval-0309): Method execution failed
|> | [\\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node 0xff00011d24c0),
|> | AE_NOT_EXIST
|> |
|> | After looking at my ASL code, I noticed that YES this code was
|> | generated by the MSFT devkit which means its probably NOT spec
|> | compliant.
|> |
|> | RSDT: Length=64, Revision=1, Checksum=83,
|> | OEMID=MSI_NB, OEM Table ID=MEGABOOK, OEM Revision=0x7000725,
|> | Creator ID=MSFT, Creator Revision=0x97
|> | Entries={ 0xcffc0200, 0xcffc0390, 0xcffc03f0, 0xcffc0430,
|> | 0xcffce040, 0xcffc42f0, 0xcffc4330 }
|> |
|> | The pertinent section (DSDT) condensed is:
|> |
|> | _SB.PCI0.SBRG:
|> |
|> | Device (EC) {
|> | Device (BAT1) {
|> | Name (_HID, EisaId ("PNP0C0A"))
|> | Name (_UID, One)
|> | Name (_PCL, Package (0x01)
|> | {
|> | _SB
|> | })
|> | Method (_STA, 0, NotSerialized)
|> | {
|> |If (MYEC)
|> |{
|> | If (MBTS)
|> | {
|> | Return (0x1F)
|> | }
|> | Else
|> | {
|> | Return (0x0F)
|> | }
|> |}
|> |Else
|> |{
|> |
Re: ACPI CA Embedded Controller (EC) error messages MSI notebook
On Fri, Jun 20, 2008 at 11:37 AM, Pietro Cerutti <[EMAIL PROTECTED]> wrote: > |> I have a MSI-1034 (M662) Core2 Duo. Attached is my (patched) asl. Dunno > |> if it can be of any use for you, though > |> > |> > | > | Thanks Pietro, I really appreciate this. Can I ask by chance, does this > | turn on your battery indicator light on your front panel on your MSI > | notebook? > > This was working anyway, IIRC. Ah yea well mine is now completely off charging or not :(! I thought this could be related to the status handler for the battery but on second thought this maybe something else. > | > | Also, what's the downside of changing ASL? Can I brick my notebook? > I just > | have to ask since I am assuming I will be changing the underlying AML > | generated which I suppose can cause chaos (i.e. I want to make sure I can > | reset it). > > No, it just changes the ACPI code used by the operating system. It > doesn't modify anything in your laptop. If it doesn't work, just disable > it and reboot :) Ah, I got it. I get confused. The ASL is groked by the core CA (which provides the main table API for the kernel). Duh! (my ACPI is rusty) Ok, let me look at it some more and see if I can integrate it in for the battery status section...I'd like to try to get this notebook to be fully functional if possible! -aps ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI CA Embedded Controller (EC) error messages MSI notebook
On Fri, Jun 20, 2008 at 11:46 AM, Alexander Sack <[EMAIL PROTECTED]> wrote: > On Fri, Jun 20, 2008 at 11:37 AM, Pietro Cerutti <[EMAIL PROTECTED]> wrote: >> |> I have a MSI-1034 (M662) Core2 Duo. Attached is my (patched) asl. Dunno >> |> if it can be of any use for you, though >> |> >> |> >> | >> | Thanks Pietro, I really appreciate this. Can I ask by chance, does this >> | turn on your battery indicator light on your front panel on your MSI >> | notebook? >> >> This was working anyway, IIRC. > > Ah yea well mine is now completely off charging or not :(! I > thought this could be related to the status handler for the battery > but on second thought this maybe something else. > >> | >> | Also, what's the downside of changing ASL? Can I brick my notebook? >> I just >> | have to ask since I am assuming I will be changing the underlying AML >> | generated which I suppose can cause chaos (i.e. I want to make sure I can >> | reset it). >> >> No, it just changes the ACPI code used by the operating system. It >> doesn't modify anything in your laptop. If it doesn't work, just disable >> it and reboot :) > > Ah, I got it. I get confused. The ASL is groked by the core CA > (which provides the main table API for the kernel). Duh! (my ACPI is > rusty) > > Ok, let me look at it some more and see if I can integrate it in for > the battery status section...I'd like to try to get this notebook to > be fully functional if possible! Well still no dice and my battery status light remains off. Question, how did you patch this (or where did you get it patched)? The issue is still CA complaining there isn't a handler for the region. -aps ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI temprature settings [WAS: Re: laptop very hot and noisy]
On 08/05/2012 15:06, Anton Shterenlikht wrote: Anyway, this was easier than I expected. I removed a lot of dust from the fan and the heat sink gills. I also replaced the "thermal material". I prop my mine up off the desk to get better airflow to the fan intake which is on the underside. The fan slows down when I lift it up indicating it is moving more air. I rebuilt gcc47 and saw the highest temperature of 75. This is on the southern side, so not too bad. The noise reduced too. Now, I'd just like to understand better the meaning of these console messages: May 8 15:00:08 mech-aslap239 kernel: acpi_tz0: _AC3: temperature 64.0>= setpoint 40.0 May 8 15:00:08 mech-aslap239 kernel: acpi_tz0: _AC2: temperature 64.0>= setpoint 50.0 May 8 15:00:18 mech-aslap239 kernel: acpi_tz0: _AC3: temperature 64.0>= setpoint 40.0 May 8 15:00:18 mech-aslap239 kernel: acpi_tz0: _AC2: temperature 64.0>= setpoint 50.0 May 8 15:00:28 mech-aslap239 kernel: acpi_tz0: _AC3: temperature 64.0>= setpoint 40.0 May 8 15:00:28 mech-aslap239 kernel: acpi_tz0: _AC2: temperature 64.0>= setpoint 50.0 May 8 15:00:38 mech-aslap239 kernel: acpi_tz0: _AC3: temperature 64.0>= setpoint 40.0 May 8 15:00:38 mech-aslap239 kernel: acpi_tz0: _AC2: temperature 64.0>= setpoint 50.0 May 8 15:00:48 mech-aslap239 kernel: acpi_tz0: _AC3: temperature 65.0>= setpoint 40.0 May 8 15:00:48 mech-aslap239 kernel: acpi_tz0: _AC2: temperature 65.0>= setpoint 50.0 Where are setpoints defined? What's acpi_tz? What are AC1, AC2, AC3? Which kernel tunables are involved in the switching from one fan speed to another (assuming AC1, AC2, AC3 are related to fan speed in some way)? I had a quick look at ⌡aacpi(4), but none of the above are mentioned. Many thanks for all your help. Google for "acpi_tz0: _CRT value is absurd, ignored" and you will find a long thread with some hopefully useful pointers. You may need to bone up on the ACPI reference and custom ASL's for FreeBSD. I've forgotten most of it now but I think you will find references for both of them in that thread. 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: bad read from port 0x71:: FreeBSD 6.1 /boot fault (solution)
On Wed, Sep 06, 2006 at 07:30:05PM -0700, Gary Kline wrote: > Does anybody know what to tweak in /boot/* to stop > "bad read/write" messages from/to the BIOS? [At least > so fare as I can tell? > > I've triied everything suggested on Google; rebooted, no-joy. > The BIOS is reset (AFAICT) to their fail-safe defaults, but > every 10 sec these errs get printed to stderr. > > I'd like to know what ... and *why* with 6.1, just out of the > blue! > I'm replying to my own post for anyone who runs into this problem and finds this in an archive. The solution is to take a clue from /boot/loader.help and drop hint.acpi.0.disable="1" into /boot/device.hints. reboot, and errors should disappear. Why this began with FBSD 6.1? No idea. -- Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI errors at bit on Abit BP-6 mb (since 5.1) on 5.2RC
Chad Leigh -- Shire.Net LLC wrote: Hi. I have been getting these errors at boot time on a dual CPU Abit BP-6. This has been happening since I converted this old system into a test system a while back with 5.1R. It still happens with 5.2RC. I have not updated to 5.2R yet. It still seems to run fine and stably even with the errors. What do these mean? Here is a dmesg Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.2-RC #1: Thu Jan 8 09:59:56 MST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NABIKI-SMP [dmesg snipped] Mounting root from ufs:/dev/ad0s1a ACPI-0438: *** Error: Looking up [\\_PR_.CPU0] in namespace, AE_NOT_FOUND SearchNode 0xc54fd260 StartNode 0xc54fd260 ReturnNode 0 ACPI-1287: *** Error: , AE_NOT_FOUND ACPI-0438: *** Error: Looking up [\\_PR_.CPU0] in namespace, AE_NOT_FOUND SearchNode 0xc54fd260 StartNode 0xc54fd260 ReturnNode 0 ACPI-1287: *** Error: , AE_NOT_FOUND I installed and ran fbsd 5.1 and current for a bit on a BP6, dual Cel-366. Only problems I came across were: 1. Flash the board to the lastest/BIOS. This had cured a few issues when it was running Linux SMP previously. 2. Enable the Intel MP spec in BIOS, 1.4 if available (no longer have the system so can't verify, but I believe it's a BIOS option even on the BP-6) 3. If you're overclocking it, go back to the normal speed at least for the install. I hadn't reloaded that system in so long I forgot they were 366MHz CPUs (they were overclocked to somewhere ~450MHz), and ran into all kinds of problems until I checked and then reset it back to the default...which was interesting, as the system had been successfully running Oracle on RH7.3 for some time previously in the same configuration... Definitely never saw any similar messages as yours, but there's also a BP-6 motherboard issue some have come across- try googling for "BP-6 problem" if all else fails, something about a (filtering?) cap being the wrong size... Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI can only be compiled into the kernel on the amd64 and ia64 platforms
anyone? On Wed, Apr 30, 2008 at 5:23 PM, alexus <[EMAIL PROTECTED]> wrote: > dd# make cleandepend && make depend > rm -f .depend machine amd64 > cd ../../../modules; > MAKEOBJDIRPREFIX=/usr/src/sys/i386/compile/dd/modules > KMODDIR=/boot/kernel DEBUG_FLAGS="-g" MACHINE=i386 > KERNBUILDDIR="/usr/src/sys/i386/compile/dd" make cleandepend > ===> aac (cleandepend) > rm -f @ machine amd64 > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> accf_data (cleandepend) > rm -f @ machine amd64 > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> accf_http (cleandepend) > rm -f @ machine amd64 > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> acpi (cleandepend) > ===> acpi/acpi (cleandepend) > "Makefile", line 4: "ACPI can only be compiled into the kernel on the > amd64 and ia64 platforms" > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/src/sys/i386/compile/dd. > dd# > > I took GENERIC and rewise it a little bit > > -- > http://alexus.org/ > -- http://alexus.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI can only be compiled into the kernel on the amd64 and ia64 platforms
On Wednesday 30 April 2008 23:23:27 alexus wrote: > dd# make cleandepend && make depend > rm -f .depend machine amd64 > cd ../../../modules; > MAKEOBJDIRPREFIX=/usr/src/sys/i386/compile/dd/modules > KMODDIR=/boot/kernel DEBUG_FLAGS="-g" MACHINE=i386 > KERNBUILDDIR="/usr/src/sys/i386/compile/dd" make cleandepend > ===> aac (cleandepend) > rm -f @ machine amd64 > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> accf_data (cleandepend) > rm -f @ machine amd64 > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> accf_http (cleandepend) > rm -f @ machine amd64 > rm -f .depend GPATH GRTAGS GSYMS GTAGS > ===> acpi (cleandepend) > ===> acpi/acpi (cleandepend) > "Makefile", line 4: "ACPI can only be compiled into the kernel on the > amd64 and ia64 platforms" > *** Error code 1 > > Stop in /usr/src/sys/modules/acpi. > *** Error code 1 > > Stop in /usr/src/sys/modules. > *** Error code 1 > > Stop in /usr/src/sys/i386/compile/dd. > dd# > > I took GENERIC and rewise it a little bit You removed device acpi and shouldn't have done that. Also, your build system looks weird. What is compile/dd, why are you compiling under i386 when your system is detected as amd64 or ia64, why is MAKEOBJDIRPREFIX pointing to a directory below the source tree, rather then a directory outside the source tree. In other words, not enough info (aside from the missing question). -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI can only be compiled into the kernel on the amd64 and ia64 platforms
like i said i copy GENERIC dd# pwd /usr/src/sys/i386/conf dd# grep -i acpi GENERIC dd# my GENERIC doesn't have acpi either... as far as "weird" part goes, this is a plain vanila FreeBSD-7.0-RELEASE, I'm not sure what you mean by "weird" or i386 part, all I did is cp GENERIC dd then vi dd, then config dd and then tried compiling and it threw me an error right away. On Thu, May 1, 2008 at 5:34 PM, Mel <[EMAIL PROTECTED]> wrote: > > On Wednesday 30 April 2008 23:23:27 alexus wrote: > > dd# make cleandepend && make depend > > rm -f .depend machine amd64 > > cd ../../../modules; > > MAKEOBJDIRPREFIX=/usr/src/sys/i386/compile/dd/modules > > KMODDIR=/boot/kernel DEBUG_FLAGS="-g" MACHINE=i386 > > KERNBUILDDIR="/usr/src/sys/i386/compile/dd" make cleandepend > > ===> aac (cleandepend) > > rm -f @ machine amd64 > > rm -f .depend GPATH GRTAGS GSYMS GTAGS > > ===> accf_data (cleandepend) > > rm -f @ machine amd64 > > rm -f .depend GPATH GRTAGS GSYMS GTAGS > > ===> accf_http (cleandepend) > > rm -f @ machine amd64 > > rm -f .depend GPATH GRTAGS GSYMS GTAGS > > ===> acpi (cleandepend) > > ===> acpi/acpi (cleandepend) > > "Makefile", line 4: "ACPI can only be compiled into the kernel on the > > amd64 and ia64 platforms" > > *** Error code 1 > > > > Stop in /usr/src/sys/modules/acpi. > > *** Error code 1 > > > > Stop in /usr/src/sys/modules. > > *** Error code 1 > > > > Stop in /usr/src/sys/i386/compile/dd. > > dd# > > > > I took GENERIC and rewise it a little bit > > You removed device acpi and shouldn't have done that. > Also, your build system looks weird. > What is compile/dd, why are you compiling under i386 when your system is > detected as amd64 or ia64, why is MAKEOBJDIRPREFIX pointing to a directory > below the source tree, rather then a directory outside the source tree. > In other words, not enough info (aside from the missing question). > > -- > Mel > > Problem with today's modular software: they start with the modules > and never get to the software part. > -- http://alexus.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI can only be compiled into the kernel on the amd64 and ia64 platforms
On Thursday 01 May 2008 23:43:17 alexus wrote: > like i said i copy GENERIC > > dd# pwd > /usr/src/sys/i386/conf > dd# grep -i acpi GENERIC > dd# > > my GENERIC doesn't have acpi either... > > as far as "weird" part goes, this is a plain vanila > FreeBSD-7.0-RELEASE, I'm not sure what you mean by "weird" or i386 > part, all I did is cp GENERIC dd then vi dd, then config dd and then > tried compiling and it threw me an error right away. Ah, the old config way. Better to use buildkernel target in /usr/src. What's your uname -m? -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI can only be compiled into the kernel on the amd64 and ia64 platforms
On Thursday 01 May 2008 18:43:17 alexus wrote: >> why are you compiling under i386 when your system is >> detected as amd64 or ia64 ? You didn't answer this one. uname -a can help. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio YET!!] (99,7% winedows FREE) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI can only be compiled into the kernel on the amd64 and ia64 platforms
sorry, this is amd64 On Thu, May 1, 2008 at 6:14 PM, Mario Lobo <[EMAIL PROTECTED]> wrote: > On Thursday 01 May 2008 18:43:17 alexus wrote: > >> why are you compiling under i386 when your system is > >> detected as amd64 or ia64 ? > > You didn't answer this one. > > uname -a can help. > -- > Mario Lobo > http://www.mallavoodoo.com.br > FreeBSD since version 2.2.8 [not Pro-Audio YET!!] (99,7% winedows FREE) > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- http://alexus.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI can only be compiled into the kernel on the amd64 and ia64 platforms
On Thursday 01 May 2008 20:41:49 alexus wrote: > sorry, this is amd64 > > On Thu, May 1, 2008 at 6:14 PM, Mario Lobo <[EMAIL PROTECTED]> wrote: > > On Thursday 01 May 2008 18:43:17 alexus wrote: > > >> why are you compiling under i386 when your system is > > >> detected as amd64 or ia64 ? > > > > You didn't answer this one. > > > > uname -a can help. > > -- > > Mario Lobo > > http://www.mallavoodoo.com.br > > FreeBSD since version 2.2.8 [not Pro-Audio YET!!] (99,7% winedows > > FREE) ___ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to > > "[EMAIL PROTECTED]" Then you should: cd /usr/src/sys/amd64/conf copy/edit GENERIC dd /usr/sbin/config dd cd ../compile/dd make cleandepend;make depend;make;make make install this should work -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio YET!!] (99,7% winedows FREE) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
