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.

Jiang Liu | 25 Jun 11:02 2014

[Patch Part3 V3 00/21] 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 mainstream kernel

Patch 1-13 are bugfixes and code improvement for current drivers.
Patch 14-17 enhances DMAR framework to support hotplug
Patch 18 enhances Intel interrupt remapping driver to support hotplug
Patch 19 enhances error handling in Intel IR driver
Patch 20 enhance Intel IOMMU to support hotplug
Patch 21 enhance ACPI pci_root driver to handle DMAR units

This patch set has been tested on Intel development machine.
Appreciate any comments and tests. With this patch set and
another IOAPIC hotplug patch set(
 <at> applied, we could support full functional
socket hotplug on x86 platforms now.

1) rebase to latest v3.16-rc2
2) fix a bug in detecting super page support when hot-adding IOMMU

1) enhance the way to simplify intel_unmap_sg()
2) rename dmar_device_hotplug() to dmar_device_add/remove()
3) coding style improvment

Best Regards!

(Continue reading)

Jiang Liu | 20 Jun 09:08 2014

[Patch] iommu/vt-d: fix bug in handling multiple RMRRs for the same PCI device

Function dmar_iommu_notify_scope_dev() makes a wrong assumption that
there's one RMRR for each PCI device at most, which causes DMA failure
on some HP platforms. So enhance dmar_iommu_notify_scope_dev() to
handle multiple RMRRs for the same PCI device.


Cc: <stable <at>> # 3.15
Reported-by: Tom Mingarelli <thomas.mingarelli <at>>
Tested-by: Linda Knippers <linda.knippers <at>>
Signed-off-by: Jiang Liu <jiang.liu <at>>
 drivers/iommu/intel-iommu.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 6bb32773c3ac..51b6b77dc3e5 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
 <at>  <at>  -3816,14 +3816,11  <at>  <at>  int dmar_iommu_notify_scope_dev(struct dmar_pci_notify_info *info)
 				((void *)rmrr) + rmrr->header.length,
 				rmrr->segment, rmrru->devices,
-			if (ret > 0)
-				break;
-			else if(ret < 0)
+			if(ret < 0)
 				return ret;
 		} else if (info->event == BUS_NOTIFY_DEL_DEVICE) {
-			if (dmar_remove_dev_scope(info, rmrr->segment,
(Continue reading)

Saran Neti | 19 Jun 06:42 2014

Kernel BUG() in block/blk-tag.c:89 causing panic.


I have a many identical looking USB drives in two btrfs multi-device
configurations. I was unplugging and replugging a few devices to
identify which physical device belonged to which btrfs filesystem.
Running "btrfs fi show" during this unplugging/replugging business
produced the BUG() stack trace shown below. "btrfs fi show" wouldn't
return and neither would "fdisk -l". When I tried to reboot the
computer, it panicked forcing me to do a hard reset.

All hard disks are run-of-the-mill Seagate Expansion or Backup Plus
drives. They all work fine (data and SMART) when kernel
detects them at the start. I hit the BUG() twice during
unplugging/replugging them randomly and I think it could've been when
I swapped USB ports for identical drives (model/version etc.)

If more lspci/lsusb information if needed, let me know. I should be
able to reproduce it again and if needed insert printks and debug on

# uname -a
Linux godel 3.15.1-1-ARCH #1 SMP PREEMPT Tue Jun 17 09:32:20 CEST 2014
x86_64 GNU/Linux

------------[ cut here ]------------
kernel BUG at block/blk-tag.c:89!
invalid opcode: 0000 [#1] PREEMPT SMP
Modules linked in: bridge stp llc tun nct6775 hwmon_vid hid_microsoft
uas usb_storage joydev hid_generic ir_lirc_codec mousedev lirc_dev
ir_mce_kbd_decoder ir_sharp_decoder ir_sanyo_decoder ir_sony_decoder
(Continue reading)

Santander Finance | 9 Jun 00:15 2014

We offer all purpose loan at 3% interest rate

We offer all purpose loan at 3% interest rate. Contact Us for more details by Email:santanderfinancegroup <at>
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at>
More majordomo info at