Bug 70972 - [NV67] Modesetting failure at 1280x800
Summary: [NV67] Modesetting failure at 1280x800
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-28 22:01 UTC by Larry Finger
Modified: 2017-09-03 16:34 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Output of dmesg (612 bytes, text/plain)
2013-10-28 22:01 UTC, Larry Finger
no flags Details
Correct dmesg output for nouveau (68.00 KB, text/plain)
2013-11-10 01:11 UTC, Larry Finger
no flags Details
mmiotrace of NVIDIA proprietary driver (1.96 MB, application/x-xz)
2015-04-22 00:46 UTC, adlo
no flags Details
mmiotrace of NVIDIA proprietary driver with glxgears (2.51 MB, application/x-xz)
2015-04-22 19:27 UTC, adlo
no flags Details
mmiotrace when changing resolutions with nouveau (2.11 KB, text/plain)
2016-10-12 20:53 UTC, Nerijus Baliūnas
no flags Details
mmiotrace of nouveau (5.11 MB, application/x-xz)
2016-10-12 21:22 UTC, Nerijus Baliūnas
no flags Details
garbled X photo (2.12 MB, image/jpeg)
2016-10-12 21:44 UTC, Nerijus Baliūnas
no flags Details
garbled console photo (2.13 MB, image/jpeg)
2016-10-12 21:54 UTC, Nerijus Baliūnas
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Larry Finger 2013-10-28 22:01:43 UTC
Created attachment 88259 [details]
Output of dmesg

With nouveau on the graphics adapter on an HP dv2815nr laptop, both console and X displays show an incorrect scan length with a resulting garbled screen.

The 'lspci -nnv' for this adapter is

