* Re: systemd-183
From: Kay Sievers @ 2012-05-27 11:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4FBE8DC4.1070202@gmail.com>
On Sun, May 27, 2012 at 5:19 AM, Karl O. Pinc <kop@meme.com> wrote:
> On 05/26/2012 07:54:51 PM, William Hubbs wrote:
>
>> I have the same questions. I don't want to do a full systemd build
>> just
>> to install udev. Is there some way to build udev only?
>
> I don't recall how to do it, but when the merge into systemd
> was announced there were instructions for building just udev.
>
> See the mailing list archives.
We support stand-alone *operation* of the udev tools, but the build
system does not support a stand-alone *build*. The systemd tree needs
to be built and udev picked out of it.
There are also several other generally useful tools in the built tree,
which you might need too over time, like tmpfiles, module-load,
sysconf, binfmt, ... A couple of D-Bus services to manage system
settings from the desktop.
Various upstream tools start to install config files or use these
interfaces. It might be the simplest to install them too, even when
systemd is not used.
Kay
^ permalink raw reply
* Re: systemd-183
From: Karl O. Pinc @ 2012-05-27 4:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4FBE8DC4.1070202@gmail.com>
On 05/26/2012 10:38:30 PM, Bruce Dubbs wrote:
> I looked at the systemd mailing list and I cannot find any such
> instructions. The announce message was only yesterday.
>
> I'd appreciate a pointer.
The udev mailing list: linux-hotplug@vger.kernel.org
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply
* Re: systemd-183
From: Bruce Dubbs @ 2012-05-27 3:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4FBE8DC4.1070202@gmail.com>
Karl O. Pinc wrote:
> On 05/26/2012 07:54:51 PM, William Hubbs wrote:
>
>> I have the same questions. I don't want to do a full systemd build
>> just
>> to install udev. Is there some way to build udev only?
>
> I don't recall how to do it, but when the merge into systemd
> was announced there were instructions for building just udev.
>
> See the mailing list archives.
I looked at the systemd mailing list and I cannot find any such
instructions. The announce message was only yesterday.
I'd appreciate a pointer.
The announcement I found was on the freedesktop.org systemd-devel list.
Is this mailing list going to be abandoned?
-- Bruce
^ permalink raw reply
* Re: systemd-183
From: Karl O. Pinc @ 2012-05-27 3:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4FBE8DC4.1070202@gmail.com>
On 05/26/2012 07:54:51 PM, William Hubbs wrote:
> I have the same questions. I don't want to do a full systemd build
> just
> to install udev. Is there some way to build udev only?
I don't recall how to do it, but when the merge into systemd
was announced there were instructions for building just udev.
See the mailing list archives.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
^ permalink raw reply
* Re: systemd-183
From: William Hubbs @ 2012-05-27 0:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4FBE8DC4.1070202@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
On Thu, May 24, 2012 at 02:36:36PM -0500, Bruce Dubbs wrote:
> I see that systemd-183 is out in the
> http://www.freedesktop.org/software/systemd/ repository.
>
> My understanding is that this version of systemd has udev included.
>
> I've looked through the NEWS, README, and ./configure --help.
I have the same questions. I don't want to do a full systemd build just
to install udev. Is there some way to build udev only?
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH V2] rules: Limit USB autosuspend on USB HID devices
From: Matthew Garrett @ 2012-05-25 14:27 UTC (permalink / raw)
To: linux-hotplug
Some USB ports on external hubs may be reported as "fixed". We only want
to auto-enable this on ports that are internal to the machine, so check
the parent state as well.
---
Sorry, screwed up the label name on the first version.
rules/42-usb-hid-pm.rules | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index d5d5897..9e5f59f 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
@@ -46,4 +46,10 @@ ACTION="add", SUBSYSTEM="usb", ATTRS{idVendor}="04b3", ATTR{idProduct}="4012
ACTION="add", SUBSYSTEM="usb", ATTR{idVendor}="14dd", ATTR{idProduct}="0002", TEST="power/control", ATTR{power/control}="auto"
# USB HID devices that are internal to the machine should also be safe to autosuspend
+
+ACTION="add", SUBSYSTEM="usb", SUBSYSTEMS="usb", ATTRS{removable}="removable", GOTO="usb_hid_pm_end"
+ACTION="add", SUBSYSTEM="usb", SUBSYSTEMS="usb", ATTRS{removable}="unknown", GOTO="usb_hid_pm_end"
+
ACTION="add", SUBSYSTEM="usb", ATTR{bInterfaceClass}="03", ATTRS{removable}="fixed", TEST="../power/control", ATTR{../power/control}="auto"
+
+LABEL="usb_hid_pm_end"
\ No newline at end of file
--
1.7.10.2
^ permalink raw reply related
* [PATCH] rules: Limit USB autosuspend on USB HID devices
From: Matthew Garrett @ 2012-05-25 12:01 UTC (permalink / raw)
To: linux-hotplug
Some USB ports on external hubs may be reported as "fixed". We only want
to auto-enable this on ports that are internal to the machine, so check
the parent state as well.
---
rules/42-usb-hid-pm.rules | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index d5d5897..fc44b94 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
@@ -46,4 +46,10 @@ ACTION="add", SUBSYSTEM="usb", ATTRS{idVendor}="04b3", ATTR{idProduct}="4012
ACTION="add", SUBSYSTEM="usb", ATTR{idVendor}="14dd", ATTR{idProduct}="0002", TEST="power/control", ATTR{power/control}="auto"
# USB HID devices that are internal to the machine should also be safe to autosuspend
+
+ACTION="add", SUBSYSTEM="usb", SUBSYSTEMS="usb", ATTRS{removable}="removable", GOTO="usb_hid_pm_end"
+ACTION="add", SUBSYSTEM="usb", SUBSYSTEMS="usb", ATTRS{removable}="unknown", GOTO="usb_hid_pm_end"
+
ACTION="add", SUBSYSTEM="usb", ATTR{bInterfaceClass}="03", ATTRS{removable}="fixed", TEST="../power/control", ATTR{../power/control}="auto"
+
+LABEL="usb_add_pm_end"
\ No newline at end of file
--
1.7.10.2
^ permalink raw reply related
* systemd-183
From: Bruce Dubbs @ 2012-05-24 19:36 UTC (permalink / raw)
To: linux-hotplug
I see that systemd-183 is out in the
http://www.freedesktop.org/software/systemd/ repository.
My understanding is that this version of systemd has udev included.
I've looked through the NEWS, README, and ./configure --help.
How do I build udev without systemd? Failing that, how do I install
just udev without systend?
Or will there be a separate udev distribution?
-- Bruce Dubbs
Linux From Scratch
^ permalink raw reply
* Re: bus id match
From: Hannes Reinecke @ 2012-05-22 13:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <op.wepn2cfimcnq8x@idontknow.suse.cz>
On 05/22/2012 03:07 PM, Michal Filka wrote:
> 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≠d /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≠d
> SUBSYSTEM=net
> ID_VENDOR_FROM_DATABASE=Intel Corporation
> ID_MODEL_FROM_DATABASEÇ566DC 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?
>
You can't rename network interfaces in state 'UP'.
That only works for unconfigured interfaces.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* bus id match
From: Michal Filka @ 2012-05-22 13:07 UTC (permalink / raw)
To: linux-hotplug
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 --actiond /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
ACTIONd
SUBSYSTEM=net
ID_VENDOR_FROM_DATABASE=Intel Corporation
ID_MODEL_FROM_DATABASE‚566DC 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
^ permalink raw reply
* Re: udev, net device alias
From: Hannes Reinecke @ 2012-05-22 10:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <op.wepfs8aqmcnq8x@idontknow.suse.cz>
On 05/22/2012 12:08 PM, Michal Filka wrote:
> 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.
>
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
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
^ permalink raw reply
* udev, net device alias
From: Michal Filka @ 2012-05-22 10:08 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply
* Missing ID_BUS, ID_TYPE
From: John Frankish @ 2012-05-21 5:48 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply
* Re: Inconsistences using GUdev.Client
From: Martin Pitt @ 2012-05-06 12:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABpL_NdACqSWGs+oepbR4KpeDWu5wBseWBKbwSb5mZ3vvpENKA@mail.gmail.com>
Hello again,
Martin Pitt [2012-05-05 14:42 -0700]:
> 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.
For the record, all done now:
http://git.gnome.org/browse/pygobject/commit/?idò494526e1c
http://git.gnome.org/browse/pygobject/commit/?idƒ21af2c7df
http://git.gnome.org/browse/pygobject/commit/?idŸ50fd214e4
However, setting GStrv properties in the constructor has already
worked before.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: Inconsistences using GUdev.Client
From: Martin Pitt @ 2012-05-05 21:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABpL_NdACqSWGs+oepbR4KpeDWu5wBseWBKbwSb5mZ3vvpENKA@mail.gmail.com>
David Zeuthen [2012-04-12 11:32 -0400]:
> I think the python bindings are just buggy - probably they don't
> support GStrv GObject properties very well.
Is that still the case? I just tried this with current PyGObject
3.2.0, and it seems to work:
$ python
>>> from gi.repository import GUdev
>>> c = GUdev.Client.new(subsystems=['usb'])
>>> c.props.subsystems
['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
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: modprobe.d question.
From: Kay Sievers @ 2012-05-03 14:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4FA27897.6020409@ameritech.net>
On Thu, May 3, 2012 at 2:22 PM, F. Heitkamp <heitkamp@ameritech.net> wrote:
> 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.
Poor choice. :)
> The brute force approach would be to just write a shell script that executes
> during the boot process.
Right, that's the generic SYSV style, and should work.
> 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.
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.
> 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.
That should work fine on Debian, just add it there.
> I am not using a initial ram disk.
That does not matter.
> This is on a "linux from scratch" like system, but not LFS.
It needs to support /etc/modules, which is a Debian-specific file.
Kay
^ permalink raw reply
* modprobe.d question.
From: F. Heitkamp @ 2012-05-03 12:22 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply
* [PATCH] fxload: Add support for loading FX3 RAM
From: Steven J. Magnani @ 2012-04-27 20:20 UTC (permalink / raw)
To: linux-hotplug
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\x167&rIDS996
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@digidescorp.com>
---
diff -uprN fxload-cvs/ezusb.c fxload-fx3/ezusb.c
--- fxload-cvs/ezusb.c 2012-04-27 12:47:44.856752994 -0500
+++ fxload-fx3/ezusb.c 2012-04-27 14:45:50.083897780 -0500
@@ -2,6 +2,7 @@
* Copyright (c) 2001 Stephen Williams (steve@icarus.com)
* Copyright (c) 2001-2002 David Brownell (dbrownell@users.sourceforge.net)
* Copyright (c) 2008 Roger Williams (rawqux@users.sourceforge.net)
+ * Copyright (c) 2012 Steve Magnani (steve@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
@@ -22,10 +23,13 @@
# include <stdio.h>
# include <errno.h>
+# include <fcntl.h>
# include <assert.h>
# include <limits.h>
+# include <stdint.h>
# include <stdlib.h>
# include <string.h>
+# include <unistd.h>
# include <sys/ioctl.h>
@@ -33,6 +37,11 @@
# include <linux/usb/ch9.h>
# include <linux/usbdevice_fs.h>
+#ifndef _BSD_SOURCE
+#define _BSD_SOURCE
+#endif
+#include <endian.h>
+
# include "ezusb.h"
extern void logerror(const char *format, ...)
@@ -63,7 +72,7 @@ int verbose;
* return true iff [addr,addr+len) includes external RAM
* for Anchorchips EZ-USB or Cypress EZ-USB FX
*/
-static int fx_is_external (unsigned short addr, size_t len)
+static int fx_is_external (unsigned int addr, size_t len)
{
/* with 8KB RAM, 0x0000-0x1b3f can be written
* we can't tell if it's a 4KB device here
@@ -82,7 +91,7 @@ static int fx_is_external (unsigned shor
* return true iff [addr,addr+len) includes external RAM
* for Cypress EZ-USB FX2
*/
-static int fx2_is_external (unsigned short addr, size_t len)
+static int fx2_is_external (unsigned int addr, size_t len)
{
/* 1st 8KB for data/code, 0x0000-0x1fff */
if (addr <= 0x1fff)
@@ -101,7 +110,7 @@ static int fx2_is_external (unsigned sho
* return true iff [addr,addr+len) includes external RAM
* for Cypress EZ-USB FX2LP
*/
-static int fx2lp_is_external (unsigned short addr, size_t len)
+static int fx2lp_is_external (unsigned int addr, size_t len)
{
/* 1st 16KB for data/code, 0x0000-0x3fff */
if (addr <= 0x3fff)
@@ -117,6 +126,25 @@ static int fx2lp_is_external (unsigned s
}
/*****************************************************************************/
+/*
+ * Read num_bytes from fd into buf.
+ * Report any errors.
+ */
+int read_fd(int fd, void *buf, size_t num_bytes)
+{
+ ssize_t bytes_read = read(fd, buf, num_bytes);
+
+ if (bytes_read != num_bytes) {
+ if (bytes_read < 0)
+ logerror("Error reading file: %s\n", strerror(errno));
+ else
+ logerror("Truncated file\n");
+ }
+
+ return (bytes_read = num_bytes);
+}
+
+/*****************************************************************************/
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,3)
/*
@@ -214,17 +242,17 @@ static int ezusb_write (
int device,
char *label,
unsigned char opcode,
- unsigned short addr,
+ unsigned int addr,
const unsigned char *data,
size_t len
) {
int status;
if (verbose)
- logerror("%s, addr 0x%04x len %4zd (0x%04zx)\n", label, addr, len, len);
+ logerror("%s, addr 0x%05x len %4zd (0x%04zx)\n", label, addr, len, len);
status = ctrl_msg (device,
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, opcode,
- addr, 0,
+ addr & 0xFFFF, addr >> 16,
(unsigned char *) data, len);
if (status != len) {
if (status < 0)
@@ -296,8 +324,8 @@ static inline int ezusb_get_eeprom_type
int parse_ihex (
FILE *image,
void *context,
- int (*is_external)(unsigned short addr, size_t len),
- int (*poke) (void *context, unsigned short addr, int external,
+ int (*is_external)(unsigned int addr, size_t len),
+ int (*poke) (void *context, unsigned int addr, int external,
const unsigned char *data, size_t len)
)
{
@@ -430,6 +458,90 @@ int parse_ihex (
return 0;
}
+/*
+ * Parse a FX3 '.img' file and invoke the poke() function on the
+ * various segments to implement policies such as writing to RAM (with
+ * a one or two stage loader setup, depending on the firmware) or to
+ * EEPROM (two stages required).
+ *
+ * img_fd - the image file
+ * context - for use by poke()
+ * poke - called with each memory segment; errors indicated
+ * by returning negative values.
+ *
+ * Caller is responsible for halting CPU as needed, such as when
+ * overwriting a second stage loader.
+ */
+int parse_img (
+ int img_fd,
+ void *context,
+ int (*poke) (void *context, unsigned int addr, int external,
+ const unsigned char *data, size_t len)
+)
+{
+ unsigned char header[4];
+ unsigned char data[4096];
+ int rc = -1;
+
+ /* Validate the header */
+ if (!read_fd(img_fd, header, sizeof(header)))
+ return -1;
+
+ if ((header[0] != 'C') || (header[1] != 'Y')) {
+ logerror("Invalid file: missing CYpress signature\n");
+ return -1;
+ }
+
+ if (header[3] != 0xB0) {
+ logerror("Invalid file: format 0x%02X, expected 0xB0\n", header[3]);
+ return -1;
+ }
+
+ /* Now process data segments */
+ do {
+ uint32_t segment_addr, cur_addr;
+ uint32_t segment_len, bytes_remaining, bytes_this_chunk;
+
+ rc = -1; /* In case of error */
+ if (!read_fd(img_fd, &segment_len, sizeof(segment_len)))
+ break;
+
+ if (!read_fd(img_fd, &segment_addr, sizeof(segment_addr)))
+ break;
+
+ segment_len = le32toh(segment_len) << 2;
+ segment_addr = le32toh(segment_addr);
+
+ cur_addr = segment_addr;
+ bytes_remaining = segment_len;
+
+ /* Make sure we poke() if segment_len = 0,
+ * as FX3 interprets this as a "run from address" command
+ */
+
+ do {
+ bytes_this_chunk = bytes_remaining;
+ if (bytes_this_chunk > sizeof(data))
+ bytes_this_chunk = sizeof(data);
+
+ if (bytes_this_chunk && !read_fd(img_fd, data, bytes_this_chunk)) {
+ rc = -1;
+ break;
+ }
+
+ rc = poke (context, cur_addr, 0, data, bytes_this_chunk);
+
+ cur_addr += bytes_this_chunk;
+ bytes_remaining -= bytes_this_chunk;
+ } while ((rc = 0) && (bytes_remaining > 0));
+
+ if (segment_len = 0)
+ break;
+
+ } while (rc = 0);
+
+ return rc;
+}
/*****************************************************************************/
@@ -454,7 +566,7 @@ struct ram_poke_context {
static int ram_poke (
void *context,
- unsigned short addr,
+ unsigned int addr,
int external,
const unsigned char *data,
size_t len
@@ -466,7 +578,7 @@ static int ram_poke (
switch (ctx->mode) {
case internal_only: /* CPU should be stopped */
if (external) {
- logerror("can't write %zd bytes external memory at 0x%04x\n",
+ logerror("can't write %zd bytes external memory at 0x%05x\n",
len, addr);
return -EINVAL;
}
@@ -474,7 +586,7 @@ static int ram_poke (
case skip_internal: /* CPU must be running */
if (!external) {
if (verbose >= 2) {
- logerror("SKIP on-chip RAM, %zd bytes at 0x%04x\n",
+ logerror("SKIP on-chip RAM, %zd bytes at 0x%05x\n",
len, addr);
}
return 0;
@@ -483,7 +595,7 @@ static int ram_poke (
case skip_external: /* CPU should be stopped */
if (external) {
if (verbose >= 2) {
- logerror("SKIP external RAM, %zd bytes at 0x%04x\n",
+ logerror("SKIP external RAM, %zd bytes at 0x%05x\n",
len, addr);
}
return 0;
@@ -513,6 +625,51 @@ static int ram_poke (
}
/*
+ * Load a FX3 'img' file into target RAM. The dev_fd is the open "usbfs"
+ * device, and the path is the name of the source file. Open the file,
+ * parse the bytes, and write them in one or two phases.
+ *
+ * This uses the first stage loader, built into FX3 hardware but limited
+ * to writing on-chip memory. Everything is written during one stage.
+ */
+static int fx3_load_ram (int dev_fd, const char *path, int stage)
+{
+ int image_fd;
+ struct ram_poke_context ctx;
+ int status;
+
+ if (stage != 0) {
+ logerror("Two-stage load not yet supported for FX3\n");
+ return -1;
+ }
+
+ image_fd = open(path, O_RDONLY);
+ if (image_fd < 0) {
+ logerror("%s: unable to open for input.\n", path);
+ return -2;
+ } else if (verbose)
+ logerror("open RAM image %s\n", path);
+
+ ctx.device = dev_fd;
+ ctx.total = 0;
+ ctx.count = 0;
+ ctx.mode = internal_only;
+
+ status = parse_img(image_fd, &ctx, ram_poke);
+ if (status < 0) {
+ logerror("unable to download %s\n", path);
+ return status;
+ }
+
+ if (verbose) {
+ logerror("... WROTE: %d bytes, %d segments, avg %d\n",
+ ctx.total, ctx.count, ctx.total / ctx.count);
+ }
+
+ return 0;
+}
+
+/*
* Load an Intel HEX file into target RAM. The fd is the open "usbfs"
* device, and the path is the name of the source file. Open the file,
* parse the bytes, and write them in one or two phases.
@@ -526,14 +683,19 @@ static int ram_poke (
* memory is written, expecting a second stage loader to have already
* been loaded. Then file is re-parsed and on-chip memory is written.
*/
-int ezusb_load_ram (int fd, const char *path, int fx2, int stage)
+int ezusb_load_ram (int fd, const char *path, const char *type, int stage)
{
FILE *image;
unsigned short cpucs_addr;
- int (*is_external)(unsigned short off, size_t len);
+ int (*is_external)(unsigned int off, size_t len);
struct ram_poke_context ctx;
int status;
+ /* FX3 loading differs significantly from that of previous devices */
+ if (strcmp(type, "fx3") = 0)
+ return fx3_load_ram (fd, path, stage);
+
+
image = fopen (path, "r");
if (image = 0) {
logerror("%s: unable to open for input.\n", path);
@@ -542,10 +704,10 @@ int ezusb_load_ram (int fd, const char *
logerror("open RAM hexfile image %s\n", path);
/* EZ-USB original/FX and FX2 devices differ, apart from the 8051 core */
- if (fx2 = 2) {
+ if (strcmp(type, "fx2lp") = 0) {
cpucs_addr = 0xe600;
is_external = fx2lp_is_external;
- } else if (fx2) {
+ } else if (strcmp(type, "fx2") = 0) {
cpucs_addr = 0xe600;
is_external = fx2_is_external;
} else {
@@ -622,7 +784,7 @@ struct eeprom_poke_context {
static int eeprom_poke (
void *context,
- unsigned short addr,
+ unsigned int addr,
int external,
const unsigned char *data,
size_t len
@@ -633,7 +795,7 @@ static int eeprom_poke (
if (external) {
logerror(
- "EEPROM can't init %zd bytes external memory at 0x%04x\n",
+ "EEPROM can't init %zd bytes external memory at 0x%05x\n",
len, addr);
return -EINVAL;
}
@@ -683,11 +845,16 @@ int ezusb_load_eeprom (int dev, const ch
{
FILE *image;
unsigned short cpucs_addr;
- int (*is_external)(unsigned short off, size_t len);
+ int (*is_external)(unsigned int off, size_t len);
struct eeprom_poke_context ctx;
int status;
unsigned char value, first_byte;
+ if (strcmp ("fx3", type) = 0) {
+ logerror("FX3 EEPROM loading is not yet supported.\n");
+ return -1;
+ }
+
if (ezusb_get_eeprom_type (dev, &value) != 1 || value != 1) {
logerror("don't see a large enough EEPROM\n");
return -1;
@@ -726,7 +893,7 @@ int ezusb_load_eeprom (int dev, const ch
is_external = fx2lp_is_external;
ctx.ee_addr = 8;
config &= 0x4f;
- fprintf (stderr,
+ logerror (
"FX2LP: config = 0x%02x, %sconnected, I2C = %d KHz\n",
config,
(config & 0x40) ? "dis" : "",
diff -uprN fxload-cvs/ezusb.h fxload-fx3/ezusb.h
--- fxload-cvs/ezusb.h 2012-04-27 12:47:44.856752994 -0500
+++ fxload-fx3/ezusb.h 2012-04-27 13:54:00.930595226 -0500
@@ -3,6 +3,7 @@
/*
* Copyright (c) 2001 Stephen Williams (steve@icarus.com)
* Copyright (c) 2002 David Brownell (dbrownell@users.sourceforge.net)
+ * Copyright (c) 2012 Steve Magnani (steve@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
@@ -24,14 +25,16 @@
/*
* This function loads the firmware from the given file into RAM.
- * The file is assumed to be in Intel HEX format. If fx2 is set, uses
- * appropriate reset commands. Stage = 0 means this is a single stage
- * load (or the first of two stages). Otherwise it's the second of
- * two stages; the caller preloaded the second stage loader.
+ * The file is assumed to be in Intel HEX format unless type is fx3.
+ * If type is fx2 or fx2lp, appropriate reset commands are used.
+ * Stage = 0 means this is a single stage load (or the first of two stages).
+ * Otherwise it's the second of two stages; the caller preloaded the second
+ * stage loader.
*
* The target processor is reset at the end of this download.
*/
-extern int ezusb_load_ram (int dev, const char *path, int fx2, int stage);
+extern int ezusb_load_ram (int dev, const char *path, const char *type,
+ int stage);
/*
diff -uprN fxload-cvs/fxload.8 fxload-fx3/fxload.8
--- fxload-cvs/fxload.8 2012-04-27 12:47:44.856752994 -0500
+++ fxload-fx3/fxload.8 2012-04-27 13:37:30.059702926 -0500
@@ -23,7 +23,7 @@
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
-.TH FXLOAD 8 "September 2008" "" "Linux Programmer's Manual"
+.TH FXLOAD 8 "April 2012" "" "Linux Programmer's Manual"
.SH "NAME"
fxload \- Firmware download to EZ-USB devices
.SH "SYNOPSIS"
@@ -31,7 +31,7 @@ fxload \- Firmware download to EZ-USB de
.BI "[ \-v ]"
.BI "[ \-l ]"
.BI "[ \-D " devpath " ]"
-.BI "[ \-I " hexfile " ]"
+.BI "[ \-I " firmware " ]"
.BI "[ \-t " type " ]"
.BI "[ \-c " config " ]"
.BI "[ \-s " loader " ]"
@@ -47,14 +47,17 @@ fxload \- Firmware download to EZ-USB de
.B fxload
is a program which downloads firmware to USB devices based on
AnchorChips EZ-USB, Cypress EZ-USB FX,
-or Cypress EZ-USB FX2/FX2LP microcontrollers.
+or Cypress EZ-USB FX2/FX2LP/FX3 microcontrollers.
These have 8-bit 8051 cores with special extensions for USB I/O.
The FX2 supports high speed USB 2.0 transfers (480 Mbit/sec)
as well as full speed USB 1.1 transfers (12 Mbit/sec),
-while the earlier parts supports only full speed transfers.
+while the earlier parts support only full speed transfers.
+The FX3 supports super speed USB 3.0 transfers and has a 32-bit
+ARM core.
These controllers have several package options,
and can be set up with external memory (on-chip memory is
-usually 8K or 16K), EEPROMs, and ROMs when device costs allow.
+usually 8K or 16K; for FX3, it is 512K), EEPROMs, and ROMs when
+device costs allow.
.PP
This uses "usbfs" (older name: "usbdevfs") to access
devices, and issues vendor specific control requests
@@ -87,13 +90,16 @@ Note that as usual with UNIX and Linux c
the order of command option flags does not matter.
You may use these in any order.
.TP
-.BI "\-I " hexfile
+.BI "\-I " firmware
Downloads the specified firmware file.
-This firmware is provided in standard Intel hexfile format.
+For FX3 devices, the format is a Cypress-specific binary image.
+For other devices, the file has standard Intel hexfile format.
(Common naming conventions include
.I *.hex
-and
-.IR *.ihx .)
+,
+.I *.ihx
+, and
+.IR *.img ).
Depending on the device and firmware in use, the
.B \-s
option may also be necessary to specify a second stage loader.
@@ -146,8 +152,8 @@ After downloading to a device's EEPROM,
you should retest it starting from power off.
.TP
.BI "\-s " loader
-This identifies the hex file holding a second stage loader
-(in the same hex file format as the firmware itself),
+This identifies the file holding a second stage loader
+(in the same file format as the firmware itself),
which is loaded into internal memory.
This loader understands additional vendor control requests,
beyond the one built into all EZ-USB hardware,
@@ -163,13 +169,16 @@ type may be one of
.I an21
(the original AnchorChips devices),
.I fx
-(Cypress' updated version, the EZ-USB FX), or
+(Cypress' updated version, the EZ-USB FX),
.I fx2
-(the Cypress EZ-USB FX2, supporting high speed transfers), or
+(the Cypress EZ-USB FX2, supporting high speed transfers),
.I fx2lp
-(the Cypress EZ-USB FX2LP, with 16KB internal RAM).
+(the Cypress EZ-USB FX2LP, with 16KB internal RAM), or
+.I fx3
+(the Cypress EZ-USB FX3, supporting USB 3.0).
Except when writing to EEPROM, all that normally matters when
-downloading firmware is whether or not the device uses an FX2.
+downloading firmware is whether or not the device uses an FX2
+or FX3.
.TP
.B "\-v"
Prints some diagnostics, such as download addresses and sizes,
@@ -213,7 +222,7 @@ Similarly, a second stage loader that su
is needed when writing boot firmware into an I2C EEPROM.
These 0xA2 and 0xA3 vendor commands are conventions defined by Cypress.
Devices that use bank switching or similar mechanisms to stretch the
-64KByte address space may need different approach to loading firmware.
+64KByte address space may need different approaches to loading firmware.
.PP
Not all devices support EEPROM updates.
Some EZ-USB based devices don't have an I2C EEPROM;
diff -uprN fxload-cvs/main.c fxload-fx3/main.c
--- fxload-cvs/main.c 2012-04-27 12:47:44.856752994 -0500
+++ fxload-fx3/main.c 2012-04-27 13:12:30.785424048 -0500
@@ -2,6 +2,7 @@
* Copyright (c) 2001 Stephen Williams (steve@icarus.com)
* Copyright (c) 2001-2002 David Brownell (dbrownell@users.sourceforge.net)
* Copyright (c) 2008 Roger Williams (rawqux@users.sourceforge.net)
+ * Copyright (c) 2012 Steve Magnani (steve@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
@@ -28,7 +29,7 @@
* looking for the device.
*
* -I <path> -- Download this firmware (intel hex)
- * -t <type> -- uController type: an21, fx, fx2, fx2lp
+ * -t <type> -- uController type: an21, fx, fx2, fx2lp, fx3
* -s <path> -- use this second stage loader
* -c <byte> -- Download to EEPROM, with this config byte
*
@@ -148,6 +149,7 @@ int main(int argc, char*argv[])
&& strcmp (optarg, "fx") // updated Cypress versions
&& strcmp (optarg, "fx2") // Cypress USB 2.0 versions
&& strcmp (optarg, "fx2lp") // updated FX2
+ && strcmp (optarg, "fx3") // Cypress USB 3.0 versions
) {
logerror("illegal microcontroller type: %s\n", optarg);
goto usage;
@@ -192,7 +194,7 @@ usage:
fputs ("[-s loader] [-c config_byte]\n", stderr);
fputs ("\t\t[-L link] [-m mode]\n", stderr);
fputs ("... [-D devpath] overrides DEVICE= in env\n", stderr);
- fputs ("... device types: one of an21, fx, fx2, fx2lp\n", stderr);
+ fputs ("... device types: one of an21, fx, fx2, fx2lp, fx3\n", stderr);
fputs ("... at least one of -I, -L, -m is required\n", stderr);
return -1;
}
@@ -200,7 +202,6 @@ usage:
if (ihex_path) {
int fd = open(device_path, O_RDWR);
int status;
- int fx2;
if (fd = -1) {
logerror("%s : %s\n", strerror(errno), device_path);
@@ -209,11 +210,7 @@ usage:
if (type = 0) {
type = "fx"; /* an21-compatible for most purposes */
- fx2 = 0;
- } else if (strcmp (type, "fx2lp") = 0)
- fx2 = 2;
- else
- fx2 = (strcmp (type, "fx2") = 0);
+ }
if (verbose)
logerror("microcontroller type: %s\n", type);
@@ -222,7 +219,7 @@ usage:
/* first stage: put loader into internal memory */
if (verbose)
logerror("1st stage: load 2nd stage loader\n");
- status = ezusb_load_ram (fd, stage1, fx2, 0);
+ status = ezusb_load_ram (fd, stage1, type, 0);
if (status != 0)
return status;
@@ -230,14 +227,14 @@ usage:
if (config >= 0)
status = ezusb_load_eeprom (fd, ihex_path, type, config);
else
- status = ezusb_load_ram (fd, ihex_path, fx2, 1);
+ status = ezusb_load_ram (fd, ihex_path, type, 1);
if (status != 0)
return status;
} else {
/* single stage, put into internal memory */
if (verbose)
logerror("single stage: load on-chip memory\n");
- status = ezusb_load_ram (fd, ihex_path, fx2, 0);
+ status = ezusb_load_ram (fd, ihex_path, type, 0);
if (status != 0)
return status;
}
^ permalink raw reply
* Re: udev missing events?
From: Frank Ch. Eigler @ 2012-04-27 13:59 UTC (permalink / raw)
To: Jim Paris; +Cc: linux-hotplug, linux-kernel, Eric W. Biederman, Milan Broz
In-Reply-To: <20120422043655.GA27861@psychosis.jim.sh>
Jim Paris <jim@jtan.com> writes:
> [...]
> To try to track it further, I wrote a systemtap script (available at
> http://jim.sh/~jim/tmp/monitor.stp). It dumps the result of
> netlink_broadcast_filtered at lib/kobject_uevent.c:248 [...]
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
^ permalink raw reply
* udev global properties
From: John Sheu @ 2012-04-24 8:35 UTC (permalink / raw)
To: linux-hotplug
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
^ permalink raw reply
* Re: udev missing events?
From: Jim Paris @ 2012-04-22 16:54 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-hotplug, linux-kernel
In-Reply-To: <m14nsbwy1c.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> > 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.
>
> By stop working you mean "udevadm settle" waits because it thinks there
> are unprocessed events but those events are never found, and eventually
> "udevadm settle" times out?
Yeah.
> I'm sorry I don't see the problem.
>
> I think the most we could do would be to have a per network namespace
> sequence number, but I don't get see the problem with skipping a sequence
> number or two. Does that cause udev to explode or something? It
> doesn't sound like udev has problems.
>
> It does look like we aren't filtering all of the events for the new
> loopback device properly. We should be filtering the events for
> /sys/devices/virtual/net/lo/queues/rx-0 and friends. But fixing that
> problem looks like it will only make the gap in sequence numbers
> larger, and if anything make the "udevadm settle" problem worse.
>
> What precisely is the problem you are seeing?
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.
> Of course in this instance I can't see how the version of libvirt you
> are playing with would ever have worked. It is relying on features to
> act in a way the simply don't act.
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
^ permalink raw reply
* Re: udev missing events?
From: Eric W. Biederman @ 2012-04-22 16:07 UTC (permalink / raw)
To: Jim Paris; +Cc: linux-hotplug, linux-kernel
In-Reply-To: <20120422141106.GA3021@psychosis.jim.sh>
Jim Paris <jim@jtan.com> writes:
> Eric W. Biederman wrote:
>> Jim Paris <jim@jtan.com> wrote:
>>
>> >(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)
>> > ACTIONd
>> > DEVPATH=/devices/virtual/net/lo/queues/rx-0
>> > SEQNUM\x13589
>> > SUBSYSTEM=queues
>> > UDEV_LOG=3
>> >
>> >KERNEL[537903.765683] add /devices/virtual/net/lo/queues/tx-0
>> >(queues)
>> > ACTIONd
>> > DEVPATH=/devices/virtual/net/lo/queues/tx-0
>> > SEQNUM\x13590
>> > SUBSYSTEM=queues
>> > UDEV_LOG=3
>> >
>> >KERNEL[537903.844154] remove /devices/virtual/net/lo/queues/rx-0
>> >(queues)
>> > ACTION=remove
>> > DEVPATH=/devices/virtual/net/lo/queues/rx-0
>> > SEQNUM\x13591
>> > SUBSYSTEM=queues
>> > UDEV_LOG=3
>> >
>> >KERNEL[537903.844192] remove /devices/virtual/net/lo/queues/tx-0
>> >(queues)
>> > ACTION=remove
>> > DEVPATH=/devices/virtual/net/lo/queues/tx-0
>> > SEQNUM\x13592
>> > SUBSYSTEM=queues
>> > UDEV_LOG=3
>> >
>> >To try to track it further, I wrote a systemtap script (available at
>> >http://jim.sh/~jim/tmp/monitor.stp). It dumps the result of
>> >netlink_broadcast_filtered at lib/kobject_uevent.c:248, and then dumps
>> >the uevent_seqnum and environment at the end of the same function.
>> >It seems to show that netlink_broadcast_filter is failing to send out
>> >the event, with -ESRCH:
>> >
>> > $ sudo ./monitor.stp
>> > begin
>> > -----
>> > netlink_broadcast_filtered: -3 (ESRCH)
>> > netlink_broadcast_filtered: -3 (ESRCH)
>> > event was:
>> > uevent_seqnum: 13588
>> > "ACTIONd"
>> > "DEVPATH=/devices/virtual/net/lo"
>> > "SUBSYSTEM=net"
>> > "INTERFACE=lo"
>> > "IFINDEXh"
>> > "SEQNUM\x13588"
>> > -----
>> > netlink_broadcast_filtered: 0x0
>> > netlink_broadcast_filtered: -3 (ESRCH)
>> > event was:
>> > uevent_seqnum: 13589
>> > "ACTIONd"
>> > "DEVPATH=/devices/virtual/net/lo/queues/rx-0"
>> > "SUBSYSTEM=queues"
>> > "SEQNUM\x13589"
>> > -----
>> > netlink_broadcast_filtered: 0x0
>> > netlink_broadcast_filtered: -3 (ESRCH)
>> > event was:
>> > uevent_seqnum: 13590
>> > "ACTIONd"
>> > "DEVPATH=/devices/virtual/net/lo/queues/tx-0"
>> > "SUBSYSTEM=queues"
>> > "SEQNUM\x13590"
>> > -----
>> > netlink_broadcast_filtered: 0x0
>> > netlink_broadcast_filtered: -3 (ESRCH)
>> > event was:
>> > uevent_seqnum: 13591
>> > "ACTION=remove"
>> > "DEVPATH=/devices/virtual/net/lo/queues/rx-0"
>> > "SUBSYSTEM=queues"
>> > "SEQNUM\x13591"
>> > -----
>> > netlink_broadcast_filtered: 0x0
>> > netlink_broadcast_filtered: -3 (ESRCH)
>> > event was:
>> > uevent_seqnum: 13592
>> > "ACTION=remove"
>> > "DEVPATH=/devices/virtual/net/lo/queues/tx-0"
>> > "SUBSYSTEM=queues"
>> > "SEQNUM\x13592"
>> > -----
>> > netlink_broadcast_filtered: -3 (ESRCH)
>> > netlink_broadcast_filtered: -3 (ESRCH)
>> > event was:
>> > uevent_seqnum: 13593
>> > "ACTION=remove"
>> > "DEVPATH=/devices/virtual/net/lo"
>> > "SUBSYSTEM=net"
>> > "INTERFACE=lo"
>> > "IFINDEXh"
>> > "SEQNUM\x13593"
>> > -----
>> > ^Cend
>> >
>> >
>> >Is it expected that those events would not be sent like that?
>>
>> Roughly. Events for network devices are only delivered to sockets in the same netwoerk namespace.
>>
>> So you really shouldn't see much of an event for the creationof a network namespace.
>>
>> >If not, is there something else I can do to track this further?
>>
>> >Or, if that's expected behavior, is there anything "udevadm settle"
>> >can do to avoid the timeout?
>>
>> I don't think so. Udev for the host should not see events for things that happen inside a container.
>>
>> I am a little mystified that you see as much of the add of lo as you do in the udem monitor command.
>>
>> I am infering what is going on with libvirt and your machine and assuming containers are involved because of the additions and removals of lo.
>
> 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.
By stop working you mean "udevadm settle" waits because it thinks there
are unprocessed events but those events are never found, and eventually
"udevadm settle" times out?
I'm sorry I don't see the problem.
I think the most we could do would be to have a per network namespace
sequence number, but I don't get see the problem with skipping a sequence
number or two. Does that cause udev to explode or something? It
doesn't sound like udev has problems.
It does look like we aren't filtering all of the events for the new
loopback device properly. We should be filtering the events for
/sys/devices/virtual/net/lo/queues/rx-0 and friends. But fixing that
problem looks like it will only make the gap in sequence numbers
larger, and if anything make the "udevadm settle" problem worse.
What precisely is the problem you are seeing?
Of course in this instance I can't see how the version of libvirt you
are playing with would ever have worked. It is relying on features to
act in a way the simply don't act.
Eric
^ permalink raw reply
* Re: udev missing events?
From: Jim Paris @ 2012-04-22 14:11 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-hotplug, linux-kernel
In-Reply-To: <ef67a489-94bc-4f97-903d-907ab974537c@email.android.com>
Eric W. Biederman wrote:
> Jim Paris <jim@jtan.com> wrote:
>
> >(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)
> > ACTIONd
> > DEVPATH=/devices/virtual/net/lo/queues/rx-0
> > SEQNUM\x13589
> > SUBSYSTEM=queues
> > UDEV_LOG=3
> >
> >KERNEL[537903.765683] add /devices/virtual/net/lo/queues/tx-0
> >(queues)
> > ACTIONd
> > DEVPATH=/devices/virtual/net/lo/queues/tx-0
> > SEQNUM\x13590
> > SUBSYSTEM=queues
> > UDEV_LOG=3
> >
> >KERNEL[537903.844154] remove /devices/virtual/net/lo/queues/rx-0
> >(queues)
> > ACTION=remove
> > DEVPATH=/devices/virtual/net/lo/queues/rx-0
> > SEQNUM\x13591
> > SUBSYSTEM=queues
> > UDEV_LOG=3
> >
> >KERNEL[537903.844192] remove /devices/virtual/net/lo/queues/tx-0
> >(queues)
> > ACTION=remove
> > DEVPATH=/devices/virtual/net/lo/queues/tx-0
> > SEQNUM\x13592
> > SUBSYSTEM=queues
> > UDEV_LOG=3
> >
> >To try to track it further, I wrote a systemtap script (available at
> >http://jim.sh/~jim/tmp/monitor.stp). It dumps the result of
> >netlink_broadcast_filtered at lib/kobject_uevent.c:248, and then dumps
> >the uevent_seqnum and environment at the end of the same function.
> >It seems to show that netlink_broadcast_filter is failing to send out
> >the event, with -ESRCH:
> >
> > $ sudo ./monitor.stp
> > begin
> > -----
> > netlink_broadcast_filtered: -3 (ESRCH)
> > netlink_broadcast_filtered: -3 (ESRCH)
> > event was:
> > uevent_seqnum: 13588
> > "ACTIONd"
> > "DEVPATH=/devices/virtual/net/lo"
> > "SUBSYSTEM=net"
> > "INTERFACE=lo"
> > "IFINDEXh"
> > "SEQNUM\x13588"
> > -----
> > netlink_broadcast_filtered: 0x0
> > netlink_broadcast_filtered: -3 (ESRCH)
> > event was:
> > uevent_seqnum: 13589
> > "ACTIONd"
> > "DEVPATH=/devices/virtual/net/lo/queues/rx-0"
> > "SUBSYSTEM=queues"
> > "SEQNUM\x13589"
> > -----
> > netlink_broadcast_filtered: 0x0
> > netlink_broadcast_filtered: -3 (ESRCH)
> > event was:
> > uevent_seqnum: 13590
> > "ACTIONd"
> > "DEVPATH=/devices/virtual/net/lo/queues/tx-0"
> > "SUBSYSTEM=queues"
> > "SEQNUM\x13590"
> > -----
> > netlink_broadcast_filtered: 0x0
> > netlink_broadcast_filtered: -3 (ESRCH)
> > event was:
> > uevent_seqnum: 13591
> > "ACTION=remove"
> > "DEVPATH=/devices/virtual/net/lo/queues/rx-0"
> > "SUBSYSTEM=queues"
> > "SEQNUM\x13591"
> > -----
> > netlink_broadcast_filtered: 0x0
> > netlink_broadcast_filtered: -3 (ESRCH)
> > event was:
> > uevent_seqnum: 13592
> > "ACTION=remove"
> > "DEVPATH=/devices/virtual/net/lo/queues/tx-0"
> > "SUBSYSTEM=queues"
> > "SEQNUM\x13592"
> > -----
> > netlink_broadcast_filtered: -3 (ESRCH)
> > netlink_broadcast_filtered: -3 (ESRCH)
> > event was:
> > uevent_seqnum: 13593
> > "ACTION=remove"
> > "DEVPATH=/devices/virtual/net/lo"
> > "SUBSYSTEM=net"
> > "INTERFACE=lo"
> > "IFINDEXh"
> > "SEQNUM\x13593"
> > -----
> > ^Cend
> >
> >
> >Is it expected that those events would not be sent like that?
>
> Roughly. Events for network devices are only delivered to sockets in the same netwoerk namespace.
>
> So you really shouldn't see much of an event for the creationof a network namespace.
>
> >If not, is there something else I can do to track this further?
>
> >Or, if that's expected behavior, is there anything "udevadm settle"
> >can do to avoid the timeout?
>
> I don't think so. Udev for the host should not see events for things that happen inside a container.
>
> I am a little mystified that you see as much of the add of lo as you do in the udem monitor command.
>
> I am infering what is going on with libvirt and your machine and assuming containers are involved because of the additions and removals of lo.
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
^ permalink raw reply
* udev missing events?
From: Jim Paris @ 2012-04-22 4:36 UTC (permalink / raw)
To: linux-hotplug, linux-kernel; +Cc: Eric W. Biederman, Milan Broz
(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)
ACTIONd
DEVPATH=/devices/virtual/net/lo/queues/rx-0
SEQNUM\x13589
SUBSYSTEM=queues
UDEV_LOG=3
KERNEL[537903.765683] add /devices/virtual/net/lo/queues/tx-0 (queues)
ACTIONd
DEVPATH=/devices/virtual/net/lo/queues/tx-0
SEQNUM\x13590
SUBSYSTEM=queues
UDEV_LOG=3
KERNEL[537903.844154] remove /devices/virtual/net/lo/queues/rx-0 (queues)
ACTION=remove
DEVPATH=/devices/virtual/net/lo/queues/rx-0
SEQNUM\x13591
SUBSYSTEM=queues
UDEV_LOG=3
KERNEL[537903.844192] remove /devices/virtual/net/lo/queues/tx-0 (queues)
ACTION=remove
DEVPATH=/devices/virtual/net/lo/queues/tx-0
SEQNUM\x13592
SUBSYSTEM=queues
UDEV_LOG=3
To try to track it further, I wrote a systemtap script (available at
http://jim.sh/~jim/tmp/monitor.stp). It dumps the result of
netlink_broadcast_filtered at lib/kobject_uevent.c:248, and then dumps
the uevent_seqnum and environment at the end of the same function.
It seems to show that netlink_broadcast_filter is failing to send out
the event, with -ESRCH:
$ sudo ./monitor.stp
begin
-----
netlink_broadcast_filtered: -3 (ESRCH)
netlink_broadcast_filtered: -3 (ESRCH)
event was:
uevent_seqnum: 13588
"ACTIONd"
"DEVPATH=/devices/virtual/net/lo"
"SUBSYSTEM=net"
"INTERFACE=lo"
"IFINDEXh"
"SEQNUM\x13588"
-----
netlink_broadcast_filtered: 0x0
netlink_broadcast_filtered: -3 (ESRCH)
event was:
uevent_seqnum: 13589
"ACTIONd"
"DEVPATH=/devices/virtual/net/lo/queues/rx-0"
"SUBSYSTEM=queues"
"SEQNUM\x13589"
-----
netlink_broadcast_filtered: 0x0
netlink_broadcast_filtered: -3 (ESRCH)
event was:
uevent_seqnum: 13590
"ACTIONd"
"DEVPATH=/devices/virtual/net/lo/queues/tx-0"
"SUBSYSTEM=queues"
"SEQNUM\x13590"
-----
netlink_broadcast_filtered: 0x0
netlink_broadcast_filtered: -3 (ESRCH)
event was:
uevent_seqnum: 13591
"ACTION=remove"
"DEVPATH=/devices/virtual/net/lo/queues/rx-0"
"SUBSYSTEM=queues"
"SEQNUM\x13591"
-----
netlink_broadcast_filtered: 0x0
netlink_broadcast_filtered: -3 (ESRCH)
event was:
uevent_seqnum: 13592
"ACTION=remove"
"DEVPATH=/devices/virtual/net/lo/queues/tx-0"
"SUBSYSTEM=queues"
"SEQNUM\x13592"
-----
netlink_broadcast_filtered: -3 (ESRCH)
netlink_broadcast_filtered: -3 (ESRCH)
event was:
uevent_seqnum: 13593
"ACTION=remove"
"DEVPATH=/devices/virtual/net/lo"
"SUBSYSTEM=net"
"INTERFACE=lo"
"IFINDEXh"
"SEQNUM\x13593"
-----
^Cend
Is it expected that those events would not be sent like that?
If not, is there something else I can do to track this further?
Or, if that's expected behavior, is there anything "udevadm settle"
can do to avoid the timeout?
-jim
^ permalink raw reply
* kmod 8
From: Lucas De Marchi @ 2012-04-19 14:34 UTC (permalink / raw)
To: linux-modules, LKML, linux-hotplug
kmod 8 is out:
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-8.tar.xz
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-8.tar.sign
Very small, bug-fix release, nothing new. Last release I changed my
laptop, which caused a wrong setup and kmod 7 got out with docs
disabled. kmod 8 fixes as well.
Check NEWS file for more information.
Shortlog is below.
Lucas De Marchi
--
Dave Reisner (1):
modprobe: handle -ENOENT return from init_module
Elan Ruusamäe (1):
modprobe: fix typo in config dump: option->options
Kay Sievers (1):
doc: silent man page generation and fix gtk-doc warnings
Lucas De Marchi (4):
README: note that there are more files to read
TODO: add item to implement actions in kmod
doc: remove links to NULL going nowhere
kmod 8
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox