IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
On Sun, Nov 6, 2011 at 21:45, William Hubbs <w.d.hubbs@gmail.com> wrote:
> someone on gentoo just reported to me that the following rule has been
> deleted from udev-174, which is leaving his optical devices in the
> standard "disk" group. He does not want to add his users to this group.
On Tue, Aug 2, 2011 at 10:56, Thomas Bächler <thomas@archlinux.org> wrote:
> Commit c49df20758 prevented udev from
> creating broken symlinks for bluetooth hid devices. Unfortunately,
> it also removed the ID_INPUT=1 and ID_INPUT_{KEY,MOUSE}=1 properties
> from those devices. Xorg relies on these properties for cold- and
> hotplugging of input devices.
When the CD tray door is locked and the hardware eject button is pressed, newer
kernels (2.6.38+) will send out a change event with a DISK_EJECT_REQUEST==1
property. Do not run cdrom_id and blkid in this case, as the media state and
contents does not change, and this only needlessly spins up the drive again
right before ejection.
If a USB device is marked as removable, it is often a SATA/PATA disk
in an enclosure (note that flash card readers and usb storage sticks
are always marked as removable). In this case, try running ata_id
(which sends ATA commands wrapped in SCSI ATA PASS THROUGH commands)
to get information about the disk. If this fails, just fall back to
running usb_id since it could be the device isn't an ATA device at
all or the device doesn't have a SAT layer.
This extra information is nice to have as it indicates if it is
suitable to send e.g. SMART commands to the disk, whether the disk
supports power management and so on. Additionally, the VPD and serial
number returned by ata_id is usually more accurate as it stems from
the disk itself instead of the enclosure.
Note that udisks has been doing this for a while
KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="usb", ENV{DEVTYPE}=="disk", IMPORT{program}="udisks-probe-ata-smart $tempnode"
so this change shouldn't be too disruptive (udisks-probe-ata-smart
also sends ATA commands via the ATA PASS THROUGH command).
Signed-off-by: David Zeuthen <davidz@redhat.com>
Commit 5e9eb156c added new symlinks for multi-interface USB input devices.
However, we do not actually need the one for interface number "00", as we
already have the symlink without the interface number.
Create /dev/input/by-id symlinks containing the USB interface number so that
each interface in a multi-interface USB input device gets its own symlink.
Thanks to a7x <ubuntu-a7x@scientician.org>!
https://launchpad.net/bugs/626449
These patches enable usb autosuspend for the qemu emulated HID devices.
This reduces the cpu load for idle guests with a hid device attached
because the linux kernel will suspend the usb bus then and qemu can stop
running a 1000 Hz to emulate the (active) UHCI controller.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The bsg devices node are created after the LUN, so we fail in the
hotplug case, but succeed at coldplug, and create inconsistent data
that way.
The bsg device event order will need to be sorted out, by changing the
kernel.
The major benefit here, is that we get the ATAPI device serial
number. With SCSI ID we didn't get this since it's not part of the
SCSI INQUIRY command. Specifically this means that we get symlinks to
empty optical drives, e.g.
/dev/disk/by-id/ata-VBOX_CD-ROM_VB2-01700376
which we didn't get earlier. So this is a major win.
Also make ata_id work on CD-ROM devices when using /dev/bsg nodes so
this works on both the scsi_device as well as the block device. We do
this, basically, by issuing the ATA IDENTIFY PACKET DEVICE command
instead of the ATA IDENTIFY command. We also use 16-byte pass-through
ATA passthrough instead of 12-byte passthrough to avoid clashing with
the MMC BLANK command.
This means that we get this output
# udevadm info -q all -p /sys/devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
P: /devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
E: DEVTYPE=scsi_device
E: DRIVER=sr
E: MODALIAS=scsi:t-0x05
E: SUBSYSTEM=scsi
E: ID_ATA=1
E: ID_TYPE=cd
E: ID_BUS=ata
E: ID_MODEL=VBOX_CD-ROM
E: ID_MODEL_ENC=VBOX\x20CD-ROM\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x 20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=1.0
E: ID_SERIAL=VBOX_CD-ROM_VB2-01700376
E: ID_SERIAL_SHORT=VB2-01700376
instead of just
# udevadm info -q all -p /sys/devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
P: /devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:01.1/host3/target3:0:0/3:0:0:0
E: DEVTYPE=scsi_device
E: DRIVER=sr
E: MODALIAS=scsi:t-0x05
E: SUBSYSTEM=scsi
E: ID_SCSI=1
E: ID_VENDOR=VBOX
E: ID_VENDOR_ENC=VBOX\x20\x20\x20\x20
E: ID_MODEL=CD-ROM
E: ID_MODEL_ENC=CD-ROM\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=1.0
E: ID_TYPE=cd
Signed-off-by: David Zeuthen <davidz@redhat.com>
In a multi-initiator setup, the HBA may very well export a SCSI device
for a device that another initiator has already logged into. But since
another initiator has already logged in, the kernel will not create a
block device.
Note that this is also the case for some RAID HBAs - for example, the
LSI 1068 series cards will export a SCSI device for a disk that is in
use by the HBAs RAID engine (no block device will be created here).
Running scsi_id and ata_id on the actual SCSI device means that we can
inquire the capabilities of the device. For example, we can check
whether ID_ATA_FEATURE_SET_SMART and ID_ATA_FEATURE_SET_SMART_ENABLED
is set and, if so, periodically poll the SMART status of the
disk. Even when other initiators has claimed the disk and if the disk
is in use by the RAID engine of the HBA.
Note that we run scsi_id and ata_id on /dev/bsg/* nodes - this is safe
to do because the scsi core guarantees that the bsg device has been
created before the actual add uevent for the scsi_device is emitted.
Since the block device is a direct child of the scsi_device we can
avoid running scsi_id and ata_id again by simply importing the
resulting ID_* properties from the parent.
Signed-off-by: David Zeuthen <davidz@redhat.com>
1. IIDC cameras from Point Grey use the vendor OUI as Specifier_ID
instead of the 1394 TA's OUI but are otherwise fully compliant to the
IIDC spec. Their device files should be accessible like those of any
other IIDC cameras.
2. Originally, the Software_Version of devices that implement FCP
(IEC 61883-1 Function Control Protocol) was meant to be a bitmap of all
command sets that an FCP capable unit supports. Bitmap flags are
defined for AV/C, CAL, EHS, HAVi, and vendor unique command sets.
Software_Version was revised to be a simple identifier instead, and
devices that support several command sets were meant to instantiate one
unit directory for each command set. Still, some devices with the flags
for AV/C and vendor unique command sets combined were released (but
apparently no devices with any other flag combinations). These rare but
existing AV/C + vendor unique devices need to be accessible just like
plain AV/C devices.
Side notes:
- Many AV/C devices make use of the Vendor Dependent AV/C command, but
this is unrelated to vendor unique FCP command sets.
- Here are all standardized FireWire protocol identifiers that I know
of, listed as Specifier_ID:Software_Version | specifier | protocol.
0x00005e:0x000001 | IANA | IPv4 over 1394 (RFC 2734)
0x00005e:0x000002 | IANA | IPv6 over 1394 (RFC 3146)
0x00609e:0x010483 | INCITS | SBP-2 (or SCSI command sets over SBP-3)
0x00609e:0x0105bb | INCITS | AV/C over SBP-3
0x00a02d:0x010001 | 1394 TA | AV/C (over FCP)
0x00a02d:0x010002 | 1394 TA | CAL
0x00a02d:0x010004 | 1394 TA | EHS
0x00a02d:0x010008 | 1394 TA | HAVi
0x00a02d:0x014000 | 1394 TA | Vendor Unique
0x00a02d:0x014001 | 1394 TA | Vendor Unique and AV/C (over FCP)
0x00a02d:0x000100 | 1394 TA | IIDC 1.04
0x00a02d:0x000101 | 1394 TA | IIDC 1.20
0x00a02d:0x000102 | 1394 TA | IIDC 1.30
0x00a02d:0x0A6BE2 | 1394 TA | DPP 1.0
0x00a02d:0x4B661F | 1394 TA | IICP 1.0
For now we are only interested in udev rules for AV/C and IIDC.
Reported-by: Damien Douxchamps <ddsf@douxchamps.net> (Point Grey IIDC ID)
Reported-by: Clemens Ladisch <clemens@ladisch.de> (AV/C + vendor unique ID)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
