Re: with ACPI=on, 9.1-RELEASE shutdown automatically
On Fri, May 10, 2013 at 01:03:45PM +0200, Eduardo Morras wrote: Hi Eduardo, On Fri, 10 May 2013 12:34:14 +0200 Xavier xavierfreebsdquesti...@gmail.com wrote: Hi to all, About this email subject, on acer Aspire 5634WLMi machine and 9.1-RELEASE OS, FreeBSD shutdown the machine automatically in few minuts. In freebsd-es a similar problem was reported some months ago. The cause is fan switch off after startup menu and rising temperature. It looks like ec controller problem (Acer doesn't provide documentation about Embedded Controller, all is done by try and error and can damage the laptop) Yes, is the same situation. I don't solved the problem. For this reason I post here now. And, I wait a long time for try new situations and not crossposting the problem in other mailing list. How can I debug the reason of the problem ? A not so good wokaround is down the temperature where cpu Hz is adjusted: #sysctl hw.acpi.thermal.user_override=1 #sysctl hw.acpi.thermal.tz0._PSV=65C #sysctl hw.acpi.thermal.user_override=0 First of all, I load the correct ACPI mapping driver for acer laptops ( this situation ): acpi_wmi(4) root@casa:/root # kldstat | grep acpi 41 0xc13dd000 462c acpi_wmi.ko root@casa:/root # Now I try yours values: First, de defaults values: root@casa:/root # sysctl -a | grep hw.acpi.thermal.user_override hw.acpi.thermal.user_override: 0 root@casa:/root # sysctl -a | grep hw.acpi.thermal.tz0._PSV hw.acpi.thermal.tz0._PSV: -1 root@casa:/root # sysctl -a | grep hw.acpi.thermal.tz1._PSV hw.acpi.thermal.tz1._PSV: 95,0C root@casa:/root # sysctl -a | grep hw.acpi.thermal.user_override hw.acpi.thermal.user_override: 0 root@casa:/root # I change to your suggerations: root@casa:/root # sysctl hw.acpi.thermal.user_override=1 hw.acpi.thermal.user_override: 0 - 1 root@casa:/root # sysctl hw.acpi.thermal.tz0._PSV=65C hw.acpi.thermal.tz0._PSV: -1 - 65,0C root@casa:/root # sysctl hw.acpi.thermal.tz1._PSV=65C hw.acpi.thermal.tz1._PSV: 95,0C - 65,0C root@casa:/root # sysctl -a | grep hw.acpi.thermal.user_override hw.acpi.thermal.user_override: 1 root@casa:/root # sysctl -a | grep hw.acpi.thermal.tz0._PSV hw.acpi.thermal.tz0._PSV: 65,0C root@casa:/root # sysctl -a | grep hw.acpi.thermal.tz1._PSV hw.acpi.thermal.tz1._PSV: 65,0C root@casa:/root # I look for the temperature at the moment: root@casa:/root # sysctl -a | grep temperature acpi_tz1: temperature 67.0C: decreasing clock speed from 500 MHz to 250 MHz acpi_tz1: temperature 67.0C: decreasing clock speed from 250 MHz to 125 MHz hw.acpi.thermal.tz0.temperature: 73,0C hw.acpi.thermal.tz1.temperature: 72,0C dev.cpu.0.temperature: 75,0C dev.cpu.1.temperature: 75,0C root@casa:/root # I try compile one port ... : ... while compile I look the temperature: root@casa:/root # sysctl -a | grep temperature acpi_tz1: temperature 67.0C: decreasing clock speed from 500 MHz to 250 MHz acpi_tz1: temperature 67.0C: decreasing clock speed from 250 MHz to 125 MHz hw.acpi.thermal.tz0.temperature: 95,0C hw.acpi.thermal.tz1.temperature: 94,0C dev.cpu.0.temperature: 92,0C dev.cpu.1.temperature: 92,0C root@casa:/root # I break the compilation because if hw.acpi.thermal.tz%d.temperature ( of ACPI_THERMAL(4) ) = 100C the FreeBSD shutdown automacally. Or downgrade to 8.x On 8.x I get the same problem. Thanks, see you. ___ 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
with ACPI=on, 9.1-RELEASE shutdown automatically
Hi to all, About this email subject, on acer Aspire 5634WLMi machine and 9.1-RELEASE OS, FreeBSD shutdown the machine automatically in few minuts. How can I debug the reason of the problem ? Thanks, see you ! ___ 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: with ACPI=on, 9.1-RELEASE shutdown automatically
On Fri, 10 May 2013 12:34:14 +0200 Xavier xavierfreebsdquesti...@gmail.com wrote: Hi to all, About this email subject, on acer Aspire 5634WLMi machine and 9.1-RELEASE OS, FreeBSD shutdown the machine automatically in few minuts. In freebsd-es a similar problem was reported some months ago. The cause is fan switch off after startup menu and rising temperature. It looks like ec controller problem (Acer doesn't provide documentation about Embedded Controller, all is done by try and error and can damage the laptop) How can I debug the reason of the problem ? A not so good wokaround is down the temperature where cpu Hz is adjusted: #sysctl hw.acpi.thermal.user_override=1 #sysctl hw.acpi.thermal.tz0._PSV=65C #sysctl hw.acpi.thermal.user_override=0 Or downgrade to 8.x Thanks, see you ! ___ 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 --- --- Eduardo Morras emorr...@yahoo.es ___ 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
Acpi suspend - screen does not wake up
Hi, I have recently installed freebsd-9.1RC on my thinkpad t420i laptop and I have run into some problems regarding acpi suspend/resume. When I run # acpiconf -s 3 Computer seem to suspend correctly, but when I wake it up, laptop seems to resume correctly except the screen stays dark. I have made dmesg dump after boot with verbose booting: http://files.farka.eu/pub/fari-tpt420i.dmesg and acpidump: http://files.farka.eu/pub/fari-tpt420i.asl I tried to boot without acpi, but the system did not boot at all. I have also tried suspend with # sysctl debug.acpi.suspend_bounce=1 and this is a resulting dmesg during suspend: http://files.farka.eu/pub/fari-tpt420i.suspend I haven't found any problem connected to LCD/screen or something like that. Do you have any idea what to do in order to make suspend/resume working? Thanks Frantisek Farka ___ 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
9.0 w/ACPI enabled, excluding NICs
Hi, I am running a small personal file server. To ensure constant network access, had to disable the ACPI, hence no power saving at all. The CPU gets very warm as everything (presumably) is running at full throttle. Is there any way to disable the ACPI partially, i.e. allow spin-down for disks etc, but keep the NICs running? Hope that this question was understandable. Thanks. Regards, Ronny Mandal ___ 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: 9.0 w/ACPI enabled, excluding NICs
I am running a small personal file server. To ensure constant network access, had to disable the ACPI, hence no power saving at all. The CPU why you had to disable ACPI. i never ever seen network problems with ACPI. basically it works, or it doesn't at all. gets very warm as everything (presumably) is running at full throttle. Is there any way to disable the ACPI partially, i.e. allow spin-down for disks etc, but keep the NICs running? This is IMHO not about FreeBSD support of ACPI but possible BIOS settings that turn on some kind of hibernation. Hope that this question was understandable. Thanks. Regards, Ronny Mandal ___ 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: 9.0 w/ACPI enabled, excluding NICs
On 13.07.2012 15:52, Wojciech Puchar wrote: I am running a small personal file server. To ensure constant network access, had to disable the ACPI, hence no power saving at all. The CPU why you had to disable ACPI. i never ever seen network problems with ACPI. basically it works, or it doesn't at all. When the server is idle with ACPI enabled, it did not respond to ping after a short period. With ACPI disabled, this was alleviated. So, basically, it will stop working after a while. My guess is that ACPI will shut down the power for the NIC. But that is only a guess. Furthermore, when ACPI is disabled, no network problem arises. This suggests, at least to me, that ACPI is somehow involved. gets very warm as everything (presumably) is running at full throttle. Is there any way to disable the ACPI partially, i.e. allow spin-down for disks etc, but keep the NICs running? This is IMHO not about FreeBSD support of ACPI but possible BIOS settings that turn on some kind of hibernation. Each and every power saving function in the BIOS is disabled. Nevertheless, I believe that a selective ACPI configuration should resolve this issue, Hope that this question was understandable. Thanks. Regards, Ronny Mandal ___ 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: 9.0 w/ACPI enabled, excluding NICs
On Jul 13, 2012 8:34 AM, Ronny Mandal ronn...@volatile.no wrote: On 13.07.2012 15:52, Wojciech Puchar wrote: I am running a small personal file server. To ensure constant network access, had to disable the ACPI, hence no power saving at all. The CPU why you had to disable ACPI. i never ever seen network problems with ACPI. basically it works, or it doesn't at all. When the server is idle with ACPI enabled, it did not respond to ping after a short period. With ACPI disabled, this was alleviated. So, basically, it will stop working after a while. My guess is that ACPI will shut down the power for the NIC. But that is only a guess. Furthermore, when ACPI is disabled, no network problem arises. This suggests, at least to me, that ACPI is somehow involved. gets very warm as everything (presumably) is running at full throttle. Is there any way to disable the ACPI partially, i.e. allow spin-down for disks etc, but keep the NICs running? This is IMHO not about FreeBSD support of ACPI but possible BIOS settings that turn on some kind of hibernation. Each and every power saving function in the BIOS is disabled. Nevertheless, I believe that a selective ACPI configuration should resolve this issue, Hope that this question was understandable. Thanks. Regards, Ronny Mandal ___ 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 A «band-aid» type fix could be to ping gw (once) using cron 0-59/5 or something Waitman Gobble San Jose California ___ 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
Issuing ACPI calls or Nvidia Optimus support
Hello. I have an Asus U36JC laptop which has two graphic cards (NVIDIA Optimus technology): an Intel integrated card and GeForce 310M. To save power on Linux I use acpi_call module to disable nvidia card completely. This acpi_call module (https://github.com/mkottman/acpi_call) enables an interface to pass ACPI methods. Then when I issue echo '\_SB.PCI0.PEG1.GFX0._OFF' /proc/acpi/call I'm disabling the nvidia card. Is something like that possible with FreeBSD? I'd like to use it on my laptop, but unfortunately it gets too hot when both Intel and Nvidia card are powered on. Are there any plans on supporting nvidia optimus? Or at least an option to disable the nvidia card and use the intel one? Regards, -- Bartek Krawczyk ___ 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 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: Kernel stalling at pci0: ACPI bus on pcib0
Hi, On Tuesday 07 February 2012 12:49:46 Da Rock wrote: On 02/07/12 15:48, Erich Dollansky wrote: On Tuesday 07 February 2012 12:40:09 Will McCutcheon wrote: Hello all, I recently got a HP t5700 thin client that I wanted to turn into a firewall using pfSense. For reference, this system uses a Transmeta Crusoe TM5800 CPU with a VIA chipset that I'm having difficulty identifying. My issue is that about half of the time the kernel will stall during startup after the following: this reminds me of my notebook with the same Crusoe CPU. I have had to leave it with 7.x as newer version gave problems. The problems have been different but it looked like some driver could not handle the peripherals properly. It booted but was unusable. I never tried 9 on it. Maybe try hackers@? I think that it is a waste of resources to make new versions of FreeBSD work with old hardware as long as a supported version is available for it. Erich ___ 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
Kernel stalling at pci0: ACPI bus on pcib0
Hello all, I recently got a HP t5700 thin client that I wanted to turn into a firewall using pfSense. For reference, this system uses a Transmeta Crusoe TM5800 CPU with a VIA chipset that I'm having difficulty identifying. My issue is that about half of the time the kernel will stall during startup after the following: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/CENERIC i386 CPU: Transmeta(tm) Crusoe(tm) Processor TM5800 (997.69-MHz 586-class CPU) Origin = CenuineTMx86 Id = 0x543 Family = 5 Model = 4 Stepping = 3 Features= 0x84893fFPU,VME,DE,PSE,TSC,MSR,CX8,SEP,CMOV,PN,MMX real memory = 270532608 (258 MB) avail memory = 226930688 (216 MB) kbd1 at kbdmux0 acpi0: I-BASE AWRDACPI on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, eef (3) failed acpi_timer0: couldn't allocate resource (port 0x4008) cpu0: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port Oxcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x500 0-0x500f on acpi0 pcib0: Length mismatch for 4 range: f00 vs eff pcib0: Length mismatch for 4 range: aff0 vs afef pciO: ACPI PCI bus on pcib0 If I power the system off and on again there's about a 50/50 chance it will start up properly, whereupon it will run for days without issue. It's just during startup that I see any problems. I've tried two separate systems of the same model but they both exhibit the same issue, thus suggesting it's not a one-off hardware defect. I tried both pfSense 2.0.1 (which is FreeBSD 8.1-based) and FreeBSD 9.0-RELEASE from a USB stick, but they exhibited the same issue. I do see some acpi0 and pcib0 messages in there that seem possibly problematic, but I'm a bit out of my depth here. Could anyone spare a moment to suggest any further troubleshooting steps I might try? Thanks so much for your time! Will ___ 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: Kernel stalling at pci0: ACPI bus on pcib0
Hi, On Tuesday 07 February 2012 12:40:09 Will McCutcheon wrote: Hello all, I recently got a HP t5700 thin client that I wanted to turn into a firewall using pfSense. For reference, this system uses a Transmeta Crusoe TM5800 CPU with a VIA chipset that I'm having difficulty identifying. My issue is that about half of the time the kernel will stall during startup after the following: this reminds me of my notebook with the same Crusoe CPU. I have had to leave it with 7.x as newer version gave problems. The problems have been different but it looked like some driver could not handle the peripherals properly. It booted but was unusable. I never tried 9 on it. Erich ___ 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: Kernel stalling at pci0: ACPI bus on pcib0
On 02/07/12 15:48, Erich Dollansky wrote: Hi, On Tuesday 07 February 2012 12:40:09 Will McCutcheon wrote: Hello all, I recently got a HP t5700 thin client that I wanted to turn into a firewall using pfSense. For reference, this system uses a Transmeta Crusoe TM5800 CPU with a VIA chipset that I'm having difficulty identifying. My issue is that about half of the time the kernel will stall during startup after the following: this reminds me of my notebook with the same Crusoe CPU. I have had to leave it with 7.x as newer version gave problems. The problems have been different but it looked like some driver could not handle the peripherals properly. It booted but was unusable. I never tried 9 on it. Maybe try hackers@? ___ 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
acpi problem on dell latitude d830
Hello, I'm still investigating the problem with my dell latitude d830 notebook. ACPI states S3 and S4 don't work... Here comes dmesg: xueyu@monopohl:~% dmesg Copyright (c) 1992-2011 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #2: Wed Dec 14 03:15:04 CET 2011 root@:/usr/obj/usr/src/sys/MONOPOHL i386 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1994.44-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2081214464 (1984 MB) ACPI APIC Table: DELL M08 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: DELL M08 on motherboard acpi0: [ITHREAD] Timecounter HPET frequency 14318180 Hz quality 900 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, 7f55b800 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xefe8-0xefef mem 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0 agp0: Intel GM965 SVGA controller on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory vgapci1: VGA-compatible display mem 0xfeb0-0xfebf at device 2.1 on pci0 uhci0: Intel 82801H (ICH8) USB controller USB-D port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 uhci0: [ITHREAD] usbus0: Intel 82801H (ICH8) USB controller USB-D on uhci0 uhci1: Intel 82801H (ICH8) USB controller USB-E port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] usbus1: Intel 82801H (ICH8) USB controller USB-E on uhci1 ehci0: Intel 82801H (ICH8) USB 2.0 controller USB2-B mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: Intel 82801H (ICH8) USB 2.0 controller USB2-B on ehci0 hdac0: Intel 82801H High Definition Audio Controller mem 0xfe9fc000-0xfe9f irq 21 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib1: ACPI PCI-PCI bridge at device 28.0 on pci0 pci11: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 28.1 on pci0 pci12: ACPI PCI bus on pcib2 wpi0: Intel(R) PRO/Wireless 3945ABG mem 0xfe8ff000-0xfe8f irq 17 at device 0.0 on pci12 wpi0: [ITHREAD] pcib3: ACPI PCI-PCI bridge at device 28.3 on pci0 pci13: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 28.5 on pci0 pci9: ACPI PCI bus on pcib4 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x00a002 mem 0xfe5f-0xfe5f irq 17 at device 0.0 on pci9 bge0: CHIP ID 0xa002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5755 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: [FILTER] uhci2: Intel 82801H (ICH8) USB controller USB-A port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 uhci2: [ITHREAD] usbus3: Intel 82801H (ICH8) USB controller USB-A on uhci2 uhci3: Intel 82801H (ICH8) USB controller USB-B port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 uhci3: [ITHREAD] usbus4: Intel 82801H (ICH8) USB controller USB-B on uhci3 uhci4: Intel 82801H (ICH8) USB controller USB-C port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 uhci4: [ITHREAD] usbus5: Intel 82801H (ICH8) USB controller USB-C on uhci4 ehci1: Intel 82801H (ICH8) USB 2.0 controller USB2-A mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: Intel 82801H (ICH8) USB 2.0 controller USB2-A on ehci1 pcib5: ACPI PCI-PCI bridge at device 30.0 on pci0 pci3: ACPI PCI bus on pcib5 cbb0: PCI-CardBus Bridge at device 1.0 on pci3 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb0: [FILTER] fwohci0: 1394 Open Host Controller Interface mem 0xfe4ff000-0xfe4f,0xfe4fe800-0xfe4fefff irq 19 at device 1.4 on pci3 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 35:4f:c0:00:0b:25:ec:70 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes
Re: acpi problem on dell latitude d830
Ouyang Xueyu free...@suiyuan.de 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
acpi problem on dell latitude d830
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 also want to use the docking station. I would like to use the hot-docking functionality. The docking station has a power switch, which functions properly. It also has an undocking-button, which causes a freeze of the system. The audio-out on the docking-station is also not working. PS/2 keyboard, ethernet and USB on the docking-station is working. My kernel was compiled with acpi_dock. dmesg says: acpi_dock0: ACPI Docking Station on acpi0 acpi_dock0: _DCK failed Xueyu ___ 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
How to remove ACPI from boot ?
Aloha, I have a box that wont shut down with ACPI setting activated. Anyone point me to a how to on keeping ACPI from being set to on at boot. Thanks . ## Please copy me directly as I cant get messages on the list for some reason. Any one know who I can email about whats blocking the FreeBSD list? ## ~Al Plant - Honolulu, Hawaii - Phone: 808-284-2740 + http://hawaiidakine.com + http://freebsdinfo.org + + http://aloha50.net - Supporting - FreeBSD 7.2 - 8.0 - 9* + email: n...@hdk5.net All that's really worth doing is what we do for others.- Lewis Carrol ___ 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: How to remove ACPI from boot ?
in /boot/loader.conf (see /boot/defaults/loader.conf) acpi_load=NO On Wed, Nov 2, 2011 at 3:11 PM, Al Plant n...@hdk5.net wrote: Aloha, I have a box that wont shut down with ACPI setting activated. Anyone point me to a how to on keeping ACPI from being set to on at boot. Thanks . ## Please copy me directly as I cant get messages on the list for some reason. Any one know who I can email about whats blocking the FreeBSD list? ## ~Al Plant - Honolulu, Hawaii - Phone: 808-284-2740 + http://hawaiidakine.com + http://freebsdinfo.org + + http://aloha50.net - Supporting - FreeBSD 7.2 - 8.0 - 9* + email: n...@hdk5.net All that's really worth doing is what we do for others.- Lewis Carrol ___ 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
mail list debug - Was Re: How to remove ACPI from boot ?
Al Plant wrote: ## Please copy me directly as I cant get messages on the list for some reason. Any one know who I can email about whats blocking the FreeBSD list? ## It's downstream from freebsd.org toward you then, so suggestions: 1) Ask your own postmas...@hdk5.net Point them at eg http://lists.freebsd.org/pipermail/freebsd-questions/2011-November/234989.html Which proves everyone else is getting your mail that you are not. 2) We have a test list you / your postmaster@ can subscribe to send test messages: http://lists.freebsd.org/mailman/listinfo/freebsd-test 3) Subscribe from some other domain 4) If postmas...@freebsd.org has time to answer a request from you, he might be able to tell you if mail to your subscribed address might be part of a block forwarding to another SMTP relay ( your recipient SMTP might have that relay blocked ? Remember to declare if eg you might be receiving Elsewhere@ forwarding to @hdk5.net, perhaps with a 2nd subscribtion of @hdk5.net for outgoing, in that case the Elsewhere might have falsely black listed @freebsd.org (or a downstream relay) as eg a spammer (innocent domains occasionaly accidentaly /or maliciously get listed as spam domains) 5) Ask your postmaster@ if freebsd.org or any intermediate relay (See #4) Might be listed in the RBL (Automated Domain Spam Black Lists) that about a dozen different organsiations offer)Ref http://en.wikipedia.org/wiki/DNSBL Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with ; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ 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: How to remove ACPI from boot ?
Le Wed, 02 Nov 2011 12:11:19 -1000, Al Plant n...@hdk5.net a écrit : Aloha, Bonjour, I have a box that wont shut down with ACPI setting activated. Anyone point me to a how to on keeping ACPI from being set to on at boot. in /boot/loader.conf hint.acpi.0.disabled=1 man acpi (DISABLING ACPI) Regards. ___ 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: How to remove ACPI from boot ?
Le Wed, 2 Nov 2011 15:15:43 -0700, Michael Sierchio ku...@tenebras.com a écrit : in /boot/loader.conf (see /boot/defaults/loader.conf) acpi_load=NO Not useful since acpi is built by default in the kernel GENERIC. Regards. ___ 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: How to remove ACPI from boot ?
Patrick Lamaiziere wrote: Le Wed, 02 Nov 2011 12:11:19 -1000, Al Plant n...@hdk5.net a écrit : Aloha, Bonjour, I have a box that wont shut down with ACPI setting activated. Anyone point me to a how to on keeping ACPI from being set to on at boot. in /boot/loader.conf hint.acpi.0.disabled=1 man acpi (DISABLING ACPI) Regards. Aloha, That worked. Merci ~Al Plant - Honolulu, Hawaii - Phone: 808-284-2740 + http://hawaiidakine.com + http://freebsdinfo.org + + http://aloha50.net - Supporting - FreeBSD 7.2 - 8.0 - 9* + email: n...@hdk5.net All that's really worth doing is what we do for others.- Lewis Carrol ___ 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
ACPI error message
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: INSYDE RSDT_000 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 Regards. -- Davide Petili - k3rn31 Potenza, Italy FreeBSD, Mac OSX, GNU/Debian, GNU/Hurd. 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 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: INSYDE RSDT_000 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
ACPI Warning: 32/64X FACS address mismatch in FADT
I have an INTEL DP43TF motherboad with an Intel Core 2 Quad. (non-HTT) When I boot up Freebsd 8.1 I see a message like this: ACPI Warning: 32/64X FACS address mismatch in FADT..(blah)..using 32 I cant determine if this is OK and a cosmetic type of message or something more serious to question. Google turned up several hits but nothing explains what this is and/or the importance of it. Thanks, -- J.D. Bronson ___ 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: VIA EPIA 5000 and ACPI Cx levels
On 10/10/10, Bruce Cran br...@cran.org.uk wrote: On Sunday 10 October 2010 21:49:30 b. f. wrote: If it has an i8254, that can also be used in one-shot mode if hint.attimer.0.timecounter=0 is used, since r212778. Thanks, I didn't know about that. After enabling it things are quite different: kern.eventtimer.periodic is now 1, and setting hw.acpi.cpu.cx_lowest=C2 results in 100% time being reported as being spent in C2 mode according to dev.cpu.0.cx_usage - using C3 causes the system to hang. Shouldn't a fully loaded CPU spent more time in C1 state though? When I run a program that results in 0% idle time cx_usage still reports that no time was spent in C1 state. I'm not sure what is going on here: if you set hint.attimer.0.timecounter=0 and kern.eventtimer.timer=i8254 in /boot/loader.conf, then the system should try to use the i8254 in one-shot mode, unless you've specifically set periodic mode. If kern.eventtimer.periodic=1, then you are _not_ using one-shot mode. If it was 0 before your latest changes, then you were previously using one-shot mode. But, as I wrote earlier, for kern.hz128 and kern.eventtimer.singlemul=1, periodic mode may result in more sleeping than one-shot mode, though at a price. This may be what you are seeing. The C-state used is determined in acpi_cpu_idle() in src/sys/dev/acpica/acpi_cpu.c, if you are using ACPI. I think that if the latency for the C2 state is low enough, the number of callouts and interrupts sufficiently low, and the scheduler quanta large enough, it's possible for your machine to mostly use C2 rather than C1. You can take a look at the algorithm, and make some experiments. Note that bus mastering activity, which can include routine USB polling, may prevent the use of C3. This or the high latency of C3 may account for your machine not using it. Also note that you shouldn't use a LAPIC timer if you are using C3 or deeper sleep states. b. ___ 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: VIA EPIA 5000 and ACPI Cx levels
On Thu, 14 Oct 2010 19:43:36 + b. f. bf1...@googlemail.com wrote: I'm not sure what is going on here: if you set hint.attimer.0.timecounter=0 and kern.eventtimer.timer=i8254 in /boot/loader.conf, then the system should try to use the i8254 in one-shot mode, unless you've specifically set periodic mode. If kern.eventtimer.periodic=1, then you are _not_ using one-shot mode. If it was 0 before your latest changes, then you were previously using one-shot mode. But, as I wrote earlier, for kern.hz128 and kern.eventtimer.singlemul=1, periodic mode may result in more sleeping than one-shot mode, though at a price. This may be what you are seeing. Sorry, that was a typo: kern.eventtimer.periodic=0 after setting hint.attimer.0.timecounter=0. I'm seeing 145 interrupts per second now, so setting hz=100 and using singlemul mode would further decrease it - but I guess it's not something you would want to do on a router or desktop. This or the high latency of C3 may account for your machine not using it. Also note that you shouldn't use a LAPIC timer if you are using C3 or deeper sleep states. Thanks. It sounds like things are working as they should then. Good to know the new timer code is working properly on this more unusual hardware! -- Bruce Cran ___ 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
VIA EPIA 5000 and ACPI Cx levels
I recently upgraded to HEAD on my VIA EPIA C3 box, and had thought about trying out the new one-shot timer mode. Reading mav@'s email it seems that since it doesn't have LAPIC or HPET timers it won't work. However I thought I should still get power savings by using higher Cx levels, but setting hw.acpi.cpu.cx_lowest to C3 I'm only seeing 0.8% time spent in C2 mode, the rest being in C1. The CPU's idle so I don't understand why it's not going into deeper sleep modes. Is this likely to just be an ACPI bug? -- Bruce Cran ___ 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: VIA EPIA 5000 and ACPI Cx levels
I recently upgraded to HEAD on my VIA EPIA C3 box, and had thought about trying out the new one-shot timer mode. Reading mav@'s email it seems that since it doesn't have LAPIC or HPET timers it won't work. However I thought I should still get power savings by using higher Cx levels, but setting hw.acpi.cpu.cx_lowest to C3 I'm only seeing 0.8% time spent in C2 mode, the rest being in C1. The CPU's idle so I don't understand why it's not going into deeper sleep modes. Is this likely to just be an ACPI bug? If it has an i8254, that can also be used in one-shot mode if hint.attimer.0.timecounter=0 is used, since r212778. But for low values of kern.hz, I've found that periodic mode can result in fewer interrupts (albeit increased latencies and lower accuracy in accounting) than one-shot mode, if kern.eventtimer.singlemul=1. As for the power-saving states, are you using a simple 'sysctl dev.cpu.0.cx_usage' to find the percentages? If you're doing something more involved, you may be affecting the measurements. Also, does the system think that the deeper sleep states are available on your machine? If so, what are their latencies? If they are high, they may be used less often, or not at all. Did you follow some of the other recommendations to allow more sleeping, like at: http://wiki.freebsd.org/TuningPowerConsumption ? Or apply mav's extra patch to further reduce interrupts: http://people.freebsd.org/~mav/tm6292_idle.patch ? b. ___ 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: VIA EPIA 5000 and ACPI Cx levels
On Sunday 10 October 2010 21:49:30 b. f. wrote: If it has an i8254, that can also be used in one-shot mode if hint.attimer.0.timecounter=0 is used, since r212778. Thanks, I didn't know about that. After enabling it things are quite different: kern.eventtimer.periodic is now 1, and setting hw.acpi.cpu.cx_lowest=C2 results in 100% time being reported as being spent in C2 mode according to dev.cpu.0.cx_usage - using C3 causes the system to hang. Shouldn't a fully loaded CPU spent more time in C1 state though? When I run a program that results in 0% idle time cx_usage still reports that no time was spent in C1 state. But for low values of kern.hz, I've found that periodic mode can result in fewer interrupts (albeit increased latencies and lower accuracy in accounting) than one-shot mode, if kern.eventtimer.singlemul=1. As for the power-saving states, are you using a simple 'sysctl dev.cpu.0.cx_usage' to find the percentages? If you're doing something more involved, you may be affecting the measurements. Also, does the system think that the deeper sleep states are available on your machine? If so, what are their latencies? If they are high, they may be used less often, or not at all. I'm just using dev.cpu.0.cx_usage to check the Cx level usage. According to dev.cpu.0.cx_supported, I have: C1/0, C2/90, C3/900 Did you follow some of the other recommendations to allow more sleeping, like at: http://wiki.freebsd.org/TuningPowerConsumption I haven't done anything extra yet, since I was mainly interested in seeing if one-shot mode worked on this box. I can't use powerd because running at 266MHz (I only have 533 and 266 available) results in too much of a slowdown. -- Bruce Cran ___ 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, four.harris...@googlemail.com 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 battery issues
2010/10/2 Eitan Adler li...@eitanadler.com: On Sat, Oct 2, 2010 at 4:01 PM, four.harris...@googlemail.com 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 li...@eitanadler.com 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 smi...@nimnet.asn.au wrote: In freebsd-questions Digest, Vol 330, Issue 10, Message: 5 On Sat, 2 Oct 2010 10:42:23 -0400 Eitan Adler li...@eitanadler.com 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
ACPI battery issues
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
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 li...@eitanadler.com 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, four.harris...@googlemail.com 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 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 s.dave.jo...@gmail.com 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 notify0x00
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 s.dave.jo...@gmail.com:
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
ACPI questions about press power button
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 notify0x00
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
Re: Get server's internal temperature from ACPI ?
On 7/7/10 12:38 PM, Chip Camden wrote: Quoth Frank Bonnet on Wednesday, 07 July 2010: Hello Is there an utility to get the internal temperature from a HP Proliant server with ACPI ??? sysctl -n hw.acpi.thermal.tz0.temperature I'm not sure if the Proliant has an Intel Core, but if it does then you can get per-cpu temperature info: kld coretemp kldload, of course. :-) for i in 0 1 2 3; sysctl -n dev.cpu.$i.temperature amdtemp(4) exists for K8, K10, and K11 AMD chips as well. Regards, -- Glen Barber ___ 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
Get server's internal temperature from ACPI ?
Hello Is there an utility to get the internal temperature from a HP Proliant server with ACPI ??? Thank you ___ 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: Get server's internal temperature from ACPI ?
Quoth Frank Bonnet on Wednesday, 07 July 2010: Hello Is there an utility to get the internal temperature from a HP Proliant server with ACPI ??? Thank you ___ 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 sysctl -n hw.acpi.thermal.tz0.temperature I'm not sure if the Proliant has an Intel Core, but if it does then you can get per-cpu temperature info: kld coretemp for i in 0 1 2 3; sysctl -n dev.cpu.$i.temperature -- Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F http://camdensoftware.com | http://chipstips.com| http://chipsquips.com pgpsIIJEqpJbw.pgp Description: PGP signature
ACER Aspire ACPI / Intel Wifi Link 5100
Hello guys, i was playing around with my bsd installation for a while now. everything works fine expect two things: 1. if i boot up with acpi enabled, some devices aren't recognized. like my atheros ethernet card. this doesn't happen if i disable acpi. 2. My wifi link 5100 card isn't detected, too. no matter if acpi is on or off. is there a driver around? i wasn't able to find something. and one last thing for benefits: is there an ethernet driver for iphone tethering over usb? cheer! ___ 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: ACER Aspire ACPI / Intel Wifi Link 5100
On 26 may 2010 at 09:55:28 mar...@amobos.org wrote: 2. My wifi link 5100 card isn't detected, too. no matter if acpi is on or off. is there a driver around? i wasn't able to find something. Try loading if_iwn module. But before loading read man if_iwn there are information about using this module. Greetings, Maciej Milewski ___ 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 | 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 malcolm@internode.on.net 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
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? 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 malcolm@internode.on.netwrote: 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 malcolm@internode.on.net 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 real) knowledge of the range of tasks performed by ACPI. Is my guess that I have
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 malcolm@internode.on.netwrote: 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 malcolm@internode.on.net 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 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
ACPI? problem with release 8.0
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
Re: ACPI temperature
On Monday 30 November 2009 04:59:51 pm you wrote: 2009/11/29 Steven Friedrich free...@insightbb.com: On Sunday 29 November 2009 11:03:28 am you wrote: 2009/11/29 Steven Friedrich free...@insightbb.com: 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 temperature
2009/11/29 Steven Friedrich free...@insightbb.com: On Sunday 29 November 2009 11:03:28 am you wrote: 2009/11/29 Steven Friedrich free...@insightbb.com: 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
ACPI temperature
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.
Here's chkCPUTemperature:
#!/bin/sh
# $Id:$
#
# CPU Temperature Information from ACPI
POLLING_RATE=`sysctl hw.acpi.thermal.polling_rate|awk '{print $2}'`
while [ 1 ]
do
sysctl hw.acpi.thermal.tz0.temperature
sleep $POLLING_RATE
done
uname -a
FreeBSD laptop2.StevenFriedrich.org 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #1:
Sat Oct 3 18:47:43 EDT 2009
r...@laptop2.stevenfriedrich.org:/usr/obj/usr/src/sys/LAPTOP i386
___
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 free...@insightbb.com: 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 free...@insightbb.com: 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
disable ACPI for mouse
Is it possible to disable ACPI support for one specific device? (/dev/psm) ___ 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
Mouse fails with ACPI enabled 8-B4
If I boot with ACPI enabled and then either start X or moused the mouse will appear to work for a few moments and then cease to proccess any input (as tested by moused verbose output, xev, and failure of the mouse to move). This happens on 8.0 BETA 4 If I boot without ACPI the mouse works. Any ideas on how to fix? ___ 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
ACPI - works for wireless fails for mouse
On my laptop when I boot with ACPI enabled my wireless card works but my mouse fails a few seconds after starting moused or X. If I boot without ACPI my mouse works but the wireless card fails. Is it possible to disable ACPI for the mouse and only the mouse (/dev/psm0, IRQ 12, glidepoint type)? OS == FreeBSD 8.0 BETA2 I'm currently stuck with a sub-par internet connection so if this has been covered by the handbook or google I appologize. ___ 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 taj...@gmail.com: On Tue, Jun 2, 2009 at 11:17 PM, mojo fms fbsdli...@gmail.com 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
acpi HD spin down and CPU sleep
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 ___ 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 fbsdli...@gmail.com 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
P2B-D and ACPI or SMB anyone?
Hi, found this old P2B-D board with two 1GHz CPUs and don't want to throw it away ;-) Has anyone got it running with ACPI and without the interrupt storm on irq20? Judging from old mailing list messages it was blacklisted in 5.3 so ACPI got disabled but since it doesn't in 6.4-STABLE the issues were possibly fixed and I am simply too stupid... Another thing is the SMB. I have lots of P2B and P2B-L boards where the SMB is running fine (used by healthd). On this P2B-D it doesn't even attach using the usual device smbus device intpm device smb lines in the kernel. This is the dmesg (without ACPI), nothing special to see. When enabling ACPI we see an error about an interrupt storm on irq20 constantly... Copyright (c) 1992-2008 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.4-STABLE #5: Wed May 20 11:58:13 CEST 2009 r...@server.ofw.tld:/src/obj-6/src/src-6/sys/cvsfix Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (1002.28-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536858624 (511 MB) avail memory = 520503296 (496 MB) MPTable: OEM0 PROD FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-23 on motherboard cpu0 on motherboard cpu1 on motherboard pcib0: MPTable Host-PCI bridge pcibus 0 on motherboard pci0: PCI bus on pcib0 eccmon0: RAM ECC Monitor v0.01 on 8086:7190 eccmon0: Chipset (i440BX/ZX) ECC capability: ECC with hardware scrubber eccmon0: Active mode: ECC with hardware scrubber eccmon0: Bank Size Type ILV ECC eccmon0: 0 128M SDR NY eccmon0: 1 128M SDR NY eccmon0: 2 128M SDR NY eccmon0: 3 128M SDR NY eccmon0: Total RAM detected: 512M eccmon0: attached pcib1: MPTable PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 pci0: mass storage, ATA at device 4.1 (no driver attached) pci0: serial bus, USB at device 4.2 (no driver attached) piix0: PIIX Timecounter port 0xe800-0xe80f at device 4.3 on pci0 Timecounter PIIX frequency 3579545 Hz quality 0 ahc0: Adaptec 29160 Ultra160 SCSI adapter port 0xd000-0xd0ff mem 0xd680-0xd6800fff irq 18 at device 10.0 on pci0 ahc0: Bugs (0x0040): SCBCHAN_UPLOAD ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs em0: Intel(R) PRO/1000 Network Connection Version - 6.7.3 port 0xb800-0xb83f mem 0xd600-0xd601 irq 17 at device 11.0 on pci0 em0: Ethernet address: 00:07:e9:14:56:a6 orm0: ISA Option ROM at iomem 0xc-0xcefff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] fdc0: Enhanced floppy controller at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: 1440-KB 3.5 drive on fdc0 drive 0 sc0: System console at flags 0x100 on isa0 sc0: VGA 9 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 uart0: 16550 or compatible at port 0x3f8-0x3ff irq 4 on isa0 uart1: 16550 or compatible at port 0x2f8-0x2ff irq 3 on isa0 unknown: PNP0700 can't assign resources (port) unknown: PNP0c01 can't assign resources (memory) unknown: PNP0303 can't assign resources (port) unknown: PNP0c02 can't assign resources (port) Timecounters tick every 10.000 msec da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST39175LW 0001 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da1 at ahc0 bus 0 target 1 lun 0 da1: QUANTUM XP39100S LYK8 Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (20.000MHz, offset 31), Tagged Queueing Enabled da1: 8682MB (17781520 512 byte sectors: 255H 63S/T 1106C) da2 at ahc0 bus 0 target 2 lun 0 da2: SEAGATE ST318404LW 3251 Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da3 at ahc0 bus 0 target 3 lun 0 da3: SEAGATE ST318404LW 3251 Fixed Direct Access SCSI-3 device da3: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da3: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) SMP: AP CPU #1 Launched! cd0 at ahc0 bus 0 target 6 lun 0 cd0: TOSHIBA CD-ROM XM-6201TA 1400 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root
Re: P2B-D and ACPI or SMB anyone?
Andre Albsmeier wrote: Hi, found this old P2B-D board with two 1GHz CPUs and don't want to throw it away ;-) Has anyone got it running with ACPI and without the interrupt storm on irq20? Judging from old mailing list messages it was blacklisted in 5.3 so ACPI got disabled but since it doesn't in 6.4-STABLE the issues were possibly fixed and I am simply too stupid... [snip] What you may want to check is the BIOS revision. Easy enough to flash it with the latest released bits if there is something newer than what you've got currently. As far as the SMB goes I don't have any clue... -Mike ___ 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: P2B-D and ACPI or SMB anyone?
On Thu, 21-May-2009 at 08:44:00 -0400, Michael Powell wrote: Andre Albsmeier wrote: Hi, found this old P2B-D board with two 1GHz CPUs and don't want to throw it away ;-) Has anyone got it running with ACPI and without the interrupt storm on irq20? Judging from old mailing list messages it was blacklisted in 5.3 so ACPI got disabled but since it doesn't in 6.4-STABLE the issues were possibly fixed and I am simply too stupid... [snip] What you may want to check is the BIOS revision. Easy enough to flash it with the latest released bits if there is something newer than what you've got currently. Done that already. I run the latest V14beta3 (whose counterpart I also run on the UP boxes for the purpose of Tualatin support)... -Andre ___ 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
hear no sound if acpi=on
Hello all, I have FreeBSD-7.1-RELEASE on my Laptop (compaq presario cq40-401 au). In formation of my devices can be found at * http://viettug.org/attachments/download/128/icy_pciconf.txt (`pciconf -lbv`) * http://viettug.org/attachments/download/132/icy_lspci_nn.txt (`lspci -nn`) * http://viettug.org/attachments/download/147/icy_kernel.txt (the kernel configuration) When I boot the system with `acpi=off`, I can hear the sound (snd_hda). But when `acpi` is used, I hear no sound though the driver seems to work and `mplayer` detects /dev/sp and /dev/mixer successfully. pre $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) Installed devices: pcm0: ATI (Unknown) High Definition Audio Controller at memory 0x9241 irq 19 kld snd_hda [20080420_0052] [MPSAFE] (mixer only) pcm1: ATI SB600 High Definition Audio Controller at memory 0x9250 irq 16 kld snd_hda [20080420_0052] [MPSAFE] (1p:1v/1r:1v channels duplex) /pre I don't experience FreeBSD much. Could you help me to turn the sound on? Thank you very much, Regards, -- Ky Anh, Huynh Homepage: http://viettug.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: [snd_hda] hear no sound if acpi=on
Le Fri, 3 Apr 2009 13:24:49 +0700, kyanh xky...@gmail.com: Hello all, I have FreeBSD-7.1-RELEASE on my Laptop (compaq presario cq40-401 au). In formation of my devices can be found at * http://viettug.org/attachments/download/128/icy_pciconf.txt (`pciconf -lbv`) * http://viettug.org/attachments/download/132/icy_lspci_nn.txt (`lspci -nn`) * http://viettug.org/attachments/download/147/icy_kernel.txt (the kernel configuration) When I boot the system with `acpi=off`, I can hear the sound (snd_hda). But when `acpi` is used, I hear no sound though the driver seems to work and `mplayer` detects /dev/sp and /dev/mixer successfully. pre $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) Installed devices: pcm0: ATI (Unknown) High Definition Audio Controller at memory 0x9241 irq 19 kld snd_hda [20080420_0052] [MPSAFE] (mixer only) pcm1: ATI SB600 High Definition Audio Controller at memory 0x9250 irq 16 kld snd_hda [20080420_0052] [MPSAFE] (1p:1v/1r:1v channels duplex) /pre I don't experience FreeBSD much. Could you help me to turn the sound on? There were some changes in snd_hda just after the 7.1-RELEASE. You can try to update to a 7-STABLE. You can also take the files of snd_hda from current or from stable (/usr/src/sys/dev/sound/pci/hda/*) and rebuild the kernel module. Regards. ___ 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
3ware 8006-2lp hang with ACPI enabled on fbsd-6.4
Hello! I have something strange here. I had a pretty old (5 y.o) network server with mirror raid on 3WARE 8006-2LP running FreeBSD 5.3. memory or mb started to fail periodically, so the server was upgraded to Asus P5Q MB. Everything was fine. Then i decided to upgrade to 6.4-STABLE. After upgrade the machines just locked up after kernel boot is complete and daemons started to load. I have tried many times: sometimes i see PCI parity error from twe driver. Something i don't see any message at all, the machines just freezes. I tried changing pci slot, playing with BIOS settings - no luck. Then i just booted with ACPI disables and everything worked fine! I tried disabling parts of ACPI with debug.acpi loader options, but if i disable bus and pci the loader cannot load the kernel and all other options do not help. The firmware on the raid controller is the latest available (dec 2007). Can anyone explain, why everything worked fine on 5.4 and locks up on 6.4? I am upgrading the box to 7.1-STABLE now via cvs. -- Regards, Artem ___ 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: 3ware 8006-2lp hang with ACPI enabled on fbsd-6.4
Can anyone explain, why everything worked fine on 5.4 and locks up on 6.4? I am upgrading the box to 7.1-STABLE now via cvs. and it will probably fix your problems as ACPI support is constantly improved == more workarounds are added for buggy ACPI bioses -- Regards, Artem ___ 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 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
ACPI issue on my Toshiba laptop
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 I went to go do my monthly source update. While rebooting I couldn't get back into FreeBSD. I would get this dreadful message at the very beginning of the scrolling boot up messages ioapic0: Assuming intbase of 0 *panic: Bogus interrupt flags* From here I only had two options, either shut down or reboot, but would get the same message no matter what. In other words, FreeBSD won't let me fully boot up unless I have ACPI enabled or select the boottime option to run with it enabled. Booting up would let me back into FreeBSD, but then I'd start getting the awful, Watchdog: Device Timeout messages, and my LAN and wireless connections would be useless. I'm assuming there was something added in the source update that altered the ACPI again?? Does anyone know how to get around this?? It's driving me nuts! FreeBSD is basically useless if I can't use any Internet connection. :( Thank You in advance -Frustrated FreeBSD user. ___ 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: SMP and ACPI problem ??
Alain G. Fabry alainfa...@belgacom.net writes (in *extremely* long lines, which I wrapped for him): To make a long story shorteverything worked fine on my system (7.0-RELEASE FreeBSD). Last night I was updating stuff on my windoswXP guess (under qemu) and performed a clean shutdown. This morning, after bringing back up my system it has been unbearably slow. Without doing anyting to FreeBSD, it suddenly started working in SMP mode - recognizing my 2 processors. Before, it never did this...and looking at the speed it is going now, I'm happy it didn't. After googling a bit, I tried to disable ACPI in order to fall back to single processor mode, but my system keeps acting up like it never did before. Very slow booting and KDM/KDE loading. Once up it's ok until I run a portupgrade or such. That's weird all right. My first guess would be interrupt problems. vmstat(8) will show you what is happening on that front. 1. What are some suggestions as to make it run 'normal' again? You need to understand what's going wrong first. 2. Is it possible to make it actually run better in SMP mode? Your system has an SMP kernel, I presume? [The GENERIC kernel does, these days.] 3. Can my updates on the Qemu WindowsXP host make my FreeBSD system suddenly recognize the 2nd CPU? - this doesn't make sense to me but that's the only thing I worked on last night. Vanishingly unlikely, but not completely impossible. I hope I can get some pointers as to what could have caused this and what I can do to get it back to the way it was. I wouldn't be surprised if it were a hardware problem, which can be tricky to trace down from the software side. -- Lowell Gilbert, embedded/networking software engineer, Boston area http://be-well.ilk.org/~lowell/ ___ 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
SMP and ACPI problem ??
Hi, To make a long story shorteverything worked fine on my system (7.0-RELEASE FreeBSD). Last night I was updating stuff on my windoswXP guess (under qemu) and performed a clean shutdown. This morning, after bringing back up my system it has been unbearably slow. Without doing anyting to FreeBSD, it suddenly started working in SMP mode - recognizing my 2 processors. Before, it never did this...and looking at the speed it is going now, I'm happy it didn't. After googling a bit, I tried to disable ACPI in order to fall back to single processor mode, but my system keeps acting up like it never did before. Very slow booting and KDM/KDE loading. Once up it's ok until I run a portupgrade or such. 1. What are some suggestions as to make it run 'normal' again? 2. Is it possible to make it actually run better in SMP mode? 3. Can my updates on the Qemu WindowsXP host make my FreeBSD system suddenly recognize the 2nd CPU? - this doesn't make sense to me but that's the only thing I worked on last night. I hope I can get some pointers as to what could have caused this and what I can do to get it back to the way it was. Thanks in advance, Alain ___ 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
ACPI suspend/resume on RELENG_7 vs. Dell Inspiron XPS
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)? Thanks in advance for any information on this matter. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-questions@freebsd.org 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
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]
ACPI CA Embedded Controller (EC) error messages MSI notebook
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 should I attempt to try to
rewrite my ASL to make it more spec conforming so Intel's CA likes it
OR would it be better to try to work around it in the CA directly. I
believe I understand the problem but I'm still reading the spec
regarding embedded controller sections (which is a little different).
I believe I'm probably not the only MSI FreeBSD owner so I figured I
would share!
Thanks a lot!
-aps
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send
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 should I attempt to try to
| rewrite my ASL to make it more spec conforming so Intel's CA likes it
| OR would it be better
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
| |{
| | Return (0x0F)
| |}
| | }
| | }
| |
| | I've read http://www.freebsd.org/doc/en
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]
Asus A7V-E and ACPI.
I'm running a Fileserver on a now ancient Asus A7V-E box. Until last week this box ran FreeBSD 6.2 and it worked okay. Now it runs 7.0- STABLE. Before last night I had a pair of PCI Dec Tulip Nics in it. I've since replaced that with a Dual Intel Pro/100 (yes, 100, not 1000 if you saw my other post). My problem is with ACPI. When I boot the box with ACPI enabled it cannot allocate all the resources needed for both tulip nics. When I boot the box without ACPI, it can allocate the resources to make everything work but I cannot reboot or shutdown the box. I'd like some suggestions about how I can either tune the box so that the shutdown commands work right with ACPI enabled. I'd accept some suggestions about how to get the box to properly allocate resources with ACPI disabled. Currently the box works because I've reduced the resources by using a Dual Nic but if the time comes that I have to add some other resources I'd like to have some options. -- Chris Chris Hilton tildeChris -- http://myblog.vindaloo.com email -- chris/at/vindaloo/ dot/com .~ ~ .--.~ ~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~. I'm on the outside looking inside, What do I see? Much confusion, disillution, all around me. -- Ian McDonald / Peter Sinfield ___ 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]
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]
ACPI can only be compiled into the kernel on the amd64 and ia64 platforms
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/ ___ 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]
ACPI Problem: acpi_tz0:_TMP value is absurd
A few weeks ago, I upgraded my Compaq Presario desktop machine from FreeBSD 6.2 to 6.3. I soon noticed this message on the screen. Apparently, the system is measuring the temperature of absolute zero. At first, I thought it to be an installation error on my part, but reformatting the hard drive and re-installing 6.3 didn't change anything. This message still appears in 7.0. I installed 6.3 on a Thinkpad laptop but there doesn't seem to be a problem with that machine. A search through Google showed that other users are having the same difficulty but I haven't found a solution yet. It's quite frustrating as there doesn't seem to be a file which I could edit to reset ACPI, either is there anything in the desktop machine's BIOS. Does anyone have any suggestions? Thank you. BMJ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ 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]
ACPI trouble FreeBSD 7.0 STABLE
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 Mar 2 14:21:20 gw-core-iixrouter syslogd: kernel boot file is /boot/kernel/kernel Mar 2 14:21:20 gw-core-iixrouter kernel: Copyright (c) 1992-2008 The FreeBSD Project. Mar 2 14:21:20 gw-core-iixrouter kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 2 14:21:20 gw-core-iixrouter kernel: The Regents of the University of California. All rights reserved. Mar 2 14:21:20 gw-core-iixrouter kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Mar 2 14:21:20 gw-core-iixrouter kernel: FreeBSD 7.0-STABLE #0: Sat Mar 1 09:44:33 WIT 2008 Mar 2 14:21:20 gw-core-iixrouter kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IIX-ROUTER Mar 2 14:21:20 gw-core-iixrouter kernel: Timecounter i8254 frequency 1193182 Hz quality 0 Mar 2 14:21:20 gw-core-iixrouter kernel: CPU: Intel(R) Celeron(R) CPU 2.13GHz (2130.56-MHz 686-class CPU) Mar 2 14:21:20 gw-core-iixrouter kernel: Origin = GenuineIntel Id = 0xf41 Stepping = 1 Mar 2 14:21:20 gw-core-iixrouter kernel: Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,F Mar 2 14:21:20 gw-core-iixrouter kernel: Features2=0x441dSSE3,RSVD2,MON,DS_CPL,CNXT-ID,xTPR Mar 2 14:21:20 gw-core-iixrouter kernel: real memory = 263454720 (251 MB) Mar 2 14:21:20 gw-core-iixrouter kernel: avail memory = 247963648 (236 MB) Mar 2 14:21:20 gw-core-iixrouter kernel: ACPI APIC Table: A M I OEMAPIC Mar 2 14:21:20 gw-core-iixrouter kernel: ioapic0: Changing APIC ID to 1 Mar 2 14:21:20 gw-core-iixrouter kernel: ioapic0 Version 2.0 irqs 0-23 on motherboard Mar 2 14:21:20 gw-core-iixrouter kernel: acpi0: A M I OEMRSDT on motherboard Mar 2 14:21:20 gw-core-iixrouter kernel: acpi0: [ITHREAD] Mar 2 14:21:20 gw-core-iixrouter kernel: acpi0: Power Button (fixed) Mar 2 14:21:20 gw-core-iixrouter kernel: acpi0: reservation of 0, a (3) failed Mar 2 14:21:20 gw-core-iixrouter kernel: acpi0: reservation of 10, fb0 (3) failed Someone give me clue to resolving this problem. Thanks You. -- budsz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with acpi and freebsd7
Hello, I upgraded my system to 7.0-RELEASE, and in the dmesg, I see this message: ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: A M I OEMRSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3f6f (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [ üý] - 0, should be A5 [20070320] ACPI Error (tbinstal-0222): Table has invalid signature [ üý], must be SSDT or PSDT [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_PR_.CPU1._PDC] (Node 0xc3ac1ba0), AE_BAD_SIGNATURE p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [ üý] - 0, should be A5 [20070320] ACPI Error (tbinstal-0222): Table has invalid signature [ üý], must be SSDT or PSDT [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_PR_.CPU2._PDC] (Node 0xc3ac1aa0), AE_BAD_SIGNATURE Are the warning messages important? You can see the full dmesg here: http://zone.nicoelro.net/freebsd/dmesg-trinite Thanks for your advices. -Nicolas ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Clearchains wpi and apm/acpi
Hi, I successfully installed wpi driver and it works great. I'm using acpi. But my screen doesn't go off when I close the lid, and I read that apm could do the trick. So I disabled acpi and enabled apm. Woohoo! The screen shutdowns as predicted. BUT, the wpi driver won't work anymore! I guess that it somehow depends on acpi. Do you guys have seen anything alike? Is it possible to make wpi work with apm? I'm running 7.0-current i386, on a Dell Inspiron 6400. Thanks!! Martin Boulianne ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
