linux-kernel - Re: Blank console but X11 works on MCP79

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:   Sat, 18 Nov 2017 00:23:33 -0500
From:   Ilia Mirkin <imirkin@...m.mit.edu>
To:     Ondrej Zary <linux@...nbow-software.org>
Cc:     Ben Skeggs <bskeggs@...hat.com>,
        "nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin@...m.mit.edu> wrote:
> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux@...nbow-software.org> wrote:
>> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
>>> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>>>
>>> <linux@...nbow-software.org> wrote:
>>> > @@ -483,8 +483,8 @@
>>> >  nouveau 0000:02:00.0: disp:    0860: 00000000 -> 00000500
>>> >  nouveau 0000:02:00.0: disp:    0864: 00000000
>>> >  nouveau 0000:02:00.0: disp:    0868: 00000000 -> 04000500
>>> > -nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100500
>>> > -nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 00001e00
>>> > +nouveau 0000:02:00.0: disp:    086c: 00000000 -> 00100a00
>>> > +nouveau 0000:02:00.0: disp:    0870: 0000e900 -> 0000e800
>>> >  nouveau 0000:02:00.0: disp:    0874: 00000000 -> ffff0000
>>> >  nouveau 0000:02:00.0: disp:    0878: 00000000
>>> >  nouveau 0000:02:00.0: disp:    0880: 05000000
>>> >
>>> > Looks like it's using 8bpp (0x1e00) in 32MB case but 16bpp (0xe800) in
>>> > 64MB case. Why?
>>> >
>>> > I get blank screen even with 64MB with video=1280x1024-8 kernel
>>> > parameter. Console works with video=1280x1024-16 even with 32MB stolen
>>> > memory.
>>> >
>>> > Conclusions: 8-bit support is broken and bpp reduction is weird.
>>>
>>> OK, well that makes a *ton* of sense (8bpp being broken).
>>>
>>> I think the idea of bpp reduction is that when you're on your shiny
>>> new Riva TNT with 16MB of VRAM, you don't want to go crazy allocating
>>> all that to a pinned fbcon - almost half of that would go to a single
>>> 32bpp 1600x1200 buffer, more for 1920x1200. You want to be able to
>>> have at least a few fb-sized buffers for backbuffer rendering, etc.
>>>
>>> The specific limits could probably use tweaking - I think they only
>>> consider VRAM size, not the fb size.
>>>
>>> I guess 8bpp worked prior to the change you bisected though, so we
>>> should figure out what we did wrong in the new code.
>>
>> Yes, booted 3.7 (last working kernel) and it's running in 8bpp.
>
> By the way, instead of booting $kernel, you can use modetest from
> libdrm/tests. Not sure if it supports C8 though =/

It didn't. But it does now - I mailed a patch to dri-devel, also (with
slight fix) available at

https://people.freedesktop.org/~imirkin/patches/0001-modetest-add-C8-support-to-generate-SMPTE-pattern.patch

This works on GK208 but not on G92 (whose display unit is much closer
to your MCP79's). You can run as

./modetest -s DVI-I-1:1920x1200@C8

This should display a SMPTE pattern, and exit when you hit enter. When
it does so, it doesn't restore fbcon, but you can swtich to another
vty to get console back.

I get a white picture on G92. Now just have to figure out how to fix
it. Someone should also test on a G80 if possible, since that takes a
different path as well.

  -ilia