00:12.0 VGA compatible controller [0300]: NVIDIA Corporation C67 [GeForce 7150M / nForce 630M] [10de:0531] (rev a2) (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Device [103c:30d6]
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10
        Memory at f4000000 (32-bit, non-prefetchable) [size=16M]
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at f0000000 (64-bit, non-prefetchable) [size=16M]
        [virtual] Expansion ROM at c0000000 [disabled] [size=128K]
        Capabilities: <access denied>
        Kernel modules: nouveau

This device has never worked with nouveau on any kernel. I am trying to make it work now as the nv driver is failing in certain cases, and fbdev cannot use the optimum resolution (1600 x 800) for this laptop.
Comment 1 Ilia Mirkin 2013-11-09 20:51:58 UTC
I believe you attached the wrong dmesg, that one seems more relevant to b43 dev work...
Comment 2 Larry Finger 2013-11-10 00:30:08 UTC
Sorry about that. Let me generate a proper dmesg and post it.
Comment 3 Larry Finger 2013-11-10 01:11:32 UTC
Created attachment 88953 [details]
Correct dmesg output for nouveau

This attachment is the proper one to show the dmesg problem. On this boot, X did not start due to an xorg.d file calling for driver nv; however, the console output showed the line breaking.
Comment 4 Ilia Mirkin 2013-11-10 08:19:40 UTC
Do other modes work, or do they all fail? Did you really mean 1600x800 (that's a 2:1 resolution, I've never seen that...)? The driver detects 1280x800, which seems more common. Any interesting info in /sys/class/drm/card0-LVDS-1?

Not sure what other advice to give... the function you're most interested in is nv04_dfp_mode_set and probably nv04_dfp_commit. Perhaps compare them to the nv driver, on which a lot of that code is based.
Comment 5 Larry Finger 2013-11-10 18:35:58 UTC
Yes, I did mean 1280x800.

Thanks for the hint. I will look at the two routines you suggest.
Comment 6 Larry Finger 2013-11-13 05:05:59 UTC
I tested 640x480. After X started, it was OK for about 5 seconds, and then it failed in the same way as 1280x800.
Comment 7 Ilia Mirkin 2014-02-05 20:24:05 UTC
No clue if this will help, but we recently noticed that the NV4x IGP's have some differences in register placement. Perhaps this patch:

http://lists.freedesktop.org/archives/nouveau/2014-February/016033.html

will help something. (See nouveau list for another patch that possibly fixes MSI that comes with 3.13.)
Comment 8 Larry Finger 2014-02-05 21:16:39 UTC
I am now running 3.14-rc1, and the MSI changes for 3.13 should be in my kernel.

I added the patch mentioned in comment #7. I did not alter my xorg.conf.d setup and X did not start, but I still had the screen double-up/faulty wrap in the text screen.

Thanks for notifying me. Perhaps there are other register location differences.
Comment 9 Ilia Mirkin 2014-02-05 21:26:51 UTC
Well, unrelated to this issue, you probably need

http://lists.freedesktop.org/archives/nouveau/2014-February/016032.html

For MSI to work properly. We've had reports of issues for people on NV4E, and it's also been confirmed that the registers are in a different place for NV63. It's very likely to also be different on NV67. You can also disable MSI by using nouveau.config=NvMSI=0 . (However if you can confirm that this patch either helps or breaks things, that would be nice -- not a lot of people with this HW.)
Comment 10 Larry Finger 2014-02-05 22:02:22 UTC
Unfortunately, neither the patch nor the patch and the nouveau.config boot change made any difference.

I certainly understand that not many people have this hardware.
Comment 11 adlo 2015-02-23 15:51:01 UTC
I also have an NVIDIA GeForce 7150m / nForce 630m and I am also experiencing this problem. The screen is garbled in both X and the console.

I noticed that xrandr detects a load on TV-1 even though nothing is connected to this port. I have tried setting the video=TV-1:d and nouveau.tv_disable=1 kernel options, but neither of these have any effect.

I can get a clear image if I set the resolution to 1024x768, but this is not ideal as this is not my monitor's native resolution.

I am wondering if the cause of the garbled screen could be TV-out misdetection?
Comment 12 Ilia Mirkin 2015-02-23 16:03:03 UTC
A few things to try if you're feeling motivated to resolve this:

(a) Does setting the mode work properly with the xf86-video-nv driver (and with nouveau entirely disabled)? If so, try to see what the two are doing differently.

(b) What about nvidiafb (drivers/video/nvidia)?

(c) Do a mmiotrace of the blob and compare what it's doing to what nouveau's doing.
Comment 13 adlo 2015-02-25 20:05:11 UTC
I tried the nv driver and it did not list any resolutions above 1024x768, so I could not find out if it would work at 1280x800.
Comment 14 adlo 2015-04-22 00:46:47 UTC
Created attachment 115254 [details]
mmiotrace of NVIDIA proprietary driver
Comment 15 Larry Finger 2015-04-22 01:36:25 UTC
I no longer have the computer with the adaptor that failed. I now am using a machine with a GeForce 7150M/nForce 630M with PCI ID 10de:0531. It works perfectly with nouveau.
Comment 16 adlo 2015-04-22 19:27:03 UTC
Created attachment 115278 [details]
mmiotrace of NVIDIA proprietary driver with glxgears
Comment 17 adlo 2015-04-22 19:52:10 UTC
(In reply to Larry Finger from comment #15)
> I no longer have the computer with the adaptor that failed. I now am using a
> machine with a GeForce 7150M/nForce 630M with PCI ID 10de:0531. It works
> perfectly with nouveau.

From what I've heard, it would seem that some GeForce 7150M/nForce 630Ms work perfectly with nouveau, while others exhibit the garbled screen problem. I wonder why this could be?

What is the screen resolution of your new machine?
Comment 18 Larry Finger 2015-04-22 20:06:39 UTC
It is 1280x800.
Comment 19 adlo 2015-05-20 17:47:44 UTC
Could anyone assist with analysing my mmiotrace?
Comment 20 adlo 2015-05-22 18:11:35 UTC
Is it possible for anyone at your end to do some analysis based on the information I have provided so far?
Comment 21 Viktor Sidochenko 2015-06-27 16:21:18 UTC
I have laptop with NVIDIA Corporation C67 [GeForce 7150M / nForce 630M] [10de:0531] (rev a2) card onboard and native 1280x800 resolution. And it shows broken picture with nouveau. 

Full info with  lspci -nnv:

00:12.0 VGA compatible controller [0300]: NVIDIA Corporation C67 [GeForce 7150M / nForce 630M] [10de:0531] (rev a2) (prog-if 00 [VGA controller])
	Subsystem: Hewlett-Packard Company Device [103c:30cf]
	Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 16
	Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Memory at f4000000 (64-bit, non-prefetchable) [size=16M]
	[virtual] Expansion ROM at f6280000 [disabled] [size=128K]
	Capabilities: [48] Power Management version 2
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
	Kernel driver in use: nvidia
Comment 22 Nerijus Baliūnas 2016-10-12 14:11:00 UTC
I have GeForce 7150M / nForce 630M and it shows garbled screen with 1280x800 resolution. 1024x768 works OK, as well as proprietary nvidia driver.
I tried a few modelines generated with cvt 1280 800, cvt 1280 800 59, cvt 1280 800 57, cvt 1280 800 50 - does not help, still the garbled screen. Adding nouveau.config=NvMSI=0 to kernel boot line did not help neither.
Fedora 25 beta, xorg-x11-drv-nouveau-1.0.13-1.fc25.x86_64.
Comment 23 Nerijus Baliūnas 2016-10-12 15:22:22 UTC
Tried nv driver, 1280x800 garbled screen too, 1024x768 OK.
Comment 24 Ilia Mirkin 2016-10-12 20:11:43 UTC
It would be helpful to have a mmiotrace of nouveau attempting to do the modeset. The code's not exactly easy to read, and this should make it easy to compare 1:1.
Comment 25 Nerijus Baliūnas 2016-10-12 20:53:42 UTC
Created attachment 127258 [details]
mmiotrace when changing resolutions with nouveau
Comment 26 Nerijus Baliūnas 2016-10-12 20:54:37 UTC
I ran commands:
echo mmiotrace > /sys/kernel/debug/tracing/current_tracer
cat /sys/kernel/debug/tracing/trace_pipe > mydump.txt &
xrandr -s 1280x800 - screen became garbled
xrandr -s 1024x768 - screen became OK
Comment 27 Ilia Mirkin 2016-10-12 20:56:51 UTC
(In reply to Nerijus Baliūnas from comment #25)
> Created attachment 127258 [details]
> mmiotrace when changing resolutions with nouveau

A successful mmiotrace should be 10-100MB or so. (Use xz -9 to compress it.)

Have a look at https://wiki.ubuntu.com/X/MMIOTracing for a guide on how to trace properly. The trace needs to be started before nouveau loads.
Comment 28 Nerijus Baliūnas 2016-10-12 21:19:39 UTC
Booted to console, ran
echo 64000 > /sys/kernel/debug/tracing/buffer_size_kb
echo mmiotrace > /sys/kernel/debug/tracing/current_tracer
cat /sys/kernel/debug/tracing/trace_pipe > mmiotrace.log &
modprobe nouveau
init 5
xrandr -s 1024x768 - screen became OK
xrandr -s 1280x800 - screen became garbled
Comment 29 Ilia Mirkin 2016-10-12 21:21:42 UTC
(In reply to Nerijus Baliūnas from comment #28)
> Booted to console, ran
> echo 64000 > /sys/kernel/debug/tracing/buffer_size_kb
> echo mmiotrace > /sys/kernel/debug/tracing/current_tracer
> cat /sys/kernel/debug/tracing/trace_pipe > mmiotrace.log &
> modprobe nouveau
> init 5
> xrandr -s 1024x768 - screen became OK
> xrandr -s 1280x800 - screen became garbled

Does the console not become garbled when you just run 'modprobe nouevau' and it flips to 1280x800 mode? Or does it go into some other mode?
Comment 30 Nerijus Baliūnas 2016-10-12 21:22:20 UTC
Created attachment 127259 [details]
mmiotrace of nouveau
Comment 31 Nerijus Baliūnas 2016-10-12 21:28:35 UTC
(In reply to Ilia Mirkin from comment #29)
> Does the console not become garbled when you just run 'modprobe nouevau' and
> it flips to 1280x800 mode? Or does it go into some other mode?
It becomes garbled. It does not if I boot with video=LVDS-1:1024x768
Comment 32 Ilia Mirkin 2016-10-12 21:33:58 UTC
(In reply to Nerijus Baliūnas from comment #31)
> (In reply to Ilia Mirkin from comment #29)
> > Does the console not become garbled when you just run 'modprobe nouevau' and
> > it flips to 1280x800 mode? Or does it go into some other mode?
> It becomes garbled. It does not if I boot with video=LVDS-1:1024x768

OK. And if it's not too difficult, mind taking a photograph of the garbling?
Comment 33 Nerijus Baliūnas 2016-10-12 21:44:53 UTC
Created attachment 127260 [details]
garbled X photo
Comment 34 Nerijus Baliūnas 2016-10-12 21:54:24 UTC
Created attachment 127261 [details]
garbled console photo
Comment 35 Sérgio M. Basto 2017-09-02 18:01:17 UTC
OK but you don't test many drive options that you have in nouveau drive [1] 

Option "AccelMethod" 0 

Option "WrappedFB" 1

              Enable  or  disable  wfb,  only  affects  nv50+. Useful for some legacy configurations where high rendering
              latency is perceived.  Default: wfb is disabled.

Option "PageFlip" 0

etc 

Also in Fedora 25 we got xf86-video-nouveau 1.0.15 last report was 1.0.13

[1] 
man nouveau
Comment 36 Nerijus Baliūnas 2017-09-03 14:33:23 UTC
Just tried with 1.0.15 and options
        Option "AccelMethod" "none"
        Option "WrappedFB" "on"
        Option "PageFlip" "off"
Nothing changed, the screen is garbled.
Comment 37 Ilia Mirkin 2017-09-03 15:20:02 UTC
Modesetting is all done in the kernel, so no xf86-video-nouveau options will affect it one way or the other.
Comment 38 Nerijus Baliūnas 2017-09-03 15:33:59 UTC
Is there any possibility to make 1280x800 work? 
304xx is going to be retired at the end of the year by nvidia.
http://nvidia.custhelp.com/app/answers/detail/a_id/3142
Comment 39 Ilia Mirkin 2017-09-03 15:43:21 UTC
(In reply to Nerijus Baliūnas from comment #38)
> Is there any possibility to make 1280x800 work? 
> 304xx is going to be retired at the end of the year by nvidia.
> http://nvidia.custhelp.com/app/answers/detail/a_id/3142

If the NVIDIA driver can do it, that means that there's a possibility. Patches welcome.
Comment 40 Nerijus Baliūnas 2017-09-03 16:07:47 UTC
Where in the source should I look?
Comment 41 Ilia Mirkin 2017-09-03 16:34:08 UTC
All of the modesetting logic (for pre-G80 chips) lives in

drivers/gpu/drm/nouveau/dispnv04

This is mostly an adaptation of xf86-video-nv to work in the kernel, with some IMHO misguided "cleanups" that were applied to some of the incomprehensible clock/etc calculation code. Unfortunately those are also mixed in with legit fixes, so it's hard to undo.

Either way, since xf86-video-nv also reputedly can't make 1280x800 work, reading that source is unlikely to be of much help. However at least the NV1A and NV1F IGP's tend to have their own very special clock calculation logic, so perhaps that's missing (might look at what e.g. NV4C/NV4E do, as those allegedly work well).

There are already traces of both the blob and nouveau and how they perform the modesetting (see attachments in this bug). What's largely missing is identifying what nouveau does differently, and then coming up with a way to fix it.

You can use 'demmio' from envytools to help analyze the traces (https://github.com/envytools/envytools).

If you have questions about the tooling or the code, feel free to join in #nouveau on irc.freenode.net.


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.