Angelo Dureghello | 13 Oct 15:19 2014

Re: udev error, ENOEXEC

On 13/10/2014 15:10, Andrei Borzenkov wrote:
> On Mon, Oct 13, 2014 at 5:06 PM, Angelo Dureghello <angelo70 <at>> wrote:
>> Dear all,
>> i am running kernel 3.19.0,
> Are you sure?
Sry, 3.17.0.

I solved.

This kernel needs:



To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at>
More majordomo info at

Angelo Dureghello | 13 Oct 15:06 2014

udev error, ENOEXEC

Dear all,

i am running kernel 3.19.0, Init 2.88 and udev 182

At boot i get this automount error:

VFS: Mounted root (ubifs filesystem) on device 0:14.
devtmpfs: mounted
Freeing unused kernel memory: 152K (c05de000 - c0604000)
INIT: version 2.88 booting
Please wait: booting...
Populating /dev using udev: udevd[1070]: starting version 182
davinci_wdt: disagrees about version of symbol module_layout
Starting System Watchdog service: random: nonblocking pool is initialized
udevd[1088]: failed to execute '/lib/udev/automount' 'automount add 
mmcsd /dev/mmcblk0p1': Exec format error

Mounting configuration partition...
Checking that all configuration is in place...
Inserting all the extra modules...

Tried hardly to find informations over the day, but still can't get out.
After login, if i execute the same "automount" command not launched from 
udev but from command prompt), mount works.
Same rootfs image with old kernel 3.5.1 was also working.

(Continue reading)

Jiang Liu | 19 Sep 07:18 2014

[Patch Part3 V6 0/8] Enable support of Intel DMAR device hotplug

When hot plugging a descrete IOH or a physical processor with embedded
IIO, we need to handle DMAR(or IOMMU) unit in the PCIe host bridge if
DMAR is in use. This patch set tries to enhance current DMAR/IOMMU/IR
drivers to support hotplug and is based on latest Linus master branch.

All prerequisite patches to support DMAR device hotplug have been merged
into the mainstream kernel, and this is the last patch set to enable
DMAR device hotplug.

You may access the patch set at: iommu/hotplug_v6

This patch set has been tested on Intel development machine.
Appreciate any comments and tests.

1) Fix a race condition found during review
2) Refine dmar_walk_resources() to dmar_walk_remapping_entries()

Patch 1-4 enhances DMAR framework to support hotplug
Patch 5 enhances Intel interrupt remapping driver to support hotplug
Patch 6 enhances error handling in Intel IR driver
Patch 7 enhance Intel IOMMU to support hotplug
Patch 8 enhance ACPI pci_root driver to handle DMAR units

Jiang Liu (8):
  iommu/vt-d: Introduce helper function dmar_walk_resources()
  iommu/vt-d: Dynamically allocate and free seq_id for DMAR units
  iommu/vt-d: Implement DMAR unit hotplug framework
  iommu/vt-d: Search for ACPI _DSM method for DMAR hotplug
(Continue reading)

Brandon R Schwartz | 11 Sep 04:34 2014

Improper Naming in /dev/disk/by-id and Drives Offline


I'm working on a particular issue (possibly two separate issues) where
our HDDs are (1) getting mislabeled in /dev/disk/by-id and (2)
dropping offline even though drive and controller logs show that the
drive is communicating and working as expected.  I don't have much
knowledge on the udev side of things so it would be great if someone
could offer some insight into the way udev assigns device names and if
there are thoughts as to why the OS cannot see the drive in certain
cases (timing issue?).

The first issue, the mislabeling problem, is that on reboots or power
cycles we occasionally see our drives become mislabeled in
/dev/disk/by-id.  We expect to see something like:


But instead we see:


The "scsi" drive is assigned a drive letter and the OS can communicate
with the drive.  Drives logs and controller logs show the drive is
working properly, but for some reason it's getting labeled incorrectly
in /dev/disk/by-id.  We have looked through dmesg and enabled logging
in udev (udevadm control --log-priority=debug), but we have not seen
where these labels are coming from.

(Continue reading)

Patrick Hemmer | 16 Aug 01:46 2014

device symlinks being removed

It seems I have some sort of race condition when using udev rules to set
up some device symlinks, but I'm not sure why.
I'm building EC2 boxes, and immediately after they boot, they add some
udev rules to create symlinks, and then call `udevadm trigger` to
process the rules. The problem is that during this procedure, sometimes
some of the links are missing. The udev debug log indicates the links
were created, and then subsequently removed.

The complete system log can be viewed at
However I've grabbed what look like the interesting lines, and have
included them at the bottom. Notice the ones such as

    creating symlink '/dev/disk/ec2/vol-05b50706' to '../../xvda'


    update old name, '/dev/disk/ec2/vol-05b50706' no longer belonging to
    no reference left, remove '/dev/disk/ec2/vol-05b50706'

My udev rule looks like this:

    SUBSYSTEM=="block", SUBSYSTEMS=="xen", ATTR{capability}=="*",
ACTION=="add", PROGRAM="/ec2disks -A %k", SYMLINK+="%c"

My current process is:

    # create the file
    /bin/udevadm control --reload
    /bin/udevadm settle
