Blank console but X11 works on MCP79 - old regression since 3.8

Blank console but X11 works on MCP79 - old regression since 3.8

[Ondrej Zary]

Hello,
I've just been hit by this old bug which is still present in 4.14:
https://bugs.freedesktop.org/show_bug.cgi?id=80675

On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is blank 
but X11 works. When the stolen memory is increased to 64MB, console works 
fine.

Bisected it to this:

4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit
commit 4f6029da58ba9204c98e33f4f3737fe085c87a6f
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Fri Nov 16 11:54:31 2012 +1000

    drm/nv50-nvc0: switch to common disp impl, removing previous version

    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

It's a big change so I'm not able to do more debugging.

-- 
Ondrej Zary

Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ilia Mirkin]

With a new kernel, mind grabbing a dmesg with drm.debug=0x1e
nouveau.debug=debug (or maybe even =trace)? Maybe also see if
fbcon/fbdev have any debug things that can be turned on?

Sounds like things are generally working, just the fbcon -> nouveaufb
path seems somehow buggered.

Another thing to try would be nouveau.atomic=1

On Fri, Nov 17, 2017 at 9:26 AM, Ondrej Zary <linux@rainbow-software.org> wrote:
> Hello,
> I've just been hit by this old bug which is still present in 4.14:
> https://bugs.freedesktop.org/show_bug.cgi?id=80675
>
> On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is blank
> but X11 works. When the stolen memory is increased to 64MB, console works
> fine.
>
> Bisected it to this:
>
> 4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit
> commit 4f6029da58ba9204c98e33f4f3737fe085c87a6f
> Author: Ben Skeggs <bskeggs@redhat.com>
> Date:   Fri Nov 16 11:54:31 2012 +1000
>
>     drm/nv50-nvc0: switch to common disp impl, removing previous version
>
>     Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
>
> It's a big change so I'm not able to do more debugging.
>
> --
> Ondrej Zary

Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ondrej Zary]

On Friday 17 November 2017 15:43:33 Ilia Mirkin wrote:
> With a new kernel, mind grabbing a dmesg with drm.debug=0x1e
> nouveau.debug=debug (or maybe even =trace)? Maybe also see if
> fbcon/fbdev have any debug things that can be turned on?

Here's diff of the 32MB and 64MB debug logs:

--- nouveau-debug-32mb.txt-	2017-11-17 18:12:06.290108330 +0100
+++ nouveau-debug-64mb.txt-	2017-11-17 18:12:31.709696096 +0100
@@ -81,9 +81,9 @@
 nouveau 0000:02:00.0: tmr: numerator       : 0000000c
 nouveau 0000:02:00.0: tmr: denominator     : 00000005
 nouveau 0000:02:00.0: tmr: timer frequency : 31250Hz
-nouveau 0000:02:00.0: tmr: time low        : 6335d09e
+nouveau 0000:02:00.0: tmr: time low        : 7bb102a6
 nouveau 0000:02:00.0: tmr: time high       : 00000003
-nouveau 0000:02:00.0: fb: 32 MiB stolen system memory
+nouveau 0000:02:00.0: fb: 64 MiB stolen system memory
 nouveau 0000:02:00.0: fb: 0 compression tags
 nouveau 0000:02:00.0: volt: current voltage unknown
 nouveau 0000:02:00.0: i2c: bus 0002: probing monitoring devices
@@ -103,11 +103,11 @@
 nouveau 0000:02:00.0: clk: 1b:     450000 KHz
 nouveau 0000:02:00.0: clk: --: core 450 MHz shader 1100 MHz vdec 450 MHz
 nouveau: DRM:00000000:00000080: init children...
-nouveau: DRM:00000000:00000080: init completed in 71380us
-[TTM] Zone  kernel: Available graphics memory: 444902 kiB
-[TTM] Zone highmem: Available graphics memory: 497930 kiB
+nouveau: DRM:00000000:00000080: init completed in 71260us
+[TTM] Zone  kernel: Available graphics memory: 445198 kiB
+[TTM] Zone highmem: Available graphics memory: 481842 kiB
 [TTM] Initializing pool allocator
