Hi all,
On 7/8/20 9:47 AM, Linus Walleij wrote:
On Wed, Jul 8, 2020 at 9:18 AM Jiri Slaby <jirislaby@xxxxxxxxxx> wrote:
I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
even then it encounters lags, soft lockups:
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
Adding Hans de Goede to Cc, he often deals with this kind of weirdness
so he might have some ideas here.
Thank you for looping me in Linus. I've read up on the rest of the
thread in the archives.
So looking at this:
https://www.umax.cz/umax-visionbook-10wi/
This device appears to be a pretty standard Cherry Trail based 2-in-1
with detachable keyboard. Which usually means (with all the hw-enablement
I've been doing the last 2 years for these) that it will just work.
But no such luck this time it seems.
What I find interesting / weird is that you (Jiri) get an active
(/sys/bus/acpi/devices/INT3496\:00/status != 0) INT3496 device at
all. That typically only happens when the BIOS thinks you are booting
Android.
Now you may think that Android == Linux so that should be good,
but Intel did a real frankenstein solution for Android X86, see:
https://github.com/intel/ProductionKernelQuilts
for all the 5000 downstream patches in al their glory (hint your
life will be better if you don't take a look).
The much saner support for these devices which eventually got added
to the mainline kernel actually works much better with the "Windows"
profile of the BIOS, since the mainline code expects sane ACPI tables
and the Android targetting ACPI tables are a bit of a mess.
So the first thing to do is to go into the BIOS setup and see if
there is a setting for this (this depends on if the BIOS is
unlocked and has like a gazillion settings, or if it is locked
to only show a few settings).
I just checked on one of own CHT devices and there the option is
under Advanced -> System Component -> OS IMAGE ID
If you have that option (or a similar android/windows toggle
elsewhere) try setting it to Windows and see if that helps.
I would expect the INT3496 device to disappear when you do
this (it will be replaced by an ACPI event handler for the
USB id pin GPIO, so I guess we might change one interrupt
storm for the other).
Also can you put an acpidump of this device up somewhere,
or send me a private email with it ?
Regards,
Hans
p.s.
As for adding your device's DMI id to the chv_no_valid_mask
dmi table not helping. That is somewhat expected, that table
activates a bug to work around an *IRQ* numbering problem
for some older Chromebooks which use direct IRQ resources
in combination with broken IRQ numbering. The chromebooks
adjusted the ACPI tables to deal with a bug in the Linux kernel,
then when we fixed the bug so that things would work with
the gazillion Windows devices out there, we had to add the
quirk to restore the buggy behavior for the chromebooks.
