Re: [pre-2.6.23 REGRESSION] 2.6.23-rc3-git1 crash/stuck on VIA CN700system

[Stefan Becker]

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