Bug#370186: FINALLY got the workaround to work, after about 2 hours.

2007-01-21 Thread Steve Langasek
On Sun, Jan 21, 2007 at 12:50:01AM -0500, Nathanael Nerode wrote:
 That would be quite good enough for me.

 After an exceptional amount of fiddling (hal seems to be very picky about its
 configuration files, and it doesn't report when it can't read them -- that 
 should
 be logged, and it's not, and I filed a bug) I seem to have gotten it working. 

 device
   match key=info.product string=HL-DT-STDVD-ROM GDR8162B
 merge key=info.addons type=strlist/merge
   /match
 /device

 Now it spins up the drive when hal starts, for about 3 seconds, but then 
 stops and behaves itself.

 This workaround seriously needs to be documented.  I'm fairly adept, so I
 also managed to figure out where the script to restart hal is (NOT obvious),
 and that I had to match the string to a string in lshal (slightly more 
 obvious), 
 but I doubt an average user, even a technically adept one, would ever make it
 through this without help.

A more novice-friendly workaround might be possible, matching on a
non-vendor-specific attribute; e.g.,

  match key=storage.cdrom.cdr bool=true

But that obviously wouldn't be a correct default for all users or all
devices -- if this is a problem specific to particular CD ROM models, maybe
hal can ship some settings to disable this on a per-model basis instead, but
if we need to give users a workaround to deploy themselves, the above is
probably a better bet.

 I think this is the workaround for a lot of similar bugs (#360554, perhaps?) 
 and 
 we already have two users reporting the problem (me and Steve)

I never had the spin-up problem; my bug was, as Sjoerd correctly noted,
a separate kernel bug, that seems to have gone away in more recent kernels.

 so this should be documented in README.Debian or somewhere else in 
 /usr/share/doc/hal.  If this is documented prominently, I think the bug
 can be closed, because the real bug is indeed in the hardware or the
 kernel and may be very difficult or impossible to work around.

Fair by me.  Sjoerd, what do you think?

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#370186: FINALLY got the workaround to work, after about 2 hours.

2007-01-20 Thread Nathanael Nerode
Steve Langasek wrote:
I can't find a way to disable it using just the media_check_enabled flag,
but adding the following to /etc/hal/fdi/policy/preferences.fdi overrides
the use of hald-addon-storage for my particular CD-ROM:

  device
match key=info.product string=SD-R2512
  merge key=info.addons type=strlist/merge
/match
  /device

That means hal will never be notified of media changes on that device at
all.

That would be quite good enough for me.

After an exceptional amount of fiddling (hal seems to be very picky about its
configuration files, and it doesn't report when it can't read them -- that 
should
be logged, and it's not, and I filed a bug) I seem to have gotten it working. 

device
  match key=info.product string=HL-DT-STDVD-ROM GDR8162B
merge key=info.addons type=strlist/merge
  /match
/device

Now it spins up the drive when hal starts, for about 3 seconds, but then 
stops and behaves itself.

This workaround seriously needs to be documented.  I'm fairly adept, so I
also managed to figure out where the script to restart hal is (NOT obvious),
and that I had to match the string to a string in lshal (slightly more 
obvious), 
but I doubt an average user, even a technically adept one, would ever make it
through this without help.

And it is a *very* annoying problem.  My CD-ROM drive doesn't just spin up, it
spins up to top speed and stays there, which it doesn't even do when playing an 
audio CD or DVD.  Doing this constantly is actually a *lot* more wear and tear 
than the drive is designed to receive; it's quite loud enough to be audibly 
obnoxious, as well.

I think this is the workaround for a lot of similar bugs (#360554, perhaps?) 
and 
we already have two users reporting the problem (me and Steve) so 
this should be documented in README.Debian or somewhere else in 
/usr/share/doc/hal.  If this is documented prominently, I think the bug can be 
closed, because the real bug is indeed in the hardware or the kernel 
and may be very difficult or impossible to work around.  (FYI, hal is one of 
the 
least documented programs I've ever seen.)

Suggested text, which I place in the public domain:

--

Is hal keeping your CD-ROM or disk drive spinning constantly?  This is a
known problem related to the behavior of particular hardware.  You can
stop this behavior by disabling hald-addon-storage for that specific drive 
(this will also disable automounting and the other features of hal for that 
drive, of course).

To do so, run 'lshal | more' and find the entry describing the troublesome
drive -- you may have to guess which one it is, but it will probably have
DVD or CD or something recognizable in it.  Mine was identifiable by
the line:
  info.product = 'HL-DT-STDVD-ROM GDR8162B'

As root, create a file /etc/hal/fdi/policy/dont-wake-drive.fdi containing the 
following text (replacing the string HL-DT-STDVD-ROM GDR8162B with the one 
for 
your drive):

?xml version=1.0 encoding=UTF-8?

deviceinfo version=0.2
  device
match key=info.product string=HL-DT-STDVD-ROM GDR8162B
  merge key=info.addons type=strlist/merge
/match
  /device
/deviceinfo

Then, as root, restart hal as follows:
/etc/dbus-1/event.d/20hal force-reload

Your drive should spin down in a few seconds.

-

-- 
Nathanael Nerode  [EMAIL PROTECTED]

[Insert famous quote here]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]