gmane.linux.hotplug.devel

Re: bus id match

Hannes Reinecke — 2012-05-22T13:09:10

You can't rename network interfaces in state 'UP'.
That only works for unconfigured interfaces.

Cheers,

Hannes

bus id match

Michal Filka — 2012-05-22T13:07:14

Hi,

I've problem with following rule (simplified as much as possible):

# replaced 70-persistent-net.rules
SUBSYSTEM=="net", KERNELS="0000:00:19.0", NAME="eth1"

#  udevadm test --action=add /sys/class/net/eth0
(snip)
rename_netif: changing net interface name from 'eth0' to 'eth1'
rename_netif: error changing net interface name eth0 to eth1: Device or  
resource busy
(snip)
UDEV_LOG=6
DEVPATH=/devices/pci0000:00/0000:00:19.0/net/eth0
INTERFACE=eth0
IFINDEX=2
ACTION=add
SUBSYSTEM=net
ID_VENDOR_FROM_DATABASE=Intel Corporation
ID_MODEL_FROM_DATABASE=82566DC Gigabit Network Connection
ID_BUS=pci
ID_VENDOR_ID=0x8086
ID_MODEL_ID=0x104b
ID_MM_CANDIDATE=1
SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth1
TAGS=:systemd:

So, the device is named correctly (eth1), but what about that rename_netif  
errors? Is that a problem?


Michal Filka
--
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/majordom

Re: udev, net device alias

Hannes Reinecke — 2012-05-22T10:14:21

Here holds the Highlander-Mantra:

There can only be one.

Network devices do not have symlinks, but rather live in the kernel
namespace. And the name is the primary key for finding this device.
To have network device aliases you would need to implement an
additional infrastructure within the kernel.

And get that past Dave Miller :-)

Cheers,

Hannes

udev, net device alias

Michal Filka — 2012-05-22T10:08:58

Hi,

is it possible to create an alias for an ethernet device using udev rules?  
E.g. to have eth0 accessible even as "eth0" and "eth-alias" at the same  
time.

Thanks for info
Michal Filka
--
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

Missing ID_BUS, ID_TYPE

John Frankish — 2012-05-21T05:48:01

Ref (udev-173)

$ udevadm info -q env -n /dev/sda
DEVPATH=/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda
MAJOR=8
MINOR=0
DEVNAME=/dev/sda
DEVTYPE=disk
SUBSYSTEM=block
ID_PATH=pci-0000:00:1f.2-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_1f_2-scsi-0_0_0_0
DEVLINKS=/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0

I would expect something like "ID_BUS=ata" and "ID_TYPE=disk" to be returned, but they are not.

What controls the reporting of ID_BUS and ID_TYPE?

Regards
John
--
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: Inconsistences using GUdev.Client

Martin Pitt — 2012-05-06T12:55:53

Hello again,

Martin Pitt [2012-05-05 14:42 -0700]:

For the record, all done now:

http://git.gnome.org/browse/pygobject/commit/?id=f2494526e1c
http://git.gnome.org/browse/pygobject/commit/?id=8321af2c7df
http://git.gnome.org/browse/pygobject/commit/?id=9f50fd214e4

However, setting GStrv properties in the constructor has already
worked before.

Martin

Re: Inconsistences using GUdev.Client

Martin Pitt — 2012-05-05T21:42:02

David Zeuthen [2012-04-12 11:32 -0400]:

Is that still the case? I just tried this with current PyGObject
3.2.0, and it seems to work:

$ python
['usb']

I also tested with "GUdev.Client(subsystems=['usb'])", i. e. using the
GObject constructor instead of gudev_client_new(), and it works just
as well.

I am just committing test cases for handling GStrv properties to g-i
and pygobject, and indeed a few cases don't work yet (such as defining
GStrv properties in Python, and _setting_ GStrv properties). I'm
working my way through fixing those.

Thanks,

Martin

Re: modprobe.d question.

Kay Sievers — 2012-05-03T14:58:37

Poor choice. :)


Right, that's the generic SYSV style, and should work.


No, that makes no sense. modprobe config is only read if modprobe is
called, but nothing will call it. And 'install' instructions are a
very broken concept, and should not be used. Besides the fact that the
above would not work anyway, because it would never be triggered.


That should work fine on Debian, just add it there.


That does not matter.


It needs to support /etc/modules, which is a Debian-specific file.

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

modprobe.d question.

F. Heitkamp — 2012-05-03T12:22:47

I have a module that I want to have installed during the boot process 
(fbcon) but I can't figure out what the standard practice would be to do it.

I am still using SYSV init as well.

The brute force approach would be to just write a shell script that 
executes during the boot process.

 From what I understand reading docs what adding install fbcon modprobe 
