* kmod 8
From: Lucas De Marchi @ 2012-04-19 14:34 UTC (permalink / raw)
To: linux-modules, LKML, linux-hotplug
kmod 8 is out:
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-8.tar.xz
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-8.tar.sign
Very small, bug-fix release, nothing new. Last release I changed my
laptop, which caused a wrong setup and kmod 7 got out with docs
disabled. kmod 8 fixes as well.
Check NEWS file for more information.
Shortlog is below.
Lucas De Marchi
--
Dave Reisner (1):
modprobe: handle -ENOENT return from init_module
Elan Ruusamäe (1):
modprobe: fix typo in config dump: option->options
Kay Sievers (1):
doc: silent man page generation and fix gtk-doc warnings
Lucas De Marchi (4):
README: note that there are more files to read
TODO: add item to implement actions in kmod
doc: remove links to NULL going nowhere
kmod 8
^ permalink raw reply
* Re: /dev/shm and /dev/pts not been created by devtmpfs or udev
From: F. Heitkamp @ 2012-04-19 3:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F8EB679.7080107@ameritech.net>
On 04/18/12 10:37, Kay Sievers wrote:
> On Wed, Apr 18, 2012 at 14:41, F. Heitkamp<heitkamp@ameritech.net> wrote:
>> I am using kernel 3.3.2 and udev 182.
>> I have TMPFS, DEVTMPFS, DEVTMPFS_MOUNT and SHMEN all yes.
>>
>> However after the machine boots there is no /dev/shm or /dev/pts in the
>> /dev/ directory and udev does not create them even though they are in the
>> /usr/libexec/udev/devices directory.
> Udev uses /lib/udev/. never libexec/, (/usr)/lib/udev/ is a de-facto
> API and should not be changed.
>
> "strace udevd" might show what goes wrong on your box.
>
> Kay
> --
> 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
>
Sorry. The devices directory is "/lib/udev/devices".
udev seems to be mostly working AFAICT. When I plug/unplug USB or
firewire, I can see events being processed with udevadm monitor.
There is no shm or pts directory shown in /proc/devices. Should there be?
There is also lots of information in the /run directory tree.
Fred
^ permalink raw reply
* Re: "udevadm info --attribute-walk --path=/block/sda" doesn't show parents
From: Kay Sievers @ 2012-04-18 22:41 UTC (permalink / raw)
To: Chris Friesen; +Cc: LKML, linux-hotplug
In-Reply-To: <4F8F3C74.7040000@genband.com>
On Thu, Apr 19, 2012 at 00:13, Chris Friesen <chris.friesen@genband.com> wrote:
> On 04/18/2012 03:42 PM, Chris Friesen wrote:
>>
>> I have a 2.6.34.10-based kernel with udev-161 (also tested with udevadm from udev-173).
>>
>> When I run "udevadm info --attribute-walk --path=/block/sda" it just shows the device
>> itself, and doesn't walk the whole chain showing the parents.
>>
>> Is there anything I can do, or am I caught with a kernel that isn't properly supported?
>> I'm not subscribed to the hotplug list, so cc'ing me would be appreciated.
>>
>> I don't know what's causing the problem, but I find it suspicious that /sys/block/sda
>> is a directory rather than a symlink like it is on my 2.6.35.14 laptop. I'm poking
>> around in the udevadm code now.
>
> Looking at the udevadm code led me to the following:
>
> On the problematic 2.6.34 machine:
>
> root@typhoon-base-unit0:/root> ls -l /sys/dev/block/
> <snip>
> lrwxrwxrwx 1 root root 0 Apr 18 14:34 8:0 -> ../../block/sda
>
> On my 2.6.35 machine:
>
> [cfriesen@blah udev-173]$ ls -l /sys/dev/block/
> <snip>
> lrwxrwxrwx. 1 root root 0 Apr 18 15:54 8:0 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
>
> So where do I go from here? Is there a simple kernel change to make my 2.6.34
> kernel behave more like the more recent one? Would an older version of udev be
> able to parse my 2.6.34 /sys directory properly, or do I need to figure out a
> way to parse /sys manually?
On old kernels, the chain of parent devices was not always properly
exported, because the "struct class_device" created all device
directories and spread spread them all over the the /sys/class tree.
There was a "device" link created at these disconnected device
directories, which udev tried to follow to find the parents.
We cleaned that up that mess, by having a single and unified tree in
/sys/devices, and /sys/class and /sys/bus just have symlinks pointing
into that tree. "Hierarchy" vs. "classification" are properly
separated that way.
For a while the CONFIG_SYSFS_DEPRECATED controlled the behaviour, you
might check if that is available in your kernel and can be turned off
to switch to the unified hierarchy. I kind of lost track which kernel
versions did what here.
In general, if you need the more recent udev tools to work regarding
the chain of parents, which "udevadm info --attribute-walk" uses, you
need a newer kernel, which exports that natively. There is no support
for the "device" link in newer versions of udev. We only really
supports it the other way around, which is new kernels on older
userspace. So you either use a newer kernel for a new udev, or also
stick with the old udev if you are stuck with that old kernel.
Or alternatively, you patch-in the support for the old "struct
class_device" stuff into the curent udev, to support older kernels; it
should be fairly simple. If that's what you look for, I can look up
the stuff you need to add, just let me know.
Kay
^ permalink raw reply
* Re: "udevadm info --attribute-walk --path=/block/sda" doesn't show parents
From: Chris Friesen @ 2012-04-18 22:13 UTC (permalink / raw)
To: LKML, linux-hotplug
In-Reply-To: <4F8F3563.9020701@genband.com>
On 04/18/2012 03:42 PM, Chris Friesen wrote:
>
> I have a 2.6.34.10-based kernel with udev-161 (also tested with udevadm from udev-173).
>
> When I run "udevadm info --attribute-walk --path=/block/sda" it just shows the device
> itself, and doesn't walk the whole chain showing the parents.
>
> Is there anything I can do, or am I caught with a kernel that isn't properly supported?
> I'm not subscribed to the hotplug list, so cc'ing me would be appreciated.
>
>
> I don't know what's causing the problem, but I find it suspicious that /sys/block/sda
> is a directory rather than a symlink like it is on my 2.6.35.14 laptop. I'm poking
> around in the udevadm code now.
Looking at the udevadm code led me to the following:
On the problematic 2.6.34 machine:
root@typhoon-base-unit0:/root> ls -l /sys/dev/block/
<snip>
lrwxrwxrwx 1 root root 0 Apr 18 14:34 8:0 -> ../../block/sda
On my 2.6.35 machine:
[cfriesen@blah udev-173]$ ls -l /sys/dev/block/
<snip>
lrwxrwxrwx. 1 root root 0 Apr 18 15:54 8:0 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
So where do I go from here? Is there a simple kernel change to make my 2.6.34
kernel behave more like the more recent one? Would an older version of udev be
able to parse my 2.6.34 /sys directory properly, or do I need to figure out a
way to parse /sys manually?
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: "udevadm info --attribute-walk --path=/block/sda" doesn't show parents
From: Chris Friesen @ 2012-04-18 21:46 UTC (permalink / raw)
To: LKML, linux-hotplug
In-Reply-To: <4F8F3563.9020701@genband.com>
On 04/18/2012 03:42 PM, Chris Friesen wrote:
>
> I have a 2.6.34.10-based kernel with udev-161 (also tested with udevadm from udev-173).
>
> When I run "udevadm info --attribute-walk --path=/block/sda" it just shows the device
> itself, and doesn't walk the whole chain showing the parents.
>
> Is there anything I can do, or am I caught with a kernel that isn't properly supported?
> I'm not subscribed to the hotplug list, so cc'ing me would be appreciated.
>
>
> I don't know what's causing the problem, but I find it suspicious that /sys/block/sda
> is a directory rather than a symlink like it is on my 2.6.35.14 laptop. I'm poking
> around in the udevadm code now.
>
>
> Some possibly-useful information:
I forgot to include this....this might be useful as well:
root@typhoon-base-unit0:/root> udevadm info -q path -n /dev/sda
/block/sda
For comparison, on my 2.6.35.14 laptop I get:
[cfriesen@blah log]$ udevadm info -q path -n /dev/sda
/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* "udevadm info --attribute-walk --path=/block/sda" doesn't show parents
From: Chris Friesen @ 2012-04-18 21:42 UTC (permalink / raw)
To: LKML, linux-hotplug
I have a 2.6.34.10-based kernel with udev-161 (also tested with udevadm from udev-173).
When I run "udevadm info --attribute-walk --path=/block/sda" it just shows the device
itself, and doesn't walk the whole chain showing the parents.
Is there anything I can do, or am I caught with a kernel that isn't properly supported?
I'm not subscribed to the hotplug list, so cc'ing me would be appreciated.
I don't know what's causing the problem, but I find it suspicious that /sys/block/sda
is a directory rather than a symlink like it is on my 2.6.35.14 laptop. I'm poking
around in the udevadm code now.
Some possibly-useful information:
root@typhoon-base-unit0:/root> udevadm info --attribute-walk --path=/block/sda
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 '/block/sda':
KERNEL="sda"
SUBSYSTEM="block"
DRIVER=""
ATTR{range}="16"
ATTR{ext_range}="256"
ATTR{removable}="0"
ATTR{ro}="0"
ATTR{size}="586072368"
ATTR{alignment_offset}="0"
ATTR{discard_alignment}="0"
ATTR{capability}="50"
ATTR{stat}=" 12 3 80 50 0 0 0 0 0 50 50"
ATTR{inflight}=" 0 0"
root@typhoon-base-unit0:/root> udevadm info -p /block/sda -q all
P: /block/sda
N: sda
S: scsi/host/bus/target/lun/disc
S: discs/disc0/disc
S: block/8:0
S: disk/by-id/scsi-1ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599
E: UDEV_LOG=3
E: DEVPATH=/block/sda
E: SUBSYSTEM=block
E: DEVNAME=sda
E: ID_SCSI=1
E: ID_VENDOR=ATA
E: ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20
E: ID_MODEL=WDC_WD3000BLHX-0
E: ID_MODEL_ENC=WDC\x20WD3000BLHX-0
E: ID_REVISION\x04.0
E: ID_TYPE=disk
E: ID_SERIAL\x1aTA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599
E: ID_SERIAL_SHORT=ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599
E: ID_SCSI_SERIAL=WD-WX61E41PY599
E: ID_BUS=scsi
E: MAJOR=8
E: MINOR=0
E: DEVTYPE=disk
E: PHYSDEVPATH=/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0
E: PHYSDEVBUS=scsi
E: PHYSDEVDRIVER=sd
E: DEVLINKS=/dev/scsi/host/bus/target/lun/disc /dev/discs/disc0/disc /dev/block/8:0 /dev/disk/by-id/scsi-1ATA_WDC_WD3000BLHX-01V7BV0_WD-WX61E41PY599
root@typhoon-base-unit0:/root> ls -l /sys/block/sda
total 0
-r--r--r-- 1 root root 4096 Apr 18 14:16 alignment_offset
lrwxrwxrwx 1 root root 0 Apr 18 14:16 bdi -> ../../class/bdi/8:0
-r--r--r-- 1 root root 4096 Apr 18 14:16 capability
-r--r--r-- 1 root root 4096 Apr 18 14:16 dev
lrwxrwxrwx 1 root root 0 Apr 18 14:16 device -> ../../devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0
-r--r--r-- 1 root root 4096 Apr 18 14:16 discard_alignment
-r--r--r-- 1 root root 4096 Apr 18 14:16 ext_range
drwxr-xr-x 2 root root 0 Apr 18 14:16 holders
-r--r--r-- 1 root root 4096 Apr 18 14:16 inflight
drwxr-xr-x 2 root root 0 Apr 18 14:16 power
drwxr-xr-x 3 root root 0 Apr 18 14:16 queue
-r--r--r-- 1 root root 4096 Apr 18 14:16 range
-r--r--r-- 1 root root 4096 Apr 18 14:16 removable
-r--r--r-- 1 root root 4096 Apr 18 14:16 ro
drwxr-xr-x 4 root root 0 Apr 18 14:16 sda1
drwxr-xr-x 4 root root 0 Apr 18 14:16 sda2
-r--r--r-- 1 root root 4096 Apr 18 14:16 size
drwxr-xr-x 2 root root 0 Apr 18 14:16 slaves
-r--r--r-- 1 root root 4096 Apr 18 14:16 stat
lrwxrwxrwx 1 root root 0 Apr 18 14:16 subsystem -> ../../block
-rw-r--r-- 1 root root 4096 Apr 18 14:16 uevent
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: /dev/shm and /dev/pts not been created by devtmpfs or udev
From: Kay Sievers @ 2012-04-18 14:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F8EB679.7080107@ameritech.net>
On Wed, Apr 18, 2012 at 14:41, F. Heitkamp <heitkamp@ameritech.net> wrote:
> I am using kernel 3.3.2 and udev 182.
> I have TMPFS, DEVTMPFS, DEVTMPFS_MOUNT and SHMEN all yes.
>
> However after the machine boots there is no /dev/shm or /dev/pts in the
> /dev/ directory and udev does not create them even though they are in the
> /usr/libexec/udev/devices directory.
Udev uses /lib/udev/. never libexec/, (/usr)/lib/udev/ is a de-facto
API and should not be changed.
"strace udevd" might show what goes wrong on your box.
Kay
^ permalink raw reply
* Re: /dev/shm and /dev/pts not been created by devtmpfs or udev
From: Marco d'Itri @ 2012-04-18 13:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F8EB679.7080107@ameritech.net>
On Apr 18, "F. Heitkamp" <heitkamp@ameritech.net> wrote:
> Any suggestions?
Please ask on the appropriate users support forum/mailing list/newsgroup
/whaterver for your distribution.
--
ciao,
Marco
^ permalink raw reply
* /dev/shm and /dev/pts not been created by devtmpfs or udev
From: F. Heitkamp @ 2012-04-18 12:41 UTC (permalink / raw)
To: linux-hotplug
I am using kernel 3.3.2 and udev 182.
I have TMPFS, DEVTMPFS, DEVTMPFS_MOUNT and SHMEN all yes.
However after the machine boots there is no /dev/shm or /dev/pts in the
/dev/ directory and udev does not create them even though they are in
the /usr/libexec/udev/devices directory.
Any suggestions?
Fred
^ permalink raw reply
* udev: USB HID PM screws up logitech receiver
From: Manuel Lauss @ 2012-04-13 6:03 UTC (permalink / raw)
To: linux-hotplug
Hello,
I have a Logitech Bluetooth dongle, used in HID mode, which gets unusable on
recent kernels (3.4-rcX: the 'removable' attribute was added) due to autosuspend
being enabled on its internal hub ports (the last of rule 42-usb-hid-pm.rules),
see also a thread on linux-usb here:
http://marc.info/?l=linux-usb&m\x133380762425041&w=2
Please exclude this receiver from autosuspend, as it makes it unusable.
Thanks,
Manuel Lauss
Bus 004 Device 002: ID 046d:0b02 Logitech, Inc. BT Mini-Receiver (HID
proxy mode)
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 003: ID 046d:c70b Logitech, Inc. BT Mini-Receiver (HID
proxy mode)
Bus 004 Device 004: ID 046d:c70c Logitech, Inc. BT Mini-Receiver (HID
proxy mode)
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/5p, 12M
|__ Port 2: Dev 2, If 0, Class=hub, Driver=hub/3p, 12M
|__ Port 2: Dev 3, If 0, Class=HID, Driver=usbhid, 12M
|__ Port 3: Dev 4, If 0, Class=HID, Driver=usbhid, 12M
Bus 004 Device 002: ID 046d:0b02 Logitech, Inc. BT Mini-Receiver (HID
proxy mode)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0x0b02 BT Mini-Receiver (HID proxy mode)
bcdDevice 40.06
iManufacturer 1 Logitech
iProduct 2 Logitech BT Mini-Receiver
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0001 1x 1 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 3
wHubCharacteristic 0x0004
Ganged power switching
Compound device
Ganged overcurrent protection
bPwrOn2PwrGood 50 * 2 milli seconds
bHubContrCurrent 100 milli Ampere
DeviceRemovable 0x0c
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0103 power enable connect
Port 3: 0000.0103 power enable connect
Device Status: 0x0000
(Bus Powered)
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0001 1.1 root hub
bcdDevice 3.04
iManufacturer 3 Linux 3.4.0-rc2-00270-g00413fe ohci_hcd
iProduct 2 OHCI Host Controller
iSerial 1 0000:00:12.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 5
wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
bPwrOn2PwrGood 2 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0103 power enable connect
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Device Status: 0x0001
Self Powered
Bus 004 Device 003: ID 046d:c70b Logitech, Inc. BT Mini-Receiver (HID
proxy mode)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc70b BT Mini-Receiver (HID proxy mode)
bcdDevice 40.06
iManufacturer 1 Logitech
iProduct 2 Logitech BT Mini-Receiver
iSerial 3 00076146494E
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 RR40.06_B0077
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 98mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 59
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)
Bus 004 Device 004: ID 046d:c70c Logitech, Inc. BT Mini-Receiver (HID
proxy mode)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc70c BT Mini-Receiver (HID proxy mode)
bcdDevice 40.06
iManufacturer 1 Logitech
iProduct 2 Logitech BT Mini-Receiver
iSerial 3 00076146494E
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 RR40.06_B0077
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 98mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 226
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 5
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply
* Re: Inconsistences using GUdev.Client
From: David Zeuthen @ 2012-04-12 15:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABpL_NdACqSWGs+oepbR4KpeDWu5wBseWBKbwSb5mZ3vvpENKA@mail.gmail.com>
Hi,
On Thu, Apr 12, 2012 at 8:18 AM, Javier Hernández Antúnez
<jhernandez@emergya.com> wrote:
> 16:59 < tomeu> the problem is people doing things in _new_* that
> should be done instead in _init or _construct
> 16:59 < tomeu> jhernandez: it's a bug that should be reported
> 17:00 < tomeu> (in GUDev)
> 17:00 < jhernandez> tomeu: ACK
I think you are confused, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/gudev/gudevclient.c#n318
basically, what we do is this
GUdevClient *
g_udev_client_new (const gchar * const *subsystems)
{
return G_UDEV_CLIENT (g_object_new (G_UDEV_TYPE_CLIENT,
"subsystems", subsystems, NULL));
}
I think the python bindings are just buggy - probably they don't
support GStrv GObject properties very well.
David
^ permalink raw reply
* Inconsistences using GUdev.Client
From: Javier Hernández Antúnez @ 2012-04-12 12:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABpL_NdACqSWGs+oepbR4KpeDWu5wBseWBKbwSb5mZ3vvpENKA@mail.gmail.com>
Hi!
I've been porting a python application which uses gudev to use the new
gobject-introspection based bindings, but I encountered an issue. So,
I pulled udev from master and the issue was still there, so I went to
talk with some pygobject developers, and here's a retail of the
conversation.
16:12 < jhernandez> I'm using GUdev with pygobject
16:12 < jhernandez> and, I have some doubts regarding the way I'm using it
16:13 < jhernandez> with the old python-gudev, I was used to do like
this: client = gudev.Client(subsystems)
16:14 < jhernandez> using the gobject introspected bindings, I'm not
able to get my client object like I was used
16:14 < jhernandez> instead, I need to use the gudev.Client.new method
16:16 < jhernandez> should I report this as a bug? or it is my fault?
16:59 < tomeu> all GObjects should be instantiable with g_object_new
16:59 < tomeu> the problem is people doing things in _new_* that
should be done instead in _init or _construct
16:59 < tomeu> jhernandez: it's a bug that should be reported
17:00 < tomeu> (in GUDev)
17:00 < jhernandez> tomeu: ACK
JFYI, the full conversation log is here [1]
I think the final decision on this is up to udev/gudev developers, and
I'll try (with some help) to provide a patch if it is really needed.
My devel environment consists in:
- openSUSE 12.1 + Official updates
- udev pulled from master (182)
Best regards!
[1]: http://pastebin.com/js7rKh3J
--
Javier Hernández Antúnez
<jhernandez@emergya.com>
^ permalink raw reply
* Inconsistences using GUdev.Client
From: Javier Hernández Antúnez @ 2012-04-12 12:18 UTC (permalink / raw)
To: linux-hotplug
Hi!
I've been porting a python application which uses gudev to use the new
gobject-introspection based bindings, but I encountered an issue. So,
I pulled udev from master and the issue was still there, so I went to
talk with some pygobject developers, and here's a retail of the
conversation.
16:12 < jhernandez> I'm using GUdev with pygobject
16:12 < jhernandez> and, I have some doubts regarding the way I'm using it
16:13 < jhernandez> with the old python-gudev, I was used to do like
this: client = gudev.Client(subsystems)
16:14 < jhernandez> using the gobject introspected bindings, I'm not
able to get my client object like I was used
16:14 < jhernandez> instead, I need to use the gudev.Client.new method
16:16 < jhernandez> should I report this as a bug? or it is my fault?
16:59 < tomeu> all GObjects should be instantiable with g_object_new
16:59 < tomeu> the problem is people doing things in _new_* that
should be done instead in _init or _construct
16:59 < tomeu> jhernandez: it's a bug that should be reported
17:00 < tomeu> (in GUDev)
17:00 < jhernandez> tomeu: ACK
JFYI, the full conversation log is here [1]
I think the final decision on this is up to udev/gudev developers, and
I'll try (with some help) to provide a patch if it is really needed.
My devel environment consists in:
- openSUSE 12.1 + Official updates
- udev pulled from master (182)
Best regards!
[1]: http://pastebin.com/js7rKh3J
--
Javier Hernández Antúnez
<jhernandez@emergya.com>
^ permalink raw reply
* Re: [RFC PATCH] virtio_blk: Checking "private_data" to avoid kernel panic when hotplugging
From: Ren Mingxin @ 2012-04-11 9:09 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Rusty Russell, Kay Sievers, Tokunaga Kei, LKML, UDEV
In-Reply-To: <20120411083608.GC8562@redhat.com>
On 04/11/2012 04:36 PM, Michael S. Tsirkin wrote:
> On Wed, Apr 11, 2012 at 11:17:16AM +0800, Ren Mingxin wrote:
>> On 04/09/2012 03:53 PM, Michael S. Tsirkin wrote:
>>
>>> There's a chance you are hitting a race fixed by
>>> 4678d6f970c2f7c0cbfefc0cc666432d153b321b.
>>>
>>> If it's still not fixed it might make sense to enable slab debugging -
>>> we might have a use after free here.
>>>
>> I don't think the below commit has fixed this panic issue, for it is
>> included
>> in my last test environment(3.3-rc7).
>> 4678d6f970c2f7c0cbfefc0cc666432d153b321b
>>
>> Now, I'd find which commit makes sense.
> Great, thanks very much. I do suggest slab debugging if
> the race reproduces for you with it enabled - reducing
> the chance random struct rearrangements hide the bug.
>
Much appreciated for suggesting :-)
I'll try it to locate the commit and backport it into rhel.
--
Thanks,
Ren
^ permalink raw reply
* Re: [RFC PATCH] virtio_blk: Checking "private_data" to avoid kernel panic when hotplugging
From: Michael S. Tsirkin @ 2012-04-11 8:36 UTC (permalink / raw)
To: Ren Mingxin; +Cc: Rusty Russell, Kay Sievers, Tokunaga Kei, LKML, UDEV
In-Reply-To: <4F84F7BC.102@cn.fujitsu.com>
On Wed, Apr 11, 2012 at 11:17:16AM +0800, Ren Mingxin wrote:
> On 04/09/2012 03:53 PM, Michael S. Tsirkin wrote:
> >On Wed, Mar 28, 2012 at 11:40:33AM +0800, Ren Mingxin wrote:
> >>On guest with upstream's kernel(3.3.0-rc7), I
> >>mounted virtblk as:
> >> a) # mkfs /dev/vda
> >> b) # mount /dev/vda /mnt
> >> c) # cd /mnt
> >>
> >>Then I did hotplug for virtblk via virsh on host as:
> >> a) # sudo virsh detach-disk guest vda
> >> b) # sudo virsh attach-disk guest /media/data/test.img vda
> >>
> >>I encountered guest's kernel panic (*probability*
> >>*event*)whose backtrace liked this:
> >Any news here? Managed to trace?
>
> Sorry, I had a leave last week.
>
> >Does this still happen with 3.4-rc2?
>
> I retested this with 3.4-rc2, but the panic couldn't be reproduced.
> (Last time, It seemed that the upstream's kernel was 3.3-rc7)
>
> >There's a chance you are hitting a race fixed by
> >4678d6f970c2f7c0cbfefc0cc666432d153b321b.
> >
> >If it's still not fixed it might make sense to enable slab debugging -
> >we might have a use after free here.
> >
>
> I don't think the below commit has fixed this panic issue, for it is
> included
> in my last test environment(3.3-rc7).
> 4678d6f970c2f7c0cbfefc0cc666432d153b321b
>
> Now, I'd find which commit makes sense.
Great, thanks very much. I do suggest slab debugging if
the race reproduces for you with it enabled - reducing
the chance random struct rearrangements hide the bug.
> --
> Thanks,
> Ren
^ permalink raw reply
* Re: [RFC PATCH] virtio_blk: Checking "private_data" to avoid kernel panic when hotplugging
From: Ren Mingxin @ 2012-04-11 3:17 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Rusty Russell, Kay Sievers, Tokunaga Kei, LKML, UDEV
In-Reply-To: <20120409075318.GB27771@redhat.com>
On 04/09/2012 03:53 PM, Michael S. Tsirkin wrote:
> On Wed, Mar 28, 2012 at 11:40:33AM +0800, Ren Mingxin wrote:
>> On guest with upstream's kernel(3.3.0-rc7), I
>> mounted virtblk as:
>> a) # mkfs /dev/vda
>> b) # mount /dev/vda /mnt
>> c) # cd /mnt
>>
>> Then I did hotplug for virtblk via virsh on host as:
>> a) # sudo virsh detach-disk guest vda
>> b) # sudo virsh attach-disk guest /media/data/test.img vda
>>
>> I encountered guest's kernel panic (*probability*
>> *event*)whose backtrace liked this:
> Any news here? Managed to trace?
Sorry, I had a leave last week.
> Does this still happen with 3.4-rc2?
I retested this with 3.4-rc2, but the panic couldn't be reproduced.
(Last time, It seemed that the upstream's kernel was 3.3-rc7)
> There's a chance you are hitting a race fixed by
> 4678d6f970c2f7c0cbfefc0cc666432d153b321b.
>
> If it's still not fixed it might make sense to enable slab debugging -
> we might have a use after free here.
>
I don't think the below commit has fixed this panic issue, for it is
included
in my last test environment(3.3-rc7).
4678d6f970c2f7c0cbfefc0cc666432d153b321b
Now, I'd find which commit makes sense.
--
Thanks,
Ren
^ permalink raw reply
* Re: [RFC PATCH] virtio_blk: Checking "private_data" to avoid kernel panic when hotplugging
From: Michael S. Tsirkin @ 2012-04-09 7:53 UTC (permalink / raw)
To: Ren Mingxin; +Cc: Rusty Russell, Kay Sievers, Tokunaga Kei, LKML, UDEV
In-Reply-To: <4F728831.2090406@cn.fujitsu.com>
On Wed, Mar 28, 2012 at 11:40:33AM +0800, Ren Mingxin wrote:
> Hi,
>
> On guest with upstream's kernel(3.3.0-rc7), I
> mounted virtblk as:
> a) # mkfs /dev/vda
> b) # mount /dev/vda /mnt
> c) # cd /mnt
>
> Then I did hotplug for virtblk via virsh on host as:
> a) # sudo virsh detach-disk guest vda
> b) # sudo virsh attach-disk guest /media/data/test.img vda
>
> I encountered guest's kernel panic (*probability *
> *event*)whose backtrace liked this:
Any news here? Managed to trace?
Does this still happen with 3.4-rc2?
There's a chance you are hitting a race fixed by
4678d6f970c2f7c0cbfefc0cc666432d153b321b.
If it's still not fixed it might make sense to enable slab debugging -
we might have a use after free here.
--
MST
^ permalink raw reply
* Re: udev hangs during boot (arch linux on thinkpad w520)
From: Mark K. Zanfardino @ 2012-04-06 21:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F79FD39.3090104@gmail.com>
Update: It appears that the issue I am/was having with my ThinkPad W520
hanging during boot is likely not related to udev. The short answer for
me was: turn off Intel Virtualization Technology in BIOS.
I will be doing testing this weekend to attempt to isolate the offending
module.
Thanks for all the help I got in #udev. Kay's suggestion to enable
debugging and turn off asynchronous processing helped me to eliminate
udev as the source of the failure.
Cheers
Mark "Zanberdo" Zanfardino
^ permalink raw reply
* Re: [PATCH] keymap: Add support for Lenovo v480 touchpad toggle hotkey.
From: Martin Pitt @ 2012-04-05 8:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4f7b4d2d.smGVhW48tnwfC1gw%ayan.george@canonical.com>
Martin Pitt [2012-04-04 9:09 +0200]:
> I pushed that to my personal systemd branch [1], will ask Kay or
> Lennart to pull.
FTR, it's in now.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* building stand-alone udev
From: William Hubbs @ 2012-04-04 14:19 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 139 bytes --]
Hi all,
now that the udev and systemd source trees have been merged, how do we
build udev for non-systemd setups?
Thanks much,
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] keymap: Add support for Lenovo v480 touchpad toggle hotkey.
From: Martin Pitt @ 2012-04-04 7:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4f7b4d2d.smGVhW48tnwfC1gw%ayan.george@canonical.com>
Hello Ayan,
Ayan George [2012-04-03 19:19 +0000]:
> +ENV{DMI_VENDOR}="LENOVO", ATTR{[dmi/id]product_version}="*Lenovo V480*", RUN+="keymap $name 0xf1 f21"
Thanks for this! Yesterday udev was merged into systemd, so we need to
sort out a new workflow now.
I pushed that to my personal systemd branch [1], will ask Kay or
Lennart to pull.
Martin
[1] http://cgit.freedesktop.org/~martin/systemd/ -- it's not yet on the
web UI at the time of this writing; cron apparently takes a while to
pick this up
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2
From: Kay Sievers @ 2012-04-03 21:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1333371414-412-1-git-send-email-nils.carlson@ericsson.com>
On Tue, Apr 3, 2012 at 22:25, Hannes Reinecke <hare@suse.de> wrote:
> On 04/03/2012 08:24 PM, Kay Sievers wrote:
>> On Tue, Apr 3, 2012 at 10:04, Nils Carlson <nils.carlson@ericsson.com> wrote:
>>
>>> This patch reintroduces enumeration
>>> of the form
>>>
>>> pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0
>>>
>>> where phy0 is the reintroduced substring where 0 corresponds
>>> to the lowest phy identifier on the port to which the device
>>> is connected.
>>
>> Without having any real insight knowledge, a quick check:
>>
>> We usually refuse any "find the lowest number approach" in new code,
>> and require the kernel to export a stable instance number per parent
>> device, which is entirely disconnected from any global device
>> enumeration counter or prober ordering.
>>
>> Almost all existing examples doing that are broken, and some even
>> needed to be removed because they just blindly bet on luck that things
>> are always in the same probe order.
>>
>> Many device can individually unbound and rebound in the kernel, so
>> after the rebind the same device will no longer have a smaller number
>> like it had before. Kernel enumeration is only in a very few cases
>> useful to build persistent paths.
>>
>> The approach in this case is safe against individual pieces being
>> unregistered and registered again?
>>
> Note, this is just a first step towards real configuration.
>
> This is the SAS PHY issue we've talked about earlier; eventually we'll
> have to export paths for all phys.
>
> I'm working on a patch (on top of this one), but it'll be quite a change
> to path_id. So I've asked for this patch to be sent now, rather than
> wait for the full blown solution.
Yeah, sure, I just need to make sure we do not do things like this any more:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=src/udev-builtin-path_id.c;h¨559d2dd4118ac89feb03b7db8ef364caa73a0b;hb=HEAD#l255
It is just broken, and the kernel needs to export that if we really
want to use it in userspace. The kernel device name has zero meaning
and we must not derive any order from it, never. Re-registering the
same device will probably just break that too-simple logic.
I just asked, because the requirement for new stuff is much higher
today, we do not fiddle around with broken kernel interfaces anymore.
If the stuff does not export the proper things, we just don't support
it.
The time to fiddle with symptoms is over. We either get it fixed for
real, or it will just not show up in new things in higher levels in
userspace, including new symlinks udev creates.
And the transport classes in sysfs are just a nightmare; but I know, I
don't need to tell you. :)
Kay
^ permalink raw reply
* Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2
From: Hannes Reinecke @ 2012-04-03 20:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1333371414-412-1-git-send-email-nils.carlson@ericsson.com>
On 04/03/2012 08:24 PM, Kay Sievers wrote:
> On Tue, Apr 3, 2012 at 10:04, Nils Carlson <nils.carlson@ericsson.com> wrote:
>
>> This patch reintroduces enumeration
>> of the form
>>
>> pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0
>>
>> where phy0 is the reintroduced substring where 0 corresponds
>> to the lowest phy identifier on the port to which the device
>> is connected.
>
> Without having any real insight knowledge, a quick check:
>
> We usually refuse any "find the lowest number approach" in new code,
> and require the kernel to export a stable instance number per parent
> device, which is entirely disconnected from any global device
> enumeration counter or prober ordering.
>
> Almost all existing examples doing that are broken, and some even
> needed to be removed because they just blindly bet on luck that things
> are always in the same probe order.
>
> Many device can individually unbound and rebound in the kernel, so
> after the rebind the same device will no longer have a smaller number
> like it had before. Kernel enumeration is only in a very few cases
> useful to build persistent paths.
>
> The approach in this case is safe against individual pieces being
> unregistered and registered again?
>
Note, this is just a first step towards real configuration.
This is the SAS PHY issue we've talked about earlier; eventually we'll
have to export paths for all phys.
I'm working on a patch (on top of this one), but it'll be quite a change
to path_id. So I've asked for this patch to be sent now, rather than
wait for the full blown solution.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
^ permalink raw reply
* [PATCH] keymap: Add support for Lenovo v480 touchpad toggle hotkey.
From: Ayan George @ 2012-04-03 19:19 UTC (permalink / raw)
To: linux-hotplug
---
src/keymap/95-keymap.rules | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/keymap/95-keymap.rules b/src/keymap/95-keymap.rules
index 524e506..ee5b5c1 100644
--- a/src/keymap/95-keymap.rules
+++ b/src/keymap/95-keymap.rules
@@ -83,6 +83,7 @@ ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="ThinkPad X2[02]* Tab
ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="*IdeaPad*", RUN+="keymap $name lenovo-ideapad"
ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_name}="S10-*", RUN+="keymap $name lenovo-ideapad"
ENV{DMI_VENDOR}="LENOVO", ATTR{[dmi/id]product_version}="*IdeaPad Y550*", RUN+="keymap $name 0x95 media 0xA3 play"
+ENV{DMI_VENDOR}="LENOVO", ATTR{[dmi/id]product_version}="*Lenovo V480*", RUN+="keymap $name 0xf1 f21"
ENV{DMI_VENDOR}="Hewlett-Packard*", RUN+="keymap $name hewlett-packard"
ENV{DMI_VENDOR}="Hewlett-Packard*", ATTR{[dmi/id]product_name}="*[tT][aA][bB][lL][eE][tT]*", RUN+="keymap $name hewlett-packard-tablet"
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices v2
From: Kay Sievers @ 2012-04-03 18:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1333371414-412-1-git-send-email-nils.carlson@ericsson.com>
On Tue, Apr 3, 2012 at 10:04, Nils Carlson <nils.carlson@ericsson.com> wrote:
> This patch reintroduces enumeration
> of the form
>
> pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0
>
> where phy0 is the reintroduced substring where 0 corresponds
> to the lowest phy identifier on the port to which the device
> is connected.
Without having any real insight knowledge, a quick check:
We usually refuse any "find the lowest number approach" in new code,
and require the kernel to export a stable instance number per parent
device, which is entirely disconnected from any global device
enumeration counter or prober ordering.
Almost all existing examples doing that are broken, and some even
needed to be removed because they just blindly bet on luck that things
are always in the same probe order.
Many device can individually unbound and rebound in the kernel, so
after the rebind the same device will no longer have a smaller number
like it had before. Kernel enumeration is only in a very few cases
useful to build persistent paths.
The approach in this case is safe against individual pieces being
unregistered and registered again?
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