Fwd: How to determine which device crashes udev in boot?

* Fwd: How to determine which device crashes udev in boot?
@ 2016-03-15  1:39 iwillallways forget1
  2016-03-15  3:16 ` Greg KH
  0 siblings, 1 reply; 2+ messages in thread
From: iwillallways forget1 @ 2016-03-15  1:39 UTC (permalink / raw)
  To: linux-hotplug

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 --actiond (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

^ permalink raw reply	[flat|nested] 2+ messages in thread