-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sjoerd Simons wrote:
> On Tue, Jun 20, 2006 at 01:45:36PM -0400, Nathanael Nerode wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Steve Langasek wrote:
>>> On Tue, Jun 13, 2006 at 11:23:02PM +0200, Sjoerd Simons wrote:
>>>> On Mon, Jun 05, 2006 at 12:29:55PM -0400, Daniel Schepler wrote:
>>>>> I can confirm that this happens on my laptop as well; when a CD is in the
>>>>> drive, I can hear the drive spinning all the time, although at a lower
>>>>> speed than when the disc is being read. After I stop hald manually, the
>>>>> drive spins down after about a minute.
>>>> What hal does is poll the cddrive for status every two seconds..
>> Bloody hell. :-) Don't do that please!
>
> Sure, if you have another way to detect the insertion of a cd :)
>
>> It causes a nightmare on laptops as well.
>
> Only on certain somewhat broken dell laptops.
>
>>>> This shouldn't
>>>> spin up the drive though..
>> Well, I can't change the hardware. This drive certainly seems to spin
>> up on status checks; back when I was running Windows, it would spin up
>> three times during the boot process. Hypothesizing, this may well be in
>> the drive firmware.
>
> Well a status check isn't the same as trying to read from the drive, which
> would indeed spin up the drive.
>
>>> Could you try to kill/stop the
>>>> /usr/lib/hal/hald-addon-storage processes that hal spawns (These poll your
>>>> drive) and check if that solves it ?
>> Yes, it does. Is there a way to configure hal to not run that process,
>> ever? Or to tell it not to poll the CD drive?
>
> Setting storage_media_check_enabled to false in /etc/hal/hald.conf should
> stop
> hal from polling your drive.
This is sufficient to reduce the bug from "grave" to "important". :-)
If it's documented somewhere (I couldn't find such documentation).
> But as said it shouldn't be necessary..
>
> Could you please also try the test program i sent earlier in this bug ? I can
> really use that info :)
Done; sorry it took so long.
The test program does *not* spin up the CD drive.
This is its output:
- --cut here--
Doing CDROM_DRIVE_STATUS
Got: 4
Doing CDROM_MEDIA_CHANGEDs
- --cut here--
So I did a little extra debugging and research. "4" should be
CDS_DISC_OK. If the drive is empty, I get 1 (NO_DISC) and if it's
open I get 2 (TRAY_OPEN). So far so good!
I then checked the output value for the CDROM_MEDIA_CHANGED ioctl.
If the tray is open or there's no disc, I get 1 both times.
If I've just put a disc in, I get 1 and then 0.
If I then rerun the test program again, I get 0 both times. So
CDROM_MEDIA_CHANGED is doing its job correctly....
I then tried making a test program containing the hideous code
under "/* check if eject button was pressed */". This still doesn't
spin up the CD-ROM drive.
I tried the code on the other, non-CD path, in case hal wasn't
recognizing the drive as a CD drive. This *also* doesn't spin up the
CD-ROM drive. (Anyway, I checked the environment and it is recognizing
it as a CD-ROM drive.)
However, the moment I install hal, the CD drive spins up to top speed,
and keeps spinning.
Weirder: if I kill hald-addon-storage, it stops spinning after about 2
seconds. If I then start hald-addon-storage *manually* from the command
line with the same environment as the previous hald-addon-storage
(environment found with 'ps fwwe <pid>'), the CD-ROM drive does *not*
start spinning.
If, while this new invocation of hald-addon-storage is running, I eject
the tray and close it again, then the CD-ROM drive *does* start
spinning. If I then kill this new hald-addon-storage, the CD-ROM drive
stops spinning again after about 2 seconds.
This led me to look at the following piece of code.
case MEDIA_STATUS_NO_MEDIA:
if (got_media) {
DBusError error;
dbg ("Media insertion detected on %s", device_file);
/* our probe will trigger the appropriate hotplug events */
/* could have a fs on the main block device; do a rescan to add
it */
dbus_error_init (&error);
libhal_device_rescan (ctx, udi, &error);
}
break;
h
Now, libhal_device_rescan appears to basically send a message onto DBUS.
However, killing both running copies of dbus doesn't help; exactly the
same behavior still happens.
What's confusing to me is that /dev/hdc is not opened by anything
according to lsof.
Anyway, I looked for where the dbus message sent by libhal_device_rescan
is picked up, in hald_dbus.c. (It could be picked up elsewhere, outside
HAL, and that could cause the problem, but how could I tell?)
It triggers device_rescan, which eventially
triggers osspec_device_rescan, which is a wrapper around
hotplug_rescan_device, which triggers blockdev_rescan_device (based on
the value of HAL_PROP_LINUX_HOTPLUG_TYPE=3 in the environment). So the
trouble could be in any of those, but they're basically wrappers, so it
seems unlikely. So I looked further on; blockdev_rescan_device runs
this code (since HAL_PROP_BLOCK_IS_VOLUME=false):
/* now see if we got a file system on the main block device */
hald_runner_run (d,
"hald-probe-storage --only-check-for-media", NULL,
HAL_HELPER_TIMEOUT,
block_rescan_storage_done,
NULL, NULL);
This appears to cause yet ANOTHER dbus message. I have nothing positive
to say about HAL architecture so far....
Anyway, without looking too hard at hald-runner -- which might also be
the source of the bug, of course -- I'm guessing that its main response
to this message is to invoke hald-probe-storage --only-check-for-media.
I'm not sure how to reproduce the invocation manually, however, or how
to debug the automatic invocation.
Looking in hald/linux2/probing/probe-storage.c, I find a duplicate of
the CD-ROM media change detection code ioctls (surprise, surprise),
followed by a readonly open of the device file (I already know that's
not the culprit from earlier testing), followed by this code:
/* probe for file system */
vid = volume_id_open_fd (fd);
if (vid != NULL) {
if (volume_id_probe_all (vid, 0, 0 /* size */) == 0) {
/* signal to hald that we've found a file system and a fakevolume
* should be added - see
hald/linux2/blockdev.c:add_blockdev_probing_helper_done(
)
* and hald/linux2/blockdev.c:block_rescan_storage_done().
*/
if (vid->usage_id == VOLUME_ID_FILESYSTEM)
ret = 2;
} else {
;
}
volume_id_close(vid);
}
close (fd);
It seems quite likely something triggered by this code is the source of
the endless spinup. Unfortunately, this could be *anything* in the
volume_id_probe_* family of functions.
Or the bug could be in the later code, after a filesystem is found and
"2" is returned to hald to signal that a filesystem has been found. I
don't know where I'd look if that's the problem.
I don't know how to distinguish between these two likely possibilities.
So that's as far as I've gotten with this bug. Perhaps you, knowing
more about HAL, can work out how to track it down further.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEpxazRGZ0aC4lkIIRAmJlAJ48/8UJGxSFwRbmAAfjBqiVdMYh1ACeNk2G
dmlPAmHh65k5mEd0Kd/RK5A=
=mSyT
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