-nouveau 0000:02:00.0: DRM: VRAM: 32 MiB
+nouveau 0000:02:00.0: DRM: VRAM: 64 MiB
 nouveau 0000:02:00.0: DRM: GART: 1048576 MiB
 nouveau 0000:02:00.0: DRM: TMDS table version 2.0
 nouveau 0000:02:00.0: DRM: DCB version 4.0
@@ -126,22 +126,22 @@
 nouveau: DRM:00000000:0000887d: init completed in 96us
 nouveau: DRM:00000000:00000002: fini children...
 nouveau: DRM:00000000:00000002: fini running...
-nouveau: DRM:00000000:00000002: fini completed in 66us
+nouveau: DRM:00000000:00000002: fini completed in 64us
 nouveau: DRM:00000000:00000002: destroy children...
 nouveau: DRM:00000000:00000002: destroy running...
-nouveau: DRM:00000000:00000002: destroy completed in 69us...
+nouveau: DRM:00000000:00000002: destroy completed in 68us...
 nouveau: DRM:f0000000:0000003d: init running...
 nouveau: DRM:f0000000:0000003d: init children...
-nouveau: DRM:f0000000:0000003d: init completed in 64us
+nouveau: DRM:f0000000:0000003d: init completed in 66us
 nouveau: DRM:f0000001:0000003d: init running...
 nouveau: DRM:f0000001:0000003d: init children...
-nouveau: DRM:f0000001:0000003d: init completed in 68us
+nouveau: DRM:f0000001:0000003d: init completed in 66us
 nouveau: DRM:00000000:0000827a: init running...
 nouveau: DRM:00000000:0000827a: init children...
-nouveau: DRM:00000000:0000827a: init completed in 67us
+nouveau: DRM:00000000:0000827a: init completed in 73us
 nouveau: DRM:00000000:00000002: init running...
 nouveau: DRM:00000000:00000002: init children...
-nouveau: DRM:00000000:00000002: init completed in 66us
+nouveau: DRM:00000000:00000002: init completed in 68us
 nouveau: DRM:00000000:0000837c: init running...
 nouveau: DRM:00000000:0000837c: init children...
 nouveau: DRM:00000000:0000837c: init completed in 71us
@@ -150,16 +150,16 @@
 nouveau: DRM:00000000:00000002: fini completed in 66us
 nouveau: DRM:00000000:00000002: destroy children...
 nouveau: DRM:00000000:00000002: destroy running...
-nouveau: DRM:00000000:00000002: destroy completed in 66us...
+nouveau: DRM:00000000:00000002: destroy completed in 85us...
 nouveau: DRM:f0000000:0000003d: init running...
 nouveau: DRM:f0000000:0000003d: init children...
-nouveau: DRM:f0000000:0000003d: init completed in 66us
+nouveau: DRM:f0000000:0000003d: init completed in 65us
 nouveau: DRM:f0000001:0000003d: init running...
 nouveau: DRM:f0000001:0000003d: init children...
 nouveau: DRM:f0000001:0000003d: init completed in 66us
 nouveau: DRM:00000000:0000827b: init running...
 nouveau: DRM:00000000:0000827b: init children...
-nouveau: DRM:00000000:0000827b: init completed in 69us
+nouveau: DRM:00000000:0000827b: init completed in 71us
 nouveau: DRM:00000000:00000002: init running...
 nouveau: DRM:00000000:00000002: init children...
 nouveau: DRM:00000000:00000002: init completed in 66us
@@ -174,43 +174,43 @@
 nouveau: DRM:00000000:00000002: destroy completed in 66us...
 nouveau: DRM:f0000000:0000003d: init running...
 nouveau: DRM:f0000000:0000003d: init children...
