Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Lukas Ertl wrote: On Wed, 26 Nov 2003, Nate Lawson wrote: I need the output of sysctl hw.acpi.thermal to see your _ACx values. hw.acpi.thermal.tz0.temperature: 3072 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3627 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3662 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 Um, you have no _ACx values so the fan will be controlled by the BIOS. We should probably provide a way for users to supply their own _ACx values if they're not happy with the BIOS's but I'm not sure your ASL exports a power resource for the fan object. Do you have an object with id PNP0C0B? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 2 Dec 2003, Nate Lawson wrote: Um, you have no _ACx values so the fan will be controlled by the BIOS. We should probably provide a way for users to supply their own _ACx values if they're not happy with the BIOS's but I'm not sure your ASL exports a power resource for the fan object. Do you have an object with id PNP0C0B? No, there's no PNP0C0B device. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 2 Dec 2003, Lukas Ertl wrote: On Tue, 2 Dec 2003, Nate Lawson wrote: Um, you have no _ACx values so the fan will be controlled by the BIOS. We should probably provide a way for users to supply their own _ACx values if they're not happy with the BIOS's but I'm not sure your ASL exports a power resource for the fan object. Do you have an object with id PNP0C0B? No, there's no PNP0C0B device. Build with options ACPI_DEBUG and boot with this in loader.conf: debug.acpi.layer=ACPI_POWER debug.acpi.level=ACPI_LV_OBJECTS It will print any power resources you have. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 2 Dec 2003, Nate Lawson wrote: Build with options ACPI_DEBUG and boot with this in loader.conf: debug.acpi.layer=ACPI_POWER debug.acpi.level=ACPI_LV_OBJECTS It will print any power resources you have. Unfortunately, there's no power resource listed. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Fri, 21 Nov 2003, Lukas Ertl wrote: On Fri, 21 Nov 2003, Nate Lawson wrote: On Tue, 18 Nov 2003, Lukas Ertl wrote: I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. That's probably ok. It has a lot of IO. Now I've tried running make buildkernel and tarring /usr/src to a different location, with different setting for hw.acpi.cpu.cx_lowest. I couldn't see any real difference - neither in performance nor in heat emission. Well, heat emission will be high during benchmarks because the CPU is rarely idle. My fan always comes on my laptop during buildworld. But the difference is when it's mostly idle (checking email, web browsing). With machdep.cpu_idle_hlt=0, the fan is always on even when the box is sitting there. With cpu_idle_hlt=0 and cx_lowest=0 (C1), the fan goes off but the box is still warm. With cx_lowest=2 (C3, 120 us transition time), the box is very cool but some IO gets a little slower (serial port). But not much. The problem is that the fan in this machine always kicks in after several minutes, and then stays on. This is very annoying. If you're testing C3 states, you have to disable USB in your kernel config. (I just load USB as modules since performance is not an issue and I like to use C3 while on the road to get max power savings). It's possible the fan is under BIOS control so make sure you have an up-to-date bios. If not, you should get a console printout when acpi switches the fan on. sysctl hw.acpi.thermal BTW, I'm having another ACPI question, do these figures here make sense? hw.acpi.thermal.tz0._PSV: 3627 hw.acpi.thermal.tz0._CRT: 3662 They are valid, yes. If I understood the ACPI spec correctly, _PSV is the temperature where passive cooling actions begin, and _CRT is the critical temp, where the OS should initiate a shutdown. First, _PSV seems to be way to high, and second, they are so close to each other. You are correct. _PSV is not currently implemented by FreeBSD but I hope to do it at some point. Once we have all methods of processor control (cpufreq, Cx, and throttling), we can use them to implement _PSV. In any case, I think the _PSV value is set high because your platform designer expects active cooling to be the most effective and passive, since it slows down performance, is a last resort. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Nate Lawson wrote: It's possible the fan is under BIOS control so make sure you have an up-to-date bios. If not, you should get a console printout when acpi switches the fan on. sysctl hw.acpi.thermal Nope, no ACPI messages, and I can't find a FAN device in my ASL. (At least no 'standard' one - anyone knows what hides behind this HKEY device every ThinkPad seems to have?) You are correct. _PSV is not currently implemented by FreeBSD but I hope to do it at some point. Once we have all methods of processor control (cpufreq, Cx, and throttling), we can use them to implement _PSV. In any case, I think the _PSV value is set high because your platform designer expects active cooling to be the most effective and passive, since it slows down performance, is a last resort. Ah, sounds reasonable, thanks for the explaination. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Lukas Ertl wrote: On Wed, 26 Nov 2003, Nate Lawson wrote: It's possible the fan is under BIOS control so make sure you have an up-to-date bios. If not, you should get a console printout when acpi switches the fan on. sysctl hw.acpi.thermal Nope, no ACPI messages, and I can't find a FAN device in my ASL. (At least no 'standard' one - anyone knows what hides behind this HKEY device every ThinkPad seems to have?) It's not called FAN. It is a device with a certain PNP id and controlled by a power resource. I need the output of sysctl hw.acpi.thermal to see your _ACx values. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Nate Lawson wrote: On Wed, 26 Nov 2003, Lukas Ertl wrote: On Wed, 26 Nov 2003, Nate Lawson wrote: It's possible the fan is under BIOS control so make sure you have an up-to-date bios. If not, you should get a console printout when acpi switches the fan on. sysctl hw.acpi.thermal Nope, no ACPI messages, and I can't find a FAN device in my ASL. (At least no 'standard' one - anyone knows what hides behind this HKEY device every ThinkPad seems to have?) It's not called FAN. It is a device with a certain PNP id and controlled by a power resource. That's what I meant, actually. I need the output of sysctl hw.acpi.thermal to see your _ACx values. hw.acpi.thermal.tz0.temperature: 3072 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3627 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3662 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Sat, 22 Nov 2003, Lukas Ertl wrote: Ah, this would explain why I can see the C3 states change after a suspend/resume - USB is dead then :-) I'm gonna try without USB and send you the output again. Yes, looks better now: hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 hw.acpi.cpu.cx_lowest: 3 hw.acpi.cpu.cx_history: 0/0 451979/0 2361/15 805279/27634 regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Lukas Ertl wrote: I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. That's probably ok. It has a lot of IO. Now I've tried running make buildkernel and tarring /usr/src to a different location, with different setting for hw.acpi.cpu.cx_lowest. I couldn't see any real difference - neither in performance nor in heat emission. Well, heat emission will be high during benchmarks because the CPU is rarely idle. My fan always comes on my laptop during buildworld. But the difference is when it's mostly idle (checking email, web browsing). With machdep.cpu_idle_hlt=0, the fan is always on even when the box is sitting there. With cpu_idle_hlt=0 and cx_lowest=0 (C1), the fan goes off but the box is still warm. With cx_lowest=2 (C3, 120 us transition time), the box is very cool but some IO gets a little slower (serial port). But not much. So there are actually two things to test for each setting: temperature when mostly idle/low use and performance loss for IO latency benchmarks. Those are what is more interesting. Also, can you send me your sysctl hw.acpi.cpu.cx_history after you've used it for a while with the maximum cx_lowest setting? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Fri, 21 Nov 2003, Nate Lawson wrote: On Tue, 18 Nov 2003, Lukas Ertl wrote: I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. That's probably ok. It has a lot of IO. Now I've tried running make buildkernel and tarring /usr/src to a different location, with different setting for hw.acpi.cpu.cx_lowest. I couldn't see any real difference - neither in performance nor in heat emission. Well, heat emission will be high during benchmarks because the CPU is rarely idle. My fan always comes on my laptop during buildworld. But the difference is when it's mostly idle (checking email, web browsing). With machdep.cpu_idle_hlt=0, the fan is always on even when the box is sitting there. With cpu_idle_hlt=0 and cx_lowest=0 (C1), the fan goes off but the box is still warm. With cx_lowest=2 (C3, 120 us transition time), the box is very cool but some IO gets a little slower (serial port). But not much. The problem is that the fan in this machine always kicks in after several minutes, and then stays on. This is very annoying. BTW, I'm having another ACPI question, do these figures here make sense? hw.acpi.thermal.tz0._PSV: 3627 hw.acpi.thermal.tz0._CRT: 3662 If I understood the ACPI spec correctly, _PSV is the temperature where passive cooling actions begin, and _CRT is the critical temp, where the OS should initiate a shutdown. First, _PSV seems to be way to high, and second, they are so close to each other. Those are what is more interesting. Also, can you send me your sysctl hw.acpi.cpu.cx_history after you've used it for a while with the maximum cx_lowest setting? Ok, no problem. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Sat, 22 Nov 2003, Lukas Ertl wrote: On Fri, 21 Nov 2003, Nate Lawson wrote: Those are what is more interesting. Also, can you send me your sysctl hw.acpi.cpu.cx_history after you've used it for a while with the maximum cx_lowest setting? hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 hw.acpi.cpu.cx_lowest: 3 hw.acpi.cpu.cx_history: 0/0 1143097/0 0/0 0/0 This is after 1:22h doing things like eMail, web surfing, IRC... Ah, I see the C3 states aren't being used. If you are playing mp3s or have usb enabled in your kernel, they won't be used (because we can't use them when bus mastering transfers are active.) Try making usb a module and not loading it and test this again. I've been working on a change to USB to disable polling for devices when we are attempting to sleep in idle but this may take a while. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Fri, 21 Nov 2003, Nate Lawson wrote: On Sat, 22 Nov 2003, Lukas Ertl wrote: On Fri, 21 Nov 2003, Nate Lawson wrote: Those are what is more interesting. Also, can you send me your sysctl hw.acpi.cpu.cx_history after you've used it for a while with the maximum cx_lowest setting? hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 hw.acpi.cpu.cx_lowest: 3 hw.acpi.cpu.cx_history: 0/0 1143097/0 0/0 0/0 This is after 1:22h doing things like eMail, web surfing, IRC... Ah, I see the C3 states aren't being used. If you are playing mp3s or have usb enabled in your kernel, they won't be used (because we can't use them when bus mastering transfers are active.) Try making usb a module and not loading it and test this again. Ah, this would explain why I can see the C3 states change after a suspend/resume - USB is dead then :-) I'm gonna try without USB and send you the output again. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote: On Tue, 18 Nov 2003, Lukas Ertl wrote: I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. That's probably ok. It has a lot of IO. Now I've tried running make buildkernel and tarring /usr/src to a different location, with different setting for hw.acpi.cpu.cx_lowest. I couldn't see any real difference - neither in performance nor in heat emission. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
Ok, here's the final patch. I believe it fixes both problems.
* Add a DEVMETHOD for acpi so that child detach methods get called. Add
an acpi_cpu method for both detach and shutdown that disables entry to
acpi_cpu_idle and then IPIs/waits for threads to exit. This fixes a panic
late in reboot in the SMP case.
* In the !SMP case, don't use the processor id filled out by the MADT
since there can only be one processor. This was causing a panic in
acpi_cpu_idle if the id was 1 since the data was being dereferenced from
cpu_softc[1] even though the actual data was in cpu_softc[0] (which is
correct).
* Rework the initialization functions so that cpu_idle_hook is written
late in the boot process.
* Make the P_BLK, P_BLK_LEN, and cpu_cx_count all softc-local variables.
This will help SMP boxes that have _CST or multiple P_BLKs. No such boxes
are known at this time.
* Always allocate the C1 state, even if the P_BLK is invalid. This means
we will always take over idling if enabled. Remove the value -1 as valid
for cx_lowest since this is redundant with machdep.cpu_idle_hlt.
* Reduce locking for the throttle initialization case to around the write
to the smi_cmd port. Add disabled code to write the CST_CNT. It will be
enabled once _CST re-evaluation is tested (post 5.2R).
Thank you: dfr, imp, jhb, marcel, peter
-Nate
Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.19
diff -u -r1.19 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 - 1.19
+++ sys/dev/acpica/acpi_cpu.c 19 Nov 2003 15:21:07 -
@@ -1,5 +1,5 @@
/*-
- * Copyright (c) 2003 Nate Lawson
+ * Copyright (c) 2003 Nate Lawson (SDG)
* Copyright (c) 2001 Michael Smith
* All rights reserved.
*
@@ -30,20 +30,21 @@
#include opt_acpi.h
#include sys/param.h
-#include sys/kernel.h
-#include sys/proc.h
#include sys/bus.h
+#include sys/kernel.h
+#include sys/pcpu.h
#include sys/power.h
+#include sys/proc.h
#include sys/sbuf.h
-#include sys/pcpu.h
#include sys/smp.h
#include dev/pci/pcivar.h
+#include machine/atomic.h
#include machine/bus.h
-#include sys/rman.h
#ifdef __ia64__
#include machine/pal.h
#endif
+#include sys/rman.h
#include acpi.h
#include dev/acpica/acpivar.h
@@ -77,9 +78,11 @@
device_tcpu_dev;
ACPI_HANDLE cpu_handle;
uint32_tcpu_id;/* ACPI processor id */
+uint32_tcpu_p_blk; /* ACPI P_BLK location */
+uint32_tcpu_p_blk_len; /* P_BLK length (must be 6). */
struct resource*cpu_p_cnt; /* Throttling control register */
struct acpi_cx cpu_cx_states[MAX_CX_STATES];
-int cpu_bm_ok; /* Bus mastering control available. */
+int cpu_cx_count; /* Number of valid Cx states. */
};
#define CPU_GET_REG(reg, width)\
@@ -116,10 +119,9 @@
#define PCI_REVISION_4M3
/* Platform hardware resource information. */
-static uint32_t cpu_p_blk; /* ACPI P_BLK location */
-static uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */
static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */
static uint8_t cpu_pstate_cnt;/* Register to take over throttling. */
+static uint8_t cpu_cst_cnt; /* Indicate we are _CST aware. */
static uint32_t cpu_rid; /* Driver-wide resource id. */
static uint32_t cpu_quirks;/* Indicate any hardware bugs. */
@@ -128,6 +130,9 @@
static uint32_t cpu_cx_next; /* State to use for next sleep. */
static uint32_t cpu_non_c3;/* Index of lowest non-C3 state. */
static struct acpi_cx_stats cpu_cx_stats[MAX_CX_STATES];
+#ifdef SMP
+static int cpu_idle_busy; /* Count of CPUs in acpi_cpu_idle. */
+#endif
/* Values for sysctl. */
static uint32_t cpu_current_state;
@@ -146,11 +151,13 @@
static int acpi_cpu_probe(device_t dev);
static int acpi_cpu_attach(device_t dev);
+static int acpi_cpu_detach(device_t dev);
static int acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
static voidacpi_cpu_startup(void *arg);
static voidacpi_cpu_startup_throttling(void);
+static voidacpi_cpu_startup_cx(void);
static voidacpi_cpu_throttle_set(uint32_t speed);
static voidacpi_cpu_idle(void);
static voidacpi_cpu_c1(void);
@@ -166,6 +173,8 @@
/* Device interface */
DEVMETHOD(device_probe,acpi_cpu_probe),
DEVMETHOD(device_attach, acpi_cpu_attach),
+DEVMETHOD(device_detach, acpi_cpu_detach),
+DEVMETHOD(device_shutdown, acpi_cpu_detach),
{0, 0}
};
@@ -178,6
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Nate Lawson wrote: Ok, here's the final patch. I believe it fixes both problems. Success! The system rebooted without panicking. It even came back up cleanly. :-) In an earlier e-mail, you asked me for dmesg output. I've attached it on the off chance you still want it. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories * Add a DEVMETHOD for acpi so that child detach methods get called. Add an acpi_cpu method for both detach and shutdown that disables entry to acpi_cpu_idle and then IPIs/waits for threads to exit. This fixes a panic late in reboot in the SMP case. * In the !SMP case, don't use the processor id filled out by the MADT since there can only be one processor. This was causing a panic in acpi_cpu_idle if the id was 1 since the data was being dereferenced from cpu_softc[1] even though the actual data was in cpu_softc[0] (which is correct). * Rework the initialization functions so that cpu_idle_hook is written late in the boot process. * Make the P_BLK, P_BLK_LEN, and cpu_cx_count all softc-local variables. This will help SMP boxes that have _CST or multiple P_BLKs. No such boxes are known at this time. * Always allocate the C1 state, even if the P_BLK is invalid. This means we will always take over idling if enabled. Remove the value -1 as valid for cx_lowest since this is redundant with machdep.cpu_idle_hlt. * Reduce locking for the throttle initialization case to around the write to the smi_cmd port. Add disabled code to write the CST_CNT. It will be enabled once _CST re-evaluation is tested (post 5.2R). Thank you:dfr, imp, jhb, marcel, peter -Nate Index: sys/dev/acpica/acpi_cpu.c === RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v retrieving revision 1.19 diff -u -r1.19 acpi_cpu.c --- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 - 1.19 +++ sys/dev/acpica/acpi_cpu.c 19 Nov 2003 15:21:07 - @@ -1,5 +1,5 @@ /*- - * Copyright (c) 2003 Nate Lawson + * Copyright (c) 2003 Nate Lawson (SDG) * Copyright (c) 2001 Michael Smith * All rights reserved. * @@ -30,20 +30,21 @@ #include opt_acpi.h #include sys/param.h -#include sys/kernel.h -#include sys/proc.h #include sys/bus.h +#include sys/kernel.h +#include sys/pcpu.h #include sys/power.h +#include sys/proc.h #include sys/sbuf.h -#include sys/pcpu.h #include sys/smp.h #include dev/pci/pcivar.h +#include machine/atomic.h #include machine/bus.h -#include sys/rman.h #ifdef __ia64__ #include machine/pal.h #endif +#include sys/rman.h #include acpi.h #include dev/acpica/acpivar.h @@ -77,9 +78,11 @@ device_t cpu_dev; ACPI_HANDLE cpu_handle; uint32_t cpu_id;/* ACPI processor id */ +uint32_t cpu_p_blk; /* ACPI P_BLK location */ +uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */ struct resource *cpu_p_cnt; /* Throttling control register */ struct acpi_cxcpu_cx_states[MAX_CX_STATES]; -int cpu_bm_ok; /* Bus mastering control available. */ +int cpu_cx_count; /* Number of valid Cx states. */ }; #define CPU_GET_REG(reg, width) \ @@ -116,10 +119,9 @@ #define PCI_REVISION_4M 3 /* Platform hardware resource information. */ -static uint32_t cpu_p_blk; /* ACPI P_BLK location */ -static uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */ static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */ static uint8_tcpu_pstate_cnt;/* Register to take over throttling. */ +static uint8_tcpu_cst_cnt; /* Indicate we are _CST aware. */ static uint32_t cpu_rid; /* Driver-wide resource id. */ static uint32_t cpu_quirks;/* Indicate any hardware bugs. */ @@ -128,6 +130,9 @@ static uint32_t cpu_cx_next; /* State to use for next sleep. */ static uint32_t cpu_non_c3;/* Index of lowest non-C3 state. */ static struct acpi_cx_stats cpu_cx_stats[MAX_CX_STATES]; +#ifdef SMP +static intcpu_idle_busy; /* Count of CPUs in acpi_cpu_idle. */ +#endif /* Values for sysctl. */ static uint32_t cpu_current_state; @@ -146,11 +151,13 @@ static int acpi_cpu_probe(device_t dev); static int acpi_cpu_attach(device_t dev); +static int acpi_cpu_detach(device_t dev); static int acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc); static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc); static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc); static void acpi_cpu_startup(void *arg); static void acpi_cpu_startup_throttling(void); +static void
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Robert Watson wrote: On Wed, 19 Nov 2003, Nate Lawson wrote: Ok, here's the final patch. I believe it fixes both problems. Success! The system rebooted without panicking. It even came back up cleanly. :-) Good to hear. I think Don has the same problem as Harald so perhaps he can report on the patch. In an earlier e-mail, you asked me for dmesg output. I've attached it on the off chance you still want it. Looks great! sysctl hw.acpi.cpu? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Nate Lawson wrote: On Wed, 19 Nov 2003, Robert Watson wrote: On Wed, 19 Nov 2003, Nate Lawson wrote: Ok, here's the final patch. I believe it fixes both problems. Success! The system rebooted without panicking. It even came back up cleanly. :-) Good to hear. I think Don has the same problem as Harald so perhaps he can report on the patch. In an earlier e-mail, you asked me for dmesg output. I've attached it on the off chance you still want it. Looks great! sysctl hw.acpi.cpu? crash2:~ sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 2902705/0 Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Robert Watson wrote: On Wed, 19 Nov 2003, Nate Lawson wrote: On Wed, 19 Nov 2003, Robert Watson wrote: Success! The system rebooted without panicking. It even came back up cleanly. :-) Good to hear. I think Don has the same problem as Harald so perhaps he can report on the patch. In an earlier e-mail, you asked me for dmesg output. I've attached it on the off chance you still want it. Looks great! sysctl hw.acpi.cpu? crash2:~ sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 2902705/0 Ok, this is correct. Hopefully SMP boxes in the future will have multiple P_BLKs and/or _CST and we can have better power savings. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Wednesday 19 November 2003 16:31, Nate Lawson wrote: Ok, here's the final patch. I believe it fixes both problems. *SCHNIP* Yep, seems really final. I downloaded the acpi_cpi.c from cvs-web to be sure to have the correct one and applied your patch. hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 27743/0 No Problems at booting/rebooting Attached my dmesg but it doesn't show anything unusual/debug. Thanks, -Harry Copyright (c) 1992-2003 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.1-CURRENT #50: Wed Nov 19 21:01:37 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE Preloaded elf kernel /boot/kernel/kernel at 0xc09d9000. Preloaded elf module /boot/kernel/linux.ko at 0xc09d9244. Preloaded elf module /boot/kernel/nvidia.ko at 0xc09d92f0. ACPI APIC Table: D815EA EA81510A Timecounter i8254 frequency 1183576 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 Version 2.0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07760c2 (122) VESA: NVIDIA acpi0: D815EA D815EPFV on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2a10 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU port 0x530-0x537 on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci2: PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci1: ACPI PCI bus on pcib2 fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: MII bus on fxp0 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ichsmb0: Intel 82801BA (ICH2) SMBus controller port 0xefa0-0xefaf irq 17 at device 31.3 on pci0 smbus0: System Management Bus on ichsmb0 smb0: SMBus generic I/O on smbus0 uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xef80-0xef9f irq 23 at device 31.4 on pci0 usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub2: Standard Microsystems product 0x0140, class 9/0, rev 1.10/0.00, addr 2 uhub2: 4 ports with 4 removable, self powered ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. uhub3: Texas Instruments General Purpose USB Hub, class 9/0, rev 1.10/1.01, addr 4 uhub3: 2 ports with 2 removable, bus powered pcm0: Intel ICH2 (82801BA) port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on pci0 pcm0: Analog Devices AD1885 AC97 Codec atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface orm0: Option ROMs at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 12 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 1095817986 Hz quality 800 Timecounters tick every 1.000 msec GEOM: create disk ad0 dp=0xc2dbbd60 ad0: 39083MB Maxtor 4D040H2 [79408/16/63] at ata0-master UDMA100 acd0: CDROM SONY CDU4811 at ata1-master
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Harald Schmalzbauer wrote: On Wednesday 19 November 2003 16:31, Nate Lawson wrote: Ok, here's the final patch. I believe it fixes both problems. *SCHNIP* Yep, seems really final. I downloaded the acpi_cpi.c from cvs-web to be sure to have the correct one and applied your patch. hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 27743/0 No Problems at booting/rebooting Thanks, I'll commit it now. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote: Below you'll find the update patch for acpi_cpu. Please test this, especially for SMP and laptops with _CST objects in their ASL. Looks good here on a Centrino based laptop, which has a _CST method in its ASL: acpi_cpu0: CPU on acpi0 acpi_cpu0: C2 state 1 lat acpi_cpu0: C3 state 85 lat hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 86231/0 0/0 0/0 Although it seems I have lost a C3 state (before, I had an additional C3/185). regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Lukas Ertl wrote: hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 86231/0 0/0 0/0 Although it seems I have lost a C3 state (before, I had an additional C3/185). Correction: every other boot I get the additional C3/185 - strange, indeed. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote:
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
...
Notes:
* Add a detach method that disables entry to acpi_cpu_idle and in the SMP
case, IPIs all processors to exit sleeping. This fixes a panic on
shutdown for MP boxes.
Sigh, I appear to have been mistaken about the SMP reboot problem being
fixed, sorry about that. Mark's random_harvest panic appears to have
caused me to miss the other failure mode in my last test. Stack trace
attached, and I believe I'm running with your latest patch.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
crash2# reboot
boot() called on cpu#0
Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped
syncing disks, buffers remaining...
done
Uptime: 1m4s
Shutting down ACPI
terneRle btoroatpi n1g2. .w.i
h interrupts disabled
panic: Assertion td-td_turnstile != NULL failed at
../../../kern/subr_turnstile
.c:437
cpuid = 1;
Debugger(panic)
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db trace
Debugger(c08975c7,1,c0896aca,c8f389f4,100) at Debugger+0x55
panic(c0896aca,c089a415,c089a1f2,1b5,c0959398) at panic+0x156
turnstile_wait(c20e1280,c0955320,c2007640,1cc,c101bfe4) at
turnstile_wait+0x2ac
_mtx_lock_sleep(c0955320,0,c08ad7ae,df,0) at _mtx_lock_sleep+0x125
_mtx_lock_flags(c0955320,0,c08ad7ae,df,a) at _mtx_lock_flags+0x98
vm_fault(c0951d00,0,1,0,c1380640) at vm_fault+0x5a
trap_pfault(c8f38c04,0,9c,fc,9c) at trap_pfault+0x109
trap(c1380018,c8f30010,c0660010,0,10) at trap+0x333
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc047c619, esp = 0xc8f38c44, ebp = 0xc8f38c64 ---
AcpiHwLowLevelRead(10,c8f38c80,94,10,0) at AcpiHwLowLevelRead+0x19
AcpiHwRegisterRead(0,1,c8f38ca0,0,c137fc5c) at AcpiHwRegisterRead+0x71
AcpiGetRegister(1,c8f38ccc,0,3e8,0) at AcpiGetRegister+0x61
acpi_cpu_idle(c8f38d0c,c0658f4c,c0955320,2,c089533f) at acpi_cpu_idle+0x5e
cpu_idle(c0955320,2,c089533f,53,14b) at cpu_idle+0x28
idle_proc(0,c8f38d48,c08951f4,311,e8241c89) at idle_proc+0x3c
fork_exit(c0658f10,0,c8f38d48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xc8f38d7c, ebp = 0 ---
db
(kgdb) bt
#0 0xc081317b in Debugger (msg=0x12 Address 0x12 out of bounds)
at machine/atomic.h:263
#1 0xc066db36 in panic (fmt=0xc0896aca Assertion %s failed at %s:%d)
at ../../../kern/kern_shutdown.c:534
#2 0xc0693c8c in turnstile_wait (ts=0xc20e1280, lock=0xc0955320,
owner=0xc2007640) at ../../../kern/subr_turnstile.c:469
#3 0xc0664125 in _mtx_lock_sleep (m=0xc0955320, opts=0,
file=0xc08ad7ae ../../../vm/vm_fault.c, line=223)
at ../../../kern/kern_mutex.c:476
#4 0xc0663c88 in _mtx_lock_flags (m=0xc0955320, opts=0,
file=0xc08ad7ae ../../../vm/vm_fault.c, line=223)
at ../../../kern/kern_mutex.c:218
#5 0xc07d39fa in vm_fault (map=0xc0951d00, vaddr=0, fault_type=1 '\001',
fault_flags=0) at ../../../vm/vm_fault.c:223
#6 0xc0829159 in trap_pfault (frame=0xc8f38c04, usermode=0, eva=156)
at ../../../i386/i386/trap.c:711
#7 0xc0828dd3 in trap (frame=
{tf_fs = -1053294568, tf_es = -923598832, tf_ds = -1067057136,
tf_edi = 0, tf_esi = 16, tf_ebp = -923562908, tf_isp = -923562960, tf_ebx
= -923562880, tf_edx = -1, tf_ecx = 148, tf_eax = -923562880, tf_trapno =
12, tf_err = 0, tf_eip = -1069038055, tf_cs = 8, tf_eflags = 65538, tf_esp
= 1024, tf_ss = -923562880}) at ../../../i386/i386/trap.c:420
#8 0xc08148b8 in calltrap () at {standard input}:94
#9 0xc047c321 in AcpiHwRegisterRead (UseLock=0 '\0', RegisterId=16,
ReturnValue=0x12) at ../../../contrib/dev/acpica/hwregs.c:601
#10 0xc047c071 in AcpiGetRegister (RegisterId=18, ReturnValue=0x12,
Flags=0)
at ../../../contrib/dev/acpica/hwregs.c:375
#11 0xc0499ebe in acpi_cpu_idle () at ../../../dev/acpica/acpi_cpu.c:798
#12 0xc081d2d8 in cpu_idle () at ../../../i386/i386/machdep.c:1071
#13 0xc0658f4c in idle_proc (dummy=0x0) at ../../../kern/kern_idle.c:86
#14 0xc0658c44 in fork_exit (callout=0xc0658f10 idle_proc, arg=0x12,
frame=0x12) at ../../../kern/kern_fork.c:793
(kgdb) l *AcpiHwLowLevelRead+0x19
0xc047c619 is in AcpiHwLowLevelRead (../../../contrib/dev/acpica/hwregs.c:836).
831 /*
832 * Must have a valid pointer to a GAS structure, and
833 * a non-zero address within. However, don't return an error
834 * because the PM1A/B code must not fail if B isn't present.
835 */
836 if ((!Reg) ||
837 (!ACPI_VALID_ADDRESS (Reg-Address)))
838 {
839 return (AE_OK);
840 }
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Lukas Ertl wrote:
On Tue, 18 Nov 2003, Nate Lawson wrote:
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
Looks good here on a Centrino based laptop, which has a _CST method in
its ASL:
acpi_cpu0: CPU on acpi0
acpi_cpu0: C2 state 1 lat
acpi_cpu0: C3 state 85 lat
I'll be moving some printfs under bootverbose before release.
hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85
hw.acpi.cpu.cx_lowest: 0
hw.acpi.cpu.cx_history: 86231/0 0/0 0/0
Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is
available). I'm interested in any benchmark results, especially IO. I'm
hoping the scheduling of sleeps is good enough that you don't experience
much performance loss even with lower sleeps.
Although it seems I have lost a C3 state (before, I had an additional
C3/185).
_CST can change dynamically at runtime. If you booted with the AC adapter
attached, your laptop may not offer all the sleep states. When you unplug
the AC adapter, we get a notify on _CST to re-evaluate it and look for new
states. However, that code is currently disabled due to complex locking
issues (i.e. what to do when a Cx state is being accessed but _CST is
being re-evaluated). _CST re-evaluation won't be enabled until after
5.2R. However, you can reboot your laptop with the AC adapter detached
(or attached) to see what states are available.
This excerpt from truckman@'s asl shows that 4 Cx states are only
available when the AC adapter is not attached. (The C*NA memory addresses
appear to be managed by the BIOS and not the AML but the PSR access is
clear).
Method (_CST, 0, NotSerialized)
{
If (\C2NA)
{
Return (CST1)
}
If (\C3NA)
{
Return (CST2)
}
If (\_SB.PCI0.LPC.EC.AC._PSR ())
{
Return (CST3)
}
If (\C4NA)
{
Return (CST3)
}
Return (CST4)
}
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Robert Watson wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: Below you'll find the update patch for acpi_cpu. Please test this, especially for SMP and laptops with _CST objects in their ASL. ... Notes: * Add a detach method that disables entry to acpi_cpu_idle and in the SMP case, IPIs all processors to exit sleeping. This fixes a panic on shutdown for MP boxes. Sigh, I appear to have been mistaken about the SMP reboot problem being fixed, sorry about that. Mark's random_harvest panic appears to have caused me to miss the other failure mode in my last test. Stack trace attached, and I believe I'm running with your latest patch. Could you add a printf to the start of acpi_cpu_detach()? I want to see if we're being called before or after ACPI is stopped (Shutting down ACPI). Also, please do: l *AcpiGetRegister+0x61 I think it's the call to get the bus master status, which is interesting since this means that cpu_cx_count != 0 which means that acpi_cpu_detach hasn't run yet. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote: On Tue, 18 Nov 2003, Lukas Ertl wrote: hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 86231/0 0/0 0/0 Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is available). I'm interested in any benchmark results, especially IO. I'm hoping the scheduling of sleeps is good enough that you don't experience much performance loss even with lower sleeps. I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. Although it seems I have lost a C3 state (before, I had an additional C3/185). _CST can change dynamically at runtime. If you booted with the AC adapter attached, your laptop may not offer all the sleep states. When you unplug the AC adapter, we get a notify on _CST to re-evaluate it and look for new states. However, that code is currently disabled due to complex locking issues (i.e. what to do when a Cx state is being accessed but _CST is being re-evaluated). _CST re-evaluation won't be enabled until after 5.2R. However, you can reboot your laptop with the AC adapter detached (or attached) to see what states are available. Ah, yes, that would explain it - I just booted on battery. This excerpt from truckman@'s asl shows that 4 Cx states are only available when the AC adapter is not attached. (The C*NA memory addresses appear to be managed by the BIOS and not the AML but the PSR access is clear). This part of the ASL looks the one here - let me guess, is it a ThinkPad? :-) regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Lukas Ertl wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is available). I'm interested in any benchmark results, especially IO. I'm hoping the scheduling of sleeps is good enough that you don't experience much performance loss even with lower sleeps. I'm gonna try some buildkernelstones with the different settings. If you have some special benchmarks in mind I'd be happy to run them. That's probably ok. It has a lot of IO. This excerpt from truckman@'s asl shows that 4 Cx states are only available when the AC adapter is not attached. (The C*NA memory addresses appear to be managed by the BIOS and not the AML but the PSR access is clear). This part of the ASL looks the one here - let me guess, is it a ThinkPad? :-) Yes, R40. I'm scared because I'm beginning to recognize chipsets by their ASL organization. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote:
On Tue, 18 Nov 2003, Robert Watson wrote:
On Tue, 18 Nov 2003, Nate Lawson wrote:
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
...
Notes:
* Add a detach method that disables entry to acpi_cpu_idle and in the SMP
case, IPIs all processors to exit sleeping. This fixes a panic on
shutdown for MP boxes.
Sigh, I appear to have been mistaken about the SMP reboot problem being
fixed, sorry about that. Mark's random_harvest panic appears to have
caused me to miss the other failure mode in my last test. Stack trace
attached, and I believe I'm running with your latest patch.
Could you add a printf to the start of acpi_cpu_detach()? I want to see
if we're being called before or after ACPI is stopped (Shutting down
I modified acpi_cpu_detach:
+acpi_cpu_detach(device_t dev)
+{
+
+printf(\nacpi_cpu_detach\n\n);
+
But sure enough:
syncing disks, buffers remaining...
done
Uptime: 56s
Shutting down ACPI
kernel trap 12 with interrupts disabled
tanicR:e bAososteirntgi.o.n.
d-td_turnstile != NULL failed at ../../../kern/subr_turnstile.c:437
cpuid = 0;
Debugger(panic)
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db
So indeed, it doesn't look like the ACPI detach call has gone out yet.
ACPI). Also, please do:
l *AcpiGetRegister+0x61
I think it's the call to get the bus master status, which is interesting
since this means that cpu_cx_count != 0 which means that acpi_cpu_detach
hasn't run yet.
This is using the existing crash from the trace I sent you previously.
(kgdb) l *AcpiGetRegister+0x61
0xc047c071 is in AcpiGetRegister
(../../../contrib/dev/acpica/hwregs.c:375).
370 {
371 return_ACPI_STATUS (Status);
372 }
373 }
374
375 Status = AcpiHwRegisterRead (ACPI_MTX_DO_NOT_LOCK,
376 BitRegInfo-ParentRegister, RegisterValue);
377
378 if (Flags ACPI_MTX_LOCK)
379 {
Also potentially useful information:
(kgdb) inspect cpu_cx_count
$1 = 1
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Robert Watson wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: Could you add a printf to the start of acpi_cpu_detach()? I want to see if we're being called before or after ACPI is stopped (Shutting down So indeed, it doesn't look like the ACPI detach call has gone out yet. Yes, I'm certain acpi_cpu_detach is not being called before AcpiTerminate(). Can someone with some newbus knowledge explain this? devinfo shows acpi_cpu0 as a child of acpi0 so its detach should be called before acpi0's. Perhaps the fact that there is no DEVMETHOD for acpi_detach means that its children never have their detach methods called? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On 18 Nov, Lukas Ertl wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: This excerpt from truckman@'s asl shows that 4 Cx states are only available when the AC adapter is not attached. (The C*NA memory addresses appear to be managed by the BIOS and not the AML but the PSR access is clear). This part of the ASL looks the one here - let me guess, is it a ThinkPad? :-) Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode when I run shutdown -p. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Don Lewis wrote: On 18 Nov, Lukas Ertl wrote: On Tue, 18 Nov 2003, Nate Lawson wrote: This excerpt from truckman@'s asl shows that 4 Cx states are only available when the AC adapter is not attached. (The C*NA memory addresses appear to be managed by the BIOS and not the AML but the PSR access is clear). This part of the ASL looks the one here - let me guess, is it a ThinkPad? :-) Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode when I run shutdown -p. That's an old problem that Linux is also trying to work around. It appears to be buggy hw. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 18 Nov 2003, Nate Lawson wrote: On Tue, 18 Nov 2003, Don Lewis wrote: Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode when I run shutdown -p. That's an old problem that Linux is also trying to work around. It appears to be buggy hw. Just for the record: shutdown -p works fine on the T40. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
