Bug 80675 - [NVAA] Nouveau KMS framebuffer hand-over: no/black console on Nvidia MCP78S/C77/GeForce 8300 (10de:0848) with 32MB graphics RAM, X11 ok
Summary: [NVAA] Nouveau KMS framebuffer hand-over: no/black console on Nvidia MCP78S/C...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-29 12:06 UTC by Walter Haidinger
Modified: 2019-12-04 08:46 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
3.15.2 dmesg log (45.00 KB, text/plain)
2014-06-29 12:06 UTC, Walter Haidinger
no flags Details
vbtracetool rom dump (56.00 KB, application/octet-stream)
2014-06-29 12:32 UTC, Walter Haidinger
no flags Details
use "low res" lut for c8 (828 bytes, patch)
2017-12-31 03:44 UTC, Ilia Mirkin
no flags Details | Splinter Review

Description Walter Haidinger 2014-06-29 12:06:44 UTC
Created attachment 101974 [details]
3.15.2 dmesg log

I've an AMD M4N78 PRO (Bios 1303) motherboard [1] here having
a MCP78S chipset (GeForce 8300 onboard, PCI-ID 10de:0848)
where I get all black consoles with KMS.

Please note that X11 works fine.
Fortunately no lockups when switching VTs either.

I think there is probably a problem with KMS hand-over.

Reproducible at least with:
* vanilla 64-bit kernel 3.15.2 and 3.14.8 
* openSUSE 13.1/x86_64 (3.11.10 kernel)
* grml64-2014.03 live CD with 3.13.6 kernel [2]
 
Yes, I've read:
http://nouveau.freedesktop.org/wiki/KernelModeSetting/

The consoles disappear (black only) once Nouveau switches
to its framebuffer. If KMS is disabled, the consoles stay
visible, i.e. vesa-fb works.

Console switching still works, i.e. switching to/from VT7
where X11 runs fine is possible. When switching, the
display goes black but switching back to VT7 restores
the X11 display.

When using fbcon=map:1 kernel parameter, behavior changes
just slightly when console switching: The X11 screen stays
(no switch to black screen) but seems to freeze. Switching
back to VT7 enables X11 again. 

Btw, the Linux Penguins shown for each CPU core are displayed
but are distorted and in false colors. They disappear after
about 10 seconds when the VT screens goes all black.

Below are more details:

* Relevant dmesg lines (see attachment for full):
[    9.017968] nouveau  [  DEVICE][0000:02:00.0] BOOT0  : 0x0aa400a2
[    9.036288] nouveau  [  DEVICE][0000:02:00.0] Chipset: MCP77/MCP78 (NVAA)
[    9.056678] nouveau  [  DEVICE][0000:02:00.0] Family : NV50
[    9.073849] nouveau  [   VBIOS][0000:02:00.0] checking PRAMIN for image...
[    9.135263] nouveau  [   VBIOS][0000:02:00.0] ... appears to be valid
[    9.154602] nouveau  [   VBIOS][0000:02:00.0] using image from PRAMIN
[    9.174041] nouveau  [   VBIOS][0000:02:00.0] BIT signature found
[    9.192343] nouveau  [   VBIOS][0000:02:00.0] version 62.77.36.00.00
[    9.231562] nouveau  [     PFB][0000:02:00.0] RAM type: stolen system memory
[    9.252736] nouveau  [     PFB][0000:02:00.0] RAM size: 32 MiB
[    9.270265] nouveau  [     PFB][0000:02:00.0]    ZCOMP: 0 tags
[    9.289229] nouveau  [    VOLT][0000:02:00.0] GPU voltage: 1100000uv
[    9.498063] tsc: Refined TSC clocksource calibration: 3299.999 MHz
[   10.543608] Switched to clocksource tsc
[   18.015935] nouveau  [  PTHERM][0000:02:00.0] FAN control: none / external
[   18.036606] nouveau  [  PTHERM][0000:02:00.0] fan management: automatic
[   18.056467] nouveau  [  PTHERM][0000:02:00.0] internal sensor: yes
[   18.075056] nouveau  [     CLK][0000:02:00.0] 0f: core 500 MHz shader 1500 MHz vdec 500 MHz
[   18.100202] nouveau  [     CLK][0000:02:00.0] --: core 350 MHz shader 800 MHz vdec 350 MHz
[   18.125199] [TTM] Zone  kernel: Available graphics memory: 4062588 kiB
[   18.144801] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[   18.164410] [TTM] Initializing pool allocator
[   18.177527] [TTM] Initializing DMA pool allocator
[   18.191691] nouveau  [     DRM] VRAM: 32 MiB
[   18.204540] nouveau  [     DRM] GART: 1048576 MiB
[   18.218697] nouveau  [     DRM] TMDS table version 2.0
[   18.234151] nouveau  [     DRM] DCB version 4.0
[   18.247787] nouveau  [     DRM] DCB outp 00: 01000300 0000001e
[   18.265322] nouveau  [     DRM] DCB outp 01: 01011332 00020010
[   18.282855] nouveau  [     DRM] DCB conn 00: 00000100
[   18.298118] nouveau  [     DRM] DCB conn 01: 00001261
[   18.319941] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   18.339819] [drm] Driver supports precise vblank timestamp query.
[   18.366629] nouveau  [     DRM] MM: using M2MF for buffer copies
[   18.414966] nouveau  [     DRM] allocated 1024x768 fb: 0x50000, bo ffff88022058e400
[   18.438055] fbcon: nouveaufb (fb0) is primary device
[   18.498687] random: nonblocking pool is initialized
[   18.505940] Console: switching to colour frame buffer device 128x48
[   18.555299] nouveau 0000:02:00.0: fb0: nouveaufb frame buffer device
[   18.574317] nouveau 0000:02:00.0: registered panic notifier
[   18.590996] [drm] Initialized nouveau 1.1.1 20120801 for 0000:02:00.0 on minor 0

* Xorg.0.log, driver from openSUSE package
 xorg-x11-driver-video-nouveau-1.0.9-3.1.2.x86_64

 NOTE: Yes, this isn't the lastest but X11 is working. 
       This bug is about the console framebuffer.
       I'm adding the Xorg log because it might provide some clues.   

 X.Org X Server 1.14.3.901 (1.14.4 RC 1)
 Release Date: 2013-10-26
 Build Operating System: openSUSE SUSE LINUX
 Build Date: 17 April 2014  05:37:34AM
 (II) xfree86: Adding drm device (/dev/dri/card0)
 (--) PCI:*(0:2:0:0) 10de:0848:1043:82e2 rev 162, Mem @ 0xfa000000/16777216, 0xd8000000/134217728, 0xd6000000/33554432, I/O @ 0x0000bc00/128, BIOS @ 0x????????/131072
 (II) NOUVEAU driver
 (II) NOUVEAU driver for NVIDIA chipset families :
        RIVA TNT        (NV04)
        RIVA TNT2       (NV05)
        GeForce 256     (NV10)
        GeForce 2       (NV11, NV15)
        GeForce 4MX     (NV17, NV18)
        GeForce 3       (NV20)
        GeForce 4Ti     (NV25, NV28)
        GeForce FX      (NV3x)
        GeForce 6       (NV4x)
        GeForce 7       (G7x)
        GeForce 8       (G8x)
        GeForce GTX 200 (NVA0)
        GeForce GTX 400 (NVC0)
 (++) using VT number 7
 (II) [drm] nouveau interface version: 1.1.1
 (--) NOUVEAU(0): Chipset: "NVIDIA NVAA"
 (**) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32
 (==) NOUVEAU(0): RGB weight 888
 (==) NOUVEAU(0): Default visual is TrueColor
 (==) NOUVEAU(0): Using HW cursor
 (==) NOUVEAU(0): GLX sync to VBlank disabled.
 (==) NOUVEAU(0): Page flipping enabled
 (==) NOUVEAU(0): Swap limit set to 2 [Max allowed 2]
 (II) NOUVEAU(0): Output VGA-1 using monitor section Monitor[0]
 (II) NOUVEAU(0): EDID for output VGA-1
 (II) NOUVEAU(0): Printing probed modes for output VGA-1
 (II) NOUVEAU(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz eP)
 (II) NOUVEAU(0): EDID for output HDMI-1
 (II) NOUVEAU(0): Output VGA-1 connected
 (II) NOUVEAU(0): Output HDMI-1 disconnected
 (II) NOUVEAU(0): Using exact sizes for initial modes
 (II) NOUVEAU(0): Output VGA-1 using initial mode 1024x768
 (II) NOUVEAU(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
 (--) NOUVEAU(0): Virtual size is 1024x768 (pitch 0)
 (==) NOUVEAU(0): Backing store disabled
 (==) NOUVEAU(0): Silken mouse enabled
 (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured Video.
 (II) NOUVEAU(0): [XvMC] Extension initialized.
 (**) NOUVEAU(0): DPMS enabled
 (II) NOUVEAU(0): RandR 1.2 enabled, ignore the following RandR disabled message.
 (II) NOUVEAU(0): NVEnterVT is called.
 (II) NOUVEAU(0): Setting screen physical size to 304 x 228

* lspci -vs 02:00.0
02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 8300] (rev a2) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 82e2
        Flags: bus master, fast devsel, latency 0, IRQ 23
        Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
        Memory at d8000000 (64-bit, prefetchable) [size=128M]
        Memory at d6000000 (64-bit, prefetchable) [size=32M]
        I/O ports at bc00 [size=128]
        Expansion ROM at fb3e0000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
        Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
        Kernel driver in use: nouveau

* Relevant kernel config:
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y

* References:
[1] http://www.asus.com/Motherboards/M4N78_PRO/specifications/
[2] http://grml.org/changelogs/README-grml-2014.03/
Comment 1 Walter Haidinger 2014-06-29 12:32:55 UTC
Created attachment 101975 [details]
vbtracetool rom dump

Created a rom dump as suggested on
http://nouveau.freedesktop.org/wiki/DumpingVideoBios/

# ./vbtracetool -w 2> 1043-82e2.rom
Using card 10de:0848 on 0200
Nvidia card -- using PROM/PRAMIN BIOS
Using card memory region at 0xfa000000
Attempting to locate BIOS image in PROM... BIOS signature not found
Attempting to locate BIOS image in PRAMIN... appears to be valid
Comment 2 Ilia Mirkin 2014-06-29 15:42:21 UTC
You have a number of options being passed to the kernel:

console=tty0 console=fb0 console=ttyS0,38400n8 video=card0-VGA-1:1024x768@60

Would you mind trying it without those? esp the video= option.
Comment 3 Walter Haidinger 2014-06-29 20:11:56 UTC
No changes if I omit the console=fb0 and/or video= option.
Using a different resolution for video= sets the X11 screen accordingly, though.

I also recall that I've added those two in an effort to get a working console.
But that obviously did not help.
Comment 4 Jeff 2014-07-10 02:59:43 UTC
I believe I am having the same issue, except it is entirely black after KMS is activated on boot. Even in X11.

I use Debian Testing on a Dell XPS m1730 with SLI Geforce 8700m.


lspci -v |grep 84
03:00.0 VGA compatible controller: NVIDIA Corporation G84M [GeForce 8700M GT] (rev a1) (prog-if 00 [VGA controller])
Comment 5 Ilia Mirkin 2014-07-10 03:02:55 UTC
(In reply to comment #4)
> I believe I am having the same issue, except

In other words... not the same issue. File a fresh bug with the relevant info. If it's deemed the same, we can mark it as a dup.
Comment 6 Walter Haidinger 2014-10-31 20:39:43 UTC
Update: I got my consoles back! :-)

Fix: Increased the ivdeo RAM set in the BIOS for the video card from 32MB to 64MB.
I've also modified the title accordingly.

Before:
 nouveau  [     DRM] VRAM: 32 MiB

Now:
 nouveau  [     DRM] VRAM: 64 MiB

Before closing this bug, could you at least add a warning if someone sets the video memory below 64MB?
Comment 7 Ilia Mirkin 2014-10-31 20:49:51 UTC
(In reply to Walter Haidinger from comment #6)
> Update: I got my consoles back! :-)
> 
> Fix: Increased the ivdeo RAM set in the BIOS for the video card from 32MB to
> 64MB.
> I've also modified the title accordingly.
> 
> Before:
>  nouveau  [     DRM] VRAM: 32 MiB
> 
> Now:
>  nouveau  [     DRM] VRAM: 64 MiB
> 
> Before closing this bug, could you at least add a warning if someone sets
> the video memory below 64MB?

There shouldn't be any issue with using 32MB of vram. However I do think that the scanout buffer has to be in VRAM... which should be *more* than sufficient for 1024x768. Sounds like we're doing something very wrong somewhere...
Comment 8 Alexey 2014-11-01 10:16:26 UTC
Same issue: when KMS is just switched I can see two kerenel logos in the top (the are not properly draw though) and after that - black console. I have same amount of VRAM allocated in BIOS setup (32M).

02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 8200] (rev a2)
Linux hades 3.14.22-hardened-r1-grsec #2 SMP Fri Oct 31 10:48:31 EET 2014 x86_64 AMD Athlon(tm) II X2 270u Processor AuthenticAMD GNU/Linux
Comment 9 Alexey 2014-11-01 10:17:17 UTC
BTW this is regression since kernel 3.2.* I've used before.
Comment 10 Ondrej Zary 2017-11-16 23:45:16 UTC
This bug is still present in 4.14 kernel at least on MCP79 (ION). Bisected it to:

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>

But it's a huge patch :(
Comment 11 Ilia Mirkin 2017-12-31 03:44:59 UTC
Created attachment 136458 [details] [review]
use "low res" lut for c8

This patch seems to help. There is a problem in that the first modeset does appear to miss that initialization entirely, but later ones seem to work after the screen is initially turned off (by the modeset).
Comment 12 Ilia Mirkin 2018-01-12 13:32:06 UTC
Ben's latest tree ought to fix it completely:

https://github.com/skeggsb/nouveau/commits/master

Looks like fbcon started using the atomic ioctls when available, which for nouveau is since the conversion in 4.10, but we had not switched to using the atomic gamma property.

That's why my patch was insufficient.
Comment 13 Martin Peres 2019-12-04 08:46:09 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/114.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.