headers
Phillip Susi | 18 Jun 2013 19:45
Favicon

Inhibiting plug and play


Various tools, but most notably partitioners, manipulate disks in such
a way that they need to prevent the rest of the system from racing
with them while they are in the middle of manipulating the disk.
Presently this is done with a hodge podge of hacks that involve
running some script or executable to temporarily hold off on some
aspects ( typically only auto mounting ) of plug and play processing.
 Which one depends on whether you are running hal, udisks, udisks2, or
systemd.

There really needs to be a proper way at a lower level, either udev,
or maybe in the kernel, to inhibit processing events until the tool
changing the device has finished completely.  The question is, should
this be in the kernel, or in udev, and what should the interface be?
Permalink | Reply | 4 comments |
headers
Steve White | 26 Apr 2013 10:46

Lenovo IdeaPad S206

Hi,

My new Lenovo IdeaPad S206 has a special button ("OneKey recovery system"
button) that I wanted to re-map to a sleep button.  I did this, and it
works well.  There is also a QS key, that one could profitably re-map.

Along the way realized that the generic IdeaPad mappings of the Ubuntu 12.10
distro are largely incompatible with the keys on this computer.
So I set out to remedy that.

I'm not sure I'm following best practices though.  In particular, should
existing IdeaPad rules be restricted, or should the mappings be overridden?

I have some evidence that the mappings here should also work for the S200,
but I'm pretty sure they *aren't* appropriate for the S205.
  ________________________________
$ cat /sys/class/dmi/id/sys_vendor
LENOVO
$ cat /sys/class/dmi/id/product_name
2638
$ cat /sys/class/dmi/id/product_version
Lenovo IdeaPad S206
  ________________________________
The OneKey button on this machine is perfect for a sleep button:
it is easily accessible, but impossible to press accidentally.

To simply re-map the OneKey button, I first observed:
A 0x10 press-release pair is emitted if the button is given a substantial
press, and released. After about 3 sec of continuous pressing,
a 0x11 press-release pair is emitted.
(Continue reading)

Permalink | Reply | 1 comment |
headers
snowyxx | 26 Apr 2013 05:32
Favicon

(unknown)

Hi Boss,
So sorry to mail you in this rude way (if you look into this mail, I know is
not support mail, but god guide missing people, right?  )
I am finding a solution to my problem….
I have some machines with 8 net interfaces, I want to name one as eth0, I
need a solution to work for all machine ( I will clone OS from one to
others), so I could not just modify the rule file under /etc/udev/rules.d 

I need setup a math condition works for all machine. 
I want to change  /lib/udev/rules.d/75-persistent-net-generator.rules file
to only match MACs
But my problem is that interface names turn out did not ordered by MACs,
It suppose  00:0d:48:08:92:9a named as eth0, but not.

Is there any way to let interfaces named by MACs order? 

root <at> APM:~# dmesg |grep eth
[   10.429663] e1000e 0000:03:00.0: eth0: (PCI Express:2.5GB/s:Width x4)
00:0d:48:08:92:9b
[   10.429665] e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network
Connection
[   10.429742] e1000e 0000:03:00.0: eth0: MAC: 0, PHY: 1, PBA No: C85839-002
[   12.421678] e1000e 0000:03:00.1: eth1: (PCI Express:2.5GB/s:Width x4)
00:0d:48:08:92:9a
[   12.421680] e1000e 0000:03:00.1: eth1: Intel(R) PRO/1000 Network
Connection
[   12.421756] e1000e 0000:03:00.1: eth1: MAC: 0, PHY: 1, PBA No: C85839-002
[   16.061712] e1000e 0000:04:00.0: eth2: (PCI Express:2.5GB/s:Width x4)
00:0d:48:08:92:9d
[   16.061714] e1000e 0000:04:00.0: eth2: Intel(R) PRO/1000 Network
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tom Gundersen | 16 Apr 2013 15:12
Picon
Gravatar

[PATCH v3] tools: add static-nodes tool

This tool reads modules.devname from the current kernel directory and outputs
the information. By default in a human-readable format, and optionally in
machine-readable formats.

For now only the tmpfiles.d(5) format is supported, but more could easily be
added in the future if there is a need.

This means nothing but kmod needs to reads the private files under
/lib/modules/. In particular systemd-udevd can stop reading modules.devname.

Cc: <linux-hotplug <at> vger.kernel.org>
Cc: <systemd-devel <at> lists.freedesktop.org>tools: static-nodes
---

