Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 185983
Alias:
Product:
Component:
Status: RESOLVED
Resolution: FIXED
Assigned To: Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Bjoern Olausson <spamsuxx@gmail.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 185983 depends on: Show dependency tree
Bug 185983 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2007-07-20 13:35 0000
Starting udev: udevd-event[<four digit number>]: node_symlink: symlink (../md0,
/dev/md/0) failed. File exists.
Starting udev: udevd-event[<four digit number>]: node_symlink: symlink (../md1,
/dev/md/1) failed. File exists.
Starting udev: udevd-event[<four digit number>]: node_symlink: symlink (../md2,
/dev/md/2) failed. File exists.
Starting udev: udevd-event[<four digit number>]: node_symlink: symlink (../md3,
/dev/md/3) failed. File exists.

Afer a view minutes the system boots normally.



Reproducible: Always

Steps to Reproduce:
(0.Create a md raid array, wich kind does not matter)
1.reboot...
2.Fetch some soft drink
3.watch udev trying to simlink links that already exist.

Actual Results:  
Initrd AND udev, are trying to create the symlinks.

This results in the above errors and a veeeery long boot phase (didn't count
the minutes but at least 3-5 minutes)

Expected Results:  
Symlinks should be created by either UDEV or initrd, but not both.

Boot phase should  consume way less time.

With sys-fs/udev-104-r12 you can at leat see why the boot process hangs.
When installing udev-113-r2 there is no more output... it just hangs.

sys-apps/sysvinit-2.86-r5

*** Deprecated use of action 'info', use '--info' instead
Portage 2.1.2.9 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.5-r4,
2.6.21.6 i686)
=================================================================
System uname: 2.6.21.6 i686 Intel(R) Celeron(R) CPU 2.66GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Fri, 20 Jul 2007 10:50:01 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
ccache version 2.4 [enabled]
dev-lang/python:    2.4.4-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:    2.4-r7
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:  1.5.23b
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O2 -pipe -msse2 -mfpmath=sse -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /var/qmail/alias /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/
/etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild
/etc/terminfo /etc/texmf/web2c"
CXXFLAGS="-march=pentium4 -O2 -pipe -msse2 -mfpmath=sse -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms
strict"
GENTOO_MIRRORS="ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/
ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo
ftp://ftp.easynet.nl/mirror/gentoo/ http://distfiles.gentoo.org
http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LANG="de_DE.utf8"
LC_ALL="de_DE.utf8"
LINGUAS="en us de sv"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude=/distfiles --exclude=/local --exclude=/packages
--filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="7zip a52 aac aalib acl acpi alsa amr apache2 apm ares bash-completion
berkdb bitmap-fonts bittorrent bzip2 cairo cdparanoia cdr clamav clamd cli
cpudetection cracklib crypt cups curl dbus dcraw dga dri dts dv dvd dvdnav dvdr
dvdread eds emboss encode evo exif fam fbcon ffmpeg filter firefox flac fortran
gd gdbm geoip gif gnutls gpm gstreamer hal iconv imagemagick imap ipalias
isdnlog jpeg jpeg2k libg++ live lm_sensors logrotate lufsusermount lzo mad
madwifi matroska metalink midi mikmod mjpeg mmx mmxext mp2 mp3 mpeg mpeg2
mpm-prefork mudflap multiuser musepack mysql ncurses netpbm nls nptl nptlonly
oav ogg openmp opensslcrypt pam pcre pdf perl png postgres pppd python
qt3support quicktime quotas readline real reflection rewrite rrdtool rtc samba
sdl sensord serial session sftplogging shaper snmp softquota spell spl sqlite
sse sse2 ssl svg tcpd theora tiff tools truetype truetype-fonts type1-fonts
unicode unzip usb userlocales valias vhosts vidix vorbis vroot win32codecs
winbind x264 x86 xinetd xml xml2 xorg xpm xvid zip zlib" ALSA_CARDS="ali5451
als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370
ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident
usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy
dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear
meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc"
INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz
cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en us de sv"
USERLAND="GNU" VIDEO_CARDS="nvidia vesa fbdev nv"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, MAKEOPTS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

regards
Bjoern

------- Comment #1 From Matthias Schwarzott 2007-07-20 14:21:55 0000 -------
initrd definitely does not create nodes/symlinks inside /dev, as the
udev-start.sh script does mount a new, EMPTY tmpfs on /dev.

------- Comment #2 From Doug Goldstein 2007-07-20 15:09:21 0000 -------
Unfortunately a rack at the office is currently down so I can't live test this,
but I have machines with udev-104-r12 and this is not reproducable for me..

------- Comment #3 From Bjoern Olausson 2007-07-20 15:17:30 0000 -------
mmmh, okay, I tried to delete teh symlinks... BUT after a reboot... the same
story.

So what other app is able to create the symlinks BEVORE udev can do it?

Are the device nodes stored somwhere and restored at boot?

regards
Bjoern

------- Comment #4 From Bjoern Olausson 2007-07-20 15:23:03 0000 -------
mmmh, okay, I tried to delete teh symlinks... BUT after a reboot... the same
story.

So what other app is able to create the symlinks BEVORE udev can do it?

Are the device nodes stored somwhere and restored at boot?

regards
Bjoern

