gmane.linux.hotplug.devel

Re: Lenovo IdeaPad S206

Steve White — 2013-04-27T16:15:18

Hi,

In the previous post, I had confused the "win" key with the "switch video"
key.  This is corrected now.  See attached.

I still have several questions:

switch video
------------
The key meant to switch video (mod F10) produces two scan codes.
In man showkey, there are some remarks, but I don't know what they mean.

$ keymap -i /input/event4
scan code: 0xDB
scan code: 0x19
(both scancodes emitted together only once on press,
nothing on longer hold, nothing on release)
$ showkey -s
0x19 on press
0x99 on release

** What does this mean, and how are such results to be used with udev rules?

camera off-on
-------------
I can't see that this key (mod F9) generates anything on any device,
although it does in fact seem to kill the USB-based camera.

** Any ideas?

kill key
----------
The kill key (mod F4) very effectively kills any terminal it's running
in, so I have yet to determine what scan codes it generates.

** Any ideas?
# key codes on Lenovo IdeaPad S206, and presumably the S200
0x81 reserved

RE:

snowyxx — 2013-04-27T06:48:59

thx

-----Original Message-----
From: Tom Gundersen [mailto:teg< at >jklm.no] 
Sent: 2013年4月26日 15:01
To: snowyxx
Cc: linux-hotplug
Subject: Re:

On Fri, Apr 26, 2013 at 5:32 AM, snowyxx <snowyxx< at >126.com> wrote:

You should avoid renaming devices to ethX, this is racy and especially in recent udev versions it does not work.

You have two options:

1) Rename your devices to something not in the kernel namespace (e.g., lan0, lan1, ... or net0, net1, ...).

or

2) Use the predictable interface names, which is the default in recent versions. This will give you a new set of names (see [0] for details).

HTH,

Tom

[0]: <http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames>

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

Lenovo IdeaPad S206

Steve White — 2013-04-26T08:46:30

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

Re:

Tom Gundersen — 2013-04-26T07:00:40

You should avoid renaming devices to ethX, this is racy and especially
in recent udev versions it does not work.

You have two options:

1) Rename your devices to something not in the kernel namespace (e.g.,
lan0, lan1, ... or net0, net1, ...).

or

2) Use the predictable interface names, which is the default in recent
versions. This will give you a new set of names (see [0] for details).

HTH,

Tom

[0]: <http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames>
--
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

(unknown)

snowyxx — 2013-04-26T03:32:34

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

Re: [PATCH v3] tools: add static-nodes tool

Tom Gundersen — 2013-04-16T20:32:41

Thanks for the suggestions Thomas. I implemented most of them, so now
it should be a lot simpler to extend this in the future.

The only thing I skipped was the --format=? idea, as this info is
already in the help output, and I'm not sure how useful it is to
parse. That said, it could easily be added follow-up patch if there is
a need for it.

-t
--
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

Re: [PATCH v3] tools: add static-nodes tool

Kay Sievers — 2013-04-16T19:08:10

On Tue, Apr 16, 2013 at 8:51 PM, Lucas De Marchi
<lucas.demarchi< at >profusion.mobi> wrote:


Sounds all good to me.

Kay
--
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

[PATCH v3] tools: add static-nodes tool

Tom Gundersen — 2013-04-16T13:12:34

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

[PATCH v2] tools: add static-nodes tool

Tom Gundersen — 2013-04-13T00:15:45

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

Re: Disabling device

Greg KH — 2013-04-11T16:46:25

As you are using RHEL6, why not ask for support for this type of
situation from Red Hat?  You are paying for the support, might as well
use it :)

Good luck,

greg k-h
--
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

Disabling device

Štefan Sakalík — 2013-04-11T16:16:08

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

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

Tom Gundersen — 2013-04-11T15:48:31

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

[ANNOUNCE] kmod 13

Lucas De Marchi — 2013-04-09T22:57:02

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):
      l

Re: device properties and change events

Greg KH — 2013-03-28T22:58:45

My sympathies :)


What is triggering a change event?  What type of device?  What driver?


I think that is correct.  When a device "changes", all of it's
attributes are thrown away as they obviously changed (the kernel told us
so.)


What type of device is this?


Your kernel driver should tell you why, what driver is it?

thanks,

greg k-h
--
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

device properties and change events

Keith Pine — 2013-03-27T04:47:39

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 whe

Re: Dell Latitude E6530 keymap

Dmitry Torokhov — 2013-03-26T00:46:46

Unfortunately X can't deal with keycodes above 255 :(

Dell Latitude E6530 keymap

Stephen Gildea — 2013-03-24T23:21:24

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

The SysRq (Fn+Home) and Prnt Scrn (Fn+End) keys both

Re: [PATCH] udevadm-info: Don't access sysfs 'resource' files

Myron Stowe — 2013-03-19T16:57:49

Yes - the system hangs when BAR1's (and likely BAR3's) I/O port space is
read.

Here are the details that I've been able to put together from the two
linux-pci threads and various online sources -


From Robert Hancock - "... BAR5 is the MMIO region used by the AHCI
driver. BARs 0-4 are the legacy SFF-compatible ATA ports.  Nothing
should be messing with those IO ports while AHCI is enabled. ..."  This
likely explains why the system boots and runs fine as long as the
'udevadm ...' command is *not* ran (i.e. the driver never accesses the
I/O port BARs).

Using a SATA controller I have access to as an example for the details
(Note: I do not have access to a system with the Marvell 9125 device):
  00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port  SATA AHCI Controller (rev 06) (prog-if 01 [AHCI 1.0])
  Subsystem: Lenovo Device 2168
  Region 0: I/O ports at 1860 [size=8]
  Region 1: I/O ports at 1814 [size=4]
  Region 2: I/O ports at 1818 [size=8]
  Region 3: I/O ports at 1810 [size

Re: [PATCH] udevadm-info: Don't access sysfs 'resource' files

Robert Hancock — 2013-03-19T03:08:37

Well, clearly not. Although accessing this file with grep, etc. is
really just another way root can shoot themselves in the foot, it
would be nice if this functionality could be provided in a way that
didn't leave this kind of exposed land mine.
--
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

Re: [PATCH] udevadm-info: Don't access sysfs 'resource' files

Alex Williamson — 2013-03-18T17:54:47

The expectation is that the user doesn't mess with the device through
pci-sysfs while it's running.  This is really no different than config
space or MMIO space in that respect.  You can use setpci to break your
PCI card while it's used by the driver today.  The difference is that
MMIO spaces side-step the issue by only allowing mmap and config space
is known not to have read side-effects.


Never underestimate how broken hardware can be, though in this case
reading a device register seems to be causing a system hang/reset.


That doesn't really solve anything though.  Let's pretend the resource
files only work while the device is bound to pci-stub.  Now what happens
when you run this udevadm command as admin while it's in use by the
userspace driver?  All we've done is limit the scope of the problem.


Yes, if these are dead registers, let's blacklist and move along.  I
suspect though that these registers probably work fine if you access
them according to the device programming model, so blacklisting just

Re: [PATCH] udevadm-info: Don't access sysfs 'resource' files

Alex Williamson — 2013-03-17T22:28:48

That may be true of our AHCI driver, but when it's assigned to a guest
we're potentially using a completely different stack and cannot make
that assumption.  A guest running in compatibility mode or the option
ROM for the device may still use I/O port regions.  Thanks,

Alex


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