| Summary: | [BISECTED] nouveau, nv50: dual display doesn't work in 3.9 | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Yves-Alexis <corsac> |
| Component: | Driver/nouveau | Assignee: | Emil Velikov <emil.l.velikov> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | joshuabaergen, per.arnold, wippbox |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 64904 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
Yves-Alexis
2013-06-24 15:46:49 UTC
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 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.