------- Comment #5 From Bjoern Olausson 2007-07-24 11:32:03 0000 -------
okay, I figured out that this only happens when I use my pata_hpt37x as a
module. Compiled into the kernel it works flawless.

For now I compiled it into the kernel but I would be interested in the reason
why udev behaves the I described it above.

regards
Bjoern

------- Comment #6 From Doug Goldstein 2007-07-24 21:56:11 0000 -------
Cause the HighPoint controller sucks and takes forever to initialize. I had a
HighPoint 366 and a 370. The code for this controller was equally as crappy.
I'm willing to bet when the module gets loaded by udev rather then loaded into
the kernel it literally takes minutes for the module to initialize and emit the
proper signal to udev.

------- Comment #7 From Bjoern Olausson 2007-07-25 12:49:12 0000 -------
This _WAS_ right, but with vanilla 2.6.22.1 this behavior changed (I can only
speak for hpt374). The disks are found right away. No more delay while
initiating the discs.

But i found a bug in the pata_hpt37x and reported it to the kernel bugtracker
and it got already fixed:
pata_hpt37x: BIOS has not set timing clocks
http://bugzilla.kernel.org/show_bug.cgi?id=8791

But both drivers work fine in 2.6.22.1 with the patch mentioned above.(the new
one belonging to the section "Serial ATA (prod) and Parallel ATA (experimental)
drivers" and the old one belonging to the section "ATA/ATAPI/MFM/RLL support"

regards
Bjoern

------- Comment #8 From Bjoern Olausson 2007-07-25 12:51:43 0000 -------
Maybe gentoo should incorporate this patch wehen gentoo-sources reaches the
2.6.22 line.

By the way, I didn't try the driver as module... but I think we can close this
bug, can't we?

regards
Bjoern

------- Comment #9 From Doug Goldstein 2007-07-25 13:02:11 0000 -------
gentoo-sources-2.6.22-r1 contain 2.6.22.1 already. However, I don't know what
the stabilization plans for that are. Possibly dsd will backport this to
2.6.21.

Since this is not a udev bug, but a kernel bug with questions for the kernel
guys. Re-assigning.

------- Comment #10 From Bjoern Olausson 2007-07-25 14:54:03 0000 -------
The actual question is still not answered... wy does udev behave like I
descibed?

Actually compiling the driver into the kernel is, more or less, a workaround
and does not solve the problem why udev hangs for mitnutes while it tries to
create the symlinks.... and that is IMHO not Kernel related.

I can open another bugreport for the patch inclusion.

regards
Bjoern

------- Comment #11 From Doug Goldstein 2007-07-25 14:59:41 0000 -------
(In reply to comment #10)
> The actual question is still not answered... wy does udev behave like I
> descibed?
> 

It behaves like that because of comment #6 by me. Which you yourself affirmed
and said was fixed in 2.6.22.1.

------- Comment #12 From Bjoern Olausson 2007-07-25 15:09:12 0000 -------
I know about that delay.... But why das the delay, wich occures while
initiating the devices, affect udev in such a way that it shows errors about
symlinks? That does not fit.

I commited that the delay with the new driver has gone. There is still the
delay whan you use the old kernel. But when compiled in the kernel, the delay
does not affect udev, cause the delay does happen long bevor init comes into
play.

And by the way... the delay, initiating the devices, does not take 5 Minutes,
not even one minute. So there is still an issue with udev wehn not using the
bleeding edge Kernel.

Any ideas?

regards
Bjoern

------- Comment #13 From Daniel Drake 2007-07-27 02:25:44 0000 -------
I find the above confusing, can you please clarify by answering these
questions:

With 2.6.21 and the HPT driver built into the kernel, does udev appear to hang
during boot?

With 2.6.21 and the HPT driver built as a module, does udev appear to hang
during boot?

With 2.6.22 plus the upstream clock patch with the HPT driver built into the
kernel, does udev appear to hang during boot?

With 2.6.22 plus the upstream clock patch with the HPT driver built as a
module, does udev appear to hang during boot?

------- Comment #14 From Doug Goldstein 2007-07-27 14:08:06 0000 -------
<Cardoe> dsd_: 2.6.22 + patch works in ALL situations
<Cardoe> dsd_: 2.6.21 works if compiled in kernel
<Cardoe> dsd_: 2.6.21 does not work properly when compiled as module.
<Cardoe> dsd_: I complained of the similar issue about 7 years ago when I got
that controller
<dsd_> Cardoe: ok thanks, any chance you can write that on the bug?

------- Comment #15 From Bjoern Olausson 2007-07-27 14:38:21 0000 -------
Sory for my delayed answere.

I but all I can do is to confirm the results Doug Goldstein posted in commnet
#14

Same behavior here.

regards
Bjoern Olausson

------- Comment #16 From Daniel Drake 2007-07-28 16:11:03 0000 -------
OK.

So it appears that the issue is a kernel issue (now fixed thanks to the
upstream bug report), but causes udev to print some confusing messages at
approximately the same time which throw you off course.

I've included the patch in gentoo-sources-2.6.22-r2. I think that's the best we
can do right now (there were lots of changes to that driver between 2.6.21 and
2.6.22 so it's not obvious how to backport this).

------- Comment #17 From Bjoern Olausson 2007-07-28 17:08:40 0000 -------
Fine. Thanks a lot.

regards
Bjoern

Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug