* Blank console but X11 works on MCP79 - old regression since 3.8
@ 2017-11-17 14:26 Ondrej Zary
2017-11-17 14:43 ` Ilia Mirkin
0 siblings, 1 reply; 10+ messages in thread
From: Ondrej Zary @ 2017-11-17 14:26 UTC (permalink / raw)
To: Ben Skeggs; +Cc: nouveau, linux-kernel
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Blank console but X11 works on MCP79 - old regression since 3.8 2017-11-17 14:26 Blank console but X11 works on MCP79 - old regression since 3.8 Ondrej Zary @ 2017-11-17 14:43 ` Ilia Mirkin 2017-11-17 17:33 ` Ondrej Zary 0 siblings, 1 reply; 10+ messages in thread From: Ilia Mirkin @ 2017-11-17 14:43 UTC (permalink / raw) To: Ondrej Zary Cc: Ben Skeggs, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Blank console but X11 works on MCP79 - old regression since 3.8 2017-11-17 14:43 ` Ilia Mirkin @ 2017-11-17 17:33 ` Ondrej Zary 2017-11-17 17:41 ` Ilia Mirkin 0 siblings, 1 reply; 10+ messages in thread From: Ondrej Zary @ 2017-11-17 17:33 UTC (permalink / raw) To: Ilia Mirkin Cc: Ben Skeggs, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Blank console but X11 works on MCP79 - old regression since 3.8 2017-11-17 17:33 ` Ondrej Zary @ 2017-11-17 17:41 ` Ilia Mirkin 2017-11-17 19:25 ` Ondrej Zary 0 siblings, 1 reply; 10+ messages in thread From: Ilia Mirkin @ 2017-11-17 17:41 UTC (permalink / raw) To: Ondrej Zary Cc: Ben Skeggs, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Blank console but X11 works on MCP79 - old regression since 3.8 2017-11-17 17:41 ` Ilia Mirkin @ 2017-11-17 19:25 ` Ondrej Zary 2017-11-17 19:37 ` Ilia Mirkin 0 siblings, 1 reply; 10+ messages in thread From: Ondrej Zary @ 2017-11-17 19:25 UTC (permalink / raw) To: Ilia Mirkin Cc: Ben Skeggs, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Blank console but X11 works on MCP79 - old regression since 3.8 2017-11-17 19:25 ` Ondrej Zary @ 2017-11-17 19:37 ` Ilia Mirkin 2017-11-17 19:52 ` Ilia Mirkin 2017-11-18 5:23 ` Ilia Mirkin 0 siblings, 2 replies; 10+ messages in thread From: Ilia Mirkin @ 2017-11-17 19:37 UTC (permalink / raw) To: Ondrej Zary Cc: Ben Skeggs, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Blank console but X11 works on MCP79 - old regression since 3.8 2017-11-17 19:37 ` Ilia Mirkin @ 2017-11-17 19:52 ` Ilia Mirkin 2017-11-17 20:06 ` Ondrej Zary 2017-11-18 5:23 ` Ilia Mirkin 1 sibling, 1 reply; 10+ messages in thread From: Ilia Mirkin @ 2017-11-17 19:52 UTC (permalink / raw) To: Ondrej Zary Cc: Ben Skeggs, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Blank console but X11 works on MCP79 - old regression since 3.8 2017-11-17 19:52 ` Ilia Mirkin @ 2017-11-17 20:06 ` Ondrej Zary 0 siblings, 0 replies; 10+ messages in thread From: Ondrej Zary @ 2017-11-17 20:06 UTC (permalink / raw) To: Ilia Mirkin Cc: Ben Skeggs, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Blank console but X11 works on MCP79 - old regression since 3.8 2017-11-17 19:37 ` Ilia Mirkin 2017-11-17 19:52 ` Ilia Mirkin @ 2017-11-18 5:23 ` Ilia Mirkin 2017-11-21 1:52 ` Ilia Mirkin 1 sibling, 1 reply; 10+ messages in thread From: Ilia Mirkin @ 2017-11-18 5:23 UTC (permalink / raw) To: Ondrej Zary Cc: Ben Skeggs, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Blank console but X11 works on MCP79 - old regression since 3.8 2017-11-18 5:23 ` Ilia Mirkin @ 2017-11-21 1:52 ` Ilia Mirkin 0 siblings, 0 replies; 10+ messages in thread From: Ilia Mirkin @ 2017-11-21 1:52 UTC (permalink / raw) To: Ondrej Zary Cc: Ben Skeggs, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-11-21 1:52 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-11-17 14:26 Blank console but X11 works on MCP79 - old regression since 3.8 Ondrej Zary 2017-11-17 14:43 ` Ilia Mirkin 2017-11-17 17:33 ` Ondrej Zary 2017-11-17 17:41 ` Ilia Mirkin 2017-11-17 19:25 ` Ondrej Zary 2017-11-17 19:37 ` Ilia Mirkin 2017-11-17 19:52 ` Ilia Mirkin 2017-11-17 20:06 ` Ondrej Zary 2017-11-18 5:23 ` Ilia Mirkin 2017-11-21 1:52 ` Ilia Mirkin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox