On Sat, 2009-11-21 at 09:56 +0100, Soeren Sonnenburg wrote:tough to say... some how your hitting
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:Alright so I tried to do a bisect when I noticed that building a knwon
On Mon, 2009-11-16 at 20:01 -0800, Dmitry Torokhov wrote:I have been looking through the changes and I really don't see anything
On Tue, Nov 17, 2009 at 03:59:03AM +0100, Soeren Sonnenburg wrote:Well only the mouse button #1 emulation - though I don't see what could
On Mon, 2009-11-16 at 18:04 -0800, Dmitry Torokhov wrote:Umm, I looked through the changes between -rc6 and 7 but nothing jumped
On Mon, Nov 16, 2009 at 05:14:55PM -0800, Greg KH wrote:Anything I should/could do to narrow it down a bit (apart from
On Mon, Nov 16, 2009 at 11:37:48PM +0100, Rafael J. Wysocki wrote:Hmm, evdev does:
This message has been generated automatically as a part of a reportThis looks like an input core problem, as the evdev module was just
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
loaded and died.
Any input developers have any ideas?
dev_set_name(&evdev->dev, "event%d", minor);
Not sure how it can go wrong...
bisecting?).
out at me... You don't happen to have any local changes in your tree?
go wrong there.
suspicious. I am also not hittign this oops on any of my boxes. Any
chance you could bisect?
Thanks.
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