[06:29]  * alkisg got access to one of the schools with black screens, let's see... i5-6400, HD Graphics 530 [8086:1912] (rev 06)
[06:30] <alkisg> Updating from ppa: libegl-mesa0 libegl1-mesa libgbm1 libgl1-mesa-dri libgl1-mesa-glx  libglapi-mesa libglx-mesa0 libosmesa6 libwayland-egl1-mesa libxatracker2  mesa-va-drivers mesa-vdpau-driver
[07:13] <alkisg> tjaalton: sorry for the direct ping; I updated to the mesa from the PPA, and lightdm still fails. Anything else I can try? Any logs to keep, while the server is booted without nomodeset?
[07:14] <tjaalton> boot an earlier kernel
[07:15] <alkisg> .44 or .29?
[07:15]  * alkisg tries with this first: vmlinuz-4.15.0-44-generic
[07:15] <tjaalton> -44 is broken
[07:15] <alkisg> OK, 29 then, from the repositories
[07:15] <alkisg> 4.15.0.20.23 500
[07:16] <alkisg> Sorry I meant that one, that is available from the stock repositories
[07:16] <tjaalton> that's the metapackage
[07:16] <alkisg> apt install linux-image-4.15.0-20-generic linux-modules-4.15.0-20-generic linux-modules-extra-4.15.0-20-generic
[07:16] <tjaalton> that should do it
[07:23] <alkisg> GRUB_DEFAULT='gnulinux-advanced-00d0b350-2f42-4574-8abe-b53ede7da033>gnulinux-4.15.0-20-generic-advanced-00d0b350-2f42-4574-8abe-b53ede7da033'; update-grub; reboot
[07:25] <alkisg> tjaalton: the same. `uname -r` = 4.15.0-20-generic, gput-manager, lightdm ==> failed
[07:26] <alkisg> Xorg.log reports success even though it fails: https://termbin.com/6l2b
[07:26] <alkisg> Plain `xinit` reports: i965: Failed to submit batchbuffer: Invalid argument
[07:26] <tjaalton> downgrade mesa then
[07:27] <alkisg> I'll need a bit of help on that, which packages does it involve, any handy commands? Trying...
[07:27] <tjaalton> you just mentioned the list of packages that got updated..
[07:27] <tjaalton> apt install foo=ver
[07:27] <alkisg> That was the updates from the ppa, not the whole list
[07:28] <alkisg> echo $(dpkg -l '*mesa*' | awk '/^ii/ { print $2 }')
[07:28] <alkisg> libegl-mesa0:i386 libegl1-mesa:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libglx-mesa0:i386 libosmesa6:i386 libwayland-egl1-mesa:i386 mesa-utils mesa-va-drivers:i386 mesa-vdpau-drivers:i386
[07:28] <tjaalton> apt-cache policy libgl1-mesa-dri for instance will show that the original version is still there
[07:28] <alkisg> Are those enough, to downgrade?
[07:28] <tjaalton> maybe, and it'll complain if there are more dependencies
[07:28] <alkisg> Ty, trying
[07:28] <alkisg> I'll try 18.0.0~rc5-1ubuntu1
[07:29] <tjaalton> that's what main has
[07:29] <tjaalton> and bionic shipped with
[07:29] <alkisg> I have those available: 18.2.8-0ubuntu0~18.04.1~ppa1,  18.2.2-0ubuntu1~18.04.1, 18.0.0~rc5-1ubuntu1
[07:29] <alkisg> Which one should I try? I think the first 2 failed
[07:30] <tjaalton> the last
[07:30] <alkisg> So I guess, try with the stock bionic? Yup.
[07:36] <alkisg> apt install libegl-mesa0:i386=18.0.0~rc5-1ubuntu1 libegl1-mesa:i386=18.0.0~rc5-1ubuntu1 libgl1-mesa-dri:i386=18.0.0~rc5-1ubuntu1 libgl1-mesa-glx:i386=18.0.0~rc5-1ubuntu1 libglapi-mesa:i386=18.0.0~rc5-1ubuntu1 libglx-mesa0:i386=18.0.0~rc5-1ubuntu1 libosmesa6:i386=18.0.0~rc5-1ubuntu1 libwayland-egl1-mesa:i386=18.0.0~rc5-1ubuntu1 mesa-va-drivers:i386=18.0.0~rc5-1ubuntu1 mesa-vdpau-drivers:i386=18.0.0~rc5-1ubuntu1 libgbm1=18.0.0~rc5-1ubunt
[07:36] <alkisg> u1 libegl1-mesa=18.0.0~rc5-1ubuntu1 libegl1=1.0.0-2ubuntu2 libglvnd0=1.0.0-2ubuntu2 libgl1-mesa-glx=18.0.0~rc5-1ubuntu1 libgl1=1.0.0-2ubuntu2 libglx0=1.0.0-2ubuntu2
[07:36] <alkisg> ...a long list there, probably cut by irc :D
[07:36] <tjaalton> why would it want to downgrade libegl1 et al
[07:37] <alkisg> Version mismatches
[07:37] <tjaalton> huh?
[07:37] <tjaalton> ah ok
[07:37] <tjaalton> nevermind
[07:37] <tjaalton> doesn't matter
[07:37] <alkisg> I build all this list slowly, because each one complained about some other package version mismatch,
[07:37] <alkisg> now it wants to remove vlc and kio etc, but I don't know how else to do it
[07:39] <alkisg> The following packages will be REMOVED:  kinit kio kolourpaint libgles2 libkf5kdelibs4support5  libkf5kdelibs4support5-bin libkf5notifications5 libkf5parts-plugins  libkf5parts5 libkf5sane5 libkf5wallet-bin libkf5wallet5 libkwalletbackend5-5   libwayland-egl1 phonon4qt5 phonon4qt5-backend-vlc vlc   vlc-plugin-video-output
[07:39] <alkisg> I can put them back on after we test, shall I continue?
[07:40] <tjaalton> downgrade wayland
[07:40] <tjaalton> too
[07:41] <alkisg> They're using MATE, so I hope it won't even load wayland
[07:41] <tjaalton> and libgles2
[07:42] <alkisg> apt install libgles2=1.0.0-2ubuntu2 ; reboot
[07:44] <alkisg> tjaalton: that worked
[07:44] <tjaalton> downgrade fixed it?
[07:44] <alkisg> Yes
[07:44] <tjaalton> ok, file a bug upstream and on lp
[07:45] <alkisg> Thank you, doing so
[07:45] <tjaalton> wondering if it's lightdm which is triggering it
[07:46] <alkisg> Maybe MATE as well
[07:46] <alkisg> But plain xinit doesn't work either
[07:46] <alkisg> I.e. it's possible that ubuntu gnome users don't even see that, I don't know
[07:46] <tjaalton> how did you run xinit if it didn't have any display?
[07:46] <alkisg> From something like ssh
[07:47] <alkisg> (epoptes, remote control)
[07:47] <tjaalton> k
[07:48] <tjaalton> does xubuntu use the same bits?
[07:49] <tjaalton> probably not
[07:49] <alkisg> Unfortunately I don't have a hardware that fails locally, and it's very hard to test other distros than mate remotely
[07:49] <alkisg> I'll try to find some affected hardware tomorrow
[07:50] <tjaalton> ubuntu mate
[07:50] <tjaalton> I'll try that on snb
[07:50] <alkisg> I file it in https://bugs.freedesktop.org/enter_bug.cgi under Drivers/DRI/i915? It warns "that's the old driver"
[07:50] <tjaalton> i965
[07:50] <alkisg> Ty
[07:51] <tjaalton> unless it's migrated to gitlab, not sure
[07:51] <alkisg> They also have a 18.3 there, can I try that in Ubuntu?
[07:51] <alkisg> xorg-edgers or something?
[07:53] <tjaalton> I can push that to x-swat updates
[07:58] <alkisg> lspci => 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:1912] (rev 06) 	Subsystem: ASUSTeK Computer Inc. HD Graphics 530 [1043:8694] 	Kernel modules: i915
[07:58] <tjaalton> does dmesg have anything btw?
[07:58] <tjaalton> it's sandybridge
[07:58] <alkisg> tjaalton: i915?
[07:58] <tjaalton> yes
[07:59] <alkisg> And I should report it under i965?
[07:59] <tjaalton> the dri driver is i965
[07:59] <alkisg> ty
[07:59] <alkisg> dmesg is clean
[07:59] <alkisg> https://termbin.com/ip4e
[08:00] <tjaalton> hmm
[08:01] <tjaalton> it's skylake actually
[08:01] <alkisg> A mail was just sent to ltsp-discuss, "black screen on cinnamon"
[08:01] <alkisg> I think they're using lightdm too
[08:03] <tjaalton> k
[08:04] <alkisg> https://bugs.freedesktop.org/show_bug.cgi?id=109583
[08:04] <ubottu> Freedesktop bug 109583 in Drivers/DRI/i965 "Black screen on skylake after 18.0 => 18.2 update" [Normal,New]
[08:04] <alkisg> Filing in launchpad now...
[08:05] <tjaalton> check lightdm logs btw
[08:05] <tjaalton> if they have the same error
[08:06] <alkisg> I don't think systemd even starts lightdm as it depends on gpu-manager
[08:06] <alkisg> Ah, I can try restarting gpu-manager, I think that allows systemd to start lightdm and let it fail there..
[08:06] <tjaalton> so how does it fail then?
[08:07] <tjaalton> and what's failing..
[08:08] <tjaalton> so you're running 32bit on skylake?
[08:08] <alkisg> gpu-manager, with some error message about not able to initialize the cards etc
[08:08] <alkisg> Yes. Hmm, I'll try to see if 64bit installations are affected
[08:09] <alkisg> Let me update mesa so that I see the errors again
[08:09] <tjaalton> just run full dist-upgrade
[08:09] <alkisg> Yeah that's the easy one :)
[08:10] <alkisg> Launchpad bug: https://bugs.launchpad.net/mesa/+bug/1815172
[08:10] <ubottu> Launchpad bug 1815172 in mesa (Ubuntu) "Black screen on skylake after 18.0 => 18.2 update" [Undecided,New]
[08:10] <tjaalton> great
[08:15] <tjaalton> i wonder if that xinit is doing the right thing, or if it's trying to use remote x somehow
[08:15] <alkisg> tjaalton: nah I use it a lot of times, it works great for troubleshooting
[08:15] <tjaalton> ok then
[08:15] <alkisg> I can even get remote access after that, I know that step
[08:15] <alkisg> *remote xorg, with vnc
[08:16] <alkisg> systemctl status gpu-manager: https://termbin.com/kkix
[08:16] <tjaalton> 18.3.3 test build on cosmic fine, now bionic
[08:16] <alkisg> Thanks
[08:17] <alkisg> gidarakos: could you tell the school to leave the server open for the whole weekend?
[08:17] <alkisg> *running
[08:17] <tjaalton> tseliot: ^
[08:17] <tjaalton> tseliot: the gpu-manager error
[08:17] <alkisg> systemctl status lightdm: https://termbin.com/ybev
[08:18] <tjaalton> check it's logs then
[08:18] <tjaalton> tseliot: probably nothing
[08:20] <alkisg> Clean lightdm.log, after doing: systemctl start gpu-manager; systemctl start lightdm: https://termbin.com/ssrb
[08:20] <alkisg> gpu-manager runs for a bit, and allows the lightdm service to run without dependency issues, then enter the failed state
[08:20] <tjaalton> then look at the x log
[08:20] <tjaalton> [+0.18s] DEBUG: XServer 0: X server stopped
[08:21] <tjaalton> it was respawning every 0.2s
[08:21] <alkisg> Last xorg.log: https://termbin.com/92rx
[08:21] <tjaalton> huh
[08:22] <alkisg> I never see any issues in xorg log in these tests
[08:22] <tjaalton> so it's a client crashing that takes the server down without leaving a trace in the log
[08:22] <tjaalton> enable apport, check /var/crash
[08:23] <alkisg> Isn't xinit a simpler test there?
[08:23] <tjaalton> maybe
[08:23] <alkisg> As it doesn't involve lightdm and anything?
[08:24] <alkisg> xinit again gives a clean xorg.log, with just this in stderr: i965: Failed to submit batchbuffer: Invalid argument | xinit: giving up | xinit: unable to connect to X server: Connection refused | xinit: server error
[08:24] <tjaalton> ok
[08:25] <alkisg> Apport is enabled afaik, but nothing in /var/crash
[08:25] <alkisg> https://wiki.ubuntu.com/Apport#How_to_enable_apport
[08:26] <tjaalton> alright
[08:29] <tjaalton> uploaded 18.3.3 to ppa:ubuntu-x-swat/updates
[08:29] <alkisg> Ty, adding...
[08:30] <tjaalton> not built yet
[08:31] <gidarakos> alkisg: Ok, I'll ask for it and I'll let you know..
[08:31] <alkisg> 18.2.8-0ubuntu0~18.04.1~ppa1 500 for now, waiting
[08:31] <alkisg> Thank gidarakos
[08:33] <gidarakos> alkisg: you are welcome! :)
[08:47] <alkisg> Another school that has the issue, said: 64bit installation, Intel Corporation HD Graphics 530 [8086:1912] (rev 06)   Subsystem: Dell HD Graphics 530 [1028:06b7]
[08:47] <alkisg> So fortunately it doesn't just happen on 32bit systems :)
[08:47] <tjaalton> k
[09:06] <alkisg> Upgrading to 18.3..
[09:08] <alkisg> Same issue
[09:10] <tjaalton> cool
[09:10] <tjaalton> no need to bisect
[09:11] <alkisg> Eh, unless we end up needing to bisect between 18.0 and 18.2, to pinpoint the issue :D
[09:11] <tjaalton> nah
[09:12] <tjaalton> what does xinit try to run, btw?
[09:12] <alkisg> tjaalton: would it make sense to try with a -hwe kernel, something newer than 4.15?
[09:12] <alkisg> xinit runs xterm
[09:12] <tjaalton> k
[09:12] <alkisg> When not provided any params
[09:13] <tjaalton> right
[09:33] <tseliot> tjaalton: is that a hybrid system?
[09:33] <tjaalton> no
[09:34] <alkisg> Debug log: https://termbin.com/6n12
[09:34] <tseliot> then I doubt the error is fatal
[09:34] <alkisg> After: echo 0xf > /sys/module/drm/parameters/debug; xinit; dmesg
[09:34] <tjaalton> right, it didn't prevent lightdm from starting
[09:44] <tjaalton> alkisg: chris (ickle) is also on #intel-3d
[09:57] <tjaalton> hum, should ubuntu mate support efi boot?
[09:58] <tjaalton> probably not
[09:58] <tjaalton> doesn't have an EFI dir
[10:00] <tjaalton> trying it on a kabylake
[10:02] <tjaalton> seems to hang
[10:05] <tjaalton> hmm no, it was probably respawning the desktop and didn't accept any input other than power button
[10:07] <tjaalton> yep, works with nomodesest
[10:07] <tjaalton> -set
[10:11] <tjaalton> oh right, 32bit doesn't support efi..
[10:17] <tjaalton> alkisg: try with the hwe kernel
[10:19] <tjaalton> linux-image-4.18.0-14-generic
[10:19] <tjaalton> and the modules
[10:27] <tjaalton> alkisg: try the kernel from proposed
[10:28] <tjaalton> alkisg: nevermind
[10:28] <tjaalton> but try hwe kernel
[10:41] <tjaalton> 64bit daily image seems to work fine here
[11:03] <tjaalton> alkisg: I'm running 64bit mate with stock bionic kernel & X and things work fine :/
[11:23] <alkisg> Back
[11:24] <alkisg> tjaalton: AFAIK all ubuntu CDs have the EFI dir, but in the fat special file system, not in the iso9xx noe
[11:24] <alkisg> *one
[11:24] <alkisg> I do have MATE installed under EFI
[11:24] <alkisg> Ah 32 bit, ok, yeah
[11:24]  * alkisg tries with -hwe
[11:26] <alkisg> apt install linux-generic-hwe-18.04
[11:27] <tjaalton> I'll install 32bit version next
[11:28] <alkisg> tjaalton: Does it run with 4.15 for you?
[11:28] <tjaalton> 64bit did
[11:28] <alkisg> Which card, the same as the schools?
[11:28] <tjaalton> kabylake, same gen9 as skylake
[11:29] <alkisg> Maybe it depends on the specific model?
[11:29] <alkisg> Rebooting with 4.18...
[11:31] <alkisg> 4.18.0-14-generic => failed
[11:31] <tjaalton> k
[11:32] <tjaalton> skl gt2 is pretty much the same as kbl gt2, which this is
[11:33] <alkisg> A school did report failure with their 64bit installation, so I don't know what  to say
[11:33] <tjaalton> could be something else
[11:44] <tjaalton> meh, installing 32bit messed up grub/efi
[12:08] <alkisg> Do you get the rescue prompt?
[12:11] <tjaalton> yes
[12:11] <alkisg> set root=(hd0,gpt1)
[12:11] <alkisg> configfile /boot/grub/grub.cfg
[12:11] <alkisg> I think this should work...
[12:11] <alkisg> Point it to your 64bit instalaltion
[12:11] <alkisg> After it boots, run grub-install /dev/sda
[12:12] <tjaalton> so what after configfile?
[12:12] <tjaalton> it just clears the screen
[12:13] <alkisg> Ouch, it should have displayed the grub menu
[12:13] <alkisg> set root=(hd0,gpt  ==> tab there for autocompletion
[12:13] <alkisg> If you installed in 2 partitions, select the other one
[12:14] <tjaalton> nah
[12:15] <alkisg> Eh, then manually load linux/initrd
[12:15] <alkisg> linux /boot/vmlinuz root=/dev/sda1
[12:15] <alkisg> initrd /boot/initrd.img
[12:15] <alkisg> boot
[12:15] <alkisg> And if grub.cfg was empty,you'll need `update-grub` as well, to generate a proper one
[12:16] <tjaalton> i'll just fix it from a live session
[12:26] <tjaalton> ha, was able to boot the 32bit install after all, and it works fine
[12:39] <alkisg> Another affected school has a slightly different card: 
[12:39] <alkisg>  root@pc02:~# lspci -nn -k | grep -A 2 VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 [8086:5912] (rev 04)         Subsystem: ASRock Incorporation HD Graphics 630 [1849:5912]         Kernel driver in use: i915
[12:44] <tjaalton> that's kbl gt2, which I have
[12:45] <alkisg> Hrm. Stranger and stranger.
[13:04] <alkisg> Should I mention in the bug report that we're using modesetting instead of the intel driver? (the Ubuntu defaults)
[13:04] <tjaalton> no
[13:04] <tjaalton> it's seen on the X log
[13:04] <alkisg> OK, ty
[13:22] <alkisg> tjaalton: you can boot an efi installation from grub-rescue-cd, by typing that "configfile" command above, if you feel like spending the time to test that...
[13:54] <tjaalton> yeah I fixed it already
[14:16]  * alkisg tests with linux-image-4.20.7-042007-generic_4.20.7-042007.201902061234_i386.deb ...
[14:18] <tjaalton> oh right, I was about to push mesa 19.0rc2 somewhere..
[14:20] <alkisg> They're asking me for the output of `/usr/bin/glxinfo -B`, how should I provide that, with nomodeset or with AccelMethod=none?
[14:20] <alkisg> I don't have a display without those, and I guess no glx in either case?
[14:21] <tjaalton> you should probably get the hw on your desk
[14:21] <tjaalton> otherwise it'll be painful
[14:21] <tjaalton> as it is
[14:22] <alkisg> I only have one so far in my city, and it's the school  server... I'll see if I can replace the server with something else, and keep the disk maybe...
[14:22] <alkisg> The others are in other cities
[14:24] <tjaalton> you don't have skylake?
[14:25] <tjaalton> I guess legacy bios is the key
[14:25] <tjaalton> but I can't wipe my machines
[14:25] <alkisg> I only have this in my office: 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
[14:25] <tjaalton> these machines
[14:25] <alkisg> Wait, I think it works fine with 4.20
[14:25] <alkisg> Let me reboot without xorg.conf...
[14:26] <tjaalton> that's a haswell
[14:26] <tjaalton> gen7 gpu
[14:26] <alkisg> I don't have anything more recent here :(
[14:26] <alkisg> But I tried 4.20 in the remote school, and I think it works, I'll be sure after the reboot
[14:26] <tjaalton> cool
[14:26] <alkisg> Not sure how that will help us for a "real" solution, but it's surely progress
[14:28] <alkisg> Yup, it seems to work ifne
[14:28] <alkisg> fine
[14:29] <tjaalton> it's a kernel bug then
[14:30] <tjaalton> fixed between 4.18..4.20
[14:30] <tjaalton> ickle might have ideas.. post to the upstream bug
[14:30] <tjaalton> looking at changes to i915_gem_execbuffer.c gives some hints
[14:32] <alkisg> So, mesa=18.0 works, mesa=18.2 breaks, yet it's a kernel issue? :D
[14:32] <alkisg> Meh these programmers! :P
[14:32]  * alkisg has been a programmer / sysadmin for 25 years now...
[14:35] <tjaalton> needs a newer kernel :)
[14:50] <tjaalton> alkisg: you could bisect the kernel by using mainline builds between 4.18 and .20
[15:03] <tjaalton> alkisg: if you're still around, boot v4.19.0, then .3
[15:03] <tjaalton> .3 has plenty of changes for i915
[15:06] <alkisg> tjaalton: thanks, will do
[15:06] <alkisg> tjaalton: so the end result will probably be a kernel cherrypick for 4.15 in bionic?
[15:07] <tjaalton> es
[15:07] <tjaalton> yes
[15:07] <alkisg> ty
[16:28] <alkisg> tjaalton: if you do build a kernel, please build both 32bit and 64bit, so that schools test both of them...
[16:28] <tjaalton> alkisg: need to push to a ppa
[16:28] <tjaalton> but can do
[16:28] <tjaalton> ppa with tons of space, I have that
[16:29] <alkisg> Great, even better than wget
[16:33] <tjaalton> could probably cross-build locally, but meh
[16:33] <tjaalton> I'll verify the build first as 64bit
[16:33] <tjaalton> locally, then upload
[16:41] <tjaalton> alkisg: maybe I'll just revert softpin support from mesa, as ickle suggested.. more likely to get in the release
[16:41] <alkisg> Sure, whatever is easier
[16:41] <alkisg> I can test mesa then,if you want me to
[16:45] <tjaalton> yes, getting late, maybe not today, we'll see
[16:46] <tjaalton> I'll check the code first how to disable it
[16:46] <alkisg> np, take your time, thanks for all the help
[17:01] <tjaalton> must be this https://pastebin.com/tAeRSD1v
[17:01] <tjaalton> so I'll revert that
[17:15] <tjaalton> alkisg: I've pushed it to https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging
[17:18] <tjaalton> and closed the upstream bug
[17:18] <alkisg> tjaalton: thanks, will test when it builds. It's 18.2 with that line reverted?
[17:18] <tjaalton> yeah
[17:18] <alkisg> Great, ty
[17:18] <tjaalton> the kernel patches will be backported later
[18:00] <tjaalton> alkisg: i386 seems to be built
[18:06] <alkisg> ty,testing...
[18:10]  * alkisg hopes he didn't mess up grub this time :D
[18:10] <tjaalton> mesa doesn't touch it
[18:10] <tjaalton> kernel update does
[18:11] <alkisg> The hard part is configuring grub to boot an older kernel
[18:11] <alkisg> From 4.19 back to 4.15
[18:11] <tjaalton> uninstall 4.19
[18:11] <alkisg> Not good when it's running, apt refuses
[18:11] <tjaalton> complains
[18:11] <alkisg> Hmm maybe that changed from the last time I tried
[18:12] <alkisg> tjaalton: success!
[18:12] <alkisg> Can I copy this to the schools ppa, for everyone to get?
[18:12] <tjaalton> sure
[18:12] <janesma> tjaalton: Mesa i965 was hitting consistent deadlocks with userptr, so we switched entirely to softpin recently
[18:12] <alkisg> I assume it'll be overriden by the next stable update, right?
[18:12] <tjaalton> it'll be in proposed soon
[18:13] <janesma> alkisg: you reported that this happened with 64bit systems too?  
[18:13] <tjaalton> janesma: well, changing the kernel takes more time than rolling a revert via mesa
[18:13] <alkisg> janesma: yes, a school said it saw it on a 64bit system
[18:13] <janesma> yep
[18:13] <tjaalton> and kernel won't get changed for 18.04.2 image which is next week
[18:15] <janesma> why wouldn't see the same thing with upstream mesa 18.3.3 and linux 4.18.2, on a 64bit system?
[18:15] <alkisg> The same card?
[18:16] <alkisg> tjaalton didn't see it either, I don't know why
[18:16] <tjaalton> beats me, but this was with legacy bios
[18:16] <janesma> it was a skylake machine...  I think all of this should be the same for gen9
[18:16] <tjaalton> which might or might not play a part
[18:16] <tjaalton> I tested on a kbl laptop
[18:17] <janesma> yeah, gen9 has the same feature set (skylake kabylake coffeelake)
[18:17] <janesma> 100% symmetry in the mesa regressions
[18:17] <janesma> we don't test different boot configurations (legacy/uefi), and I can't see how that would affect graphics....  but if it does then we have a new validation problem.
[18:18] <tjaalton> I'll test next week on hw that I can wipe clean
[18:18] <janesma> I'm hoping that this is down to running a 32bit kernel.
[18:19] <tjaalton> I managed to boot that too, still worked
[18:21] <janesma> I'd like to figure out how to reproduce this and make sure we aren't missing something in Mesa CI.
[18:22] <janesma> I think disabling softpin will cause intermittent hangs under load for ubuntu users.  Not nearly as bad as a black screen.
[18:22] <tjaalton> that's a good tradeoff for now
[18:22] <alkisg> It's not configurable by kernel cmdline or xorg.conf, right?
[18:24] <janesma> mesa 19.0 has the switch to softpin, in 731c4adcf9b11
[18:25] <janesma> not sure what that will do to oibaf/padoka users.  I guess they will be getting newer kernel and mesa, so they won't suffer.
[18:38] <tjaalton> alkisg: bionic will get 18.2.2 + the revert soon, 18.2.8 will follow after 18.04.2 is released
[18:42] <tjaalton> alkisg: are you still able to verify this build?
[18:42] <alkisg> tjaalton: I only have access to one server now, and it works with this build, yes
[18:43] <tjaalton> remove 18.2.8 with ppa-purge, then enable proposed and install the new update from there, then verify bionic for the bug
[18:43] <alkisg> Schools will need it on monday anyway, so if it'll get the build until then, I can do the verification done step
[18:43] <alkisg> Will do
[18:43] <tjaalton> it just got accepted, so the build takes a while again
[18:43] <alkisg> Tomorrow is fine
[18:43] <tjaalton> https://launchpad.net/ubuntu/+source/mesa/18.2.2-0ubuntu1~18.04.2
[18:44] <tjaalton> already building
[18:44] <tjaalton> yeah tomorrow is fine I guess
[18:45] <tjaalton> thanks for everything so far
[18:45] <tjaalton> almost 2100, time to grab a beer
[18:45] <alkisg> Thank you too!
[18:45] <tjaalton> too late to go out for a run
[18:45] <alkisg> Oh, same timezone, where are you?
[18:45] <tjaalton> espoo, finland
[18:45]  * alkisg ran 10 km earlier
[18:45] <alkisg> Ah, greece here, so yeah same timezone
[18:46] <tjaalton> yup, I remember
[18:46]  * alkisg sends a virtual beer to tjaalton :)
[18:46] <tjaalton> hope we'll get to crete again next year
[18:46] <tjaalton> though it's a tourist trap but we like it
[18:47] <alkisg> Here's a nice trick I found to revert to the stock versions, even when ppa-purge can't do it; google translate needed: http://alkisg.mysch.gr/steki/index.php?topic=7370.0
[18:47] <alkisg> Yeah I spent 5 of my best months in crete
[18:47] <tjaalton> what happened ?-)
[18:48] <alkisg> Nah, just talking in general, nothing happened here
[18:48] <alkisg> I had to research it for schools with veeery broken installations
[18:48] <alkisg> that were installing .debs from wherever they could find them
[18:48] <tjaalton> I mean in crete, why only 5mo :)
[18:48] <alkisg> Haha
[18:48] <alkisg> I was in the army then
[18:49] <tjaalton> ah right
[18:49] <alkisg> For 23 months, 5 in crete
[18:49] <alkisg> And even though the army generally isn't a good period.... crete was soooo nice....
[18:49] <tjaalton> I remember f-16 flyovers
[18:49] <alkisg> and many tourist women too :D
[18:49] <tjaalton> yes yes, very receptive
[18:49] <tjaalton> I assume
[19:04] <janesma> tjaalton: if you find a way to reproduce this locally, can you update me?
[19:07] <alkisg> So to only update mesa from proposed, I guess this will do it (after apt sources + pinning):
[19:07] <alkisg> apt update libegl-mesa0:i386 libglapi-mesa:i386 libxatracker2:i386 libegl1-mesa:i386 libx11-6:i386 libgbm1:i386 libwayland-egl1-mesa:i386 libx11-data:i386 libgl1-mesa-dri:i386 libosmesa6:i386 libgl1-mesa-glx:i386 mesa-vdpau-drivers:i386 libx11-xcb1:i386 mesa-va-drivers:i386 libglx-mesa0:i386
[19:08] <alkisg> I don't know why these libx11 things were in the upgraded-from-the-ppa list previously though...
[19:11] <alkisg> tjaalton, janesma: apt policy libegl-mesa0:i386 => 18.2.8-0ubuntu0~18.04.1 from bionic-proposed/main
[19:11] <alkisg> How can you upload 18.2.2 when it has 18.2.8?
[19:12] <alkisg> Ah, maybe standard repository rules don't apply to the proposed queue :)
[19:33] <tjaalton> alkisg: 18.2.8 got removed
[19:33] <tjaalton> janesma: hope I can, next week
[21:04] <alkisg> yup, proposed works, i'll comment in launchpad
[21:09] <alkisg> Hmm it'll be hard to do the cosmic verification
[21:09] <tjaalton> don't worry about that
[21:10] <tjaalton> thanks for testing
[21:10] <alkisg> :)
[21:10] <alkisg> Thanks for the package :)
[21:57] <tjaalton> alkisg: and released to updates :)
[21:57] <tjaalton> now 18.2.8 back in
[22:09] <alkisg> Yey!!!! :)
[23:36] <tomreyn> is there a change to get vega20 fimwares from agd5f into disco before release?
[23:36] <tomreyn> *chanCe