From amistry at am-productions.biz Thu May 1 02:20:04 2008 From: amistry at am-productions.biz (Anish Mistry) Date: Thu May 1 02:20:06 2008 Subject: kern/121102: [acpi_fujitsu] [patch] update acpi_fujitsu for the P8010 Message-ID: <200805010220.m412K4g5056173@freefall.freebsd.org> The following reply was made to PR kern/121102; it has been noted by GNATS. From: Anish Mistry To: bug-followup@freebsd.org, amistry@am-productions.biz Cc: Subject: Re: kern/121102: [acpi_fujitsu] [patch] update acpi_fujitsu for the P8010 Date: Wed, 30 Apr 2008 22:15:59 -0400 --nextPart5846104.NFOZF52qm8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline This doesn't need to wait on kern/121504 since it still fixes the=20 sysctl toggling not working on the P8010. =2D-=20 Anish Mistry amistry@am-productions.biz AM Productions http://am-productions.biz/ --nextPart5846104.NFOZF52qm8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgZJ+AACgkQxqA5ziudZT0N6gCfd+NZtu5QOhsrE7Z5IR2QpKrK Q9UAn1Uws3AimopH9RlWHq+sXhCm5VQk =DhIx -----END PGP SIGNATURE----- --nextPart5846104.NFOZF52qm8-- From rpaulo at FreeBSD.org Thu May 1 12:59:32 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu May 1 12:59:37 2008 Subject: Biostar 945GC-M7 TE - won't suspend ("oper not supported"), even though sysctl's say S1 S3 supported In-Reply-To: <539c60b90804301105x7658d95eo6bb265420f85140c@mail.gmail.com> References: <539c60b90804301105x7658d95eo6bb265420f85140c@mail.gmail.com> Message-ID: <4819BEAE.2060307@FreeBSD.org> Steve Franks wrote: > Someone explain this to me. Maybe you have some device that doesn't allow you to suspend? That's common with some USB devices. Try detaching everything before suspending. Regards, -- Rui Paulo From stevefranks at ieee.org Thu May 1 20:39:07 2008 From: stevefranks at ieee.org (Steve Franks) Date: Thu May 1 20:39:11 2008 Subject: Biostar 945GC-M7 TE - won't suspend ("oper not supported"), even though sysctl's say S1 S3 supported In-Reply-To: <4819BEAE.2060307@FreeBSD.org> References: <539c60b90804301105x7658d95eo6bb265420f85140c@mail.gmail.com> <4819BEAE.2060307@FreeBSD.org> Message-ID: <539c60b90805011339l2d3c300cl6a5ea3af76f97539@mail.gmail.com> If that were the case, the error message I posted would be grossly misleading. Besides, I have no extra hardware after the motherboard except a second 100BT NIC. No flash drives, not even a hub. Steve On Thu, May 1, 2008 at 5:59 AM, Rui Paulo wrote: > Steve Franks wrote: > > > Someone explain this to me. > > > > Maybe you have some device that doesn't allow you to suspend? > That's common with some USB devices. Try detaching everything before > suspending. > > Regards, > -- > Rui Paulo > -- Steve Franks, KE7BTE Staff Engineer La Palma Devices, LLC http://www.lapalmadevices.com (520) 312-0089 From stevefranks at ieee.org Thu May 1 20:41:03 2008 From: stevefranks at ieee.org (Steve Franks) Date: Thu May 1 20:41:07 2008 Subject: Biostar 945GC-M7 TE - won't suspend ("oper not supported"), even though sysctl's say S1 S3 supported In-Reply-To: <539c60b90805011339l2d3c300cl6a5ea3af76f97539@mail.gmail.com> References: <539c60b90804301105x7658d95eo6bb265420f85140c@mail.gmail.com> <4819BEAE.2060307@FreeBSD.org> <539c60b90805011339l2d3c300cl6a5ea3af76f97539@mail.gmail.com> Message-ID: <539c60b90805011341i22d9f85ci7e6d20f925720698@mail.gmail.com> Ok, I admit, I had a ucom plugged in in the dmesg I sent, but I assure you, that isn't the issue. I even just double-checked. Steve On Thu, May 1, 2008 at 1:39 PM, Steve Franks wrote: > If that were the case, the error message I posted would be grossly > misleading. Besides, I have no extra hardware after the motherboard > except a second 100BT NIC. No flash drives, not even a hub. > > Steve > > > > On Thu, May 1, 2008 at 5:59 AM, Rui Paulo wrote: > > Steve Franks wrote: > > > > > Someone explain this to me. > > > > > > > Maybe you have some device that doesn't allow you to suspend? > > That's common with some USB devices. Try detaching everything before > > suspending. > > > > Regards, > > -- > > Rui Paulo > > > > > > -- > Steve Franks, KE7BTE > Staff Engineer > La Palma Devices, LLC > http://www.lapalmadevices.com > (520) 312-0089 > -- Steve Franks, KE7BTE Staff Engineer La Palma Devices, LLC http://www.lapalmadevices.com (520) 312-0089 From rpaulo at FreeBSD.org Thu May 1 21:16:42 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu May 1 21:16:46 2008 Subject: Biostar 945GC-M7 TE - won't suspend ("oper not supported"), even though sysctl's say S1 S3 supported In-Reply-To: <539c60b90805011341i22d9f85ci7e6d20f925720698@mail.gmail.com> References: <539c60b90804301105x7658d95eo6bb265420f85140c@mail.gmail.com> <4819BEAE.2060307@FreeBSD.org> <539c60b90805011339l2d3c300cl6a5ea3af76f97539@mail.gmail.com> <539c60b90805011341i22d9f85ci7e6d20f925720698@mail.gmail.com> Message-ID: <481A3333.6070407@FreeBSD.org> Steve Franks wrote: > Ok, I admit, I had a ucom plugged in in the dmesg I sent, but I assure > you, that isn't the issue. I even just double-checked. I think your best bet is boot with ACPI debug turned on. Try adding: options ACPI_DEBUG to your kernel config file, and: debug.acpi.layer=ACPI_ALL_DRIVERS debug.acpi.level=ACPI_LV_ALL_EXCEPTIONS If that doesn't show anything particularly interesting, try increasing the debugging level. For more information, see the acpi(4) man page. Good luck, -- Rui Paulo From bugmaster at FreeBSD.org Mon May 5 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 5 11:07:03 2008 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200805051106.m45B6xDm070605@freefall.freebsd.org> 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 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am 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/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/120953 acpi [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is o kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo 20 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 s kern/73823 acpi [request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/89411 acpi [acpi] acpiconf bug s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI 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 s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi [acpi] Dell C810 - ACPI problem o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f amd64/122521 acpi ACPI Error after upgrade to 7.0 o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot 22 problems total. From vishketan at yahoo.com Tue May 6 11:32:37 2008 From: vishketan at yahoo.com (Vishwanathan S V N) Date: Tue May 6 11:32:41 2008 Subject: Sony Vaio VGN SZ483NC warm docking issues Message-ID: <52395.36218.qm@web31707.mail.mud.yahoo.com> Hi! >> I used load acpi_dock.ko and then boot as suggested by you but theproblem still persists. I can undock successfully but cannot redock. > Hmm, your \_SB.DOCK._STA method always seems to return zero (i.e. dock > status method indicates that the system is undocked all the time) > that's why the same problem occurs on Linux kernel, I guess. This issue is now fixed in the Linux kernel (see http://bugzilla.kernel.org/show_bug.cgi?id=10431). Maybe this information can be used fix it in the FreeBSD too? vishy ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From nate at root.org Tue May 6 16:35:38 2008 From: nate at root.org (Nate Lawson) Date: Tue May 6 16:35:43 2008 Subject: Sony Vaio VGN SZ483NC warm docking issues In-Reply-To: <52395.36218.qm@web31707.mail.mud.yahoo.com> References: <52395.36218.qm@web31707.mail.mud.yahoo.com> Message-ID: <482088D4.9030705@root.org> Vishwanathan S V N wrote: > Hi! > >>> I used load acpi_dock.ko and then boot as suggested by you but theproblem still persists. I can undock successfully but cannot redock. > >> Hmm, your \_SB.DOCK._STA method always seems to return zero (i.e. dock >> status method indicates that the system is undocked all the time) >> that's why the same problem occurs on Linux kernel, I guess. > > This issue is now fixed in the Linux kernel (see http://bugzilla.kernel.org/show_bug.cgi?id=10431). Maybe this information can be used fix it in the FreeBSD too? > > vishy It seems the _DCK method must be called unconditionally in the Notify handler. Here is the relevant text from the Linux bug: > The reason I thought it could be related is the common feature: the _STA method > on the dock device returns a false zero. The Dell then freezes because it > receives a continuous stream of ACPI events until the kernel responds by > calling the _DCK method. It looks as if the Vaio only sends a single ACPI > event, and thus doesn't freeze. -- Nate From sfourman at gmail.com Fri May 9 17:28:31 2008 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Fri May 9 17:28:35 2008 Subject: Need help with a new Motherboard Message-ID: <11167f520805090959g2a0a3105pf51faaf1b683df09@mail.gmail.com> hello, I need help, I can't seem to get FreBSD to run on a Foxconn G31MX-K without a panic the only think in a dmesg i can find is this error ACPI Error (psparse-0626): Method parse/execution failed [\\_PR_.CPU0._OSC] (Node 0xc505b9c0), AE_ALREADY_EXISTS http://www.foxconnchannel.com/product/Motherboards/detail_overview.aspx?ID=en-us0000345 here are 2 dmesg's http://www.puffybsd.com/G31MX-K-8 <-- 8 -CURRENT http://www.puffybsd.com/G31MX-K <-- RELENG_7 the intent was to run PC-BSD 1.5.1 on these systems,but it panics when it is coping the cd contents to memory right before x loads any help would be helpful Sam Fourman Jr. From jhb at freebsd.org Fri May 9 19:34:25 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri May 9 19:34:29 2008 Subject: Need help with a new Motherboard In-Reply-To: <11167f520805090959g2a0a3105pf51faaf1b683df09@mail.gmail.com> References: <11167f520805090959g2a0a3105pf51faaf1b683df09@mail.gmail.com> Message-ID: <200805091358.13854.jhb@freebsd.org> On Friday 09 May 2008 12:59:37 pm Sam Fourman Jr. wrote: > hello, > I need help, I can't seem to get FreBSD to run on a Foxconn G31MX-K > without a panic > the only think in a dmesg i can find is this error > > ACPI Error (psparse-0626): Method parse/execution failed > [\\_PR_.CPU0._OSC] (Node 0xc505b9c0), AE_ALREADY_EXISTS > > http://www.foxconnchannel.com/product/Motherboards/detail_overview.aspx?ID=en-us0000345 > > here are 2 dmesg's > > http://www.puffybsd.com/G31MX-K-8 <-- 8 -CURRENT > http://www.puffybsd.com/G31MX-K <-- RELENG_7 > > the intent was to run PC-BSD 1.5.1 on these systems,but it panics when > it is coping the cd contents to memory right before x loads You can ignore those warnings. Can you get the actual panic messages somehow? Perhaps use a serial console? -- John Baldwin From sfourman at gmail.com Fri May 9 23:01:42 2008 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Fri May 9 23:01:45 2008 Subject: Need help with a new Motherboard In-Reply-To: <200805091358.13854.jhb@freebsd.org> References: <11167f520805090959g2a0a3105pf51faaf1b683df09@mail.gmail.com> <200805091358.13854.jhb@freebsd.org> Message-ID: <11167f520805091601q532e477egc1ae4e9bc993bde@mail.gmail.com> > You can ignore those warnings. Can you get the actual panic messages somehow? > Perhaps use a serial console? > is there a howto, that I can use to setup a serial console? I have several computers so I could do it. Sam Fourman Jr. From alex.wilkinson at dsto.defence.gov.au Sat May 10 06:58:18 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Sat May 10 06:58:22 2008 Subject: Need help with a new Motherboard In-Reply-To: <11167f520805091601q532e477egc1ae4e9bc993bde@mail.gmail.com> References: <11167f520805090959g2a0a3105pf51faaf1b683df09@mail.gmail.com> <200805091358.13854.jhb@freebsd.org> <11167f520805091601q532e477egc1ae4e9bc993bde@mail.gmail.com> Message-ID: <20080510063808.GF22514@stlux503.dsto.defence.gov.au> 0n Fri, May 09, 2008 at 06:01:41PM -0500, Sam Fourman Jr. wrote: >is there a howto, that I can use to setup a serial console? >I have several computers so I could do it. Yes: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From avg at icyb.net.ua Sun May 11 21:02:23 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Sun May 11 21:02:27 2008 Subject: intpm: minor issues in debug printing Message-ID: <48275EDC.9030808@icyb.net.ua> I've recently performed some hacking of SMBus-attached peripherals in PIIX4-based system and I haven't always been nice to the bus. While doing that I noticed two very minor issues with printing in intpm.c. I got "mysterious" messages like the following: unknown: unknown cause why? [Two "unknowns" is too much :-)] The attached patch should fix that. -- Andriy Gapon -------------- next part -------------- diff --git a/sys/pci/intpm.c b/sys/pci/intpm.c index 2e5e815..3cae6cc 100644 --- a/sys/pci/intpm.c +++ b/sys/pci/intpm.c @@ -110,6 +110,8 @@ intsmb_attach(device_t dev) int error, rid, value; char *str; + sc->dev = dev; + mtx_init(&sc->lock, device_get_nameunit(dev), "intsmb", MTX_DEF); rid = PCI_BASE_ADDR_SMB; @@ -410,7 +412,7 @@ intsmb_stop_poll(struct intsmb_softc *sc) sc->isbusy = 0; error = intsmb_error(status); if (error == 0 && !(status & PIIX4_SMBHSTSTAT_INTR)) - device_printf(sc->dev, "unknown cause why?"); + device_printf(sc->dev, "unknown cause why?\n"); return (error); } } From bugmaster at FreeBSD.org Mon May 12 11:06:51 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 12 11:06:53 2008 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200805121106.m4CB6oOU037909@freefall.freebsd.org> 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 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am 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/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/120953 acpi [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is o kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo 20 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 s kern/73823 acpi [request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/89411 acpi [acpi] acpiconf bug s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI 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 s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi [acpi] Dell C810 - ACPI problem o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f amd64/122521 acpi ACPI Error after upgrade to 7.0 o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot 22 problems total. From stevefranks at ieee.org Mon May 12 20:48:00 2008 From: stevefranks at ieee.org (Steve Franks) Date: Mon May 12 20:48:03 2008 Subject: Biostar 945GC-M7 TE - won't suspend ("oper not supported"), even though sysctl's say S1 S3 supported In-Reply-To: <481A3333.6070407@FreeBSD.org> References: <539c60b90804301105x7658d95eo6bb265420f85140c@mail.gmail.com> <4819BEAE.2060307@FreeBSD.org> <539c60b90805011339l2d3c300cl6a5ea3af76f97539@mail.gmail.com> <539c60b90805011341i22d9f85ci7e6d20f925720698@mail.gmail.com> <481A3333.6070407@FreeBSD.org> Message-ID: <539c60b90805121347l4835d558w95666aeb10755600@mail.gmail.com> On Thu, May 1, 2008 at 2:16 PM, Rui Paulo wrote: > Steve Franks wrote: > > > Ok, I admit, I had a ucom plugged in in the dmesg I sent, but I assure > > you, that isn't the issue. I even just double-checked. > > > > I think your best bet is boot with ACPI debug turned on. > Try adding: > options ACPI_DEBUG > to your kernel config file, and: > debug.acpi.layer=ACPI_ALL_DRIVERS > debug.acpi.level=ACPI_LV_ALL_EXCEPTIONS > > If that doesn't show anything particularly interesting, try increasing the > debugging level. > For more information, see the acpi(4) man page. > > Good luck, > -- > Rui Paulo > Finally got around to rebuilding my kernel with options acpi debug. Not everyone recognizes blah.foo.bar=somestring as an input to sysctl, and the acpi manpage is less than explicit about it also, by the way, saying only "some of these things have equivalent sysctl's". Not having much luck, other than a shiny new kernel, though: Steve [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo sysctl debug.acpi.layer=ACPI_ALL_DRIVERS debug.acpi.layer: NONE -> ACPI_AC_ADAPTER ACPI_BATTERY ACPI_BUS ACPI_BUTTON ACPI_EC ACPI_FAN ACPI_POWERRES ACPI_PROCESSOR ACPI_THERMAL ACPI_TIMER ACPI_ALL_DRIVERS [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo sysctl debug.acpi.level=ACPI_LV_ALL_EXCEPTIONS debug.acpi.level: NONE -> ACPI_LV_ERROR ACPI_LV_WARN ACPI_LV_INIT ACPI_LV_DEBUG_OBJECT ACPI_LV_INFO ACPI_LV_ALL_EXCEPTIONS [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo sysctl hw.acpi.verbose=1 hw.acpi.verbose: 0 -> 1 [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo acpiconf -s3 acpiconf: request sleep type (3) failed: Operation not supported [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ dmesg Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE-p1 #0: Mon May 12 11:27:26 MST 2008 root@dystant.franks-development.dyndns.biz:/usr/obj/usr/src/sys/DYSTANT Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 430 @ 1.80GHz (1799.99-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10661 Stepping = 1 Features=0xafebfbff Features2=0xe31d AMD Features=0x20100800 AMD Features2=0x1 usable memory = 1051373568 (1002 MB) avail memory = 1012994048 (966 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=513364kB. ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (May 12 2008 11:27:11) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3f6f0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 cpu0: on acpi0 p4tcc0: on cpu0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xff00-0xff07 mem 0xfde80000-0xfdefffff,0xc0000000-0xcfffffff,0xfdf00000-0xfdf3ffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M pcm0: mem 0xfdff8000-0xfdffbfff irq 16 at device 27.0 on pci0 pcm0: [ITHREAD] pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 pci2: at device 0.0 (no driver attached) uhci0: port 0xfe00-0xfe1f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] uhci0: LegSup = 0x003a usb0: on uhci0 usb0: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xfd00-0xfd1f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] uhci1: LegSup = 0x0010 usb1: on uhci1 usb1: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xfc00-0xfc1f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] uhci2: LegSup = 0x0010 usb2: on uhci2 usb2: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xfb00-0xfb1f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] uhci3: LegSup = 0x0010 usb3: on uhci3 usb3: USB revision 1.0 usbd_get_string: getting lang failed, using 0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfdfff000-0xfdfff3ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib3: at device 30.0 on pci0 pci3: on pcib3 vr0: port 0xde00-0xdeff mem 0xfdaff000-0xfdaff0ff irq 16 at device 2.0 on pci3 vr0: Quirks: 0x0 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: using obsoleted if_watchdog interface vr0: Ethernet address: 00:1b:11:b0:ec:1d vr0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xf900-0xf907,0xf800-0xf803,0xf700-0xf707,0xf600-0xf603,0xf500-0xf50f mem 0xfdffe000-0xfdffe3ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: on uhub1 ums0: 4 buttons and Z dir. ugen0: on uhub1 ugen1: on uhub2 Timecounter "TSC" frequency 1799986311 Hz quality 800 Timecounters tick every 1.000 msec hptrr: no controller detected. acd0: DVDR at ata0-master UDMA33 ad4: 152627MB at ata2-master SATA150 pcm0: pcm0: Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted tap0: Ethernet address: 00:bd:bc:16:00:00 tap1: Ethernet address: 00:bd:cd:16:00:01 tap2: Ethernet address: 00:bd:d0:16:00:02 tap3: Ethernet address: 00:bd:d4:16:00:03 tap4: Ethernet address: 00:bd:d7:16:00:04 tap5: Ethernet address: 00:bd:db:16:00:05 tap6: Ethernet address: 00:bd:e0:16:00:06 tap7: Ethernet address: 00:bd:e5:16:00:07 tap8: Ethernet address: 00:bd:e9:16:00:08 tap9: Ethernet address: 00:bd:ef:16:00:09 drm0: on vgapci0 info: [drm] AGP at 0xc0000000 256MB info: [drm] Initialized i915 1.5.0 20060119 drm0: [ITHREAD] ACPI set debug layer 'ACPI_ALL_DRIVERS' ACPI set debug layer 'ACPI_ALL_DRIVERS' level 'ACPI_LV_ALL_EXCEPTIONS' [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ From rpaulo at FreeBSD.org Mon May 12 21:31:25 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Mon May 12 21:31:29 2008 Subject: Biostar 945GC-M7 TE - won't suspend ("oper not supported"), even though sysctl's say S1 S3 supported In-Reply-To: <539c60b90805121347l4835d558w95666aeb10755600@mail.gmail.com> References: <539c60b90804301105x7658d95eo6bb265420f85140c@mail.gmail.com> <4819BEAE.2060307@FreeBSD.org> <539c60b90805011339l2d3c300cl6a5ea3af76f97539@mail.gmail.com> <539c60b90805011341i22d9f85ci7e6d20f925720698@mail.gmail.com> <481A3333.6070407@FreeBSD.org> <539c60b90805121347l4835d558w95666aeb10755600@mail.gmail.com> Message-ID: <4828B725.1010500@FreeBSD.org> Steve Franks wrote: > On Thu, May 1, 2008 at 2:16 PM, Rui Paulo wrote: >> Steve Franks wrote: >> >>> Ok, I admit, I had a ucom plugged in in the dmesg I sent, but I assure >>> you, that isn't the issue. I even just double-checked. >>> >> I think your best bet is boot with ACPI debug turned on. >> Try adding: >> options ACPI_DEBUG >> to your kernel config file, and: >> debug.acpi.layer=ACPI_ALL_DRIVERS >> debug.acpi.level=ACPI_LV_ALL_EXCEPTIONS >> >> If that doesn't show anything particularly interesting, try increasing the >> debugging level. >> For more information, see the acpi(4) man page. >> >> Good luck, >> -- >> Rui Paulo >> > > Finally got around to rebuilding my kernel with options acpi debug. > Not everyone recognizes blah.foo.bar=somestring as an input to sysctl, > and the acpi manpage is less than explicit about it also, by the way, > saying only "some of these things have equivalent sysctl's". > > Not having much luck, other than a shiny new kernel, though: > > Steve > > [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo sysctl > debug.acpi.layer=ACPI_ALL_DRIVERS > debug.acpi.layer: NONE -> ACPI_AC_ADAPTER ACPI_BATTERY ACPI_BUS > ACPI_BUTTON ACPI_EC ACPI_FAN ACPI_POWERRES ACPI_PROCESSOR ACPI_THERMAL > ACPI_TIMER ACPI_ALL_DRIVERS > [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo sysctl > debug.acpi.level=ACPI_LV_ALL_EXCEPTIONS > debug.acpi.level: NONE -> ACPI_LV_ERROR ACPI_LV_WARN ACPI_LV_INIT > ACPI_LV_DEBUG_OBJECT ACPI_LV_INFO ACPI_LV_ALL_EXCEPTIONS > [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo sysctl hw.acpi.verbose=1 > hw.acpi.verbose: 0 -> 1 > [steve@dystant /usr/obj/usr/src/sys/DYSTANT]$ sudo acpiconf -s3 > acpiconf: request sleep type (3) failed: Operation not supported :-( Well, I'm really out of ideas... Sorry, -- Rui Paulo From jhb at freebsd.org Mon May 12 22:10:16 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon May 12 22:10:20 2008 Subject: intpm: minor issues in debug printing In-Reply-To: <48275EDC.9030808@icyb.net.ua> References: <48275EDC.9030808@icyb.net.ua> Message-ID: <200805121735.04792.jhb@freebsd.org> On Sunday 11 May 2008 05:02:20 pm Andriy Gapon wrote: > > I've recently performed some hacking of SMBus-attached peripherals in > PIIX4-based system and I haven't always been nice to the bus. While > doing that I noticed two very minor issues with printing in intpm.c. > I got "mysterious" messages like the following: > unknown: unknown cause why? > [Two "unknowns" is too much :-)] > The attached patch should fix that. Committed, thanks! -- John Baldwin From takawata at init-main.com Tue May 13 11:45:59 2008 From: takawata at init-main.com (takawata@init-main.com) Date: Tue May 13 11:46:07 2008 Subject: SMP suspend/resume. Message-ID: <200805131125.m4DBPu1q092741@sana.init-main.com> Hi, I managed to make suspend and resume work on SMP system. The patch following is a bit crude patch, but it begin to work on my ThinkPad X61 (core2duo system). TODO: 1. Suspend/resume path it self is simular to AP boot path. Some of code may be integrated. 2. More context, like MTRR or npx context should be saved on suspend. 3. Make acpi suspend resume path more ABI aware: needless register recoverly or special register context saving (the value itself is usually constant) should be removed. 4. Make same binary module work on both UP or SMP case. (Or is it time to give up using acpi module on also on i386?) Index: i386/acpica/acpi_wakeup.c =================================================================== RCS file: /home/ncvs/src/sys/i386/acpica/acpi_wakeup.c,v retrieving revision 1.47 diff -u -r1.47 acpi_wakeup.c --- i386/acpica/acpi_wakeup.c 16 Mar 2008 10:58:03 -0000 1.47 +++ i386/acpica/acpi_wakeup.c 13 May 2008 09:12:18 -0000 @@ -27,6 +27,7 @@ #include __FBSDID("$FreeBSD: src/sys/i386/acpica/acpi_wakeup.c,v 1.47 2008/03/16 10:58:03 rwatson Exp $"); +#define SMP #include #include @@ -49,6 +50,11 @@ #include #include +#include +#include +#include +#include +#include #include "acpi_wakecode.h" @@ -71,7 +77,9 @@ static uint16_t r_cs, r_ds, r_es, r_fs, r_gs, r_ss, r_tr; static uint32_t r_esp; - +extern void *bootstacks[]; +static char *bootSTK; +void restore_sub(void); static void acpi_printcpu(void); static void acpi_realmodeinst(void *arg, bus_dma_segment_t *segs, int nsegs, int error); @@ -80,6 +88,7 @@ /* XXX shut gcc up */ extern int acpi_savecpu(void); extern int acpi_restorecpu(void); +extern void acpi_kicksub(void); #ifdef __GNUCLIKE_ASM __asm__(" \n\ @@ -104,6 +113,15 @@ movl %eax,(%esp) \n\ xorl %eax,%eax \n\ ret \n\ + \n\ + .text \n\ + .p2align 2, 0x90 \n\ + .type acpi_kicksub, @function \n\ +acpi_kicksub: \n\ + .align 4 \n\ + movl bootSTK,%esp \n\ + jmp restore_sub \n\ + ret \n\ \n\ .text \n\ .p2align 2, 0x90 \n\ @@ -149,6 +167,24 @@ ret \n\ "); #endif /* __GNUCLIKE_ASM */ +int acpi_cpu_resumed[MAXCPU]; +int acpi_curcpu; +extern int switch_debug; + +void restore_sub() +{ + ACPI_DISABLE_IRQS(); + printf("RESTORE_SUB\n"); + lapic_disable(); + printf("LAPIC_SETUP\n"); + lapic_setup(0); + lapic_dump("RESTORE_SUB"); + printf("RESTORE_SUB2\n"); + ACPI_ENABLE_IRQS(); + + acpi_cpu_resumed[acpi_curcpu]= 1; + acpi_restorecpu(); +} static void acpi_printcpu(void) @@ -187,6 +223,119 @@ outb(0x61, inb(0x61) & ~0x3); } + +int resume_other_cpu(struct acpi_softc *sc, int cpu); +int resume_other_cpu(struct acpi_softc *sc, int cpu) +{ + int ms; + int apic_id = cpu_apic_ids[cpu]; + int gsel_tss; + + gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); + acpi_curcpu = cpu; + bootSTK= (char *)bootstacks[cpu] + KSTACK_PAGES * PAGE_SIZE - 4; + printf("%p\n", bootSTK); + p_gdt = (struct region_descriptor *) + (sc->acpi_wakeaddr + physical_gdt); + saved_gdt.rd_limit = NGDT * sizeof(gdt[0]) -1; + saved_gdt.rd_base = (int )&gdt[cpu*NGDT]; + p_gdt->rd_limit = saved_gdt.rd_limit; + p_gdt->rd_base = vtophys(saved_gdt.rd_base); + r_esp = stoppcbs[cpu].pcb_esp; + r_ebp = stoppcbs[cpu].pcb_ebp; + r_esi = stoppcbs[cpu].pcb_esi; + r_edi = stoppcbs[cpu].pcb_edi; + r_efl = stoppcbs[cpu].pcb_psl; + ret_addr = stoppcbs[cpu].pcb_eip; + WAKECODE_FIXUP(physical_esp, uint32_t, vtophys(bootSTK) ); + WAKECODE_FIXUP(previous_cr0, uint32_t, r_cr0); + WAKECODE_FIXUP(previous_cr2, uint32_t, r_cr2); + WAKECODE_FIXUP(previous_cr3, uint32_t, r_cr3); + WAKECODE_FIXUP(previous_cr4, uint32_t, r_cr4); + + WAKECODE_FIXUP(resume_beep, uint32_t, 0); + WAKECODE_FIXUP(reset_video, uint32_t, 0); + + WAKECODE_FIXUP(previous_tr, uint16_t, gsel_tss); + WAKECODE_BCOPY(previous_gdt, struct region_descriptor, saved_gdt); + WAKECODE_FIXUP(previous_ldt, uint16_t, saved_ldt); + WAKECODE_BCOPY(previous_idt, struct region_descriptor, saved_idt); + + WAKECODE_FIXUP(where_to_recover, void *, acpi_kicksub); + + WAKECODE_FIXUP(previous_ds, uint16_t, r_ds); + WAKECODE_FIXUP(previous_es, uint16_t, r_es); + WAKECODE_FIXUP(previous_fs, uint16_t, r_fs); + WAKECODE_FIXUP(previous_gs, uint16_t, 0); + WAKECODE_FIXUP(previous_ss, uint16_t, r_ss); + + /* do an INIT IPI: assert RESET */ + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | + APIC_LEVEL_ASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, apic_id); + + /* wait for pending status end */ + lapic_ipi_wait(-1); + + /* do an INIT IPI: deassert RESET */ + lapic_ipi_raw(APIC_DEST_ALLESELF | APIC_TRIGMOD_LEVEL | + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, 0); + + /* wait for pending status end */ + DELAY(10000); /* wait ~10mS */ + lapic_ipi_wait(-1); + /* + * next we do a STARTUP IPI: the previous INIT IPI might still be + * latched, (P5 bug) this 1st STARTUP would then terminate + * immediately, and the previously started INIT IPI would continue. OR + * the previous INIT IPI has already run. and this STARTUP IPI will + * run. OR the previous INIT IPI was ignored. and this STARTUP IPI + * will run. + */ + + /* do a STARTUP IPI */ + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP | + ((sc->acpi_wakephys >>12)&0xff), apic_id); + lapic_ipi_wait(-1); + DELAY(200); /* wait ~200uS */ + + /* + * finally we do a 2nd STARTUP IPI: this 2nd STARTUP IPI should run IF + * the previous STARTUP IPI was cancelled by a latched INIT IPI. OR + * this STARTUP IPI will be ignored, as only ONE STARTUP IPI is + * recognized after hardware RESET or INIT IPI. + */ + + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP | + ((sc->acpi_wakephys >>12)&0xff), apic_id); + lapic_ipi_wait(-1); + DELAY(200); /* wait ~200uS */ + + /* Wait up to 5 seconds for it to start. */ + for (ms = 0; ms < 5000; ms++) { + if(acpi_cpu_resumed[cpu]){ + acpi_cpu_resumed[cpu]= 0; + return 0; + } + DELAY(1000); + } + return -1; /* return FAILURE */ + +} +int resume_other_cpus(struct acpi_softc *sc); +int resume_other_cpus(struct acpi_softc *sc) +{ + int i; + printf("RESUME_OTHER_CPUS"); + *((volatile u_short *) 0x467) = 0; + *((volatile u_short *) 0x468) = (sc->acpi_wakephys&0xffff0)>>4; + + for(i = 1; i < mp_ncpus; i++){ + resume_other_cpu(sc, i); + } + return 0; +} int acpi_sleep_machdep(struct acpi_softc *sc, int state) { @@ -270,14 +419,15 @@ for (;;) ; } else { /* Execute Wakeup */ - intr_resume(); - if (bootverbose) { acpi_savecpu(); acpi_printcpu(); } + resume_other_cpus(sc); + restart_cpus(stopped_cpus); + intr_resume(); + lapic_dump("MAIN"); } - out: load_cr3(cr3); write_eflags(ef); @@ -285,7 +435,7 @@ /* If we beeped, turn it off after a delay. */ if (acpi_resume_beep) timeout(acpi_stop_beep, NULL, 3 * hz); - + printf("FUGAFUGA\n"); return (ret); } Index: i386/i386/io_apic.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/io_apic.c,v retrieving revision 1.35 diff -u -r1.35 io_apic.c --- i386/i386/io_apic.c 5 Jun 2007 18:57:48 -0000 1.35 +++ i386/i386/io_apic.c 13 May 2008 08:22:55 -0000 @@ -444,8 +444,9 @@ struct ioapic *io = (struct ioapic *)pic; int i; - for (i = 0; i < io->io_numintr; i++) + for (i = 0; i < io->io_numintr; i++){ ioapic_program_intpin(&io->io_pins[i]); + } } /* Index: i386/i386/mp_machdep.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v retrieving revision 1.286 diff -u -r1.286 mp_machdep.c --- i386/i386/mp_machdep.c 10 Apr 2008 18:38:31 -0000 1.286 +++ i386/i386/mp_machdep.c 13 May 2008 07:08:29 -0000 @@ -1299,18 +1299,19 @@ int cpu = PCPU_GET(cpuid); int cpumask = PCPU_GET(cpumask); - savectx(&stoppcbs[cpu]); - - /* Indicate that we are stopped */ - atomic_set_int(&stopped_cpus, cpumask); + if(savectx(&stoppcbs[cpu])){ + /* Indicate that we are stopped */ + atomic_set_int(&stopped_cpus, cpumask); + wbinvd(); + } /* Wait for restart */ - while (!(started_cpus & cpumask)) - ia32_pause(); - + while (!(started_cpus & cpumask)){ + ia32_pause(); + } atomic_clear_int(&started_cpus, cpumask); atomic_clear_int(&stopped_cpus, cpumask); - + if (cpu == 0 && cpustop_restartfunc != NULL) { cpustop_restartfunc(); cpustop_restartfunc = NULL; Index: i386/i386/swtch.s =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/swtch.s,v retrieving revision 1.156 diff -u -r1.156 swtch.s --- i386/i386/swtch.s 22 Aug 2007 05:06:14 -0000 1.156 +++ i386/i386/swtch.s 9 May 2008 15:16:03 -0000 @@ -413,6 +413,6 @@ 1: popfl #endif /* DEV_NPX */ - + movl $1, %eax ret END(savectx) Index: i386/include/pcb.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/pcb.h,v retrieving revision 1.56 diff -u -r1.56 pcb.h --- i386/include/pcb.h 29 Dec 2005 13:23:48 -0000 1.56 +++ i386/include/pcb.h 24 Apr 2008 06:46:59 -0000 @@ -81,7 +81,7 @@ struct trapframe; void makectx(struct trapframe *, struct pcb *); -void savectx(struct pcb *); +int savectx(struct pcb *); #endif #endif /* _I386_PCB_H_ */ Index: dev/acpica/acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.247 diff -u -r1.247 acpi.c --- dev/acpica/acpi.c 13 Mar 2008 20:39:03 -0000 1.247 +++ dev/acpica/acpi.c 30 Apr 2008 13:14:48 -0000 @@ -29,7 +29,7 @@ #include __FBSDID("$FreeBSD: src/sys/dev/acpica/acpi.c,v 1.247 2008/03/13 20:39:03 jhb Exp $"); - +#define SMP #include "opt_acpi.h" #include #include @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -2339,6 +2340,8 @@ * drivers need this. */ mtx_lock(&Giant); + sched_bind(curthread, 0); + stop_cpus(PCPU_GET(other_cpus)); slp_state = ACPI_SS_NONE; switch (state) { case ACPI_STATE_S1: @@ -2430,13 +2433,16 @@ acpi_wake_prep_walk(state); sc->acpi_sstate = ACPI_STATE_S0; } + printf("PREP WALK\n"); if (slp_state >= ACPI_SS_SLP_PREP) AcpiLeaveSleepState(state); + printf("LEAVE_SLEEP_STATE\n"); if (slp_state >= ACPI_SS_DEV_SUSPEND) DEVICE_RESUME(root_bus); + printf("DEVICE_RESUME\n"); if (slp_state >= ACPI_SS_SLEPT) acpi_enable_fixed_events(sc); - + printf("ENABLE_FIXED_EVENT\n"); /* Allow another sleep request after a while. */ if (state != ACPI_STATE_S5) timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME); @@ -2445,6 +2451,7 @@ acpi_UserNotify("Resume", ACPI_ROOT_OBJECT, state); mtx_unlock(&Giant); + sched_unbind(curthread); return_ACPI_STATUS (status); } Index: dev/acpica/acpi_ec.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v retrieving revision 1.80 diff -u -r1.80 acpi_ec.c --- dev/acpica/acpi_ec.c 8 Nov 2007 21:20:34 -0000 1.80 +++ dev/acpica/acpi_ec.c 7 May 2008 17:07:11 -0000 @@ -747,7 +747,7 @@ * If booting, check if we need to run the query handler. If so, we * we call it directly here since our thread taskq is not active yet. */ - if (cold || rebooting) { + if (cold || rebooting||sc->ec_suspending) { if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { CTR0(KTR_ACPI, "ec running gpe handler directly"); EcGpeQueryHandler(sc); From rpaulo at FreeBSD.org Wed May 14 10:10:49 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Wed May 14 10:10:53 2008 Subject: SMP suspend/resume. In-Reply-To: <200805131125.m4DBPu1q092741@sana.init-main.com> References: <200805131125.m4DBPu1q092741@sana.init-main.com> Message-ID: <482ABAA5.6020300@FreeBSD.org> takawata@init-main.com wrote: > Hi, I managed to make suspend and resume work on SMP system. > The patch following is a bit crude patch, but it begin > to work on my ThinkPad X61 (core2duo system). > > TODO: > 1. Suspend/resume path it self is simular to AP boot path. > Some of code may be integrated. > 2. More context, like MTRR or npx context should be saved on > suspend. > 3. Make acpi suspend resume path more ABI aware: needless > register recoverly or special register context saving > (the value itself is usually constant) should be removed. > 4. Make same binary module work on both UP or SMP case. > (Or is it time to give up using acpi module on also on i386?) > Thanks! This is great work! I can look at your patch, but I'm not the best one to comment on it. Regards, -- Rui Paulo From sebosik at demax.sk Wed May 14 12:25:27 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed May 14 12:25:32 2008 Subject: SMP suspend/resume. Message-ID: <482AD2B6.20704@demax.sk> Hi I`ve tried your attached patch against RELENG-7 synchronized today.. rebuilt kernel with patched sources and on reboot I got this (only important part.. I don`t wanna mess mailing list): FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #7: Wed May 14 13:43:52 CEST 2008 root@localhost:/usr/obj/usr/src/sys/notebook link_elf: symbol bootstacks undefined KLD file acpi.ko - could not finalize loading How to solve/debug link_elf problem ? Any ideas? Best regards --- Jan Sebosik, Slovakia sebosik@demax.sk From takawata at init-main.com Wed May 14 13:11:28 2008 From: takawata at init-main.com (Takanori Watanabe) Date: Wed May 14 13:11:32 2008 Subject: SMP suspend/resume. In-Reply-To: Your message of "Wed, 14 May 2008 13:53:26 +0200." <482AD2B6.20704@demax.sk> Message-ID: <200805141251.m4ECp7NK015436@sana.init-main.com> In message <482AD2B6.20704@demax.sk>, Jan Sebosik さんいわく: >Hi > >I`ve tried your attached patch against RELENG-7 synchronized today.. >rebuilt kernel with patched sources and on reboot I got this (only >important part.. I don`t wanna mess mailing list): > >FreeBSD is a registered trademark of The FreeBSD Foundation. >FreeBSD 7.0-STABLE #7: Wed May 14 13:43:52 CEST 2008 > root@localhost:/usr/obj/usr/src/sys/notebook >link_elf: symbol bootstacks undefined >KLD file acpi.ko - could not finalize loading > >How to solve/debug link_elf problem ? > >Any ideas? The symbol is introduced on 1.282 of mp_machdep.c And you have to merge 1.286 change to preserve identity mapping for ACPI wakeup routine. You may want to merge them from current. From efajardo1 at verizon.net Wed May 14 14:42:00 2008 From: efajardo1 at verizon.net (Maxorata) Date: Wed May 14 14:42:09 2008 Subject: Thinkpad T61p Message-ID: <17232169.post@talk.nabble.com> Hi, I just bought a Thinkpad T61 with the Nvidia graphics card (256 Mg) and am having trouble with suspend/resume. In fact it does not work at all. Only the fan seems to behave normally. It starts and stops the way it should, both when running on AC or battery. I'm running FreeBSD 6.3 i386 Final and I have absolutely no idea as to what drivers should I load to make this work. I've searched all over the internet but never found any information specific to my Thinkpad model that would help me solve this problem. I know that I'm supposed to add an entry to my /boot/loader.conf file but I don't know what to enter there. Can any one please tell me EXACTLY what to enter in that file to enable suspend/resume? I'm not too worried about the special keys, but if I can get them to work too, that would be nice. Perhaps someone who also owns a Thinkpad T61p can help me. Thank you very much. -- View this message in context: http://www.nabble.com/Thinkpad-T61p-tp17232169p17232169.html Sent from the freebsd-acpi mailing list archive at Nabble.com. From takawata at init-main.com Wed May 14 14:58:16 2008 From: takawata at init-main.com (Takanori Watanabe) Date: Wed May 14 14:58:21 2008 Subject: Thinkpad T61p In-Reply-To: Your message of "Wed, 14 May 2008 07:17:45 MST." <17232169.post@talk.nabble.com> Message-ID: <200805141438.m4EEc09O016052@sana.init-main.com> In message <17232169.post@talk.nabble.com>, Maxorata wrote: > >Hi, >I just bought a Thinkpad T61 with the Nvidia graphics card (256 Mg) and am >having trouble with suspend/resume. In fact it does not work at all. Only >the fan seems to behave normally. It starts and stops the way it should, >both when running on AC or battery. > >I'm running FreeBSD 6.3 i386 Final and I have absolutely no idea as to what >drivers should I load to make this work. I've searched all over the internet >but never found any information specific to my Thinkpad model that would >help me solve this problem. First of all, you cannot use suspend resume on SMP kernel with any version you can get.(I succeeded to make suspend/resume work on SMP environment yesterdey with 8.0-CURRENT of April.) From efajardo1 at verizon.net Wed May 14 16:54:16 2008 From: efajardo1 at verizon.net (Maxorata) Date: Wed May 14 16:54:22 2008 Subject: Thinkpad T61p In-Reply-To: <200805141438.m4EEc09O016052@sana.init-main.com> References: <17232169.post@talk.nabble.com> <200805141438.m4EEc09O016052@sana.init-main.com> Message-ID: <17235908.post@talk.nabble.com> Takanori Watanabe-2 wrote: > > In message <17232169.post@talk.nabble.com>, Maxorata wrote: >> >>Hi, >>I just bought a Thinkpad T61 with the Nvidia graphics card (256 Mg) and am >>having trouble with suspend/resume. In fact it does not work at all. Only >>the fan seems to behave normally. It starts and stops the way it should, >>both when running on AC or battery. >> >>I'm running FreeBSD 6.3 i386 Final and I have absolutely no idea as to what >>drivers should I load to make this work. I've searched all over the internet >>but never found any information specific to my Thinkpad model that would >>help me solve this problem. > > First of all, you cannot use suspend resume on SMP kernel with > any version you can get.(I succeeded to make suspend/resume work on > SMP environment yesterdey with 8.0-CURRENT of April.) > > Thanks for your prompt reply. So, I might as well forget about enabling > suspend/resume on my laptop? > Is there any other options left? > Thanks again. > > > _______________________________________________ > 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" > > -- View this message in context: http://www.nabble.com/Thinkpad-T61p-tp17232169p17235908.html Sent from the freebsd-acpi mailing list archive at Nabble.com. From gavin at FreeBSD.org Thu May 15 18:30:10 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu May 15 18:30:13 2008 Subject: kern/123705: REGRESSION: acpi_cpu.c rev 1.57.2.4 broke booting on SuperMicro X7DBP Message-ID: <200805151830.m4FIUAx8098950@freefall.freebsd.org> Synopsis: REGRESSION: acpi_cpu.c rev 1.57.2.4 broke booting on SuperMicro X7DBP Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: gavin Responsible-Changed-When: Thu May 15 18:22:52 UTC 2008 Responsible-Changed-Why: Over to maintainers. Submitter has determined that rpaulo's MFC of src/sys/dev/acpica/acpi_cpu.c 1.67 is responsible for causing 6.3-RELEAASE to panic on boot. He can only test patches for the next 7-10 days. http://www.freebsd.org/cgi/query-pr.cgi?pr=123705 From krz at cis.rit.edu Fri May 16 02:15:43 2008 From: krz at cis.rit.edu (Bob Krzaczek) Date: Fri May 16 02:15:48 2008 Subject: ThinkPad and ACPI on FreeBSD 7.0 Message-ID: <482CE80C.6080701@cis.rit.edu> Hi there, I've been investigating why my ThinkPad T42p, with FreeBSD-7.0, only successfully resumes from a suspend-to-memory once in a very great while. Most of the time it hangs on a resume, and once in a while it panics. I've seen similar reports to what I'm seeing below in the bug database. The general sequence is this: Press the sleep key. /etc/rc.suspend runs (see below for a note about this). The last thing I see on the console before the backlight turns off is acpi_ec0: warning: EC done before starting event wait And then the system is down and off in sleep mode. Upon resuming the system, I first see this next message four times in a row. It's not related to this bug, I believe. an0: unknown RID: 0 Anyway, ignoring the wireless, here's where it gets interesting. Next we have subdisk0: detached disk0: detached Followed by this resulting noise from geom, GEOM_LABEL: Label msdosfs/IBM_SERVICE removed. And then anywhere from 5 to 100's of the following. g_vfs_done():ad0s3e[WRITE(offset=1355055104, length=16384)]error = 6 That error, I've seen in the bug database from other notebook users on resume. I'm assuming that it's directly related to the detached drives. ad0s3e is my /var slice. On a previous install from a few days ago, with different drive partitioning, these messages reported a different slice that was /var on that configuration, too. So far, it's always /var for me. At a guess, I'm thinking that something (maybe the logger?) has some pending I/O to write before the system has really gotten into a quiescent state prior to shutdown. The reason I'm considering the logger is that originally, the system didn't always crash, but then again, /etc/rc.suspend didn't get run, either. I found a one-line patch on this mailing list recently for devctl_process_running(); once applied, /etc/rc.suspend runs every time. Or, maybe the "detached" messages were supposed to occur earlier, during the suspend? I'm just making guesses here, because I don't really understand the intended ACPI sequence of events. What's more, I read about hw.acpi.sleep_delay. I tried adjusting that, but it had no effect on my system. Eventually, I traced it back to /usr/src/sys/dev/acpica/acpi.c where it seems the DELAY() has _no_ effect. In fact, I even replaced the DELAY(...sleep_delay * 1000000) with a hardcoded 5000000 (five seconds), and the system still goes to sleep instantly after /etc/rc.suspend. This, I'm sure, is at least part of the problem; there's no chance for the system to settle when suspending. I've provided acpi and acpi_ibm dumps from sysctl, the ASL dump, device.hints, dmesg, loader.conf, rc.conf, and sysctl.conf information at the following URI: http://30dor.com/freebsd-acpi/ I'm quite willing to try patches or other things you might suggest. The fact that DELAY() isn't working in acpi_EnterSleepState() has me most concerned at the moment. Alternatively, should I go to APM, or even install FreeBSD 6.3 or 6.2? Would that run better in my particular case? Looking for advice, willing to be a guinea pig... ;-) Cheers, Bob -- Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT phone +1-585-4757196, email krz@cis.rit.edu, icbm 43.0848N 77.6789W From ariff at FreeBSD.org Fri May 16 12:22:56 2008 From: ariff at FreeBSD.org (Ariff Abdullah) Date: Fri May 16 12:23:02 2008 Subject: BIOS Regression on HP/Compaq [d]v6000 series notebooks In-Reply-To: <20080428112623.GA99757@server.vk2pj.dyndns.org> References: <20080428112623.GA99757@server.vk2pj.dyndns.org> Message-ID: <20080516202242.3992b284.ariff@FreeBSD.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080516/34ada4bc/attachment.pgp From rpaulo at FreeBSD.org Fri May 16 22:27:08 2008 From: rpaulo at FreeBSD.org (rpaulo@FreeBSD.org) Date: Fri May 16 22:27:10 2008 Subject: kern/123705: [acpi_cpu] [regression] acpi_cpu.c rev 1.57.2.4 broke booting on SuperMicro X7DBP Message-ID: <200805162227.m4GMR8na097427@freefall.freebsd.org> Synopsis: [acpi_cpu] [regression] acpi_cpu.c rev 1.57.2.4 broke booting on SuperMicro X7DBP State-Changed-From-To: open->feedback State-Changed-By: rpaulo State-Changed-When: Fri May 16 22:26:28 UTC 2008 State-Changed-Why: feedback requested. Responsible-Changed-From-To: freebsd-acpi->rpaulo Responsible-Changed-By: rpaulo Responsible-Changed-When: Fri May 16 22:26:28 UTC 2008 Responsible-Changed-Why: My problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=123705 From krz at cis.rit.edu Fri May 16 23:28:23 2008 From: krz at cis.rit.edu (Bob Krzaczek) Date: Fri May 16 23:28:30 2008 Subject: Update on T42p with FreeBSD-7.0 and ACPI Message-ID: <482E1895.3000700@cis.rit.edu> Following some extremely helpful advice from Tobias Roth, I've moved from RELEASE to STABLE, and I'm happy to say that the laptop is so much better behaved with suspend/resume logic. One anomaly: /etc/rc.suspend is still not running. This turns out to be harmless in my particular case. However, I've verified first hand that Mitsuru IWASAKI's patch will take care of this. http://lists.freebsd.org/pipermail/freebsd-acpi/2008-April/004806.html Anyway, thanks again for the fast and responsive feedback, folks. This is getting much more stable and useful, now. Cheers, Bob -- Bob Krzaczek, Chester F. Carlson Center for Imaging Science, RIT phone +1-585-4757196, email krz@cis.rit.edu, icbm 43.0848N 77.6789W From freebsd at abv.bg Sat May 17 05:58:26 2008 From: freebsd at abv.bg (Mario Pavlov) Date: Sat May 17 05:58:30 2008 Subject: PCI bridge with I/O decode 0x0-0x0 Message-ID: <285282561.7160.1211002881523.JavaMail.apache@mail52.abv.bg> Hi list, I've recently bought a laptop Acer Aspire 5920 but I can't get the LAN and WLAN to work I thought it's because of the drivers but now I think it's an ACPI problem here is a verbose logging of the boot process and some comments: http://lists.freebsd.org/pipermail/freebsd-mobile/2008-May/010727.html I've tried to dump and decompile the AML image but I'm not very much in the ASL coding and I understand nearly nothing however I've tried to find on OS specific parts in the code this is what I found: Scope (\_SB) { Method (_INI, 0, NotSerialized) { If (DTSE) { TRAP (0x47) } Store (0x07D0, OSYS) If (CondRefOf (_OSI, Local0)) { If (_OSI ("Linux")) { Store (0x01, LINX) } If (_OSI ("Windows 2001")) { Store (0x07D1, OSYS) } If (_OSI ("Windows 2001 SP1")) { Store (0x07D1, OSYS) } If (_OSI ("Windows 2001 SP2")) { Store (0x07D2, OSYS) } If (_OSI ("Windows 2006")) { Store (0x07D6, OSYS) } } If (LAnd (MPEN, LEqual (OSYS, 0x07D1))) { TRAP (0x3D) } TRAP (0x2B) TRAP (0x32) } } I have no idea what is this for...but I've tried to add an Else clause and some combinations in like that: If (_OSI ("Windows 2006")) { Store (0x07D6, OSYS) } Else { Store (0x01, LINX) } but the result is just the same... I'm not even sure where exactly the problem is... Could you give me a hand please thank you Regards MGP ----------------------------------------------------------------- ?????? ?? ???? 2008 !!! http://sportni.bg/euro2008/ From peterjeremy at optushome.com.au Sat May 17 07:37:21 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat May 17 07:37:24 2008 Subject: BIOS Regression on HP/Compaq [d]v6000 series notebooks In-Reply-To: <20080516202242.3992b284.ariff@FreeBSD.org> References: <20080428112623.GA99757@server.vk2pj.dyndns.org> <20080516202242.3992b284.ariff@FreeBSD.org> Message-ID: <20080517073716.GF80125@server.vk2pj.dyndns.org> On 2008-May-16 20:22:42 +0800, Ariff Abdullah wrote: >After the recent update, the BIOS decided to force/enable C1E whenever >it losing main power: That explains the behaviour I see. > not their (HP) fault though. I don't follow this. HP released a BIOS that is broken. Either they did it deliberately, they didn't bother testing it or they don't care. >Try this patch (against -current, should be OK for other branches >too). With this patch, whenever AC line state change it will >disable C1E, hopefully. Thanks for that. I've tried it against the latest 6-STABLE and it applies OK. The results are mixed though. If I run top(1) and remove power, top's clock stops. When I plug power back in, the clock jumps to the current time - ntpq shows no time jump so the kernel time- keeping is still OK. I've tried this in both single-user and multi- user within X. I get the same behaviour with xclock(1) within X. If I move the mouse, window focus changes appropriately and if I wave the mouse enough, the clocks will jump to the correct time. The above is all with kern.timecounter.hardware=ACPI-fast. I tried using HPET but the behaviour is the same. Having the system recover when power is re-applied is a big improvement over the previous behaviour but I don't understand the current behaviour - it's far more responsive than it was without the C1E patch but is still not behaving correctly. >Hack or no hack, there must be a better / appropriate solution for >this issue. Agreed. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080517/81544eeb/attachment.pgp From ariff at FreeBSD.org Sat May 17 11:43:44 2008 From: ariff at FreeBSD.org (Ariff Abdullah) Date: Sat May 17 11:43:52 2008 Subject: BIOS Regression on HP/Compaq [d]v6000 series notebooks In-Reply-To: <20080517073716.GF80125@server.vk2pj.dyndns.org> References: <20080428112623.GA99757@server.vk2pj.dyndns.org> <20080516202242.3992b284.ariff@FreeBSD.org> <20080517073716.GF80125@server.vk2pj.dyndns.org> Message-ID: <20080517194326.420ceb81.ariff@FreeBSD.org> On Sat, 17 May 2008 17:37:17 +1000 Peter Jeremy wrote: > On 2008-May-16 20:22:42 +0800, Ariff Abdullah > wrote: > >After the recent update, the BIOS decided to force/enable C1E > >whenever it losing main power: > > That explains the behaviour I see. > > > not their (HP) fault though. > > I don't follow this. HP released a BIOS that is broken. Either > they did it deliberately, they didn't bother testing it or they > don't care. > It is not their fault, really. It is expected to lower down everything, either forcefully or not whenever you loose main power connection to conserve power usages. The problem is with FreeBSD own timer which relies on local APIC timer that went dead whenever it enter lowest power state (and lapic timer is _mandatory_ for APIC/SMP as in FreeBSD case). If you manage to boot without apic (thus using old/legacy i8254 timer, SMP disabled), you'll find that everything runs normally. Booting without apic is quite tricky especially on modern hardwares. > >Try this patch (against -current, should be OK for other branches > >too). With this patch, whenever AC line state change it will > >disable C1E, hopefully. > > Thanks for that. I've tried it against the latest 6-STABLE and it > applies OK. The results are mixed though. If I run top(1) and > remove power, top's clock stops. When I plug power back in, the > clock jumps to the current time - ntpq shows no time jump so the > kernel time- keeping is still OK. I've tried this in both > single-user and multi- user within X. I get the same behaviour with > xclock(1) within X. > > If I move the mouse, window focus changes appropriately and if I > wave the mouse enough, the clocks will jump to the correct time. > > The above is all with kern.timecounter.hardware=ACPI-fast. I tried > using HPET but the behaviour is the same. > > Having the system recover when power is re-applied is a big > improvement over the previous behaviour but I don't understand > the current behaviour - it's far more responsive than it was without > the C1E patch but is still not behaving correctly. > > >Hack or no hack, there must be a better / appropriate solution for > >this issue. > > Agreed. > Install sysutils/devcpu from ports, load cpu.ko, and grab / compile http://people.freebsd.org/~ariff/misc/k8c1e/ . Try playing with it (enable, disable, status) -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080517/018c33c3/attachment.pgp From sbruno at miralink.com Sat May 17 17:51:58 2008 From: sbruno at miralink.com (Sean Bruno) Date: Sat May 17 17:52:01 2008 Subject: Update on T42p with FreeBSD-7.0 and ACPI In-Reply-To: <482E1895.3000700@cis.rit.edu> References: <482E1895.3000700@cis.rit.edu> Message-ID: <482F1482.6060105@miralink.com> Bob Krzaczek wrote: > Following some extremely helpful advice from Tobias Roth, I've moved > from RELEASE to STABLE, and I'm happy to say that the laptop is so > much better behaved with suspend/resume logic. > > One anomaly: /etc/rc.suspend is still not running. This turns out to > be harmless in my particular case. However, I've verified first hand > that Mitsuru IWASAKI's patch will take care of this. > > http://lists.freebsd.org/pipermail/freebsd-acpi/2008-April/004806.html > > Anyway, thanks again for the fast and responsive feedback, folks. > This is getting much more stable and useful, now. > > Cheers, > Bob > Hrm...Is there a PR somewhere on this issue? Or, more importantly, has a committer accepted the patch? Sean From eric.servant at gmail.com Sat May 17 19:20:53 2008 From: eric.servant at gmail.com (Eric SERVANT) Date: Sat May 17 19:20:58 2008 Subject: ACPI problems afer update 6.3 to 7.0 Message-ID: <20080517205245.387d7d7c.eric.servant@gmail.com> Hello everybody, I have updated my system a few days ago from 6.3-STABLE to 7.0-STABLE. With the system 6.3-STABLE all worked fine, but with 7.0 some problems appear. First : the percentage of processor states (user, nice, system, idle, interrupt) are always 0.0%. The display vmstat in the command systat display : The alternate system clock has died! Reverting to ``pigs'' display. Second : reboot or shutdown doesn't work after the kernel messages (disk synchronization, uptime). I must use the power button. My computer : NEC Versa Note VX BIOS Revision /126A2300 (04/03/2000) acpi0: on motherboard Booting the kernel with boot_verbose, display this messages : acpi: bad write to port 0x070 (8), val 0x52 acpi: bad read from port 0x071 (8) These messages appear fourteen/fifteen times during the boot. If someone have an idea... Thanks. -- Eric S. From nate at root.org Sat May 17 20:48:52 2008 From: nate at root.org (Nate Lawson) Date: Sat May 17 20:48:56 2008 Subject: Update on T42p with FreeBSD-7.0 and ACPI In-Reply-To: <482F1482.6060105@miralink.com> References: <482E1895.3000700@cis.rit.edu> <482F1482.6060105@miralink.com> Message-ID: <482F44AC.1010904@root.org> Sean Bruno wrote: > Bob Krzaczek wrote: >> Following some extremely helpful advice from Tobias Roth, I've moved >> from RELEASE to STABLE, and I'm happy to say that the laptop is so >> much better behaved with suspend/resume logic. >> >> One anomaly: /etc/rc.suspend is still not running. This turns out to >> be harmless in my particular case. However, I've verified first hand >> that Mitsuru IWASAKI's patch will take care of this. >> >> http://lists.freebsd.org/pipermail/freebsd-acpi/2008-April/004806.html >> >> Anyway, thanks again for the fast and responsive feedback, folks. >> This is getting much more stable and useful, now. >> >> Cheers, >> Bob >> > Hrm...Is there a PR somewhere on this issue? Or, more importantly, has > a committer accepted the patch? Iwasaki-san's patch should be committed. Rui? -- Nate From zb at ispid.com.pl Sat May 17 21:12:53 2008 From: zb at ispid.com.pl (Zbigniew Baniewski) Date: Sat May 17 21:12:57 2008 Subject: ACPI problems afer update 6.3 to 7.0 In-Reply-To: <20080517205245.387d7d7c.eric.servant@gmail.com> References: <20080517205245.387d7d7c.eric.servant@gmail.com> Message-ID: <20080517211257.GA16923@sarge.my.own.domain.no-net> On Sat, May 17, 2008 at 08:52:45PM +0200, Eric SERVANT wrote: > First : the percentage of processor states (user, nice, system, idle, > interrupt) are always 0.0%. > The display vmstat in the command systat display : The same thing like in my case. > My computer : NEC Versa Note VX > BIOS Revision /126A2300 (04/03/2000) > acpi0: on motherboard > [..] > If someone have an idea... Thanks. Nobody wants to fix the FreeBSD's ACPI for older mobos. You just have to switch ACPI off. -- pozdrawiam / regards Zbigniew Baniewski From peterjeremy at optushome.com.au Sun May 18 03:05:33 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun May 18 03:05:37 2008 Subject: BIOS Regression on HP/Compaq [d]v6000 series notebooks In-Reply-To: <20080517194326.420ceb81.ariff@FreeBSD.org> References: <20080428112623.GA99757@server.vk2pj.dyndns.org> <20080516202242.3992b284.ariff@FreeBSD.org> <20080517073716.GF80125@server.vk2pj.dyndns.org> <20080517194326.420ceb81.ariff@FreeBSD.org> Message-ID: <20080518030528.GA1099@server.vk2pj.dyndns.org> On 2008-May-17 19:43:26 +0800, Ariff Abdullah wrote: >Install sysutils/devcpu from ports, load cpu.ko, and grab / compile >http://people.freebsd.org/~ariff/misc/k8c1e/ . Try playing with it >(enable, disable, status) It reported C1E disabled normally and enabled when I removed power. Explicitly disabling it when running on battery caused everything to behave. Curiously, enabling C1E when running on AC power did not make things stop - which confused me. I extended k8c1e.c to report the actual IPMR contents. This gave me the following. Running on AC (ie after plugging AC back in): cpu0: MSR=0x0000000004c10000 C1E disabled cpu1: MSR=0x0000000004c10000 C1E disabled Disconnecting AC: cpu0: MSR=0x0000000014c11015 C1E enabled cpu1: MSR=0x000000001cc11015 C1E enabled I notice that it doesn't set SmiOnCmpHalt on CPU0. Interestingly, "BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh Processors" (#32559) revision 3.08, states that each of C1eOnCmpHalt, SmiOnCmpHalt and IntPndMsg are mutually exclusive (only one can be set to 1) and that all cores should be programmed the same - it looks like the BIOS is not doing this. I don't know why your patch is not working. It looks suspiciously like it's not getting the relevant ACPI notify message (or maybe the ACPI BIOS is sending the ACPI notify early and juggling C1E after the notify). I checked and I _am_ running a kernel with the patch in it. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080518/4d3990e1/attachment.pgp From ariff at FreeBSD.org Sun May 18 03:30:56 2008 From: ariff at FreeBSD.org (Ariff Abdullah) Date: Sun May 18 03:30:59 2008 Subject: BIOS Regression on HP/Compaq [d]v6000 series notebooks In-Reply-To: <20080518030528.GA1099@server.vk2pj.dyndns.org> References: <20080428112623.GA99757@server.vk2pj.dyndns.org> <20080516202242.3992b284.ariff@FreeBSD.org> <20080517073716.GF80125@server.vk2pj.dyndns.org> <20080517194326.420ceb81.ariff@FreeBSD.org> <20080518030528.GA1099@server.vk2pj.dyndns.org> Message-ID: <20080518113051.34027506.ariff@FreeBSD.org> On Sun, 18 May 2008 13:05:28 +1000 Peter Jeremy wrote: > On 2008-May-17 19:43:26 +0800, Ariff Abdullah > wrote: > >Install sysutils/devcpu from ports, load cpu.ko, and grab / compile > >http://people.freebsd.org/~ariff/misc/k8c1e/ . Try playing with it > >(enable, disable, status) > > It reported C1E disabled normally and enabled when I removed power. > Explicitly disabling it when running on battery caused everything to > behave. Curiously, enabling C1E when running on AC power did not > make things stop - which confused me. > > I extended k8c1e.c to report the actual IPMR contents. This gave > me the following. > > Running on AC (ie after plugging AC back in): > cpu0: MSR=0x0000000004c10000 C1E disabled > cpu1: MSR=0x0000000004c10000 C1E disabled > > Disconnecting AC: > cpu0: MSR=0x0000000014c11015 C1E enabled > cpu1: MSR=0x000000001cc11015 C1E enabled > > I notice that it doesn't set SmiOnCmpHalt on CPU0. Interestingly, > "BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh > Processors" (#32559) revision 3.08, states that each of > C1eOnCmpHalt, SmiOnCmpHalt and IntPndMsg are mutually exclusive > (only one can be set to 1) and that all cores should be programmed > the same - it looks like the BIOS is not doing this. > > I don't know why your patch is not working. It looks suspiciously > like it's not getting the relevant ACPI notify message (or maybe the > ACPI BIOS is sending the ACPI notify early and juggling C1E after > the notify). I checked and I _am_ running a kernel with the patch > in it. > The patch does not try to get to other cpus, too much complications just for a tiny quirk. Since acpi AC notifaction delivered only to a single cpu, the quirk applied only to and just that cpu. If the BIOS set C1E before sending ac notification, you're lucky: otherwise not (which _probably_ in your case). Disregarding my patch, try executing that "k8c1e disable" through devd notifaction by adding followings to /etc/devd.conf: # K8 C1E notify 100 { match "system" "ACPI"; match "subsystem" "ACAD"; action "/whatever/k8c1e disable > /dev/null 2>&1"; }; Perhaps even: action "sleep X ; /whatever/k8c1e..." -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080518/5df50dda/attachment.pgp From uspoerlein at gmail.com Sun May 18 11:44:58 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Sun May 18 11:45:04 2008 Subject: kern/123705: [acpi_cpu] [regression] acpi_cpu.c rev 1.57.2.4 broke booting on SuperMicro X7DBP In-Reply-To: <200805162227.m4GMR8na097427@freefall.freebsd.org> References: <200805162227.m4GMR8na097427@freefall.freebsd.org> Message-ID: <20080518110610.GA3434@roadrunner.spoerlein.net> Hi, only tested the patch on this one machine, no more panics, although the _OSC evaluation itself fails: cpu0: on acpi0 ACPI-1304: *** Error: Method execution failed [\_PR_.CPU0._OSC] (Node 0xc871e660), AE_AML_OPERAND_TYPE cpu0: switching to generic Cx mode acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x1010 Thanks! Ulrich Spoerlein From rpaulo at fnop.net Sun May 18 13:47:34 2008 From: rpaulo at fnop.net (Rui Paulo) Date: Sun May 18 13:47:38 2008 Subject: Update on T42p with FreeBSD-7.0 and ACPI In-Reply-To: <482F44AC.1010904@root.org> References: <482E1895.3000700@cis.rit.edu> <482F1482.6060105@miralink.com> <482F44AC.1010904@root.org> Message-ID: <48303370.1030101@fnop.net> Nate Lawson wrote: > Sean Bruno wrote: >> Bob Krzaczek wrote: >>> Following some extremely helpful advice from Tobias Roth, I've moved >>> from RELEASE to STABLE, and I'm happy to say that the laptop is so >>> much better behaved with suspend/resume logic. >>> >>> One anomaly: /etc/rc.suspend is still not running. This turns out to >>> be harmless in my particular case. However, I've verified first hand >>> that Mitsuru IWASAKI's patch will take care of this. >>> >>> http://lists.freebsd.org/pipermail/freebsd-acpi/2008-April/004806.html >>> >>> Anyway, thanks again for the fast and responsive feedback, folks. >>> This is getting much more stable and useful, now. >>> >>> Cheers, >>> Bob >>> >> Hrm...Is there a PR somewhere on this issue? Or, more importantly, >> has a committer accepted the patch? > > Iwasaki-san's patch should be committed. Rui? > Will do it. Thanks. Regards, -- Rui Paulo From ariff at FreeBSD.org Mon May 19 03:10:20 2008 From: ariff at FreeBSD.org (Ariff Abdullah) Date: Mon May 19 03:10:22 2008 Subject: BIOS Regression on HP/Compaq [d]v6000 series notebooks In-Reply-To: <20080518030528.GA1099@server.vk2pj.dyndns.org> References: <20080428112623.GA99757@server.vk2pj.dyndns.org> <20080516202242.3992b284.ariff@FreeBSD.org> <20080517073716.GF80125@server.vk2pj.dyndns.org> <20080517194326.420ceb81.ariff@FreeBSD.org> <20080518030528.GA1099@server.vk2pj.dyndns.org> Message-ID: <20080519110954.09c2d42f.ariff@FreeBSD.org> On Sun, 18 May 2008 13:05:28 +1000 Peter Jeremy wrote: > On 2008-May-17 19:43:26 +0800, Ariff Abdullah > wrote: > >Install sysutils/devcpu from ports, load cpu.ko, and grab / compile > >http://people.freebsd.org/~ariff/misc/k8c1e/ . Try playing with it > >(enable, disable, status) > > It reported C1E disabled normally and enabled when I removed power. > Explicitly disabling it when running on battery caused everything to > behave. Curiously, enabling C1E when running on AC power did not > make things stop - which confused me. > > I extended k8c1e.c to report the actual IPMR contents. This gave > me the following. > > Running on AC (ie after plugging AC back in): > cpu0: MSR=0x0000000004c10000 C1E disabled > cpu1: MSR=0x0000000004c10000 C1E disabled > > Disconnecting AC: > cpu0: MSR=0x0000000014c11015 C1E enabled > cpu1: MSR=0x000000001cc11015 C1E enabled > > I notice that it doesn't set SmiOnCmpHalt on CPU0. Interestingly, > "BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh > Processors" (#32559) revision 3.08, states that each of > C1eOnCmpHalt, SmiOnCmpHalt and IntPndMsg are mutually exclusive > (only one can be set to 1) and that all cores should be programmed > the same - it looks like the BIOS is not doing this. > > I don't know why your patch is not working. It looks suspiciously > like it's not getting the relevant ACPI notify message (or maybe the > ACPI BIOS is sending the ACPI notify early and juggling C1E after > the notify). I checked and I _am_ running a kernel with the patch > in it. > I've been thinking on taking a different stab by hijacking cpu_idle*() functions instead. Please disregard all previous quirks and get either of these: http://people.freebsd.org/~ariff/misc/k8c1e/current_k8c1e_idle_hlt.diff http://people.freebsd.org/~ariff/misc/k8c1e/releng6-7_k8c1e_idle_hlt.diff -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080519/6f1de17f/attachment.pgp From bugmaster at FreeBSD.org Mon May 19 11:06:48 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 19 11:06:51 2008 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200805191106.m4JB6lrC011476@freefall.freebsd.org> 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 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am 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/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/120953 acpi [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is o kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo 20 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 s kern/73823 acpi [request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/89411 acpi [acpi] acpiconf bug s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI 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 s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi [acpi] Dell C810 - ACPI problem o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f amd64/122521 acpi ACPI Error after upgrade to 7.0 o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot 22 problems total. From freebsd at abv.bg Tue May 20 17:42:42 2008 From: freebsd at abv.bg (Mario Pavlov) Date: Tue May 20 18:10:14 2008 Subject: PCI bridge with I/O decode 0x0-0x0 Message-ID: <1749772363.84307.1211305358208.JavaMail.apache@mail54.abv.bg> >Hi list, >I've recently bought a laptop Acer Aspire 5920 >but I can't get the LAN and WLAN to work >I thought it's because of the drivers but now I think it's an ACPI problem >here is a verbose logging of the boot process and some comments: >http://lists.freebsd.org/pipermail/freebsd-mobile/2008-May/010727.html >I've tried to dump and decompile the AML image but I'm not very much in the ASL coding and I understand nearly nothing >however I've tried to find on OS specific parts in the code >this is what I found: > > Scope (\_SB) > { > Method (_INI, 0, NotSerialized) > { > If (DTSE) > { > TRAP (0x47) > } > > Store (0x07D0, OSYS) > If (CondRefOf (_OSI, Local0)) > { > If (_OSI ("Linux")) > { > Store (0x01, LINX) > } > > If (_OSI ("Windows 2001")) > { > Store (0x07D1, OSYS) > } > > If (_OSI ("Windows 2001 SP1")) > { > Store (0x07D1, OSYS) > } > > If (_OSI ("Windows 2001 SP2")) > { > Store (0x07D2, OSYS) > } > > If (_OSI ("Windows 2006")) > { > Store (0x07D6, OSYS) > } > } > > If (LAnd (MPEN, LEqual (OSYS, 0x07D1))) > { > TRAP (0x3D) > } > > TRAP (0x2B) > TRAP (0x32) > } > } > >I have no idea what is this for...but I've tried to add an Else clause and some combinations in >like that: > > If (_OSI ("Windows 2006")) > { > Store (0x07D6, OSYS) > } > Else > { > Store (0x01, LINX) > } > >but the result is just the same... >I'm not even sure where exactly the problem is... >Could you give me a hand please >thank you > >Regards >MGP Hi again, I've figured what's the node name of the LAN card - RP06.LANE but I don't understand what does this code mean... do you see any error here ? Device (RP06) { Name (_ADR, 0x001C0005) OperationRegion (PXCS, PCI_Config, 0x40, 0xC0) Field (PXCS, AnyAcc, NoLock, WriteAsZeros) { Offset (0x10), , 4, LKDS, 1, Offset (0x12), , 13, LASX, 1, Offset (0x1A), ABPX, 1, , 2, PDCX, 1, , 2, PDSX, 1, Offset (0x1B), LSCX, 1, Offset (0x20), Offset (0x22), PSPX, 1, Offset (0x98), , 30, HPEX, 1, PMEX, 1, , 30, HPSX, 1, PMSX, 1 } Method (_PRT, 0, NotSerialized) { If (\GPIC) { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, 0x00, 0x11 }, Package (0x04) { 0xFFFF, 0x01, 0x00, 0x12 }, Package (0x04) { 0xFFFF, 0x02, 0x00, 0x13 }, Package (0x04) { 0xFFFF, 0x03, 0x00, 0x10 } }) } Else { Return (Package (0x04) { Package (0x04) { 0xFFFF, 0x00, \_SB.PCI0.LPCB.LNKB, 0x00 }, Package (0x04) { 0xFFFF, 0x01, \_SB.PCI0.LPCB.LNKC, 0x00 }, Package (0x04) { 0xFFFF, 0x02, \_SB.PCI0.LPCB.LNKD, 0x00 }, Package (0x04) { 0xFFFF, 0x03, \_SB.PCI0.LPCB.LNKA, 0x00 } }) } } Device (LANE) { Name (_ADR, 0x00) Name (_PRW, Package (0x02) { 0x09, 0x04 }) Name (LANP, 0x00) Method (_PSW, 1, NotSerialized) { If (LEqual (Arg0, 0x00)) { Store (0x00, LANP) } Else { Store (0x01, LANP) } } } } you can find the whole code attached... guys could you please have a look on that I'm sure you could give me some hints... thank you regards MGP ----------------------------------------------------------------- ????? ?? ???????! http://zoom.bg/page.php?bid=6 -------------- next part -------------- A non-text attachment was scrubbed... Name: laptop.asl Type: application/octet-stream Size: 343142 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080520/fd0670af/laptop-0001.obj From serge at a-1.com.ua Tue May 20 21:27:40 2008 From: serge at a-1.com.ua (Serge Semenenko) Date: Tue May 20 21:27:43 2008 Subject: PCI bridge with I/O decode 0x0-0x0 In-Reply-To: <1749772363.84307.1211305358208.JavaMail.apache@mail54.abv.bg> References: <1749772363.84307.1211305358208.JavaMail.apache@mail54.abv.bg> Message-ID: <48333C08.2020001@a-1.com.ua> Hi Have the same problem with my Acer 6292... But at the same time there are no problems on my friend's EX5620G. I've spent some time trying to fix aml code but with no success. May be I'm not too good in that or the problem might be somewhere else... Anyway, it seems that somewhere during acpi initialization PCI Config space of PCI bridges gets corrupted. So, to get my network cards working as a temporary solution I use the patch attached. Memory ranges I've found while booting with acpi disabled. I know that's not a solution but at least I could send now this message through built-in wifi card :) Regards, Serge -------------- next part -------------- --- acpi_pcib_pci.c.orig 2008-02-28 00:55:04.000000000 +0200 +++ acpi_pcib_pci.c 2008-02-28 23:51:16.000000000 +0200 @@ -133,6 +133,22 @@ ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); + if (device_get_unit(dev)==2){ + pci_write_config(dev, PCIR_COMMAND, PCIM_CMD_MEMEN | PCIM_CMD_PORTEN, 1); + pci_enable_busmaster(dev); + pci_write_config(dev, PCIR_IOBASEL_1, 0xf0, 1); + pci_write_config(dev, PCIR_MEMBASE_1, 0xf020, 2); + pci_write_config(dev, PCIR_MEMLIMIT_1, 0xf020, 2); + pci_write_config(dev, PCIR_PMBASEL_1, 0xfff1, 2); + } + if (device_get_unit(dev)==3){ + pci_write_config(dev, PCIR_COMMAND, PCIM_CMD_MEMEN | PCIM_CMD_PORTEN, 1); + pci_enable_busmaster(dev); + pci_write_config(dev, PCIR_IOBASEL_1, 0xf0, 1); + pci_write_config(dev, PCIR_MEMBASE_1, 0xf030, 2); + pci_write_config(dev, PCIR_MEMLIMIT_1, 0xf030, 2); + pci_write_config(dev, PCIR_PMBASEL_1, 0xfff1, 2); + } pcib_attach_common(dev); sc = device_get_softc(dev); sc->ap_handle = acpi_get_handle(dev); From sarumont at sigil.org Wed May 21 05:18:35 2008 From: sarumont at sigil.org (Richard Kolkovich) Date: Wed May 21 05:18:37 2008 Subject: Thinkpad t43p suspend/resume only once In-Reply-To: <20080407145115.GA11167@snobol> References: <20080407145115.GA11167@snobol> Message-ID: <20080521045843.GC18427@snobol> On Mon, Apr 07, 2008 at 09:51:15AM -0500, Richard Kolkovich wrote: > Hi, > > On my T43p, I can suspend to RAM (S3) and resume once. After this, nothing > happens when I close the lid (until a reboot). I started digging into this > today, and it looks like the acpi device is in a bad state after the resume. > Running devd -dD from a terminal shows no output from ACPI buttons after the > resume. > > I discovered today, however, that I can run acpiconf -s S3 to regain my ability > to sleep/resume. This will suspend the machine and immediately resume it, after > which devd shows output again. > > I'm running RELENG_7 as of about March 25th. I've only run 7.0 on this laptop, > so I've always had this problem. I've just now gotten a chance to work on > finding a fix. > > Please CC me, as I'm not subscribed to freebsd-acpi. Thanks, > > -- > > Richard Kolkovich > sarumont@sigil.org > FWIW - I just discovered that disabling APIC resolves this issue. Thanks, -- Richard Kolkovich sarumont@sigil.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080521/04e5a754/attachment.pgp From freebsd at abv.bg Wed May 21 05:25:16 2008 From: freebsd at abv.bg (Mario Pavlov) Date: Wed May 21 05:25:21 2008 Subject: PCI bridge with I/O decode 0x0-0x0 Message-ID: <1312312888.89527.1211347514074.JavaMail.apache@mail54.abv.bg> >Hi > >Have the same problem with my Acer 6292... But at the same time there >are no problems on my friend's EX5620G. I've spent some time trying to >fix aml code but with no success. May be I'm not too good in that or the >problem might be somewhere else... Anyway, it seems that somewhere >during acpi initialization PCI Config space of PCI bridges gets >corrupted. So, to get my network cards working as a temporary solution I >use the patch attached. Memory ranges I've found while booting with acpi >disabled. I know that's not a solution but at least I could send now >this message through built-in wifi card :) > >Regards, >Serge Hi Serge, nice hack ;) I may also try something like that... however why don't you post your ASL and also your friend's ASL and lets see what we can do together we may also get some help from the ACPI gurus here. thanks Regards MGP ----------------------------------------------------------------- ????? ?? ???????! http://zoom.bg/page.php?bid=6 From vova at fbsd.ru Wed May 21 13:22:00 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Wed May 21 13:22:04 2008 Subject: SMP suspend/resume. In-Reply-To: <200805131125.m4DBPu1q092741@sana.init-main.com> References: <200805131125.m4DBPu1q092741@sana.init-main.com> Message-ID: <1211374700.1566.27.camel@localhost> On Tue, 2008-05-13 at 20:25 +0900, takawata@init-main.com wrote: I've tried to build patch with recent CURRENT and get SMP redefined for acpi.c and acpi_wakeup.c Was it expected ? I have options SMP # Symmetric MultiProcessor Kernel in my kernel configuration. (notebook: ThinkPad T60) > Hi, I managed to make suspend and resume work on SMP system. > The patch following is a bit crude patch, but it begin > to work on my ThinkPad X61 (core2duo system). > > TODO: > 1. Suspend/resume path it self is simular to AP boot path. > Some of code may be integrated. > 2. More context, like MTRR or npx context should be saved on > suspend. > 3. Make acpi suspend resume path more ABI aware: needless > register recoverly or special register context saving > (the value itself is usually constant) should be removed. > 4. Make same binary module work on both UP or SMP case. > (Or is it time to give up using acpi module on also on i386?) > > > > > > Index: i386/acpica/acpi_wakeup.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/acpica/acpi_wakeup.c,v > retrieving revision 1.47 > diff -u -r1.47 acpi_wakeup.c > --- i386/acpica/acpi_wakeup.c 16 Mar 2008 10:58:03 -0000 1.47 > +++ i386/acpica/acpi_wakeup.c 13 May 2008 09:12:18 -0000 > @@ -27,6 +27,7 @@ > > #include > __FBSDID("$FreeBSD: src/sys/i386/acpica/acpi_wakeup.c,v 1.47 2008/03/16 10:58:03 rwatson Exp $"); > +#define SMP > > #include > #include > @@ -49,6 +50,11 @@ > > #include > #include > +#include > +#include > +#include > +#include > +#include > > #include "acpi_wakecode.h" > > @@ -71,7 +77,9 @@ > > static uint16_t r_cs, r_ds, r_es, r_fs, r_gs, r_ss, r_tr; > static uint32_t r_esp; > - > +extern void *bootstacks[]; > +static char *bootSTK; > +void restore_sub(void); > static void acpi_printcpu(void); > static void acpi_realmodeinst(void *arg, bus_dma_segment_t *segs, > int nsegs, int error); > @@ -80,6 +88,7 @@ > /* XXX shut gcc up */ > extern int acpi_savecpu(void); > extern int acpi_restorecpu(void); > +extern void acpi_kicksub(void); > > #ifdef __GNUCLIKE_ASM > __asm__(" \n\ > @@ -104,6 +113,15 @@ > movl %eax,(%esp) \n\ > xorl %eax,%eax \n\ > ret \n\ > + \n\ > + .text \n\ > + .p2align 2, 0x90 \n\ > + .type acpi_kicksub, @function \n\ > +acpi_kicksub: \n\ > + .align 4 \n\ > + movl bootSTK,%esp \n\ > + jmp restore_sub \n\ > + ret \n\ > \n\ > .text \n\ > .p2align 2, 0x90 \n\ > @@ -149,6 +167,24 @@ > ret \n\ > "); > #endif /* __GNUCLIKE_ASM */ > +int acpi_cpu_resumed[MAXCPU]; > +int acpi_curcpu; > +extern int switch_debug; > + > +void restore_sub() > +{ > + ACPI_DISABLE_IRQS(); > + printf("RESTORE_SUB\n"); > + lapic_disable(); > + printf("LAPIC_SETUP\n"); > + lapic_setup(0); > + lapic_dump("RESTORE_SUB"); > + printf("RESTORE_SUB2\n"); > + ACPI_ENABLE_IRQS(); > + > + acpi_cpu_resumed[acpi_curcpu]= 1; > + acpi_restorecpu(); > +} > > static void > acpi_printcpu(void) > @@ -187,6 +223,119 @@ > outb(0x61, inb(0x61) & ~0x3); > } > > + > +int resume_other_cpu(struct acpi_softc *sc, int cpu); > +int resume_other_cpu(struct acpi_softc *sc, int cpu) > +{ > + int ms; > + int apic_id = cpu_apic_ids[cpu]; > + int gsel_tss; > + > + gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); > + acpi_curcpu = cpu; > + bootSTK= (char *)bootstacks[cpu] + KSTACK_PAGES * PAGE_SIZE - 4; > + printf("%p\n", bootSTK); > + p_gdt = (struct region_descriptor *) > + (sc->acpi_wakeaddr + physical_gdt); > + saved_gdt.rd_limit = NGDT * sizeof(gdt[0]) -1; > + saved_gdt.rd_base = (int )&gdt[cpu*NGDT]; > + p_gdt->rd_limit = saved_gdt.rd_limit; > + p_gdt->rd_base = vtophys(saved_gdt.rd_base); > + r_esp = stoppcbs[cpu].pcb_esp; > + r_ebp = stoppcbs[cpu].pcb_ebp; > + r_esi = stoppcbs[cpu].pcb_esi; > + r_edi = stoppcbs[cpu].pcb_edi; > + r_efl = stoppcbs[cpu].pcb_psl; > + ret_addr = stoppcbs[cpu].pcb_eip; > + WAKECODE_FIXUP(physical_esp, uint32_t, vtophys(bootSTK) ); > + WAKECODE_FIXUP(previous_cr0, uint32_t, r_cr0); > + WAKECODE_FIXUP(previous_cr2, uint32_t, r_cr2); > + WAKECODE_FIXUP(previous_cr3, uint32_t, r_cr3); > + WAKECODE_FIXUP(previous_cr4, uint32_t, r_cr4); > + > + WAKECODE_FIXUP(resume_beep, uint32_t, 0); > + WAKECODE_FIXUP(reset_video, uint32_t, 0); > + > + WAKECODE_FIXUP(previous_tr, uint16_t, gsel_tss); > + WAKECODE_BCOPY(previous_gdt, struct region_descriptor, saved_gdt); > + WAKECODE_FIXUP(previous_ldt, uint16_t, saved_ldt); > + WAKECODE_BCOPY(previous_idt, struct region_descriptor, saved_idt); > + > + WAKECODE_FIXUP(where_to_recover, void *, acpi_kicksub); > + > + WAKECODE_FIXUP(previous_ds, uint16_t, r_ds); > + WAKECODE_FIXUP(previous_es, uint16_t, r_es); > + WAKECODE_FIXUP(previous_fs, uint16_t, r_fs); > + WAKECODE_FIXUP(previous_gs, uint16_t, 0); > + WAKECODE_FIXUP(previous_ss, uint16_t, r_ss); > + > + /* do an INIT IPI: assert RESET */ > + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | > + APIC_LEVEL_ASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, apic_id); > + > + /* wait for pending status end */ > + lapic_ipi_wait(-1); > + > + /* do an INIT IPI: deassert RESET */ > + lapic_ipi_raw(APIC_DEST_ALLESELF | APIC_TRIGMOD_LEVEL | > + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, 0); > + > + /* wait for pending status end */ > + DELAY(10000); /* wait ~10mS */ > + lapic_ipi_wait(-1); > + /* > + * next we do a STARTUP IPI: the previous INIT IPI might still be > + * latched, (P5 bug) this 1st STARTUP would then terminate > + * immediately, and the previously started INIT IPI would continue. OR > + * the previous INIT IPI has already run. and this STARTUP IPI will > + * run. OR the previous INIT IPI was ignored. and this STARTUP IPI > + * will run. > + */ > + > + /* do a STARTUP IPI */ > + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | > + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP | > + ((sc->acpi_wakephys >>12)&0xff), apic_id); > + lapic_ipi_wait(-1); > + DELAY(200); /* wait ~200uS */ > + > + /* > + * finally we do a 2nd STARTUP IPI: this 2nd STARTUP IPI should run IF > + * the previous STARTUP IPI was cancelled by a latched INIT IPI. OR > + * this STARTUP IPI will be ignored, as only ONE STARTUP IPI is > + * recognized after hardware RESET or INIT IPI. > + */ > + > + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | > + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP | > + ((sc->acpi_wakephys >>12)&0xff), apic_id); > + lapic_ipi_wait(-1); > + DELAY(200); /* wait ~200uS */ > + > + /* Wait up to 5 seconds for it to start. */ > + for (ms = 0; ms < 5000; ms++) { > + if(acpi_cpu_resumed[cpu]){ > + acpi_cpu_resumed[cpu]= 0; > + return 0; > + } > + DELAY(1000); > + } > + return -1; /* return FAILURE */ > + > +} > +int resume_other_cpus(struct acpi_softc *sc); > +int resume_other_cpus(struct acpi_softc *sc) > +{ > + int i; > + printf("RESUME_OTHER_CPUS"); > + *((volatile u_short *) 0x467) = 0; > + *((volatile u_short *) 0x468) = (sc->acpi_wakephys&0xffff0)>>4; > + > + for(i = 1; i < mp_ncpus; i++){ > + resume_other_cpu(sc, i); > + } > + return 0; > +} > int > acpi_sleep_machdep(struct acpi_softc *sc, int state) > { > @@ -270,14 +419,15 @@ > for (;;) ; > } else { > /* Execute Wakeup */ > - intr_resume(); > - > if (bootverbose) { > acpi_savecpu(); > acpi_printcpu(); > } > + resume_other_cpus(sc); > + restart_cpus(stopped_cpus); > + intr_resume(); > + lapic_dump("MAIN"); > } > - > out: > load_cr3(cr3); > write_eflags(ef); > @@ -285,7 +435,7 @@ > /* If we beeped, turn it off after a delay. */ > if (acpi_resume_beep) > timeout(acpi_stop_beep, NULL, 3 * hz); > - > + printf("FUGAFUGA\n"); > return (ret); > } > > Index: i386/i386/io_apic.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/io_apic.c,v > retrieving revision 1.35 > diff -u -r1.35 io_apic.c > --- i386/i386/io_apic.c 5 Jun 2007 18:57:48 -0000 1.35 > +++ i386/i386/io_apic.c 13 May 2008 08:22:55 -0000 > @@ -444,8 +444,9 @@ > struct ioapic *io = (struct ioapic *)pic; > int i; > > - for (i = 0; i < io->io_numintr; i++) > + for (i = 0; i < io->io_numintr; i++){ > ioapic_program_intpin(&io->io_pins[i]); > + } > } > > /* > Index: i386/i386/mp_machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v > retrieving revision 1.286 > diff -u -r1.286 mp_machdep.c > --- i386/i386/mp_machdep.c 10 Apr 2008 18:38:31 -0000 1.286 > +++ i386/i386/mp_machdep.c 13 May 2008 07:08:29 -0000 > @@ -1299,18 +1299,19 @@ > int cpu = PCPU_GET(cpuid); > int cpumask = PCPU_GET(cpumask); > > - savectx(&stoppcbs[cpu]); > - > - /* Indicate that we are stopped */ > - atomic_set_int(&stopped_cpus, cpumask); > + if(savectx(&stoppcbs[cpu])){ > + /* Indicate that we are stopped */ > + atomic_set_int(&stopped_cpus, cpumask); > + wbinvd(); > + } > > /* Wait for restart */ > - while (!(started_cpus & cpumask)) > - ia32_pause(); > - > + while (!(started_cpus & cpumask)){ > + ia32_pause(); > + } > atomic_clear_int(&started_cpus, cpumask); > atomic_clear_int(&stopped_cpus, cpumask); > - > + > if (cpu == 0 && cpustop_restartfunc != NULL) { > cpustop_restartfunc(); > cpustop_restartfunc = NULL; > Index: i386/i386/swtch.s > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/swtch.s,v > retrieving revision 1.156 > diff -u -r1.156 swtch.s > --- i386/i386/swtch.s 22 Aug 2007 05:06:14 -0000 1.156 > +++ i386/i386/swtch.s 9 May 2008 15:16:03 -0000 > @@ -413,6 +413,6 @@ > 1: > popfl > #endif /* DEV_NPX */ > - > + movl $1, %eax > ret > END(savectx) > Index: i386/include/pcb.h > =================================================================== > RCS file: /home/ncvs/src/sys/i386/include/pcb.h,v > retrieving revision 1.56 > diff -u -r1.56 pcb.h > --- i386/include/pcb.h 29 Dec 2005 13:23:48 -0000 1.56 > +++ i386/include/pcb.h 24 Apr 2008 06:46:59 -0000 > @@ -81,7 +81,7 @@ > struct trapframe; > > void makectx(struct trapframe *, struct pcb *); > -void savectx(struct pcb *); > +int savectx(struct pcb *); > #endif > > #endif /* _I386_PCB_H_ */ > Index: dev/acpica/acpi.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v > retrieving revision 1.247 > diff -u -r1.247 acpi.c > --- dev/acpica/acpi.c 13 Mar 2008 20:39:03 -0000 1.247 > +++ dev/acpica/acpi.c 30 Apr 2008 13:14:48 -0000 > @@ -29,7 +29,7 @@ > > #include > __FBSDID("$FreeBSD: src/sys/dev/acpica/acpi.c,v 1.247 2008/03/13 20:39:03 jhb Exp $"); > - > +#define SMP > #include "opt_acpi.h" > #include > #include > @@ -47,6 +47,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -2339,6 +2340,8 @@ > * drivers need this. > */ > mtx_lock(&Giant); > + sched_bind(curthread, 0); > + stop_cpus(PCPU_GET(other_cpus)); > slp_state = ACPI_SS_NONE; > switch (state) { > case ACPI_STATE_S1: > @@ -2430,13 +2433,16 @@ > acpi_wake_prep_walk(state); > sc->acpi_sstate = ACPI_STATE_S0; > } > + printf("PREP WALK\n"); > if (slp_state >= ACPI_SS_SLP_PREP) > AcpiLeaveSleepState(state); > + printf("LEAVE_SLEEP_STATE\n"); > if (slp_state >= ACPI_SS_DEV_SUSPEND) > DEVICE_RESUME(root_bus); > + printf("DEVICE_RESUME\n"); > if (slp_state >= ACPI_SS_SLEPT) > acpi_enable_fixed_events(sc); > - > + printf("ENABLE_FIXED_EVENT\n"); > /* Allow another sleep request after a while. */ > if (state != ACPI_STATE_S5) > timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME); > @@ -2445,6 +2451,7 @@ > acpi_UserNotify("Resume", ACPI_ROOT_OBJECT, state); > > mtx_unlock(&Giant); > + sched_unbind(curthread); > return_ACPI_STATUS (status); > } > > Index: dev/acpica/acpi_ec.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v > retrieving revision 1.80 > diff -u -r1.80 acpi_ec.c > --- dev/acpica/acpi_ec.c 8 Nov 2007 21:20:34 -0000 1.80 > +++ dev/acpica/acpi_ec.c 7 May 2008 17:07:11 -0000 > @@ -747,7 +747,7 @@ > * If booting, check if we need to run the query handler. If so, we > * we call it directly here since our thread taskq is not active yet. > */ > - if (cold || rebooting) { > + if (cold || rebooting||sc->ec_suspending) { > if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { > CTR0(KTR_ACPI, "ec running gpe handler directly"); > EcGpeQueryHandler(sc); > _______________________________________________ > 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" -- Vladimir B. Grebenschikov vova@fbsd.ru From vova at fbsd.ru Wed May 21 14:22:06 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Wed May 21 14:22:16 2008 Subject: SMP suspend/resume. In-Reply-To: <200805131125.m4DBPu1q092741@sana.init-main.com> References: <200805131125.m4DBPu1q092741@sana.init-main.com> Message-ID: <1211379715.2851.2.camel@localhost> On Tue, 2008-05-13 at 20:25 +0900, takawata@init-main.com wrote: > Hi, I managed to make suspend and resume work on SMP system. > The patch following is a bit crude patch, but it begin > to work on my ThinkPad X61 (core2duo system). Tried patch on T60, from text console, on acpiconf -s3 it shows multiple times "forward_wakeup: Idle processor not found" on console and then friezed hard (even DDB does not works). But nothing was suspended actually ( before system goes to sleep but did not awakes) Any hints ? > TODO: > 1. Suspend/resume path it self is simular to AP boot path. > Some of code may be integrated. > 2. More context, like MTRR or npx context should be saved on > suspend. > 3. Make acpi suspend resume path more ABI aware: needless > register recoverly or special register context saving > (the value itself is usually constant) should be removed. > 4. Make same binary module work on both UP or SMP case. > (Or is it time to give up using acpi module on also on i386?) > > > > > > Index: i386/acpica/acpi_wakeup.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/acpica/acpi_wakeup.c,v > retrieving revision 1.47 > diff -u -r1.47 acpi_wakeup.c > --- i386/acpica/acpi_wakeup.c 16 Mar 2008 10:58:03 -0000 1.47 > +++ i386/acpica/acpi_wakeup.c 13 May 2008 09:12:18 -0000 > @@ -27,6 +27,7 @@ > > #include > __FBSDID("$FreeBSD: src/sys/i386/acpica/acpi_wakeup.c,v 1.47 2008/03/16 10:58:03 rwatson Exp $"); > +#define SMP > > #include > #include > @@ -49,6 +50,11 @@ > > #include > #include > +#include > +#include > +#include > +#include > +#include > > #include "acpi_wakecode.h" > > @@ -71,7 +77,9 @@ > > static uint16_t r_cs, r_ds, r_es, r_fs, r_gs, r_ss, r_tr; > static uint32_t r_esp; > - > +extern void *bootstacks[]; > +static char *bootSTK; > +void restore_sub(void); > static void acpi_printcpu(void); > static void acpi_realmodeinst(void *arg, bus_dma_segment_t *segs, > int nsegs, int error); > @@ -80,6 +88,7 @@ > /* XXX shut gcc up */ > extern int acpi_savecpu(void); > extern int acpi_restorecpu(void); > +extern void acpi_kicksub(void); > > #ifdef __GNUCLIKE_ASM > __asm__(" \n\ > @@ -104,6 +113,15 @@ > movl %eax,(%esp) \n\ > xorl %eax,%eax \n\ > ret \n\ > + \n\ > + .text \n\ > + .p2align 2, 0x90 \n\ > + .type acpi_kicksub, @function \n\ > +acpi_kicksub: \n\ > + .align 4 \n\ > + movl bootSTK,%esp \n\ > + jmp restore_sub \n\ > + ret \n\ > \n\ > .text \n\ > .p2align 2, 0x90 \n\ > @@ -149,6 +167,24 @@ > ret \n\ > "); > #endif /* __GNUCLIKE_ASM */ > +int acpi_cpu_resumed[MAXCPU]; > +int acpi_curcpu; > +extern int switch_debug; > + > +void restore_sub() > +{ > + ACPI_DISABLE_IRQS(); > + printf("RESTORE_SUB\n"); > + lapic_disable(); > + printf("LAPIC_SETUP\n"); > + lapic_setup(0); > + lapic_dump("RESTORE_SUB"); > + printf("RESTORE_SUB2\n"); > + ACPI_ENABLE_IRQS(); > + > + acpi_cpu_resumed[acpi_curcpu]= 1; > + acpi_restorecpu(); > +} > > static void > acpi_printcpu(void) > @@ -187,6 +223,119 @@ > outb(0x61, inb(0x61) & ~0x3); > } > > + > +int resume_other_cpu(struct acpi_softc *sc, int cpu); > +int resume_other_cpu(struct acpi_softc *sc, int cpu) > +{ > + int ms; > + int apic_id = cpu_apic_ids[cpu]; > + int gsel_tss; > + > + gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); > + acpi_curcpu = cpu; > + bootSTK= (char *)bootstacks[cpu] + KSTACK_PAGES * PAGE_SIZE - 4; > + printf("%p\n", bootSTK); > + p_gdt = (struct region_descriptor *) > + (sc->acpi_wakeaddr + physical_gdt); > + saved_gdt.rd_limit = NGDT * sizeof(gdt[0]) -1; > + saved_gdt.rd_base = (int )&gdt[cpu*NGDT]; > + p_gdt->rd_limit = saved_gdt.rd_limit; > + p_gdt->rd_base = vtophys(saved_gdt.rd_base); > + r_esp = stoppcbs[cpu].pcb_esp; > + r_ebp = stoppcbs[cpu].pcb_ebp; > + r_esi = stoppcbs[cpu].pcb_esi; > + r_edi = stoppcbs[cpu].pcb_edi; > + r_efl = stoppcbs[cpu].pcb_psl; > + ret_addr = stoppcbs[cpu].pcb_eip; > + WAKECODE_FIXUP(physical_esp, uint32_t, vtophys(bootSTK) ); > + WAKECODE_FIXUP(previous_cr0, uint32_t, r_cr0); > + WAKECODE_FIXUP(previous_cr2, uint32_t, r_cr2); > + WAKECODE_FIXUP(previous_cr3, uint32_t, r_cr3); > + WAKECODE_FIXUP(previous_cr4, uint32_t, r_cr4); > + > + WAKECODE_FIXUP(resume_beep, uint32_t, 0); > + WAKECODE_FIXUP(reset_video, uint32_t, 0); > + > + WAKECODE_FIXUP(previous_tr, uint16_t, gsel_tss); > + WAKECODE_BCOPY(previous_gdt, struct region_descriptor, saved_gdt); > + WAKECODE_FIXUP(previous_ldt, uint16_t, saved_ldt); > + WAKECODE_BCOPY(previous_idt, struct region_descriptor, saved_idt); > + > + WAKECODE_FIXUP(where_to_recover, void *, acpi_kicksub); > + > + WAKECODE_FIXUP(previous_ds, uint16_t, r_ds); > + WAKECODE_FIXUP(previous_es, uint16_t, r_es); > + WAKECODE_FIXUP(previous_fs, uint16_t, r_fs); > + WAKECODE_FIXUP(previous_gs, uint16_t, 0); > + WAKECODE_FIXUP(previous_ss, uint16_t, r_ss); > + > + /* do an INIT IPI: assert RESET */ > + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | > + APIC_LEVEL_ASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, apic_id); > + > + /* wait for pending status end */ > + lapic_ipi_wait(-1); > + > + /* do an INIT IPI: deassert RESET */ > + lapic_ipi_raw(APIC_DEST_ALLESELF | APIC_TRIGMOD_LEVEL | > + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, 0); > + > + /* wait for pending status end */ > + DELAY(10000); /* wait ~10mS */ > + lapic_ipi_wait(-1); > + /* > + * next we do a STARTUP IPI: the previous INIT IPI might still be > + * latched, (P5 bug) this 1st STARTUP would then terminate > + * immediately, and the previously started INIT IPI would continue. OR > + * the previous INIT IPI has already run. and this STARTUP IPI will > + * run. OR the previous INIT IPI was ignored. and this STARTUP IPI > + * will run. > + */ > + > + /* do a STARTUP IPI */ > + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | > + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP | > + ((sc->acpi_wakephys >>12)&0xff), apic_id); > + lapic_ipi_wait(-1); > + DELAY(200); /* wait ~200uS */ > + > + /* > + * finally we do a 2nd STARTUP IPI: this 2nd STARTUP IPI should run IF > + * the previous STARTUP IPI was cancelled by a latched INIT IPI. OR > + * this STARTUP IPI will be ignored, as only ONE STARTUP IPI is > + * recognized after hardware RESET or INIT IPI. > + */ > + > + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | > + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP | > + ((sc->acpi_wakephys >>12)&0xff), apic_id); > + lapic_ipi_wait(-1); > + DELAY(200); /* wait ~200uS */ > + > + /* Wait up to 5 seconds for it to start. */ > + for (ms = 0; ms < 5000; ms++) { > + if(acpi_cpu_resumed[cpu]){ > + acpi_cpu_resumed[cpu]= 0; > + return 0; > + } > + DELAY(1000); > + } > + return -1; /* return FAILURE */ > + > +} > +int resume_other_cpus(struct acpi_softc *sc); > +int resume_other_cpus(struct acpi_softc *sc) > +{ > + int i; > + printf("RESUME_OTHER_CPUS"); > + *((volatile u_short *) 0x467) = 0; > + *((volatile u_short *) 0x468) = (sc->acpi_wakephys&0xffff0)>>4; > + > + for(i = 1; i < mp_ncpus; i++){ > + resume_other_cpu(sc, i); > + } > + return 0; > +} > int > acpi_sleep_machdep(struct acpi_softc *sc, int state) > { > @@ -270,14 +419,15 @@ > for (;;) ; > } else { > /* Execute Wakeup */ > - intr_resume(); > - > if (bootverbose) { > acpi_savecpu(); > acpi_printcpu(); > } > + resume_other_cpus(sc); > + restart_cpus(stopped_cpus); > + intr_resume(); > + lapic_dump("MAIN"); > } > - > out: > load_cr3(cr3); > write_eflags(ef); > @@ -285,7 +435,7 @@ > /* If we beeped, turn it off after a delay. */ > if (acpi_resume_beep) > timeout(acpi_stop_beep, NULL, 3 * hz); > - > + printf("FUGAFUGA\n"); > return (ret); > } > > Index: i386/i386/io_apic.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/io_apic.c,v > retrieving revision 1.35 > diff -u -r1.35 io_apic.c > --- i386/i386/io_apic.c 5 Jun 2007 18:57:48 -0000 1.35 > +++ i386/i386/io_apic.c 13 May 2008 08:22:55 -0000 > @@ -444,8 +444,9 @@ > struct ioapic *io = (struct ioapic *)pic; > int i; > > - for (i = 0; i < io->io_numintr; i++) > + for (i = 0; i < io->io_numintr; i++){ > ioapic_program_intpin(&io->io_pins[i]); > + } > } > > /* > Index: i386/i386/mp_machdep.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v > retrieving revision 1.286 > diff -u -r1.286 mp_machdep.c > --- i386/i386/mp_machdep.c 10 Apr 2008 18:38:31 -0000 1.286 > +++ i386/i386/mp_machdep.c 13 May 2008 07:08:29 -0000 > @@ -1299,18 +1299,19 @@ > int cpu = PCPU_GET(cpuid); > int cpumask = PCPU_GET(cpumask); > > - savectx(&stoppcbs[cpu]); > - > - /* Indicate that we are stopped */ > - atomic_set_int(&stopped_cpus, cpumask); > + if(savectx(&stoppcbs[cpu])){ > + /* Indicate that we are stopped */ > + atomic_set_int(&stopped_cpus, cpumask); > + wbinvd(); > + } > > /* Wait for restart */ > - while (!(started_cpus & cpumask)) > - ia32_pause(); > - > + while (!(started_cpus & cpumask)){ > + ia32_pause(); > + } > atomic_clear_int(&started_cpus, cpumask); > atomic_clear_int(&stopped_cpus, cpumask); > - > + > if (cpu == 0 && cpustop_restartfunc != NULL) { > cpustop_restartfunc(); > cpustop_restartfunc = NULL; > Index: i386/i386/swtch.s > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/swtch.s,v > retrieving revision 1.156 > diff -u -r1.156 swtch.s > --- i386/i386/swtch.s 22 Aug 2007 05:06:14 -0000 1.156 > +++ i386/i386/swtch.s 9 May 2008 15:16:03 -0000 > @@ -413,6 +413,6 @@ > 1: > popfl > #endif /* DEV_NPX */ > - > + movl $1, %eax > ret > END(savectx) > Index: i386/include/pcb.h > =================================================================== > RCS file: /home/ncvs/src/sys/i386/include/pcb.h,v > retrieving revision 1.56 > diff -u -r1.56 pcb.h > --- i386/include/pcb.h 29 Dec 2005 13:23:48 -0000 1.56 > +++ i386/include/pcb.h 24 Apr 2008 06:46:59 -0000 > @@ -81,7 +81,7 @@ > struct trapframe; > > void makectx(struct trapframe *, struct pcb *); > -void savectx(struct pcb *); > +int savectx(struct pcb *); > #endif > > #endif /* _I386_PCB_H_ */ > Index: dev/acpica/acpi.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v > retrieving revision 1.247 > diff -u -r1.247 acpi.c > --- dev/acpica/acpi.c 13 Mar 2008 20:39:03 -0000 1.247 > +++ dev/acpica/acpi.c 30 Apr 2008 13:14:48 -0000 > @@ -29,7 +29,7 @@ > > #include > __FBSDID("$FreeBSD: src/sys/dev/acpica/acpi.c,v 1.247 2008/03/13 20:39:03 jhb Exp $"); > - > +#define SMP > #include "opt_acpi.h" > #include > #include > @@ -47,6 +47,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -2339,6 +2340,8 @@ > * drivers need this. > */ > mtx_lock(&Giant); > + sched_bind(curthread, 0); > + stop_cpus(PCPU_GET(other_cpus)); > slp_state = ACPI_SS_NONE; > switch (state) { > case ACPI_STATE_S1: > @@ -2430,13 +2433,16 @@ > acpi_wake_prep_walk(state); > sc->acpi_sstate = ACPI_STATE_S0; > } > + printf("PREP WALK\n"); > if (slp_state >= ACPI_SS_SLP_PREP) > AcpiLeaveSleepState(state); > + printf("LEAVE_SLEEP_STATE\n"); > if (slp_state >= ACPI_SS_DEV_SUSPEND) > DEVICE_RESUME(root_bus); > + printf("DEVICE_RESUME\n"); > if (slp_state >= ACPI_SS_SLEPT) > acpi_enable_fixed_events(sc); > - > + printf("ENABLE_FIXED_EVENT\n"); > /* Allow another sleep request after a while. */ > if (state != ACPI_STATE_S5) > timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME); > @@ -2445,6 +2451,7 @@ > acpi_UserNotify("Resume", ACPI_ROOT_OBJECT, state); > > mtx_unlock(&Giant); > + sched_unbind(curthread); > return_ACPI_STATUS (status); > } > > Index: dev/acpica/acpi_ec.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v > retrieving revision 1.80 > diff -u -r1.80 acpi_ec.c > --- dev/acpica/acpi_ec.c 8 Nov 2007 21:20:34 -0000 1.80 > +++ dev/acpica/acpi_ec.c 7 May 2008 17:07:11 -0000 > @@ -747,7 +747,7 @@ > * If booting, check if we need to run the query handler. If so, we > * we call it directly here since our thread taskq is not active yet. > */ > - if (cold || rebooting) { > + if (cold || rebooting||sc->ec_suspending) { > if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { > CTR0(KTR_ACPI, "ec running gpe handler directly"); > EcGpeQueryHandler(sc); > _______________________________________________ > 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" -- Vladimir B. Grebenschikov vova@fbsd.ru From vova at fbsd.ru Wed May 21 17:23:39 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Wed May 21 17:23:44 2008 Subject: SMP suspend/resume. In-Reply-To: <1211379715.2851.2.camel@localhost> References: <200805131125.m4DBPu1q092741@sana.init-main.com> <1211379715.2851.2.camel@localhost> Message-ID: <1211390605.1794.15.camel@localhost> On Wed, 2008-05-21 at 18:21 +0400, Vladimir Grebenschikov wrote: > On Tue, 2008-05-13 at 20:25 +0900, takawata@init-main.com wrote: > > Hi, I managed to make suspend and resume work on SMP system. > > The patch following is a bit crude patch, but it begin > > to work on my ThinkPad X61 (core2duo system). > > Tried patch on T60, from text console, > on acpiconf -s3 > it shows multiple times "forward_wakeup: Idle processor not found" on > console and then friezed hard (even DDB does not works). But nothing was > suspended actually ( before system goes to sleep but did not awakes) > > Any hints ? In some conditions (single-user, no additional drivers) it shows: forward_wakeup: Idle processor not found PREP_WALK LEAVE_SLEEP_STATE DEVICE_RESUME ?forward_wakeup: Idle processor not found ENABLE_FIXED_EVENT ?forward_wakeup: Idle processor not found ?forward_wakeup: Idle processor not found ?forward_wakeup: Idle processor not found ?forward_wakeup: Idle processor not found ?forward_wakeup: Idle processor not found ... etc ... sometimes it shows just many ?forward_wakeup: Idle processor not found and in any case locks hard and did not enter S3 But RELENG_7 (without patch) normally enters to S3, but failed to wake. > > TODO: > > 1. Suspend/resume path it self is simular to AP boot path. > > Some of code may be integrated. > > 2. More context, like MTRR or npx context should be saved on > > suspend. > > 3. Make acpi suspend resume path more ABI aware: needless > > register recoverly or special register context saving > > (the value itself is usually constant) should be removed. > > 4. Make same binary module work on both UP or SMP case. > > (Or is it time to give up using acpi module on also on i386?) > > > > > > > > > > > > Index: i386/acpica/acpi_wakeup.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/i386/acpica/acpi_wakeup.c,v > > retrieving revision 1.47 > > diff -u -r1.47 acpi_wakeup.c > > --- i386/acpica/acpi_wakeup.c 16 Mar 2008 10:58:03 -0000 1.47 > > +++ i386/acpica/acpi_wakeup.c 13 May 2008 09:12:18 -0000 > > @@ -27,6 +27,7 @@ > > > > #include > > __FBSDID("$FreeBSD: src/sys/i386/acpica/acpi_wakeup.c,v 1.47 2008/03/16 10:58:03 rwatson Exp $"); > > +#define SMP > > > > #include > > #include > > @@ -49,6 +50,11 @@ > > > > #include > > #include > > +#include > > +#include > > +#include > > +#include > > +#include > > > > #include "acpi_wakecode.h" > > > > @@ -71,7 +77,9 @@ > > > > static uint16_t r_cs, r_ds, r_es, r_fs, r_gs, r_ss, r_tr; > > static uint32_t r_esp; > > - > > +extern void *bootstacks[]; > > +static char *bootSTK; > > +void restore_sub(void); > > static void acpi_printcpu(void); > > static void acpi_realmodeinst(void *arg, bus_dma_segment_t *segs, > > int nsegs, int error); > > @@ -80,6 +88,7 @@ > > /* XXX shut gcc up */ > > extern int acpi_savecpu(void); > > extern int acpi_restorecpu(void); > > +extern void acpi_kicksub(void); > > > > #ifdef __GNUCLIKE_ASM > > __asm__(" \n\ > > @@ -104,6 +113,15 @@ > > movl %eax,(%esp) \n\ > > xorl %eax,%eax \n\ > > ret \n\ > > + \n\ > > + .text \n\ > > + .p2align 2, 0x90 \n\ > > + .type acpi_kicksub, @function \n\ > > +acpi_kicksub: \n\ > > + .align 4 \n\ > > + movl bootSTK,%esp \n\ > > + jmp restore_sub \n\ > > + ret \n\ > > \n\ > > .text \n\ > > .p2align 2, 0x90 \n\ > > @@ -149,6 +167,24 @@ > > ret \n\ > > "); > > #endif /* __GNUCLIKE_ASM */ > > +int acpi_cpu_resumed[MAXCPU]; > > +int acpi_curcpu; > > +extern int switch_debug; > > + > > +void restore_sub() > > +{ > > + ACPI_DISABLE_IRQS(); > > + printf("RESTORE_SUB\n"); > > + lapic_disable(); > > + printf("LAPIC_SETUP\n"); > > + lapic_setup(0); > > + lapic_dump("RESTORE_SUB"); > > + printf("RESTORE_SUB2\n"); > > + ACPI_ENABLE_IRQS(); > > + > > + acpi_cpu_resumed[acpi_curcpu]= 1; > > + acpi_restorecpu(); > > +} > > > > static void > > acpi_printcpu(void) > > @@ -187,6 +223,119 @@ > > outb(0x61, inb(0x61) & ~0x3); > > } > > > > + > > +int resume_other_cpu(struct acpi_softc *sc, int cpu); > > +int resume_other_cpu(struct acpi_softc *sc, int cpu) > > +{ > > + int ms; > > + int apic_id = cpu_apic_ids[cpu]; > > + int gsel_tss; > > + > > + gsel_tss = GSEL(GPROC0_SEL, SEL_KPL); > > + acpi_curcpu = cpu; > > + bootSTK= (char *)bootstacks[cpu] + KSTACK_PAGES * PAGE_SIZE - 4; > > + printf("%p\n", bootSTK); > > + p_gdt = (struct region_descriptor *) > > + (sc->acpi_wakeaddr + physical_gdt); > > + saved_gdt.rd_limit = NGDT * sizeof(gdt[0]) -1; > > + saved_gdt.rd_base = (int )&gdt[cpu*NGDT]; > > + p_gdt->rd_limit = saved_gdt.rd_limit; > > + p_gdt->rd_base = vtophys(saved_gdt.rd_base); > > + r_esp = stoppcbs[cpu].pcb_esp; > > + r_ebp = stoppcbs[cpu].pcb_ebp; > > + r_esi = stoppcbs[cpu].pcb_esi; > > + r_edi = stoppcbs[cpu].pcb_edi; > > + r_efl = stoppcbs[cpu].pcb_psl; > > + ret_addr = stoppcbs[cpu].pcb_eip; > > + WAKECODE_FIXUP(physical_esp, uint32_t, vtophys(bootSTK) ); > > + WAKECODE_FIXUP(previous_cr0, uint32_t, r_cr0); > > + WAKECODE_FIXUP(previous_cr2, uint32_t, r_cr2); > > + WAKECODE_FIXUP(previous_cr3, uint32_t, r_cr3); > > + WAKECODE_FIXUP(previous_cr4, uint32_t, r_cr4); > > + > > + WAKECODE_FIXUP(resume_beep, uint32_t, 0); > > + WAKECODE_FIXUP(reset_video, uint32_t, 0); > > + > > + WAKECODE_FIXUP(previous_tr, uint16_t, gsel_tss); > > + WAKECODE_BCOPY(previous_gdt, struct region_descriptor, saved_gdt); > > + WAKECODE_FIXUP(previous_ldt, uint16_t, saved_ldt); > > + WAKECODE_BCOPY(previous_idt, struct region_descriptor, saved_idt); > > + > > + WAKECODE_FIXUP(where_to_recover, void *, acpi_kicksub); > > + > > + WAKECODE_FIXUP(previous_ds, uint16_t, r_ds); > > + WAKECODE_FIXUP(previous_es, uint16_t, r_es); > > + WAKECODE_FIXUP(previous_fs, uint16_t, r_fs); > > + WAKECODE_FIXUP(previous_gs, uint16_t, 0); > > + WAKECODE_FIXUP(previous_ss, uint16_t, r_ss); > > + > > + /* do an INIT IPI: assert RESET */ > > + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | > > + APIC_LEVEL_ASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, apic_id); > > + > > + /* wait for pending status end */ > > + lapic_ipi_wait(-1); > > + > > + /* do an INIT IPI: deassert RESET */ > > + lapic_ipi_raw(APIC_DEST_ALLESELF | APIC_TRIGMOD_LEVEL | > > + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, 0); > > + > > + /* wait for pending status end */ > > + DELAY(10000); /* wait ~10mS */ > > + lapic_ipi_wait(-1); > > + /* > > + * next we do a STARTUP IPI: the previous INIT IPI might still be > > + * latched, (P5 bug) this 1st STARTUP would then terminate > > + * immediately, and the previously started INIT IPI would continue. OR > > + * the previous INIT IPI has already run. and this STARTUP IPI will > > + * run. OR the previous INIT IPI was ignored. and this STARTUP IPI > > + * will run. > > + */ > > + > > + /* do a STARTUP IPI */ > > + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | > > + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP | > > + ((sc->acpi_wakephys >>12)&0xff), apic_id); > > + lapic_ipi_wait(-1); > > + DELAY(200); /* wait ~200uS */ > > + > > + /* > > + * finally we do a 2nd STARTUP IPI: this 2nd STARTUP IPI should run IF > > + * the previous STARTUP IPI was cancelled by a latched INIT IPI. OR > > + * this STARTUP IPI will be ignored, as only ONE STARTUP IPI is > > + * recognized after hardware RESET or INIT IPI. > > + */ > > + > > + lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | > > + APIC_LEVEL_DEASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP | > > + ((sc->acpi_wakephys >>12)&0xff), apic_id); > > + lapic_ipi_wait(-1); > > + DELAY(200); /* wait ~200uS */ > > + > > + /* Wait up to 5 seconds for it to start. */ > > + for (ms = 0; ms < 5000; ms++) { > > + if(acpi_cpu_resumed[cpu]){ > > + acpi_cpu_resumed[cpu]= 0; > > + return 0; > > + } > > + DELAY(1000); > > + } > > + return -1; /* return FAILURE */ > > + > > +} > > +int resume_other_cpus(struct acpi_softc *sc); > > +int resume_other_cpus(struct acpi_softc *sc) > > +{ > > + int i; > > + printf("RESUME_OTHER_CPUS"); > > + *((volatile u_short *) 0x467) = 0; > > + *((volatile u_short *) 0x468) = (sc->acpi_wakephys&0xffff0)>>4; > > + > > + for(i = 1; i < mp_ncpus; i++){ > > + resume_other_cpu(sc, i); > > + } > > + return 0; > > +} > > int > > acpi_sleep_machdep(struct acpi_softc *sc, int state) > > { > > @@ -270,14 +419,15 @@ > > for (;;) ; > > } else { > > /* Execute Wakeup */ > > - intr_resume(); > > - > > if (bootverbose) { > > acpi_savecpu(); > > acpi_printcpu(); > > } > > + resume_other_cpus(sc); > > + restart_cpus(stopped_cpus); > > + intr_resume(); > > + lapic_dump("MAIN"); > > } > > - > > out: > > load_cr3(cr3); > > write_eflags(ef); > > @@ -285,7 +435,7 @@ > > /* If we beeped, turn it off after a delay. */ > > if (acpi_resume_beep) > > timeout(acpi_stop_beep, NULL, 3 * hz); > > - > > + printf("FUGAFUGA\n"); > > return (ret); > > } > > > > Index: i386/i386/io_apic.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/i386/i386/io_apic.c,v > > retrieving revision 1.35 > > diff -u -r1.35 io_apic.c > > --- i386/i386/io_apic.c 5 Jun 2007 18:57:48 -0000 1.35 > > +++ i386/i386/io_apic.c 13 May 2008 08:22:55 -0000 > > @@ -444,8 +444,9 @@ > > struct ioapic *io = (struct ioapic *)pic; > > int i; > > > > - for (i = 0; i < io->io_numintr; i++) > > + for (i = 0; i < io->io_numintr; i++){ > > ioapic_program_intpin(&io->io_pins[i]); > > + } > > } > > > > /* > > Index: i386/i386/mp_machdep.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/i386/i386/mp_machdep.c,v > > retrieving revision 1.286 > > diff -u -r1.286 mp_machdep.c > > --- i386/i386/mp_machdep.c 10 Apr 2008 18:38:31 -0000 1.286 > > +++ i386/i386/mp_machdep.c 13 May 2008 07:08:29 -0000 > > @@ -1299,18 +1299,19 @@ > > int cpu = PCPU_GET(cpuid); > > int cpumask = PCPU_GET(cpumask); > > > > - savectx(&stoppcbs[cpu]); > > - > > - /* Indicate that we are stopped */ > > - atomic_set_int(&stopped_cpus, cpumask); > > + if(savectx(&stoppcbs[cpu])){ > > + /* Indicate that we are stopped */ > > + atomic_set_int(&stopped_cpus, cpumask); > > + wbinvd(); > > + } > > > > /* Wait for restart */ > > - while (!(started_cpus & cpumask)) > > - ia32_pause(); > > - > > + while (!(started_cpus & cpumask)){ > > + ia32_pause(); > > + } > > atomic_clear_int(&started_cpus, cpumask); > > atomic_clear_int(&stopped_cpus, cpumask); > > - > > + > > if (cpu == 0 && cpustop_restartfunc != NULL) { > > cpustop_restartfunc(); > > cpustop_restartfunc = NULL; > > Index: i386/i386/swtch.s > > =================================================================== > > RCS file: /home/ncvs/src/sys/i386/i386/swtch.s,v > > retrieving revision 1.156 > > diff -u -r1.156 swtch.s > > --- i386/i386/swtch.s 22 Aug 2007 05:06:14 -0000 1.156 > > +++ i386/i386/swtch.s 9 May 2008 15:16:03 -0000 > > @@ -413,6 +413,6 @@ > > 1: > > popfl > > #endif /* DEV_NPX */ > > - > > + movl $1, %eax > > ret > > END(savectx) > > Index: i386/include/pcb.h > > =================================================================== > > RCS file: /home/ncvs/src/sys/i386/include/pcb.h,v > > retrieving revision 1.56 > > diff -u -r1.56 pcb.h > > --- i386/include/pcb.h 29 Dec 2005 13:23:48 -0000 1.56 > > +++ i386/include/pcb.h 24 Apr 2008 06:46:59 -0000 > > @@ -81,7 +81,7 @@ > > struct trapframe; > > > > void makectx(struct trapframe *, struct pcb *); > > -void savectx(struct pcb *); > > +int savectx(struct pcb *); > > #endif > > > > #endif /* _I386_PCB_H_ */ > > Index: dev/acpica/acpi.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v > > retrieving revision 1.247 > > diff -u -r1.247 acpi.c > > --- dev/acpica/acpi.c 13 Mar 2008 20:39:03 -0000 1.247 > > +++ dev/acpica/acpi.c 30 Apr 2008 13:14:48 -0000 > > @@ -29,7 +29,7 @@ > > > > #include > > __FBSDID("$FreeBSD: src/sys/dev/acpica/acpi.c,v 1.247 2008/03/13 20:39:03 jhb Exp $"); > > - > > +#define SMP > > #include "opt_acpi.h" > > #include > > #include > > @@ -47,6 +47,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -2339,6 +2340,8 @@ > > * drivers need this. > > */ > > mtx_lock(&Giant); > > + sched_bind(curthread, 0); > > + stop_cpus(PCPU_GET(other_cpus)); > > slp_state = ACPI_SS_NONE; > > switch (state) { > > case ACPI_STATE_S1: > > @@ -2430,13 +2433,16 @@ > > acpi_wake_prep_walk(state); > > sc->acpi_sstate = ACPI_STATE_S0; > > } > > + printf("PREP WALK\n"); > > if (slp_state >= ACPI_SS_SLP_PREP) > > AcpiLeaveSleepState(state); > > + printf("LEAVE_SLEEP_STATE\n"); > > if (slp_state >= ACPI_SS_DEV_SUSPEND) > > DEVICE_RESUME(root_bus); > > + printf("DEVICE_RESUME\n"); > > if (slp_state >= ACPI_SS_SLEPT) > > acpi_enable_fixed_events(sc); > > - > > + printf("ENABLE_FIXED_EVENT\n"); > > /* Allow another sleep request after a while. */ > > if (state != ACPI_STATE_S5) > > timeout(acpi_sleep_enable, sc, hz * ACPI_MINIMUM_AWAKETIME); > > @@ -2445,6 +2451,7 @@ > > acpi_UserNotify("Resume", ACPI_ROOT_OBJECT, state); > > > > mtx_unlock(&Giant); > > + sched_unbind(curthread); > > return_ACPI_STATUS (status); > > } > > > > Index: dev/acpica/acpi_ec.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/dev/acpica/acpi_ec.c,v > > retrieving revision 1.80 > > diff -u -r1.80 acpi_ec.c > > --- dev/acpica/acpi_ec.c 8 Nov 2007 21:20:34 -0000 1.80 > > +++ dev/acpica/acpi_ec.c 7 May 2008 17:07:11 -0000 > > @@ -747,7 +747,7 @@ > > * If booting, check if we need to run the query handler. If so, we > > * we call it directly here since our thread taskq is not active yet. > > */ > > - if (cold || rebooting) { > > + if (cold || rebooting||sc->ec_suspending) { > > if ((EC_GET_CSR(sc) & EC_EVENT_SCI)) { > > CTR0(KTR_ACPI, "ec running gpe handler directly"); > > EcGpeQueryHandler(sc); > > _______________________________________________ > > 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" -- Vladimir B. Grebenschikov vova@fbsd.ru From takawata at init-main.com Thu May 22 04:01:19 2008 From: takawata at init-main.com (Takanori Watanabe) Date: Thu May 22 04:01:21 2008 Subject: SMP suspend/resume. In-Reply-To: Your message of "Wed, 21 May 2008 21:23:25 +0400." <1211390605.1794.15.camel@localhost> Message-ID: <200805220339.m4M3dF2q033762@sana.init-main.com> >I've tried to build patch with recent CURRENT and get >SMP redefined for acpi.c and acpi_wakeup.c > >Was it expected ? Expected. I tested with kernel module, so I define directly for now. I want to make it work without SMP defined by cleaning up and moving the smp dependent code to mp_machdep.c . >On Wed, 2008-05-21 at 18:21 +0400, Vladimir Grebenschikov wrote: >> On Tue, 2008-05-13 at 20:25 +0900, takawata@init-main.com wrote: >> > Hi, I managed to make suspend and resume work on SMP system. >> > The patch following is a bit crude patch, but it begin=20 >> > to work on my ThinkPad X61 (core2duo system). >>=20 >> Tried patch on T60, from text console,=20 >> on acpiconf -s3 >> it shows multiple times "forward_wakeup: Idle processor not found" on >> console and then friezed hard (even DDB does not works). But nothing was >> suspended actually ( before system goes to sleep but did not awakes) >>=20 >> Any hints ? > >In some conditions (single-user, no additional drivers) it shows: > >forward_wakeup: Idle processor not found >PREP_WALK >LEAVE_SLEEP_STATE >DEVICE_RESUME >=EF=BB=BFforward_wakeup: Idle processor not found >ENABLE_FIXED_EVENT >=EF=BB=BFforward_wakeup: Idle processor not found >=EF=BB=BFforward_wakeup: Idle processor not found >=EF=BB=BFforward_wakeup: Idle processor not found >=EF=BB=BFforward_wakeup: Idle processor not found >=EF=BB=BFforward_wakeup: Idle processor not found >... etc ... > >sometimes it shows just many >=EF=BB=BFforward_wakeup: Idle processor not found > > >and in any case locks hard and did not enter S3 > >But RELENG_7 (without patch) normally enters to S3, but failed to wake. I tested it on sched_ule. So I know littele about sched_4bsd. The message may caused on forward_wakeup on sched_4bsd, so how about kern.sched.ipiwakeup.forward_wakeup set to 0. From vova at fbsd.ru Thu May 22 10:30:26 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Thu May 22 10:30:34 2008 Subject: SMP suspend/resume. In-Reply-To: <200805220339.m4M3dF2q033762@sana.init-main.com> References: <200805220339.m4M3dF2q033762@sana.init-main.com> Message-ID: <1211452213.2647.1.camel@localhost> On Thu, 2008-05-22 at 12:39 +0900, Takanori Watanabe wrote: > >But RELENG_7 (without patch) normally enters to S3, but failed to wake. > > I tested it on sched_ule. So I know littele about sched_4bsd. > The message may caused on forward_wakeup on sched_4bsd, so > how about kern.sched.ipiwakeup.forward_wakeup set to 0. Just test it on SCHED_ULE. Now it does not write anything on console, just turn off console and hardlock. No actual enter to sleep (I assume that by indication lamps). I've booted as 'boot -sv' and tried to go to sleep from single-user mode. -- Vladimir B. Grebenschikov vova@fbsd.ru From takawata at init-main.com Thu May 22 14:21:17 2008 From: takawata at init-main.com (Takanori Watanabe) Date: Thu May 22 14:21:27 2008 Subject: SMP suspend/resume. In-Reply-To: Your message of "Thu, 22 May 2008 14:30:13 +0400." <1211452213.2647.1.camel@localhost> Message-ID: <200805221359.m4MDxRs9042493@sana.init-main.com> In message <1211452213.2647.1.camel@localhost>, Vladimir Grebenschikov wrote: >On Thu, 2008-05-22 at 12:39 +0900, Takanori Watanabe wrote: > >> >But RELENG_7 (without patch) normally enters to S3, but failed to wake. >> >> I tested it on sched_ule. So I know littele about sched_4bsd. >> The message may caused on forward_wakeup on sched_4bsd, so >> how about kern.sched.ipiwakeup.forward_wakeup set to 0. > >Just test it on SCHED_ULE. >Now it does not write anything on console, just turn off console and >hardlock. >No actual enter to sleep (I assume that by indication lamps). > >I've booted as 'boot -sv' and tried to go to sleep from single-user >mode. In RELENG_7, some more patch should be merged from HEAD, so that preserver identity mapping. BTW, did you make sure UP kernel successfully suspend and resume on your machine? From serge at a-1.com.ua Thu May 22 21:14:22 2008 From: serge at a-1.com.ua (Serge Semenenko) Date: Thu May 22 21:14:25 2008 Subject: PCI bridge with I/O decode 0x0-0x0 In-Reply-To: <1312312888.89527.1211347514074.JavaMail.apache@mail54.abv.bg> References: <1312312888.89527.1211347514074.JavaMail.apache@mail54.abv.bg> Message-ID: <4835E224.5090000@a-1.com.ua> Mario Pavlov wrote: > >Hi > > > >Have the same problem with my Acer 6292... But at the same time there > >are no problems on my friend's EX5620G. I've spent some time trying to > >fix aml code but with no success. May be I'm not too good in that or the > >problem might be somewhere else... Anyway, it seems that somewhere > >during acpi initialization PCI Config space of PCI bridges gets > >corrupted. So, to get my network cards working as a temporary solution I > >use the patch attached. Memory ranges I've found while booting with acpi > >disabled. I know that's not a solution but at least I could send now > >this message through built-in wifi card :) > > > >Regards, > >Serge > > Hi Serge, > nice hack ;) > I may also try something like that... > however why don't you post your ASL and also your friend's ASL > and lets see what we can do together > we may also get some help from the ACPI gurus here. > thanks > > Regards > MGP > > ----------------------------------------------------------------- > ????? ?? ???????! > http://zoom.bg/page.php?bid=6 > Well.. let's try... Please find attached both my (6292) and my friend's (5620G) asl code. Regards, Serge From serge at a-1.com.ua Thu May 22 21:42:58 2008 From: serge at a-1.com.ua (Serge Semenenko) Date: Thu May 22 21:43:04 2008 Subject: PCI bridge with I/O decode 0x0-0x0 In-Reply-To: <1312312888.89527.1211347514074.JavaMail.apache@mail54.abv.bg> References: <1312312888.89527.1211347514074.JavaMail.apache@mail54.abv.bg> Message-ID: <4835E8DB.7020200@a-1.com.ua> Hm... Can't figure out how to use attachments in this list... May be URLs would be better?.. http://www.a1.com.ua/files/5620G.asl http://www.a1.com.ua/files/6292.asl From vova at fbsd.ru Fri May 23 11:14:44 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri May 23 11:14:57 2008 Subject: SMP suspend/resume. In-Reply-To: <200805221359.m4MDxRs9042493@sana.init-main.com> References: <200805221359.m4MDxRs9042493@sana.init-main.com> Message-ID: <1211541275.1857.3.camel@localhost> On Thu, 2008-05-22 at 22:59 +0900, Takanori Watanabe wrote: > In RELENG_7, some more patch should be merged from HEAD, so that > preserver identity mapping. > BTW, did you make sure UP kernel successfully suspend and resume > on your machine? Both 8-CURRENT UP and 8-CURRENT SMP without patches Does go to sleep on acpiconf -s3, but did not awakes (actually its HDD lamp flash several times, but sleep lamp did not turned off and it have not awaken) With patches it even did not go to sleep. -- Vladimir B. Grebenschikov vova@fbsd.ru From takawata at init-main.com Fri May 23 11:23:32 2008 From: takawata at init-main.com (Takanori Watanabe) Date: Fri May 23 11:23:34 2008 Subject: SMP suspend/resume. In-Reply-To: Your message of "Fri, 23 May 2008 15:14:35 +0400." <1211541275.1857.3.camel@localhost> Message-ID: <200805231101.m4NB1F5k007720@sana.init-main.com> In message <1211541275.1857.3.camel@localhost>, Vladimir Grebenschikov wrote: >> In RELENG_7, some more patch should be merged from HEAD, so that >> preserver identity mapping. >> BTW, did you make sure UP kernel successfully suspend and resume >> on your machine? > >Both 8-CURRENT UP and 8-CURRENT SMP without patches >Does go to sleep on acpiconf -s3, but did not awakes >(actually its HDD lamp flash several times, but sleep lamp did not >turned off and it have not awaken) > >With patches it even did not go to sleep. Hmm, so it may have to investigate why UP kernel fail to resume. From vova at fbsd.ru Fri May 23 13:08:01 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Fri May 23 13:08:03 2008 Subject: SMP suspend/resume. In-Reply-To: <200805231101.m4NB1F5k007720@sana.init-main.com> References: <200805231101.m4NB1F5k007720@sana.init-main.com> Message-ID: <1211548072.1857.11.camel@localhost> On Fri, 2008-05-23 at 20:01 +0900, Takanori Watanabe wrote: > In message <1211541275.1857.3.camel@localhost>, Vladimir Grebenschikov wrote: > >> In RELENG_7, some more patch should be merged from HEAD, so that > >> preserver identity mapping. > >> BTW, did you make sure UP kernel successfully suspend and resume > >> on your machine? > > > >Both 8-CURRENT UP and 8-CURRENT SMP without patches > >Does go to sleep on acpiconf -s3, but did not awakes > >(actually its HDD lamp flash several times, but sleep lamp did not > >turned off and it have not awaken) > > > >With patches it even did not go to sleep. > > Hmm, so it may have to investigate why UP kernel fail to resume. Can you suggest some steps do find the reason ? -- Vladimir B. Grebenschikov vova@fbsd.ru From gahr at FreeBSD.org Fri May 23 15:13:42 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Fri May 23 15:13:48 2008 Subject: [patch] acpi_battery -- notify critical 'life' via devd(8) Message-ID: <4836D795.6030804@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Nate, list, pre-everything: my knowledge of the ACPI subsystem is very limited, as is my understanding of general kernel mechanisms. --> if this patch is crap, please be patient with me :) reason: I want my laptop to notify me when the battery life reaches a certain critical low level (say, 5%). solution: I've implemented a kernel process in acpi_battery which notifies devd(8) when the critical level is reached. For this, I've added the following sysctl OIDs to the hw.acpi.battery tree: polling_rate: in seconds, self explaining... critical_level: in percent, also self explaining... questions: I've chosen a notify of 0x80 for this event. The reason just being that I've seen acpi_thermal starting its own notify values with this number. Is there any guidelines for Notify values? devd: This patch allows for a devd.conf(5) entry such as: notify 10 { match "system" "ACPI"; match "subsystem" "Battery"; match "notify" "0x80"; action "logger -p kern.emerg 'WARNING: low battery!'"; }; the patch: http://gahr.ch/FreeBSD/patches/_pending/acpi_battery.c.diff Any comments, tests, bug-reports, ... welcome! Thanks! P.S. please CC me as I don't follow freebsd-acpi@ (yet).$ - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkg215QACgkQwMJqmJVx9451lQCfZuNpsOOvalRvKrlu1VcQtP0M aAoAn2iXdHxrCzeAy+8qj5vMPgO9xCn4 =UIgG -----END PGP SIGNATURE----- From peterjeremy at optushome.com.au Fri May 23 22:32:39 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri May 23 22:32:43 2008 Subject: BIOS Regression on HP/Compaq [d]v6000 series notebooks In-Reply-To: <20080519110954.09c2d42f.ariff@FreeBSD.org> References: <20080428112623.GA99757@server.vk2pj.dyndns.org> <20080516202242.3992b284.ariff@FreeBSD.org> <20080517073716.GF80125@server.vk2pj.dyndns.org> <20080517194326.420ceb81.ariff@FreeBSD.org> <20080518030528.GA1099@server.vk2pj.dyndns.org> <20080519110954.09c2d42f.ariff@FreeBSD.org> Message-ID: <20080523223234.GB1469@server.vk2pj.dyndns.org> On 2008-May-19 11:09:54 +0800, Ariff Abdullah wrote: >I've been thinking on taking a different stab by hijacking cpu_idle*() >functions instead. Please disregard all previous quirks and get either >of these: > >http://people.freebsd.org/~ariff/misc/k8c1e/current_k8c1e_idle_hlt.diff > >http://people.freebsd.org/~ariff/misc/k8c1e/releng6-7_k8c1e_idle_hlt.diff That sounds like an eminently sensible approach. I've tried the releng6 version of that patch (which isn't at the above URL but looking in the k8c1e directory made it obvious) and the laptop now works correctly when you apply or remove power. There is an issue with booting on battery and I need to do some more investigating to determine whether this is a side-effect of the patch (which I don't believe) or something else. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-acpi/attachments/20080523/3f478ab3/attachment.pgp From bugmaster at FreeBSD.org Mon May 26 11:06:44 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon May 26 11:06:50 2008 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org Message-ID: <200805261106.m4QB6h9Z064799@freefall.freebsd.org> 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 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s kern/91038 acpi [panic] [ata] [acpi] 6.0-RELEASE on Fujitsu Siemens Am 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/108954 acpi [acpi] 'sleep(1)' sleeps >1 seconds when speedstep (Cx o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o kern/118973 acpi [acpi]: Kernel panic with acpi boot o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/120953 acpi [acpi]: FreeBSD 6.3 Release: acpi_tz0: _TMP value is o kern/121454 acpi [pst] Promise SuperTrak SX6000 does not load during bo 20 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 s kern/73823 acpi [request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/89411 acpi [acpi] acpiconf bug s kern/90243 acpi Laptop fan doesn't turn off (ACPI enabled) (Packard Be o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI 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 s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi [acpi] Dell C810 - ACPI problem o kern/117605 acpi [acpi] [request] add debug.cpufreq.highest o kern/120515 acpi [acpi] [patch] acpi_alloc_wakeup_handler: can't alloc o kern/121102 acpi [acpi_fujitsu] [patch] update acpi_fujitsu for the P80 o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f amd64/122521 acpi ACPI Error after upgrade to 7.0 o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot 22 problems total. From gavin at FreeBSD.org Mon May 26 17:38:07 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon May 26 17:38:09 2008 Subject: amd64/115011: ACPI problem ,reboot system down. Message-ID: <200805261738.m4QHc2cP099156@freefall.freebsd.org> Synopsis: ACPI problem ,reboot system down. State-Changed-From-To: open->feedback State-Changed-By: gavin State-Changed-When: Mon May 26 17:33:59 UTC 2008 State-Changed-Why: To submitter: do you still see these problems on newer versions of FreeBSDik (e.g. 7.0-RELEASE if possible)? If so, you will have to provide a lot more information, as I'm not even sure what the first problem you mention is. Do you mean that when running "reboot", the system actually powers off? Or that it hangs, and never successfully finishes shutting down? Responsible-Changed-From-To: freebsd-acpi->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Mon May 26 17:33:59 UTC 2008 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=115011 From markir at paradise.net.nz Tue May 27 00:07:41 2008 From: markir at paradise.net.nz (Mark Kirkwood) Date: Tue May 27 00:07:45 2008 Subject: Freebsd 7-stable on Asus Pro31j - acpi poweroff Message-ID: <483B4CE3.7070005@paradise.net.nz> I've recently obtained one of these laptops. While the basics work well, there are a few niggles, one of which is acpi poweroff: Powering down the laptop from Gnome, or command line 'shutdown -p now' results in a blank screen immediately after the acpi poweroff message (I *think* it's immediately afterwards, it blanks so quickly I can't be sure). However, the machine is still powered, and fans still running, so I have to actually power it off by holding down the power button. I see a few errors during boot: acpi0: Power Button (fixed) unknown: I/O range not supported unknown: I/O range not supported acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed but the basic stuff is detected: acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 Full dmesg is here: http://homepages.paradise.net.nz/markir/download/freebsd/zul.dmesg The acpi sysctls and dump are here: http://homepages.paradise.net.nz/markir/download/freebsd/zul.acpi http://homepages.paradise.net.nz/markir/download/freebsd/zul.asl.gz I looked at recompiling the asl, and it has a few warnings, but no errors: http://homepages.paradise.net.nz/markir/download/freebsd/zul.asl.recompile Finally the results of pciconf -lv are here: http://homepages.paradise.net.nz/markir/download/freebsd/zul.pciconf Any suggestions welcome! regards Mark From david at wood2.org.uk Sat May 31 19:43:03 2008 From: david at wood2.org.uk (David Wood) Date: Sat May 31 19:43:07 2008 Subject: Dell PowerEdge 2950 III - CPU power management problems Message-ID: Dear all, I'm having problems with CPU power management on a Dell PowerEdge 2950 III. I've posted this to freebsd-acpi in the first instance - though it may finish up belonging on freebsd-stable. As I am almost certain there are bugs in teh DSDT, I thought I'd start on freebsd-acpi. THE HARDWARE AND OS The machine has BIOS version 2.2.6; it came from the factory that way and there's no later version available on the Dell Support web site. It has two Xeon E5430 processors (2.66GHz quad core Penryn), for a total of 8 cores. The "Demand-based power management" option is selected in the F2 BIOS setup. The machine is running FreeBSD 7.0-STABLE, csupped, built and installed earlier today (ACPI_DEBUG=1 was passed to all the make commands). The intention is to deploy this machine in production with 7.0-RELEASE and that's the OS I started off with. When I found I had problems, I went to -STABLE in case any relevant fixes had already been checked in. The behaviour of est(4) is different in -STABLE to 7.0-RELEASE. WHERE I THINK I AM I can't control the processor core clock frequencies, even after fixing what I'm almost certain are bugs in the DSDT. The values in the _PSS object for Control and Status could be wrong, upsetting est(4) - but the correct values are only available in the (Intel Confidential - only available via an Intel FAE) BIOS Writers' Guide. There are errors from est on a verbose boot. Maybe the _PSS values aren't the problem, even though they appear to be wrong. I believe there are restrictions on controlling clock frequency of the individual cores of multi-core processors. However, it would be useful to be able to use powerd on this box as its load in production will be bursty and slowing down the processor cores should save power (and save on generating heat). dev.cpu.0.freq_levels looks reasonable, but no other cpu has freq_levels or freq. sysctl dev.cpu.0.freq=2000 is accepted without error. sysctl dev.cpu.0.freq=2667 more often that not results in: dev.cpu.0.freq: 2667 sysctl: dev.cpu.0.freq: Invalid argument dev.est.n.freq_settings (for all values of n) is not as expected at all. Even values of n has 2667/103000 (from the _PSS object in the DSDT, there should be three levels), and odd values of n just has 0. All the est related errors in dmesg indicate that something is not working with Enhanced SpeedStep. Download links for "sysctl dev" and dmesg output after a verbose boot can be found at the end of this message. I'd be grateful if someone could look this over. If a developer needs access to the machine, please email me and I'll see if I can sort something out - it does have a remote management card which simplifies this sort of debugging considerably. The notes below have been prepared with Nate's notes in the handbook in mind - I hope that they're in a helpful format. THE DSDT - AND WHAT I THINK ARE BUGS The output of acpidump -dt is at http://www.wood2.org.uk/freebsd/djwood-Dell_2950_2.2.6.asl I've posted a patch at http://www.wood2.org.uk/freebsd/djwood-Dell_2950_2.2.6.asl.diff that fixes what I'm almost certain are two separate bugs. Firstly, the _CST method for CPU1 says it's returning 3 states when there are only two. This leads to cpu0: invalid _CST state count (3 != 2) at boot if it isn't fixed. Secondly, the reference in CPUs 2-8 for _CST is incorrect. Return (\_PR.CPU0.CST) should be Return (\_PR.CPU1._CST) in each case otherwise you get ACPI Error (psargs-0459): [\\_PR_.CPU0.CST_] Namespace lookup failure, AE_NOT_FOUND when initialising each cpu from cpu1 to cpu7 if it isn't fixed. There's a redundant External (\_PR_.CPU0.CST_, IntObj) left over after fixing the second bug - I've commented it out. I built AML from my patched source with iasl -2f and set /boot/loader.conf to soft load it. Both the errors mentioned no longer occur, though I still can't control the clock frequency of my processor cores. The -f is needed otherwise iasl complaints about reserved names in the TPM part of the DSDT and won't emit any output (I built the latest iasl from the source on the ACPI CA site and got the same results). -2 is because I believe the output of acpidump -dt is ACPI 2.x compatible - if this is incorrect on my part, let me know. These problems only appear when the "Demand-based power management" option is selected in the F2 BIOS setup. Without that option turned on, most of the power management related stuff is omitted from the DSDT. I tried to report these problems to Dell, as they also show under CentOS 5.1 (which is really just a debranded RedHat Enterprise Linux 5.1 - a Dell supported OS for this system), asking that my notes were passed to R&D. I got a worthless response saying that there was little that PowerEdge Linux support could do unless I have a definite hardware fault. Not only was I left wondering why I bothered, I'm somewhat saddened that the buggy BIOS for one of Dell's leading rack mount servers passed software QA in this state. I'd be grateful if someone can confirm these bugs and my fixes. If anyone has a suitable contact at Dell to get these bugs fixed, please pass this message on. LOGS AND SO ON /boot/loader.conf reads: # For MegaCLi mfi_linux_load="YES" # For SMART monitoring mfip_load="YES" # ACPI fixing acpi_dsdt_load="YES" acpi_dsdt_name="/boot/acpi.aml" debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_VERBOSE" debug.cpufreq.verbose="1" dmesg output after verbose boot with those settings (apart from the acpi_dsdt_load line, which is commented) can be found at: http://www.wood2.org.uk/freebsd/djwood-Dell_2950_2.2.6-dmesg.log When the acpi_dsdt_load line is uncommented to soft-load my fixed DSDT, the dmesg output can be found at: http://www.wood2.org.uk/freebsd/djwood-Dell_2950_2.2.6_fixed-dmesg.log sysctl hw.acpi isn't very useful here. The output of sysctl dev with my soft-loaded DSDT can be found at: http://www.wood2.org.uk/freebsd/djwood-Dell_2950_2.2.6_fixed.sysctl.log I think grep -E '(freq|^dev.cpu)' will pull out the salient points, but seeing as it's a file, it may as well contain everything. Best wishes, David -- David Wood david@wood2.org.uk