From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261841AbTKRRJt (ORCPT ); Tue, 18 Nov 2003 12:09:49 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263723AbTKRRJt (ORCPT ); Tue, 18 Nov 2003 12:09:49 -0500 Received: from modemcable137.219-201-24.mc.videotron.ca ([24.201.219.137]:56194 "EHLO montezuma.fsmlabs.com") by vger.kernel.org with ESMTP id S261841AbTKRRJq (ORCPT ); Tue, 18 Nov 2003 12:09:46 -0500 Date: Tue, 18 Nov 2003 12:08:43 -0500 (EST) From: Zwane Mwaikambo To: Linus Torvalds cc: Ingo Molnar , "Martin J. Bligh" , Andrew Morton , Linux Kernel , linux-mm@kvack.org, Hugh Dickins Subject: Re: [PATCH][2.6-mm] Fix 4G/4G X11/vm86 oops In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 18 Nov 2003, Linus Torvalds wrote: > Ok. Much more readable. > > And there is something very suspicious there. > > The code with and without the printk() looks _identical_ apart from some > trivial label renumbering, and the added > > pushl $.LC6 > call printk > .. asm .. > popl %esi > > which all looks fine (esi is dead at that point, so the compiler is just > using a "popl" as a shorter form of "addl $4,%esp"). > > Btw, you seem to compile with debugging, which makes the assembly > language pretty much unreadable and accounts for most of the > differences: the line numbers change. If you compile a kernel where the > line numbers don't change (by commenting _out_ the printk rather than > removing the whole line), your diff would be more readable. Aha! Thanks for mentioning that, noted. > Anyway, there are _zero_ differences. > > Just for fun, try this: move the "printk()" to _below_ the "asm" > statement. It will never actually get executed, but if it's an issue of > some subtle code or data placement things (cache lines etc), maybe that > also hides the oops, since all the same code and data will be generated, > just not run... Ok i just tried that and it still fails. Matt Mackall suggested i also try writing a minimal printk which has the same effect.