Any M18 R1 AMD owner that could help me?

[jimmypops]

I have a brand new M18 R1 AMD that has trouble booting linux when on battery power and I was hoping someone else with this machine could verify that they also have this issue. It is very easy to replicate, even if you are on windows. Just download any recent linux live usb/installer like ubuntu 22.04 or Fedora 38 Workstation or Archlinux (I have reproduced it on all of these) and see if you can boot into the live usb while the computer is not plugged in and the battery is below 60%.

 

For me, it gets part way through the boot process and then either shuts down or reboots.

 

I have tried tons of things to fix this, including entirely replacing the battery, but it occurs consistently no matter what. It would be a big help if someone could verify that this happens for them, too, so I can tell whether or not I may have defective hardware.

 

This does not happen with windows, windows installs and boots fine.

[win32asmguy]

I can test fedora 38 tonight, but mine is the Intel model. I will let you know if I can replicate it. I take it you have also installed to an SSD but it still cannot boot on battery under 60%?

[jimmypops]

Thanks!  Yeah I have installed to the internal nvme drives and Ive tried several--same behavior.  But yah it replicates even booting from a live usb so that's the easiest way to replicate it.

 

I believe there is something screwy with the BIOS and it needs an update from Dell.  I am using the newest BIOS (1.8.2) . 

[win32asmguy]

I tested cold / hot booting Fedora 38 (kernel 6.3.8, nvidia 530.41.03, xorg, bios 1.8.1) with battery power under 60%, no issues. I did have to set nvidia-drm.modeset=1 to get rid of a phantom display but that issue occurred regardless of being on battery or plugged in. I do have secure boot disabled and no battery charge limiter set.

 

I have had a similar issue with the Precision 7740 in the past (would not boot linux on battery). The issue was a bad Intel CPU microcode update bundled with Ubuntu at the time which had to be disabled via a kernel flag.

[jimmypops]

Thanks for checking.  I guess I'll need to file a linux kernel bug and hope someone can help me narrow down the issue.  With your 7740, did the issue start after a BIOS update?  I'm having a hard time figuring out which microcode updates there might be on the AMD 7945HX. 

[win32asmguy]

The 7740 issue started occurring after the microcode update was pulled in with routine updates to the distribution.

 

In general you could try booting with "acpi_osi=! acpi_osi='Windows 2022'". Are you booting with the MUX set to hybrid or dedicated mode?

 

Also curious if you have tested Windows 10 on the AMD M18 R1 variant.

[jimmypops]

Thanks for the tips.  I tried those kernel args and they did not change the behavior.  acpi=off does work, though, but of course tons of devices don't work so the computer becomes pretty unusable. 

 

I am using it in dedicated mode but the same thing happens in hybrid graphics mode.  None of the BIOS options seem to affect this issue.

 

I have not tried Windows 10.  Why are you curious about the result with windows 10?  What would this tell you?  I have tried windows 11 and it works fine, though.

[win32asmguy]

You might also try the kernel params "iommu=soft" or "dis_ucode_ldr" to see either allows it to boot. I would be curious if the same problem happens with the Asus or Lenovo models using dragon range chips.

 

I was curious about Windows 10 just because sometimes compatibility is not gauranteed and it is what I would run if I had one. Luckily the m18 Intel model has full support for Windows 10 22H2. Last year I tested the Asus Strix Scar 17 with Intel 12th Gen HX and it did not fully support Windows 10 and was missing many critical drivers, for the USB controllers for instance. It also was not able to easily boot Linux on it either - the bios had some kind of arcane grub2 memory mapping issue.

[jimmypops]

I tried those kernel params but no luck.  But thanks please let me know if you have any other ideas.  It looks like I'm gonna have to file a kernel bug even though most likely the issue is on the dell end. 

 

I'm surprised I can't find anyone else with this problem.. I suppose very few people are using the dragon range chips with linux.  I can't find anything on google. 

 

I did a head to head with my 5950x desktop, compiling some code, and the 7945 was 20-30% faster.  Crazy.