[2.6.18-rc2-mm1] libata cdroms not automounted

[2.6.18-rc2-mm1] libata cdroms not automounted

[J.A. Magallón]

Hi...

Following with my switch to libata for everything...
After latest patches, my burner and dvd work ok, apart from the fact that
they do not get auto-mounted in gnome environment.
udevmonitor shows nothing when a CD is inserted.

More:
- USB sticks work
- IDE ZIP drive works:
UEVENT[1154559818.714967] add@/block/sda/sda1
UEVENT[1154559820.046948] mount@/block/sda/sda1
- cdroms work under the old IDE driver (not tested in the same box, but
  with the same software)
- srX cdroms generated by libata do not automount (tested in 2 boxes)

As software is the same in the 3 boxes, and some things work, I suspect
the kernel is not generating the correct events ?
Or is the combo udev+dbus+hal userspace what fails ?
But as udevmonitor shows events for zip drive but none for cdrom, I would
vote against the kernel :)

Someone with a real SCSI cdrom can check if it works ?

Software:
- Linux 2.6.18-rc2-mm1+scsi-media-detection-patch [1]
- udev-096
- dbus-0.91
- hal-0.5.7.1

(mandriva cooker)

More info on demand.

TIA

[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=115412002912837&w=2

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam05 (gcc 4.1.1 20060724 (prerelease) (4.1.1-3mdk)) #1 SMP PREEMPT

Re: [2.6.18-rc2-mm1] libata cdroms not automounted

[Robert Hancock]

J.A. Magallón wrote:
> Following with my switch to libata for everything...
> After latest patches, my burner and dvd work ok, apart from the fact that
> they do not get auto-mounted in gnome environment.

I've seen this as well on my laptop with the latest Fedora Core 5 kernel 
plus Alan's 2.6.17-ide1, with the latest FC5 update versions of udev, 
hal, etc.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [2.6.18-rc2-mm1] libata cdroms not automounted

[Tejun Heo]

J.A. Magallón wrote:
> Hi...
> 
> Following with my switch to libata for everything...
> After latest patches, my burner and dvd work ok, apart from the fact that
> they do not get auto-mounted in gnome environment.
> udevmonitor shows nothing when a CD is inserted.

Media insertion is not notified to user space via udev, so userspace 
implement cd automount by polling.  IIRC, back when libata ATAPI support 
was premature, we had quite a few bug reports regarding error messages 
generated by those polling activities.  Maybe your distribution disabled 
polling for SCSI cdroms for that reason.  I seem to recollect the 
polling was done by some gnome daemon, not sure which though.

My memory is a bit vague about this.  Please correct me if I got 
something wrong.

-- 
tejun

Re: [2.6.18-rc2-mm1] libata cdroms not automounted

[Mark Lord]

Tejun Heo wrote:
> J.A. Magallón wrote:
>> Hi...
>>
>> Following with my switch to libata for everything...
>> After latest patches, my burner and dvd work ok, apart from the fact that
>> they do not get auto-mounted in gnome environment.
>> udevmonitor shows nothing when a CD is inserted.
> 
> Media insertion is not notified to user space via udev, so userspace 
> implement cd automount by polling.  IIRC, back when libata ATAPI support 
> was premature, we had quite a few bug reports regarding error messages 
> generated by those polling activities.  Maybe your distribution disabled 
> polling for SCSI cdroms for that reason.  I seem to recollect the 
> polling was done by some gnome daemon, not sure which though.

The problem at the time was that libata error handling was horribly broken
and would randomly lock up the system from time to time.  Since CD autopolling
triggers a libata error each time it is done (1 or 2 times per second..),
it tended to trip over the libata EH bug and kill the system quite often.

I don't know what the distros did about it, other than patch the kernel
once we identified the issue.

Cheers

Re: [2.6.18-rc2-mm1] libata cdroms not automounted

[Jiri Slaby]

Tejun Heo wrote:
> polling for SCSI cdroms for that reason.  I seem to recollect the 
> polling was done by some gnome daemon, not sure which though.

probably gnome-volume-manager

regards,
-- 
<a href="http://www.fi.muni.cz/~xslaby/">Jiri Slaby</a>
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: [2.6.18-rc2-mm1] libata cdroms not automounted

[Tejun Heo]

Jiri Slaby wrote:
> Tejun Heo wrote:
>> polling for SCSI cdroms for that reason.  I seem to recollect the 
>> polling was done by some gnome daemon, not sure which though.
> 
> probably gnome-volume-manager

Yeah, that sounds about right.

-- 
tejun

Re: [2.6.18-rc2-mm1] libata cdroms not automounted

[Robert Hancock]

J.A. Magallón wrote:
> Hi...
> 
> Following with my switch to libata for everything...
> After latest patches, my burner and dvd work ok, apart from the fact that
> they do not get auto-mounted in gnome environment.
> udevmonitor shows nothing when a CD is inserted.

I don't think udev does anything with this, hal is the task that polls 
to see when a disc has been inserted.

> 
> More:
> - USB sticks work
> - IDE ZIP drive works:
> UEVENT[1154559818.714967] add@/block/sda/sda1
> UEVENT[1154559820.046948] mount@/block/sda/sda1
> - cdroms work under the old IDE driver (not tested in the same box, but
>   with the same software)
> - srX cdroms generated by libata do not automount (tested in 2 boxes)
> 
> As software is the same in the 3 boxes, and some things work, I suspect
> the kernel is not generating the correct events ?
> Or is the combo udev+dbus+hal userspace what fails ?
> But as udevmonitor shows events for zip drive but none for cdrom, I would
> vote against the kernel :)

 From what I can tell it looks like this is due to some broken 
assumptions in HAL that I described in this RH Bugzilla entry:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201533

Essentially it seems to assume that any sysfs filename like sr0 which 
ends in a number corresponds to a partition, which in this case (and 
likely others) is wrong. This looks to have been fixed in the HAL git 
repository but hasn't made it into a HAL release yet.

IOW, from what I can see the kernel is vindicated..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/