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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux