Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
Nate Lawson wrote: On Tue, 18 Nov 2003, Eric Anderson wrote: Nate Lawson wrote: cvsup to -current as of today would be a good first start. The code was committed Nov 15. Then boot with acpi enabled and post the output of sysctl hw.acpi.cpu. You can try different levels by doing sysctl hw.acpi.cpu.cx_lowest=x where x is 0...(number_supported_states - 1) Thanks! I've rebuilt and am happy to say that nothing is hosed and I booted successfully :) Here's my sysctl output: $ sysctl hw.acpi.cpu hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 4 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 4 You should run a benchmark with different values for hw.acpi.cpu.current_speed to be sure the throttling control still works ok. I left it mostly intact so you shouldn't see any problems but it's still good to test. As you change it, you should see dmesg output of "acpi_cpu0: set speed to xx%" I can change the hw.acpi.cpu.economy_speed value, but the current_speed is read only. When I set economy speed, it automatically bumps the current speed down to my economy value (as expected). However, no dmesg output. The only note I see is when going from AC to battery, I get: kernel: system power profile changed to 'economy' and of course going back to aAC shows 'performance' instead of economy. I never see any "set speed to xx%". hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 23589/0 0/0 0/0 0/0 I played with the different levels a bit, and can't tell much difference in them. Let me know what else I can try to break with this. Just for the info, I booted with a/c plugged in, but did the sysctl running on battery. You should set hw.acpi.cpu.cx_lowest to 1 regularly and 2 or 3 if you're using battery. This will save on heat. I'd also be interested in if you'd set it to 3 while on battery and run a typical workload for an hour and then send me the result of sysctl hw.acpi.cpu. The cx_history value helps me know if my scheduler is accurate. I'll try this tomorrow - anyway to get it to automatically set it to a value when going in to economy mode? Eric Anderson Systems Administrator Centaur Technology Say hi to Tom Crispin for me. :) He says "hi" :) (small world, eh?) On a side note - can I do anything with the "lid control switch" acpi piece? I'd like to make it turn off the screen and go into a sleep mode (it goes into sleep, but the screen stays lit up). Thanks for the great work! Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Tue, 18 Nov 2003, Eric Anderson wrote: > Nate Lawson wrote: > >cvsup to -current as of today would be a good first start. The code was > >committed Nov 15. Then boot with acpi enabled and post the output of > >sysctl hw.acpi.cpu. You can try different levels by doing sysctl > >hw.acpi.cpu.cx_lowest=x where x is 0...(number_supported_states - 1) > > > Thanks! I've rebuilt and am happy to say that nothing is hosed and I > booted successfully :) > > Here's my sysctl output: > $ sysctl hw.acpi.cpu > hw.acpi.cpu.max_speed: 8 > hw.acpi.cpu.current_speed: 4 > hw.acpi.cpu.performance_speed: 8 > hw.acpi.cpu.economy_speed: 4 You should run a benchmark with different values for hw.acpi.cpu.current_speed to be sure the throttling control still works ok. I left it mostly intact so you shouldn't see any problems but it's still good to test. As you change it, you should see dmesg output of "acpi_cpu0: set speed to xx%" > hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 23589/0 0/0 0/0 0/0 > > I played with the different levels a bit, and can't tell much difference > in them. Let me know what else I can try to break with this. Just for > the info, I booted with a/c plugged in, but did the sysctl running on > battery. You should set hw.acpi.cpu.cx_lowest to 1 regularly and 2 or 3 if you're using battery. This will save on heat. I'd also be interested in if you'd set it to 3 while on battery and run a typical workload for an hour and then send me the result of sysctl hw.acpi.cpu. The cx_history value helps me know if my scheduler is accurate. > Eric AndersonSystems Administrator Centaur Technology Say hi to Tom Crispin for me. :) -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
Nate Lawson wrote: Ok - what do I need to do to try this new acpi stuff out? I'm running -current as of Nov 14th, and I'd like to help debug/test this on my notebook.. cvsup to -current as of today would be a good first start. The code was committed Nov 15. Then boot with acpi enabled and post the output of sysctl hw.acpi.cpu. You can try different levels by doing sysctl hw.acpi.cpu.cx_lowest=x where x is 0...(number_supported_states - 1) Thanks! I've rebuilt and am happy to say that nothing is hosed and I booted successfully :) Here's my sysctl output: $ sysctl hw.acpi.cpu hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 4 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 4 hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 23589/0 0/0 0/0 0/0 I played with the different levels a bit, and can't tell much difference in them. Let me know what else I can try to break with this. Just for the info, I booted with a/c plugged in, but did the sysctl running on battery. Thanks Nate for the hints.. Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Tue, 18 Nov 2003, Eric Anderson wrote: > >And here is what you requested in your first patch: > > > >cale:~> sysctl hw.acpi.cpu > >hw.acpi.cpu.cx_supported: C1/0 > >hw.acpi.cpu.cx_lowest: 0 > >hw.acpi.cpu.cx_history: 0/0 > > Ok - what do I need to do to try this new acpi stuff out? I'm running > -current as of Nov 14th, and I'd like to help debug/test this on my > notebook.. cvsup to -current as of today would be a good first start. The code was committed Nov 15. Then boot with acpi enabled and post the output of sysctl hw.acpi.cpu. You can try different levels by doing sysctl hw.acpi.cpu.cx_lowest=x where x is 0...(number_supported_states - 1) -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Wednesday 19 November 2003 02:09, Eric Anderson wrote:
> Harald Schmalzbauer wrote:
> >On Tuesday 18 November 2003 18:58, you wrote:
> >>On Tue, 18 Nov 2003, Harald Schmalzbauer wrote:
> >>>On Tuesday 18 November 2003 03:37, you wrote:
> Sorry I wasn't more clear. I need you to print the contents like this:
> print *cpu_cx_count
> >>>
> >>>cpu_cx_count 1
> >>>cpu_cx_lowest 0
> >>>cpu_idle_hook c0468300
> >>>cpu_cx_next 0
> >>>
> >>>I hope these are the correct values.
> >>
> >>Thanks, those are the correct values for your box. I just posted a patch
> >>that should address the boot-time panic. Please revert old patches and
> >>try it.
> >
> >Yep, this looks good. Perhaps you're interested in the following line
> > which arose for the first time during boot:
> >
> >C0? cx_next 0 cx_count 1
> >
> >And here is what you requested in your first patch:
> >
> >cale:~> sysctl hw.acpi.cpu
> >hw.acpi.cpu.cx_supported: C1/0
> >hw.acpi.cpu.cx_lowest: 0
> >hw.acpi.cpu.cx_history: 0/0
>
> Ok - what do I need to do to try this new acpi stuff out? I'm running
> -current as of Nov 14th, and I'd like to help debug/test this on my
> notebook..
Try the patch Nate posted in "Updated acpi_cpu patch". For convinience I
attached it. That's all I can tell you.
-Harry
>
> Eric
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 18 Nov 2003 17:46:23 -
@@ -1,5 +1,5 @@
/*-
- * Copyright (c) 2003 Nate Lawson
+ * Copyright (c) 2003 Nate Lawson (SDG)
* Copyright (c) 2001 Michael Smith
* All rights reserved.
*
@@ -77,9 +77,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_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 +118,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_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. */
@@ -146,11 +147,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 acpi_cpu_startup_cx(void);
static void acpi_cpu_throttle_set(uint32_t speed);
static void acpi_cpu_idle(void);
static void acpi_cpu_c1(void);
@@ -166,6 +169,7 @@
/* Device interface */
DEVMETHOD(device_probe, acpi_cpu_probe),
DEVMETHOD(device_attach, acpi_cpu_attach),
+DEVMETHOD(device_detach, acpi_cpu_detach),
{0, 0}
};
@@ -178,6 +182,7 @@
static devclass_t acpi_cpu_devclass;
DRIVER_MODULE(acpi_cpu, acpi, acpi_cpu_driver, acpi_cpu_devclass, 0, 0);
+
static int
acpi_cpu_probe(device_t dev)
{
@@ -272,11 +277,10 @@
AcpiEvaluateObject(sc->cpu_handle, "_INI", NULL, NULL);
/* Get various global values from the Processor object. */
-cpu_p_blk = pobj.Processor.PblkAddress;
-cpu_p_blk_len = pobj.Processor.PblkLength;
+sc->cpu_p_blk = pobj.Processor.PblkAddress;
+sc->cpu_p_blk_len = pobj.Processor.PblkLength;
ACPI_DEBUG_PRINT((ACPI_DB_IO, "acpi_cpu%d: P_BLK at %#x/%d%s\n",
- device_get_unit(dev), cpu_p_blk, cpu_p_blk_len,
- sc->cpu_p_cnt ? "" : " (shadowed)"));
+ device_get_unit(dev), sc->cpu_p_blk, sc->cpu_p_blk_len));
acpi_sc = acpi_device_get_parent_softc(dev);
sysctl_ctx_init(&acpi_cpu_sysctl_ctx);
@@ -297,7 +301,8 @@
if (thr_ret == 0 || cx_ret == 0) {
status = AcpiInstallNotifyHandler(sc->cpu_handle, ACPI_DEVICE_NOTIFY,
acpi_cpu_notify, sc);
- AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, sc);
+ if (device_get_unit(dev) == 0)
+ AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, NULL);
} else {
sysctl_ctx_free(&acpi_cpu_sysctl_ctx);
}
@@ -306,6 +311,21 @@
}
static int
+acpi_cpu_detach(device_t dev)
+{
+
+/* Disable any entry to the idle funct
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
Harald Schmalzbauer wrote: On Tuesday 18 November 2003 18:58, you wrote: On Tue, 18 Nov 2003, Harald Schmalzbauer wrote: On Tuesday 18 November 2003 03:37, you wrote: Sorry I wasn't more clear. I need you to print the contents like this: print *cpu_cx_count cpu_cx_count 1 cpu_cx_lowest 0 cpu_idle_hook c0468300 cpu_cx_next 0 I hope these are the correct values. Thanks, those are the correct values for your box. I just posted a patch that should address the boot-time panic. Please revert old patches and try it. Yep, this looks good. Perhaps you're interested in the following line which arose for the first time during boot: C0? cx_next 0 cx_count 1 And here is what you requested in your first patch: cale:~> sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 0/0 Ok - what do I need to do to try this new acpi stuff out? I'm running -current as of Nov 14th, and I'd like to help debug/test this on my notebook.. Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Tuesday 18 November 2003 18:58, you wrote: > On Tue, 18 Nov 2003, Harald Schmalzbauer wrote: > > On Tuesday 18 November 2003 03:37, you wrote: > > > Sorry I wasn't more clear. I need you to print the contents like this: > > > print *cpu_cx_count > > > > cpu_cx_count 1 > > cpu_cx_lowest 0 > > cpu_idle_hook c0468300 > > cpu_cx_next 0 > > > > I hope these are the correct values. > > Thanks, those are the correct values for your box. I just posted a patch > that should address the boot-time panic. Please revert old patches and > try it. Yep, this looks good. Perhaps you're interested in the following line which arose for the first time during boot: C0? cx_next 0 cx_count 1 And here is what you requested in your first patch: cale:~> sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 0/0 How do I know when this will be comitted to . Thanks a lot, -Harry > > -Nate pgp0.pgp Description: signature
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Monday 17 November 2003 18:45, Nate Lawson wrote:
> On Mon, 17 Nov 2003, Harald Schmalzbauer wrote:
> > On Sunday 16 November 2003 21:11, Nate Lawson wrote:
> > > The panic you see is a result of the new acpi_cpu driver, not ULE. In
> > > any case, it appears that acpi_cpu_idle is being called and trying to
> > > read one of the processor control registers before they are present.
> > > Please send me privately the output of:
> > >acpidump -t -d > harald-MachineType.asl
> > >
> > > As a workaround, please set this in loader.conf:
> > >debug.acpi.disable="cpu"
> > >
> > > That will allow you to get running and give me some time to look into
> > > this.
> >
> > Now I followed your advise and found out the following (source from some
> > hours ago, 4BSD scheduler, and the acpidump went away to you by private
> > mail) The panic only occurs if the nvidia.ko module is was loaded.
> > I use it straight from the ports.
> > But your sysctl tweak keeps the whole thing working (I'm writing with
> > kmail)!
>
> Please try the patch below. It does more than fix your problem but the
> other changes will be needed eventually anyways. If your system boots ok,
> please send me the output of sysctl hw.acpi.cpu
>
> Also, be sure to comment out the disable CPU line in loader.conf while
> testing the patch.
Sorry, things got worse. Now it panics even if the nvidia module is not
loaded.
But the debug.acpi.disable="cpu" tweak is still working. I'm using the kernel
with your patch(es) at the moment.
cale:/home/harry# sysctl hw.acpi.cpu
sysctl: unknown oid 'hw.acpi.cpu'
Thanks a lot,
-Harry
>
> Thanks,
> 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 17 Nov 2003 17:39:54 -
> @@ -78,8 +78,8 @@
> ACPI_HANDLE cpu_handle;
> uint32_t cpu_id;/* ACPI processor id */
> struct resource *cpu_p_cnt; /* Throttling control register */
> +int cpu_cx_count; /* Number of valid Cx states. */
> struct acpi_cxcpu_cx_states[MAX_CX_STATES];
> -int cpu_bm_ok; /* Bus mastering control available. */
> };
>
> #define CPU_GET_REG(reg, width) \
> @@ -151,6 +151,7 @@
> 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 acpi_cpu_startup_cx(void);
> static void acpi_cpu_throttle_set(uint32_t speed);
> static void acpi_cpu_idle(void);
> static void acpi_cpu_c1(void);
> @@ -406,8 +407,7 @@
> {
> ACPI_GENERIC_ADDRESS gas;
> struct acpi_cx *cx_ptr;
> -struct sbuf sb;
> -int i, error;
> +int error;
>
> /* Bus mastering arbitration control is needed for C3. */
> if (AcpiGbl_FADT->V1_Pm2CntBlk == 0 || AcpiGbl_FADT->Pm2CntLen == 0) {
> @@ -420,11 +420,9 @@
> * First, check for the ACPI 2.0 _CST sleep states object.
> * If not usable, fall back to the P_BLK's P_LVL2 and P_LVL3.
> */
> -cpu_cx_count = 0;
> +sc->cpu_cx_count = 0;
> error = acpi_cpu_cx_cst(sc);
> if (error != 0) {
> - if (cpu_p_blk_len != 6)
> - return (ENXIO);
> cx_ptr = sc->cpu_cx_states;
>
> /* C1 has been required since just after ACPI 1.0 */
> @@ -432,7 +430,10 @@
> cx_ptr->trans_lat = 0;
> cpu_non_c3 = 0;
> cx_ptr++;
> - cpu_cx_count++;
> + sc->cpu_cx_count++;
> +
> + if (cpu_p_blk_len != 6)
> + goto done;
>
> /* Validate and allocate resources for C2 (P_LVL2). */
> gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO;
> @@ -446,7 +447,7 @@
> cx_ptr->trans_lat = AcpiGbl_FADT->Plvl2Lat;
> cpu_non_c3 = 1;
> cx_ptr++;
> - cpu_cx_count++;
> + sc->cpu_cx_count++;
> }
> }
>
> @@ -461,40 +462,16 @@
> cx_ptr->type = ACPI_STATE_C3;
> cx_ptr->trans_lat = AcpiGbl_FADT->Plvl3Lat;
> cx_ptr++;
> - cpu_cx_count++;
> + sc->cpu_cx_count++;
> }
> }
> }
>
> +done:
> /* If no valid registers were found, don't attach. */
> -if (cpu_cx_count == 0)
> +if (sc->cpu_cx_count == 0)
> return (ENXIO);
>
> -sbuf_new(&sb, cpu_cx_supported, sizeof(cpu_cx_supported),
> SBUF_FIXEDLEN); -for (i = 0; i < cpu_cx_count; i++) {
> - sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type,
> - sc->cpu_cx_states[i].trans_lat);
> -}
> -sbuf_trim(&sb);
> -sbuf_finish(&sb);
> -SYSCTL_ADD_STRING(&acpi_cpu_sysctl_ctx,
> - SYSCTL_CHILDR
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Mon, 17 Nov 2003, Harald Schmalzbauer wrote:
> On Sunday 16 November 2003 21:11, Nate Lawson wrote:
> > The panic you see is a result of the new acpi_cpu driver, not ULE. In any
> > case, it appears that acpi_cpu_idle is being called and trying to read one
> > of the processor control registers before they are present. Please send
> > me privately the output of:
> >acpidump -t -d > harald-MachineType.asl
> >
> > As a workaround, please set this in loader.conf:
> >debug.acpi.disable="cpu"
> >
> > That will allow you to get running and give me some time to look into
> > this.
>
> Now I followed your advise and found out the following (source from some hours
> ago, 4BSD scheduler, and the acpidump went away to you by private mail)
> The panic only occurs if the nvidia.ko module is was loaded.
> I use it straight from the ports.
> But your sysctl tweak keeps the whole thing working (I'm writing with kmail)!
Please try the patch below. It does more than fix your problem but the
other changes will be needed eventually anyways. If your system boots ok,
please send me the output of sysctl hw.acpi.cpu
Also, be sure to comment out the disable CPU line in loader.conf while
testing the patch.
Thanks,
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 17 Nov 2003 17:39:54 -
@@ -78,8 +78,8 @@
ACPI_HANDLE cpu_handle;
uint32_tcpu_id;/* ACPI processor id */
struct resource*cpu_p_cnt; /* Throttling control register */
+int cpu_cx_count; /* Number of valid Cx states. */
struct acpi_cx cpu_cx_states[MAX_CX_STATES];
-int cpu_bm_ok; /* Bus mastering control available. */
};
#define CPU_GET_REG(reg, width)\
@@ -151,6 +151,7 @@
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);
@@ -406,8 +407,7 @@
{
ACPI_GENERIC_ADDRESS gas;
struct acpi_cx *cx_ptr;
-struct sbuf sb;
-int i, error;
+int error;
/* Bus mastering arbitration control is needed for C3. */
if (AcpiGbl_FADT->V1_Pm2CntBlk == 0 || AcpiGbl_FADT->Pm2CntLen == 0) {
@@ -420,11 +420,9 @@
* First, check for the ACPI 2.0 _CST sleep states object.
* If not usable, fall back to the P_BLK's P_LVL2 and P_LVL3.
*/
-cpu_cx_count = 0;
+sc->cpu_cx_count = 0;
error = acpi_cpu_cx_cst(sc);
if (error != 0) {
- if (cpu_p_blk_len != 6)
- return (ENXIO);
cx_ptr = sc->cpu_cx_states;
/* C1 has been required since just after ACPI 1.0 */
@@ -432,7 +430,10 @@
cx_ptr->trans_lat = 0;
cpu_non_c3 = 0;
cx_ptr++;
- cpu_cx_count++;
+ sc->cpu_cx_count++;
+
+ if (cpu_p_blk_len != 6)
+ goto done;
/* Validate and allocate resources for C2 (P_LVL2). */
gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO;
@@ -446,7 +447,7 @@
cx_ptr->trans_lat = AcpiGbl_FADT->Plvl2Lat;
cpu_non_c3 = 1;
cx_ptr++;
- cpu_cx_count++;
+ sc->cpu_cx_count++;
}
}
@@ -461,40 +462,16 @@
cx_ptr->type = ACPI_STATE_C3;
cx_ptr->trans_lat = AcpiGbl_FADT->Plvl3Lat;
cx_ptr++;
- cpu_cx_count++;
+ sc->cpu_cx_count++;
}
}
}
+done:
/* If no valid registers were found, don't attach. */
-if (cpu_cx_count == 0)
+if (sc->cpu_cx_count == 0)
return (ENXIO);
-sbuf_new(&sb, cpu_cx_supported, sizeof(cpu_cx_supported), SBUF_FIXEDLEN);
-for (i = 0; i < cpu_cx_count; i++) {
- sbuf_printf(&sb, "C%d/%d ", sc->cpu_cx_states[i].type,
- sc->cpu_cx_states[i].trans_lat);
-}
-sbuf_trim(&sb);
-sbuf_finish(&sb);
-SYSCTL_ADD_STRING(&acpi_cpu_sysctl_ctx,
- SYSCTL_CHILDREN(acpi_cpu_sysctl_tree),
- OID_AUTO, "cx_supported", CTLFLAG_RD, cpu_cx_supported,
- 0, "Cx/microsecond values for supported Cx states");
-SYSCTL_ADD_PROC(&acpi_cpu_sysctl_ctx,
- SYSCTL_CHILDREN(acpi_cpu_sysctl_tree),
- OID_AUTO, "cx_lowest", CTLTYPE_INT | CTLFLAG_RW,
- NULL, 0, acpi_cpu_cx_lowest_sysctl, "I",
- "lowest Cx sleep state to use");
-SYSCTL_ADD_PROC(
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
On Sunday 16 November 2003 21:11, Nate Lawson wrote: > The panic you see is a result of the new acpi_cpu driver, not ULE. In any > case, it appears that acpi_cpu_idle is being called and trying to read one > of the processor control registers before they are present. Please send > me privately the output of: >acpidump -t -d > harald-MachineType.asl > > As a workaround, please set this in loader.conf: >debug.acpi.disable="cpu" > > That will allow you to get running and give me some time to look into > this. Now I followed your advise and found out the following (source from some hours ago, 4BSD scheduler, and the acpidump went away to you by private mail) The panic only occurs if the nvidia.ko module is was loaded. I use it straight from the ports. But your sysctl tweak keeps the whole thing working (I'm writing with kmail)! Hope this helps (anyway, this driver is absolutle mandatory for my workstation!) Thanks, -Harry > > Thanks, > -Nate pgp0.pgp Description: signature
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
The panic you see is a result of the new acpi_cpu driver, not ULE. In any case, it appears that acpi_cpu_idle is being called and trying to read one of the processor control registers before they are present. Please send me privately the output of: acpidump -t -d > harald-MachineType.asl As a workaround, please set this in loader.conf: debug.acpi.disable="cpu" That will allow you to get running and give me some time to look into this. Thanks, -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
