linux-kernel - Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume

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: <d41841c1e5f524f976edea8cdd075238.squirrel@webmail.greenhost.nl>
Date:	Wed, 9 Feb 2011 03:56:36 +0100 (CET)
From:	"Indan Zupancic" <indan@....nu>
To:	"Jeff Chua" <jeff.chua.linux@...il.com>
Cc:	"Chris Wilson" <chris@...is-wilson.co.uk>,
	"Takashi Iwai" <tiwai@...e.de>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, "Len Brown" <lenb@...nel.org>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: Re: Commit 500f7147cf5bafd139056d521536b10c2bc2e154 breaks _resume_

On Wed, February 9, 2011 02:05, Jeff Chua wrote:
> On Wed, Feb 9, 2011 at 8:55 AM, Jeff Chua <jeff.chua.linux@...il.com> wrote:
>
>> And the console hangs even without starting X.
>
> I went back to retry suspending without starting X and realized that
> it's only the "screen" that's hang .. and that's without drm and i915
> loaded.

According to the dmesg you sent, you do have drm (and probably i915 too) loaded.
It seems the hang is the first bit, and then you rebooted into X to capture the
log.

Perhaps relevant message (probably not):

"No ACPI video bus found"

> On the console, I could still reboot the machine normally, but
> not when in X (everything hangs including keybard).
>
> Here's the kernel log without X.
>
> Thanks.
> Jeff
>

Looking at the commit, all it does is changing the timing.

It used to set active to true when intel_crtc_init() was called, but now
it does it always when the drm reset() callback is called.

intel_crtc->active = true; /* force the pipe off on setup_init_config */

I can't find a setup_init_config anywhere, but looking at the other code
it assumes that *_crtc_disable() will be called just after the forced true.

All in all it seems quite wrong, no matter if it happens to work, because
it depends on the calling order done by the drm layer. If *_crtc_enable()
is called instead it won't do anything because of that active = true thing.
This seems to be happening in your case.

So I'd get rid of that dodgy active = true assignment altogether. Isn't
the introduction of the reset() callback done to avoid exactly this kind
of subtle state fiddling? And removing it might solve the original problem
that the move tried to fix as well.

I can't check the rest of the code as I'm still on patched 37 (won't move
till the fix for bug 23472 is upstream), but my gut feeling is that removing
that weird active = true will solve most problems.

Greetings,

Indan

--
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/