On Sun, Jan 14, 2007 at 03:46:14AM -0500, Nathanael Nerode wrote: > Only now *kdebase* depends on hal. Suxxor!
> I can reproduce the spinning problem in KDE, any time. This means that > Juergen > Lueters is on the wrong track. > I don't like automounting and I have turned it off (it always behaves > incorectly). > It's not acceptable for HAL to misbehave when automounting is turned off, > particularly > when it's *required* by KDE. > Did anyone get my HAL systrace log? It's huge. I have put it at > http://home.twcny.rr.com/nerode/hal.logfile since it seems difficult to > transfer it any other way. This strace seems to include a lot of syslog messages from hald-probe-storage that weren't captured in the actual syslog output provided earlier, and in the strace they're truncated. Is it possible to get the full text of these somehow? Looking at the strace log, I see there are also other ioctls against the device from hald-probe-storage and hald-probe-volume -- BLKGETSIZE64, BLKSSZGET, CDROMREADTOCHDR, CDROMREADTOCENTRY, and CDROMMULTISESSION. But it's hald-addon-storage which continues to poll the device, so if the drive spins down shortly after killing hald-addon-storage, that seems certain to be the culprit. > This bug IS RC and it is grave. You can't downgrade it, sorry. I have a hard time keeping this bug as RC. The provided justification for the grave bug is that it destroys hardware; but while it causes unnecessary wear and tear on some hardware, it doesn't "destroy" hardware per se in the way that cooking a processor or misflashing a card would. And if it's the polling of hald-addon-storage itself that triggers the problem, this ultimately seems to be either a kernel or a hardware bug, not a hal bug, since those ioctls really shouldn't require spinning up the drive. Publishing information about pluggable devices and new media is an important feature of hal, and currently all the evidence points to hal behaving as it's designed to do, with the hardware behaving suboptimally. > The best alternative if you can't fix the actual bug would be to provide an > *easy* > mechanism to *permanently* disable hald-addon-storage. If there was such a > mechanism > documented, then you could downgrade the bug. 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. -- 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]
