udev cdrom_id rules prevent unmounted CD from spinning down

udev cdrom_id rules prevent unmounted CD from spinning down

[Nick Bowler]

Please CC me as I am not subscribed to the list.

The cdrom_id udev rules seem to be preventing the cdrom drive on my
laptop from spinning down.  Upon inserting a disk, it will spin up
to full speed, then the motor will turn off.  Before the disk stops
completely, however, it will spin right up again, then begin to stop,
then spin up, then begin to stop, ad infinitum.

This only occurs whilst no filesystem is mounted off the device, and
deleting /lib/udev/rules.d/60-cdrom_id.rules solves the problem, at
least until the next time udev gets updated.

My laptop is a ThinkPad T500, which has a SATA cdrom drive attached to
an Intel ICH9M/M-E SATA AHCI controller.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

On May 13, Nick Bowler <nbowler@elliptictech.com> wrote:

> The cdrom_id udev rules seem to be preventing the cdrom drive on my
Which udev release are you using?

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Nick Bowler]

On 18:27 Thu 13 May     , Marco d'Itri wrote:
> On May 13, Nick Bowler <nbowler@elliptictech.com> wrote:
> 
> > The cdrom_id udev rules seem to be preventing the cdrom drive on my
> Which udev release are you using?

I was using 151, but I just upgraded to 154 and the problem persists.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

On Thu, May 13, 2010 at 22:13, Nick Bowler <nbowler@elliptictech.com> wrote:
> On 18:27 Thu 13 May     , Marco d'Itri wrote:
>> On May 13, Nick Bowler <nbowler@elliptictech.com> wrote:
>>
>> > The cdrom_id udev rules seem to be preventing the cdrom drive on my
>> Which udev release are you using?
>
> I was using 151, but I just upgraded to 154 and the problem persists.

Does:
  udevadm monitor
print something?

Does killing udevd changes the issue?

Kay

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Nick Bowler]

On 23:27 Thu 13 May     , Kay Sievers wrote:
> On Thu, May 13, 2010 at 22:13, Nick Bowler <nbowler@elliptictech.com> wrote:
> > On 18:27 Thu 13 May     , Marco d'Itri wrote:
> >> On May 13, Nick Bowler <nbowler@elliptictech.com> wrote:
> >>
> >> > The cdrom_id udev rules seem to be preventing the cdrom drive on my
> >> Which udev release are you using?
> >
> > I was using 151, but I just upgraded to 154 and the problem persists.
> 
> Does:
>   udevadm monitor
> print something?

Yes (copied by hand):

KERNEL[1273786356.346839] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV  [1273786356.352880] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
KERNEL[1273786356.357396] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
UDEV  [1273786356.361771] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0 (scsi)
UDEV  [1273786356.595945] change /devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sr0 (block)
KERNEL[1273786361.162051] 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)

and it spews out a bunch like this every time the disk spins back up.

> Does killing udevd changes the issue?

Yes, after killing udevd the disk stops spinning.

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Martin Pitt]

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. 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)?

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Nick Bowler]

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)

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Nick Bowler]

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/)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Nick Bowler]

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: ACTION­d
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/)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Nicolas Thomas Bowler]

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)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Nick Bowler]

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/)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Nick Bowler]

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/)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Tejun Heo]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Tejun Heo]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Nick Bowler]

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/)

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Tejun Heo]

(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

[PATCH #upstream-fixes] libata: disable ATAPI AN by default

[Tejun Heo]

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;

Re: udev cdrom_id rules prevent unmounted CD from spinning down

[Kay Sievers]

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

Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default

[Jeff Garzik]

On 05/19/2010 09:38 AM, Tejun Heo wrote:
> 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).

Windows completely disables AN?

Or do we simply need to be less naive about _delivery_ of AN's?

	Jeff

Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default

[Tejun Heo]

Hello,

On 05/19/2010 06:14 PM, Jeff Garzik wrote:
> Windows completely disables AN?
> 
> Or do we simply need to be less naive about _delivery_ of AN's?

I think we first need to verify what the event is about before
delivering it to userland; IOW, it should kick a full polling op.  The
problem is the same with periodic polling.  Windows does it with
single command but we can't do that from userland as open() involves
issuing more commands.  That discrepancy is basically we're having all
these problems with periodic polling and AN infinite looping.

Hardware vendors don't consider cases where their devices are hit with
a series of commands periodically or after raising an AN event.  We
have quite a few drives which just die after being hit repeatedly with
media presence polling commands and this one is causing infinite loop
by re-raising AN.

So, until we can replicate the windows behavior (which actually is
pretty reasonable - just use single GET_CONFIGURATION call for polling
and status check), I think it's wiser to disable AN.

Thanks.

-- 
tejun

Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default

[Nick Bowler]

On 15:38 Wed 19 May     , Tejun Heo wrote:
> 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.

Works here, drive now spins down properly.

Tested-By: Nick Bowler <nbowler@draconx.ca>

-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default

[Robert Hancock]

On 05/19/2010 10:53 AM, Tejun Heo wrote:
> Hello,
>
> On 05/19/2010 06:14 PM, Jeff Garzik wrote:
>> Windows completely disables AN?
>>
>> Or do we simply need to be less naive about _delivery_ of AN's?
>
> I think we first need to verify what the event is about before
> delivering it to userland; IOW, it should kick a full polling op.  The
> problem is the same with periodic polling.  Windows does it with
> single command but we can't do that from userland as open() involves
> issuing more commands.  That discrepancy is basically we're having all
> these problems with periodic polling and AN infinite looping.
>
> Hardware vendors don't consider cases where their devices are hit with
> a series of commands periodically or after raising an AN event.  We
> have quite a few drives which just die after being hit repeatedly with
> media presence polling commands and this one is causing infinite loop
> by re-raising AN.
>
> So, until we can replicate the windows behavior (which actually is
> pretty reasonable - just use single GET_CONFIGURATION call for polling
> and status check), I think it's wiser to disable AN.

There are also some drives where AN is just broken - I have a Lite-ON 
DH-401S BD-ROM drive which raises AN on opening the tray, but not on 
closing with media inserted.

I don't know if Windows is using AN at all yet or not. Seems like a lot 
of drives aren't tested well with it though.

Re: [PATCH #upstream-fixes] libata: disable ATAPI AN by default

[Jeff Garzik]

On 05/19/2010 09:38 AM, Tejun Heo wrote:
> 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(-)

applied