From: iwillallways forget1 <iwillalwaysforget1@gmail.com>
To: linux-hotplug@vger.kernel.org
Subject: How to determine which device crashes udev in boot?
Date: Mon, 14 Mar 2016 04:48:39 +0000 [thread overview]
Message-ID: <CAD4SBxADbDuHn45WNxqdcRfFM=uu8=vXUYLhKc6JNaY5JL-DLw@mail.gmail.com> (raw)
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.
Porteus 3.1 64-bit boots fine, udev finds everything, x Windows works
(I told you Windows rulez), 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. It's
not a 120-second timeout in udevadm settle. It never wakes up. The
Caps Lock key stops toggling the Caps Lock light. The Num Lock key
stops toggling the Num Lock light. Ctrl+Alt+Delete is ignored. It
does not appear to be a kernel panic because two of the keyboard
lights don't flash. It is hanged, frozen, dead.
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.
The kernel in Porteus 3.1 32-bit is configured with EISA enabled but
not in Porteus 3.1 64-bit. I think I could figure out how to try
udevadm trigger excluding eisa, but it still hanged. The PC doesn't
actually contain any EISA devices, so there's an eisa.0 bus but no
actual devices, so this experiment didn't change anything.
Obviously for myself I could just run 64-bit Linux on this PC, but
this doesn't solve the problem. I have to provide something that
customers can run on any PC made since around 1999, and a lot of those
don't have 64-bit CPUs. I don't know if NEC VF-6 is the only model
that has problems, but I have to be able to patch something to work
around this kind of problem when I learn about them.
Someone found that pci=use_crs solved udev hangs on some PCs, but it
didn't help on NEC VF-6.
(By the way, my name is Norman Diamond. vger.kernel.org bounces mail
from my real e-mail address n0diamond atsign yahoo period co period jp
because I've been a big bad spammer, but I don't know what spams I
seent.)
next reply other threads:[~2016-03-14 4:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 4:48 iwillallways forget1 [this message]
2016-03-14 17:49 ` How to determine which device crashes udev in boot? Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAD4SBxADbDuHn45WNxqdcRfFM=uu8=vXUYLhKc6JNaY5JL-DLw@mail.gmail.com' \
--to=iwillalwaysforget1@gmail.com \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).