From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 20 11:08:09 2007 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 29D6C16A46B for ; Mon, 20 Aug 2007 11:08:09 +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 1460913C4B3 for ; Mon, 20 Aug 2007 11:08:09 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l7KB88OL087314 for ; Mon, 20 Aug 2007 11:08:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l7KB87sa087310 for freebsd-acpi@FreeBSD.org; Mon, 20 Aug 2007 11:08:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Aug 2007 11:08:07 GMT Message-Id: <200708201108.l7KB87sa087310@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 you 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, 20 Aug 2007 11:08:09 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 s i386/79080 acpi acpi thermal changes freezes HP nx6110 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/114113 acpi [patch] ACPI kernel panic during S3 suspend / resume o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. 13 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 o i386/72179 acpi [acpi] [patch] Inconsistent apm(8) output regarding th o kern/73823 acpi [feature request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/89411 acpi [acpi] acpiconf bug o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/111591 acpi [acpi] dev.acpi_ibm.0.events returns I/O error (regres o kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi Dell C810 - ACPI problem o kern/114722 acpi [acpi] [patch] Nearly duplicate p-state entries report 18 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 21 12:25:28 2007 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 6493316A420 for ; Tue, 21 Aug 2007 12:25:28 +0000 (UTC) (envelope-from william88@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id 37E7413C4A6 for ; Tue, 21 Aug 2007 12:25:28 +0000 (UTC) (envelope-from william88@gmail.com) Received: by wa-out-1112.google.com with SMTP id m33so1118227wag for ; Tue, 21 Aug 2007 05:25:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=Im6kGu7TvRTxPybkPerFGT7dpPz6RJ67f12sFhzXdVsQQZPmnPHKuVJldTaqYuWAIYBI8gyO+30t5fl4tc2uqrDjH2aM8yHLIQMdIPMOKLb85jX5gYfsDhAfyq7nhyxp8ZTKdQZt7v4w2JU+tTAxRdfRdtwg9roDRzv2vd0K3dY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Pcwp2z0aNcaIOImlADGvtDDkemLnGMXBlCsE8+WV1fkYleKO/4aikGKjSsktI/NDGHvJF0qVJJRGH0Z4NNnLsQ2dS3QWAqIrvxBSxkbMMu++cznzcQs0peHJKnKmkrPKawcVxzijI4AMTzPHuWhQUHG476jZa/ETX9OV0m5a4/Y= Received: by 10.115.54.1 with SMTP id g1mr3883949wak.1187697455317; Tue, 21 Aug 2007 04:57:35 -0700 (PDT) Received: by 10.114.111.4 with HTTP; Tue, 21 Aug 2007 04:57:35 -0700 (PDT) Message-ID: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> Date: Tue, 21 Aug 2007 08:57:35 -0300 From: "William Grzybowski" To: freebsd-acpi@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_107319_32415101.1187697455247" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: msk dev problem with acpi 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, 21 Aug 2007 12:25:28 -0000 ------=_Part_107319_32415101.1187697455247 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! I'm having a problem with my marvell yukon ethernet when i boot my -CURRENT with the ACPI enable, it goes fine when acpi is off... I already tried to talk with the msk driver developer and he has now idea why it is happening and told me to try something here... dmesg error: mskc0: irq 16 at device 0.0 on pci2 mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). mskc0: unknown device: id=0x00, rev=0x00 device_attach: mskc0 attach returned 6 the card: mskc0@pci2:0:0: class=0x020000 card=0x01101025 chip=0x435211ab rev=0x14 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Yukon 88E8038 PCI-E Fast Ethernet Controller' class = network subclass = ethernet I am also attaching the acpidump and dmesg , If it can't be a apci isue, please, let me know. Thanks. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR ------=_Part_107319_32415101.1187697455247-- From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 21 17:28:00 2007 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 9DB9616A420 for ; Tue, 21 Aug 2007 17:28:00 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id A255613C467 for ; Tue, 21 Aug 2007 17:27:59 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 20B5E619E69; Tue, 21 Aug 2007 10:27:57 -0700 (PDT) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30817-01; Tue, 21 Aug 2007 10:27:51 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id CB562619DBB; Tue, 21 Aug 2007 10:27:51 -0700 (PDT) Message-ID: <46CB2097.5000706@miralink.com> Date: Tue, 21 Aug 2007 10:27:51 -0700 From: Sean Bruno User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: William Grzybowski References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> In-Reply-To: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Aug 21 10:27:52 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 46cb2098311591542430122 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.488 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, AWL=0.011, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.488 X-Spam-Level: Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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, 21 Aug 2007 17:28:00 -0000 William Grzybowski wrote: > Hi! > > I'm having a problem with my marvell yukon ethernet when i boot my -CURRENT > with the ACPI enable, it goes fine when acpi is off... > I already tried to talk with the msk driver developer and he has now idea > why it is happening and told me to try something here... > > dmesg error: > mskc0: irq 16 at device 0.0 on pci2 > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > mskc0: unknown device: id=0x00, rev=0x00 > device_attach: mskc0 attach returned 6 > > the card: > mskc0@pci2:0:0: class=0x020000 card=0x01101025 chip=0x435211ab rev=0x14 > hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = 'Yukon 88E8038 PCI-E Fast Ethernet Controller' > class = network > subclass = ethernet > > I am also attaching the acpidump and dmesg , > If it can't be a apci isue, please, let me know. > > Thanks. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" > I don't see any attachments in this email. Can you try resending to the list? Sean From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 21 17:58:28 2007 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 77DCB16A41B for ; Tue, 21 Aug 2007 17:58:28 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4BE13C465 for ; Tue, 21 Aug 2007 17:58:27 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 8E827619CFB; Tue, 21 Aug 2007 10:58:26 -0700 (PDT) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02278-06; Tue, 21 Aug 2007 10:58:25 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id 79AFB619B85; Tue, 21 Aug 2007 10:58:25 -0700 (PDT) Message-ID: <46CB27C1.4090805@miralink.com> Date: Tue, 21 Aug 2007 10:58:25 -0700 From: Sean Bruno User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: Sean Bruno References: <46C37FBF.50004@miralink.com> In-Reply-To: <46C37FBF.50004@miralink.com> Content-Type: multipart/mixed; boundary="------------050205030600050006060406" X-Virus-Scanned: amavisd-new at Cc: freebsd-acpi@freebsd.org Subject: Re: Supermicro Boot Lockup with ACPI enabled 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, 21 Aug 2007 17:58:28 -0000 This is a multi-part message in MIME format. --------------050205030600050006060406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sean Bruno wrote: > I am using RELENG6_2 on a Supermicro 5015P-TR that has a model PDSMP-I > motherboard. It currently locks up when booting the system with ACPI > enabled in the BIOS and at the same time a card(I've tried an Adaptec > 29160, 29320 and a Qlogic F/C 2342) in either PCI-X slot. > > If I deselect ACPI in the BIOS, the system boots and all is well. If > I remove the expansion cards, I can boot with ACPI enabled and all is > well. I can then dump the DSDT to look for errors. I don't see > anything obvious and I'm not sure how to proceed. > > I'm looking to see how I can find the error in the DSDT and report it > to supermicro, but I can't see anything wrong with the tables that I > have attached to the email. There doesn't appear to be any updates to > the BIOS for this system either. Any ideas? > > Sean > ------------------------------------------------------------------------ I was able to dump the ACPI tables with a pci card inserted by disabling the driver for that card(in my case, the ISP driver). I still don't see any reason why FreeBSD 6.2 freezes when ACPI is enabled and a card is in the PCI-X slot. I have attached the full DSDT dump, hopefully someone can give me a clue here so I can get SuperMicro to fix their box? Sean --------------050205030600050006060406 Content-Type: text/plain; name="acpi.asl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi.asl" /* RSD PTR: OEM=PTLTD, ACPI_Rev=1.0x (0) RSDT=0x1fee3fa0, cksum=77 */ /* RSDT: Length=56, Revision=1, Checksum=132, OEMID=PTLTD, OEM Table ID= RSDT, OEM Revision=0x6040000, Creator ID= LTP, Creator Revision=0x0 Entries={ 0x1fee8ea8, 0x1fee8f1c, 0x1fee8f58, 0x1fee8fd8, 0x1fee3fd8 } */ /* FACP: Length=116, Revision=1, Checksum=94, OEMID=INTEL, OEM Table ID=, OEM Revision=0x6040000, Creator ID=PTL, Creator Revision=0x3 FACS=0x1fee9fc0, DSDT=0x1fee4392 INT_MODEL=PIC Preferred_PM_Profile=Unspecified (0) SCI_INT=9 SMI_CMD=0xb2, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0 PSTATE_CNT=0x80 PM1a_EVT_BLK=0x1000-0x1003 PM1a_CNT_BLK=0x1004-0x1005 PM2_CNT_BLK=0x1020-0x1020 PM_TMR_BLK=0x1008-0x100b GPE0_BLK=0x1028-0x102f P_LVL2_LAT=101 us, P_LVL3_LAT=1001 us FLUSH_SIZE=0, FLUSH_STRIDE=0 DUTY_OFFSET=1, DUTY_WIDTH=3 DAY_ALRM=13, MON_ALRM=0, CENTURY=50 IAPC_BOOT_ARCH= Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4} */ /* FACS: Length=64, HwSig=0x00000000, Firm_Wake_Vec=0x00000000 Global_Lock= Flags= Version=0 */ /* DSDT: Length=19222, Revision=1, Checksum=11, OEMID=INTEL, OEM Table ID=GLENWOOD, OEM Revision=0x6040000, Creator ID=MSFT, Creator Revision=0x100000e */ /* MCFG: Length=60, Revision=1, Checksum=78, OEMID=PTLTD, OEM Table ID= MCFG, OEM Revision=0x6040000, Creator ID= LTP, Creator Revision=0x0 Base Address= 0x00000000f0000000 Segment Group= 0x0000 Start Bus= 0 End Bus= 9 */ /* APIC: Length=128, Revision=1, Checksum=2, OEMID=PTLTD, OEM Table ID= APIC, OEM Revision=0x6040000, Creator ID= LTP, Creator Revision=0x0 Local APIC ADDR=0xfee00000 Flags={PC-AT} Type=Local APIC ACPI CPU=0 Flags={ENABLED} APIC ID=0 Type=Local APIC ACPI CPU=1 Flags={ENABLED} APIC ID=1 Type=IO APIC APIC ID=2 INT BASE=0 ADDR=0x00000000fec00000 Type=IO APIC APIC ID=3 INT BASE=24 ADDR=0x00000000fec80000 Type=IO APIC APIC ID=4 INT BASE=48 ADDR=0x00000000fec80400 Type=INT Override BUS=0 IRQ=0 INTR=2 Flags={Polarity=active-hi, Trigger=edge} Type=INT Override BUS=0 IRQ=9 INTR=9 Flags={Polarity=active-hi, Trigger=level} Type=Local NMI ACPI CPU=0 LINT Pin=1 Flags={Polarity=active-hi, Trigger=edge} Type=Local NMI ACPI CPU=1 LINT Pin=1 Flags={Polarity=active-hi, Trigger=edge} */ /* BOOT: Length=40, Revision=1, Checksum=164, OEMID=PTLTD, OEM Table ID=$SBFTBL$, OEM Revision=0x6040000, Creator ID= LTP, Creator Revision=0x1 */ /* SSDT: Length=954, Revision=1, Checksum=118, OEMID=PmRef, OEM Table ID=CpuPm, OEM Revision=0x3000, Creator ID=INTL, Creator Revision=0x20030224 */ /* * Intel ACPI Component Architecture * AML Disassembler version 20041119 * * Disassembly of /tmp/acpidump.Jf3Z24, Tue Aug 21 10:53:01 2007 */ DefinitionBlock ("DSDT.aml", "DSDT", 1, "INTEL", "GLENWOOD", 100925440) { OperationRegion (RCRB, SystemMemory, 0xFED1C000, 0x00004000) Field (RCRB, DWordAcc, Lock, Preserve) { Offset (0x1000), Offset (0x3000), Offset (0x3404), HPAS, 2, , 5, HPAE, 1, Offset (0x3418), , 1, PATD, 1, SATD, 1, SMBD, 1, AZAD, 1, A97D, 1 } Name (OSYS, 0x00) Scope (_GPE) { Method (_L03, 0, NotSerialized) { Store (0x03, DEBG) Notify (\_SB.PCI0.USB1, 0x02) } Method (_L04, 0, NotSerialized) { Store (0x04, DEBG) Notify (\_SB.PCI0.USB2, 0x02) } Method (_L08, 0, NotSerialized) { Store (0x08, DEBG) Notify (\_SB.PCI0.LPC0.SIO.COM1, 0x02) Notify (\_SB.PCI0.LPC0.SIO.COM2, 0x02) Notify (\_SB.PCI0.PWRB, 0x02) } Method (_L09, 0, NotSerialized) { Store (0x09, DEBG) Notify (\_SB.PCI0.EXP1, 0x02) Notify (\_SB.PCI0.EXP5, 0x02) Notify (\_SB.PCI0.EXP6, 0x02) } Method (_L0B, 0, NotSerialized) { Store (0x0B, DEBG) Notify (\_SB.PCI0.DEV1.PXHA, 0x02) Notify (\_SB.PCI0.DEV1.PXHB, 0x02) Notify (\_SB.PCI0.PCIB, 0x02) } Method (_L0C, 0, NotSerialized) { Store (0x0C, DEBG) Notify (\_SB.PCI0.USB3, 0x02) } Method (_L0D, 0, NotSerialized) { Store (0x0D, DEBG) Notify (\_SB.PCI0.EUSB, 0x02) } Method (_L0E, 0, NotSerialized) { Store (0x0E, DEBG) Notify (\_SB.PCI0.USB4, 0x02) } Method (_L1D, 0, NotSerialized) { Notify (\_SB.PCI0.LPC0.SIO.KBC0, 0x02) Notify (\_SB.PCI0.LPC0.SIO.MSE0, 0x02) } } Scope (_PR) { Processor (CPU0, 0x00, 0x00001010, 0x06) {} Processor (CPU1, 0x01, 0x00001010, 0x06) {} Processor (CPU2, 0x02, 0x00001010, 0x06) {} Processor (CPU3, 0x03, 0x00001010, 0x06) {} } Scope (_SB) { Device (PCI0) { Method (_INI, 0, NotSerialized) { } Name (_HID, EisaId ("PNP0A03")) Name (_BBN, 0x00) Name (_ADR, 0x00) OperationRegion (REGS, PCI_Config, 0x40, 0xC0) Field (REGS, ByteAcc, NoLock, Preserve) { Offset (0x50), PAM0, 8, PAM1, 8, PAM2, 8, PAM3, 8, PAM4, 8, PAM5, 8, PAM6, 8, , 7, HEN, 1, Offset (0x5C), Z000, 8 } OperationRegion (DRBS, SystemMemory, 0xFED14000, 0x00004000) Field (DRBS, DWordAcc, Lock, Preserve) { Offset (0x100), Z001, 8, Z002, 8, Z003, 8, Z004, 8, Offset (0x180), Z005, 8, Z006, 8, Z007, 8, Z008, 8 } Name (RSRC, ResourceTemplate () { WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode, 0x0000, 0x0000, 0x00FF, 0x0000, 0x0100, 0x00) IO (Decode16, 0x0CF8, 0x0CF8, 0x01, 0x08) DWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, 0x00000000, 0x00000CF7, 0x00000000, 0x00000CF8, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000A0000, 0x000BFFFF, 0x00000000, 0x00020000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000C0000, 0x000C3FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000C4000, 0x000C7FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000C8000, 0x000CBFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000CC000, 0x000CFFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000D0000, 0x000D3FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000D4000, 0x000D7FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000D8000, 0x000DBFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000DC000, 0x000DFFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000E0000, 0x000E3FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000E4000, 0x000E7FFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000E8000, 0x000EBFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000EC000, 0x000EFFFF, 0x00000000, 0x00004000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x000F0000, 0x000FFFFF, 0x00000000, 0x00010000, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00) DWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange, 0x00000000, 0x00000D00, 0x0000FDFF, 0x00000000, 0x0000F100, 0x00) DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00) }) Method (_CRS, 0, Serialized) { Store (Zero, Local1) CreateDWordField (RSRC, 0x01B8, BTMN) CreateDWordField (RSRC, 0x01BC, BTMX) CreateDWordField (RSRC, 0x01C4, BTLN) ShiftLeft (And (Z000, 0xF8), 0x18, BTMN) Subtract (0xF0000000, BTMN, BTLN) Subtract (Add (BTMN, BTLN), 0x01, BTMX) CreateBitField (RSRC, 0x02A0, C0RW) CreateDWordField (RSRC, 0x59, C0MN) CreateDWordField (RSRC, 0x5D, C0MX) CreateDWordField (RSRC, 0x65, C0LN) Store (One, C0RW) If (LEqual (And (PAM1, 0x03), 0x01)) { Store (Zero, C0RW) } Store (Zero, C0LN) If (LNot (And (PAM1, 0x03))) { Store (0x4000, C0LN) } CreateBitField (RSRC, 0x0378, C4RW) CreateDWordField (RSRC, 0x74, C4MN) CreateDWordField (RSRC, 0x78, C4MX) CreateDWordField (RSRC, 0x80, C4LN) Store (One, C4RW) If (LEqual (And (PAM1, 0x30), 0x10)) { Store (Zero, C4RW) } Store (Zero, C4LN) If (LNot (And (PAM1, 0x30))) { Store (0x4000, C4LN) } CreateBitField (RSRC, 0x0450, C8RW) CreateDWordField (RSRC, 0x8F, C8MN) CreateDWordField (RSRC, 0x93, C8MX) CreateDWordField (RSRC, 0x9B, C8LN) Store (One, C8RW) If (LEqual (And (PAM2, 0x03), 0x01)) { Store (Zero, C8RW) } Store (Zero, C8LN) If (LNot (And (PAM2, 0x03))) { Store (0x4000, C8LN) } CreateBitField (RSRC, 0x0528, CCRW) CreateDWordField (RSRC, 0xAA, CCMN) CreateDWordField (RSRC, 0xAE, CCMX) CreateDWordField (RSRC, 0xB6, CCLN) Store (One, CCRW) If (LEqual (And (PAM2, 0x30), 0x10)) { Store (Zero, CCRW) } Store (Zero, CCLN) If (LNot (And (PAM2, 0x30))) { Store (0x4000, CCLN) } CreateBitField (RSRC, 0x0600, D0RW) CreateDWordField (RSRC, 0xC5, D0MN) CreateDWordField (RSRC, 0xC9, D0MX) CreateDWordField (RSRC, 0xD1, D0LN) Store (One, D0RW) If (LEqual (And (PAM3, 0x03), 0x01)) { Store (Zero, D0RW) } Store (Zero, D0LN) If (LNot (And (PAM3, 0x03))) { Store (0x4000, D0LN) } CreateBitField (RSRC, 0x06D8, D4RW) CreateDWordField (RSRC, 0xE0, D4MN) CreateDWordField (RSRC, 0xE4, D4MX) CreateDWordField (RSRC, 0xEC, D4LN) Store (One, D4RW) If (LEqual (And (PAM3, 0x30), 0x10)) { Store (Zero, D4RW) } Store (Zero, D4LN) If (LNot (And (PAM3, 0x30))) { Store (0x4000, D4LN) } CreateBitField (RSRC, 0x07B0, D8RW) CreateDWordField (RSRC, 0xFB, D8MN) CreateDWordField (RSRC, 0xFF, D8MX) CreateDWordField (RSRC, 0x0107, D8LN) Store (One, D8RW) If (LEqual (And (PAM4, 0x03), 0x01)) { Store (Zero, D8RW) } Store (Zero, D8LN) If (LNot (And (PAM4, 0x03))) { Store (0x4000, D8LN) } CreateBitField (RSRC, 0x0888, DCRW) CreateDWordField (RSRC, 0x0116, DCMN) CreateDWordField (RSRC, 0x011A, DCMX) CreateDWordField (RSRC, 0x0122, DCLN) Store (One, DCRW) If (LEqual (And (PAM4, 0x30), 0x10)) { Store (Zero, DCRW) } Store (Zero, DCLN) If (LNot (And (PAM4, 0x30))) { Store (0x4000, DCLN) } CreateBitField (RSRC, 0x0960, E0RW) CreateDWordField (RSRC, 0x0131, E0MN) CreateDWordField (RSRC, 0x0135, E0MX) CreateDWordField (RSRC, 0x013D, E0LN) Store (One, E0RW) If (LEqual (And (PAM5, 0x03), 0x01)) { Store (Zero, E0RW) } Store (Zero, E0LN) If (LNot (And (PAM5, 0x03))) { Store (0x4000, E0LN) } CreateBitField (RSRC, 0x0A38, E4RW) CreateDWordField (RSRC, 0x014C, E4MN) CreateDWordField (RSRC, 0x0150, E4MX) CreateDWordField (RSRC, 0x0158, E4LN) Store (One, E4RW) If (LEqual (And (PAM5, 0x30), 0x10)) { Store (Zero, E4RW) } Store (Zero, E4LN) If (LNot (And (PAM5, 0x30))) { Store (0x4000, E4LN) } CreateBitField (RSRC, 0x0B10, E8RW) CreateDWordField (RSRC, 0x0167, E8MN) CreateDWordField (RSRC, 0x016B, E8MX) CreateDWordField (RSRC, 0x0173, E8LN) Store (One, E8RW) If (LEqual (And (PAM6, 0x03), 0x01)) { Store (Zero, E8RW) } Store (Zero, E8LN) If (LNot (And (PAM6, 0x03))) { Store (0x4000, E8LN) } CreateBitField (RSRC, 0x0BE8, ECRW) CreateDWordField (RSRC, 0x0182, ECMN) CreateDWordField (RSRC, 0x0186, ECMX) CreateDWordField (RSRC, 0x018E, ECLN) Store (One, ECRW) If (LEqual (And (PAM6, 0x30), 0x10)) { Store (Zero, ECRW) } Store (Zero, ECLN) If (LNot (And (PAM6, 0x30))) { Store (0x4000, ECLN) } CreateBitField (RSRC, 0x0CC0, F0RW) CreateDWordField (RSRC, 0x019D, F0MN) CreateDWordField (RSRC, 0x01A1, F0MX) CreateDWordField (RSRC, 0x01A9, F0LN) Store (One, F0RW) If (LEqual (And (PAM0, 0x30), 0x10)) { Store (Zero, F0RW) } Store (Zero, F0LN) If (LNot (And (PAM0, 0x30))) { Store (0x00010000, F0LN) } If (HPAE) { CreateDWordField (RSRC, 0x01EE, M2MN) CreateDWordField (RSRC, 0x01F2, M2MX) CreateDWordField (RSRC, 0x01FA, M2LN) Store (0xFED00000, M2MN) Store (0xFED003FF, M2MX) Store (0x0400, M2LN) If (LEqual (HPAS, 0x01)) { Store (0xFED01000, M2MN) Store (0xFED013FF, M2MX) } If (LEqual (HPAS, 0x02)) { Store (0xFED02000, M2MN) Store (0xFED023FF, M2MX) } If (LEqual (HPAS, 0x03)) { Store (0xFED03000, M2MN) Store (0xFED033FF, M2MX) } } Return (RSRC) } Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x0C) { Package (0x04) { 0x0001FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x001CFFFF, 0x00, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0x001CFFFF, 0x01, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x001CFFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x001CFFFF, 0x03, \_SB.PCI0.LPC0.LNKD, 0x00 }, Package (0x04) { 0x001DFFFF, 0x00, \_SB.PCI0.LPC0.LNKH, 0x00 }, Package (0x04) { 0x001DFFFF, 0x01, \_SB.PCI0.LPC0.LNKD, 0x00 }, Package (0x04) { 0x001DFFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x001DFFFF, 0x03, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x001FFFFF, 0x00, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x001FFFFF, 0x01, \_SB.PCI0.LPC0.LNKD, 0x00 }, Package (0x04) { 0x001FFFFF, 0x03, \_SB.PCI0.LPC0.LNKA, 0x00 } }) } Else { Return (Package (0x0C) { Package (0x04) { 0x0001FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x001CFFFF, 0x00, 0x00, 0x11 }, Package (0x04) { 0x001CFFFF, 0x01, 0x00, 0x10 }, Package (0x04) { 0x001CFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0x001CFFFF, 0x03, 0x00, 0x13 }, Package (0x04) { 0x001DFFFF, 0x00, 0x00, 0x17 }, Package (0x04) { 0x001DFFFF, 0x01, 0x00, 0x13 }, Package (0x04) { 0x001DFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0x001DFFFF, 0x03, 0x00, 0x10 }, Package (0x04) { 0x001FFFFF, 0x00, 0x00, 0x12 }, Package (0x04) { 0x001FFFFF, 0x01, 0x00, 0x13 }, Package (0x04) { 0x001FFFFF, 0x03, 0x00, 0x10 } }) } } Method (_S3D, 0, NotSerialized) { Return (0x02) } Method (_S4D, 0, NotSerialized) { Return (0x02) } Device (DEV1) { Name (_ADR, 0x00010000) Device (PXHA) { Name (_ADR, 0x00) Name (_PRW, Package (0x02) { 0x0B, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x06) { Package (0x04) { 0x0005FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0005FFFF, 0x01, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0x0005FFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x0005FFFF, 0x03, \_SB.PCI0.LPC0.LNKD, 0x00 }, Package (0x04) { 0x0006FFFF, 0x00, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x0006FFFF, 0x01, \_SB.PCI0.LPC0.LNKD, 0x00 } }) } Else { Return (Package (0x06) { Package (0x04) { 0x0005FFFF, 0x00, 0x00, 0x18 }, Package (0x04) { 0x0005FFFF, 0x01, 0x00, 0x19 }, Package (0x04) { 0x0005FFFF, 0x02, 0x00, 0x1A }, Package (0x04) { 0x0005FFFF, 0x03, 0x00, 0x1B }, Package (0x04) { 0x0006FFFF, 0x00, 0x00, 0x1A }, Package (0x04) { 0x0006FFFF, 0x01, 0x00, 0x1B } }) } } } Device (PXHB) { Name (_ADR, 0x02) Name (_PRW, Package (0x02) { 0x0B, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x04) { Package (0x04) { 0x0002FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0002FFFF, 0x01, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0x0002FFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0x0002FFFF, 0x03, \_SB.PCI0.LPC0.LNKD, 0x00 } }) } Else { Return (Package (0x04) { Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x30 }, Package (0x04) { 0x0002FFFF, 0x01, 0x00, 0x31 }, Package (0x04) { 0x0002FFFF, 0x02, 0x00, 0x32 }, Package (0x04) { 0x0002FFFF, 0x03, 0x00, 0x33 } }) } } } } Device (EXP1) { Name (_ADR, 0x001C0000) Name (_PRW, Package (0x02) { 0x09, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPC0.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPC0.LNKD, 0x00 } }) } Else { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x11 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x13 } }) } } } Device (EXP5) { Name (_ADR, 0x001C0004) Name (_PRW, Package (0x02) { 0x09, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x01) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 } }) } Else { Return (Package (0x01) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x10 } }) } } } Device (EXP6) { Name (_ADR, 0x001C0005) Name (_PRW, Package (0x02) { 0x09, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x01) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPC0.LNKB, 0x00 } }) } Else { Return (Package (0x01) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x11 } }) } } } Device (PCIB) { Name (_ADR, 0x001E0000) Name (_PRW, Package (0x02) { 0x0B, 0x05 }) Method (_PRT, 0, NotSerialized) { If (LNot (\PICF)) { Return (Package (0x03) { Package (0x04) { 0x0002FFFF, 0x00, \_SB.PCI0.LPC0.LNKA, 0x00 }, Package (0x04) { 0x0002FFFF, 0x01, \_SB.PCI0.LPC0.LNKB, 0x00 }, Package (0x04) { 0x0001FFFF, 0x00, \_SB.PCI0.LPC0.LNKC, 0x00 } }) } Else { Return (Package (0x03) { Package (0x04) { 0x0002FFFF, 0x00, 0x00, 0x10 }, Package (0x04) { 0x0002FFFF, 0x01, 0x00, 0x11 }, Package (0x04) { 0x0001FFFF, 0x00, 0x00, 0x12 } }) } } } Device (LPC0) { Name (_ADR, 0x001F0000) Name (DVEN, 0x00) Method (DECD, 4, Serialized) { Store (Arg0, Debug) } Device (MBRD) { Name (_HID, EisaId ("PNP0C02")) Name (_UID, 0x1F) Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0010, 0x0010, 0x01, 0x10) IO (Decode16, 0x0024, 0x0024, 0x01, 0x02) IO (Decode16, 0x0028, 0x0028, 0x01, 0x02) IO (Decode16, 0x002C, 0x002C, 0x01, 0x02) IO (Decode16, 0x0030, 0x0030, 0x01, 0x02) IO (Decode16, 0x0034, 0x0034, 0x01, 0x02) IO (Decode16, 0x0038, 0x0038, 0x01, 0x02) IO (Decode16, 0x003C, 0x003C, 0x01, 0x02) IO (Decode16, 0x0072, 0x0072, 0x01, 0x06) IO (Decode16, 0x0080, 0x0080, 0x01, 0x01) IO (Decode16, 0x0090, 0x0090, 0x01, 0x10) IO (Decode16, 0x00A4, 0x00A4, 0x01, 0x02) IO (Decode16, 0x00A8, 0x00A8, 0x01, 0x02) IO (Decode16, 0x00AC, 0x00AC, 0x01, 0x02) IO (Decode16, 0x00B0, 0x00B0, 0x01, 0x06) IO (Decode16, 0x00B8, 0x00B8, 0x01, 0x02) IO (Decode16, 0x00BC, 0x00BC, 0x01, 0x02) IO (Decode16, 0x0295, 0x0295, 0x01, 0x02) IO (Decode16, 0x0800, 0x0800, 0x01, 0x40) IO (Decode16, 0x0900, 0x0900, 0x01, 0x10) IO (Decode16, 0x1000, 0x1000, 0x01, 0x80) IO (Decode16, 0x1180, 0x1180, 0x01, 0x40) IO (Decode16, 0x002E, 0x002E, 0x01, 0x02) IO (Decode16, 0x04D0, 0x04D0, 0x01, 0x02) IO (Decode16, 0xFE00, 0xFE00, 0x01, 0x01) Memory32Fixed (ReadWrite, 0xFED14000, 0x00004000) Memory32Fixed (ReadWrite, 0xFED13000, 0x00001000) Memory32Fixed (ReadWrite, 0xFED18000, 0x00004000) Memory32Fixed (ReadWrite, 0xF0000000, 0x04000000) Memory32Fixed (ReadWrite, 0xFED20000, 0x00070000) Memory32Fixed (ReadWrite, 0xFEF00000, 0x00100000) }) Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0xA2, PMMN) CreateWordField (RSRC, 0xA4, PMMX) And (^^PMBA, 0xFF80, PMMN) Store (PMMN, PMMX) CreateWordField (RSRC, 0xAA, GPMN) CreateWordField (RSRC, 0xAC, GPMX) And (^^GPBA, 0xFF80, GPMN) Store (GPMN, GPMX) Return (RSRC) } } Device (DMAC) { Name (_HID, EisaId ("PNP0200")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x10) IO (Decode16, 0x0081, 0x0081, 0x01, 0x0F) IO (Decode16, 0x00C0, 0x00C0, 0x01, 0x20) DMA (Compatibility, NotBusMaster, Transfer16) {4} }) } Device (MATH) { Name (_HID, EisaId ("PNP0C04")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x00F0, 0x00F0, 0x01, 0x0F) IRQ (Edge, ActiveHigh, Exclusive) {13} }) } Device (PIC) { Name (_HID, EisaId ("PNP0000")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0020, 0x0020, 0x01, 0x02) IO (Decode16, 0x00A0, 0x00A0, 0x01, 0x02) IRQ (Edge, ActiveHigh, Exclusive) {2} }) } Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (BUF0, ResourceTemplate () { IO (Decode16, 0x0070, 0x0070, 0x01, 0x02) }) Name (BUF1, ResourceTemplate () { IO (Decode16, 0x0070, 0x0070, 0x01, 0x02) IRQNoFlags () {8} }) Method (_CRS, 0, Serialized) { If (HPAE) { Return (BUF0) } Return (BUF1) } } Device (SPKR) { Name (_HID, EisaId ("PNP0800")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0061, 0x0061, 0x01, 0x01) }) } Device (TIMR) { Name (_HID, EisaId ("PNP0100")) Name (BUF0, ResourceTemplate () { IO (Decode16, 0x0040, 0x0040, 0x01, 0x04) IO (Decode16, 0x0050, 0x0050, 0x10, 0x04) }) Name (BUF1, ResourceTemplate () { IO (Decode16, 0x0040, 0x0040, 0x01, 0x04) IO (Decode16, 0x0050, 0x0050, 0x10, 0x04) IRQNoFlags () {0} }) Method (_CRS, 0, Serialized) { If (HPAE) { Return (BUF0) } Return (BUF1) } } Device (MMTM) { Name (_HID, EisaId ("PNP0103")) Name (BUF0, ResourceTemplate () { IRQNoFlags () {0} IRQNoFlags () {8} Memory32Fixed (ReadOnly, 0xFED00000, 0x00000400) }) Method (_STA, 0, NotSerialized) { If (LNot (LLess (OSYS, 0x07D1))) { If (HPAE) { Return (0x0F) } } Else { If (HPAE) { Return (0x0B) } } Return (0x00) } Method (_CRS, 0, Serialized) { If (HPAE) { CreateDWordField (BUF0, 0x0A, HPT0) If (LEqual (HPAS, 0x01)) { Store (0xFED01000, HPT0) } If (LEqual (HPAS, 0x02)) { Store (0xFED02000, HPT0) } If (LEqual (HPAS, 0x03)) { Store (0xFED03000, HPT0) } } Return (BUF0) } } Device (LNKA) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x01) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRA, 0x80, PIRA) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRA, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Store (RSRC, Debug) Return (RSRC) } Method (_SRS, 1, NotSerialized) { Store (Arg0, Debug) CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRA, 0x70), PIRA) } Method (_STA, 0, NotSerialized) { If (And (PIRA, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKB) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x02) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRB, 0x80, PIRB) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRB, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRB, 0x70), PIRB) } Method (_STA, 0, NotSerialized) { If (And (PIRB, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKC) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x03) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRC, 0x80, PIRC) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRC, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRC, 0x70), PIRC) } Method (_STA, 0, NotSerialized) { If (And (PIRC, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKD) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x04) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRD, 0x80, PIRD) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRD, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Return (RSRC) } Method (_SRS, 1, NotSerialized) { CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRD, 0x70), PIRD) } Method (_STA, 0, NotSerialized) { If (And (PIRD, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKE) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x05) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRE, 0x80, PIRE) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRE, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Store (RSRC, Debug) Return (RSRC) } Method (_SRS, 1, NotSerialized) { Store (Arg0, Debug) CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRE, 0x70), PIRE) } Method (_STA, 0, NotSerialized) { If (And (PIRE, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKF) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x06) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRF, 0x80, PIRF) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRF, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Store (RSRC, Debug) Return (RSRC) } Method (_SRS, 1, NotSerialized) { Store (Arg0, Debug) CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRF, 0x70), PIRF) } Method (_STA, 0, NotSerialized) { If (And (PIRF, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKG) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x07) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRG, 0x80, PIRG) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRG, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Store (RSRC, Debug) Return (RSRC) } Method (_SRS, 1, NotSerialized) { Store (Arg0, Debug) CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRG, 0x70), PIRG) } Method (_STA, 0, NotSerialized) { If (And (PIRG, 0x80)) { Return (0x09) } Return (0x0B) } } Device (LNKH) { Name (_HID, EisaId ("PNP0C0F")) Name (_UID, 0x08) Name (_PRS, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {3,10,11,14,15} }) Name (RSRC, ResourceTemplate () { IRQ (Level, ActiveLow, Shared) {} }) Method (_DIS, 0, NotSerialized) { Or (PIRH, 0x80, PIRH) } Method (_CRS, 0, NotSerialized) { CreateWordField (RSRC, 0x01, IRQ0) And (PIRH, 0x0F, Local0) ShiftLeft (0x01, Local0, IRQ0) Store (RSRC, Debug) Return (RSRC) } Method (_SRS, 1, NotSerialized) { Store (Arg0, Debug) CreateWordField (Arg0, 0x01, IRQ0) FindSetRightBit (IRQ0, Local0) Decrement (Local0) Or (Local0, And (PIRH, 0x70), PIRH) } Method (_STA, 0, NotSerialized) { If (And (PIRH, 0x80)) { Return (0x09) } Return (0x0B) } } OperationRegion (GPOX, SystemIO, 0x1180, 0x30) Field (GPOX, DWordAcc, NoLock, Preserve) { Offset (0x07), , 3, IO27, 1, Offset (0x0F), , 3, LV27, 1, Offset (0x1B), , 3, BL27, 1 } OperationRegion (PIRX, PCI_Config, 0x60, 0x04) Field (PIRX, DWordAcc, Lock, Preserve) { AccessAs (ByteAcc, 0x00), PIRA, 8, PIRB, 8, PIRC, 8, PIRD, 8 } OperationRegion (PIRY, PCI_Config, 0x68, 0x04) Field (PIRY, DWordAcc, Lock, Preserve) { AccessAs (ByteAcc, 0x00), PIRE, 8, PIRF, 8, PIRG, 8, PIRH, 8 } OperationRegion (ELR0, PCI_Config, 0xA0, 0x14) Field (ELR0, DWordAcc, Lock, Preserve) { , 9, PBLV, 1, Offset (0x10), , 1, ELSS, 1, , 1, ELST, 1, ELPB, 1, Offset (0x11), , 1, ELLO, 1, ELGN, 2, ELYL, 2, ELBE, 1, ELIE, 1, ELSN, 1, ELOC, 1, Offset (0x13), ELSO, 1 } OperationRegion (ROUT, SystemIO, 0xB8, 0x04) Field (ROUT, DWordAcc, Lock, Preserve) { AccessAs (ByteAcc, 0x00), GPI0, 2, GPI1, 2, GPI2, 2, GPI3, 2, GPI4, 2, GPI5, 2, GPI6, 2, GPI7, 2, GPI8, 2, GPI9, 2, GP10, 2, GP11, 2, GP12, 2, GP13, 2, GP14, 2, GP15, 2 } OperationRegion (PMIO, SystemIO, 0x1000, 0x30) Field (PMIO, WordAcc, NoLock, Preserve) { AccessAs (DWordAcc, 0x00), Offset (0x2D), , 4, GPES, 1, Offset (0x2F), , 4, GPEE, 1 } OperationRegion (REGS, PCI_Config, 0x40, 0x10) Field (REGS, DWordAcc, Lock, Preserve) { PMBA, 16, Offset (0x08), GPBA, 16 } Device (FWH) { Name (_HID, EisaId ("INT0800")) Name (_CRS, ResourceTemplate () { Memory32Fixed (ReadOnly, 0xFF800000, 0x00800000) }) } Device (SIO) { Name (_HID, EisaId ("PNP0A05")) Mutex (W627, 0x00) OperationRegion (SIBP, SystemIO, 0x2E, 0x02) Field (SIBP, ByteAcc, NoLock, Preserve) { BPIO, 8 } OperationRegion (SIIO, SystemIO, 0x2E, 0x02) Field (SIIO, ByteAcc, NoLock, Preserve) { INDX, 8, DATA, 8 } IndexField (INDX, DATA, ByteAcc, NoLock, Preserve) { Offset (0x07), LDN, 8, Offset (0x22), POW, 8, Offset (0x30), ACT, 1, Offset (0x60), IOBH, 8, IOBL, 8, IO2H, 8, IO2L, 8, Offset (0x70), INT, 4, Offset (0x74), DMAS, 3, Offset (0xE0), Z009, 8, Offset (0xE4), Z00A, 8, Offset (0xF0), MODE, 3, Offset (0xF1), , 3, IRMD, 3, Offset (0xF3), , 6, SLED, 2, Offset (0xF5), , 6, PLED, 2 } Method (CFG, 1, NotSerialized) { Store (0x87, BPIO) Store (0x87, BPIO) Store (Arg0, LDN) } Method (XCFG, 0, NotSerialized) { Store (0xAA, BPIO) } Method (STA, 1, NotSerialized) { Acquire (W627, 0x5000) CFG (Arg0) Store (0x00, Local1) If (ACT) { Store (0x0F, Local1) } Else { If (LOr (IOBH, IOBL)) { Store (0x0D, Local1) } } XCFG () Release (W627) Return (Local1) } Method (DIS, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (Arg0) Store (0x00, ACT) XCFG () Release (W627) Return (0x00) } Method (PS0, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (Arg0) Store (0x01, ACT) XCFG () Release (W627) Return (0x00) } Method (PS3, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (Arg0) Store (0x00, ACT) XCFG () Release (W627) Return (0x00) } Device (KBC0) { Name (_HID, EisaId ("PNP0303")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0060, 0x0060, 0x01, 0x01) IO (Decode16, 0x0064, 0x0064, 0x01, 0x01) IRQ (Edge, ActiveHigh, Exclusive) {1} }) Name (_PRW, Package (0x02) { 0x1D, 0x01 }) } Device (MSE0) { Name (_HID, EisaId ("PNP0F13")) Name (_CRS, ResourceTemplate () { IRQ (Edge, ActiveHigh, Exclusive) {12} }) Name (_PRW, Package (0x02) { 0x1D, 0x01 }) } Device (COM1) { Name (_HID, EisaId ("PNP0501")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { Store (STA (0x02), Local1) Return (Local1) } Method (_DIS, 0, NotSerialized) { DIS (0x02) } Method (_CRS, 0, NotSerialized) { Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x08, 0x08) IRQNoFlags () {} }) CreateByteField (RSRC, 0x02, IO1) CreateByteField (RSRC, 0x03, IO2) CreateByteField (RSRC, 0x04, IO3) CreateByteField (RSRC, 0x05, IO4) CreateWordField (RSRC, 0x09, IRQV) Acquire (W627, 0x1388) CFG (0x02) If (ACT) { Store (IOBL, IO1) Store (IOBH, IO2) Store (IOBL, IO3) Store (IOBH, IO4) Store (0x01, Local0) ShiftLeft (Local0, INT, IRQV) } XCFG () Release (W627) Return (RSRC) } Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFnNoPri () { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IO1) CreateByteField (Arg0, 0x03, IO2) CreateWordField (Arg0, 0x09, IRQV) Acquire (W627, 0x1388) CFG (0x02) Store (IO1, IOBL) Store (IO2, IOBH) FindSetRightBit (IRQV, Local0) Subtract (Local0, 0x01, INT) Store (0x01, ACT) XCFG () Release (W627) } Method (_PS0, 0, NotSerialized) { PS0 (0x02) } Method (_PS3, 0, NotSerialized) { PS3 (0x02) } } Device (COM2) { Method (_HID, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x03) If (LAnd (IRMD, 0x38)) { Store (0x1005D041, Local1) } Else { Store (0x0105D041, Local1) } XCFG () Release (W627) Return (Local1) } Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { Store (STA (0x03), Local1) Return (Local1) } Method (_DIS, 0, NotSerialized) { DIS (0x03) } Method (_CRS, 0, NotSerialized) { Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x08, 0x08) IRQNoFlags () {} }) CreateByteField (RSRC, 0x02, IO1) CreateByteField (RSRC, 0x03, IO2) CreateByteField (RSRC, 0x04, IO3) CreateByteField (RSRC, 0x05, IO4) CreateWordField (RSRC, 0x09, IRQV) Acquire (W627, 0x1388) CFG (0x03) If (ACT) { Store (IOBL, IO1) Store (IOBH, IO2) Store (IOBL, IO3) Store (IOBH, IO4) Store (0x01, Local0) ShiftLeft (Local0, INT, IRQV) } XCFG () Release (W627) Return (RSRC) } Name (_PRS, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFn (0x00, 0x00) { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFnNoPri () { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFnNoPri () { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x03F8, 0x03F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x02F8, 0x02F8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x03E8, 0x03E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {3} } StartDependentFn (0x02, 0x02) { IO (Decode16, 0x02E8, 0x02E8, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {4} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IO1) CreateByteField (Arg0, 0x03, IO2) CreateWordField (Arg0, 0x09, IRQV) Acquire (W627, 0x1388) CFG (0x03) Store (IO1, IOBL) Store (IO2, IOBH) FindSetRightBit (IRQV, Local0) Subtract (Local0, 0x01, INT) Store (0x01, ACT) XCFG () Release (W627) } Method (_PS0, 0, NotSerialized) { PS0 (0x03) } Method (_PS3, 0, NotSerialized) { PS3 (0x03) } } Device (FDC) { Name (_HID, EisaId ("PNP0700")) Name (_UID, 0x01) Method (_STA, 0, NotSerialized) { Store (STA (0x00), Local1) Return (Local1) } Method (_DIS, 0, NotSerialized) { DIS (0x00) } Method (_CRS, 0, NotSerialized) { Name (RSRC, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x06) IO (Decode16, 0x0000, 0x0000, 0x01, 0x01) IRQNoFlags () {} DMA (Compatibility, NotBusMaster, Transfer8) {} }) Acquire (W627, 0x1388) CFG (0x00) If (ACT) { CreateByteField (RSRC, 0x02, IO1) CreateByteField (RSRC, 0x03, IO2) CreateByteField (RSRC, 0x04, IO3) CreateByteField (RSRC, 0x05, IO4) CreateByteField (RSRC, 0x0A, IO5) CreateByteField (RSRC, 0x0B, IO6) CreateByteField (RSRC, 0x0C, IO7) CreateByteField (RSRC, 0x0D, IO8) CreateWordField (RSRC, 0x11, IRQV) CreateByteField (RSRC, 0x14, DMAV) Store (IOBL, IO1) Store (IOBH, IO2) Store (IOBL, IO3) Store (IOBH, IO4) Add (IOBL, 0x07, IO5) Store (IOBH, IO6) Add (IOBL, 0x07, IO7) Store (IOBH, IO8) Store (0x01, Local0) ShiftLeft (Local0, INT, IRQV) Store (0x01, Local0) ShiftLeft (Local0, DMAS, DMAV) } XCFG () Release (W627) Return (RSRC) } Name (_PRS, ResourceTemplate () { StartDependentFn (0x00, 0x00) { IO (Decode16, 0x03F0, 0x03F0, 0x01, 0x06) IO (Decode16, 0x03F7, 0x03F7, 0x01, 0x01) IRQ (Edge, ActiveHigh, Exclusive) {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} } StartDependentFn (0x00, 0x00) { IO (Decode16, 0x0370, 0x0370, 0x01, 0x06) IO (Decode16, 0x0377, 0x0377, 0x01, 0x01) IRQ (Edge, ActiveHigh, Exclusive) {6} DMA (Compatibility, NotBusMaster, Transfer8) {2} } EndDependentFn () }) Method (_SRS, 1, NotSerialized) { CreateByteField (Arg0, 0x02, IO1) CreateByteField (Arg0, 0x03, IO2) CreateWordField (Arg0, 0x11, IRQV) CreateByteField (Arg0, 0x14, DMAV) Acquire (W627, 0x1388) CFG (0x00) Store (IO1, IOBL) Store (IO2, IOBH) FindSetRightBit (IRQV, Local0) Subtract (Local0, 0x01, INT) FindSetRightBit (DMAV, Local0) Subtract (Local0, 0x01, DMAS) Store (0x01, ACT) XCFG () Release (W627) } Method (_PS0, 0, NotSerialized) { PS0 (0x00) } Method (_PS3, 0, NotSerialized) { PS3 (0x00) } } Device (PRT) { Method (_HID, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x01) If (LEqual (MODE, 0x02)) { Store (0x0104D041, Local1) } Else { Store (0x0004D041, Local1) } XCFG () Release (W627) Return (Local1) } Name (_UID, 0x02) Method (_STA, 0, NotSerialized) { Store (STA (0x01), Local1) Return (Local1) } Method (_DIS, 0, NotSerialized) { DIS (0x01) } Method (_CRS, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x01) Name (CRSA, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x08) IRQNoFlags () {} }) CreateByteField (CRSA, 0x02, IOA1) CreateByteField (CRSA, 0x03, IOA2) CreateByteField (CRSA, 0x04, IOA3) CreateByteField (CRSA, 0x05, IOA4) CreateByteField (CRSA, 0x06, ALA1) CreateByteField (CRSA, 0x07, LNA1) CreateWordField (CRSA, 0x09, IRQA) Name (CRSB, ResourceTemplate () { IO (Decode16, 0x0000, 0x0000, 0x01, 0x08) IO (Decode16, 0x0000, 0x0000, 0x01, 0x08) IRQNoFlags () {} DMA (Compatibility, NotBusMaster, Transfer16) {} }) CreateByteField (CRSB, 0x02, IOB1) CreateByteField (CRSB, 0x03, IOB2) CreateByteField (CRSB, 0x04, IOB3) CreateByteField (CRSB, 0x05, IOB4) CreateByteField (CRSB, 0x06, ALB1) CreateByteField (CRSB, 0x07, LNB1) CreateByteField (CRSB, 0x0A, IOB5) CreateByteField (CRSB, 0x0B, IOB6) CreateByteField (CRSB, 0x0C, IOB7) CreateByteField (CRSB, 0x0D, IOB8) CreateByteField (CRSB, 0x0E, ALB2) CreateByteField (CRSB, 0x0F, LNB2) CreateWordField (CRSB, 0x11, IRQB) CreateWordField (CRSB, 0x14, DMAV) If (ACT) { If (LEqual (MODE, 0x02)) { Store (IOBL, IOB1) Store (IOBH, IOB2) Store (IOBL, IOB3) Store (IOBH, IOB4) Store (IOBL, IOB5) Add (IOBH, 0x04, IOB6) Store (IOBL, IOB7) Add (IOBH, 0x04, IOB8) If (LEqual (IOBL, 0xBC)) { Store (0x01, ALB1) Store (0x04, LNB1) Store (0x01, ALB2) Store (0x04, LNB2) } Store (0x01, Local0) ShiftLeft (Local0, INT, IRQB) Store (0x01, Local0) ShiftLeft (Local0, DMAS, DMAV) Return (CRSB) } Else { Store (IOBL, IOA1) Store (IOBH, IOA2) Store (IOBL, IOA3) Store (IOBH, IOA4) Store (0x01, Local0) ShiftLeft (Local0, INT, IRQA) If (LEqual (IOBL, 0xBC)) { Store (0x01, ALA1) Store (0x04, LNA1) } Return (CRSA) } } Else { If (LEqual (MODE, 0x02)) { Return (CRSB) } Else { Return (CRSA) } } XCFG () Release (W627) } Name (PRSA, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {7} } StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {5} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {7} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {5} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {7} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {5} } EndDependentFn () }) Name (PRSB, ResourceTemplate () { StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {7} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x0378, 0x0378, 0x01, 0x08) IO (Decode16, 0x0778, 0x0778, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {5} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IO (Decode16, 0x0678, 0x0678, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {7} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x0278, 0x0278, 0x01, 0x08) IO (Decode16, 0x0678, 0x0678, 0x01, 0x08) IRQ (Edge, ActiveHigh, Exclusive) {5} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IO (Decode16, 0x07BC, 0x07BC, 0x01, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {7} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } StartDependentFnNoPri () { IO (Decode16, 0x03BC, 0x03BC, 0x01, 0x04) IO (Decode16, 0x07BC, 0x07BC, 0x01, 0x04) IRQ (Edge, ActiveHigh, Exclusive) {5} DMA (Compatibility, NotBusMaster, Transfer16) {0,1,3} } EndDependentFn () }) Method (_PRS, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x01) If (LEqual (MODE, 0x02)) { Store (PRSB, Local0) } Else { Store (PRSA, Local0) } XCFG () Release (W627) Return (Local0) } Method (_SRS, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (0x01) If (LEqual (MODE, 0x02)) { CreateByteField (Arg0, 0x02, IOB1) CreateByteField (Arg0, 0x03, IOB2) CreateByteField (Arg0, 0x04, IOB3) CreateByteField (Arg0, 0x05, IOB4) CreateByteField (Arg0, 0x06, ALB1) CreateByteField (Arg0, 0x07, LNB1) CreateByteField (Arg0, 0x0A, IOB5) CreateByteField (Arg0, 0x0B, IOB6) CreateByteField (Arg0, 0x0C, IOB7) CreateByteField (Arg0, 0x0D, IOB8) CreateByteField (Arg0, 0x0E, ALB2) CreateByteField (Arg0, 0x0F, LNB2) CreateWordField (Arg0, 0x11, IRQB) CreateWordField (Arg0, 0x14, DMAV) Store (IOB1, IOBL) Store (IOB2, IOBH) FindSetLeftBit (IRQB, Local0) Subtract (Local0, 0x01, INT) FindSetLeftBit (DMAV, Local0) Subtract (Local0, 0x01, DMAS) } Else { CreateByteField (Arg0, 0x02, IOA1) CreateByteField (Arg0, 0x03, IOA2) CreateByteField (Arg0, 0x04, IOA3) CreateByteField (Arg0, 0x05, IOA4) CreateByteField (Arg0, 0x06, ALA1) CreateByteField (Arg0, 0x07, LNA1) CreateWordField (Arg0, 0x09, IRQA) Store (IOA1, IOBL) Store (IOA2, IOBH) FindSetLeftBit (IRQA, Local0) Subtract (Local0, 0x01, INT) } Store (0x01, ACT) XCFG () Release (W627) } Method (_PS0, 0, NotSerialized) { PS0 (0x01) } Method (_PS3, 0, NotSerialized) { PS3 (0x01) } } Method (ENWK, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x0A) Store (0x00, ACT) Store (0x01, ACT) Store (0xF3, INDX) Store (0x3F, DATA) Store (0xF6, INDX) Store (0x30, DATA) Store (0xF9, INDX) Store (0x05, DATA) XCFG () Release (W627) } Method (DSWK, 0, NotSerialized) { Acquire (W627, 0x1388) CFG (0x0A) Store (0x00, ACT) Store (0xF6, INDX) Store (0x00, DATA) Store (0xF9, INDX) Store (0x00, DATA) Store (0xF3, INDX) Store (0x3F, DATA) XCFG () Release (W627) } Method (CLED, 1, NotSerialized) { Acquire (W627, 0x1388) CFG (0x09) Store (Arg0, SLED) XCFG () Release (W627) } } } Name (NATA, Package (0x02) { 0x001F0001, 0x001F0002 }) Method (GETP, 1, NotSerialized) { Noop If (LEqual (And (Arg0, 0x09), 0x00)) { Return (0xFFFFFFFF) } If (LEqual (And (Arg0, 0x09), 0x08)) { Return (0x0384) } ShiftRight (And (Arg0, 0x0300), 0x08, Local0) ShiftRight (And (Arg0, 0x3000), 0x0C, Local1) Return (Multiply (0x1E, Subtract (0x09, Add (Local0, Local1)))) } Method (GETD, 4, NotSerialized) { Noop If (Arg0) { If (Arg1) { Return (0x14) } If (Arg2) { Return (Multiply (Subtract (0x04, Arg3), 0x0F)) } Return (Multiply (Subtract (0x04, Arg3), 0x1E)) } Return (0xFFFFFFFF) } Method (GETT, 1, NotSerialized) { Noop Return (Multiply (0x1E, Subtract (0x09, Add (And (ShiftRight (Arg0, 0x02), 0x03), And (Arg0, 0x03))))) } Method (GETF, 3, NotSerialized) { Noop Name (TMPF, 0x00) If (Arg0) { Or (TMPF, 0x01, TMPF) } If (And (Arg2, 0x02)) { Or (TMPF, 0x02, TMPF) } If (Arg1) { Or (TMPF, 0x04, TMPF) } If (And (Arg2, 0x20)) { Or (TMPF, 0x08, TMPF) } If (And (Arg2, 0x4000)) { Or (TMPF, 0x10, TMPF) } Return (TMPF) } Method (SETP, 3, NotSerialized) { Noop If (LNot (LLess (Arg0, 0xF0))) { Return (0x08) } Else { If (And (Arg1, 0x02)) { If (LAnd (LNot (LGreater (Arg0, 0x78)), And (Arg2, 0x02))) { Return (0x2301) } If (LAnd (LNot (LGreater (Arg0, 0xB4)), And (Arg2, 0x01))) { Return (0x2101) } } Return (0x1001) } } Method (SETD, 1, NotSerialized) { Noop If (LNot (LGreater (Arg0, 0x14))) { Return (0x01) } If (LNot (LGreater (Arg0, 0x1E))) { Return (0x02) } If (LNot (LGreater (Arg0, 0x2D))) { Return (0x01) } If (LNot (LGreater (Arg0, 0x3C))) { Return (0x02) } If (LNot (LGreater (Arg0, 0x5A))) { Return (0x01) } Return (0x00) } Method (SETT, 3, NotSerialized) { Noop If (And (Arg1, 0x02)) { If (LAnd (LNot (LGreater (Arg0, 0x78)), And (Arg2, 0x02))) { Return (0x0B) } If (LAnd (LNot (LGreater (Arg0, 0xB4)), And (Arg2, 0x01))) { Return (0x09) } } Return (0x04) } Device (IDEC) { Name (_ADR, 0x001F0001) OperationRegion (IDEC, PCI_Config, 0x40, 0x18) Field (IDEC, DWordAcc, NoLock, Preserve) { PRIT, 16, SECT, 16, PSIT, 4, SSIT, 4, Offset (0x08), SDMA, 4, Offset (0x0A), SDT0, 2, , 2, SDT1, 2, Offset (0x0B), SDT2, 2, , 2, SDT3, 2, Offset (0x14), ICR0, 4, ICR1, 4, ICR2, 4, ICR3, 4, ICR4, 4, ICR5, 4 } Device (PRID) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Noop Name (PBUF, Buffer (0x14) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) CreateDWordField (PBUF, 0x00, PIO0) CreateDWordField (PBUF, 0x04, DMA0) CreateDWordField (PBUF, 0x08, PIO1) CreateDWordField (PBUF, 0x0C, DMA1) CreateDWordField (PBUF, 0x10, FLAG) Store (GETP (PRIT), PIO0) Store (GETD (And (SDMA, 0x01), And (ICR3, 0x01), And (ICR0, 0x01), SDT0), DMA0) If (LEqual (DMA0, 0xFFFFFFFF)) { Store (PIO0, DMA0) } If (And (PRIT, 0x4000)) { If (LEqual (And (PRIT, 0x90), 0x80)) { Store (0x0384, PIO1) } Else { Store (GETT (PSIT), PIO1) } } Else { Store (0xFFFFFFFF, PIO1) } Store (GETD (And (SDMA, 0x02), And (ICR3, 0x02), And (ICR0, 0x02), SDT1), DMA1) If (LEqual (DMA1, 0xFFFFFFFF)) { Store (PIO1, DMA1) } Store (GETF (And (SDMA, 0x01), And (SDMA, 0x02), PRIT), FLAG) Return (PBUF) } Method (_STM, 3, NotSerialized) { Noop CreateDWordField (Arg0, 0x00, PIO0) CreateDWordField (Arg0, 0x04, DMA0) CreateDWordField (Arg0, 0x08, PIO1) CreateDWordField (Arg0, 0x0C, DMA1) CreateDWordField (Arg0, 0x10, FLAG) Store (0x04, ICR2) If (LEqual (SizeOf (Arg1), 0x0200)) { And (PRIT, 0x4CF0, PRIT) And (SDMA, 0x0E, SDMA) Store (0x00, SDT0) And (ICR0, 0x0E, ICR0) And (ICR1, 0x0E, ICR1) And (ICR3, 0x0E, ICR3) And (ICR5, 0x0E, ICR5) CreateWordField (Arg1, 0x62, W490) CreateWordField (Arg1, 0x6A, W530) CreateWordField (Arg1, 0x7E, W630) CreateWordField (Arg1, 0x80, W640) CreateWordField (Arg1, 0xB0, W880) Or (PRIT, 0x8004, PRIT) If (LAnd (And (FLAG, 0x02), And (W490, 0x0800))) { Or (PRIT, 0x02, PRIT) } Or (PRIT, SETP (PIO0, W530, W640), PRIT) If (And (FLAG, 0x01)) { Or (SDMA, 0x01, SDMA) Store (SETD (DMA0), SDT0) If (And (W880, 0x20)) { Or (ICR1, 0x01, ICR1) Or (ICR5, 0x01, ICR5) } If (And (W880, 0x10)) { Or (ICR1, 0x01, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x01, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x01, ICR0) } } } If (LEqual (SizeOf (Arg2), 0x0200)) { And (PRIT, 0x3F0F, PRIT) Store (0x00, PSIT) And (SDMA, 0x0D, SDMA) Store (0x00, SDT1) And (ICR0, 0x0D, ICR0) And (ICR1, 0x0D, ICR1) And (ICR3, 0x0D, ICR3) And (ICR5, 0x0D, ICR5) CreateWordField (Arg2, 0x62, W491) CreateWordField (Arg2, 0x6A, W531) CreateWordField (Arg2, 0x7E, W631) CreateWordField (Arg2, 0x80, W641) CreateWordField (Arg2, 0xB0, W881) Or (PRIT, 0x8040, PRIT) If (LAnd (And (FLAG, 0x08), And (W491, 0x0800))) { Or (PRIT, 0x20, PRIT) } If (And (FLAG, 0x10)) { Or (PRIT, 0x4000, PRIT) If (LGreater (PIO1, 0xF0)) { Or (PRIT, 0x80, PRIT) } Else { Or (PRIT, 0x10, PRIT) Store (SETT (PIO1, W531, W641), PSIT) } } If (And (FLAG, 0x04)) { Or (SDMA, 0x02, SDMA) Store (SETD (DMA1), SDT1) If (And (W881, 0x20)) { Or (ICR1, 0x02, ICR1) Or (ICR5, 0x02, ICR5) } If (And (W881, 0x10)) { Or (ICR1, 0x02, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x02, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x02, ICR0) } } } } Method (_PS0, 0, NotSerialized) { Noop } Method (_PS3, 0, NotSerialized) { Noop } Device (P_D0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Noop Name (PIB0, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF }) CreateByteField (PIB0, 0x01, PMD0) CreateByteField (PIB0, 0x08, DMD0) If (And (PRIT, 0x02)) { If (LEqual (And (PRIT, 0x09), 0x08)) { Store (0x08, PMD0) } Else { Store (0x0A, PMD0) ShiftRight (And (PRIT, 0x0300), 0x08, Local0) ShiftRight (And (PRIT, 0x3000), 0x0C, Local1) Add (Local0, Local1, Local2) If (LEqual (0x03, Local2)) { Store (0x0B, PMD0) } If (LEqual (0x05, Local2)) { Store (0x0C, PMD0) } } } Else { Store (0x01, PMD0) } If (And (SDMA, 0x01)) { Store (Or (SDT0, 0x40), DMD0) If (And (ICR0, 0x01)) { Add (DMD0, 0x02, DMD0) } If (And (ICR3, 0x01)) { Store (0x45, DMD0) } } Else { Or (Subtract (And (PMD0, 0x07), 0x02), 0x20, DMD0) } Return (PIB0) } } Device (P_D1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Noop Name (PIB1, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF }) CreateByteField (PIB1, 0x01, PMD1) CreateByteField (PIB1, 0x08, DMD1) If (And (PRIT, 0x20)) { If (LEqual (And (PRIT, 0x90), 0x80)) { Store (0x08, PMD1) } Else { Add (And (PSIT, 0x03), ShiftRight (And (PSIT, 0x0C), 0x02), Local0) If (LEqual (0x05, Local0)) { Store (0x0C, PMD1) } Else { If (LEqual (0x03, Local0)) { Store (0x0B, PMD1) } Else { Store (0x0A, PMD1) } } } } Else { Store (0x01, PMD1) } If (And (SDMA, 0x02)) { Store (Or (SDT1, 0x40), DMD1) If (And (ICR0, 0x02)) { Add (DMD1, 0x02, DMD1) } If (And (ICR3, 0x02)) { Store (0x45, DMD1) } } Else { Or (Subtract (And (PMD1, 0x07), 0x02), 0x20, DMD1) } Return (PIB1) } } } Device (SECD) { Name (_ADR, 0x01) Method (_GTM, 0, NotSerialized) { Noop Name (SBUF, Buffer (0x14) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) CreateDWordField (SBUF, 0x00, PIO0) CreateDWordField (SBUF, 0x04, DMA0) CreateDWordField (SBUF, 0x08, PIO1) CreateDWordField (SBUF, 0x0C, DMA1) CreateDWordField (SBUF, 0x10, FLAG) Store (GETP (SECT), PIO0) Store (GETD (And (SDMA, 0x04), And (ICR3, 0x04), And (ICR0, 0x04), SDT2), DMA0) If (LEqual (DMA0, 0xFFFFFFFF)) { Store (PIO0, DMA0) } If (And (SECT, 0x4000)) { If (LEqual (And (SECT, 0x90), 0x80)) { Store (0x0384, PIO1) } Else { Store (GETT (SSIT), PIO1) } } Else { Store (0xFFFFFFFF, PIO1) } Store (GETD (And (SDMA, 0x08), And (ICR3, 0x08), And (ICR0, 0x08), SDT3), DMA1) If (LEqual (DMA1, 0xFFFFFFFF)) { Store (PIO1, DMA1) } Store (GETF (And (SDMA, 0x04), And (SDMA, 0x08), SECT), FLAG) Return (SBUF) } Method (_STM, 3, NotSerialized) { Noop CreateDWordField (Arg0, 0x00, PIO0) CreateDWordField (Arg0, 0x04, DMA0) CreateDWordField (Arg0, 0x08, PIO1) CreateDWordField (Arg0, 0x0C, DMA1) CreateDWordField (Arg0, 0x10, FLAG) Store (0x04, ICR2) If (LEqual (SizeOf (Arg1), 0x0200)) { And (SECT, 0x4CF0, SECT) And (SDMA, 0x0B, SDMA) Store (0x00, SDT2) And (ICR0, 0x0B, ICR0) And (ICR1, 0x0B, ICR1) And (ICR3, 0x0B, ICR3) And (ICR5, 0x0B, ICR5) CreateWordField (Arg1, 0x62, W490) CreateWordField (Arg1, 0x6A, W530) CreateWordField (Arg1, 0x7E, W630) CreateWordField (Arg1, 0x80, W640) CreateWordField (Arg1, 0xB0, W880) Or (SECT, 0x8004, SECT) If (LAnd (And (FLAG, 0x02), And (W490, 0x0800))) { Or (SECT, 0x02, SECT) } Or (SECT, SETP (PIO0, W530, W640), SECT) If (And (FLAG, 0x01)) { Or (SDMA, 0x04, SDMA) Store (SETD (DMA0), SDT2) If (And (W880, 0x20)) { Or (ICR1, 0x04, ICR1) Or (ICR5, 0x04, ICR5) } If (And (W880, 0x10)) { Or (ICR1, 0x04, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x04, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x04, ICR0) } } } If (LEqual (SizeOf (Arg2), 0x0200)) { And (SECT, 0x3F0F, SECT) Store (0x00, SSIT) And (SDMA, 0x07, SDMA) Store (0x00, SDT3) And (ICR0, 0x07, ICR0) And (ICR1, 0x07, ICR1) And (ICR3, 0x07, ICR3) And (ICR5, 0x07, ICR5) CreateWordField (Arg2, 0x62, W491) CreateWordField (Arg2, 0x6A, W531) CreateWordField (Arg2, 0x7E, W631) CreateWordField (Arg2, 0x80, W641) CreateWordField (Arg2, 0xB0, W881) Or (SECT, 0x8040, SECT) If (LAnd (And (FLAG, 0x08), And (W491, 0x0800))) { Or (SECT, 0x20, SECT) } If (And (FLAG, 0x10)) { Or (SECT, 0x4000, SECT) If (LGreater (PIO1, 0xF0)) { Or (SECT, 0x80, SECT) } Else { Or (SECT, 0x10, SECT) Store (SETT (PIO1, W531, W641), SSIT) } } If (And (FLAG, 0x04)) { Or (SDMA, 0x08, SDMA) Store (SETD (DMA1), SDT3) If (And (W881, 0x20)) { Or (ICR1, 0x08, ICR1) Or (ICR5, 0x08, ICR5) } If (And (W881, 0x10)) { Or (ICR1, 0x08, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x08, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x08, ICR0) } } } } Method (_PS0, 0, NotSerialized) { Noop } Method (_PS3, 0, NotSerialized) { Noop } Device (S_D0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Noop Name (SIB0, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF }) CreateByteField (SIB0, 0x01, PMD0) CreateByteField (SIB0, 0x08, DMD0) If (And (SECT, 0x02)) { If (LEqual (And (SECT, 0x09), 0x08)) { Store (0x08, PMD0) } Else { Store (0x0A, PMD0) ShiftRight (And (SECT, 0x0300), 0x08, Local0) ShiftRight (And (SECT, 0x3000), 0x0C, Local1) Add (Local0, Local1, Local2) If (LEqual (0x03, Local2)) { Store (0x0B, PMD0) } If (LEqual (0x05, Local2)) { Store (0x0C, PMD0) } } } Else { Store (0x01, PMD0) } If (And (SDMA, 0x04)) { Store (Or (SDT2, 0x40), DMD0) If (And (ICR0, 0x04)) { Add (DMD0, 0x02, DMD0) } If (And (ICR3, 0x04)) { Store (0x45, DMD0) } } Else { Or (Subtract (And (PMD0, 0x07), 0x02), 0x20, DMD0) } Return (SIB0) } } Device (S_D1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Noop Name (SIB1, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF }) CreateByteField (SIB1, 0x01, PMD1) CreateByteField (SIB1, 0x08, DMD1) If (And (SECT, 0x20)) { If (LEqual (And (SECT, 0x90), 0x80)) { Store (0x08, PMD1) } Else { Add (And (SSIT, 0x03), ShiftRight (And (SSIT, 0x0C), 0x02), Local0) If (LEqual (0x05, Local0)) { Store (0x0C, PMD1) } Else { If (LEqual (0x03, Local0)) { Store (0x0B, PMD1) } Else { Store (0x0A, PMD1) } } } } Else { Store (0x01, PMD1) } If (And (SDMA, 0x08)) { Store (Or (SDT3, 0x40), DMD1) If (And (ICR0, 0x08)) { Add (DMD1, 0x02, DMD1) } If (And (ICR3, 0x08)) { Store (0x45, DMD1) } } Else { Or (Subtract (And (PMD1, 0x07), 0x02), 0x20, DMD1) } Return (SIB1) } } } } Device (IDE1) { Name (_ADR, 0x001F0002) OperationRegion (IDE1, PCI_Config, 0x90, 0x03) Field (IDE1, DWordAcc, NoLock, Preserve) { MAP, 8, Offset (0x02), PCS, 8 } OperationRegion (IDEC, PCI_Config, 0x40, 0x18) Field (IDEC, DWordAcc, NoLock, Preserve) { PRIT, 16, SECT, 16, PSIT, 4, SSIT, 4, Offset (0x08), SDMA, 4, Offset (0x0A), SDT0, 2, , 2, SDT1, 2, Offset (0x0B), SDT2, 2, , 2, SDT3, 2, Offset (0x14), ICR0, 4, ICR1, 4, ICR2, 4, ICR3, 4, ICR4, 4, ICR5, 4 } Method (CTYP, 1, NotSerialized) { Store (Zero, Local0) If (Arg0) { If (LAnd (LGreater (MAP, 0x01), LLess (MAP, 0x06))) { Store (0x01, Local0) } Else { If (LEqual (MAP, Zero)) { Store (0x03, Local0) } If (LEqual (MAP, One)) { Store (0x04, Local0) } } } Else { If (LGreater (MAP, 0x05)) { Store (0x02, Local0) } Else { If (LEqual (MAP, Zero)) { Store (0x05, Local0) } If (LEqual (MAP, One)) { Store (0x06, Local0) } } } Return (Local0) } Device (PRID) { Name (_ADR, 0x00) Method (_GTM, 0, NotSerialized) { Noop Name (PBUF, Buffer (0x14) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) CreateDWordField (PBUF, 0x00, PIO0) CreateDWordField (PBUF, 0x04, DMA0) CreateDWordField (PBUF, 0x08, PIO1) CreateDWordField (PBUF, 0x0C, DMA1) CreateDWordField (PBUF, 0x10, FLAG) Store (GETP (PRIT), PIO0) Store (GETD (And (SDMA, 0x01), And (ICR3, 0x01), And (ICR0, 0x01), SDT0), DMA0) If (LEqual (DMA0, 0xFFFFFFFF)) { Store (PIO0, DMA0) } If (And (PRIT, 0x4000)) { If (LEqual (And (PRIT, 0x90), 0x80)) { Store (0x0384, PIO1) } Else { Store (GETT (PSIT), PIO1) } } Else { Store (0xFFFFFFFF, PIO1) } Store (GETD (And (SDMA, 0x02), And (ICR3, 0x02), And (ICR0, 0x02), SDT1), DMA1) If (LEqual (DMA1, 0xFFFFFFFF)) { Store (PIO1, DMA1) } Store (GETF (And (SDMA, 0x01), And (SDMA, 0x02), PRIT), FLAG) Return (PBUF) } Method (_STM, 3, NotSerialized) { Noop CreateDWordField (Arg0, 0x00, PIO0) CreateDWordField (Arg0, 0x04, DMA0) CreateDWordField (Arg0, 0x08, PIO1) CreateDWordField (Arg0, 0x0C, DMA1) CreateDWordField (Arg0, 0x10, FLAG) Store (0x04, ICR2) If (LEqual (SizeOf (Arg1), 0x0200)) { And (PRIT, 0x4CF0, PRIT) And (SDMA, 0x0E, SDMA) Store (0x00, SDT0) And (ICR0, 0x0E, ICR0) And (ICR1, 0x0E, ICR1) And (ICR3, 0x0E, ICR3) And (ICR5, 0x0E, ICR5) CreateWordField (Arg1, 0x62, W490) CreateWordField (Arg1, 0x6A, W530) CreateWordField (Arg1, 0x7E, W630) CreateWordField (Arg1, 0x80, W640) CreateWordField (Arg1, 0xB0, W880) Or (PRIT, 0x8004, PRIT) If (LAnd (And (FLAG, 0x02), And (W490, 0x0800))) { Or (PRIT, 0x02, PRIT) } Or (PRIT, SETP (PIO0, W530, W640), PRIT) If (And (FLAG, 0x01)) { Or (SDMA, 0x01, SDMA) Store (SETD (DMA0), SDT0) If (And (W880, 0x20)) { Or (ICR1, 0x01, ICR1) Or (ICR5, 0x01, ICR5) } If (And (W880, 0x10)) { Or (ICR1, 0x01, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x01, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x01, ICR0) } } } If (LEqual (SizeOf (Arg2), 0x0200)) { And (PRIT, 0x3F0F, PRIT) Store (0x00, PSIT) And (SDMA, 0x0D, SDMA) Store (0x00, SDT1) And (ICR0, 0x0D, ICR0) And (ICR1, 0x0D, ICR1) And (ICR3, 0x0D, ICR3) And (ICR5, 0x0D, ICR5) CreateWordField (Arg2, 0x62, W491) CreateWordField (Arg2, 0x6A, W531) CreateWordField (Arg2, 0x7E, W631) CreateWordField (Arg2, 0x80, W641) CreateWordField (Arg2, 0xB0, W881) Or (PRIT, 0x8040, PRIT) If (LAnd (And (FLAG, 0x08), And (W491, 0x0800))) { Or (PRIT, 0x20, PRIT) } If (And (FLAG, 0x10)) { Or (PRIT, 0x4000, PRIT) If (LGreater (PIO1, 0xF0)) { Or (PRIT, 0x80, PRIT) } Else { Or (PRIT, 0x10, PRIT) Store (SETT (PIO1, W531, W641), PSIT) } } If (And (FLAG, 0x04)) { Or (SDMA, 0x02, SDMA) Store (SETD (DMA1), SDT1) If (And (W881, 0x20)) { Or (ICR1, 0x02, ICR1) Or (ICR5, 0x02, ICR5) } If (And (W881, 0x10)) { Or (ICR1, 0x02, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x02, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x02, ICR0) } } } } Method (_PS0, 0, NotSerialized) { } Method (_PS3, 0, NotSerialized) { } Device (P_D0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Noop Name (PIB0, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF }) CreateByteField (PIB0, 0x01, PMD0) CreateByteField (PIB0, 0x08, DMD0) If (And (PRIT, 0x02)) { If (LEqual (And (PRIT, 0x09), 0x08)) { Store (0x08, PMD0) } Else { Store (0x0A, PMD0) ShiftRight (And (PRIT, 0x0300), 0x08, Local0) ShiftRight (And (PRIT, 0x3000), 0x0C, Local1) Add (Local0, Local1, Local2) If (LEqual (0x03, Local2)) { Store (0x0B, PMD0) } If (LEqual (0x05, Local2)) { Store (0x0C, PMD0) } } } Else { Store (0x01, PMD0) } If (And (SDMA, 0x01)) { Store (Or (SDT0, 0x40), DMD0) If (And (ICR0, 0x01)) { Add (DMD0, 0x02, DMD0) } If (And (ICR3, 0x01)) { Store (0x45, DMD0) } } Else { Or (Subtract (And (PMD0, 0x07), 0x02), 0x20, DMD0) } Return (PIB0) } } Device (P_D1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Noop Name (PIB1, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF }) CreateByteField (PIB1, 0x01, PMD1) CreateByteField (PIB1, 0x08, DMD1) If (And (PRIT, 0x20)) { If (LEqual (And (PRIT, 0x90), 0x80)) { Store (0x08, PMD1) } Else { Add (And (PSIT, 0x03), ShiftRight (And (PSIT, 0x0C), 0x02), Local0) If (LEqual (0x05, Local0)) { Store (0x0C, PMD1) } Else { If (LEqual (0x03, Local0)) { Store (0x0B, PMD1) } Else { Store (0x0A, PMD1) } } } } Else { Store (0x01, PMD1) } If (And (SDMA, 0x02)) { Store (Or (SDT1, 0x40), DMD1) If (And (ICR0, 0x02)) { Add (DMD1, 0x02, DMD1) } If (And (ICR3, 0x02)) { Store (0x45, DMD1) } } Else { Or (Subtract (And (PMD1, 0x07), 0x02), 0x20, DMD1) } Return (PIB1) } } } Device (SECD) { Name (_ADR, 0x01) Method (_GTM, 0, NotSerialized) { Noop Name (SBUF, Buffer (0x14) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }) CreateDWordField (SBUF, 0x00, PIO0) CreateDWordField (SBUF, 0x04, DMA0) CreateDWordField (SBUF, 0x08, PIO1) CreateDWordField (SBUF, 0x0C, DMA1) CreateDWordField (SBUF, 0x10, FLAG) Store (GETP (SECT), PIO0) Store (GETD (And (SDMA, 0x04), And (ICR3, 0x04), And (ICR0, 0x04), SDT2), DMA0) If (LEqual (DMA0, 0xFFFFFFFF)) { Store (PIO0, DMA0) } If (And (SECT, 0x4000)) { If (LEqual (And (SECT, 0x90), 0x80)) { Store (0x0384, PIO1) } Else { Store (GETT (SSIT), PIO1) } } Else { Store (0xFFFFFFFF, PIO1) } Store (GETD (And (SDMA, 0x08), And (ICR3, 0x08), And (ICR0, 0x08), SDT3), DMA1) If (LEqual (DMA1, 0xFFFFFFFF)) { Store (PIO1, DMA1) } Store (GETF (And (SDMA, 0x04), And (SDMA, 0x08), SECT), FLAG) Return (SBUF) } Method (_STM, 3, NotSerialized) { Noop CreateDWordField (Arg0, 0x00, PIO0) CreateDWordField (Arg0, 0x04, DMA0) CreateDWordField (Arg0, 0x08, PIO1) CreateDWordField (Arg0, 0x0C, DMA1) CreateDWordField (Arg0, 0x10, FLAG) Store (0x04, ICR2) If (LEqual (SizeOf (Arg1), 0x0200)) { And (SECT, 0x4CF0, SECT) And (SDMA, 0x0B, SDMA) Store (0x00, SDT2) And (ICR0, 0x0B, ICR0) And (ICR1, 0x0B, ICR1) And (ICR3, 0x0B, ICR3) And (ICR5, 0x0B, ICR5) CreateWordField (Arg1, 0x62, W490) CreateWordField (Arg1, 0x6A, W530) CreateWordField (Arg1, 0x7E, W630) CreateWordField (Arg1, 0x80, W640) CreateWordField (Arg1, 0xB0, W880) Or (SECT, 0x8004, SECT) If (LAnd (And (FLAG, 0x02), And (W490, 0x0800))) { Or (SECT, 0x02, SECT) } Or (SECT, SETP (PIO0, W530, W640), SECT) If (And (FLAG, 0x01)) { Or (SDMA, 0x04, SDMA) Store (SETD (DMA0), SDT2) If (And (W880, 0x20)) { Or (ICR1, 0x04, ICR1) Or (ICR5, 0x04, ICR5) } If (And (W880, 0x10)) { Or (ICR1, 0x04, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x04, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x04, ICR0) } } } If (LEqual (SizeOf (Arg2), 0x0200)) { And (SECT, 0x3F0F, SECT) Store (0x00, SSIT) And (SDMA, 0x07, SDMA) Store (0x00, SDT3) And (ICR0, 0x07, ICR0) And (ICR1, 0x07, ICR1) And (ICR3, 0x07, ICR3) And (ICR5, 0x07, ICR5) CreateWordField (Arg2, 0x62, W491) CreateWordField (Arg2, 0x6A, W531) CreateWordField (Arg2, 0x7E, W631) CreateWordField (Arg2, 0x80, W641) CreateWordField (Arg2, 0xB0, W881) Or (SECT, 0x8040, SECT) If (LAnd (And (FLAG, 0x08), And (W491, 0x0800))) { Or (SECT, 0x20, SECT) } If (And (FLAG, 0x10)) { Or (SECT, 0x4000, SECT) If (LGreater (PIO1, 0xF0)) { Or (SECT, 0x80, SECT) } Else { Or (SECT, 0x10, SECT) Store (SETT (PIO1, W531, W641), SSIT) } } If (And (FLAG, 0x04)) { Or (SDMA, 0x08, SDMA) Store (SETD (DMA1), SDT3) If (And (W881, 0x20)) { Or (ICR1, 0x08, ICR1) Or (ICR5, 0x08, ICR5) } If (And (W881, 0x10)) { Or (ICR1, 0x08, ICR1) } If (LLess (DMA0, 0x1E)) { Or (ICR3, 0x08, ICR3) } If (LLess (DMA0, 0x3C)) { Or (ICR0, 0x08, ICR0) } } } } Method (_PS0, 0, NotSerialized) { } Method (_PS3, 0, NotSerialized) { } Device (S_D0) { Name (_ADR, 0x00) Method (_GTF, 0, NotSerialized) { Noop Name (SIB0, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xA0, 0xEF }) CreateByteField (SIB0, 0x01, PMD0) CreateByteField (SIB0, 0x08, DMD0) If (And (SECT, 0x02)) { If (LEqual (And (SECT, 0x09), 0x08)) { Store (0x08, PMD0) } Else { Store (0x0A, PMD0) ShiftRight (And (SECT, 0x0300), 0x08, Local0) ShiftRight (And (SECT, 0x3000), 0x0C, Local1) Add (Local0, Local1, Local2) If (LEqual (0x03, Local2)) { Store (0x0B, PMD0) } If (LEqual (0x05, Local2)) { Store (0x0C, PMD0) } } } Else { Store (0x01, PMD0) } If (And (SDMA, 0x04)) { Store (Or (SDT2, 0x40), DMD0) If (And (ICR0, 0x04)) { Add (DMD0, 0x02, DMD0) } If (And (ICR3, 0x04)) { Store (0x45, DMD0) } } Else { Or (Subtract (And (PMD0, 0x07), 0x02), 0x20, DMD0) } Return (SIB0) } } Device (S_D1) { Name (_ADR, 0x01) Method (_GTF, 0, NotSerialized) { Noop Name (SIB1, Buffer (0x0E) { 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF, 0x03, 0x00, 0x00, 0x00, 0x00, 0xB0, 0xEF }) CreateByteField (SIB1, 0x01, PMD1) CreateByteField (SIB1, 0x08, DMD1) If (And (SECT, 0x20)) { If (LEqual (And (SECT, 0x90), 0x80)) { Store (0x08, PMD1) } Else { Add (And (SSIT, 0x03), ShiftRight (And (SSIT, 0x0C), 0x02), Local0) If (LEqual (0x05, Local0)) { Store (0x0C, PMD1) } Else { If (LEqual (0x03, Local0)) { Store (0x0B, PMD1) } Else { Store (0x0A, PMD1) } } } } Else { Store (0x01, PMD1) } If (And (SDMA, 0x02)) { Store (Or (SDT3, 0x40), DMD1) If (And (ICR0, 0x08)) { Add (DMD1, 0x02, DMD1) } If (And (ICR3, 0x08)) { Store (0x45, DMD1) } } Else { Or (Subtract (And (PMD1, 0x07), 0x02), 0x20, DMD1) } Return (SIB1) } } } } Device (SMBS) { Name (_ADR, 0x001F0003) } Device (PWRB) { Name (_HID, EisaId ("PNP0C0C")) } Device (USB1) { Name (_ADR, 0x001D0000) OperationRegion (USBO, PCI_Config, 0xC4, 0x04) Field (USBO, DWordAcc, Lock, Preserve) { RSEN, 2 } Name (_PRW, Package (0x02) { 0x03, 0x04 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, RSEN) } Else { Store (0x00, RSEN) } } Method (_S3D, 0, NotSerialized) { Return (0x02) } Method (_S4D, 0, NotSerialized) { Return (0x02) } } Device (USB2) { Name (_ADR, 0x001D0001) OperationRegion (USBO, PCI_Config, 0xC4, 0x04) Field (USBO, DWordAcc, Lock, Preserve) { RSEN, 2 } Name (_PRW, Package (0x02) { 0x04, 0x04 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, RSEN) } Else { Store (0x00, RSEN) } } Method (_S3D, 0, NotSerialized) { Return (0x02) } Method (_S4D, 0, NotSerialized) { Return (0x02) } } Device (USB3) { Name (_ADR, 0x001D0002) OperationRegion (USBO, PCI_Config, 0xC4, 0x04) Field (USBO, DWordAcc, Lock, Preserve) { RSEN, 2 } Name (_PRW, Package (0x02) { 0x0C, 0x04 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, RSEN) } Else { Store (0x00, RSEN) } } Method (_S3D, 0, NotSerialized) { Return (0x02) } Method (_S4D, 0, NotSerialized) { Return (0x02) } } Device (USB4) { Name (_ADR, 0x001D0003) OperationRegion (USBO, PCI_Config, 0xC4, 0x04) Field (USBO, DWordAcc, Lock, Preserve) { RSEN, 2 } Name (_PRW, Package (0x02) { 0x0E, 0x04 }) Method (_PSW, 1, NotSerialized) { If (Arg0) { Store (0x03, RSEN) } Else { Store (0x00, RSEN) } } Method (_S3D, 0, NotSerialized) { Return (0x02) } Method (_S4D, 0, NotSerialized) { Return (0x02) } } Device (EUSB) { Name (_ADR, 0x001D0007) Name (_S3D, 0x02) Name (_S4D, 0x02) Name (_PRW, Package (0x02) { 0x0D, 0x04 }) } } } Scope (_SI) { Method (_SST, 1, NotSerialized) { If (LEqual (Arg0, 0x01)) { \_SB.PCI0.LPC0.SIO.ENWK () } } } Scope (_TZ) { } OperationRegion (DBG, SystemIO, 0x80, 0x01) Field (DBG, ByteAcc, NoLock, Preserve) { DEBG, 8 } Name (_S0, Package (0x02) { 0x00, 0x00 }) Name (_S1, Package (0x02) { 0x01, 0x01 }) Name (_S4, Package (0x02) { 0x06, 0x06 }) Name (_S5, Package (0x02) { 0x07, 0x07 }) Name (PICF, 0x00) Method (_PIC, 1, NotSerialized) { Store (Arg0, \PICF) } Method (_PTS, 1, NotSerialized) { Store (Arg0, DEBG) If (LEqual (Arg0, 0x01)) { \_SB.PCI0.LPC0.SIO.ENWK () \_SB.PCI0.LPC0.SIO.CLED (0x02) } If (LEqual (Arg0, 0x03)) { \_SB.PCI0.LPC0.SIO.CLED (0x03) } If (LNot (LLess (Arg0, 0x04))) { \_SB.PCI0.LPC0.SIO.CLED (0x01) } } Method (_WAK, 1, NotSerialized) { ShiftLeft (Arg0, 0x04, DEBG) \_SB.PCI0.LPC0.SIO.CLED (0x00) Notify (\_SB.PCI0.PWRB, 0x02) \_SB.PCI0.LPC0.SIO.DSWK () } Scope (\) { Name (SSDT, Package (0x18) { "CPU0IST ", 0x00000000, 0x00000000, "CPU1IST ", 0x00000000, 0x00000000, "CPU0CST ", 0x00000000, 0x00000000, "CPU1CST ", 0x00000000, 0x00000000, "CPU2IST ", 0x80000000, 0x80000000, "CPU3IST ", 0x80000000, 0x80000000, "CPU2CST ", 0x80000000, 0x80000000, "CPU3CST ", 0x80000000, 0x80000000 }) Name (CFGD, 0x0F474108) Name (\PDC0, 0x80000000) Name (\PDC1, 0x80000000) Name (\PDC2, 0x80000000) Name (\PDC3, 0x80000000) } Scope (\_PR.CPU0) { Name (HI0, 0x00) Name (HC0, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP0) Store (CAP0, PDC0) If (LAnd (And (CFGD, 0x4000), LEqual (And (PDC0, 0x0A), 0x0A))) { If (And (CFGD, 0x03)) { OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, 0x01)), DerefOf (Index (SSDT, 0x02))) Load (IST0, HI0) } If (And (CFGD, 0x10)) { OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08))) Load (CST0, HC0) } } } } Scope (\_PR.CPU1) { Name (HI1, 0x00) Name (HC1, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP1) Store (CAP1, PDC1) If (LAnd (And (CFGD, 0x4000), LEqual (And (PDC1, 0x0A), 0x0A))) { If (And (CFGD, 0x03)) { OperationRegion (IST1, SystemMemory, DerefOf (Index (SSDT, 0x04)), DerefOf (Index (SSDT, 0x05))) Load (IST1, HI1) } If (And (CFGD, 0x10)) { OperationRegion (CST1, SystemMemory, DerefOf (Index (SSDT, 0x0A)), DerefOf (Index (SSDT, 0x0B))) Load (CST1, HC1) } } If (LEqual (And (PDC1, 0x0A), 0x0A)) {} } } Scope (\_PR.CPU2) { Name (HI2, 0x00) Name (HC2, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP2) Store (CAP2, PDC2) If (LAnd (And (CFGD, 0x4000), LEqual (And (PDC2, 0x0A), 0x0A))) { If (And (CFGD, 0x03)) { OperationRegion (IST2, SystemMemory, DerefOf (Index (SSDT, 0x0D)), DerefOf (Index (SSDT, 0x0E))) Load (IST2, HI2) } If (And (CFGD, 0x10)) { OperationRegion (CST2, SystemMemory, DerefOf (Index (SSDT, 0x13)), DerefOf (Index (SSDT, 0x14))) Load (CST2, HC2) } } } } Scope (\_PR.CPU3) { Name (HI3, 0x00) Name (HC3, 0x00) Method (_PDC, 1, NotSerialized) { CreateDWordField (Arg0, 0x08, CAP3) Store (CAP3, PDC3) If (LAnd (And (CFGD, 0x4000), LEqual (And (PDC3, 0x0A), 0x0A))) { If (And (CFGD, 0x03)) { OperationRegion (IST3, SystemMemory, DerefOf (Index (SSDT, 0x10)), DerefOf (Index (SSDT, 0x11))) Load (IST3, HI3) } If (And (CFGD, 0x10)) { OperationRegion (CST3, SystemMemory, DerefOf (Index (SSDT, 0x16)), DerefOf (Index (SSDT, 0x17))) Load (CST3, HC3) } } If (LEqual (And (PDC3, 0x0A), 0x0A)) {} } } } --------------050205030600050006060406 Content-Type: application/octet-stream; name="acpi.dsdt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="acpi.dsdt" RFNEVKxOAAABU0lOVEVMAEdMRU5XT09EAAAEBk1TRlQOAAABW4BSQ1JCAAwAwNH+DABAAABb gTxSQ1JCEwCAAAgAgAAQAIACAkhQQVMCAAVIUEFFAQBICQABUEFURAFTQVREAVNNQkQBQVpB RAFBOTdEAQhPU1lTCgAQSBxfR1BFFB9fTDAzAHAKA0RFQkeGXC8DX1NCX1BDSTBVU0IxCgIU H19MMDQAcAoEREVCR4ZcLwNfU0JfUENJMFVTQjIKAhREBV9MMDgAcAoIREVCR4ZcLwVfU0Jf UENJMExQQzBTSU9fQ09NMQoChlwvBV9TQl9QQ0kwTFBDMFNJT19DT00yCgKGXC8DX1NCX1BD STBQV1JCCgIURARfTDA5AHAKCURFQkeGXC8DX1NCX1BDSTBFWFAxCgKGXC8DX1NCX1BDSTBF WFA1CgKGXC8DX1NCX1BDSTBFWFA2CgIUTARfTDBCAHAKC0RFQkeGXC8EX1NCX1BDSTBERVYx UFhIQQoChlwvBF9TQl9QQ0kwREVWMVBYSEIKAoZcLwNfU0JfUENJMFBDSUIKAhQfX0wwQwBw CgxERUJHhlwvA19TQl9QQ0kwVVNCMwoCFB9fTDBEAHAKDURFQkeGXC8DX1NCX1BDSTBFVVNC CgIUH19MMEUAcAoOREVCR4ZcLwNfU0JfUENJMFVTQjQKAhQ6X0wxRACGXC8FX1NCX1BDSTBM UEMwU0lPX0tCQzAKAoZcLwVfU0JfUENJMExQQzBTSU9fTVNFMAoCEDlfUFJfW4MLQ1BVMAAQ EAAABluDC0NQVTEBEBAAAAZbgwtDUFUyAhAQAAAGW4MLQ1BVMwMQEAAABhCGcwRfU0JfW4KN cgRQQ0kwFAZfSU5JAAhfSElEDEHQCgMIX0JCTgoACF9BRFIKAFuAUkVHUwIKQArAW4E6UkVH UwEAQChQQU0wCFBBTTEIUEFNMghQQU0zCFBBTTQIUEFNNQhQQU02CAAHSEVOXwEAIFowMDAI W4BEUkJTAAwAQNH+DABAAABbgTREUkJTEwBAgFowMDEIWjAwMghaMDAzCFowMDQIAEA+WjAw NQhaMDA2CFowMDcIWjAwOAgIUlNSQxFGIAsBAogOAAIMAAAAAAD/AAAAAAEARwH4DPgMAQiH GAABDAMAAAAAAAAAAPcMAAAAAAAA+AwAAACHGAAADAMAAAAAAAAKAP//CwAAAAAAAAACAACH GAAADAMAAAAAAAAMAP8/DAAAAAAAAEAAAACHGAAADAMAAAAAAEAMAP9/DAAAAAAAAEAAAACH GAAADAMAAAAAAIAMAP+/DAAAAAAAAEAAAACHGAAADAMAAAAAAMAMAP//DAAAAAAAAEAAAACH GAAADAMAAAAAAAANAP8/DQAAAAAAAEAAAACHGAAADAMAAAAAAEANAP9/DQAAAAAAAEAAAACH GAAADAMAAAAAAIANAP+/DQAAAAAAAEAAAACHGAAADAMAAAAAAMANAP//DQAAAAAAAEAAAACH GAAADAMAAAAAAAAOAP8/DgAAAAAAAEAAAACHGAAADAMAAAAAAEAOAP9/DgAAAAAAAEAAAACH GAAADAMAAAAAAIAOAP+/DgAAAAAAAEAAAACHGAAADAMAAAAAAMAOAP//DgAAAAAAAEAAAACH GAAADAMAAAAAAAAPAP//DwAAAAAAAAABAACHGAAADAMAAAAAAAAAAAAAAAAAAAAAAAAAAACH GAABDAMAAAAAAA0AAP/9AAAAAAAAAPEAAACHGAAADAMAAAAAAAAAAAAAAAAAAAAAAAAAAAB5 ABRHXl9DUlMIcABhilJTUkMLuAFCVE1OilJTUkMLvAFCVE1YilJTUkMLxAFCVExOeXtaMDAw CvgAChhCVE1OdAwAAADwQlRNTkJUTE50ckJUTU5CVExOAAoBQlRNWI1SU1JDC6ACQzBSV4pS U1JDCllDME1OilJTUkMKXUMwTViKUlNSQwplQzBMTnABQzBSV6ASk3tQQU0xCgMACgFwAEMw UldwAEMwTE6gEpJ7UEFNMQoDAHALAEBDMExOjVJTUkMLeANDNFJXilJTUkMKdEM0TU6KUlNS Qwp4QzRNWIpSU1JDCoBDNExOcAFDNFJXoBKTe1BBTTEKMAAKEHAAQzRSV3AAQzRMTqASkntQ QU0xCjAAcAsAQEM0TE6NUlNSQwtQBEM4UleKUlNSQwqPQzhNTopSU1JDCpNDOE1YilJTUkMK m0M4TE5wAUM4UlegEpN7UEFNMgoDAAoBcABDOFJXcABDOExOoBKSe1BBTTIKAwBwCwBAQzhM To1SU1JDCygFQ0NSV4pSU1JDCqpDQ01OilJTUkMKrkNDTViKUlNSQwq2Q0NMTnABQ0NSV6AS k3tQQU0yCjAAChBwAENDUldwAENDTE6gEpJ7UEFNMgowAHALAEBDQ0xOjVJTUkMLAAZEMFJX ilJTUkMKxUQwTU6KUlNSQwrJRDBNWIpSU1JDCtFEMExOcAFEMFJXoBKTe1BBTTMKAwAKAXAA RDBSV3AARDBMTqASkntQQU0zCgMAcAsAQEQwTE6NUlNSQwvYBkQ0UleKUlNSQwrgRDRNTopS U1JDCuRENE1YilJTUkMK7EQ0TE5wAUQ0UlegEpN7UEFNMwowAAoQcABENFJXcABENExOoBKS e1BBTTMKMABwCwBARDRMTo1SU1JDC7AHRDhSV4pSU1JDCvtEOE1OilJTUkMK/0Q4TViKUlNS QwsHAUQ4TE5wAUQ4UlegEpN7UEFNNAoDAAoBcABEOFJXcABEOExOoBKSe1BBTTQKAwBwCwBA RDhMTo1SU1JDC4gIRENSV4pSU1JDCxYBRENNTopSU1JDCxoBRENNWIpSU1JDCyIBRENMTnAB RENSV6ASk3tQQU00CjAAChBwAERDUldwAERDTE6gEpJ7UEFNNAowAHALAEBEQ0xOjVJTUkML YAlFMFJXilJTUkMLMQFFME1OilJTUkMLNQFFME1YilJTUkMLPQFFMExOcAFFMFJXoBKTe1BB TTUKAwAKAXAARTBSV3AARTBMTqASkntQQU01CgMAcAsAQEUwTE6NUlNSQws4CkU0UleKUlNS QwtMAUU0TU6KUlNSQwtQAUU0TViKUlNSQwtYAUU0TE5wAUU0UlegEpN7UEFNNQowAAoQcABF NFJXcABFNExOoBKSe1BBTTUKMABwCwBARTRMTo1SU1JDCxALRThSV4pSU1JDC2cBRThNTopS U1JDC2sBRThNWIpSU1JDC3MBRThMTnABRThSV6ASk3tQQU02CgMACgFwAEU4UldwAEU4TE6g EpJ7UEFNNgoDAHALAEBFOExOjVJTUkML6AtFQ1JXilJTUkMLggFFQ01OilJTUkMLhgFFQ01Y ilJTUkMLjgFFQ0xOcAFFQ1JXoBKTe1BBTTYKMAAKEHAARUNSV3AARUNMTqASkntQQU02CjAA cAsAQEVDTE6NUlNSQwvADEYwUleKUlNSQwudAUYwTU6KUlNSQwuhAUYwTViKUlNSQwupAUYw TE5wAUYwUlegEpN7UEFNMAowAAoQcABGMFJXcABGMExOoBSSe1BBTTAKMABwDAAAAQBGMExO oE0JSFBBRYpSU1JDC+4BTTJNTopSU1JDC/IBTTJNWIpSU1JDC/oBTTJMTnAMAADQ/k0yTU5w DP8D0P5NMk1YcAsABE0yTE6gHJNIUEFTCgFwDAAQ0P5NMk1OcAz/E9D+TTJNWKAck0hQQVMK AnAMACDQ/k0yTU5wDP8j0P5NMk1YoByTSFBBUwoDcAwAMND+TTJNTnAM/zPQ/k0yTVikUlNS QxRJI19QUlQAoEEYklxQSUNGpBJHFwwSHgQM//8BAAoAXC8EX1NCX1BDSTBMUEMwTE5LQQoA Eh4EDP//HAAKAFwvBF9TQl9QQ0kwTFBDMExOS0IKABIeBAz//xwACgFcLwRfU0JfUENJMExQ QzBMTktBCgASHgQM//8cAAoCXC8EX1NCX1BDSTBMUEMwTE5LQwoAEh4EDP//HAAKA1wvBF9T Ql9QQ0kwTFBDMExOS0QKABIeBAz//x0ACgBcLwRfU0JfUENJMExQQzBMTktICgASHgQM//8d AAoBXC8EX1NCX1BDSTBMUEMwTE5LRAoAEh4EDP//HQAKAlwvBF9TQl9QQ0kwTFBDMExOS0MK ABIeBAz//x0ACgNcLwRfU0JfUENJMExQQzBMTktBCgASHgQM//8fAAoAXC8EX1NCX1BDSTBM UEMwTE5LQwoAEh4EDP//HwAKAVwvBF9TQl9QQ0kwTFBDMExOS0QKABIeBAz//x8ACgNcLwRf U0JfUENJMExQQzBMTktBCgChTwqkEksKDBINBAz//wEACgAKAAoQEg0EDP//HAAKAAoAChES DQQM//8cAAoBCgAKEBINBAz//xwACgIKAAoSEg0EDP//HAAKAwoAChMSDQQM//8dAAoACgAK FxINBAz//x0ACgEKAAoTEg0EDP//HQAKAgoAChISDQQM//8dAAoDCgAKEBINBAz//x8ACgAK AAoSEg0EDP//HwAKAQoAChMSDQQM//8fAAoDCgAKEBQJX1MzRACkCgIUCV9TNEQApAoCW4JC JERFVjEIX0FEUgwAAAEAW4JFFFBYSEEIX0FEUgoACF9QUlcSBgIKCwoFFEsSX1BSVACgRwyS XFBJQ0akEk0LBhIeBAz//wUACgBcLwRfU0JfUENJMExQQzBMTktBCgASHgQM//8FAAoBXC8E X1NCX1BDSTBMUEMwTE5LQgoAEh4EDP//BQAKAlwvBF9TQl9QQ0kwTFBDMExOS0MKABIeBAz/ /wUACgNcLwRfU0JfUENJMExQQzBMTktECgASHgQM//8GAAoAXC8EX1NCX1BDSTBMUEMwTE5L QwoAEh4EDP//BgAKAVwvBF9TQl9QQ0kwTFBDMExOS0QKAKFLBaQSRwUGEg0EDP//BQAKAAoA ChgSDQQM//8FAAoBCgAKGRINBAz//wUACgIKAAoaEg0EDP//BQAKAwoAChsSDQQM//8GAAoA CgAKGhINBAz//wYACgEKAAobW4JJDlBYSEIIX0FEUgoCCF9QUlcSBgIKCwoFFE8MX1BSVACg SQiSXFBJQ0akEk8HBBIeBAz//wIACgBcLwRfU0JfUENJMExQQzBMTktBCgASHgQM//8CAAoB XC8EX1NCX1BDSTBMUEMwTE5LQgoAEh4EDP//AgAKAlwvBF9TQl9QQ0kwTFBDMExOS0MKABIe BAz//wIACgNcLwRfU0JfUENJMExQQzBMTktECgChPaQSOgQSDQQM//8CAAoACgAKMBINBAz/ /wIACgEKAAoxEg0EDP//AgAKAgoACjISDQQM//8CAAoDCgAKM1uCTA1FWFAxCF9BRFIMAAAc AAhfUFJXEgYCCgkKBRRPC19QUlQAoEEIklxQSUNGpBJHBwQSHAQL//8KAFwvBF9TQl9QQ0kw TFBDMExOS0EKABIcBAv//woBXC8EX1NCX1BDSTBMUEMwTE5LQgoAEhwEC///CgJcLwRfU0Jf UENJMExQQzBMTktDCgASHAQL//8KA1wvBF9TQl9QQ0kwTFBDMExOS0QKAKE1pBIyBBILBAv/ /woACgAKEBILBAv//woBCgAKERILBAv//woCCgAKEhILBAv//woDCgAKE1uCTwVFWFA1CF9B RFIMBAAcAAhfUFJXEgYCCgkKBRRCBF9QUlQAoCiSXFBJQ0akEh8BEhwEC///CgBcLwRfU0Jf UENJMExQQzBMTktBCgChEaQSDgESCwQL//8KAAoAChBbgk8FRVhQNghfQURSDAUAHAAIX1BS VxIGAgoJCgUUQgRfUFJUAKAoklxQSUNGpBIfARIcBAv//woAXC8EX1NCX1BDSTBMUEMwTE5L QgoAoRGkEg4BEgsEC///CgAKAAoRW4JPC1BDSUIIX0FEUgwAAB4ACF9QUlcSBgIKCwoFFEIK X1BSVACgSgaSXFBJQ0akEkAGAxIeBAz//wIACgBcLwRfU0JfUENJMExQQzBMTktBCgASHgQM //8CAAoBXC8EX1NCX1BDSTBMUEMwTE5LQgoAEh4EDP//AQAKAFwvBF9TQl9QQ0kwTFBDMExO S0MKAKEvpBIsAxINBAz//wIACgAKAAoQEg0EDP//AgAKAQoAChESDQQM//8BAAoACgAKEluC ipIBTFBDMAhfQURSDAAAHwAIRFZFTgoAFApERUNEDHBoWzFbgksZTUJSRAhfSElEDEHQDAII X1VJRAofCFJTUkMRRxELEgFHARAAEAABEEcBJAAkAAECRwEoACgAAQJHASwALAABAkcBMAAw AAECRwE0ADQAAQJHATgAOAABAkcBPAA8AAECRwFyAHIAAQZHAYAAgAABAUcBkACQAAEQRwGk AKQAAQJHAagAqAABAkcBrACsAAECRwGwALAAAQZHAbgAuAABAkcBvAC8AAECRwGVApUCAQJH AQAIAAgBQEcBAAkACQEQRwEAEAAQAYBHAYARgBEBQEcBLgAuAAECRwHQBNAEAQJHAQD+AP4B AYYJAAEAQNH+AEAAAIYJAAEAMNH+ABAAAIYJAAEAgNH+AEAAAIYJAAEAAADwAAAABIYJAAEA ANL+AAAHAIYJAAEAAPD+AAAQAHkAFEYGX0NSUwCLUlNSQwqiUE1NTotSU1JDCqRQTU1Ye15e UE1CQQuA/1BNTU5wUE1NTlBNTViLUlNSQwqqR1BNTotSU1JDCqxHUE1Ye15eR1BCQQuA/0dQ TU5wR1BNTkdQTVikUlNSQ1uCNURNQUMIX0hJRAxB0AIACF9DUlMRIAodRwEAAAAAARBHAYEA gQABD0cBwADAAAEgKhACeQBbgiZNQVRICF9ISUQMQdAMBAhfQ1JTEREKDkcB8ADwAAEPIwAg AXkAW4IsUElDXwhfSElEC0HQCF9DUlMRGQoWRwEgACAAAQJHAaAAoAABAiMEAAF5AFuCQAVS VENfCF9ISUQMQdALAAhCVUYwEQ0KCkcBcABwAAECeQAIQlVGMREQCg1HAXAAcAABAiIAAXkA FBZfQ1JTCKAKSFBBRaRCVUYwpEJVRjFbgiJTUEtSCF9ISUQMQdAIAAhfQ1JTEQ0KCkcBYQBh AAEBeQBbgkAGVElNUghfSElEDEHQAQAIQlVGMBEVChJHAUAAQAABBEcBUABQABAEeQAIQlVG MREYChVHAUAAQAABBEcBUABQABAEIgEAeQAUFl9DUlMIoApIUEFFpEJVRjCkQlVGMVuCTgpN TVRNCF9ISUQMQdABAwhCVUYwERcKFCIBACIAAYYJAAAAAND+AAQAAHkAFChfU1RBAKATkpVP U1lTC9EHoAhIUEFFpAoPoQqgCEhQQUWkCgukCgAURwVfQ1JTCKBKBEhQQUWKQlVGMAoKSFBU MKASk0hQQVMKAXAMABDQ/khQVDCgEpNIUEFTCgJwDAAg0P5IUFQwoBKTSFBBUwoDcAwAMND+ SFBUMKRCVUYwW4JFC0xOS0EIX0hJRAxB0AwPCF9VSUQKAQhfUFJTEQkKBiMIzBh5AAhSU1JD EQkKBiMAABh5ABQRX0RJUwB9UElSQQqAUElSQRQtX0NSUwCLUlNSQwoBSVJRMHtQSVJBCg9g eQoBYElSUTBwUlNSQ1sxpFJTUkMUKF9TUlMBcGhbMYtoCgFJUlEwgklSUTBgdmB9YHtQSVJB CnAAUElSQRQWX1NUQQCgDHtQSVJBCoAApAoJpAoLW4JKCkxOS0IIX0hJRAxB0AwPCF9VSUQK AghfUFJTEQkKBiMIzBh5AAhSU1JDEQkKBiMAABh5ABQRX0RJUwB9UElSQgqAUElSQhQmX0NS UwCLUlNSQwoBSVJRMHtQSVJCCg9geQoBYElSUTCkUlNSQxQkX1NSUwGLaAoBSVJRMIJJUlEw YHZgfWB7UElSQgpwAFBJUkIUFl9TVEEAoAx7UElSQgqAAKQKCaQKC1uCSgpMTktDCF9ISUQM QdAMDwhfVUlECgMIX1BSUxEJCgYjCMwYeQAIUlNSQxEJCgYjAAAYeQAUEV9ESVMAfVBJUkMK gFBJUkMUJl9DUlMAi1JTUkMKAUlSUTB7UElSQwoPYHkKAWBJUlEwpFJTUkMUJF9TUlMBi2gK AUlSUTCCSVJRMGB2YH1ge1BJUkMKcABQSVJDFBZfU1RBAKAMe1BJUkMKgACkCgmkCgtbgkoK TE5LRAhfSElEDEHQDA8IX1VJRAoECF9QUlMRCQoGIwjMGHkACFJTUkMRCQoGIwAAGHkAFBFf RElTAH1QSVJECoBQSVJEFCZfQ1JTAItSU1JDCgFJUlEwe1BJUkQKD2B5CgFgSVJRMKRSU1JD FCRfU1JTAYtoCgFJUlEwgklSUTBgdmB9YHtQSVJECnAAUElSRBQWX1NUQQCgDHtQSVJECoAA pAoJpAoLW4JFC0xOS0UIX0hJRAxB0AwPCF9VSUQKBQhfUFJTEQkKBiMIzBh5AAhSU1JDEQkK BiMAABh5ABQRX0RJUwB9UElSRQqAUElSRRQtX0NSUwCLUlNSQwoBSVJRMHtQSVJFCg9geQoB YElSUTBwUlNSQ1sxpFJTUkMUKF9TUlMBcGhbMYtoCgFJUlEwgklSUTBgdmB9YHtQSVJFCnAA UElSRRQWX1NUQQCgDHtQSVJFCoAApAoJpAoLW4JFC0xOS0YIX0hJRAxB0AwPCF9VSUQKBghf UFJTEQkKBiMIzBh5AAhSU1JDEQkKBiMAABh5ABQRX0RJUwB9UElSRgqAUElSRhQtX0NSUwCL UlNSQwoBSVJRMHtQSVJGCg9geQoBYElSUTBwUlNSQ1sxpFJTUkMUKF9TUlMBcGhbMYtoCgFJ UlEwgklSUTBgdmB9YHtQSVJGCnAAUElSRhQWX1NUQQCgDHtQSVJGCoAApAoJpAoLW4JFC0xO S0cIX0hJRAxB0AwPCF9VSUQKBwhfUFJTEQkKBiMIzBh5AAhSU1JDEQkKBiMAABh5ABQRX0RJ UwB9UElSRwqAUElSRxQtX0NSUwCLUlNSQwoBSVJRMHtQSVJHCg9geQoBYElSUTBwUlNSQ1sx pFJTUkMUKF9TUlMBcGhbMYtoCgFJUlEwgklSUTBgdmB9YHtQSVJHCnAAUElSRxQWX1NUQQCg DHtQSVJHCoAApAoJpAoLW4JFC0xOS0gIX0hJRAxB0AwPCF9VSUQKCAhfUFJTEQkKBiMIzBh5 AAhSU1JDEQkKBiMAABh5ABQRX0RJUwB9UElSSAqAUElSSBQtX0NSUwCLUlNSQwoBSVJRMHtQ SVJICg9geQoBYElSUTBwUlNSQ1sxpFJTUkMUKF9TUlMBcGhbMYtoCgFJUlEwgklSUTBgdmB9 YHtQSVJICnAAUElSSBQWX1NUQQCgDHtQSVJICoAApAoJpAoLW4BHUE9YAQuAEQowW4EiR1BP WAMAOAADSU8yNwEAPAADTFYyNwEATAUAA0JMMjcBW4BQSVJYAgpgCgRbgR1QSVJYEwEBAFBJ UkEIUElSQghQSVJDCFBJUkQIW4BQSVJZAgpoCgRbgR1QSVJZEwEBAFBJUkUIUElSRghQSVJH CFBJUkgIW4BFTFIwAgqgChRbgUIFRUxSMBMACVBCTFYBAEYHAAFFTFNTAQABRUxTVAFFTFBC AQADAAFFTExPAUVMR04CRUxZTAJFTEJFAUVMSUUBRUxTTgFFTE9DAQAGRUxTTwFbgFJPVVQB CrgKBFuBSgVST1VUEwEBAEdQSTACR1BJMQJHUEkyAkdQSTMCR1BJNAJHUEk1AkdQSTYCR1BJ NwJHUEk4AkdQSTkCR1AxMAJHUDExAkdQMTICR1AxMwJHUDE0AkdQMTUCW4BQTUlPAQsAEAow W4EcUE1JTwIBAwAASBYABEdQRVMBAAsABEdQRUUBW4BSRUdTAgpAChBbgRJSRUdTE1BNQkEQ ADBHUEJBEFuCJkZXSF8IX0hJRAwl1AgACF9DUlMREQoOhgkAAAAAgP8AAIAAeQBbgkHgU0lP XwhfSElEDEHQCgVbAVc2MjcAW4BTSUJQAQouCgJbgQtTSUJQAUJQSU8IW4BTSUlPAQouCgJb gRBTSUlPAUlORFgIREFUQQhbhkoHSU5EWERBVEEBADhMRE5fCABADVBPV18IAEgGQUNUXwEA TxdJT0JICElPQkwISU8ySAhJTzJMCABABklOVF8EABxETUFTAwBNNVowMDkIABhaMDBBCABI BU1PREUDAAUAA0lSTUQDAAoABlNMRUQCAAgABlBMRUQCFBpDRkdfAXAKh0JQSU9wCodCUElP cGhMRE5fFA1YQ0ZHAHAKqkJQSU8UPlNUQV8BWyNXNjI3AFBDRkdfaHAKAGGgCUFDVF9wCg9h oRCgDpFJT0JISU9CTHAKDWFYQ0ZHWydXNjI3pGEUJ0RJU18BWyNXNjI3iBNDRkdfaHAKAEFD VF9YQ0ZHWydXNjI3pAoAFCdQUzBfAVsjVzYyN4gTQ0ZHX2hwCgFBQ1RfWENGR1snVzYyN6QK ABQnUFMzXwFbI1c2MjeIE0NGR19ocAoAQUNUX1hDRkdbJ1c2MjekCgBbgjpLQkMwCF9ISUQM QdADAwhfQ1JTERkKFkcBYABgAAEBRwFkAGQAAQEjAgABeQAIX1BSVxIGAgodCgFbgipNU0Uw CF9ISUQMQdAPEwhfQ1JTEQkKBiMAEAF5AAhfUFJXEgYCCh0KAVuCQh1DT00xCF9ISUQMQdAF AQhfVUlECgEUEF9TVEEAcFNUQV8KAmGkYRQMX0RJUwBESVNfCgIUSQpfQ1JTAAhSU1JDERAK DUcBAAAAAAgIIgAAeQCMUlNSQwoCSU8xX4xSU1JDCgNJTzJfjFJTUkMKBElPM1+MUlNSQwoF SU80X4tSU1JDCglJUlFWWyNXNjI3iBNDRkdfCgKgN0FDVF9wSU9CTElPMV9wSU9CSElPMl9w SU9CTElPM19wSU9CSElPNF9wCgFgeWBJTlRfSVJRVlhDRkdbJ1c2MjekUlNSQwhfUFJTEUQH CnAxAEcB+AP4AwEIIxAAATBHAfgC+AIBCCMIAAEwRwHoA+gDAQgjEAABMEcB6ALoAgEIIwgA ATEKRwH4A/gDAQgjCAABMQpHAfgC+AIBCCMQAAExCkcB6APoAwEIIwgAATEKRwHoAugCAQgj EAABOHkAFE4FX1NSUwGMaAoCSU8xX4xoCgNJTzJfi2gKCUlSUVZbI1c2MjeIE0NGR18KAnBJ TzFfSU9CTHBJTzJfSU9CSIJJUlFWYHRgCgFJTlRfcAoBQUNUX1hDRkdbJ1c2MjcUDF9QUzAA UFMwXwoCFAxfUFMzAFBTM18KAluCQiBDT00yFDlfSElEAFsjVzYyN4gTQ0ZHXwoDoA+QSVJN RAo4cAxB0AUQYaEIcAxB0AUBYVhDRkdbJ1c2MjekYQhfVUlECgIUEF9TVEEAcFNUQV8KA2Gk YRQMX0RJUwBESVNfCgMUSQpfQ1JTAAhSU1JDERAKDUcBAAAAAAgIIgAAeQCMUlNSQwoCSU8x X4xSU1JDCgNJTzJfjFJTUkMKBElPM1+MUlNSQwoFSU80X4tSU1JDCglJUlFWWyNXNjI3iBND RkdfCgOgN0FDVF9wSU9CTElPMV9wSU9CSElPMl9wSU9CTElPM19wSU9CSElPNF9wCgFgeWBJ TlRfSVJRVlhDRkdbJ1c2MjekUlNSQwhfUFJTEUQHCnAwRwH4A/gDAQgjEAABMQBHAfgC+AIB CCMIAAEwRwHoA+gDAQgjEAABMEcB6ALoAgEIIwgAATEKRwH4A/gDAQgjCAABMQpHAfgC+AIB CCMQAAExCkcB6APoAwEIIwgAATEKRwHoAugCAQgjEAABOHkAFE4FX1NSUwGMaAoCSU8xX4xo CgNJTzJfi2gKCUlSUVZbI1c2MjeIE0NGR18KA3BJTzFfSU9CTHBJTzJfSU9CSIJJUlFWYHRg CgFJTlRfcAoBQUNUX1hDRkdbJ1c2MjcUDF9QUzAAUFMwXwoDFAxfUFMzAFBTM18KA1uCRSJG RENfCF9ISUQMQdAHAAhfVUlECgEUEF9TVEEAcFNUQV8KAGGkYRQMX0RJUwBESVNfCgAUQhJf Q1JTAAhSU1JDERsKGEcBAAAAAAEGRwEAAAAAAQEiAAAqAAB5AFsjVzYyN4gTQ0ZHXwoAoEwN QUNUX4xSU1JDCgJJTzFfjFJTUkMKA0lPMl+MUlNSQwoESU8zX4xSU1JDCgVJTzRfjFJTUkMK CklPNV+MUlNSQwoLSU82X4xSU1JDCgxJTzdfjFJTUkMKDUlPOF+LUlNSQwoRSVJRVoxSU1JD ChRETUFWcElPQkxJTzFfcElPQkhJTzJfcElPQkxJTzNfcElPQkhJTzRfcklPQkwKB0lPNV9w SU9CSElPNl9ySU9CTAoHSU83X3BJT0JISU84X3AKAWB5YElOVF9JUlFWcAoBYHlgRE1BU0RN QVZYQ0ZHWydXNjI3pFJTUkMIX1BSUxE4CjUxAEcB8APwAwEGRwH3A/cDAQEjQAABKgQAMQBH AXADcAMBBkcBdwN3AwEBI0AAASoEADh5ABREB19TUlMBjGgKAklPMV+MaAoDSU8yX4toChFJ UlFWjGgKFERNQVZbI1c2MjeIE0NGR18KAHBJTzFfSU9CTHBJTzJfSU9CSIJJUlFWYHRgCgFJ TlRfgkRNQVZgdGAKAURNQVNwCgFBQ1RfWENGR1snVzYyNxQMX1BTMABQUzBfCgAUDF9QUzMA UFMzXwoAW4JCUlBSVF8UOV9ISUQAWyNXNjI3iBNDRkdfCgGgD5NNT0RFCgJwDEHQBAFhoQhw DEHQBABhWENGR1snVzYyN6RhCF9VSUQKAhQQX1NUQQBwU1RBXwoBYaRhFAxfRElTAERJU18K ARRIJF9DUlMAWyNXNjI3iBNDRkdfCgEIQ1JTQREQCg1HAQAAAAABCCIAAHkAjENSU0EKAklP QTGMQ1JTQQoDSU9BMoxDUlNBCgRJT0EzjENSU0EKBUlPQTSMQ1JTQQoGQUxBMYxDUlNBCgdM TkExi0NSU0EKCUlSUUEIQ1JTQhEbChhHAQAAAAABCEcBAAAAAAEIIgAAKgACeQCMQ1JTQgoC SU9CMYxDUlNCCgNJT0IyjENSU0IKBElPQjOMQ1JTQgoFSU9CNIxDUlNCCgZBTEIxjENSU0IK B0xOQjGMQ1JTQgoKSU9CNYxDUlNCCgtJT0I2jENSU0IKDElPQjeMQ1JTQgoNSU9COIxDUlNC Cg5BTEIyjENSU0IKD0xOQjKLQ1JTQgoRSVJRQotDUlNCChRETUFWoEMPQUNUX6BLCZNNT0RF CgJwSU9CTElPQjFwSU9CSElPQjJwSU9CTElPQjNwSU9CSElPQjRwSU9CTElPQjVySU9CSAoE SU9CNnBJT0JMSU9CN3JJT0JICgRJT0I4oCSTSU9CTAq8cAoBQUxCMXAKBExOQjFwCgFBTEIy cAoETE5CMnAKAWB5YElOVF9JUlFCcAoBYHlgRE1BU0RNQVakQ1JTQqFABXBJT0JMSU9BMXBJ T0JISU9BMnBJT0JMSU9BM3BJT0JISU9BNHAKAWB5YElOVF9JUlFBoBaTSU9CTAq8cAoBQUxB MXAKBExOQTGkQ1JTQaEWoA2TTU9ERQoCpENSU0KhBqRDUlNBWENGR1snVzYyNwhQUlNBEUUF ClEwRwF4A3gDAQgjgAABMEcBeAN4AwEIIyAAATBHAXgCeAIBCCOAAAEwRwF4AngCAQgjIAAB MEcBvAO8AwEEI4AAATBHAbwDvAMBBCMgAAE4eQAIUFJTQhFHCQqTMEcBeAN4AwEIRwF4B3gH AQgjgAABKgsCMEcBeAN4AwEIRwF4B3gHAQgjIAABKgsCMEcBeAJ4AgEIRwF4BngGAQgjgAAB KgsCMEcBeAJ4AgEIRwF4BngGAQgjIAABKgsCMEcBvAO8AwEERwG8B7wHAQQjgAABKgsCMEcB vAO8AwEERwG8B7wHAQQjIAABKgsCOHkAFDdfUFJTAFsjVzYyN4gTQ0ZHXwoBoA6TTU9ERQoC cFBSU0JgoQdwUFJTQWBYQ0ZHWydXNjI3pGAUSRJfU1JTAVsjVzYyN4gTQ0ZHXwoBoEcKk01P REUKAoxoCgJJT0IxjGgKA0lPQjKMaAoESU9CM4xoCgVJT0I0jGgKBkFMQjGMaAoHTE5CMYxo CgpJT0I1jGgKC0lPQjaMaAoMSU9CN4xoCg1JT0I4jGgKDkFMQjKMaAoPTE5CMotoChFJUlFC i2gKFERNQVZwSU9CMUlPQkxwSU9CMklPQkiBSVJRQmB0YAoBSU5UX4FETUFWYHRgCgFETUFT oUoFjGgKAklPQTGMaAoDSU9BMoxoCgRJT0EzjGgKBUlPQTSMaAoGQUxBMYxoCgdMTkExi2gK CUlSUUFwSU9BMUlPQkxwSU9BMklPQkiBSVJRQWB0YAoBSU5UX3AKAUFDVF9YQ0ZHWydXNjI3 FAxfUFMwAFBTMF8KARQMX1BTMwBQUzNfCgEURwVFTldLAFsjVzYyN4gTQ0ZHXwoKcAoAQUNU X3AKAUFDVF9wCvNJTkRYcAo/REFUQXAK9klORFhwCjBEQVRBcAr5SU5EWHAKBURBVEFYQ0ZH WydXNjI3FEAFRFNXSwBbI1c2MjeIE0NGR18KCnAKAEFDVF9wCvZJTkRYcAoAREFUQXAK+UlO RFhwCgBEQVRBcArzSU5EWHAKP0RBVEFYQ0ZHWydXNjI3FCRDTEVEAVsjVzYyN4gTQ0ZHXwoJ cGhTTEVEWENGR1snVzYyNwhOQVRBEgwCDAEAHwAMAgAfABRHBEdFVFABo6APk3toCgkACgCk DP////+gDZN7aAoJAAoIpAuEA3p7aAsAAwAKCGB6e2gLADAACgxhpHcKHnQKCXJgYQAAABQt R0VURASjoB9ooAVppAoUoAxqpHd0CgRrAAoPAKR3dAoEawAKHgCkDP////8UIEdFVFQBo6R3 Ch50Cglye3poCgIACgMAe2gKAwAAAAAURwZHRVRGA6MIVE1QRgoAoA1ofVRNUEYKAVRNUEag EXtqCgIAfVRNUEYKAlRNUEagDWl9VE1QRgoEVE1QRqARe2oKIAB9VE1QRgoIVE1QRqASe2oL AEAAfVRNUEYKEFRNUEakVE1QRhRBBFNFVFADo6AJkpVoCvCkCgihLqAoe2kKAgCgEJCSlGgK eHtqCgIApAsBI6AQkJKUaAq0e2oKAQCkCwEhpAsBEBQ8U0VURAGjoAmSlGgKFKQKAaAJkpRo Ch6kCgKgCZKUaAotpAoBoAmSlGgKPKQKAqAJkpRoClqkCgGkCgAUMVNFVFQDo6Ame2kKAgCg D5CSlGgKeHtqCgIApAoLoA+QkpRoCrR7agoBAKQKCaQKBFuCQNJJREVDCF9BRFIMAQAfAFuA SURFQwIKQAoYW4FPBUlERUMDUFJJVBBTRUNUEFBTSVQEU1NJVAQAGFNETUEEAAxTRFQwAgAC U0RUMQIAAlNEVDICAAJTRFQzAgBCBElDUjAESUNSMQRJQ1IyBElDUjMESUNSNARJQ1I1BFuC QGVQUklECF9BRFIKABRKE19HVE0AowhQQlVGERcKFAAAAAAAAAAAAAAAAAAAAAAAAAAAilBC VUYKAFBJTzCKUEJVRgoERE1BMIpQQlVGCghQSU8xilBCVUYKDERNQTGKUEJVRgoQRkxBR3BH RVRQUFJJVFBJTzBwR0VURHtTRE1BCgEAe0lDUjMKAQB7SUNSMAoBAFNEVDBETUEwoBSTRE1B MAz/////cFBJTzBETUEwoC57UFJJVAsAQACgFJN7UFJJVAqQAAqAcAuEA1BJTzGhDnBHRVRU UFNJVFBJTzGhC3AM/////1BJTzFwR0VURHtTRE1BCgIAe0lDUjMKAgB7SUNSMAoCAFNEVDFE TUExoBSTRE1BMQz/////cFBJTzFETUExcEdFVEZ7U0RNQQoBAHtTRE1BCgIAUFJJVEZMQUek UEJVRhRAL19TVE0Do4poCgBQSU8wimgKBERNQTCKaAoIUElPMYpoCgxETUEximgKEEZMQUdw CgRJQ1IyoE4Tk4dpCwACe1BSSVQL8ExQUklUe1NETUEKDlNETUFwCgBTRFQwe0lDUjAKDklD UjB7SUNSMQoOSUNSMXtJQ1IzCg5JQ1Ize0lDUjUKDklDUjWLaQpiVzQ5MItpCmpXNTMwi2kK flc2MzCLaQqAVzY0MItpCrBXODgwfVBSSVQLBIBQUklUoB6Qe0ZMQUcKAgB7VzQ5MAsACAB9 UFJJVAoCUFJJVH1QUklUU0VUUFBJTzBXNTMwVzY0MFBSSVSgTwd7RkxBRwoBAH1TRE1BCgFT RE1BcFNFVERETUEwU0RUMKAfe1c4ODAKIAB9SUNSMQoBSUNSMX1JQ1I1CgFJQ1I1oBR7Vzg4 MAoQAH1JQ1IxCgFJQ1IxoBOVRE1BMAoefUlDUjMKAUlDUjOgE5VETUEwCjx9SUNSMAoBSUNS MKBJF5OHagsAAntQUklUCw8/UFJJVHAKAFBTSVR7U0RNQQoNU0RNQXAKAFNEVDF7SUNSMAoN SUNSMHtJQ1IxCg1JQ1Ixe0lDUjMKDUlDUjN7SUNSNQoNSUNSNYtqCmJXNDkxi2oKalc1MzGL agp+VzYzMYtqCoBXNjQxi2oKsFc4ODF9UFJJVAtAgFBSSVSgHpB7RkxBRwoIAHtXNDkxCwAI AH1QUklUCiBQUklUoEwEe0ZMQUcKEAB9UFJJVAsAQFBSSVSgE5RQSU8xCvB9UFJJVAqAUFJJ VKEhfVBSSVQKEFBSSVRwU0VUVFBJTzFXNTMxVzY0MVBTSVSgTwd7RkxBRwoEAH1TRE1BCgJT RE1BcFNFVERETUExU0RUMaAfe1c4ODEKIAB9SUNSMQoCSUNSMX1JQ1I1CgJJQ1I1oBR7Vzg4 MQoQAH1JQ1IxCgJJQ1IxoBOVRE1BMAoefUlDUjMKAklDUjOgE5VETUEwCjx9SUNSMAoCSUNS MBQHX1BTMACjFAdfUFMzAKNbgkQQUF9EMAhfQURSCgAURg9fR1RGAKMIUElCMBERCg4DAAAA AKDvAwAAAACg74xQSUIwCgFQTUQwjFBJQjAKCERNRDCgQAZ7UFJJVAoCAKATk3tQUklUCgkA CghwCghQTUQwoUEEcAoKUE1EMHp7UFJJVAsAAwAKCGB6e1BSSVQLADAACgxhcmBhYqAMkwoD YnAKC1BNRDCgDJMKBWJwCgxQTUQwoQhwCgFQTUQwoDx7U0RNQQoBAHB9U0RUMApAAERNRDCg FHtJQ1IwCgEAckRNRDAKAkRNRDCgEHtJQ1IzCgEAcApFRE1EMKEUfXR7UE1EMAoHAAoCAAog RE1EMKRQSUIwW4JPD1BfRDEIX0FEUgoBFEEPX0dURgCjCFBJQjEREQoOAwAAAACw7wMAAAAA sO+MUElCMQoBUE1EMYxQSUIxCghETUQxoEsFe1BSSVQKIACgE5N7UFJJVAqQAAqAcAoIUE1E MaE8cntQU0lUCgMAentQU0lUCgwACgIAYKAMkwoFYHAKDFBNRDGhF6AMkwoDYHAKC1BNRDGh CHAKClBNRDGhCHAKAVBNRDGgPHtTRE1BCgIAcH1TRFQxCkAARE1EMaAUe0lDUjAKAgByRE1E MQoCRE1EMaAQe0lDUjMKAgBwCkVETUQxoRR9dHtQTUQxCgcACgIACiBETUQxpFBJQjFbgkBl U0VDRAhfQURSCgEUShNfR1RNAKMIU0JVRhEXChQAAAAAAAAAAAAAAAAAAAAAAAAAAIpTQlVG CgBQSU8wilNCVUYKBERNQTCKU0JVRgoIUElPMYpTQlVGCgxETUExilNCVUYKEEZMQUdwR0VU UFNFQ1RQSU8wcEdFVER7U0RNQQoEAHtJQ1IzCgQAe0lDUjAKBABTRFQyRE1BMKAUk0RNQTAM /////3BQSU8wRE1BMKAue1NFQ1QLAEAAoBSTe1NFQ1QKkAAKgHALhANQSU8xoQ5wR0VUVFNT SVRQSU8xoQtwDP////9QSU8xcEdFVER7U0RNQQoIAHtJQ1IzCggAe0lDUjAKCABTRFQzRE1B MaAUk0RNQTEM/////3BQSU8xRE1BMXBHRVRGe1NETUEKBAB7U0RNQQoIAFNFQ1RGTEFHpFNC VUYUQC9fU1RNA6OKaAoAUElPMIpoCgRETUEwimgKCFBJTzGKaAoMRE1BMYpoChBGTEFHcAoE SUNSMqBOE5OHaQsAAntTRUNUC/BMU0VDVHtTRE1BCgtTRE1BcAoAU0RUMntJQ1IwCgtJQ1Iw e0lDUjEKC0lDUjF7SUNSMwoLSUNSM3tJQ1I1CgtJQ1I1i2kKYlc0OTCLaQpqVzUzMItpCn5X NjMwi2kKgFc2NDCLaQqwVzg4MH1TRUNUCwSAU0VDVKAekHtGTEFHCgIAe1c0OTALAAgAfVNF Q1QKAlNFQ1R9U0VDVFNFVFBQSU8wVzUzMFc2NDBTRUNUoE8He0ZMQUcKAQB9U0RNQQoEU0RN QXBTRVRERE1BMFNEVDKgH3tXODgwCiAAfUlDUjEKBElDUjF9SUNSNQoESUNSNaAUe1c4ODAK EAB9SUNSMQoESUNSMaATlURNQTAKHn1JQ1IzCgRJQ1IzoBOVRE1BMAo8fUlDUjAKBElDUjCg SReTh2oLAAJ7U0VDVAsPP1NFQ1RwCgBTU0lUe1NETUEKB1NETUFwCgBTRFQze0lDUjAKB0lD UjB7SUNSMQoHSUNSMXtJQ1IzCgdJQ1Ize0lDUjUKB0lDUjWLagpiVzQ5MYtqCmpXNTMxi2oK flc2MzGLagqAVzY0MYtqCrBXODgxfVNFQ1QLQIBTRUNUoB6Qe0ZMQUcKCAB7VzQ5MQsACAB9 U0VDVAogU0VDVKBMBHtGTEFHChAAfVNFQ1QLAEBTRUNUoBOUUElPMQrwfVNFQ1QKgFNFQ1Sh IX1TRUNUChBTRUNUcFNFVFRQSU8xVzUzMVc2NDFTU0lUoE8He0ZMQUcKBAB9U0RNQQoIU0RN QXBTRVRERE1BMVNEVDOgH3tXODgxCiAAfUlDUjEKCElDUjF9SUNSNQoISUNSNaAUe1c4ODEK EAB9SUNSMQoISUNSMaATlURNQTAKHn1JQ1IzCghJQ1IzoBOVRE1BMAo8fUlDUjAKCElDUjAU B19QUzAAoxQHX1BTMwCjW4JEEFNfRDAIX0FEUgoAFEYPX0dURgCjCFNJQjAREQoOAwAAAACg 7wMAAAAAoO+MU0lCMAoBUE1EMIxTSUIwCghETUQwoEAGe1NFQ1QKAgCgE5N7U0VDVAoJAAoI cAoIUE1EMKFBBHAKClBNRDB6e1NFQ1QLAAMACghgentTRUNUCwAwAAoMYXJgYWKgDJMKA2Jw CgtQTUQwoAyTCgVicAoMUE1EMKEIcAoBUE1EMKA8e1NETUEKBABwfVNEVDIKQABETUQwoBR7 SUNSMAoEAHJETUQwCgJETUQwoBB7SUNSMwoEAHAKRURNRDChFH10e1BNRDAKBwAKAgAKIERN RDCkU0lCMFuCTw9TX0QxCF9BRFIKARRBD19HVEYAowhTSUIxEREKDgMAAAAAsO8DAAAAALDv jFNJQjEKAVBNRDGMU0lCMQoIRE1EMaBLBXtTRUNUCiAAoBOTe1NFQ1QKkAAKgHAKCFBNRDGh PHJ7U1NJVAoDAHp7U1NJVAoMAAoCAGCgDJMKBWBwCgxQTUQxoRegDJMKA2BwCgtQTUQxoQhw CgpQTUQxoQhwCgFQTUQxoDx7U0RNQQoIAHB9U0RUMwpAAERNRDGgFHtJQ1IwCggAckRNRDEK AkRNRDGgEHtJQ1IzCggAcApFRE1EMaEUfXR7UE1EMQoHAAoCAAogRE1EMaRTSUIxW4JD2klE RTEIX0FEUgwCAB8AW4BJREUxAgqQCgNbgRJJREUxA01BUF8IAAhQQ1NfCFuASURFQwIKQAoY W4FPBUlERUMDUFJJVBBTRUNUEFBTSVQEU1NJVAQAGFNETUEEAAxTRFQwAgACU0RUMQIAAlNE VDICAAJTRFQzAgBCBElDUjAESUNSMQRJQ1IyBElDUjMESUNSNARJQ1I1BBRHBkNUWVABcABg oDFooBSQlE1BUF8KAZVNQVBfCgZwCgFgoRmgC5NNQVBfAHAKA2CgC5NNQVBfAXAKBGChKKAM lE1BUF8KBXAKAmChGaALk01BUF8AcAoFYKALk01BUF8BcAoGYKRgW4JOZFBSSUQIX0FEUgoA FEoTX0dUTQCjCFBCVUYRFwoUAAAAAAAAAAAAAAAAAAAAAAAAAACKUEJVRgoAUElPMIpQQlVG CgRETUEwilBCVUYKCFBJTzGKUEJVRgoMRE1BMYpQQlVGChBGTEFHcEdFVFBQUklUUElPMHBH RVREe1NETUEKAQB7SUNSMwoBAHtJQ1IwCgEAU0RUMERNQTCgFJNETUEwDP////9wUElPMERN QTCgLntQUklUCwBAAKAUk3tQUklUCpAACoBwC4QDUElPMaEOcEdFVFRQU0lUUElPMaELcAz/ ////UElPMXBHRVREe1NETUEKAgB7SUNSMwoCAHtJQ1IwCgIAU0RUMURNQTGgFJNETUExDP// //9wUElPMURNQTFwR0VURntTRE1BCgEAe1NETUEKAgBQUklURkxBR6RQQlVGFEAvX1NUTQOj imgKAFBJTzCKaAoERE1BMIpoCghQSU8ximgKDERNQTGKaAoQRkxBR3AKBElDUjKgThOTh2kL AAJ7UFJJVAvwTFBSSVR7U0RNQQoOU0RNQXAKAFNEVDB7SUNSMAoOSUNSMHtJQ1IxCg5JQ1Ix e0lDUjMKDklDUjN7SUNSNQoOSUNSNYtpCmJXNDkwi2kKalc1MzCLaQp+VzYzMItpCoBXNjQw i2kKsFc4ODB9UFJJVAsEgFBSSVSgHpB7RkxBRwoCAHtXNDkwCwAIAH1QUklUCgJQUklUfVBS SVRTRVRQUElPMFc1MzBXNjQwUFJJVKBPB3tGTEFHCgEAfVNETUEKAVNETUFwU0VURERNQTBT RFQwoB97Vzg4MAogAH1JQ1IxCgFJQ1IxfUlDUjUKAUlDUjWgFHtXODgwChAAfUlDUjEKAUlD UjGgE5VETUEwCh59SUNSMwoBSUNSM6ATlURNQTAKPH1JQ1IwCgFJQ1IwoEkXk4dqCwACe1BS SVQLDz9QUklUcAoAUFNJVHtTRE1BCg1TRE1BcAoAU0RUMXtJQ1IwCg1JQ1Iwe0lDUjEKDUlD UjF7SUNSMwoNSUNSM3tJQ1I1Cg1JQ1I1i2oKYlc0OTGLagpqVzUzMYtqCn5XNjMxi2oKgFc2 NDGLagqwVzg4MX1QUklUC0CAUFJJVKAekHtGTEFHCggAe1c0OTELAAgAfVBSSVQKIFBSSVSg TAR7RkxBRwoQAH1QUklUCwBAUFJJVKATlFBJTzEK8H1QUklUCoBQUklUoSF9UFJJVAoQUFJJ VHBTRVRUUElPMVc1MzFXNjQxUFNJVKBPB3tGTEFHCgQAfVNETUEKAlNETUFwU0VURERNQTFT RFQxoB97Vzg4MQogAH1JQ1IxCgJJQ1IxfUlDUjUKAklDUjWgFHtXODgxChAAfUlDUjEKAklD UjGgE5VETUEwCh59SUNSMwoCSUNSM6ATlURNQTAKPH1JQ1IwCgJJQ1IwFAZfUFMwABQGX1BT MwBbgkQQUF9EMAhfQURSCgAURg9fR1RGAKMIUElCMBERCg4DAAAAAKDvAwAAAACg74xQSUIw CgFQTUQwjFBJQjAKCERNRDCgQAZ7UFJJVAoCAKATk3tQUklUCgkACghwCghQTUQwoUEEcAoK UE1EMHp7UFJJVAsAAwAKCGB6e1BSSVQLADAACgxhcmBhYqAMkwoDYnAKC1BNRDCgDJMKBWJw CgxQTUQwoQhwCgFQTUQwoDx7U0RNQQoBAHB9U0RUMApAAERNRDCgFHtJQ1IwCgEAckRNRDAK AkRNRDCgEHtJQ1IzCgEAcApFRE1EMKEUfXR7UE1EMAoHAAoCAAogRE1EMKRQSUIwW4JPD1Bf RDEIX0FEUgoBFEEPX0dURgCjCFBJQjEREQoOAwAAAACw7wMAAAAAsO+MUElCMQoBUE1EMYxQ SUIxCghETUQxoEsFe1BSSVQKIACgE5N7UFJJVAqQAAqAcAoIUE1EMaE8cntQU0lUCgMAentQ U0lUCgwACgIAYKAMkwoFYHAKDFBNRDGhF6AMkwoDYHAKC1BNRDGhCHAKClBNRDGhCHAKAVBN RDGgPHtTRE1BCgIAcH1TRFQxCkAARE1EMaAUe0lDUjAKAgByRE1EMQoCRE1EMaAQe0lDUjMK AgBwCkVETUQxoRR9dHtQTUQxCgcACgIACiBETUQxpFBJQjFbgk5kU0VDRAhfQURSCgEUShNf R1RNAKMIU0JVRhEXChQAAAAAAAAAAAAAAAAAAAAAAAAAAIpTQlVGCgBQSU8wilNCVUYKBERN QTCKU0JVRgoIUElPMYpTQlVGCgxETUExilNCVUYKEEZMQUdwR0VUUFNFQ1RQSU8wcEdFVER7 U0RNQQoEAHtJQ1IzCgQAe0lDUjAKBABTRFQyRE1BMKAUk0RNQTAM/////3BQSU8wRE1BMKAu e1NFQ1QLAEAAoBSTe1NFQ1QKkAAKgHALhANQSU8xoQ5wR0VUVFNTSVRQSU8xoQtwDP////9Q SU8xcEdFVER7U0RNQQoIAHtJQ1IzCggAe0lDUjAKCABTRFQzRE1BMaAUk0RNQTEM/////3BQ SU8xRE1BMXBHRVRGe1NETUEKBAB7U0RNQQoIAFNFQ1RGTEFHpFNCVUYUQC9fU1RNA6OKaAoA UElPMIpoCgRETUEwimgKCFBJTzGKaAoMRE1BMYpoChBGTEFHcAoESUNSMqBOE5OHaQsAAntT RUNUC/BMU0VDVHtTRE1BCgtTRE1BcAoAU0RUMntJQ1IwCgtJQ1Iwe0lDUjEKC0lDUjF7SUNS MwoLSUNSM3tJQ1I1CgtJQ1I1i2kKYlc0OTCLaQpqVzUzMItpCn5XNjMwi2kKgFc2NDCLaQqw Vzg4MH1TRUNUCwSAU0VDVKAekHtGTEFHCgIAe1c0OTALAAgAfVNFQ1QKAlNFQ1R9U0VDVFNF VFBQSU8wVzUzMFc2NDBTRUNUoE8He0ZMQUcKAQB9U0RNQQoEU0RNQXBTRVRERE1BMFNEVDKg H3tXODgwCiAAfUlDUjEKBElDUjF9SUNSNQoESUNSNaAUe1c4ODAKEAB9SUNSMQoESUNSMaAT lURNQTAKHn1JQ1IzCgRJQ1IzoBOVRE1BMAo8fUlDUjAKBElDUjCgSReTh2oLAAJ7U0VDVAsP P1NFQ1RwCgBTU0lUe1NETUEKB1NETUFwCgBTRFQze0lDUjAKB0lDUjB7SUNSMQoHSUNSMXtJ Q1IzCgdJQ1Ize0lDUjUKB0lDUjWLagpiVzQ5MYtqCmpXNTMxi2oKflc2MzGLagqAVzY0MYtq CrBXODgxfVNFQ1QLQIBTRUNUoB6Qe0ZMQUcKCAB7VzQ5MQsACAB9U0VDVAogU0VDVKBMBHtG TEFHChAAfVNFQ1QLAEBTRUNUoBOUUElPMQrwfVNFQ1QKgFNFQ1ShIX1TRUNUChBTRUNUcFNF VFRQSU8xVzUzMVc2NDFTU0lUoE8He0ZMQUcKBAB9U0RNQQoIU0RNQXBTRVRERE1BMVNEVDOg H3tXODgxCiAAfUlDUjEKCElDUjF9SUNSNQoISUNSNaAUe1c4ODEKEAB9SUNSMQoISUNSMaAT lURNQTAKHn1JQ1IzCghJQ1IzoBOVRE1BMAo8fUlDUjAKCElDUjAUBl9QUzAAFAZfUFMzAFuC RBBTX0QwCF9BRFIKABRGD19HVEYAowhTSUIwEREKDgMAAAAAoO8DAAAAAKDvjFNJQjAKAVBN RDCMU0lCMAoIRE1EMKBABntTRUNUCgIAoBOTe1NFQ1QKCQAKCHAKCFBNRDChQQRwCgpQTUQw entTRUNUCwADAAoIYHp7U0VDVAsAMAAKDGFyYGFioAyTCgNicAoLUE1EMKAMkwoFYnAKDFBN RDChCHAKAVBNRDCgPHtTRE1BCgQAcH1TRFQyCkAARE1EMKAUe0lDUjAKBAByRE1EMAoCRE1E MKAQe0lDUjMKBABwCkVETUQwoRR9dHtQTUQwCgcACgIACiBETUQwpFNJQjBbgk8PU19EMQhf QURSCgEUQQ9fR1RGAKMIU0lCMRERCg4DAAAAALDvAwAAAACw74xTSUIxCgFQTUQxjFNJQjEK CERNRDGgSwV7U0VDVAogAKATk3tTRUNUCpAACoBwCghQTUQxoTxye1NTSVQKAwB6e1NTSVQK DAAKAgBgoAyTCgVgcAoMUE1EMaEXoAyTCgNgcAoLUE1EMaEIcAoKUE1EMaEIcAoBUE1EMaA8 e1NETUEKAgBwfVNEVDMKQABETUQxoBR7SUNSMAoIAHJETUQxCgJETUQxoBB7SUNSMwoIAHAK RURNRDGhFH10e1BNRDEKBwAKAgAKIERNRDGkU0lCMVuCD1NNQlMIX0FEUgwDAB8AW4IPUFdS QghfSElEDEHQDAxbgkIGVVNCMQhfQURSDAAAHQBbgFVTQk8CCsQKBFuBC1VTQk8TUlNFTgII X1BSVxIGAgoDCgQUGV9QU1cBoAlocAoDUlNFTqEIcAoAUlNFThQJX1MzRACkCgIUCV9TNEQA pAoCW4JCBlVTQjIIX0FEUgwBAB0AW4BVU0JPAgrECgRbgQtVU0JPE1JTRU4CCF9QUlcSBgIK BAoEFBlfUFNXAaAJaHAKA1JTRU6hCHAKAFJTRU4UCV9TM0QApAoCFAlfUzREAKQKAluCQgZV U0IzCF9BRFIMAgAdAFuAVVNCTwIKxAoEW4ELVVNCTxNSU0VOAghfUFJXEgYCCgwKBBQZX1BT VwGgCWhwCgNSU0VOoQhwCgBSU0VOFAlfUzNEAKQKAhQJX1M0RACkCgJbgkIGVVNCNAhfQURS DAMAHQBbgFVTQk8CCsQKBFuBC1VTQk8TUlNFTgIIX1BSVxIGAgoOCgQUGV9QU1cBoAlocAoD UlNFTqEIcAoAUlNFThQJX1MzRACkCgIUCV9TNEQApAoCW4IpRVVTQghfQURSDAcAHQAIX1Mz RAoCCF9TNEQKAghfUFJXEgYCCg0KBBApX1NJXxQjX1NTVAGgHJNoCgFcLwVfU0JfUENJMExQ QzBTSU9fRU5XSxAFX1RaX1uAREJHXwEKgAoBW4ELREJHXwFERUJHCAhfUzBfEgYCCgAKAAhf UzFfEgYCCgEKAQhfUzRfEgYCCgYKBghfUzVfEgYCCgcKBwhQSUNGCgAUDV9QSUMBcGhcUElD RhRCCF9QVFMBcGhERUJHoDWTaAoBXC8FX1NCX1BDSTBMUEMwU0lPX0VOV0tcLwVfU0JfUENJ MExQQzBTSU9fQ0xFRAoCoB6TaAoDXC8FX1NCX1BDSTBMUEMwU0lPX0NMRUQKA6AfkpVoCgRc LwVfU0JfUENJMExQQzBTSU9fQ0xFRAoBFEEFX1dBSwF5aAoEREVCR1wvBV9TQl9QQ0kwTFBD MFNJT19DTEVECgCGXC8DX1NCX1BDSTBQV1JCCgJcLwVfU0JfUENJMExQQzBTSU9fRFNXSxBD DlwACFNTRFQSQwoYDUNQVTBJU1QgAAwAAAAADAAAAAANQ1BVMUlTVCAADAAAAAAMAAAAAA1D UFUwQ1NUIAAMAAAAAAwAAAAADUNQVTFDU1QgAAwAAAAADAAAAAANQ1BVMklTVCAADAAAAIAM AAAAgA1DUFUzSVNUIAAMAAAAgAwAAACADUNQVTJDU1QgAAwAAACADAAAAIANQ1BVM0NTVCAA DAAAAIAMAAAAgAhDRkdEDAhBRw8IXFBEQzAMAAAAgAhcUERDMQwAAACACFxQREMyDAAAAIAI XFBEQzMMAAAAgBBFClwuX1BSX0NQVTAISEkwXwoACEhDMF8KABRKCF9QREMBimgKCENBUDBw Q0FQMFBEQzCgQQeQe0NGR0QLAEAAk3tQREMwCgoACgqgLHtDRkdECgMAW4BJU1QwAIOIU1NE VAoBAIOIU1NEVAoCAFsgSVNUMEhJMF+gLHtDRkdEChAAW4BDU1QwAIOIU1NEVAoHAIOIU1NE VAoIAFsgQ1NUMEhDMF8QQgtcLl9QUl9DUFUxCEhJMV8KAAhIQzFfCgAURwlfUERDAYpoCghD QVAxcENBUDFQREMxoEEHkHtDRkdECwBAAJN7UERDMQoKAAoKoCx7Q0ZHRAoDAFuASVNUMQCD iFNTRFQKBACDiFNTRFQKBQBbIElTVDFISTFfoCx7Q0ZHRAoQAFuAQ1NUMQCDiFNTRFQKCgCD iFNTRFQKCwBbIENTVDFIQzFfoAyTe1BEQzEKCgAKChBFClwuX1BSX0NQVTIISEkyXwoACEhD Ml8KABRKCF9QREMBimgKCENBUDJwQ0FQMlBEQzKgQQeQe0NGR0QLAEAAk3tQREMyCgoACgqg LHtDRkdECgMAW4BJU1QyAIOIU1NEVAoNAIOIU1NEVAoOAFsgSVNUMkhJMl+gLHtDRkdEChAA W4BDU1QyAIOIU1NEVAoTAIOIU1NEVAoUAFsgQ1NUMkhDMl8QQgtcLl9QUl9DUFUzCEhJM18K AAhIQzNfCgAURwlfUERDAYpoCghDQVAzcENBUDNQREMzoEEHkHtDRkdECwBAAJN7UERDMwoK AAoKoCx7Q0ZHRAoDAFuASVNUMwCDiFNTRFQKEACDiFNTRFQKEQBbIElTVDNISTNfoCx7Q0ZH RAoQAFuAQ1NUMwCDiFNTRFQKFgCDiFNTRFQKFwBbIENTVDNIQzNfoAyTe1BEQzMKCgAKCg== --------------050205030600050006060406-- From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 21 18:02:29 2007 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 471B216A417 for ; Tue, 21 Aug 2007 18:02:29 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 10E4613C49D for ; Tue, 21 Aug 2007 18:02:28 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 27748 invoked from network); 21 Aug 2007 18:02:29 -0000 Received: from ppp-71-139-26-116.dsl.snfc21.pacbell.net (HELO ?10.0.5.18?) (nate-mail@71.139.26.116) by root.org with ESMTPA; 21 Aug 2007 18:02:29 -0000 Message-ID: <46CB28AF.5080506@root.org> Date: Tue, 21 Aug 2007 11:02:23 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070810) MIME-Version: 1.0 To: Sean Bruno References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <46CB2097.5000706@miralink.com> In-Reply-To: <46CB2097.5000706@miralink.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, William Grzybowski Subject: Re: msk dev problem with acpi 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, 21 Aug 2007 18:02:29 -0000 Sean Bruno wrote: > William Grzybowski wrote: >> Hi! >> >> I'm having a problem with my marvell yukon ethernet when i boot my >> -CURRENT >> with the ACPI enable, it goes fine when acpi is off... >> I already tried to talk with the msk driver developer and he has now idea >> why it is happening and told me to try something here... >> >> dmesg error: >> mskc0: irq 16 at device 0.0 >> on pci2 >> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). >> mskc0: unknown device: id=0x00, rev=0x00 >> device_attach: mskc0 attach returned 6 >> >> the card: >> mskc0@pci2:0:0: class=0x020000 card=0x01101025 chip=0x435211ab rev=0x14 >> hdr=0x00 >> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >> device = 'Yukon 88E8038 PCI-E Fast Ethernet Controller' >> class = network >> subclass = ethernet >> >> I am also attaching the acpidump and dmesg , >> If it can't be a apci isue, please, let me know. >> > I don't see any attachments in this email. Can you try resending to the > list? > Attachments that are too big are stripped. Please post a URL to the acpidump instead. -Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 21 18:16:03 2007 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 A774816A420 for ; Tue, 21 Aug 2007 18:16:03 +0000 (UTC) (envelope-from william88@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 76C3F13C480 for ; Tue, 21 Aug 2007 18:16:03 +0000 (UTC) (envelope-from william88@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1306104waf for ; Tue, 21 Aug 2007 11:16:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dvPPiCJO/z2MSfuax7X5JGpI4fVxyMSBDgQ0glvqnTWtxbDIbUM/0yXXObx0rgMGVhylu92sIh8B1/qDjtnKBhugEGjSvKh2oWRcZmDhFXVfNNMl/EewV7aU8dWcNtxEi0angzb9wjQq4ZC+xBQvD7GYGa3X0egUAnA9h2ZsFEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qikrCH0jdIsGY3LApSgalMp8fSDrBPpnGfpH+rjtkD4BfHTyq/CtdF8OXTQGnQdSlOHzyZLDLrDQ0MBa9gZUKpLpiWDgSbYw9brgrNcfxSLxfJx9+zUMylJrg202+fq9hi/VfjpKdO4Vuo1uVlbLc6rEaZ3y8leTC3gwcOdl6HQ= Received: by 10.114.174.2 with SMTP id w2mr4920364wae.1187720162029; Tue, 21 Aug 2007 11:16:02 -0700 (PDT) Received: by 10.114.111.4 with HTTP; Tue, 21 Aug 2007 11:16:01 -0700 (PDT) Message-ID: <632825b40708211116g1c11612aj86163495e6a32e97@mail.gmail.com> Date: Tue, 21 Aug 2007 15:16:01 -0300 From: "William Grzybowski" To: "Nate Lawson" In-Reply-To: <46CB28AF.5080506@root.org> MIME-Version: 1.0 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <46CB2097.5000706@miralink.com> <46CB28AF.5080506@root.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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, 21 Aug 2007 18:16:03 -0000 On 8/21/07, Nate Lawson wrote: > > Sean Bruno wrote: > > William Grzybowski wrote: > >> Hi! > >> > >> I'm having a problem with my marvell yukon ethernet when i boot my > >> -CURRENT > >> with the ACPI enable, it goes fine when acpi is off... > >> I already tried to talk with the msk driver developer and he has now > idea > >> why it is happening and told me to try something here... > >> > >> dmesg error: > >> mskc0: irq 16 at device 0.0 > >> on pci2 > >> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > >> mskc0: unknown device: id=0x00, rev=0x00 > >> device_attach: mskc0 attach returned 6 > >> > >> the card: > >> mskc0@pci2:0:0: class=0x020000 card=0x01101025 chip=0x435211ab rev=0x14 > >> hdr=0x00 > >> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > >> device = 'Yukon 88E8038 PCI-E Fast Ethernet Controller' > >> class = network > >> subclass = ethernet > >> > >> I am also attaching the acpidump and dmesg , > >> If it can't be a apci isue, please, let me know. > >> > > I don't see any attachments in this email. Can you try resending to the > > list? > > > > Attachments that are too big are stripped. Please post a URL to the > acpidump instead. > > -Nate > It has just ~30kb, anyway, i am posting the links... http://www.inf.ufpr.br/wg06/acpi.gz http://www.inf.ufpr.br/wg06/dmesg.gz Thanks -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 21 20:55:21 2007 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 E7A2716A41A for ; Tue, 21 Aug 2007 20:55:21 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from plato.miralink.com (mail.miralink.com [70.103.185.20]) by mx1.freebsd.org (Postfix) with ESMTP id BA50513C474 for ; Tue, 21 Aug 2007 20:55:21 +0000 (UTC) (envelope-from sbruno@miralink.com) Received: from localhost (localhost.localdomain [127.0.0.1]) by plato.miralink.com (Postfix) with ESMTP id 5621C619CFB for ; Tue, 21 Aug 2007 13:55:21 -0700 (PDT) Received: from plato.miralink.com ([127.0.0.1]) by localhost (plato.miralink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29817-02 for ; Tue, 21 Aug 2007 13:55:20 -0700 (PDT) Received: from [10.0.0.40] (iago.office.miralink.com [10.0.0.40]) by plato.miralink.com (Postfix) with ESMTP id 4CC6C619B85 for ; Tue, 21 Aug 2007 13:55:20 -0700 (PDT) Message-ID: <46CB5138.4000007@miralink.com> Date: Tue, 21 Aug 2007 13:55:20 -0700 From: Sean Bruno User-Agent: Thunderbird 1.5.0.12 (X11/20070719) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <46C37FBF.50004@miralink.com> <46CB27C1.4090805@miralink.com> In-Reply-To: <46CB27C1.4090805@miralink.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Aug 21 13:55:21 2007 X-DSPAM-Confidence: 0.6768 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 46cb5139318151649814603 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Status: No, score=-4.493 tagged_above=-10 required=6.6 autolearn=ham tests=[ALL_TRUSTED=-1.8, AWL=0.006, BAYES_00=-2.599, DSPAM_HAM=-0.1] X-Spam-Score: -4.493 X-Spam-Level: Subject: Re: Supermicro Boot Lockup with ACPI enabled 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, 21 Aug 2007 20:55:22 -0000 Sean Bruno wrote: > Sean Bruno wrote: >> I am using RELENG6_2 on a Supermicro 5015P-TR that has a model >> PDSMP-I motherboard. It currently locks up when booting the system >> with ACPI enabled in the BIOS and at the same time a card(I've tried >> an Adaptec 29160, 29320 and a Qlogic F/C 2342) in either PCI-X slot. >> >> If I deselect ACPI in the BIOS, the system boots and all is well. If >> I remove the expansion cards, I can boot with ACPI enabled and all is >> well. I can then dump the DSDT to look for errors. I don't see >> anything obvious and I'm not sure how to proceed. >> >> I'm looking to see how I can find the error in the DSDT and report it >> to supermicro, but I can't see anything wrong with the tables that I >> have attached to the email. There doesn't appear to be any updates >> to the BIOS for this system either. Any ideas? >> >> Sean >> ------------------------------------------------------------------------ > I was able to dump the ACPI tables with a pci card inserted by > disabling the driver for that card(in my case, the ISP driver). I > still don't see any reason why FreeBSD 6.2 freezes when ACPI is > enabled and a card is in the PCI-X slot. I have attached the full > DSDT dump, hopefully someone can give me a clue here so I can get > SuperMicro to fix their box? > > Sean > > Hmmm...I ran my dsdt through the Intel ACPI decompiler/compiler on a linux box and was able to get some interesting input, at least I now know something more about ACPI. I assume that this warning isn't causing any severe issues as it seems to be pretty common throughout the DSDT on my supermicro: acpi.dsl 3213: Acquire (W627, 0x1388) Warning 1103 - Possible operator timeout is ignored ^ However the last few look very interesting and most probably are related to why my machine kind of dead locks when a PCI card is in the PCI-X slot: acpi.dsl 4044: Field (IDE1, DWordAcc, NoLock, Preserve) Error 4026 - ^ Access width is greater than region size acpi.dsl 4046: MAP, 8, Error 4027 - ^ Access width of Field Unit extends beyond region limit acpi.dsl 4048: PCS, 8 Error 4027 - ^ Access width of Field Unit extends beyond region limit acpi.dsl 4986: Method (_WAK, 1, NotSerialized) Warning 1079 - ^ Reserved method must return a value (_WAK) Any suggestions on how to approach supermicro with this information? Sean From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 22 10:20:10 2007 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 8323916A417; Wed, 22 Aug 2007 10:20:10 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id A8EA113C458; Wed, 22 Aug 2007 10:20:08 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7MAK7TH078827; Wed, 22 Aug 2007 07:20:08 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-acpi@freebsd.org Date: Wed, 22 Aug 2007 07:24:24 -0300 User-Agent: KMail/1.9.7 References: <200707271109.51334.joao@matik.com.br> <46AB160D.6040207@freebsd.org> <200708060928.36154.joao@matik.com.br> In-Reply-To: <200708060928.36154.joao@matik.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708220724.25330.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: powerd freeze with amd 5000 X2 but not with lower cpus 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, 22 Aug 2007 10:20:10 -0000 On Monday 06 August 2007 09:28:35 JoaoBR wrote: =2E.... > > I had a chance to test several MBs with the same 6000+, 5000+ and 4600+ c= pu > > At the end seems that the problem is mb/hardware related since some > combinations hung even with latest BIOS installed and others not. > not sure if somebody still wants to hear about this but it is kind of=20 interesting I guess for my understandings in first place the MB and Bios is most important thin= g=20 and there are vendor bios out which say they support the higher freq CPUs b= ut=20 certainly they don't or at least not all of them even so I gut freezes on all kind of combinations and seems that xorg and i= t's=20 video drv are kind of very sensitive to certain settings, also with glx and= =20 dri disabled I still got freezings sooner or later I got a new monitor this days and that brought the real stuff up, seems tha= t=20 xorg is not liking when the HorizSync and VertRefresh rates are not 100%=20 correct and what then cause the kill. In order to doublecheck this I took m= y=20 old monitor back with correct settings and i got no further freezes either= =20 with any of the CPU/MB combinations I tested before. I have an LCD which can 1280x1024 at 75hz , the former could 1024x768 at 75= hz=20 and with both it works now fine with VertRefresh 50-100 HorizSync 31.5 - 82.0 before I had VertRefresh 50 - 90 HorizSync 30 - 75 one thing more I did which caused a sysctl error on boot. There is a funny= =20 line in /etc/rc.s/power_profile as 'highest_value=3D"C1"' which I commented= out=20 but I guess that has nothing to do since the setting was not accepted anyway xorg seems to have problems when enabling DPMS and returns wrong=20 values. The vesa driver seems to work better or is less sensitive than sis= =20 and nv and ati but with the correct monitor rates all are working fine. well, I believe that's it because I have now two different MATX MBs running= =20 24h with Athlon 5000 without any problem, since friday night =20 =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 22 20:19:39 2007 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 5CB4716A468 for ; Wed, 22 Aug 2007 20:19:39 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.184]) by mx1.freebsd.org (Postfix) with ESMTP id 2FC0F13C46E for ; Wed, 22 Aug 2007 20:19:39 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so181280rvb for ; Wed, 22 Aug 2007 13:19:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MaRTl9KMFNHhaJ33W2YAnUWblmjuG3goc4c6gergfAnK6i2rE1q1xqPF6tjqcVafeHlEdfHYr88YpQkRdNnE2dfy23TnaHjvmK9QzAwkDun/+cw0Zg+g1U8eNa0QTejAg1hCeiMB0z3aHQqAl7YpN82Z6RabZ7v5HF9ouRC2sM8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dc90OKp4rZFDvM+0b0QViHYKDCxOyByMUJsPeo8owmK9NgRsAJ17tBWUFZiNFvkKCCEMoF+4iFKXdesPmXo5epJPj3i+sZEZRLExhvPachoeoUFlfDB6XHWDyIwv1B5xK3w6A8fBXb3Ko1FF1/iNGuFyOslT3en4rK8LqtGVUc4= Received: by 10.141.202.12 with SMTP id e12mr503023rvq.1187813978481; Wed, 22 Aug 2007 13:19:38 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Wed, 22 Aug 2007 13:19:38 -0700 (PDT) Message-ID: <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> Date: Wed, 22 Aug 2007 17:19:38 -0300 From: "William Grzybowski" To: "Nate Lawson" In-Reply-To: <632825b40708211116g1c11612aj86163495e6a32e97@mail.gmail.com> MIME-Version: 1.0 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <46CB2097.5000706@miralink.com> <46CB28AF.5080506@root.org> <632825b40708211116g1c11612aj86163495e6a32e97@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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, 22 Aug 2007 20:19:39 -0000 On 8/21/07, William Grzybowski wrote: > > On 8/21/07, Nate Lawson wrote: > > > > Sean Bruno wrote: > > > William Grzybowski wrote: > > >> Hi! > > >> > > >> I'm having a problem with my marvell yukon ethernet when i boot my > > >> -CURRENT > > >> with the ACPI enable, it goes fine when acpi is off... > > >> I already tried to talk with the msk driver developer and he has now > > idea > > >> why it is happening and told me to try something here... > > >> > > >> dmesg error: > > >> mskc0: irq 16 at device 0.0 > > >> on pci2 > > >> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > > >> mskc0: unknown device: id=0x00, rev=0x00 > > >> device_attach: mskc0 attach returned 6 > > >> > > >> the card: > > >> mskc0@pci2:0:0: class=0x020000 card=0x01101025 chip=0x435211ab > > rev=0x14 > > >> hdr=0x00 > > >> vendor = 'Marvell Semiconductor (Was: Galileo Technology > > Ltd)' > > >> device = 'Yukon 88E8038 PCI-E Fast Ethernet Controller' > > >> class = network > > >> subclass = ethernet > > >> > > >> I am also attaching the acpidump and dmesg , > > >> If it can't be a apci isue, please, let me know. > > >> > > > I don't see any attachments in this email. Can you try resending to > > the > > > list? > > > > > > > Attachments that are too big are stripped. Please post a URL to the > > acpidump instead. > > > > -Nate > > > > It has just ~30kb, anyway, i am posting the links... > http://www.inf.ufpr.br/wg06/acpi.gz > http://www.inf.ufpr.br/wg06/dmesg.gz Hi, i was testing a verbose boot with acpi and without acpi, i noted a "requested unsupported memory range" with acpi... verbose dmesg with acpi: mskc0: irq 16 at device 0.0 on pci2 pcib1: mskc0 requested unsupported memory range 0-0xffffffff (decoding 0-0, 0-0) mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). mskc0: Lazy allocation of 0x4 bytes rid 0x14 type 4 at 0x1000 mskc0: unknown device: id=0xff, rev=0x0f and without acpi: mskc0: port 0x2000-0x20ff mem 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000 mskc0: MSI count : 2 mskc0: attempting to allocate 2 MSI vectors (2 supported) Is that relevant? Maybe a issue in the msk driver allocation and not in acpi? Should I send all the verbose boots with and without acpi? Thanks, bye. Thanks > > -- > William Grzybowski > ------------------------------------------ > Jabber: william88 at gmail dot com > Msn: william.grz at hotmail dot com > Curitiba/PR > -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 22 21:03:47 2007 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 1C23016A418 for ; Wed, 22 Aug 2007 21:03:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id C55E213C457 for ; Wed, 22 Aug 2007 21:03:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8k) with ESMTP id 204704924-1834499 for multiple; Wed, 22 Aug 2007 17:03:49 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l7ML3i6l011667; Wed, 22 Aug 2007 17:03:44 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 22 Aug 2007 17:02:38 -0400 User-Agent: KMail/1.9.6 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <632825b40708211116g1c11612aj86163495e6a32e97@mail.gmail.com> <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> In-Reply-To: <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708221702.39180.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 22 Aug 2007 17:03:44 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4031/Wed Aug 22 13:50:25 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: William Grzybowski Subject: Re: msk dev problem with acpi 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, 22 Aug 2007 21:03:47 -0000 On Wednesday 22 August 2007 04:19:38 pm William Grzybowski wrote: > Hi, i was testing a verbose boot with acpi and without acpi, i noted a > "requested unsupported memory range" with acpi... Yes, this is why your device doesn't work. Verbose dmesg's for both cases would be useful. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 22 22:04:55 2007 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 4862816A420 for ; Wed, 22 Aug 2007 22:04:55 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1D29F13C461 for ; Wed, 22 Aug 2007 22:04:55 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so197806rvb for ; Wed, 22 Aug 2007 15:04:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qGirUGVOon9K2WnIZByfWE/qyX3G3lMQmRnOB8VXXaJaBbhxvWKDOR9/6Yg/tTP2TB8DIRFMwydEEYB1+GU0aZNWWKl1pYT45CqoiMZUTBxqY87Ek2BfzL0soOfXf/s2fjZ8WK2zohOUrY5znGu4QItHzlbH9sAohOq4CSXKD9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NHgojzFfX8A/WKnjiFir5iozSgKzWJTHPmK0N+DeIn7bJpZmyeMOF72mQNlPclQnYd0po4yqGpA8EB7LqAs8EuQjksHLuR8j7AT3hRKIm/J2f8hmCr7QFUuRpbwWmCkcB74+GFpuwoqKr5tDPhzc/IO41yrFwPhbcTU8qykTg8A= Received: by 10.141.28.12 with SMTP id f12mr546934rvj.1187820294682; Wed, 22 Aug 2007 15:04:54 -0700 (PDT) Received: by 10.141.136.13 with HTTP; Wed, 22 Aug 2007 15:04:54 -0700 (PDT) Message-ID: <632825b40708221504oa35fcfbgc02eba47c82eb93b@mail.gmail.com> Date: Wed, 22 Aug 2007 19:04:54 -0300 From: "William Grzybowski" To: "John Baldwin" In-Reply-To: <200708221702.39180.jhb@freebsd.org> MIME-Version: 1.0 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <632825b40708211116g1c11612aj86163495e6a32e97@mail.gmail.com> <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> <200708221702.39180.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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, 22 Aug 2007 22:04:55 -0000 On 8/22/07, John Baldwin wrote: > > On Wednesday 22 August 2007 04:19:38 pm William Grzybowski wrote: > > Hi, i was testing a verbose boot with acpi and without acpi, i noted a > > "requested unsupported memory range" with acpi... > > Yes, this is why your device doesn't work. Verbose dmesg's for both cases > would be useful. Hi, i am sending the both verbose dmesg's: http://www.inf.ufpr.br/wg06/dmesg-verbose-acpi.gz http://www.inf.ufpr.br/wg06/dmesg-verbose-noacpi.gz I hope it helps.. tell me if you need anything more thanks all :) -- > John Baldwin > -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 23 03:53:43 2007 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 3A89716A41A for ; Thu, 23 Aug 2007 03:53:43 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id E929C13C468 for ; Thu, 23 Aug 2007 03:53:41 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id NAA28554; Thu, 23 Aug 2007 13:17:57 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 23 Aug 2007 13:17:56 +1000 (EST) From: Ian Smith To: JoaoBR In-Reply-To: <200708220724.25330.joao@matik.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: powerd freeze with amd 5000 X2 but not with lower cpus 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, 23 Aug 2007 03:53:43 -0000 On Wed, 22 Aug 2007, JoaoBR wrote: > On Monday 06 August 2007 09:28:35 JoaoBR wrote: > ..... > > > > I had a chance to test several MBs with the same 6000+, 5000+ and 4600+ cpu > > > > At the end seems that the problem is mb/hardware related since some > > combinations hung even with latest BIOS installed and others not. > > > > not sure if somebody still wants to hear about this but it is kind of > interesting I guess [.. leaving out your video / xorg / DPMS stuff without comment ..] > one thing more I did which caused a sysctl error on boot. There is a funny > line in /etc/rc.s/power_profile as 'highest_value="C1"' which I commented out > but I guess that has nothing to do since the setting was not accepted Call me curious, but (assuming that you're tuning for performance, not economy, and so will always run these boxes on AC power, not battery): a) why you think that line in /etc/rc.d/power_profile is 'funny'? b) what value for performance_cx_lowest you would consider more appropriate to use than C1, and why? c) whether you have overridden the /etc/defaults/rc.conf values for {performance,economy}_cx_lowest or {performance,economy}_cpu_freq ? Cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 23 11:35:17 2007 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 0B66616A419 for ; Thu, 23 Aug 2007 11:35:17 +0000 (UTC) (envelope-from william88@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id CCEF613C468 for ; Thu, 23 Aug 2007 11:35:16 +0000 (UTC) (envelope-from william88@gmail.com) Received: by wa-out-1112.google.com with SMTP id m33so548146wag for ; Thu, 23 Aug 2007 04:35:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=bolacj/rzKqsR6Ldsa3eSllvXdSF5qOYO9/r5q238CpIOzUOuFaRMexlyFzDklqg71yW4BIXyS2CtfVREnlz/yJK5WyDGET72HZiALyopkIwqC6iLjzvSHT58MEvtqisMp0o4aNBshh54uck+l9AQ9Q46K/LzwrB5Wj+au4ebFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mkmu3qiiIit82xyzptsE/+ww8W37dZvvLV5zg5QAFX03qb6NOc9Cgmk4uZEDNvgGF9W9uAZbfwQzJQWLhW9YNtu2gkHihGMDLX77MsqjBIbn7yU6tNif0+r1IL161qSaEOR/ZpUUrzK3gCll6HCFJa4WpX/I9xsTBA5BxUeTN4k= Received: by 10.114.136.1 with SMTP id j1mr690742wad.1187868915599; Thu, 23 Aug 2007 04:35:15 -0700 (PDT) Received: by 10.114.111.4 with HTTP; Thu, 23 Aug 2007 04:35:15 -0700 (PDT) Message-ID: <632825b40708230435x2b32d73clfcd88b766e171c46@mail.gmail.com> Date: Thu, 23 Aug 2007 08:35:15 -0300 From: "William Grzybowski" To: "John Baldwin" In-Reply-To: <632825b40708221504oa35fcfbgc02eba47c82eb93b@mail.gmail.com> MIME-Version: 1.0 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <632825b40708211116g1c11612aj86163495e6a32e97@mail.gmail.com> <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> <200708221702.39180.jhb@freebsd.org> <632825b40708221504oa35fcfbgc02eba47c82eb93b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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, 23 Aug 2007 11:35:17 -0000 On 8/22/07, William Grzybowski wrote: > > On 8/22/07, John Baldwin wrote: > > > On Wednesday 22 August 2007 04:19:38 pm William Grzybowski wrote: > > > Hi, i was testing a verbose boot with acpi and without acpi, i noted a > > > "requested unsupported memory range" with acpi... > > > > Yes, this is why your device doesn't work. Verbose dmesg's for both > > cases > > would be useful. > > > Hi, i am sending the both verbose dmesg's: > http://www.inf.ufpr.br/wg06/dmesg-verbose-acpi.gz > http://www.inf.ufpr.br/wg06/dmesg-verbose-noacpi.gz > > I hope it helps.. tell me if you need anything more > thanks all :) > > -- > > John Baldwin > > Hi, i just verified it, the links which i gave hadn't the full dmesg, if you already saw this links, please, see it again. It is more informative :) http://www.inf.ufpr.br/wg06/dmesg-verbose-acpi.gz http://www.inf.ufpr.br/wg06/dmesg-verbose-noacpi.gz Thanks again and sorry for multiple messages and annoying :S Bye. -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 23 12:10:57 2007 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 6456C16A418; Thu, 23 Aug 2007 12:10:57 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id DFC5D13C442; Thu, 23 Aug 2007 12:10:56 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anb.matik.com.br (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7NCAs60014317; Thu, 23 Aug 2007 09:10:55 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Thu, 23 Aug 2007 09:10:51 -0300 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708230910.52163.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-acpi@freebsd.org, Ian Smith Subject: Re: powerd freeze with amd 5000 X2 but not with lower cpus 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, 23 Aug 2007 12:10:57 -0000 On Thursday 23 August 2007 00:17:56 Ian Smith wrote: > > Call me curious, but (assuming that you're tuning for performance, not > economy, and so will always run these boxes on AC power, not battery): > > a) why you think that line in /etc/rc.d/power_profile is 'funny'? > well, in first place because it gave an error, I haven't looked deeper at t= hat=20 moment because I was after something else so now I did because of your question and it seems the power_profile script= =20 has a bug I tries to set hw.acpi.cpu.cx_lowest=3DC1 but I guess it should be dev.cpu.0.cx_lowest > b) what value for performance_cx_lowest you would consider more > appropriate to use than C1, and why? > I didn't said that, My comment was not regarding the value but the error pe= r=20 se > c) whether you have overridden the /etc/defaults/rc.conf values for > {performance,economy}_cx_lowest or {performance,economy}_cpu_freq ? > no =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 23 17:38:15 2007 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 DE76816A419; Thu, 23 Aug 2007 17:38:15 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 2F38613C468; Thu, 23 Aug 2007 17:38:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id DAA22954; Fri, 24 Aug 2007 03:37:58 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 24 Aug 2007 03:37:57 +1000 (EST) From: Ian Smith To: JoaoBR In-Reply-To: <200708230910.52163.joao@matik.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org Subject: Re: powerd freeze with amd 5000 X2 but not with lower cpus 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, 23 Aug 2007 17:38:16 -0000 On Thu, 23 Aug 2007, JoaoBR wrote: > On Thursday 23 August 2007 00:17:56 Ian Smith wrote: > > > > > Call me curious, but (assuming that you're tuning for performance, not > > economy, and so will always run these boxes on AC power, not battery): > > > > a) why you think that line in /etc/rc.d/power_profile is 'funny'? > > > > well, in first place because it gave an error, I haven't looked deeper at that > moment because I was after something else > > so now I did because of your question and it seems the power_profile script > has a bug > > I tries to set hw.acpi.cpu.cx_lowest=C1 > > but I guess it should be dev.cpu.0.cx_lowest Ah, ok. Updated in HEAD but not STABLE: http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/power_profile.diff?r1=text&tr1=1.7&r2=text&tr2=1.11 But http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/power_profile indicates that hw.acpi.cpu.cx_lowest should still work anyway, to set all cpus the same? What is the error message you're getting? Cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 23 21:05:34 2007 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 C7EB516A41A; Thu, 23 Aug 2007 21:05:34 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4E46C13C45E; Thu, 23 Aug 2007 21:05:34 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7NL5ZRO069252; Thu, 23 Aug 2007 18:05:36 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Thu, 23 Aug 2007 18:09:49 -0300 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708231809.50623.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-acpi@freebsd.org, Ian Smith Subject: Re: powerd freeze with amd 5000 X2 but not with lower cpus 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, 23 Aug 2007 21:05:34 -0000 On Thursday 23 August 2007 14:37:57 Ian Smith wrote: > On Thu, 23 Aug 2007, JoaoBR wrote: > > On Thursday 23 August 2007 00:17:56 Ian Smith wrote: > > > Call me curious, but (assuming that you're tuning for performance, n= ot > > > economy, and so will always run these boxes on AC power, not battery= ): > > > > > > a) why you think that line in /etc/rc.d/power_profile is 'funny'? > > > > well, in first place because it gave an error, I haven't looked deeper > > at that moment because I was after something else > > > > so now I did because of your question and it seems the power_profile > > script has a bug > > > > I tries to set hw.acpi.cpu.cx_lowest=3DC1 > > > > but I guess it should be dev.cpu.0.cx_lowest > > Ah, ok. Updated in HEAD but not STABLE: > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/power_profile.diff?r1= =3Dte >xt&tr1=3D1.7&r2=3Dtext&tr2=3D1.11 > > But http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/power_profile > indicates that hw.acpi.cpu.cx_lowest should still work anyway, to set > all cpus the same? What is the error message you're getting? > no it not working # sysctl hw.acpi.cpu.cx_lowest=3DC1 hw.acpi.cpu.cx_lowest: C1 sysctl: hw.acpi.cpu.cx_lowest: Invalid argument =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 23 22:07:23 2007 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 AA42016A41B for ; Thu, 23 Aug 2007 22:07:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 5EDA113C45D for ; Thu, 23 Aug 2007 22:07:23 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8k) with ESMTP id 204898437-1834499 for multiple; Thu, 23 Aug 2007 18:07:27 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l7NM7GQw021635; Thu, 23 Aug 2007 18:07:18 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "William Grzybowski" Date: Thu, 23 Aug 2007 15:24:50 -0400 User-Agent: KMail/1.9.6 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <632825b40708221504oa35fcfbgc02eba47c82eb93b@mail.gmail.com> <632825b40708230435x2b32d73clfcd88b766e171c46@mail.gmail.com> In-Reply-To: <632825b40708230435x2b32d73clfcd88b766e171c46@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708231524.51244.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 23 Aug 2007 18:07:18 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4037/Thu Aug 23 15:08:22 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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, 23 Aug 2007 22:07:23 -0000 On Thursday 23 August 2007 07:35:15 am William Grzybowski wrote: > On 8/22/07, William Grzybowski wrote: > > > > On 8/22/07, John Baldwin wrote: > > > > > On Wednesday 22 August 2007 04:19:38 pm William Grzybowski wrote: > > > > Hi, i was testing a verbose boot with acpi and without acpi, i noted a > > > > "requested unsupported memory range" with acpi... > > > > > > Yes, this is why your device doesn't work. Verbose dmesg's for both > > > cases > > > would be useful. > > > > > > Hi, i am sending the both verbose dmesg's: > > http://www.inf.ufpr.br/wg06/dmesg-verbose-acpi.gz > > http://www.inf.ufpr.br/wg06/dmesg-verbose-noacpi.gz > > > > I hope it helps.. tell me if you need anything more > > thanks all :) > > > > -- > > > John Baldwin > > > > > > Hi, i just verified it, the links which i gave hadn't the full dmesg, if you > already saw this links, please, see it again. > It is more informative :) > http://www.inf.ufpr.br/wg06/dmesg-verbose-acpi.gz > http://www.inf.ufpr.br/wg06/dmesg-verbose-noacpi.gz > > Thanks again and sorry for multiple messages and annoying :S ACPI is clearing the resources in the PCI-PCI bridge (and the msk(4) device), presumably during an _INI routine and FreeBSD can't currently cope with that. I couldn't really find where in your ASL it clears the BAR. You can try bugging warner losh (imp@). In this case it should be easier to handle as the PCI-PCI bridge has no resources at all, so it should be able to recurse up ok. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 23 22:49:02 2007 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 5F2D716A419 for ; Thu, 23 Aug 2007 22:49:02 +0000 (UTC) (envelope-from william88@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id EFFC213C469 for ; Thu, 23 Aug 2007 22:49:01 +0000 (UTC) (envelope-from william88@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so464223rvb for ; Thu, 23 Aug 2007 15:49:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=E+tXiHoCH/b6u85hpJUTibSU6dUyVjXIXnB86O7Yryy6Pgu+zuu5i4PacgkqBF9PgfKLu3e7UjuIziMSkDNq1US1OccXlzoxm1nrCEk9VfAScesUChgn0IPWvJITSwodmUyf5XpQBCAw6T57iGQF0zGfgUOS/xTJQB7WhdKcq1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=W1C4eKxjtjS0PSc44GmfDOF2ynJdjBWYe8nJ4a7x+RwWGj1lzIUbfyl4HZ98qcYj3dofW9vky0OvnGr1PjcvQuz+mTYEbWiqfyYL0BNNDc2jyoPRbtDfdMKPPPKCgR2rt5JnrVHk0xHNo4um3BDvxM5NA+mSCKP9QDZflzGdZiA= Received: by 10.115.60.1 with SMTP id n1mr645896wak.1187909341287; Thu, 23 Aug 2007 15:49:01 -0700 (PDT) Received: by 10.114.111.4 with HTTP; Thu, 23 Aug 2007 15:49:01 -0700 (PDT) Message-ID: <632825b40708231549w39d703b8hc5fab02930ffca3c@mail.gmail.com> Date: Thu, 23 Aug 2007 19:49:01 -0300 From: "William Grzybowski" To: "John Baldwin" In-Reply-To: <200708231524.51244.jhb@freebsd.org> MIME-Version: 1.0 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <632825b40708221504oa35fcfbgc02eba47c82eb93b@mail.gmail.com> <632825b40708230435x2b32d73clfcd88b766e171c46@mail.gmail.com> <200708231524.51244.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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, 23 Aug 2007 22:49:02 -0000 On 8/23/07, John Baldwin wrote: > > On Thursday 23 August 2007 07:35:15 am William Grzybowski wrote: > > On 8/22/07, William Grzybowski wrote: > > > > > > On 8/22/07, John Baldwin wrote: > > > > > > > On Wednesday 22 August 2007 04:19:38 pm William Grzybowski wrote: > > > > > Hi, i was testing a verbose boot with acpi and without acpi, i > noted a > > > > > "requested unsupported memory range" with acpi... > > > > > > > > Yes, this is why your device doesn't work. Verbose dmesg's for both > > > > cases > > > > would be useful. > > > > > > > > > Hi, i am sending the both verbose dmesg's: > > > http://www.inf.ufpr.br/wg06/dmesg-verbose-acpi.gz > > > http://www.inf.ufpr.br/wg06/dmesg-verbose-noacpi.gz > > > > > > I hope it helps.. tell me if you need anything more > > > thanks all :) > > > > > > -- > > > > John Baldwin > > > > > > > > > > Hi, i just verified it, the links which i gave hadn't the full dmesg, if > you > > already saw this links, please, see it again. > > It is more informative :) > > http://www.inf.ufpr.br/wg06/dmesg-verbose-acpi.gz > > http://www.inf.ufpr.br/wg06/dmesg-verbose-noacpi.gz > > > > Thanks again and sorry for multiple messages and annoying :S > > ACPI is clearing the resources in the PCI-PCI bridge (and the msk(4) > device), > presumably during an _INI routine and FreeBSD can't currently cope with > that. > I couldn't really find where in your ASL it clears the BAR. You can try > bugging warner losh (imp@). In this case it should be easier to handle as > the PCI-PCI bridge has no resources at all, so it should be able to > recurse > up ok. Hmm, ok. I will try to talk with Warner about it. Thanks for your reply. Bye. -- > John Baldwin > -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 23 23:39:47 2007 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 425BF16A417 for ; Thu, 23 Aug 2007 23:39:47 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 18B7E13C457 for ; Thu, 23 Aug 2007 23:39:46 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 22775 invoked from network); 23 Aug 2007 23:39:48 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 23 Aug 2007 23:39:48 -0000 Message-ID: <46CE1ABC.2090008@root.org> Date: Thu, 23 Aug 2007 16:39:40 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (X11/20070806) MIME-Version: 1.0 To: William Grzybowski References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <46CB2097.5000706@miralink.com> <46CB28AF.5080506@root.org> <632825b40708211116g1c11612aj86163495e6a32e97@mail.gmail.com> <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> In-Reply-To: <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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, 23 Aug 2007 23:39:47 -0000 William Grzybowski wrote: > On 8/21/07, *William Grzybowski* > wrote: > > On 8/21/07, *Nate Lawson* > wrote: > > Sean Bruno wrote: > > William Grzybowski wrote: > >> Hi! > >> > >> I'm having a problem with my marvell yukon ethernet when i boot my > >> -CURRENT > >> with the ACPI enable, it goes fine when acpi is off... > >> I already tried to talk with the msk driver developer and he > has now idea > >> why it is happening and told me to try something here... > >> > >> dmesg error: > >> mskc0: irq 16 at > device 0.0 > >> on pci2 > >> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > >> mskc0: unknown device: id=0x00, rev=0x00 > >> device_attach: mskc0 attach returned 6 > >> > >> the card: > >> mskc0@pci2:0:0: class=0x020000 card=0x01101025 chip=0x435211ab > rev=0x14 > >> hdr=0x00 > >> vendor = 'Marvell Semiconductor (Was: Galileo > Technology Ltd)' > >> device = 'Yukon 88E8038 PCI-E Fast Ethernet Controller' > >> class = network > >> subclass = ethernet > >> > >> I am also attaching the acpidump and dmesg , > >> If it can't be a apci isue, please, let me know. > >> > > I don't see any attachments in this email. Can you try > resending to the > > list? > > > > Attachments that are too big are stripped. Please post a URL to the > acpidump instead. > > -Nate > > > It has just ~30kb, anyway, i am posting the links... > http://www.inf.ufpr.br/wg06/acpi.gz > > http://www.inf.ufpr.br/wg06/dmesg.gz > > > > > Hi, i was testing a verbose boot with acpi and without acpi, i noted a > "requested unsupported memory range" with acpi... > > verbose dmesg with acpi: > mskc0: irq 16 at device 0.0 on pci2 > pcib1: mskc0 requested unsupported memory range 0-0xffffffff (decoding > 0-0, 0-0) > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > mskc0: Lazy allocation of 0x4 bytes rid 0x14 type 4 at 0x1000 > mskc0: unknown device: id=0xff, rev=0x0f > > and without acpi: > mskc0: port 0x2000-0x20ff mem > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000 > mskc0: MSI count : 2 > mskc0: attempting to allocate 2 MSI vectors (2 supported) > > Is that relevant? Maybe a issue in the msk driver allocation and not in > acpi? > Should I send all the verbose boots with and without acpi? > > Thanks, bye. I looked at the dmesg and ASL more carefully. It appears that PCI0 is the only bus described in the ASL. Every device except mskc0 is on pci0, so they all work. --- pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 mskc0: irq 16 at device 0.0 on pci2 mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). mskc0: unknown device: id=0xff, rev=0x0f device_attach: mskc0 attach returned 6 --- At this point, pci0 has a bunch of resources set via the _CRS method on Device (PCI0). However, since there is no definition for pcib1, there are no resources to assign to pcib1 and thus mskc0. --- pcib2: irq 17 at device 28.1 on pci0 pci3: on pcib2 pci3: at device 0.0 (no driver attached) pcib3: irq 18 at device 28.2 on pci0 pci4: on pcib3 --- This is interesting. It appears to be a second ethernet adapter and another PCI-PCI bridge that is empty? So the question is what to do in the first case -- it seems easiest that if a bridge has no resources, just pass everything up to the parent. Is that what you're recommending, John? But it's not clear who is erasing the boot-time BARs in the acpi case. There is no method that appears to reference pcib1 unless writing directly to its config space. It would take a lot of analysis to figure that out statically, but should be easy at runtime by just hacking in some printfs. -Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 24 17:17:44 2007 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 7017016A420 for ; Fri, 24 Aug 2007 17:17:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 3622413C47E for ; Fri, 24 Aug 2007 17:17:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8k) with ESMTP id 205083177-1834499 for multiple; Fri, 24 Aug 2007 13:17:28 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l7OHHFvB030448; Fri, 24 Aug 2007 13:17:16 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Fri, 24 Aug 2007 12:41:38 -0400 User-Agent: KMail/1.9.6 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> <46CE1ABC.2090008@root.org> In-Reply-To: <46CE1ABC.2090008@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708241241.39187.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 24 Aug 2007 13:17:16 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4053/Fri Aug 24 11:41:12 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org, William Grzybowski Subject: Re: msk dev problem with acpi 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, 24 Aug 2007 17:17:44 -0000 On Thursday 23 August 2007 07:39:40 pm Nate Lawson wrote: > William Grzybowski wrote: > > On 8/21/07, *William Grzybowski* > > wrote: > > > > On 8/21/07, *Nate Lawson* > wrote: > > > > Sean Bruno wrote: > > > William Grzybowski wrote: > > >> Hi! > > >> > > >> I'm having a problem with my marvell yukon ethernet when i boot my > > >> -CURRENT > > >> with the ACPI enable, it goes fine when acpi is off... > > >> I already tried to talk with the msk driver developer and he > > has now idea > > >> why it is happening and told me to try something here... > > >> > > >> dmesg error: > > >> mskc0: irq 16 at > > device 0.0 > > >> on pci2 > > >> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > > >> mskc0: unknown device: id=0x00, rev=0x00 > > >> device_attach: mskc0 attach returned 6 > > >> > > >> the card: > > >> mskc0@pci2:0:0: class=0x020000 card=0x01101025 chip=0x435211ab > > rev=0x14 > > >> hdr=0x00 > > >> vendor = 'Marvell Semiconductor (Was: Galileo > > Technology Ltd)' > > >> device = 'Yukon 88E8038 PCI-E Fast Ethernet Controller' > > >> class = network > > >> subclass = ethernet > > >> > > >> I am also attaching the acpidump and dmesg , > > >> If it can't be a apci isue, please, let me know. > > >> > > > I don't see any attachments in this email. Can you try > > resending to the > > > list? > > > > > > > Attachments that are too big are stripped. Please post a URL to the > > acpidump instead. > > > > -Nate > > > > > > It has just ~30kb, anyway, i am posting the links... > > http://www.inf.ufpr.br/wg06/acpi.gz > > > > http://www.inf.ufpr.br/wg06/dmesg.gz > > > > > > > > > > Hi, i was testing a verbose boot with acpi and without acpi, i noted a > > "requested unsupported memory range" with acpi... > > > > verbose dmesg with acpi: > > mskc0: irq 16 at device 0.0 on pci2 > > pcib1: mskc0 requested unsupported memory range 0-0xffffffff (decoding > > 0-0, 0-0) > > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > > mskc0: Lazy allocation of 0x4 bytes rid 0x14 type 4 at 0x1000 > > mskc0: unknown device: id=0xff, rev=0x0f > > > > and without acpi: > > mskc0: port 0x2000-0x20ff mem > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000 > > mskc0: MSI count : 2 > > mskc0: attempting to allocate 2 MSI vectors (2 supported) > > > > Is that relevant? Maybe a issue in the msk driver allocation and not in > > acpi? > > Should I send all the verbose boots with and without acpi? > > > > Thanks, bye. > > I looked at the dmesg and ASL more carefully. It appears that PCI0 is > the only bus described in the ASL. Every device except mskc0 is on > pci0, so they all work. Yes, the ASL doesn't descend into the bridges. However, since disabling ACPI gives resources to the msk0 device it means that the BIOS is writing values into the BAR's for the bridge and the mskc0 device during POST, but that some _REG or _INI routine during ACPI enabling is clearing those BAR's for some reason. > --- > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 28.0 on pci0 > pci2: on pcib1 > mskc0: irq 16 at device 0.0 on pci2 > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > mskc0: unknown device: id=0xff, rev=0x0f > device_attach: mskc0 attach returned 6 > --- > > At this point, pci0 has a bunch of resources set via the _CRS method on > Device (PCI0). However, since there is no definition for pcib1, there > are no resources to assign to pcib1 and thus mskc0. Actually, we are too dumb to do that (on my list, but low). Right now Host-PCI bridges just try to alloc anything that's free, but with some tunables to limit the range. So the _CRS for the host bridges doesn't matter for how FreeBSD currently does things. > --- > pcib2: irq 17 at device 28.1 on pci0 > pci3: on pcib2 > pci3: at device 0.0 (no driver attached) > pcib3: irq 18 at device 28.2 on pci0 > pci4: on pcib3 > --- > > This is interesting. It appears to be a second ethernet adapter and > another PCI-PCI bridge that is empty? Yep. > So the question is what to do in the first case -- it seems easiest that > if a bridge has no resources, just pass everything up to the parent. Is > that what you're recommending, John? Well, sorta. The bridge needs to allocate resources and then hand them down to its children, but while this simple case is doable, the harder case is when you have multiple devices and no bridge resources, or you have bridge resources that aren't enough for all the devices you have, etc. Really fixing this requires that we do an early pass assigning resources to busses before any "leaf" drivers probe (but after all the bridges have probed), but for that we really need the multi-pass new-bus stuff. > But it's not clear who is erasing > the boot-time BARs in the acpi case. There is no method that appears to > reference pcib1 unless writing directly to its config space. It would > take a lot of analysis to figure that out statically, but should be easy > at runtime by just hacking in some printfs. Yeah, it's not obvious. I wonder if it's caused by a power reset? There is that \_SB_.PHRS routine (or whatever it's called) that seems to manage powering up and down devices? I noticed during _INI that if none of the _OSI stuff works (though we should be succeeding the _OSI("Linux") call) it appears to power off something (I think). Also, there are places that write into the config space of the bridges like RP01 (the parent for mskc0) (but below the BARs) when certain GPE's fire. Perhaps one of those registers causes a reset of that device, or perhaps one of them is actually part of a power management capability, etc. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 24 21:31:01 2007 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 CFC0F16A41A for ; Fri, 24 Aug 2007 21:31:01 +0000 (UTC) (envelope-from william88@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by mx1.freebsd.org (Postfix) with ESMTP id A280313C46B for ; Fri, 24 Aug 2007 21:31:01 +0000 (UTC) (envelope-from william88@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so1134597waf for ; Fri, 24 Aug 2007 14:31:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=olQ8b7wVg4KN8Dapq9HavhtHFnw4RoCYVO0f/M+eohNziOXppuMY6YwhWPWpDhavJxFlq54PpG4IGyXTsfhGfPU7G0GI8wmgSsGugVUTztedfOeWRCH5Cabjao8veVV5Mqrt7P+FKOHrZGovFdQmORZQEz4/ZgZkaGt0sUk5KgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZsZy9eEo44ZfQrEcjlX1FXKv6rAsDaAumLcdGzZhS5ep+b3oUqkUSNp++LNRoeOXHhtApXh9FOwCDWj0+TMWG0pAhpn1S0r9GTFd7gl1qHaToZhzyMP8JrRmf4iuuFYOGIK8Jk71a+47fRStZ9OfOzckGGC0XW6LKUM4U117Rdg= Received: by 10.115.109.1 with SMTP id l1mr512543wam.1187991059949; Fri, 24 Aug 2007 14:30:59 -0700 (PDT) Received: by 10.114.111.4 with HTTP; Fri, 24 Aug 2007 14:30:59 -0700 (PDT) Message-ID: <632825b40708241430u31f4eebbm671958abb5ec258c@mail.gmail.com> Date: Fri, 24 Aug 2007 18:30:59 -0300 From: "William Grzybowski" To: "John Baldwin" In-Reply-To: <200708241241.39187.jhb@freebsd.org> MIME-Version: 1.0 References: <632825b40708210457r50b22cf9xd55fa88b569e3b5b@mail.gmail.com> <632825b40708221319jbdd6391u19d3172d2b58485f@mail.gmail.com> <46CE1ABC.2090008@root.org> <200708241241.39187.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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, 24 Aug 2007 21:31:02 -0000 On 8/24/07, John Baldwin wrote: > > On Thursday 23 August 2007 07:39:40 pm Nate Lawson wrote: > > William Grzybowski wrote: > > > On 8/21/07, *William Grzybowski* > > > wrote: > > > > > > On 8/21/07, *Nate Lawson* > > wrote: > > > > > > Sean Bruno wrote: > > > > William Grzybowski wrote: > > > >> Hi! > > > >> > > > >> I'm having a problem with my marvell yukon ethernet when i > boot > my > > > >> -CURRENT > > > >> with the ACPI enable, it goes fine when acpi is off... > > > >> I already tried to talk with the msk driver developer and > he > > > has now idea > > > >> why it is happening and told me to try something here... > > > >> > > > >> dmesg error: > > > >> mskc0: irq 16 at > > > device 0.0 > > > >> on pci2 > > > >> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, > 0xffffffff). > > > >> mskc0: unknown device: id=0x00, rev=0x00 > > > >> device_attach: mskc0 attach returned 6 > > > >> > > > >> the card: > > > >> mskc0@pci2:0:0: class=0x020000 card=0x01101025 > chip=0x435211ab > > > rev=0x14 > > > >> hdr=0x00 > > > >> vendor = 'Marvell Semiconductor (Was: Galileo > > > Technology Ltd)' > > > >> device = 'Yukon 88E8038 PCI-E Fast Ethernet > Controller' > > > >> class = network > > > >> subclass = ethernet > > > >> > > > >> I am also attaching the acpidump and dmesg , > > > >> If it can't be a apci isue, please, let me know. > > > >> > > > > I don't see any attachments in this email. Can you try > > > resending to the > > > > list? > > > > > > > > > > Attachments that are too big are stripped. Please post a URL > to > the > > > acpidump instead. > > > > > > -Nate > > > > > > > > > It has just ~30kb, anyway, i am posting the links... > > > http://www.inf.ufpr.br/wg06/acpi.gz > > > > > > http://www.inf.ufpr.br/wg06/dmesg.gz > > > > > > > > > > > > > > > Hi, i was testing a verbose boot with acpi and without acpi, i noted a > > > "requested unsupported memory range" with acpi... > > > > > > verbose dmesg with acpi: > > > mskc0: irq 16 at device 0.0on > pci2 > > > pcib1: mskc0 requested unsupported memory range 0-0xffffffff (decoding > > > 0-0, 0-0) > > > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > > > mskc0: Lazy allocation of 0x4 bytes rid 0x14 type 4 at 0x1000 > > > mskc0: unknown device: id=0xff, rev=0x0f > > > > > > and without acpi: > > > mskc0: port 0x2000-0x20ff mem > > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000 > > > mskc0: MSI count : 2 > > > mskc0: attempting to allocate 2 MSI vectors (2 supported) > > > > > > Is that relevant? Maybe a issue in the msk driver allocation and not > in > > > acpi? > > > Should I send all the verbose boots with and without acpi? > > > > > > Thanks, bye. > > > > I looked at the dmesg and ASL more carefully. It appears that PCI0 is > > the only bus described in the ASL. Every device except mskc0 is on > > pci0, so they all work. > > Yes, the ASL doesn't descend into the bridges. However, since disabling > ACPI > gives resources to the msk0 device it means that the BIOS is writing > values > into the BAR's for the bridge and the mskc0 device during POST, but that > some > _REG or _INI routine during ACPI enabling is clearing those BAR's for some > reason. > > > --- > > pcib0: port 0xcf8-0xcff on acpi0 > > pci0: on pcib0 > > pcib1: irq 16 at device 28.0 on pci0 > > pci2: on pcib1 > > mskc0: irq 16 at device 0.0 on > pci2 > > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). > > mskc0: unknown device: id=0xff, rev=0x0f > > device_attach: mskc0 attach returned 6 > > --- > > > > At this point, pci0 has a bunch of resources set via the _CRS method on > > Device (PCI0). However, since there is no definition for pcib1, there > > are no resources to assign to pcib1 and thus mskc0. > > Actually, we are too dumb to do that (on my list, but low). Right now > Host-PCI bridges just try to alloc anything that's free, but with some > tunables to limit the range. So the _CRS for the host bridges doesn't > matter > for how FreeBSD currently does things. > > > --- > > pcib2: irq 17 at device 28.1 on pci0 > > pci3: on pcib2 > > pci3: at device 0.0 (no driver attached) > > pcib3: irq 18 at device 28.2 on pci0 > > pci4: on pcib3 > > --- > > > > This is interesting. It appears to be a second ethernet adapter and > > another PCI-PCI bridge that is empty? > > Yep. > > > So the question is what to do in the first case -- it seems easiest that > > if a bridge has no resources, just pass everything up to the parent. Is > > that what you're recommending, John? > > Well, sorta. The bridge needs to allocate resources and then hand them > down > to its children, but while this simple case is doable, the harder case is > when you have multiple devices and no bridge resources, or you have bridge > resources that aren't enough for all the devices you have, etc. Really > fixing this requires that we do an early pass assigning resources to > busses > before any "leaf" drivers probe (but after all the bridges have probed), > but > for that we really need the multi-pass new-bus stuff. > > > But it's not clear who is erasing > > the boot-time BARs in the acpi case. There is no method that appears to > > reference pcib1 unless writing directly to its config space. It would > > take a lot of analysis to figure that out statically, but should be easy > > at runtime by just hacking in some printfs. > > Yeah, it's not obvious. I wonder if it's caused by a power reset? There > is > that \_SB_.PHRS routine (or whatever it's called) that seems to manage > powering up and down devices? I noticed during _INI that if none of the > _OSI > stuff works (though we should be succeeding the _OSI("Linux") call) it > appears to power off something (I think). Also, there are places that > write > into the config space of the bridges like RP01 (the parent for mskc0) (but > below the BARs) when certain GPE's fire. Perhaps one of those registers > causes a reset of that device, or perhaps one of them is actually part of > a > power management capability, etc. If I am wrong, tell me, but for what i can understand is it: When the system boots it keeps probing the devices and fulling the resources on pci bridge 0, but actually freebsd can't handle it and keep it going on a second pci bridge bar, is that right or a sorta of it? Well, there is anyway to pass trough it discarding some useless devices to use this bar "BAR" just for useful devices while you guys can't implement it? Thanks, bye. -- > John Baldwin > -- William Grzybowski ------------------------------------------ Jabber: william88 at gmail dot com Msn: william.grz at hotmail dot com Curitiba/PR From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 24 21:53:59 2007 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 9515D16A417; Fri, 24 Aug 2007 21:53:59 +0000 (UTC) (envelope-from SRS0=143ea76425076831a5d5d282a5deeae3cb7536aa=437=es.net=oberman@es.net) Received: from postal1.es.net (postal1.es.net [IPv6:2001:400:14:3::6]) by mx1.freebsd.org (Postfix) with ESMTP id 6232A13C48D; Fri, 24 Aug 2007 21:53:57 +0000 (UTC) (envelope-from SRS0=143ea76425076831a5d5d282a5deeae3cb7536aa=437=es.net=oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id DDZ34852; Fri, 24 Aug 2007 14:53:52 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D089E4506A; Fri, 24 Aug 2007 14:53:51 -0700 (PDT) To: John Baldwin In-Reply-To: Your message of "Fri, 24 Aug 2007 12:41:38 EDT." <200708241241.39187.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1187992431_46671P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 24 Aug 2007 14:53:51 -0700 From: "Kevin Oberman" Message-Id: <20070824215351.D089E4506A@ptavv.es.net> Cc: freebsd-acpi@freebsd.org, William Grzybowski Subject: Re: msk dev problem with acpi 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, 24 Aug 2007 21:53:59 -0000 --==_Exmh_1187992431_46671P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > From: John Baldwin > Date: Fri, 24 Aug 2007 12:41:38 -0400 > Sender: owner-freebsd-acpi@freebsd.org > > On Thursday 23 August 2007 07:39:40 pm Nate Lawson wrote: > > > So the question is what to do in the first case -- it seems easiest that > > if a bridge has no resources, just pass everything up to the parent. Is > > that what you're recommending, John? > > Well, sorta. The bridge needs to allocate resources and then hand them down > to its children, but while this simple case is doable, the harder case is > when you have multiple devices and no bridge resources, or you have bridge > resources that aren't enough for all the devices you have, etc. Really > fixing this requires that we do an early pass assigning resources to busses > before any "leaf" drivers probe (but after all the bridges have probed), but > for that we really need the multi-pass new-bus stuff. Sorry for a slight hijack of the thread, but I am wondering if this is the reason that USB disks get attached to a UHCI interface if they are already connected before umass and usb are loaded into the kernel as UHCI is always loaded first, ohci second and ehci is last. I suspect that this has happened to others without them ever realizing it. They may have been annoyed by the slow devices just blamed hardware and "crappy USBs". -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 --==_Exmh_1187992431_46671P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: Exmh version 2.5 06/03/2002 iD8DBQFGz1Nvkn3rs5h7N1ERAvC2AJ0fRYtrusWRU/pSPfZFF27M9OkuEwCeKGJc l8d7cuTXeJFX2aJZeg9RTlE= =yNyd -----END PGP SIGNATURE----- --==_Exmh_1187992431_46671P-- From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 25 02:41:44 2007 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 CC1E716A420 for ; Sat, 25 Aug 2007 02:41:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.189]) by mx1.freebsd.org (Postfix) with ESMTP id A12C913C480 for ; Sat, 25 Aug 2007 02:41:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so713027rvb for ; Fri, 24 Aug 2007 19:41:44 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lWJyUWuWtKNinzwuogjkzq4AnOIpfqoLP9QFupk7goJ2BG94t8JDJhvtSu0qpJpfClkop9T42hlQC9UkDpYuq0hZ2W9xy10r7kxyII8cYRTFn2Lk9KfwV9BAfuKvWQipdak89X6U4p6RIGCFaoiI1i+UzmrTWahb5ekspJJNAE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RozHPSEJAosXJtNq6/Hc/iOG0u/Bh2D3jL5W3PeFdPGgnw453bQOWgablyGm24WdLKhkyFp2hPIuEVF0/5KR7UGXZz51cUxZYbNAvp/m1zZY43s/wv/QcPlhrhqLxlb/r+IrdfH8ABTEKqhlzhdwys0B0Y4IfBmqPnYFO89Fr0A= Received: by 10.114.183.1 with SMTP id g1mr1060909waf.1188009703950; Fri, 24 Aug 2007 19:41:43 -0700 (PDT) Received: by 10.115.77.13 with HTTP; Fri, 24 Aug 2007 19:41:43 -0700 (PDT) Message-ID: <4956a5e50708241941if3b7778h8433b7ce6e4730e5@mail.gmail.com> Date: Fri, 24 Aug 2007 23:41:43 -0300 From: Nenhum_de_Nos To: "Bruno Ducrot" In-Reply-To: <20070205135815.GH12197@poupinou.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <499c70c0701240044q32162e40ye8f923bf758e8633@mail.gmail.com> <20070124103226.GA12197@poupinou.org> <20070124181449.GI874@turion.vk2pj.dyndns.org> <20070124184828.GC12197@poupinou.org> <20070202094627.GA1758@turion.vk2pj.dyndns.org> <20070205135815.GH12197@poupinou.org> Cc: Peter Jeremy , freebsd-acpi@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: AMD Turion64 X2 works with PowerNow! thank you Bruno 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: Sat, 25 Aug 2007 02:41:44 -0000 On 2/5/07, Bruno Ducrot wrote: > On Fri, Feb 02, 2007 at 08:46:27PM +1100, Peter Jeremy wrote: > > On Wed, 2007-Jan-24 19:48:28 +0100, Bruno Ducrot wrote: > > >acpi_throttle is broken ATM on your machine. BTW if you boot with > > >hint.apic.0.disabled="1" > > >into /boot/loader.conf > > >does this solve the acpi_throttle issue? > > > > No. hint.apic.0.disabled makes no difference to me: > > hint.powernow.0.disabled has no effect (powernow0 still attaches) and > > throttling can still cause random lockups unless acpi_throttle is > > disabled. > > > > Thanks for your report. In order to disable powernow, you shouldn't > load the cpufreq kernel module, or don't compile your kernel > with the device cpufreq. > > The cpufreq.ko is a bundlle of different hw drivers related to > cpufreq, but without the acpi specfic ones, those being acpi_throttle and > acpi_perf and they are included into acpi.ko. > > After that check, you want to go back to powernow enabled and without > acpi_throttle, since powernow ofer way much more power saving than > throttling. > > Cheers, hi, I didnt read this thread from the beginning, and got confused with so many modules. i have a Turion X2, and -CURRENT on it. If I'd like to use that powersaving features, and frequency change capabilities ( I had a Pentium M based before and it used to work really fine, 6.1R in that time) now with this turion, what modules should I load ? it is possible to know this list, apart from trial and error ? thanks in advance, matheus -- We will call you cygnus, The God of balance you shall be From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 25 03:19:31 2007 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 0713216A419; Sat, 25 Aug 2007 03:19:31 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A7BD013C458; Sat, 25 Aug 2007 03:19:30 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l7P3JAve055164; Fri, 24 Aug 2007 21:19:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 24 Aug 2007 21:19:12 -0600 (MDT) Message-Id: <20070824.211912.1723235653.imp@bsdimp.com> To: william88@gmail.com From: "M. Warner Losh" In-Reply-To: <632825b40708241430u31f4eebbm671958abb5ec258c@mail.gmail.com> References: <46CE1ABC.2090008@root.org> <200708241241.39187.jhb@freebsd.org> <632825b40708241430u31f4eebbm671958abb5ec258c@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 24 Aug 2007 21:19:11 -0600 (MDT) Cc: freebsd-acpi@freebsd.org Subject: Re: msk dev problem with acpi 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: Sat, 25 Aug 2007 03:19:31 -0000 In message: <632825b40708241430u31f4eebbm671958abb5ec258c@mail.gmail.com> "William Grzybowski" writes: : On 8/24/07, John Baldwin wrote: : > : > On Thursday 23 August 2007 07:39:40 pm Nate Lawson wrote: : > > William Grzybowski wrote: : > > > On 8/21/07, *William Grzybowski* > > > wrote: : > > > : > > > On 8/21/07, *Nate Lawson* > : > wrote: : > > > : > > > Sean Bruno wrote: : > > > > William Grzybowski wrote: : > > > >> Hi! : > > > >> : > > > >> I'm having a problem with my marvell yukon ethernet when i : > boot : > my : > > > >> -CURRENT : > > > >> with the ACPI enable, it goes fine when acpi is off... : > > > >> I already tried to talk with the msk driver developer and : > he : > > > has now idea : > > > >> why it is happening and told me to try something here... : > > > >> : > > > >> dmesg error: : > > > >> mskc0: irq 16 at : > > > device 0.0 : > > > >> on pci2 : > > > >> mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, : > 0xffffffff). : > > > >> mskc0: unknown device: id=0x00, rev=0x00 : > > > >> device_attach: mskc0 attach returned 6 : > > > >> : > > > >> the card: : > > > >> mskc0@pci2:0:0: class=0x020000 card=0x01101025 : > chip=0x435211ab : > > > rev=0x14 : > > > >> hdr=0x00 : > > > >> vendor = 'Marvell Semiconductor (Was: Galileo : > > > Technology Ltd)' : > > > >> device = 'Yukon 88E8038 PCI-E Fast Ethernet : > Controller' : > > > >> class = network : > > > >> subclass = ethernet : > > > >> : > > > >> I am also attaching the acpidump and dmesg , : > > > >> If it can't be a apci isue, please, let me know. : > > > >> : > > > > I don't see any attachments in this email. Can you try : > > > resending to the : > > > > list? : > > > > : > > > : > > > Attachments that are too big are stripped. Please post a URL : > to : > the : > > > acpidump instead. : > > > : > > > -Nate : > > > : > > > : > > > It has just ~30kb, anyway, i am posting the links... : > > > http://www.inf.ufpr.br/wg06/acpi.gz : > > > : > > > http://www.inf.ufpr.br/wg06/dmesg.gz : > > > : > > > : > > > : > > > : > > > Hi, i was testing a verbose boot with acpi and without acpi, i noted a : > > > "requested unsupported memory range" with acpi... : > > > : > > > verbose dmesg with acpi: : > > > mskc0: irq 16 at device 0.0on : > pci2 : > > > pcib1: mskc0 requested unsupported memory range 0-0xffffffff (decoding : > > > 0-0, 0-0) : > > > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). : > > > mskc0: Lazy allocation of 0x4 bytes rid 0x14 type 4 at 0x1000 : > > > mskc0: unknown device: id=0xff, rev=0x0f : > > > : > > > and without acpi: : > > > mskc0: port 0x2000-0x20ff mem : > > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 : > > > mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xd0100000 : > > > mskc0: MSI count : 2 : > > > mskc0: attempting to allocate 2 MSI vectors (2 supported) : > > > : > > > Is that relevant? Maybe a issue in the msk driver allocation and not : > in : > > > acpi? : > > > Should I send all the verbose boots with and without acpi? : > > > : > > > Thanks, bye. : > > : > > I looked at the dmesg and ASL more carefully. It appears that PCI0 is : > > the only bus described in the ASL. Every device except mskc0 is on : > > pci0, so they all work. : > : > Yes, the ASL doesn't descend into the bridges. However, since disabling : > ACPI : > gives resources to the msk0 device it means that the BIOS is writing : > values : > into the BAR's for the bridge and the mskc0 device during POST, but that : > some : > _REG or _INI routine during ACPI enabling is clearing those BAR's for some : > reason. : > : > > --- : > > pcib0: port 0xcf8-0xcff on acpi0 : > > pci0: on pcib0 : > > pcib1: irq 16 at device 28.0 on pci0 : > > pci2: on pcib1 : > > mskc0: irq 16 at device 0.0 on : > pci2 : > > mskc0: 0x4000 bytes of rid 0x10 res 3 failed (0, 0xffffffff). : > > mskc0: unknown device: id=0xff, rev=0x0f : > > device_attach: mskc0 attach returned 6 : > > --- : > > : > > At this point, pci0 has a bunch of resources set via the _CRS method on : > > Device (PCI0). However, since there is no definition for pcib1, there : > > are no resources to assign to pcib1 and thus mskc0. : > : > Actually, we are too dumb to do that (on my list, but low). Right now : > Host-PCI bridges just try to alloc anything that's free, but with some : > tunables to limit the range. So the _CRS for the host bridges doesn't : > matter : > for how FreeBSD currently does things. : > : > > --- : > > pcib2: irq 17 at device 28.1 on pci0 : > > pci3: on pcib2 : > > pci3: at device 0.0 (no driver attached) : > > pcib3: irq 18 at device 28.2 on pci0 : > > pci4: on pcib3 : > > --- : > > : > > This is interesting. It appears to be a second ethernet adapter and : > > another PCI-PCI bridge that is empty? : > : > Yep. : > : > > So the question is what to do in the first case -- it seems easiest that : > > if a bridge has no resources, just pass everything up to the parent. Is : > > that what you're recommending, John? : > : > Well, sorta. The bridge needs to allocate resources and then hand them : > down : > to its children, but while this simple case is doable, the harder case is : > when you have multiple devices and no bridge resources, or you have bridge : > resources that aren't enough for all the devices you have, etc. Really : > fixing this requires that we do an early pass assigning resources to : > busses : > before any "leaf" drivers probe (but after all the bridges have probed), : > but : > for that we really need the multi-pass new-bus stuff. : > : > > But it's not clear who is erasing : > > the boot-time BARs in the acpi case. There is no method that appears to : > > reference pcib1 unless writing directly to its config space. It would : > > take a lot of analysis to figure that out statically, but should be easy : > > at runtime by just hacking in some printfs. : > : > Yeah, it's not obvious. I wonder if it's caused by a power reset? There : > is : > that \_SB_.PHRS routine (or whatever it's called) that seems to manage : > powering up and down devices? I noticed during _INI that if none of the : > _OSI : > stuff works (though we should be succeeding the _OSI("Linux") call) it : > appears to power off something (I think). Also, there are places that : > write : > into the config space of the bridges like RP01 (the parent for mskc0) (but : > below the BARs) when certain GPE's fire. Perhaps one of those registers : > causes a reset of that device, or perhaps one of them is actually part of : > a : > power management capability, etc. : : : : If I am wrong, tell me, but for what i can understand is it: : When the system boots it keeps probing the devices and fulling the resources : on pci bridge 0, but actually freebsd can't handle it and keep it going on a : second pci bridge bar, is that right or a sorta of it? Sorta, but not really. PCI is a tree structure. The nodes between levels are the pci bridges. They are responsible for forwarding bus transactions down the tree. Once upon a time, the BIOS would program these bridges such that the transactions would be forwarded. Any more, the BIOS leaves it to the OS to do this. FreeBSD needs to grow this ability. : Well, there is anyway to pass trough it discarding some useless devices to : use this bar "BAR" just for useful devices while you guys can't implement : it? Nope. You need to do the whole hierarchical resource thing. FreeBSD partially implements the hierarchical resource thing, but only when the bridge nodes are properly programmed. FreeBSD needs to be extended to program the bridge nodes. Warner From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 25 09:44:48 2007 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 8639016A417; Sat, 25 Aug 2007 09:44:48 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 0B5BF13C46C; Sat, 25 Aug 2007 09:44:47 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id l7P9iiXZ052832; Sat, 25 Aug 2007 06:44:44 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Sat, 25 Aug 2007 06:44:44 -0300 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200708250644.44972.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.90.3, clamav-milter version 0.90.3 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-acpi@freebsd.org, Ian Smith Subject: Re: powerd freeze with amd 5000 X2 but not with lower cpus 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: Sat, 25 Aug 2007 09:44:48 -0000 On Thursday 23 August 2007 14:37:57 Ian Smith wrote: > > so now I did because of your question and it seems the power_profile > > script has a bug > > > > I tries to set hw.acpi.cpu.cx_lowest=3DC1 > > > > but I guess it should be dev.cpu.0.cx_lowest > > Ah, ok. Updated in HEAD but not STABLE: > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/power_profile.diff?r1= =3Dte >xt&tr1=3D1.7&r2=3Dtext&tr2=3D1.11 > well, seems you are mistaken, it is not fixed, the new power_profile I have= on=20 my current is wrong as well # $FreeBSD: src/etc/rc.d/power_profile,v 1.11 2007/04/02 22:53:07=20 it still tries to set hw.acpi.cpu.cx_lowest but should set =20 dev.cpu.0.cx_lowest so it still gives the same erro =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br