Red Hat Bugzilla – Bug 521004
udev hangs on boot, ULi 1575 SB
Last modified: 2010-12-05 01:29:57 EST
Created attachment 359620 [details] F12::/var/log/boot.log Description of problem: boot flags: apic=yes acpi=off radeon.modeset=0 Boot sequence hangs hard during udev over 90% of time. Install DVD in rescue mode boots fine. Version-Release number of selected component (if applicable): kernel 2.6.31-0.190.rc8.fc12.x86_64 with whatever udev was current as of 9/2/09 How reproducible: very Steps to Reproduce: 1. Hit hw rest 2. select F12 from grub/menu.lst 3. await the inevitable Actual results: boot sequence hangs after "Starting udev..." Expected results: Instant gratification: I want Constantine to boot! Additional info: Date Sept 2, 2009 System: Opteron 170 s939, Abit AT8 RD480 with ULi 1575 SB, 4GB ECC, PowerColor Radeon x700 video. Release: Fedora 12 (Rawhide), but Leonides has same problem kernel /vmlinuz-2.6.31-0.190.rc8.fc12.x86_64 ro root=UUID=83005cc6-4128-4066-8a5c-59dc06c445f6 acpi=off apic=yes radeon.modeset=0 initrd /initrd-generic-2.6.31-0.190.rc8.fc12.x86_64.img (or custom site-specific, makes no difference) Package or subsystem: udev (or maybe readahead. or maybe acpi, or...) Problem: Occasionally Fedora [11|12] will boot fine, udev taking less than two seconds. Most of the time (>90%) the boot process hangs in udev (apparently, that's what it says on the boot screen), with the hdd activity light lit. Must hit hardware reset to reboot. The install DVDs always work in rescue mode, which allows me to get in and run yum. And gcc should it come to that... Boot flags are apic=yes nomodeset (0r radeon.modeset=0). No swap files are set in fstab, / and /boot are set by UUID. Get same behavior using F12's "generic" initrd and a custom one generated by mkinitrd. Readahead is disabled in /etc/sysconfig/readahead: # enable readahead at system startup READAHEAD="no" (allegedly -- it still shows up in boot.log) There is no floppy drive. The floppy controller is disabled in bios, as are 1394 and SATA (for Fedora testing). The Fedoras are installed on /dev/hda. CentOS 5.3 works fine. It is installed on a SATA md raid 1. Observations: 1. when /etc/udev/udev.conf is set to "udev_log=debug", the hang occurs during the myriad udev printfs, apparently randomly. Sometimes a printf won't even complete, almost like a race condition amongst udev threads, or a missing mutex lock, except the udev instances seem to be subprocesses. 2. There is some indication the problem occurs a bit less frequently when acpi=off then when it is left enabled. FWIW CentOS reports ACPI: Invalid PBLK length [7] 3. When ACPI is enabled, sometimes hitting the hardware reset button after the udev hang will completely power off the system, rather than the normal reset. I haven't enough tests with ACPI=off to see if this ever happens then. There is some indication that a successful boot occurs more frequently after a complete power cycle as opposed to just a reset, but nothing firm. Successful boots are pretty rare, save from the install dvd in rescue mode (which *always* works when radeon.modeset=0). 4. There were not built as many ULi boards as there might have been; you might not have access to one. I'm willing to do a certain amount of recompilation and debugging here, should it come to that. Thanks, Ed Leaver attachment: boot.log.f12 (I've also saved var/log/messages, var/log.dmesg, and their counterparts from CentOS, but Bugzilla apparently only allows one attachment at a time. Let me know if you want them.)
Please boot with "modprobedebug" added and "rhgb" removed on the kernel command line.. I think this is a kernel module problem. I hope we can pinpoint it to one module.
Right. modprobedebug pinpointed it to a group of sound modules, the last being snd-hda-intel, but didn't write a boot.log :( I next blacklisted snd-hda-intel and F12 boots reliably whew. But, no sound. running "modeprobe -a -v snd-hda-intel" then locks up the system with hdd activity light lit as before. Usually. On the one occuasion when modprobe completed I captured the following stdout: insmod /lib/modules/2.6.31-0.190.rc8.fc12.x86_64/kernel/sound/core/snd-page-alloc.ko insmod /lib/modules/2.6.31-0.190.rc8.fc12.x86_64/kernel/sound/soundcore.ko insmod /lib/modules/2.6.31-0.190.rc8.fc12.x86_64/kernel/sound/core/snd.ko insmod /lib/modules/2.6.31-0.190.rc8.fc12.x86_64/kernel/sound/core/snd-timer.ko insmod /lib/modules/2.6.31-0.190.rc8.fc12.x86_64/kernel/sound/core/snd-pcm.ko insmod /lib/modules/2.6.31-0.190.rc8.fc12.x86_64/kernel/sound/core/snd-hwdep.ko insmod /lib/modules/2.6.31-0.190.rc8.fc12.x86_64/kernel/sound/pci/hda/snd-hda-codec.ko insmod /lib/modules/2.6.31-0.190.rc8.fc12.x86_64/kernel/sound/pci/hda/snd-hda-intel.ko Sound works fine under CentOS. Its an on-board Realtek 883, CentOS uses its snd-hda-intel driver as well. Rawhide's /var/log/messages reports the following from a successful boot yesterday when snd-hda-intel was enabled.: Sep 2 16:02:40 raven kernel: HDA Intel 0000:00:1d.0: PCI->APIC IRQ transform: INT C -> IRQ 21 Sep 2 16:02:40 raven kernel: ALSA sound/pci/hda/hda_intel.c:691: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000 Sep 2 16:02:40 raven kernel: ALSA sound/pci/hda/hda_intel.c:1375: Codec #0 probe error; disabling it... Sep 2 16:02:40 raven kernel: ALSA sound/pci/hda/hda_intel.c:715: hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f0000 Sep 2 16:02:40 raven kernel: ALSA sound/pci/hda/hda_intel.c:639: spurious response 0x0:0x0, last cmd=0x0f0000 Sep 2 16:02:40 raven kernel: ALSA sound/pci/hda/hda_intel.c:639: spurious response 0x0:0x0, last cmd=0x0f0000 Sep 2 16:02:40 raven kernel: ALSA sound/pci/hda/hda_intel.c:639: spurious response 0x0:0x0, last cmd=0x0f0001 Sep 2 16:02:40 raven kernel: ALSA sound/pci/hda/hda_intel.c:639: spurious response 0x0:0x0, last cmd=0x0f0002 Sep 2 16:02:40 raven kernel: ALSA sound/pci/hda/hda_intel.c:639: spurious response 0x0:0x0, last cmd=0x0f0004 Sep 2 16:02:40 raven kernel: ALSA sound/pci/hda/hda_intel.c:1401: no codecs initialized Sep 2 16:02:40 raven kernel: device-mapper: multipath: version 1.1.0 loaded What else can I do to help track this down? Thanks, Ed Leaver
reassigning to component kernel
Just as an update, the problem persists and is reproducible with 2.6.31-0.204.rc9.fc12.x86_64. Thanks.
Update: problem persists with 2.6.31-2.fc12_x86_64. On two occasions I was able to successfully modprobe snd_hda_intel after boot, login, and startx, and sound worked. Other times still get the system lock-up, as when trying to boot with snd-hda-intel not blacklisted.
Update: problem persists with 2.6.31.1-56.fc12_x86_64, and is easily reproducible.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Bug persists with 2.6.32-0.48.rc7.git1.fc13.x86_64. (Sorry, not trying to bump this to Rawhide, but I forgot to change my yum.repos.d when F12 went GA. I'll try to find time to upgrade an F11 partition to F12 this weekend, or thanksgiving. Then I can test against both F12 and Rawhide.)
FWIW, this board is the rare case of someone implementing both SPDIF out AND in on on-board sound. (:cool:)
I am not sure..but I am also facing relatively same problem. Things written are highly more technical here but I have attached my boot.log file but I am also facing same problem. Let me describe whether its same or different you guys better know. problem : machine is in rest mode when I started machine it gives the error some time glibc or kernel error (randomly) then again I have hit poweroff instantly start machine then on that time machine work. properly smoothly. I am sure thats not hardware problem. but its belongs to udev(and/or)glibc problem.
Created attachment 385598 [details] boot log (some how take) when first start from terminal I have taken backup
(In reply to comment #12) > Created an attachment (id=385598) [details] > boot log (some how take) > > when first start from terminal I have taken backup /etc/rc.d/rc.sysinit: line 839: 771 Segmentation fault restorecon /var/run/utmp* /var/log/wtmp* > /dev/null 2>&1 hmm, your machine has a bigger problem, sounds like a hardware problem
should I know which hardware is giving problem. because this is second time I have replaced brand new harddisk.
(In reply to comment #13) > (In reply to comment #12) > > Created an attachment (id=385598) [details] [details] > > boot log (some how take) > > > > when first start from terminal I have taken backup > > /etc/rc.d/rc.sysinit: line 839: 771 Segmentation fault restorecon > /var/run/utmp* /var/log/wtmp* > /dev/null 2>&1 > > hmm, your machine has a bigger problem, sounds like a hardware problem If this is really hardware problem then after second restart boot log is like don't have any error. everything is smooth. then from second to multiple restart I don't get any segment fault or any error message. see new attached boot log which is 2/3 attempt of log.
Created attachment 385660 [details] boot log after next restart and further all restart it gives same log This is log after next booting of machine.
Hello Harald Hoyer, just little more focus on issue. Actually I am programmer(freelancer) so my machine is on for almost 8-10 hours. suppose their will be the problem on hardware then it might have crashed when I m using it. their might be 2 possibilities. 1) either some of the hardware which is not currently use. is crashing. a)For me following are the things which I regularly use it. wired eithernet lan , usb, working keyboard, usb mouse, and all usb ports as working. When I purchased the laptop on that time it had dvd but later I have removed 1 year back. (not sure is that makeing issue) b)Things which I don't use it : port of external monitor , wireless (wifi), 2 more ports for tv serial. 2) or it might be the problem in software itself. Some time I get this error ---------------- Starting udev: udevd[368]: worker [470] unexpectedly returned with status 0x000b udevd[368]: worker [470] failed while handling '/devices/virtual/tty/tty20' udevd[368]: worker [499] unexpectedly returned with status 0x000b udevd[368]: worker [499] failed while handling '/devices/virtual/tty/tty9' ---------------- should I know which device making this problem ? p.s. -- I wish its not hardware problem :)
I would guess, it's the memory.
Harald.. thanks for your help. it looks like recent kernel update resolve my issue. still I will give you confirmation after 2 or 3 days.
Hello Harald, Problems are still their. looks like problem belongs to some thing on different.(might be you are true about hardware fault)
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.