Created attachment 101974 [details]
3.15.2 dmesg log
I've an AMD M4N78 PRO (Bios 1303) motherboard  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 
Yes, I've read:
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
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 18.104.22.1681 (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
(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:  Power Management version 2
Capabilities:  MSI: Enable- Count=1/1 Maskable- 64bit+
Kernel driver in use: nouveau
* Relevant kernel config:
Created attachment 101975 [details]
vbtracetool rom dump
Created a rom dump as suggested on
# ./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
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.
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.
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])
(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.
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.
nouveau [ DRM] VRAM: 32 MiB
nouveau [ DRM] VRAM: 64 MiB
Before closing this bug, could you at least add a warning if someone sets the video memory below 64MB?
(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
> I've also modified the title accordingly.
> nouveau [ DRM] VRAM: 32 MiB
> 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...
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
BTW this is regression since kernel 3.2.* I've used before.
This bug is still present in 4.14 kernel at least on MCP79 (ION). Bisected it to:
4f6029da58ba9204c98e33f4f3737fe085c87a6f is the first bad commit
Author: Ben Skeggs <email@example.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 <firstname.lastname@example.org>
But it's a huge patch :(
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).
Ben's latest tree ought to fix it completely:
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.