Soeren Sonnenburg wrote:
On Sat, 2009-11-21 at 01:58 -0800, Justin P. Mattock wrote:
Soeren Sonnenburg wrote:
On Sat, 2009-11-21 at 09:56 +0100, Soeren Sonnenburg wrote:
On Wed, 2009-11-18 at 18:59 -0800, Dmitry Torokhov wrote:
On Tue, Nov 17, 2009 at 05:06:47AM +0100, Soeren Sonnenburg wrote:
On Mon, 2009-11-16 at 20:01 -0800, Dmitry Torokhov wrote:
On Tue, Nov 17, 2009 at 03:59:03AM +0100, Soeren Sonnenburg wrote:
On Mon, 2009-11-16 at 18:04 -0800, Dmitry Torokhov wrote:
On Mon, Nov 16, 2009 at 05:14:55PM -0800, Greg KH wrote:
On Mon, Nov 16, 2009 at 11:37:48PM +0100, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14626
Subject : oops on boot starting udev
Submitter : Soeren Sonnenburg<sonne@xxxxxxxxxx>
Date : 2009-11-14 10:16 (3 days old)
References : http://marc.info/?l=linux-kernel&m=125819380206800&w=4
This looks like an input core problem, as the evdev module was just
loaded and died.
Any input developers have any ideas?
Hmm, evdev does:
dev_set_name(&evdev->dev, "event%d", minor);
Not sure how it can go wrong...
Anything I should/could do to narrow it down a bit (apart from
bisecting?).
Umm, I looked through the changes between -rc6 and 7 but nothing jumped
out at me... You don't happen to have any local changes in your tree?
Well only the mouse button #1 emulation - though I don't see what could
go wrong there.
I have been looking through the changes and I really don't see anything
suspicious. I am also not hittign this oops on any of my boxes. Any
chance you could bisect?
Thanks.
Alright so I tried to do a bisect when I noticed that building a knwon
to work -rc5 did no longer work either. Thought it might be a gcc
problem (gcc-4.3 here) so upgraded to 4.4 - same thing.
Then I recognized that it crashes on loading basically *any* module,
tried tun and applesmc. Attaching the crashes...
I am starting to run out of ideas...
OK, I've found the culprit: binutils-gold
I build all kernels upto and including -rc6 with the old binutils and
since then have upgraded to binutils gold 2.20-4 which - in contrast to
the old binutils - uses --no-add-needed per default.
So I suspect it triggers an error(?) in the way how the kernel links
modules: It is now required to provide all needed libraries to the
linker when building the modules. I guess this problem could be worked
around by adding --add-needed to the LDFLAGS_MODULE ...
Soeren
tough to say... some how your hitting
__wait_status during your initial boot.
by looking at the comment(in applesmc.c):
__wait_status - Wait up to 32ms for the status port to get a certain value
* (masked with 0x0f), returning zero if the value is obtained.
maybe your hitting a different value because of binutls.
It could be anything missing...
(keep in mind I have the latest binutils running on the macbook,
but nothing switched to gold during compilation time)
Note that everything works fine with the old binutils here too.You will
need binutils gold to see the problem and it is described here too
http://wiki.debian.org/qa.debian.org/FTBFS#A2009-11-02Packagesfailingbecausebinutils-gold.2BAC8-indirectlinking
Soeren
Well I'd like to go into building
gcc with the switch of: --disable-multilib
but I cant because of the whole "gold factor"
maybe somebody else with this knowledge of(gold) gcc etc...
can assist you because I have no knowledge of that .
(I'll have to try building a system this way one day);
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
