Bug 521004 - udev hangs on boot, ULi 1575 SB
udev hangs on boot, ULi 1575 SB
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-03 01:49 EDT by ed leaver
Modified: 2010-12-05 01:29 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:29:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
F12::/var/log/boot.log (2.82 KB, text/plain)
2009-09-03 01:49 EDT, ed leaver
no flags Details
boot log (some how take) (3.14 KB, text/plain)
2010-01-20 01:59 EST, Runwalsoft
no flags Details
boot log after next restart and further all restart it gives same log (2.88 KB, application/octet-stream)
2010-01-20 07:02 EST, Runwalsoft
no flags Details

  None (edit)
Description ed leaver 2009-09-03 01:49:28 EDT
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.)
Comment 1 Harald Hoyer 2009-09-03 07:17:33 EDT
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.
Comment 2 ed leaver 2009-09-03 12:10:09 EDT
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
Comment 3 Harald Hoyer 2009-09-03 12:15:41 EDT
reassigning to component kernel
Comment 4 ed leaver 2009-09-07 17:44:03 EDT
Just as an update, the problem persists and is reproducible with 2.6.31-0.204.rc9.fc12.x86_64. Thanks.
Comment 5 ed leaver 2009-09-12 08:49:14 EDT
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.
Comment 6 ed leaver 2009-10-17 12:40:03 EDT
Update: problem persists with 2.6.31.1-56.fc12_x86_64, and is easily reproducible.
Comment 7 Bug Zapper 2009-11-16 06:56:32 EST
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
Comment 8 ed leaver 2009-11-20 17:39:27 EST
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.)
Comment 9 ed leaver 2009-11-20 19:21:01 EST
FWIW, this board is the rare case of someone implementing both SPDIF out AND in on on-board sound. (:cool:)
Comment 10 ed leaver 2009-11-23 04:10:38 EST
FWIW, this board is the rare case of someone implementing both SPDIF out AND in on on-board sound. (:cool:)
Comment 11 Runwalsoft 2010-01-20 01:57:40 EST
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.
Comment 12 Runwalsoft 2010-01-20 01:59:18 EST
Created attachment 385598 [details]
boot log (some how take)

when first start from terminal I have taken backup
Comment 13 Harald Hoyer 2010-01-20 06:01:56 EST
(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
Comment 14 Runwalsoft 2010-01-20 06:55:49 EST
should I know which hardware is giving problem. because this is second time I have replaced brand new harddisk.
Comment 15 Runwalsoft 2010-01-20 07:01:15 EST
(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.
Comment 16 Runwalsoft 2010-01-20 07:02:56 EST
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.
Comment 17 Runwalsoft 2010-01-20 07:56:54 EST
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 :)
Comment 18 Harald Hoyer 2010-01-20 10:47:38 EST
I would guess, it's the memory.
Comment 19 Runwalsoft 2010-01-21 07:21:02 EST
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.
Comment 20 Runwalsoft 2010-01-24 00:32:01 EST
Hello Harald, Problems are still their. looks like problem belongs to some thing on different.(might be you are true about hardware fault)
Comment 21 Bug Zapper 2010-11-04 06:14:06 EDT
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
Comment 22 Bug Zapper 2010-12-05 01:29:57 EST
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.

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