Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #62591 > unrolled thread

Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201 Russel Winder <russel@winder.org.uk> - 2018-11-29 11:20 +0100
    Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201 Cyril Brulebois <cyril@debamax.com> - 2018-12-15 22:40 +0100
      Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201 Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2018-12-16 00:10 +0100
        Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201 Ben Hutchings <ben@decadent.org.uk> - 2018-12-16 02:40 +0100

#62591 — Bug#914980: linux-image-4.18.0-3-amd64: linux image installed via 4.18.0-3 won't reboot on T500 and X201

[Multipart message — attachments visible in raw view] — view raw

It is also perhaps worth noting that whilst this new kernel reboots fine on a
Lenovo X1, on the T500 and X201 rebooting just locks the laptops up requiring
a forced power button shutdown.

[toc] | [next] | [standalone]

#62743

[Multipart message — attachments visible in raw view] — view raw

Hi Russel and others,

Russel Winder <russel@winder.org.uk> (2018-11-29):
> It is also perhaps worth noting that whilst this new kernel reboots
> fine on a Lenovo X1, on the T500 and X201 rebooting just locks the
> laptops up requiring a forced power button shutdown.

There's a pending patch upstream (at least in drm-intel) for this bug:
  https://patchwork.freedesktop.org/patch/265653/

but it doesn't seem to apply cleanly on v4.18.20:
| Changes to be committed:
| 
| 	modified:   drivers/gpu/drm/i915/i915_drv.h
| 	modified:   drivers/gpu/drm/i915/i915_gpu_error.c
| 
| Unmerged paths:
|   (use "git add <file>..." to mark resolution)
| 
| 	both modified:   drivers/gpu/drm/i915/i915_gem.c
| 	both modified:   drivers/gpu/drm/i915/intel_engine_cs.c
| 	both modified:   drivers/gpu/drm/i915/intel_lrc.c
| 	both modified:   drivers/gpu/drm/i915/intel_ringbuffer.c
| 	both modified:   drivers/gpu/drm/i915/intel_ringbuffer.h

with things like:
| diff --cc drivers/gpu/drm/i915/intel_ringbuffer.h
| index 010750e8ee44,72edaa7ff411..000000000000
| --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
| +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
| @@@ -415,7 -436,9 +415,13 @@@ struct intel_engine_cs 
|   
|         struct intel_hw_status_page status_page;
|         struct i915_ctx_workarounds wa_ctx;
| ++<<<<<<< HEAD
|  +      struct i915_vma *scratch;
| ++=======
| +       struct i915_wa_list ctx_wa_list;
| +       struct i915_wa_list wa_list;
| +       struct i915_wa_list whitelist;
| ++>>>>>>> 517974992593... drm/i915: Allocate a common scratch page
|   
|         u32             irq_keep_mask; /* always keep these interrupts */
|         u32             irq_enable_mask; /* bitmask to enable ring interrupt */

I might have missed it, but I wasn't able to spot this commit's
being advertised on stable@ anyway, at least by manually checking:
  https://www.spinics.net/lists/stable/

(hence Chris Wilson in copy.)

Since that doesn't look like things I can fix on my own, I took
inspiration from a bug reporter[1], trying to simply revert the
offending patch (which is said to be fixed by the commit message
of 5179749925933575a67f9d8f16d0cc204f98a29f[2]).

 1. https://bugs.freedesktop.org/show_bug.cgi?id=108984
 2. https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next&id=5179749925933575a67f9d8f16d0cc204f98a29f

I'm attaching a patch against the sid branch of the debian packaging,
implementing this revert; and packages built from this updated sid
branch can be found in this repository (also available over https://):

  deb http://apt.debamax.com/bug-914980/ sid main

This repository is signed with my work key (itself signed by my Debian
key), to make it clear it's an independent effort at trying to get this
bug worked around for the time being, rather than something official
from the debian-kernel team. In any case, this repository will only be
kept online while this issue isn't fixed in unstable.

Test reports welcome!


For context, Tails usually tracks the Linux kernel from sid to get
regular bugfixes; we seem to have missed this regression on gen4/gen5,
so I've started checking whether the upstream fix was being queued for
linux-4.18.y, and moved to trying to get a work around once I've noticed
that wasn't the case yet. We might end up temporarily downgrading the
kernel in Tails instead, though.

  https://redmine.tails.boum.org/code/issues/16224


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

[toc] | [prev] | [next] | [standalone]

#62745

On 2018-12-15 22:21:52 [+0100], Cyril Brulebois wrote:
> regular bugfixes; we seem to have missed this regression on gen4/gen5,
> so I've started checking whether the upstream fix was being queued for
> linux-4.18.y, and moved to trying to get a work around once I've noticed

that bug is a bummer. I reverted that one patch myself for my needs. v4.18
isn't maintained anymore so I'm unsure if this gets fixed in the stable tree.
Debian wise I *think* they will move to v4.19 soon.

> Cheers,

Sebastian

[toc] | [prev] | [next] | [standalone]

#62746

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2018-12-15 at 23:59 +0100, Sebastian Andrzej Siewior wrote:
> On 2018-12-15 22:21:52 [+0100], Cyril Brulebois wrote:
> > regular bugfixes; we seem to have missed this regression on gen4/gen5,
> > so I've started checking whether the upstream fix was being queued for
> > linux-4.18.y, and moved to trying to get a work around once I've noticed
> 
> that bug is a bummer. I reverted that one patch myself for my needs. v4.18
> isn't maintained anymore so I'm unsure if this gets fixed in the stable tree.
> Debian wise I *think* they will move to v4.19 soon.

That's correct - the next upload to unstable will be based on 4.19.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web