Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 58021
Summary: | Problem with rc.sysinit starting usb before sound card | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | George Karabin <gkarabin> | ||||||
Component: | initscripts | Assignee: | Bill Nottingham <notting> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 7.2 | CC: | rvokal | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | athlon | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2005-04-05 19:47:08 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
George Karabin
2002-01-06 05:40:42 UTC
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 /etc/sysconfig/firstboot -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
necessary.
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. |