Watchdog catches hard CPU lock in 4.8.11

[iwillallways forget1]

 This is on a Dell Latitude D830 with 4GB of RAM.  I am booting kernel
4.8.11 from a live Linux distribution in a USB stick.  The CPU is a
Core 2 Duo T7100 capable of 64-bit kernels but this live Linux kernel
is 32-bit.  The hard drive has Windows 7 and is not involved in this
live Linux system.

Approximately the last five lines on the screen are quoted below.  The
third line wrapped around several times but I'm quoting it as a single
line, which will wrap differently in e-mail.  The third line contains
a misquotation.  The word cpu1*dModules doesn't have an asterisk in
the middle; it has a smiley face in one character cell which I cannot
quote properly.

The LED for NumLock is on but CapsLock and ScrollLock are off, and
there is no visible panic stack trace.

Starting system message bus:  /uar/bin/dbus-uuidgen --ensure ;
/usr/bin/dbus-daemon --system
Starting HAL daemon:  /usr/sbin/hald --daemon=yes
[   47.131508] NMI watchdog: Watchdog detected hard LOCKUP on
cpu1*dModules linked in: snd_hda_codec_hdmi arc4 b43 mac80211 cfg_pc
8250 parport dell_rbtn 8250_base thermal firewire_ohci acpi_cpufreq
tpm_tis tpm_tis_core gpio_ich tpm firewire_core sg wmi snd_hda_intel
ac dell_laptop dell_smbios intel_agp i2c_i801 i2c_smbus i2c_core
snd_hda_codec ssb button snd_hda_core snd_hwdep snd_pcm tg3 intel_gtt
agppart libphy rfkill dcdbas ptp evdev pps_core input_leds hwmon
psmouse battery serio_raw lpc_ich snd_timer snd soundcore
Loading OSS compatibility modules for ALSA
Setting default ALSA mixer settings.

Ctrl+Alt+Delete does not work.  I used the power switch to turn it off
and on again.  After rebooting, the system locked up at this point:

Starting system message bus:  /uar/bin/dbus-uuidgen --ensure ;
/usr/bin/dbus-daemon --system
Starting HAL daemon:  /usr/sbin/hald --daemon=yes

I wonder what happened to the NMI watchdog this time.

It gets stranger.  I pressed the power button but released it when the
next two lines came up.

INIT: Switching to runlevel: 0
INIT: Sending processes the TERM signal

But nothing further.  The LEDs are the same as last time, no evidence
of panic.  A second temporary press of the power button has no further
effect so I have to hold it 4 seconds to power off.

Windows 7 still boots.  A SigmaTel High Definition Codec (vendor 8348
device 76A0) and HDA CX11270 Soft Modem (vendor 1F41 device 2C06) are
attached to High Definition Audio Controller (vendor 8086 device
284B).  The video chip is Nvidia Quadro NVS 140M but I doubt that's
the problem; Linux has already started using the frame buffer well
before getting to the hang.  To the best of my knowledge the TPM chip
has never been used; it is off in the BIOS and not visible in Windows.

The reason for today's experiment is that a colleague reported boot
failing on a Dell Latitude D505.  His failure occurs earlier in the
boot process than mine.  I don't think his gets as far as dbus.

A Dell Latitude E6500 with a Core 2 Duo P8700 boots.

My live Linux system has to work on any PC made since around year
2000.  Does anyone even know if I can just blacklist something in the
kernel command line to get it to boot?

And then...

> Subject: Failure Notice
>
> Sorry, we were unable to deliver your message to the following address.
>
> <linux-kernel@xxxxxxxxxxxxxxx>:
> Remote host said: 553 5.7.1 Hello [183.79.56.187], for your MAIL FROM address
> <censored> policy analysis reported: Your address is not
> liked source for email  [MAIL_FROM]

100% of my e-mail addresses are on ordinary ISPs known for sending
large volumes of legitimate e-mail and moderate volumes of spam.  Why
do you accept bug reports from anyone else?

The sender address on this e-mail is one that I hardly ever check.  It
uses a provider known for sending large volumes of legitimate e-mail
and moderate volumes of spam, but I rarely look at this one.