summaryrefslogtreecommitdiff
path: root/wait_for_sysfs.c
AgeCommit message (Collapse)Author
2005-04-26[PATCH] integrate wait_for_sysfs in udevkay.sievers@vrfy.org
Move the wait_for_sysfs logic into the udev binary. udev is called for every hotplug event. It also waits for /devices events.
2005-04-26[PATCH] don't wait for sysfs if the kernel(2.6.10-rc2) tells us what not to ↵kay.sievers@vrfy.org
expect Newer kernels will tell us if we should wait for the "device" or the "bus" link. So don't waste the time with our lists or wait for the timeout.
2005-04-26[PATCH] Make dev.d/ handling a separate processing stagekay.sievers@vrfy.org
Move the logic when and how to call the dev.d/ scripts into the main processing path.
2005-04-26[PATCH] Shut up wait_for_sysfs class/net failure messages, as it's not possiblekay.sievers@vrfy.org
2005-04-26[PATCH] skip waiting for device if we get a bad event for class creationkay.sievers@vrfy.org
2005-04-26[PATCH] expose sysfs functions for sharing itkay.sievers@vrfy.org
This patch exposes the wait_for_sysfs functions to all possible users, so we need to maintain only one list of exceptions. The last list is hereby removed from udev.c.
2005-04-26[PATCH] fix debug in volume id / fix clashing global var namekay.sievers@vrfy.org
Here we get the logging for udev_volume_id working if it is compiled with DEBUG=true. Also fixed is a name clash with a global variable.
2005-04-26[PATCH] wait_for_sysfs update for dm devicesjk@blackdown.de
Hi, I got these when creating LVM2 snapshots: ,---- | Oct 17 04:23:09 server wait_for_sysfs[5120]: error: wait_for_sysfs needs an update to handle the device '/block/dm-6' properly, please report to <linux-hotplug-devel@lists.sourceforge.net> | Oct 17 04:23:09 server wait_for_sysfs[5129]: error: wait_for_sysfs needs an update to handle the device '/block/dm-6' properly, please report to <linux-hotplug-devel@lists.sourceforge.net> | Oct 17 04:23:09 server wait_for_sysfs[5131]: error: wait_for_sysfs needs an update to handle the device '/block/dm-7' properly, please report to <linux-hotplug-devel@lists.sourceforge.net> | [...] `----
2005-04-26[PATCH] don't wait for dummy deviceskay.sievers@vrfy.org
No need to wait for dummy net devices.
2005-04-26[PATCH] close the syslogkay.sievers@vrfy.org
Seems that we never closed the opened syslog. Here is a patch to do this in all our binaries.
2005-04-26[PATCH] Fix ppp net devices in wait_for_sysfskay.sievers@vrfy.org
On Sat, Oct 16, 2004 at 10:32:47AM -0500, Jason Dravet wrote: > FYI > > wait_for_sysfs[2986]: either wait_for_sysfs (udev 038) needs an update to > handle the device '/class/ppp/ppp' properly (5) or the sysfs-support of > your device's driver needs to be fixed, please report to > <linux-hotplug-devel@lists.sourceforge.net> > > I am running udev 38-2 and ppp-2.4.2-6.3 Yeah, the ppp-class is missing, we only covered the net ppp-devices.
2005-04-26[PATCH] Fix wait_for_sysfs messages (more debugging info)kay.sievers@vrfy.org
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 :)
2005-04-26[PATCH] Hopefully fix the vcs issue in wait_for_sysfsgreg@kroah.com
2005-04-26[PATCH] swich attribute open() to simple stat()kay.sievers@vrfy.org
Here we switch to a simple stat() to recognize the file creation. This will make it possible to wait for files, which are unreadable. I've switched the timout back to 5 seconds cause the our /class/vc errors seems like a bug in the vc layer not a sysfs delay.
2005-04-26[PATCH] wait_for_sysfs update for /class/firmware and /class/net/irda deviceskay.sievers@vrfy.org
update for /class/firmware and /class/net/irda devices
2005-04-26[PATCH] fix unusual sysfs behavior for pcmcia_socketkay.sievers@vrfy.org
All files in /sys/class/pcmcia_socket/pcmcia_socket0/* are unreadable without a card inserted: read(3, 0x9167858, 4096) = -1 ENODEV (No such device) So we need to skip that step for now.
2005-04-26[PATCH] add ipsec to wait_for_sysfs ignore list.greg@kroah.com
2005-04-26[PATCH] prevent deadlocks on an corrupt udev databasekay.sievers@vrfy.org
Here is the patch, that should prevent all of the known deadlocks with corrupt tdb databases we discovered. Thanks to Frank Steiner <fsteiner-mail@bio.ifi.lmu.de>, who tested all this endlessly with a NFS mounted /dev. The conclusion is, that udev will not work on filesystems without proper record locking, but we should prevent the endless loops anyway. This patch implements: o recovery from a corrupted udev database. udev will continue without database support now, instead of doing nothing. So the node should be generated in any case, remove will obviously not work for custom names. o added iteration limits to the tdb-code at the places we discovered endless loops. In the case tdb tries to find more than 100.000 entries with the same hash, we better give up :) o prevent a {all_partitions} loop caused by corrupt db data o log all tdb errors to syslog o switch sleep() to usleep() cause we want to use alarm()
2005-04-26[PATCH] change max time to wait in wait_for_sysfs to 10 seconds to hopefully ↵greg@kroah.com
handle some slow machines.
2005-04-26[PATCH] add support for class/raw/ to wait_for_sysfsgreg@kroah.com
2005-04-26[PATCH] wait_for_sysfs_updatekay.sievers@vrfy.org
Here is an update to wait_for_sysfs to print the udev version to syslog, let hardware net interfaces wait again for the device link and revert the video4linux to wait for the device. The error here was caused by a out-of-tree media-driver, that needs the fix, not the our program. I've added a small comment for that to the log as I expect more of this to show up and the recent desktop integration work depends heavily on proper sysfs support, so the drivers should be fixed.
2005-04-26[PATCH] add the error number to the error message in wait_for_sysfs to help ↵greg@kroah.com
out in debugging problems.
2005-04-26[PATCH] added ieee1394 support to wait_for_sysfsgreg@kroah.com
2005-04-26[PATCH] update wait_for_sysfs with a bunch more devices thanks to user reports.greg@kroah.com
2005-04-26[PATCH] add comment in wait_for_sysfs to explain the structure better.greg@kroah.com
2005-04-26[PATCH] wait_for_sysfs: clean up the logic for the list of devices that we ↵greg@kroah.com
do not expect device symlinks for This makes it a lot easier to test for these devices, otherwise the list would have gotten very large
2005-04-26[PATCH] added support for i2c devices in wait_for_sysfs.cgreg@kroah.com
2005-04-26[PATCH] add support for i2c-adapter devices to wait_for_sysfs.cgreg@kroah.com
2005-04-26[PATCH] wait_for_sysfs bluetooth class updatekay.sievers@vrfy.org
Here is the file to wait for the bluetooth class, as it is not a "dev" file. udev waits for 10 seconds here too.
2005-04-26[PATCH] add support for usb interfaces to wait_for_sysfs to keep it quiet.greg@kroah.com
2005-04-26[PATCH] wait_for_sysfs debug cleanupkay.sievers@vrfy.org
> Sorry, I left my debug code in. Oops, just realized it now. You've applied a older version and not the latest. Here is a new patch to catch up.
2005-04-26[PATCH] finally solve the bad sysfs-timing for all of uskay.sievers@vrfy.org
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.