Hi,
On 7/8/20 1:36 PM, Jiri Slaby wrote:
Hi,
On 08. 07. 20, 13:24, Hans de Goede wrote:
It also has only 32 but EFI. It doesn't recognize 64-bit binaries. I had
to load 32-bit grub first to load the installer from a USB. So this is
EFI-mixed mode as it is called.
Hmm, ok, with CHT I would really expect there to be a 64 bit UEFI and
your DSDT and the fact that my untested patch broke your boot, all do
show that this is Cherry Trail / Cherryview and not a Bay Trail.
I guess that doing:
cat /proc/cpuinfo | grep "model name"
Will output something like this:
model name : Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz
model name : Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz
model name : Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz
model name : Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz
Note the model bould be some other Z8xxx nummer, likely it is a
Z8350, and if not a Z8300 but any Z8xxx number is CHT.
Yes, correct:
model name : Intel(R) Atom(TM) x5-Z8350 CPU @ 1.44GHz
Further confirming that this really is Cherry Trail. Which
at least means that my patches might help a bit.
They do not :(. The interrupts are still storming.
FWIW I tried the acpi_osi="Windows 2015" kernel parameter. No success too.
But ideally we would still be able to get the BIOS to see
us as Windows and set its OSID variable to 1. So we don't
try to use the wrong GPIOs as IRQ at all. Can you try loading
the BIOS setup-defaults / optimal defaults?
Loaded the optimal values. Still the same
If that does not get rid of the IN3496 device (changes its
status to 0), then try this:
Maybe you have a "Boot Architecture" option under the "Boot"
menu in the BIOS? I know you are already at 32 bits, but
maybe changing it to 64 bits helps? (after installing a 64 bit
shim + grub)
Unfortunately, there is nothing like that. It's discussed on the net,
that these UMAXes have only 32bit EFI.
Which is not a problem by itself, mixed-mode support works well,
in Fedora we even support it out of the box.
What is a problem is the OSID thing. So one last silly idea,
can you try on your EFI system partition, creating a dir called:
EFI/Microsoft/Boot
So the Linux path of that likely is:
/boot/efi/EFI/Microsoft/Boot
And then copy your grub.efi to:
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
And then with efibootmgr create an entry
titled Windows pointing to that and try booting
that boot entry?
If that does not help and you cannot find any other helpful
options in the BIOS, the only thing I can think of is to
use a DSDT overlay with the OSID checks in the _STA method
of the INT3496, ACPI0011 and INTCFD9 ACPI objects
inverted (or removed).
That should get rid of the interrupt storm, but there are
a lot of other OSID checks and chances are some of those
will cause other issues.
Regards,
Hans
