2006-08-02 23:16:37

by J.A. Magallón

[permalink] [raw]
Subject: [2.6.18-rc2-mm1] libata cdroms not automounted

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


2006-08-03 02:39:01

by Robert Hancock

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

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 [email protected]
Home Page: http://www.roberthancock.com/

2006-08-04 07:29:15

by Tejun Heo

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

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

2006-08-04 14:05:39

by Mark Lord

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

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

2006-08-04 23:04:42

by Jiri Slaby

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

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

2006-08-05 03:41:06

by Tejun Heo

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

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

2006-08-07 07:51:48

by Robert Hancock

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

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 [email protected]
Home Page: http://www.roberthancock.com/