Hello, I just purchased a DVD+-RW drive that I put into a usb 2.0 enclosure. The manufacture is:
scsi0 : SCSI emulation for USB Mass Storage devices Vendor: MAD DOG Model: MD-16XDVD9 Rev: 2.F6 Type: CD-ROM ANSI SCSI revision: 02
It looks like to burn anything (dvd/cd) with this external device, I have to stop haldaemon. If I do not, then I have coasters.
My question is, is there any way to have hal ignore this device when a blank cd/dvd is inserted? I, ofcourse, would want hal to mount any valid disk that is inserted.
Thanks.
Oh yeah, I am running rawhide yumed on top of FC3.
On Sat, 27 Nov 2004 18:59:51 -0600 (CST), Brian Millett bpm@ec-group.com wrote:
Hello, I just purchased a DVD+-RW drive that I put into a usb 2.0 enclosure. The manufacture is:
scsi0 : SCSI emulation for USB Mass Storage devices Vendor: MAD DOG Model: MD-16XDVD9 Rev: 2.F6 Type: CD-ROM ANSI SCSI revision: 02
It looks like to burn anything (dvd/cd) with this external device, I have to stop haldaemon. If I do not, then I have coasters.
My question is, is there any way to have hal ignore this device when a blank cd/dvd is inserted? I, ofcourse, would want hal to mount any valid disk that is inserted.
Hal doesnt mount anything by itself.... maybe you are refering to gnome-volume-manager, which interacts with hal to mount storage devices and deal with removable media when inserted.. assuming you are running gnome. My understanding is, at least in gnome, it should be enough to disable gnome-volume-manager's handling of blank writable dvd/cd media.
Of course disabling hal completely has the side-effect of preventing gnome-volume-manager from doing anything useful, since gnome-volume-manager relies on hal running to sense hardware. But based on my admittedly limited understanding of how the software stack built up around hal works, the problem i think you are describing is with gnome-volume-manager or whatever kde's equivlant is and not with hal specifically.
-jef
On Sat, 27 Nov 2004 18:59:51 -0600 (CST), Brian Millett bpm@ec-group.com wrote:
Hello, I just purchased a DVD+-RW drive that I put into a usb 2.0 enclosure. The manufacture is:
scsi0 : SCSI emulation for USB Mass Storage devices Vendor: MAD DOG Model: MD-16XDVD9 Rev: 2.F6 Type: CD-ROM ANSI SCSI revision: 02
It looks like to burn anything (dvd/cd) with this external device, I have to stop haldaemon. If I do not, then I have coasters.
My question is, is there any way to have hal ignore this device when a blank cd/dvd is inserted? I, ofcourse, would want hal to mount any valid disk that is inserted.
Hal doesnt mount anything by itself.... maybe you are refering to gnome-volume-manager, which interacts with hal to mount storage devices and deal with removable media when inserted.. assuming you are running gnome. My understanding is, at least in gnome, it should be enough to disable gnome-volume-manager's handling of blank writable dvd/cd media.
Jeff, Thanks. Yep I am running gnome. Running gnome-volume-properties shows that blank cds are disabled. However, if I put one in (cd/dvd) they show up being handled by nautilus-cd-burn-whatever-comand. What I have here is a failure to communicate. I'm going to stroll over to bugzilla and see if it is there, if not file it.
Thanks.
On Sat, 27 Nov 2004 18:59:51 -0600 (CST), Brian Millett bpm@ec-group.com wrote:
Hello, I just purchased a DVD+-RW drive that I put into a usb 2.0 enclosure. The manufacture is:
scsi0 : SCSI emulation for USB Mass Storage devices Vendor: MAD DOG Model: MD-16XDVD9 Rev: 2.F6 Type: CD-ROM ANSI SCSI revision: 02
It looks like to burn anything (dvd/cd) with this external device, I have to stop haldaemon. If I do not, then I have coasters.
My question is, is there any way to have hal ignore this device when a blank cd/dvd is inserted? I, ofcourse, would want hal to mount any valid disk that is inserted.
Hal doesnt mount anything by itself.... maybe you are refering to gnome-volume-manager, which interacts with hal to mount storage devices and deal with removable media when inserted.. assuming you are running gnome. My understanding is, at least in gnome, it should be enough to disable gnome-volume-manager's handling of blank writable dvd/cd media.
Jeff, Thanks. Yep I am running gnome. Running gnome-volume-properties shows that blank cds are disabled. However, if I put one in (cd/dvd) they show up being handled by nautilus-cd-burn-whatever-comand. What I have here is a failure to communicate.
Well, before I filed a bug, I tried stopping g-v-m and inserted a blank cd. Nuts! It shows up. So any ideas what is really handling mounting blank media? Or is that a bug? Or am I just not testing correctly?
On my systems, it is sufficient to do
/sbin/service haldaemon stop
to make the system quit trying to "help" me with media and devices
Brian Millett wrote:
On Sat, 27 Nov 2004 18:59:51 -0600 (CST), Brian Millett bpm@ec-group.com wrote:
Well, before I filed a bug, I tried stopping g-v-m and inserted a blank cd. Nuts! It shows up. So any ideas what is really handling mounting blank media? Or is that a bug? Or am I just not testing correctly?
On Sat, Nov 27, 2004 at 11:58:50PM -0500, Jeff Spaleta wrote:
Hal doesnt mount anything by itself.... maybe you are refering to gnome-volume-manager, which interacts with hal to mount storage devices and deal with removable media when inserted.. assuming you are running gnome. My understanding is, at
Hal polls devices and that is enough to screw up USB burners sometimes, to break ide burns if there are two drives on the same bus one burning one being probed, and other stuff.
On Sun, 2004-11-28 at 10:45 -0500, Alan Cox wrote:
On Sat, Nov 27, 2004 at 11:58:50PM -0500, Jeff Spaleta wrote:
Hal doesnt mount anything by itself.... maybe you are refering to gnome-volume-manager, which interacts with hal to mount storage devices and deal with removable media when inserted.. assuming you are running gnome. My understanding is, at
Hal polls devices and that is enough to screw up USB burners sometimes, to break ide burns if there are two drives on the same bus one burning one being probed, and other stuff.
That would *really* surprise me.
Remember: when polling on optical drives, hald uses O_EXCL and that should make open(2) fail with EBUSY if someone else has opened that device O_EXCL - and all cd recording software in the Fedora distribution should do that otherwise it's a bug.
So, assuming that hald gets EBUSY on attempting to open with O_EXCL, why should that interfere with the hardware at all and thus break them?
Cheers, David
That would *really* surprise me.
Remember: when polling on optical drives, hald uses O_EXCL and that should make open(2) fail with EBUSY if someone else has opened that device O_EXCL - and all cd recording software in the Fedora distribution should do that otherwise it's a bug.
you missed the point. Hal polls the *other* IDE device on the bus. ANd that polling can take long enough so that the bus is locked too long and you get a buffer underrun.
On Sun, Nov 28, 2004 at 10:41:17PM -0500, David Zeuthen wrote:
Remember: when polling on optical drives, hald uses O_EXCL and that should make open(2) fail with EBUSY if someone else has opened that device O_EXCL - and all cd recording software in the Fedora distribution should do that otherwise it's a bug.
So, assuming that hald gets EBUSY on attempting to open with O_EXCL, why should that interfere with the hardware at all and thus break them?
For USB I don't know. That baffles me still. For IDE I can cause it when there are two devices on the bus because the HAL probe locks the bus talking to one device and that stalls the CD write on the other. IDE master/slave operations cannot occur in parallel so it just needs a slow to respond CD probe and a fairly fast CD writer to run out of buffer.
Alan
On Mon, 2004-11-29 at 04:37 -0500, Alan Cox wrote:
On Sun, Nov 28, 2004 at 10:41:17PM -0500, David Zeuthen wrote:
Remember: when polling on optical drives, hald uses O_EXCL and that should make open(2) fail with EBUSY if someone else has opened that device O_EXCL - and all cd recording software in the Fedora distribution should do that otherwise it's a bug.
So, assuming that hald gets EBUSY on attempting to open with O_EXCL, why should that interfere with the hardware at all and thus break them?
For USB I don't know. That baffles me still. For IDE I can cause it when there are two devices on the bus because the HAL probe locks the bus talking to one device and that stalls the CD write on the other. IDE master/slave operations cannot occur in parallel so it just needs a slow to respond CD probe and a fairly fast CD writer to run out of buffer.
I can only see this happening when you have two optical drives on the same IDE channel. Because the only IDE devices that hal will poll on are optical drives.
So, say that the master is a CD-ROM drive and the slave is a CD-R. Now, cdrecord writes to the slave and hal polls only the master (because hal is locked out by O_EXCL on the slave); shouldn't stalling only occur if the master employs powersaving?
I've only seen reports on the stall for laptops (actually only Dell laptops), e.g. I don't think ordinary desktop optical drives uses powersaving? FWIW, I couldn't reproduce it the stall on a desktop system anyway. And I must admit - I would be surprised to see a laptop with two optical drives on the same IDE channel.
Oh, well, just speculating.
Cheers, David
On Mon, Nov 29, 2004 at 09:39:53AM -0500, David Zeuthen wrote:
So, say that the master is a CD-ROM drive and the slave is a CD-R. Now, cdrecord writes to the slave and hal polls only the master (because hal is locked out by O_EXCL on the slave); shouldn't stalling only occur if the master employs powersaving?
No. If you've just changed the media then it will spin up, scan the TOC and take time to respond. Its a corner case and its a strongly ill advised configuration
I've only seen reports on the stall for laptops (actually only Dell laptops), e.g. I don't think ordinary desktop optical drives uses powersaving? FWIW, I couldn't reproduce it the stall on a desktop system anyway. And I must admit - I would be surprised to see a laptop with two optical drives on the same IDE channel.
All drives have some internal power management, how they respond to the OS isnt really defined providing they do respond. Again the dell one is a weird drive
-
Alan Cox -
Arjan van de Ven -
Brian Millett -
David Zeuthen -
Jef Spaleta -
Paul Johnson