-nouveau: DRM:f0000000:0000003d: init completed in 64us
+nouveau: DRM:f0000000:0000003d: init completed in 66us
 nouveau: DRM:f0000001:0000003d: init running...
 nouveau: DRM:f0000001:0000003d: init children...
 nouveau: DRM:f0000001:0000003d: init completed in 66us
 nouveau: DRM:00000000:0000827a: init running...
 nouveau: DRM:00000000:0000827a: init children...
-nouveau: DRM:00000000:0000827a: init completed in 71us
+nouveau: DRM:00000000:0000827a: init completed in 72us
 nouveau: DRM:00000000:00000002: init running...
 nouveau: DRM:00000000:00000002: init children...
-nouveau: DRM:00000000:00000002: init completed in 65us
+nouveau: DRM:00000000:00000002: init completed in 66us
 nouveau: DRM:00000000:0000837c: init running...
 nouveau: DRM:00000000:0000837c: init children...
-nouveau: DRM:00000000:0000837c: init completed in 71us
+nouveau: DRM:00000000:0000837c: init completed in 72us
 nouveau: DRM:00000000:00000002: fini children...
 nouveau: DRM:00000000:00000002: fini running...
-nouveau: DRM:00000000:00000002: fini completed in 81us
+nouveau: DRM:00000000:00000002: fini completed in 66us
 nouveau: DRM:00000000:00000002: destroy children...
 nouveau: DRM:00000000:00000002: destroy running...
-nouveau: DRM:00000000:00000002: destroy completed in 67us...
+nouveau: DRM:00000000:00000002: destroy completed in 66us...
 nouveau: DRM:f0000000:0000003d: init running...
 nouveau: DRM:f0000000:0000003d: init children...
-nouveau: DRM:f0000000:0000003d: init completed in 63us
+nouveau: DRM:f0000000:0000003d: init completed in 66us
 nouveau: DRM:f0000001:0000003d: init running...
 nouveau: DRM:f0000001:0000003d: init children...
-nouveau: DRM:f0000001:0000003d: init completed in 66us
+nouveau: DRM:f0000001:0000003d: init completed in 75us
 nouveau: DRM:00000000:0000827b: init running...
 nouveau: DRM:00000000:0000827b: init children...
-nouveau: DRM:00000000:0000827b: init completed in 159us
+nouveau: DRM:00000000:0000827b: init completed in 72us
 nouveau: DRM:00000000:00000002: init running...
 nouveau: DRM:00000000:00000002: init children...
-nouveau: DRM:00000000:00000002: init completed in 65us
+nouveau: DRM:00000000:00000002: init completed in 66us
 nouveau: DRM:00000000:0000837e: init running...
 nouveau: DRM:00000000:0000837e: init children...
-nouveau: DRM:00000000:0000837e: init completed in 70us
+nouveau: DRM:00000000:0000837e: init completed in 71us
 nouveau: DRM:00000000:00000002: fini children...
 nouveau: DRM:00000000:00000002: fini running...
-nouveau: DRM:00000000:00000002: fini completed in 66us
+nouveau: DRM:00000000:00000002: fini completed in 65us
 nouveau: DRM:00000000:00000002: destroy children...
 nouveau: DRM:00000000:00000002: destroy running...
 nouveau: DRM:00000000:00000002: destroy completed in 66us...
@@ -224,34 +224,34 @@
 [drm] Driver supports precise vblank timestamp query.
 nouveau: DRM:00000000:ffffffff: init running...
 nouveau: DRM:00000000:ffffffff: init children...
-nouveau: DRM:00000000:ffffffff: init completed in 77us
+nouveau: DRM:00000000:ffffffff: init completed in 76us
 nouveau: DRM:00000000:00000002: init running...
 nouveau: DRM:00000000:00000002: init children...
-nouveau: DRM:00000000:00000002: init completed in 67us
+nouveau: DRM:00000000:00000002: init completed in 66us
 nouveau: DRM:00000000:0000826f: init running...
 nouveau: DRM:00000000:0000826f: init children...
