lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  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]
Date:	Mon, 07 Feb 2011 11:15:01 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Jeff Chua <jeff.chua.linux@...il.com>
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	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_

At Mon, 07 Feb 2011 09:52:55 +0100,
Takashi Iwai wrote:
> 
> At Mon, 7 Feb 2011 16:36:33 +0800,
> Jeff Chua wrote:
> > 
> > On Mon, Feb 7, 2011 at 4:25 PM, Takashi Iwai <tiwai@...e.de> wrote:
> > > At Mon, 7 Feb 2011 13:02:46 +0800,
> > > Jeff Chua wrote:
> > >>
> > >> On Mon, Feb 7, 2011 at 12:48 PM, Jeff Chua <jeff.chua.linux@...il.com> wrote:
> > >> > On Sun, Feb 6, 2011 at 11:27 PM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
> > >> >> One last step: move contents of intel_crtc_reset() back to
> > >> >> intel_crtc_init() one by one.
> > >> >>
> > >> >> The active flag is my suspicion. I was thinking that we brought up the
> > >> >> outputs in a similar manner upon resume as upon initial boot. On
> > >> >> reflection, this is the not case.
> > >> >>
> > >> >> However, the first action we take inside modesetting is to disable the
> > >> >> outputs about to be reconfigured. So setting active should be the right
> > >> >> course of action so that cleanup any residual state from resume.
> > >> >>
> > >> >> So I am intrigued as to which line is the cause, and just where the
> > >> >> machine becomes unresponsive...
> > >> >
> > >> > It's this line causing the problem.
> > >> >
> > >> > intel_crtc->active = true; /* force the pipe off on setup_init_config */
> > >> >
> > >> >
> > >> > When it's called before entering intel_crtc_reset(&intel_crtc->base),
> > >> > it works, but if called within the function, it doesn't work. Strange.
> > >> > Not sure whether is passing the correct value to to_intel_crtc(crtc)?
> > >>
> > >> I've added printk() below and the function returns a different value
> > >> of intel_crtc.
> > >>
> > >>
> > >> static void intel_crtc_reset(struct drm_crtc *crtc)
> > >> {
> > >>         struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > >>         printk("intel_crtc %p\n", intel_crtc); ===> intel_crtc ffff8802349d1000
> > >>
> > >> }
> > >>
> > >> printk("intel_crtc %p\n", intel_crtc); ===> intel_crtc ffff8802349d0000
> > >> intel_crtc_reset(&intel_crtc->base);
> > >
> > > That's weird.  Since base is the first member, both intel_crtc and crtc
> > > must be identical.
> > 
> > In case I'm messing something up, here's my intel_display.c
> 
> Thanks, that looks good.  What about other files?  Did you change
> (especially intel_drv.h) from Linus git tree?
> 
> I'll also check later to be sure (now I have no machine for testing).

I don't see any problem with my machine (but running in 32bit).

Are you sure that you are seeing the same CRTC?  There are two active
CRTCs on Intel, and both are initialized and set up.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