hi | 3 Dec 19:49 2014
Picon

hi


iphone 6,  380euro,
nous avons aussi samsung s5, seulement  260euro, ...
Si Te: assroooo. com
Rajib Karmakar | 2 Dec 14:46 2014
Picon

udev not renaming interface if driver is built-in

Hello,

My ethernet driver was built as a module and once it was probed, I can
see that udev renames the interface. but when I try to have the
ethernet driver as built-in. the driver is probed but udev no longer
renames the interface.

Can you please help me in this?

Thanks in advance.

Regards,
Rajib
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Angelo Dureghello | 13 Oct 15:19 2014
Picon

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> gmail.com> wrote:
>> Dear all,
>>
>> i am running kernel 3.19.0,
> Are you sure?
Sry, 3.17.0.

I solved.

This kernel needs:

CONFIG_BINFMT_SCRIPT

Regards,
angelo

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Angelo Dureghello | 13 Oct 15:06 2014
Picon

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
done
Starting System Watchdog service: random: nonblocking pool is initialized
done
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...
Done
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
Picon

[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:
https://github.com/jiangliu/linux.git iommu/hotplug_v6

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

V5->V6:
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
Picon

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

Hi,

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:

ata-ST3000DM001-1CH166_W1F26HKK
ata-ST3000DM001-1CH166_Z1F2FBBY

But instead we see:

ata-ST3000DM001-1CH166_W1F26HKK
scsi-35000c500668a9bdb

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
Picon

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 http://dpaste.com/1BN5FKA
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'

and

    update old name, '/dev/disk/ec2/vol-05b50706' no longer belonging to
'/devices/vbd-2048/block/xvda'
    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
Picon

[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 linuxquestions.org 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 linuxquestions.org:
http://www.linuxquestions.org/questions/linux-kernel-70/why-dev-init_name-%3D-null-in-device_add-function-4175504749/
(Continue reading)

Sebastian Parschauer | 24 Jul 16:48 2014

udev 215 creates inactive MD devices upon stopping them

Hi,

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

Reference: http://www.spinics.net/lists/raid/msg46676.html
Reported-by: Francis Moreau <francis.moro <at> gmail.com>

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 vrfy.org>
> Date:   Sun Apr 13 19:54:27 2014 -0700
> 
>      udev: serialize/synchronize block device event handling with file locks
> 
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
> 
> It seems that they have already disabled this for dm for some reason,
> but not for md:
> 
> commit e918a1b5a94f270186dca59156354acd2a596494
> Author: Kay Sievers <kay <at> vrfy.org>
> 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
Picon

[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
http://comments.gmane.org/gmane.linux.kernel/1687425

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
node.

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

Hi,

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
function?

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> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane