Bug 218234 - "udev_run_hotplugd abnormal exit" on a startup
"udev_run_hotplugd abnormal exit" on a startup
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-03 17:59 EST by Michal Jaegermann
Modified: 2008-08-02 19:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 12:03:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
udevdebug output from a "level 3" boot (28.02 KB, text/plain)
2006-12-05 13:32 EST, Michal Jaegermann
no flags Details
udevdebug output from a "normal" boot (33.38 KB, text/plain)
2006-12-05 13:33 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2006-12-03 17:59:35 EST
Description of problem:

Sometimes, and I really mean "sometimes", when booting an FC6
machine something like that shows up from udev startup:
 
  udev: /lib/udev/udev_run_hotplugd abnormal exit

followed by "[ OK ]".  The reason for "something like that" is that
every time I observed that a machine was booting into a level 5 and
with rhgb so this message quickly vanished from a screen never to be
seen again.  I failed to find something in logs which would
look like associated with such event and it appears that things are
"normal" after that.

OTOH a newly inserted Cardbus card (a wireless interface) is not
automatically recognized, always, and it needs '/sbin/pccardctl insert'
to show up to the system; and I wonder if this is not really related
to the above with a possibilty that such failure is usually silent.

Version-Release number of selected component (if applicable):
udev-095-14

How reproducible:
I did not managed to get that even once when I tried to reproduce
that and look closer.  OTOH the message was observed many times.
Comment 1 Bill Nottingham 2006-12-05 12:26:22 EST
/lib/udev/udev_run_hotplugd is provided by udev. Tag!
Comment 2 Harald Hoyer 2006-12-05 12:36:37 EST
do find something in /var/log/messages?
maybe you could boot with udevdebug in the kernel command line?
Comment 3 Michal Jaegermann 2006-12-05 13:31:21 EST
> do find something in /var/log/messages?

Quoting myself: "failed to find something in logs". Unfortunately.
This happens before anyting is mounted although syslogd should be
already running.

> maybe you could boot with udevdebug in the kernel command line?

Smells to me like some kind of a race so 'udevdebug' will likely
disturb that sufficiently enough. :-)  In any case - this is producing
so much output that if "abnormal exit" appears there somewhere
it is not likely to be noticed and I am not sure if everything is
logged.

I attach below two udev traces from logs.  One from a boot
to level 3 and another to level 5 with rhgb and all that jazz.
When booting to level 3 I later found in dmesg output, although not
in /var/log/messages, the following:

kobject_add failed for vcs1 with -EEXIST, don't try to register things with the
same name in the same directory.
 [<c04051db>] dump_trace+0x69/0x1af
 [<c0405339>] show_trace_log_lvl+0x18/0x2c
 [<c04058ed>] show_trace+0xf/0x11
 [<c04059ea>] dump_stack+0x15/0x17
 [<c04e52f2>] kobject_add+0x165/0x18e
 [<c0553703>] class_device_add+0xa2/0x3de
 [<c0553ad1>] class_device_create+0x82/0xa2
 [<c05373f0>] vcs_make_devfs+0x3c/0x7e
 [<c053c2bf>] con_open+0x6f/0x7c
 [<c0532bfe>] tty_open+0x1e2/0x369
 [<c0476eca>] chrdev_open+0xfb/0x12f
 [<c046de32>] __dentry_open+0xc7/0x1ab
 [<c046df90>] nameidata_to_filp+0x24/0x33
 [<c046dfd1>] do_filp_open+0x32/0x39
 [<c046e01a>] do_sys_open+0x42/0xbe
 [<c046e0cf>] sys_open+0x1c/0x1e
 [<c0404013>] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb
Leftover inexact backtrace:
 =======================