v3: dropped the systemd integration for now, we can decide on that separately
    added human-readable format and use this by default
    added a --format= switch to get the tmpfiles format

 Makefile.am          |   3 +-
 tools/kmod.c         |   1 +
 tools/kmod.h         |   1 +
 tools/static-nodes.c | 176 +++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 tools/static-nodes.c

diff --git a/Makefile.am b/Makefile.am
index fe4c769..b1bfd59 100644
--- a/Makefile.am
+++ b/Makefile.am
 <at>  <at>  -110,7 +110,8  <at>  <at>  noinst_SCRIPTS = tools/insmod tools/rmmod tools/lsmod \
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tom Gundersen | 13 Apr 2013 02:15
Picon
Gravatar

[PATCH v2] tools: add static-nodes tool

This tool reads modules.devname from the current kernel directory and outputs
the information.

For now only the tmpfiles.d(5) format is supported, but more could easily be
added in the future if there is a need.

When booting with systemd, the new tool is called at boot to instruct
systemd-tmpfiles to create the necessary static modules before starting
systemd-udevd.

This means nothing but kmod needs to reads the private files under /lib/modules/.

Cc: <linux-hotplug <at> vger.kernel.org>
Cc: <systemd-devel <at> lists.freedesktop.org>
---

v2: adressed concerns raised by Dave, and made the tool a bit more generic so
more output formats may be added in the future as suggested by Lucas. Also
included the systemd unit file to hook this up with systemd.

 Makefile.am                        |  20 ++++-
 configure.ac                       |   8 ++
 tools/kmod-static-nodes.service.in |  16 ++++
 tools/kmod.c                       |   1 +
 tools/kmod.h                       |   1 +
 tools/static-nodes.c               | 163 +++++++++++++++++++++++++++++++++++++
 6 files changed, 207 insertions(+), 2 deletions(-)
 create mode 100644 tools/kmod-static-nodes.service.in
 create mode 100644 tools/static-nodes.c
(Continue reading)

Permalink | Reply | 2 comments |
headers
Štefan Sakalík | 11 Apr 2013 18:16
Picon

Disabling device

Hello,
I want to tell udev in RHEL6 _not_ to create a hard drive device in 
/dev/ identified by (for example) serial number. I see two problems:
1. AFAIK it is not possible to disable device creation in udev/rules.d/
2. It is not possible to identify device by serial number in udev. When 
I run: udevadm info -a -p $(udevadm info -q path -n /dev/sdak)
, it does not show me serial or other identifying information.

I need to get rid of this device because I'm sharing one disk array 
between two servers and both of them see all devices in the array.
I want to make sure the two servers are not accessing the drives 
simultaneously.

-Stefan
--
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
Permalink | Reply | 1 comment |
headers
Tom Gundersen | 11 Apr 2013 17:48
Picon
Gravatar

[PATCH] [RFC] udevd: let tmpfiles create all static nodes

systemd-tmpfiles has had support for creation of static nodes for some time (to
replace copying nodes from /lib/udev/). Make sure these nodes are created before
udev is started.

