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.
I believe you attached the wrong dmesg, that one seems more relevant to b43 dev work...
Sorry about that. Let me generate a proper dmesg and post it.
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.
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.
Yes, I did mean 1280x800. Thanks for the hint. I will look at the two routines you suggest.
I tested 640x480. After X started, it was OK for about 5 seconds, and then it failed in the same way as 1280x800.
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.)
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.
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.)
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.
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?
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.
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.
Created attachment 115254 [details] mmiotrace of NVIDIA proprietary driver
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.
Created attachment 115278 [details] mmiotrace of NVIDIA proprietary driver with glxgears
(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?
It is 1280x800.
Could anyone assist with analysing my mmiotrace?
Is it possible for anyone at your end to do some analysis based on the information I have provided so far?
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
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.
Tried nv driver, 1280x800 garbled screen too, 1024x768 OK.
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.
Created attachment 127258 [details] mmiotrace when changing resolutions with nouveau
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
(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.
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
(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?
Created attachment 127259 [details] mmiotrace of nouveau
(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
(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?
Created attachment 127260 [details] garbled X photo
Created attachment 127261 [details] garbled console photo
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
Just tried with 1.0.15 and options Option "AccelMethod" "none" Option "WrappedFB" "on" Option "PageFlip" "off" Nothing changed, the screen is garbled.
Modesetting is all done in the kernel, so no xf86-video-nouveau options will affect it one way or the other.
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
(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.
Where in the source should I look?
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.
-- 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/68.
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.