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: <88546787bbe2f26026d6f291fdadef52.squirrel@webmail.greenhost.nl>
Date:	Wed, 9 Feb 2011 10:42:05 +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 06:45, Jeff Chua wrote:
>
> This may help a little. I added printk("intel_crtc 2") inside
> intel_crtc_reset() and added printk("intel_crtc 1") before calling
> intel_crtc_reset().
>
> Looking at  dmesg, it looks like something else is calling
> intel_crtc_reset() and not from intel_crtc_init() during resume.

That something else is the drm layer.

(I must say it's very unclear what the the ordering of driver function
calls will be from just looking at drm the code. I hope the drm
abstraction is working out well for others, to me it all seems a bit
awkward. If state needs to be tracked, fine, but do it either in the
drm layer or let the driver handle it.)

> intel_crtc 2 ffff880239cdf000
> intel_crtc 2 ffff880239cdf800

This doesn't really help, all it probably means is that you've got
multiple crtc outputs, or something like that. It might help if you
get two calls with the offending commit, but only one without it.

I'd add printk's to the *_crtc_disable()/*_crtc_enable() calls with
info whether it actually enables or disables something and compare
the result between a working suspend and a broken one.

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/