-v fbcon  to  a conf file in modprobe.d  (say I called it fbcon.conf ) 
would do is if the hot-plugging needed fbcon it would use fbcon.conf 
instead.

I am most familiar with debian and there is a file called /etc/modules 
that lists modules to be installed during boot, but I think the magic of 
modprobe is not used so the dependencies would not get included.

I am not using a initial ram disk.

This is on a "linux from scratch" like system, but not LFS.

Any corrections or thoughts?

Fred



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

[PATCH] fxload: Add support for loading FX3 RAM

Steven J. Magnani — 2012-04-27T20:20:04

Adds the ability to load a single-stage Cypress ".img" file
to FX3 RAM. The tweaks Cypress made to the download protocol
to support the FX3 are described here:

  http://www.cypress.com/?app=forum&id=167&rID=53996

The FX3 .img format is described in the FX3 Programmer's Manual,
provided with the EZ-USB FX3 Software Development Kit.

Signed-off-by: Steven J. Magnani <steve< at >digidescorp.com>
---
diff -uprN fxload-cvs/ezusb.c fxload-fx3/ezusb.c
--- fxload-cvs/ezusb.c2012-04-27 12:47:44.856752994 -0500
+++ fxload-fx3/ezusb.c2012-04-27 14:45:50.083897780 -0500
< at >< at > -2,6 +2,7 < at >< at >
  * Copyright (c) 2001 Stephen Williams (steve< at >icarus.com)
  * Copyright (c) 2001-2002 David Brownell (dbrownell< at >users.sourceforge.net)
  * Copyright (c) 2008 Roger Williams (rawqux< at >users.sourceforge.net)
+ * Copyright (c) 2012 Steve Magnani (steve< at >digidescorp.com)
  *
  *    This source code is free software; you can redistribute it
  *    and/or modify it in source code form under the terms of the GNU
< at >< at > -22,10 +23,13 < at >< at >
 
 # include  <s

Re: udev missing events?

Frank Ch. Eigler — 2012-04-27T13:59:49

Jim Paris <jim< at >jtan.com> writes:


