Intel-gfx related suspend-to-ram issues on IBM R31

Intel-gfx related suspend-to-ram issues on IBM R31

[Thomas Richter]

Hi Daniel, hi Ville,

thanks for integrating my patches of the DVO chip of my old IBM R31.
With this patch in place, dithering on the laptop works now.

However, I recently upgraded to Debian Stretch, and since then, I'm
having either issues with 3D acceleration or with suspend-to-RAM.

Details are as follows: The machine comes with the infamous i830M
chipset, to be precise:

00:00.0 Host bridge: Intel Corporation 82830M/MG/MP Host Bridge (rev 04)
00:02.0 VGA compatible controller: Intel Corporation 82830M/MG
Integrated Graphics Controller (rev 04)
00:02.1 Display controller: Intel Corporation 82830M/MG Integrated
Graphics Controller

I previously run the machine on a 4.1.38 kernel and Debian jessie, and
everything (almost) worked. 3D acceleration worked (stable), and
suspend-to-ram and suspend-to-disk worked. I had to disable the S3 state
by a custom dsdt, but except that, everything was ok.

Now, after upgrading to stretch, something must have changed in the
userland. Even after booting with the identical 4.1.38 kernel, 3D
acceleration broke.

*Q1: What changed in userland, and is there a way to revert the changes?*

I tried now the system with various other kernels. Here is what happens:

- Under 4.9.49 (longterm), 3D acceleration works, the machine enters the
S1 state, but does not wake up anymore. Trying a suspend-trace, the
machine claims to hang in power/main.c:

[    0.952198]   Magic number: 0:791:321
[    0.967849]   hash matches drivers/base/power/main.c:742

This is the same location the machine hangs at when allowing it to enter
S3 (and there does not wake up). A code analysis is inconclusive.

- linux-4.1.38: (The old kernel): With new userland, 3D acceleration
does not work at all. S1 standby and resume work. With old userland, 3D
acceleration works before and after resume to S1 state (no issues).

- linux-4.1.44: 3d acceleration with new userland hangs, then stops
working with a GPU lockup, S1 works as in 4.1.38.

- linux-4.2.8: 3d acceleration with new userland unstable, breaks down
sooner or later, S1 standby and resume works, but GPU hangs after wakeup
and is then disabled.

- linux-4.3.6:  3d acceleration works, suspend to ram does not work at
all, i.e. the system does not even enter the S1 state.

- linux-4.14.0-rc1 (the latest release candidate on www.kernel.org): 3d
acceleration works, suspend does not work at all, the machine does not
enter the S1 state.

- linux 4.13.5-rc5+ (intel-drm, head branch): quite the same (machine
does not enter S1 state)

- linux 4.14.0-rc1+ (intel-drm-nightly): quite the same (machine does
not enter S1 state).

Enter S1 state: The IBM R31 has a status LED (a moon) that is lit
whenever the machine is in S1 or S3 state.

Any other hints or pointers I should try - or to help you debugging? It
is quite unsatisfying that the machine worked perfectly with jessie, but
3D broke with the latest userland.

Greetings,
	Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Intel-gfx related suspend-to-ram issues on IBM R31

[Ville Syrjälä]