-nouveau: DRM:00000000:0000826f: init completed in 171us
+nouveau: DRM:00000000:0000826f: init completed in 173us
 nouveau: DRM:80000002:0000003d: init running...
 nouveau: DRM:80000002:0000003d: init children...
-nouveau: DRM:80000002:0000003d: init completed in 66us
+nouveau: DRM:80000002:0000003d: init completed in 67us
 nouveau: DRM:80000003:0000003d: init running...
 nouveau: DRM:80000003:0000003d: init children...
-nouveau: DRM:80000003:0000003d: init completed in 68us
+nouveau: DRM:80000003:0000003d: init completed in 64us
 nouveau: DRM:55550000:fffffffa: init running...
 nouveau: DRM:00000000:00000000: init running...
 nouveau: DRM:00000000:00000000: init children...
-nouveau: DRM:00000000:00000000: init completed in 66us
+nouveau: DRM:00000000:00000000: init completed in 65us
 nouveau: DRM:55550000:fffffffa: init children...
-nouveau: DRM:55550000:fffffffa: init completed in 262us
+nouveau: DRM:55550000:fffffffa: init completed in 263us
 nouveau: DRM:80000006:0000003d: init running...
 nouveau: DRM:80000006:0000003d: init children...
-nouveau: DRM:80000006:0000003d: init completed in 65us
+nouveau: DRM:80000006:0000003d: init completed in 66us
 nouveau: DRM:00005039:00005039: init running...
 nouveau: DRM:00000000:00000000: init running...
 nouveau: DRM:00000000:00000000: init children...
 nouveau: DRM:00000000:00000000: init completed in 66us
 nouveau: DRM:00005039:00005039: init children...
-nouveau: DRM:00005039:00005039: init completed in 268us
+nouveau: DRM:00005039:00005039: init completed in 274us
 nouveau 0000:02:00.0: DRM: MM: using M2MF for buffer copies
 nouveau 0000:02:00.0: disp: supervisor 00000010 000002a0
 nouveau 0000:02:00.0: disp: Core:
@@ -405,7 +405,7 @@
 [drm:drm_setup_crtcs [drm_kms_helper]] desired mode 1280x1024 set on crtc 34 (0,0)
 nouveau: DRM:ffff0000:0000003d: init running...
 nouveau: DRM:ffff0000:0000003d: init children...
-nouveau: DRM:ffff0000:0000003d: init completed in 71us
+nouveau: DRM:ffff0000:0000003d: init completed in 68us
 nouveau: DRM:ffff0000:0000003d: init running...
 nouveau: DRM:ffff0000:0000003d: init children...
 nouveau: DRM:ffff0000:0000003d: init completed in 67us
@@ -415,7 +415,7 @@
 nouveau: DRM:0000502d:0000502d: init running...
 nouveau: DRM:0000502d:0000502d: init children...
 nouveau: DRM:0000502d:0000502d: init completed in 67us
-nouveau 0000:02:00.0: DRM: allocated 1280x1024 fb: 0x50000, bo f667ac00
+nouveau 0000:02:00.0: DRM: allocated 1280x1024 fb: 0x50000, bo f6afa000
 fbcon: nouveaufb (fb0) is primary device
 [drm:drm_crtc_helper_set_config [drm_kms_helper]] 
 [drm:drm_crtc_helper_set_config [drm_kms_helper]] [CRTC:34:crtc-0] [FB:61] #connectors=1 (x y) (0 0)
@@ -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.

