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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

[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]
  Powered by Linux