On Thu, Sep 21, 2017 at 08:36:33PM +0200, Thomas Richter wrote:
> Hi Daniel, hi Ville,
> 
> thanks for integrating my patches of the DVO chip of my old IBM R31.
> With this patch in place, dithering on the laptop works now.
> 
> However, I recently upgraded to Debian Stretch, and since then, I'm
> having either issues with 3D acceleration or with suspend-to-RAM.
> 
> Details are as follows: The machine comes with the infamous i830M
> chipset, to be precise:
> 
> 00:00.0 Host bridge: Intel Corporation 82830M/MG/MP Host Bridge (rev 04)
> 00:02.0 VGA compatible controller: Intel Corporation 82830M/MG
> Integrated Graphics Controller (rev 04)
> 00:02.1 Display controller: Intel Corporation 82830M/MG Integrated
> Graphics Controller
> 
> I previously run the machine on a 4.1.38 kernel and Debian jessie, and
> everything (almost) worked. 3D acceleration worked (stable), and
> suspend-to-ram and suspend-to-disk worked. I had to disable the S3 state
> by a custom dsdt, but except that, everything was ok.
> 
> Now, after upgrading to stretch, something must have changed in the
> userland. Even after booting with the identical 4.1.38 kernel, 3D
> acceleration broke.
> 
> *Q1: What changed in userland, and is there a way to revert the changes?*
> 
> I tried now the system with various other kernels. Here is what happens:
> 
> - Under 4.9.49 (longterm), 3D acceleration works, the machine enters the
> S1 state, but does not wake up anymore. Trying a suspend-trace, the
> machine claims to hang in power/main.c:
> 
> [    0.952198]   Magic number: 0:791:321
> [    0.967849]   hash matches drivers/base/power/main.c:742
> 
> This is the same location the machine hangs at when allowing it to enter
> S3 (and there does not wake up). A code analysis is inconclusive.
> 
> - linux-4.1.38: (The old kernel): With new userland, 3D acceleration
> does not work at all. S1 standby and resume work. With old userland, 3D
> acceleration works before and after resume to S1 state (no issues).
> 
> - linux-4.1.44: 3d acceleration with new userland hangs, then stops
> working with a GPU lockup, S1 works as in 4.1.38.
> 
> - linux-4.2.8: 3d acceleration with new userland unstable, breaks down
> sooner or later, S1 standby and resume works, but GPU hangs after wakeup
> and is then disabled.
> 
> - linux-4.3.6:  3d acceleration works, suspend to ram does not work at
> all, i.e. the system does not even enter the S1 state.
> 
> - linux-4.14.0-rc1 (the latest release candidate on www.kernel.org): 3d
> acceleration works, suspend does not work at all, the machine does not
> enter the S1 state.
> 
> - linux 4.13.5-rc5+ (intel-drm, head branch): quite the same (machine
> does not enter S1 state)
> 
> - linux 4.14.0-rc1+ (intel-drm-nightly): quite the same (machine does
> not enter S1 state).
> 
> Enter S1 state: The IBM R31 has a status LED (a moon) that is lit
> whenever the machine is in S1 or S3 state.
> 
> Any other hints or pointers I should try - or to help you debugging? It
> is quite unsatisfying that the machine worked perfectly with jessie, but
> 3D broke with the latest userland.

drm-tip + https://patchwork.freedesktop.org/patch/176870/ works rather
well on my 830 machine (Fujitu-Siemens Lifebook S6010). Without that
things gets stuck on account of vblank interrupts getting disabled at
random times. Xonotic has been pretty good at reproducing that bug for
me. Apart from that S3 works, S4 works, never tried S1 and probably
never will since I have S3 ;)

There are some bugs in Mesa though. One at least (a missing workaround)
can cause the GPU to die. I think the current upstream Mesa doesn't hit
it very reliably because it inlines the vertex data into the batch.
I've been working on making it use vertex buffers instead, and I think
that made me hit it more reliably. I have a pile of patches for Mesa
that I need to clean up at some point. In the meantime here's the diff
for that one fix (probably won't apply as is since I have it sitting
on top a pile of other stuff atm):

diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c b/src/mesa/drivers/dri/i915/i830_vtbl.c
index 0da5a8118c7f..a9d5a6f37067 100644
--- a/src/mesa/drivers/dri/i915/i830_vtbl.c
+++ b/src/mesa/drivers/dri/i915/i830_vtbl.c
@@ -416,7 +416,7 @@ get_state_size(struct i830_hw_state *state)
       sz += sizeof(state->Ctx);
 
    if (dirty & I830_UPLOAD_BUFFERS)
-      sz += sizeof(state->Buffer) + 2 * 4; /* 2 relocs */
+      sz += sizeof(state->Buffer) + (2+7) * 4; /* 2 relocs + w/a */
 
    if (dirty & I830_UPLOAD_STIPPLE)
       sz += sizeof(state->Stipple);