By the way, your monitor.stp contains this bit:

   /* I don't know how to do this better, indexing envp
   if ($env->envp_idx > 0) printf("  %s\n", $env->envp[0]$)
   if ($env->envp_idx > 1) printf("  %s\n", $env->envp[1]$)
   [...]
   if ($env->envp_idx > 9) printf("  %s\n", $env->envp[9]$)
   if ($env->envp_idx > 10) printf("..... more\n")

More idiomatic would be as follows (stap version 0.9.9+):

   for (i=0; i<$env->envp_idx; i++) {
       printf("  %s\n", $env->envp[i]$)
   }

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

udev global properties

John Sheu — 2012-04-24T08:35:36

I'm noticing that udev global properties (e.g. those set with "udevadm
control --property=KEY=VALUE") aren't propagated to the udev device
database, so, for example, they don't show up when using "udevadm
info".  Is there a particular reason we do this?

Thanks,
-John Sheu
--
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: udev missing events?

Jim Paris — 2012-04-22T16:54:01

Yeah.


The specific problem is that virt-manager loses its connection to
libvirt.  Libvirt triggers this situation, and then later executes
"udevadm settle" after some of virt-manager's storage requests.  I
think that happens in one thread, while another libvirt thread then
kills the virt-manager connection for stalling for so long.

I can certainly ask the libvirt guys to add a shorter --timeout
parameter, at the very least, if this isn't considered a bug from the
udev point of view.  But libvirt isn't the only thing that calls
"udevadm settle" -- having to wait 2-3 minutes for each settle call
during an initramfs build or similar would also be annoying.


I upgraded libvirt and the kernel lately, so either some of this lxc
probing code in libvirt is new, or maybe my kernel didn't support net
namespaces before.  Libvirt has called udevadm settle for a while,
though.

Thanks,
-jim
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo< at >vger.kernel.o

Re: udev missing events?

Jim Paris — 2012-04-22T14:11:06

I'm not using them on purpose, but it's caused by a probing clone() in
libvirt's lxcContainerAavilable, followed by a "ip link set lo netns -1"
in lxcCheckNetNsSupport.  It can be recreated with just:

  #include <unistd.h>
  #include <sched.h>
  static int dummy(void *argv) { _exit(0); }
  main() {
          char stack[4096];
          clone(dummy, stack+4096, CLONE_NEWNET, NULL);
          wait();
          system("ip link set lo netns -1");
  }

Running that program causes "udevadm settle" to stop working due to
the filtered events.

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

udev missing events?

Jim Paris — 2012-04-22T04:36:55

(cc'd Eric and Milan because 5f71a296 and ebf4127c might be related)

I'm trying to track down a problem that started with virt-manager not
being able to connect to libvirtd.  Long story short, the problem is
that "udevadm settle" is timing out, with no events in the udev queue.

(I know it's bad for libvirt to rely on "udevadm settle", but it seems
that this is exposing some other problem).

This is with 3.2.14 from Debian.

I can trigger the problem easily by just starting libvirtd and killing
it.  Then, the counters are stuck here:

  # cat /sys/kernel/uevent_seqnum
  13593
  # od -t d2 /dev/.udev/queue.bin | head -1
  0000000  13592

During the libvirtd startup, I ran "udevadm monitor", which seems to
indicate that 13593 never made it to udev:

 # udevadm monitor --kernel --property
  monitor will print the received events for:
  KERNEL - the kernel uevent
  
  KERNEL[537903.765581] add      /devices/virtual/net/lo/queues/rx-0 (queues)
  ACTION=add
  DEVPATH=/devices/virtual/net/lo/queues/rx-0
  SEQNUM=1

"udevadm info --attribute-walk --path=/block/sda" doesn't show parents

Chris Friesen — 2012-04-18T21:42:59

I have a 2.6.34.10-based kernel with udev-161 (also tested with udevadm from udev-173).

When I run "udevadm info --attribute-walk --path=/block/sda" it just shows the device
itself, and doesn't walk the whole chain showing the parents.

Is there anything I can do, or am I caught with a kernel that isn't properly supported?
I'm not subscribed to the hotplug list, so cc'ing me would be appreciated.


I don't know what's causing the problem, but I find it suspicious that /sys/block/sda
is a directory rather than a symlink like it is on my 2.6.35.14 laptop.  I'm poking
around in the udevadm code now.


Some possibly-useful information:


root< at >typhoon-base-unit0:/root> udevadm info --attribute-walk --path=/block/sda

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single par

Re: /dev/shm and /dev/pts not been created by devtmpfs or udev

F. Heitkamp — 2012-04-19T03:20:23

Sorry.  The devices directory is "/lib/udev/devices".

udev seems to be mostly working AFAICT.  When I plug/unplug USB or 
firewire, I can see events being processed with udevadm monitor.

There is no shm or pts directory shown in /proc/devices.  Should there be?

There is also lots of information in the /run directory tree.

Fred

--
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: "udevadm info --attribute-walk --path=/block/sda" doesn't show parents

Kay Sievers — 2012-04-18T22:41:03

On old kernels, the chain of parent devices was not always properly
exported, because the "struct class_device" created all device
directories and spread spread them all over the the /sys/class tree.
There was a "device" link created at these disconnected device
directories, which udev tried to follow to find the parents.

We cleaned that up that mess, by having a single and unified tree in
/sys/devices, and /sys/class and /sys/bus just have symlinks pointing
into that tree. "Hierarchy" vs. "classification" are properly
separated that way.

For a while the CONFIG_SYSFS_DEPRECATED controlled the behaviour, you
might check if that is available in your kernel and can be turned off
to switch to the unified hierarchy. I kind of lost track which kernel
versions did what here.

In general, if you need the more recent udev tools to work regarding
the chain of parents, which "udevadm info --attribute-walk" uses, you
need a newer kernel, which exports that natively. There is no support
for the "device" link in newer

Re: "udevadm info --attribute-walk --path=/block/sda" doesn't show parents

Chris Friesen — 2012-04-18T22:13:08

Looking at the udevadm code led me to the following:

On the problematic 2.6.34 machine:

root< at >typhoon-base-unit0:/root> ls -l /sys/dev/block/
<snip>
lrwxrwxrwx 1 root root 0 Apr 18 14:34 8:0 -> ../../block/sda



On my 2.6.35 machine:

[cfriesen< at >blah udev-173]$ ls -l /sys/dev/block/
<snip>
lrwxrwxrwx. 1 root root 0 Apr 18 15:54 8:0 -> ../../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda



So where do I go from here?  Is there a simple kernel change to make my 2.6.34
kernel behave more like the more recent one?  Would an older version of udev be
able to parse my 2.6.34 /sys directory properly, or do I need to figure out a
way to parse /sys manually?

Thanks,
Chris

Re: /dev/shm and /dev/pts not been created by devtmpfs or udev

Kay Sievers — 2012-04-18T14:37:47

Udev uses /lib/udev/. never libexec/, (/usr)/lib/udev/ is a de-facto
API and should not be changed.

"strace udevd" might show what goes wrong on your box.

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

Re: /dev/shm and /dev/pts not been created by devtmpfs or udev

Marco d'Itri — 2012-04-18T13:45:07

Please ask on the appropriate users support forum/mailing list/newsgroup
/whaterver for your distribution.