Re: Watchdog catches hard CPU lock in 4.8.11

[iwillallways forget1 <iwillalwaysforget1@gmail.com>]

Solved by upgrading to kernel 3.14.4.

The hangs in booting the D830 (in an unknown driver after hald starts)
and the D505 (much earlier in the boot process, maybe in USB HID even
though no HID device is attached) were solved by booting 3.14.4
instead of 4.8.11.

> 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@vger.kernel.org>:
>> 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.