Hi Kay, thanks for your answers! On Tue, Aug 2, 2011 at 15:30, Kay Sievers <kay.sievers@xxxxxxxx> wrote: > On Tue, Aug 2, 2011 at 16:57, Filipe Brandenburger <filbranden@xxxxxxxxx> wrote: >> I tried adding a call to "udevsettle" just before initializing VxVM >> but it doesn't help, whenever I have the problem that triggers that >> log message the devices do not show up even after udevsettle. I also >> tried "udevtrigger" but that didn't help either. > > Missing devices are likely not related to udev but your > driver/hardware/setup. I guess in the case you miss the stuff, you > also don't have the device in /sys/block, right? Indeed, that's the problem, the problem device is not present in /sys/block or in /dev. >> I saw this patch that looked interesting, it's from almost 4 years ago >> but it resembles the codebase of RHEL5 that I'm running: >> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=39ea7c6c67de69379b603196a0eff6f7ce2e469a >> >> I'm pretty much considering applying that patch to udevd since it will >> probably fix it, but as I can't reproduce the problem reliably I >> wanted to ask some questions just to have more confidence in going on >> with that fix. > > As said, that only makes the error logging go away, and maybe some > udev-event users that expect proper sysfs timing. Hmmm... So you're saying there's no correlation from the fact that I get the "wait_for_sysfs: waiting for ... failed" message and the fact that when I need the devices (on volume manager startup) they are still not present? Even if I have a call to "udevsettle" just before the volume manager initialization? Won't the failure of wait_for_sysfs affect the result of a "udevsettle" call? >> For instance, the log message is somewhat vague saying some SCSI disks >> take 6.5s to populate sysfs, does someone have some details of which >> kinds of disks cause that? > > I don't really remember the details, but it was probably the disk > spin-up time, that blocked the creation of the sysfs files for > seconds. The code that does that got all changed in later kernels to > be timed properly. Ok, so is it possible that this is the issue I have here? I only have it in one machine so it may be because of faulty/suboptimal SAN behind it? Thanks for your answers, I'm trying to get to the bottom of it and hopefully your help will lead me into the right direction! Fil -- 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
