[11:22] tseliot: ricotz: Last night I tried to package 361.28 for the PPA based on a diff between 361.18 and the 361.28 in NEW for Xenial, but I had a few questions. First, how long are packages stuck in NEW? Would it be worth it to re-upload 361.28 for Xenial in the PPA? [11:22] Second, I'm not quite sure how to handle Wily and Trusty. In the PPA, the packaging for Xenial and Wily was identical besides the EGL alternative stuff in Xenial. Should I upload the Xenial packaging for 361.28 to Wily (minus the EGL alternatives), should I base the Wily 361.28 off of the Wily 361.18, or should I backport some subset of the changes? [11:23] The packaging for Trusty had several differences between that of Wily and Xenial, so I am not sure what if any of the changes from 361.28 I should backport to that. [11:24] mamarley: as for NEW, that's anybody's guess. I pinged an admin [11:25] you can reuse the Xenial packaging (minus EGL) in Wily [11:25] OK, that's what I though. [11:26] s/though/thought [11:26] as for trusty, I think the same as Wily would work [11:27] Ah, OK, that makes things easier. Thanks! [11:27] * tseliot has just uploaded nvidia-settings in xenial [11:31] don't forget the substvars modifications [11:32] ricotz: I don't think I am familiar with that change? [11:32] for trusty to allow installation of the lts-xorg stacks [11:33] Ah, yes. OK, I will make sure to get those. [11:41] ricotz, mamarley: only the xorg-video-abi-$number is needed though [11:41] no need to depend on xserver-xorg-core-lts-* any more [11:42] Good afternoon! [11:43] tseliot: It already depends on one of xorg-video-abi 11 throught 20 in the Xenial packaging, so that will be sufficient? [11:43] mamarley: yes, I think so [11:43] Cool, thanks! [12:56] ricotz: I have uploaded 361.28 to https://launchpad.net/~mamarley/+archive/ubuntu/staging/+packages. [12:57] "nvidia-graphics-drivers-361 - 361.28-0ubuntu1+gpu16.04.1" <- NO [12:58] the official upload should/must override it [12:58] OK. [12:59] Oops, I actually didn't mean to use a + there. [13:07] ricotz: Are Wily and Trusty OK? I can re-upload Xenial with a ~. [13:15] mamarley, I don't like to have the 352 transitionals just yet [13:16] so for any 361 upload those should not be there [13:22] ricotz: OK, I will cut those out. Anything else? [13:23] mamarley, that should be it [13:24] tseliot, btw, I really don't like you starting a new changelog with every new series, the packaging doesn't appear out of thin air ;P [13:42] ricotz: Should I leave the transitionals in for Xenial since the official package with transitionals will override ours anyway? [13:43] mamarley, no, otherwise the ppa packages of 352 are gone with them [13:44] ricotz: OK [13:44] ricotz: well, it's really a new source package though ;) [13:45] tseliot, still, you know what I mean [13:45] I do [13:47] I keep track of all the changes in git, so I really don't need the changelogs to remind myself of what I included (from previous releases) in the packaging [14:08] ricotz: Do you mind if I upload the fixed packages straight to gpu-drivers or should I make another temporary staging PPA for that? [14:20] mamarley, if you are sure you got it right [14:21] For Xenial, I replaced the + with a ~ in the version. For everything, I removed the 352-related stuff from the control.in template. [14:23] mamarley, alright, double-check and upload ;) [14:24] * mamarley nervously quadruple-checks his work. [14:35] ricotz: OK, it is all uploaded. I even checked after running debuild -S -sd to make sure the 352 stuff was gone from the generated control file before uploading. :) [15:20] soee: 361.28 is ready for testing. Please use the version from the gpu-drivers PPA and not the one from my staging PPA. (I hope you disable that when you aren't actively testing something?) [15:20] mamarley: i have drivers ppa always enabled :) [15:25] mamarley, clear your ppa? [15:25] ricotz: D'oh, yes, I should do that. [15:27] updating now [15:46] marlinc: can you reproduce the problem and show me your dmesg and X log, please? [15:47] Any specific things I should enable first? Should I use the PPA? [15:55] marlinc: was the problem there after enabling the PPA? [15:55] I'm talking about the last problem you mentioned yesterday [16:03] I'm sorry tseliot, lost my connection to the bouncer [16:05] marlinc: I was already away yesterday, and you pinged me about a problem with hybrid graphics that maybe involved the PPA. Whatever the last problem you ran into was, I would like to see those two files, and possibly the output of a command [16:07] Okay, tjaalton asked me to try the PPA. Then I ran into issues where LightDM wouldn't start [16:07] One moment [16:13] I'm starting using the PPA now tseliot [16:13] ok [16:13] new driver works fine :) [16:15] Okay, so yesterday we commented everything in /usr/share/lightdm/lightdm.conf.d/90-nvidia.conf as LightDM was crashing when I switched to the NVIDIA driver using prime-select [16:16] Currently that's causing a black screen with the following errors in the greeter log https://gist.github.com/anonymous/1f8d9e00474afbf209b8 [16:16] hmm, mamarley ping [16:16] pong [16:17] mamarley: steam now yields this: http://wstaw.org/m/2016/02/11/snapshot65.png [16:17] I see there's a ton of updates, I'll install those to make sure I'm not missing any fixes [16:18] Including ZFS, nice [16:18] soee: I'm not where I can look at that. Can you give a quick description? [16:18] marlinc: I see a lot of errors but none specific to nvidia [16:19] mamarley: Could not find required OneGL entry point 'glGetError'! Either your video card is unsupported, or your OpenGL driver needs to be updated. [16:19] LightDM runs a X server right? Is there a way to look at what its doign? [16:19] Doing* [16:20] marlinc: /var/log/lightdm/ has the different logs [16:21] One moment, I'll reboot the server. Got a kernel update [16:22] Reboot the laptop* [16:23] Okay, I've removed all the logs and restarted LightDM [16:24] soee: This is new for 361.28? [16:24] mamarley: i think so. never seen it before [16:25] These are all the logs tseliot https://gist.github.com/anonymous/24846fdffb2cc60f1935 [16:25] I'll post dmesg as well [16:26] And this is dmesg tseliot https://gist.github.com/anonymous/ade956eeec744021417f [16:27] I don't see it execute the script for prime... [16:27] Ah, yes tjaalton and I disabled that to debug [16:27] I'll re enable it and post some new logs [16:28] ok [16:29] The logs might be confusing as LightDM keeps restarting, or rather the X server that LightDM uses I think. Will post the logs now [16:30] There you go tseliot https://gist.github.com/anonymous/c30e9500c63007c82ba0 [16:32] marlinc: the greeter got an error from X, and died [16:32] I guess that makes sense, unity-greeter crashes which causes the X server to shutdown. And then LightDM tries to start the X server again [16:33] Anything else I can do to get more information on the issue [16:34] maybe it's a problem with the modesetting driver. Try booting with either gpumanager_uxa or gpumanager_sna, and see which one works [16:35] (kernel parameters) [16:35] Will do [16:37] tjaalton: I should probably test the PPA myself with hybrid graphics [16:37] just in case... [16:37] Okay, uxa doesn't work. Will test sna now [16:37] Same greeter errors [16:37] ok [16:38] hmm, my old laptop has i+n.. will steal it from the wife and upgrade it to x [16:39] that would be a good idea... don't tell your wife though :P [16:40] Okay now sure if this is better or worse. With sna its just starting X and nothing else [16:40] Fatal server error: [16:40] (EE) Failed to recover from error! [16:41] This is it https://gist.github.com/anonymous/8c5421e8510189a57361 [16:41] And the two lines I pasted above are what's in the X log [16:41] tseliot: it was still on vivid, so about time I upgraded it [16:42] right ;) [16:43] marlinc: ok, so sna is not expected to work (they broke it in the previous release cycle). If uxa doesn't work though, then something else is going on [16:43] but I can't see what from the logs [16:44] calling xrandr likely causes the issue [16:44] are you doing this while the external screen is connected? [16:46] Yes, I'll disconnect it and restart LightDM. But I guess I first have to boot over to either uxa or a regular boot [16:46] But I'm back in about 20-30 minutes have to eat, thanks! [16:47] regular boot would be fine [16:48] ok [17:01] Okay back tseliot [17:03] ok [17:03] A single screen crashes as well tseliot [17:04] Same greeter error [17:05] marlinc: and it doesn't crash if you comment out the nvidia script? [17:05] Then the screen just stays black [17:05] Wait let me check to be sure [17:06] Yep stays black [17:06] marlinc: if the screen stays black, you can try to log in blindly. Just type in your password and press enter, after your hear the drums. Then ssh into the computer [17:07] I need you to run a command after that [17:07] I can try logging in, I'm already logged in SSH if that helps [17:07] Via SSH* [17:08] Lets see what the log says if I try to login [17:08] marlinc: the thing is you need to login from the greeter or the command will fail [17:08] this is the command: DISPLAY=:0 xrandr --listproviders [17:09] Ah, you need a active X server. I should be able to run that now [17:09] Providers: number : 0 [17:10] did you log in from the black screen? [17:10] I did [17:10] I can see that I logged in as the LightDM shows that [17:10] Let me gist it [17:10] both intel and nvidia should show up there [17:11] https://gist.github.com/anonymous/e8b91e4ccc411f3ed65f [17:12] right I can see that [17:12] tjaalton: randr 1.4 support is broken ^^ [17:12] no wonder X dies [17:13] I can see that I logged in as the LightDM log shows that [17:13] that'd be surprising [17:13] I have typing problems at the moment :p [17:13] marlinc: what does /var/log/gpu-manager.log say? [17:14] Let me try something, I'll switch to intel using prime-select and see what happens [17:14] Okay [17:14] https://gist.github.com/anonymous/881c50c143a2315f5f59 [17:14] There you go [17:16] Just tried starting by switching to intel using 'prime-select'. That does work and show LightDM [17:17] Switched back to NVIDIA which has the problems we're looking at [17:17] can you try this command again after switching to intel, please? DISPLAY=:0 xrandr --listproviders [17:17] the log looks fine BTW [17:18] Sure [17:19] marlinc@marlinc-laptop:~$ DISPLAY=:0 xrandr --listproviders [17:19] Providers: number : 0 [17:19] Btw the actual session, works just fine when I log in using intel [17:20] tjaalton: that is wrong ^ [17:20] Ah that explains it, it started on another display number [17:20] Its 1 now [17:20] marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders [17:20] Providers: number : 1 [17:20] Provider 0: id: 0x47 cap: 0x9, Source Output, Sink Offload crtcs: 4 outputs: 4 associated providers: 0 name:Intel [17:20] oh [17:20] maybe try again with nvidia then on display 1 [17:20] Okay, will do [17:21] remember to log in [17:21] Progress: [ 39%] [17:21] getting there [17:21] :) [17:21] Ah, there you go [17:21] marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders [17:21] Providers: number : 2 [17:21] Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-0 [17:21] Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 0 name:modesetting [17:21] ok, that looks much better [17:22] Not sure what display 0 is [17:22] I can even get GLX info [17:22] OpenGL renderer string: GeForce 840M/PCIe/SSE2 [17:22] OpenGL core profile version string: 4.5.0 NVIDIA 352.63 [17:22] OpenGL core profile shading language version string: 4.50 NVIDIA [17:23] I guess that this could make sense? [17:23] marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr [17:23] Screen 0: minimum 8 x 8, current 640 x 480, maximum 16384 x 16384 [17:23] Its supposed to show a VGA, HDMI and internal connection [17:23] yes, it's just that attaching the outputs to nvidia causes X to crash [17:24] Ah [17:24] once attached you will see the outputs [17:25] What does prime-offload do? When I run DISPLAY=:1 sudo prime-offload it actually gets the outputs and doesn't crash [17:25] maybe try crashing X yourself. I'll give you the command [17:25] so maybe this time we get the error in the log [17:28] Shall I first restart the LightDM so that the session in which I did prime-offload is closed? [17:28] isn't that a different X? [17:28] it shouldn't really matter [17:29] Okay ;) [17:29] DISPLAY=:1 xrandr --setprovideroutputsource modesetting NVIDIA-0 [17:29] That didn't do much [17:30] meaning? [17:30] what does this say? DISPLAY=:1 xrandr --listproviders [17:30] marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders [17:30] Providers: number : 3 [17:30] Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 1 name:NVIDIA-0 [17:30] Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting [17:30] Provider 2: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting [17:31] err... [17:31] Wait, let me restart the session so its clean. The fact that I ran prime-offload might have done something [17:31] ok [17:32] So that's clean again [17:32] marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders [17:32] Providers: number : 2 [17:32] Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 0 name:NVIDIA-0 [17:32] Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 0 name:modesetting [17:32] After I ran your command I got the same [17:32] marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders [17:32] Providers: number : 3 [17:32] Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 1 name:NVIDIA-0 [17:32] Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting [17:32] Provider 2: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting [17:33] it looks like a bug [17:34] try running prime-offload manually [17:34] Just 'DISPLAY=:1 sudo prime-offload'> [17:34] Just 'DISPLAY=:1 sudo prime-offload'? [17:34] yes [17:35] Okay, once again I got somewhat of an image [17:35] Might have to make a picture [17:35] DISPLAY=:1 xrandr --listproviders [17:36] marlinc@marlinc-laptop:~$ DISPLAY=:1 xrandr --listproviders [17:36] Providers: number : 3 [17:36] Provider 0: id: 0x204 cap: 0x1, Source Output crtcs: 0 outputs: 0 associated providers: 1 name:NVIDIA-0 [17:36] Provider 1: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting [17:36] Provider 2: id: 0x45 cap: 0x2, Sink Output crtcs: 3 outputs: 3 associated providers: 1 name:modesetting [17:36] hmm... [17:36] https://lh3.googleusercontent.com/cvbNSL8LTfSSHrOodsAoEZiX09S_pw2VPEI5d9Jzh7mPJffgdS2cclFBgqaI0g5ZK_OKcpI8-2xjX-KsR8Gj1jkwcNywsfbvmgmEuowYeAS3kj6_MSOnGWP5N4aHp5gtmx3pNmgnMv5wCsUMqfAL0ywrfdc2avJfnSXgA_YfMWc9KaytTsXJV61sCp66lBhtu-02ehQejFe7C11ksKrBHnkXT1E5j3hUd6rSmAyMdxQUJPL2XFgVj2nxrmxL4YR4VFSTMu6y3lxwPwNvL-B7n1lzyEYbnwsglsASdP4RiHiz-REn1h454jtkPNQNXSipB6KaBVllF3sPzSq5dtP8_dVgJa5rMoSCXISBBeXEUGh1BBG6Uo2ywYVi4nipNqoxcDxAOQHFBBa7rNco8h6c8kycustrS4_7 [17:36] Z0vYVHE91zLY6NRekqu60MiXiLqo7uANLLGxuABCbtKNctJ0w9EIB9ppEZQoR7PEfi-xE0OM75TC2XeOrvzCDFXYb0SOWS_MJ0jCMFIiJnaaBXkLYcdgPDSbp-Pty7LUonDsQg15pZDPdprbaTF8ajhYnXhlNmwGC7jn-Q=w940-h705-no [17:36] tinyurl [17:36] https://goo.gl/MP1mEv [17:37] multiple screens within the same screen [17:37] Now it out of nowhere started to show https://goo.gl/PpJWId [17:38] maybe try removing your ~/.monitors.xml [17:38] https://gist.github.com/anonymous/1db59dd738a71bcf281d is the general xrandr output [17:39] Removed it [17:39] so that kind of worked [17:39] try simply restarting [17:39] (no external screen plugged in) [17:40] Okay, I reran all the commands, LightDM restart, --setprovideroutputsource, prime-offload. Same result as the first picture [17:40] It will probably in a minute switch to the second picture [17:41] Now I got https://goo.gl/Vbp0tT instead of the other picture [17:42] the bug must be in the open drivers [17:42] And now it again switched to the second picture I posted [17:42] But with a second system error pop up [17:42] I'm using the nvidia-352 driver [17:43] And the regular Intel driver that you get out of the box [17:43] can you try adding a "sleep 2" in prime-offload and before this line, please? # Remove any previous logs [17:43] then restart lightdm [17:43] Sure [17:44] BTW it's beyond EOD for me. We can continue tomorrow [17:45] No change at all [17:45] Okay, I'll reboot to my regular install without the PPA [17:45] Thanks a lot [17:59] tseliot: Do you get the emails sent to the graphics drivers PPA team? We just got an email reporting the same issue soee reported earlier about Source engine games not running on 361.28. I think something might be out-of-whack with the libraries. [18:00] mamarley: i tried also reinstalling steam, but with no luck [18:01] tseliot: Maybe we need to extract the .run files with "--glvnd-glx-client"? [18:02] * mamarley doesn't actually have Steam on his system. [18:08] mamarley, one reason not to force an update with transitionals ;) [18:08] ricotz: Indeed, but both of these people upgraded manually. [18:09] mamarley, so if needed they can simply switch back in the meantime until this gets settled [18:30] Hmm, the --glvnd-glx-client argument has no effect when -x is used... [18:31] Because all the libraries are extracted, not just the GLVND or non-GLVND ones. [18:32] But when installed, the libraries are set up exactly the way https://devtalk.nvidia.com/default/topic/915640/unix-graphics-announcements-and-news/multiple-glx-client-libraries-in-the-nvidia-linux-driver-installer-package/ recommends... [18:44] Hmm, after reading https://devtalk.nvidia.com/default/topic/915789/-solved-361-28-gtx-580, it appears that the arch people only got it to work by switching to the non-GLVND libraries. In other words, this appears to be an upstream regression between 361.18 and 361.28 and not a packaging error on anyone's part. [18:44] soee: ^ [18:45] mamarley: i see, so we have to wait or next release :) [18:45] tseliot: If you have a contact at NVIDIA, it might be worth mentioning that. [20:18] mamarley: ok, I'll do that tomorrow. Thanks [20:18] * tseliot -> off