* Andrew Morton <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
