Message-ID: <46DF0257.5050303@nokia.com>
Date: Wed, 05 Sep 2007 22:24:07 +0300
From: Stefan Becker <Stefan.Becker@nokia.com>
User-Agent: Thunderbird 2.0.0.5 (X11/20070719)
MIME-Version: 1.0
To: ext Andi Kleen <andi@firstfloor.org>
CC: ext Michal Piotrowski <michal.k.k.piotrowski@gmail.com>,
       linux-kernel@vger.kernel.org
Subject: Re: [pre-2.6.23 REGRESSION] 2.6.23-rc3-git1 crash/stuck on VIA CN700
 system
References: <46C9D148.5080505@nokia.com> <p734pibbbex.fsf@bingen.suse.de> <46DDA366.8090806@nokia.com> <20070905102525.GB31880@one.firstfloor.org> <46DECDC9.9050407@nokia.com> <20070905163724.GC31880@one.firstfloor.org>
In-Reply-To: <20070905163724.GC31880@one.firstfloor.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2271
Lines: 70

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/