Greg KH, thank you for replying to me, since your bot on your documented e-mail address kept deleting my message and kept telling me to resend if I really intended to mail you, whereupon it automatically deleted the resends, etc. Does anyone know why my real e-mail address n0diamond attract yahoo dotty co dotty jp iw disliked by vger.kernel.org? What spam does it accuse me of spamming? Greg KH wrote: > I (Norman Diamond) wrote: >> I'm trying to narrow which device in an NEC VF-6 causes Linux boots to >> hang, permanently, in udevadm trigger and udevadm settle. Many Google >> searches found many pages but no tutorials on how to debug udev this >> way. >> I downloaded fresh copies of Porteus 3.1 32-bit and 64-bit. > > What kernel versions are these? 3.17.4. I had the same problem with kernel 3.4.something and probably some older ones, but that's probabky beside the point because the question of how to track down the device is a udev question. >> Porteus 3.1 64-bit boots fine, udev finds everything, x Windows works >> (I told you Windows rulez) (Oh yeah, I created a throwaway account on outlook.com but vger.kernel.org accused my brand new account of being a spammer too, and I forgot to delete that part when trying to send from gmail.com) >> etc. Even on this NEC VF-6. >> >> Porteus 3.1 32-bit boots fine on everything except this NEC VF-6, x >> Windows works, etc. >> >> Porteus 3.1 32-bit hangs when starting udev on this NEC VF-6. >> >> Booting with "3 nohotplug" works (3 tells Porteus what run level to >> use, and nohotplug is observed by both the kernel and Porteus). In >> text mode I can do some amount of experiments. I don't know how to do >> meaningful experiments, to try to track down which device causes the >> hang. > > Try looking at the documentation of udevadm, you can manually enable the > 'coldplug' options there to narrow down what hardware is causing the > problem. That's exactly what I want to do. Several Google searches today were as futile as dozens of Google searches during the past week. As far as I can tell, udevadm trigger --action=add (the same as in rc.udev) adds everything, and there is some way to exclude an individual device but I haven't found how to specify a device correctly to get it excluded. --max-childs=1 and stuff like that have not helped. > Odds are, you have a kernel driver that doesn't like the > hardware and it is getting loaded automatically by udev. Yes, that's why I'm asking how to track down which device it is. If the problematic device is something not needed for my employer's product, I can try to blacklist the device if I can figure out or get help to do it. But first I have to find out which device it is. Some devices obviously have drivers running already before udevd and udevadm trigger get started. But for example if I type startx then the video driver gets loaded dynamically and the keyboard and mouse die dynamically, so I have to press the power switch. So I think the kernel hang comes from some other driver getting loaded dynamically after udevd starts and udevadm triggers everything, but I can't find what device it is. Some device has a working driver for Porteus's 64-bit kernel but a crashing driver for Porteus's 32-bit kernel, and the crash is so hard that it doesn't even start flashing two keyboard lights. Also this being text mode (when I type udevadm not startx), the crash is so hard that it doesn't print an oops. greg k-h -- 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
