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] [day] [month] [year] [list]
Message-ID: <20121116192159.GA491@polaris.bitmath.org>
Date:	Fri, 16 Nov 2012 20:21:59 +0100
From:	"Henrik Rydberg" <rydberg@...omail.se>
To:	Ben Skeggs <bskeggs@...hat.com>
Cc:	Dave Airlie <airlied@...il.com>, nouveau@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] nouveau: Severe screen corruption on (0xaf, nv50)

On Sun, Oct 21, 2012 at 09:10:24AM +0200, Henrik Rydberg wrote:
> On Thu, Oct 18, 2012 at 11:58:09AM +0200, Henrik Rydberg wrote:
> > Hi Ben,
> > 
> > 3.7-rc1 messed up the screen on my MacBookAir3,1 (nv50, 0xaf) pretty
> > badly. Not surprisingly,
> > 
> > commit 3863c9bc887e9638a9d905d55f6038641ece78d6
> > Author: Ben Skeggs <bskeggs@...hat.com>
> > Date:   Sat Jul 14 19:09:17 2012 +1000
> > 
> >     drm/nouveau/instmem: completely new implementation, as a subdev module
> > 
> > is the first bad commit. Standing on that commit, booting and then
> > starting X yields the output below. Hints are especially appreciated,
> > considering the patch is almost 8000 lines.
> 
> Going through one suspend/resume cycle makes the corruption go away,
> and there are no more errors in dmesg. Oddly enough, I have seen
> something very similar when using i915 on the MBP10. Builtin modules
> and systemd in both cases. Maybe this is a general drm issue. Any
> thoughts?

This is still a problem in Linus' tree. The screen corruption happens
during boot, in text mode, presumably in conjunction with alloction of
the nouveaufb device. It is 100% reproducible, and there is no
advanced graphics involved, just simple text console. Booting from efi
or bios does not matter. Modules are builtin.

Suspending and resuming once makes the problem go away every time.

Since this is a simple usecase, and the failing commit has been
bisected, it ought to be possible to find the problem. Unfortunately,
I am not familiar enough with the nouveau code to find the problem in
an 8000-line patch. Please help. :-)

Thanks,
Henrik
--
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