> Sounds like things are generally working, just the fbcon -> nouveaufb
> path seems somehow buggered.
>
> Another thing to try would be nouveau.atomic=1
>
> On Fri, Nov 17, 2017 at 9:26 AM, Ondrej Zary <linux@rainbow-software.org> wrote:
> > Hello,
> > I've just been hit by this old bug which is still present in 4.14:
> > https://bugs.freedesktop.org/show_bug.cgi?id=80675
> >
> > On MCP79 (ION), when stolen memory is set to 32MB in BIOS, console is
> > blank but X11 works. When the stolen memory is increased to 64MB, console
> > works fine.
> >
> > Bisected it to this:
> >
> > 4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit
> > commit 4f6029da58ba9204c98e33f4f3737fe085c87a6f
> > Author: Ben Skeggs <bskeggs@redhat.com>
> > Date:   Fri Nov 16 11:54:31 2012 +1000
> >
> >     drm/nv50-nvc0: switch to common disp impl, removing previous version
> >
> >     Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
> >
> > It's a big change so I'm not able to do more debugging.
> >
> > --
> > Ondrej Zary


-- 
Ondrej Zary

Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ilia Mirkin]

On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
<linux@rainbow-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.

  -ilia

Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ondrej Zary]

On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote:
> On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary
>
> <linux@rainbow-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

Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ilia Mirkin]

On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux@rainbow-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@rainbow-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 =/

I think the issue is this:

-               OUT_RING(evo, nv_crtc->lut.depth == 8 ?
-                               NV50_EVO_CRTC_CLUT_MODE_OFF :
-                               NV50_EVO_CRTC_CLUT_MODE_ON);

Whereas now we always set 0xC0000000 (aka "ON").

  -ilia

Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ilia Mirkin]

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux@rainbow-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@rainbow-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 =/
>
> I think the issue is this:
>
> -               OUT_RING(evo, nv_crtc->lut.depth == 8 ?
> -                               NV50_EVO_CRTC_CLUT_MODE_OFF :
> -                               NV50_EVO_CRTC_CLUT_MODE_ON);
>
> Whereas now we always set 0xC0000000 (aka "ON").

In case I was being unclear, I'm talking about

https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nv50_display.c#L1808

and surrounding items. Looks like lut_clr sets 0x40000000 which was
previously not used. Not sure what the difference between that and
0x00000000 is. This is what we have in rnndb for it:

https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml#L408

So bit 30 is mode, set is "high res", unset is "low res". So really
what we want is 0x80000000 which leaves the LUT enabled but uses the
low-res mode?

All this could use some playing-around with.

  -ilia

Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ondrej Zary]

On Friday 17 November 2017 20:52:45 Ilia Mirkin wrote:
> On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> > On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux@rainbow-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@rainbow-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 =/
> >
> > I think the issue is this:
> >
> > -               OUT_RING(evo, nv_crtc->lut.depth == 8 ?
> > -                               NV50_EVO_CRTC_CLUT_MODE_OFF :
> > -                               NV50_EVO_CRTC_CLUT_MODE_ON);
> >
> > Whereas now we always set 0xC0000000 (aka "ON").
>

Changing that to 0x80000000 does not help :(

> In case I was being unclear, I'm talking about
>
> https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nv50_display.c#L
>1808
>
> and surrounding items. Looks like lut_clr sets 0x40000000 which was
> previously not used. Not sure what the difference between that and
> 0x00000000 is. This is what we have in rnndb for it:

lut_clr is not called during boot so we can ignore it for now.

> https://github.com/envytools/envytools/blob/master/rnndb/display/nv_evo.xml
>#L408
>
> So bit 30 is mode, set is "high res", unset is "low res". So really
> what we want is 0x80000000 which leaves the LUT enabled but uses the
> low-res mode?
>
> All this could use some playing-around with.
>
>   -ilia


-- 
Ondrej Zary

Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ilia Mirkin]

On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux@rainbow-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@rainbow-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

Re: Blank console but X11 works on MCP79 - old regression since 3.8

[Ilia Mirkin]

On Sat, Nov 18, 2017 at 12:23 AM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
> On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary <linux@rainbow-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@rainbow-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.

Someone tested out a GF100 and it had the same issue.

I've since determined that the color is that of the first entry in the
LUT. With the above program, it's (192, 192, 192) which looks white.

  -ilia