Messages in this thread | | | Date | Wed, 05 Sep 2007 22:24:07 +0300 | From | Stefan Becker <> | Subject | Re: [pre-2.6.23 REGRESSION] 2.6.23-rc3-git1 crash/stuck on VIA CN700 system |
| |
Hi,
ext Andi Kleen wrote: >> flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge cmov pat >> clflush acpi mmx fxsr sse sse2 tm up pni est tm2 rng rng_en ace ace_en > > Hmm, I can't really see anything wrong. This means the original > version of the patch you found had a few problems, but they > were all fixed later and only applied with CONFIG_PARAVIRT enabled anyways. > > As a stab in the dark since the CPU has clflush can you please > comment out the > > if (cpu_has_clflush) > asm("clflush (%0) " :: "r" (addr) : "memory"); > > statement in arch/i386/kernel/alternative.c and see if it makes a difference? > Perhaps your CPU doesn't like that (it seems to have clflush) > > If that doesn't help it might be needed to revert the patch > hunk by hunk to see which text_poke() invocation caused it.
OK, I reset my working area to the master branch (i.e. 2.6.23-rc5-gitX) and then changed text_poke() to read
void __kprobes text_poke(void *addr, unsigned char *opcode, int len) { memcpy(addr, opcode, len); sync_core(); /* Not strictly needed, but can speed CPU recovery up. Ignore cross cacheline case. */ #if 0 if (cpu_has_clflush) asm("clflush (%0) " :: "r" (addr) : "memory"); #endif }
This kernel boots up OK. Looking at the preprocessed C code the following code in alternative_instructions() is compiled in:
#ifdef CONFIG_SMP if (smp_alt_once) { if (1 == num_possible_cpus()) { printk(KERN_INFO "SMP alternatives: switching to UP code\n"); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This I still see at bootup
set_bit(X86_FEATURE_UP, boot_cpu_data.x86_capability); set_bit(X86_FEATURE_UP, cpu_data[0].x86_capability); alternatives_smp_unlock(__smp_locks, __smp_locks_end, _text, _etext);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this function uses text_poke() ---> BOOM } free_init_pages("SMP alternatives", (unsigned long)__smp_locks, (unsigned long)__smp_locks_end);
So what can we do about the clflush on this CPU?
Regards,
Stefan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |