http://bugzilla.suse.com/show_bug.cgi?id=1016917 Max Staudt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mstaudt@suse.com, | |sndirsch@suse.com Flags| |needinfo?(sndirsch@suse.com | |) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c4 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED Assignee|xorg-maintainer-bugs@forge. |sndirsch@suse.com |provo.novell.com | Flags|needinfo?(sndirsch@suse.com | |) | --- Comment #4 from Stefan Dirsch --- Yes, I'm back. Can I still find the test .iso somewhere? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c6 --- Comment #6 from Stefan Dirsch --- Thanks. Meanwhile I've found the .iso myself. I can't easily reproduce the issue after installation and I have no idea how to investigate such issues during openQA installation. So if you can give me some hints, this would be helpful.

[ 20.372] (WW) xf86OpenConsole: setpgid failed: Operation not permitted [ 20.372] (WW) xf86OpenConsole: setsid failed: Operation not permitted

This appears to be a red herring. I see this in my X logfile after installation as well, where I have no issues to switch between X and Linux console via 'sendkey ctrl-alt-f1' and 'sendkey ctrl-alt-f7' commands. qemu command line I'm using is # qemu-kvm -enable-kvm -m 2048M -smp 2 -drive file=/test/qemu-tumbleweed.img,index=0,media=disk,cache=unsafe -localtime -name tw -boot c -vga cirrus -display sdl -net nic -net user,hostname=tw,hostfwd=tcp::5555-:22 -monitor stdio -usb -cdrom /test/Test-Build351.1-Media.iso Unfortunately network (ssh access) doesn't work for me. Not sure how to do this right. :-( -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c8 --- Comment #8 from Stefan Dirsch --- And, could you please try with plymouth disabled? (plymouth.enable=0 or plymouth.disable=1 or whatever as boot option; I can't rememaber any longer). We have a race condition between plymouth and KMS drivers since ever. :-( -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c10 --- Comment #10 from Stefan Dirsch --- Created attachment 708511 --> http://bugzilla.suse.com/attachment.cgi?id=708511&action=edit Screenshot Now, even without changing from X to Linux console I see a hang. I see no longer a cursor when clicking into qemu window. Now having access via ssh would be rather useful. ;-) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c12 --- Comment #12 from Michal Srb --- The backtrace with debug info is: #0 0x0000000000000021 in () #1 0x000000000059d49c in InputReady (fd=28, xevents=1, data=0x2244ce0) at inputthread.c:173 #2 0x000000000059fba1 in ospoll_wait (ospoll=0x226ea80, timeout=timeout@entry=-1) at ospoll.c:412 #3 0x000000000059d2f6 in InputThreadDoWork (arg=<optimized out>) at inputthread.c:360 #4 0x00007f3012c02454 in create_thread () at /lib64/libpthread.so.0 #5 0x00007f3014fe0000 in _rtld_local () at /lib64/ld-linux-x86-64.so.2 #6 0xffffffffffffffff in ()#7 0xffffffffffffffff in ()#8 0x0000000000000000 in () `InputReady` function casts the `data` to `InputThreadDevice *dev` calls `dev->readInputProc` which in this case is `xf86ReadInput`. It gives it `dev->readInputArgs` as a its third `void *closure` parameter. `xf86ReadInput` casts that `void *closure` parameter to `InputInfoPtr pInfo` and attempts to call `pInfo->read_input`, however `read_input` has value 0x21 and that is where the segfault happens. The whole `pInfo` structure looks messed up. So it is some issue in the new threaded input handling in 1.19. It looks like something freed and reused the InputInfo memory before this handler got to run. If anyone is interested, I have got core dump of the crashed X server from the installation (84 MB). -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c14 --- Comment #14 from Michal Srb --- It seems that X server receives udev event about the input device being removed and as part of removing the device it deletes its InputInfo record. However it never removes the task that is waiting for data in the InputThread. I can not find where is that supposed to happen, it looks like it was never implemented. It can be easily reproduced in installed system by running `udevadm trigger` and then moving mouse. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c16 --- Comment #16 from Dominique Leuenberger --- (In reply to Stefan Dirsch from comment #15)

Oh. That's interesting. xf86-input-<driver> packages run

udevadm trigger --subsystem-match=input --action=change || :

in their %post. YaST may run it at one point in addition as well.

Latest when yast installs the package on the target system - even without doing it on its own -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c18 --- Comment #18 from Dominique Leuenberger --- (In reply to Michal Srb from comment #17)

I tested it and it fixes the issue. This bug is opened against Tumbleweed, should the patch be backported into somewhere? The xf86-input-libinput in X11:XOrg is already version 0.23.0 which contains the fix.

Thanks for that find! we will rebase the staging project which currently holds X.org 1.19.0 to ensure it builds against current TW which has xf86-input-libinput; if this solves it, we're in the green. Backports are not needed, as Xorg 1.19 is not going to be shipped on anything older than TW at this moment. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c20 --- Comment #20 from Dominique Leuenberger --- (In reply to Stefan Dirsch from comment #19)

Indeed xf86-input-libinput on the test iso is still 0.20. And yeah, fixed since 0.21. And we've updated to 0.22 alreay in Oct 2016 !?!

Indeed - there was a ring setup error that 'froze' the libinput at version 0.20.0 for some reason; this has been corrected and the staging project is now building with 0.23.0 and then moving to test. Sadly, I can't really say how we ended up with the 0.20.0 freeze in Ring1 (wheras we had the version properly updated in the distro) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.suse.com/show_bug.cgi?id=1016917 http://bugzilla.suse.com/show_bug.cgi?id=1016917#c22 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #22 from Stefan Dirsch --- Ok. I agree. Let's close it. -- You are receiving this mail because: You are on the CC list for the bug.