+++ This bug was initially created as a clone of Bug #64904 +++ (In reply to comment #19) > I seem to have much of the same problem.as this, but this fix does not seem > to work for me. > > I just installed kernel 3.9.7 which have these fixes included. And I still > have the same problem. > > I am running a Dell desktop with NVIDA Quadro NVS 295 graphic card and two > identical Dell monitors attached via DisplayPort. > > I run Fedora 18 with all latest updates and using Nouveau drivers. > > Starting with Kernel 3.8.11 it boots OK and both monitors works as expected. > Starting with Kernel 3.9.2-3.9.7 it boots, but when trying to display > anything on monitor two it gets into problems. > > It boots until its tries to start the Xorg server and then monitor 2 starts > flickering on and off. Monitor 1 stays with the boot logo of fedora. > > Also during boot when booting I only have the boot logo of fedora on monitor > 1 > when running kernel 3.9.x while I have it on both screens when running kernel > 3.8.11 > > I am able to hit CTRL+f2 to get a text login. > > Is having two monitor different from having an external VGA? I have the same issue so I took the liberty to clone this bug. I also have a DELL desktop with: 02:00.0 VGA compatible controller [0300]: NVIDIA Corporation G86 [Quadro NVS 290] [10de:042f] (rev a1) Starting 3.9, dual screen doesn't work anymore (screen stays blank or doesn't not start at all) and vt switch takes some time. I've bisected the issue and here are the results: # bad: [c1be5a5b1b355d40e6cf79cc979eb66dafa24ad1] Linux 3.9 # good: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8 git bisect start 'v3.9' 'v3.8' # good: [d778df51c09264076fe0208c099ef7d428f21790] mm: vmscan: save work scanning (almost) empty LRU lists git bisect good d778df51c09264076fe0208c099ef7d428f21790 # bad: [ee89f81252179dcbf6cd65bd48299f5e52292d88] Merge branch 'for-3.9/core' of git://git.kernel.dk/linux-block git bisect bad ee89f81252179dcbf6cd65bd48299f5e52292d88 # good: [69086a78bdc973ec0b722be790b146e84ba8a8c4] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs git bisect good 69086a78bdc973ec0b722be790b146e84ba8a8c4 # bad: [ed5dc2372dba46e0ecd08791b1a0399d313e5cff] Merge tag 'mmc-updates-for-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc git bisect bad ed5dc2372dba46e0ecd08791b1a0399d313e5cff # bad: [1f3a574a4bfe86ebf7d51fac37e0668397372fd8] Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next git bisect bad 1f3a574a4bfe86ebf7d51fac37e0668397372fd8 # good: [cd17ef4114ad5c514b17e6a0bb02a309ab90b692] Merge tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel into drm-next git bisect good cd17ef4114ad5c514b17e6a0bb02a309ab90b692 # good: [210561ffd72d00eccf12c0131b8024d5436bae95] intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets git bisect good 210561ffd72d00eccf12c0131b8024d5436bae95 # good: [0f0800661a125ddb038462570c869fe6f8ab5737] drm/nouveau/gpio: pass number of on-die gpio lines to base git bisect good 0f0800661a125ddb038462570c869fe6f8ab5737 # good: [35f8badc1cf652381fa3f82c1fbea39f4dbe87fd] drm: Don't set the plane->fb to NULL on successfull set_plane git bisect good 35f8badc1cf652381fa3f82c1fbea39f4dbe87fd # good: [31a34aa421032cfe3b2b892c929e7539e747a7ac] drm/nouveau/i2c: aux channels not necessarily on nvio git bisect good 31a34aa421032cfe3b2b892c929e7539e747a7ac # good: [0a0afd282fd715dd63d64b243299a64da14f8e8d] drm/nv50-/disp: move DP link training to core and train from supervisor git bisect good 0a0afd282fd715dd63d64b243299a64da14f8e8d # bad: [eb6313add6dddf07ea3e50c4caa33a9c3b2379f1] drm/nv50: initial kms support for off-chip TMDS/DP encoders git bisect bad eb6313add6dddf07ea3e50c4caa33a9c3b2379f1 # good: [a2bc283f3905389ba53962a2bbb05ede0c16193d] drm/nv50-/disp: initial work towards supporting external encoders git bisect good a2bc283f3905389ba53962a2bbb05ede0c16193d # bad: [476e84e126171d809f9c0b5d97137f5055f95ca8] drm/nv50-/disp: initial supervisor support for off-chip encoders git bisect bad 476e84e126171d809f9c0b5d97137f5055f95ca8 # first bad commit: [476e84e126171d809f9c0b5d97137f5055f95ca8] drm/nv50-/disp: initial supervisor support for off-chip encoders # bad: [476e84e126171d809f9c0b5d97137f5055f95ca8] drm/nv50-/disp: initial supervisor support for off-chip encoders git bisect bad 476e84e126171d809f9c0b5d97137f5055f95ca8 # first bad commit: [476e84e126171d809f9c0b5d97137f5055f95ca8] drm/nv50-/disp: initial supervisor support for off-chip encoders # bad: [476e84e126171d809f9c0b5d97137f5055f95ca8] drm/nv50-/disp: initial supervisor support for off-chip encoders git bisect bad 476e84e126171d809f9c0b5d97137f5055f95ca8 # first bad commit: [476e84e126171d809f9c0b5d97137f5055f95ca8] drm/nv50-/disp: initial supervisor support for off-chip encoders And: 476e84e126171d809f9c0b5d97137f5055f95ca8 is the first bad commit commit 476e84e126171d809f9c0b5d97137f5055f95ca8 Author: Ben Skeggs <bskeggs@redhat.com> Date: Mon Feb 11 09:24:23 2013 +1000 drm/nv50-/disp: initial supervisor support for off-chip encoders Signed-off-by: Ben Skeggs <bskeggs@redhat.com> :040000 040000 9a28e3a997b96d2581ff81f5e0b97a9fc4f07917 41f69d26a80082e19d3c76e6556ad5ef9eb2677d M drivers Unfortunately it doesn't seem easy to just revert 476e84e126171d809f9c0b5d97137f5055f95ca8. If you need more info/debugging, please ask.
Adding Per Arnold Blaasmo to CC since he seems to have the same issue.
Yves-Alexis thanks for the bisection log Note that Bug #64904 is about broken logic wrt VGA detection, and as far as I can see Display port is not the same as VGA :) (Per Arnold Blaasmo) Before proceeding make sure that you have the patches from the above bug (either apply manually or upstream 3.9.7 & 3.10-rc7) Firstly can you try single head, and confirm if nouveau works correctly for each monitor plugged into it's respective connector Secondly please attach the output of dmesg for working and non-working setup. vbios might be useful as well [1] Lastly please be more explicit as to what the issue is "Starting 3.9, dual screen doesn't work anymore (screen stays blank or doesn't not start at all)" * Which screen stays black, is it connected using VGA, Cheers Emil
[1] http://nouveau.freedesktop.org/wiki/DumpingVideoBios/
Created attachment 81508 [details] Dmesg using kernel 3.8.11 (good)
Created attachment 81509 [details] Dmesg using kernel 3.9.4 (bad)
I just started my summer vacation :-)' So I am not able to test using each monitor as single head right now. I will do that when I am back around 15.July. I the mean time I have uploaded the dmesg from running with kernel 3.8.1 and 3.9.4. 3.8.11 is the last kernel that give me good result. I have tested with kernel 3.9.7, but have the same result as with other 3.9.x kernels.
Per Arnold Blaasmo Enjoy your vacation, shame you did not manage to confirm if the commit 476e84e126171d809f9c0b5d97137f5055f95ca8 is indeed the one causing your issue ? Please feel free to try the monitors individually and attach your vbios when you have the chance. Yves-Alexis It would still be beneficial if one complete set of logs + vbios is available
Created attachment 81530 [details] dmesg with 3.10-rc7 (bad) (In reply to comment #2) > Yves-Alexis thanks for the bisection log > > Note that Bug #64904 is about broken logic wrt VGA detection, and as far as > I can see Display port is not the same as VGA :) (Per Arnold Blaasmo) > > Before proceeding make sure that you have the patches from the above bug > (either apply manually or upstream 3.9.7 & 3.10-rc7) Ok, this comment is about 3.10-rc7. > > Firstly can you try single head, and confirm if nouveau works correctly for > each monitor plugged into it's respective connector No. Only the monitor plugged to the first connector is working (actually there's only one proprietary connector on the card itself, and I have some kind of adapter with two VGA outputs). > > Secondly please attach the output of dmesg for working and non-working > setup. vbios might be useful as well [1] Attached. > > Lastly please be more explicit as to what the issue is > "Starting 3.9, dual screen doesn't work anymore (screen stays blank or > doesn't not start at all)" > > * Which screen stays black, is it connected using VGA, The monitor plugged to the second connector stays black. Xorg doesn't even start.
Created attachment 81536 [details] dmesg with 3.8.0-rc6-00083-ga2bc283 (In reply to comment #2) > Secondly please attach the output of dmesg for working and non-working > setup. vbios might be useful as well [1] Here's the working case (commit ga2bc283 just before the bad one)
Just a quick comment. I my case both monitors is connected via displayport, and there are two separate displayports on my graphic card. I do not use a splitter cable of any sort.
Created attachment 81537 [details] dmesg with 3.8.0-rc6-00084-g476e84e (In reply to comment #2) > Secondly please attach the output of dmesg for working and non-working > setup. vbios might be useful as well [1] Here's the non working case (second monitor stays blank/off and Xorg doesn't start). This is with commit 476e84e (first bad commit).
Some notes from the log(s) * 2x DCB_OUTPUT_TMDS * 2x DCB_OUTPUT_ANALOG All of which onchip * 2x DCB_CONNECTOR_DVI_I
Created attachment 81580 [details] [review] sprinkle some printfs on top of non-working commin "Proprietary connector" - is it a DMS-59[1] by any chance ? Can you apply this patch on top of the offending commit and attach the dmesg [1] http://en.wikipedia.org/wiki/DMS-59
Created attachment 81581 [details] [review] sprinkle some printfs on top of working commit Apply this patch on top of the _working_ commit and attach dmesg Note: patches may contain some typos
(In reply to comment #13) > Created attachment 81580 [details] [review] [review] > sprinkle some printfs on top of non-working commin > > "Proprietary connector" - is it a DMS-59[1] by any chance ? Yes, looks like that. Will try the patches and report back.
Created attachment 81641 [details] dmesg with debug on top of bad commit (In reply to comment #13) > Created attachment 81580 [details] [review] [review] > sprinkle some printfs on top of non-working commin > > "Proprietary connector" - is it a DMS-59[1] by any chance ? > > Can you apply this patch on top of the offending commit and attach the dmesg Here it is.
(In reply to comment #14) > Created attachment 81581 [details] [review] [review] > sprinkle some printfs on top of working commit > > Apply this patch on top of the _working_ commit and attach dmesg > > Note: patches may contain some typos Yeah, seems this one doesn't boot at all (after loading nouveau module, the screen shuts down and nothing responds anymore). I'll try too look at the patch and fix obvious mistakes if I can spot ones.
Created attachment 81643 [details] dmesg with debug on top of good commit (In reply to comment #14) > Created attachment 81581 [details] [review] [review] > sprinkle some printfs on top of working commit > > Apply this patch on top of the _working_ commit and attach dmesg > > Note: patches may contain some typos Here it is.
Created attachment 81705 [details] [review] revert Can you give this patch a try. I reverts two pieces, namely * sets NV50_PDISPLAY_CRTC_CLK_CTRL2, after the vpll has been changed * uses output specific mask
Created attachment 81784 [details] dmesg with tentative fix applied (In reply to comment #19) > Created attachment 81705 [details] [review] [review] > revert > > Can you give this patch a try. I reverts two pieces, namely > > * sets NV50_PDISPLAY_CRTC_CLK_CTRL2, after the vpll has been changed > * uses output specific mask I've tried this commit on top of the first bad commit (it doesn't apply on top of 3.9.8) and it seems to fix the problem. Attached is a dmesg (without additional debugging from the previous patch).
Created attachment 81808 [details] [review] Use output specific mask Yves-Alexis Can you confirm which one (or if both) hunk of the previous patch is(are) needed? For your convenience I have split the patch into two
Created attachment 81809 [details] [review] set NV50_PDISPLAY_CRTC_CLK_CTRL2, after vpll Both of these(individually) apply on top of the offending commit
(In reply to comment #21) > Created attachment 81808 [details] [review] [review] > Use output specific mask > > Yves-Alexis > > Can you confirm which one (or if both) hunk of the previous patch is(are) > needed? > For your convenience I have split the patch into two This one is needed, and only this one.
Hi Yves-Alexis, thanks for testing (and fixing a ton of silly typos) Hope you don't mind that I've added you as reported-and-tested-by in the patch http://lists.freedesktop.org/archives/nouveau/2013-July/012895.html Per Arnold Blaasmo Feel free to try the patch, although I would suspect that your issue is caused by another commit
(In reply to comment #24) > Hi Yves-Alexis, thanks for testing (and fixing a ton of silly typos) > > Hope you don't mind that I've added you as reported-and-tested-by in the > patch > http://lists.freedesktop.org/archives/nouveau/2013-July/012895.html > > > Per Arnold Blaasmo > Feel free to try the patch, although I would suspect that your issue is > caused by another commit So any news on this beeing fixed in 3.9 or 3.10?
Good point, I have received no reply from stable(Greg) wrt to including this in the 3.9 and/or 3.10. Just pinged stable, to check if they have any objections, or if it just slipped through the cracks
(In reply to comment #26) > Good point, I have received no reply from stable(Greg) wrt to including this > in the 3.9 and/or 3.10. > > Just pinged stable, to check if they have any objections, or if it just > slipped through the cracks Any news on this? Doesn't seem to be in 3.10.2 either.
(In reply to comment #24) > Per Arnold Blaasmo > Feel free to try the patch, although I would suspect that your issue is > caused by another commit I have applied the patch, rebuild the module and tested it. I tested using kernel 3.9.10. It did NOT fix my problem. Just as you guessed. Before applying the patch I tried each monitor separately, and both work fine when only one monitor is connected. Since I now have a build environment for the module, I can have a look into differences of the version in kernel 3.8.11 and 3.9.10 and see if I find something. I am not familiar with this module code, so if you have any clues to help me, it would be nice :-) Per A.
Yves-Alexis Yay the patch has been added to the 3.10-stable queue http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary Thanks for the reminder ;) Per Arnold Blaasmo Please, please, please try to bisect[1] the problem :) If you're struggling with the bisection, open a bugreport about the issue and state your status so that we can guide you further Cheers Emil [1] The easiest "How to bisect" guide I've seen - http://wiki.winehq.org/RegressionTesting
Hi, Sorry for not answering for a long time. I have not bisected my self, but it seems that bug #67628 has the same problem with dual displayport. A bisect there of the kernel narrows it down to patch 5cc027f6b1ec651c18a4322ed3e30c6e9cf01e96 (drm/nv50-/disp: move DP link training to core and train from supervisor) I have tried to look into that patch and see if there is some obvious thing that might cause it, but i do not know much the different registers etc of displayport and nv50. I guess it makes sense to follow up this in that bug.
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.