From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 29 11:01:57 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 636BE16A4CE for ; Mon, 29 Nov 2004 11:01:57 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5048943D48 for ; Mon, 29 Nov 2004 11:01:57 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iATB1v4p007963 for ; Mon, 29 Nov 2004 11:01:57 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iATB1uhl007957 for freebsd-acpi@freebsd.org; Mon, 29 Nov 2004 11:01:56 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 29 Nov 2004 11:01:56 GMT Message-Id: <200411291101.iATB1uhl007957@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 11:01:57 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/07] kern/53008 acpi [PATCH] genwakecode generates errornously o [2003/07/22] i386/54756 acpi ACPI suspend/resume problem on CF-W2 lapt o [2003/08/17] i386/55661 acpi ACPI suspend/resume problem on ARMADA M70 o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/08/27] kern/56024 acpi ACPI suspend drains battery while in S3 o [2003/09/03] i386/56372 acpi acpi don't work on TYAN tiger100 M/B f [2003/09/10] kern/56659 acpi ACPI trouble on IBM ThinkPad X31 f [2003/12/17] i386/60317 acpi FreeBSD 5.2rc1 doesn't boot with ACPI ena o [2004/03/09] i386/64002 acpi acpi problem o [2004/05/27] i386/67273 acpi [hang] system hangs with acpi and Xfree o [2004/10/12] i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Arma 11 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2004/01/22] i386/61703 acpi ACPI + Sound + Boot = Reboot o [2004/03/17] kern/64365 acpi ACPI problems f [2004/05/25] i386/67189 acpi ACPI S3 reboot computer on Dell Latitude o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) f [2004/06/23] i386/68219 acpi ACPI + snd_maestro3 problem o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 6 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 29 19:15:10 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F17316A4CE for ; Mon, 29 Nov 2004 19:15:10 +0000 (GMT) Received: from ylpvm29.prodigy.net (ylpvm29-ext.prodigy.net [207.115.57.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id D96CB43D48 for ; Mon, 29 Nov 2004 19:15:09 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])iATJEtaO008286; Mon, 29 Nov 2004 14:14:55 -0500 Message-ID: <41AB7539.1090305@root.org> Date: Mon, 29 Nov 2004 11:15:05 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20041124232339.E1B605D07@ptavv.es.net> In-Reply-To: <20041124232339.E1B605D07@ptavv.es.net> Content-Type: multipart/mixed; boundary="------------000307060008090406000508" cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 19:15:10 -0000 This is a multi-part message in MIME format. --------------000307060008090406000508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kevin Oberman wrote: > > The new patch removed the annoying "bad Vcc request" messages, but > that's all it improved. With the new patch I still lose cbb1 and > anything connected to it. I see no real difference in the log other than > the disappearance of the Vcc messages, but that is a good thing. > > If I set debug.suspend_power to '0', everything works as it did > before. All PCI and CardBus devices seem to work fine after resume. Ok, I've revved it to only power down type 0 PCI (i.e. normal) devices so it shouldn't touch your cbb bridge. Please try the attached patch. Note that there are now two separate tunables/sysctls to disable powerstates: hw.pci.do_powerstate=1 debug.acpi.do_powerstate=1 This way you can disable PCI and ACPI power separately for debugging. Once things are stabilized, these will go away. -Nate --------------000307060008090406000508 Content-Type: text/plain; name="acpi_pwr.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_pwr.diff" Index: sys/dev/acpica/acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.193 diff -u -r1.193 acpi.c --- sys/dev/acpica/acpi.c 13 Oct 2004 07:29:29 -0000 1.193 +++ sys/dev/acpica/acpi.c 29 Nov 2004 19:13:26 -0000 @@ -59,6 +59,10 @@ #include #include +#include "pci_if.h" +#include +#include + MALLOC_DEFINE(M_ACPIDEV, "acpidev", "ACPI devices"); /* Hooks for the ACPI CA debugging infrastructure */ @@ -87,10 +91,13 @@ static void acpi_identify(driver_t *driver, device_t parent); static int acpi_probe(device_t dev); static int acpi_attach(device_t dev); +static int acpi_suspend(device_t dev); +static int acpi_resume(device_t dev); static int acpi_shutdown(device_t dev); static device_t acpi_add_child(device_t bus, int order, const char *name, int unit); static int acpi_print_child(device_t bus, device_t child); +static void acpi_probe_nomatch(device_t bus, device_t child); static int acpi_read_ivar(device_t dev, device_t child, int index, uintptr_t *result); static int acpi_write_ivar(device_t dev, device_t child, int index, @@ -110,10 +117,14 @@ static ACPI_STATUS acpi_device_eval_obj(device_t bus, device_t dev, ACPI_STRING pathname, ACPI_OBJECT_LIST *parameters, ACPI_BUFFER *ret); +static int acpi_device_pwr_for_sleep(device_t bus, device_t dev, + int *dstate); static ACPI_STATUS acpi_device_scan_cb(ACPI_HANDLE h, UINT32 level, void *context, void **retval); static ACPI_STATUS acpi_device_scan_children(device_t bus, device_t dev, int max_depth, acpi_scan_cb_t user_fn, void *arg); +static int acpi_set_powerstate_method(device_t bus, device_t child, + int state); static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids); static void acpi_probe_children(device_t bus); @@ -145,12 +156,13 @@ DEVMETHOD(device_attach, acpi_attach), DEVMETHOD(device_shutdown, acpi_shutdown), DEVMETHOD(device_detach, bus_generic_detach), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_suspend, acpi_suspend), + DEVMETHOD(device_resume, acpi_resume), /* Bus interface */ DEVMETHOD(bus_add_child, acpi_add_child), DEVMETHOD(bus_print_child, acpi_print_child), + DEVMETHOD(bus_probe_nomatch, acpi_probe_nomatch), DEVMETHOD(bus_read_ivar, acpi_read_ivar), DEVMETHOD(bus_write_ivar, acpi_write_ivar), DEVMETHOD(bus_get_resource_list, acpi_get_rlist), @@ -169,8 +181,12 @@ /* ACPI bus */ DEVMETHOD(acpi_id_probe, acpi_device_id_probe), DEVMETHOD(acpi_evaluate_object, acpi_device_eval_obj), + DEVMETHOD(acpi_pwr_for_sleep, acpi_device_pwr_for_sleep), DEVMETHOD(acpi_scan_children, acpi_device_scan_children), + /* PCI emulation */ + DEVMETHOD(pci_set_powerstate, acpi_set_powerstate_method), + /* ISA emulation */ DEVMETHOD(isa_pnp_probe, acpi_isa_pnp_probe), @@ -212,6 +228,12 @@ static int acpi_serialize_methods; TUNABLE_INT("hw.acpi.serialize_methods", &acpi_serialize_methods); +/* Power devices off and on in suspend and resume. XXX Remove once tested. */ +static int acpi_do_powerstate = 1; +TUNABLE_INT("debug.acpi.do_powerstate", &acpi_do_powerstate); +SYSCTL_INT(_debug_acpi, OID_AUTO, do_powerstate, CTLFLAG_RW, + &acpi_do_powerstate, 1, "Turn off devices when suspending."); + /* * ACPI can only be loaded as a module by the loader; activating it after * system bootstrap time is not useful, and can be fatal to the system. @@ -570,6 +592,72 @@ } static int +acpi_suspend(device_t dev) +{ + struct acpi_softc *sc; + device_t child, *devlist; + int error, i, numdevs, pstate; + + /* First give child devices a chance to suspend. */ + error = bus_generic_suspend(dev); + if (error) + return (error); + + /* + * Now, set them into the appropriate power state, usually D3. If the + * device has an _SxD method for the next sleep state, use that power + * state instead. + */ + sc = device_get_softc(dev); + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + /* If the device is not attached, we've powered it down elsewhere. */ + child = devlist[i]; + if (!device_is_attached(child)) + continue; + + /* + * Default to D3 for all sleep states. The _SxD method is optional + * so set the powerstate even if it's absent. + */ + pstate = PCI_POWERSTATE_D3; + error = acpi_device_pwr_for_sleep(device_get_parent(child), + child, &pstate); + if ((error == 0 || error == ESRCH) && acpi_do_powerstate) + pci_set_powerstate(child, pstate); + } + free(devlist, M_TEMP); + error = 0; + + return (error); +} + +static int +acpi_resume(device_t dev) +{ + ACPI_HANDLE handle; + int i, numdevs; + device_t child, *devlist; + + /* + * Put all devices in D0 before resuming them. Call _S0D on each one + * since some systems expect this. + */ + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + child = devlist[i]; + handle = acpi_get_handle(child); + if (handle) + AcpiEvaluateObject(handle, "_S0D", NULL, NULL); + if (device_is_attached(child) && acpi_do_powerstate) + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + free(devlist, M_TEMP); + + return (bus_generic_resume(dev)); +} + +static int acpi_shutdown(device_t dev) { @@ -624,6 +712,23 @@ return (retval); } +static void +acpi_probe_nomatch(device_t bus, device_t child) +{ + + /* + * If this device is an ACPI child but no one claimed it, attempt + * to power it off. We'll power it back up when a driver is added. + * + * XXX Disabled for now since many necessary devices (like fdc and + * ATA) don't claim the devices we created for them but still expect + * them to be powered up. + */ +#if 0 + pci_set_powerstate(child, PCI_POWERSTATE_D3); +#endif +} + /* Location hint for devctl(8) */ static int acpi_child_location_str_method(device_t cbdev, device_t child, char *buf, @@ -1064,6 +1169,57 @@ return (AcpiEvaluateObject(h, pathname, parameters, ret)); } +static int +acpi_device_pwr_for_sleep(device_t bus, device_t dev, int *dstate) +{ + struct acpi_softc *sc; + ACPI_HANDLE handle; + ACPI_STATUS status; + char sxd[8]; + int error; + + sc = device_get_softc(bus); + handle = acpi_get_handle(dev); + + /* + * XXX If we find these devices, don't try to power them down. + * The serial and IRDA ports on my T23 hang the system when + * set to D3 and it appears that such legacy devices may + * need special handling in their drivers. + */ + if (handle == NULL || + acpi_MatchHid(handle, "PNP0500") || + acpi_MatchHid(handle, "PNP0501") || + acpi_MatchHid(handle, "PNP0502") || + acpi_MatchHid(handle, "PNP0510") || + acpi_MatchHid(handle, "PNP0511")) + return (ENXIO); + + /* + * Override next state with the value from _SxD, if present. If no + * dstate argument was provided, don't fetch the return value. + */ + snprintf(sxd, sizeof(sxd), "_S%dD", sc->acpi_sstate); + if (dstate) + status = acpi_GetInteger(handle, sxd, dstate); + else + status = AcpiEvaluateObject(handle, sxd, NULL, NULL); + + switch (status) { + case AE_OK: + error = 0; + break; + case AE_NOT_FOUND: + error = ESRCH; + break; + default: + error = ENXIO; + break; + } + + return (error); +} + /* Callback arg for our implementation of walking the namespace. */ struct acpi_device_scan_ctx { acpi_scan_cb_t user_fn; @@ -1138,6 +1294,34 @@ acpi_device_scan_cb, &ctx, NULL)); } +/* + * Even though ACPI devices are not PCI, we use the PCI approach for setting + * device power states since it's close enough to ACPI. + */ +static int +acpi_set_powerstate_method(device_t bus, device_t child, int state) +{ + ACPI_HANDLE h; + ACPI_STATUS status; + int error; + + error = 0; + h = acpi_get_handle(child); + if (state < ACPI_STATE_D0 || state > ACPI_STATE_D3) + return (EINVAL); + if (h == NULL) + return (0); + + /* Ignore errors if the power methods aren't present. */ + status = acpi_pwr_switch_consumer(h, state); + if (ACPI_FAILURE(status) && status != AE_NOT_FOUND + && status != AE_BAD_PARAMETER) + device_printf(bus, "failed to set ACPI power state D%d on %s: %s\n", + state, acpi_name(h), AcpiFormatException(status)); + + return (error); +} + static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids) { Index: sys/dev/pci/pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.268 diff -u -r1.268 pci.c --- sys/dev/pci/pci.c 10 Nov 2004 00:41:39 -0000 1.268 +++ sys/dev/pci/pci.c 29 Nov 2004 18:46:49 -0000 @@ -60,6 +60,10 @@ #include "pcib_if.h" #include "pci_if.h" +#include +#include +#include "acpi_if.h" + static uint32_t pci_mapbase(unsigned mapreg); static int pci_maptype(unsigned mapreg); static int pci_mapsize(unsigned testval); @@ -169,7 +173,7 @@ SYSCTL_NODE(_hw, OID_AUTO, pci, CTLFLAG_RD, 0, "PCI bus tuning parameters"); static int pci_enable_io_modes = 1; -TUNABLE_INT("hw.pci.enable_io_modes", (int *)&pci_enable_io_modes); +TUNABLE_INT("hw.pci.enable_io_modes", &pci_enable_io_modes); SYSCTL_INT(_hw_pci, OID_AUTO, enable_io_modes, CTLFLAG_RW, &pci_enable_io_modes, 1, "Enable I/O and memory bits in the config register. Some BIOSes do not\n\ @@ -177,7 +181,7 @@ are some peripherals that this causes problems with."); static int pci_do_powerstate = 1; -TUNABLE_INT("hw.pci.do_powerstate", (int *)&pci_do_powerstate); +TUNABLE_INT("hw.pci.do_powerstate", &pci_do_powerstate); SYSCTL_INT(_hw_pci, OID_AUTO, do_powerstate, CTLFLAG_RW, &pci_do_powerstate, 1, "Power down devices into D3 state when no driver attaches to them.\n\ @@ -1016,43 +1020,78 @@ int pci_suspend(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int dstate, error, i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Save the pci configuration space for each child. We don't need - * to do this, unless the BIOS suspend code powers down the bus and - * the devices on the bus. + * Save the PCI configuration space for each child and set the + * device in the appropriate power state for this sleep state. */ + acpi_dev = NULL; + if (pci_do_powerstate) + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { child = devlist[i]; dinfo = (struct pci_devinfo *) device_get_ivars(child); pci_cfg_save(child, dinfo, 0); } + + /* Suspend devices before potentially powering them down. */ + error = bus_generic_suspend(dev); + if (error) + return (error); + + /* + * Always set the device to D3. If ACPI suggests a different + * power state, use it instead. If ACPI is not present, the + * firmware is responsible for managing device power. Skip + * children who aren't attached since they are powered down + * separately. Only manage type 0 devices for now. + */ + for (i = 0; acpi_dev && i < numdevs; i++) { + child = devlist[i]; + dinfo = (struct pci_devinfo *) device_get_ivars(child); + if (device_is_attached(child) && dinfo->cfg.hdrtype == 0) { + dstate = PCI_POWERSTATE_D3; + ACPI_PWR_FOR_SLEEP(acpi_dev, child, &dstate); + pci_set_powerstate(child, dstate); + } + } free(devlist, M_TEMP); - return (bus_generic_suspend(dev)); + return (0); } int pci_resume(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Restore the pci configuration space for each child. + * Set each child to D0 and restore its PCI configuration space. */ + acpi_dev = NULL; + if (pci_do_powerstate) + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { + /* + * Notify ACPI we're going to D0 but ignore the result. If + * ACPI is not present, the firmware is responsible for + * managing device power. Only manage type 0 devices for now. + */ child = devlist[i]; dinfo = (struct pci_devinfo *) device_get_ivars(child); + if (acpi_dev && device_is_attached(child) && + dinfo->cfg.hdrtype == 0) { + ACPI_PWR_FOR_SLEEP(acpi_dev, child, NULL); + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + + /* Now the device is powered up, restore its config space. */ pci_cfg_restore(child, dinfo); } free(devlist, M_TEMP); --------------000307060008090406000508-- From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 29 22:16:55 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BF9F16A4CE for ; Mon, 29 Nov 2004 22:16:55 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCACA43D31 for ; Mon, 29 Nov 2004 22:16:54 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 29 Nov 2004 14:16:54 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 2CF815D04; Mon, 29 Nov 2004 14:16:54 -0800 (PST) To: Nate Lawson In-reply-to: Your message of "Mon, 29 Nov 2004 11:15:05 PST." <41AB7539.1090305@root.org> Date: Mon, 29 Nov 2004 14:16:54 -0800 From: "Kevin Oberman" Message-Id: <20041129221654.2CF815D04@ptavv.es.net> cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 22:16:55 -0000 > Date: Mon, 29 Nov 2004 11:15:05 -0800 > From: Nate Lawson > > Kevin Oberman wrote: > > > > The new patch removed the annoying "bad Vcc request" messages, but > > that's all it improved. With the new patch I still lose cbb1 and > > anything connected to it. I see no real difference in the log other than > > the disappearance of the Vcc messages, but that is a good thing. > > > > If I set debug.suspend_power to '0', everything works as it did > > before. All PCI and CardBus devices seem to work fine after resume. > > Ok, I've revved it to only power down type 0 PCI (i.e. normal) devices > so it shouldn't touch your cbb bridge. Please try the attached patch. > Note that there are now two separate tunables/sysctls to disable > powerstates: > > hw.pci.do_powerstate=1 > debug.acpi.do_powerstate=1 > > This way you can disable PCI and ACPI power separately for debugging. > Once things are stabilized, these will go away. Nate, I tried to patch STABLE with this and the third patch for pci.c failed. I don't see why. Maybe whitespace? In any case, I did that one by hand, but I could not compile a kernel. cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/pci/pci.c /usr/src/sys/dev/pci/pci.c: In function `pci_suspend': /usr/src/sys/dev/pci/pci.c:1057: warning: implicit declaration of function `ACPI_PWR_FOR_SLEEP' /usr/src/sys/dev/pci/pci.c:1057: warning: nested extern declaration of `ACPI_PWR_FOR_SLEEP' /usr/src/sys/dev/pci/pci.c: In function `pci_resume': /usr/src/sys/dev/pci/pci.c:1089: warning: nested extern declaration of `ACPI_PWR_FOR_SLEEP' /usr/src/sys/dev/pci/pci.c:1057: warning: redundant redeclaration of 'ACPI_PWR_FOR_SLEEP' /usr/src/sys/dev/pci/pci.c:1057: warning: previous implicit declaration of 'ACPI_PWR_FOR_SLEEP' was here *** Error code 1 Perhaps I should note that I have been setting hw.pci.do_powerstate to 1 for many months. All sources are RELENG_5 as of noon today PST. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 29 22:19:02 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBA6116A4CE for ; Mon, 29 Nov 2004 22:19:02 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6058C43D67 for ; Mon, 29 Nov 2004 22:19:02 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iATMIrC4031927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Nov 2004 14:18:53 -0800 Message-ID: <41ABA04C.7020207@root.org> Date: Mon, 29 Nov 2004 14:18:52 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20041129221654.2CF815D04@ptavv.es.net> In-Reply-To: <20041129221654.2CF815D04@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2004 22:19:02 -0000 Kevin Oberman wrote: >>Date: Mon, 29 Nov 2004 11:15:05 -0800 >>From: Nate Lawson >> >>Kevin Oberman wrote: >> >>>The new patch removed the annoying "bad Vcc request" messages, but >>>that's all it improved. With the new patch I still lose cbb1 and >>>anything connected to it. I see no real difference in the log other than >>>the disappearance of the Vcc messages, but that is a good thing. >>> >>>If I set debug.suspend_power to '0', everything works as it did >>>before. All PCI and CardBus devices seem to work fine after resume. >> >>Ok, I've revved it to only power down type 0 PCI (i.e. normal) devices >>so it shouldn't touch your cbb bridge. Please try the attached patch. >>Note that there are now two separate tunables/sysctls to disable >>powerstates: >> >>hw.pci.do_powerstate=1 >>debug.acpi.do_powerstate=1 >> >>This way you can disable PCI and ACPI power separately for debugging. >>Once things are stabilized, these will go away. > > > Nate, > > I tried to patch STABLE with this and the third patch for pci.c > failed. I don't see why. Maybe whitespace? In any case, I did that one > by hand, but I could not compile a kernel. > > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/pci/pci.c > /usr/src/sys/dev/pci/pci.c: In function `pci_suspend': > /usr/src/sys/dev/pci/pci.c:1057: warning: implicit declaration of function `ACPI_PWR_FOR_SLEEP' > /usr/src/sys/dev/pci/pci.c:1057: warning: nested extern declaration of `ACPI_PWR_FOR_SLEEP' > /usr/src/sys/dev/pci/pci.c: In function `pci_resume': > /usr/src/sys/dev/pci/pci.c:1089: warning: nested extern declaration of `ACPI_PWR_FOR_SLEEP' > /usr/src/sys/dev/pci/pci.c:1057: warning: redundant redeclaration of 'ACPI_PWR_FOR_SLEEP' > /usr/src/sys/dev/pci/pci.c:1057: warning: previous implicit declaration of 'ACPI_PWR_FOR_SLEEP' was here > *** Error code 1 I think I neglected to include the acpi_if.m patch this time. You can manually add that from the previous versions of the diff. > Perhaps I should note that I have been setting hw.pci.do_powerstate to 1 > for many months. The change is that I've overloaded that option to also control PCI suspend power, not just power for unattached devices. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 30 03:02:37 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E59C16A4CE for ; Tue, 30 Nov 2004 03:02:37 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99F9143D66 for ; Tue, 30 Nov 2004 03:02:36 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-185.dsl.snfc21.pacbell.net [64.171.186.185])iAU32XHr017254; Mon, 29 Nov 2004 22:02:34 -0500 Message-ID: <41ABE20E.7020407@root.org> Date: Mon, 29 Nov 2004 18:59:26 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20041124232339.E1B605D07@ptavv.es.net> In-Reply-To: <20041124232339.E1B605D07@ptavv.es.net> Content-Type: multipart/mixed; boundary="------------010102000808000603040105" cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 03:02:37 -0000 This is a multi-part message in MIME format. --------------010102000808000603040105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kevin Oberman wrote: > > The new patch removed the annoying "bad Vcc request" messages, but > that's all it improved. With the new patch I still lose cbb1 and > anything connected to it. I see no real difference in the log other than > the disappearance of the Vcc messages, but that is a good thing. > > If I set debug.suspend_power to '0', everything works as it did > before. All PCI and CardBus devices seem to work fine after resume. Here's another version of the patch including the acpi_if.m changes, sorry for leaving them out. -Nate --------------010102000808000603040105 Content-Type: text/plain; name="acpi_pwr.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="acpi_pwr.diff" Index: sys/dev/acpica/acpi.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.193 diff -u -r1.193 acpi.c --- sys/dev/acpica/acpi.c 13 Oct 2004 07:29:29 -0000 1.193 +++ sys/dev/acpica/acpi.c 30 Nov 2004 02:56:51 -0000 @@ -59,6 +59,10 @@ #include #include +#include "pci_if.h" +#include +#include + MALLOC_DEFINE(M_ACPIDEV, "acpidev", "ACPI devices"); /* Hooks for the ACPI CA debugging infrastructure */ @@ -87,10 +91,14 @@ static void acpi_identify(driver_t *driver, device_t parent); static int acpi_probe(device_t dev); static int acpi_attach(device_t dev); +static int acpi_suspend(device_t dev); +static int acpi_resume(device_t dev); static int acpi_shutdown(device_t dev); static device_t acpi_add_child(device_t bus, int order, const char *name, int unit); static int acpi_print_child(device_t bus, device_t child); +static void acpi_probe_nomatch(device_t bus, device_t child); +static void acpi_driver_added(device_t dev, driver_t *driver); static int acpi_read_ivar(device_t dev, device_t child, int index, uintptr_t *result); static int acpi_write_ivar(device_t dev, device_t child, int index, @@ -110,10 +118,14 @@ static ACPI_STATUS acpi_device_eval_obj(device_t bus, device_t dev, ACPI_STRING pathname, ACPI_OBJECT_LIST *parameters, ACPI_BUFFER *ret); +static int acpi_device_pwr_for_sleep(device_t bus, device_t dev, + int *dstate); static ACPI_STATUS acpi_device_scan_cb(ACPI_HANDLE h, UINT32 level, void *context, void **retval); static ACPI_STATUS acpi_device_scan_children(device_t bus, device_t dev, int max_depth, acpi_scan_cb_t user_fn, void *arg); +static int acpi_set_powerstate_method(device_t bus, device_t child, + int state); static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids); static void acpi_probe_children(device_t bus); @@ -145,12 +157,14 @@ DEVMETHOD(device_attach, acpi_attach), DEVMETHOD(device_shutdown, acpi_shutdown), DEVMETHOD(device_detach, bus_generic_detach), - DEVMETHOD(device_suspend, bus_generic_suspend), - DEVMETHOD(device_resume, bus_generic_resume), + DEVMETHOD(device_suspend, acpi_suspend), + DEVMETHOD(device_resume, acpi_resume), /* Bus interface */ DEVMETHOD(bus_add_child, acpi_add_child), DEVMETHOD(bus_print_child, acpi_print_child), + DEVMETHOD(bus_probe_nomatch, acpi_probe_nomatch), + DEVMETHOD(bus_driver_added, acpi_driver_added), DEVMETHOD(bus_read_ivar, acpi_read_ivar), DEVMETHOD(bus_write_ivar, acpi_write_ivar), DEVMETHOD(bus_get_resource_list, acpi_get_rlist), @@ -160,7 +174,6 @@ DEVMETHOD(bus_release_resource, acpi_release_resource), DEVMETHOD(bus_child_pnpinfo_str, acpi_child_pnpinfo_str_method), DEVMETHOD(bus_child_location_str, acpi_child_location_str_method), - DEVMETHOD(bus_driver_added, bus_generic_driver_added), DEVMETHOD(bus_activate_resource, bus_generic_activate_resource), DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource), DEVMETHOD(bus_setup_intr, bus_generic_setup_intr), @@ -169,8 +182,12 @@ /* ACPI bus */ DEVMETHOD(acpi_id_probe, acpi_device_id_probe), DEVMETHOD(acpi_evaluate_object, acpi_device_eval_obj), + DEVMETHOD(acpi_pwr_for_sleep, acpi_device_pwr_for_sleep), DEVMETHOD(acpi_scan_children, acpi_device_scan_children), + /* PCI emulation */ + DEVMETHOD(pci_set_powerstate, acpi_set_powerstate_method), + /* ISA emulation */ DEVMETHOD(isa_pnp_probe, acpi_isa_pnp_probe), @@ -212,6 +229,12 @@ static int acpi_serialize_methods; TUNABLE_INT("hw.acpi.serialize_methods", &acpi_serialize_methods); +/* Power devices off and on in suspend and resume. XXX Remove once tested. */ +static int acpi_do_powerstate = 1; +TUNABLE_INT("debug.acpi.do_powerstate", &acpi_do_powerstate); +SYSCTL_INT(_debug_acpi, OID_AUTO, do_powerstate, CTLFLAG_RW, + &acpi_do_powerstate, 1, "Turn off devices when suspending."); + /* * ACPI can only be loaded as a module by the loader; activating it after * system bootstrap time is not useful, and can be fatal to the system. @@ -570,6 +593,72 @@ } static int +acpi_suspend(device_t dev) +{ + struct acpi_softc *sc; + device_t child, *devlist; + int error, i, numdevs, pstate; + + /* First give child devices a chance to suspend. */ + error = bus_generic_suspend(dev); + if (error) + return (error); + + /* + * Now, set them into the appropriate power state, usually D3. If the + * device has an _SxD method for the next sleep state, use that power + * state instead. + */ + sc = device_get_softc(dev); + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + /* If the device is not attached, we've powered it down elsewhere. */ + child = devlist[i]; + if (!device_is_attached(child)) + continue; + + /* + * Default to D3 for all sleep states. The _SxD method is optional + * so set the powerstate even if it's absent. + */ + pstate = PCI_POWERSTATE_D3; + error = acpi_device_pwr_for_sleep(device_get_parent(child), + child, &pstate); + if ((error == 0 || error == ESRCH) && acpi_do_powerstate) + pci_set_powerstate(child, pstate); + } + free(devlist, M_TEMP); + error = 0; + + return (error); +} + +static int +acpi_resume(device_t dev) +{ + ACPI_HANDLE handle; + int i, numdevs; + device_t child, *devlist; + + /* + * Put all devices in D0 before resuming them. Call _S0D on each one + * since some systems expect this. + */ + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + child = devlist[i]; + handle = acpi_get_handle(child); + if (handle) + AcpiEvaluateObject(handle, "_S0D", NULL, NULL); + if (device_is_attached(child) && acpi_do_powerstate) + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + free(devlist, M_TEMP); + + return (bus_generic_resume(dev)); +} + +static int acpi_shutdown(device_t dev) { @@ -624,6 +713,45 @@ return (retval); } +/* + * If this device is an ACPI child but no one claimed it, attempt + * to power it off. We'll power it back up when a driver is added. + * + * XXX Disabled for now since many necessary devices (like fdc and + * ATA) don't claim the devices we created for them but still expect + * them to be powered up. + */ +static void +acpi_probe_nomatch(device_t bus, device_t child) +{ + + /* pci_set_powerstate(child, PCI_POWERSTATE_D3); */ +} + +/* + * If a new driver has a chance to probe a child, first power it up. + * + * XXX Disabled for now (see acpi_probe_nomatch for details). + */ +static void +acpi_driver_added(device_t dev, driver_t *driver) +{ + device_t child, *devlist; + int i, numdevs; + + DEVICE_IDENTIFY(driver, dev); + device_get_children(dev, &devlist, &numdevs); + for (i = 0; i < numdevs; i++) { + child = devlist[i]; + if (device_get_state(child) == DS_NOTPRESENT) { + /* pci_set_powerstate(child, PCI_POWERSTATE_D0); */ + if (device_probe_and_attach(child) != 0) + ; /* pci_set_powerstate(child, PCI_POWERSTATE_D3); */ + } + } + free(devlist, M_TEMP); +} + /* Location hint for devctl(8) */ static int acpi_child_location_str_method(device_t cbdev, device_t child, char *buf, @@ -1064,6 +1192,57 @@ return (AcpiEvaluateObject(h, pathname, parameters, ret)); } +static int +acpi_device_pwr_for_sleep(device_t bus, device_t dev, int *dstate) +{ + struct acpi_softc *sc; + ACPI_HANDLE handle; + ACPI_STATUS status; + char sxd[8]; + int error; + + sc = device_get_softc(bus); + handle = acpi_get_handle(dev); + + /* + * XXX If we find these devices, don't try to power them down. + * The serial and IRDA ports on my T23 hang the system when + * set to D3 and it appears that such legacy devices may + * need special handling in their drivers. + */ + if (handle == NULL || + acpi_MatchHid(handle, "PNP0500") || + acpi_MatchHid(handle, "PNP0501") || + acpi_MatchHid(handle, "PNP0502") || + acpi_MatchHid(handle, "PNP0510") || + acpi_MatchHid(handle, "PNP0511")) + return (ENXIO); + + /* + * Override next state with the value from _SxD, if present. If no + * dstate argument was provided, don't fetch the return value. + */ + snprintf(sxd, sizeof(sxd), "_S%dD", sc->acpi_sstate); + if (dstate) + status = acpi_GetInteger(handle, sxd, dstate); + else + status = AcpiEvaluateObject(handle, sxd, NULL, NULL); + + switch (status) { + case AE_OK: + error = 0; + break; + case AE_NOT_FOUND: + error = ESRCH; + break; + default: + error = ENXIO; + break; + } + + return (error); +} + /* Callback arg for our implementation of walking the namespace. */ struct acpi_device_scan_ctx { acpi_scan_cb_t user_fn; @@ -1138,6 +1317,34 @@ acpi_device_scan_cb, &ctx, NULL)); } +/* + * Even though ACPI devices are not PCI, we use the PCI approach for setting + * device power states since it's close enough to ACPI. + */ +static int +acpi_set_powerstate_method(device_t bus, device_t child, int state) +{ + ACPI_HANDLE h; + ACPI_STATUS status; + int error; + + error = 0; + h = acpi_get_handle(child); + if (state < ACPI_STATE_D0 || state > ACPI_STATE_D3) + return (EINVAL); + if (h == NULL) + return (0); + + /* Ignore errors if the power methods aren't present. */ + status = acpi_pwr_switch_consumer(h, state); + if (ACPI_FAILURE(status) && status != AE_NOT_FOUND + && status != AE_BAD_PARAMETER) + device_printf(bus, "failed to set ACPI power state D%d on %s: %s\n", + state, acpi_name(h), AcpiFormatException(status)); + + return (error); +} + static int acpi_isa_pnp_probe(device_t bus, device_t child, struct isa_pnp_id *ids) { Index: sys/dev/acpica/acpi_if.m =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_if.m,v retrieving revision 1.2 diff -u -r1.2 acpi_if.m --- sys/dev/acpica/acpi_if.m 15 Jul 2004 16:29:08 -0000 1.2 +++ sys/dev/acpica/acpi_if.m 20 Nov 2004 03:12:35 -0000 @@ -109,6 +109,26 @@ }; # +# Get the highest power state (D0-D3) that is usable for a device when +# suspending/resuming. If a bus calls this when suspending a device, it +# must also call it when resuming. +# +# device_t bus: parent bus for the device +# +# device_t dev: check this device's appropriate power state +# +# int *dstate: if successful, contains the highest valid sleep state +# +# Returns: 0 on success, ESRCH if device has no special state, or +# some other error value. +# +METHOD int pwr_for_sleep { + device_t bus; + device_t dev; + int *dstate; +}; + +# # Rescan a subtree and optionally reattach devices to handles. Users # specify a callback that is called for each ACPI_HANDLE of type Device # that is a child of "dev". Index: sys/dev/pci/pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.268 diff -u -r1.268 pci.c --- sys/dev/pci/pci.c 10 Nov 2004 00:41:39 -0000 1.268 +++ sys/dev/pci/pci.c 29 Nov 2004 18:46:49 -0000 @@ -60,6 +60,10 @@ #include "pcib_if.h" #include "pci_if.h" +#include +#include +#include "acpi_if.h" + static uint32_t pci_mapbase(unsigned mapreg); static int pci_maptype(unsigned mapreg); static int pci_mapsize(unsigned testval); @@ -169,7 +173,7 @@ SYSCTL_NODE(_hw, OID_AUTO, pci, CTLFLAG_RD, 0, "PCI bus tuning parameters"); static int pci_enable_io_modes = 1; -TUNABLE_INT("hw.pci.enable_io_modes", (int *)&pci_enable_io_modes); +TUNABLE_INT("hw.pci.enable_io_modes", &pci_enable_io_modes); SYSCTL_INT(_hw_pci, OID_AUTO, enable_io_modes, CTLFLAG_RW, &pci_enable_io_modes, 1, "Enable I/O and memory bits in the config register. Some BIOSes do not\n\ @@ -177,7 +181,7 @@ are some peripherals that this causes problems with."); static int pci_do_powerstate = 1; -TUNABLE_INT("hw.pci.do_powerstate", (int *)&pci_do_powerstate); +TUNABLE_INT("hw.pci.do_powerstate", &pci_do_powerstate); SYSCTL_INT(_hw_pci, OID_AUTO, do_powerstate, CTLFLAG_RW, &pci_do_powerstate, 1, "Power down devices into D3 state when no driver attaches to them.\n\ @@ -1016,43 +1020,78 @@ int pci_suspend(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int dstate, error, i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Save the pci configuration space for each child. We don't need - * to do this, unless the BIOS suspend code powers down the bus and - * the devices on the bus. + * Save the PCI configuration space for each child and set the + * device in the appropriate power state for this sleep state. */ + acpi_dev = NULL; + if (pci_do_powerstate) + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { child = devlist[i]; dinfo = (struct pci_devinfo *) device_get_ivars(child); pci_cfg_save(child, dinfo, 0); } + + /* Suspend devices before potentially powering them down. */ + error = bus_generic_suspend(dev); + if (error) + return (error); + + /* + * Always set the device to D3. If ACPI suggests a different + * power state, use it instead. If ACPI is not present, the + * firmware is responsible for managing device power. Skip + * children who aren't attached since they are powered down + * separately. Only manage type 0 devices for now. + */ + for (i = 0; acpi_dev && i < numdevs; i++) { + child = devlist[i]; + dinfo = (struct pci_devinfo *) device_get_ivars(child); + if (device_is_attached(child) && dinfo->cfg.hdrtype == 0) { + dstate = PCI_POWERSTATE_D3; + ACPI_PWR_FOR_SLEEP(acpi_dev, child, &dstate); + pci_set_powerstate(child, dstate); + } + } free(devlist, M_TEMP); - return (bus_generic_suspend(dev)); + return (0); } int pci_resume(device_t dev) { - int numdevs; - device_t *devlist; - device_t child; + int i, numdevs; + device_t acpi_dev, child, *devlist; struct pci_devinfo *dinfo; - int i; /* - * Restore the pci configuration space for each child. + * Set each child to D0 and restore its PCI configuration space. */ + acpi_dev = NULL; + if (pci_do_powerstate) + acpi_dev = devclass_get_device(devclass_find("acpi"), 0); device_get_children(dev, &devlist, &numdevs); for (i = 0; i < numdevs; i++) { + /* + * Notify ACPI we're going to D0 but ignore the result. If + * ACPI is not present, the firmware is responsible for + * managing device power. Only manage type 0 devices for now. + */ child = devlist[i]; dinfo = (struct pci_devinfo *) device_get_ivars(child); + if (acpi_dev && device_is_attached(child) && + dinfo->cfg.hdrtype == 0) { + ACPI_PWR_FOR_SLEEP(acpi_dev, child, NULL); + pci_set_powerstate(child, PCI_POWERSTATE_D0); + } + + /* Now the device is powered up, restore its config space. */ pci_cfg_restore(child, dinfo); } free(devlist, M_TEMP); --------------010102000808000603040105-- From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 30 08:53:45 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 932E616A518 for ; Tue, 30 Nov 2004 08:53:45 +0000 (GMT) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id E888743D55 for ; Tue, 30 Nov 2004 08:53:44 +0000 (GMT) (envelope-from espent@totem.fix.no) Received: from localhost (totem.fix.no [80.91.36.20]) by totem.fix.no (Postfix) with ESMTP id 3DB7A5F382F for ; Tue, 30 Nov 2004 09:53:44 +0100 (CET) Received: from totem.fix.no ([80.91.36.20]) by localhost (totem.fix.no [80.91.36.20]) (amavisd-new, port 10024) with LMTP id 77562-01 for ; Tue, 30 Nov 2004 09:53:40 +0100 (CET) Received: by totem.fix.no (Postfix, from userid 1032) id D15715F3828; Tue, 30 Nov 2004 09:53:40 +0100 (CET) Date: Tue, 30 Nov 2004 09:53:40 +0100 From: Espen Tagestad To: freebsd-acpi@freebsd.org Message-ID: <20041130085340.GA76915@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: ACPI differences 4.10 - 5.3, laptop problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 08:53:45 -0000 Hi, I have run FreeBSD 4 on my laptop for a couple of years know, and as ACPI was included in 4.9 (or was it 4.10) I was quite satisfied with the situation. Now, I've upgraded to 5.3 on ACPI is no longer working. With acpi enabled, the laptop starts but after 10-15 seconds it stops and won't respond to anything. Currently it runs without ACPI with the thermal coolers on full speed. It's irritating, and it'll probably eat up the batteries much faster than running with ACPI. * Is there any tunable options to get ACPI working? * What is the differences with ACPI on FreeBSD 4 vs 5? * Can I run FreeBSD 4-ACPI on FreeBSD 5? My laptop is a Acer Travelmate 630-series. dmesg out is as follows (with ACPI disabled): Copyright (c) 1992-2004 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 5.3-STABLE #1: Sun Nov 28 15:59:56 UTC 2004 root@:/usr/obj/usr/src/sys/LEFSE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz (1560.22-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febf9ff real memory = 535756800 (510 MB) avail memory = 518795264 (494 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: mem 0xf0000000-0xf7ffffff at device 0.0 o n pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 6.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 8.0 (no driver attached) rl0: port 0x2000-0x20ff mem 0xe0002000-0xe00020ff ir q 11 at device 10.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:00:e2:8d:6b:51 pci0: at device 11.0 (no driver attached) cbb0: at device 12.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 ohci0: mem 0xe0003000-0xe0003fff irq 11 at device 15.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered atapci0: port 0x2480-0x248f,0x376,0x170-0x 177,0x3f6,0x1f0-0x1f7 at device 16.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 17.0 (no driver attached) cbb1: at device 19.0 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb2: at device 19.1 on pci0 cardbus2: on cbb2 pccard2: <16-bit PCCard bus> on cbb2 ohci1: mem 0xe0004000-0xe0004fff irq 11 at device 20.0 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered cpu0 on motherboard orm0: at iomem 0xdc000-0xdffff,0xd8000-0xdbfff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (memory) fdc1: cannot allocate I/O port (6 ports) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) Timecounter "TSC" frequency 1560224664 Hz quality 800 Timecounters tick every 10.000 msec IP Filter: v3.4.35 initialized. Default = block all, Logging = enabled ata0-master: DMA limited to UDMA33, non-ATA66 cable or device ad0: 28615MB [58140/16/63] at ata0-master UDMA33 acd0: DVDROM at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s2a wi0: at port 0x100-0x13f irq 10 function 0 co nfig 1 on pccard0 wi0: using Lucent Embedded WaveLAN/IEEE wi0: Lucent Firmware: Station (6.16.1) wi0: Ethernet address: 00:02:2d:6e:72:fc wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps pccard2: (manufacturer=0xffff, product=0x0001) at function 0 pccard2: CIS info: O2Micro, SmartCardBus Reader, V1.0 Thanks for all advices! reagards, Espen Tagestad From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 30 17:53:34 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D30B416A4CE for ; Tue, 30 Nov 2004 17:53:34 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48FA843D45 for ; Tue, 30 Nov 2004 17:53:34 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 6942 invoked from network); 30 Nov 2004 17:53:33 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 30 Nov 2004 17:53:32 -0000 Received: from qa4379.itdev.weather.com (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iAUHrJ08088272; Tue, 30 Nov 2004 12:53:28 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Tue, 30 Nov 2004 10:50:53 -0500 User-Agent: KMail/1.6.2 References: <20041127223609.BB2DA5D04@ptavv.es.net> In-Reply-To: <20041127223609.BB2DA5D04@ptavv.es.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411301050.53981.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 17:53:35 -0000 On Saturday 27 November 2004 05:36 pm, Kevin Oberman wrote: > > From: John Baldwin > > Date: Mon, 22 Nov 2004 08:45:56 -0500 > > > > On Nov 20, 2004, at 7:15 PM, Kevin Oberman wrote: > > >> From: John Baldwin > > >> Date: Thu, 4 Nov 2004 17:30:04 -0500 > > >> > > >> On Thursday 04 November 2004 05:23 pm, Kevin Oberman wrote: > > >>>> From: John Baldwin > > >>>> Date: Mon, 1 Nov 2004 17:48:25 -0500 > > >>>> > > >>>> On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > >>>>> Ok, well, it seems your BIOS is too busted for non-ACPI to work > > >>>>> out of > > >>>>> the box, you can try setting a hint to force the link for your > > >>>>> sound > > >>>>> card to use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or > > >>>>> maybe 'hw.pci.link.0x04.irq' if that doesn't work. > > >>>> > > >>>> Actually, the $PIR code won't let you use an invalid IRQ currently, > > >>>> but > > >>>> this patch lets it do so. I'm curious if you could try booting > > >>>> with this > > >>>> patch with ACPI disabled and using an appropriate tunable (such as > > >>>> 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them > > >>>> routed. If this does work, I'd like to try another patch as well > > >>>> that > > >>>> would help it to work out-of-the-box for the non-ACPI case. Thanks. > > >>> > > >>> John, > > >>> > > >>> I have not forgotten this, but remote testing when re-boots are > > >>> required > > >>> is a bit difficult. My wife helped me a bit yesterday, but she is a > > >>> Solaris type and I need to step her through things command by > > >>> command, > > >>> so it's a bit tedious. > > >> > > >> That's ok, take your time, this isn't super critical. > > > > > > O.K. I tried the loadable (hw.pci.link.0x4.irq="6"), but it still did > > > not work. I got the expected message: > > > $PIR: BIOS IRQ 6 for 0.9.INTA is not valid for link 0x4 > > > but still no interrupts from the network card. > > > > Well, the patch doesn't fix that message, but it should let the override > > you add from the loader work. If your system does end up working ok > > I'll > > come up with another patch that will trust what your BIOS says over what > > the $PIR says. > > > > > Both the network card and the sound card claim to be using the > > > specified > > > IRQ (I tried both 6 and 10): > > > pcm0: port 0xd800-0xd83f irq 6 at device 9.0 on > > > pci0 > > > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem > > > 0xde000000-0xde00007f irq 10 at device 11.0 on pci0 > > > but 'vmstat -i' did not list IRQ6 as being in use. > > > > Well, if the device gets the IRQ, then that means the patch worked. :) > > Does the sound card actually work now? Note that IRQ6 won't show up in > > vmstat -i until the device actually interrupts. > > The correct IRQ shows up during the device probe at boot, but neither the > sound card nor the network card actually works. It seems like the IRQ > assignment is understood at the device probe, but the interrupt never > actually get routed. My BIOS may simply be toast. Odd. Maybe it's because we specifically route the IRQ that this happens? > There is a beta BIOS version available and I have been thinking about > installing it as Ruslan tells me it fixes the ACPI timer problem, but I > was hoping to figure out a way to get the released BIOS to work better > so others can have an easier time going to V5. I suspect a lot of ASUS > P5A and P5B cards are still out there and booting in SAFE mode won't > work for them at this time. I don't know if the beta BIOS helps the > IRQ issue. > > I get nervous flashing BIOS, so I don't want to jump back and > forth. Since Nate adjusted ACPI to just disable the timer and not all of > ACPI, the board boots fine with ACPI, so it's not a big issue for > me. Just trying to help if you are interested. > > Let me know if there is anything else you would like me to try. Yes, I've tweaked the code further now so that it will allow invalid IRQs if the BIOS uses them. This should use IRQ6 without needing to set the hint and might even work since it won't try to reroute the IRQ: --- //depot/vendor/freebsd/src/sys/i386/pci/pci_pir.c 2004/07/01 07:50:36 +++ //depot/user/jhb/acpipci/i386/pci/pci_pir.c 2004/11/22 19:28:47 @@ -324,22 +324,50 @@ pin = intpin - entry->pe_intpin; pci_link = pci_pir_find_link(intpin->link); irq = pci_pir_search_irq(entry->pe_bus, entry->pe_device, pin); - if (irq == PCI_INVALID_IRQ) + if (irq == PCI_INVALID_IRQ || irq == pci_link->pl_irq) return; - if (pci_pir_valid_irq(pci_link, irq)) { - if (pci_link->pl_irq == PCI_INVALID_IRQ) { - pci_link->pl_irq = irq; - pci_link->pl_routed = 1; - } else if (pci_link->pl_irq != irq) + + /* + * If we don't have an IRQ for this link yet, then we trust the + * BIOS, even if it seems invalid from the $PIR entries. + */ + if (pci_link->pl_irq == PCI_INVALID_IRQ) { + if (!pci_pir_valid_irq(pci_link, irq)) printf( - "$PIR: BIOS IRQ %d for %d.%d.INT%c does not match link %#x irq %d\n", + "$PIR: Using invalid BIOS IRQ %d from %d.%d.INT%c is for link %#x\n", irq, entry->pe_bus, entry->pe_device, pin + 'A', - pci_link->pl_id, pci_link->pl_irq); - } else + pci_link->pl_id); + pci_link->pl_irq = irq; + pci_link->pl_routed = 1; + return; + } + + /* + * We have an IRQ and it doesn't match the current IRQ for this + * link. If the new IRQ is invalid, then warn about it and ignore + * it. If the old IRQ is invalid and the new IRQ is valid, then + * prefer the new IRQ instead. If both IRQs are valid, then just + * use the first one. Note that if we ever get into this situation + * we are having to guess which setting the BIOS actually routed. + * Perhaps we should just give up instead. + */ + if (!pci_pir_valid_irq(pci_link, irq)) { printf( "$PIR: BIOS IRQ %d for %d.%d.INT%c is not valid for link %#x\n", irq, entry->pe_bus, entry->pe_device, pin + 'A', pci_link->pl_id); + } else if (!pci_pir_valid_irq(pci_link, pci_link->pl_irq)) { + printf( +"$PIR: Preferring valid BIOS IRQ %d from %d.%d.INT%c for link %#x to IRQ %d\n", + irq, entry->pe_bus, entry->pe_device, pin + 'A', + pci_link->pl_id, pci_link->pl_irq); + pci_link->pl_irq = irq; + pci_link->pl_routed = 1; + } else + printf( + "$PIR: BIOS IRQ %d for %d.%d.INT%c does not match link %#x irq %d\n", + irq, entry->pe_bus, entry->pe_device, pin + 'A', + pci_link->pl_id, pci_link->pl_irq); } /* @@ -386,9 +414,9 @@ } /* - * Allow the user to override the IRQ for a given link device as - * long as the override is valid or is 255 or 0 to clear a preset - * IRQ. + * Allow the user to override the IRQ for a given link device. We + * allow invalid IRQs to be specified but warn about them. An IRQ + * of 255 or 0 clears any preset IRQ. */ i = 0; TAILQ_FOREACH(pci_link, &pci_links, pl_links) { @@ -398,12 +426,14 @@ continue; if (irq == 0) irq = PCI_INVALID_IRQ; - if (irq == PCI_INVALID_IRQ || - pci_pir_valid_irq(pci_link, irq)) { - pci_link->pl_routed = 0; - pci_link->pl_irq = irq; - i = 1; - } + if (irq != PCI_INVALID_IRQ && + !pci_pir_valid_irq(pci_link, irq) && bootverbose) + printf( + "$PIR: Warning, IRQ %d for link %#x is not listed as valid\n", + irq, pci_link->pl_id); + pci_link->pl_routed = 0; + pci_link->pl_irq = irq; + i = 1; } if (bootverbose && i) { printf("$PIR: Links after tunable overrides:\n"); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 30 17:53:34 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D793416A4CF for ; Tue, 30 Nov 2004 17:53:34 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4862243D2D for ; Tue, 30 Nov 2004 17:53:34 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 6942 invoked from network); 30 Nov 2004 17:53:33 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 30 Nov 2004 17:53:32 -0000 Received: from qa4379.itdev.weather.com (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iAUHrJ08088272; Tue, 30 Nov 2004 12:53:28 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Tue, 30 Nov 2004 10:50:53 -0500 User-Agent: KMail/1.6.2 References: <20041127223609.BB2DA5D04@ptavv.es.net> In-Reply-To: <20041127223609.BB2DA5D04@ptavv.es.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200411301050.53981.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org Subject: Re: ASUS P5A broken by ACPI black-list X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 17:53:35 -0000 On Saturday 27 November 2004 05:36 pm, Kevin Oberman wrote: > > From: John Baldwin > > Date: Mon, 22 Nov 2004 08:45:56 -0500 > > > > On Nov 20, 2004, at 7:15 PM, Kevin Oberman wrote: > > >> From: John Baldwin > > >> Date: Thu, 4 Nov 2004 17:30:04 -0500 > > >> > > >> On Thursday 04 November 2004 05:23 pm, Kevin Oberman wrote: > > >>>> From: John Baldwin > > >>>> Date: Mon, 1 Nov 2004 17:48:25 -0500 > > >>>> > > >>>> On Wednesday 06 October 2004 01:20 pm, John Baldwin wrote: > > >>>>> Ok, well, it seems your BIOS is too busted for non-ACPI to work > > >>>>> out of > > >>>>> the box, you can try setting a hint to force the link for your > > >>>>> sound > > >>>>> card to use IRQ 6. Something like 'set hw.pci.link.0x4.irq=6', or > > >>>>> maybe 'hw.pci.link.0x04.irq' if that doesn't work. > > >>>> > > >>>> Actually, the $PIR code won't let you use an invalid IRQ currently, > > >>>> but > > >>>> this patch lets it do so. I'm curious if you could try booting > > >>>> with this > > >>>> patch with ACPI disabled and using an appropriate tunable (such as > > >>>> 'hw.pci.link.0x4.irq=6') to route your links the way ACPI likes them > > >>>> routed. If this does work, I'd like to try another patch as well > > >>>> that > > >>>> would help it to work out-of-the-box for the non-ACPI case. Thanks. > > >>> > > >>> John, > > >>> > > >>> I have not forgotten this, but remote testing when re-boots are > > >>> required > > >>> is a bit difficult. My wife helped me a bit yesterday, but she is a > > >>> Solaris type and I need to step her through things command by > > >>> command, > > >>> so it's a bit tedious. > > >> > > >> That's ok, take your time, this isn't super critical. > > > > > > O.K. I tried the loadable (hw.pci.link.0x4.irq="6"), but it still did > > > not work. I got the expected message: > > > $PIR: BIOS IRQ 6 for 0.9.INTA is not valid for link 0x4 > > > but still no interrupts from the network card. > > > > Well, the patch doesn't fix that message, but it should let the override > > you add from the loader work. If your system does end up working ok > > I'll > > come up with another patch that will trust what your BIOS says over what > > the $PIR says. > > > > > Both the network card and the sound card claim to be using the > > > specified > > > IRQ (I tried both 6 and 10): > > > pcm0: port 0xd800-0xd83f irq 6 at device 9.0 on > > > pci0 > > > xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xd400-0xd47f mem > > > 0xde000000-0xde00007f irq 10 at device 11.0 on pci0 > > > but 'vmstat -i' did not list IRQ6 as being in use. > > > > Well, if the device gets the IRQ, then that means the patch worked. :) > > Does the sound card actually work now? Note that IRQ6 won't show up in > > vmstat -i until the device actually interrupts. > > The correct IRQ shows up during the device probe at boot, but neither the > sound card nor the network card actually works. It seems like the IRQ > assignment is understood at the device probe, but the interrupt never > actually get routed. My BIOS may simply be toast. Odd. Maybe it's because we specifically route the IRQ that this happens? > There is a beta BIOS version available and I have been thinking about > installing it as Ruslan tells me it fixes the ACPI timer problem, but I > was hoping to figure out a way to get the released BIOS to work better > so others can have an easier time going to V5. I suspect a lot of ASUS > P5A and P5B cards are still out there and booting in SAFE mode won't > work for them at this time. I don't know if the beta BIOS helps the > IRQ issue. > > I get nervous flashing BIOS, so I don't want to jump back and > forth. Since Nate adjusted ACPI to just disable the timer and not all of > ACPI, the board boots fine with ACPI, so it's not a big issue for > me. Just trying to help if you are interested. > > Let me know if there is anything else you would like me to try. Yes, I've tweaked the code further now so that it will allow invalid IRQs if the BIOS uses them. This should use IRQ6 without needing to set the hint and might even work since it won't try to reroute the IRQ: --- //depot/vendor/freebsd/src/sys/i386/pci/pci_pir.c 2004/07/01 07:50:36 +++ //depot/user/jhb/acpipci/i386/pci/pci_pir.c 2004/11/22 19:28:47 @@ -324,22 +324,50 @@ pin = intpin - entry->pe_intpin; pci_link = pci_pir_find_link(intpin->link); irq = pci_pir_search_irq(entry->pe_bus, entry->pe_device, pin); - if (irq == PCI_INVALID_IRQ) + if (irq == PCI_INVALID_IRQ || irq == pci_link->pl_irq) return; - if (pci_pir_valid_irq(pci_link, irq)) { - if (pci_link->pl_irq == PCI_INVALID_IRQ) { - pci_link->pl_irq = irq; - pci_link->pl_routed = 1; - } else if (pci_link->pl_irq != irq) + + /* + * If we don't have an IRQ for this link yet, then we trust the + * BIOS, even if it seems invalid from the $PIR entries. + */ + if (pci_link->pl_irq == PCI_INVALID_IRQ) { + if (!pci_pir_valid_irq(pci_link, irq)) printf( - "$PIR: BIOS IRQ %d for %d.%d.INT%c does not match link %#x irq %d\n", + "$PIR: Using invalid BIOS IRQ %d from %d.%d.INT%c is for link %#x\n", irq, entry->pe_bus, entry->pe_device, pin + 'A', - pci_link->pl_id, pci_link->pl_irq); - } else + pci_link->pl_id); + pci_link->pl_irq = irq; + pci_link->pl_routed = 1; + return; + } + + /* + * We have an IRQ and it doesn't match the current IRQ for this + * link. If the new IRQ is invalid, then warn about it and ignore + * it. If the old IRQ is invalid and the new IRQ is valid, then + * prefer the new IRQ instead. If both IRQs are valid, then just + * use the first one. Note that if we ever get into this situation + * we are having to guess which setting the BIOS actually routed. + * Perhaps we should just give up instead. + */ + if (!pci_pir_valid_irq(pci_link, irq)) { printf( "$PIR: BIOS IRQ %d for %d.%d.INT%c is not valid for link %#x\n", irq, entry->pe_bus, entry->pe_device, pin + 'A', pci_link->pl_id); + } else if (!pci_pir_valid_irq(pci_link, pci_link->pl_irq)) { + printf( +"$PIR: Preferring valid BIOS IRQ %d from %d.%d.INT%c for link %#x to IRQ %d\n", + irq, entry->pe_bus, entry->pe_device, pin + 'A', + pci_link->pl_id, pci_link->pl_irq); + pci_link->pl_irq = irq; + pci_link->pl_routed = 1; + } else + printf( + "$PIR: BIOS IRQ %d for %d.%d.INT%c does not match link %#x irq %d\n", + irq, entry->pe_bus, entry->pe_device, pin + 'A', + pci_link->pl_id, pci_link->pl_irq); } /* @@ -386,9 +414,9 @@ } /* - * Allow the user to override the IRQ for a given link device as - * long as the override is valid or is 255 or 0 to clear a preset - * IRQ. + * Allow the user to override the IRQ for a given link device. We + * allow invalid IRQs to be specified but warn about them. An IRQ + * of 255 or 0 clears any preset IRQ. */ i = 0; TAILQ_FOREACH(pci_link, &pci_links, pl_links) { @@ -398,12 +426,14 @@ continue; if (irq == 0) irq = PCI_INVALID_IRQ; - if (irq == PCI_INVALID_IRQ || - pci_pir_valid_irq(pci_link, irq)) { - pci_link->pl_routed = 0; - pci_link->pl_irq = irq; - i = 1; - } + if (irq != PCI_INVALID_IRQ && + !pci_pir_valid_irq(pci_link, irq) && bootverbose) + printf( + "$PIR: Warning, IRQ %d for link %#x is not listed as valid\n", + irq, pci_link->pl_id); + pci_link->pl_routed = 0; + pci_link->pl_irq = irq; + i = 1; } if (bootverbose && i) { printf("$PIR: Links after tunable overrides:\n"); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 30 17:56:32 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CA0316A4CE for ; Tue, 30 Nov 2004 17:56:32 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9D5043D1D for ; Tue, 30 Nov 2004 17:56:31 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Tue, 30 Nov 2004 09:56:31 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 65DD65D07; Tue, 30 Nov 2004 09:56:29 -0800 (PST) To: Nate Lawson In-reply-to: Your message of "Mon, 29 Nov 2004 18:59:26 PST." <41ABE20E.7020407@root.org> Date: Tue, 30 Nov 2004 09:56:29 -0800 From: "Kevin Oberman" Message-Id: <20041130175629.65DD65D07@ptavv.es.net> cc: acpi@FreeBSD.org Subject: Re: PATCH: power down acpi and pci devices in suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 17:56:32 -0000 > Date: Mon, 29 Nov 2004 18:59:26 -0800 > From: Nate Lawson > > This is a multi-part message in MIME format. > --------------010102000808000603040105 > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > > Kevin Oberman wrote: > > > > The new patch removed the annoying "bad Vcc request" messages, but > > that's all it improved. With the new patch I still lose cbb1 and > > anything connected to it. I see no real difference in the log other than > > the disappearance of the Vcc messages, but that is a good thing. > > > > If I set debug.suspend_power to '0', everything works as it did > > before. All PCI and CardBus devices seem to work fine after resume. > > Here's another version of the patch including the acpi_if.m changes, > sorry for leaving them out. Nate, Well, this one still refuses to apply the third hunk of the pci.c patch. I edited out the (int *) on the tunable manually. Other than that, it is bad news. The system now hangs on probe of the card or card insertion. Ejecting the card does not improve things. It locks solidly and I have to power down the system to do anything. All I get on the console is the first line from the probe: dc0: port 0x4000-0x407f mem 0xd0201000-0xd02017ff, 0xd0201800-0xd0201fff irq 11 at device 0.0 on cardbus1 Any suggestions for trying to break into the debugger? I've had no luck. I think I have tried all combinations of debug.acpi.do_powerstate and hw.pci.do_powerstate. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 30 18:05:48 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 041F216A4CE for ; Tue, 30 Nov 2004 18:05:48 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id D508A43D39 for ; Tue, 30 Nov 2004 18:05:47 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Tue, 30 Nov 2004 10:05:47 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BD4CC5D04; Tue, 30 Nov 2004 10:05:46 -0800 (PST) To: Espen Tagestad In-reply-to: Your message of "Tue, 30 Nov 2004 09:53:40 +0100." <20041130085340.GA76915@totem.fix.no> Date: Tue, 30 Nov 2004 10:05:46 -0800 From: "Kevin Oberman" Message-Id: <20041130180546.BD4CC5D04@ptavv.es.net> cc: freebsd-acpi@freebsd.org Subject: Re: ACPI differences 4.10 - 5.3, laptop problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 18:05:48 -0000 > Date: Tue, 30 Nov 2004 09:53:40 +0100 > From: Espen Tagestad > Sender: owner-freebsd-acpi@freebsd.org > > Hi, > > I have run FreeBSD 4 on my laptop for a couple of years know, and as > ACPI was included in 4.9 (or was it 4.10) I was quite satisfied with the > situation. Now, I've upgraded to 5.3 on ACPI is no longer working. With > acpi enabled, the laptop starts but after 10-15 seconds it stops and > won't respond to anything. Currently it runs without ACPI with the > thermal coolers on full speed. It's irritating, and it'll probably eat > up the batteries much faster than running with ACPI. > > * Is there any tunable options to get ACPI working? > * What is the differences with ACPI on FreeBSD 4 vs 5? > * Can I run FreeBSD 4-ACPI on FreeBSD 5? > > My laptop is a Acer Travelmate 630-series. dmesg out is as follows (with > ACPI disabled): > > Copyright (c) 1992-2004 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 5.3-STABLE #1: Sun Nov 28 15:59:56 UTC 2004 > root@:/usr/obj/usr/src/sys/LEFSE > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.80GHz (1560.22-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 > Features=0x3febf9ff AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM> Looks like the same processor I have and you can try adding: options CPU_ENABLE_TCC to your kernel. This enables the P4 Thermal Control which will let you throttle the speed of the CPU without ACPI. Use the hw.p4tcc sysctls to manage the speed. Also, have you tried APM? It's far less comprehensive than ACPI and not very granular, but it may work. Just load the APM module in /boot/loader.conf and disable ACPI. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Tue Nov 30 23:44:35 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2603416A4CE for ; Tue, 30 Nov 2004 23:44:35 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1519E43D31 for ; Tue, 30 Nov 2004 23:44:34 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id iAUNhXZg014610 for ; Wed, 1 Dec 2004 10:13:33 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Wed, 1 Dec 2004 10:14:27 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id iAUNadQ12912 for ; Wed, 1 Dec 2004 10:06:39 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X53DBYD6; Wed, 1 Dec 2004 10:06:37 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id iAUNb0Nm020508 for ; Wed, 1 Dec 2004 10:07:00 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id iAUNb0Dp020507 for freebsd-acpi@freebsd.org; Wed, 1 Dec 2004 10:07:00 +1030 (CST) (envelope-from wilkinsa) Date: Wed, 1 Dec 2004 10:07:00 +1030 From: "Wilkinson, Alex" To: freebsd-acpi@freebsd.org Message-ID: <20041130233659.GC20263@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-acpi@freebsd.org References: <20041130085340.GA76915@totem.fix.no> <20041130180546.BD4CC5D04@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20041130180546.BD4CC5D04@ptavv.es.net> User-Agent: Mutt/1.5.6i Subject: Re: ACPI differences 4.10 - 5.3, laptop problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 23:44:35 -0000 0n Tue, Nov 30, 2004 at 10:05:46AM -0800, Kevin Oberman wrote: > Looks like the same processor I have and you can try adding: > options CPU_ENABLE_TCC > to your kernel. This enables the P4 Thermal Control which will let you > throttle the speed of the CPU without ACPI. Use the hw.p4tcc sysctls to > manage the speed. Kevin, why don't you use 'C states' for the afforementioned ? Throttling reduces CPU performance. I thought it would be better to use C1,C2,C3, states. Or does fbsd ACPI not support C states yet ? - aW From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 1 00:21:52 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0046A16A4CE for ; Wed, 1 Dec 2004 00:21:51 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9A7143D31 for ; Wed, 1 Dec 2004 00:21:51 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iB10LgC4019714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2004 16:21:44 -0800 Message-ID: <41AD0E96.7010306@root.org> Date: Tue, 30 Nov 2004 16:21:42 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wilkinson, Alex" References: <20041130085340.GA76915@totem.fix.no> <20041130180546.BD4CC5D04@ptavv.es.net> <20041130233659.GC20263@squash.dsto.defence.gov.au> In-Reply-To: <20041130233659.GC20263@squash.dsto.defence.gov.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: ACPI differences 4.10 - 5.3, laptop problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 00:21:52 -0000 Wilkinson, Alex wrote: > 0n Tue, Nov 30, 2004 at 10:05:46AM -0800, Kevin Oberman wrote: > > > Looks like the same processor I have and you can try adding: > > options CPU_ENABLE_TCC > > to your kernel. This enables the P4 Thermal Control which will let you > > throttle the speed of the CPU without ACPI. Use the hw.p4tcc sysctls to > > manage the speed. > > Kevin, why don't you use 'C states' for the afforementioned ? > Throttling reduces CPU performance. I thought it would be better to > use C1,C2,C3, states. Or does fbsd ACPI not support C states yet ? It's supported them since 5.2 a year and a half ago, including static _CST support. This is equivalent to Linux. Also, support is automatic so he doesn't need to configure them. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 1 04:37:40 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64EFE16A4CE; Wed, 1 Dec 2004 04:37:40 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32EE843D2F; Wed, 1 Dec 2004 04:37:40 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 763A9512B1; Tue, 30 Nov 2004 20:42:55 -0800 (PST) Date: Tue, 30 Nov 2004 20:42:55 -0800 From: Kris Kennaway To: acpi@FreeBSD.org, current@FreeBSD.org Message-ID: <20041201044255.GA36090@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: Lock ACPI PCI link not exclusively locked X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 04:37:40 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Rebuilt 6.0 kernel tonight, panics at boot: pci_link0: irq 6 on acpi0 panic: Lock ACPI PCI link not exclusively locked @ /a/portbuild/i386/src-client/sys/dev/acpica/acpi_pci_link.c:153 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x32: leal 0(%esi),%esi db> db> tr Tracing pid 0 tid 0 td 0xc07b8260 kdb_enter(c07551c4,c07ba540,c07558db,c0c20a7c,c07b8260) at kdb_enter+0x32 panic(c07558db,c0740d53,c0740d88,99,c0c20b00) at panic+0x14d _sx_assert(c07b4a60,4,c0740d88,99,c1a2e9c0) at _sx_assert+0xfe link_add_crs(c1a2e9c0,c0c20b00,c0c20ac8,2c,c1a2e9c0) at link_add_crs+0x35 AcpiWalkResources(c1950900,c073db16,c047e620,c0c20b00,c195c980) at AcpiWalkResources+0x8d acpi_pci_link_attach(c1a28380,c19bd04c,c077a96c,c0756dc5,0) at acpi_pci_link_attach+0x251 device_attach(c1a28380,c0475100,c0c20b78,c0c20b80,0) at device_attach+0x2c9 prt_attach_devices(c1a08800,c195c400,c195c980,c195c400,c1a0f994) at prt_attach_devices+0xe6 prt_walk_table(c195c400,c0771297,0,c0c20bcc,0) at prt_walk_table+0x3c acpi_pcib_attach(c195c400,c1a0f994,0,c0c20c04,c0473fb7,c0764021,c1945970,c077a96c,c19494a0) at acpi_pcib_attach+0xe4 acpi_pcib_acpi_attach(c195c400,c19b104c,c077a96c,c0756dc5,0) at acpi_pcib_acpi_attach+0xf9 device_attach(c195c400,1fefffff,c0c20cbc,c0476474,c195c980) at device_attach+0x2c9 bus_generic_attach(c195c980,100000,1fefffff,c1a0f9e8,100000) at bus_generic_attach+0x18 acpi_attach(c195c980,c19ca04c,c077a96c,c0756dc5,0) at acpi_attach+0x7b4 device_attach(c195c980,c195ca00,c0c20d18,c070d6da,c195ca00) at device_attach+0x2c9 bus_generic_attach(c195ca00,c195ca4c,c0c20d54,c0574679,c195ca00) at bus_generic_attach+0x18 nexus_attach(c195ca00,c19e084c,c077a96c,c0756dc5,0) at nexus_attach+0x1a device_attach(c195ca00,c07a4190,c0c20d78,c06fff08,c19ac180) at device_attach+0x2c9 root_bus_configure(c19ac180,c077305f,0,c0c20d98,c052ed66) at root_bus_configure+0x19 configure(0,0,c0777508,c1ec00,c1e000) at configure+0x28 mi_startup() at mi_startup+0xd6 begin() at begin+0x2c Kris --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBrUvPWry0BWjoQKURAsRBAJoC2EVUJ17SLoJazULAQpmMn6Ye2QCg4UWW VurJ6zFmQSmrYk86HMdfxEM= =pxSp -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 1 05:40:54 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F277C16A4CE; Wed, 1 Dec 2004 05:40:53 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B543643D55; Wed, 1 Dec 2004 05:40:53 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-186-185.dsl.snfc21.pacbell.net [64.171.186.185]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iB15eqC4028325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Nov 2004 21:40:52 -0800 Message-ID: <41AD5962.4020501@root.org> Date: Tue, 30 Nov 2004 21:40:50 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway References: <20041201044255.GA36090@xor.obsecurity.org> In-Reply-To: <20041201044255.GA36090@xor.obsecurity.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.org cc: current@FreeBSD.org Subject: Re: panic: Lock ACPI PCI link not exclusively locked X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 05:40:54 -0000 Kris Kennaway wrote: > Rebuilt 6.0 kernel tonight, panics at boot: > > pci_link0: irq 6 on acpi0 > panic: Lock ACPI PCI link not exclusively locked @ /a/portbuild/i386/src-client/sys/dev/acpica/acpi_pci_link.c:153 > > KDB: enter: panic > [thread pid 0 tid 0 ] > Stopped at kdb_enter+0x32: leal 0(%esi),%esi > db> > db> tr > Tracing pid 0 tid 0 td 0xc07b8260 > kdb_enter(c07551c4,c07ba540,c07558db,c0c20a7c,c07b8260) at kdb_enter+0x32 > panic(c07558db,c0740d53,c0740d88,99,c0c20b00) at panic+0x14d > _sx_assert(c07b4a60,4,c0740d88,99,c1a2e9c0) at _sx_assert+0xfe > link_add_crs(c1a2e9c0,c0c20b00,c0c20ac8,2c,c1a2e9c0) at link_add_crs+0x35 > AcpiWalkResources(c1950900,c073db16,c047e620,c0c20b00,c195c980) at AcpiWalkResources+0x8d > acpi_pci_link_attach(c1a28380,c19bd04c,c077a96c,c0756dc5,0) at acpi_pci_link_attach+0x251 > device_attach(c1a28380,c0475100,c0c20b78,c0c20b80,0) at device_attach+0x2c9 > prt_attach_devices(c1a08800,c195c400,c195c980,c195c400,c1a0f994) at prt_attach_devices+0xe6 > prt_walk_table(c195c400,c0771297,0,c0c20bcc,0) at prt_walk_table+0x3c > acpi_pcib_attach(c195c400,c1a0f994,0,c0c20c04,c0473fb7,c0764021,c1945970,c077a96c,c19494a0) at acpi_pcib_attach+0xe4 > acpi_pcib_acpi_attach(c195c400,c19b104c,c077a96c,c0756dc5,0) at acpi_pcib_acpi_attach+0xf9 > device_attach(c195c400,1fefffff,c0c20cbc,c0476474,c195c980) at device_attach+0x2c9 > bus_generic_attach(c195c980,100000,1fefffff,c1a0f9e8,100000) at bus_generic_attach+0x18 > acpi_attach(c195c980,c19ca04c,c077a96c,c0756dc5,0) at acpi_attach+0x7b4 > device_attach(c195c980,c195ca00,c0c20d18,c070d6da,c195ca00) at device_attach+0x2c9 > bus_generic_attach(c195ca00,c195ca4c,c0c20d54,c0574679,c195ca00) at bus_generic_attach+0x18 > nexus_attach(c195ca00,c19e084c,c077a96c,c0756dc5,0) at nexus_attach+0x1a > device_attach(c195ca00,c07a4190,c0c20d78,c06fff08,c19ac180) at device_attach+0x2c9 > root_bus_configure(c19ac180,c077305f,0,c0c20d98,c052ed66) at root_bus_configure+0x19 > configure(0,0,c0777508,c1ec00,c1e000) at configure+0x28 > mi_startup() at mi_startup+0xd6 > begin() at begin+0x2c > > Kris This has been partially addressed by David backing out my commit although I will now complete the backout for the !SMP case too. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 1 10:06:03 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FD8716A4CE for ; Wed, 1 Dec 2004 10:06:03 +0000 (GMT) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F24643D31 for ; Wed, 1 Dec 2004 10:06:03 +0000 (GMT) (envelope-from espent@totem.fix.no) Received: from localhost (totem.fix.no [80.91.36.20]) by totem.fix.no (Postfix) with ESMTP id 16E865F3825; Wed, 1 Dec 2004 11:06:02 +0100 (CET) Received: from totem.fix.no ([80.91.36.20]) by localhost (totem.fix.no [80.91.36.20]) (amavisd-new, port 10024) with LMTP id 26126-01-7; Wed, 1 Dec 2004 11:05:58 +0100 (CET) Received: by totem.fix.no (Postfix, from userid 1032) id E6CF65F380D; Wed, 1 Dec 2004 11:05:58 +0100 (CET) Date: Wed, 1 Dec 2004 11:05:58 +0100 From: Espen Tagestad To: Kevin Oberman Message-ID: <20041201100558.GA26164@totem.fix.no> References: <20041130085340.GA76915@totem.fix.no> <20041130180546.BD4CC5D04@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041130180546.BD4CC5D04@ptavv.es.net> User-Agent: Mutt/1.5.6i cc: freebsd-acpi@freebsd.org Subject: Re: ACPI differences 4.10 - 5.3, laptop problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 10:06:03 -0000 On Tue, Nov 30, 2004 at 10:05:46AM -0800, Kevin Oberman wrote: > > Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 > > Features=0x3febf9ff > AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM> > > Looks like the same processor I have and you can try adding: > options CPU_ENABLE_TCC > to your kernel. This enables the P4 Thermal Control which will let you > throttle the speed of the CPU without ACPI. Use the hw.p4tcc sysctls to > manage the speed. No, this didn't have any effect on the coolers. If I set hw.p4tcc.cpuperf_performance to 13 (the lowest available) hw.p4tcc.cpuperf follows. But I can't see wether it's slowing down the processor, and it certainly don't slow down the coolers :( > Also, have you tried APM? It's far less comprehensive than ACPI and not > very granular, but it may work. Just load the APM module in > /boot/loader.conf and disable ACPI. I tried APM too, but it simply didn't work. I can't even get battery info from it. I didn't work much on it other than enabling it through rc.conf and loader.conf. I tried apm -e 1, but that didn't have any effect either. regards, Espen From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 1 10:21:53 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2065716A4CE for ; Wed, 1 Dec 2004 10:21:53 +0000 (GMT) Received: from totem.fix.no (totem.fix.no [80.91.36.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8C7743D64 for ; Wed, 1 Dec 2004 10:21:52 +0000 (GMT) (envelope-from espent@totem.fix.no) Received: from localhost (totem.fix.no [80.91.36.20]) by totem.fix.no (Postfix) with ESMTP id B39085F3825; Wed, 1 Dec 2004 11:21:51 +0100 (CET) Received: from totem.fix.no ([80.91.36.20]) by localhost (totem.fix.no [80.91.36.20]) (amavisd-new, port 10024) with LMTP id 26307-02-3; Wed, 1 Dec 2004 11:21:45 +0100 (CET) Received: by totem.fix.no (Postfix, from userid 1032) id 7FC8F5F380D; Wed, 1 Dec 2004 11:21:45 +0100 (CET) Date: Wed, 1 Dec 2004 11:21:45 +0100 From: Espen Tagestad To: Kevin Oberman Message-ID: <20041201102145.GA26414@totem.fix.no> References: <20041130085340.GA76915@totem.fix.no> <20041130180546.BD4CC5D04@ptavv.es.net> <20041201100558.GA26164@totem.fix.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041201100558.GA26164@totem.fix.no> User-Agent: Mutt/1.5.6i cc: freebsd-acpi@freebsd.org Subject: Re: ACPI differences 4.10 - 5.3, laptop problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 10:21:53 -0000 On Wed, Dec 01, 2004 at 11:05:58AM +0100, Espen Tagestad wrote: > No, this didn't have any effect on the coolers. If I set > hw.p4tcc.cpuperf_performance to 13 (the lowest available) > hw.p4tcc.cpuperf follows. But I can't see wether it's slowing down the > processor, and it certainly don't slow down the coolers :( Ouch! It DID slow down the processor, I didn't see it before now! Ok, then I'll guess the processor decreases it's energy consumption, but the coolers are still running at full speed. regards, Espen From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 1 12:08:56 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B98916A4CE for ; Wed, 1 Dec 2004 12:08:56 +0000 (GMT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD4F343D54 for ; Wed, 1 Dec 2004 12:08:55 +0000 (GMT) (envelope-from h-k@mail.ru) Received: from [213.247.182.194] (port=2151 helo=213.247.182.194) by mx1.mail.ru with esmtp id 1CZTHx-000NnY-00; Wed, 01 Dec 2004 15:08:53 +0300 Date: Wed, 1 Dec 2004 15:09:57 +0300 From: dawnshade X-Mailer: The Bat! (v2.00) CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <116438671326.20041201150957@mail.ru> To: freebsd-acpi@freebsd.org In-Reply-To: <118601515.20041127112408@mail.ru> References: <49610308517.20041126114605@mail.ru> <41A7C901.4000105@root.org> <118601515.20041127112408@mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected Subject: Re[3]: Problem with ASUS NRLLS533 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dawnshade List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 12:08:56 -0000 Hello dawnshade, Saturday, November 27, 2004, 11:24:08 AM, you wrote: d> Hello Nate, d> Saturday, November 27, 2004, 3:23:29 AM, you wrote: NL>> dawnshade wrote: >>> Hello all, >>> >>> I not sure related problem to acpi or smp, but.... >>> Motherboard with serverworks chipset and 1 Xeon onboard, but HTT not >>> working (if course enabled in bios). Kernel build with options: >>> >>> device apic # I/O APIC >>> options SMP >>> options MPTABLE_FORCE_HTT >>> >>> If I add options NO_MIXED_MODE system hang up in boot. NL>> If you disable acpi (unset acpi_load) in boot, does it hang with options NL>> NO_MIXED_MODE? If not, it's not an acpi problem. If so, it may be an NL>> APIC/MADT issue. With NO_MIXED_MODE and disabled ACPI system hang up too. :( Now, I can't continue experiments, because server gone in productions... ---------- Best regards, dawnshade mailto:h-k@mail.ru From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 1 18:14:46 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA16416A4CE for ; Wed, 1 Dec 2004 18:14:46 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A50F043D58 for ; Wed, 1 Dec 2004 18:14:46 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iB1IEjC4027733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Dec 2004 10:14:46 -0800 Message-ID: <41AE0A15.2030305@root.org> Date: Wed, 01 Dec 2004 10:14:45 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dawnshade References: <49610308517.20041126114605@mail.ru> <41A7C901.4000105@root.org> <118601515.20041127112408@mail.ru> <116438671326.20041201150957@mail.ru> In-Reply-To: <116438671326.20041201150957@mail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org Subject: Re: Problem with ASUS NRLLS533 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 18:14:47 -0000 dawnshade wrote: > Hello dawnshade, Talking to yourself? :) > Saturday, November 27, 2004, 11:24:08 AM, you wrote: >>>>I not sure related problem to acpi or smp, but.... >>>>Motherboard with serverworks chipset and 1 Xeon onboard, but HTT not >>>>working (if course enabled in bios). Kernel build with options: >>>> >>>>device apic # I/O APIC >>>>options SMP >>>>options MPTABLE_FORCE_HTT >>>> >>>>If I add options NO_MIXED_MODE system hang up in boot. > > NL>> If you disable acpi (unset acpi_load) in boot, does it hang with options > NL>> NO_MIXED_MODE? If not, it's not an acpi problem. If so, it may be an > NL>> APIC/MADT issue. > > With NO_MIXED_MODE and disabled ACPI system hang up too. :( > Now, I can't continue experiments, because server gone in > productions... It sounds like NO_MIXED_MODE is the culprit and not acpi then. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Wed Dec 1 18:44:42 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 271A916A4CE for ; Wed, 1 Dec 2004 18:44:42 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA94543D54 for ; Wed, 1 Dec 2004 18:44:41 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Wed, 01 Dec 2004 10:44:41 -0800 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 220185D04; Wed, 1 Dec 2004 10:44:41 -0800 (PST) To: "Wilkinson, Alex" In-reply-to: Your message of "Wed, 01 Dec 2004 10:07:00 +1030." <20041130233659.GC20263@squash.dsto.defence.gov.au> Date: Wed, 01 Dec 2004 10:44:41 -0800 From: "Kevin Oberman" Message-Id: <20041201184441.220185D04@ptavv.es.net> cc: freebsd-acpi@freebsd.org Subject: Re: ACPI differences 4.10 - 5.3, laptop problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2004 18:44:42 -0000 > Date: Wed, 1 Dec 2004 10:07:00 +1030 > From: "Wilkinson, Alex" > Sender: owner-freebsd-acpi@freebsd.org > > 0n Tue, Nov 30, 2004 at 10:05:46AM -0800, Kevin Oberman wrote: > > > Looks like the same processor I have and you can try adding: > > options CPU_ENABLE_TCC > > to your kernel. This enables the P4 Thermal Control which will let you > > throttle the speed of the CPU without ACPI. Use the hw.p4tcc sysctls to > > manage the speed. > > Kevin, why don't you use 'C states' for the afforementioned ? > Throttling reduces CPU performance. I thought it would be better to > use C1,C2,C3, states. Or does fbsd ACPI not support C states yet ? C states are used in ACPI, but they provide minimal reduction in power consumption, This is especially true if you have USB drivers present as they block ever getting to C3. ACPI does support CPU throttling, but this is not too different from the TCC throttling. (NOTE: TCC and ACPI CPU throttles are independent. Setting TCC to 13% and the ACPI throttle to 4 results in about 6% of full speed. This is just a bit painful!) In any case, the issue was rapid battery drain when ACPI was not present and TCC is not dependent on ACPI. It's always there for P4s. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Thu Dec 2 05:51:22 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F49416A4CE for ; Thu, 2 Dec 2004 05:51:22 +0000 (GMT) Received: from otter3.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC8C343D41 for ; Thu, 2 Dec 2004 05:51:21 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.21] (andersonbox1.centtech.com [192.168.42.21]) by otter3.centtech.com (8.12.3/8.12.3) with ESMTP id iB25pLOJ003561 for ; Wed, 1 Dec 2004 23:51:21 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <41AEAD56.606@centtech.com> Date: Wed, 01 Dec 2004 23:51:18 -0600 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041110 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: S3 on Dell laptops.. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2004 05:51:22 -0000 Prior to today, I've been running 5.3-RELEASE on a Dell laptop. Only one power save mode worked for me, S1. Today, I updated my src tree, and sucked in the recently posted acpi patches and rebuilt world. Prior to doing that, attempting to go into S3 would result in immediate reboot, whereas now, it actually begins to run the disk, blank the screen, and THEN reboots. So progress has been made :) I'd love to get S3 (and S4/S4BIOS?) working on this laptop - what can I do to help? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology When in doubt, mumble; when in trouble, delegate; when in charge, ponder ------------------------------------------------------------------------ From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 3 06:50:25 2004 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 273B116A4CE for ; Fri, 3 Dec 2004 06:50:25 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5D6F43D2F for ; Fri, 3 Dec 2004 06:50:24 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iB36oOoY014108 for ; Fri, 3 Dec 2004 06:50:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iB36oOAw014107; Fri, 3 Dec 2004 06:50:24 GMT (envelope-from gnats) Date: Fri, 3 Dec 2004 06:50:24 GMT Message-Id: <200412030650.iB36oOAw014107@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Sean Farley Subject: Re: i386/69750: Boot without ACPI failed on ASUS L5 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Sean Farley List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2004 06:50:25 -0000 The following reply was made to PR i386/69750; it has been noted by GNATS. From: Sean Farley To: freebsd-gnats-submit@FreeBSD.org, mcsi@mcsi.pp.ru Cc: Subject: Re: i386/69750: Boot without ACPI failed on ASUS L5 Date: Fri, 3 Dec 2004 00:41:45 -0600 (CST) I can confirm a panic with disabled ACPI (for using VMware). HTT probably has nothing to do with it since I have an Athlon XP. I attempted disabling ACPI in the BIOS, but the board seems to keep it alive. During boot, ACPI v1.0 is enabled according to the BIOS. System: Athlon XP 2100+ on an Asus A7V880 board. Ignore the labeling of the processor as 2000+. The BIOS is not the best at identifying processors. I had to set the bus and multiplier manually. Sean -- sean-freebsd@farley.org dmesg output ------------ Copyright (c) 1992-2004 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 5.3-STABLE #0: Mon Nov 29 13:48:28 CST 2004 root@thor.farley.org:/usr/obj/usr/src/sys/THOR ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2000+ (1733.41-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc0400000 real memory = 536084480 (511 MB) avail memory = 510726144 (487 MB) MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xafe00000-0xafe7ffff,0xa0000000-0xa7ffffff,0xfc000000-0xfcffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] csa0: mem 0xfe600000-0xfe6fffff,0xfe700000-0xfe700fff irq 17 at device 14.0 on pci0 csa: card is Turtle Beach Santa Cruz csa0: [GIANT-LOCKED] pcm0: on csa0 pcm0: pcm0: [GIANT-LOCKED] atapci0: port 0xe800-0xe8ff,0xef90-0xef9f,0xefe0-0xefe3,0xefa8-0xefaf,0xefe4-0xefe7,0xeff0-0xeff7 irq 20 at device 15.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 uhci0: port 0xeec0-0xeedf irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xef00-0xef1f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xef20-0xef3f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xef40-0xef5f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfe800000-0xfe8000ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 ehci_pci_attach: companion usb3 usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 dc0: <82c169 PNIC 10/100BaseTX> port 0xe400-0xe4ff mem 0xfeb00000-0xfeb000ff irq 18 at device 19.0 on pci0 miibus0: on dc0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:a0:cc:d2:58:91 dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] acpi_button0: on acpi0 acpi_button1: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounter "TSC" frequency 1733409090 Hz quality 800 Timecounters tick every 10.000 msec acd0: DVDROM at ata0-master UDMA33 acd1: CDRW at ata0-slave PIO4 ad2: 76345MB [155114/16/63] at ata1-master UDMA133