@@ -514,9 +514,14 @@ i830_emit_state(struct intel_context *intel)
    }
 
    if (dirty & I830_UPLOAD_BUFFERS) {
+      /* 830: 3DSTATE_BUFFER_INFO must not straddle two cachlines */
+      int align = (8 - (intel->batch.used & 7)) & 7;
+
       DBG("I830_UPLOAD_BUFFERS:\n");
 
-      BEGIN_BATCH(18);
+      BEGIN_BATCH(18+align);
+      while (align--)
+         OUT_BATCH(MI_NOOP);
       OUT_BATCH(state->Buffer[I830_DESTREG_CBUFADDR0]);
       OUT_BATCH(state->Buffer[I830_DESTREG_CBUFADDR1]);
       if (state->draw_region)
-- 
2.13.5

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Intel-gfx related suspend-to-ram issues on IBM R31

[Thomas Richter]

Hi Ville,

Thanks for the pointers. However, which branch of mesa does this
> 
> drm-tip + https://patchwork.freedesktop.org/patch/176870/ 

patch apply to? I assume it is the intel-drm-nightly? Tried that, 
without success. While the 4.9.xx reaches at least S1, this one gets 
stuck earlier, with or without the patch.

> works rather
> well on my 830 machine (Fujitu-Siemens Lifebook S6010). Without that
> things gets stuck on account of vblank interrupts getting disabled at
> random times. Xonotic has been pretty good at reproducing that bug for
> me. Apart from that S3 works, S4 works, never tried S1 and probably
> never will since I have S3 ;)

Well, you forget that the IBM R31 "made by Acer" has a quite buggy bios 
compared to the Fujitsu. Unfortunately, my S6010 died about two years 
ago, a very nice machine for its age, actually. The R31 never woke up 
from S3, the Fujitsu did from the 4.1.38 kernel. The same kernel worked 
only for S1, though Win XP seems to manage it on the same hardware.


> There are some bugs in Mesa though. One at least (a missing workaround)
> can cause the GPU to die. I think the current upstream Mesa doesn't hit
> it very reliably because it inlines the vertex data into the batch.
> I've been working on making it use vertex buffers instead, and I think
> that made me hit it more reliably. I have a pile of patches for Mesa
> that I need to clean up at some point. In the meantime here's the diff
> for that one fix (probably won't apply as is since I have it sitting
> on top a pile of other stuff atm):

Sorry, again the same question: I checked the head branch, but there the 
functions look quite different. I tried to tweak it in, there seems to 
be the same sort of misalingment issue, but it's really not the same 
structure. With the modifications below "fiddled in", I do not see much 
of of a difference.

Thanks and greetings,

Thomas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Intel-gfx related suspend-to-ram issues on IBM R31

[Jani Nikula]

On Sat, 23 Sep 2017, Thomas Richter <thorfdbg@t-online.de> wrote:
> Hi Ville,
>
> Thanks for the pointers. However, which branch of mesa does this
>> 
>> drm-tip + https://patchwork.freedesktop.org/patch/176870/ 
>
> patch apply to? I assume it is the intel-drm-nightly? Tried that, 
> without success. While the 4.9.xx reaches at least S1, this one gets 
> stuck earlier, with or without the patch.

drm-tip branch of [1].

BR,
Jani.

[1] https://cgit.freedesktop.org/drm/drm-tip


>
>> works rather
>> well on my 830 machine (Fujitu-Siemens Lifebook S6010). Without that
>> things gets stuck on account of vblank interrupts getting disabled at
>> random times. Xonotic has been pretty good at reproducing that bug for
>> me. Apart from that S3 works, S4 works, never tried S1 and probably
>> never will since I have S3 ;)
>
> Well, you forget that the IBM R31 "made by Acer" has a quite buggy bios 
> compared to the Fujitsu. Unfortunately, my S6010 died about two years 
> ago, a very nice machine for its age, actually. The R31 never woke up 
> from S3, the Fujitsu did from the 4.1.38 kernel. The same kernel worked 
> only for S1, though Win XP seems to manage it on the same hardware.
>
>
>> There are some bugs in Mesa though. One at least (a missing workaround)
>> can cause the GPU to die. I think the current upstream Mesa doesn't hit
>> it very reliably because it inlines the vertex data into the batch.
>> I've been working on making it use vertex buffers instead, and I think
>> that made me hit it more reliably. I have a pile of patches for Mesa
>> that I need to clean up at some point. In the meantime here's the diff
>> for that one fix (probably won't apply as is since I have it sitting
>> on top a pile of other stuff atm):
>
> Sorry, again the same question: I checked the head branch, but there the 
> functions look quite different. I tried to tweak it in, there seems to 
> be the same sort of misalingment issue, but it's really not the same 
> structure. With the modifications below "fiddled in", I do not see much 
> of of a difference.
>
> Thanks and greetings,
>
> Thomas
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx