linux-kernel - Re: [KERNEL] Re: [KERNEL] Regression bug in drm/i915, Wrong assumption in commit e11aa36 breaks suspend on at least lenovo x61

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1424291272.5303.23.camel@ideak-mobl>
Date:	Wed, 18 Feb 2015 22:27:52 +0200
From:	Imre Deak <imre.deak@...el.com>
To:	Klaus Ethgen <Klaus+lkml@...gen.de>
Cc:	Jani Nikula <jani.nikula@...ux.intel.com>,
	linux-kernel@...r.kernel.org,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>
Subject: Re: [KERNEL] Re: [KERNEL] Regression bug in drm/i915, Wrong
 assumption in commit e11aa36  breaks suspend on at least lenovo x61

On Wed, 2015-02-18 at 20:03 +0100, Klaus Ethgen wrote:
> Hi,
> 
> Am Mi den 18. Feb 2015 um 16:39 schrieb Jani Nikula:
> > On Tue, 17 Feb 2015, Klaus Ethgen <Klaus+lkml@...gen.de> wrote:
> > > After solving  the conflicts, I applied the revert (see attachment) to
> > > v3.18.7. I think it should also apply to the current head. With that
> > > patch, suspend is working again on that version.
> > >
> > > However, I have not to deep knowledge of that subsystem, so please,
> > > someone who have, have a deeper look into it. I especially do not know
> > > if the lines in .../intel_pm.c are correct or better leaving them as
> > > they are in v3.18.7.
> > >
> > > I want to have it working on a version that I know is stable before
> > > asking to pull it to head.
> > 
> > Hi Klaus, we fear this patch may hide the actual cause.
> 
> That might be. But that might be a second step, to find the actual
> cause. I think first the patch that causes the problem should be
> fixed/reverted to have a working kernel and the next step would be to
> find the real cause.
> 
> I would happily help to solve both.
> 
> > Would be useful to get a better description of what happens,
> 
> Ask.. English is not my mother thong and I am not that good in finding
> descriptions. ;-)
> 
> > along with a dmesg with drm.debug=14 module parameter set.
> 
> Oh, I would be happy to be able to provide that. But if you look at the
> first mail in this thread, I asked days before how to debug that cause.
> The problem is that it stops in the middle of the suspend right after
> switching of screen. There is no way to get it back working after that
> and so no dmesg. I have to hard switch off the laptop after that.
> 
> > This might clutter the mailing list, would you mind filing a bug at
> > [1] and attach the info there?
> 
> One another account to just fill one bug? Or is there a way to fill the
> bug without creating an account? I would really like to not create
> another account. I still have that many from systems that forced me to
> create an account for just one bug report.

Yes, you need an account to file a freedesktop bug. This would be really
great to keep records, but if this isn't possible for you, then please
email the logs to us. In the latter case I would also suggest not CC'ing
the mailing lists to reduce the clutter.

> Am Mi den 18. Feb 2015 um 17:24 schrieb Imre Deak:
> > In addition to the above could you also try the following patch and
> > provide a dmesg log on the bugzilla ticket - at this point only to try
> > to narrow down the issue?:
> > 
> [PATCH]
> 
> Yes, I can do that. But can you tell me how to get dmesg output when the
> problem happened? After that the box is unusable and I have to hard
> switch off it. There is no way to get any dmesg output after the bug
> happened.

Thanks. I'm hoping that the patch also gets rid of the problem, so you
could get the dmesg log easily. If the patch doesn't get rid of the hang
it'd be great if you could still try setting up netconsole and get the
log from another machine. To get a trace closer to the hang you could
also try
# echo N > /sys/module/printk/parameters/console_suspend
before suspending.

Thanks,
Imre

> Ps. I can forward the first two messages that I posted on kernel ML.
>     That should also be available online.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/