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

[Jiri Slaby <jirislaby@kernel.org>]

Hi,

On 08. 07. 20, 12:15, Hans de Goede wrote:
> Hi,
> 
> On 7/8/20 10:52 AM, Jiri Slaby wrote:
>> 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@kernel.org> 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.
>>
>> 15 that is.
> 
> Right, that is normal for an enabled device the ACPI method
> implementing the status attribute for your tablet looks like this:
> 
>             Method (_STA, 0, NotSerialized)  // _STA: Status
>             {
>                 If (((BDID == One) && (OSID != One)))
>                 {
>                     Return (0x0F)
>                 }
> 
>                 Return (Zero)
>             }
> 
> So now we know that BDID == One and OSID != One, OSID == One
> typically is Windows...
> 
> Looking at the buttons next, can you do:
> 
> cat /sys/bus/acpi/devices/ACPI0011:00/status

Gives 0

> and:
> 
> cat /sys/bus/acpi/devices/INTCFD9:00/status

Gives 15

> 
> If the BIOS thinks you are booting normal Windows the first
> one should output 15  (0xf) aka present and the second one
> should output 0, but I suspect it is the other way around...

Right.

> So looking at the GPIO resource definitions for BDID == One
> for the ACPI0011 device we have:
> 
>                 Name (PBUF, ResourceTemplate ()
>                 {
>                     GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp,
> 0x0BB8,
>                         "\\_SB.GPO2", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0008
>                         }
>                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
> 0x0BB8,
>                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x004E
>                         }
>                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
> 0x0BB8,
>                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0050
>                         }
>                 })
> 
> With a mapping of first resource to KEY_POWER, second resource to
> KEY_VOLUMEUP and third resource to KEY_VOLUMEDOWN
> 
> The INTCFD9 device OTOH has the following resource definitions for BDID
> == One
> 
>                 Name (PBUF, ResourceTemplate ()
>                 {
>                     GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp,
> 0x0BB8,
>                         "\\_SB.GPO2", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0008
>                         }
>                     GpioInt (Edge, ActiveBoth, ExclusiveAndWake,
> PullDefault, 0x
>                         "\\_SB.GPO1", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0008
>                         }
>                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
> 0x0BB8,
>                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x004E
>                         }
>                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
> 0x0BB8,
>                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0050
>                         }
>                 })
> 
> With a mapping of resource1: power, resource2: home, resource3: volume_up,
> resource4: volume_down.
> 
> So what we see here is that the "Android" style INTCFD9 device has
> an extra entry for the home-button and I guess (hard to see on the
> pictures) that there is no physical home-button.

I don't know what it should look like, but there is no button with
house-like painting. There is only a standard "Home" button -- Fn+PgUp.
And that works even without that module.

> Since the IRQ storm you are seeing on the home button is happening on
> GPO1 pin 8 which is only listed as a button on the "Android" style
> INTCFD9 device. I guess that the manufacturer started with a standard
> ACPI DSDT for these devices and then hacked up the Windows entries until
> they work.
> 
> Likewise the INT3496 entry likely is non-sense too. So you are seeing
> a storm from some floating GPIOs which are close enough to some
> other signals to pick up interference from them.
> 
> Conclusion: we need to get your BIOS to stop setting OSID to 0
> (Android) and get it to set it to 1 (Windows).
> 
>>> 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?
> 
> Ok, so some of these devices have some multi-boot code inside for
> dualbooting both Android and Windows and they automatically override
> the "OS selection" on every boot.
> 
> Since your device has only 1G of RAM it likely shipped with a 32
> bit Windows to save RAM and thus has either a 32 bit only UEFI,
> or a dual-mode UEFI. I'm guessing that it is the latter and when
> you inserted the boot-medium you used to install, the BIOS saw a
> EFI/BOOT/bootx64.efi binary on the boot-medium and switches to
> 64 bit mode which it associates with Android.

No, it has 2G of RAM.
# free -h
              total        used        free      shared  buff/cache
available
Mem:          1,8Gi       497Mi       786Mi       108Mi       567Mi
  1,1Gi
Swap:         2,0Gi          0B       2,0Gi

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.

> If you run:
> efibootmgr -v
> 
> You will likely see your current active boot entry point to
> something with x64 in the name, e.g. I have:
> 
> Boot0000* Fedora       
> HD(1,GPT,a662134d-b40c-48de-8811-e43fee1adfa3,0x800,0x82000)/File(\EFI\fedora\shimx64.efi)

As I wrote above:
Boot0001* opensuse
HD(1,GPT,3f7cc368-0736-45a3-b23e-e1c0eda840be,0x800,0xfa000)/File(\EFI\opensuse\grub32.efi)

I've tried your patches now, but it crashes the kernel due to omitted
chv_padreg(), so rebuilding with that fixed...

thanks,
-- 
js