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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
