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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Nov 2017 20:25:14 +0100
From:   Ondrej Zary <linux@...nbow-software.org>
To:     Ilia Mirkin <imirkin@...m.mit.edu>
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 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.

I guess that nv50_head_gamma_set() is missing something like this (from 
nv_crtc_gamma_set()):
        /* We need to know the depth before we upload, but it's possible to
         * get called before a framebuffer is bound.  If this is the case,
         * mark the lut values as dirty by setting depth==0, and it'll be
         * uploaded on the first mode_set_base()
         */
        if (!nv_crtc->base.primary->fb) {
                nv_crtc->lut.depth = 0;
                return 0;
        }

That's easy to add but there's no mode_set_base() for nv50 so there's no place 
to add code like this:
        if (nv_crtc->lut.depth != drm_fb->format->depth) {
                nv_crtc->lut.depth = drm_fb->format->depth;
                nv_crtc_gamma_load(crtc);
        }

-- 
Ondrej Zary