public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Krzysztof Oledzki <olel@ans.pl>
Cc: Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	stable@kernel.org, lwn@lwn.net
Subject: Re: Linux 2.6.27.27
Date: Tue, 21 Jul 2009 12:15:39 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.2.01.0907211133010.19335@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.01.0907210906400.19335@localhost.localdomain>



On Tue, 21 Jul 2009, Linus Torvalds wrote:
> 
> Great. This is all about as perfect as could be asked for. Now it's just a 
> question of trying to find the right code generation difference...

Ok, that "just" is turning out to be really painful.

I've tried to do clever things, but the best I've been able to do is to 
get the relevant differences down to about 22 thousand lines of assembler 
diffs that don't match either of the working kernels. Sadly, 22KLOC of 
assembler diffs isn't something anybody can reasonably read to even start 
to make a guess about which lines are causing problems. 

So what I'd love to do is to narrow the failure down a bit, by using 
-fno-strict-overflow only on _parts_ of the tree and then try a couple of 
kernels to see if they hang, to see which part it is that mis-compiles.

With a newer kernel, we could do something like this:

	diff --git a/Makefile b/Makefile
	index 79957b3..b096be2 100644
	--- a/Makefile
	+++ b/Makefile
	@@ -565,9 +565,6 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
	 # disable pointer signed / unsigned warnings in gcc 4.0
	 KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
	 
	-# disable invalid "can't wrap" optimizations for signed / pointers
	-KBUILD_CFLAGS	+= $(call cc-option,-fno-strict-overflow)
	-
	 # revert to pre-gcc-4.4 behaviour of .eh_frame
	 KBUILD_CFLAGS	+= $(call cc-option,-fno-dwarf2-cfi-asm)
	 
	diff --git a/drivers/Makefile b/drivers/Makefile
	index bc4205d..1250b55 100644
	--- a/drivers/Makefile
	+++ b/drivers/Makefile
	@@ -5,6 +5,8 @@
	 # Rewritten to use lists instead of if-statements.
	 #
	 
	+subdir-ccflags-y += -fno-strict-overflow
	+
	 obj-y				+= gpio/
	 obj-$(CONFIG_PCI)		+= pci/
	 obj-$(CONFIG_PARISC)		+= parisc/

to say "use -fno-strict-overflow only when compiling objects in the
drivers/ subdirectories", but I'm pretty sure that whole clever
'subdir-ccflags-y' thing was added pretty recently, and won't work in
2.6.27

However, since there is _some_ reason to wonder about whether the problem 
could be in radeonfb (because the last printouts before the hang are about 
that), it would be good to test just that part.

So if you have the time and energy, it would be very interesting if you 
could do something like this:

 - remove the "KBUILD_CFLAGS  += $(call cc-option,-fno-strict-overflow)"
   entirely from the main Makefile.

 - one directory at a time, add

	ccflags-y += -fno-strict-overflow

   to the Makefile in just that particular directory, and compile and test 
   the kernel. Now, since your old kernel doesn't have that nifty new
   "subdir-ccflags-y" thing, you can't do it for big parts of the kernel, 
   you can literally do it for just the contents of one subdirectory 
   (non-recusive!) at a time, but while there's two thousand 
   subdirectories in the Linux kernel sources, judicious sprinking of that 
   into the tree could hopefully make it possible to find.

 - the first Makefile's to test would be 'drivers/video/aty/Makefile'. If 
   that one doesn't work, some scripting might be in order, eg something 
   like

	for i in $(find drivers -name Makefile)
	do
		( echo "ccflags-y += -fno-strict-overflow" ; cat $i ) > $i.new
		mv $i.new $i
	done

   should add it to all the subdirectories under 'drivers', etc.

and if you can find the subdirectory where '-fno-strict-overflow' makes 
the difference, at that point I'd love to see the kernel image where 
things worked (ie the last kernel you booted successfully _before_ the 
kernel that failed) and the kernel that fails - now hopefully the 
differences should be much smaller (how small will obviously depend on 
whether you caught the difference in just one subdirectory or whether you 
scripted it over lots and lots of subdirectories).

Of course, the tighter you can do this, the better. If it happens to be in 
'drivers/video/aty/' for example, and you end up being really gung-ho 
about this and want to narrow it down to not just the subdirectory, but a 
few files, you could remove the per-directory "ccflags-y" line, and do a 
few per-file CFLAGS entries instead, like:

	CFLAGS_radeon_base.o += -fno-strict-overflow

etc.

And hey, if you think this is too much work, then you're right. It's a lot 
of work. So don't worry if you can't be bothered - it would be wonderful 
to try to get this thing resolved, but I do realize I'm asking a lot here.

			Linus

  reply	other threads:[~2009-07-21 19:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-20  4:06 Linux 2.6.27.27 Greg KH
2009-07-20  4:07 ` Greg KH
2009-07-20 11:51 ` Krzysztof Oledzki
2009-07-20 15:10   ` Greg KH
2009-07-20 16:01     ` Linus Torvalds
2009-07-20 21:45       ` Krzysztof Oledzki
2009-07-20 22:08         ` Linus Torvalds
2009-07-20 23:47           ` Marc Dionne
2009-07-20 23:56             ` Linus Torvalds
2009-07-21  0:37               ` Marc Dionne
2009-07-21  1:01                 ` Linus Torvalds
2009-07-21  6:40                   ` Krzysztof Oledzki
2009-07-21  1:05                 ` Linus Torvalds
2009-07-21  2:38                   ` Marc Dionne
2009-07-21  6:33           ` Krzysztof Oledzki
2009-07-21 10:16             ` Krzysztof Oledzki
2009-07-21 16:11               ` Linus Torvalds
2009-07-21 19:15                 ` Linus Torvalds [this message]
2009-07-21 21:34                   ` Troy Moure
2009-07-22  0:53                     ` Linus Torvalds
2009-07-22  1:07                       ` Linus Torvalds
2009-07-22  6:16                         ` Troy Moure
2009-07-22 15:58                           ` Linus Torvalds
2009-07-22  1:16                       ` Linus Torvalds
2009-07-22  8:12                         ` Krzysztof Oledzki
2009-07-22  8:32                           ` Krzysztof Oledzki
2009-07-22  9:55                             ` Krzysztof Oledzki
2009-07-22 10:44                               ` Krzysztof Oledzki
2009-07-22  9:58                             ` Jens Rosenboom
2009-07-22 10:27                               ` Troy Moure
2009-07-22 10:54                               ` Krzysztof Oledzki
2009-07-22 10:24                             ` Troy Moure
2009-07-22 10:33                             ` Dick Streefland
2009-07-22 13:48                         ` Krzysztof Oledzki
2009-07-22 15:48                           ` Linus Torvalds
2009-07-29 14:57                             ` Pavel Machek
2009-07-29 15:59                               ` Linus Torvalds
2009-07-22 11:49                       ` Krzysztof Oledzki
2009-07-22 13:27                         ` Henrique de Moraes Holschuh
2009-07-22 13:45                         ` Krzysztof Oledzki
2009-07-22 15:36                         ` Ian Lance Taylor
2009-07-23 17:33     ` Krzysztof Olędzki
2009-07-24 21:13       ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.01.0907211133010.19335@localhost.localdomain \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lwn@lwn.net \
    --cc=olel@ans.pl \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox