From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 07:17:07 2010 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E09D6106568B; Mon, 1 Feb 2010 07:17:07 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B8A838FC22; Mon, 1 Feb 2010 07:17:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o117H7N1037833; Mon, 1 Feb 2010 07:17:07 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o117H7N6037829; Mon, 1 Feb 2010 07:17:07 GMT (envelope-from linimon) Date: Mon, 1 Feb 2010 07:17:07 GMT Message-Id: <201002010717.o117H7N6037829@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143420: [acpi] ACPI issues with Toshiba X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 07:17:08 -0000 Old Synopsis: ACPI issues with Toshiba New Synopsis: [acpi] ACPI issues with Toshiba Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 1 07:16:50 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143420 From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 11:06:49 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02A46106568D for ; Mon, 1 Feb 2010 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CB1538FC13 for ; Mon, 1 Feb 2010 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o11B6m3v062696 for ; Mon, 1 Feb 2010 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o11B6m2w062694 for freebsd-acpi@FreeBSD.org; Mon, 1 Feb 2010 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Feb 2010 11:06:48 GMT Message-Id: <201002011106.o11B6m2w062694@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 11:06:49 -0000 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/143420 acpi [acpi] ACPI issues with Toshiba o kern/142263 acpi [acpi] ACPI regression on Asus K8N7-E deluxe motherboa o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/140979 acpi [acpi] [panic] Kernel panic (fatal trap 12: page fault o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o kern/136808 acpi [acpi] panic when switching to s3 o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/135070 acpi [acpi] [patch] BIOS resource allocation and FreeBSD AC 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 f 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 amd64/121439 acpi [boot] Installation of FreeBSD 7.0 fails: ACPI problem 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 o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 f 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 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 59 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 15:40:03 2010 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60D121065670 for ; Mon, 1 Feb 2010 15:40:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 34CF18FC12 for ; Mon, 1 Feb 2010 15:40:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o11Fe3JL009976 for ; Mon, 1 Feb 2010 15:40:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o11Fe2cP009974; Mon, 1 Feb 2010 15:40:03 GMT (envelope-from gnats) Date: Mon, 1 Feb 2010 15:40:03 GMT Message-Id: <201002011540.o11Fe2cP009974@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: msherman77@gmail.com Cc: Subject: Re: Re: misc/143420: ACPI issues with Toshiba X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: msherman77@gmail.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 15:40:03 -0000 The following reply was made to PR kern/143420; it has been noted by GNATS. From: msherman77@gmail.com To: Garrett Cooper Cc: freebsd-gnats-submit@freebsd.org Subject: Re: Re: misc/143420: ACPI issues with Toshiba Date: Mon, 01 Feb 2010 15:02:47 +0000 --0016e648d93c37dc8e047e8b47b3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes On Feb 1, 2010 12:35am, Garrett Cooper wrote: > On Sun, Jan 31, 2010 at 9:22 PM, Michael msherman77@gmail.com> wrote: > > > >>Number: 143420 > >>Category: misc > >>Synopsis: ACPI issues with Toshiba > >>Confidential: no > >>Severity: serious > >>Priority: medium > >>Responsible: freebsd-bugs > >>State: open > >>Quarter: > >>Keywords: > >>Date-Required: > >>Class: sw-bug > >>Submitter-Id: current-users > >>Arrival-Date: Mon Feb 01 05:30:07 UTC 2010 > >>Closed-Date: > >>Last-Modified: > >>Originator: Michael > >>Release: 8.0 (PCBSD 8.0 Beta) > >>Organization: > >>Environment: > > FreeBSD pcbsd-2645 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #3: Fri Dec 11 > 13:33:42 PST 2009 > root@build8x32.pcbsd.org:/usr/obj/usr/pcbsd-build80/fbsd-source/8.0-src/sys/PCBSD > i386 > >>Description: > > I just installed PCBSD 8.0 Beta (which is FreeBSD 8.0 release-p1) on > > my Toshiba Satellite. > > Specs: CPU: 1.9 Ghz Athlon X 2. Video: ATI chipset (radeonhd driver) > > Audio: Intel (sound_hda) Wireless: (Atheros driver) > > ACPI doesn't fully work. No suspend / resume, but I can live without it. > > > > What does bother me is that the laptop runs very hot 60+ C. Other > > systems run at ~45 - 50C > > Enabling powerd makes system very slow (almost unusable) and produces > > the message: set freq failed, error 6 > > > > dmesg.boot > > > > Copyright (c) 1992-2009 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 8.0-RELEASE-p1 #3: Fri Dec 11 13:33:42 PST 2009 > > root at > build8x32.pcbsd.org:/usr/obj/usr/pcbsd-build80/fbsd-source/8.0-src/sys/PCBSD > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: AMD Athlon(tm) X2 Dual-Core QL-60 (1895.28-MHz 686-class CPU) > > Origin = "AuthenticAMD" Id = 0x200f31 Stepping = 1 > > Features=0x178bfbff > > Features2=0x2001 > > AMD Features=0xea500800 > > AMD Features2=0x131f > > TSC: P-state invariant > > real memory = 2147483648 (2048 MB) > > avail memory = 1821257728 (1736 MB) > > ACPI APIC Table: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > > FreeBSD/SMP: 1 package(s) x 2 core(s) > > cpu0 (BSP): APIC ID: 0 > > cpu1 (AP): APIC ID: 1 > > ioapic0: Changing APIC ID to 4 > > ioapic0 irqs 0-23 on motherboard > > kbd1 at kbdmux0 > > module_register_init: MOD_LOAD (splash_pcx, 0xc0fbe830, 0) error 2 > > cryptosoft0: on motherboard > > acpi0: on motherboard > > acpi0: [ITHREAD] > > acpi0: Power Button (fixed) > > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > > acpi_timer0: port 0x408-0x40b on acpi0 > > acpi_ec0: port 0x62,0x66 on acpi0 > > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > > Timecounter "HPET" frequency 14318180 Hz quality 900 > > acpi_button0: on acpi0 > > acpi_lid0: on acpi0 > > battery0: on acpi0 > > acpi_acad0: on acpi0 > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > pcib1: at device 1.0 on pci0 > > pci1: on pcib1 > > vgapci0: port 0x6000-0x60ff mem > > 0x80000000-0x8fffffff,0x96300000-0x9630ffff,0x96200000-0x962fffff irq > > 18 at device 5.0 on pci1 > > pcib2: at device 4.0 on pci0 > > pci2: on pcib2 > > pcib3: at device 5.0 on pci0 > > pci4: on pcib3 > > re0: port 0x3000-0x30ff > > mem 0x91010000-0x91010fff,0x91000000-0x9100ffff irq 17 at device 0.0 > > on pci4 > > re0: Using 1 MSI messages > > re0: Chip rev. 0x34800000 > > re0: MAC rev. 0x00000000 > > miibus0: on re0 > > rlphy0: PHY 1 on miibus0 > > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > re0: Ethernet address: 00:1e:33:46:bb:a0 > > re0: [FILTER] > > pcib4: at device 6.0 on pci0 > > pci5: on pcib4 > > ath0: mem 0x93100000-0x9310ffff irq 18 at device 0.0 on pci5 > > ath0: [ITHREAD] > > ath0: AR2425 mac 14.2 RF5424 phy 7.0 > > pcib5: at device 7.0 on pci0 > > pci6: on pcib5 > > atapci0: port > > 0x7038-0x703f,0x704c-0x704f,0x7030-0x7037,0x7048-0x704b,0x7010-0x701f > > mem 0x96408000-0x964083ff irq 22 at device 17.0 on pci0 > > atapci0: [ITHREAD] > > atapci0: AHCI v1.10 controller with 6 3Gbps ports, PM supported > > ata2: on atapci0 > > ata2: port is not ready (timeout 0ms) tfd = 000001d0 > > ata2: software reset clear timeout > > ata2: [ITHREAD] > > ata3: on atapci0 > > ata3: [ITHREAD] > > ata4: on atapci0 > > ata4: port is not ready (timeout 0ms) tfd = 00000180 > > ata4: software reset clear timeout > > ata4: [ITHREAD] > > ata5: on atapci0 > > ata5: [ITHREAD] > > ata6: on atapci0 > > ata6: [ITHREAD] > > ata7: on atapci0 > > ata7: [ITHREAD] > > ohci0: mem 0x96407000-0x96407fff irq > > 16 at device 18.0 on pci0 > > ohci0: [ITHREAD] > > usbus0: on ohci0 > > ohci1: mem 0x96406000-0x96406fff irq > > 16 at device 18.1 on pci0 > > ohci1: [ITHREAD] > > usbus1: on ohci1 > > ehci0: mem 0x96408500-0x964085ff > > irq 17 at device 18.2 on pci0 > > ehci0: [ITHREAD] > > usbus2: waiting for BIOS to give up control > > usbus2: EHCI version 1.0 > > usbus2: on ehci0 > > ohci2: mem 0x96405000-0x96405fff irq > > 18 at device 19.0 on pci0 > > ohci2: [ITHREAD] > > usbus3: on ohci2 > > ohci3: mem 0x96404000-0x96404fff irq > > 18 at device 19.1 on pci0 > > ohci3: [ITHREAD] > > usbus4: on ohci3 > > ehci1: mem 0x96408400-0x964084ff > > irq 19 at device 19.2 on pci0 > > ehci1: [ITHREAD] > > usbus5: waiting for BIOS to give up control > > usbus5: EHCI version 1.0 > > usbus5: on ehci1 > > pci0: at device 20.0 (no driver attached) > > atapci1: port > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x7000-0x700f irq 16 at device > > 20.1 on pci0 > > ata0: on atapci1 > > ata0: [ITHREAD] > > ata1: on atapci1 > > ata1: [ITHREAD] > > pci0: at device 20.2 (no driver attached) > > isab0: at device 20.3 on pci0 > > isa0: on isab0 > > pcib6: at device 20.4 on pci0 > > pci128: on pcib6 > > acpi_tz0: on acpi0 > > atrtc0: port 0x70-0x71 on acpi0 > > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > atkbd0: irq 1 on atkbdc0 > > kbd0 at atkbd0 > > atkbd0: [GIANT-LOCKED] > > atkbd0: [ITHREAD] > > psm0: flags 0x1000 irq 12 on atkbdc0 > > psm0: [GIANT-LOCKED] > > psm0: [ITHREAD] > > psm0: model Generic PS/2 mouse, device ID 0 > > cpu0: on acpi0 > > acpi_throttle0: on cpu0 > > hwpstate0: on cpu0 > > cpu1: on acpi0 > > pmtimer0 on isa0 > > orm0: at iomem 0xcf000-0xcffff pnpid ORM0000 on isa0 > > sc0: at flags 0x100 on isa0 > > sc0: VGA > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > > ppc0: parallel port not found. > > ZFS NOTICE: Prefetch is disabled by default on i386 -- to enable, > > add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. > > ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable > behavior. > > Consider tuning vm.kmem_size and vm.kmem_size_max > > in /boot/loader.conf. > > ZFS filesystem version 13 > > ZFS storage pool version 13 > > Timecounters tick every 1.000 msec > > usbus0: 12Mbps Full Speed USB v1.0 > > usbus1: 12Mbps Full Speed USB v1.0 > > usbus2: 480Mbps High Speed USB v2.0 > > usbus3: 12Mbps Full Speed USB v1.0 > > usbus4: 12Mbps Full Speed USB v1.0 > > usbus5: 480Mbps High Speed USB v2.0 > > ad4: 152627MB at ata2-master SATA150 > > ugen0.1: at usbus0 > > uhub0: on usbus0 > > ugen1.1: at usbus1 > > uhub1: on usbus1 > > ugen2.1: at usbus2 > > uhub2: on usbus2 > > ugen3.1: at usbus3 > > uhub3: on usbus3 > > ugen4.1: at usbus4 > > uhub4: on usbus4 > > ugen5.1: at usbus5 > > uhub5: on usbus5 > > uhub0: 3 ports with 3 removable, self powered > > uhub1: 3 ports with 3 removable, self powered > > uhub3: 3 ports with 3 removable, self powered > > uhub4: 3 ports with 3 removable, self powered > > acd0: DVDR at ata4-master SATA150 > > uhub2: 6 ports with 6 removable, self powered > > uhub5: 6 ports with 6 removable, self powered > > ugen5.2: at usbus5 > > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 > 0x00 0x01 > > (probe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > > (probe0:ata1:0:0:0): CAM Status: SCSI Status Error > > (probe0:ata1:0:0:0): SCSI Status: Check Condition > > (probe0:ata1:0:0:0): NOT READY asc:3a,1 > > (probe0:ata1:0:0:0): Medium not present - tray closed > > (probe0:ata1:0:0:0): Unretryable error > > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x48 > 0x00 0x01 > > SMP: AP CPU #1 Launched! > > cd0 at ata1 bus 0 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 device > > cd0: 3.300MB/s transfers > > cd0: Attempt to query device size failed: NOT READY, Medium not > > present - tray closed > > ugen5.3: at usbus5 > > umass0: on usbus5 > > umass0: SCSI over Bulk-Only; quirks = 0x0000 > > Root mount waiting for: usbus5 > > umass0:2:0:-1: Attached to scbus2 > > Trying to mount root from ufs:/dev/label/rootfs0 > > (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error > > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition > > (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 > > (probe0:umass-sim0:0:0:0): Medium not present > > (probe0:umass-sim0:0:0:0): Unretryable error > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-0 device > > da0: 40.000MB/s transfers > > da0: Attempt to query device size failed: NOT READY, Medium not present > > wlan0: Ethernet address: 00:21:63:10:a4:d9 > > ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based > > forwarding disabled, default to deny, logging disabled > Error 6 corresponds to -- > #define ENXIO 6 /* Device not configured */ > -- is there a step that wasn't performed before powerd was called? Not sure about this. It's a standard PCBSD install, I can send the rc.conf, loader.conf or whatever else is needed. > Thanks, > -Garrett --0016e648d93c37dc8e047e8b47b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Feb 1, 2010 12:35am, Garrett Cooper <yanefbsd@gmail.com> wrote:> On Sun, Jan 31, 2010 at 9:22 PM, Michael msherman77@gmail.com> w= rote:
>
> >
>
> >>Number: =A0 = =A0 =A0 =A0 143420
>
> >>Category: =A0 =A0 =A0 misc<= br />>
> >>Synopsis: =A0 =A0 =A0 ACPI issues with Toshiba=
>
> >>Confidential: =A0 no
>
> >= ;>Severity: =A0 =A0 =A0 serious
>
> >>Priority: = =A0 =A0 =A0 medium
>
> >>Responsible: =A0 =A0freebsd= -bugs
>
> >>State: =A0 =A0 =A0 =A0 =A0open
>=
> >>Quarter:
>
> >>Keywords:
&g= t;
> >>Date-Required:
>
> >>Class: = =A0 =A0 =A0 =A0 =A0sw-bug
>
> >>Submitter-Id: =A0 cu= rrent-users
>
> >>Arrival-Date: =A0 Mon Feb 01 05:30= :07 UTC 2010
>
> >>Closed-Date:
>
>= >>Last-Modified:
>
> >>Originator: =A0 =A0 Mi= chael
>
> >>Release: =A0 =A0 =A0 =A08.0 (PCBSD 8.0 B= eta)
>
> >>Organization:
>
> >&g= t;Environment:
>
> > FreeBSD pcbsd-2645 8.0-RELEASE-p1 = FreeBSD 8.0-RELEASE-p1 #3: Fri Dec 11 13:33:42 PST 2009 =A0 =A0 root@build8= x32.pcbsd.org:/usr/obj/usr/pcbsd-build80/fbsd-source/8.0-src/sys/PCBSD =A0i= 386
>
> >>Description:
>
> > I j= ust installed PCBSD 8.0 Beta (which is FreeBSD 8.0 release-p1) on
>=
> > my Toshiba Satellite.
>
> > Specs: CPU= : 1.9 Ghz Athlon X 2. Video: ATI chipset (radeonhd driver)
>
= > > Audio: Intel (sound_hda) Wireless: (Atheros driver)
> > > ACPI doesn't fully work. No suspend / resume, but I can li= ve without it.
>
> >
>
> > What doe= s bother me is that the laptop runs very hot 60+ C. Other
>
&= gt; > systems run at ~45 - 50C
>
> > Enabling powerd= makes system very slow (almost unusable) and produces
>
>= > the message: set freq failed, error 6
>
> >
= >
> > dmesg.boot
>
> >
>
&= gt; > Copyright (c) 1992-2009 The FreeBSD Project.
>
> = > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19= 94
>
> > =A0 =A0 =A0 =A0The Regents of the University o= f California. All rights reserved.
>
> > FreeBSD is a r= egistered trademark of The FreeBSD Foundation.
>
> > Fr= eeBSD 8.0-RELEASE-p1 #3: Fri Dec 11 13:33:42 PST 2009
>
> = > =A0 =A0root at build8x32.pcbsd.org:/usr/obj/usr/pcbsd-build80/fbsd-sou= rce/8.0-src/sys/PCBSD
>
> > Timecounter "i8254&quo= t; frequency 1193182 Hz quality 0
>
> > CPU: AMD Athlon= (tm) X2 Dual-Core QL-60 (1895.28-MHz 686-class CPU)
>
> &g= t; =A0Origin =3D "AuthenticAMD" =A0Id =3D 0x200f31 =A0Stepping = =3D 1
>
> > =A0Features=3D0x178bfbff
>
&g= t; > =A0Features2=3D0x2001
>
> > =A0AMD Features=3D0= xea500800
>
> > =A0AMD Features2=3D0x131f
> > > =A0TSC: P-state invariant
>
> > real memor= y =A0=3D 2147483648 (2048 MB)
>
> > avail memory =3D 18= 21257728 (1736 MB)
>
> > ACPI APIC Table:
> > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>=
> > FreeBSD/SMP: 1 package(s) x 2 core(s)
>
>= > =A0cpu0 (BSP): APIC ID: =A00
>
> > =A0cpu1 (AP): = APIC ID: =A01
>
> > ioapic0: Changing APIC ID to 4
>
> > ioapic0 irqs 0-23 on motherboard
>
>= ; > kbd1 at kbdmux0
>
> > module_register_init: MOD_= LOAD (splash_pcx, 0xc0fbe830, 0) error 2
>
> > cryptoso= ft0: on motherboard
>
> > acpi0: on motherboard
= >
> > acpi0: [ITHREAD]
>
> > acpi0: Powe= r Button (fixed)
>
> > Timecounter "ACPI-safe"= ; frequency 3579545 Hz quality 850
>
> > acpi_timer0: = port 0x408-0x40b on acpi0
>
> > acpi_ec0: port 0x62,0x= 66 on acpi0
>
> > acpi_hpet0: iomem 0xfed00000-0xfed00= 3ff on acpi0
>
> > Timecounter "HPET" frequen= cy 14318180 Hz quality 900
>
> > acpi_button0: on acpi= 0
>
> > acpi_lid0: on acpi0
>
> > = battery0: on acpi0
>
> > acpi_acad0: on acpi0
&g= t;
> > pcib0: port 0xcf8-0xcff on acpi0
>
> &= gt; pci0: on pcib0
>
> > pcib1: at device 1.0 on pci0=
>
> > pci1: on pcib1
>
> > vgapci= 0: port 0x6000-0x60ff mem
>
> > 0x80000000-0x8fffffff,= 0x96300000-0x9630ffff,0x96200000-0x962fffff irq
>
> > 1= 8 at device 5.0 on pci1
>
> > pcib2: at device 4.0 on = pci0
>
> > pci2: on pcib2
>
> > pc= ib3: at device 5.0 on pci0
>
> > pci4: on pcib3
= >
> > re0: port 0x3000-0x30ff
>
> > mem= 0x91010000-0x91010fff,0x91000000-0x9100ffff irq 17 at device 0.0
>=
> > on pci4
>
> > re0: Using 1 MSI message= s
>
> > re0: Chip rev. 0x34800000
>
> = > re0: MAC rev. 0x00000000
>
> > miibus0: on re0>
> > rlphy0: PHY 1 on miibus0
>
> >= rlphy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> =
> > re0: Ethernet address: 00:1e:33:46:bb:a0
>
&g= t; > re0: [FILTER]
>
> > pcib4: at device 6.0 on pc= i0
>
> > pci5: on pcib4
>
> > ath0= : mem 0x93100000-0x9310ffff irq 18 at device 0.0 on pci5
>
&= gt; > ath0: [ITHREAD]
>
> > ath0: AR2425 mac 14.2 RF= 5424 phy 7.0
>
> > pcib5: at device 7.0 on pci0
&= gt;
> > pci6: on pcib5
>
> > atapci0: por= t
>
> > 0x7038-0x703f,0x704c-0x704f,0x7030-0x7037,0x704= 8-0x704b,0x7010-0x701f
>
> > mem 0x96408000-0x964083ff = irq 22 at device 17.0 on pci0
>
> > atapci0: [ITHREAD]<= br />>
> > atapci0: AHCI v1.10 controller with 6 3Gbps ports= , PM supported
>
> > ata2: on atapci0
>
= > > ata2: port is not ready (timeout 0ms) tfd =3D 000001d0
> =
> > ata2: software reset clear timeout
>
> >= ; ata2: [ITHREAD]
>
> > ata3: on atapci0
> > > ata3: [ITHREAD]
>
> > ata4: on atapci0>
> > ata4: port is not ready (timeout 0ms) tfd =3D 00000= 180
>
> > ata4: software reset clear timeout
> =
> > ata4: [ITHREAD]
>
> > ata5: on atapci0=
>
> > ata5: [ITHREAD]
>
> > ata6: = on atapci0
>
> > ata6: [ITHREAD]
>
> = > ata7: on atapci0
>
> > ata7: [ITHREAD]
> =
> > ohci0: mem 0x96407000-0x96407fff irq
>
> = > 16 at device 18.0 on pci0
>
> > ohci0: [ITHREAD]>
> > usbus0: on ohci0
>
> > ohci1:= mem 0x96406000-0x96406fff irq
>
> > 16 at device 18.1= on pci0
>
> > ohci1: [ITHREAD]
>
> &g= t; usbus1: on ohci1
>
> > ehci0: mem 0x96408500-0x964= 085ff
>
> > irq 17 at device 18.2 on pci0
> > > ehci0: [ITHREAD]
>
> > usbus2: waiting for= BIOS to give up control
>
> > usbus2: EHCI version 1.0=
>
> > usbus2: on ehci0
>
> > ohci= 2: mem 0x96405000-0x96405fff irq
>
> > 18 at device 19= .0 on pci0
>
> > ohci2: [ITHREAD]
>
> = > usbus3: on ohci2
>
> > ohci3: mem 0x96404000-0x9= 6404fff irq
>
> > 18 at device 19.1 on pci0
> <= br />> > ohci3: [ITHREAD]
>
> > usbus4: on ohci3=
>
> > ehci1: mem 0x96408400-0x964084ff
>
> > irq 19 at device 19.2 on pci0
>
> > ehci1: = [ITHREAD]
>
> > usbus5: waiting for BIOS to give up con= trol
>
> > usbus5: EHCI version 1.0
>
>= ; > usbus5: on ehci1
>
> > pci0: at device 20.0 (n= o driver attached)
>
> > atapci1: port
>
> > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x7000-0x700f irq 16 at devi= ce
>
> > 20.1 on pci0
>
> > ata0: = on atapci1
>
> > ata0: [ITHREAD]
>
> &= gt; ata1: on atapci1
>
> > ata1: [ITHREAD]
> <= br />> > pci0: at device 20.2 (no driver attached)
>
&= gt; > isab0: at device 20.3 on pci0
>
> > isa0: on= isab0
>
> > pcib6: at device 20.4 on pci0
> <= br />> > pci128: on pcib6
>
> > acpi_tz0: on ac= pi0
>
> > atrtc0: port 0x70-0x71 on acpi0
> > > atkbdc0: port 0x60,0x64 irq 1 on acpi0
>
> = > atkbd0: irq 1 on atkbdc0
>
> > kbd0 at atkbd0
>
> > atkbd0: [GIANT-LOCKED]
>
> > atk= bd0: [ITHREAD]
>
> > psm0: flags 0x1000 irq 12 on atkb= dc0
>
> > psm0: [GIANT-LOCKED]
>
> >= ; psm0: [ITHREAD]
>
> > psm0: model Generic PS/2 mouse,= device ID 0
>
> > cpu0: on acpi0
>
>= > acpi_throttle0: on cpu0
>
> > hwpstate0: on cpu= 0
>
> > cpu1: on acpi0
>
> > pmtim= er0 on isa0
>
> > orm0: at iomem 0xcf000-0xcffff pnpid= ORM0000 on isa0
>
> > sc0: at flags 0x100 on isa0
>
> > sc0: VGA
>
> > vga0: at port 0= x3c0-0x3df iomem 0xa0000-0xbffff on isa0
>
> > ppc0: pa= rallel port not found.
>
> > ZFS NOTICE: Prefetch is di= sabled by default on i386 -- to enable,
>
> > =A0 =A0 = =A0 =A0 =A0 =A0add "vfs.zfs.prefetch_disable=3D0" to /boot/loader= .conf.
>
> > ZFS WARNING: Recommended minimum kmem_size= is 512MB; expect unstable behavior.
>
> > =A0 =A0 =A0 = =A0 =A0 =A0 Consider tuning vm.kmem_size and vm.kmem_size_max
> > > =A0 =A0 =A0 =A0 =A0 =A0 in /boot/loader.conf.
>
= > > ZFS filesystem version 13
>
> > ZFS storage p= ool version 13
>
> > Timecounters tick every 1.000 msec=
>
> > usbus0: 12Mbps Full Speed USB v1.0
> > > usbus1: 12Mbps Full Speed USB v1.0
>
> > u= sbus2: 480Mbps High Speed USB v2.0
>
> > usbus3: 12Mbps= Full Speed USB v1.0
>
> > usbus4: 12Mbps Full Speed US= B v1.0
>
> > usbus5: 480Mbps High Speed USB v2.0
&= gt;
> > ad4: 152627MB at ata2-master SATA150
>
&= gt; > ugen0.1: at usbus0
>
> > uhub0: on usbus0>
> > ugen1.1: at usbus1
>
> > uhub1= : on usbus1
>
> > ugen2.1: at usbus2
>
= > > uhub2: on usbus2
>
> > ugen3.1: at usbus3>
> > uhub3: on usbus3
>
> > ugen4.= 1: at usbus4
>
> > uhub4: on usbus4
>
&= gt; > ugen5.1: at usbus5
>
> > uhub5: on usbus5>
> > uhub0: 3 ports with 3 removable, self powered
= >
> > uhub1: 3 ports with 3 removable, self powered
>= ;
> > uhub3: 3 ports with 3 removable, self powered
> <= br />> > uhub4: 3 ports with 3 removable, self powered
>
> > acd0: DVDR at ata4-master SATA150
>
> > uh= ub2: 6 ports with 6 removable, self powered
>
> > uhub5= : 6 ports with 6 removable, self powered
>
> > ugen5.2:= at usbus5
>
> > acd0: FAILURE - INQUIRY ILLEGAL REQUE= ST asc=3D0x24 ascq=3D0x00 sks=3D0x48 0x00 0x01
>
> > (p= robe0:ata1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
>
> &= gt; (probe0:ata1:0:0:0): CAM Status: SCSI Status Error
>
>= > (probe0:ata1:0:0:0): SCSI Status: Check Condition
>
>= ; > (probe0:ata1:0:0:0): NOT READY asc:3a,1
>
> > (p= robe0:ata1:0:0:0): Medium not present - tray closed
>
> &g= t; (probe0:ata1:0:0:0): Unretryable error
>
> > acd0: F= AILURE - INQUIRY ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 sks=3D0x48 0x00 0x0= 1
>
> > SMP: AP CPU #1 Launched!
>
> &= gt; cd0 at ata1 bus 0 target 0 lun 0
>
> > cd0: Remova= ble CD-ROM SCSI-0 device
>
> > cd0: 3.300MB/s transfers=
>
> > cd0: Attempt to query device size failed: NOT RE= ADY, Medium not
>
> > present - tray closed
> <= br />> > ugen5.3: at usbus5
>
> > umass0: on us= bus5
>
> > umass0: =A0SCSI over Bulk-Only; quirks =3D 0= x0000
>
> > Root mount waiting for: usbus5
> > > umass0:2:0:-1: Attached to scbus2
>
> > T= rying to mount root from ufs:/dev/label/rootfs0
>
> > (= probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
>
> > (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
&g= t;
> > (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition<= br />>
> > (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0
>
> > (probe0:umass-sim0:0:0:0): Medium not present
&= gt;
> > (probe0:umass-sim0:0:0:0): Unretryable error
> =
> > da0 at umass-sim0 bus 0 target 0 lun 0
>
>= > da0: Removable Direct Access SCSI-0 device
>
> >= da0: 40.000MB/s transfers
>
> > da0: Attempt to query = device size failed: NOT READY, Medium not present
>
> >= wlan0: Ethernet address: 00:21:63:10:a4:d9
>
> > ipfw2= (+ipv6) initialized, divert loadable, nat loadable, rule-based
> <= br />> > forwarding disabled, default to deny, logging disabled
= >
>
>
> Error 6 corresponds to --
> <= br />>
>
> #define ENXIO =A0 =A0 =A0 =A0 =A0 6 =A0 =A0= =A0 =A0 =A0 =A0 =A0 /* Device not configured */
>
>
>
> -- is there a step that wasn't performed before powerd= was called?

Not sure about this. It's a standard PCBSD inst= all, I can send the rc.conf, loader.conf or whatever else is needed.
<= br />>
> Thanks,
>
> -Garrett
> --0016e648d93c37dc8e047e8b47b3-- From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 19:21:35 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id ADFF11065672; Mon, 1 Feb 2010 19:21:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Rui Paulo Date: Mon, 1 Feb 2010 14:21:20 -0500 User-Agent: KMail/1.6.2 References: <875CBAC3-245A-4199-94DC-BBB047318681@freebsd.org> In-Reply-To: <875CBAC3-245A-4199-94DC-BBB047318681@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002011421.22465.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPICA 20100121 regression X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 19:21:35 -0000 On Saturday 30 January 2010 10:49 am, Rui Paulo wrote: > Hi, > Latest ACPICA can't find my ASUS010 HID. It worked fine with > FreeBSD 8, which has ACPICA 20090521. > > The ASL is located at: > http://people.freebsd.org/~rpaulo/asus-1005ha.asl.gz > > What I'm seeing is ACPI_ID_PROBE() returning always NULL for > "ASUS010" and "ATK0100" devids. It seems the ASL disables ASUS010 when the OS is "Windows 2009" (aka Windows 7). FYI, current ACPI-CA just returns okay for any Microsoft OSes when _OSI method is used in ASL. Thus, it thinks you are running Windows 7. You can comment out or remove line 3626-3629 and override DSDT to re-enable the device, I think. Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 19:25:16 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F30AD106566B; Mon, 1 Feb 2010 19:25:16 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 593168FC08; Mon, 1 Feb 2010 19:25:15 +0000 (UTC) Received: by ewy3 with SMTP id 3so7533ewy.13 for ; Mon, 01 Feb 2010 11:25:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=UbWNKXPXoQa+e5WFe0ErB7KBDv0YgfCNfHlc1/vTbbY=; b=jJmiZoDinxPSVKvWZcRNscFX/pypfwTQx203wgqfL1ZQYADZIyZfvfU8qS7xFeKsdM q2PWme5RkmIQegiwr2qwYr5YuAiQgDnJc0f2pktGfeaI58Xbd2wI9YkGkN70HqPY+pC/ 2qbOih6a8W7id8lJEvuxwwmuTf+ocNtuFrN/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Mqbk9sNHrCXgTV23ffGCcaV+gkI16kVwroRn+54yVvfCfa0iEL20uXpLeyPmLHuBnJ DZy1oVGTy8oFjeZCGbEmKkpe7cDNfkmHe3vvmMA7q001Qcm8DtqFcR3PHovLuMveQtOa bEmdgGj18+OrHEgiJ7A34iVQVCI4mg9bTEF5A= Received: by 10.213.104.74 with SMTP id n10mr4917555ebo.64.1265052314633; Mon, 01 Feb 2010 11:25:14 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 5sm7954198eyf.2.2010.02.01.11.25.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 11:25:13 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <201002011421.22465.jkim@FreeBSD.org> Date: Mon, 1 Feb 2010 19:25:11 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <875CBAC3-245A-4199-94DC-BBB047318681@freebsd.org> <201002011421.22465.jkim@FreeBSD.org> To: Jung-uk Kim X-Mailer: Apple Mail (2.1077) Cc: freebsd-acpi@freebsd.org Subject: Re: ACPICA 20100121 regression X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 19:25:17 -0000 On 1 Feb 2010, at 19:21, Jung-uk Kim wrote: > On Saturday 30 January 2010 10:49 am, Rui Paulo wrote: >> Hi, >> Latest ACPICA can't find my ASUS010 HID. It worked fine with >> FreeBSD 8, which has ACPICA 20090521. >> >> The ASL is located at: >> http://people.freebsd.org/~rpaulo/asus-1005ha.asl.gz >> >> What I'm seeing is ACPI_ID_PROBE() returning always NULL for >> "ASUS010" and "ATK0100" devids. > > It seems the ASL disables ASUS010 when the OS is "Windows 2009" (aka > Windows 7). FYI, current ACPI-CA just returns okay for any Microsoft > OSes when _OSI method is used in ASL. Thus, it thinks you are > running Windows 7. You can comment out or remove line 3626-3629 and > override DSDT to re-enable the device, I think. You're right, but I'm left wondering why it worked with a previous ACPICA. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 19:33:52 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 869C6106568F; Mon, 1 Feb 2010 19:33:52 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Rui Paulo Date: Mon, 1 Feb 2010 14:33:37 -0500 User-Agent: KMail/1.6.2 References: <875CBAC3-245A-4199-94DC-BBB047318681@freebsd.org> <201002011421.22465.jkim@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002011433.39506.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPICA 20100121 regression X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 19:33:52 -0000 On Monday 01 February 2010 02:25 pm, Rui Paulo wrote: > On 1 Feb 2010, at 19:21, Jung-uk Kim wrote: > > On Saturday 30 January 2010 10:49 am, Rui Paulo wrote: > >> Hi, > >> Latest ACPICA can't find my ASUS010 HID. It worked fine with > >> FreeBSD 8, which has ACPICA 20090521. > >> > >> The ASL is located at: > >> http://people.freebsd.org/~rpaulo/asus-1005ha.asl.gz > >> > >> What I'm seeing is ACPI_ID_PROBE() returning always NULL for > >> "ASUS010" and "ATK0100" devids. > > > > It seems the ASL disables ASUS010 when the OS is "Windows 2009" > > (aka Windows 7). FYI, current ACPI-CA just returns okay for any > > Microsoft OSes when _OSI method is used in ASL. Thus, it thinks > > you are running Windows 7. You can comment out or remove line > > 3626-3629 and override DSDT to re-enable the device, I think. > > You're right, but I'm left wondering why it worked with a previous > ACPICA. Because "Windows 2009" was added in 20090903. :-) Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 19:36:58 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A947C106566C; Mon, 1 Feb 2010 19:36:58 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 12BA68FC1A; Mon, 1 Feb 2010 19:36:57 +0000 (UTC) Received: by ewy3 with SMTP id 3so20073ewy.13 for ; Mon, 01 Feb 2010 11:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=ygtLICQe3jMH2b6CWvz3O3PutXZwcmC7w2797r12wMA=; b=pLzorHyyTQTc1L4gjVVeemdXXehe5+isQIwT5KQiryvgApttL0rAvTNL85xTKUDnNW Zr8LUnSMcHtuRDimuRGezquIz7aJGwqKw++qsLJ3eyx4P/aX0P2NM5T6xJiyTIJHggbU KT1n6xfMD2K+2DuimR57td0hU1ETqBpFJaU2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=hXdKMPSERaQWhVzrgjBZFXsoYX5MqB/2gq32/3fciCmI75twv1TEtC5q0KA4U2AnWM RWHhzMakUpgDm3LL9yaQjpAo8gexeoN06Dw7VFaAoFLu6CkO570sHTYHCSXjVepvIasD vGb9JoDukhElpKKKNosOXfstsJyQBTG5RTms8= Received: by 10.213.43.81 with SMTP id v17mr5009681ebe.0.1265053016713; Mon, 01 Feb 2010 11:36:56 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 7sm10776543eyg.9.2010.02.01.11.36.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 11:36:54 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <201002011433.39506.jkim@FreeBSD.org> Date: Mon, 1 Feb 2010 19:36:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <976B4942-6DD5-438D-B8C3-1A1E7B1EDEC0@freebsd.org> References: <875CBAC3-245A-4199-94DC-BBB047318681@freebsd.org> <201002011421.22465.jkim@FreeBSD.org> <201002011433.39506.jkim@FreeBSD.org> To: Jung-uk Kim X-Mailer: Apple Mail (2.1077) Cc: freebsd-acpi@freebsd.org Subject: Re: ACPICA 20100121 regression X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 19:36:58 -0000 On 1 Feb 2010, at 19:33, Jung-uk Kim wrote: > On Monday 01 February 2010 02:25 pm, Rui Paulo wrote: >> On 1 Feb 2010, at 19:21, Jung-uk Kim wrote: >>> On Saturday 30 January 2010 10:49 am, Rui Paulo wrote: >>>> Hi, >>>> Latest ACPICA can't find my ASUS010 HID. It worked fine with >>>> FreeBSD 8, which has ACPICA 20090521. >>>>=20 >>>> The ASL is located at: >>>> http://people.freebsd.org/~rpaulo/asus-1005ha.asl.gz >>>>=20 >>>> What I'm seeing is ACPI_ID_PROBE() returning always NULL for >>>> "ASUS010" and "ATK0100" devids. >>>=20 >>> It seems the ASL disables ASUS010 when the OS is "Windows 2009" >>> (aka Windows 7). FYI, current ACPI-CA just returns okay for any >>> Microsoft OSes when _OSI method is used in ASL. Thus, it thinks >>> you are running Windows 7. You can comment out or remove line >>> 3626-3629 and override DSDT to re-enable the device, I think. >>=20 >> You're right, but I'm left wondering why it worked with a previous >> ACPICA. >=20 > Because "Windows 2009" was added in 20090903. :-) I understand now. Still, I think this is ACPICA's fault, but I = understand that other laptops may rely on this behavior from ACPICA, so = the fix may cause even more problems.. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 19:51:21 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 0AE231065672; Mon, 1 Feb 2010 19:51:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Rui Paulo Date: Mon, 1 Feb 2010 14:51:06 -0500 User-Agent: KMail/1.6.2 References: <875CBAC3-245A-4199-94DC-BBB047318681@freebsd.org> <201002011433.39506.jkim@FreeBSD.org> <976B4942-6DD5-438D-B8C3-1A1E7B1EDEC0@freebsd.org> In-Reply-To: <976B4942-6DD5-438D-B8C3-1A1E7B1EDEC0@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002011451.09084.jkim@FreeBSD.org> Cc: freebsd-acpi@freebsd.org Subject: Re: ACPICA 20100121 regression X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 19:51:21 -0000 On Monday 01 February 2010 02:36 pm, Rui Paulo wrote: > On 1 Feb 2010, at 19:33, Jung-uk Kim wrote: > > On Monday 01 February 2010 02:25 pm, Rui Paulo wrote: > >> On 1 Feb 2010, at 19:21, Jung-uk Kim wrote: > >>> On Saturday 30 January 2010 10:49 am, Rui Paulo wrote: > >>>> Hi, > >>>> Latest ACPICA can't find my ASUS010 HID. It worked fine with > >>>> FreeBSD 8, which has ACPICA 20090521. > >>>> > >>>> The ASL is located at: > >>>> http://people.freebsd.org/~rpaulo/asus-1005ha.asl.gz > >>>> > >>>> What I'm seeing is ACPI_ID_PROBE() returning always NULL for > >>>> "ASUS010" and "ATK0100" devids. > >>> > >>> It seems the ASL disables ASUS010 when the OS is "Windows 2009" > >>> (aka Windows 7). FYI, current ACPI-CA just returns okay for > >>> any Microsoft OSes when _OSI method is used in ASL. Thus, it > >>> thinks you are running Windows 7. You can comment out or > >>> remove line 3626-3629 and override DSDT to re-enable the > >>> device, I think. > >> > >> You're right, but I'm left wondering why it worked with a > >> previous ACPICA. > > > > Because "Windows 2009" was added in 20090903. :-) > > I understand now. Still, I think this is ACPICA's fault, but I > understand that other laptops may rely on this behavior from > ACPICA, so the fix may cause even more problems.. I agree that it is ACPI-CA's fault but it was debated in Linux community for a while and they decided it is the best course of action for ACPI-CA, AFAIK. Basically, a lot of ACPI implementations out there just disable some "features" based on Windows versions. Even worse, many features are disabled when it matches "Linux". So, they decided returning the latest and greatest Windows version instead is the best choice. Luckily (or unluckily), not so many ACPI implementations match "FreeBSD". :-( Jung-uk Kim From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 20:24:14 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62D671065670; Mon, 1 Feb 2010 20:24:14 +0000 (UTC) (envelope-from robert.moore@intel.com) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by mx1.freebsd.org (Postfix) with ESMTP id 264028FC1F; Mon, 1 Feb 2010 20:24:13 +0000 (UTC) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 01 Feb 2010 12:23:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.49,385,1262592000"; d="scan'208";a="592223288" Received: from orsmsx602.amr.corp.intel.com ([10.22.226.211]) by orsmga001.jf.intel.com with ESMTP; 01 Feb 2010 12:24:04 -0800 Received: from orsmsx503.amr.corp.intel.com ([10.22.226.47]) by orsmsx602.amr.corp.intel.com ([10.22.226.211]) with mapi; Mon, 1 Feb 2010 12:24:11 -0800 From: "Moore, Robert" To: Jung-uk Kim , Rui Paulo Date: Mon, 1 Feb 2010 12:24:10 -0800 Thread-Topic: ACPICA 20100121 regression Thread-Index: Acqjd/TR30b+d1bWQTCCZtIGFcoA8gAA5isw Message-ID: <4911F71203A09E4D9981D27F9D83085855AF8381@orsmsx503.amr.corp.intel.com> References: <875CBAC3-245A-4199-94DC-BBB047318681@freebsd.org> <201002011433.39506.jkim@FreeBSD.org> <976B4942-6DD5-438D-B8C3-1A1E7B1EDEC0@freebsd.org> <201002011451.09084.jkim@FreeBSD.org> In-Reply-To: <201002011451.09084.jkim@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Brown, Len" , "freebsd-acpi@freebsd.org" , "Lin, Ming M" Subject: RE: ACPICA 20100121 regression X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 20:24:14 -0000 The worst part of all is that if ACPICA returns TRUE for "Linux", the ASL c= ode executes down paths that often have never been tested. The goal of ACPICA is to be 100% compatible with the Windows ACPI implement= ation. As such, it returns TRUE for all Windows query strings. Note, _OSI was never intended to be a test for "which operating system is e= xecuting". It is meant to query the "set of ACPI-related interfaces, behavi= ors, or features that the operating system supports" (from ACPI specificati= on.) Thus, it is entirely appropriate for ACPICA to return TRUE for windows= strings. I guess the next question would be: why is the machine disabling things spe= cifically for Windows 7? Bob >-----Original Message----- >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- >acpi@freebsd.org] On Behalf Of Jung-uk Kim >Sent: Monday, February 01, 2010 11:51 AM >To: Rui Paulo >Cc: freebsd-acpi@freebsd.org >Subject: Re: ACPICA 20100121 regression > >On Monday 01 February 2010 02:36 pm, Rui Paulo wrote: >> On 1 Feb 2010, at 19:33, Jung-uk Kim wrote: >> > On Monday 01 February 2010 02:25 pm, Rui Paulo wrote: >> >> On 1 Feb 2010, at 19:21, Jung-uk Kim wrote: >> >>> On Saturday 30 January 2010 10:49 am, Rui Paulo wrote: >> >>>> Hi, >> >>>> Latest ACPICA can't find my ASUS010 HID. It worked fine with >> >>>> FreeBSD 8, which has ACPICA 20090521. >> >>>> >> >>>> The ASL is located at: >> >>>> http://people.freebsd.org/~rpaulo/asus-1005ha.asl.gz >> >>>> >> >>>> What I'm seeing is ACPI_ID_PROBE() returning always NULL for >> >>>> "ASUS010" and "ATK0100" devids. >> >>> >> >>> It seems the ASL disables ASUS010 when the OS is "Windows 2009" >> >>> (aka Windows 7). FYI, current ACPI-CA just returns okay for >> >>> any Microsoft OSes when _OSI method is used in ASL. Thus, it >> >>> thinks you are running Windows 7. You can comment out or >> >>> remove line 3626-3629 and override DSDT to re-enable the >> >>> device, I think. >> >> >> >> You're right, but I'm left wondering why it worked with a >> >> previous ACPICA. >> > >> > Because "Windows 2009" was added in 20090903. :-) >> >> I understand now. Still, I think this is ACPICA's fault, but I >> understand that other laptops may rely on this behavior from >> ACPICA, so the fix may cause even more problems.. > >I agree that it is ACPI-CA's fault but it was debated in Linux >community for a while and they decided it is the best course of >action for ACPI-CA, AFAIK. Basically, a lot of ACPI implementations >out there just disable some "features" based on Windows versions. >Even worse, many features are disabled when it matches "Linux". So, >they decided returning the latest and greatest Windows version >instead is the best choice. Luckily (or unluckily), not so many ACPI >implementations match "FreeBSD". :-( > >Jung-uk Kim >_______________________________________________ >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 owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 20:27:37 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8748106566B; Mon, 1 Feb 2010 20:27:37 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 2766E8FC17; Mon, 1 Feb 2010 20:27:36 +0000 (UTC) Received: by fxm27 with SMTP id 27so643615fxm.3 for ; Mon, 01 Feb 2010 12:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=aL/qaE3B9xZ7Qnb3/G8Bf+DU03rSc0nlwg9mImLa4UI=; b=RYQ8GeVU3ED5IsTMBIl03uadReA97bM7v+b/P9Hna722L6IhEhvYmo2WdxwrddSLez pzaBP96crtArbORYHICw0RKF+rCQwns9vhcxBRsc7KTPTN3tHukDm2/RWoC7MgnwyDMX 8P7SARhl/dfaEhZ+WHaUTihrP+HUsVG76KMVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=OwiUO88y2Bz4nt+xMRZjXzufzHsJRYBGHHwLlCpy3xkmOuGdkbuSOrXZOEAb/ymbv9 sIcmSqSq0RdBYmyZGYh/MH/uZc2JKSH5uJxEOu3jXsDlhHZYRagewaedTmyrSuD+WIR0 3bO5fe6ekuPCYAk1DYKcc86dhtCowOMb28r3g= Received: by 10.223.6.89 with SMTP id 25mr5008349fay.89.1265056055947; Mon, 01 Feb 2010 12:27:35 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 14sm2126001fxm.3.2010.02.01.12.27.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Feb 2010 12:27:34 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4911F71203A09E4D9981D27F9D83085855AF8381@orsmsx503.amr.corp.intel.com> Date: Mon, 1 Feb 2010 20:27:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <875E4247-D942-4C2E-8287-1B3A9C93D79F@freebsd.org> References: <875CBAC3-245A-4199-94DC-BBB047318681@freebsd.org> <201002011433.39506.jkim@FreeBSD.org> <976B4942-6DD5-438D-B8C3-1A1E7B1EDEC0@freebsd.org> <201002011451.09084.jkim@FreeBSD.org> <4911F71203A09E4D9981D27F9D83085855AF8381@orsmsx503.amr.corp.intel.com> To: "Moore, Robert" X-Mailer: Apple Mail (2.1077) Cc: "Brown, Len" , "freebsd-acpi@freebsd.org" , "Lin, Ming M" , Jung-uk Kim Subject: Re: ACPICA 20100121 regression X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 20:27:37 -0000 On 1 Feb 2010, at 20:24, Moore, Robert wrote: > The worst part of all is that if ACPICA returns TRUE for "Linux", the = ASL code executes down paths that often have never been tested. >=20 > The goal of ACPICA is to be 100% compatible with the Windows ACPI = implementation. As such, it returns TRUE for all Windows query strings. >=20 > Note, _OSI was never intended to be a test for "which operating system = is executing". It is meant to query the "set of ACPI-related interfaces, = behaviors, or features that the operating system supports" (from ACPI = specification.) Thus, it is entirely appropriate for ACPICA to return = TRUE for windows strings. >=20 > I guess the next question would be: why is the machine disabling = things specifically for Windows 7? The machine came with Windows 7. My guess is that they have another = piece of software that does the same as the ASUS010 interface (LCD = brightness control / disabling enabling devices / etc.) but for Windows = 7. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 1 20:45:39 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 48AFD106566B; Mon, 1 Feb 2010 20:45:37 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "Moore, Robert" Date: Mon, 1 Feb 2010 15:45:15 -0500 User-Agent: KMail/1.6.2 References: <875CBAC3-245A-4199-94DC-BBB047318681@freebsd.org> <201002011451.09084.jkim@FreeBSD.org> <4911F71203A09E4D9981D27F9D83085855AF8381@orsmsx503.amr.corp.intel.com> In-Reply-To: <4911F71203A09E4D9981D27F9D83085855AF8381@orsmsx503.amr.corp.intel.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002011545.25010.jkim@FreeBSD.org> Cc: "Brown, Len" , "freebsd-acpi@freebsd.org" , Rui Paulo , "Lin, Ming M" Subject: Re: ACPICA 20100121 regression X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 20:45:39 -0000 On Monday 01 February 2010 03:24 pm, Moore, Robert wrote: > The worst part of all is that if ACPICA returns TRUE for "Linux", > the ASL code executes down paths that often have never been tested. Luckiily there are only handful of BIOSes out there match "FreeBSD" AFAIK. :-) > The goal of ACPICA is to be 100% compatible with the Windows ACPI > implementation. As such, it returns TRUE for all Windows query > strings. Yes, of course. > Note, _OSI was never intended to be a test for "which operating > system is executing". It is meant to query the "set of ACPI-related > interfaces, behaviors, or features that the operating system > supports" (from ACPI specification.) Thus, it is entirely > appropriate for ACPICA to return TRUE for windows strings. Like it or not, Microsoft is advertising it as "how to identify Windows version" method to BIOS writers, unfortunately: http://www.microsoft.com/whdc/system/pnppwr/powermgmt/WinACPI_OSI.mspx Jung-uk Kim > I guess the next question would be: why is the machine disabling > things specifically for Windows 7? > > Bob > > >-----Original Message----- > >From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd- > >acpi@freebsd.org] On Behalf Of Jung-uk Kim > >Sent: Monday, February 01, 2010 11:51 AM > >To: Rui Paulo > >Cc: freebsd-acpi@freebsd.org > >Subject: Re: ACPICA 20100121 regression > > > >On Monday 01 February 2010 02:36 pm, Rui Paulo wrote: > >> On 1 Feb 2010, at 19:33, Jung-uk Kim wrote: > >> > On Monday 01 February 2010 02:25 pm, Rui Paulo wrote: > >> >> On 1 Feb 2010, at 19:21, Jung-uk Kim wrote: > >> >>> On Saturday 30 January 2010 10:49 am, Rui Paulo wrote: > >> >>>> Hi, > >> >>>> Latest ACPICA can't find my ASUS010 HID. It worked fine > >> >>>> with FreeBSD 8, which has ACPICA 20090521. > >> >>>> > >> >>>> The ASL is located at: > >> >>>> http://people.freebsd.org/~rpaulo/asus-1005ha.asl.gz > >> >>>> > >> >>>> What I'm seeing is ACPI_ID_PROBE() returning always NULL > >> >>>> for "ASUS010" and "ATK0100" devids. > >> >>> > >> >>> It seems the ASL disables ASUS010 when the OS is "Windows > >> >>> 2009" (aka Windows 7). FYI, current ACPI-CA just returns > >> >>> okay for any Microsoft OSes when _OSI method is used in ASL. > >> >>> Thus, it thinks you are running Windows 7. You can comment > >> >>> out or remove line 3626-3629 and override DSDT to re-enable > >> >>> the device, I think. > >> >> > >> >> You're right, but I'm left wondering why it worked with a > >> >> previous ACPICA. > >> > > >> > Because "Windows 2009" was added in 20090903. :-) > >> > >> I understand now. Still, I think this is ACPICA's fault, but I > >> understand that other laptops may rely on this behavior from > >> ACPICA, so the fix may cause even more problems.. > > > >I agree that it is ACPI-CA's fault but it was debated in Linux > >community for a while and they decided it is the best course of > >action for ACPI-CA, AFAIK. Basically, a lot of ACPI > > implementations out there just disable some "features" based on > > Windows versions. Even worse, many features are disabled when it > > matches "Linux". So, they decided returning the latest and > > greatest Windows version instead is the best choice. Luckily (or > > unluckily), not so many ACPI implementations match "FreeBSD". :-( > > > >Jung-uk Kim > >_______________________________________________ > >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 owner-freebsd-acpi@FreeBSD.ORG Tue Feb 2 00:08:23 2010 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84F401065676; Tue, 2 Feb 2010 00:08:23 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5BD128FC22; Tue, 2 Feb 2010 00:08:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1208Ns6057285; Tue, 2 Feb 2010 00:08:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1208NJW057281; Tue, 2 Feb 2010 00:08:23 GMT (envelope-from linimon) Date: Tue, 2 Feb 2010 00:08:23 GMT Message-Id: <201002020008.o1208NJW057281@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/143432: [acpi] [patch] Two bugs in acpica in AcpiExReleaseMutex X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 00:08:23 -0000 Old Synopsis: Two bugs in acpica in AcpiExReleaseMutex New Synopsis: [acpi] [patch] Two bugs in acpica in AcpiExReleaseMutex Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Tue Feb 2 00:07:42 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143432 From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 2 03:25:32 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B97CE106566C; Tue, 2 Feb 2010 03:25:32 +0000 (UTC) (envelope-from ming.m.lin@intel.com) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mx1.freebsd.org (Postfix) with ESMTP id 993298FC13; Tue, 2 Feb 2010 03:25:32 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 01 Feb 2010 18:56:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.49,387,1262592000"; d="scan'208";a="769230647" Received: from minggr.sh.intel.com (HELO [10.239.13.174]) ([10.239.13.174]) by fmsmga001.fm.intel.com with ESMTP; 01 Feb 2010 18:57:15 -0800 From: Lin Ming To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org In-Reply-To: <4911F71203A09E4D9981D27F9D83085855BBCFC8@orsmsx503.amr.corp.intel.com> References: <4911F71203A09E4D9981D27F9D83085855BBCFC8@orsmsx503.amr.corp.intel.com> Content-Type: multipart/mixed; boundary="=-+akFnwk/NjPxo18vPa8t" Date: Tue, 02 Feb 2010 10:40:23 +0800 Message-Id: <1265078423.14186.15.camel@minggr.sh.intel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.1 (2.24.1-2.fc10) Cc: "Moore, Robert" Subject: Re: kern/143432: [acpi] [patch] Two bugs in acpica in AcpiExReleaseMutex X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 03:25:32 -0000 --=-+akFnwk/NjPxo18vPa8t Content-Type: text/plain Content-Transfer-Encoding: 7bit Problem 1 was already fixed in release 20091214, see http://git.moblin.org/cgit.cgi/acpica/commit/?id=93324dd734d70c4aa451c3aa24dfe91b7b8ef7f9 Problem 2 is same with http://www.freebsd.org/cgi/query-pr.cgi?pr=140979 and fixed by the attached patch. We will merge it into next release. Lin Ming > -----Original Message----- > From: owner-freebsd-acpi@freebsd.org [mailto:owner-freebsd-acpi@freebsd.org] On Behalf Of linimon@FreeBSD.org > Sent: Monday, February 01, 2010 4:08 PM > To: linimon@FreeBSD.org; freebsd-bugs@FreeBSD.org; freebsd-acpi@FreeBSD.org > Subject: Re: kern/143432: [acpi] [patch] Two bugs in acpica in AcpiExReleaseMutex > > Old Synopsis: Two bugs in acpica in AcpiExReleaseMutex > New Synopsis: [acpi] [patch] Two bugs in acpica in AcpiExReleaseMutex > > Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi > Responsible-Changed-By: linimon > Responsible-Changed-When: Tue Feb 2 00:07:42 UTC 2010 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=143432 > _______________________________________________ > 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" --=-+akFnwk/NjPxo18vPa8t Content-Disposition: attachment; filename="mutex.patch" Content-Type: text/x-patch; name="mutex.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit diff --git a/source/components/executer/exmutex.c b/source/components/executer/exmutex.c index d0aa9de..0a4048d 100644 --- a/source/components/executer/exmutex.c +++ b/source/components/executer/exmutex.c @@ -471,6 +471,7 @@ AcpiExReleaseMutex ( { ACPI_STATUS Status = AE_OK; UINT8 PreviousSyncLevel; + ACPI_THREAD_STATE *OwnerThread; ACPI_FUNCTION_TRACE (ExReleaseMutex); @@ -481,9 +482,11 @@ AcpiExReleaseMutex ( return_ACPI_STATUS (AE_BAD_PARAMETER); } + OwnerThread = ObjDesc->Mutex.OwnerThread; + /* The mutex must have been previously acquired in order to release it */ - if (!ObjDesc->Mutex.OwnerThread) + if (!OwnerThread) { ACPI_ERROR ((AE_INFO, "Cannot release Mutex [%4.4s], not acquired", AcpiUtGetNodeName (ObjDesc->Mutex.Node))); @@ -503,14 +506,14 @@ AcpiExReleaseMutex ( * The Mutex is owned, but this thread must be the owner. * Special case for Global Lock, any thread can release */ - if ((ObjDesc->Mutex.OwnerThread->ThreadId != WalkState->Thread->ThreadId) && + if ((OwnerThread->ThreadId != WalkState->Thread->ThreadId) && (ObjDesc != AcpiGbl_GlobalLockMutex)) { ACPI_ERROR ((AE_INFO, "Thread %p cannot release Mutex [%4.4s] acquired by thread %p", ACPI_CAST_PTR (void, WalkState->Thread->ThreadId), AcpiUtGetNodeName (ObjDesc->Mutex.Node), - ACPI_CAST_PTR (void, ObjDesc->Mutex.OwnerThread->ThreadId))); + ACPI_CAST_PTR (void, OwnerThread->ThreadId))); return_ACPI_STATUS (AE_AML_NOT_OWNER); } @@ -521,7 +524,7 @@ AcpiExReleaseMutex ( * different level can only mean that the mutex ordering rule is being * violated. This behavior is clarified in ACPI 4.0 specification. */ - if (ObjDesc->Mutex.SyncLevel != WalkState->Thread->CurrentSyncLevel) + if (ObjDesc->Mutex.SyncLevel != OwnerThread->CurrentSyncLevel) { ACPI_ERROR ((AE_INFO, "Cannot release Mutex [%4.4s], SyncLevel mismatch: mutex %d current %d", @@ -536,7 +539,7 @@ AcpiExReleaseMutex ( * acquired, but are not released in reverse order. */ PreviousSyncLevel = - WalkState->Thread->AcquiredMutexList->Mutex.OriginalSyncLevel; + OwnerThread->AcquiredMutexList->Mutex.OriginalSyncLevel; Status = AcpiExReleaseMutexObject (ObjDesc); if (ACPI_FAILURE (Status)) @@ -548,7 +551,7 @@ AcpiExReleaseMutex ( { /* Restore the previous SyncLevel */ - WalkState->Thread->CurrentSyncLevel = PreviousSyncLevel; + OwnerThread->CurrentSyncLevel = PreviousSyncLevel; } return_ACPI_STATUS (Status); } --=-+akFnwk/NjPxo18vPa8t-- From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 2 11:50:36 2010 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98B1E1065670; Tue, 2 Feb 2010 11:50:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 708598FC0A; Tue, 2 Feb 2010 11:50:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o12BoaKO005535; Tue, 2 Feb 2010 11:50:36 GMT (envelope-from avg@freefall.freebsd.org) Received: (from avg@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o12BoaAj005525; Tue, 2 Feb 2010 11:50:36 GMT (envelope-from avg) Date: Tue, 2 Feb 2010 11:50:36 GMT Message-Id: <201002021150.o12BoaAj005525@freefall.freebsd.org> To: avg@FreeBSD.org, freebsd-acpi@FreeBSD.org, avg@FreeBSD.org From: avg@FreeBSD.org Cc: Subject: Re: kern/143432: [acpi] [patch] Two bugs in acpica in AcpiExReleaseMutex X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 11:50:36 -0000 Synopsis: [acpi] [patch] Two bugs in acpica in AcpiExReleaseMutex Responsible-Changed-From-To: freebsd-acpi->avg Responsible-Changed-By: avg Responsible-Changed-When: Tue Feb 2 11:49:10 UTC 2010 Responsible-Changed-Why: I will take this as I've been working on these issues. http://www.freebsd.org/cgi/query-pr.cgi?pr=143432 From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 2 11:56:49 2010 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C5D4106566B; Tue, 2 Feb 2010 11:56:49 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 532B88FC1B; Tue, 2 Feb 2010 11:56:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o12Bunjv009198; Tue, 2 Feb 2010 11:56:49 GMT (envelope-from avg@freefall.freebsd.org) Received: (from avg@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o12BunDR009194; Tue, 2 Feb 2010 11:56:49 GMT (envelope-from avg) Date: Tue, 2 Feb 2010 11:56:49 GMT Message-Id: <201002021156.o12BunDR009194@freefall.freebsd.org> To: avg@FreeBSD.org, freebsd-acpi@FreeBSD.org, avg@FreeBSD.org From: avg@FreeBSD.org Cc: Subject: Re: kern/140979: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 11:56:49 -0000 Synopsis: [acpi] [panic] Kernel panic (fatal trap 12: page fault when in kernel mode) on FreeBSD 8.0 with ACPI because of "ec" sub-device Responsible-Changed-From-To: freebsd-acpi->avg Responsible-Changed-By: avg Responsible-Changed-When: Tue Feb 2 11:55:57 UTC 2010 Responsible-Changed-Why: I will take this as I've been working on thise issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=140979 From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 3 14:53:17 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BCE31065679; Wed, 3 Feb 2010 14:53:17 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 69DC08FC12; Wed, 3 Feb 2010 14:53:15 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA08273; Wed, 03 Feb 2010 16:53:13 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B698DD8.4010404@icyb.net.ua> Date: Wed, 03 Feb 2010 16:53:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Rui Paulo , John Baldwin Subject: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 14:53:17 -0000 What do you think about changing logic of evaluating _PDC and _OSC for Processor object in acpi_cpu_attach? It seems that later versions of ACPI standard deprecate _PDC in favor of _OSC. Although, in practice they seem to be present or not present together, sometimes _PDC being only a wrappper around _OSC. There are still, of course, systems with only _PDC present. I assume that there are systems with only _OSC too. I would like to change the order, so that _OSC evaluation is attempted first and only if it fails then proceed with _PDC. Also, I would like to print status returned by _OSC (in case of successful evaluation) if it is not zero. (Note: this is not the same as status of evaluating _OSC). And I am going to fix the following comment: * On some systems we need to evaluate _OSC so that the ASL * loads the _PSS and/or _PDC methods at runtime. Although on many systems either _PDC or _OSC or both dynamically load SSDTs that contain additional Processor objects like _PSS and _PCT, I haven't seen any system where _OSC would load _PDC. And, honestly, that wouldn't make any sense. Perhaps, comment's author meant _PCT in place of _PDC, or something like that. Please let me know what you think. Thanks! Convenience link: http://download.intel.com/technology/IAPC/acpi/downloads/30222305.pdf -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 3 15:15:43 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0DF1065676; Wed, 3 Feb 2010 15:15:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6DB0A8FC28; Wed, 3 Feb 2010 15:15:43 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1007A46B0C; Wed, 3 Feb 2010 10:15:43 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 6E8328A024; Wed, 3 Feb 2010 10:15:42 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Wed, 3 Feb 2010 10:04:32 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B698DD8.4010404@icyb.net.ua> In-Reply-To: <4B698DD8.4010404@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002031004.32588.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 03 Feb 2010 10:15:42 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 15:15:43 -0000 On Wednesday 03 February 2010 9:53:12 am Andriy Gapon wrote: > > What do you think about changing logic of evaluating _PDC and _OSC for Processor > object in acpi_cpu_attach? > It seems that later versions of ACPI standard deprecate _PDC in favor of _OSC. > Although, in practice they seem to be present or not present together, sometimes > _PDC being only a wrappper around _OSC. There are still, of course, systems with > only _PDC present. I assume that there are systems with only _OSC too. > > I would like to change the order, so that _OSC evaluation is attempted first and > only if it fails then proceed with _PDC. > > Also, I would like to print status returned by _OSC (in case of successful > evaluation) if it is not zero. (Note: this is not the same as status of evaluating > _OSC). > > And I am going to fix the following comment: > * On some systems we need to evaluate _OSC so that the ASL > * loads the _PSS and/or _PDC methods at runtime. > > Although on many systems either _PDC or _OSC or both dynamically load SSDTs that > contain additional Processor objects like _PSS and _PCT, I haven't seen any system > where _OSC would load _PDC. And, honestly, that wouldn't make any sense. > Perhaps, comment's author meant _PCT in place of _PDC, or something like that. > > Please let me know what you think. > Thanks! This all sounds good to me. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 3 15:21:06 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4D521065679; Wed, 3 Feb 2010 15:21:06 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 0A16E8FC13; Wed, 3 Feb 2010 15:21:05 +0000 (UTC) Received: by fxm26 with SMTP id 26so556326fxm.13 for ; Wed, 03 Feb 2010 07:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Ysx2FA5pkRiD6QOMI6Le2JImu1pBbp+k+Vk4JsprmA0=; b=hsDykKwkeZAyDD39jFlUAR1b1BhwcCVbd1Lc08sqO4wvkIQrsvSt63WDjkAKlRQ/6E 6nKKo5Np4S09sRbLhC8KZ+N81WI6I1JWM5kUK4Mt/dIhTEM7G5vXV2kflvcTxQj4ltco faHv17/b6Ktda9xG2iHV6Ax4l5v21G/DbGBRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=CxI3biukoKVWKsdrTYF3XM3NieMs23N0+8iRKOJgraDnu9QOdR4JyFNRLn5KUAH9lA AjhRo5csfI9siHieKjjRDsCsfsbmXCesW1Jtvr5Sb+XUL89sqbcCBkPkgx4CmOcMIW3I ugO91lrc1as+G4kqkNmLr+ISIz9YkSKfpK9sA= Received: by 10.223.5.14 with SMTP id 14mr7977669fat.83.1265210464949; Wed, 03 Feb 2010 07:21:04 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 14sm3230212fxm.11.2010.02.03.07.21.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 07:21:03 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <4B698DD8.4010404@icyb.net.ua> Date: Wed, 3 Feb 2010 15:21:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <43E821DA-BBD8-4ADD-ACA6-BDDD1ECB8B8F@FreeBSD.org> References: <4B698DD8.4010404@icyb.net.ua> To: Andriy Gapon X-Mailer: Apple Mail (2.1077) Cc: freebsd-acpi@FreeBSD.org, John Baldwin Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 15:21:06 -0000 On 3 Feb 2010, at 14:53, Andriy Gapon wrote: >=20 > What do you think about changing logic of evaluating _PDC and _OSC for = Processor > object in acpi_cpu_attach? > It seems that later versions of ACPI standard deprecate _PDC in favor = of _OSC. > Although, in practice they seem to be present or not present together, = sometimes > _PDC being only a wrappper around _OSC. There are still, of course, = systems with > only _PDC present. I assume that there are systems with only _OSC = too. >=20 > I would like to change the order, so that _OSC evaluation is attempted = first and > only if it fails then proceed with _PDC. >=20 > Also, I would like to print status returned by _OSC (in case of = successful > evaluation) if it is not zero. (Note: this is not the same as status = of evaluating > _OSC). >=20 > And I am going to fix the following comment: > * On some systems we need to evaluate _OSC so that the ASL > * loads the _PSS and/or _PDC methods at runtime. >=20 > Although on many systems either _PDC or _OSC or both dynamically load = SSDTs that > contain additional Processor objects like _PSS and _PCT, I haven't = seen any system > where _OSC would load _PDC. And, honestly, that wouldn't make any = sense. > Perhaps, comment's author meant _PCT in place of _PDC, or something = like that. I added the comment and I have such system. It's a MacBook first = generation. By evaluating _OSC we were able to make _PDC visible, thus enabling = cpufreq(4). -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 3 15:29:10 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D6671065670; Wed, 3 Feb 2010 15:29:10 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4840C8FC0C; Wed, 3 Feb 2010 15:29:08 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA08664; Wed, 03 Feb 2010 17:29:07 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B699643.1080803@icyb.net.ua> Date: Wed, 03 Feb 2010 17:29:07 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Rui Paulo References: <4B698DD8.4010404@icyb.net.ua> <43E821DA-BBD8-4ADD-ACA6-BDDD1ECB8B8F@FreeBSD.org> In-Reply-To: <43E821DA-BBD8-4ADD-ACA6-BDDD1ECB8B8F@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, John Baldwin Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 15:29:10 -0000 on 03/02/2010 17:21 Rui Paulo said the following: > On 3 Feb 2010, at 14:53, Andriy Gapon wrote: > >> What do you think about changing logic of evaluating _PDC and _OSC for Processor >> object in acpi_cpu_attach? >> It seems that later versions of ACPI standard deprecate _PDC in favor of _OSC. >> Although, in practice they seem to be present or not present together, sometimes >> _PDC being only a wrappper around _OSC. There are still, of course, systems with >> only _PDC present. I assume that there are systems with only _OSC too. >> >> I would like to change the order, so that _OSC evaluation is attempted first and >> only if it fails then proceed with _PDC. >> >> Also, I would like to print status returned by _OSC (in case of successful >> evaluation) if it is not zero. (Note: this is not the same as status of evaluating >> _OSC). >> >> And I am going to fix the following comment: >> * On some systems we need to evaluate _OSC so that the ASL >> * loads the _PSS and/or _PDC methods at runtime. >> >> Although on many systems either _PDC or _OSC or both dynamically load SSDTs that >> contain additional Processor objects like _PSS and _PCT, I haven't seen any system >> where _OSC would load _PDC. And, honestly, that wouldn't make any sense. >> Perhaps, comment's author meant _PCT in place of _PDC, or something like that. > > I added the comment and I have such system. It's a MacBook first generation. > > By evaluating _OSC we were able to make _PDC visible, thus enabling cpufreq(4). You know what is strange - in current code _PDC is evaluated before _OSC. 1. So even if _OSC makes it visible, how would that affect anything? There is no code that would evaluate _PDC that comes into existence after _OSC evaluation. 2. That's beside the theoretical question of why _OSC which deprecates _PDC would bring in the latter. 3. Also, are you sure that it was _PDC that did that? I.e. not _PSS, not _PCT, not _ETC :-) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 3 20:46:53 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2103106568F for ; Wed, 3 Feb 2010 20:46:53 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7570C8FC0A for ; Wed, 3 Feb 2010 20:46:53 +0000 (UTC) Received: from [192.168.1.226] (dsl081-053-082.sfo1.dsl.speakeasy.net [64.81.53.82]) by mail.root.org (Postfix) with ESMTP id 1217942D8; Wed, 3 Feb 2010 20:46:51 +0000 (UTC) Message-ID: <4B69E0BA.4080104@root.org> Date: Wed, 03 Feb 2010 12:46:50 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andriy Gapon References: <4B698DD8.4010404@icyb.net.ua> In-Reply-To: <4B698DD8.4010404@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, Rui Paulo , John Baldwin Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 20:46:53 -0000 Andriy Gapon wrote: > What do you think about changing logic of evaluating _PDC and _OSC for Processor > object in acpi_cpu_attach? > It seems that later versions of ACPI standard deprecate _PDC in favor of _OSC. > Although, in practice they seem to be present or not present together, sometimes > _PDC being only a wrappper around _OSC. There are still, of course, systems with > only _PDC present. I assume that there are systems with only _OSC too. > > I would like to change the order, so that _OSC evaluation is attempted first and > only if it fails then proceed with _PDC. > This is fine with me. When I first implemented this stuff, _PDC was barely public and I had to guess at some of the bits. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 4 19:42:52 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B5E61065670; Thu, 4 Feb 2010 19:42:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CAC848FC08; Thu, 4 Feb 2010 19:42:50 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA00576; Thu, 04 Feb 2010 21:42:48 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B6B2337.8070404@icyb.net.ua> Date: Thu, 04 Feb 2010 21:42:47 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org References: <4B698DD8.4010404@icyb.net.ua> <4B69E0BA.4080104@root.org> In-Reply-To: <4B69E0BA.4080104@root.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Rui Paulo , John Baldwin Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 19:42:52 -0000 Below is the patch that I have. _PDC is evaluated only if _OSC evaluation fails. _OSC status returned by AML is reported if not zero. Small changes in comments. BTW, 'if (sc->cpu_features)' check could probably be dropped, because we initialize cpu_features with non-zero value and then only bit-or to it. Index: sys/dev/acpica/acpi_cpu.c =================================================================== --- sys/dev/acpica/acpi_cpu.c (revision 203497) +++ sys/dev/acpica/acpi_cpu.c (working copy) @@ -345,26 +345,13 @@ } /* - * CPU capabilities are specified as a buffer of 32-bit integers: - * revision, count, and one or more capabilities. The revision of - * "1" is not specified anywhere but seems to match Linux. + * CPU capabilities are specified in + * Intel Processor Vendor-Specific ACPI Interface Specification. */ if (sc->cpu_features) { - arglist.Pointer = arg; - arglist.Count = 1; - arg[0].Type = ACPI_TYPE_BUFFER; - arg[0].Buffer.Length = sizeof(cap_set); - arg[0].Buffer.Pointer = (uint8_t *)cap_set; - cap_set[0] = 1; /* revision */ - cap_set[1] = 1; /* number of capabilities integers */ - cap_set[2] = sc->cpu_features; - AcpiEvaluateObject(sc->cpu_handle, "_PDC", &arglist, NULL); - /* - * On some systems we need to evaluate _OSC so that the ASL - * loads the _PSS and/or _PDC methods at runtime. - * - * TODO: evaluate failure of _OSC. + * On some systems evaluation of _OSC/_PDC dynamically + * loads the _PSS and other methods. */ arglist.Pointer = arg; arglist.Count = 4; @@ -380,7 +367,22 @@ arg[3].Buffer.Pointer = (uint8_t *)cap_set; cap_set[0] = 0; /* status */ cap_set[1] = sc->cpu_features; - AcpiEvaluateObject(sc->cpu_handle, "_OSC", &arglist, NULL); + status = AcpiEvaluateObject(sc->cpu_handle, "_OSC", &arglist, NULL); + if (ACPI_SUCCESS(status)) { + if (cap_set[0] != 0) + device_printf(dev, "_OSC returned status %#x\n", cap_set[0]); + } + else { + arglist.Pointer = arg; + arglist.Count = 1; + arg[0].Type = ACPI_TYPE_BUFFER; + arg[0].Buffer.Length = sizeof(cap_set); + arg[0].Buffer.Pointer = (uint8_t *)cap_set; + cap_set[0] = 1; /* revision */ + cap_set[1] = 1; /* number of capabilities integers */ + cap_set[2] = sc->cpu_features; + AcpiEvaluateObject(sc->cpu_handle, "_PDC", &arglist, NULL); + } } /* Probe for Cx state support. */ -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 4 21:57:57 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ED2C10656B6; Thu, 4 Feb 2010 21:57:57 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 70FB38FC15; Thu, 4 Feb 2010 21:57:57 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E5CDC46B17; Thu, 4 Feb 2010 16:57:56 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 26E538A024; Thu, 4 Feb 2010 16:57:56 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Thu, 4 Feb 2010 16:57:52 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B698DD8.4010404@icyb.net.ua> <4B69E0BA.4080104@root.org> <4B6B2337.8070404@icyb.net.ua> In-Reply-To: <4B6B2337.8070404@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002041657.52232.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 04 Feb 2010 16:57:56 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 21:57:57 -0000 On Thursday 04 February 2010 2:42:47 pm Andriy Gapon wrote: > > Below is the patch that I have. > _PDC is evaluated only if _OSC evaluation fails. > _OSC status returned by AML is reported if not zero. > Small changes in comments. > > BTW, 'if (sc->cpu_features)' check could probably be dropped, because we > initialize cpu_features with non-zero value and then only bit-or to it. > > Index: sys/dev/acpica/acpi_cpu.c > =================================================================== > --- sys/dev/acpica/acpi_cpu.c (revision 203497) > +++ sys/dev/acpica/acpi_cpu.c (working copy) > @@ -345,26 +345,13 @@ > } > > /* > - * CPU capabilities are specified as a buffer of 32-bit integers: > - * revision, count, and one or more capabilities. The revision of > - * "1" is not specified anywhere but seems to match Linux. > + * CPU capabilities are specified in > + * Intel Processor Vendor-Specific ACPI Interface Specification. > */ > if (sc->cpu_features) { > - arglist.Pointer = arg; > - arglist.Count = 1; > - arg[0].Type = ACPI_TYPE_BUFFER; > - arg[0].Buffer.Length = sizeof(cap_set); > - arg[0].Buffer.Pointer = (uint8_t *)cap_set; > - cap_set[0] = 1; /* revision */ > - cap_set[1] = 1; /* number of capabilities integers */ > - cap_set[2] = sc->cpu_features; > - AcpiEvaluateObject(sc->cpu_handle, "_PDC", &arglist, NULL); > - > /* > - * On some systems we need to evaluate _OSC so that the ASL > - * loads the _PSS and/or _PDC methods at runtime. > - * > - * TODO: evaluate failure of _OSC. > + * On some systems evaluation of _OSC/_PDC dynamically > + * loads the _PSS and other methods. > */ I would only say _OSC here. I don't think we've seen any systems that load something when _PDC is invoked, only when _OSC is invoked. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 4 22:13:33 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC4A0106566C; Thu, 4 Feb 2010 22:13:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 95F938FC18; Thu, 4 Feb 2010 22:13:32 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA02026; Fri, 05 Feb 2010 00:13:31 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Nd9x4-0004KK-SM; Fri, 05 Feb 2010 00:13:30 +0200 Message-ID: <4B6B4689.4020708@icyb.net.ua> Date: Fri, 05 Feb 2010 00:13:29 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: John Baldwin References: <4B698DD8.4010404@icyb.net.ua> <4B69E0BA.4080104@root.org> <4B6B2337.8070404@icyb.net.ua> <201002041657.52232.jhb@freebsd.org> In-Reply-To: <201002041657.52232.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 22:13:33 -0000 on 04/02/2010 23:57 John Baldwin said the following: > On Thursday 04 February 2010 2:42:47 pm Andriy Gapon wrote: >> - * TODO: evaluate failure of _OSC. >> + * On some systems evaluation of _OSC/_PDC dynamically >> + * loads the _PSS and other methods. >> */ > > I would only say _OSC here. I don't think we've seen any systems that load > something when _PDC is invoked, only when _OSC is invoked. Actually, I think that the way it's written should be OK. I've seen a few DSDTs where both are present and both do the same thing. E.g.: Scope (\_PR.CPU0) { Name (HI0, Zero) Name (HC0, Zero) Method (_PDC, 1, NotSerialized) { Store (CPDC (Arg0), Local0) GCAP (Local0) Return (Local0) } Method (_OSC, 4, NotSerialized) { Store (COSC (Arg0, Arg1, Arg2, Arg3), Local0) GCAP (Local0) Return (Local0) } ... Looks like CPDC is "Convert _PDC" and COSC is "Convert _OSC" and GCAP is "G... capabilities", whatever "G..." could mean. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 4 22:29:20 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EF171065670 for ; Thu, 4 Feb 2010 22:29:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5525C8FC14 for ; Thu, 4 Feb 2010 22:29:18 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA02195 for ; Fri, 05 Feb 2010 00:29:17 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NdACL-0004LQ-Iy for freebsd-acpi@FreeBSD.org; Fri, 05 Feb 2010 00:29:17 +0200 Message-ID: <4B6B4A3C.5090308@icyb.net.ua> Date: Fri, 05 Feb 2010 00:29:16 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: acpi_ec_ecdt_probe => acpi_ec_identify X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 22:29:20 -0000 I would like to convert acpi_ec_ecdt_probe to device_identify method. Rationale: 1. It doesn't look like any device is using acpi_ec's services during identify stage (or earlier) and acpi_ec already has a rather high priority among acpi drivers that it would probe and attach before most of them. 2. Making a driver 'less special' is always a good thing in general. 3. Probing/attachment of acpi_ec at the current very early stage may even fail because it could be dependent on things done by other, even more fundamental, drivers that provide system resources. 4. To expand the above: on some systems EC _REG method accesses things that only get dynamically loaded after Processor's _PDC/_OSC is evaluated[*]. Converting acpi_ec_ecdt_probe => acpi_ec_identify won't help here, but this would be a first step towards a solution. [*] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/142561 Followups from Jan 15 on. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 4 22:29:26 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1B0110656B0; Thu, 4 Feb 2010 22:29:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B56D18FC0C; Thu, 4 Feb 2010 22:29:26 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6D5D446B03; Thu, 4 Feb 2010 17:29:26 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B91268A01F; Thu, 4 Feb 2010 17:29:25 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Thu, 4 Feb 2010 17:29:18 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B698DD8.4010404@icyb.net.ua> <201002041657.52232.jhb@freebsd.org> <4B6B4689.4020708@icyb.net.ua> In-Reply-To: <4B6B4689.4020708@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002041729.18714.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 04 Feb 2010 17:29:25 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 22:29:27 -0000 On Thursday 04 February 2010 5:13:29 pm Andriy Gapon wrote: > on 04/02/2010 23:57 John Baldwin said the following: > > On Thursday 04 February 2010 2:42:47 pm Andriy Gapon wrote: > >> - * TODO: evaluate failure of _OSC. > >> + * On some systems evaluation of _OSC/_PDC dynamically > >> + * loads the _PSS and other methods. > >> */ > > > > I would only say _OSC here. I don't think we've seen any systems that load > > something when _PDC is invoked, only when _OSC is invoked. > > Actually, I think that the way it's written should be OK. > I've seen a few DSDTs where both are present and both do the same thing. > E.g.: > > Scope (\_PR.CPU0) > { > Name (HI0, Zero) > Name (HC0, Zero) > Method (_PDC, 1, NotSerialized) > { > Store (CPDC (Arg0), Local0) > GCAP (Local0) > Return (Local0) > } > > Method (_OSC, 4, NotSerialized) > { > Store (COSC (Arg0, Arg1, Arg2, Arg3), Local0) > GCAP (Local0) > Return (Local0) > } > ... > > Looks like CPDC is "Convert _PDC" and COSC is "Convert _OSC" and GCAP is "G... > capabilities", whatever "G..." could mean. But is GCAP loading an additional SSDT? That is what the "loading something" refers to and I think we've only observed that occurring with _OSC. I'd rather we only document unexpected quirks that someone has actually reported and not assume that just because an _OSC method on some box did it, there's bound to be a _PDC method on some other box that does it. In truth, the comment is probably not needed now anyway since this will always do _OSC first. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 4 22:33:22 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B7BA106566B; Thu, 4 Feb 2010 22:33:22 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 64C258FC14; Thu, 4 Feb 2010 22:33:21 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA02253; Fri, 05 Feb 2010 00:33:20 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NdAGF-0004Ly-Iq; Fri, 05 Feb 2010 00:33:19 +0200 Message-ID: <4B6B4B2F.2010109@icyb.net.ua> Date: Fri, 05 Feb 2010 00:33:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: John Baldwin References: <4B698DD8.4010404@icyb.net.ua> <201002041657.52232.jhb@freebsd.org> <4B6B4689.4020708@icyb.net.ua> <201002041729.18714.jhb@freebsd.org> In-Reply-To: <201002041729.18714.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 22:33:22 -0000 on 05/02/2010 00:29 John Baldwin said the following: > But is GCAP loading an additional SSDT? That is what the "loading something" > refers to and I think we've only observed that occurring with _OSC. I'd > rather we only document unexpected quirks that someone has actually reported > and not assume that just because an _OSC method on some box did it, there's > bound to be a _PDC method on some other box that does it. In truth, the > comment is probably not needed now anyway since this will always do _OSC > first. I agree with you. Probably the comment is too obvious or too useless now, when such things are a common place. To answer your first question - yes it does: Method (GCAP, 1, NotSerialized) { CreateDWordField (Arg0, Zero, STS0) CreateDWordField (Arg0, 0x04, CAP0) If (LOr (LEqual (STS0, 0x06), LEqual (STS0, 0x0A))) { Return (Zero) } If (And (STS0, One)) { And (CAP0, 0x0BFF, CAP0) Return (Zero) } Or (And (PDC0, 0x7FFFFFFF), CAP0, PDC0) If (And (CFGD, One)) { If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (PDC0, 0x09), 0x09)), LNot (And (SDTL, One)))) { Or (SDTL, One, SDTL) OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, One)), DerefOf (Index (SSDT, 0x02 ))) Load (IST0, HI0) } } If (And (CFGD, 0xF0)) { If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC0, 0x18 )), LNot (And (SDTL, 0x02)))) { Or (SDTL, 0x02, SDTL) OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08 ))) Load (CST0, HC0) } } Return (Zero) } -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 5 05:53:41 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FFF9106566B for ; Fri, 5 Feb 2010 05:53:41 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id 406C68FC0A for ; Fri, 5 Feb 2010 05:53:41 +0000 (UTC) Received: from [10.0.5.50] (ppp-71-139-29-85.dsl.snfc21.pacbell.net [71.139.29.85]) by mail.root.org (Postfix) with ESMTP id 84D584E04; Fri, 5 Feb 2010 05:53:39 +0000 (UTC) Message-ID: <4B6BB263.4040604@root.org> Date: Thu, 04 Feb 2010 21:53:39 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andriy Gapon References: <4B6B4A3C.5090308@icyb.net.ua> In-Reply-To: <4B6B4A3C.5090308@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: acpi_ec_ecdt_probe => acpi_ec_identify X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 05:53:41 -0000 Andriy Gapon wrote: > I would like to convert acpi_ec_ecdt_probe to device_identify method. > Rationale: > 1. It doesn't look like any device is using acpi_ec's services during identify > stage (or earlier) and acpi_ec already has a rather high priority among acpi > drivers that it would probe and attach before most of them. > 2. Making a driver 'less special' is always a good thing in general. > 3. Probing/attachment of acpi_ec at the current very early stage may even fail > because it could be dependent on things done by other, even more fundamental, > drivers that provide system resources. > 4. To expand the above: on some systems EC _REG method accesses things that only > get dynamically loaded after Processor's _PDC/_OSC is evaluated[*]. Converting > acpi_ec_ecdt_probe => acpi_ec_identify won't help here, but this would be a > first step towards a solution. > > [*] > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/142561 > Followups from Jan 15 on. I agree in concept. The ECDT-based probe method was intended to get it active as early as possible, and Linux has a quirk to create a fake ECDT to get an early EC on some systems that require it but don't have an ECDT. However, I thought jhb@'s multi-pass probe work would be a better way to support this than moving it into device_identify(). Is that code ready to use yet? -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 5 06:16:20 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7109106566C; Fri, 5 Feb 2010 06:16:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C66A28FC1D; Fri, 5 Feb 2010 06:16:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA07463; Fri, 05 Feb 2010 08:16:16 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NdHUG-0006wb-7T; Fri, 05 Feb 2010 08:16:16 +0200 Message-ID: <4B6BB7AF.3040205@icyb.net.ua> Date: Fri, 05 Feb 2010 08:16:15 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Nate Lawson References: <4B6B4A3C.5090308@icyb.net.ua> <4B6BB263.4040604@root.org> In-Reply-To: <4B6BB263.4040604@root.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, John Baldwin Subject: Re: acpi_ec_ecdt_probe => acpi_ec_identify X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 06:16:20 -0000 on 05/02/2010 07:53 Nate Lawson said the following: > Andriy Gapon wrote: >> I would like to convert acpi_ec_ecdt_probe to device_identify method. >> Rationale: >> 1. It doesn't look like any device is using acpi_ec's services during identify >> stage (or earlier) and acpi_ec already has a rather high priority among acpi >> drivers that it would probe and attach before most of them. >> 2. Making a driver 'less special' is always a good thing in general. >> 3. Probing/attachment of acpi_ec at the current very early stage may even fail >> because it could be dependent on things done by other, even more fundamental, >> drivers that provide system resources. >> 4. To expand the above: on some systems EC _REG method accesses things that only >> get dynamically loaded after Processor's _PDC/_OSC is evaluated[*]. Converting >> acpi_ec_ecdt_probe => acpi_ec_identify won't help here, but this would be a >> first step towards a solution. >> >> [*] >> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/142561 >> Followups from Jan 15 on. > > I agree in concept. The ECDT-based probe method was intended to get it > active as early as possible, and Linux has a quirk to create a fake ECDT > to get an early EC on some systems that require it but don't have an ECDT. > > However, I thought jhb@'s multi-pass probe work would be a better way to > support this than moving it into device_identify(). Is that code ready > to use yet? I agree with this. But, unfortunately, the code doesn't seem to be as ready as everyone would love it to be. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 5 06:21:23 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 371D7106566C; Fri, 5 Feb 2010 06:21:23 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id 172C88FC17; Fri, 5 Feb 2010 06:21:22 +0000 (UTC) Received: from [10.0.5.50] (ppp-71-139-29-85.dsl.snfc21.pacbell.net [71.139.29.85]) by mail.root.org (Postfix) with ESMTP id 842A24E82; Fri, 5 Feb 2010 06:21:21 +0000 (UTC) Message-ID: <4B6BB8E2.6080204@root.org> Date: Thu, 04 Feb 2010 22:21:22 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andriy Gapon References: <4B6B4A3C.5090308@icyb.net.ua> <4B6BB263.4040604@root.org> <4B6BB7AF.3040205@icyb.net.ua> In-Reply-To: <4B6BB7AF.3040205@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, John Baldwin Subject: Re: acpi_ec_ecdt_probe => acpi_ec_identify X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 06:21:23 -0000 Andriy Gapon wrote: > on 05/02/2010 07:53 Nate Lawson said the following: >> I agree in concept. The ECDT-based probe method was intended to get it >> active as early as possible, and Linux has a quirk to create a fake ECDT >> to get an early EC on some systems that require it but don't have an ECDT. >> >> However, I thought jhb@'s multi-pass probe work would be a better way to >> support this than moving it into device_identify(). Is that code ready >> to use yet? > > I agree with this. But, unfortunately, the code doesn't seem to be as ready as > everyone would love it to be. Ok, then identify() is fine too. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 5 08:37:10 2010 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30BCC1065692; Fri, 5 Feb 2010 08:37:10 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3797A8FC28; Fri, 5 Feb 2010 08:37:08 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA09950; Fri, 05 Feb 2010 10:37:07 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NdJgZ-0007CN-7C; Fri, 05 Feb 2010 10:37:07 +0200 Message-ID: <4B6BD8B2.2060504@icyb.net.ua> Date: Fri, 05 Feb 2010 10:37:06 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org, Jung-uk Kim X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: acpica in stable/8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 08:37:10 -0000 I would like to bring version of ACPICA in stable/8 to that of head, that is 20100121. Here's svn status and svn diff outputs for the merge: http://people.freebsd.org/~avg/stable-8-acpi.status.txt http://people.freebsd.org/~avg/stable-8-acpi.diff I've performed this MFC by doing series of svn merges first to sys, then to usr.sbin/acpi. I hope that this is a correct approach. I have some doubts because of heard suggestions that such merges should be done from vendor area. But, OTOH, in head there were direct commits sys to fix consequences of merge from vendor area. Subversion gurus, please advise! Please also check if I haven't forgot to MFC something or maybe MFC-ed something unneeded, or made some other mistake. The change is compile tested on i386 and amd64, and run-tested on amd64, but on a rather 'plain' machine from ACPI point of view. If you would like and are able to test this change, I will greatly appreciate your feedback! Some arguments for doing this MFC (copied from an earlier email to jkim): First, it gets more testing. Then, I think it would be hard to keep it at the current version forever. Because some bugs get discovered and, as people get newer hardware, they are more likely to hit those bugs, and the people will demand fixes :-) And 8-STABLE is expected to have an active life for at least 2 years. And, the more frequent will be the updates, the easier it should be to catch bugs and fix them. One thing is getting a year's worth of changes, another is that of a month. Below is the list of the MFC-ed changes. It was generated in semi-automated fashion, so I might have made a mistake somewhere and the list could be incorrect: ------------------------------------------------------------------------ r197104 | jkim | 2009-09-12 01:48:53 +0300 (Sat, 12 Sep 2009) | 4 lines MFV: r196804 Import ACPICA 20090903 ------------------------------------------------------------------------ r197105 | jkim | 2009-09-12 01:49:34 +0300 (Sat, 12 Sep 2009) | 2 lines Catch up with ACPICA 20090903. ------------------------------------------------------------------------ r197106 | jkim | 2009-09-12 01:50:15 +0300 (Sat, 12 Sep 2009) | 2 lines Catch up with ACPICA 20090903. ------------------------------------------------------------------------ r197107 | jkim | 2009-09-12 01:56:08 +0300 (Sat, 12 Sep 2009) | 2 lines Canonify include paths for newly added files. ------------------------------------------------------------------------ r197688 | jkim | 2009-10-01 23:56:15 +0300 (Thu, 01 Oct 2009) | 4 lines Compile ACPI debugger and disassembler for kernel modules unconditionally. These files will generate almost empty object files without ACPI_DEBUG/DDB options. As a result, size of acpi.ko will increase slightly. ------------------------------------------------------------------------ r198237 | jkim | 2009-10-19 19:12:58 +0300 (Mon, 19 Oct 2009) | 2 lines Merge ACPICA 20091013. ------------------------------------------------------------------------ r199337 | jkim | 2009-11-16 23:47:12 +0200 (Mon, 16 Nov 2009) | 2 lines Merge ACPICA 20091112. ------------------------------------------------------------------------ r199338 | jkim | 2009-11-16 23:53:56 +0200 (Mon, 16 Nov 2009) | 2 lines Add a forgotten module Makefile change from the previous commit. ------------------------------------------------------------------------ r200553 | jkim | 2009-12-15 00:24:04 +0200 (Tue, 15 Dec 2009) | 2 lines Merge ACPICA 20091214. ------------------------------------------------------------------------ r200554 | jkim | 2009-12-15 00:28:32 +0200 (Tue, 15 Dec 2009) | 3 lines Remove _FDE quirk handling as these quirks are automatically repaired by ACPICA layer since ACPICA 20091214. ------------------------------------------------------------------------ r202771 | jkim | 2010-01-21 23:14:28 +0200 (Thu, 21 Jan 2010) | 2 lines Merge ACPICA 20100121. ------------------------------------------------------------------------ r202773 | jkim | 2010-01-21 23:31:39 +0200 (Thu, 21 Jan 2010) | 2 lines Fix a new header inclusion. ------------------------------------------------------------------------ In a raw form with some additional info: /head/usr.sbin/acpi:r197106,198237,199337,202771 /head/sys:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head/sys/dev/xen/xenpci:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head/sys/contrib/pf:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /vendor-sys/acpica/dist:r193332-202768 /head/sys/contrib/dev/acpica:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head/sys/cddl/contrib/opensolaris:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 /head/sys/amd64/include/xen:r197104-197105,197107,197688,198237,199337-199338,200553-200554,202771,202773 -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 5 13:36:46 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E10AD106568D; Fri, 5 Feb 2010 13:36:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B2E408FC15; Fri, 5 Feb 2010 13:36:46 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6558046B2E; Fri, 5 Feb 2010 08:36:46 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 68F578A01F; Fri, 5 Feb 2010 08:36:45 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Fri, 5 Feb 2010 08:22:54 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B698DD8.4010404@icyb.net.ua> <201002041729.18714.jhb@freebsd.org> <4B6B4B2F.2010109@icyb.net.ua> In-Reply-To: <4B6B4B2F.2010109@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002050822.54616.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 05 Feb 2010 08:36:45 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_cpu: _PDC vs _OSC X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 13:36:47 -0000 On Thursday 04 February 2010 5:33:19 pm Andriy Gapon wrote: > on 05/02/2010 00:29 John Baldwin said the following: > > But is GCAP loading an additional SSDT? That is what the "loading something" > > refers to and I think we've only observed that occurring with _OSC. I'd > > rather we only document unexpected quirks that someone has actually reported > > and not assume that just because an _OSC method on some box did it, there's > > bound to be a _PDC method on some other box that does it. In truth, the > > comment is probably not needed now anyway since this will always do _OSC > > first. > > I agree with you. Probably the comment is too obvious or too useless now, when > such things are a common place. > To answer your first question - yes it does: Aiee, fair enough. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 5 13:36:47 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0C781065694 for ; Fri, 5 Feb 2010 13:36:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C362F8FC18 for ; Fri, 5 Feb 2010 13:36:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7627B46B38; Fri, 5 Feb 2010 08:36:47 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 931958A021; Fri, 5 Feb 2010 08:36:46 -0500 (EST) From: John Baldwin To: Nate Lawson Date: Fri, 5 Feb 2010 08:23:36 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6B4A3C.5090308@icyb.net.ua> <4B6BB7AF.3040205@icyb.net.ua> <4B6BB8E2.6080204@root.org> In-Reply-To: <4B6BB8E2.6080204@root.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002050823.36322.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 05 Feb 2010 08:36:46 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-acpi@freebsd.org, Andriy Gapon Subject: Re: acpi_ec_ecdt_probe => acpi_ec_identify X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 13:36:48 -0000 On Friday 05 February 2010 1:21:22 am Nate Lawson wrote: > Andriy Gapon wrote: > > on 05/02/2010 07:53 Nate Lawson said the following: > >> I agree in concept. The ECDT-based probe method was intended to get it > >> active as early as possible, and Linux has a quirk to create a fake ECDT > >> to get an early EC on some systems that require it but don't have an ECDT. > >> > >> However, I thought jhb@'s multi-pass probe work would be a better way to > >> support this than moving it into device_identify(). Is that code ready > >> to use yet? > > > > I agree with this. But, unfortunately, the code doesn't seem to be as ready as > > everyone would love it to be. > > Ok, then identify() is fine too. Also, once the multi-pass stuff is pushed down into the acpi(4) driver, an identify method would be the right way to do this. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 5 14:36:40 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0FF61065670; Fri, 5 Feb 2010 14:36:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 941678FC1A; Fri, 5 Feb 2010 14:36:40 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2EC3F46B46; Fri, 5 Feb 2010 09:36:40 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id DE92F8A01F; Fri, 5 Feb 2010 09:36:38 -0500 (EST) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 5 Feb 2010 09:36:08 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <4B6BD8B2.2060504@icyb.net.ua> In-Reply-To: <4B6BD8B2.2060504@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002050936.08434.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 05 Feb 2010 09:36:38 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andriy Gapon Subject: Re: acpica in stable/8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 14:36:40 -0000 On Friday 05 February 2010 3:37:06 am Andriy Gapon wrote: > > I would like to bring version of ACPICA in stable/8 to that of head, that is > 20100121. > > Here's svn status and svn diff outputs for the merge: > http://people.freebsd.org/~avg/stable-8-acpi.status.txt > http://people.freebsd.org/~avg/stable-8-acpi.diff > > I've performed this MFC by doing series of svn merges first to sys, then to > usr.sbin/acpi. I hope that this is a correct approach. > I have some doubts because of heard suggestions that such merges should be done > from vendor area. But, OTOH, in head there were direct commits sys to fix > consequences of merge from vendor area. > Subversion gurus, please advise! You should just MFC the changes from HEAD. You should not merge from the vendor branch directly into a stable branch. The only time that would be appropriate would be to merge a vendor change into a stable branch that was never merged to HEAD (e.g. if some vendor software 'foo' was upgraded from version 1 to version 2 in HEAD but was version 1 in a stable branch and later a patch release 1.1 that fixed a security bug came out, then 1.1 would be imported into the vendor area and directly merged to the stable branch). -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Feb 5 14:45:27 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E822106566B; Fri, 5 Feb 2010 14:45:27 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 3B5128FC19; Fri, 5 Feb 2010 14:45:25 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA15539; Fri, 05 Feb 2010 16:45:24 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B6C2F04.1010104@icyb.net.ua> Date: Fri, 05 Feb 2010 16:45:24 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: John Baldwin References: <4B6BD8B2.2060504@icyb.net.ua> <201002050936.08434.jhb@freebsd.org> In-Reply-To: <201002050936.08434.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpica in stable/8 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 14:45:27 -0000 on 05/02/2010 16:36 John Baldwin said the following: > On Friday 05 February 2010 3:37:06 am Andriy Gapon wrote: >> I would like to bring version of ACPICA in stable/8 to that of head, that is >> 20100121. >> >> Here's svn status and svn diff outputs for the merge: >> http://people.freebsd.org/~avg/stable-8-acpi.status.txt >> http://people.freebsd.org/~avg/stable-8-acpi.diff >> >> I've performed this MFC by doing series of svn merges first to sys, then to >> usr.sbin/acpi. I hope that this is a correct approach. >> I have some doubts because of heard suggestions that such merges should be done >> from vendor area. But, OTOH, in head there were direct commits sys to fix >> consequences of merge from vendor area. >> Subversion gurus, please advise! > > You should just MFC the changes from HEAD. You should not merge from the > vendor branch directly into a stable branch. The only time that would be > appropriate would be to merge a vendor change into a stable branch that > was never merged to HEAD (e.g. if some vendor software 'foo' was upgraded > from version 1 to version 2 in HEAD but was version 1 in a stable branch > and later a patch release 1.1 that fixed a security bug came out, then 1.1 > would be imported into the vendor area and directly merged to the stable > branch). Thanks a lot for the explanation! So, this is exactly what I did. I guess it should be OK to commit then, provided I haven't overlooked something else. -- Andriy Gapon