You are not logged in.

#1 2012-03-26 01:05:28

medianmajik
Member
Registered: 2010-05-27
Posts: 53

Udev Error on Eee 701

This is on a Eee 701 4g running Kernel-eee.

Sun Mar 25 11:09:29 2012: udevd[89]: error opening ATTR{/sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/sda5/queue/rotational} for writing: No such file or directory

You can find the complete output from /log/boot here.  Thanks!


One thing at a time

Offline

#2 2012-03-26 01:16:38

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: Udev Error on Eee 701

disks (e.g. /dev/sda) have a queue/rotational attribute in sysfs, not partitions (e.g. /dev/sda5). Whatever rule you've added to /etc/udev/rules.d is erroring out because its wrong.

Offline

#3 2012-03-27 03:14:13

medianmajik
Member
Registered: 2010-05-27
Posts: 53

Re: Udev Error on Eee 701

/etc/udev/rules.d is an empty directory for me, with no hidden files.  Perhaps it is related to a bug in kernel-eee, which I recently upgraded


One thing at a time

Offline

#4 2012-03-27 04:03:27

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: Udev Error on Eee 701

...but you've had the same error in your log since mid-February. Might want to check /lib/udev/rules.d as well. Make sure all the files in the directory are owned by a package.

Offline

#5 2012-03-27 19:25:00

medianmajik
Member
Registered: 2010-05-27
Posts: 53

Re: Udev Error on Eee 701

falconindy wrote:

Might want to check /lib/udev/rules.d as well. Make sure all the files in the directory are owned by a package.

Thanks, /lib/udev/rules.d contains lots of rules.  I'm reading the wiki and man udev to learn more.

$ ls -la /lib/udev/rules.d/
total 160
drwxr-xr-x 2 root root  4096 Mar 25 10:53 .
drwxr-xr-x 5 root root  4096 Mar 25 07:30 ..
-r--r--r-- 1 root root  6539 Mar 14 15:26 10-dm.rules
-r--r--r-- 1 root root  1286 Jul  7  2010 11-dm-lvm.rules
-r--r--r-- 1 root root  1446 Mar 14 15:26 13-dm-disk.rules
-rw-r--r-- 1 root root    60 Dec 20 10:01 40-hpet-permissions.rules
-rw-r--r-- 1 root root   764 Mar 14 18:25 42-qemu-usb.rules
-rw-r--r-- 1 root root  3660 Mar 14 18:25 50-udev-default.rules
-rw-r--r-- 1 root root   646 Mar 14 18:25 60-cdrom_id.rules
-rw-r--r-- 1 root root  1060 Mar 13 13:05 60-pcmcia.rules
-rw-r--r-- 1 root root   616 Mar 14 18:25 60-persistent-alsa.rules
-rw-r--r-- 1 root root  2400 Mar 14 18:25 60-persistent-input.rules
-rw-r--r-- 1 root root   947 Mar 14 18:25 60-persistent-serial.rules
-rw-r--r-- 1 root root  5968 Mar 14 18:25 60-persistent-storage.rules
-rw-r--r-- 1 root root  1420 Mar 14 18:25 60-persistent-storage-tape.rules
-rw-r--r-- 1 root root   769 Mar 14 18:25 60-persistent-v4l.rules
-rw-r--r-- 1 root root   166 Mar 14 18:25 61-accelerometer.rules
-rw-r--r-- 1 root root   561 Mar 25 01:28 61-eee-ssd.rules
-rw-r--r-- 1 root root  2301 Jan 20 05:38 64-md-raid.rules
-rw-r--r-- 1 root root   174 Mar  9 09:13 69-xorg-vmmouse.rules
-rw-r--r-- 1 root root  2569 Mar 14 18:25 70-udev-acl.rules
-rw-r--r-- 1 root root   570 Mar 14 18:25 75-net-description.rules
-rw-r--r-- 1 root root   255 Mar 14 18:25 75-probe_mtd.rules
-rw-r--r-- 1 root root   570 Mar 14 18:25 75-tty-description.rules
-rw-r--r-- 1 root root  4174 Mar 14 18:25 78-sound-card.rules
-rw-r--r-- 1 root root   565 Mar 14 18:25 80-drivers.rules
-rw-r--r-- 1 root root  9507 Mar  3 06:08 80-udisks.rules
-rw-r--r-- 1 root root   335 Feb  9 09:54 85-regulatory.rules
-rw-r--r-- 1 root root   131 Mar  1 23:35 90-alsa-restore.rules
-r--r--r-- 1 root root   492 Nov  1  2009 95-dm-notify.rules
-rw-r--r-- 1 root root  3328 Mar 14 18:25 95-keyboard-force-release.rules
-rw-r--r-- 1 root root 11643 Mar 14 18:25 95-keymap.rules
-rw-r--r-- 1 root root   155 Mar 14 18:25 95-udev-late.rules

