Otto Moerbeek <o...@drijf.net> wrote: > On Mon, May 27, 2019 at 04:57:48AM -0600, Theo de Raadt wrote: > > > Claudio Jeker <cje...@diehard.n-r-g.com> wrote: > > > > > On Sat, May 25, 2019 at 03:53:03PM +0100, Maurice McCarthy wrote: > > > > On 25/05/2019, Timo Myyrä <timo.my...@bittivirhe.fi> wrote: > > > > > Tristan Pilat <cont...@tristanpilat.com> writes: > > > > > > > > > >> Hi OpenBSD users and devs! > > > > >> > > > > >> I got a new laptop in January, a thinkpad x280. At that time my > > > > >> system > > > > >> running 'current' was very slow and I assumed the video acceleration > > > > >> wasn't working so I just sadly stuck with Debian for a while. I then > > > > >> saw that an update of the inteldrm landed in current a month ago or > > > > >> so > > > > >> so I tried yesterday to reinstall current. Unfortunately the system > > > > >> is > > > > >> still barely usable. Could you guys tell me why the video > > > > >> acceleration > > > > >> isn't handled? Isn't Kaby lake compatible for now? I saw this article > > > > >> (https://jcs.org/2017/05/22/xiaomiair) which says it is. > > > > >> > > > > > > > > You may have to adjust the aperture > > > > See /etc/examples/sysctl.conf > > > > > > > > #machdep.allowaperture=2 # See xf86(4) > > > > > > > > > > Nope. That does not help. I bet the issue is not related to anything > > > related to inteldrm. It is most probably an interrupt storm happening > > > because of Thunderbolt 3. At least that seems to be something people > > > complained about. > > > > Same sort of thing happened with x1rev6, but various folk figured out BIOS > > options which could prevent it, and newer BIOS replacements also improved > > the situation. Please study it and see if you can find some clues. > > I'm up-to-date with the newest BIOS on my X1 6th but I see acpi0 > eating lots of CPU if I connect a displayport device. Playing with > options does not fix this for me. The workaround I'm using now see > below) is very unsatisfactory, but I have no clue on where I should be > looking for a real fix and no one with knowledge in this area has > surfaced to look into this problem. > > -Otto > > Index: acpi.c > =================================================================== > RCS file: /cvs/src/sys/dev/acpi/acpi.c,v > retrieving revision 1.367 > diff -u -p -r1.367 acpi.c > --- acpi.c 12 May 2019 15:52:52 -0000 1.367 > +++ acpi.c 27 May 2019 11:07:52 -0000 > @@ -2262,6 +2262,10 @@ acpi_gpe(struct acpi_softc *sc, int gpe, > struct aml_node *node = arg; > uint8_t mask, en; > > + static unsigned short count111; > + if (gpe == 111 && count111++ != 0) > + return 0; > + > dnprintf(10, "handling GPE %.2x\n", gpe); > aml_evalnode(sc, node, 0, NULL, NULL);
It is good clue to know what GPE is firing. Next step is to see what parts of AML use that GPE. (I still suspect it is related to Thunderbolt 3 / xhci / etc)
