Red Hat Bugzilla – Bug 130649
CD Changers need care
Last modified: 2013-03-05 22:41:24 EST
Description of problem: When you open CD changers in sequence to poll you keep changing the disk. This is really slow, really noisy and breaks any music playback. Changers appear as a set of sequential scsi CD devices. A good heuristic to spot them appears to be CD devices with the same vendor/model at the same bus/target and with sequential LUNs where there are 5 or more LUNs present. Most but not all of them are made by "Nakamichi" - There are a few others like the Pioneer DRM-624X series
Ok, I need some more information to diagnose this. First, get hal-0.2.97.cvs20040823-1 that I just uploaded to Rawhide. Then shutdown the haldaemon (the init script is haldaemon) and run 'HALD_VERBOSE=1 hald --daemon=no' as root and attach the output. The debug output got timestamps so that will help me see where the time goes. This is also worth trying with respectively discs in all drives and without any. FWIW, on my slowish P3 650Mhz laptop with 192MB RAM it takes about 2-3 seconds to start the hal daemon with no discs. When the haldaemon is fully running, run lshal and also attach this output. Question: are the drives noisy when the hal daemon is running or is it only during the startup of the hal daemon? FWIW, I've not seen any bug reports about hald making drives unusable. Many thanks, David
Will dig into it once I get back from travelling (Sept 1st)
Alan, did you try this out yet? You might want to try with the latest and greatest version of hal which is hal-0.2.97.cvs20040901. For submitting traces etc. please see http://freedesktop.org/Software/HalTraces Thanks! David
Was waiting for FC3 test2
FC3test2 does not boot on the system in question. Still on the todo pile.
Ok that fixed With no media in the drives I get the kenrel logging Device not ready. Make sure there is a disc in the drive. four times a second. This destroys my logs and is way faster than I'd expect. This continual hammering also eventually crashes the drive firmware. If I insert disks the behaviour has changed, now fstab-sync keeps segfaulting with NULL pointer dereferences
As mentioned in comment 1 I do need more information. Please read http://freedesktop.org/Software/HalTraces and supply that information. It would also be useful if you stated the package versions in question. > With no media in the drives I get the kenrel logging > Device not ready. Make sure there is a disc in the drive. > four times a second. That probably means that you got 8 drives since hal polls each of the every two second. Correct? > This destroys my logs Supposedly the kernel driver for your device shouldn't spew this information as it effectively means we cannot poll the drives. > and is way faster than I'd > expect. This continual hammering also eventually > crashes the drive firmware. Does polling your drive every two seconds make the drive firmware crash? > If I insert disks the behaviour has changed, now fstab-sync > keeps segfaulting with NULL pointer dereferences You probably need to upgrade libselinux; the explanation of this bug is in comment 10 of bug 133775. This is a packaging/build system bug and will be fixed on the next upload of a hal package. Reiterating some old questions and adding some new: 1. Does this work with magicdev? Does this also spew entries into you log file? 2. are the drives noisy when the hal daemon is running or is it only during the startup of the hal daemon? Please describe the exact behaviour Do you have any constructive ideas on how to fix this?
Ok firstly I agree the kernel driver shouldn't be printing the messages. Thats code going back before Linux GUI's even as fas as I can tell. I'll submit a patch see what people say. Polling the multichangers ever 2 seconds kills the Pioneer drive and makes the Nakamichi behave a little oddly. The pioneer at least takes longer than that to flip slot and check disk in some cases so when you change cartridge. Is polling no more than one LUN of a device per 5 seconds feasible, what is the upper limit for responsiveness that UI would like ? Magicdev works, but that is because it only polls one lun so the changer gets no change requests and has one poll per 5 seconds not 7 per 2 seconds. If I fill it with disks it seems reasonably happy with FC3t2 HAL. It takes a long time to start up (about 5-10 seconds a disk), and sticks some icons over the top of existing ones [unrelated issue Im sure!], but the feeling as a user is of progress because its <kerchunk><pause><whirrr><icon> each time and so you see the progress. Pieces are all FC3t2 CD-ROM. I'll update the box, see what it does after update and get traces if it still faults.
As a PS: btw - magicdev doesn't produce that message for me!
I got a similar report on the kernel warning agains gnome-vfs, and the solution was to check the drive status before the disc status. The code goes like: *fd = open (vol_dev_path, O_RDONLY|O_NONBLOCK); if (*fd < 0) { return -1; } if (ioctl (*fd, CDROM_DRIVE_STATUS, CDSL_CURRENT) != CDS_DISC_OK) { close (*fd); *fd = -1; return -1; } return ioctl (*fd, CDROM_DISC_STATUS, CDSL_CURRENT);
I've added the check Alex mentioned in comment 10, so the next hal package should fix this (Thanks Alex!) > Polling the multichangers ever 2 seconds kills the Pioneer drive > and makes the Nakamichi behave a little oddly. The pioneer at > least takes longer than that to flip slot and check disk in > some cases so when you change cartridge. Is polling no more > than one LUN of a device per 5 seconds feasible, I just tried only to poll a single LUN of my 6in1 card reader, that didn't work so we will have to special case for optical drives... Does polling on a single LUN, e.g. /dev/sdb really report a change if you insert a disc into the drive represented by /dev/sda? > what is the > upper limit for responsiveness that UI would like ? Studies I've read for Interactive Television (think BSkyB set top boxes) in my past job suggest that two seconds is the upper bound before feedback must be given. I think that applies here as well, e.g. the drive spins up within two seconds. However, we don't want to crash your drive either so perhaps we should just merge a property saying don't poll more than every N seconds - does this sound like an acceptable solution? I think it is, because a) we can match on the firmware revision; e.g. lshal output from your box should export the property 'storage.firmware_version'; and b) this is *fact* about the drive with the current firmware. > Magicdev works, but that is because it only polls one lun so the > changer gets no change requests and has one poll per 5 seconds > not 7 per 2 seconds. OK, we need to tag one of the drives at least with some property storage.poll_only_one_lun in the same fashion. Does this sound OK? > If I fill it with disks it seems reasonably happy with FC3t2 HAL. > It takes a long time to start up (about 5-10 seconds a disk), > and sticks some icons over the top of existing ones [unrelated > issue Im sure!], > but the feeling as a user is of progress because > its <kerchunk><pause><whirrr><icon> each time and so you see > the progress. Nice, at some future point I'll hope to have worker threads so this happens in parallel but for now all device detection in hal is delibirately done in a single threaded fashion. Please attach the output of lshal for your drives and I'll prepare some hal device information files that merges said properties and put some logic into hal to use this. It won't make t3 but should be out before FC3 final. Thanks, David
What I was trying to suggest was that for a multi-lun device you slow down the polling to avoid overloading the multichangers. Ie poll lun 0, wait 2 seconds, poll lun 1 , .. etc. It takes them a while to spin a disk up anyway as with any CD drive, but in this case with the added cost of loading the right disk. Your comment about USB stuff means it shouldn't be done generically however. If you parallel poll the device it should [hah] behave sanely. The multichangers cache the TOC and so don't need to reshuffle disks except when you ask for data from them. I'll try and get that box back running and lshal it tonight.
Ok there is also no newer firmware for either changer. lshal attached
Created attachment 104533 [details] lshal output for this box The problem devices are the SCSI multichangers, the IDE DVD is happy.
A side comment (might be a related issue): When analyzing why my Yamaha 4260 (older SCSI writer) causes "Device not ready" kernel messages in the log with FC3 while my SCSI DVD does not, I noticed this detail: The SCSI command that triggers the NOT_READY answer for the Yamaha seems to be ALLOW_MEDIUM_REMOVAL, not TEST_UNIT_READY. After applying the patch below, the kernel got quiet. Note that this cures only a symptom, I did not analyze the root cause, i.e. look for the application issueing this command.
Created attachment 109067 [details] Kernel patch againg "device not ready" with Yamaha SCSI devs Suppresses the "Device not ready" kernel message in scsi_ioctl.c not only as response to TEST_UNIT_READY (as in the original kernel), but also for ALLOW_MEDIUM_REMOVAL.
Can't test further - my Nakamichi went "poof"
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Closing per lack of response to previous request for information. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier.