Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Jiri Slaby <jirislaby@xxxxxxxxxx>]

On 08. 07. 20, 10:23, Hans de Goede wrote:
> 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.

Hi,

It seems to be Baytrail.

> 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.

15 that is.

> 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

I had/have:
Advanced
  -> Droid boot = disabled
  -> Android boot = disabled
  -> OS selection = Windows 8.x (there is also GMIN and Android to select)

So there seems nothing I should change?

> 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 ?

Sure:
https://paste.opensuse.org/view/raw/79423338

> 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.

The bugs also suggest that this avoids storms thanks to different
handling in chv_gpio_irq_init_hw (if (!pctrl->chip.irq.init_valid_mask)
there).

thanks,
-- 
js