(Continue reading)

Aniroop Mathur | 1 Aug 19:13 2014

[Question: Drivers/base/core.c] Why dev->init_name = NULL in device_add function ?

Dear Mr. Greg Kroah-Hartman and Linux Community,
Greetings of the day !! :)

I am Aniroop Mathur working on Linux Kernel for last two years.
I am stuck at one point and could not find the solution over internet.
I posted on too.
So I need your help and suggestion for it.

Can you please help in answering my query as below:

In function device_add of /drivers/base/core.c file, it is mentioned:
* for statically allocated devices, which should all be converted
* some day, we need to initialize the name. We prevent reading back
* the name, and force the use of dev_name()
if (dev->init_name) {
dev_set_name(dev, "%s", dev->init_name);
dev->init_name = NULL;

Except forcing the use of dev_name to read device name,
Is there any other reason to make init_name as NULL ?
And if it is not made NULL, is there any problem or side-effect ?


Link at
(Continue reading)

Sebastian Parschauer | 24 Jul 16:48 2014

udev 215 creates inactive MD devices upon stopping them


as discussed on linux-raid, please fix the bug that udev 215 creates
inactive MD devices upon stopping them.

Reported-by: Francis Moreau <francis.moro <at>>

An open() call to /dev/mdX after creating it with mknod is enough to
create such inactive MD device.

According to Artur the issue is caused by this change in udev:

> commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> Author: Kay Sievers <kay at>
> Date:   Sun Apr 13 19:54:27 2014 -0700
>      udev: serialize/synchronize block device event handling with file locks
> It seems that they have already disabled this for dm for some reason,
> but not for md:
> commit e918a1b5a94f270186dca59156354acd2a596494
> Author: Kay Sievers <kay <at>>
> Date:   Tue Jun 3 16:49:38 2014 +0200
>     udev: exclude device-mapper from block device ownership event locking
(Continue reading)

Jiang Liu | 11 Jul 09:37 2014

[RFC Patch V1 00/30] Enable memoryless node on x86 platforms

Previously we have posted a patch fix a memory crash issue caused by
memoryless node on x86 platforms, please refer to

As suggested by David Rientjes, the most suitable fix for the issue
should be to use cpu_to_mem() rather than cpu_to_node() in the caller.
So this is the patchset according to David's suggestion.

Patch 1-26 prepare for enabling memoryless node on x86 platforms by
replacing cpu_to_node()/numa_node_id() with cpu_to_mem()/numa_mem_id().
Patch 27-29 enable support of memoryless node on x86 platforms.
Patch 30 tunes order to online NUMA node when doing CPU hot-addition.

This patchset fixes the issue mentioned by Mike Galbraith that CPUs
are associated with wrong node after adding memory to a memoryless

With support of memoryless node enabled, it will correctly report system
hardware topology for nodes without memory installed.
root <at> bkd01sdp:~# numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
node 0 size: 15725 MB
node 0 free: 15129 MB
node 1 cpus: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89
node 1 size: 15862 MB
node 1 free: 15627 MB
node 2 cpus: 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104
node 2 size: 0 MB
node 2 free: 0 MB
(Continue reading)

Igor Bezukh | 8 Jul 19:02 2014

A question about hotplug and suspend-resume functionallity


We are testing Intel Gigabit adapter driver (igb) under Fedora 20, kernel 3.14.4 for the following use-case:

(*) Adapter is connected to the PCIE slot
(*) We put the system under suspend by running pm-suspend from user-space
(*) Remove the adapter from the PCIE slot
(*) Wake up the system

Currently, we got kernel panics and the system gets stuck.

My questions are - 
1) in order to support hot-unplugging in igb driver, should I implement the check of device presence in igb_resume

2) After the system wakes up, I see in dmesg that the PCI device function igb refuses to change power state and
remains in PCI power state D3.
     can I assume that after suspend-resume if the function remains in D3 and refuses to move to D1 then
hot-unplug event has occured?

Thanks and BR,
Igor Bezukh

To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at>
More majordomo info at

shawn wilson | 6 Jul 04:18 2014

multi-port usb-serial hub rules

I've got a few usb to 4 serial port hubs. The problem is that
sometimes the ttyUSB* devs get resorted. I'm trying to write rules to
handle them (and maybe name the devices after the machines they're
connected to) however, I'm stuck because they only show up as one usb
device (and not another usb hub with a serial device on each port):

  looking at device

  looking at parent device

  looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0':
    ATTRS{bAlternateSetting}==" 0"
(Continue reading)

Phillip Susi | 26 Jun 01:22 2014

Matching on the ata port number, which is an attribute that is not a direct ancestor

I am trying to figure out how to set up a rule, preferably using
information stored in the hwdb, to identify ata ports that are known
to be esata on specific hardware.  The problem seems to be that ata
exposes this information not in a direct ancestor of the block device
node, but off to the side.  For example, the block node is:


But the ata port number is exposed in the attribute:


So how can I write a udev rule to match on a specific port_no, and
then add in the modalias for this specific controller?

Matching on ATTRS{ata_port/ata1/port_no} doesn't seem to work.