Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)

2003-11-19 Thread Eric Anderson 
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)

2003-11-18 Thread Harald Schmalzbauer 
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)

2003-11-18 Thread Eric Anderson 
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)

2003-11-18 Thread Harald Schmalzbauer 
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)

2003-11-18 Thread Nate Lawson 
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)

2003-11-18 Thread Eric Anderson 
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)

2003-11-18 Thread Nate Lawson 
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)

2003-11-17 Thread Nate Lawson 
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)

2003-11-17 Thread Harald Schmalzbauer 
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

2003-11-16 Thread Harald Schmalzbauer 
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)

2003-11-16 Thread Nate Lawson 
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)

2003-11-16 Thread Harald Schmalzbauer 
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

2003-11-15 Thread Harald Schmalzbauer 
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

2003-11-15 Thread Robert Watson 

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

2003-11-15 Thread Harald Schmalzbauer 
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

2003-11-15 Thread Harald Schmalzbauer 
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

2003-11-15 Thread Harald Schmalzbauer 
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