kobject_add failed for vcsa1 with -EEXIST, don't try to register things with the
same name in the same directory.
 [<c04051db>] dump_trace+0x69/0x1af
 [<c0405339>] show_trace_log_lvl+0x18/0x2c
 [<c04058ed>] show_trace+0xf/0x11
 [<c04059ea>] dump_stack+0x15/0x17
 [<c04e52f2>] kobject_add+0x165/0x18e
 [<c0553703>] class_device_add+0xa2/0x3de
 [<c0553ad1>] class_device_create+0x82/0xa2
 [<c053742d>] vcs_make_devfs+0x79/0x7e
 [<c053c2bf>] con_open+0x6f/0x7c
 [<c0532bfe>] tty_open+0x1e2/0x369
 [<c0476eca>] chrdev_open+0xfb/0x12f
 [<c046de32>] __dentry_open+0xc7/0x1ab
 [<c046df90>] nameidata_to_filp+0x24/0x33
 [<c046dfd1>] do_filp_open+0x32/0x39
 [<c046e01a>] do_sys_open+0x42/0xbe
 [<c046e0cf>] sys_open+0x1c/0x1e
 [<c0404013>] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb
Leftover inexact backtrace:
 =======================

and that seems to related to udevd operations.  These backtraces
were not repeated when booting to level 5 although another boot
to level 3 produced those again.  OTOH I cannot tell when I will
see "abnormal exit" the next time and I never encoutered such
thing when booting to level 3 (although this may be "luck";
I was not doing that as often as a "normal" boot).

Comment 4 Michal Jaegermann 2006-12-05 13:32:36 EST
Created attachment 142875 [details]
udevdebug output from a "level 3" boot
Comment 5 Michal Jaegermann 2006-12-05 13:33:16 EST
Created attachment 142876 [details]
udevdebug output from a "normal" boot
Comment 6 Michal Jaegermann 2006-12-05 13:36:35 EST
Oops! I should add. Backtraces in comment #3 are from 2.6.18-1.2849.fc6
kernel.
Comment 7 Michal Jaegermann 2006-12-05 14:20:57 EST
One more clarification to comment #3.  When booting to level 3 _without_
'udevdebug' I am not seeing backtraces as quoted there; or at least it
did not happen when I was checking.
Comment 8 Harald Hoyer 2007-09-20 06:52:14 EDT
still a problem with latest kernel/udev/fedora versions?
Comment 9 Michal Jaegermann 2007-09-24 12:47:46 EDT
> still a problem with latest kernel/udev/fedora versions?

I did not notice anything like that on a few tries with
2.6.22.5-49.fc6.  OTOH this was showing up only sporadically
so, unless an underlying cause is determined, who knows?
Comment 10 Harald Hoyer 2008-02-20 06:33:34 EST
Fixed in recent F8?
Comment 11 Michal Jaegermann 2008-02-20 11:35:58 EST
I did not observe that for a long time so I guess that it is gone
although noticing that never was easy.  OTOH comment #9 still applies.
Comment 12 Harald Hoyer 2008-02-20 11:47:56 EST
As far as I can interpret, the backtraces are from kernel drivers trying to
register files in sysfs. Namely "vcs1" and "vcsa1". Maybe a framebuffer module
not listed in /etc/modprobe.d/blacklist-compat.
Comment 13 Harald Hoyer 2008-02-20 11:49:01 EST
maybe a kernel guy can give more information on comment #3 ?
Comment 14 Michal Jaegermann 2008-02-20 12:26:13 EST
The backtrace from a comment #3 may, or may not, be releated to
those abnormal exits.  In any case this was a while.

AFAICT _currently_ framebuffer modules are listed in
/etc/modprobe.d/blacklist-compat.  If your guess is correct that
would prevent the problem from showing up.

The issue was reported well over a year ago and I am afraid that
currently all setup from that time (configurations, software versions)
is impossible for me to reproduce.  It now apparently vanished so,
unless somebody has some insights to share, I would think that this
could be closed.
Comment 15 Chuck Ebbert 2008-02-20 17:34:33 EST
(In reply to comment #13)
> maybe a kernel guy can give more information on comment #3 ?

That was an old kernel bug that was causing duplicate virtual console names to
be registered.
Comment 16 Harald Hoyer 2008-02-21 02:11:50 EST
close?
Comment 17 Bug Zapper 2008-04-04 01:05:05 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

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