From Juergen.Dankoweit at T-Online.de Sun Mar 1 00:18:38 2009 From: Juergen.Dankoweit at T-Online.de (Juergen Dankoweit) Date: Sun Mar 1 00:18:45 2009 Subject: Thinkap T43 suspend/resume only once In-Reply-To: <8cff488f0902282154u66127f6pc21297c4543cace8@mail.gmail.com> References: <8cff488f0902282154u66127f6pc21297c4543cace8@mail.gmail.com> Message-ID: <49AA44D0.60607@T-Online.de> Hello Steve, Steve Schmidt schrieb: > Juergen, > > I've having the same > issuesyou > reported with FreeBSD/Suspend/Resume/Gnome. > > My settings are identical to the artice (great article) you posted on > ThinkWiki Thanks for the flowers :) > > Without GNOME started, suspend/resume works perfectly. Within GNOME, suspend > works great, however, resume results in a system hang. > > Have any progess/tips? Meanwhile I found out that these troubles partly have to do with hal (I criticize that hal because under FreeBSD there is no need, but that's not the point in this thread!): Gnome wants to do things that the operating system wants to do, too. What helped on my system was disabling the APIC (not ACPI!!!) in /boot/device.hints: hint.apic.0.disabled="1" But now I'm unable to use my Adaptec-SCSI-PCMCIA-Card because there are no free IRQs anymore... I hope this helps. Best regards J?rgen From bugmaster at FreeBSD.org Mon Mar 2 03:07:29 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 2 03:10:31 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200903021106.n22B6lCd057204@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 f kern/67309 acpi zzz reboot computer (ACPI S3) o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 47 problems total. From sdshschmidt at gmail.com Tue Mar 3 07:32:49 2009 From: sdshschmidt at gmail.com (Steve Schmidt) Date: Tue Mar 3 07:32:56 2009 Subject: T43 resume problem Message-ID: <8cff488f0903030732u120850c0s338fdf6194c25c06@mail.gmail.com> If x (X.Org X Server 1.5.3) is not started, then closing the lid suspends/resumes perfectly. If x is started and /etc/rc.d/netif started, suspend works, resume fails. If x is started and /etc/rc.d/netif stopped, suspend works, resume works. Thinkpad T43 (type 2668), bge0 and iwi0 network drivers. With 7.1-RELEASE-p2 FreeBSD: My network devices: $ sysctl -a|grep bge hw.bge.allow_asf: 0 dev.bge.0.%desc: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x4101 dev.bge.0.%driver: bge dev.bge.0.%location: slot=0 function=0 dev.bge.0.%pnpinfo: vendor=0x14e4 device=0x167d subvendor=0x1014 subdevice=0x0577 class=0x020000 dev.bge.0.%parent: pci2 dev.miibus.0.%parent: bge0 $ sysctl -a|grep iwi net.wlan.0.%parent: iwi0 debug.iwi: 0 dev.iwi.0.%desc: Intel(R) PRO/Wireless 2200BG dev.iwi.0.%driver: iwi dev.iwi.0.%location: slot=2 function=0 dev.iwi.0.%pnpinfo: vendor=0x8086 device=0x4220 subvendor=0x8086 subdevice=0x2711 class=0x028000 dev.iwi.0.%parent: pci4 dev.iwi.0.radio: 1 dev.iwi.0.bluetooth: 0 dev.iwi.0.antenna: 0 dev.iwi.0.softled: 1 dev.iwi.0.ledpin: 16 dev.iwi.0.ledidle: 2700 dev.iwi.0.nictype: 0 From scottmaccal.list at gmail.com Sat Mar 7 14:11:38 2009 From: scottmaccal.list at gmail.com (Scott MacCallum) Date: Sat Mar 7 14:11:46 2009 Subject: acpi_tz0: _TMP value is absurd, ignored (-270.9C) -- HP-Pavilion-a305w-Trigem-Motherboard Message-ID: <1c15953f0903071343w414c6312p3d7bdf49677006e0@mail.gmail.com> Greetings, I own a HP Pavilion a305w with a Trigem motherboard ( http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00046449&lc=en&dlc=en&cc=us&lang=en&softwareitem=pv-15624-1&os=228&product=362754 ). acpi_tz0: _TMP value is absurd, ignored (-270.9C) repeats on the screen. This started after I did a FreeBSD 7.0 Release minimum network install. I updated FreeBSD 7.0 with cvsup to FreeBSD 7.0-RELEASE-p10 and the problem continues. I updated my BIOS ( http://h10025.www1.hp.com/ewfrf/wc/softwareList?os=228&lc=en&dlc=en&cc=us&product=362754&lang=en) to the latest version (3.24) and the problem continues. _dmesg with ACPI enabled_ 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 7.0-RELEASE-p10 #0: Wed Mar 4 23:37:45 EST 2009 root@node03.droidlab:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.70GHz (2691.28-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 796393472 (759 MB) avail memory = 765341696 (729 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Mar 4 2009 23:36:56) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: mem 0xf0000000-0xf7ffffff,0xe8000000-0xe807fff f irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 8060k stolen memory agp0: aperture size is 128M uhci0: port 0x1800-0x181f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xe8080000-0xe80803ff i rq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib1: at device 30.0 on pci0 pci2: on pcib1 rl0: port 0x2000-0x20ff mem 0xe8100000-0xe81000ff ir q 17 at device 2.0 on pci2 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:2b:6f:36:0f rl0: [ITHREAD] pci2: at device 10.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x37 6,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (-263.7C) acpi_tz0: _PSV value is absurd, ignored (-273.2C) acpi_tz0: _ACx value is absurd, ignored (-267.3C) acpi_button0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xe0000-0xe3fff,0xe4000-0xe4fff pnpid ORM0000 o n isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub2 kbd2 at ukbd0 uhid0: on uhub2 Timecounter "TSC" frequency 2691280232 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. acpi_tz0: _TMP value is absurd, ignored (-270.6C) ad0: 38166MB at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a rl0: link state changed to UP acpi_tz0: _TMP value is absurd, ignored (-270.9C) acpi_tz0: _TMP value is absurd, ignored (-270.9C) acpi_tz0: _TMP value is absurd, ignored (-270.9C) acpi_tz0: _TMP value is absurd, ignored (-270.8C) acpi_tz0: _TMP value is absurd, ignored (-270.8C) acpi_tz0: _TMP value is absurd, ignored (-271.0C) acpi_tz0: _TMP value is absurd, ignored (-271.0C) _dmesg with ACPI disabled_ 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 7.0-RELEASE-p10 #0: Wed Mar 4 23:37:45 EST 2009 root@node03.droidlab:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.70GHz (2691.28-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 796393472 (759 MB) avail memory = 765341696 (729 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Mar 4 2009 23:36:56) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: mem 0xf0000000-0xf7ffffff,0xe8000000-0xe807ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 8060k stolen memory agp0: aperture size is 128M uhci0: port 0x1800-0x181f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xe8080000-0xe80803ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered pcib1: at device 30.0 on pci0 pci2: on pcib1 rl0: port 0x2000-0x20ff mem 0xe8100000-0xe81000ff irq 17 at device 2.0 on pci2 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:40:2b:6f:36:0f rl0: [ITHREAD] pci2: at device 10.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) acpi_tz0: on acpi0 acpi_tz0: _CRT value is absurd, ignored (-263.7C) acpi_tz0: _PSV value is absurd, ignored (-273.2C) acpi_tz0: _ACx value is absurd, ignored (-267.3C) acpi_button0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xe0000-0xe3fff,0xe4000-0xe4fff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub2 kbd2 at ukbd0 uhid0: on uhub2 Timecounter "TSC" frequency 2691283684 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. acpi_tz0: _TMP value is absurd, ignored (-270.4C) ad0: 38166MB at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a rl0: link state changed to UP acpi_tz0: _TMP value is absurd, ignored (-270.5C) acpi_tz0: _TMP value is absurd, ignored (-270.7C) acpi_tz0: _TMP value is absurd, ignored (-270.7C) acpi_tz0: _TMP value is absurd, ignored (-270.8C) acpi_tz0: _TMP value is absurd, ignored (-270.8C) acpi_tz0: _TMP value is absurd, ignored (-270.5C) acpi_tz0: _TMP value is absurd, ignored (-270.9C) acpi_tz0: _TMP value is absurd, ignored (-270.9C) _sysctl hw.acpi_ hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: -273.2C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: -1 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 _ACPI source language_ http://scm.freeshell.org/HP-Pavilion-a305w-Trigem-Motherboard.asl Thank you. -- Sincerely, Scott From gaijin.k at gmail.com Sat Mar 7 17:12:07 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sat Mar 7 17:12:12 2009 Subject: acpi_tz0: _TMP value is absurd, ignored (-270.9C) -- HP-Pavilion-a305w-Trigem-Motherboard In-Reply-To: <1c15953f0903071343w414c6312p3d7bdf49677006e0@mail.gmail.com> References: <1c15953f0903071343w414c6312p3d7bdf49677006e0@mail.gmail.com> Message-ID: <1236473234.1204.12.camel@RabbitsDen> On Sat, 2009-03-07 at 16:43 -0500, Scott MacCallum wrote: > Greetings, > > I own a HP Pavilion a305w with a Trigem motherboard ( > http://h10025.www1.hp.com/ewfrf/wc/document?docname=c00046449&lc=en&dlc=en&cc=us?=en&softwareitem=pv-15624-1&os=228&product=362754 > ). > > acpi_tz0: _TMP value is absurd, ignored (-270.9C) repeats on the screen. > > _ACPI source language_ > > http://scm.freeshell.org/HP-Pavilion-a305w-Trigem-Motherboard.asl > > Thank you. > Whoever wrote that BIOS needs to figure out that specification calls for _TMP, _CRT, _PSV and _ACx methods to return value, measured in 0.1K. Hence, -270.9 is, likely, 24C. If you feel adventurous, you might want to change your _TMP method by adding Multiply (0x0A, Local0, Local0) Add (Local0, 0x0AAC, Local0) before Return (Local0) _CRT, _PSV and _AC0 could use the same treatment. HTH, -- Alexandre "Sunny" Kovalenko From scottmaccal.list at gmail.com Sat Mar 7 18:37:30 2009 From: scottmaccal.list at gmail.com (Scott MacCallum) Date: Sat Mar 7 18:37:36 2009 Subject: acpi_tz0: _TMP value is absurd, ignored (-270.9C) -- HP-Pavilion-a305w-Trigem-Motherboard In-Reply-To: <1236473234.1204.12.camel@RabbitsDen> References: <1c15953f0903071343w414c6312p3d7bdf49677006e0@mail.gmail.com> <1236473234.1204.12.camel@RabbitsDen> Message-ID: <1c15953f0903071837r208277ecte24d325118d48ecd@mail.gmail.com> Hi Alexandre, Thank you for the suggestion. I would like to give it a try. Could you point me to a tutorial with the steps to implement the change after I have edited my ASL file. I have been reading the ACPI debug section of the FreeBSD handbook (http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html) but I am at the point where I feel I need more information. I couldn't find anything that was of help with Google and the ACPI Specification ( http://acpi.info/spec.htm) is over my head at the moment. Something more FreeBSD specific would be a great help. Thank you. -- Sincerely, Scott From gaijin.k at gmail.com Sun Mar 8 08:54:32 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sun Mar 8 08:54:38 2009 Subject: acpi_tz0: _TMP value is absurd, ignored (-270.9C) -- HP-Pavilion-a305w-Trigem-Motherboard In-Reply-To: <1c15953f0903071837r208277ecte24d325118d48ecd@mail.gmail.com> References: <1c15953f0903071343w414c6312p3d7bdf49677006e0@mail.gmail.com> <1236473234.1204.12.camel@RabbitsDen> <1c15953f0903071837r208277ecte24d325118d48ecd@mail.gmail.com> Message-ID: <1236527641.1259.3.camel@RabbitsDen> On Sat, 2009-03-07 at 21:37 -0500, Scott MacCallum wrote: > Hi Alexandre, > > Thank you for the suggestion. I would like to give it a try. Could you > point me to a tutorial with the steps to implement the change after I > have edited my ASL file. I have been reading the ACPI debug section of > the FreeBSD handbook > (http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html) but I > am at the point where I feel I need more information. I couldn't find > anything that was of help with Google and the ACPI Specification > (http://acpi.info/spec.htm) is over my head at the moment. Something > more FreeBSD specific would be a great help. Chapter 11.16.5.3 "Overriding the Default AML" in the handbook (URL, you have quoted above) is all you need. It really is *that* simple ;) If something isn't very clear, or does not work for you, please, do not hesitate to ask, though. -- Alexandre "Sunny" Kovalenko From scottmaccal.list at gmail.com Sun Mar 8 18:00:09 2009 From: scottmaccal.list at gmail.com (Scott MacCallum) Date: Sun Mar 8 18:00:16 2009 Subject: acpi_tz0: _TMP value is absurd, ignored (-270.9C) -- HP-Pavilion-a305w-Trigem-Motherboard In-Reply-To: <1236527641.1259.3.camel@RabbitsDen> References: <1c15953f0903071343w414c6312p3d7bdf49677006e0@mail.gmail.com> <1236473234.1204.12.camel@RabbitsDen> <1c15953f0903071837r208277ecte24d325118d48ecd@mail.gmail.com> <1236527641.1259.3.camel@RabbitsDen> Message-ID: <1c15953f0903081800s59683b0bo949b6759bc991d67@mail.gmail.com> Why yes it is. I missed that section in the document. :-) Thanks again. -- Sincerely, Scott From bugmaster at FreeBSD.org Mon Mar 9 10:15:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 9 10:15:21 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200903091714.n29HEwX2045144@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 f kern/67309 acpi zzz reboot computer (ACPI S3) o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 47 problems total. From linimon at FreeBSD.org Fri Mar 13 13:06:44 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Mar 13 13:06:55 2009 Subject: kern/132602: [acpi] ACPI Problem with Intel SS4200: System does not power off Message-ID: <200903132006.n2DK6fYj043822@freefall.freebsd.org> Old Synopsis: ACPI Problem with Intel SS4200: System does not power off New Synopsis: [acpi] ACPI Problem with Intel SS4200: System does not power off Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Fri Mar 13 20:06:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132602 From bugmaster at FreeBSD.org Mon Mar 16 04:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 16 04:07:11 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200903161106.n2GB6nDN043150@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 f kern/67309 acpi zzz reboot computer (ACPI S3) o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 48 problems total. From avg at icyb.net.ua Mon Mar 16 09:03:36 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Mar 16 09:03:43 2009 Subject: piix4: heuristic quirk for incorrect value of PM1a_CNT_BLK Message-ID: <49BE7855.40709@icyb.net.ua> I personally own two different systems (from different vendors) based on PIIX4E/440BX chipset. They both have incorrect value of PM1a_CNT_BLK and in both case it's 0x4040 instead 0x4004. I suspect that this was a common mistake that was made by a BIOS vendor and then propagated into a number of BIOSes for different motehrboard vendors. I've developed a local quirk/fix for this which works in heuristic way. It depends on the fact that PIIX4 and later ICH chipsets have the same layout for several ACPI-related registers in Power Management IO space. So it forces Pm1aControlBlock to pm_base + 4 if Pm1aEventBlock is at pm_base + 0 and PmTimerBlock is at pm_base + 8. But I am not sure if it won't break any non-Intel HW. So this patch is not likely to be ever committed to freebsd sources, but it might be useful for some people. This can help on the relevant systems that have problems with shutdown/reboot via ACPI. diff --git a/sys/dev/acpica/acpi_quirk.c b/sys/dev/acpica/acpi_quirk.c index b75a527..bb44088 100644 --- a/sys/dev/acpica/acpi_quirk.c +++ b/sys/dev/acpica/acpi_quirk.c @@ -140,6 +140,7 @@ acpi_table_quirks(int *quirks) const struct acpi_q_entry *entry; const struct acpi_q_rule *match; ACPI_TABLE_HEADER fadt, dsdt, xsdt, *hdr; + UINT32 pm_base; int done; /* First, allow the machdep system to set its idea of quirks. */ @@ -180,5 +181,21 @@ acpi_table_quirks(int *quirks) } } + /* Special check for incorrect PM1a_CNT_BLK address on PIIX4E systems, + * a mistake that was common for many BIOS vendors. + */ + pm_base = AcpiGbl_FADT.Pm1aControlBlock & 0xffffff00; + if ((AcpiGbl_FADT.PmTimerBlock & 0xffffff00) == pm_base + && (AcpiGbl_FADT.Pm1aEventBlock & 0xffffff00) == pm_base + && (AcpiGbl_FADT.PmTimerBlock & 0xff) == 0x08 + && (AcpiGbl_FADT.Pm1aEventBlock & 0xff) == 0x00 + && (AcpiGbl_FADT.Pm1aControlBlock & 0xff) != 0x04) + { + printf("detected a system that looks like PIIX4E with incorrect " + "PM1a_CNT_BLK address\n"); + printf("PM_BASE: %#x, PM1a_CNT_BLK: %#x => %#x\n", + pm_base, AcpiGbl_FADT.Pm1aControlBlock, pm_base | 0x04); + AcpiGbl_FADT.Pm1aControlBlock = pm_base | 0x04; + } return (0); } -- Andriy Gapon From avg at icyb.net.ua Mon Mar 16 09:11:09 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Mar 16 09:11:15 2009 Subject: piix4e: quirk/fix for proper throttling duty width Message-ID: <49BE7A1A.3040603@icyb.net.ua> Intel documentation on PIIX4E unambiguously specifies CPU throttling duty offset and width. It seems that some vendor BIOS specify an incorrect (smaller) value for the width for unknown reason. I have a private patch for this. This is unlikely to be ever committed to freebsd source because of minor importance (of both the feature and the very old hardware) and potential risks. But someone might find this useful, so I am sharing. diff --git a/sys/dev/acpica/acpi_throttle.c b/sys/dev/acpica/acpi_throttle.c index d79d7ae..a0ad5ae 100644 --- a/sys/dev/acpica/acpi_throttle.c +++ b/sys/dev/acpica/acpi_throttle.c @@ -80,11 +80,14 @@ struct acpi_throttle_softc { (CPU_SPEED_PERCENT(x) % 10) #define CPU_P_CNT_THT_EN (1<<4) #define CPU_QUIRK_NO_THROTTLE (1<<1) /* Throttling is not usable. */ +#define CPU_QUIRK_PIIX4_WIDTH (1<<2) #define PCI_VENDOR_INTEL 0x8086 #define PCI_DEVICE_82371AB_3 0x7113 /* PIIX4 chipset for quirks. */ #define PCI_REVISION_A_STEP 0 #define PCI_REVISION_B_STEP 1 +#define PCI_REVISION_4E 2 +#define PCI_REVISION_4M 3 static uint32_t cpu_duty_offset; /* Offset in P_CNT of throttle val. */ static uint32_t cpu_duty_width; /* Bit width of throttle value. */ @@ -247,6 +250,8 @@ acpi_throttle_evaluate(struct acpi_throttle_softc *sc) } if (cpu_duty_width == 0 || (thr_quirks & CPU_QUIRK_NO_THROTTLE) != 0) return (ENXIO); + if ((thr_quirks & CPU_QUIRK_PIIX4_WIDTH) != 0) + cpu_duty_width = 3; /* Validate the duty offset/width. */ duty_end = cpu_duty_offset + cpu_duty_width - 1; @@ -333,8 +338,14 @@ acpi_throttle_quirks(struct acpi_throttle_softc *sc) case PCI_REVISION_A_STEP: case PCI_REVISION_B_STEP: thr_quirks |= CPU_QUIRK_NO_THROTTLE; + device_printf(sc->cpu_dev, + "throttling is disabled for PIIX4 rev. A/B\n"); break; - default: + case PCI_REVISION_4E: + case PCI_REVISION_4M: + thr_quirks |= CPU_QUIRK_PIIX4_WIDTH; + device_printf(sc->cpu_dev, + "throttling has 12.5%% step for PIIX4E/M\n"); break; } } -- Andriy Gapon From c.r.n.a at wanadoo.fr Thu Mar 19 05:00:41 2009 From: c.r.n.a at wanadoo.fr (Nicolas) Date: Thu Mar 19 05:00:47 2009 Subject: Problem with ACPI Message-ID: <49C2221B.2050004@wanadoo.fr> Hi FreeBSD users, I'm using FreeBSD 8-Current and i have this message in dmesg when i click on the direct application button: acpi_ec0: wait timed out (no response), forcing polled mode acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.HTEV] (Node 0xc6b4cb60), AE_NO_HARDWARE_RESPONSE ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC_.EC0_._Q44] (Node 0xc6b4b020), AE_NO_HARDWARE_RESPONSE acpi_ec0: evaluation of query method _Q44 failed: AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc6b46860), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc6b46860), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc6b46860), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.BAT0._BST] (Node 0xc6b46860), AE_NO_HARDWARE_RESPONSE acpi_ec0: EcRead: failed waiting to get data ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by Handler for [EmbeddedControl] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.PCI0.LPC_.EC0_._Q43] (Node 0xc6b4b040), AE_NO_HARDWARE_RESPONSE acpi_ec0: evaluation of query method _Q43 failed: AE_NO_HARDWARE_RESPONSE I'm using the latest available bios version. Do you know where the problem come from ? Do you know if i need a special "acpi_support" driver to make it work (like the acpi_panasonic or acpi_sony) ? Thanks in advance. Niko. From niktychina at gmail.com Thu Mar 19 11:56:18 2009 From: niktychina at gmail.com (Nikolay Tychina) Date: Thu Mar 19 11:56:24 2009 Subject: Problem with ACPI In-Reply-To: <49C2221B.2050004@wanadoo.fr> References: <49C2221B.2050004@wanadoo.fr> Message-ID: Acer? I have the same errors on 7.1 /Acer Aspire 5520/ I disabled ec debug.acpi.disabled="ec" and don't care :D Suspending doesn't work of course. 2009/3/19 Nicolas > Hi FreeBSD users, > > I'm using FreeBSD 8-Current and i have this message in dmesg when i click > on the direct application button: > > acpi_ec0: wait timed out (no response), forcing polled mode > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by > Handler for [EmbeddedControl] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.HTEV] > (Node 0xc6b4cb60), AE_NO_HARDWARE_RESPONSE > ACPI Error (psparse-0626): Method parse/execution failed > [\\_SB_.PCI0.LPC_.EC0_._Q44] (Node 0xc6b4b020), AE_NO_HARDWARE_RESPONSE > acpi_ec0: evaluation of query method _Q44 failed: AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by > Handler for [EmbeddedControl] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.BAT0._BST] > (Node 0xc6b46860), AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by > Handler for [EmbeddedControl] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.BAT0._BST] > (Node 0xc6b46860), AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by > Handler for [EmbeddedControl] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.BAT0._BST] > (Node 0xc6b46860), AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by > Handler for [EmbeddedControl] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed [\\_SB_.BAT0._BST] > (Node 0xc6b46860), AE_NO_HARDWARE_RESPONSE > acpi_ec0: EcRead: failed waiting to get data > ACPI Exception (evregion-0529): AE_NO_HARDWARE_RESPONSE, Returned by > Handler for [EmbeddedControl] [20070320] > ACPI Error (psparse-0626): Method parse/execution failed > [\\_SB_.PCI0.LPC_.EC0_._Q43] (Node 0xc6b4b040), AE_NO_HARDWARE_RESPONSE > acpi_ec0: evaluation of query method _Q43 failed: AE_NO_HARDWARE_RESPONSE > > I'm using the latest available bios version. > Do you know where the problem come from ? > Do you know if i need a special "acpi_support" driver to make it work (like > the acpi_panasonic or acpi_sony) ? > > Thanks in advance. > Niko. > > > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From c.r.n.a at wanadoo.fr Thu Mar 19 13:17:18 2009 From: c.r.n.a at wanadoo.fr (Nicolas) Date: Thu Mar 19 13:17:25 2009 Subject: Problem with ACPI In-Reply-To: References: <49C2221B.2050004@wanadoo.fr> Message-ID: <49C29759.4060003@wanadoo.fr> No, it's HP Pavilion dv7 Disabling "ec" make hald not working. Acpi errors messages disapared ! But how to use the direct application button ? Thanks in advance, Niko. > Acer? I have the same errors on 7.1 /Acer Aspire 5520/ > > I disabled ec > > debug.acpi.disabled="ec" > > > and don't care :D > > Suspending doesn't work of course. From dandee at hellteam.net Thu Mar 19 17:30:04 2009 From: dandee at hellteam.net (=?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?=) Date: Thu Mar 19 17:30:11 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Message-ID: <200903200030.n2K0U3iG011009@freefall.freebsd.org> The following reply was made to PR kern/108581; it has been noted by GNATS. From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= To: , Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C9A8F7.746C4190 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi acpi team, =20 today I have installed fbsd 7.1R on one box with this relativly old = error and I was surprised about results .. it is the same: =20 # uname -a FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 = UTC 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386 # sysctl dev.cpu.0.cx_supported dev.cpu.0.cx_supported: C1/0 # sysctl hw.acpi.cpu.cx_lowest=3DC1 hw.acpi.cpu.cx_lowest: C1 sysctl: hw.acpi.cpu.cx_lowest: Invalid argument =20 # sysctl hw.acpi.cpu.cx_lowest=3DC0 hw.acpi.cpu.cx_lowest: C1 sysctl: hw.acpi.cpu.cx_lowest: Invalid argument =20 # sysctl hw.acpi.cpu.cx_lowest=3DC1/0 hw.acpi.cpu.cx_lowest: C1 sysctl: hw.acpi.cpu.cx_lowest: Invalid argument # dmesg -a | grep "acpi" acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ff00000 (3) failed acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 cpu0: on acpi0 hw.acpi.cpu.cx_lowest: hw.acpi.cpu.cx_lowest ------=_NextPart_000_0007_01C9A8F7.746C4190 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi = acpi=20 team,
 
today = I have=20 installed fbsd 7.1R on one box with this relativly old error and I was = surprised=20 about results .. it is the same:
 
# = uname=20 -a
FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan  1 = 14:37:25=20 UTC 2009     r= oot@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC =20 i386
# sysctl=20 dev.cpu.0.cx_supported
dev.cpu.0.cx_supported:=20 C1/0
# = sysctl=20 hw.acpi.cpu.cx_lowest=3DC1
hw.acpi.cpu.cx_lowest: C1
sysctl:=20 hw.acpi.cpu.cx_lowest: Invalid argument
 
# = sysctl=20 hw.acpi.cpu.cx_lowest=3DC0
hw.acpi.cpu.cx_lowest: C1
sysctl:=20 hw.acpi.cpu.cx_lowest: Invalid argument
 
# = sysctl=20 hw.acpi.cpu.cx_lowest=3DC1/0
hw.acpi.cpu.cx_lowest: C1
sysctl:=20 hw.acpi.cpu.cx_lowest: Invalid argument
# = dmesg -a | grep=20 "acpi"
acpi0: = <ASUS=20 P4S8X-X> on motherboard
acpi0: Overriding SCI Interrupt from IRQ 9 = to IRQ=20 20
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: = reservation of=20 0, a0000 (3) failed
acpi0: reservation of 100000, ff00000 (3)=20 failed
acpi_timer0: <24-bit timer at 3.579545MHz> port = 0xe408-0xe40b on=20 acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI = Host-PCI=20 bridge> port 0xcf8-0xcff on acpi0
atkbdc0: <Keyboard controller = (i8042)> port 0x60,0x64 irq 1 on acpi0
cpu0: <ACPI CPU> on=20 acpi0
hw.acpi.cpu.cx_lowest:
hw.acpi.cpu.cx_lowest
------=_NextPart_000_0007_01C9A8F7.746C4190-- From bruce at cran.org.uk Fri Mar 20 12:13:50 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Fri Mar 20 12:13:56 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <200903200030.n2K0U3iG011009@freefall.freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> Message-ID: <20090320191340.7cff38c9@gluon> On Fri, 20 Mar 2009 00:30:03 GMT Daniel Dvo??k wrote: > The following reply was made to PR kern/108581; it has been noted by > GNATS. > > From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= > To: , > > Cc: > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > > This is a multi-part message in MIME format. > > ------=_NextPart_000_0007_01C9A8F7.746C4190 > Content-Type: text/plain; > charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Hi acpi team, > =20 > today I have installed fbsd 7.1R on one box with this relativly old = > error and I was surprised about results .. it is the same: > =20 > # uname -a > FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > 14:37:25 = UTC 2009 > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386 > > # sysctl dev.cpu.0.cx_supported > dev.cpu.0.cx_supported: C1/0 > > # sysctl hw.acpi.cpu.cx_lowest=3DC1 > hw.acpi.cpu.cx_lowest: C1 > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument I get the same error on my relatively ancient Athlon XP machine - I originally bought it in 2002. Since it pre-dates all the CPU power-saving technologies I wouldn't expect setting Cx to do anything, but it seems FreeBSD creates the sysctl nodes regardless, and tries to initialize cx_lowest to C1 during boot. -- Bruce Cran From robert.moore at intel.com Fri Mar 20 13:09:53 2009 From: robert.moore at intel.com (Moore, Robert) Date: Fri Mar 20 13:21:05 2009 Subject: ACPICA version 20090320 released Message-ID: <4911F71203A09E4D9981D27F9D8308581C920D84@orsmsx503.amr.corp.intel.com> 20 March 2009. Summary of changes for version 20090320: This release is available at www.acpica.org/downloads. 1) ACPI CA Core Subsystem: Fixed a possible race condition between AcpiWalkNamespace and dynamic table unloads. Added a reader/writer locking mechanism to allow multiple concurrent namespace walks (readers), but block a dynamic table unload until it can gain exclusive write access to the namespace. This fixes a problem where a table unload could (possibly catastrophically) delete the portion of the namespace that is currently being examined by a walk. Adds a new file, utlock.c, that implements the reader/writer lock mechanism. ACPICA BZ 749. Fixed a regression introduced in version 20090220 where a change to the FADT handling could cause the ACPICA subsystem to access non-existent I/O ports. Modified the handling of FADT register and table (FACS/DSDT) addresses. The FADT can contain both 32-bit and 64-bit versions of these addresses. Previously, the 64-bit versions were favored, meaning that if both 32 and 64 versions were valid, but not equal, the 64-bit version was used. This was found to cause some machines to fail. Now, in this case, the 32-bit version is used instead. This now matches the Windows behavior. Implemented a new mechanism to protect certain I/O ports. Provides Microsoft compatibility and protects the standard PC I/O ports from access via AML code. Adds a new file, hwvalid.c Fixed a possible extraneous warning message from the FADT support. The message warns of a 32/64 length mismatch between the legacy and GAS definitions for a register. Removed the obsolete AcpiOsValidateAddress OSL interface. This interface is made obsolete by the port protection mechanism above. It was previously used to validate the entire address range of an operation region, which could be incorrect if the range included illegal ports, but fields within the operation region did not actually access those ports. Validation is now performed on a per-field basis instead of the entire region. Modified the handling of the PM1 Status Register ignored bit (bit 11.) Ignored bits must be "preserved" according to the ACPI spec. Usually, this means a read/modify/write when writing to the register. However, for status registers, writing a one means clear the event. Writing a zero means preserve the event (do not clear.) This behavior is clarified in the ACPI 4.0 spec, and the ACPICA code now simply always writes a zero to the ignored bit. Modified the handling of ignored bits for the PM1 A/B Control Registers. As per the ACPI specification, for the control registers, preserve (read/modify/write) all bits that are defined as either reserved or ignored. Updated the handling of write-only bits in the PM1 A/B Control Registers. When reading the register, zero the write-only bits as per the ACPI spec. ACPICA BZ 443. Lin Ming. Removed "Linux" from the list of supported _OSI strings. Linux no longer wants to reply true to this request. The Windows strings are the only paths through the AML that are tested and known to work properly. Previous Release: Non-Debug Version: 82.0K Code, 17.5K Data, 99.5K Total Debug Version: 156.9K Code, 49.8K Data, 206.7K Total Current Release: Non-Debug Version: 82.6K Code, 17.6K Data, 100.2K Total Debug Version: 157.7K Code, 49.9K Data, 207.6K Total 2) iASL Compiler/Disassembler and Tools: Acpiexec: Split the large aeexec.c file into two new files, aehandlers.c and aetables.c From bugmaster at FreeBSD.org Mon Mar 23 04:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 23 04:07:16 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200903231106.n2NB6pBa003904@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 f kern/67309 acpi zzz reboot computer (ACPI S3) o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 48 problems total. From cwhiteh at onetel.com Mon Mar 23 15:44:50 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Mon Mar 23 15:44:57 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) Message-ID: <49C80E65.9090500@onetel.com> Hi, I sent this a while ago but don't think there was a reply. I'm about to embark on a custom ASL to load in loader.conf as per http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just wondering if their might be a 'proper' fix on the way. I do have the latest bios installed. Would it help if I installed 8-CURRENT? As below please would you cc me in any reply as I'm not subscribed. Thanks Chris -------- Original Message -------- Subject: pr kern/105537 Date: Mon, 12 Jan 2009 15:00:49 +0000 From: Chris Whitehouse To: freebsd-acpi@FreeBSD.org hi, Please would you cc me in any reply as I'm not subscribed, thanks. I have the same problem noted in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 of frequent messages saying acpi_tz0: _CRT value is absurd, ignored (256.0C) on my HP nc6320 laptop, model RH383ET. Is there any progress on this PR? Would it help if I arranged root access on this machine for someone to have a look at it? Currently has PCBSD but I can replace that with something else if required. FreeBSD muji 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Mon Nov 24 20:22:16 EST 2008 root@pcbsdx32-7:/usr/obj/pcbsd-build/cvs/7.0.2-src/sys/PCBSD i386 thanks Chris From nate at root.org Mon Mar 23 16:36:11 2009 From: nate at root.org (Nate Lawson) Date: Mon Mar 23 16:36:18 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49C80E65.9090500@onetel.com> References: <49C80E65.9090500@onetel.com> Message-ID: <49C81A84.7060004@root.org> It's probably the EC timing out, not ASL. -Nate Chris Whitehouse wrote: > Hi, I sent this a while ago but don't think there was a reply. I'm about > to embark on a custom ASL to load in loader.conf as per > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > wondering if their might be a 'proper' fix on the way. I do have the > latest bios installed. > > Would it help if I installed 8-CURRENT? > > As below please would you cc me in any reply as I'm not subscribed. > > Thanks > > Chris > > -------- Original Message -------- > Subject: pr kern/105537 > Date: Mon, 12 Jan 2009 15:00:49 +0000 > From: Chris Whitehouse > To: freebsd-acpi@FreeBSD.org > > hi, > > Please would you cc me in any reply as I'm not subscribed, thanks. > > I have the same problem noted in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > of frequent messages saying > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > on my HP nc6320 laptop, model RH383ET. > > Is there any progress on this PR? Would it help if I arranged root > access on this machine for someone to have a look at it? > > Currently has PCBSD but I can replace that with something else if required. > > FreeBSD muji 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Mon Nov 24 > 20:22:16 EST 2008 > root@pcbsdx32-7:/usr/obj/pcbsd-build/cvs/7.0.2-src/sys/PCBSD i386 > > > thanks > > Chris > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" -- Nate From invite+ppvicpif at facebookmail.com Tue Mar 24 05:43:42 2009 From: invite+ppvicpif at facebookmail.com (Vahid Chitsazzadeh) Date: Tue Mar 24 05:43:49 2009 Subject: Check out my photos on Facebook Message-ID: <1f395b901198befac92278d23bf38254@localhost.localdomain> I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. ---------- hello! ---------- Thanks, Vahid To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=1485341899&k=5VCUZ2U23ZVM5DDFPD4ZU4&r This e-mail may contain promotional materials. If you do not wish to receive future commercial mailings from Facebook, please click on the link below. Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. http://www.facebook.com/o.php?k=e1b487&u=1606162649&mid=32cf26G5fbc18d9G0G8 From avg at icyb.net.ua Tue Mar 24 06:34:00 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Mar 24 06:34:07 2009 Subject: shutdown via power button: "acpi: resumed at..." Message-ID: <49C8E143.2080305@icyb.net.ua> I noticed that sometimes I am getting "acpi: resumed at..." message on console and in system log when I initiate system shutdown by pressing power button. I think that the cause is in acpi_UserNotify("Resume") call and this call is only found in acpi_EnterSleepState(). I see the following code in that function: case ACPI_STATE_S5: /* * Shut down cleanly and power off. This will call us back through the * shutdown handlers. */ shutdown_nice(RB_POWEROFF); break; So it seems that it is expected that shutdown_nice() would return immediately. I think it makes S5 a special case comparing to other states where return happens upon resuming from the state. In this case, maybe it is not necessary for S5 request to go through the resume/wakeup half of acpi_EnterSleepState. -- Andriy Gapon From pasi.parviainen at iki.fi Tue Mar 24 12:40:10 2009 From: pasi.parviainen at iki.fi (Pasi Parviainen) Date: Tue Mar 24 12:40:43 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49C80E65.9090500@onetel.com> References: <49C80E65.9090500@onetel.com> Message-ID: <49C93309.6050708@iki.fi> Chris Whitehouse wrote: > Hi, I sent this a while ago but don't think there was a reply. I'm about > to embark on a custom ASL to load in loader.conf as per > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > wondering if their might be a 'proper' fix on the way. I do have the > latest bios installed. Loading custom ASL with modified _CRT value for temperature zone in question will solve the problem, see below for more information. > Would it help if I installed 8-CURRENT? Probably not, see below. > -------- Original Message -------- > Subject: pr kern/105537 > Date: Mon, 12 Jan 2009 15:00:49 +0000 > From: Chris Whitehouse > To: freebsd-acpi@FreeBSD.org > > hi, > > Please would you cc me in any reply as I'm not subscribed, thanks. > > I have the same problem noted in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > of frequent messages saying > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > on my HP nc6320 laptop, model RH383ET. > I have HP 6510b and HP 2510p laptops and had same problem with those. Actual problem is that the ACPI thermal code in kernel does sanity-check for temperature values, and accepts only values between 0 - 200 Celsius. To solve the problem you either create custom DSDT which returns 200.0C value instead of 256.0C for thermal zone in question or increase the limit of the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c function: acpi_tz_sanity). Proper way to solve this in my opinion is to increase the range of sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at least provide sysctl variable to disable thermal sanity-checks. From smithi at nimnet.asn.au Tue Mar 24 20:30:12 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Mar 24 20:30:21 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49C93309.6050708@iki.fi> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> Message-ID: <20090325140718.J95588@sola.nimnet.asn.au> On Tue, 24 Mar 2009, Pasi Parviainen wrote: > Chris Whitehouse wrote: > > Hi, I sent this a while ago but don't think there was a reply. I'm about to > > embark on a custom ASL to load in loader.conf as per > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > > wondering if their might be a 'proper' fix on the way. I do have the latest > > bios installed. > > Loading custom ASL with modified _CRT value for temperature zone in > question will solve the problem, see below for more information. > > > Would it help if I installed 8-CURRENT? > > Probably not, see below. > > > -------- Original Message -------- > > Subject: pr kern/105537 > > Date: Mon, 12 Jan 2009 15:00:49 +0000 > > From: Chris Whitehouse > > To: freebsd-acpi@FreeBSD.org > > > > hi, > > > > Please would you cc me in any reply as I'm not subscribed, thanks. > > > > I have the same problem noted in > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > > > of frequent messages saying > > > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > > > on my HP nc6320 laptop, model RH383ET. > > > > I have HP 6510b and HP 2510p laptops and had same problem with those. > Actual problem is that the ACPI thermal code in kernel does sanity-check > for temperature values, and accepts only values between 0 - 200 Celsius. > To solve the problem you either create custom DSDT which returns 200.0C > value instead of 256.0C for thermal zone in question or increase the limit of > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c > function: acpi_tz_sanity). > > Proper way to solve this in my opinion is to increase the range of > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at > least provide sysctl variable to disable thermal sanity-checks. Even 200C is absurd, really. That's above the melting point of many types of solder (http://www.rfcafe.com/references/electrical/solder.htm) while 256C exceeds the melting point of _most_ types of solder. I seem to recall that this limit used to be 150C, still hotter than anything you actually want to have anywhere on a computer board. No sense checking sanity to then accept insane values; fix the broken ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? cheers, Ian From cwhiteh at onetel.com Wed Mar 25 01:30:23 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Wed Mar 25 01:30:35 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49C81A84.7060004@root.org> References: <49C80E65.9090500@onetel.com> <49C81A84.7060004@root.org> Message-ID: <49C9EB9B.4020601@onetel.com> Nate Lawson wrote: > It's probably the EC timing out, not ASL. > > -Nate Someone on questions@ noted recently he had fixed something very similar with a custom ASL so I thought I would have a go. What is EC? Chris > > Chris Whitehouse wrote: >> Hi, I sent this a while ago but don't think there was a reply. I'm about >> to embark on a custom ASL to load in loader.conf as per >> http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just >> wondering if their might be a 'proper' fix on the way. I do have the >> latest bios installed. >> >> Would it help if I installed 8-CURRENT? >> >> As below please would you cc me in any reply as I'm not subscribed. >> >> Thanks >> >> Chris >> >> -------- Original Message -------- >> Subject: pr kern/105537 >> Date: Mon, 12 Jan 2009 15:00:49 +0000 >> From: Chris Whitehouse >> To: freebsd-acpi@FreeBSD.org >> >> hi, >> >> Please would you cc me in any reply as I'm not subscribed, thanks. >> >> I have the same problem noted in >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 >> >> of frequent messages saying >> >> acpi_tz0: _CRT value is absurd, ignored (256.0C) >> >> on my HP nc6320 laptop, model RH383ET. >> >> Is there any progress on this PR? Would it help if I arranged root >> access on this machine for someone to have a look at it? >> >> Currently has PCBSD but I can replace that with something else if required. >> >> FreeBSD muji 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Mon Nov 24 >> 20:22:16 EST 2008 >> root@pcbsdx32-7:/usr/obj/pcbsd-build/cvs/7.0.2-src/sys/PCBSD i386 >> >> >> thanks >> >> Chris >> >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > From cwhiteh at onetel.com Wed Mar 25 01:42:07 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Wed Mar 25 01:42:14 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <20090325140718.J95588@sola.nimnet.asn.au> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> Message-ID: <49C9EE50.6070507@onetel.com> [Please would you cc me in any reply as I'm not subscribed, thanks.] Ian Smith wrote: > On Tue, 24 Mar 2009, Pasi Parviainen wrote: > > Chris Whitehouse wrote: > > > Hi, I sent this a while ago but don't think there was a reply. I'm about to > > > embark on a custom ASL to load in loader.conf as per > > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > > > wondering if their might be a 'proper' fix on the way. I do have the latest > > > bios installed. > > > > Loading custom ASL with modified _CRT value for temperature zone in > > question will solve the problem, see below for more information. > > > > > Would it help if I installed 8-CURRENT? > > > > Probably not, see below. > > > > > -------- Original Message -------- > > > Subject: pr kern/105537 > > > Date: Mon, 12 Jan 2009 15:00:49 +0000 > > > From: Chris Whitehouse > > > To: freebsd-acpi@FreeBSD.org > > > > > > hi, > > > > > > Please would you cc me in any reply as I'm not subscribed, thanks. > > > > > > I have the same problem noted in > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > > > > > of frequent messages saying > > > > > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > > > > > on my HP nc6320 laptop, model RH383ET. > > > > > > > I have HP 6510b and HP 2510p laptops and had same problem with those. > > Actual problem is that the ACPI thermal code in kernel does sanity-check > > for temperature values, and accepts only values between 0 - 200 Celsius. > > To solve the problem you either create custom DSDT which returns 200.0C > > value instead of 256.0C for thermal zone in question or increase the limit of > > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c > > function: acpi_tz_sanity). > > > > Proper way to solve this in my opinion is to increase the range of > > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at > > least provide sysctl variable to disable thermal sanity-checks. > > Even 200C is absurd, really. That's above the melting point of many > types of solder (http://www.rfcafe.com/references/electrical/solder.htm) > while 256C exceeds the melting point of _most_ types of solder. I seem > to recall that this limit used to be 150C, still hotter than anything > you actually want to have anywhere on a computer board. > > No sense checking sanity to then accept insane values; fix the broken > ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? > > cheers, Ian > Getting the ASL in the actual BIOS firmware fixed would be great, but I tried once to get Asus to correct a byte swapped value without success. I don't suppose HP will be any more cooperative but I can try. I will have a look at an acpidump tonight. A custom ASL would at least prove what is wrong. Does anyone know what this value is supposed to be measuring? Chris From smithi at nimnet.asn.au Wed Mar 25 03:02:26 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Wed Mar 25 03:02:33 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49C9EE50.6070507@onetel.com> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> Message-ID: <20090325203237.F95588@sola.nimnet.asn.au> On Wed, 25 Mar 2009, Chris Whitehouse wrote: > Getting the ASL in the actual BIOS firmware fixed would be great, but I tried > once to get Asus to correct a byte swapped value without success. I don't > suppose HP will be any more cooperative but I can try. I will have a look at > an acpidump tonight. A custom ASL would at least prove what is wrong. Well, it might fix it, too .. unless Nate's suspicion about the Embedded Controller timing out is right. I don't know how that might be fixed. > Does anyone know what this value is supposed to be measuring? Maybe sysctl hw.acpi.thermal would provide a clue? cheers, Ian From gaijin.k at gmail.com Wed Mar 25 08:05:47 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Wed Mar 25 08:05:54 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49C9EE50.6070507@onetel.com> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> Message-ID: <1237992462.1297.22.camel@RabbitsDen> On Wed, 2009-03-25 at 08:41 +0000, Chris Whitehouse wrote: > [Please would you cc me in any reply as I'm not subscribed, thanks.] > > Ian Smith wrote: > > On Tue, 24 Mar 2009, Pasi Parviainen wrote: > > > Chris Whitehouse wrote: > > > > Hi, I sent this a while ago but don't think there was a reply. I'm about to > > > > embark on a custom ASL to load in loader.conf as per > > > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > > > > wondering if their might be a 'proper' fix on the way. I do have the latest > > > > bios installed. > > > > > > Loading custom ASL with modified _CRT value for temperature zone in > > > question will solve the problem, see below for more information. > > > > > > > Would it help if I installed 8-CURRENT? > > > > > > Probably not, see below. > > > > > > > -------- Original Message -------- > > > > Subject: pr kern/105537 > > > > Date: Mon, 12 Jan 2009 15:00:49 +0000 > > > > From: Chris Whitehouse > > > > To: freebsd-acpi@FreeBSD.org > > > > > > > > hi, > > > > > > > > Please would you cc me in any reply as I'm not subscribed, thanks. > > > > > > > > I have the same problem noted in > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > > > > > > > > of frequent messages saying > > > > > > > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > > > > > > > > on my HP nc6320 laptop, model RH383ET. > > > > > > > > > > I have HP 6510b and HP 2510p laptops and had same problem with those. > > > Actual problem is that the ACPI thermal code in kernel does sanity-check > > > for temperature values, and accepts only values between 0 - 200 Celsius. > > > To solve the problem you either create custom DSDT which returns 200.0C > > > value instead of 256.0C for thermal zone in question or increase the limit of > > > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c > > > function: acpi_tz_sanity). > > > > > > Proper way to solve this in my opinion is to increase the range of > > > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at > > > least provide sysctl variable to disable thermal sanity-checks. > > > > Even 200C is absurd, really. That's above the melting point of many > > types of solder (http://www.rfcafe.com/references/electrical/solder.htm) > > while 256C exceeds the melting point of _most_ types of solder. I seem > > to recall that this limit used to be 150C, still hotter than anything > > you actually want to have anywhere on a computer board. > > > > No sense checking sanity to then accept insane values; fix the broken > > ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? > > > > cheers, Ian > > > > Getting the ASL in the actual BIOS firmware fixed would be great, but I > tried once to get Asus to correct a byte swapped value without success. > I don't suppose HP will be any more cooperative but I can try. I will > have a look at an acpidump tonight. A custom ASL would at least prove > what is wrong. > > Does anyone know what this value is supposed to be measuring? _CRT method in ASL is supposed to return temperature (in the tenth of Kelvin) at which you would like to have your computer shut down rather rapidly. On my ThinkPad X60 it is 97C. Overriding ASL is simple, if you are following the instruction in the "Handbook", but the ease of fixing it really depends on what is broken. Your case does not seem to look like the most popular exercise by the BIOS writers -- returning temperature in the whole degrees of Celsius, resulting in absurd negative values. If you would like to post your ASL someplace and send out link to it or forward it to me privately, I can take a look at it. I make no promises -- unless it is something obvious it will require understanding of your specific hardware. To be fair, if all you want is to override _CRT, you should be able to put something to the tune of hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0._CRT=90C in your /etc/sysctl.conf and not deal with the ASL at all. You might want to take a look at your output of 'sysctl hw.acpi.thermal' -- your specific thermal zone, might be different from the one, I have used as an example above. In fact, on my laptop, it is tz1 and not tz0. In either case, I would recommend reading thermal chapter of the ACPI specification -- it is short, well-written and has an example, I was stealing stuff from, shamelessly, in the past. HTH, -- Alexandre "Sunny" Kovalenko From nate at root.org Wed Mar 25 09:06:41 2009 From: nate at root.org (Nate Lawson) Date: Wed Mar 25 09:06:48 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <1237992462.1297.22.camel@RabbitsDen> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> Message-ID: <49CA568B.6030305@root.org> Alexandre "Sunny" Kovalenko wrote: > On Wed, 2009-03-25 at 08:41 +0000, Chris Whitehouse wrote: >> [Please would you cc me in any reply as I'm not subscribed, thanks.] >> >> Ian Smith wrote: >>> On Tue, 24 Mar 2009, Pasi Parviainen wrote: >>> > Chris Whitehouse wrote: >>> > > Hi, I sent this a while ago but don't think there was a reply. I'm about to >>> > > embark on a custom ASL to load in loader.conf as per >>> > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just >>> > > wondering if their might be a 'proper' fix on the way. I do have the latest >>> > > bios installed. >>> > >>> > Loading custom ASL with modified _CRT value for temperature zone in >>> > question will solve the problem, see below for more information. >>> > >>> > > Would it help if I installed 8-CURRENT? >>> > >>> > Probably not, see below. >>> > >>> > > -------- Original Message -------- >>> > > Subject: pr kern/105537 >>> > > Date: Mon, 12 Jan 2009 15:00:49 +0000 >>> > > From: Chris Whitehouse >>> > > To: freebsd-acpi@FreeBSD.org >>> > > >>> > > hi, >>> > > >>> > > Please would you cc me in any reply as I'm not subscribed, thanks. >>> > > >>> > > I have the same problem noted in >>> > > >>> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 >>> > > >>> > > of frequent messages saying >>> > > >>> > > acpi_tz0: _CRT value is absurd, ignored (256.0C) >>> > > >>> > > on my HP nc6320 laptop, model RH383ET. >>> > > >>> > >>> > I have HP 6510b and HP 2510p laptops and had same problem with those. >>> > Actual problem is that the ACPI thermal code in kernel does sanity-check >>> > for temperature values, and accepts only values between 0 - 200 Celsius. >>> > To solve the problem you either create custom DSDT which returns 200.0C >>> > value instead of 256.0C for thermal zone in question or increase the limit of >>> > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c >>> > function: acpi_tz_sanity). >>> > >>> > Proper way to solve this in my opinion is to increase the range of >>> > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at >>> > least provide sysctl variable to disable thermal sanity-checks. >>> >>> Even 200C is absurd, really. That's above the melting point of many >>> types of solder (http://www.rfcafe.com/references/electrical/solder.htm) >>> while 256C exceeds the melting point of _most_ types of solder. I seem >>> to recall that this limit used to be 150C, still hotter than anything >>> you actually want to have anywhere on a computer board. >>> >>> No sense checking sanity to then accept insane values; fix the broken >>> ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? >>> >>> cheers, Ian >>> >> Getting the ASL in the actual BIOS firmware fixed would be great, but I >> tried once to get Asus to correct a byte swapped value without success. >> I don't suppose HP will be any more cooperative but I can try. I will >> have a look at an acpidump tonight. A custom ASL would at least prove >> what is wrong. >> >> Does anyone know what this value is supposed to be measuring? > _CRT method in ASL is supposed to return temperature (in the tenth of > Kelvin) at which you would like to have your computer shut down rather > rapidly. On my ThinkPad X60 it is 97C. > > To be fair, if all you want is to override _CRT, you should be able to > put something to the tune of > > hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz0._CRT=90C > > in your /etc/sysctl.conf and not deal with the ASL at all. Yes, this is the best way instead of messing with ASL. -- Nate From nate at root.org Wed Mar 25 09:08:14 2009 From: nate at root.org (Nate Lawson) Date: Wed Mar 25 09:08:21 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49C9EB9B.4020601@onetel.com> References: <49C80E65.9090500@onetel.com> <49C81A84.7060004@root.org> <49C9EB9B.4020601@onetel.com> Message-ID: <49CA56E6.3030509@root.org> Chris Whitehouse wrote: > Nate Lawson wrote: >> It's probably the EC timing out, not ASL. >> >> -Nate > > Someone on questions@ noted recently he had fixed something very similar > with a custom ASL so I thought I would have a go. What is EC? > > Chris I misread the original message. _CRT is usually not reported by the embedded controller. It is hard-coded. If you saw a stray temperature reading that was incorrect, that is probably the EC. -- Nate From nate at root.org Wed Mar 25 09:12:21 2009 From: nate at root.org (Nate Lawson) Date: Wed Mar 25 09:12:28 2009 Subject: shutdown via power button: "acpi: resumed at..." In-Reply-To: <49C8E143.2080305@icyb.net.ua> References: <49C8E143.2080305@icyb.net.ua> Message-ID: <49CA57E2.7090805@root.org> Andriy Gapon wrote: > I noticed that sometimes I am getting "acpi: resumed at..." message on console and > in system log when I initiate system shutdown by pressing power button. > I think that the cause is in acpi_UserNotify("Resume") call and this call is only > found in acpi_EnterSleepState(). > > I see the following code in that function: > case ACPI_STATE_S5: > /* > * Shut down cleanly and power off. This will call us back through the > * shutdown handlers. > */ > shutdown_nice(RB_POWEROFF); > break; > > So it seems that it is expected that shutdown_nice() would return immediately. > I think it makes S5 a special case comparing to other states where return happens > upon resuming from the state. > In this case, maybe it is not necessary for S5 request to go through the > resume/wakeup half of acpi_EnterSleepState. > I thought shutdown*() should never return at all. It sounds like interrupts are being re-enabled or something. -- Nate From avg at icyb.net.ua Wed Mar 25 09:24:49 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Mar 25 09:24:56 2009 Subject: shutdown via power button: "acpi: resumed at..." In-Reply-To: <49CA57E2.7090805@root.org> References: <49C8E143.2080305@icyb.net.ua> <49CA57E2.7090805@root.org> Message-ID: <49CA5AC9.1040601@icyb.net.ua> on 25/03/2009 18:12 Nate Lawson said the following: > Andriy Gapon wrote: >> I noticed that sometimes I am getting "acpi: resumed at..." message on console and >> in system log when I initiate system shutdown by pressing power button. >> I think that the cause is in acpi_UserNotify("Resume") call and this call is only >> found in acpi_EnterSleepState(). >> >> I see the following code in that function: >> case ACPI_STATE_S5: >> /* >> * Shut down cleanly and power off. This will call us back through the >> * shutdown handlers. >> */ >> shutdown_nice(RB_POWEROFF); >> break; >> >> So it seems that it is expected that shutdown_nice() would return immediately. >> I think it makes S5 a special case comparing to other states where return happens >> upon resuming from the state. >> In this case, maybe it is not necessary for S5 request to go through the >> resume/wakeup half of acpi_EnterSleepState. >> > > I thought shutdown*() should never return at all. It sounds like > interrupts are being re-enabled or something. > No, this is a different kind of shutdown, this one just send a signal to init: void shutdown_nice(int howto) { shutdown_howto = howto; /* Send a signal to init(8) and have it shutdown the world */ if (initproc != NULL) { PROC_LOCK(initproc); psignal(initproc, SIGINT); PROC_UNLOCK(initproc); } else { /* No init(8) running, so simply reboot */ boot(RB_NOSYNC); } return; } -- Andriy Gapon From nate at root.org Wed Mar 25 09:28:49 2009 From: nate at root.org (Nate Lawson) Date: Wed Mar 25 09:28:55 2009 Subject: shutdown via power button: "acpi: resumed at..." In-Reply-To: <49CA5AC9.1040601@icyb.net.ua> References: <49C8E143.2080305@icyb.net.ua> <49CA57E2.7090805@root.org> <49CA5AC9.1040601@icyb.net.ua> Message-ID: <49CA5BBE.2040305@root.org> Andriy Gapon wrote: > on 25/03/2009 18:12 Nate Lawson said the following: >> Andriy Gapon wrote: >>> I noticed that sometimes I am getting "acpi: resumed at..." message on console and >>> in system log when I initiate system shutdown by pressing power button. >>> I think that the cause is in acpi_UserNotify("Resume") call and this call is only >>> found in acpi_EnterSleepState(). >>> >>> I see the following code in that function: >>> case ACPI_STATE_S5: >>> /* >>> * Shut down cleanly and power off. This will call us back through the >>> * shutdown handlers. >>> */ >>> shutdown_nice(RB_POWEROFF); >>> break; >>> >>> So it seems that it is expected that shutdown_nice() would return immediately. >>> I think it makes S5 a special case comparing to other states where return happens >>> upon resuming from the state. >>> In this case, maybe it is not necessary for S5 request to go through the >>> resume/wakeup half of acpi_EnterSleepState. >>> >> I thought shutdown*() should never return at all. It sounds like >> interrupts are being re-enabled or something. >> > > No, this is a different kind of shutdown, this one just send a signal to init: > void > shutdown_nice(int howto) > { > > shutdown_howto = howto; > > /* Send a signal to init(8) and have it shutdown the world */ > if (initproc != NULL) { > PROC_LOCK(initproc); > psignal(initproc, SIGINT); > PROC_UNLOCK(initproc); > } else { > /* No init(8) running, so simply reboot */ > boot(RB_NOSYNC); > } > return; > } But the shutdown that is initiated through ACPI is RB_POWEROFF. There should be no returning from there. What has changed in the code so that RB_POWEROFF does not immediately call back into acpi_shutdown_final() which powers off the system? Anyway, the resume notification could be moved under the "if (state != S5)" line right above it if this behavior is legal. -- Nate From avg at icyb.net.ua Wed Mar 25 09:41:12 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Mar 25 09:41:17 2009 Subject: shutdown via power button: "acpi: resumed at..." In-Reply-To: <49CA5BBE.2040305@root.org> References: <49C8E143.2080305@icyb.net.ua> <49CA57E2.7090805@root.org> <49CA5AC9.1040601@icyb.net.ua> <49CA5BBE.2040305@root.org> Message-ID: <49CA5EA3.3000500@icyb.net.ua> on 25/03/2009 18:28 Nate Lawson said the following: > Andriy Gapon wrote: >> on 25/03/2009 18:12 Nate Lawson said the following: >>> Andriy Gapon wrote: >>>> I noticed that sometimes I am getting "acpi: resumed at..." message on console and >>>> in system log when I initiate system shutdown by pressing power button. >>>> I think that the cause is in acpi_UserNotify("Resume") call and this call is only >>>> found in acpi_EnterSleepState(). >>>> >>>> I see the following code in that function: >>>> case ACPI_STATE_S5: >>>> /* >>>> * Shut down cleanly and power off. This will call us back through the >>>> * shutdown handlers. >>>> */ >>>> shutdown_nice(RB_POWEROFF); >>>> break; >>>> >>>> So it seems that it is expected that shutdown_nice() would return immediately. >>>> I think it makes S5 a special case comparing to other states where return happens >>>> upon resuming from the state. >>>> In this case, maybe it is not necessary for S5 request to go through the >>>> resume/wakeup half of acpi_EnterSleepState. >>>> >>> I thought shutdown*() should never return at all. It sounds like >>> interrupts are being re-enabled or something. >>> >> No, this is a different kind of shutdown, this one just send a signal to init: >> void >> shutdown_nice(int howto) >> { >> >> shutdown_howto = howto; >> >> /* Send a signal to init(8) and have it shutdown the world */ >> if (initproc != NULL) { >> PROC_LOCK(initproc); >> psignal(initproc, SIGINT); >> PROC_UNLOCK(initproc); >> } else { >> /* No init(8) running, so simply reboot */ >> boot(RB_NOSYNC); >> } >> return; >> } > > But the shutdown that is initiated through ACPI is RB_POWEROFF. Not sure what exactly you meant here, so can't argue, just can comment - we are just handing power button press in acpi_EnterSleepState. > There > should be no returning from there. What has changed in the code so that > RB_POWEROFF does not immediately call back into acpi_shutdown_final() > which powers off the system? I am not sure what you are asking here, so I can't answer, but... power off or not, shouldn't userland be given a chance to shutdown gracefully? I thought it always worked this way. > Anyway, the resume notification could be moved under the "if (state != > S5)" line right above it if this behavior is legal. > Yes, I also think so. -- Andriy Gapon From gaijin.k at gmail.com Wed Mar 25 09:42:10 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Wed Mar 25 09:42:16 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49CA568B.6030305@root.org> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CA568B.6030305@root.org> Message-ID: <1237999314.83221.20.camel@RabbitsDen> On Wed, 2009-03-25 at 09:06 -0700, Nate Lawson wrote: > > Alexandre "Sunny" Kovalenko wrote: > > On Wed, 2009-03-25 at 08:41 +0000, Chris Whitehouse wrote: > >> [Please would you cc me in any reply as I'm not subscribed, thanks.] > >> > >> Ian Smith wrote: > >>> On Tue, 24 Mar 2009, Pasi Parviainen wrote: > >>> > Chris Whitehouse wrote: > >>> > > Hi, I sent this a while ago but don't think there was a reply. I'm about to > >>> > > embark on a custom ASL to load in loader.conf as per > >>> > > http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just > >>> > > wondering if their might be a 'proper' fix on the way. I do have the latest > >>> > > bios installed. > >>> > > >>> > Loading custom ASL with modified _CRT value for temperature zone in > >>> > question will solve the problem, see below for more information. > >>> > > >>> > > Would it help if I installed 8-CURRENT? > >>> > > >>> > Probably not, see below. > >>> > > >>> > > -------- Original Message -------- > >>> > > Subject: pr kern/105537 > >>> > > Date: Mon, 12 Jan 2009 15:00:49 +0000 > >>> > > From: Chris Whitehouse > >>> > > To: freebsd-acpi@FreeBSD.org > >>> > > > >>> > > hi, > >>> > > > >>> > > Please would you cc me in any reply as I'm not subscribed, thanks. > >>> > > > >>> > > I have the same problem noted in > >>> > > > >>> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/105537 > >>> > > > >>> > > of frequent messages saying > >>> > > > >>> > > acpi_tz0: _CRT value is absurd, ignored (256.0C) > >>> > > > >>> > > on my HP nc6320 laptop, model RH383ET. > >>> > > > >>> > > >>> > I have HP 6510b and HP 2510p laptops and had same problem with those. > >>> > Actual problem is that the ACPI thermal code in kernel does sanity-check > >>> > for temperature values, and accepts only values between 0 - 200 Celsius. > >>> > To solve the problem you either create custom DSDT which returns 200.0C > >>> > value instead of 256.0C for thermal zone in question or increase the limit of > >>> > the sanity-check code of ACPI thermal code (src/sys/dev/acpica/acpi_thermal.c > >>> > function: acpi_tz_sanity). > >>> > > >>> > Proper way to solve this in my opinion is to increase the range of > >>> > sanity-check function from 0 - 200 Celsius to 0 - 256 Celsius, or at > >>> > least provide sysctl variable to disable thermal sanity-checks. > >>> > >>> Even 200C is absurd, really. That's above the melting point of many > >>> types of solder (http://www.rfcafe.com/references/electrical/solder.htm) > >>> while 256C exceeds the melting point of _most_ types of solder. I seem > >>> to recall that this limit used to be 150C, still hotter than anything > >>> you actually want to have anywhere on a computer board. > >>> > >>> No sense checking sanity to then accept insane values; fix the broken > >>> ASL. 256 sounds suspiciously like a byte-swapped value, perhaps? > >>> > >>> cheers, Ian > >>> > >> Getting the ASL in the actual BIOS firmware fixed would be great, but I > >> tried once to get Asus to correct a byte swapped value without success. > >> I don't suppose HP will be any more cooperative but I can try. I will > >> have a look at an acpidump tonight. A custom ASL would at least prove > >> what is wrong. > >> > >> Does anyone know what this value is supposed to be measuring? > > _CRT method in ASL is supposed to return temperature (in the tenth of > > Kelvin) at which you would like to have your computer shut down rather > > rapidly. On my ThinkPad X60 it is 97C. > > > > > To be fair, if all you want is to override _CRT, you should be able to > > put something to the tune of > > > > hw.acpi.thermal.user_override=1 > > hw.acpi.thermal.tz0._CRT=90C > > > > in your /etc/sysctl.conf and not deal with the ASL at all. > > Yes, this is the best way instead of messing with ASL. > While it is true that, unlike _PSV, _CRT should not be changed while OS is running, it is not impossible to imagine that it could be calculated at boot, taking into account point-in-time configuration of the hardware (and causing EC timeout in process). Hence, I would recommend looking into ASL anyway, at least so OP understands what he is giving up by hardcoding the value. If I am not mistaken, 256C should look like Return(0x14AD), which is somewhat odd a number to say the least. Besides, FreeBSD makes ASL overriding so easy ;) -- Alexandre "Sunny" Kovalenko From getmoney at jinno.com Wed Mar 25 13:18:46 2009 From: getmoney at jinno.com (Fast Money) Date: Wed Mar 25 13:18:53 2009 Subject: Click-Paid.Com Message-ID: <00fce596-39897-08668871352315@amd> <<< The Project is Paying!>>> Join This site New PTC Project!!! http://click-paid.com >>>>> Join Now!!! <<<<< From bruce at cran.org.uk Wed Mar 25 15:39:37 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Wed Mar 25 15:39:45 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <200903200030.n2K0U3iG011009@freefall.freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> Message-ID: <20090325223914.4387eeae@gluon.draftnet> On Fri, 20 Mar 2009 00:30:03 GMT Daniel Dvo??k wrote: > The following reply was made to PR kern/108581; it has been noted by > GNATS. > > From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= > To: , > > Cc: > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > > This is a multi-part message in MIME format. > > ------=_NextPart_000_0007_01C9A8F7.746C4190 > Content-Type: text/plain; > charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Hi acpi team, > =20 > today I have installed fbsd 7.1R on one box with this relativly old = > error and I was surprised about results .. it is the same: > =20 > # uname -a > FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > 14:37:25 = UTC 2009 > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386 > > # sysctl dev.cpu.0.cx_supported > dev.cpu.0.cx_supported: C1/0 > > # sysctl hw.acpi.cpu.cx_lowest=3DC1 > hw.acpi.cpu.cx_lowest: C1 > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > =20 > # sysctl hw.acpi.cpu.cx_lowest=3DC0 > hw.acpi.cpu.cx_lowest: C1 > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > =20 > # sysctl hw.acpi.cpu.cx_lowest=3DC1/0 > hw.acpi.cpu.cx_lowest: C1 > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > # dmesg -a | grep "acpi" > acpi0: on motherboard > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, ff00000 (3) failed > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > acpi0 acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > cpu0: on acpi0 > hw.acpi.cpu.cx_lowest: > hw.acpi.cpu.cx_lowest I think I've found the problem and have updated the PR kern/108581 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108581). The global cpu_cx_count was being initialized to 0 in acpi_cpu_startup (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume that it's been intialized to 3 because it only sets it if it's higher than the current CPU supports - that is, cpu_cx_count should reflect the highest Cx state that all CPUs support. There's also a bug in the _CST section just below it; I think the line: if (sc->cpu_cx_count > cpu_cx_count) should be if (sc->cpu_cx_count < cpu_cx_count) -- Bruce Cran From bruce at cran.org.uk Wed Mar 25 15:40:05 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Wed Mar 25 15:40:11 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Message-ID: <200903252240.n2PMe4eZ073657@freefall.freebsd.org> The following reply was made to PR kern/108581; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, lars.stokholm@gmail.com Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Wed, 25 Mar 2009 22:32:16 +0000 In acpi_cpu_startup in /sys/dev/acpi_cpu.c cpu_cx_count is initialized to 0. If the generic Cx mode is being used (which it appears to be on older CPUs) then a loop is run over all the CPUs to find the highest Cx state common to all of them. However that code assumes that cpu_cx_count has been initialized too *high*, since it only sets it if it finds a CPU with a maximum Cx state lower than the current value of cpu_cx_count. This means that while setting the per-CPU cx_lowest sysctl works because it correctly gets initialized to 1 in acpi_cpu_generic_cx_probe, the global systl hw.acpi.cpu.cx_lowest always fails because it thinks there are no Cx states. Initializing cpu_cx_count to 3 instead of 0 should fix the problem. There appears to be a related bug in the _CST mode handling below; if there exists a CPU in the system which supports a higher Cx state than the others, the global cx_cpu_count will be set too high if the purpose of that sysctl is to reflect the maximum Cx state that all CPUs support. -- Bruce From bruce at cran.org.uk Wed Mar 25 16:20:05 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Wed Mar 25 16:25:39 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Message-ID: <200903252320.n2PNK4nj033068@freefall.freebsd.org> The following reply was made to PR kern/108581; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, lars.stokholm@gmail.com Cc: Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Wed, 25 Mar 2009 23:13:55 +0000 --MP_/.Mqqm3g9tTbq0b=KU9SrVSj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline --MP_/.Mqqm3g9tTbq0b=KU9SrVSj Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=acpi_cpu.c.diff.txt --- acpi_cpu.c 2009-03-25 23:06:24.000000000 +0000 +++ sys/dev/acpica/acpi_cpu.c 2009-03-25 23:07:45.000000000 +0000 @@ -742,7 +742,7 @@ */ acpi_cpu_quirks(); - cpu_cx_count = 0; + cpu_cx_count = 3; if (cpu_cx_generic) { /* * We are using generic Cx mode, probe for available Cx states @@ -775,7 +775,7 @@ if (cpu_quirks & CPU_QUIRK_NO_C3) { sc->cpu_cx_count = sc->cpu_non_c3 + 1; } - if (sc->cpu_cx_count > cpu_cx_count) + if (sc->cpu_cx_count < cpu_cx_count) cpu_cx_count = sc->cpu_cx_count; AcpiInstallNotifyHandler(sc->cpu_handle, ACPI_DEVICE_NOTIFY, acpi_cpu_notify, sc); --MP_/.Mqqm3g9tTbq0b=KU9SrVSj-- From jhb at freebsd.org Thu Mar 26 06:57:09 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Mar 26 06:57:16 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <20090325223914.4387eeae@gluon.draftnet> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> Message-ID: <200903260937.51028.jhb@freebsd.org> On Wednesday 25 March 2009 6:39:14 pm Bruce Cran wrote: > On Fri, 20 Mar 2009 00:30:03 GMT > Daniel Dvo??k wrote: > > > The following reply was made to PR kern/108581; it has been noted by > > GNATS. > > > > From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= > > To: , > > > > Cc: > > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > > > > This is a multi-part message in MIME format. > > > > ------=_NextPart_000_0007_01C9A8F7.746C4190 > > Content-Type: text/plain; > > charset="UTF-8" > > Content-Transfer-Encoding: quoted-printable > > > > Hi acpi team, > > =20 > > today I have installed fbsd 7.1R on one box with this relativly old = > > error and I was surprised about results .. it is the same: > > =20 > > # uname -a > > FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > > 14:37:25 = UTC 2009 > > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386 > > > > # sysctl dev.cpu.0.cx_supported > > dev.cpu.0.cx_supported: C1/0 > > > > # sysctl hw.acpi.cpu.cx_lowest=3DC1 > > hw.acpi.cpu.cx_lowest: C1 > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > =20 > > # sysctl hw.acpi.cpu.cx_lowest=3DC0 > > hw.acpi.cpu.cx_lowest: C1 > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > =20 > > # sysctl hw.acpi.cpu.cx_lowest=3DC1/0 > > hw.acpi.cpu.cx_lowest: C1 > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > > # dmesg -a | grep "acpi" > > acpi0: on motherboard > > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > > acpi0: [ITHREAD] > > acpi0: Power Button (fixed) > > acpi0: reservation of 0, a0000 (3) failed > > acpi0: reservation of 100000, ff00000 (3) failed > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > > acpi0 acpi_button0: on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > cpu0: on acpi0 > > hw.acpi.cpu.cx_lowest: > > hw.acpi.cpu.cx_lowest > > I think I've found the problem and have updated the PR kern/108581 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108581). The global > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume that > it's been intialized to 3 because it only sets it if it's higher than > the current CPU supports - that is, cpu_cx_count should reflect the > highest Cx state that all CPUs support. > > There's also a bug in the _CST section just below it; I think the line: > > if (sc->cpu_cx_count > cpu_cx_count) > > should be > > if (sc->cpu_cx_count < cpu_cx_count) No, the code is doing things differently on purpose (though I'm not completely sure why). For _CST it sets cpu_cx_count to the maximum Cx level supported by any CPU in the system. For non-_CST it sets it to the maximum Cx level supported by all CPUs in the system. I think it is correct for cpu_cx_count to always start at 0 and only be bumped up to a higher setting. Setting it to 3 would be very wrong for the _CST case as I've seen CPUs that support C4. Note that C1 _always_ exists as it is simply the "hlt" instruction that has existed since the 8086. Only C2+ require power-saving extension support in the CPU, so cpu_cx_count should always end up >= 1. It would be interesting if you could add some debug printfs to print out the values that acpi_cpu_generic_cx_probe() computes for 'sc->cpu_cx_count' (sysctl dev.cpu could be useful for this) as well as all changes to the 'cpu_cx_count' global variable. -- John Baldwin From avg at icyb.net.ua Thu Mar 26 07:09:17 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Mar 26 07:09:25 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <20090325223914.4387eeae@gluon.draftnet> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> Message-ID: <49CB8C86.4020800@icyb.net.ua> on 26/03/2009 00:39 Bruce Cran said the following: > On Fri, 20 Mar 2009 00:30:03 GMT > Daniel Dvo??k wrote: > >> The following reply was made to PR kern/108581; it has been noted by >> GNATS. >> >> From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= >> To: , >> >> Cc: >> Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: >> Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 >> >> This is a multi-part message in MIME format. >> >> ------=_NextPart_000_0007_01C9A8F7.746C4190 >> Content-Type: text/plain; >> charset="UTF-8" >> Content-Transfer-Encoding: quoted-printable >> >> Hi acpi team, >> =20 >> today I have installed fbsd 7.1R on one box with this relativly old = >> error and I was surprised about results .. it is the same: >> =20 >> # uname -a >> FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 >> 14:37:25 = UTC 2009 >> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386 >> >> # sysctl dev.cpu.0.cx_supported >> dev.cpu.0.cx_supported: C1/0 >> >> # sysctl hw.acpi.cpu.cx_lowest=3DC1 >> hw.acpi.cpu.cx_lowest: C1 >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument >> =20 >> # sysctl hw.acpi.cpu.cx_lowest=3DC0 >> hw.acpi.cpu.cx_lowest: C1 >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument >> =20 >> # sysctl hw.acpi.cpu.cx_lowest=3DC1/0 >> hw.acpi.cpu.cx_lowest: C1 >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument >> >> # dmesg -a | grep "acpi" >> acpi0: on motherboard >> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, ff00000 (3) failed >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on >> acpi0 acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> cpu0: on acpi0 >> hw.acpi.cpu.cx_lowest: >> hw.acpi.cpu.cx_lowest > > I think I've found the problem and have updated the PR kern/108581 > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108581). The global > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume that > it's been intialized to 3 because it only sets it if it's higher than > the current CPU supports - that is, cpu_cx_count should reflect the > highest Cx state that all CPUs support. If you specifically mean the generic case (non-cst) as you mention in the PR, then I think that you didn't notice that cpu_cx_count (the global variable) gets updated in acpi_cpu_generic_cx_probe, So after looping over all CPUs it has the value of the maximum Cx level supported by at least one CPU. Only then we loop again and determine the smallest of the supported maximums. -- Andriy Gapon From bruce at cran.org.uk Thu Mar 26 07:25:20 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Mar 26 07:25:28 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <200903260937.51028.jhb@freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <200903260937.51028.jhb@freebsd.org> Message-ID: <20090326142456.042ea2f0@gluon.draftnet> On Thu, 26 Mar 2009 09:37:50 -0400 John Baldwin wrote: > On Wednesday 25 March 2009 6:39:14 pm Bruce Cran wrote: > > On Fri, 20 Mar 2009 00:30:03 GMT > > Daniel Dvo??k wrote: > > > > > The following reply was made to PR kern/108581; it has been noted > > > by GNATS. > > > > > > From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= > > > To: , > > > > > > Cc: > > > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > > > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > > > > > > This is a multi-part message in MIME format. > > > > > > ------=_NextPart_000_0007_01C9A8F7.746C4190 > > > Content-Type: text/plain; > > > charset="UTF-8" > > > Content-Transfer-Encoding: quoted-printable > > > > > > Hi acpi team, > > > =20 > > > today I have installed fbsd 7.1R on one box with this relativly > > > old = error and I was surprised about results .. it is the same: > > > =20 > > > # uname -a > > > FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > > > 14:37:25 = UTC 2009 > > > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386 > > > > > > # sysctl dev.cpu.0.cx_supported > > > dev.cpu.0.cx_supported: C1/0 > > > > > > # sysctl hw.acpi.cpu.cx_lowest=3DC1 > > > hw.acpi.cpu.cx_lowest: C1 > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > =20 > > > # sysctl hw.acpi.cpu.cx_lowest=3DC0 > > > hw.acpi.cpu.cx_lowest: C1 > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > =20 > > > # sysctl hw.acpi.cpu.cx_lowest=3DC1/0 > > > hw.acpi.cpu.cx_lowest: C1 > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > > > > # dmesg -a | grep "acpi" > > > acpi0: on motherboard > > > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > > > acpi0: [ITHREAD] > > > acpi0: Power Button (fixed) > > > acpi0: reservation of 0, a0000 (3) failed > > > acpi0: reservation of 100000, ff00000 (3) failed > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > > > acpi0 acpi_button0: on acpi0 > > > pcib0: port 0xcf8-0xcff on acpi0 > > > atkbdc0: port 0x60,0x64 irq 1 on > > > acpi0 cpu0: on acpi0 > > > hw.acpi.cpu.cx_lowest: > > > hw.acpi.cpu.cx_lowest > > > > I think I've found the problem and have updated the PR kern/108581 > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108581). The global > > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume > > that it's been intialized to 3 because it only sets it if it's > > higher than the current CPU supports - that is, cpu_cx_count should > > reflect the highest Cx state that all CPUs support. > > > > There's also a bug in the _CST section just below it; I think the > > line: > > > > if (sc->cpu_cx_count > cpu_cx_count) > > > > should be > > > > if (sc->cpu_cx_count < cpu_cx_count) > > No, the code is doing things differently on purpose (though I'm not > completely sure why). For _CST it sets cpu_cx_count to the maximum > Cx level supported by any CPU in the system. For non-_CST it sets it > to the maximum Cx level supported by all CPUs in the system. I think > it is correct for cpu_cx_count to always start at 0 and only be > bumped up to a higher setting. Setting it to 3 would be very wrong > for the _CST case as I've seen CPUs that support C4. > > Note that C1 _always_ exists as it is simply the "hlt" instruction > that has existed since the 8086. Only C2+ require power-saving > extension support in the CPU, so cpu_cx_count should always end up >= > 1. It would be interesting if you could add some debug printfs to > print out the values that acpi_cpu_generic_cx_probe() computes for > 'sc->cpu_cx_count' (sysctl dev.cpu could be useful for this) as well > as all changes to the 'cpu_cx_count' global variable. > For my Athlon XP CPU, acpi_cpu_generic_cx_probe sets sc->cpu_cx_count to 1, and subsequently dev.cpu.0.cx_lowest has always worked. After adding printfs I found that the problem is that the cpu_cx_generic block in acpi_cpu_startup is being run and because cpu_cx_count is set to 0 it never gets updated; the statement "if (sc->cpu_cx_count < cpu_cx_count)" is never true. -- Bruce Cran From bruce at cran.org.uk Thu Mar 26 07:28:55 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Mar 26 07:29:00 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <49CB8C86.4020800@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> Message-ID: <20090326142832.0dba187a@gluon.draftnet> On Thu, 26 Mar 2009 16:09:10 +0200 Andriy Gapon wrote: > on 26/03/2009 00:39 Bruce Cran said the following: > > On Fri, 20 Mar 2009 00:30:03 GMT > > Daniel Dvo??k wrote: > > > >> The following reply was made to PR kern/108581; it has been noted > >> by GNATS. > >> > >> From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= > >> To: , > >> > >> Cc: > >> Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > >> Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > >> > >> This is a multi-part message in MIME format. > >> > >> ------=_NextPart_000_0007_01C9A8F7.746C4190 > >> Content-Type: text/plain; > >> charset="UTF-8" > >> Content-Transfer-Encoding: quoted-printable > >> > >> Hi acpi team, > >> =20 > >> today I have installed fbsd 7.1R on one box with this relativly > >> old = error and I was surprised about results .. it is the same: > >> =20 > >> # uname -a > >> FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > >> 14:37:25 = UTC 2009 > >> root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386 > >> > >> # sysctl dev.cpu.0.cx_supported > >> dev.cpu.0.cx_supported: C1/0 > >> > >> # sysctl hw.acpi.cpu.cx_lowest=3DC1 > >> hw.acpi.cpu.cx_lowest: C1 > >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > >> =20 > >> # sysctl hw.acpi.cpu.cx_lowest=3DC0 > >> hw.acpi.cpu.cx_lowest: C1 > >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > >> =20 > >> # sysctl hw.acpi.cpu.cx_lowest=3DC1/0 > >> hw.acpi.cpu.cx_lowest: C1 > >> sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > >> > >> # dmesg -a | grep "acpi" > >> acpi0: on motherboard > >> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > >> acpi0: [ITHREAD] > >> acpi0: Power Button (fixed) > >> acpi0: reservation of 0, a0000 (3) failed > >> acpi0: reservation of 100000, ff00000 (3) failed > >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > >> acpi0 acpi_button0: on acpi0 > >> pcib0: port 0xcf8-0xcff on acpi0 > >> atkbdc0: port 0x60,0x64 irq 1 on > >> acpi0 cpu0: on acpi0 > >> hw.acpi.cpu.cx_lowest: > >> hw.acpi.cpu.cx_lowest > > > > I think I've found the problem and have updated the PR kern/108581 > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108581). The global > > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume > > that it's been intialized to 3 because it only sets it if it's > > higher than the current CPU supports - that is, cpu_cx_count should > > reflect the highest Cx state that all CPUs support. > > If you specifically mean the generic case (non-cst) as you mention in > the PR, then I think that you didn't notice that cpu_cx_count (the > global variable) gets updated in acpi_cpu_generic_cx_probe, So after > looping over all CPUs it has the value of the maximum Cx level > supported by at least one CPU. Only then we loop again and determine > the smallest of the supported maximums. Yes, I had missed that. I think the problem however is still that in the generic cx case the global is re-initialized to 0 and never gets updated. -- Bruce Cran From avg at icyb.net.ua Thu Mar 26 07:33:15 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Mar 26 07:33:21 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <20090326142832.0dba187a@gluon.draftnet> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> Message-ID: <49CB9224.6010509@icyb.net.ua> on 26/03/2009 16:28 Bruce Cran said the following: > On Thu, 26 Mar 2009 16:09:10 +0200 > Andriy Gapon wrote: >> If you specifically mean the generic case (non-cst) as you mention in >> the PR, then I think that you didn't notice that cpu_cx_count (the >> global variable) gets updated in acpi_cpu_generic_cx_probe, So after >> looping over all CPUs it has the value of the maximum Cx level >> supported by at least one CPU. Only then we loop again and determine >> the smallest of the supported maximums. > > Yes, I had missed that. I think the problem however is still that in > the generic cx case the global is re-initialized to 0 and never gets > updated. It would be interesting to catch where/when this happens if this is indeed the case. -- Andriy Gapon From bruce at cran.org.uk Thu Mar 26 07:37:53 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Mar 26 07:37:59 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <200903260937.51028.jhb@freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <200903260937.51028.jhb@freebsd.org> Message-ID: <20090326143731.0d2b7711@gluon.draftnet> On Thu, 26 Mar 2009 09:37:50 -0400 John Baldwin wrote: > No, the code is doing things differently on purpose (though I'm not > completely sure why). For _CST it sets cpu_cx_count to the maximum > Cx level supported by any CPU in the system. For non-_CST it sets it > to the maximum Cx level supported by all CPUs in the system. I think > it is correct for cpu_cx_count to always start at 0 and only be > bumped up to a higher setting. Setting it to 3 would be very wrong > for the _CST case as I've seen CPUs that support C4. From briefly reading through the specifications I'd assumed the maximum power state was C3. I had thought the _CST block was wrong because in acpi_cpu_global_cx_lowest_sysctl it validates the new value against cpu_cx_count; if one CPU has a lower cx state than the others, then won't this tell the other CPUs to use an unsupported state? -- Bruce Cran From bruce at cran.org.uk Thu Mar 26 07:42:07 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Mar 26 07:42:14 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <49CB9224.6010509@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> Message-ID: <20090326144140.2203c0d8@gluon.draftnet> On Thu, 26 Mar 2009 16:33:08 +0200 Andriy Gapon wrote: > on 26/03/2009 16:28 Bruce Cran said the following: > > On Thu, 26 Mar 2009 16:09:10 +0200 > > Andriy Gapon wrote: > >> If you specifically mean the generic case (non-cst) as you mention > >> in the PR, then I think that you didn't notice that cpu_cx_count > >> (the global variable) gets updated in acpi_cpu_generic_cx_probe, > >> So after looping over all CPUs it has the value of the maximum Cx > >> level supported by at least one CPU. Only then we loop again and > >> determine the smallest of the supported maximums. > > > > Yes, I had missed that. I think the problem however is still that > > in the generic cx case the global is re-initialized to 0 and never > > gets updated. > > It would be interesting to catch where/when this happens if this is > indeed the case. > I added lots of printfs to acpi_cpu.c and found that it's occuring in acpi_cpu_startup; initializing it to 3 in that function (which I wrongly assumed was the lowest Cx state supported in ACPI) fixed the problem on my Athlon XP PC because the generic cx handling code then lowered cpu_cx_count to 1 based on the fact that sc->cpu_cx_count was also 1. -- Bruce Cran From jhb at freebsd.org Thu Mar 26 07:51:13 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Mar 26 07:51:26 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <20090326142456.042ea2f0@gluon.draftnet> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326142456.042ea2f0@gluon.draftnet> Message-ID: <200903261049.02977.jhb@freebsd.org> On Thursday 26 March 2009 10:24:56 am Bruce Cran wrote: > On Thu, 26 Mar 2009 09:37:50 -0400 > John Baldwin wrote: > > > On Wednesday 25 March 2009 6:39:14 pm Bruce Cran wrote: > > > On Fri, 20 Mar 2009 00:30:03 GMT > > > Daniel Dvo??k wrote: > > > > > > > The following reply was made to PR kern/108581; it has been noted > > > > by GNATS. > > > > > > > > From: =?UTF-8?Q?Daniel_Dvo=C5=99=C3=A1k?= > > > > To: , > > > > > > > > Cc: > > > > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: > > > > Invalid argument Date: Fri, 20 Mar 2009 01:01:51 +0100 > > > > > > > > This is a multi-part message in MIME format. > > > > > > > > ------=_NextPart_000_0007_01C9A8F7.746C4190 > > > > Content-Type: text/plain; > > > > charset="UTF-8" > > > > Content-Transfer-Encoding: quoted-printable > > > > > > > > Hi acpi team, > > > > =20 > > > > today I have installed fbsd 7.1R on one box with this relativly > > > > old = error and I was surprised about results .. it is the same: > > > > =20 > > > > # uname -a > > > > FreeBSD X.Y.Z 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 > > > > 14:37:25 = UTC 2009 > > > > root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC = i386 > > > > > > > > # sysctl dev.cpu.0.cx_supported > > > > dev.cpu.0.cx_supported: C1/0 > > > > > > > > # sysctl hw.acpi.cpu.cx_lowest=3DC1 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > > =20 > > > > # sysctl hw.acpi.cpu.cx_lowest=3DC0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > > =20 > > > > # sysctl hw.acpi.cpu.cx_lowest=3DC1/0 > > > > hw.acpi.cpu.cx_lowest: C1 > > > > sysctl: hw.acpi.cpu.cx_lowest: Invalid argument > > > > > > > > # dmesg -a | grep "acpi" > > > > acpi0: on motherboard > > > > acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 > > > > acpi0: [ITHREAD] > > > > acpi0: Power Button (fixed) > > > > acpi0: reservation of 0, a0000 (3) failed > > > > acpi0: reservation of 100000, ff00000 (3) failed > > > > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on > > > > acpi0 acpi_button0: on acpi0 > > > > pcib0: port 0xcf8-0xcff on acpi0 > > > > atkbdc0: port 0x60,0x64 irq 1 on > > > > acpi0 cpu0: on acpi0 > > > > hw.acpi.cpu.cx_lowest: > > > > hw.acpi.cpu.cx_lowest > > > > > > I think I've found the problem and have updated the PR kern/108581 > > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108581). The global > > > cpu_cx_count was being initialized to 0 in acpi_cpu_startup > > > (in /sys/dev/acpica/acpi_cpu.c) but code below it appears to assume > > > that it's been intialized to 3 because it only sets it if it's > > > higher than the current CPU supports - that is, cpu_cx_count should > > > reflect the highest Cx state that all CPUs support. > > > > > > There's also a bug in the _CST section just below it; I think the > > > line: > > > > > > if (sc->cpu_cx_count > cpu_cx_count) > > > > > > should be > > > > > > if (sc->cpu_cx_count < cpu_cx_count) > > > > No, the code is doing things differently on purpose (though I'm not > > completely sure why). For _CST it sets cpu_cx_count to the maximum > > Cx level supported by any CPU in the system. For non-_CST it sets it > > to the maximum Cx level supported by all CPUs in the system. I think > > it is correct for cpu_cx_count to always start at 0 and only be > > bumped up to a higher setting. Setting it to 3 would be very wrong > > for the _CST case as I've seen CPUs that support C4. > > > > Note that C1 _always_ exists as it is simply the "hlt" instruction > > that has existed since the 8086. Only C2+ require power-saving > > extension support in the CPU, so cpu_cx_count should always end up >= > > 1. It would be interesting if you could add some debug printfs to > > print out the values that acpi_cpu_generic_cx_probe() computes for > > 'sc->cpu_cx_count' (sysctl dev.cpu could be useful for this) as well > > as all changes to the 'cpu_cx_count' global variable. > > > > For my Athlon XP CPU, acpi_cpu_generic_cx_probe sets sc->cpu_cx_count > to 1, and subsequently dev.cpu.0.cx_lowest has always worked. After > adding printfs I found that the problem is that the cpu_cx_generic > block in acpi_cpu_startup is being run and because cpu_cx_count is set > to 0 it never gets updated; the statement "if (sc->cpu_cx_count < > cpu_cx_count)" is never true. Err, you missed the end of acpi_cpu_generic_cx_probe() where it does this: /* Update the largest cx_count seen so far */ if (sc->cpu_cx_count > cpu_cx_count) cpu_cx_count = sc->cpu_cx_count; That is effectively the same as the for loop in the _CST case that finds the maximum supported state of all CPUs. It would probably be clearer to move that into acpi_cpu_startup() instead. -- John Baldwin From jhb at freebsd.org Thu Mar 26 07:51:17 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Mar 26 07:51:26 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <20090326143731.0d2b7711@gluon.draftnet> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet> Message-ID: <200903261050.51602.jhb@freebsd.org> On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: > On Thu, 26 Mar 2009 09:37:50 -0400 > John Baldwin wrote: > > > No, the code is doing things differently on purpose (though I'm not > > completely sure why). For _CST it sets cpu_cx_count to the maximum > > Cx level supported by any CPU in the system. For non-_CST it sets it > > to the maximum Cx level supported by all CPUs in the system. I think > > it is correct for cpu_cx_count to always start at 0 and only be > > bumped up to a higher setting. Setting it to 3 would be very wrong > > for the _CST case as I've seen CPUs that support C4. > > From briefly reading through the specifications I'd assumed the maximum > power state was C3. For the non _CST case that is all that is defined, yes. However, _CST is a variable length array of Cx states, so it can support arbitrary numbers of states. > I had thought the _CST block was wrong because in > acpi_cpu_global_cx_lowest_sysctl it validates the new value against > cpu_cx_count; if one CPU has a lower cx state than the others, then > won't this tell the other CPUs to use an unsupported state? It depends on if the CPU driver is smart enough to cap requests to sc->cpu_cx_count, though if it does presumably it would do that in the cx_generic case as well. I'm not sure why it behaves differently for the _CST case, but I do think it is on purpose at least rather than an accidental bug. Perhaps Nate can chime in with why? -- John Baldwin From avg at icyb.net.ua Thu Mar 26 08:04:28 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Mar 26 08:04:34 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <20090326144140.2203c0d8@gluon.draftnet> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> Message-ID: <49CB9973.3010306@icyb.net.ua> on 26/03/2009 16:41 Bruce Cran said the following: > On Thu, 26 Mar 2009 16:33:08 +0200 > Andriy Gapon wrote: > >> on 26/03/2009 16:28 Bruce Cran said the following: >>> On Thu, 26 Mar 2009 16:09:10 +0200 >>> Andriy Gapon wrote: >>>> If you specifically mean the generic case (non-cst) as you mention >>>> in the PR, then I think that you didn't notice that cpu_cx_count >>>> (the global variable) gets updated in acpi_cpu_generic_cx_probe, >>>> So after looping over all CPUs it has the value of the maximum Cx >>>> level supported by at least one CPU. Only then we loop again and >>>> determine the smallest of the supported maximums. >>> Yes, I had missed that. I think the problem however is still that >>> in the generic cx case the global is re-initialized to 0 and never >>> gets updated. >> It would be interesting to catch where/when this happens if this is >> indeed the case. >> > > I added lots of printfs to acpi_cpu.c and found that it's occuring in > acpi_cpu_startup; initializing it to 3 in that function (which I wrongly > assumed was the lowest Cx state supported in ACPI) fixed the problem on > my Athlon XP PC because the generic cx handling code then lowered > cpu_cx_count to 1 based on the fact that sc->cpu_cx_count was also 1. > Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in early exits from it. So, sc->cpu_cx_count is always set to at least 1, but if we exit via one of the returns before the end of function, then global cpu_cx_count is never updated. -- Andriy Gapon From bruce at cran.org.uk Thu Mar 26 08:10:59 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Mar 26 08:11:05 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <49CB9973.3010306@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> Message-ID: <20090326151035.51e4196e@gluon.draftnet> On Thu, 26 Mar 2009 17:04:19 +0200 Andriy Gapon wrote: > on 26/03/2009 16:41 Bruce Cran said the following: > > I added lots of printfs to acpi_cpu.c and found that it's occuring > > in acpi_cpu_startup; initializing it to 3 in that function (which I > > wrongly assumed was the lowest Cx state supported in ACPI) fixed > > the problem on my Athlon XP PC because the generic cx handling code > > then lowered cpu_cx_count to 1 based on the fact that > > sc->cpu_cx_count was also 1. > > > > Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in > early exits from it. So, sc->cpu_cx_count is always set to at least > 1, but if we exit via one of the returns before the end of function, > then global cpu_cx_count is never updated. > Exactly: acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 acpi_cpu_generic_cx_probe if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 So we're hitting an early exit in acpi_cpu_generic_cx_probe. -- Bruce Cran From sepotvin at FreeBSD.org Thu Mar 26 08:14:29 2009 From: sepotvin at FreeBSD.org (Stephane E. Potvin) Date: Thu Mar 26 08:14:36 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <200903261050.51602.jhb@freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet> <200903261050.51602.jhb@freebsd.org> Message-ID: <49CB9972.4030502@FreeBSD.org> John Baldwin wrote: > On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: >> On Thu, 26 Mar 2009 09:37:50 -0400 >> John Baldwin wrote: >> >>> No, the code is doing things differently on purpose (though I'm not >>> completely sure why). For _CST it sets cpu_cx_count to the maximum >>> Cx level supported by any CPU in the system. For non-_CST it sets it >>> to the maximum Cx level supported by all CPUs in the system. I think >>> it is correct for cpu_cx_count to always start at 0 and only be >>> bumped up to a higher setting. Setting it to 3 would be very wrong >>> for the _CST case as I've seen CPUs that support C4. >> From briefly reading through the specifications I'd assumed the maximum >> power state was C3. > > For the non _CST case that is all that is defined, yes. However, _CST is a > variable length array of Cx states, so it can support arbitrary numbers of > states. > >> I had thought the _CST block was wrong because in >> acpi_cpu_global_cx_lowest_sysctl it validates the new value against >> cpu_cx_count; if one CPU has a lower cx state than the others, then >> won't this tell the other CPUs to use an unsupported state? > > It depends on if the CPU driver is smart enough to cap requests to > sc->cpu_cx_count, though if it does presumably it would do that in the > cx_generic case as well. I'm not sure why it behaves differently for the > _CST case, but I do think it is on purpose at least rather than an accidental > bug. Perhaps Nate can chime in with why? > The intent when I added support for cx states on SMP systems was to use the same maximum cx_state for all CPUs when _CST is not used (cx_generic case) and to respect per-processor maximum cx_state when _CST is present and can be used. This whole piece of code is really convoluted and there's been a few errors found in it over time so I wouldn't be surprised if there were some still lurking. Could you send me privately a copy of your ASL and a verbose boot log? Steph From avg at icyb.net.ua Thu Mar 26 08:15:45 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Mar 26 08:15:51 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <20090326151035.51e4196e@gluon.draftnet> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> <20090326151035.51e4196e@gluon.draftnet> Message-ID: <49CB9C1B.4070308@icyb.net.ua> on 26/03/2009 17:10 Bruce Cran said the following: > On Thu, 26 Mar 2009 17:04:19 +0200 > Andriy Gapon wrote: > >> on 26/03/2009 16:41 Bruce Cran said the following: > >>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>> the problem on my Athlon XP PC because the generic cx handling code >>> then lowered cpu_cx_count to 1 based on the fact that >>> sc->cpu_cx_count was also 1. >>> >> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >> early exits from it. So, sc->cpu_cx_count is always set to at least >> 1, but if we exit via one of the returns before the end of function, >> then global cpu_cx_count is never updated. >> > > Exactly: > > acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 > acpi_cpu_generic_cx_probe > if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] > acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 > > So we're hitting an early exit in acpi_cpu_generic_cx_probe. > John, what would be a better fix - initialize the global variable to 1 or use goto in acpi_cpu_generic_cx_probe? I think the latter is more consistent and obvious, the former is simpler and safer, though. -- Andriy Gapon From jhb at freebsd.org Thu Mar 26 08:33:59 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Mar 26 08:34:05 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <49CB9C1B.4070308@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> Message-ID: <200903261129.50419.jhb@freebsd.org> On Thursday 26 March 2009 11:15:39 am Andriy Gapon wrote: > on 26/03/2009 17:10 Bruce Cran said the following: > > On Thu, 26 Mar 2009 17:04:19 +0200 > > Andriy Gapon wrote: > > > >> on 26/03/2009 16:41 Bruce Cran said the following: > > > >>> I added lots of printfs to acpi_cpu.c and found that it's occuring > >>> in acpi_cpu_startup; initializing it to 3 in that function (which I > >>> wrongly assumed was the lowest Cx state supported in ACPI) fixed > >>> the problem on my Athlon XP PC because the generic cx handling code > >>> then lowered cpu_cx_count to 1 based on the fact that > >>> sc->cpu_cx_count was also 1. > >>> > >> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in > >> early exits from it. So, sc->cpu_cx_count is always set to at least > >> 1, but if we exit via one of the returns before the end of function, > >> then global cpu_cx_count is never updated. > >> > > > > Exactly: > > > > acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 > > acpi_cpu_generic_cx_probe > > if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] > > acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 > > > > So we're hitting an early exit in acpi_cpu_generic_cx_probe. > > > > John, what would be a better fix - initialize the global variable to 1 or use goto > in acpi_cpu_generic_cx_probe? > I think the latter is more consistent and obvious, the former is simpler and > safer, though. I would rather move the cpu_cx_count code out into acpi_cpu_startup() completely. It would more closely match the _CST code in that case. It is also easier to follow the logic this way as well as it is only modified in one place and not via a secret side-effect. --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_cpu.c 2009/02/19 14:40:18 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_cpu.c 2009/03/26 15:28:32 @@ -609,10 +609,6 @@ sc->cpu_cx_count++; } } - - /* Update the largest cx_count seen so far */ - if (sc->cpu_cx_count > cpu_cx_count) - cpu_cx_count = sc->cpu_cx_count; } /* @@ -752,6 +748,8 @@ for (i = 0; i < cpu_ndevices; i++) { sc = device_get_softc(cpu_devices[i]); acpi_cpu_generic_cx_probe(sc); + if (sc->cpu_cx_count > cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; } /* -- John Baldwin From sepotvin at FreeBSD.org Thu Mar 26 08:40:25 2009 From: sepotvin at FreeBSD.org (Stephane E. Potvin) Date: Thu Mar 26 08:40:36 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <49CB9C1B.4070308@icyb.net.ua> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> Message-ID: <49CBA1E5.2090902@FreeBSD.org> Andriy Gapon wrote: > on 26/03/2009 17:10 Bruce Cran said the following: >> On Thu, 26 Mar 2009 17:04:19 +0200 >> Andriy Gapon wrote: >> >>> on 26/03/2009 16:41 Bruce Cran said the following: >>>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>>> the problem on my Athlon XP PC because the generic cx handling code >>>> then lowered cpu_cx_count to 1 based on the fact that >>>> sc->cpu_cx_count was also 1. >>>> >>> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >>> early exits from it. So, sc->cpu_cx_count is always set to at least >>> 1, but if we exit via one of the returns before the end of function, >>> then global cpu_cx_count is never updated. >>> >> Exactly: >> >> acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 >> acpi_cpu_generic_cx_probe >> if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] >> acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 >> >> So we're hitting an early exit in acpi_cpu_generic_cx_probe. >> > > John, what would be a better fix - initialize the global variable to 1 or use goto > in acpi_cpu_generic_cx_probe? > I think the latter is more consistent and obvious, the former is simpler and > safer, though. > Your right, it seems that I need to order some more pointy hats. There should have been a goto there to jump at the end in order to initialize the global cpu_cx_count. The following patch should fix your issue. John, is this ok with you? Index: acpi_cpu.c =================================================================== --- acpi_cpu.c (revision 190318) +++ acpi_cpu.c (working copy) @@ -576,7 +576,7 @@ * "only" C1-C3 is not a hardship. */ if (sc->cpu_p_blk_len < 5) - return; + goto done; /* Validate and allocate resources for C2 (P_LVL2). */ gas.SpaceId = ACPI_ADR_SPACE_SYSTEM_IO; @@ -594,7 +594,7 @@ } } if (sc->cpu_p_blk_len < 6) - return; + goto done; /* Validate and allocate resources for C3 (P_LVL3). */ if (AcpiGbl_FADT.C3Latency <= 1000 && !(cpu_quirks & CPU_QUIRK_NO_C3)) { @@ -610,6 +610,7 @@ } } +done: /* Update the largest cx_count seen so far */ if (sc->cpu_cx_count > cpu_cx_count) cpu_cx_count = sc->cpu_cx_count; From avg at icyb.net.ua Thu Mar 26 08:41:21 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Mar 26 08:41:28 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <200903261129.50419.jhb@freebsd.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> <200903261129.50419.jhb@freebsd.org> Message-ID: <49CBA21B.5050207@icyb.net.ua> on 26/03/2009 17:29 John Baldwin said the following: > On Thursday 26 March 2009 11:15:39 am Andriy Gapon wrote: >> on 26/03/2009 17:10 Bruce Cran said the following: >>> On Thu, 26 Mar 2009 17:04:19 +0200 >>> Andriy Gapon wrote: >>> >>>> on 26/03/2009 16:41 Bruce Cran said the following: >>>>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>>>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>>>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>>>> the problem on my Athlon XP PC because the generic cx handling code >>>>> then lowered cpu_cx_count to 1 based on the fact that >>>>> sc->cpu_cx_count was also 1. >>>>> >>>> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >>>> early exits from it. So, sc->cpu_cx_count is always set to at least >>>> 1, but if we exit via one of the returns before the end of function, >>>> then global cpu_cx_count is never updated. >>>> >>> Exactly: >>> >>> acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 >>> acpi_cpu_generic_cx_probe >>> if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] >>> acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 >>> >>> So we're hitting an early exit in acpi_cpu_generic_cx_probe. >>> >> John, what would be a better fix - initialize the global variable to 1 or > use goto >> in acpi_cpu_generic_cx_probe? >> I think the latter is more consistent and obvious, the former is simpler and >> safer, though. > > I would rather move the cpu_cx_count code out into acpi_cpu_startup() > completely. It would more closely match the _CST code in that case. It is > also easier to follow the logic this way as well as it is only modified in > one place and not via a secret side-effect. Perfect! > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_cpu.c 2009/02/19 14:40:18 > +++ //depot/user/jhb/acpipci/dev/acpica/acpi_cpu.c 2009/03/26 15:28:32 > @@ -609,10 +609,6 @@ > sc->cpu_cx_count++; > } > } > - > - /* Update the largest cx_count seen so far */ > - if (sc->cpu_cx_count > cpu_cx_count) > - cpu_cx_count = sc->cpu_cx_count; > } > > /* > @@ -752,6 +748,8 @@ > for (i = 0; i < cpu_ndevices; i++) { > sc = device_get_softc(cpu_devices[i]); > acpi_cpu_generic_cx_probe(sc); > + if (sc->cpu_cx_count > cpu_cx_count) > + cpu_cx_count = sc->cpu_cx_count; > } > > /* > > -- Andriy Gapon From nate at root.org Thu Mar 26 09:38:43 2009 From: nate at root.org (Nate Lawson) Date: Thu Mar 26 09:38:49 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <49CBA1E5.2090902@FreeBSD.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> <49CBA1E5.2090902@FreeBSD.org> Message-ID: <49CBAF8F.9080301@root.org> Stephane E. Potvin wrote: > Andriy Gapon wrote: >> on 26/03/2009 17:10 Bruce Cran said the following: >>> On Thu, 26 Mar 2009 17:04:19 +0200 >>> Andriy Gapon wrote: >>> >>>> on 26/03/2009 16:41 Bruce Cran said the following: >>>>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>>>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>>>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>>>> the problem on my Athlon XP PC because the generic cx handling code >>>>> then lowered cpu_cx_count to 1 based on the fact that >>>>> sc->cpu_cx_count was also 1. >>>>> >>>> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >>>> early exits from it. So, sc->cpu_cx_count is always set to at least >>>> 1, but if we exit via one of the returns before the end of function, >>>> then global cpu_cx_count is never updated. >>>> >>> Exactly: >>> >>> acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 >>> acpi_cpu_generic_cx_probe >>> if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] >>> acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 >>> >>> So we're hitting an early exit in acpi_cpu_generic_cx_probe. >>> >> John, what would be a better fix - initialize the global variable to 1 or use goto >> in acpi_cpu_generic_cx_probe? >> I think the latter is more consistent and obvious, the former is simpler and >> safer, though. >> > > Your right, it seems that I need to order some more pointy hats. There > should have been a goto there to jump at the end in order to initialize > the global cpu_cx_count. The following patch should fix your issue. > John, is this ok with you? John's patch does the same thing without a goto (see message <200903261129.50419.jhb@freebsd.org>) -- Nate From avg at icyb.net.ua Thu Mar 26 10:50:05 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Mar 26 10:50:11 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Message-ID: <200903261750.n2QHo41h007676@freefall.freebsd.org> The following reply was made to PR kern/108581; it has been noted by GNATS. From: Andriy Gapon To: Bruce Cran Cc: bug-followup@FreeBSD.org, lars.stokholm@gmail.com Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Thu, 26 Mar 2009 19:46:56 +0200 on 26/03/2009 17:29 John Baldwin said the following: > I would rather move the cpu_cx_count code out into acpi_cpu_startup() > completely. It would more closely match the _CST code in that case. It is > also easier to follow the logic this way as well as it is only modified in > one place and not via a secret side-effect. Just in case: Bruce, Lars, could you please test John's patch (verbatim) and report back? Thank you! > --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_cpu.c 2009/02/19 14:40:18 > +++ //depot/user/jhb/acpipci/dev/acpica/acpi_cpu.c 2009/03/26 15:28:32 > @@ -609,10 +609,6 @@ > sc->cpu_cx_count++; > } > } > - > - /* Update the largest cx_count seen so far */ > - if (sc->cpu_cx_count > cpu_cx_count) > - cpu_cx_count = sc->cpu_cx_count; > } > > /* > @@ -752,6 +748,8 @@ > for (i = 0; i < cpu_ndevices; i++) { > sc = device_get_softc(cpu_devices[i]); > acpi_cpu_generic_cx_probe(sc); > + if (sc->cpu_cx_count > cpu_cx_count) > + cpu_cx_count = sc->cpu_cx_count; > } > > /* > > -- Andriy Gapon From sepotvin at FreeBSD.org Thu Mar 26 10:58:07 2009 From: sepotvin at FreeBSD.org (Stephane E. Potvin) Date: Thu Mar 26 10:58:13 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <49CBAF8F.9080301@root.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <20090325223914.4387eeae@gluon.draftnet> <49CB8C86.4020800@icyb.net.ua> <20090326142832.0dba187a@gluon.draftnet> <49CB9224.6010509@icyb.net.ua> <20090326144140.2203c0d8@gluon.draftnet> <49CB9973.3010306@icyb.net.ua> <20090326151035.51e4196e@gluon.draftnet> <49CB9C1B.4070308@icyb.net.ua> <49CBA1E5.2090902@FreeBSD.org> <49CBAF8F.9080301@root.org> Message-ID: <49CBC22D.9090606@FreeBSD.org> Nate Lawson wrote: > Stephane E. Potvin wrote: >> Andriy Gapon wrote: >>> on 26/03/2009 17:10 Bruce Cran said the following: >>>> On Thu, 26 Mar 2009 17:04:19 +0200 >>>> Andriy Gapon wrote: >>>> >>>>> on 26/03/2009 16:41 Bruce Cran said the following: >>>>>> I added lots of printfs to acpi_cpu.c and found that it's occuring >>>>>> in acpi_cpu_startup; initializing it to 3 in that function (which I >>>>>> wrongly assumed was the lowest Cx state supported in ACPI) fixed >>>>>> the problem on my Athlon XP PC because the generic cx handling code >>>>>> then lowered cpu_cx_count to 1 based on the fact that >>>>>> sc->cpu_cx_count was also 1. >>>>>> >>>>> Ok, yes, the real issue is in acpi_cpu_generic_cx_probe, namely in >>>>> early exits from it. So, sc->cpu_cx_count is always set to at least >>>>> 1, but if we exit via one of the returns before the end of function, >>>>> then global cpu_cx_count is never updated. >>>>> >>>> Exactly: >>>> >>>> acpi: acpi_cpu_startup: initializing cpu_cx_count to 0 >>>> acpi_cpu_generic_cx_probe >>>> if sc->cpu_p_blk_len < 5 [sc->cpu_p_blk_len = 0] >>>> acpi: acpi_cpu_startup: cpu 0,cpu_cx_count = 0,sc->cpu_cx_count = 1 >>>> >>>> So we're hitting an early exit in acpi_cpu_generic_cx_probe. >>>> >>> John, what would be a better fix - initialize the global variable to 1 or use goto >>> in acpi_cpu_generic_cx_probe? >>> I think the latter is more consistent and obvious, the former is simpler and >>> safer, though. >>> >> Your right, it seems that I need to order some more pointy hats. There >> should have been a goto there to jump at the end in order to initialize >> the global cpu_cx_count. The following patch should fix your issue. >> John, is this ok with you? > > John's patch does the same thing without a goto (see message > <200903261129.50419.jhb@freebsd.org>) > I saw it after sending mine, John's patch is indeed better. Steph From bruce at cran.org.uk Thu Mar 26 11:40:05 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Mar 26 11:40:10 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Message-ID: <200903261840.n2QIe325075203@freefall.freebsd.org> The following reply was made to PR kern/108581; it has been noted by GNATS. From: Bruce Cran To: Andriy Gapon Cc: bug-followup@FreeBSD.org, lars.stokholm@gmail.com Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Date: Thu, 26 Mar 2009 18:29:53 +0000 On Thu, 26 Mar 2009 19:46:56 +0200 Andriy Gapon wrote: > on 26/03/2009 17:29 John Baldwin said the following: > > I would rather move the cpu_cx_count code out into > > acpi_cpu_startup() completely. It would more closely match the > > _CST code in that case. It is also easier to follow the logic this > > way as well as it is only modified in one place and not via a > > secret side-effect. > > Just in case: > Bruce, Lars, > could you please test John's patch (verbatim) and report back? > Thank you! Works here - thanks! -- Bruce Cran From dandee at hellteam.net Thu Mar 26 13:11:08 2009 From: dandee at hellteam.net (=?iso-8859-1?Q?Daniel_Dvor=E1k?=) Date: Thu Mar 26 13:13:42 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <49CB9972.4030502@FreeBSD.org> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <200903260937.51028.jhb@freebsd.org> <20090326143731.0d2b7711@gluon.draftnet> <200903261050.51602.jhb@freebsd.org> <49CB9972.4030502@FreeBSD.org> Message-ID: <7DFA954C8D084B4DAF8C7CC3306DF096@tocnet28.jspoj.czf> Hi all, I found out this error on the other computers. Will it be helpful for analyzing to send infromation about cpu, acpi table and so on ? Or is the first example enough ? DD -----Original Message----- From: Stephane E. Potvin [mailto:sepotvin@FreeBSD.org] Sent: Thursday, March 26, 2009 4:04 PM To: John Baldwin Cc: Bruce Cran; Daniel Dvor(?k; freebsd-acpi@freebsd.org Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument John Baldwin wrote: > On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: >> On Thu, 26 Mar 2009 09:37:50 -0400 >> John Baldwin wrote: >> >>> No, the code is doing things differently on purpose (though I'm not >>> completely sure why). For _CST it sets cpu_cx_count to the maximum >>> Cx level supported by any CPU in the system. For non-_CST it sets >>> it to the maximum Cx level supported by all CPUs in the system. I >>> think it is correct for cpu_cx_count to always start at 0 and only >>> be bumped up to a higher setting. Setting it to 3 would be very >>> wrong for the _CST case as I've seen CPUs that support C4. >> From briefly reading through the specifications I'd assumed the >> maximum power state was C3. > > For the non _CST case that is all that is defined, yes. However, _CST > is a variable length array of Cx states, so it can support arbitrary > numbers of states. > >> I had thought the _CST block was wrong because in >> acpi_cpu_global_cx_lowest_sysctl it validates the new value against >> cpu_cx_count; if one CPU has a lower cx state than the others, then >> won't this tell the other CPUs to use an unsupported state? > > It depends on if the CPU driver is smart enough to cap requests to > sc->cpu_cx_count, though if it does presumably it would do that in the > cx_generic case as well. I'm not sure why it behaves differently for > the _CST case, but I do think it is on purpose at least rather than an > accidental bug. Perhaps Nate can chime in with why? > The intent when I added support for cx states on SMP systems was to use the same maximum cx_state for all CPUs when _CST is not used (cx_generic case) and to respect per-processor maximum cx_state when _CST is present and can be used. This whole piece of code is really convoluted and there's been a few errors found in it over time so I wouldn't be surprised if there were some still lurking. Could you send me privately a copy of your ASL and a verbose boot log? Steph From jhb at freebsd.org Thu Mar 26 13:29:17 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Mar 26 13:29:23 2009 Subject: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument In-Reply-To: <7DFA954C8D084B4DAF8C7CC3306DF096@tocnet28.jspoj.czf> References: <200903200030.n2K0U3iG011009@freefall.freebsd.org> <49CB9972.4030502@FreeBSD.org> <7DFA954C8D084B4DAF8C7CC3306DF096@tocnet28.jspoj.czf> Message-ID: <200903261629.06238.jhb@freebsd.org> On Thursday 26 March 2009 3:51:51 pm Daniel Dvor?k wrote: > Hi all, > > I found out this error on the other computers. Will it be helpful for > analyzing to send infromation about cpu, acpi table and so on ? Or is the > first example enough ? The example is enough, we just need someone to test the patch and make sure it fixes the problem. > DD > > -----Original Message----- > From: Stephane E. Potvin [mailto:sepotvin@FreeBSD.org] > Sent: Thursday, March 26, 2009 4:04 PM > To: John Baldwin > Cc: Bruce Cran; Daniel Dvor(?k; freebsd-acpi@freebsd.org > Subject: Re: kern/108581: [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid > argument > > John Baldwin wrote: > > On Thursday 26 March 2009 10:37:31 am Bruce Cran wrote: > >> On Thu, 26 Mar 2009 09:37:50 -0400 > >> John Baldwin wrote: > >> > >>> No, the code is doing things differently on purpose (though I'm not > >>> completely sure why). For _CST it sets cpu_cx_count to the maximum > >>> Cx level supported by any CPU in the system. For non-_CST it sets > >>> it to the maximum Cx level supported by all CPUs in the system. I > >>> think it is correct for cpu_cx_count to always start at 0 and only > >>> be bumped up to a higher setting. Setting it to 3 would be very > >>> wrong for the _CST case as I've seen CPUs that support C4. > >> From briefly reading through the specifications I'd assumed the > >> maximum power state was C3. > > > > For the non _CST case that is all that is defined, yes. However, _CST > > is a variable length array of Cx states, so it can support arbitrary > > numbers of states. > > > >> I had thought the _CST block was wrong because in > >> acpi_cpu_global_cx_lowest_sysctl it validates the new value against > >> cpu_cx_count; if one CPU has a lower cx state than the others, then > >> won't this tell the other CPUs to use an unsupported state? > > > > It depends on if the CPU driver is smart enough to cap requests to > > sc->cpu_cx_count, though if it does presumably it would do that in the > > cx_generic case as well. I'm not sure why it behaves differently for > > the _CST case, but I do think it is on purpose at least rather than an > > accidental bug. Perhaps Nate can chime in with why? > > > > The intent when I added support for cx states on SMP systems was to use the > same maximum cx_state for all CPUs when _CST is not used (cx_generic > case) and to respect per-processor maximum cx_state when _CST is present and > can be used. This whole piece of code is really convoluted and there's been > a few errors found in it over time so I wouldn't be surprised if there were > some still lurking. > > Could you send me privately a copy of your ASL and a verbose boot log? > > Steph > > -- John Baldwin From dfilter at FreeBSD.ORG Thu Mar 26 14:20:06 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Thu Mar 26 14:20:12 2009 Subject: kern/108581: commit references a PR Message-ID: <200903262120.n2QLK5sm094807@freefall.freebsd.org> The following reply was made to PR kern/108581; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/108581: commit references a PR Date: Thu, 26 Mar 2009 21:10:49 +0000 (UTC) Author: jhb Date: Thu Mar 26 21:10:35 2009 New Revision: 190454 URL: http://svn.freebsd.org/changeset/base/190454 Log: Move the code to update cpu_cx_count out of acpi_cpu_generic_cx_probe() and into acpi_cpu_startup() which is where all the other code to update this global variable lives. This fixes a bug where cpu_cx_count was not updated correctly if acpi_cpu_generic_cx_probe() returned early. PR: kern/108581 Debugged by: Bruce Cran Reviewed by: avg, njl, sepotvin MFC after: 3 days Modified: head/sys/dev/acpica/acpi_cpu.c Modified: head/sys/dev/acpica/acpi_cpu.c ============================================================================== --- head/sys/dev/acpica/acpi_cpu.c Thu Mar 26 20:23:21 2009 (r190453) +++ head/sys/dev/acpica/acpi_cpu.c Thu Mar 26 21:10:35 2009 (r190454) @@ -609,10 +609,6 @@ acpi_cpu_generic_cx_probe(struct acpi_cp sc->cpu_cx_count++; } } - - /* Update the largest cx_count seen so far */ - if (sc->cpu_cx_count > cpu_cx_count) - cpu_cx_count = sc->cpu_cx_count; } /* @@ -752,6 +748,8 @@ acpi_cpu_startup(void *arg) for (i = 0; i < cpu_ndevices; i++) { sc = device_get_softc(cpu_devices[i]); acpi_cpu_generic_cx_probe(sc); + if (sc->cpu_cx_count > cpu_cx_count) + cpu_cx_count = sc->cpu_cx_count; } /* _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From jhb at FreeBSD.org Thu Mar 26 14:22:24 2009 From: jhb at FreeBSD.org (jhb@FreeBSD.org) Date: Thu Mar 26 14:22:31 2009 Subject: kern/108581: [patch] [acpi] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument Message-ID: <200903262122.n2QLMNVa007697@freefall.freebsd.org> Synopsis: [patch] [acpi] sysctl: hw.acpi.cpu.cx_lowest: Invalid argument State-Changed-From-To: open->patched State-Changed-By: jhb State-Changed-When: Thu Mar 26 21:21:55 UTC 2009 State-Changed-Why: Fix is in HEAD, will MFC in a few days. Responsible-Changed-From-To: freebsd-acpi->jhb Responsible-Changed-By: jhb Responsible-Changed-When: Thu Mar 26 21:21:55 UTC 2009 Responsible-Changed-Why: Fix is in HEAD, will MFC in a few days. http://www.freebsd.org/cgi/query-pr.cgi?pr=108581 From cwhiteh at onetel.com Thu Mar 26 14:47:13 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Thu Mar 26 14:47:25 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <1237992462.1297.22.camel@RabbitsDen> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> Message-ID: <49CBF7D1.20102@onetel.com> Alexandre "Sunny" Kovalenko wrote: > To be fair, if all you want is to override _CRT, you should be able to > put something to the tune of > > hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz0._CRT=90C > > in your /etc/sysctl.conf and not deal with the ASL at all. I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change values at which point hw.acpi.thermal.tz0._CRT reverts to -1. At idle having set hw.acpi.thermal.tz0._CRT to 90C with sysctl: chrisw@muji% sysctl hw.acpi.thermal.tz0 hw.acpi.thermal.tz0.temperature: 55.0C hw.acpi.thermal.tz0.active: 3 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 90.0C hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 45.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 Heat it up a bit with cpuburn: chrisw@muji% sysctl hw.acpi.thermal.tz0 hw.acpi.thermal.tz0.temperature: 60.0C hw.acpi.thermal.tz0.active: 2 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: -1 hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 55.0C 45.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz0._CRT will now stay at -1 until I reset it with sysctl. So I suppose I need to find out where hw.acpi.thermal.tz0._CRT is getting its value from - which must be the ASL. acpidump -td says ThermalZone (TZ0) { snip Method (_CRT, 0, Serialized) { Return (C316 (0x04, 0x00)) } snip } The whole asl is fetch(1)able as www.fishercroft.plus.com/nc6320.asl.gz Watching /var/log/messages I can't see a correlation between when the warning messages appear and changing the temperature states so I don't even know what is actually triggering them. I've started reading the ACPI specs as suggested but in the meantime all suggestions welcome. Thanks Chris > > You might want to take a look at your output of 'sysctl hw.acpi.thermal' > -- your specific thermal zone, might be different from the one, I have > used as an example above. In fact, on my laptop, it is tz1 and not tz0. > > In either case, I would recommend reading thermal chapter of the ACPI > specification -- it is short, well-written and has an example, I was > stealing stuff from, shamelessly, in the past. > > HTH, > From nate at root.org Thu Mar 26 16:49:18 2009 From: nate at root.org (Nate Lawson) Date: Thu Mar 26 16:49:24 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49CBF7D1.20102@onetel.com> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> Message-ID: <49CC147A.3030805@root.org> Chris Whitehouse wrote: > Alexandre "Sunny" Kovalenko wrote: >> To be fair, if all you want is to override _CRT, you should be able to >> put something to the tune of >> >> hw.acpi.thermal.user_override=1 >> hw.acpi.thermal.tz0._CRT=90C >> >> in your /etc/sysctl.conf and not deal with the ASL at all. > > I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until > hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change > values at which point hw.acpi.thermal.tz0._CRT reverts to -1. > Thermal zones are re-evaluated when a Notify comes in that says to do so. Perhaps if "user_override" is set to 1, we should not re-evaluate them. However, perhaps that should only be done for values the user actually overrode. There has to be a different solution Windows used. Maybe they ignore _crt. -- Nate From gaijin.k at gmail.com Thu Mar 26 18:50:37 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Thu Mar 26 18:50:43 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49CC147A.3030805@root.org> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> Message-ID: <1238118621.1365.35.camel@RabbitsDen> On Thu, 2009-03-26 at 16:49 -0700, Nate Lawson wrote: > Chris Whitehouse wrote: > > Alexandre "Sunny" Kovalenko wrote: > >> To be fair, if all you want is to override _CRT, you should be able to > >> put something to the tune of > >> > >> hw.acpi.thermal.user_override=1 > >> hw.acpi.thermal.tz0._CRT=90C > >> > >> in your /etc/sysctl.conf and not deal with the ASL at all. > > > > I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until > > hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change > > values at which point hw.acpi.thermal.tz0._CRT reverts to -1. > > > > Thermal zones are re-evaluated when a Notify comes in that says to do > so. Perhaps if "user_override" is set to 1, we should not re-evaluate > them. However, perhaps that should only be done for values the user > actually overrode. ACPI 2.0 spec explicitly talks about updating of the _PSV and _ACx on Notify(..., 0x81). ACPI 3.0b is shade more vague, but still talking about "active and passive cooling temperature trip points". Maybe we should not reevaluate _HOT and _CRT at all? > > There has to be a different solution Windows used. Maybe they ignore _crt. Looking at ASL I can see five thermal zone objects defined and only one of them (TZ4) looking somewhat normal: _CRT is 110C and _TMP method goes to the trouble of making sane return value. Maybe Windows somehow knows which thermal zones to ignore? Given the snippet below this _was_ geared heavily towards Windows: If (\_OSI ("Windows 2001")) { Store (0x04, C014) } If (\_OSI ("Windows 2001 SP1")) { Store (0x04, C014) } If (\_OSI ("Windows 2001 SP2")) { Store (0x05, C014) } If (\_OSI ("Windows 2006")) { Store (0x06, C014) } Chris, you should be able to set hw.acpi.osname= in loader.conf and see if things improve somewhat. Note that "Windows 2001" and "Windows 2001 SP1" are identical. Could you also, please, post the full output of the sysctl hw.acpi.thermal -- Alexandre Kovalenko (????????? ?????????) From smithi at nimnet.asn.au Thu Mar 26 22:44:26 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Thu Mar 26 22:44:33 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49CBF7D1.20102@onetel.com> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> Message-ID: <20090327155343.C95588@sola.nimnet.asn.au> On Thu, 26 Mar 2009, Chris Whitehouse wrote: > Alexandre "Sunny" Kovalenko wrote: > > To be fair, if all you want is to override _CRT, you should be able to > > put something to the tune of > > > > hw.acpi.thermal.user_override=1 > > hw.acpi.thermal.tz0._CRT=90C > > > > in your /etc/sysctl.conf and not deal with the ASL at all. > > I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until > hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change values > at which point hw.acpi.thermal.tz0._CRT reverts to -1. > > At idle having set hw.acpi.thermal.tz0._CRT to 90C with sysctl: > > chrisw@muji% sysctl hw.acpi.thermal.tz0 > hw.acpi.thermal.tz0.temperature: 55.0C > hw.acpi.thermal.tz0.active: 3 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 90.0C > hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 45.0C -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 Just towards figuring out what this zone might represent .. perhaps it's a case temperature sensor, seemingly controlling a fan? No passive cooling, and here at 55C tz0.active is 3, being the zero-based index into the active cooling array _ACx (ie, temp > 45C). > Heat it up a bit with cpuburn: > > chrisw@muji% sysctl hw.acpi.thermal.tz0 > hw.acpi.thermal.tz0.temperature: 60.0C > hw.acpi.thermal.tz0.active: 2 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: -1 > hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 55.0C 45.0C -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 And now tz0.active is 2, ie > 55C. Some fan should be running faster, is that anything noticeable? It could be separate from the CPU fan. > hw.acpi.thermal.tz0._CRT will now stay at -1 until I reset it with sysctl. > > So I suppose I need to find out where hw.acpi.thermal.tz0._CRT is getting its > value from - which must be the ASL. > > acpidump -td says > > ThermalZone (TZ0) > { > > snip > > Method (_CRT, 0, Serialized) > { > Return (C316 (0x04, 0x00)) > } > > snip > > } > > The whole asl is fetch(1)able as www.fishercroft.plus.com/nc6320.asl.gz > > Watching /var/log/messages I can't see a correlation between when the warning > messages appear and changing the temperature states so I don't even know what > is actually triggering them. What's the highest temperature you've observed for that zone? I wonder how that may correlate with your CPU and/or GPU temperatures / zones? > I've started reading the ACPI specs as suggested but in the meantime all > suggestions welcome. > > Thanks > > Chris > > > > > You might want to take a look at your output of 'sysctl hw.acpi.thermal' > > -- your specific thermal zone, might be different from the one, I have > > used as an example above. In fact, on my laptop, it is tz1 and not tz0. As Alexandre says, showing all of the hw.acpi.thermal zones may help. My earlier guess about maybe being byte-swapped seems more unlikely, I forgot these were returned as tenths of a degree Kelvin, not Celcius. Nate suggested Windows might ignore _crt for this one .. or perhaps this odd figure of 256.0C signals something to Windows? Just speculating .. > > In either case, I would recommend reading thermal chapter of the ACPI > > specification -- it is short, well-written and has an example, I was > > stealing stuff from, shamelessly, in the past. Indeed, it's one of the few chapters that made a lot of sense to me :) cheers, Ian From cwhiteh at onetel.com Fri Mar 27 06:58:22 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Fri Mar 27 06:58:29 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <20090327155343.C95588@sola.nimnet.asn.au> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <20090327155343.C95588@sola.nimnet.asn.au> Message-ID: <49CCDAC6.2060407@onetel.com> Ian Smith wrote: > On Thu, 26 Mar 2009, Chris Whitehouse wrote: >> Alexandre "Sunny" Kovalenko wrote: >>> To be fair, if all you want is to override _CRT, you should be >>> able to put something to the tune of >>> >>> hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0._CRT=90C >>> >>> in your /etc/sysctl.conf and not deal with the ASL at all. >> >> I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until >> hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature >> change values at which point hw.acpi.thermal.tz0._CRT reverts to >> -1. >> >> At idle having set hw.acpi.thermal.tz0._CRT to 90C with sysctl: >> >> chrisw@muji% sysctl hw.acpi.thermal.tz0 >> hw.acpi.thermal.tz0.temperature: 55.0C hw.acpi.thermal.tz0.active: >> 3 hw.acpi.thermal.tz0.passive_cooling: 0 >> hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 >> hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 90.0C >> hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 45.0C -1 -1 -1 -1 -1 -1 >> hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 >> hw.acpi.thermal.tz0._TSP: -1 > > Just towards figuring out what this zone might represent .. perhaps > it's a case temperature sensor, seemingly controlling a fan? No > passive cooling, and here at 55C tz0.active is 3, being the > zero-based index into the active cooling array _ACx (ie, temp > 45C). > The lowest temperature I have seen is 45C. > >> Heat it up a bit with cpuburn: >> >> chrisw@muji% sysctl hw.acpi.thermal.tz0 >> hw.acpi.thermal.tz0.temperature: 60.0C hw.acpi.thermal.tz0.active: >> 2 hw.acpi.thermal.tz0.passive_cooling: 0 >> hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 >> hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: -1 >> hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 55.0C 45.0C -1 -1 -1 -1 -1 -1 >> hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 >> hw.acpi.thermal.tz0._TSP: -1 > > And now tz0.active is 2, ie > 55C. Some fan should be running > faster, is that anything noticeable? It could be separate from the > CPU fan. There is one fan and it changes speed with hw.acpi.thermal.tz0.temperature and hw.acpi.thermal.tz0.active which move together. I'm pretty sure it is located to cool the cpu but I'd have to check some hardware docs to be certain. See also my other post with details of /var/log/messages. > >> hw.acpi.thermal.tz0._CRT will now stay at -1 until I reset it with >> sysctl. >> >> So I suppose I need to find out where hw.acpi.thermal.tz0._CRT is >> getting its value from - which must be the ASL. >> >> acpidump -td says >> >> ThermalZone (TZ0) { >> >> snip >> >> Method (_CRT, 0, Serialized) { Return (C316 (0x04, 0x00)) } >> >> snip >> >> } >> >> The whole asl is fetch(1)able as >> www.fishercroft.plus.com/nc6320.asl.gz >> >> Watching /var/log/messages I can't see a correlation between when >> the warning messages appear and changing the temperature states so >> I don't even know what is actually triggering them. > > What's the highest temperature you've observed for that zone? I > wonder how that may correlate with your CPU and/or GPU temperatures / > zones? Highest temperature I've seen for hw.acpi.thermal.tz0.temperature is 80C. And on looking closer I see they do correlate - also see my other post. Chris From cwhiteh at onetel.com Fri Mar 27 07:01:05 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Fri Mar 27 07:01:12 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49CC147A.3030805@root.org> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> Message-ID: <49CCDC19.3040606@onetel.com> Nate Lawson wrote: > > Thermal zones are re-evaluated when a Notify comes in that says to do > so. Perhaps if "user_override" is set to 1, we should not re-evaluate > them. However, perhaps that should only be done for values the user > actually overrode. > > There has to be a different solution Windows used. Maybe they ignore _crt. I wondered about this. Surely if the laptop is running Windows and it overheats it would shut down? I do have Windows Xp installed as well as FreeBSD. I had a quick look in the registry - couldn't find _CRT and CRT was too common. I also found some references to acpi and thermal zone but couldn't take the time to look properly right now (supposed to be working). I could look later if anybody is interested. Chris > From cwhiteh at onetel.com Fri Mar 27 07:03:55 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Fri Mar 27 07:04:02 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <1238118621.1365.35.camel@RabbitsDen> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> <1238118621.1365.35.camel@RabbitsDen> Message-ID: <49CCDCBA.3000406@onetel.com> Alexandre "Sunny" Kovalenko wrote: > On Thu, 2009-03-26 at 16:49 -0700, Nate Lawson wrote: >> Chris Whitehouse wrote: >>> Alexandre "Sunny" Kovalenko wrote: >>>> To be fair, if all you want is to override _CRT, you should be able to >>>> put something to the tune of >>>> >>>> hw.acpi.thermal.user_override=1 >>>> hw.acpi.thermal.tz0._CRT=90C >>>> >>>> in your /etc/sysctl.conf and not deal with the ASL at all. >>> I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until >>> hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change >>> values at which point hw.acpi.thermal.tz0._CRT reverts to -1. >>> > > Looking at ASL I can see five thermal zone objects defined and only one > of them (TZ4) looking somewhat normal: _CRT is 110C and _TMP method goes > to the trouble of making sane return value. Maybe Windows somehow knows > which thermal zones to ignore? Given the snippet below this _was_ geared > heavily towards Windows: > > If (\_OSI ("Windows 2001")) > { > Store (0x04, C014) > } > > If (\_OSI ("Windows 2001 SP1")) > { > Store (0x04, C014) > } > > If (\_OSI ("Windows 2001 SP2")) > { > Store (0x05, C014) > } > > If (\_OSI ("Windows 2006")) > { > Store (0x06, C014) > } > > Chris, you should be able to set hw.acpi.osname= above> in loader.conf and see if things improve somewhat. Note that > "Windows 2001" and "Windows 2001 SP1" are identical. sysctl says it is an unknown oid > > Could you also, please, post the full output of the sysctl > hw.acpi.thermal > hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 1 hw.acpi.thermal.tz0.temperature: 45.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: -1 hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 43.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 102.0C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 105.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 1 hw.acpi.thermal.tz1._TC2: 2 hw.acpi.thermal.tz1._TSP: 300 hw.acpi.thermal.tz2.temperature: 43.0C hw.acpi.thermal.tz2.active: -1 hw.acpi.thermal.tz2.passive_cooling: 0 hw.acpi.thermal.tz2.thermal_flags: 0 hw.acpi.thermal.tz2._PSV: -1 hw.acpi.thermal.tz2._HOT: -1 hw.acpi.thermal.tz2._CRT: 105.0C hw.acpi.thermal.tz2._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz2._TC1: 1 hw.acpi.thermal.tz2._TC2: 2 hw.acpi.thermal.tz2._TSP: 300 hw.acpi.thermal.tz3.temperature: 28.9C hw.acpi.thermal.tz3.active: -1 hw.acpi.thermal.tz3.passive_cooling: 0 hw.acpi.thermal.tz3.thermal_flags: 0 hw.acpi.thermal.tz3._PSV: 60.0C hw.acpi.thermal.tz3._HOT: -1 hw.acpi.thermal.tz3._CRT: 105.0C hw.acpi.thermal.tz3._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz3._TC1: 1 hw.acpi.thermal.tz3._TC2: 2 hw.acpi.thermal.tz3._TSP: 300 hw.acpi.thermal.tz4.temperature: 0.0C hw.acpi.thermal.tz4.active: -1 hw.acpi.thermal.tz4.passive_cooling: 0 hw.acpi.thermal.tz4.thermal_flags: 0 hw.acpi.thermal.tz4._PSV: -1 hw.acpi.thermal.tz4._HOT: -1 hw.acpi.thermal.tz4._CRT: 110.0C hw.acpi.thermal.tz4._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz4._TC1: -1 hw.acpi.thermal.tz4._TC2: -1 hw.acpi.thermal.tz4._TSP: -1 Also fetch www.fishercroft.plus.com/messages.gz will get bits of /var/log/messages with the normal startup messages and the output of #!/bin/sh while [ TRUE ]; do logger \ ` sysctl -n dev.cpu.0.temperature ; sysctl -n dev.cpu.1.temperature ; \ sysctl -n hw.acpi.thermal.tz0.temperature ; sysctl -n hw.acpi.thermal.tz0.active ; sysctl -n hw.acpi.thermal.tz0._CRT ; \ sysctl -n hw.acpi.thermal.tz1.temperature ; sysctl -n hw.acpi.thermal.tz1.active ; sysctl -n hw.acpi.thermal.tz1._CRT ; \ sysctl -n hw.acpi.thermal.tz2.temperature ; sysctl -n hw.acpi.thermal.tz2.active ; sysctl -n hw.acpi.thermal.tz2._CRT ; \ sysctl -n hw.acpi.thermal.tz3.temperature ; sysctl -n hw.acpi.thermal.tz3.active ; sysctl -n hw.acpi.thermal.tz3._CRT ; \ sysctl -n hw.acpi.thermal.tz4.temperature ; sysctl -n hw.acpi.thermal.tz4.active ; sysctl -n hw.acpi.thermal.tz4._CRT ` sleep 5 done (sorry bad wrapping) The two cpu temps come from coretemp.ko module. While this was running I changed the temp with burnK7 and an icepack :). It's clear that the messages do correspond to changes of state but there are further triggers that I am not watching. Chris From martin at email.aon.at Sat Mar 28 01:50:03 2009 From: martin at email.aon.at (Martin Birgmeier) Date: Sat Mar 28 01:50:10 2009 Subject: kern/132602: [acpi] ACPI Problem with Intel SS4200: System does not power off Message-ID: <200903280850.n2S8o248092794@freefall.freebsd.org> The following reply was made to PR kern/132602; it has been noted by GNATS. From: Martin Birgmeier To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132602: [acpi] ACPI Problem with Intel SS4200: System does not power off Date: Sat, 28 Mar 2009 09:43:36 +0100 (CET) From the description I'd say that this is a duplicate of the bug report I submitted, kern/130683. From smithi at nimnet.asn.au Sun Mar 29 07:20:49 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sun Mar 29 07:20:56 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49CCDCBA.3000406@onetel.com> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> <1238118621.1365.35.camel@RabbitsDen> <49CCDCBA.3000406@onetel.com> Message-ID: <20090329223815.U95588@sola.nimnet.asn.au> On Fri, 27 Mar 2009, Chris Whitehouse wrote: > Alexandre "Sunny" Kovalenko wrote: > > On Thu, 2009-03-26 at 16:49 -0700, Nate Lawson wrote: > > > Chris Whitehouse wrote: > > > > Alexandre "Sunny" Kovalenko wrote: > > > > > To be fair, if all you want is to override _CRT, you should be able > > > > > to > > > > > put something to the tune of > > > > > > > > > > hw.acpi.thermal.user_override=1 > > > > > hw.acpi.thermal.tz0._CRT=90C > > > > > > > > > > in your /etc/sysctl.conf and not deal with the ASL at all. > > > > I tried this and it sets hw.acpi.thermal.tz0._CRT correctly until > > > > hw.acpi.thermal.tz0.active and hw.acpi.thermal.tz0.temperature change > > > > values at which point hw.acpi.thermal.tz0._CRT reverts to -1. > > > > > > > > Looking at ASL I can see five thermal zone objects defined and only one > > of them (TZ4) looking somewhat normal: _CRT is 110C and _TMP method goes > > to the trouble of making sane return value. Maybe Windows somehow knows > > which thermal zones to ignore? Given the snippet below this _was_ geared > > heavily towards Windows: However looking at Chris' messages listing linked below, TZ4 is strange. It's the one that got hottest during the burnk7 run, 10C below _CRT, steps seem sometimes to be 15 or 20C, and occasionally it reports 0C. It controls nothing obvious, maybe it only exists to trigger on _CRT? No, later looking at ThermalZone (TZ4) it seems to clip readings at 100C anyway and doesn't have a _CRT method .. but I'm an ASL neophyte .. > > If (\_OSI ("Windows 2001")) > > { > > Store (0x04, C014) > > } > > > > If (\_OSI ("Windows 2001 SP1")) > > { > > Store (0x04, C014) > > } > > > > If (\_OSI ("Windows 2001 SP2")) > > { > > Store (0x05, C014) > > } > > > > If (\_OSI ("Windows 2006")) > > { > > Store (0x06, C014) > > } > > > > Chris, you should be able to set hw.acpi.osname= > above> in loader.conf and see if things improve somewhat. Note that > > "Windows 2001" and "Windows 2001 SP1" are identical. > > sysctl says it is an unknown oid Try adding it to loader.conf and rebooting. > > Could you also, please, post the full output of the sysctl > > hw.acpi.thermal > > > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 1 > hw.acpi.thermal.tz0.temperature: 45.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: -1 > hw.acpi.thermal.tz0._ACx: 80.0C 70.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 >From your messages listing I guess this is the heatsink sensor, running the fan. 5C steps up to 60C then 10C steps above. values returned are a little on the high side of either coretemp or tz[12].temperature. No _CRT value (shown here) though the value returned by the _CRT method seems to be causing the problem? >From what I can figure for TZ0: Method (_CRT, 0, Serialized) { Return (C316 (0x04, 0x00)) } where: Method (C316, 2, Serialized) { Store (0x01, Local0) Store (Arg0, Local1) Store (DerefOf (Index (C312, Arg1)), Local3) If (LEqual (Local3, 0xFFFFFFFD)) { Store (0x00, Local3) } If (LLess (Arg0, Local3)) { Store (0x00, Local0) Add (Arg0, 0x01, Local1) } Store (DerefOf (Index (DerefOf (Index (DerefOf (Index (C305, C317 (Arg1) )), Local0)), Local1)), Local2) Return (Local2) } but I got lost amongst the DerefOf (Index ..) nesting, not quite like following source with helpfully symbolic names. Good luck Alexandre! > hw.acpi.thermal.tz1.temperature: 43.0C > hw.acpi.thermal.tz1.active: -1 > hw.acpi.thermal.tz1.passive_cooling: 1 > hw.acpi.thermal.tz1.thermal_flags: 0 > hw.acpi.thermal.tz1._PSV: 102.0C > hw.acpi.thermal.tz1._HOT: -1 > hw.acpi.thermal.tz1._CRT: 105.0C > hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz1._TC1: 1 > hw.acpi.thermal.tz1._TC2: 2 > hw.acpi.thermal.tz1._TSP: 300 Quacks like a CPU0. This one triggers passive cooling. Its temperature values are generally 2-3C lower than the (eyeball) average of coretemp values, except when heating up fast, when it lags the latter by 5-6C. I don't know where these various sensors live. Board? Package? Die? > hw.acpi.thermal.tz2.temperature: 43.0C > hw.acpi.thermal.tz2.active: -1 > hw.acpi.thermal.tz2.passive_cooling: 0 > hw.acpi.thermal.tz2.thermal_flags: 0 > hw.acpi.thermal.tz2._PSV: -1 > hw.acpi.thermal.tz2._HOT: -1 > hw.acpi.thermal.tz2._CRT: 105.0C > hw.acpi.thermal.tz2._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz2._TC1: 1 > hw.acpi.thermal.tz2._TC2: 2 > hw.acpi.thermal.tz2._TSP: 300 CPU1. From the messages it appears that burnk7 ran on just CPU0 (tz1). Snippets like this seem to confirm the cpu to tz allocation: Notify (\_PR.CPU0, 0x80) Notify (\_PR.CPU1, 0x80) Notify (\_TZ.TZ1, 0x81) Notify (\_TZ.TZ2, 0x81) > hw.acpi.thermal.tz3.temperature: 28.9C > hw.acpi.thermal.tz3.active: -1 > hw.acpi.thermal.tz3.passive_cooling: 0 > hw.acpi.thermal.tz3.thermal_flags: 0 > hw.acpi.thermal.tz3._PSV: 60.0C > hw.acpi.thermal.tz3._HOT: -1 > hw.acpi.thermal.tz3._CRT: 105.0C > hw.acpi.thermal.tz3._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz3._TC1: 1 > hw.acpi.thermal.tz3._TC2: 2 > hw.acpi.thermal.tz3._TSP: 300 This returned 28.[89]C throughout, too consistently to be anything real, except perhaps ambient external temperature? Even then it's too steady. > hw.acpi.thermal.tz4.temperature: 0.0C > hw.acpi.thermal.tz4.active: -1 > hw.acpi.thermal.tz4.passive_cooling: 0 > hw.acpi.thermal.tz4.thermal_flags: 0 > hw.acpi.thermal.tz4._PSV: -1 > hw.acpi.thermal.tz4._HOT: -1 > hw.acpi.thermal.tz4._CRT: 110.0C > hw.acpi.thermal.tz4._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz4._TC1: -1 > hw.acpi.thermal.tz4._TC2: -1 > hw.acpi.thermal.tz4._TSP: -1 As above, a mystery. > Also > fetch www.fishercroft.plus.com/messages.gz > > will get bits of /var/log/messages with the normal startup messages and the > output of > > #!/bin/sh > while [ TRUE ]; do > logger \ > ` sysctl -n dev.cpu.0.temperature ; sysctl -n dev.cpu.1.temperature ; \ > sysctl -n hw.acpi.thermal.tz0.temperature ; sysctl -n > hw.acpi.thermal.tz0.active ; sysctl -n hw.acpi.thermal.tz0._CRT ; \ > sysctl -n hw.acpi.thermal.tz1.temperature ; sysctl -n > hw.acpi.thermal.tz1.active ; sysctl -n hw.acpi.thermal.tz1._CRT ; \ > sysctl -n hw.acpi.thermal.tz2.temperature ; sysctl -n > hw.acpi.thermal.tz2.active ; sysctl -n hw.acpi.thermal.tz2._CRT ; \ > sysctl -n hw.acpi.thermal.tz3.temperature ; sysctl -n > hw.acpi.thermal.tz3.active ; sysctl -n hw.acpi.thermal.tz3._CRT ; \ > sysctl -n hw.acpi.thermal.tz4.temperature ; sysctl -n > hw.acpi.thermal.tz4.active ; sysctl -n hw.acpi.thermal.tz4._CRT ` > sleep 5 > done > > (sorry bad wrapping) Good data. I don't know if it helps track the ASL re $subject though. > The two cpu temps come from coretemp.ko module. These I don't get. They always track a few degrees above tz1 value, but rarely differ by more than 2C, while your burnk7 run showed CPU0 getting much hotter than CPU1, which only slowly rose during the run, indicating sympathetic package warming with an essentially idle CPU1, perhaps? > While this was running I changed the temp with burnK7 and an icepack :). It's > clear that the messages do correspond to changes of state but there are > further triggers that I am not watching. Sure, but educational. I won't ask where you applied the icepack :) cheers, Ian From cwhiteh at onetel.com Sun Mar 29 07:42:58 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Sun Mar 29 07:43:05 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) FIX? In-Reply-To: <49C93309.6050708@iki.fi> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> Message-ID: <49CF87E5.5020107@onetel.com> Pasi Parviainen wrote: > Chris Whitehouse wrote: >> Hi, I sent this a while ago but don't think there was a reply. I'm >> about to embark on a custom ASL to load in loader.conf as per >> http://www.freebsd.org/doc/en/books/handbook/acpi-debug.html but just >> wondering if their might be a 'proper' fix on the way. I do have the >> latest bios installed. > > Loading custom ASL with modified _CRT value for temperature zone in > question will solve the problem, see below for more information. > --- /nc6320.asl 2009-03-28 21:21:25.000000000 +0000 +++ /nc6320.TZ0._CRT.95C.asl 2009-03-29 16:16:16.000000000 +0100 @@ -146,7 +146,7 @@ * Intel ACPI Component Architecture * AML Disassembler version 20070320 * - * Disassembly of /tmp/acpidump.RLCPmU, Sat Mar 28 21:21:25 2009 + * Disassembly of /tmp/acpidump.nryPEu, Sat Mar 28 18:02:15 2009 * * * Original Table Header: @@ -12940,7 +12940,7 @@ Method (_CRT, 0, Serialized) { - Return (C316 (0x04, 0x00)) + Return (C316 (0x00, 0x02)) } Method (_TMP, 0, Serialized) These values set hw.acpi.thermal.tz0._CRT to 95.0C. I tested various values which gave different _CRT temps, some of which were below hw.acpi.thermal.tz0.temperature. The messages have stopped and I now know that the machine will shut down if the temperature is exceeded. Thanks everybody for suggestions and pointers. Chris From cwhiteh at onetel.com Sun Mar 29 15:53:54 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Sun Mar 29 15:54:00 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <20090329223815.U95588@sola.nimnet.asn.au> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> <1238118621.1365.35.camel@RabbitsDen> <49CCDCBA.3000406@onetel.com> <20090329223815.U95588@sola.nimnet.asn.au> Message-ID: <49CFFBBE.30605@onetel.com> Ian Smith wrote: > > > If (\_OSI ("Windows 2001")) > > > { > > > Store (0x04, C014) > > > } > > > > > > If (\_OSI ("Windows 2001 SP1")) > > > { > > > Store (0x04, C014) > > > } > > > > > > If (\_OSI ("Windows 2001 SP2")) > > > { > > > Store (0x05, C014) > > > } > > > > > > If (\_OSI ("Windows 2006")) > > > { > > > Store (0x06, C014) > > > } > > > > > > Chris, you should be able to set hw.acpi.osname= > > above> in loader.conf and see if things improve somewhat. Note that > > > "Windows 2001" and "Windows 2001 SP1" are identical. > > > > sysctl says it is an unknown oid > > Try adding it to loader.conf and rebooting. Nope still unknown oid. But in view of other progress I don't think that matters, at least for me. > Quacks like a CPU0. This one triggers passive cooling. Its temperature > values are generally 2-3C lower than the (eyeball) average of coretemp > values, except when heating up fast, when it lags the latter by 5-6C. > > I don't know where these various sensors live. Board? Package? Die? > > > hw.acpi.thermal.tz2.temperature: 43.0C > > hw.acpi.thermal.tz2.active: -1 > > hw.acpi.thermal.tz2.passive_cooling: 0 > > hw.acpi.thermal.tz2.thermal_flags: 0 > > hw.acpi.thermal.tz2._PSV: -1 > > hw.acpi.thermal.tz2._HOT: -1 > > hw.acpi.thermal.tz2._CRT: 105.0C > > hw.acpi.thermal.tz2._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > hw.acpi.thermal.tz2._TC1: 1 > > hw.acpi.thermal.tz2._TC2: 2 > > hw.acpi.thermal.tz2._TSP: 300 > > CPU1. From the messages it appears that burnk7 ran on just CPU0 (tz1). For some of the time I was running one instance of burnK7, other times 2 instances. I just tested and 2 instances does run on both cores. > > fetch www.fishercroft.plus.com/messages.gz > > > > will get bits of /var/log/messages with the normal startup messages and the > > output of > > > > #!/bin/sh > > while [ TRUE ]; do > > logger \ > > ` sysctl -n dev.cpu.0.temperature ; sysctl -n dev.cpu.1.temperature ; \ > > sysctl -n hw.acpi.thermal.tz0.temperature ; sysctl -n > > hw.acpi.thermal.tz0.active ; sysctl -n hw.acpi.thermal.tz0._CRT ; \ > > sysctl -n hw.acpi.thermal.tz1.temperature ; sysctl -n > > hw.acpi.thermal.tz1.active ; sysctl -n hw.acpi.thermal.tz1._CRT ; \ > > sysctl -n hw.acpi.thermal.tz2.temperature ; sysctl -n > > hw.acpi.thermal.tz2.active ; sysctl -n hw.acpi.thermal.tz2._CRT ; \ > > sysctl -n hw.acpi.thermal.tz3.temperature ; sysctl -n > > hw.acpi.thermal.tz3.active ; sysctl -n hw.acpi.thermal.tz3._CRT ; \ > > sysctl -n hw.acpi.thermal.tz4.temperature ; sysctl -n > > hw.acpi.thermal.tz4.active ; sysctl -n hw.acpi.thermal.tz4._CRT ` > > sleep 5 > > done > > > > (sorry bad wrapping) > > Good data. I don't know if it helps track the ASL re $subject though. > > > The two cpu temps come from coretemp.ko module. > > These I don't get. They always track a few degrees above tz1 value, but > rarely differ by more than 2C, while your burnk7 run showed CPU0 getting > much hotter than CPU1, which only slowly rose during the run, indicating > sympathetic package warming with an essentially idle CPU1, perhaps? Do you mean TZ1 gets much hotter than TZ2? When I ran 2 instances of burnk7 one ran on each cpu (viewed in top). When I ran a single instance the on-die temps in the first two columns still tracked each other. Also this machine is running KDE which is always doing something which blurs the figures a bit. I put messages2 next the previous one, I think it shows that tz2 is not cpu1 even if tz1 is measuring cpu temp somehow. dev.cpu.n.temperature columns are the on-die temps. Those oids are only visible when coretemp is loaded, I don't know if the ASL is using those temperature probes. Chris From smithi at nimnet.asn.au Mon Mar 30 00:13:35 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Mon Mar 30 00:13:42 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <49CFFBBE.30605@onetel.com> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> <1238118621.1365.35.camel@RabbitsDen> <49CCDCBA.3000406@onetel.com> <20090329223815.U95588@sola.nimnet.asn.au> <49CFFBBE.30605@onetel.com> Message-ID: <20090330174824.L95588@sola.nimnet.asn.au> On Sun, 29 Mar 2009, Chris Whitehouse wrote: > Ian Smith wrote: [..] > > Try adding it to loader.conf and rebooting. > > Nope still unknown oid. But in view of other progress I don't think that > matters, at least for me. Good to see you got there with the patched ASL; should help others too. > > I don't know where these various sensors live. Board? Package? Die? > > > > > hw.acpi.thermal.tz2.temperature: 43.0C > > > hw.acpi.thermal.tz2.active: -1 > > > hw.acpi.thermal.tz2.passive_cooling: 0 > > > hw.acpi.thermal.tz2.thermal_flags: 0 > > > hw.acpi.thermal.tz2._PSV: -1 > > > hw.acpi.thermal.tz2._HOT: -1 > > > hw.acpi.thermal.tz2._CRT: 105.0C > > > hw.acpi.thermal.tz2._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > hw.acpi.thermal.tz2._TC1: 1 > > > hw.acpi.thermal.tz2._TC2: 2 > > > hw.acpi.thermal.tz2._TSP: 300 > > > > CPU1. From the messages it appears that burnk7 ran on just CPU0 (tz1). > > For some of the time I was running one instance of burnK7, other times 2 > instances. I just tested and 2 instances does run on both cores. Right. I was well wrong about CPU1 being TZ2. Perhaps its the GPU? If still interested, something like glxgears would test the theory. The same _CRT and _TC1,TC2,TSP values did assist me into false assumption :) > > > The two cpu temps come from coretemp.ko module. > > > > These I don't get. They always track a few degrees above tz1 value, but > > rarely differ by more than 2C, while your burnk7 run showed CPU0 getting > > much hotter than CPU1, which only slowly rose during the run, indicating > > sympathetic package warming with an essentially idle CPU1, perhaps? > > Do you mean TZ1 gets much hotter than TZ2? When I ran 2 instances of burnk7 > one ran on each cpu (viewed in top). When I ran a single instance the on-die > temps in the first two columns still tracked each other. Also this machine is > running KDE which is always doing something which blurs the figures a bit. > > I put messages2 next the previous one, I think it shows that tz2 is not cpu1 > even if tz1 is measuring cpu temp somehow. dev.cpu.n.temperature columns are > the on-die temps. Those oids are only visible when coretemp is loaded, I > don't know if the ASL is using those temperature probes. http://www.fishercroft.plus.com/messages2.gz indeed does show that. Making sense now; there's no reason two sensors on one die should vary much, so there's no need for a separate TZ for the second core. Sorry if my further education was at the expense of your problem .. cheers, Ian From bugmaster at FreeBSD.org Mon Mar 30 04:06:47 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Mar 30 04:07:09 2009 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200903301106.n2UB6k7h054632@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D o kern/129618 acpi [acpi] Problem with ACPI on HP Pavilion DV2899 laptop o kern/129563 acpi [acpi] sleep broken on IBM/Lenovo T61 in amd64 mode o kern/128639 acpi [patch] [acpi_asus] acpi for ASUS A6F,A3E,A3F,A3N not f kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/127581 acpi [patch] [acpi_sony] Add support for more Sony features o kern/124744 acpi [acpi] [patch] incorrect _BST result validation for To o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be f kern/89411 acpi [acpi] acpiconf bug o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys s kern/73823 acpi [request] acpi / power-on by timer support o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 o i386/69750 acpi Boot without ACPI failed on ASUS L5 f kern/67309 acpi zzz reboot computer (ACPI S3) o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop 47 problems total. From cwhiteh at onetel.com Mon Mar 30 17:02:12 2009 From: cwhiteh at onetel.com (Chris Whitehouse) Date: Mon Mar 30 17:02:20 2009 Subject: acpi_tz0: _CRT value is absurd, ignored (256.0C) (was pr kern/105537) In-Reply-To: <20090330174824.L95588@sola.nimnet.asn.au> References: <49C80E65.9090500@onetel.com> <49C93309.6050708@iki.fi> <20090325140718.J95588@sola.nimnet.asn.au> <49C9EE50.6070507@onetel.com> <1237992462.1297.22.camel@RabbitsDen> <49CBF7D1.20102@onetel.com> <49CC147A.3030805@root.org> <1238118621.1365.35.camel@RabbitsDen> <49CCDCBA.3000406@onetel.com> <20090329223815.U95588@sola.nimnet.asn.au> <49CFFBBE.30605@onetel.com> <20090330174824.L95588@sola.nimnet.asn.au> Message-ID: <49D15D61.5090503@onetel.com> Ian Smith wrote: > On Sun, 29 Mar 2009, Chris Whitehouse wrote: > > Ian Smith wrote: > [..] > > > Try adding it to loader.conf and rebooting. > > > > Nope still unknown oid. But in view of other progress I don't think that > > matters, at least for me. > > Good to see you got there with the patched ASL; should help others too. You can get different values of tz0._CRT by choosing the two hex values: 0x00 0x00 45.0C 0x00 0x01 102.0C 0x00 0x02 95.0C 0x00 0x03 60.0C 0x01 0x00 55.0C 0x01 0x01 60.0C 0x01 0x02 105.0C 0x01 0x03 127.1C 0x02 0x00 70.0C 0x02 0x01 127.1C 0x02 0x02 127.1C 0x03 0x00 80.0C All the others I tried gave -1 Actually I think the patch may be a bit of a bodge. I think the values I changed are pointers to hard coded values in the ASL. It would be much nicer to identify the actual values in the ASL and add a new one for tz0._CRT. > > > > I don't know where these various sensors live. Board? Package? Die? > > > > > > > hw.acpi.thermal.tz2.temperature: 43.0C > > > > hw.acpi.thermal.tz2.active: -1 > > > > hw.acpi.thermal.tz2.passive_cooling: 0 > > > > hw.acpi.thermal.tz2.thermal_flags: 0 > > > > hw.acpi.thermal.tz2._PSV: -1 > > > > hw.acpi.thermal.tz2._HOT: -1 > > > > hw.acpi.thermal.tz2._CRT: 105.0C > > > > hw.acpi.thermal.tz2._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > > > hw.acpi.thermal.tz2._TC1: 1 > > > > hw.acpi.thermal.tz2._TC2: 2 > > > > hw.acpi.thermal.tz2._TSP: 300 > > > > > > CPU1. From the messages it appears that burnk7 ran on just CPU0 (tz1). > > > > For some of the time I was running one instance of burnK7, other times 2 > > instances. I just tested and 2 instances does run on both cores. > > Right. I was well wrong about CPU1 being TZ2. Perhaps its the GPU? > If still interested, something like glxgears would test the theory. The > same _CRT and _TC1,TC2,TSP values did assist me into false assumption :) See www.fishercroft.plus.com/messages3.gz. This was with 2 x glxgears and firefox streaming a flash video (yeay fbsd can do flash video :)). Looks like tz4 is gpu. The service manual which I just discovered mentions temperature limits for hard disk and battery, maybe those are zones as well but no time to test right now. I just tested the url in firefox and it displays the text, ie it gunzips it!! Amazing! > > > > > The two cpu temps come from coretemp.ko module. > > > > > > These I don't get. They always track a few degrees above tz1 value, but > > > rarely differ by more than 2C, while your burnk7 run showed CPU0 getting > > > much hotter than CPU1, which only slowly rose during the run, indicating > > > sympathetic package warming with an essentially idle CPU1, perhaps? > > > > Do you mean TZ1 gets much hotter than TZ2? When I ran 2 instances of burnk7 > > one ran on each cpu (viewed in top). When I ran a single instance the on-die > > temps in the first two columns still tracked each other. Also this machine is > > running KDE which is always doing something which blurs the figures a bit. > > > > I put messages2 next the previous one, I think it shows that tz2 is not cpu1 > > even if tz1 is measuring cpu temp somehow. dev.cpu.n.temperature columns are > > the on-die temps. Those oids are only visible when coretemp is loaded, I > > don't know if the ASL is using those temperature probes. > > http://www.fishercroft.plus.com/messages2.gz indeed does show that. > > Making sense now; there's no reason two sensors on one die should vary > much, so there's no need for a separate TZ for the second core. > > Sorry if my further education was at the expense of your problem .. Education is good :) > > cheers, Ian > From masterone at o0l0o.org Tue Mar 31 05:50:03 2009 From: masterone at o0l0o.org (Master One) Date: Tue Mar 31 05:50:10 2009 Subject: kern/132602: [acpi] ACPI Problem with Intel SS4200: System does not power off Message-ID: <200903311250.n2VCo3J2081622@freefall.freebsd.org> The following reply was made to PR kern/132602; it has been noted by GNATS. From: Master One To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/132602: [acpi] ACPI Problem with Intel SS4200: System does not power off Date: Tue, 31 Mar 2009 14:33:15 +0200 If it is of any interest, here is a dmesg from that machine: 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-RELEASE-p3 #0: Mon Mar 9 22:22:06 UTC 2009 root@vmbsd64amd64:/usr/obj/freenas/usr/src/sys/FREENAS-amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 420 @ 1.60GHz (1600.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10661 Stepping = 1 Features=0xafebfbff Features2=0xe31d AMD Features=0x20100800 AMD Features2=0x1 real memory = 2147287040 (2047 MB) avail memory = 1970548736 (1879 MB) ACPI APIC Table: <121907 APIC1340> ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Mar 9 2009 22:21:59) acpi0: <121907 XSDT1340> on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 p4tcc0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 em0: port 0xbc00-0xbc1f mem 0xff7e0000-0xff7fffff irq 16 at device 0.0 on pci1 em0: Using MSI interrupt em0: Ethernet address: 00:15:17:31:d9:2b pcib2: irq 18 at device 28.2 on pci0 pci2: on pcib2 atapci0: port 0xcc00-0xcc7f mem 0xff9ffc00-0xff9ffc7f,0xff9f8000-0xff9fbfff irq 18 at device 0.0 on pci2 ata2: on atapci0 ata3: on atapci0 uhci0: port 0xe080-0xe09f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe000-0xe01f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xdc00-0xdc1f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xd880-0xd89f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xffa3f800-0xffa3fbff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered umass0: USBest Technology USB Mass Storage Device, rev 2.00/1.00, addr 2 pcib3: at device 30.0 on pci0 pci3: on pcib3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xec00-0xec07,0xe880-0xe883,0xe800-0xe807,0xe480-0xe483,0xe400-0xe40f mem 0xffaffc00-0xffafffff irq 19 at device 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 4 ports detected ata4: on atapci1 ata5: on atapci1 ata6: on atapci1 ata7: on atapci1 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 speaker0: port 0x61 on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: cannot reserve I/O port range sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounter "TSC" frequency 1600010792 Hz quality 800 Timecounters tick every 1.000 msec IPv6 packet filtering initialized, default to accept, logging limited to 5 packets/entry ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging limited to 5 packets/entry by default hptrr: no controller detected. md0: Preloaded image 90177536 bytes at 0xffffffff80bb5e08 ad4: 239372MB at ata2-master SATA150 ad6: 239372MB at ata3-master SATA150 ad8: 953869MB at ata4-master SATA300 ad10: 953869MB at ata5-master SATA300 ad12: 953869MB at ata6-master SATA300 ad14: 953869MB at ata7-master SATA300 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 454MB (930560 512 byte sectors: 64H 32S/T 454C) cd0 at umass-sim0 bus 0 target 0 lun 1 cd0: Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present em0: link state changed to UP