>> I think you guys are missing the problem I'm having. This has nothing to >> do with USB, I don't use USB and don't load any USB modules. I've tried >> this out on 3 boxes using kernel 2.9.29.6 and udev 145. >> >> Here are the modules loaded ... >> ahci, piix, ide_core, ata_piix, pata_acpi, libata >> >> * I have a kernel with an initramfs, no disk controller modules are >> loaded at all before the initramfs fires up >> * My script is this .... >> examine pci bus & modprobe modules we need for disks >> fire up udev >> udev trigger >> udev settle >> mount LABEL=root >> >> Simple. Now .... that works in 141 fine, it does not in 145. If I do an >> ls /dev straight after settle, there are no sd* devices. If I add a >> sleep 5s after settle, the devices are there. >> >> udevadm settle exits after about 1 second, when I check the creation >> times on the devices it takes a few seconds, up to 5 depending on the >> speed of the box. >> >> Kay, you said yourself that settle does not wait until the events are >> fully processed and exits once they have been recieved by udev. >> > > I did? Where? Must be misunderstanding. > Sorry ... wrong Kay ;) I was then mis-informed. I understood settle waits until everything is 100% processed that was queued, right? so if sda is in the queue, settle will wait until /dev/sda is created? >> This is >> EXACTLY what is happening in 145. >> > > settle waits for all pending events in the kernel, and the ones > already received by udev, to finish. It exits not before no events are > pending anymore, in the kernel and in udev. > I can see udev trigger sending the correct events through to udev, I can see sda there .... but after the settle, its not in /dev/ yet, takes a second or two and its there. What would happen if udev is started, trigger, settle, kill udev. Start udev, trigger, settle .... would I get the behavior I have now (expected?), or should it still wait until everything is 100% processed and the devices exist before exiting if sda was in the queue? >> You further said this is due to the >> speed improvements with 145 and I was just lucky in 141 and I should be >> waiting for the udev event that the device has been processed. I went >> over the chat logs again to make sure I'm not imagining things. >> > > Not sure what you mean, but it's probably not pending events and > udevsettle which causes your problem. Sound like events which are not > pending. > You definitely can not be sure that there are no future events coming > in, which are not queued anywhere at this moment, not in the kernel, > not in udev. You can not be sure about this at any point. And settle > can not do anything here. It's just the next interrupt from the > hardware that may cause your device to appear, and there is usually no > way to predict that. > The thing is trigger is sending the sda event to udev, I can see it if I enable debugging, but udevadm settle is exiting before /dev/sda exists. >> This will not work ... udevadm settle >> --exit-if-exists=/dev/disk/by-label/foo , 'udevadm settle' exits >> BEFORE the device is created. >> > > Might be. But then no event is pending as described above. If you wait > for a specific device, just loop until it shows up. I guess, you just > cannot use the udev queue to tell you anything it does not know. > By pending, do you mean trigger would queue it? because I can guarantee you if I enable debugging in trigger I see it. -N -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
