Red Hat Bugzilla – Bug 58021
Problem with rc.sysinit starting usb before sound card
Last modified: 2014-03-16 22:24:57 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.0.2 (X11; Linux i686; U;) Gecko/20011226
Description of problem:
I have a PCI sound card (that doesn't need DMA buffers pre-allocated) and a
USB camera that has a microphone built in to it.
After booting, my sound card is mapped to /dev/dsp1, and the USB microphone
is mapped to /dev/dsp. Not having an output device on /dev/dsp wreaks
plenty of havoc with most programs that are (unfortunately) expecting
/dev/dsp to be the device that plays sounds. Removing the USB device and
rebooting corrects the issue.
P.S. This USB camera's video isn't supported by the current Red-Hat kernel
release, although it works OK for me under a 2.4.17 kernel (Logitech
QuickCam 3000 Pro). However, this sort of problem would occur on any of the
supported USB devices that have a microphone (and use the audio class). It
should actually occur on a supported RedHat kernel as well, since the audio
class is supported separately from the video function.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install a sound card in a PC, and attach a USB device that implemements
the audio class.
2. Boot the PC.
Actual Results: Notice that the USB audio device gets mapped to /dev/dsp,
and that the regular sound card gets mapped to /dev/dsp1.
On top of that, the information in /etc/modules.conf is now wrong, because
it isn't updated to accound for the new sound slot for the sound card.
Expected Results: The device that supports audio playback should be mapped
to /dev/dsp. Other devices should be added thereafter. At least, that's my
I'm sure there's no perfect way to solve this, although your average
Windows box seems to do the intuitive thing most of the time.
I'm sure this is a can of worms, and that it's really a small case of a
bigger problem. I got the desired effect by patching /etc/rc.sysinit to
always check for and load a sound card before starting the usb bus. There
are probably problems with that approach as well.
Created attachment 93173 [details]
hwconf on my system, made at about first or second boot time
I'm still seeing this on Severn. I'm going to start looking at this, but I'm
awfully new to Linux devices, so any hints would be appreciated.
Anyway, here's the /etc/sysconfig/hwconf file on my system. It was made right
after firstboot last touched /etc/sysconfig/firstboot.
-rw-r--r-- 1 root root 17 Jul 26 14:23
-rw-r--r-- 1 root root 6776 Jul 26 14:22 /etc/sysconfig/hwconf
-rw-r--r-- 1 root root 1412 Jul 26 13:48 /root/anaconda-ks.cfg
Strangely, firstboot didn't actually finish properly on my first boot (Bug
#100906), so I get the feeling that these modtimes are from the second boot.
This is probably tangential, but I'll record it in case it isn't.
At this point, my USB camera isn't plugged in, so hwconf doesn't see it. It
does see plenty of other USB devices, though, including the USB devices on the
hub. When I plug the USB camera in a little later (on the third boot of the
PC), its information doesn't get added to /etc/sysconfig/hwconf. Running kudzu
from the command line detects the device.
I'm thinking that if kudzu can detect the camera and add its information to
/etc/sysconfig/hwconf, there's a chance that something can be done about the
camera's microphone claiming /dev/dsp. Is that a proper function for kudzu, or
should that be handled elsewhere?
Created attachment 93174 [details]
Results of running kudzu after boot, manually
So, while the system was powered off, I attached the camera and powered up, and
found, as noted above, that /etc/sysconfig/hwconf hadn't been modified.
Once I could log in, I ran 'kudzu -s -p > hwconf-postboot'. Results are
attached. The only real difference from the first file is that the videocamera
was added. I'm not sure why kudzu didn't handle this during the boot process,
since it should be running:
chkconfig --list kudzu
kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off
I'll try a few more reboots to make sure I'm not smoking something.
Another reboot had no effect. However, after rebooting and logging in, running
'kudzu -q' manually results in an update to /etc/sysconfig/hwconf, containing
the proper lines for the camera (file is identical to attachment 93174 [details] in this
case), and proper updates for sound-slot-1 to /etc/modules.conf.
Maybe kudzu wasn't completing during the boot process? I don't see anything in
/var/log/mesassages or /var/log/boot.log to indicate that /usr/sbin/kudzu
returned for reason of a timeout. In fact, looking at the log files, I don't see
any mention of kudzu in "boot.log" until after I had manually ran kudzu by hand
(outside the confines of the initscript):
/var/log/messages:Jul 26 21:38:06 creaky kudzu: aliased sound-slot-1 as pwc
After another reboot, I see the first signs of kudzu completing in boot.log and
the messages log - prior to that point there are no entries at all for kudzu in
either of those files:
/var/log/boot.log:Jul 26 21:59:15 creaky kudzu: succeeded
/var/log/messages:Jul 26 21:59:15 creaky kudzu: succeeded
/var/log/boot.log:Jul 26 21:59:16 creaky kudzu: Updating /etc/fstab succeeded
/var/log/messages:Jul 26 21:59:16 creaky kudzu: Updating /etc/fstab succeeded
This is starting to look like 2 problems - one under which kudzu and the
associated initscript don't run to completion in the boot process until after I
manually run kudzu after logging in, and another which is the longstanding
problem with the audio on the camera assigned to the wrong device. I'm learning
something, but not getting very close to the original problem quite yet.
Any ideas on what I can look for? I imagine I can reproduce this by replace by
current /etc/sysconfig/hwconf and /etc/modules.conf with older revisions if
There's a simple solution for this I have lying around somewhere needing
implementation. I just have to remember what it is. :)
Simple sounds good. I gave it some thought, but didn't arrive at anything
satisfactory. Here's what I came up with, on the chance that it jogs your memory:
The simplest thing I can think of would be to have a "hotplug fixup" phase in
the boot process that takes stock of the devices in the system, and renames the
device files based on device capabilities. So if it determines that the devices
at /dev/dsp and /dev/dsp1 really ought to be swapped, it can rename them. If
this is all done before the system begins running in multi-user mode, and you
make sure that the initscripts aren't using any of those devices, you could
avoid race conditions.
The most correct thing I can think of is to modify the kernel code that assigns
minor numbers to sound devices to assign not on a first-come, first-serve basis.
Instead, the minor numbers for /dev/dsp0, /dev/mixer0, (any others?) could be
reserved for devices that have both input and output capabilities. Maybe that's
too much policy for the kernel, so maybe the sound system could ask a user-space
daemon or file for guidance.
I don't really like either of these. The first is too much a hack, the second is
too invasive, and to do it right probably means making some service that could
be used by devices of all types, which is even more invasive - too invasive by
far for the amount of thought I've given it...
This is solved in FC3; built-in cards are enumerated before USB.