lkml.org 
[lkml]   [2007]   [Dec]   [20]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 21 Dec 2007 00:47:59 +0100
FromIngo Molnar <>
SubjectRe: Linux 2.6.24-rc5 x86 architecture no longer Oopses...
* Andrew Morton <akpm@linux-foundation.org> wrote:

> Yes - I don't know why the smp_processor_id() test has suddenly 
> started triggering in there.

it's a "must not happen".

here:

>  		__raw_spin_lock(&die.lock);
>  		raw_local_save_flags(flags);
> -		die.lock_owner = smp_processor_id();
> +		die.lock_owner = raw_smp_processor_id();

we just disabled irqs with raw_local_save_flags().


here:

>  mem_parity_error(unsigned char reason, struct pt_regs * regs)
>  {
>  	printk(KERN_EMERG "Uhhuh. NMI received for unknown reason %02x on "
> -		"CPU %d.\n", reason, smp_processor_id());
> +		"CPU %d.\n", reason, raw_smp_processor_id());
>  	printk(KERN_EMERG "You have some hardware problem, likely on the PCI bus.\n");

we are straight into an NMI which has hardirqs disabled.


>  	printk(KERN_EMERG "Uhhuh. NMI received for unknown reason %02x on "
> -		"CPU %d.\n", reason, smp_processor_id());
> +		"CPU %d.\n", reason, raw_smp_processor_id());

ditto.

> @@ -708,7 +708,7 @@ void __kprobes die_nmi(struct pt_regs *r
>  	bust_spinlocks(1);
>  	printk(KERN_EMERG "%s", msg);
>  	printk(" on CPU%d, ip %08lx, registers:\n",
> -		smp_processor_id(), regs->ip);
> +		raw_smp_processor_id(), regs->ip);

same.

it needs to be found out why the preempt_count suddenly went to zero. Is 
task struct corruption out of question?

	Ingo


\
 
 \ /
  Last update: 2007-12-20 23:53    [from the cache]
©2003-2008