DragonFlyBSD

What's the interrupt rate of acpi0, before you load the i915?

On Mon, Dec 4, 2017 at 3:47 PM, <bugtracker-admin@leaf.dragonflybsd.org> wrote:

Issue #3107 has been reported by oyvinht.

----------------------------------------
Bug #3107: ACPI interrupt storm when loading i915 on Lenovo T460
http://bugs.dragonflybsd.org/issues/3107

• Author: oyvinht
• Status: New
• Priority: Normal
• Assignee:
• Category: ACPI
• Target version: 5.0.0
  ----------------------------------------

This is on a Lenovo T460 (firmware r06uj56d)

root# uname -a
DragonFly slaptop 5.1-DEVELOPMENT DragonFly v5.1.0.381.ge8ac90-DEVELOPMENT #10: Mon Dec 4 07:52:28 CET 2017 root@slaptop:/usr/obj/usr/src/sys/SLAPTOP x86_64

After doing:

root# kldload i915

the systems gets very slow, and looking at vmstat I see interrupts from acpi0 increasing by 2000-5000 every second (using kern.livelock_lowater=1000 and kern.livelock_limit=2000 makes the system usable again):

root# vmstat -i

interrupt total rate
acpi0 1681307 1925

FWIW I have tested enabling DDB and INVARIANTS in the kernel, and built /sys/dev/acpica with ACPI_DEBUG=1, which fills the kernel message buffer with messages like:

evgpe-0634 EvGpeDetect : Read registers for GPE 60-67: Status=40, Enable=46, RunEnable=46, WakeEnable=00
evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 68-6F: RunEnable=00, WakeEnable=00
evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 70-77: RunEnable=00, WakeEnable=00
evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 78-7F: RunEnable=00, WakeEnable=00
evevent-0361 EvFixedEventDetect : Fixed Event Block: Enable 00000120 Status 00000001
evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 00-07: RunEnable=00, WakeEnable=00
evgpe-0607 EvGpeDetect : Ignore disabled registers for GPE 08-0F: RunEnable=00, WakeEnable=00

--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

--
Tomorrow Will Never Die

sepherosa wrote:

What's the interrupt rate of acpi0, before you load the i915?

interrupt total rate
acpi0 345 8

Hello

Not sure if this might help, but I had a similar issue with an i7 skylake desktop (with a gigabyte GA-Q170M-D3H mobo). acpi0 generated 25000 interrupts per second and the machine was quite sluggish. Although it seemed at first as if loading i915 caused this, it did not turn out to be true in the end. I booted up several times and loaded i915, sometimes the high interrupt rate was there before loading i915, on other times it appeared after loading i915. Actually, on one occasion the interrupt rate was 30000 before loading i915 and decreased to 25000 after loading i915. FreeBSD was affected in the same way.

The issue resolved after updating BIOS firmware. acpi0 generated the total of 4 interrupts upon booting and none thereafter.

So I suggest try updating the BIOS to its latest and see if the problem persists.

Peeter

--

oyvinht wrote:

This is on a Lenovo T460 (firmware r06uj56d)

root# uname -a
DragonFly slaptop 5.1-DEVELOPMENT DragonFly v5.1.0.381.ge8ac90-DEVELOPMENT #10: Mon Dec 4 07:52:28 CET 2017 root@slaptop:/usr/obj/usr/src/sys/SLAPTOP x86_64

After doing:

root# kldload i915

the systems gets very slow, and looking at vmstat I see interrupts from acpi0 increasing by 2000-5000 every second (using kern.livelock_lowater=1000 and kern.livelock_limit=2000 makes the system usable again)

[...]

The same thing here:

Lenovo T460p (i7-6700HQ), bios version r07et83w (2.23; ok, last version is 2.24)
Tested on 5.3-DEVELOPMENT (yesterday snapshot)

Temperature jumps instantly from 40 to 65 degrees.

Luca

I was able to load i915 in console without errors and no acpi GPE storm by roughly removing:

Method (_L66, 0, NotSerialized)  // _Lxx: Level-Triggered GPE, xx=0x00-0xFF
{
             If (\_SB.PCI0.GFX0.GSSE (\_SB.PCI0.GFX0.GSCI ())){}
             Else
    {
                 \_SB.PCI0.SMBU.CPSC = 0x01
             }
         }

from dsdt.dsl.

Unfortunately this caused a page fault panic when starting X.

Luca