| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
As we were searching by ID_PATH, it would have been possible
for us to find a sibling device instead of the device we were
looking for.
This fixes device matching on the WeTab with the upstream kernel,
as it was trying to use the "Asus Laptop extra buttons" device
instead of the accelerometer.
|
|
Skipped bootchart and various files that looked like they should be
kept in sync with external sources.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Parameter -e is set without additional argument in getopt
and this leads to segfault when calling 'systemd-udevd -e'.
|
|
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=57206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The individual address block is a poor man's organizationally unique
identifier.
Perhaps we should change the udev key from ID_OUI_FROM_DATABASE to
something like ID_IEEE_VENDOR_FROM_DATABASE?
Suggested-by: Diego Elio Pettenò <flameeyes@flameeyes.eu>
|
|
|
|
|
|
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=879691
|
|
Currently, keymaps are provided only for the NP90X3A laptop. Samsung
introduced updated models, codenamed 900X3B, 900X3C, 900X4B, 900X4C,
which are currently not matched by udev rules. This patch includes the
newer modules in udev rules and move the samsung-n90x3a file defining
keys to a more generic samsung-series-9 file.
The patch was tested on a 900X4C laptop, and other people reported
that the rules also work for 900X3B and 900X3C ones.
|
|
|
|
|
|
|
|
Hyper-V has an abstract bus, which gets renumbered on guest
startup. So instead of the bus numbers we should be using
the device GUIDs, which can be retrieved from the 'device_id'
sysfs attribute.
|
|
--create is not a valid option.
|
|
kmod is unecessary if loadable module support is disabled in the kernel,
so make the dependency optional.
|
|
|
|
|
|
It's not configuration, so it doesn't belong in udev.
Also, remove the catalog when uninstalling udev.
|
|
If firmware file is not found in the file system, udev
terminates firmware loading. This is not the case if
firmware file exists in the file system but doesn't have
any data in it.
|
|
I'm building systemd for an embedded system and we would prefer not having
to include the entire util-linux package just to get a libblkid whose
functionality we don't need.
|
|
On Thu, Nov 15, 2012 at 5:05 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> wrote:
> Something like this appeared with latest git:
>
> Nov 15 16:55:46 fedora-15 systemd-udevd[334]: worker [364] terminated by signal 11 (Segmentation fault)
> Nov 15 16:55:46 fedora-15 [387]: Process 364 (systemd-udevd) dumped core.
> Nov 15 16:55:46 fedora-15 systemd-udevd[334]: worker [364] failed while handling '/devices/virtual/net/lo'
> Nov 15 16:55:46 fedora-15 systemd-udevd[334]: worker [360] terminated by signal 11 (Segmentation fault)
> Nov 15 16:55:46 fedora-15 systemd-udevd[334]: worker [360] failed while handling '/devices/pci0000:00/0000:00:03.0/virtio0/net
> Nov 15 16:55:46 fedora-15 [389]: Process 360 (systemd-udevd) dumped core.
>
> Core was generated by usr/lib/systemd/systemd-udevd'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x0000000000423c87 in udev_hwdb_get_properties_list_entry (hwdb=0x0, modalias=0x7fffbcd155f0
|
|
If a 'change' event is supposed to remove created symlinks, we create
a new device structure from the sysfs device and fill it with the list
of links, to compute the delta of the old and new list of links to apply.
If the device is already 'remove'd by the kernel though, udev fails to
create the device structure, so the links are not removed properly.
> From: Neil Brown <nfbrown@suse.com>
> Date: Thu, 8 Nov 2012 10:39:06 +0100
> Subject: [PATCH] If a 'change' event does not get handled by udev until
> after the device has subsequently disappeared, udev mis-handles
> it. This can happen with 'md' devices which emit a change
> event and then a remove event when they are stopped. It is
> normally only noticed if udev is very busy (lots of arrays
> being stopped at once) or the machine is otherwise loaded
> and reponding slowly.
>
> There are two problems.
>
> 1/ udev_device_new_from_syspath() will refuse to create the device
> structure if the device does not exist in /sys, and particularly if
> the uevent file does not exist.
> If a 'db' file does exist, that is sufficient evidence that the device
> is genuine and should be created. Equally if we have just received an
> event from the kernel about the device, it must be real.
>
> This patch just disabled the test for the 'uevent' file, it doesn't
> try imposing any other tests - it isn't clear that they are really
> needed.
>
> 2/ udev_event_execute_rules() calls udev_device_read_db() on a 'device'
> structure that is largely uninitialised and in particular does not
> have the 'subsystem' set. udev_device_read_db() needs the subsystem
> so it tries to read the 'subsystem' symlink out of sysfs. If the
> device is already deleted, this naturally fails.
> udev_event_execute_rules() knows the subsystem (as it was in the
> event message) so this patch simply sets the subsystem for the device
> structure to be loaded to match the subsystem of the device structure
> that is handling the event.
>
> With these two changes, deleted handling of change events will still
> correctly remove any symlinks that are not needed any more.
Use udev_device_new() instead of allowing udev_device_new_from_syspath()
to proceed without a sysfs device.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Thanks to Glen Ditchfield <gjditchfield@acm.org>!
https://launchpad.net/bugs/1071579
|
