Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upMonitor goes to standby with nVidia Quadro K1200+DisplayPort+ASUS PB278 #1952
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
May 4, 2016
Member
I do not believe that this is a Qubes-specific thing. Rather, it is an issue with nouveau and K1200 (and K2200). Filed a bug with nouveau. Hope this helps someone avoid frustration (until the bug is fixed)
Thanks! In that case, I'll tag this as a documentation enhancement.
If you're willing to submit a pull request to add this information, please do. This would probably be the appropriate page: https://www.qubes-os.org/doc/install-nvidia-driver/
Thanks! In that case, I'll tag this as a documentation enhancement. If you're willing to submit a pull request to add this information, please do. This would probably be the appropriate page: https://www.qubes-os.org/doc/install-nvidia-driver/ |
andrewdavidwong
added
enhancement
C: doc
P: major
labels
May 4, 2016
andrewdavidwong
added this to the
Documentation/website milestone
May 4, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
HeDamsja
May 5, 2016
@andrewdavidwong: Once I have something more concrete than just stating the fact 'it's broke, yo', I'll gladly submit a PR against the docs. Unless I misunderstood what you're asking me to document (quite possible) - I'd be glad to submit a PR for something else as well.
HeDamsja
commented
May 5, 2016
|
@andrewdavidwong: Once I have something more concrete than just stating the fact 'it's broke, yo', I'll gladly submit a PR against the docs. Unless I misunderstood what you're asking me to document (quite possible) - I'd be glad to submit a PR for something else as well. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
HeDamsja
May 5, 2016
So, an update.
Based on a suggestion from the nouveau folks, tried a more recent kernel. Fedora Core 23's 4.4.8-300, to be exact. Things work. DMesg output attached. Not sure if there's a way to backport 4.4.x's nouveau into Qubes' 4.1.x
dmesg-4.4.8-300.fc23.x86_64.txt
In kernel 4.1.x's output, there are "link training failed" messages, but in 4.4.x's, there are EDID checksum error messages instead. Wonder if 4.4.x's version simply handles ASUS' EDID brainfart better than 4.1.x?
dmesg output with drm|nouvea isolated:
Line 951: [ 1.547510] [drm] Initialized drm 1.1.0 20060810
Line 951: [ 1.547510] [drm] Initialized drm 1.1.0 20060810
Line 968: [ 1.600409] nouveau 0000:01:00.0: NVIDIA GM107 (1173c0a2)
Line 972: [ 1.719765] nouveau 0000:01:00.0: bios: version 82.07.76.00.05
Line 973: [ 1.720583] nouveau 0000:01:00.0: fb: 4096 MiB GDDR5
Line 984: [ 2.382416] nouveau 0000:01:00.0: DRM: VRAM: 4096 MiB
Line 984: [ 2.382416] nouveau 0000:01:00.0: DRM: VRAM: 4096 MiB
Line 985: [ 2.382582] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
Line 985: [ 2.382582] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
Line 986: [ 2.382744] nouveau 0000:01:00.0: DRM: TMDS table version 2.0
Line 986: [ 2.382744] nouveau 0000:01:00.0: DRM: TMDS table version 2.0
Line 987: [ 2.382909] nouveau 0000:01:00.0: DRM: DCB version 4.0
Line 987: [ 2.382909] nouveau 0000:01:00.0: DRM: DCB version 4.0
Line 988: [ 2.383084] nouveau 0000:01:00.0: DRM: DCB outp 00: 04800fb6 04420010
Line 988: [ 2.383084] nouveau 0000:01:00.0: DRM: DCB outp 00: 04800fb6 04420010
Line 989: [ 2.383250] nouveau 0000:01:00.0: DRM: DCB outp 01: 04000f72 00020010
Line 989: [ 2.383250] nouveau 0000:01:00.0: DRM: DCB outp 01: 04000f72 00020010
Line 990: [ 2.383417] nouveau 0000:01:00.0: DRM: DCB outp 02: 02811fa6 04420010
Line 990: [ 2.383417] nouveau 0000:01:00.0: DRM: DCB outp 02: 02811fa6 04420010
Line 991: [ 2.383579] nouveau 0000:01:00.0: DRM: DCB outp 03: 02011f62 00020010
Line 991: [ 2.383579] nouveau 0000:01:00.0: DRM: DCB outp 03: 02011f62 00020010
Line 992: [ 2.383743] nouveau 0000:01:00.0: DRM: DCB outp 04: 01822fd6 04420020
Line 992: [ 2.383743] nouveau 0000:01:00.0: DRM: DCB outp 04: 01822fd6 04420020
Line 993: [ 2.383905] nouveau 0000:01:00.0: DRM: DCB outp 05: 01022f92 00020020
Line 993: [ 2.383905] nouveau 0000:01:00.0: DRM: DCB outp 05: 01022f92 00020020
Line 994: [ 2.384068] nouveau 0000:01:00.0: DRM: DCB outp 06: 08833fc6 04420010
Line 994: [ 2.384068] nouveau 0000:01:00.0: DRM: DCB outp 06: 08833fc6 04420010
Line 995: [ 2.384232] nouveau 0000:01:00.0: DRM: DCB outp 07: 08033f82 00020010
Line 995: [ 2.384232] nouveau 0000:01:00.0: DRM: DCB outp 07: 08033f82 00020010
Line 996: [ 2.384422] nouveau 0000:01:00.0: DRM: DCB conn 00: 00020046
Line 996: [ 2.384422] nouveau 0000:01:00.0: DRM: DCB conn 00: 00020046
Line 997: [ 2.384583] nouveau 0000:01:00.0: DRM: DCB conn 01: 00010146
Line 997: [ 2.384583] nouveau 0000:01:00.0: DRM: DCB conn 01: 00010146
Line 998: [ 2.384745] nouveau 0000:01:00.0: DRM: DCB conn 02: 02000246
Line 998: [ 2.384745] nouveau 0000:01:00.0: DRM: DCB conn 02: 02000246
Line 999: [ 2.384906] nouveau 0000:01:00.0: DRM: DCB conn 03: 01000346
Line 999: [ 2.384906] nouveau 0000:01:00.0: DRM: DCB conn 03: 01000346
Line 1000: [ 2.404056] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Line 1001: [ 2.404226] [drm] Driver supports precise vblank timestamp query.
Line 1002: [ 2.483016] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
Line 1002: [ 2.483016] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
Line 1003: [ 2.516315] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 88
Line 1003: [ 2.516315] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 88
Line 1003: [ 2.516315] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 88
Line 1013: [ 2.683040] nouveau 0000:01:00.0: DRM: allocated 2560x1440 fb: 0x60000, bo ffff880440965400
Line 1013: [ 2.683040] nouveau 0000:01:00.0: DRM: allocated 2560x1440 fb: 0x60000, bo ffff880440965400
Line 1014: [ 2.683385] fbcon: nouveaufb (fb0) is primary device
Line 1016: [ 3.089721] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
Line 1016: [ 3.089721] nouveau 0000:01:00.0: fb0: nouveaufb frame buffer device
Line 1017: [ 3.092198] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
Line 1017: [ 3.092198] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
Line 1019: [ 3.361257] nouveau 0000:01:00.0: priv: HUB0: 10eb14 80000122 (18408231)
HeDamsja
commented
May 5, 2016
|
So, an update. Based on a suggestion from the nouveau folks, tried a more recent kernel. Fedora Core 23's 4.4.8-300, to be exact. Things work. DMesg output attached. Not sure if there's a way to backport 4.4.x's nouveau into Qubes' 4.1.x dmesg-4.4.8-300.fc23.x86_64.txt In kernel 4.1.x's output, there are "link training failed" messages, but in 4.4.x's, there are EDID checksum error messages instead. Wonder if 4.4.x's version simply handles ASUS' EDID brainfart better than 4.1.x?
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
May 5, 2016
Member
Once I have something more concrete than just stating the fact 'it's broke, yo', I'll gladly submit a PR against the docs. Unless I misunderstood what you're asking me to document (quite possible) - I'd be glad to submit a PR for something else as well.
I was just thinking that your workaround steps above might be useful to others, but if you'd prefer to wait until you have something more concrete, that would certainly be fine. Either way, your contribution is appreciated. :)
I was just thinking that your workaround steps above might be useful to others, but if you'd prefer to wait until you have something more concrete, that would certainly be fine. Either way, your contribution is appreciated. :) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
HeDamsja
May 5, 2016
@andrewdavidwong
I was just thinking that your workaround steps above might be useful to others, but if you'd prefer to wait until you have something more concrete, that would certainly be fine. Either way, your contribution is appreciated. :)
Fair enough :)
It seems like the work-around itself would belong in a troubleshooting or debug section, rather than a proper install section - it does not, after all, produce a usable system.
A (not the ) solution seems to be to have a text-only setup post-boot. One which would mirror the initial GUI. A pile of work to keep that in sync with the GUI-based one, AFAIK (could be wrong). Curiously, there were, in one of the install log console windows, messages scrolling indicating a failure of systemctl enable initial-setup-graphical.service and systemctl enable initial-setup-text.service, so it appears that some pieces of this sort of a thing are in place.
HeDamsja
commented
May 5, 2016
Fair enough :) A (not the ) solution seems to be to have a text-only setup post-boot. One which would mirror the initial GUI. A pile of work to keep that in sync with the GUI-based one, AFAIK (could be wrong). Curiously, there were, in one of the install log console windows, messages scrolling indicating a failure of |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
May 5, 2016
Member
It seems like the work-around itself would belong in a troubleshooting or debug section, rather than a proper install section - it does not, after all, produce a usable system.
TBH, the current Nvidia page is in need of a cleanup, so I don't think the addition of a helpful debugging section would detract from it in any way.
TBH, the current Nvidia page is in need of a cleanup, so I don't think the addition of a helpful debugging section would detract from it in any way. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
HeDamsja
May 5, 2016
@andrewdavidwong
TBH, the current Nvidia page is in need of a cleanup, so I don't think the addition of a helpful debugging section would detract from it in any way.
Fair enough. Will work on that PR.
Perhaps someone with more familiarity with Qubes' kernel selection process an weigh in on the possibility of pulling in the nouveau/drm bits from 4.4.8 branch (seems like less of an insane request than asking the kernel to be entirely upgraded to 4.4.8 )
HeDamsja
commented
May 5, 2016
Fair enough. Will work on that PR. Perhaps someone with more familiarity with Qubes' kernel selection process an weigh in on the possibility of pulling in the nouveau/drm bits from 4.4.8 branch (seems like less of an insane request than asking the kernel to be entirely upgraded to 4.4.8 ) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
May 6, 2016
Member
We're working on having 4.4 in Qubes 3.2.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
We're working on having 4.4 in Qubes 3.2. Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
HeDamsja
commented
May 6, 2016
|
@marmarek: Awesome. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
HeDamsja
commented
May 6, 2016
|
@marmarek: FWIW - I am volunteering to be a tester for R3.2 |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Watch #1807 - there will be links to test images. |
andrewdavidwong
referenced this issue
May 7, 2016
Closed
Errors (possibly spurious) during installation from 'systemctl enable' commands #1972
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
May 7, 2016
Member
@HeDamsja, we've merged your PR (thank you!). Is there any further reason to keep this issue open?
|
@HeDamsja, we've merged your PR (thank you!). Is there any further reason to keep this issue open? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
HeDamsja
commented
May 9, 2016
|
@andrewdavidwong: Fair point, closing :) |
HeDamsja commentedMay 4, 2016
Qubes OS version (e.g.,
R3.1): R3.1Expected behavior:
Frame Buffer console and/or X
Actual behavior:
Monitor goes into standby mode
Steps to reproduce the behavior:
Use an nVidia Quadro K1200 card.
General notes:
dmesg-qubes-3.1.txt
I do not believe that this is a Qubes-specific thing. Rather, it is an issue with nouveau and K1200 (and K2200). Filed a bug with nouveau. Hope this helps someone avoid frustration (until the bug is fixed)
The installation required the following gyrations: (probably didn't need to do some of them)
nomodeset ip=dhcp inst.nokill inst.vncto the kernel command linechrootto do this) - this is so that it'd be possible to log in at all.nomodesetfrom kernel boot linesleep 5m:)dmesg > dmesg.outnomodesetremainDMESG output (scraped for DRM or nouveau mentions)
Related issues:
Relevant labels:
nvidia nouveau quadro