Dell Latitude/Precision, sig=0x806ec/20090609: Linux hangs without plugged in power cable

[Paul Menzel]

Already present reported in project *dell-sputnik*. (Note, it happened here also without suspend/resume.):

1. https://bugs.launchpad.net/dell-sputnik/+bug/1661741
2. Quote from https://bugs.launchpad.net/dell-sputnik/+bug/1661741/comments/26:

    > A similar bug affects several Dell laptop models:
    > - Dell 5480/5488 :
    > https://bugs.launchpad.net/dell-sputnik/+bug/1866343
    > - Dell E5470 :
    > https://bugs.launchpad.net/dell-sputnik/+bug/1661741
    > (Note that the bug https://bugs.launchpad.net/dell-sputnik/+bug/1661741 is not fixed; it has been changed, by error, to fixed. Please, it will be nice if somebody can change the status to "confirmed")
    > - Dell 7740 :
    > https://bugs.launchpad.net/dell-sputnik/+bug/1871491
    >
    > I suppose that the bug can also affect Dell precision 7730

After experiencing this already on the Dell Latitude 5480/5488 (https://bugs.launchpad.net/dell-sputnik/+bug/1866343), we have seen this now too with the Dell Precision 3540 (with dedicated AMD graphics card).

Without the power cord plugged in, the system started fine, then updating packages, including the Linux kernel, turning the system off, and right back on, it went to GRUB, and GRUB was able to load Linux and initrd, and starting Linux it hung.

Num lock key didn’t respond (but also didn’t blink – no idea if this should work), and Ctrl + Alt + Del didn’t work either. So, the system had to be powered off by pressing the power button for some (ten(?)) seconds.

Subsequent tries didn’t help, until we remembered the issues with the other device, and plugging in the power cord fixed it.

With the power cable unplugged, it didn’t boot.

The state of the connected power cable only mattered, when starting the Linux kernel. That means, plugging it in, when GRUB was active, the system booted. Removing the cable, when GRUB was running, Linux hung.

I tried to get Linux messages, but `debug nomodeset earlyprintk=efi` didn’t get Linux to output any messages.

### Workarounds ###

I was able to get Linux booting by adding either one of the following Linux kernel parameters.

1. `maxcpus=1` (once it started with `maxcpus=2`)
2. `nosmp`
2. `acpi=off`
3. `nolapic`

In this state, there was only one CPU online. Trying to bring one more online, the system always froze instantly.

    echo 1 | sudo tee /sys/devices/system/cpu/cpu1/online

(Nothing in pstore either.) (Where maxcpus=2` worked, we were able to bring a third CPU online, but the system froze when trying the fourth.)

### Reproducibilty ###

Letting the system sit over night, and trying again in the morning, unfortunately, we did *not* test without a power cable plugged in, as we had an idea to test the non-USB-Type-C power cable. With that the system started.

Powering the system off, and unplugging the cable, the system booted without issues. So something changed.

We weren’t able to get it into a state, where it doesn’t boot in the last hour, but we would like this investigated, as we are giving these systems to our users.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1883065

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Paul Menzel (paulmenzel)]

It might be related to the latest microcode updates.

[You-Sheng Yang (vicamo)]

Could you also attach output of `dmesg | grep microcode:` and `lscpu` when booted with those work-arounds? And, most important of all, does purging intel-microcode work for you? You may need to warm boot 10 times to make sure it really boots normally.

[You-Sheng Yang (vicamo)]

[ 0.752256] microcode: sig=0x806ec, pf=0x80, revision=0xd6
[ 0.752261] microcode: Microcode Update Driver: v2.2.

So this might be a duplicate of bug 1862751.

[Paul Menzel (paulmenzel)]

    [ 0.000000] microcode: microcode updated early to revision 0xd6, date = 2020-04-23

The system was given to a user, so I won’t be able to test.

Maybe this bug is about two issues.

1. Sometimes boot failures (cold boot and from hibernate) with no power cable plugged in. (Yesteday, I wasn’t unable to reproduce it.)
2. SMP(?) issues due to latest microcode updates.

[Paul Menzel (paulmenzel)]

It looks like microcode update revision 0xd6 is still the officially shipped version.

The often occurring hangs without the power cable plugged in, are still happening.

Booting with `maxcpus=1` and adding

    earlyprintk=efi earlycon=efifb debug

to the Linux command, the last messages are:

    […]
    random: crng done (trusting CPU's manufacturer)
    Console: colour dummy device 80x25
    printk: console [tty0] enabled
    printk: bootconsole [efifb0] disabled

So, it might indeed be related to bug 1862751.

[Paul Menzel (paulmenzel)]

I create upstream issue https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/35.

[Yuan-Chen Cheng (ycheng-twn)]

as no activity for quite some time (same in the external bug), mark incomplete in oem-priority