From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751147AbWHGHvs (ORCPT ); Mon, 7 Aug 2006 03:51:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751148AbWHGHvs (ORCPT ); Mon, 7 Aug 2006 03:51:48 -0400 Received: from shawidc-mo1.cg.shawcable.net ([24.71.223.10]:21194 "EHLO pd4mo3so.prod.shaw.ca") by vger.kernel.org with ESMTP id S1751147AbWHGHvr (ORCPT ); Mon, 7 Aug 2006 03:51:47 -0400 Date: Mon, 07 Aug 2006 01:51:44 -0600 From: Robert Hancock Subject: Re: [2.6.18-rc2-mm1] libata cdroms not automounted In-reply-to: To: =?ISO-8859-1?Q?=22J=2EA=2E_Magall=F3n=22?= Cc: "Linux-Kernel, " , Alan Cox Message-id: <44D6F110.3070907@shaw.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT References: User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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/