Re: 2.6.18-rc5-mm1

Re: 2.6.18-rc5-mm1

[Maciej Rutecki]

[-- Attachment #1.1: Type: text/plain, Size: 2374 bytes --]

Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/
> 

ACPI error (similar like in 2.6.18-rc4-mm3):

[   23.790140] ACPI Error (utglobal-0125): Unknown exception code:
0xFFFFFFEA [20060707]
[   23.790318]  [<c0221ba9>] acpi_format_exception+0x9f/0xa9
[   23.790445]  [<c021edf9>] acpi_ut_status_exit+0x2e/0x56
[   23.790554]  [<c021b3ac>] acpi_walk_resources+0x103/0x10d
[   23.790661]  [<c022901c>] acpi_reserve_io_ranges+0x0/0xfc
[   23.790774]  [<c022900f>] acpi_motherboard_add+0x1f/0x2c
[   23.790880]  [<c0228154>] acpi_bus_driver_init+0x2c/0x78
[   23.790987]  [<c02285b0>] acpi_bus_register_driver+0x60/0xb1
[   23.791094]  [<c038a8da>] acpi_motherboard_init+0xa/0xf5
[   23.791205]  [<c01002b0>] init+0x70/0x280
[   23.791309]  [<c0102db2>] ret_from_fork+0x6/0x14
[   23.791420]  [<c0100240>] init+0x0/0x280
[   23.791520]  [<c0100240>] init+0x0/0x280
[   23.791621]  [<c0103997>] kernel_thread_helper+0x7/0x10
[   23.791728]  =======================
[   23.791844] ACPI Error (utglobal-0125): Unknown exception code:
0xFFFFFFEA [20060707]
[   23.792004]  [<c0221ba9>] acpi_format_exception+0x9f/0xa9
[   23.792112]  [<c021edf9>] acpi_ut_status_exit+0x2e/0x56
[   23.792218]  [<c021b3ac>] acpi_walk_resources+0x103/0x10d
[   23.792325]  [<c022901c>] acpi_reserve_io_ranges+0x0/0xfc
[   23.792432]  [<c022900f>] acpi_motherboard_add+0x1f/0x2c
[   23.792538]  [<c0228154>] acpi_bus_driver_init+0x2c/0x78
[   23.792644]  [<c02285b0>] acpi_bus_register_driver+0x60/0xb1
[   23.792751]  [<c038a8e4>] acpi_motherboard_init+0x14/0xf5
[   23.792857]  [<c01002b0>] init+0x70/0x280
[   23.792959]  [<c0102db2>] ret_from_fork+0x6/0x14
[   23.793062]  [<c0100240>] init+0x0/0x280
[   23.793162]  [<c0100240>] init+0x0/0x280
[   23.793262]  [<c0103997>] kernel_thread_helper+0x7/0x10
[   23.793367]  =======================

Also when I try:

echo standby > /sys/power/state,

I got this message on display:

Sep  1 18:03:02 maciek kernel: [  189.192822] Stopping tasks:
==========================|
Sep  1 18:03:02 maciek kernel: [  189.465008] Suspending console(s)
Sep  1 18:03:02 maciek kernel: [  191.466946] Suspending device vcsa9

But display don't want go standby.


-- 
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

[-- Attachment #1.2: config-2.6.18-rc5-mm1.gz --]
[-- Type: application/x-gzip, Size: 14631 bytes --]

[-- Attachment #1.3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 9641 bytes --]

[-- Attachment #1.4: lsmod_output.txt.gz --]
[-- Type: application/x-gzip, Size: 810 bytes --]

[-- Attachment #1.5: syslog.txt.gz --]
[-- Type: application/x-gzip, Size: 2546 bytes --]

[-- Attachment #1.6: ver_linux.txt.gz --]
[-- Type: application/x-gzip, Size: 650 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3265 bytes --]

Re: 2.6.18-rc5-mm1

[Bjorn Helgaas]

On Friday 01 September 2006 10:40, Maciej Rutecki wrote:
> ACPI error (similar like in 2.6.18-rc4-mm3):
> 
> [   23.790140] ACPI Error (utglobal-0125): Unknown exception code:
> 0xFFFFFFEA [20060707]
> [   23.790318]  [<c0221ba9>] acpi_format_exception+0x9f/0xa9
> [   23.790445]  [<c021edf9>] acpi_ut_status_exit+0x2e/0x56
> [   23.790554]  [<c021b3ac>] acpi_walk_resources+0x103/0x10d
> [   23.790661]  [<c022901c>] acpi_reserve_io_ranges+0x0/0xfc
> [   23.790774]  [<c022900f>] acpi_motherboard_add+0x1f/0x2c
> [   23.790880]  [<c0228154>] acpi_bus_driver_init+0x2c/0x78
> [   23.790987]  [<c02285b0>] acpi_bus_register_driver+0x60/0xb1
> [   23.791094]  [<c038a8da>] acpi_motherboard_init+0xa/0xf5
> [   23.791205]  [<c01002b0>] init+0x70/0x280
> [   23.791309]  [<c0102db2>] ret_from_fork+0x6/0x14
> [   23.791420]  [<c0100240>] init+0x0/0x280
> [   23.791520]  [<c0100240>] init+0x0/0x280
> [   23.791621]  [<c0103997>] kernel_thread_helper+0x7/0x10

This ACPI "unknown exception code" problem is the same one reported here:
  http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html

Basically, we just need to revert this:
  http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch

The above patch happened to fix a hot-add memory problem, but it was
the wrong fix, and we're working out a better one.

Re: 2.6.18-rc5-mm1

[Maciej Rutecki]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

Bjorn Helgaas napisał(a):
> 
> This ACPI "unknown exception code" problem is the same one reported here:
>   http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> 
> Basically, we just need to revert this:
>   http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> 
Thanks it works.

-- 
Maciej Rutecki <maciej.rutecki@gmail.com>
http://www.unixy.pl
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3265 bytes --]

Re: 2.6.18-rc5-mm1

[Andrew Morton]

On Wed, 06 Sep 2006 18:55:11 +0200
Maciej Rutecki <maciej.rutecki@gmail.com> wrote:

> Bjorn Helgaas napisał(a):
> > 
> > This ACPI "unknown exception code" problem is the same one reported here:
> >   http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> > 
> > Basically, we just need to revert this:
> >   http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> > 
> Thanks it works.
> 

So...  should I drop that patch?
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.18-rc5-mm1

[keith mannthey]

On Wed, 2006-09-06 at 20:08 -0700, Andrew Morton wrote:
> On Wed, 06 Sep 2006 18:55:11 +0200
> Maciej Rutecki <maciej.rutecki@gmail.com> wrote:
> 
> > Bjorn Helgaas napisał(a):
> > > 
> > > This ACPI "unknown exception code" problem is the same one reported here:
> > >   http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html
> > > 
> > > Basically, we just need to revert this:
> > >   http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch
> > > 
> > Thanks it works.
> > 
> 
> So...  should I drop that patch?

Yes please drop this patch.  
  I dislike breaking my boxes functionality without a consensus for the
right fix is but it appears to be breaking others.  The discussion about
what the right fix is ongoing with no definitive direction. At a minimum
this patch will need to be updated. 

Thanks,
  Keith 

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 2.6.18-rc5-mm1

[Andrew Morton]

On Sat, 02 Sep 2006 03:00:47 +0200
Matthias Hentges <oe@hentges.net> wrote:

> 2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
> attached.
> This did not happen in 2.6.18-rc4-mm3.
> 
> 
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 00000000
>  printing eip:
> 00000000
> *pde = 00000000
> Oops: 0000 [#1]
> 4K_STACKS SMP 
> last sysfs file: 
> Modules linked in:
> CPU:    0
> EIP:    0060:[<00000000>]    Not tainted VLI
> EFLAGS: 00010087   (2.6.18-rc5-mm1 #1) 
> EIP is at rest_init+0x3feffd78/0x20
> eax: 000000da   ebx: c04d5f78   ecx: c04d5f94   edx: c04d2f00
> esi: 000000da   edi: 00000000   ebp: c04d2f00   esp: c0516ffc
> ds: 007b   es: 007b   ss: 0068
> Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
> Stack: c0105027 
> Call Trace:
>  [<c0105027>] do_IRQ+0x8a/0xac
>  [<c01035a6>] common_interrupt+0x1a/0x20
>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>  [<c0101a83>] mwait_idle+0xc/0x1b
>  [<c0101a26>] cpu_idle+0x5e/0x74
>  [<c04db6fa>] start_kernel+0x363/0x36a
>  =======================
> Code:  Bad EIP value.
> EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
>  <0>Kernel panic - not syncing: Fatal exception in interrupt
>  BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
>  [<c010ca45>] smp_call_function+0x54/0xff
>  [<c011a270>] printk+0x12/0x16
>  [<c010cb03>] smp_send_stop+0x13/0x1c
>  [<c0119480>] panic+0x49/0xd3
>  [<c010410c>] die+0x273/0x28a
>  [<c01126d4>] do_page_fault+0x40d/0x4db
>  [<c01122c7>] do_page_fault+0x0/0x4db
>  [<c03d1231>] error_code+0x39/0x40
>  [<c013007b>] free_module+0x89/0xc3
>  [<c0105027>] do_IRQ+0x8a/0xac
>  [<c01035a6>] common_interrupt+0x1a/0x20
>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>  [<c0101a83>] mwait_idle+0xc/0x1b
>  [<c0101a26>] cpu_idle+0x5e/0x74
>  [<c04db6fa>] start_kernel+0x363/0x36a
>  =======================

OK, thanks.  That'll be acpi-mwait-c-state-fixes.patch.  I've uploaded the
below revert patch to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/


diff -puN arch/i386/kernel/acpi/cstate.c~revert-acpi-mwait-c-state-fixes arch/i386/kernel/acpi/cstate.c
--- a/arch/i386/kernel/acpi/cstate.c~revert-acpi-mwait-c-state-fixes
+++ a/arch/i386/kernel/acpi/cstate.c
@@ -10,7 +10,6 @@
 #include <linux/module.h>
 #include <linux/init.h>
 #include <linux/acpi.h>
-#include <linux/cpu.h>
 
 #include <acpi/processor.h>
 #include <asm/acpi.h>
@@ -42,124 +41,5 @@ void acpi_processor_power_init_bm_check(
 		flags->bm_check = 1;
 	}
 }
-EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
-
-/* The code below handles cstate entry with monitor-mwait pair on Intel*/
-
-struct cstate_entry_s {
-	struct {
-		unsigned int eax;
-		unsigned int ecx;
-	} states[ACPI_PROCESSOR_MAX_POWER];
-};
-static struct cstate_entry_s *cpu_cstate_entry;	/* per CPU ptr */
-
-static short mwait_supported[ACPI_PROCESSOR_MAX_POWER];
-
-#define MWAIT_SUBSTATE_MASK	(0xf)
-#define MWAIT_SUBSTATE_SIZE	(4)
-
-#define CPUID_MWAIT_LEAF (5)
-#define CPUID5_ECX_EXTENSIONS_SUPPORTED (0x1)
-#define CPUID5_ECX_INTERRUPT_BREAK	(0x2)
-
-#define MWAIT_ECX_INTERRUPT_BREAK	(0x1)
-
-#define NATIVE_CSTATE_BEYOND_HALT	(2)
-
-int acpi_processor_ffh_cstate_probe(unsigned int cpu,
-		struct acpi_processor_cx *cx, struct acpi_power_register *reg)
-{
-	struct cstate_entry_s *percpu_entry;
-	struct cpuinfo_x86 *c = cpu_data + cpu;
-
-	cpumask_t saved_mask;
-	int retval;
-	unsigned int eax, ebx, ecx, edx;
-	unsigned int edx_part;
-	unsigned int cstate_type; /* C-state type and not ACPI C-state type */
-	unsigned int num_cstate_subtype;
-
-	if (!cpu_cstate_entry || c->cpuid_level < CPUID_MWAIT_LEAF )
-		return -1;
-
-	if (reg->bit_offset != NATIVE_CSTATE_BEYOND_HALT)
-		return -1;
-
-	percpu_entry = per_cpu_ptr(cpu_cstate_entry, cpu);
-	percpu_entry->states[cx->index].eax = 0;
-	percpu_entry->states[cx->index].ecx = 0;
-
-	/* Make sure we are running on right CPU */
-	saved_mask = current->cpus_allowed;
-	retval = set_cpus_allowed(current, cpumask_of_cpu(cpu));
-	if (retval)
-		return -1;
-
-	cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &edx);
-
-	/* Check whether this particular cx_type (in CST) is supported or not */
-	cstate_type = (cx->address >> MWAIT_SUBSTATE_SIZE) + 1;
-	edx_part = edx >> (cstate_type * MWAIT_SUBSTATE_SIZE);
-	num_cstate_subtype = edx_part & MWAIT_SUBSTATE_MASK;
-
-	retval = 0;
-	if (num_cstate_subtype < (cx->address & MWAIT_SUBSTATE_MASK)) {
-		retval = -1;
-		goto out;
-	}
 
-	/* mwait ecx extensions INTERRUPT_BREAK should be supported for C2/C3 */
-	if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||
-	    !(ecx & CPUID5_ECX_INTERRUPT_BREAK)) {
-		retval = -1;
-		goto out;
-	}
-	percpu_entry->states[cx->index].ecx = MWAIT_ECX_INTERRUPT_BREAK;
-
-	/* Use the hint in CST */
-	percpu_entry->states[cx->index].eax = cx->address;
-
-	if (!mwait_supported[cstate_type]) {
-		mwait_supported[cstate_type] = 1;
-		printk(KERN_DEBUG "Monitor-Mwait will be used to enter C-%d "
-		       "state\n", cx->type);
-	}
-
-out:
-	set_cpus_allowed(current, saved_mask);
-	return retval;
-}
-EXPORT_SYMBOL_GPL(acpi_processor_ffh_cstate_probe);
-
-void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cx)
-{
-	unsigned int cpu = smp_processor_id();
-	struct cstate_entry_s *percpu_entry;
-
-	percpu_entry = per_cpu_ptr(cpu_cstate_entry, cpu);
-	mwait_idle_with_hints(percpu_entry->states[cx->index].eax,
-	                      percpu_entry->states[cx->index].ecx);
-}
-EXPORT_SYMBOL_GPL(acpi_processor_ffh_cstate_enter);
-
-static int __init ffh_cstate_init(void)
-{
-	struct cpuinfo_x86 *c = &boot_cpu_data;
-	if (c->x86_vendor != X86_VENDOR_INTEL)
-		return -1;
-
-	cpu_cstate_entry = alloc_percpu(struct cstate_entry_s);
-	return 0;
-}
-
-static void __exit ffh_cstate_exit(void)
-{
-	if (cpu_cstate_entry) {
-		free_percpu(cpu_cstate_entry);
-		cpu_cstate_entry = NULL;
-	}
-}
-
-arch_initcall(ffh_cstate_init);
-__exitcall(ffh_cstate_exit);
+EXPORT_SYMBOL(acpi_processor_power_init_bm_check);
diff -puN arch/i386/kernel/process.c~revert-acpi-mwait-c-state-fixes arch/i386/kernel/process.c
--- a/arch/i386/kernel/process.c~revert-acpi-mwait-c-state-fixes
+++ a/arch/i386/kernel/process.c
@@ -236,28 +236,20 @@ EXPORT_SYMBOL_GPL(cpu_idle_wait);
  * We execute MONITOR against need_resched and enter optimized wait state
  * through MWAIT. Whenever someone changes need_resched, we would be woken
  * up from MWAIT (without an IPI).
- *
- * New with Core Duo processors, MWAIT can take some hints based on CPU
- * capability.
  */
-void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
+static void mwait_idle(void)
 {
-	if (!need_resched()) {
+	local_irq_enable();
+
+	while (!need_resched()) {
 		__monitor((void *)&current_thread_info()->flags, 0, 0);
 		smp_mb();
-		if (!need_resched())
-			__mwait(eax, ecx);
+		if (need_resched())
+			break;
+		__mwait(0, 0);
 	}
 }
 
-/* Default MONITOR/MWAIT with no hints, used for default C1 state */
-static void mwait_idle(void)
-{
-	local_irq_enable();
-	while (!need_resched())
-		mwait_idle_with_hints(0, 0);
-}
-
 void __devinit select_idle_routine(const struct cpuinfo_x86 *c)
 {
 	if (cpu_has(c, X86_FEATURE_MWAIT)) {
diff -puN arch/x86_64/kernel/process.c~revert-acpi-mwait-c-state-fixes arch/x86_64/kernel/process.c
--- a/arch/x86_64/kernel/process.c~revert-acpi-mwait-c-state-fixes
+++ a/arch/x86_64/kernel/process.c
@@ -235,28 +235,20 @@ void cpu_idle (void)
  * We execute MONITOR against need_resched and enter optimized wait state
  * through MWAIT. Whenever someone changes need_resched, we would be woken
  * up from MWAIT (without an IPI).
- *
- * New with Core Duo processors, MWAIT can take some hints based on CPU
- * capability.
  */
-void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
+static void mwait_idle(void)
 {
-	if (!need_resched()) {
+	local_irq_enable();
+
+	while (!need_resched()) {
 		__monitor((void *)&current_thread_info()->flags, 0, 0);
 		smp_mb();
-		if (!need_resched())
-			__mwait(eax, ecx);
+		if (need_resched())
+			break;
+		__mwait(0, 0);
 	}
 }
 
-/* Default MONITOR/MWAIT with no hints, used for default C1 state */
-static void mwait_idle(void)
-{
-	local_irq_enable();
-	while (!need_resched())
-		mwait_idle_with_hints(0,0);
-}
-
 void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
 {
 	static int printed;
diff -puN drivers/acpi/processor_idle.c~revert-acpi-mwait-c-state-fixes drivers/acpi/processor_idle.c
--- a/drivers/acpi/processor_idle.c~revert-acpi-mwait-c-state-fixes
+++ a/drivers/acpi/processor_idle.c
@@ -219,23 +219,6 @@ static void acpi_safe_halt(void)
 
 static atomic_t c3_cpu_count;
 
-/* Common C-state entry for C2, C3, .. */
-static void acpi_cstate_enter(struct acpi_processor_cx *cstate)
-{
-	if (cstate->space_id == ACPI_CSTATE_FFH) {
-		/* Call into architectural FFH based C-state */
-		acpi_processor_ffh_cstate_enter(cstate);
-	} else {
-		int unused;
-		/* IO port based C-state */
-		inb(cstate->address);
-		/* Dummy wait op - must do something useless after P_LVL2 read
-		   because chipsets cannot guarantee that STPCLK# signal
-		   gets asserted in time to freeze execution properly. */
-		unused = inl(acpi_fadt.xpm_tmr_blk.address);
-	}
-}
-
 static void acpi_processor_idle(void)
 {
 	struct acpi_processor *pr = NULL;
@@ -378,7 +361,11 @@ static void acpi_processor_idle(void)
 		/* Get start time (ticks) */
 		t1 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Invoke C2 */
-		acpi_cstate_enter(cx);
+		inb(cx->address);
+		/* Dummy wait op - must do something useless after P_LVL2 read
+		   because chipsets cannot guarantee that STPCLK# signal
+		   gets asserted in time to freeze execution properly. */
+		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Get end time (ticks) */
 		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
 
@@ -414,7 +401,9 @@ static void acpi_processor_idle(void)
 		/* Get start time (ticks) */
 		t1 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Invoke C3 */
-		acpi_cstate_enter(cx);
+		inb(cx->address);
+		/* Dummy wait op (see above) */
+		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
 		/* Get end time (ticks) */
 		t2 = inl(acpi_fadt.xpm_tmr_blk.address);
 		if (pr->flags.bm_check) {
@@ -639,16 +628,20 @@ static int acpi_processor_get_power_info
 	return 0;
 }
 
-static int acpi_processor_get_power_info_default(struct acpi_processor *pr)
+static int acpi_processor_get_power_info_default_c1(struct acpi_processor *pr)
 {
-	if (!pr->power.states[ACPI_STATE_C1].valid) {
-		/* set the first C-State to C1 */
-		/* all processors need to support C1 */
-		pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
-		pr->power.states[ACPI_STATE_C1].valid = 1;
-	}
-	/* the C0 state only exists as a filler in our array */
+
+	/* Zero initialize all the C-states info. */
+	memset(pr->power.states, 0, sizeof(pr->power.states));
+
+	/* set the first C-State to C1 */
+	pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
+
+	/* the C0 state only exists as a filler in our array,
+	 * and all processors need to support C1 */
 	pr->power.states[ACPI_STATE_C0].valid = 1;
+	pr->power.states[ACPI_STATE_C1].valid = 1;
+
 	return 0;
 }
 
@@ -665,7 +658,12 @@ static int acpi_processor_get_power_info
 	if (nocst)
 		return -ENODEV;
 
-	current_count = 0;
+	current_count = 1;
+
+	/* Zero initialize C2 onwards and prepare for fresh CST lookup */
+	for (i = 2; i < ACPI_PROCESSOR_MAX_POWER; i++)
+		memset(&(pr->power.states[i]), 0, 
+				sizeof(struct acpi_processor_cx));
 
 	status = acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer);
 	if (ACPI_FAILURE(status)) {
@@ -720,39 +718,22 @@ static int acpi_processor_get_power_info
 		    (reg->space_id != ACPI_ADR_SPACE_FIXED_HARDWARE))
 			continue;
 
+		cx.address = (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) ?
+		    0 : reg->address;
+
 		/* There should be an easy way to extract an integer... */
 		obj = (union acpi_object *)&(element->package.elements[1]);
 		if (obj->type != ACPI_TYPE_INTEGER)
 			continue;
 
 		cx.type = obj->integer.value;
-		/*
-		 * Some buggy BIOSes won't list C1 in _CST -
-		 * Let acpi_processor_get_power_info_default() handle them later
-		 */
-		if (i == 1 && cx.type != ACPI_STATE_C1)
-			current_count++;
 
-		cx.address = reg->address;
-		cx.index = current_count + 1;
+		if ((cx.type != ACPI_STATE_C1) &&
+		    (reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO))
+			continue;
 
-		cx.space_id = ACPI_CSTATE_SYSTEMIO;
-		if (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) {
-			if (acpi_processor_ffh_cstate_probe
-					(pr->id, &cx, reg) == 0) {
-				cx.space_id = ACPI_CSTATE_FFH;
-			} else if (cx.type != ACPI_STATE_C1) {
-				/*
-				 * C1 is a special case where FIXED_HARDWARE
-				 * can be handled in non-MWAIT way as well.
-				 * In that case, save this _CST entry info.
-				 * That is, we retain space_id of SYSTEM_IO for
-				 * halt based C1.
-				 * Otherwise, ignore this info and continue.
-				 */
-				continue;
-			}
-		}
+		if ((cx.type < ACPI_STATE_C2) || (cx.type > ACPI_STATE_C3))
+			continue;
 
 		obj = (union acpi_object *)&(element->package.elements[2]);
 		if (obj->type != ACPI_TYPE_INTEGER)
@@ -957,18 +938,12 @@ static int acpi_processor_get_power_info
 	/* NOTE: the idle thread may not be running while calling
 	 * this function */
 
-	/* Zero initialize all the C-states info. */
-	memset(pr->power.states, 0, sizeof(pr->power.states));
-
+	/* Adding C1 state */
+	acpi_processor_get_power_info_default_c1(pr);
 	result = acpi_processor_get_power_info_cst(pr);
 	if (result == -ENODEV)
 		acpi_processor_get_power_info_fadt(pr);
 
-	if (result)
-		return result;
-
-	acpi_processor_get_power_info_default(pr);
-
 	pr->power.count = acpi_processor_power_verify(pr);
 
 	/*
diff -puN include/acpi/pdc_intel.h~revert-acpi-mwait-c-state-fixes include/acpi/pdc_intel.h
--- a/include/acpi/pdc_intel.h~revert-acpi-mwait-c-state-fixes
+++ a/include/acpi/pdc_intel.h
@@ -13,7 +13,6 @@
 #define ACPI_PDC_SMP_C_SWCOORD		(0x0040)
 #define ACPI_PDC_SMP_T_SWCOORD		(0x0080)
 #define ACPI_PDC_C_C1_FFH		(0x0100)
-#define ACPI_PDC_C_C2C3_FFH		(0x0200)
 
 #define ACPI_PDC_EST_CAPABILITY_SMP	(ACPI_PDC_SMP_C1PT | \
 					 ACPI_PDC_C_C1_HALT | \
@@ -24,10 +23,8 @@
 					 ACPI_PDC_SMP_P_SWCOORD | \
 					 ACPI_PDC_P_FFH)
 
-#define ACPI_PDC_C_CAPABILITY_SMP	(ACPI_PDC_SMP_C2C3  | \
-					 ACPI_PDC_SMP_C1PT  | \
-					 ACPI_PDC_C_C1_HALT | \
-					 ACPI_PDC_C_C1_FFH  | \
-					 ACPI_PDC_C_C2C3_FFH)
+#define ACPI_PDC_C_CAPABILITY_SMP	(ACPI_PDC_SMP_C2C3 | \
+					 ACPI_PDC_SMP_C1PT | \
+					 ACPI_PDC_C_C1_HALT)
 
 #endif				/* __PDC_INTEL_H__ */
diff -puN include/acpi/processor.h~revert-acpi-mwait-c-state-fixes include/acpi/processor.h
--- a/include/acpi/processor.h~revert-acpi-mwait-c-state-fixes
+++ a/include/acpi/processor.h
@@ -29,9 +29,6 @@
 #define DOMAIN_COORD_TYPE_SW_ANY	0xfd
 #define DOMAIN_COORD_TYPE_HW_ALL	0xfe
 
-#define ACPI_CSTATE_SYSTEMIO	(0)
-#define ACPI_CSTATE_FFH		(1)
-
 /* Power Management */
 
 struct acpi_processor_cx;
@@ -61,8 +58,6 @@ struct acpi_processor_cx {
 	u8 valid;
 	u8 type;
 	u32 address;
-	u8 space_id;
-	u8 index;
 	u32 latency;
 	u32 latency_ticks;
 	u32 power;
@@ -211,9 +206,6 @@ void arch_acpi_processor_init_pdc(struct
 #ifdef ARCH_HAS_POWER_INIT
 void acpi_processor_power_init_bm_check(struct acpi_processor_flags *flags,
 					unsigned int cpu);
-int acpi_processor_ffh_cstate_probe(unsigned int cpu,
-		struct acpi_processor_cx *cx, struct acpi_power_register *reg);
-void acpi_processor_ffh_cstate_enter(struct acpi_processor_cx *cstate);
 #else
 static inline void acpi_processor_power_init_bm_check(struct
 						      acpi_processor_flags
@@ -222,16 +214,6 @@ static inline void acpi_processor_power_
 	flags->bm_check = 1;
 	return;
 }
-static inline int acpi_processor_ffh_cstate_probe(unsigned int cpu,
-		struct acpi_processor_cx *cx, struct acpi_power_register *reg)
-{
-	return -1;
-}
-static inline void acpi_processor_ffh_cstate_enter(
-		struct acpi_processor_cx *cstate)
-{
-	return;
-}
 #endif
 
 /* in processor_perflib.c */
diff -puN include/asm-i386/processor.h~revert-acpi-mwait-c-state-fixes include/asm-i386/processor.h
--- a/include/asm-i386/processor.h~revert-acpi-mwait-c-state-fixes
+++ a/include/asm-i386/processor.h
@@ -306,8 +306,6 @@ static inline void __mwait(unsigned long
 		: :"a" (eax), "c" (ecx));
 }
 
-extern void mwait_idle_with_hints(unsigned long eax, unsigned long ecx);
-
 /* from system description table in BIOS.  Mostly for MCA use, but
 others may find it useful. */
 extern unsigned int machine_id;
diff -puN include/asm-x86_64/processor.h~revert-acpi-mwait-c-state-fixes include/asm-x86_64/processor.h
--- a/include/asm-x86_64/processor.h~revert-acpi-mwait-c-state-fixes
+++ a/include/asm-x86_64/processor.h
@@ -475,8 +475,6 @@ static inline void __mwait(unsigned long
 		: :"a" (eax), "c" (ecx));
 }
 
-extern void mwait_idle_with_hints(unsigned long eax, unsigned long ecx);
-
 #define stack_current() \
 ({								\
 	struct thread_info *ti;					\
_


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Jeremy Fitzhardinge wrote:
> The NULL EIP is desc->handle_irq in do_IRQ():
>
>         asm volatile(
>             "       xchgl  %%ebx,%%esp      \n"
>             "       call   *%%edi           \n"
>             "       movl   %%ebx,%%esp      \n"
>             : "=a" (arg1), "=d" (arg2), "=c" (arg3), "=b" (ebx)
>             :  "0" (irq),   "1" (desc),  "2" (regs),  "3" (isp),
>                "D" (desc->handle_irq)
>             : "memory", "cc"
>         );
>
> In my case, the IRQ is 0xdb = 219, which is an MSI interrupt for 
> libata (the AHCI SATA controller, presumably).  The exception happens 
> just after the SATA driver has probed all the hard disks.
>
> So it seems to me that the suspects are 1) sata, or 2) MSI.  I'll try 
> turning off MSI to see if it helps.

Yes, that fixed it; with MSI disabled I can boot successfully.

: ezr:pts/0; cd hg/linux-2.6/patches/broken-out/
: ezr:pts/0; ls *msi* | wc -l
23

Hm, where to start...

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Greg KH]

On Sat, Sep 02, 2006 at 01:37:13AM -0700, Jeremy Fitzhardinge wrote:
> Jeremy Fitzhardinge wrote:
> >The NULL EIP is desc->handle_irq in do_IRQ():
> >
> >        asm volatile(
> >            "       xchgl  %%ebx,%%esp      \n"
> >            "       call   *%%edi           \n"
> >            "       movl   %%ebx,%%esp      \n"
> >            : "=a" (arg1), "=d" (arg2), "=c" (arg3), "=b" (ebx)
> >            :  "0" (irq),   "1" (desc),  "2" (regs),  "3" (isp),
> >               "D" (desc->handle_irq)
> >            : "memory", "cc"
> >        );
> >
> >In my case, the IRQ is 0xdb = 219, which is an MSI interrupt for 
> >libata (the AHCI SATA controller, presumably).  The exception happens 
> >just after the SATA driver has probed all the hard disks.
> >
> >So it seems to me that the suspects are 1) sata, or 2) MSI.  I'll try 
> >turning off MSI to see if it helps.
> 
> Yes, that fixed it; with MSI disabled I can boot successfully.
> 
> : ezr:pts/0; cd hg/linux-2.6/patches/broken-out/
> : ezr:pts/0; ls *msi* | wc -l
> 23
> 
> Hm, where to start...

There are 9 MSI patches in my tree that you can just remove.  They were
just recently (a few hours ago) replaced with a total rewrite due to a
number of different problems that were found.  So I'd suggest just
waiting till the next -mm release to see if it works properly or not.

thanks,

greg k-h

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Greg KH wrote:
> There are 9 MSI patches in my tree that you can just remove.  They were
> just recently (a few hours ago) replaced with a total rewrite due to a
> number of different problems that were found.  So I'd suggest just
> waiting till the next -mm release to see if it works properly or not.
>   

This lot?

gregkh-pci-msi-01-merge_msi_disabling_quirks.patch
gregkh-pci-msi-02-factorize_pci_msi_supported.patch
gregkh-pci-msi-03-add_pci_device_exp_type.patch
gregkh-pci-msi-04-use_root_chipset_dev_no_msi_instead_of_pci_bus_flags.patch
gregkh-pci-msi-05-add_no_msi_to_sysfs.patch
gregkh-pci-msi-06-rename_pci_cap_id_ht_irqconf.patch
gregkh-pci-msi-07-check_hypertransport_msi_capabilities.patch
gregkh-pci-msi-08-drop_pci_msi_quirk.patch
gregkh-pci-msi-09-drop_pci_bus_flags.patch

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Greg KH]

On Sat, Sep 02, 2006 at 01:47:43AM -0700, Jeremy Fitzhardinge wrote:
> Greg KH wrote:
> >There are 9 MSI patches in my tree that you can just remove.  They were
> >just recently (a few hours ago) replaced with a total rewrite due to a
> >number of different problems that were found.  So I'd suggest just
> >waiting till the next -mm release to see if it works properly or not.
> >  
> 
> This lot?
> 
> gregkh-pci-msi-01-merge_msi_disabling_quirks.patch
> gregkh-pci-msi-02-factorize_pci_msi_supported.patch
> gregkh-pci-msi-03-add_pci_device_exp_type.patch
> gregkh-pci-msi-04-use_root_chipset_dev_no_msi_instead_of_pci_bus_flags.patch
> gregkh-pci-msi-05-add_no_msi_to_sysfs.patch
> gregkh-pci-msi-06-rename_pci_cap_id_ht_irqconf.patch
> gregkh-pci-msi-07-check_hypertransport_msi_capabilities.patch
> gregkh-pci-msi-08-drop_pci_msi_quirk.patch
> gregkh-pci-msi-09-drop_pci_bus_flags.patch

Yes, try reverting them and see if your machine works again.

thanks,

greg k-h

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Greg KH wrote:
> Yes, try reverting them and see if your machine works again.
>   

Reverting them makes the machine work, with basically the same effect as 
disabling CONFIG_PCI_MSI: no MSI interrupts appear in /proc/interrupts, 
and e1000 & libata are using IO-APIC-fasteoi.  So, a reasonable result 
for now.

Thanks,
    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeff Garzik]

Jeremy Fitzhardinge wrote:
> Greg KH wrote:
>> Yes, try reverting them and see if your machine works again.
>>   
> 
> Reverting them makes the machine work, with basically the same effect as 
> disabling CONFIG_PCI_MSI: no MSI interrupts appear in /proc/interrupts, 
> and e1000 & libata are using IO-APIC-fasteoi.  So, a reasonable result 
> for now.

Did you re-enable CONFIG_PCI_MSI, after reverting the patches?

	Jeff




-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
>>
>> Reverting them makes the machine work, with basically the same effect 
>> as disabling CONFIG_PCI_MSI: no MSI interrupts appear in 
>> /proc/interrupts, and e1000 & libata are using IO-APIC-fasteoi.  So, 
>> a reasonable result for now.
>
> Did you re-enable CONFIG_PCI_MSI, after reverting the patches?

Yes.  Er.  Hm, perhaps not, it didn't build:

  CC      drivers/pci/htirq.o
drivers/pci/htirq.c: In function 'ht_create_irq':
drivers/pci/htirq.c:126: error: 'PCI_CAP_ID_HT' undeclared (first use in this function)
drivers/pci/htirq.c:126: error: (Each undeclared identifier is reported only once
drivers/pci/htirq.c:126: error: for each function it appears in.)

I'll try again with CONFIG_HT_IRQ disabled...

    J


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Jeff Garzik wrote:
> Did you re-enable CONFIG_PCI_MSI, after reverting the patches?

Hm, still doesn't link with The GregKH Nine removed but CONFIG_MSI:

drivers/built-in.o: In function `pci_enable_msix':
drivers/pci/msi.c:956: undefined reference to `pci_msi_supported'

I'll just do without for now.

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Greg KH wrote:
> There are 9 MSI patches in my tree that you can just remove.  They were
> just recently (a few hours ago) replaced with a total rewrite due to a
> number of different problems that were found.  So I'd suggest just
> waiting till the next -mm release to see if it works properly or not.
>   

I'm seeing exactly the same oops with CONFIG_MSI on 2.6.18-rc6-mm1.

    J

Re: 2.6.18-rc5-mm1

[Matthias Hentges]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Am Samstag, den 09.09.2006, 16:47 -0700 schrieb Jeremy Fitzhardinge:
> Greg KH wrote:
> > There are 9 MSI patches in my tree that you can just remove.  They were
> > just recently (a few hours ago) replaced with a total rewrite due to a
> > number of different problems that were found.  So I'd suggest just
> > waiting till the next -mm release to see if it works properly or not.
> >   
> 
> I'm seeing exactly the same oops with CONFIG_MSI on 2.6.18-rc6-mm1.

Same here.
-- 
Matthias 'CoreDump' Hentges 

My OS: Debian SID. Geek by Nature, Linux by Choice

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[2.6.18-rc5-mm1 ACPI] Unknown exception code: 0xFFFFFFEA

[Mike Galbraith]

Greetings,

My single P4/HT box tossed the below on boot.

	-Mike

ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
 [<c1004089>] dump_trace+0x1d7/0x206
 [<c10040d2>] show_trace_log_lvl+0x1a/0x30
 [<c100484c>] show_trace+0x12/0x14
 [<c100496d>] dump_stack+0x19/0x1b
 [<c1229702>] acpi_format_exception+0xa2/0xaf
 [<c1226824>] acpi_ut_status_exit+0x2b/0x58
 [<c1222cbc>] acpi_walk_resources+0xfd/0x109
 [<c12393ca>] acpi_motherboard_add+0x22/0x32
 [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
 [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
 [<c15ebd20>] acpi_motherboard_init+0xd/0xf9
 [<c10003b1>] init+0x108/0x300
 [<c1003c93>] kernel_thread_helper+0x7/0x14
 =======================
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
 [<c1004089>] dump_trace+0x1d7/0x206
 [<c10040d2>] show_trace_log_lvl+0x1a/0x30
 [<c100484c>] show_trace+0x12/0x14
 [<c100496d>] dump_stack+0x19/0x1b
 [<c1229702>] acpi_format_exception+0xa2/0xaf
 [<c1226824>] acpi_ut_status_exit+0x2b/0x58
 [<c1222cbc>] acpi_walk_resources+0xfd/0x109
 [<c12393ca>] acpi_motherboard_add+0x22/0x32
 [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
 [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
 [<c15ebd2a>] acpi_motherboard_init+0x17/0xf9
 [<c10003b1>] init+0x108/0x300
 [<c1003c93>] kernel_thread_helper+0x7/0x14
 =======================
ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
 [<c1004089>] dump_trace+0x1d7/0x206
 [<c10040d2>] show_trace_log_lvl+0x1a/0x30
 [<c100484c>] show_trace+0x12/0x14
 [<c100496d>] dump_stack+0x19/0x1b
 [<c1229702>] acpi_format_exception+0xa2/0xaf
 [<c1226824>] acpi_ut_status_exit+0x2b/0x58
 [<c1222cbc>] acpi_walk_resources+0xfd/0x109
 [<c12393ca>] acpi_motherboard_add+0x22/0x32
 [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
 [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
 [<c15ebd2a>] acpi_motherboard_init+0x17/0xf9
 [<c10003b1>] init+0x108/0x300
 [<c1003c93>] kernel_thread_helper+0x7/0x14
 =======================



-- 
VGER BF report: U 0.500346

Re: [2.6.18-rc5-mm1 ACPI] Unknown exception code: 0xFFFFFFEA

[Bjorn Helgaas]

On Sunday 03 September 2006 03:09, Mike Galbraith wrote:
> My single P4/HT box tossed the below on boot.
> 
> ACPI Error (utglobal-0125): Unknown exception code: 0xFFFFFFEA [20060707]
>  [<c1004089>] dump_trace+0x1d7/0x206
>  [<c10040d2>] show_trace_log_lvl+0x1a/0x30
>  [<c100484c>] show_trace+0x12/0x14
>  [<c100496d>] dump_stack+0x19/0x1b
>  [<c1229702>] acpi_format_exception+0xa2/0xaf
>  [<c1226824>] acpi_ut_status_exit+0x2b/0x58
>  [<c1222cbc>] acpi_walk_resources+0xfd/0x109
>  [<c12393ca>] acpi_motherboard_add+0x22/0x32
>  [<c123848e>] acpi_bus_driver_init+0x2a/0x7a
>  [<c123892c>] acpi_bus_register_driver+0x8b/0xfb
>  [<c15ebd20>] acpi_motherboard_init+0xd/0xf9
>  [<c10003b1>] init+0x108/0x300
>  [<c1003c93>] kernel_thread_helper+0x7/0x14

This ACPI "unknown exception code" problem is the same one reported here:
  http://www.mail-archive.com/linux-acpi%40vger.kernel.org/msg02873.html

Basically, we just need to revert this:
  http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc4/2.6.18-rc4-mm3/broken-out/hot-add-mem-x86_64-acpi-motherboard-fix.patch

The above patch happened to fix a hot-add memory problem, but it was
the wrong fix, and we're working out a better one.

[-mm patch] ACPI_SONY shouldn't default m

[Adrian Bunk]

Drivers should default to n.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig.old	2006-09-07 00:49:37.000000000 +0200
+++ linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig	2006-09-07 00:50:01.000000000 +0200
@@ -251,7 +251,6 @@
 config ACPI_SONY
 	tristate "Sony Laptop Extras"
 	depends on X86 && ACPI
-	default m
 	  ---help---
 	  This mini-driver drives the ACPI SNC device present in the
 	  ACPI BIOS of the Sony Vaio laptops.

Re: [-mm patch] ACPI_SONY shouldn't default m

[Andrew Morton]

On Thu, 7 Sep 2006 01:07:00 +0200
Adrian Bunk <bunk@stusta.de> wrote:

> Drivers should default to n.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> --- linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig.old	2006-09-07 00:49:37.000000000 +0200
> +++ linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig	2006-09-07 00:50:01.000000000 +0200
> @@ -251,7 +251,6 @@
>  config ACPI_SONY
>  	tristate "Sony Laptop Extras"
>  	depends on X86 && ACPI
> -	default m

Not this one - I need it on my Vaio and I get sick of the option vanishing.
Make it depend on CONFIG_AKPM?

Re: [-mm patch] ACPI_SONY shouldn't default m

[Randy.Dunlap]

On Wed, 6 Sep 2006 20:30:03 -0700 Andrew Morton wrote:

> On Thu, 7 Sep 2006 01:07:00 +0200
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > Drivers should default to n.
> > 
> > Signed-off-by: Adrian Bunk <bunk@stusta.de>
> > 
> > --- linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig.old	2006-09-07 00:49:37.000000000 +0200
> > +++ linux-2.6.18-rc5-mm1/drivers/acpi/Kconfig	2006-09-07 00:50:01.000000000 +0200
> > @@ -251,7 +251,6 @@
> >  config ACPI_SONY
> >  	tristate "Sony Laptop Extras"
> >  	depends on X86 && ACPI
> > -	default m
> 
> Not this one - I need it on my Vaio and I get sick of the option vanishing.
> Make it depend on CONFIG_AKPM?

I'll ack that one.  :)
otherwise I also agree with Adrian's patch...

---
~Randy

RE: 2.6.18-rc5-mm1

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Andrew Morton [mailto:akpm@osdl.org] 
>Sent: Friday, September 01, 2006 6:30 PM
>To: Matthias Hentges
>Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org; 
>Pallipadi, Venkatesh
>Subject: Re: 2.6.18-rc5-mm1
>
>On Sat, 02 Sep 2006 03:00:47 +0200
>Matthias Hentges <oe@hentges.net> wrote:
>
>> 2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
>> attached.
>> This did not happen in 2.6.18-rc4-mm3.
>> 
>> 
>> BUG: unable to handle kernel NULL pointer dereference at 
>virtual address
>> 00000000
>>  printing eip:
>> 00000000
>> *pde = 00000000
>> Oops: 0000 [#1]
>> 4K_STACKS SMP 
>> last sysfs file: 
>> Modules linked in:
>> CPU:    0
>> EIP:    0060:[<00000000>]    Not tainted VLI
>> EFLAGS: 00010087   (2.6.18-rc5-mm1 #1) 
>> EIP is at rest_init+0x3feffd78/0x20
>> eax: 000000da   ebx: c04d5f78   ecx: c04d5f94   edx: c04d2f00
>> esi: 000000da   edi: 00000000   ebp: c04d2f00   esp: c0516ffc
>> ds: 007b   es: 007b   ss: 0068
>> Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
>> Stack: c0105027 
>> Call Trace:
>>  [<c0105027>] do_IRQ+0x8a/0xac
>>  [<c01035a6>] common_interrupt+0x1a/0x20
>>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>>  [<c0101a83>] mwait_idle+0xc/0x1b
>>  [<c0101a26>] cpu_idle+0x5e/0x74
>>  [<c04db6fa>] start_kernel+0x363/0x36a
>>  =======================
>> Code:  Bad EIP value.
>> EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
>>  <0>Kernel panic - not syncing: Fatal exception in interrupt
>>  BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
>>  [<c010ca45>] smp_call_function+0x54/0xff
>>  [<c011a270>] printk+0x12/0x16
>>  [<c010cb03>] smp_send_stop+0x13/0x1c
>>  [<c0119480>] panic+0x49/0xd3
>>  [<c010410c>] die+0x273/0x28a
>>  [<c01126d4>] do_page_fault+0x40d/0x4db
>>  [<c01122c7>] do_page_fault+0x0/0x4db
>>  [<c03d1231>] error_code+0x39/0x40
>>  [<c013007b>] free_module+0x89/0xc3
>>  [<c0105027>] do_IRQ+0x8a/0xac
>>  [<c01035a6>] common_interrupt+0x1a/0x20
>>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
>>  [<c0101a83>] mwait_idle+0xc/0x1b
>>  [<c0101a26>] cpu_idle+0x5e/0x74
>>  [<c04db6fa>] start_kernel+0x363/0x36a
>>  =======================
>
>OK, thanks.  That'll be acpi-mwait-c-state-fixes.patch.  I've 
>uploaded the
>below revert patch to
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/
>

Andrew,

As this patch doesn't seem to be the issue here, can you un-revert the
patch in mm...

Thanks,
Venki

-- 
VGER BF report: H 2.25892e-12

Re: 2.6.18-rc5-mm1

[Andrew Morton]

On Sun, 3 Sep 2006 17:22:17 -0700
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:

>  
> 
> >-----Original Message-----
> >From: Andrew Morton [mailto:akpm@osdl.org] 
> >Sent: Friday, September 01, 2006 6:30 PM
> >To: Matthias Hentges
> >Cc: linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org; 
> >Pallipadi, Venkatesh
> >Subject: Re: 2.6.18-rc5-mm1
> >
> >On Sat, 02 Sep 2006 03:00:47 +0200
> >Matthias Hentges <oe@hentges.net> wrote:
> >
> >> 2.6.18-rc5-mm1 oopses on an Asus P5W DH Deluxe board, full dmesg
> >> attached.
> >> This did not happen in 2.6.18-rc4-mm3.
> >> 
> >> 
> >> BUG: unable to handle kernel NULL pointer dereference at 
> >virtual address
> >> 00000000
> >>  printing eip:
> >> 00000000
> >> *pde = 00000000
> >> Oops: 0000 [#1]
> >> 4K_STACKS SMP 
> >> last sysfs file: 
> >> Modules linked in:
> >> CPU:    0
> >> EIP:    0060:[<00000000>]    Not tainted VLI
> >> EFLAGS: 00010087   (2.6.18-rc5-mm1 #1) 
> >> EIP is at rest_init+0x3feffd78/0x20
> >> eax: 000000da   ebx: c04d5f78   ecx: c04d5f94   edx: c04d2f00
> >> esi: 000000da   edi: 00000000   ebp: c04d2f00   esp: c0516ffc
> >> ds: 007b   es: 007b   ss: 0068
> >> Process swapper (pid: 0, ti=c0516000 task=c045c200 task.ti=c04d5000)
> >> Stack: c0105027 
> >> Call Trace:
> >>  [<c0105027>] do_IRQ+0x8a/0xac
> >>  [<c01035a6>] common_interrupt+0x1a/0x20
> >>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
> >>  [<c0101a83>] mwait_idle+0xc/0x1b
> >>  [<c0101a26>] cpu_idle+0x5e/0x74
> >>  [<c04db6fa>] start_kernel+0x363/0x36a
> >>  =======================
> >> Code:  Bad EIP value.
> >> EIP: [<00000000>] rest_init+0x3feffd78/0x20 SS:ESP 0068:c0516ffc
> >>  <0>Kernel panic - not syncing: Fatal exception in interrupt
> >>  BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
> >>  [<c010ca45>] smp_call_function+0x54/0xff
> >>  [<c011a270>] printk+0x12/0x16
> >>  [<c010cb03>] smp_send_stop+0x13/0x1c
> >>  [<c0119480>] panic+0x49/0xd3
> >>  [<c010410c>] die+0x273/0x28a
> >>  [<c01126d4>] do_page_fault+0x40d/0x4db
> >>  [<c01122c7>] do_page_fault+0x0/0x4db
> >>  [<c03d1231>] error_code+0x39/0x40
> >>  [<c013007b>] free_module+0x89/0xc3
> >>  [<c0105027>] do_IRQ+0x8a/0xac
> >>  [<c01035a6>] common_interrupt+0x1a/0x20
> >>  [<c0101a72>] mwait_idle_with_hints+0x36/0x3b
> >>  [<c0101a83>] mwait_idle+0xc/0x1b
> >>  [<c0101a26>] cpu_idle+0x5e/0x74
> >>  [<c04db6fa>] start_kernel+0x363/0x36a
> >>  =======================
> >
> >OK, thanks.  That'll be acpi-mwait-c-state-fixes.patch.  I've 
> >uploaded the
> >below revert patch to
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
> >.6.18-rc5/2.6.18-rc5-mm1/hot-fixes/
> >
> 
> Andrew,
> 
> As this patch doesn't seem to be the issue here, can you un-revert the
> patch in mm...
> 

Spose so.

But what _did_ cause it?  Looks like we took an IRQ and then leapt into
outer space, when do_IRQ() called desc->handle_irq().

Matthias, could you please test with CONFIG_4KSTACKS=n?

Also, one cause of this might be a module which fails to clean up when it's
removed.  And the trace indicates that some module has previously
been unloaded.  Can you work out which module(s) that might be?


-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Jeremy Fitzhardinge]

Andrew Morton wrote:
> Spose so.
>
> But what _did_ cause it?  Looks like we took an IRQ and then leapt into
> outer space, when do_IRQ() called desc->handle_irq().
>   

It was specifically an MSI interrupt problem; disabling CONFIG_MSI fixed 
the problem for me.  GregKH said that the MSI patch series in rc5-mm1 is 
broken, and had been replaced.

    J

-- 
VGER BF report: H 0

Re: 2.6.18-rc5-mm1

[Matthias Hentges]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

Am Sonntag, den 03.09.2006, 17:50 -0700 schrieb Andrew Morton:

> Spose so.
> 
> But what _did_ cause it?  Looks like we took an IRQ and then leapt into
> outer space, when do_IRQ() called desc->handle_irq().
> 
> Matthias, could you please test with CONFIG_4KSTACKS=n?
> 
> Also, one cause of this might be a module which fails to clean up when it's
> removed.  And the trace indicates that some module has previously
> been unloaded.  Can you work out which module(s) that might be?
> 

I'll try CONFIG_4KSTACKS=n when I get back from work (~10hrs...) and
report back.
-- 
Matthias 'CoreDump' Hentges 

Webmaster of hentges.net and OpenZaurus developer.
You can reach me in #openzaurus on Freenode.

My OS: Debian SID. Geek by Nature, Linux by Choice

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.18-rc5-mm1

[Matthias Hentges]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

Am Montag, den 04.09.2006, 13:52 +0200 schrieb Matthias Hentges:
> Am Sonntag, den 03.09.2006, 17:50 -0700 schrieb Andrew Morton:
> 
> > Spose so.
> > 
> > But what _did_ cause it?  Looks like we took an IRQ and then leapt into
> > outer space, when do_IRQ() called desc->handle_irq().
> > 
> > Matthias, could you please test with CONFIG_4KSTACKS=n?
> > 
> > Also, one cause of this might be a module which fails to clean up when it's
> > removed.  And the trace indicates that some module has previously
> > been unloaded.  Can you work out which module(s) that might be?
> > 
> 
> I'll try CONFIG_4KSTACKS=n when I get back from work (~10hrs...) and
> report back.

Just tried CONFIG_4KSTACKS=n but as Jeremy Fitzhardinge suggested, it
didn't change anything ;)
-- 
Matthias 'CoreDump' Hentges 

Webmaster of hentges.net and OpenZaurus developer.
You can reach me in #openzaurus on Freenode.

My OS: Debian SID. Geek by Nature, Linux by Choice

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 189 bytes --]