On Thu, 30 Mar 2017 22:01:31 +0200,
Lyude Paul wrote:
>
> On Thu, 2017-03-30 at 20:50 +0200, Takashi Iwai wrote:
>
> >
> > Sure, if we get a proper stack dump, we can analyze it somehow. You
> > can use addr2line, or even check objdump output manually.
> > But in this case, as already mentioned
On Thu, 2017-03-30 at 20:50 +0200, Takashi Iwai wrote:
>
> Sure, if we get a proper stack dump, we can analyze it somehow. You
> can use addr2line, or even check objdump output manually.
> But in this case, as already mentioned, it was impossible to get any
> sensible stack trace on my machine w
On Thu, 30 Mar 2017 20:07:42 +0200,
Lyude Paul wrote:
>
> On Thu, 2017-03-30 at 07:55 +0200, Takashi Iwai wrote:
> > On Thu, 30 Mar 2017 02:24:37 +0200,
> > Lyude Paul wrote:
> > >
> > > On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote:
> > > > On Wed, 29 Mar 2017 15:34:15 +0200,
> > > > Vil
On Thu, 2017-03-30 at 07:55 +0200, Takashi Iwai wrote:
> On Thu, 30 Mar 2017 02:24:37 +0200,
> Lyude Paul wrote:
> >
> > On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote:
> > > On Wed, 29 Mar 2017 15:34:15 +0200,
> > > Ville Syrjälä wrote:
> > > >
> > > > On Wed, Mar 29, 2017 at 03:10:09PM +
On Thu, 30 Mar 2017 02:24:37 +0200,
Lyude Paul wrote:
>
> On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote:
> > On Wed, 29 Mar 2017 15:34:15 +0200,
> > Ville Syrjälä wrote:
> > >
> > > On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> > > > On Mon, 27 Mar 2017 18:02:13 +0200,
>
On Wed, 2017-03-29 at 15:54 +0200, Takashi Iwai wrote:
> On Wed, 29 Mar 2017 15:34:15 +0200,
> Ville Syrjälä wrote:
> >
> > On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> > > On Mon, 27 Mar 2017 18:02:13 +0200,
> > > Takashi Iwai wrote:
> > > >
> > > > Hi,
> > > >
> > > > the up
On Wed, 29 Mar 2017 15:34:15 +0200,
Ville Syrjälä wrote:
>
> On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> > On Mon, 27 Mar 2017 18:02:13 +0200,
> > Takashi Iwai wrote:
> > >
> > > Hi,
> > >
> > > the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> > > drm/i915: Cal
On Wed, Mar 29, 2017 at 03:10:09PM +0200, Takashi Iwai wrote:
> On Mon, 27 Mar 2017 18:02:13 +0200,
> Takashi Iwai wrote:
> >
> > Hi,
> >
> > the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> > drm/i915: Call intel_dp_mst_resume() before resuming displays
> >
> > seems to trigger a
On Mon, 27 Mar 2017 18:02:13 +0200,
Takashi Iwai wrote:
>
> Hi,
>
> the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> drm/i915: Call intel_dp_mst_resume() before resuming displays
>
> seems to trigger a kernel panic when some modeset change happens after
> S3 resume. The details a
Hi! Just an FYI I am planning on taking a look at this very soon
On Mon, 2017-03-27 at 18:02 +0200, Takashi Iwai wrote:
> Hi,
>
> the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
> drm/i915: Call intel_dp_mst_resume() before resuming displays
>
> seems to trigger a kernel panic when
Hi,
the upstream fix a16b7658f4e0d4aec9bc3e75a5f0cc3f7a3a0422
drm/i915: Call intel_dp_mst_resume() before resuming displays
seems to trigger a kernel panic when some modeset change happens after
S3 resume. The details are found in openSUSE bugzilla,
https://bugzilla.suse.com/show_bug.cgi?i
11 matches
Mail list logo