On Tue, Aug 2, 2011 at 21:43, Filipe Brandenburger <filbranden@xxxxxxxxx> wrote: > 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. Then the kernel has not created the device. There is nothing that udev can do here. The message is probably only a fallout of an error that a SCSI LUN was created, but the it failed to setup the block device. >>> 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? It should only block until the timeout happens, which is 5 or 10 seconds, then settle should exit. >>> 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? It's probably the disk itself, but it's hard to tell from remote. You need to investigate the disk, and all the hardware that connects it to the host, or even the driver. I don't think it has anything to do with udev, or the upper layers. You need to see /sys/block/sdX, before you look into anything udev related. Kay Kay -- 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
