[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
/*
|
|
|
|
* wait_for_sysfs.c - small program to delay the execution
|
|
|
|
* of /etc/hotplug.d/ programs, until sysfs
|
2004-10-07 13:45:30 +07:00
|
|
|
* is fully populated by the kernel. Depending on
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
* the type of device, we wait for all expected
|
|
|
|
* directories and then just exit.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2004 Kay Sievers <kay.sievers@vrfy.org>
|
2004-10-16 12:54:12 +07:00
|
|
|
* Copyright (C) 2004 Greg Kroah-Hartman <greg@kroah.com>
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
* Free Software Foundation version 2 of the License.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
* 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stddef.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <ctype.h>
|
|
|
|
#include <errno.h>
|
|
|
|
#include <sys/stat.h>
|
|
|
|
|
|
|
|
#include "logging.h"
|
2004-10-14 10:55:01 +07:00
|
|
|
#include "udev_version.h"
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
#include "libsysfs/sysfs/libsysfs.h"
|
|
|
|
|
2004-10-16 12:54:12 +07:00
|
|
|
#ifndef FILENAME_MAX
|
|
|
|
#define FILENAME_MAX 4096
|
|
|
|
#endif
|
|
|
|
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
#ifdef LOG
|
|
|
|
unsigned char logname[LOGNAME_SIZE];
|
|
|
|
void log_message(int level, const char *format, ...)
|
|
|
|
{
|
|
|
|
va_list args;
|
|
|
|
|
|
|
|
va_start(args, format);
|
|
|
|
vsyslog(level, format, args);
|
|
|
|
va_end(args);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2004-10-16 09:45:56 +07:00
|
|
|
#define WAIT_MAX_SECONDS 5
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
#define WAIT_LOOP_PER_SECOND 20
|
|
|
|
|
2004-10-07 13:45:30 +07:00
|
|
|
/* wait for specific file to show up, normally the "dev"-file */
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
static int wait_for_class_device_attributes(struct sysfs_class_device *class_dev,
|
|
|
|
const char **error)
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
{
|
|
|
|
static struct class_file {
|
|
|
|
char *subsystem;
|
|
|
|
char *file;
|
|
|
|
} class_files[] = {
|
|
|
|
{ .subsystem = "net", .file = "ifindex" },
|
2004-10-07 13:45:30 +07:00
|
|
|
{ .subsystem = "scsi_host", .file = "unique_id" },
|
|
|
|
{ .subsystem = "scsi_device", .file = NULL },
|
2004-10-16 09:45:56 +07:00
|
|
|
{ .subsystem = "pcmcia_socket", .file = "card_type" },
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
{ .subsystem = "usb_host", .file = NULL },
|
2004-10-07 15:34:31 +07:00
|
|
|
{ .subsystem = "bluetooth", .file = "address" },
|
2004-10-15 10:36:12 +07:00
|
|
|
{ .subsystem = "firmware", .file = "data" },
|
2004-10-08 08:43:31 +07:00
|
|
|
{ .subsystem = "i2c-adapter", .file = NULL },
|
2004-10-12 14:16:24 +07:00
|
|
|
{ .subsystem = "pci_bus", .file = NULL },
|
2004-10-12 14:47:27 +07:00
|
|
|
{ .subsystem = "ieee1394", .file = NULL },
|
|
|
|
{ .subsystem = "ieee1394_host", .file = NULL },
|
|
|
|
{ .subsystem = "ieee1394_node", .file = NULL },
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
{ NULL, NULL }
|
|
|
|
};
|
|
|
|
struct class_file *classfile;
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
char *file = "dev";
|
2004-10-16 12:54:12 +07:00
|
|
|
char filename[FILENAME_MAX];
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
int loop;
|
|
|
|
|
|
|
|
/* look if we want to look for another file instead of "dev" */
|
|
|
|
for (classfile = class_files; classfile->subsystem != NULL; classfile++) {
|
|
|
|
if (strcmp(class_dev->classname, classfile->subsystem) == 0) {
|
|
|
|
if (classfile->file == NULL) {
|
|
|
|
dbg("class '%s' has no file to wait for", class_dev->classname);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
file = classfile->file;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2004-10-16 09:45:56 +07:00
|
|
|
|
2004-10-16 12:54:12 +07:00
|
|
|
strcpy(filename, class_dev->path);
|
|
|
|
strcat(filename, "/");
|
|
|
|
strcat(filename, file);
|
|
|
|
dbg("looking at class '%s' for specific file '%s' with full name %s", class_dev->classname, class_dev->path, filename);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
|
|
|
loop = WAIT_MAX_SECONDS * WAIT_LOOP_PER_SECOND;
|
|
|
|
while (--loop) {
|
2004-10-16 09:45:56 +07:00
|
|
|
struct stat stats;
|
|
|
|
|
2004-10-16 12:54:12 +07:00
|
|
|
if (stat(class_dev->path, &stats) == -1) {
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
dbg("'%s' now disappeared (probably remove has beaten us)", class_dev->path);
|
2004-10-16 12:54:12 +07:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
if (stat(filename, &stats) == 0) {
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
dbg("class '%s' specific file '%s' found", class_dev->classname, file);
|
|
|
|
return 0;
|
|
|
|
}
|
2004-10-07 13:45:30 +07:00
|
|
|
|
|
|
|
usleep(1000 * 1000 / WAIT_LOOP_PER_SECOND);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
}
|
|
|
|
|
2004-10-07 13:45:30 +07:00
|
|
|
dbg("error: getting class '%s' specific file '%s'", class_dev->classname, file);
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
*error = "class specific file unavailable";
|
2004-10-16 12:54:12 +07:00
|
|
|
return -ENOENT;
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
}
|
|
|
|
|
2004-10-14 13:13:26 +07:00
|
|
|
/* check if we need to wait for a physical device */
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
static int class_device_expect_no_device_link(struct sysfs_class_device *class_dev)
|
|
|
|
{
|
2004-10-14 13:13:26 +07:00
|
|
|
/* list of devices without a "device" symlink to the physical device
|
|
|
|
* if device is set to NULL, no devices in that subsystem has a link */
|
2004-10-08 11:06:07 +07:00
|
|
|
static struct class_device {
|
|
|
|
char *subsystem;
|
|
|
|
char *device;
|
|
|
|
} class_device[] = {
|
|
|
|
{ .subsystem = "block", .device = "double" },
|
|
|
|
{ .subsystem = "block", .device = "nb" },
|
|
|
|
{ .subsystem = "block", .device = "ram" },
|
|
|
|
{ .subsystem = "block", .device = "loop" },
|
|
|
|
{ .subsystem = "block", .device = "fd" },
|
|
|
|
{ .subsystem = "block", .device = "md" },
|
|
|
|
{ .subsystem = "block", .device = "dos_cd" },
|
|
|
|
{ .subsystem = "block", .device = "rflash" },
|
|
|
|
{ .subsystem = "block", .device = "rom" },
|
|
|
|
{ .subsystem = "block", .device = "rrom" },
|
|
|
|
{ .subsystem = "block", .device = "flash" },
|
|
|
|
{ .subsystem = "block", .device = "msd" },
|
|
|
|
{ .subsystem = "block", .device = "sbpcd" },
|
|
|
|
{ .subsystem = "block", .device = "pcd" },
|
|
|
|
{ .subsystem = "block", .device = "pf" },
|
|
|
|
{ .subsystem = "block", .device = "scd" },
|
|
|
|
{ .subsystem = "block", .device = "ubd" },
|
|
|
|
{ .subsystem = "input", .device = "event" },
|
|
|
|
{ .subsystem = "input", .device = "mice" },
|
|
|
|
{ .subsystem = "input", .device = "mouse" },
|
|
|
|
{ .subsystem = "input", .device = "ts" },
|
2004-10-12 14:16:24 +07:00
|
|
|
{ .subsystem = "vc", .device = NULL },
|
2004-10-08 11:06:07 +07:00
|
|
|
{ .subsystem = "tty", .device = NULL },
|
|
|
|
{ .subsystem = "cpuid", .device = "cpu" },
|
|
|
|
{ .subsystem = "graphics", .device = "fb" },
|
|
|
|
{ .subsystem = "mem", .device = NULL },
|
|
|
|
{ .subsystem = "misc", .device = NULL },
|
|
|
|
{ .subsystem = "msr", .device = NULL },
|
|
|
|
{ .subsystem = "netlink", .device = NULL },
|
2004-10-14 10:55:01 +07:00
|
|
|
{ .subsystem = "net", .device = "sit" },
|
|
|
|
{ .subsystem = "net", .device = "lo" },
|
|
|
|
{ .subsystem = "net", .device = "tap" },
|
2004-10-14 12:51:41 +07:00
|
|
|
{ .subsystem = "net", .device = "ipsec" },
|
2004-10-19 08:16:12 +07:00
|
|
|
{ .subsystem = "net", .device = "dummy" },
|
2004-10-15 10:36:12 +07:00
|
|
|
{ .subsystem = "net", .device = "irda" },
|
2004-10-19 08:13:40 +07:00
|
|
|
{ .subsystem = "net", .device = "ppp" },
|
|
|
|
{ .subsystem = "ppp", .device = NULL },
|
2004-10-08 11:06:07 +07:00
|
|
|
{ .subsystem = "sound", .device = NULL },
|
|
|
|
{ .subsystem = "printer", .device = "lp" },
|
2004-10-12 14:16:24 +07:00
|
|
|
{ .subsystem = "nvidia", .device = NULL },
|
2004-10-14 10:55:01 +07:00
|
|
|
{ .subsystem = "video4linux", .device = "vbi" },
|
2004-10-12 14:16:24 +07:00
|
|
|
{ .subsystem = "lirc", .device = NULL },
|
|
|
|
{ .subsystem = "firmware", .device = NULL },
|
|
|
|
{ .subsystem = "drm", .device = NULL },
|
|
|
|
{ .subsystem = "pci_bus", .device = NULL },
|
2004-10-12 14:47:27 +07:00
|
|
|
{ .subsystem = "ieee1394", .device = NULL },
|
|
|
|
{ .subsystem = "ieee1394_host", .device = NULL },
|
|
|
|
{ .subsystem = "ieee1394_node", .device = NULL },
|
2004-10-14 11:09:28 +07:00
|
|
|
{ .subsystem = "raw", .device = NULL },
|
2004-10-08 11:06:07 +07:00
|
|
|
{ NULL, NULL }
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
};
|
2004-10-08 11:06:07 +07:00
|
|
|
struct class_device *classdevice;
|
|
|
|
int len;
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
2004-10-08 11:06:07 +07:00
|
|
|
for (classdevice = class_device; classdevice->subsystem != NULL; classdevice++) {
|
|
|
|
if (strcmp(class_dev->classname, classdevice->subsystem) == 0) {
|
2004-10-14 13:13:26 +07:00
|
|
|
/* see if no device in this class is expected to have a device-link */
|
2004-10-08 11:06:07 +07:00
|
|
|
if (classdevice->device == NULL)
|
|
|
|
return 1;
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
2004-10-08 11:06:07 +07:00
|
|
|
len = strlen(classdevice->device);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
2004-10-08 11:06:07 +07:00
|
|
|
/* see if device name matches */
|
|
|
|
if (strncmp(class_dev->name, classdevice->device, len) != 0)
|
|
|
|
continue;
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
2004-10-14 13:13:26 +07:00
|
|
|
/* exact name match */
|
2004-10-08 11:06:07 +07:00
|
|
|
if (strlen(class_dev->name) == len)
|
|
|
|
return 1;
|
|
|
|
|
2004-10-14 13:13:26 +07:00
|
|
|
/* name match with instance number */
|
2004-10-08 11:06:07 +07:00
|
|
|
if (isdigit(class_dev->name[len]))
|
|
|
|
return 1;
|
|
|
|
}
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2004-10-07 13:45:30 +07:00
|
|
|
/* skip waiting for the bus */
|
|
|
|
static int class_device_expect_no_bus(struct sysfs_class_device *class_dev)
|
|
|
|
{
|
|
|
|
static char *devices_without_bus[] = {
|
|
|
|
"scsi_host",
|
2004-10-08 08:43:31 +07:00
|
|
|
"i2c-adapter",
|
2004-10-07 13:45:30 +07:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
char **device;
|
|
|
|
|
|
|
|
for (device = devices_without_bus; *device != NULL; device++) {
|
|
|
|
int len = strlen(*device);
|
|
|
|
|
|
|
|
if (strncmp(class_dev->classname, *device, len) == 0)
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* wait for the bus and for a bus specific file to show up */
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
static int wait_for_bus_device(struct sysfs_device *devices_dev,
|
|
|
|
const char **error)
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
{
|
|
|
|
static struct bus_file {
|
|
|
|
char *bus;
|
|
|
|
char *file;
|
|
|
|
} bus_files[] = {
|
|
|
|
{ .bus = "scsi", .file = "vendor" },
|
|
|
|
{ .bus = "usb", .file = "idVendor" },
|
|
|
|
{ .bus = "usb", .file = "iInterface" },
|
2004-10-07 14:11:04 +07:00
|
|
|
{ .bus = "usb", .file = "bNumEndpoints" },
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
{ .bus = "usb-serial", .file = "detach_state" },
|
|
|
|
{ .bus = "ide", .file = "detach_state" },
|
|
|
|
{ .bus = "pci", .file = "vendor" },
|
2004-10-07 13:45:30 +07:00
|
|
|
{ .bus = "platform", .file = "detach_state" },
|
2004-10-08 09:12:10 +07:00
|
|
|
{ .bus = "i2c", .file = "detach_state" },
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
{ NULL }
|
|
|
|
};
|
|
|
|
struct bus_file *busfile;
|
|
|
|
int loop;
|
|
|
|
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
/* wait for the bus device link to the devices device */
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
loop = WAIT_MAX_SECONDS * WAIT_LOOP_PER_SECOND;
|
|
|
|
while (--loop) {
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
if (sysfs_get_device_bus(devices_dev) == 0)
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
break;
|
|
|
|
|
|
|
|
usleep(1000 * 1000 / WAIT_LOOP_PER_SECOND);
|
|
|
|
}
|
|
|
|
if (loop == 0) {
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
dbg("error: getting bus device link");
|
|
|
|
*error = "no bus device link";
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
return -1;
|
|
|
|
}
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
dbg("bus device link found for bus '%s'", devices_dev->bus);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
|
|
|
/* wait for a bus specific file to show up */
|
|
|
|
loop = WAIT_MAX_SECONDS * WAIT_LOOP_PER_SECOND;
|
|
|
|
while (--loop) {
|
2004-10-07 13:45:30 +07:00
|
|
|
int found = 0;
|
|
|
|
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
for (busfile = bus_files; busfile->bus != NULL; busfile++) {
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
if (strcmp(devices_dev->bus, busfile->bus) == 0) {
|
2004-10-07 13:45:30 +07:00
|
|
|
found = 1;
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
dbg("looking at bus '%s' for specific file '%s'", devices_dev->bus, busfile->file);
|
|
|
|
if (sysfs_get_device_attr(devices_dev, busfile->file) != NULL) {
|
|
|
|
dbg("bus '%s' specific file '%s' found", devices_dev->bus, busfile->file);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2004-10-07 13:45:30 +07:00
|
|
|
if (found == 0) {
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
*error = "unknown bus";
|
2004-10-07 13:45:30 +07:00
|
|
|
info("error: unknown bus, please report to "
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
"<linux-hotplug-devel@lists.sourceforge.net> '%s'", devices_dev->bus);
|
2004-10-07 13:45:30 +07:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
usleep(1000 * 1000 / WAIT_LOOP_PER_SECOND);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
}
|
|
|
|
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
dbg("error: getting bus '%s' specific file '%s'", devices_dev->bus, busfile->file);
|
|
|
|
*error = "bus specific file unavailable";
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
|
|
|
|
static struct sysfs_class_device *open_class_device(const char *path)
|
|
|
|
{
|
|
|
|
struct sysfs_class_device *class_dev;
|
|
|
|
int loop;
|
|
|
|
|
|
|
|
loop = WAIT_MAX_SECONDS * WAIT_LOOP_PER_SECOND;
|
|
|
|
while (--loop) {
|
|
|
|
class_dev = sysfs_open_class_device_path(path);
|
|
|
|
if (class_dev)
|
|
|
|
break;
|
|
|
|
|
|
|
|
usleep(1000 * 1000 / WAIT_LOOP_PER_SECOND);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (class_dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int wait_for_class_device(struct sysfs_class_device *class_dev,
|
|
|
|
const char **error)
|
|
|
|
{
|
|
|
|
struct sysfs_class_device *class_dev_parent;
|
|
|
|
struct sysfs_device *devices_dev = NULL;
|
|
|
|
int loop;
|
|
|
|
|
|
|
|
if (wait_for_class_device_attributes(class_dev, error) != 0)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
/* skip devices without devices-link */
|
|
|
|
if (class_device_expect_no_device_link(class_dev)) {
|
|
|
|
dbg("no device symlink expected for '%s', ", class_dev->name);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* the symlink may be on the parent device */
|
|
|
|
class_dev_parent = sysfs_get_classdev_parent(class_dev);
|
|
|
|
if (class_dev_parent)
|
|
|
|
dbg("looking at parent device for device link '%s'", class_dev_parent->path);
|
|
|
|
|
|
|
|
/* wait for the symlink to the devices device */
|
|
|
|
dbg("waiting for symlink to devices device");
|
|
|
|
loop = WAIT_MAX_SECONDS * WAIT_LOOP_PER_SECOND;
|
|
|
|
while (--loop) {
|
|
|
|
if (class_dev_parent)
|
|
|
|
devices_dev = sysfs_get_classdev_device(class_dev_parent);
|
|
|
|
else
|
|
|
|
devices_dev = sysfs_get_classdev_device(class_dev);
|
|
|
|
|
|
|
|
if (devices_dev)
|
|
|
|
break;
|
|
|
|
|
|
|
|
usleep(1000 * 1000 / WAIT_LOOP_PER_SECOND);
|
|
|
|
}
|
|
|
|
if (!devices_dev) {
|
|
|
|
dbg(" error: no devices device symlink found");
|
|
|
|
*error = "no device symlink";
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
dbg("device symlink found pointing to '%s'", devices_dev->path);
|
|
|
|
|
|
|
|
/* wait for the bus value */
|
|
|
|
if (class_device_expect_no_bus(class_dev)) {
|
|
|
|
dbg("no bus device expected for '%s', ", class_dev->classname);
|
|
|
|
return 0;
|
|
|
|
} else {
|
|
|
|
return wait_for_bus_device(devices_dev, error);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct sysfs_device *open_devices_device(const char *path)
|
|
|
|
{
|
|
|
|
struct sysfs_device *devices_dev;
|
|
|
|
int loop;
|
|
|
|
|
|
|
|
loop = WAIT_MAX_SECONDS * WAIT_LOOP_PER_SECOND;
|
|
|
|
while (--loop) {
|
|
|
|
devices_dev = sysfs_open_device_path(path);
|
|
|
|
if (devices_dev)
|
|
|
|
break;
|
|
|
|
|
|
|
|
usleep(1000 * 1000 / WAIT_LOOP_PER_SECOND);
|
|
|
|
}
|
|
|
|
|
|
|
|
return(devices_dev);
|
|
|
|
}
|
|
|
|
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
int main(int argc, char *argv[], char *envp[])
|
|
|
|
{
|
|
|
|
const char *devpath = "";
|
|
|
|
const char *action;
|
|
|
|
const char *subsystem;
|
|
|
|
char sysfs_path[SYSFS_PATH_MAX];
|
|
|
|
char filename[SYSFS_PATH_MAX];
|
|
|
|
struct sysfs_class_device *class_dev;
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
struct sysfs_device *devices_dev;
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
int rc = 0;
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
const char *error = NULL;
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
2004-10-19 08:15:10 +07:00
|
|
|
logging_init("wait_for_sysfs");
|
2004-10-07 13:45:30 +07:00
|
|
|
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
if (argc != 2) {
|
|
|
|
dbg("error: subsystem");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
subsystem = argv[1];
|
|
|
|
|
|
|
|
devpath = getenv ("DEVPATH");
|
|
|
|
if (!devpath) {
|
|
|
|
dbg("error: no DEVPATH");
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
rc = 1;
|
|
|
|
goto exit;
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
action = getenv ("ACTION");
|
|
|
|
if (!action) {
|
|
|
|
dbg("error: no ACTION");
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
rc = 1;
|
|
|
|
goto exit;
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
}
|
|
|
|
|
2004-10-07 13:45:30 +07:00
|
|
|
/* we only wait on an add event */
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
if (strcmp(action, "add") != 0) {
|
|
|
|
dbg("no add ACTION");
|
|
|
|
goto exit;
|
|
|
|
}
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
|
|
|
if (sysfs_get_mnt_path(sysfs_path, SYSFS_PATH_MAX) != 0) {
|
|
|
|
dbg("error: no sysfs path");
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
rc = 2;
|
|
|
|
goto exit;
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
if ((strncmp(devpath, "/block/", 7) == 0) || (strncmp(devpath, "/class/", 7) == 0)) {
|
|
|
|
snprintf(filename, SYSFS_PATH_MAX-1, "%s%s", sysfs_path, devpath);
|
|
|
|
filename[SYSFS_PATH_MAX-1] = '\0';
|
|
|
|
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
/* open the class device we are called for */
|
|
|
|
class_dev = open_class_device(filename);
|
|
|
|
if (!class_dev) {
|
|
|
|
dbg("error: class device unavailable (probably remove has beaten us)");
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
goto exit;
|
|
|
|
}
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
dbg("class device opened '%s'", filename);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
/* wait for the class device with possible physical device and bus */
|
|
|
|
wait_for_class_device(class_dev, &error);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
2004-10-07 13:45:30 +07:00
|
|
|
sysfs_close_class_device(class_dev);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
|
|
|
} else if ((strncmp(devpath, "/devices/", 9) == 0)) {
|
|
|
|
snprintf(filename, SYSFS_PATH_MAX-1, "%s%s", sysfs_path, devpath);
|
|
|
|
filename[SYSFS_PATH_MAX-1] = '\0';
|
|
|
|
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
/* open the path we are called for */
|
|
|
|
devices_dev = open_devices_device(filename);
|
|
|
|
if (!devices_dev) {
|
|
|
|
dbg("error: devices device unavailable (probably remove has beaten us)");
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
goto exit;
|
|
|
|
}
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
dbg("devices device opened '%s'", filename);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
|
|
|
/* wait for the bus value */
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
wait_for_bus_device(devices_dev, &error);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
sysfs_close_device(devices_dev);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
|
|
|
} else {
|
|
|
|
dbg("unhandled sysfs path, no need to wait");
|
|
|
|
}
|
|
|
|
|
|
|
|
exit:
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
if (error) {
|
2004-10-14 10:55:01 +07:00
|
|
|
info("either wait_for_sysfs (udev %s) needs an update to handle the device '%s' "
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
"properly (%s) or the sysfs-support of your device's driver needs to be fixed, "
|
2004-10-14 10:55:01 +07:00
|
|
|
"please report to <linux-hotplug-devel@lists.sourceforge.net>",
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
UDEV_VERSION, devpath, error);
|
|
|
|
rc =3;
|
|
|
|
} else {
|
|
|
|
dbg("result: waiting for sysfs successful '%s'", devpath);
|
|
|
|
}
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
|
2004-10-19 08:15:10 +07:00
|
|
|
logging_close();
|
[PATCH] Fix wait_for_sysfs messages (more debugging info)
On Sat, Oct 16, 2004 at 02:48:42PM -0400, Jeff wrote:
> Kay Sievers wrote:
> >On Sat, Oct 16, 2004 at 04:40:51AM +0200, Kay Sievers wrote:
> >
> >Here is a better version. We return successful in the case, that the
> >advertised device does not appear within the timeout or goes completely
> >away while waiting for the attributes. All magic numbers should be
> >readable as a string now.
> >
> >This hopefully fixes the last vc errors.
> >
> K, first patch produced a couple of device unavailables & a slew of no
> device symlinks. Second patch-no messages at all :)
>
> Thank god, if I have to reboot again I'm going to puke.
Nice to hear that we covered all the vc errors now. I think we should
apply the same logic to the /devices device wait loops, as they may go
with a remove event too.
Here is the 3rd version of the patch :)
2004-10-19 08:13:13 +07:00
|
|
|
exit(rc);
|
[PATCH] finally solve the bad sysfs-timing for all of us
On Tue, Sep 21, 2004 at 07:17:34PM +0200, Kay Sievers wrote:
> During the integration of HAL into the linux hotplug system, we dicover
> every week a new signaling path that fails cause of the delayed
> population of the sysfs files, which are connected by symlinks and
> appear in something like a random order in userspace.
>
> It's pretty complicated to understand the connection between all these
> files for all the different subsystems with all the exceptions, so most
> of the users simply sleep a few seconds, but that is not acceptable for
> our integration work.
>
> Here I try to get all the special knowledge about that behavior together
> and place that in a simple binary. That program _must_ run first of all
> other hotplug processsing and every later script, udev or HAL all can get
> rid of the wild guesses about the right time sysfs is ready.
>
> It will not only wait for the "dev"-file events we handle with udev, also
> for every /device-device with the corresponding bus link.
>
> It is provided as a patch against the current udev tree and a "install" will
> place the new program in the hotplug.d directory:
>
> [kay@pim ~]$ tree /etc/hotplug.d/
> /etc/hotplug.d/
> `-- default
> |-- 00-wait_for_sysfs.hotplug -> /sbin/wait_for_sysfs
> |-- 10-udev.hotplug -> /sbin/udevsend
> |-- 20-hal.hotplug -> /usr/libexec/hal.hotplug
> |-- default.hotplug
> `-- log.hotplug
>
>
> For now, it logs the result of the waiting to syslog, to catch any
> device, that needs special treatment. All newly discovered delay problems,
> device black/whitelist updates should go into that program and we may remove
> that kind of specialisation from all the other hotplug programs.
>
> Any patches, reports, testing is more than welcome.
>
> Sample debug:
> Sep 21 18:44:07 localhost kernel: usb 3-2: new full speed USB device using address 12
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: USB hub found
> Sep 21 18:44:07 localhost kernel: hub 3-2:1.0: 2 ports detected
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2'
> Sep 21 18:44:07 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2:1.0'
> Sep 21 18:44:08 localhost kernel: usb 3-2.1: new full speed USB device using address 13
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/usb/lp0'
> Sep 21 18:44:08 localhost kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 13 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1/3-2.1:1.0'
> Sep 21 18:44:08 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.1'
> Sep 21 18:44:08 localhost udev: configured rule in '/etc/udev/rules.d/50-udev.rules' at line 29 applied, 'lp0' becomes 'usb/%k'
> Sep 21 18:44:08 localhost udev: creating device node '/udev/usb/lp0'
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: new full speed USB device using address 14
> Sep 21 18:44:09 localhost kernel: pl2303 3-2.2:1.0: PL-2303 converter detected
> Sep 21 18:44:09 localhost kernel: usb 3-2.2: PL-2303 converter now attached to ttyUSB0
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/devices/pci0000:00/0000:00:1d.1/usb3/3-2/3-2.2/3-2.2:1.0/ttyUSB0'
> Sep 21 18:44:09 localhost 00-wait_for_sysfs.hotplug: result: waiting for sysfs successful '/class/tty/ttyUSB0'
> Sep 21 18:44:09 localhost udev: creating device node '/udev/ttyUSB0'
New version with more devices excluded from /device-link saerch and
a better maching for device names.
2004-10-06 11:35:39 +07:00
|
|
|
}
|