Bug 14626 - oops on boot starting udev
Summary: oops on boot starting udev
Status: CLOSED DOCUMENTED
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: io_other
URL:
Keywords:
Depends on:
Blocks: 14230
  Show dependency tree
 
Reported: 2009-11-16 22:07 UTC by Rafael J. Wysocki
Modified: 2009-11-21 14:33 UTC (History)
0 users

See Also:
Kernel Version: 2.6.32-rc7
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Rafael J. Wysocki 2009-11-16 22:07:30 UTC
Subject    : 2.6.32-rc7 regression, oops on boot starting udev
Submitter  : Soeren Sonnenburg <sonne@debian.org>
Date       : 2009-11-14 10:16
References : http://marc.info/?l=linux-kernel&m=125819380206800&w=4
Notify-Also : Greg KH <greg@kroah.com>

This entry is being used for tracking a regression from 2.6.31.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Rafael J. Wysocki 2009-11-21 14:31:04 UTC
On Saturday 21 November 2009, 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@debian.org>
> > > > > > > > > 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 ...

Note You need to log in before you can comment on or make changes to this bug.