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]
Date:	Mon, 16 Apr 2007 02:29:21 -0400
From:	Dave Jones <davej@...hat.com>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Richard Purdie <rpurdie@...ys.net>
Subject: Re: [2/2] 2.6.21-rc7: known regressions

On Mon, Apr 16, 2007 at 03:16:37AM +0200, Adrian Bunk wrote:
 > On Sun, Apr 15, 2007 at 08:54:46PM -0400, Dave Jones wrote:
 > > On Mon, Apr 16, 2007 at 02:37:23AM +0200, Adrian Bunk wrote:
 > > 
 > >  > Subject    : ThinkPad X60: resume no longer works  (PCI related?)
 > >  >              workaround: booting with "hpet=disable"
 > >  > References : http://lkml.org/lkml/2007/3/13/3
 > >  > Submitter  : Dave Jones <davej@...hat.com>
 > >  >              Jeremy Fitzhardinge <jeremy@...p.org>
 > >  > Caused-By  : PCI merge
 > >  >              commit 78149df6d565c36675463352d0bfe0000b02b7a7
 > >  > Handled-By : Eric W. Biederman <ebiederm@...ssion.com>
 > >  >              Rafael J. Wysocki <rjw@...k.pl>
 > >  > Status     : unknown
 > > 
 > > note that this workaround doesn't seem to work in all cases.
 > > Mine may a slightly different model (I have the tablet version)
 > > but disabling hpet shows the same regression.
 > > I've been fighting Eric's USB debug cable code in the hope
 > > of getting _something_ useful out of it other than a black screen,
 > > but I've been getting nowhere with it.
 > 
 > I'm not sure why I thought you two ran into the same regression.

I'm not sure why I never hit the same bug that Jeremy did
(again, maybe subtle hardware differences between our models),
but I finally got somewhere.   -rc7 with the same config I've
been testing exhibited exactly the same bug.   Disabling
the FB_BACKLIGHT option (and all the FB drivers that 'select' it),
I get a working display on resume again.

This makes a lot of sense. As before, when I resumed, the backlight
wasn't coming back on, but I knew the machine was alive, as
capslock was working.  (Amusingly, I never noticed the backlight
wasn't coming back on until tonight, when I started debugging this
with the lights off.  Late-night debugging ftw).

I'll try and narrow down exactly where it's failing in the
backlight code next, but it's getting late here, so I may
leave this until tomorrow for further investigation.
Some other clues for anyone playing along at home:
This X60 has Intel graphics.  ie, I'm not using any of
the drivers that 'select FB_BACKLIGHT', so somewhere in
the common fb code is code that I'm guessing is dependant
upon the framebuffer driver doing something or other
if FB_BACKLIGHT is set.

(Adding Richard to Cc: as he seems to be responsible for
 the FB backlight code from what I can tell.)

	Dave

-- 
http://www.codemonkey.org.uk
-
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