Bug 130649 - CD Changers need care
Summary: CD Changers need care
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
URL:
Whiteboard:
Depends On: 133801
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-08-23 13:24 UTC by Alan Cox
Modified: 2013-03-06 03:41 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-10-30 14:31:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
lshal output for this box (87.08 KB, text/plain)
2004-09-29 18:23 UTC, Alan Cox
no flags Details
Kernel patch againg "device not ready" with Yamaha SCSI devs (1.07 KB, patch)
2004-12-23 09:11 UTC, Ville Steudle
no flags Details | Diff

Description Alan Cox 2004-08-23 13:24:20 UTC
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

Comment 1 David Zeuthen 2004-08-23 22:14:41 UTC
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

Comment 2 Alan Cox 2004-08-23 22:58:17 UTC
Will dig into it once I get back from travelling (Sept 1st)


Comment 3 David Zeuthen 2004-09-12 16:49:25 UTC
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

Comment 4 Alan Cox 2004-09-12 18:05:37 UTC
Was waiting for FC3 test2


Comment 5 Alan Cox 2004-09-27 17:59:32 UTC
FC3test2 does not boot on the system in question. Still on the todo pile.


Comment 6 Alan Cox 2004-09-28 21:50:22 UTC
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




Comment 7 David Zeuthen 2004-09-29 07:08:23 UTC
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?


Comment 8 Alan Cox 2004-09-29 11:57:15 UTC
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.



Comment 9 Alan Cox 2004-09-29 11:58:14 UTC
As a PS: btw - magicdev doesn't produce that message for me!


Comment 10 Alexander Larsson 2004-09-29 12:02:35 UTC
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);


Comment 11 David Zeuthen 2004-09-29 17:25:41 UTC
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

Comment 12 Alan Cox 2004-09-29 17:32:54 UTC
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.


Comment 13 Alan Cox 2004-09-29 18:20:28 UTC
Ok there is also no newer firmware for either changer.

lshal attached


Comment 14 Alan Cox 2004-09-29 18:23:16 UTC
Created attachment 104533 [details]
lshal output for this box

The problem devices are the SCSI multichangers, the IDE DVD is happy.

Comment 15 Ville Steudle 2004-12-23 09:08:21 UTC
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.

Comment 16 Ville Steudle 2004-12-23 09:11:29 UTC
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.

Comment 17 Alan Cox 2006-06-06 17:57:48 UTC
Can't test further - my Nakamichi went "poof"


Comment 18 Matthew Miller 2006-07-10 23:29:25 UTC
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!


Comment 19 John Thacker 2006-10-30 14:31:30 UTC
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.


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