Also, drop support for creating static nodes based on modules.devname from
systemd-udevd. This allows it to run witohut CAP_MKNOD, moreover we no longer
need to parse /usr/lib/modules/*/modules.devname.

As a replacement for udevd's functionality, we let kmod generate a tmpfiles.d
fragment based on the correct modules.devname file (see separate patch). We
might want to split the kmod call out into its own unit file and ship that with
kmod instead.

Note: one functional change is that we no longer update the creation time on
already existing device nodes. Is this important? If so, should tmpfiles learn to
do that?

Cc: <linux-modules <at> vger.kernel.org>
Cc: <linux-hotplug <at> vger.kernel.org>
---
 Makefile.am                           |  5 +++
 TODO                                  |  4 --
 src/udev/udevd.c                      | 72 -----------------------------------
 units/systemd-static-nodes.service.in | 17 +++++++++
 units/systemd-udevd.service.in        |  5 +--
 5 files changed, 24 insertions(+), 79 deletions(-)
 create mode 100644 units/systemd-static-nodes.service.in

diff --git a/Makefile.am b/Makefile.am
index ec81f53..3c6adcb 100644
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lucas De Marchi | 10 Apr 2013 00:57

[ANNOUNCE] kmod 13

ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-13.tar.xz
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-13.tar.sign

New release of kmod 13, after some time accumulating bug fixes and new
features. This release got a bit delayed due to my marriage,
vacations, changing job and some new features getting into the kernel.
What else could happen at the same time? :-)

The most notable new features are the support for finit_module()
syscall and for signed modules. For finit_module() we try to be nice
with older kernels  and we fallback to init_module() if the new one is
not available. The older syscall is also used in case the module is
compressed.

There are also bug fixes and other minor new features. Check the NEWS
file. Thanks to everyone involved in this release. Shortlog is below.

Cheers,
Lucas De Marchi

---

Andrey Mazo (2):
      depmod: --symbol-prefix actually requires an argument
      depmod: fix builtin symbols resolution when the prefix symbol is set

Cristian Rodríguez (1):
      libkmod: Use secure_getenv if available

Josh Boyer (1):
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Pine | 27 Mar 2013 05:47

device properties and change events

I'm using udev-147 in CentOS 6.3.

I have two rules that import properties into the udev db. I'll use a
simplified example.

    IMPORT{program}="program1 %k"
    ACTION=="add", IMPORT{program}="program2 %N"

program1 exports MY_FOO, and program2 exports MY_BAR. I've noticed that
when a change event is triggered, MY_BAR is no longer available in the
udev database. So it appears change events clear the existing environment.
The work done in program2 is relatively expensive so I'd rather only run
it when the device is first added.

It looks like I can re-import MY_BAR if I use IMPORT{db} in a separate
rule:

    IMPORT{program}="program1 %k"
    ACTION=="add", IMPORT{program}="program2 %N"
    ACTION=="change", IMPORT{db}="MY_BAR"

Is this the correct approach? Or is there another way to persist the
properties that were imported during add, besides re-importing program2?

Also, is it possible to determine *what* causes a change event to occur?
With 'udevadm monitor' I can see change events being triggered whenever my
application exits (for the devices it has opened), and would like to
determine why. I was hoping udev could give me a hint.

-Keith
(Continue reading)

Permalink | Reply | 2 comments |
headers
Stephen Gildea | 25 Mar 2013 00:21

Dell Latitude E6530 keymap

I have a Dell Latitude E6530 laptop
(system vendor "Dell Inc.", product name "Latitude E6530").
A few of the keys are mapped incorrectly:

Fn+F5, Touchpad Toggle
----------------------

Fn+F5 is labeled on my keyboard with a "touchpad" icon, and in
udev 198, the line in /lib/udev/keymaps/dell for it is this:

0x9E f21 #touchpad toggle

Since we know it is "touchpad toggle" (and I confirm it is), and there
is a key name for that, how about changing this line to read thusly:

0x9E touchpad_toggle # Fn+F5

In the same "dell" file, 0xD9 is mapped the same ("f21 # touchpad toggle");
perhaps it also should be changed to send a real touchpad_toggle?

Fn+F8, LCD/CRT Switch
---------------------

Fn+F8 is labeled on my keyboard with an "LCD/CRT" icon.  
It sends two keycodes: Left_Win (aka "leftmeta"), then "p".
Can we get it to appear as a single "switchvideomode" key?
(If this is outside udev's domain, where should I look?)

Fn+End, Prnt Scrn
-----------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Myron Stowe | 16 Mar 2013 22:35
Picon
Favicon

[PATCH] udevadm-info: Don't access sysfs entries backing device I/O port space


I've been working on identifying the root cause of an issue exposed by
'udevadm' that was first exposed on the linux-pci mail list [1] and
believe that there is now enough of an understanding to propose a fix.

What was originally witnessed was the platform hanging after "udevadm info
--attribute-walk --path=/sys/devices/pci0000:00/<...>/block/sda" is ran.
Xiangliang was able to isolate the failure to accesses involving a Marvell
9125 device's I/O BARs, or more specifically, accesses to the I/O port
space backing the device's I/O BARs (a.k.a. the device's I/O port
resources, or regions).  With this knowledge he was able to reproduce the
hang targeting the device's sysfs 'resource<N>' entries, where N
represents an I/O BARs, with "cat /sys/devices/≤...>/resource<N>".

In my research, looking for possible solutions, I noticed that kernel
commit 8633328 introduced sysfs based reading and writing of I/O port
related 'resource<N>' entries as part of adding virtualization based
device assignment functionality [2].  Note that these regions directly map
to the device's control and status registers [3].

Putting together these pieces of information we now understand that:
  o  udevadm based attribute walking initiates read accesses of all the
     entries in a device's sysfs directory [4],
  o  sysfs 'resource<N>' entries correspond to the device's internal
     status and control registers used for driving the device,
  o  If the 'resource<N>' entry corresponds to a device's I/O BAR, the
     device's control and status registers are directly accessible by
     userspace.

Allowing userspace access to a device's registers introduces potential
(Continue reading)

Permalink | Reply | 33 comments |

Gmane