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 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)
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 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 function. */ +cpu_cx_count = 0; + +#ifdef SMP +/* Wait for all processors to exit acpi_cpu_idle(). */ +
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)
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: 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)
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(acpi_cpu_sysctl_ctx, -
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_CHILDREN(acpi_cpu_sysctl_tree), - OID_AUTO, cx_supported, CTLFLAG_RD, cpu_cx_supported, - 0, Cx/microsecond values for supported Cx states); -
Re: kernel panic with todays source
On Sunday 16 November 2003 05:32, Harald Schmalzbauer wrote: Hi, I saw that something has changed on ULE and wanted to give it a try but with sources from ~ So 16 Nov 2003 04:00 UTC I get the following kernel panic just before disk/geom and after Timecounter TSC frequency 1095341787 Hz quality 800: Fatal trap 12 :page fault while in kernel mode fault virtual address =0x24 fault code=supervisor read, page not present instruction pointer =0x8:0xc056c706 stack pointer =0x10:0xcdca4ca4 frame pointer =0x10:0xcdca4ca4 code segment =base 0x0, limit 0xf, type 0x1b =DPL 0, pres 1, def32 1, gran 1 processor eflags =resume, IOPL=0 current process =11 (idle) trap number =12 panic: page fault I recvsuped some hours ago and now I have the following (this time with DDB trace): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer= 0x8:0xc0571d36 stack pointer = 0x10:0xcdca4ca4 frame pointer = 0x10:0xcdca4ca4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL=0 current process = 11 (idle) kernel: type 12 trap, code=0 Stopped at rman_get_bustag+0x6:movl0x24(%eax),%eax db trace rman_get_bustag(0,cdca4cbc,c2d2f3d0,4ab1c,3a7ee2) at rman_get_bustag+0x6 acpi_cpu_idle(cdca4d08,c0535345,ffef,42b30,42830) at acpi_cpu_idle+0x1c3 cpu_idle(ffef,42b30,42830,42b30,43724) at cpu_idle+0x1f idle_proc(0,cdca4d48,43160,437a4,3) at idle_proc+0x25 fork_exit(0c0535320,0,cdca4d48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcdca4d7c, ebp = 0 --- This GDB was configured as i386-undermydesk-freebsd... (kgdb) l *0xc0571d36 0xc0571d36 is in rman_get_bustag (/usr/src/sys/kern/subr_rman.c:661). 656 } 657 658 bus_space_tag_t 659 rman_get_bustag(struct resource *r) 660 { 661 return (r-r_bustag); 662 } 663 664 void 665 rman_set_bushandle(struct resource *r, bus_space_handle_t h) (kgdb) l *0xcdca4ca4 No source file for address 0xcdca4ca4. Hope this helps. -Harry 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]
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
kernel panic with todays source
Hi, I saw that something has changed on ULE and wanted to give it a try but with sources from ~ So 16 Nov 2003 04:00 UTC I get the following kernel panic just before disk/geom and after Timecounter TSC frequency 1095341787 Hz quality 800: Fatal trap 12 :page fault while in kernel mode fault virtual address =0x24 fault code =supervisor read, page not present instruction pointer =0x8:0xc056c706 stack pointer =0x10:0xcdca4ca4 frame pointer =0x10:0xcdca4ca4 code segment=base 0x0, limit 0xf, type 0x1b =DPL 0, pres 1, def32 1, gran 1 processor eflags=resume, IOPL=0 current process =11 (idle) trap number =12 panic: page fault I do have compiled the kernel with makeoptions debug but I don't have a serial terminal nor firewire. Let me know if I can help. Attached my kernel config Thanks, -Harry ## Kernel for ASUS CUSL2 ## ## Generic Config #--- machine i386 cpu I686_CPU options PQ_CACHESIZE=256# color for 512k/16k cache ident CALE makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options SCHED_4BSD #4BSD scheduler #optionsSCHED_ULE options PROCFS #Process filesystem (requires PSEUDOFS) options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION options HZ=2000 options PERFMON #options MAC #options MAC_BIBA #options MAC_BSDEXTENDED #options MAC_DEBUG #options MAC_IFOFF #options MAC_LOMAC #options MAC_MLS #options MAC_NONE #options MAC_PARTITION #options MAC_PORTACL #options MAC_SEEOTHERUIDS #options MAC_TEST ## Buses #-- #options SMP device apic options NO_MIXED_MODE device acpi device npx device isa device pci #device agp ## ISA-Controller # device atkbdc # AT keyboard controller device sio # 8250, 16[45]50 based serial ports device pmtimer ## PCI-Controller #-- device ata device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface ## Devices with their options # #+ IDE ++ device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering options FFS #Berkeley Fast Filesystem options UDF options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options SOFTUPDATES #Enable FFS soft updates support options GEOM_BDE options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART options QUOTA #enable disk quotas #options SUIDDIR #+ SCSI + device scbus # SCSI bus (required) device da # Direct Access (disks) device pass# Passthrough device (direct SCSI access) #device atapicam #+ Eingabe + device atkbd # AT keyboard device psm # PS/2 mouse #+ Ausgabe ++ device vga # VGA video card driver options VESA device splash # Splash screen and screen saver support device sc options MAXCONS=12 options SC_DISABLE_REBOOT options SC_PIXEL_MODE options SC_HISTORY_SIZE=1000 device pcm #+ USB + device usb # USB Bus (required) device ugen# Generic device uhid# Human Interface Devices device ukbd# Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse #+ Netzwerk + device miibus # MII bus support device fxp options DEVICE_POLLING options INET#InterNETworking options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server
Re: kernel panic with todays source
On Sun, 16 Nov 2003, Harald Schmalzbauer wrote: Fatal trap 12 :page fault while in kernel mode fault virtual address =0x24 fault code =supervisor read, page not present instruction pointer =0x8:0xc056c706 stack pointer =0x10:0xcdca4ca4 frame pointer =0x10:0xcdca4ca4 code segment=base 0x0, limit 0xf, type 0x1b =DPL 0, pres 1, def32 1, gran 1 processor eflags=resume, IOPL=0 current process =11 (idle) trap number =12 panic: page fault I do have compiled the kernel with makeoptions debug but I don't have a serial terminal nor firewire. Could you show the output from running the following command in gdb -k kernel.debug: l *0xc056c706 This will tell us where in the kernel the instruction pointer in question was. For whatever reason, your kernel panic doesn't seem to have dropped you into DDB (at least, the output looks that way). If you did get into ddb, the results of the trace command would be very helpful. As you have no serial console, it's probably sufficient to just transcript the offsets at the end of each line in the trace (functioname+0xOFFSET) without the argument entries. 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: kernel panic with todays source
On Sunday 16 November 2003 05:34, Robert Watson wrote: On Sun, 16 Nov 2003, Harald Schmalzbauer wrote: Fatal trap 12 :page fault while in kernel mode fault virtual address =0x24 fault code =supervisor read, page not present instruction pointer =0x8:0xc056c706 stack pointer =0x10:0xcdca4ca4 frame pointer =0x10:0xcdca4ca4 code segment=base 0x0, limit 0xf, type 0x1b =DPL 0, pres 1, def32 1, gran 1 processor eflags=resume, IOPL=0 current process =11 (idle) trap number =12 panic: page fault I do have compiled the kernel with makeoptions debug but I don't have a serial terminal nor firewire. Could you show the output from running the following command in gdb -k kernel.debug: l *0xc056c706 This will tell us where in the kernel the instruction pointer in question was. For whatever reason, your kernel panic doesn't seem to have dropped you into DDB (at least, the output looks that way). If you did get into ddb, the results of the trace command would be very helpful. As you have no serial console, it's probably sufficient to just transcript the I think for this I need to set options DDB in my kernel, don't I? But without serial terminal this is pretty useless I think. But I'll do if you can get needed information which was otherwise not accessable. Thanks, -Harry offsets at the end of each line in the trace (functioname+0xOFFSET) without the argument entries. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories pgp0.pgp Description: signature
Re: kernel panic with todays source
On Sunday 16 November 2003 05:40, Craig Rodrigues wrote: On Sun, Nov 16, 2003 at 05:32:03AM +0100, Harald Schmalzbauer wrote: instruction pointer =0x8:0xc056c706 stack pointer =0x10:0xcdca4ca4 frame pointer =0x10:0xcdca4ca4 Do you have a file: /usr/obj/usr/src/sys/CALE/kernel.debug ? If so, if you do: gdb -k /usr/obj/usr/src/sys/CALE/kernel.debug What do you see if you do: l *0xc056c706 (kgdb) l *0xc056c706 0xc056c706 is in vsscanf (/usr/src/sys/kern/subr_scanf.c:224). 219 220 case '[': 221 fmt = __sccl(ccltab, fmt); 222 flags |= NOSKIP; 223 c = CT_CCL; 224 break; 225 226 case 'c': 227 flags |= NOSKIP; 228 c = CT_CHAR; l *0xcdca4ca4 (kgdb) l *0xcdca4ca4 No source file for address 0xcdca4ca4 l *0xcdca4ca4 Sorry, perhaps I mistyped that address. If it helps, I could reboot with the faulty kernel and look for the address again. Thanks, -Harry pgp0.pgp Description: signature
Re: kernel panic with todays source
On Sunday 16 November 2003 05:49, Harald Schmalzbauer wrote: On Sunday 16 November 2003 05:34, Robert Watson wrote: On Sun, 16 Nov 2003, Harald Schmalzbauer wrote: Fatal trap 12 :page fault while in kernel mode fault virtual address =0x24 fault code =supervisor read, page not present instruction pointer =0x8:0xc056c706 stack pointer =0x10:0xcdca4ca4 frame pointer =0x10:0xcdca4ca4 code segment=base 0x0, limit 0xf, type 0x1b =DPL 0, pres 1, def32 1, gran 1 processor eflags=resume, IOPL=0 current process =11 (idle) trap number =12 panic: page fault I do have compiled the kernel with makeoptions debug but I don't have a serial terminal nor firewire. Could you show the output from running the following command in gdb -k kernel.debug: l *0xc056c706 Sorry, forgot to mention that I answered this in Craig Rodrigues mail. But while I'm here: (kgdb) l *0xc056c706 0xc056c706 is in vsscanf (/usr/src/sys/kern/subr_scanf.c:224). 219 220 case '[': 221 fmt = __sccl(ccltab, fmt); 222 flags |= NOSKIP; 223 c = CT_CCL; 224 break; 225 226 case 'c': 227 flags |= NOSKIP; 228 c = CT_CHAR; Thanks, -Harry This will tell us where in the kernel the instruction pointer in question was. For whatever reason, your kernel panic doesn't seem to have dropped you into DDB (at least, the output looks that way). If you did get into ddb, the results of the trace command would be very helpful. As you have no serial console, it's probably sufficient to just transcript the I think for this I need to set options DDB in my kernel, don't I? But without serial terminal this is pretty useless I think. But I'll do if you can get needed information which was otherwise not accessable. Thanks, -Harry offsets at the end of each line in the trace (functioname+0xOFFSET) without the argument entries. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories pgp0.pgp Description: signature