* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-19 13:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Wed, May 19, 2010 at 15:23, Tejun Heo <tj@kernel.org> wrote:
> For new comers: A cdrom is smart enough to actually raise AN but at
> the same time dumb enough to raise it again on each open leading to
> infinite loop involving the drive, kernel and udev.
>
> On 05/18/2010 10:18 PM, Kay Sievers wrote:
>> Tejun, the stuff in:
>> drivers/ata/libata-eh.c::sata_async_notification()
>> seems to send events for this device, even when there is no changed
>> media. Any ideas how to debug this? Or to check if these events are
>> really events we should put out to userspace?
>
> Hmmm... I've been looking through the standards and things look
> somewhat dodgy. ATA ACS continuously refers to SerialATA 2.6 for
> details on AN and SerialATA 2.6 standard in turn claims that it
> describes the AN mechanism but doesn't define all the events AN can be
> raised for and for those one should refer to command standards (in
> this case ACS), *but* both list media change event as a "yeah can be
> used like that" example. So, in the end, nobody clearly defines it.
> Sweet. :-)
>
> That said, w/o issuing further commands, the driver can't tell what
> the AN exactly means. There's no further information at all. It's a
> simple notification from the device. For ATAPI devices, it would be
> safe to assume that checking media status is the right action to take
> although both ATA and SATA standards haven't been brave enough to
> actually define it precisely; however, exposing it directly to
> userland as a media change event seems quite naive.
>
> I think it's best to plug AN till we have proper media presence
> detection inside kernel proper so that our behavior doesn't differ
> from windows apparently is the only thing many vendors are verifying
> their hardware against.
Yeah, that sounds good, and we can probably explicitly check with the
in-kernel polling if we really have a media change, and only then send
stuff out to userspace.
Sounds all good, and thanks a lot for the quick fix.
Thanks,
Kay
^ permalink raw reply
* [PATCH #upstream-fixes] libata: disable ATAPI AN by default
From: Tejun Heo @ 2010-05-19 13:38 UTC (permalink / raw)
To: Jeff Garzik, linux-ide@vger.kernel.org
Cc: Kay Sievers, Nick Bowler, David Zeuthen, linux-hotplug, stable
In-Reply-To: <4BF3E64D.2040003@kernel.org>
There are ATAPI devices which raise AN when hit by commands issued by
open(). This leads to infinite loop of AN -> MEDIA_CHANGE uevent ->
udev open() to check media -> AN.
Both ACS and SerialATA standards don't define in which case ATAPI
devices are supposed to raise or not raise AN. They both list media
insertion event as a possible use case for ATAPI ANs but there is no
clear description of what constitutes such events. As such, it seems
a bit too naive to export ANs directly to userland as MEDIA_CHANGE
events without further verification (which should behave similarly to
windows as it apparently is the only thing that some hardware vendors
are testing against).
This patch adds libata.atapi_an module parameter and disables ATAPI AN
by default for now.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Nick Bowler <nbowler@elliptictech.com>
Cc: David Zeuthen <david@fubar.dk>
Cc: stable@kernel.org
---
drivers/ata/libata-core.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 49cffb6..5abab5d 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -160,6 +160,10 @@ int libata_allow_tpm = 0;
module_param_named(allow_tpm, libata_allow_tpm, int, 0444);
MODULE_PARM_DESC(allow_tpm, "Permit the use of TPM commands (0=off [default], 1=on)");
+static int atapi_an;
+module_param(atapi_an, int, 0444);
+MODULE_PARM_DESC(atapi_an, "Enable ATAPI AN media presence notification (0\x0ff [default], 1=on)");
+
MODULE_AUTHOR("Jeff Garzik");
MODULE_DESCRIPTION("Library module for ATA devices");
MODULE_LICENSE("GPL");
@@ -2572,7 +2576,8 @@ int ata_dev_configure(struct ata_device *dev)
* to enable ATAPI AN to discern between PHY status
* changed notifications and ATAPI ANs.
*/
- if ((ap->flags & ATA_FLAG_AN) && ata_id_has_atapi_AN(id) &&
+ if (atapi_an &&
+ (ap->flags & ATA_FLAG_AN) && ata_id_has_atapi_AN(id) &&
(!sata_pmp_attached(ap) ||
sata_scr_read(&ap->link, SCR_NOTIFICATION, &sntf) = 0)) {
unsigned int err_mask;
^ permalink raw reply related
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Tejun Heo @ 2010-05-19 13:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
(cc'ing linux-ide and Jeff)
Hello,
For new comers: A cdrom is smart enough to actually raise AN but at
the same time dumb enough to raise it again on each open leading to
infinite loop involving the drive, kernel and udev.
On 05/18/2010 10:18 PM, Kay Sievers wrote:
> Tejun, the stuff in:
> drivers/ata/libata-eh.c::sata_async_notification()
> seems to send events for this device, even when there is no changed
> media. Any ideas how to debug this? Or to check if these events are
> really events we should put out to userspace?
Hmmm... I've been looking through the standards and things look
somewhat dodgy. ATA ACS continuously refers to SerialATA 2.6 for
details on AN and SerialATA 2.6 standard in turn claims that it
describes the AN mechanism but doesn't define all the events AN can be
raised for and for those one should refer to command standards (in
this case ACS), *but* both list media change event as a "yeah can be
used like that" example. So, in the end, nobody clearly defines it.
Sweet. :-)
That said, w/o issuing further commands, the driver can't tell what
the AN exactly means. There's no further information at all. It's a
simple notification from the device. For ATAPI devices, it would be
safe to assume that checking media status is the right action to take
although both ATA and SATA standards haven't been brave enough to
actually define it precisely; however, exposing it directly to
userland as a media change event seems quite naive.
I think it's best to plug AN till we have proper media presence
detection inside kernel proper so that our behavior doesn't differ
from windows apparently is the only thing many vendors are verifying
their hardware against.
Thanks.
--
tejun
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 20:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 21:23, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 20:53 Tue 18 May , Kay Sievers wrote:
>> Nick, if you run:
>> udevadm monitor --property
>> and access the device that it generates an event. does it always
>> contain the line:
>> SDEV_MEDIA_CHANGE=1
>> ?
>> That would surely be incorrect to send from the kernel, if it isn't a
>> media change. And we might check if we can suppress these.
>
> I ran the earlier blkid test with the drive idle, and yes,
> SDEV_MEDIA_CHANGE=1 appears 6 times in the output.
Tejun, the stuff in:
drivers/ata/libata-eh.c::sata_async_notification()
seems to send events for this device, even when there is no changed
media. Any ideas how to debug this? Or to check if these events are
really events we should put out to userspace?
Thanks,
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Nick Bowler @ 2010-05-18 19:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On 20:53 Tue 18 May , Kay Sievers wrote:
> Nick, if you run:
> udevadm monitor --property
> and access the device that it generates an event. does it always
> contain the line:
> SDEV_MEDIA_CHANGE=1
> ?
> That would surely be incorrect to send from the kernel, if it isn't a
> media change. And we might check if we can suppress these.
I ran the earlier blkid test with the drive idle, and yes,
SDEV_MEDIA_CHANGE=1 appears 6 times in the output.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 18:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 20:28, Tejun Heo <tj@kernel.org> wrote:
> On 05/18/2010 08:20 PM, Kay Sievers wrote:
>> Yeah, the problem is that we already have the problem with current
>> software that causes the event loop. And we need a solution now. :)
>>
>> We might need to switch the AN stuff off by default in the kernel, and
>> only enable it when we know we are able to handle it?
>
> Yeah, somehow ignoring those events was what I suggested. I thought
> maybe it can be done in userland?
It doesn't look like we can do that. But while thinking about that:
Nick, if you run:
udevadm monitor --property
and access the device that it generates an event. does it always
contain the line:
SDEV_MEDIA_CHANGE=1
?
That would surely be incorrect to send from the kernel, if it isn't a
media change. And we might check if we can suppress these.
> Currently there is no switch on the
> driver side. If the feature is there and the host supports it, it's
> automatically enabled. Hmmm... When we have proper in kernel media
> presence polling, AN should be piped through there anyway so it makes
> sense to prevent it from reaching userland directly now. How does
> that sound?
Yeah, that sounds great. It would be just nice to have something now,
so we can fix the current issues. The in-kernel polling might need
some time still. :)
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Tejun Heo @ 2010-05-18 18:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
Hello,
On 05/18/2010 08:20 PM, Kay Sievers wrote:
> Yeah, the problem is that we already have the problem with current
> software that causes the event loop. And we need a solution now. :)
>
> We might need to switch the AN stuff off by default in the kernel, and
> only enable it when we know we are able to handle it?
Yeah, somehow ignoring those events was what I suggested. I thought
maybe it can be done in userland? Currently there is no switch on the
driver side. If the feature is there and the host supports it, it's
automatically enabled. Hmmm... When we have proper in kernel media
presence polling, AN should be piped through there anyway so it makes
sense to prevent it from reaching userland directly now. How does
that sound?
Thanks.
--
tejun
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 18:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 20:14, Tejun Heo <tj@kernel.org> wrote:
> On 05/18/2010 07:53 PM, Kay Sievers wrote:
>> Tejun,
>> an AN capable SATA optical drive seems to send AN events with every
>> open(). For userspace these look the same as the media changed events,
>> and cause a loop when udev checks if there is a new media. Any ideas
>> if these AN events are expected, or useful for anything?
>
> The open() path issues several commands and it could be that the drive
> is raising AN when certain conditions are met just in case. After all
> windows only uses single command for media presence polling, so
> there's nothing stopping vendors from using TUR, for example, as the
> level triggered check point to see whether media is available and
> raise AN if so. After all, that wouldn't lose any event and in case
> the internal state went out of sync, it would work as an easy resync
> point.
>
> Long term, I think the only solution is to do what windows does for
> media presence polling; otherwise, we'll keep running into various
> obscure issues. For short term, I dunno. Don't use AN for the time
> being? :-)
Yeah, the problem is that we already have the problem with current
software that causes the event loop. And we need a solution now. :)
We might need to switch the AN stuff off by default in the kernel, and
only enable it when we know we are able to handle it?
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Tejun Heo @ 2010-05-18 18:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
Hello,
On 05/18/2010 07:53 PM, Kay Sievers wrote:
> Tejun,
> an AN capable SATA optical drive seems to send AN events with every
> open(). For userspace these look the same as the media changed events,
> and cause a loop when udev checks if there is a new media. Any ideas
> if these AN events are expected, or useful for anything?
The open() path issues several commands and it could be that the drive
is raising AN when certain conditions are met just in case. After all
windows only uses single command for media presence polling, so
there's nothing stopping vendors from using TUR, for example, as the
level triggered check point to see whether media is available and
raise AN if so. After all, that wouldn't lose any event and in case
the internal state went out of sync, it would work as an easy resync
point.
Long term, I think the only solution is to do what windows does for
media presence polling; otherwise, we'll keep running into various
obscure issues. For short term, I dunno. Don't use AN for the time
being? :-)
Thanks.
--
tejun
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 17:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 18:23, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 16:21 Tue 18 May , Kay Sievers wrote:
>> On Tue, May 18, 2010 at 15:25, Nick Bowler <nbowler@elliptictech.com> wrote:
>> > On 07:08 Tue 18 May , Kay Sievers wrote:
>> >> What does:
>> >> cat /sys/class/block/sr0/../../evt_media_change
>> >> print for this device?
>> >
>> > Prints 1.
>>
>> Oh, seems to be an AN capable device, which actually really sends events. :)
>>
>> I don't know if that works, never tried, but if you chmod the
>> evt_media_change file to 0664. and write 0 to it, does it still behave
>> the same?
>
> I can successfully chmod and write 0 to that file, and it reads back as
> 0, but the behaviour remains the same (the blkid rules are uncommented),
> and the disk never spins down.
Ok, as said, it was just a try. Thanks for the test.
The kernel seems not to filter events based on that mask. So a fix for
this would be in the kernel, to either provide information about the
source of the event, or to be able to suppress these AN event, which
have no obvious meaning.
Tejun,
an AN capable SATA optical drive seems to send AN events with every
open(). For userspace these look the same as the media changed events,
and cause a loop when udev checks if there is a new media. Any ideas
if these AN events are expected, or useful for anything?
David,
this is stuff we might need to cover with udisks in the future to
handle AN properly.
Thanks,
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Nick Bowler @ 2010-05-18 16:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On 16:21 Tue 18 May , Kay Sievers wrote:
> On Tue, May 18, 2010 at 15:25, Nick Bowler <nbowler@elliptictech.com> wrote:
> > On 07:08 Tue 18 May , Kay Sievers wrote:
> >> What does:
> >> cat /sys/class/block/sr0/../../evt_media_change
> >> print for this device?
> >
> > Prints 1.
>
> Oh, seems to be an AN capable device, which actually really sends events. :)
>
> I don't know if that works, never tried, but if you chmod the
> evt_media_change file to 0664. and write 0 to it, does it still behave
> the same?
I can successfully chmod and write 0 to that file, and it reads back as
0, but the behaviour remains the same (the blkid rules are uncommented),
and the disk never spins down.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 14:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 15:25, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 07:08 Tue 18 May , Kay Sievers wrote:
>> On Tue, May 18, 2010 at 00:54, Nicolas Thomas Bowler
>> > On Mon, 17 May 2010 18:27:48 +0200, Kay Sievers wrote:
>>
>> > With the rules commented out, the command /sbin/blkid -p -oudev /dev/sr0
>> > on the non-spinning drive causes three distinct bursts of events to
>> > occur:
>>
>> Ok, the drive seems to send out new events with every access. Maybe
>> it's a device which tries to send AN (async) events by itself.
>>
>> What does:
>> cat /sys/class/block/sr0/../../evt_media_change
>> print for this device?
>
> Prints 1.
Oh, seems to be an AN capable device, which actually really sends events. :)
I don't know if that works, never tried, but if you chmod the
evt_media_change file to 0664. and write 0 to it, does it still behave
the same?
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Nick Bowler @ 2010-05-18 13:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On 07:08 Tue 18 May , Kay Sievers wrote:
> On Tue, May 18, 2010 at 00:54, Nicolas Thomas Bowler
> > On Mon, 17 May 2010 18:27:48 +0200, Kay Sievers wrote:
>
> > With the rules commented out, the command /sbin/blkid -p -oudev /dev/sr0
> > on the non-spinning drive causes three distinct bursts of events to
> > occur:
>
> Ok, the drive seems to send out new events with every access. Maybe
> it's a device which tries to send AN (async) events by itself.
>
> What does:
> cat /sys/class/block/sr0/../../evt_media_change
> print for this device?
Prints 1.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-18 5:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Tue, May 18, 2010 at 00:54, Nicolas Thomas Bowler
<ntbowler@student.cs.uwaterloo.ca> wrote:
> On Mon, 17 May 2010 18:27:48 +0200, Kay Sievers wrote:
>> Ok, and if you enable the blkid rules again, then you see events in
>> the monitor?
>
> Sorry, the above statement that udevadm monitor prints nothing was a lie!
> (I must have been insane and/or lacking in coffee first thing in the
> morning).
>
> With the rules commented out, the command /sbin/blkid -p -oudev /dev/sr0
> on the non-spinning drive causes three distinct bursts of events to
> occur:
Ok, the drive seems to send out new events with every access. Maybe
it's a device which tries to send AN (async) events by itself.
What does:
cat /sys/class/block/sr0/../../evt_media_change
print for this device?
Kay
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Nicolas Thomas Bowler @ 2010-05-17 22:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Mon, 17 May 2010 18:27:48 +0200, Kay Sievers wrote:
> On Mon, May 17, 2010 at 14:43, Nick Bowler <nbowler@elliptictech.com>
> wrote:
>> On 12:06 Mon 17 May , Kay Sievers wrote:
>>> To make sure you don't have any other stuff accessing the device,
>>> can you please attach the output of:
>>> udevadm test /class/block/sr0
>>> so we can make sure it's nothing we don't think of.
>>
>> Appended.
>
> Loos all fine and with the usual behavior so far.
>
>>> To narrow down the blkid issue, if you comment out the rule, and let
>>> the drive spin down, then run:
>>> /sbin/blkid -p -oudev /dev/sr0
>>> manually, do you see while doing that any events generated in:
>>> udevadm monitor
>>> ?
>>
>> The command causes the cd to spin up, but nothing is printed by
>> udevadm monitor as a result.
>
> Ok, and if you enable the blkid rules again, then you see events in
> the monitor?
Sorry, the above statement that udevadm monitor prints nothing was a lie!
(I must have been insane and/or lacking in coffee first thing in the
morning).
With the rules commented out, the command /sbin/blkid -p -oudev /dev/sr0
on the non-spinning drive causes three distinct bursts of events to
occur:
(a) First, immediately after the disk spins up (and blkid prints stuff)
KERNEL[1274136271.742645] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1274136271.743204] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1274136271.743255] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1274136271.792800] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
(b) Then, after a few seconds the disk spins down, but it's still humming:
KERNEL[1274136276.306739] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1274136276.307182] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1274136276.307295] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1274136276.353864] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
(c) Finally, after a few more seconds the drive totally shuts up:
KERNEL[1274136304.187396] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
KERNEL[1274136304.187954] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV [1274136304.188004] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV [1274136304.231548] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-17 16:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Mon, May 17, 2010 at 14:43, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 12:06 Mon 17 May , Kay Sievers wrote:
>> To make sure you don't have any other stuff accessing the device, can
>> you please attach the output of:
>> udevadm test /class/block/sr0
>> so we can make sure it's nothing we don't think of.
>
> Appended.
Loos all fine and with the usual behavior so far.
>> To narrow down the blkid issue, if you comment out the rule, and let
>> the drive spin down, then run:
>> /sbin/blkid -p -oudev /dev/sr0
>> manually, do you see while doing that any events generated in:
>> udevadm monitor
>> ?
>
> The command causes the cd to spin up, but nothing is printed by udevadm
> monitor as a result.
Ok, and if you enable the blkid rules again, then you see events in the monitor?
Thanks,
Kay
^ permalink raw reply
* Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks
From: Greg KH @ 2010-05-17 16:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513134742.GB1768@piware.de>
On Mon, May 17, 2010 at 12:10:06PM +0100, Scott James Remnant wrote:
> On Sun, 2010-05-16 at 09:04 -0700, Greg KH wrote:
>
> > On Sun, May 16, 2010 at 12:22:47PM +0100, Scott James Remnant wrote:
> > > I consider myself an active member of udev upstream, and I think we've
> > > taken a wrong turn with the design and implementation.
> >
> > What specifically do you mean by this?
> >
> > Is the current libudev not a good design for your needs? What should it
> > be instead?
> >
> Actually, quite the opposite! I think that libudev is a great design.
>
> I think that the wrong turn is that we rely on a massive "cold plug"
> phase during boot, and we rely on probing every single piece of hardware
> during that phase or on later insertion - whether or not anything on the
> system actually cares about the result.
But how would we "know" if we care about a device until we actually
figure out what the device is, and load the driver for it?
This cold-plug phase doesn't seem to take a very large amount of time
these days at all, so I don't see the real savings that would be
possible here.
Or am I missing something?
thanks,
greg k-h
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Nick Bowler @ 2010-05-17 12:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On 12:06 Mon 17 May , Kay Sievers wrote:
> To make sure you don't have any other stuff accessing the device, can
> you please attach the output of:
> udevadm test /class/block/sr0
> so we can make sure it's nothing we don't think of.
Appended.
> To narrow down the blkid issue, if you comment out the rule, and let
> the drive spin down, then run:
> /sbin/blkid -p -oudev /dev/sr0
> manually, do you see while doing that any events generated in:
> udevadm monitor
> ?
The command causes the cd to spin up, but nothing is printed by udevadm
monitor as a result.
# udevadm test /class/block/sr0
run_command: calling: test
udevadm_test: version 154
This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
parse_file: reading '/dev/.udev/rules.d/10-root-link.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/30-kernel-compat.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/40-gentoo.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/40-usb_modeswitch.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/50-firmware.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/50-udev-default.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/60-cdrom_id.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/60-floppy.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-pcmcia.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/60-persistent-alsa.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/60-persistent-input.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/60-persistent-serial.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/60-persistent-storage-tape.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/60-persistent-storage.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/60-persistent-v4l.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/61-mobile-action.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/61-persistent-storage-edd.rules' as rules file
parse_file: reading '/etc/udev/rules.d/65-kvm.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/70-acl.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/70-hid2hci.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-libgphoto2.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-persistent-cd.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-persistent-net.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/75-cd-aliases-generator.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/75-net-description.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/75-persistent-net-generator.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/75-tty-description.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/78-sound-card.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/79-fstab_import.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/80-drivers.rules' as rules file
parse_file: reading '/etc/udev/rules.d/90-local.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/90-network.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/90-pulseaudio.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/95-keyboard-force-release.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/95-keymap.rules' as rules file
parse_file: reading '/lib64/udev/rules.d/95-udev-late.rules' as rules file
parse_file: reading '/etc/udev/rules.d/99-hsf.rules' as rules file
udev_rules_new: rules use 81948 bytes tokens (6829 * 12 bytes), 18007 bytes buffer
udev_rules_new: temporary index used 29900 bytes (1495 * 20 bytes)
udev_device_new_from_syspath: device 0x1790140 has devpath '/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0'
udev_device_new_from_syspath: device 0x17a7b30 has devpath '/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0'
udev_device_read_db: device 0x17a7b30 filled with db file data
udev_rules_apply_to_event: LINK 'block/11:0' /lib64/udev/rules.d/50-udev-default.rules:3
udev_rules_apply_to_event: GROUP 6 /lib64/udev/rules.d/50-udev-default.rules:76
udev_rules_apply_to_event: GROUP 19 /lib64/udev/rules.d/50-udev-default.rules:82
udev_rules_apply_to_event: LINK 'scd0' /lib64/udev/rules.d/50-udev-default.rules:82
udev_rules_apply_to_event: IMPORT 'cdrom_id --export /dev/sr0' /lib64/udev/rules.d/60-cdrom_id.rules:9
util_run_program: 'cdrom_id --export /dev/sr0' started
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_CD=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_CD_R=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_CD_RW=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_DVD=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_DVD_R=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_DVD_RW=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_DVD_RAM=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_DVD_PLUS_R=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_DVD_PLUS_RW=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_DVD_PLUS_R_DL=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_MRW=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_MRW_W=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_MEDIA=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_MEDIA_CD=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_MEDIA_SESSION_COUNT=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_MEDIA_TRACK_COUNT=1'
util_run_program: '/lib64/udev/cdrom_id' (stdout) 'ID_CDROM_MEDIA_TRACK_COUNT_DATA=1'
util_run_program: 'cdrom_id --export /dev/sr0' returned with exitcode 0
udev_device_new_from_syspath: device 0x179d460 has devpath '/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0'
udev_device_new_from_syspath: device 0x179d7b0 has devpath '/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0'
udev_device_new_from_syspath: device 0x179dae0 has devpath '/devices/pci0000:00/0000:00:1f.2/host1'
udev_device_new_from_syspath: device 0x179de00 has devpath '/devices/pci0000:00/0000:00:1f.2'
udev_device_new_from_syspath: device 0x179e110 has devpath '/devices/pci0000:00'
udev_rules_apply_to_event: IMPORT 'scsi_id --export --whitelisted -d /dev/sr0' /lib64/udev/rules.d/60-persistent-storage.rules:28
util_run_program: 'scsi_id --export --whitelisted -d /dev/sr0' started
util_run_program: '/lib64/udev/scsi_id' (stdout) 'ID_SCSI=1'
util_run_program: '/lib64/udev/scsi_id' (stdout) 'ID_VENDOR=Optiarc'
util_run_program: '/lib64/udev/scsi_id' (stdout) 'ID_VENDOR_ENC=Optiarc\x20'
util_run_program: '/lib64/udev/scsi_id' (stdout) 'ID_MODEL=DVD_RW_AD-7910S'
util_run_program: '/lib64/udev/scsi_id' (stdout) 'ID_MODEL_ENC=DVD\x20RW\x20AD-7910S\x20'
util_run_program: '/lib64/udev/scsi_id' (stdout) 'ID_REVISION=1.D2'
util_run_program: '/lib64/udev/scsi_id' (stdout) 'ID_TYPEÍ'
util_run_program: 'scsi_id --export --whitelisted -d /dev/sr0' returned with exitcode 0
udev_rules_apply_to_event: IMPORT 'path_id /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0' /lib64/udev/rules.d/60-persistent-storage.rules:47
util_run_program: 'path_id /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0' started
util_run_program: '/lib64/udev/path_id' (stdout) 'ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0'
util_run_program: 'path_id /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0' returned with exitcode 0
udev_rules_apply_to_event: LINK 'disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0' /lib64/udev/rules.d/60-persistent-storage.rules:48
udev_rules_apply_to_event: LINK 'cdrom' /etc/udev/rules.d/70-persistent-cd.rules:8
udev_rules_apply_to_event: LINK 'cdrw' /etc/udev/rules.d/70-persistent-cd.rules:9
udev_rules_apply_to_event: LINK 'dvd' /etc/udev/rules.d/70-persistent-cd.rules:10
udev_rules_apply_to_event: LINK 'dvdrw' /etc/udev/rules.d/70-persistent-cd.rules:11
udev_event_execute_rules: no node name set, will use kernel supplied name 'sr0'
udev_device_update_db: created db file for '/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0' in '/dev/.udev/db/block:sr0'
udev_node_add: creating device node '/dev/sr0', devnum\x11:0, mode\x0660, uid=0, gid\x19
udev_node_mknod: preserve file '/dev/sr0', because it has correct dev_t
udev_node_mknod: preserve permissions /dev/sr0, 060660, uid=0, gid\x19
node_symlink: preserve already existing symlink '/dev/block/11:0' to '../sr0'
link_find_prioritized: found 'b11:0' claiming '/dev/.udev/links/scd0'
link_update: creating link '/dev/scd0' to '/dev/sr0'
node_symlink: preserve already existing symlink '/dev/scd0' to 'sr0'
link_find_prioritized: found 'b11:0' claiming '/dev/.udev/links/disk\x2fby-path\x2fpci-0000:00:1f.2-scsi-1:0:0:0'
link_update: creating link '/dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0' to '/dev/sr0'
node_symlink: preserve already existing symlink '/dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0' to '../../sr0'
link_find_prioritized: found 'b11:0' claiming '/dev/.udev/links/cdrom'
link_update: creating link '/dev/cdrom' to '/dev/sr0'
node_symlink: preserve already existing symlink '/dev/cdrom' to 'sr0'
link_find_prioritized: found 'b11:0' claiming '/dev/.udev/links/cdrw'
link_update: creating link '/dev/cdrw' to '/dev/sr0'
node_symlink: preserve already existing symlink '/dev/cdrw' to 'sr0'
link_find_prioritized: found 'b11:0' claiming '/dev/.udev/links/dvd'
link_update: creating link '/dev/dvd' to '/dev/sr0'
node_symlink: preserve already existing symlink '/dev/dvd' to 'sr0'
link_find_prioritized: found 'b11:0' claiming '/dev/.udev/links/dvdrw'
link_update: creating link '/dev/dvdrw' to '/dev/sr0'
node_symlink: preserve already existing symlink '/dev/dvdrw' to 'sr0'
udevadm_test: UDEV_LOG=6
udevadm_test: DEVPATH=/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0
udevadm_test: MAJOR\x11
udevadm_test: MINOR=0
udevadm_test: DEVNAME=/dev/sr0
udevadm_test: DEVTYPE=disk
udevadm_test: ACTIONd
udevadm_test: SUBSYSTEM=block
udevadm_test: DEVLINKS=/dev/block/11:0 /dev/scd0 /dev/disk/by-path/pci-0000:00:1f.2-scsi-1:0:0:0 /dev/cdrom /dev/cdrw /dev/dvd /dev/dvdrw
udevadm_test: ID_CDROM=1
udevadm_test: ID_CDROM_CD=1
udevadm_test: ID_CDROM_CD_R=1
udevadm_test: ID_CDROM_CD_RW=1
udevadm_test: ID_CDROM_DVD=1
udevadm_test: ID_CDROM_DVD_R=1
udevadm_test: ID_CDROM_DVD_RW=1
udevadm_test: ID_CDROM_DVD_RAM=1
udevadm_test: ID_CDROM_DVD_PLUS_R=1
udevadm_test: ID_CDROM_DVD_PLUS_RW=1
udevadm_test: ID_CDROM_DVD_PLUS_R_DL=1
udevadm_test: ID_CDROM_MRW=1
udevadm_test: ID_CDROM_MRW_W=1
udevadm_test: ID_CDROM_MEDIA=1
udevadm_test: ID_CDROM_MEDIA_CD=1
udevadm_test: ID_CDROM_MEDIA_SESSION_COUNT=1
udevadm_test: ID_CDROM_MEDIA_TRACK_COUNT=1
udevadm_test: ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
udevadm_test: ID_SCSI=1
udevadm_test: ID_VENDOR=Optiarc
udevadm_test: ID_VENDOR_ENC=Optiarc\x20
udevadm_test: ID_MODEL=DVD_RW_AD-7910S
udevadm_test: ID_MODEL_ENC=DVD\x20RW\x20AD-7910S\x20
udevadm_test: ID_REVISION=1.D2
udevadm_test: ID_TYPEÍ
udevadm_test: ID_BUS=scsi
udevadm_test: ID_PATH=pci-0000:00:1f.2-scsi-1:0:0:0
udevadm_test: TAGS=:udev-acl:
udevadm_test: GENERATED=1
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks
From: Scott James Remnant @ 2010-05-17 11:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513134742.GB1768@piware.de>
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
On Sun, 2010-05-16 at 09:04 -0700, Greg KH wrote:
> On Sun, May 16, 2010 at 12:22:47PM +0100, Scott James Remnant wrote:
> > I consider myself an active member of udev upstream, and I think we've
> > taken a wrong turn with the design and implementation.
>
> What specifically do you mean by this?
>
> Is the current libudev not a good design for your needs? What should it
> be instead?
>
Actually, quite the opposite! I think that libudev is a great design.
I think that the wrong turn is that we rely on a massive "cold plug"
phase during boot, and we rely on probing every single piece of hardware
during that phase or on later insertion - whether or not anything on the
system actually cares about the result.
Scott
--
Scott James Remnant
scott@ubuntu.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-17 10:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Fri, May 14, 2010 at 20:48, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 16:41 Fri 14 May , Kay Sievers wrote:
>> Does cdrom_id work as expected otherwise? What does:
>> /lib/udev/cdrom_id --debug /dev/sr0
>> print?
>
> Output from this command is appended.
>
>> Does running cdrom_id spin up the drive?
>
> No, the above does not cause the drive to spin up.
>
>> There is a call to /sbin/blkid in:
>> /lib/udev/rules.d/60-persistent-storage.rules
>> with:
>> KERNEL="sr*", IMPORT{program}="/sbin/blkid ...
>> If you comment that out, does the issue go away?
>
> I commented both of the following lines:
>
> KERNEL="sr*", ENV{ID_CDROM_MEDIA}="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}="?*", IMPORT{program}="/sbin/blkid -o udev -p -u noraid -O $env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET} $tempnode"
> KERNEL="sr*", ENV{ID_CDROM_MEDIA}="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}="", IMPORT{program}="/sbin/blkid -o udev -p -u noraid $tempnode"
>
> and the issue indeed goes away.
Hmm, weird behavior.
To make sure you don't have any other stuff accessing the device, can
you please attach the output of:
udevadm test /class/block/sr0
so we can make sure it's nothing we don't think of.
To narrow down the blkid issue, if you comment out the rule, and let
the drive spin down, then run:
/sbin/blkid -p -oudev /dev/sr0
manually, do you see while doing that any events generated in:
udevadm monitor
?
That would look like a bug in the device or the kernel. Because they
are not supposed to flip the media-present bit when the media has not
changed.
Thanks,
Kay
^ permalink raw reply
* Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks
From: Greg KH @ 2010-05-16 16:04 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513134742.GB1768@piware.de>
On Sun, May 16, 2010 at 12:22:47PM +0100, Scott James Remnant wrote:
> I consider myself an active member of udev upstream, and I think we've
> taken a wrong turn with the design and implementation.
What specifically do you mean by this?
Is the current libudev not a good design for your needs? What should it
be instead?
curious,
greg k-h
^ permalink raw reply
* Re: udevd [was: Re: [RFC/PATCH] input_id: add touchpad quirks
From: Scott James Remnant @ 2010-05-16 11:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513134742.GB1768@piware.de>
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
On Thu, 2010-05-13 at 16:06 +0200, Lennart Poettering wrote:
> OMG! Ubuntu is forking udev! This is ... funny...
>
Wow, I've never seen anyone leap so far. There was a veritable chasm
between you and those conclusions.
I consider myself an active member of udev upstream, and I think we've
taken a wrong turn with the design and implementation. Any changes I
propose will be just as much upstream as any you propose.
Scott
--
Scott James Remnant
scott@ubuntu.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Nick Bowler @ 2010-05-14 18:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On 16:41 Fri 14 May , Kay Sievers wrote:
> Does cdrom_id work as expected otherwise? What does:
> /lib/udev/cdrom_id --debug /dev/sr0
> print?
Output from this command is appended.
> Does running cdrom_id spin up the drive?
No, the above does not cause the drive to spin up.
> There is a call to /sbin/blkid in:
> /lib/udev/rules.d/60-persistent-storage.rules
> with:
> KERNEL="sr*", IMPORT{program}="/sbin/blkid ...
> If you comment that out, does the issue go away?
I commented both of the following lines:
KERNEL="sr*", ENV{ID_CDROM_MEDIA}="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}="?*", IMPORT{program}="/sbin/blkid -o udev -p -u noraid -O $env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET} $tempnode"
KERNEL="sr*", ENV{ID_CDROM_MEDIA}="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}="", IMPORT{program}="/sbin/blkid -o udev -p -u noraid $tempnode"
and the issue indeed goes away.
# /lib/udev/cdrom_id --debug /dev/sr0
main: probing: '/dev/sr0'
cd_inquiry: INQUIRY: [Optiarc ][DVD RW AD-7910S ][1.D2]
cd_profiles: GET CONFIGURATION: size of features buffer 0x0150
cd_profiles: GET CONFIGURATION: feature 'profiles', with 14 entries
feature_profiles: profile 0x2b dvd_plus_r_dl
feature_profiles: profile 0x1b dvd_plus_r
feature_profiles: profile 0x1a dvd_plus_rw
feature_profiles: profile 0x16 <ignored>
feature_profiles: profile 0x15 <ignored>
feature_profiles: profile 0x14 dvd_rw
feature_profiles: profile 0x13 dvd_rw
feature_profiles: profile 0x12 dvd_ram
feature_profiles: profile 0x11 <ignored>
feature_profiles: profile 0x10 dvd_rom
feature_profiles: profile 0x0a cd_rw
feature_profiles: profile 0x09 cd_r
feature_profiles: profile 0x08 cd_rom
feature_profiles: profile 0x02 <ignored>
cd_profiles: GET CONFIGURATION: feature 0x0001 <ignored>, with 0x08 bytes
cd_profiles: GET CONFIGURATION: feature 0x0002 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0003 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0004 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0010 <ignored>, with 0x08 bytes
cd_profiles: GET CONFIGURATION: feature 0x001d <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x001e <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x001f <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0020 <ignored>, with 0x0c bytes
cd_profiles: GET CONFIGURATION: feature 0x0021 <ignored>, with 0x08 bytes
cd_profiles: GET CONFIGURATION: feature 0x0023 <ignored>, with 0x08 bytes
cd_profiles: GET CONFIGURATION: feature 0x0024 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0026 <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x002a <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x002b <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x002c <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x002d <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x002e <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x002f <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0033 <ignored>, with 0x08 bytes
cd_profiles: GET CONFIGURATION: feature 0x0037 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x003b <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0100 <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x0103 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0105 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0106 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0107 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0108 <ignored>, with 0x0c bytes
cd_profiles: GET CONFIGURATION: feature 0x010a <ignored>, with 0x0c bytes
cd_profiles: current profile 0x11
cd_profiles: profile 0x11 media_dvd_r
cd_media_info: disk type 00
cd_media_toc: READ TOC: len: 20
cd_media_toc: track=1 info=0x4(data) start_block=0
cd_media_toc: last track 1 starts at block 0
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_DVD=1
ID_CDROM_DVD_R=1
ID_CDROM_DVD_RW=1
ID_CDROM_DVD_RAM=1
ID_CDROM_DVD_PLUS_R=1
ID_CDROM_DVD_PLUS_RW=1
ID_CDROM_DVD_PLUS_R_DL=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_DVD_R=1
ID_CDROM_MEDIA_STATE=appendable
ID_CDROM_MEDIA_SESSION_NEXT=2
ID_CDROM_MEDIA_SESSION_COUNT=2
ID_CDROM_MEDIA_TRACK_COUNT=2
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
^ permalink raw reply
* RE: How to use blkid for getting USB partition name???
From: chinnathambi @ 2010-05-14 15:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100506093216.D2E411F105E@zimbra.jasmin-infotech.com>
Regards,
Chinnathambi M
-----Original Message-----
From: chinnathambi [mailto:chinnathambi.m@jasmin-infotech.com]
Sent: Tuesday, May 11, 2010 10:05 AM
To: 'chinnathambi'; 'Karel Zak'
Cc: 'stephane ancelot'; 'linux-hotplug@vger.kernel.org'
Subject: RE: How to use blkid for getting USB partition name???
Hai,
Can any one please clarify in this regard?
Regards,
Chinnathambi M
-----Original Message-----
From: linux-hotplug-owner@vger.kernel.org
[mailto:linux-hotplug-owner@vger.kernel.org] On Behalf Of chinnathambi
Sent: Friday, May 07, 2010 9:55 AM
To: 'Karel Zak'
Cc: 'stephane ancelot'; linux-hotplug@vger.kernel.org
Subject: RE: How to use blkid for getting USB partition name???
Hai Stephane,
I am not able to get any verbose output. Pls carify..
root:/> cat /proc/partitions
major minor #blocks name
31 0 256 mtdblock0
31 1 384 mtdblock1
31 2 7552 mtdblock2
31 3 7680 mtdblock3
31 4 512 mtdblock4
8 0 244198584 sda
8 1 1 sda1
8 5 33551721 sda5
8 6 33551721 sda6
8 7 33551721 sda7
8 8 33551721 sda8
8 9 33551721 sda9
8 10 33551721 sda10
8 11 33551721 sda11
8 12 9325701 sda12
root:/> blkid -p -o udev /dev/sda5
root:/> BLKID_DEBUG=0xffff blkid -p -o udev /dev/sda5
root:/>
root:/>
I need to extract the USB name. But I cant get it. I don
know whether I am doing anything wrong in the basic level. So please clarify
in this regard.
Regards,
Chinnathambi M
-----Original Message-----
From: linux-hotplug-owner@vger.kernel.org
[mailto:linux-hotplug-owner@vger.kernel.org] On Behalf Of Karel Zak
Sent: Thursday, May 06, 2010 7:09 PM
To: chinnathambi
Cc: 'stephane ancelot'; linux-hotplug@vger.kernel.org
Subject: Re: How to use blkid for getting USB partition name???
On Thu, May 06, 2010 at 03:03:23PM +0530, chinnathambi wrote:
> Hai,
> I have enable hotplug for detecting USB. I am having muti partition
> in my USB hard disc. I am trying to recover the parttion name by using
parttion name... Do you mean filesystem LABEL?
> blkid. But I cant get any response. I want to know whether I have to
enable
> anything in my kernel. Or after executing blkid command where to check for
> the output ?
>
> Shown below is how I used blkid.
>
> root:/> hotplug: usb inserted
> hotplug: usb inserted
> hotplug: usb inserted
> hotplug: usb inserted
> hotplug: usb inserted
>
> root:/> cat /proc/partitions
> major minor #blocks name
>
> 31 0 256 mtdblock0
> 31 1 384 mtdblock1
> 31 2 7552 mtdblock2
> 31 3 7680 mtdblock3
> 31 4 512 mtdblock4
> 8 0 244198584 sda
> 8 1 1 sda1
> 8 5 33551721 sda5
> 8 6 33551721 sda6
> 8 7 33551721 sda7
> 8 8 33551721 sda8
> 8 9 33551721 sda9
> 8 10 33551721 sda10
> 8 11 33551721 sda11
> 8 12 9325701 sda12
> root:/> blkid /dev/sda5
> root:/> blkid -c -o /dev/sda5
blkid -p -o udev /dev/sda5
or
BLKID_DEBUG=0xffff blkid -p -o udev /dev/sda5
to get more verbose output.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: udev cdrom_id rules prevent unmounted CD from spinning down
From: Kay Sievers @ 2010-05-14 14:41 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100513153043.GA3966@elliptictech.com>
On Fri, May 14, 2010 at 15:51, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 09:36 Fri 14 May , Martin Pitt wrote:
>> Nick Bowler [2010-05-13 17:37 -0400]:
>> > KERNEL[1273786356.346839] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
>> > KERNEL[1273786361.166466] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
>>
>> Seems this is a 5 second interval.
>
> I suspect it's tied to the normal spindown time for the drive (the drive
> does _start_ to spin down, after all, before it gets kicked back into
> full gear).
>
>> Both udisks and hal poll CD-ROMs
>> every two seconds, so at first sight this looks slightly unrelated.
>> But those are the two that actually generate polling events. Does the
>> issue also go away after killing hald and udisks-daemon (but leaving
>> udevd running)?
>
> Neither hald nor udisks-daemon are even installed on the machine, let
> alone running. This occurs whilst running _nothing_ other than udevd
> (as well as during normal operation):
>
> boot with init=/bin/sh
>
> mount -t proc proc proc
> mount -t sysfs sysfs sys
> mount -t tmpfs udev dev
> modprobe sr-mod
>
> (insert cd: after a few seconds it spins down normally)
>
> udevd --daemon
> udevadm trigger
>
> (remove/insert cd: it never spins down; this is when I ran udevadm
> monitor)
>
> killall udevd
>
> (after a few seconds the cd spins down normally)
Sounds odd, that the kernel/the device seems to flip the media present
bit, and sends events for that after every access.
Does cdrom_id work as expected otherwise? What does:
/lib/udev/cdrom_id --debug /dev/sr0
print?
Does running cdrom_id spin up the drive?
There is a call to /sbin/blkid in:
/lib/udev/rules.d/60-persistent-storage.rules
with:
KERNEL="sr*", IMPORT{program}="/sbin/blkid ...
If you comment that out, does the issue go away?
Kay
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox