| === JanC is now known as Guest79577 | ||
| === JanC_ is now known as JanC | ||
| alkisg | I tried gathering more info for the "16 color depth split image" issue, and I got these: | 07:06 |
|---|---|---|
| alkisg | My test case is, boot from the live cd, then run `sudo -i; wget http://paste.debian.net/plain/922125 -O /etc/X11/xorg.conf; chmod -w /etc/X11/xorg.conf; service lightdm restart` - sometimes it moves xorg.conf elsewhere and I have to do it twice | 07:07 |
| alkisg | It doesn't happen in KVM, http://termbin.com/kszu - using vesa instead of modesetting | 07:07 |
| alkisg | vbox + ubuntu-mate 16.04.2 have the issue, http://termbin.com/m78q - with the modeset driver | 07:07 |
| alkisg | vbox + ubuntu-mate 16.02.1 do NOT have the issue, http://termbin.com/66xu - with the modeset driver | 07:07 |
| alkisg | So if I understand this correctly, it's a regression in the modesetting driver, and I should report it there? | 07:07 |
| alkisg | ...where is "there"? :) | 07:08 |
| tjaalton | xserver | 07:15 |
| tjaalton | but test 1.19.3 first | 07:15 |
| tjaalton | why using 16bpp? | 07:16 |
| alkisg | tjaalton: is it enough if I test the 17.04 live cd? | 07:16 |
| tjaalton | no | 07:16 |
| tjaalton | it has 1.18.4 | 07:16 |
| alkisg | Which ppa would I need? | 07:16 |
| tjaalton | ppa:canonical-x/x-staging | 07:17 |
| alkisg | Thank you. We are using 16 bpp in thin clients in ltsp, because remote X needs half the bandwidth there | 07:17 |
| alkisg | It's like XDMCP, not VNC/RDP which compress data... | 07:17 |
| tjaalton | you mentioned vbox before.. | 07:18 |
| alkisg | Yes, I was testing with vbox, and it was loading the modeset driver | 07:18 |
| alkisg | So any client that will fall back to modesetting, will have that issue, I assume | 07:18 |
| tjaalton | so is it the same issue with thin clients? | 07:18 |
| alkisg | I think that if e.g. they have an intel card, no; but if they have something that would fall back to modesetting, like I don't know, sis, they would | 07:19 |
| alkisg | Which graphics card should I choose to verify it on a real client? | 07:19 |
| tjaalton | modesetting is only used if there's a kms driver | 07:19 |
| tjaalton | and no "native" x driver | 07:19 |
| tjaalton | so sis will have vesa | 07:20 |
| alkisg | So that would be a really rare scenario? | 07:20 |
| alkisg | Thin clients are unfortunately still used in thousands of schools worldwide | 07:20 |
| alkisg | But if it'll just affect vbox, it's not an issue | 07:21 |
| alkisg | Although, it just broke between 16.04.1 and 16.04.2, is it worth reporting it anyway? | 07:21 |
| tjaalton | test 1.19 | 07:21 |
| tjaalton | 1.18 is dead to me :) | 07:21 |
| alkisg | Sure, doing so... | 07:21 |
| tjaalton | so what's the bug again? | 07:23 |
| alkisg | tjaalton: https://snag.gy/H3FeMW.jpg | 07:24 |
| tjaalton | default lightdm looked fine here | 07:25 |
| tjaalton | unity doesn't load though | 07:25 |
| alkisg | xdpyinfo | grep Depth, says 16? | 07:25 |
| tjaalton | but I guess that's expected | 07:25 |
| tjaalton | the background looks "bad", so I think so | 07:25 |
| alkisg | compiz did have issues with 16 bpp in the past, but we don't care about that part | 07:26 |
| tjaalton | yes, depth is 16 | 07:27 |
| tjaalton | test with intel | 07:27 |
| alkisg | Intel uses the modesetting driver? | 07:27 |
| tjaalton | on 16.04.2/16.10 and up | 07:28 |
| tjaalton | i mean intel hw | 07:28 |
| alkisg | But if the problem only happens with the modesetting driver, and intel doesn't use that, how would I see it in intel hardware? | 07:28 |
| tjaalton | uh | 07:28 |
| tjaalton | the xserver is patched to not load intel | 07:29 |
| alkisg | Ah, ok then | 07:29 |
| tjaalton | falls back on modesetting | 07:29 |
| tjaalton | but only on 16.10 and the hwe backport | 07:29 |
| tjaalton | same effect if you uninstall -intel on 16.04(.1) | 07:29 |
| alkisg | On my current pc, I have: [ 19.307] (II) modesetting: Driver for Modesetting Kernel Drivers: kms | 07:30 |
| alkisg | 16.04.2 | 07:30 |
| alkisg | Can I test on that? | 07:30 |
| tjaalton | yes | 07:30 |
| alkisg | OK, be back in 2 mins, thanks... | 07:30 |
| alkisg | xorg crashes here when I try 16bpp | 07:42 |
| alkisg | I tried it 3 times, and I had to REISUB to reboot | 07:42 |
| alkisg | I have 2 graphics cards though, maybe it conflicts somewhere there, let me try it on another intel machine with just 1 card | 07:44 |
| alkisg | I think that's the failed xorg: http://termbin.com/oumo | 07:47 |
| * alkisg tries with 1 card... | 07:47 | |
| alkisg | It doesn't have an issue on 16.04.1, now upgrading that machine to .2... | 07:52 |
| tjaalton | it has the same xserver | 07:52 |
| tjaalton | could've just installed -intel if that's what you tested with on .1 | 07:52 |
| tjaalton | *uninstalled | 07:52 |
| alkisg | in vbox, the problem didn't happen in 16.04.1 and did happen in 16.04.2 | 07:53 |
| alkisg | I already ran the apt command, will see in 2 mins... | 07:53 |
| tjaalton | vbox updated then | 07:53 |
| tjaalton | 4.4 vs 4.8 | 07:53 |
| alkisg | apt install --purge xserver-xorg-hwe-16.04 xserver-xorg-input-all-hwe-16.04; service lightdm restart => no issue yet, rebooting the machine... | 07:55 |
| alkisg | Eh updating removed xorg.conf, so it wasn't a valid test yet... | 07:57 |
| tjaalton | removed? doubt that | 07:57 |
| tjaalton | oh | 07:57 |
| tjaalton | actually yes, purging xserver-xorg(-hwe-16.04) does remove it | 07:58 |
| alkisg | (yup; the intention there was to have xserver-xorg in purged state instead of ^rc) | 07:59 |
| alkisg | I have the same issue with the 1-card machine, http://termbin.com/nkwv | 07:59 |
| alkisg | -rw-r----- 1 root whoopsie 1,9M Μάρ 17 09:57 /var/crash/_usr_lib_xorg_Xorg.0.crash | 07:59 |
| alkisg | Caps lock etc doesn't work at this point, but I do have ssh access | 08:00 |
| tjaalton | broken config? | 08:00 |
| alkisg | http://paste.debian.net/plain/922125 | 08:00 |
| alkisg | It works on 16.04.1 on the same machine | 08:01 |
| alkisg | Let me try 4.4 + newer xorg... | 08:01 |
| tjaalton | drop device/monitor sections, just leave identifier/defaultdepth on screen section.. that's what I used | 08:02 |
| alkisg | Rebooting with http://termbin.com/npzg... | 08:03 |
| alkisg | (had the same symptoms with 4.4 + newer xorg) | 08:04 |
| alkisg | Same results with newer xorg.conf, here's the Xorg.0.log, http://termbin.com/56gt | 08:05 |
| * alkisg tries -depth 16 manually... | 08:06 | |
| tjaalton | wait | 08:07 |
| tjaalton | apt-cache policy libgbm1 | 08:07 |
| tjaalton | apt-cache policy libgl1-mesa-dri | 08:07 |
| alkisg | xinit -- -depth 24 => OK, xinit -- -depth 16 => Xorg: ../../../../hw/xfree86/common/xf86Helper.c:1948: xf86ScrnToScreen: Assertion `pScrn->scrnIndex < screenInfo.numScreens' failed. | 08:08 |
| tjaalton | nevermind, gbm/dri mismatch was for software rendering "bug" | 08:08 |
| tjaalton | I don't know then, if i915.ko is loaded it should work just fine | 08:09 |
| alkisg | libgbm1=12.0.6-0ubuntu0.16.04.1 500, libgl1-mesa-dri = 12.0.6-0ubuntu0.16.04.1 500 | 08:09 |
| tjaalton | and does work here | 08:09 |
| alkisg | Maybe different chipset? | 08:10 |
| tjaalton | shouldn't matter | 08:10 |
| alkisg | I can test with the live CD, if it'll help | 08:10 |
| alkisg | (to ensure that it's not an issue with my installation) | 08:10 |
| tjaalton | which cpu do you have then | 08:10 |
| alkisg | # lspci -nn -k | grep -A 2 VGA | 08:10 |
| alkisg | 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Generation Core Processor Family Integrated Graphics Controller [8086:041e] (rev 06) Subsystem: Gigabyte Technology Co., Ltd 4th Generation Core Processor Family Integrated Graphics Controller [1458:d000] Kernel driver in use: i915 | 08:10 |
| tjaalton | well that's old | 08:11 |
| alkisg | grep model /proc/cpuinfo => model name : Intel(R) Core(TM) i3-4150 CPU @ 3.50GHz | 08:11 |
| tjaalton | oh sorry | 08:11 |
| tjaalton | 4th gen core | 08:11 |
| alkisg | Well, it still shouldn't crash :D | 08:11 |
| tjaalton | not gen4 | 08:11 |
| tjaalton | haswell | 08:12 |
| alkisg | After testing with the ppa, where would I file a bug report for this? | 08:12 |
| tjaalton | which one? | 08:13 |
| alkisg | The one you proposed that I should test xorg 1.19 with | 08:13 |
| alkisg | Let me check the logs... | 08:13 |
| tjaalton | your original bug | 08:13 |
| tjaalton | that's in vbox I bet | 08:13 |
| alkisg | Yes | 08:14 |
| alkisg | Well, I have 2 cases where modesetting works in 16.04.1 and has issues in .2, in vbox the issue is split screen, in intel it's a crash | 08:14 |
| tjaalton | and same 4.8 kernel on both? | 08:14 |
| alkisg | Yes | 08:14 |
| alkisg | I tried with 4.4 on intel, it still crashed | 08:15 |
| tjaalton | while you say "modesetting" works it's using -intel on .1? | 08:15 |
| tjaalton | because it's essentially the same xserver | 08:15 |
| alkisg | On the stock 16.04.1, it worked. Would that load intel? | 08:15 |
| tjaalton | yes | 08:15 |
| alkisg | Then yes | 08:15 |
| tjaalton | but | 08:16 |
| tjaalton | you were testing on vbox.. | 08:16 |
| tjaalton | where it loads whatever | 08:16 |
| alkisg | (09:45:22 πμ) ***alkisg tries with 1 card... | 08:16 |
| alkisg | (09:52:11 πμ) alkisg: It doesn't have an issue on 16.04.1, now upgrading that machine to .2... | 08:16 |
| alkisg | That was one of the recent tests I did "just now" | 08:16 |
| tjaalton | yeah I'm just super confused at this point. file whatever | 08:17 |
| tjaalton | I can't reproduce this "crash" with skylake | 08:17 |
| alkisg | Where would I file it? | 08:17 |
| alkisg | I'll start with the intel crash | 08:17 |
| tjaalton | tried it on 16.04.1 and 17.04+ppa | 08:18 |
| alkisg | Could you please try: xinit -- -depth 16 | 08:18 |
| tjaalton | I'm reading the log instead | 08:18 |
| tjaalton | and I can see how the lightdm background looks crappy | 08:18 |
| tjaalton | and login fails | 08:19 |
| tjaalton | so it's using 16bpp alright | 08:19 |
| alkisg | Yes, but I meant, so that we have a common action to try to reproduce it | 08:19 |
| alkisg | It's simpler than trying a xorg.conf | 08:19 |
| tjaalton | I don't have your environment | 08:19 |
| alkisg | (which can vary) | 08:19 |
| tjaalton | oh | 08:19 |
| tjaalton | xinit | 08:19 |
| tjaalton | misread | 08:19 |
| alkisg | sudo service lightdm stop; xinit -- -depth 16 | 08:19 |
| tjaalton | works | 08:20 |
| alkisg | OK, then I guess it only affects a few intel chipsets | 08:21 |
| alkisg | I'll see at home if I can reproduce it with a 6th gen one | 08:21 |
| alkisg | (i3 6100p if I remember correctly) | 08:22 |
| tjaalton | well, could repro it with BDS | 08:52 |
| tjaalton | BDW | 08:52 |
| alkisg | Nice :) | 08:53 |
| tjaalton | i guess the intel X driver does some tricks | 09:03 |
| alkisg | tjaalton: should I test the staging ppa? | 09:04 |
| tjaalton | file a bug on freedesktop drm/i915 | 09:04 |
| tjaalton | it doesn't help | 09:04 |
| alkisg | OK, thank you very much | 09:04 |
| alkisg | tjaalton: can I test with forcing the intel driver instead of the modesetting one? | 09:04 |
| tjaalton | test what? | 09:04 |
| tjaalton | depth 16 works there | 09:04 |
| alkisg | Ah, ok | 09:04 |
| alkisg | Reported https://bugs.freedesktop.org/show_bug.cgi?id=100246, hopefully I got it right | 10:13 |
| ubottu | Freedesktop bug 100246 in Driver/intel "Xorg crashes with 16bpp on i3-4150" [Normal,New] | 10:13 |
| tjaalton | wrong component, and never paste logs :) | 10:18 |
| tjaalton | should be dri/i915 | 10:19 |
| tjaalton | dunno why I can't change that.. | 10:20 |
| michael-vb | tjaalton: regarding the person who had Xorg loading before the video driver, I suggested he add "ExecStartPre=/bin/udevadm settle" to the display manager service file (it was lightdm) and that seemed to do the trick. | 13:22 |
| michael-vb | The question is, who should I talk to about that? It seems to me that something on those lines would make general sense, but it might well be something else on those lines. | 13:22 |
| tjaalton | michael-vb: file a bug against lightdm | 13:23 |
| michael-vb | I should check, but it probably affects gdm too. | 13:24 |
| michael-vb | And I have a suspicion it might want fixing somewhere further upstream. | 13:24 |
| tjaalton | i don't know where that would be | 13:25 |
| michael-vb | Any idea who might, or just file the bug as you suggested and wait for the response? | 13:25 |
| tjaalton | you can try the udev/systemd folks.. | 13:26 |
| michael-vb | Looking at the .orig archives for gdm3, plymouth and systemd, gdm3 is "After" plymouth-start.service and plymouth-start.service is "After" systemd-udev-trigger.service. The manual page is not quite clear to me: does udevadm trigger also wait for all events to be handled? | 13:39 |
| tjaalton | dunno | 13:41 |
| michael-vb | Right, looking at it I get the feeling that it is a problem in the Debian lightdm package. | 13:48 |
| michael-vb | So your first suggestion applies. | 13:48 |
| alkisg | michael-vb: I bumped into this page today: https://wiki.archlinux.org/index.php/LightDM#LightDM_does_not_appear | 13:56 |
| alkisg | It may happen that your system boots so fast that LightDM service is started before your graphics drivers are properly loaded. If this is your case, you will want to add the following config to your lightdm.conf file: [LightDM] logind-check-graphical=true | 13:56 |
| alkisg | I don't know if it applies or helps in that person's case.... | 13:57 |
| michael-vb | Interesting in any case. Thanks. | 13:57 |
| alkisg | np | 13:57 |
| alkisg | tjaalton: I could not reproduce the xorg crashing issue at home, on i3-6100. | 16:05 |
| alkisg | About the other issue that I was having with the ghost e-DP1 monitor, it's like this: kernel 4.4 => no ghost monitor, 4.8 => a ghost monitor called e-DP1, 4.11 => a ghost monitor called DP-1, while the real VGA one is DP-2. Should I test anything else before reporting it, and where would I report it? Thanks again! | 16:05 |
| michael-vb | alkisg: the user tried your suggestion above and it worked. They also see the same problem with Fedora and lightdm. (They helpfully initially said "Fedora" without mentioning lightdm, leaving me assuming GNOME Shell.) | 16:14 |
| alkisg | michael-vb: glad I could help; so it appears others have bumped into that as well, since it's documented in a wiki | 16:15 |
| michael-vb | Yes, thanks. | 16:15 |
| tjaalton | alkisg: dri/drm/i915 | 16:52 |
| alkisg | tjaalton: thank you very much again | 16:52 |
| tjaalton | your cpu is a skylake, so same as here | 16:53 |
| tjaalton | might suggest it's actually a bug in i965_dri | 16:53 |
| tjaalton | so mesa | 16:53 |
| tjaalton | gen4 was busted too, hung the machine | 16:54 |
| alkisg | Nonono it took us 6 months of talking to the mayor to get those machines, we won't see new ones for the next 10 years :D | 16:54 |
| tjaalton | huh? | 16:57 |
| tjaalton | skylake is fine is it not? | 16:57 |
| alkisg | It sure is, I thought that when you said "gen4", you were referring to my work pc, which is i3-4xxx | 16:59 |
| alkisg | (the one that had the xorg crash issue) | 16:59 |
| alkisg | So skylake has the ghost monitor issue, while broadwell has the xorg crash issue | 16:59 |
| tjaalton | gen4 = 965GM | 17:01 |
| tjaalton | = old | 17:02 |
| alkisg | OK; but I don't think we tested that anywhere today | 17:02 |
| tjaalton | the "crash" is on < gen9 | 17:02 |
| tjaalton | I did | 17:02 |
| alkisg | Ah, so I could reproduce it on some older machines that I have | 17:02 |
| alkisg | Thanks, and sorry for misunderstanding | 17:02 |
| tjaalton | you already did.. | 17:02 |
| alkisg | I only tested on broadwell, I didn't test on 965gm | 17:03 |
| tjaalton | i did | 17:03 |
| alkisg | Yup, I got that part. | 17:03 |
| tjaalton | you tested haswell | 17:03 |
| alkisg | i3-4xxx is haswell? eh, sorry, my bad then | 17:04 |
| alkisg | Too many numbers and names :D 8th generation and 4xxx and haswell... confusing :D | 17:04 |
| * alkisg notes that the ghost monitor issue also happens on another skylate processor, model name : Intel(R) Pentium(R) CPU G4400 @ 3.30GHz | 20:21 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