So the number at the start of each file denotes the program that owns that rule?  Example: 95-keymap.rules

Edit: This looks useful

$ less /lib/udev/rules.d/61-eee-ssd.rules
# Ensure our SSD drive is set up as non-rotational
# These rules are derived from the output of a commands such as:
#   udevadm info -a --name /dev/sda
#   udevadm info --query=property --name=/dev/sda
# Where /dev/sda is the SSD device. SUBSYSTEM, etc. type rules come from the
# former while ENV property matches are derived from the latter.

# Eee 701
ACTION=="add" SUBSYSTEM=="block", ENV{ID_MODEL}=="SILICONMOTION_SM223AC", ATTR{queue/rotational}="0"
# Eee 901
ACTION=="add" SUBSYSTEM=="block", ENV{ID_MODEL}=="ASUS-PHISON_SSD", ATTR{queue/rotational}="0"
$ udevadm info -a --name /dev/sda5

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/sda5':
    KERNEL=="sda5"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{partition}=="5"
    ATTR{start}=="5863788"
    ATTR{size}=="1943802"
    ATTR{ro}=="0"
    ATTR{alignment_offset}=="0"
    ATTR{discard_alignment}=="0"
    ATTR{stat}=="     187      512     1724      296        7        4       58      331        0      497      627"
    ATTR{inflight}=="       0        0"

  looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda':
    KERNELS=="sda"
    SUBSYSTEMS=="block"
    DRIVERS==""
    ATTRS{range}=="16"
    ATTRS{ext_range}=="256"
    ATTRS{removable}=="0"
    ATTRS{ro}=="0"
    ATTRS{size}=="7815024"
    ATTRS{alignment_offset}=="0"
    ATTRS{discard_alignment}=="0"
    ATTRS{capability}=="50"
    ATTRS{stat}=="    3226      626    89634     5767      339       59     4010   126138        0    13567   131887"
    ATTRS{inflight}=="       0        0"
    ATTRS{events}==""
    ATTRS{events_async}==""
    ATTRS{events_poll_msecs}=="-1"

  looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0':
    KERNELS=="1:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{device_blocked}=="0"
    ATTRS{type}=="0"
    ATTRS{scsi_level}=="6"
    ATTRS{vendor}=="ATA     "
    ATTRS{model}=="SILICONMOTION SM"
    ATTRS{rev}=="n/a "
    ATTRS{state}=="running"
    ATTRS{timeout}=="30"
    ATTRS{iocounterbits}=="32"
    ATTRS{iorequest_cnt}=="0xe2d"
    ATTRS{iodone_cnt}=="0xe2d"
    ATTRS{ioerr_cnt}=="0x2"
    ATTRS{evt_media_change}=="0"
    ATTRS{queue_depth}=="1"
    ATTRS{queue_type}=="none"

  looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0':
    KERNELS=="target1:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2/host1':
    KERNELS=="host1"
    SUBSYSTEMS=="scsi"
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2':
    KERNELS=="ata2"
    SUBSYSTEMS==""
    DRIVERS==""

  looking at parent device '/devices/pci0000:00/0000:00:1f.2':
    KERNELS=="0000:00:1f.2"
    SUBSYSTEMS=="pci"
    DRIVERS=="ata_piix"
    ATTRS{vendor}=="0x8086"
    ATTRS{device}=="0x2653"
    ATTRS{subsystem_vendor}=="0x1043"
    ATTRS{subsystem_device}=="0x82d8"
    ATTRS{class}=="0x010180"
    ATTRS{irq}=="19"
    ATTRS{local_cpus}=="1"
    ATTRS{local_cpulist}=="0"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}==""

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

So, could you explain a little more on why using a partition (sda5) in udev rules relates to sysfs.  Thanks for the assistance!

Last edited by medianmajik (2012-03-27 19:39:46)


One thing at a time

Offline

#6 2012-03-27 21:37:53

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: Udev Error on Eee 701

So the number at the start of each file denotes the program that owns that rule?  Example: 95-keymap.rules

No, pacman -Qo tells you who owns a file.. the number to the left is strictly for ordering the files

Edit: This looks useful

You're triggering the rule for every partition of the given block device, when you only want to trigger for the disk itself.. however, why do you need this rule at all? If the disk isn't being detected properly as non-rotational, its a kernel bug. If for some reason  you insist on keeping the rules, change them so they only fire for disks...

ACTION=="add", KERNEL="sd[a-z]", SUBSYSTEM=="block", ENV{ID_MODEL}=="SILICONMOTION_SM223AC", ATTR{queue/rotational}="0"

So, could you explain a little more on why using a partition (sda5) in udev rules relates to sysfs.  Thanks for the assistance!

...because that's what udev mainly operates on. You can think of /dev as being an abstraction of what exists in /sys. An entry exist in sysfs for all of your hardware, but there may not necessarily be a node for it in /dev.

Offline

Board footer

Powered by FluxBB