On 28/01/14 12:00, Pekka Paalanen wrote: > On Tue, 28 Jan 2014 00:49:06 +0100 > "Yann E. MORIN" <yann.morin.1...@free.fr> wrote: > >> Pekka, All, >> >> On 2014-01-26 21:15 +0100, Yann E. MORIN spake thusly: >>> On 2014-01-26 21:51 +0200, Pekka Paalanen spake thusly: >>>> On Sun, 26 Jan 2014 19:08:47 +0100 >>>> "Yann E. MORIN" <yann.morin.1...@free.fr> wrote: >>>>> I'm trying to run wayland+weston 1.4.0 on the raspberry pi with >>>>> the rpi-backend. >>>>> >>>>> Running weston freezes while still in the console, just after >>>>> displaying "Initializing Raspberry Pi backend". >>>>> >>>>> Ctrl-C, Ctrl-Alt-Backspace don't do anything. The system is >>>>> still responsive via ssh. >>>>> >>>>> I bisected it (bisect range: 1.3.0..1.4.0) to the first bad >>>>> commit: 17bccae... input: Handle unplugging the output for a >>>>> touchscreen >>>>> >>>>> I tried applying 8fe412d: >>>>> Revert part of 17bccae[...] >>>>> >>>>> (17bccae is the failing cset), but this does not fix the >>>>> breakage. >>>>> >>>>> The RPi userland and firmware I use are the latest from their >>>>> repositories, namely: >>>>> userland: cset 5cecd5a >>>>> firmware: cset 940dc3b >>> >>>> could you get the log.txt from 'weston-launch &> log.txt' while >>>> using weston master revision? >>>> The fbcon stops updating the moment the rpi gfx backend >>>> initializes (also in normal cases), but weston may still print >>>> useful stuff after that. >>> >>> I'm not using weston-launch, but directly calling 'weston' from the >>> command line, as root. >>> >>> Here's the complete log of 'weston >weston.log 2>&1' : >>> >>> ---8<--- >>> Date: 2014-01-26 UTC >>> [20:03:09.606] weston 1.4.0 >>> http://wayland.freedesktop.org/ >>> Bug reports to: >>> >>> https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.4.0 >>> Build: >>> [20:03:09.607] OS: Linux, 3.12.7, #1 PREEMPT Sat Jan 25 >>> 14:09:48 CET 2014, armv6l >>> [20:03:09.608] Starting with no config file. >>> [20:03:09.611] Loading module '/usr/lib/weston/rpi-backend.so' >>> [20:03:09.648] initializing Raspberry Pi backend >>> [20:03:09.652] Dispmanx planes are double buffered. >>> [20:03:09.656] launching '/usr/libexec/weston-keyboard' >>> [20:03:09.909] input device HID 046a:0023, /dev/input/event0 is >>> a keyboard >>> Failed to process Wayland connection: Connection reset by peer >>> failed to create display: Connection reset by peer >>> Segmentation fault >>> ---8<--- >> >> And here is the backtrace (as asked by Daniel on IRC): >> >> ---8<--- >> (gdb) target remote 192.168.127.167:1234 >> Remote debugging using 192.168.127.167:1234 >> Reading symbols from /lib/ld-linux-armhf.so.3...(no debugging >> symbols found)...done. Loaded symbols for /lib/ld-linux-armhf.so.3 >> 0xb6fdad10 in ?? () from /lib/ld-linux-armhf.so.3 >> (gdb) continue >> Continuing. >> Cannot access memory at address 0x0 >> >> Program received signal SIGSEGV, Segmentation fault. >> 0xb6fce9b4 in wl_list_insert (list=0xb6ef6760, elm=0x40290) at >> wayland-util.c:46 46 list->next = elm; >> (gdb) bt >> #0 0xb6fce9b4 in wl_list_insert (list=0xb6ef6760, elm=0x40290) >> at wayland-util.c:46 #1 0xb6ceefc0 in wl_signal_add (signal=0x39ec4, >> listener=0x40290) >> at >> /home/ymorin/dev/buildroot/br.config/build/rpi/wayland/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/wayland-server.h:223 >> #2 0xb6cf09e0 in evdev_device_set_output (device=0x40278, >> output=0x39d20) at evdev.c:620 #3 0xb6cee3e8 in device_added >> (udev_device=0x3b3b0, input=0x39e20) at udev-seat.c:133 #4 >> 0xb6cee4fc in udev_input_add_devices (input=0x39e20, udev=0x3ab90) at >> udev-seat.c:165 #5 0xb6cee9a4 in udev_input_enable (input=0x39e20, >> udev=0x3ab90) at udev-seat.c:273 #6 0xb6ceebbc in udev_input_init >> (input=0x39e20, c=0x39c70, udev=0x3ab90, seat_id=0xb6cf5c1c "seat0") >> at udev-seat.c:321 #7 0xb6cea34c in rpi_compositor_create >> (display=0x38060, argc=0xbefffb5c, argv=0xbefffd94, config=0x0, >> param=0xbefffb30) at compositor-rpi.c:530 #8 0xb6cea608 in >> backend_init (display=0x38060, argc=0xbefffb5c, argv=0xbefffd94, >> config=0x0) at compositor-rpi.c:612 #9 0x00018944 in main (argc=1, >> argv=0xbefffd94) at compositor.c:4217 (gdb) ---8<--- >> >> Hope this helps. >> >> wayland and weston are both 1.4.0. >> >> Note that since the framebuffer freezes and no longer updates after >> the rpi-backend is loaded, I had to run through gdbserver, and attach >> from a cross-gdb running on my dev machine. > > Hi, > > yeah, at least remote if not cross-gdb is useful since you don't have > time to attach to weston via ssh after it executes. > > I would have to take time to look into this and reproduce, but > unfortunately I'm not sure when I can. > > One difference between the DRM and RPI backends is that DRM backend > initilizes outputs first and input devices then, while RPI backend > initializes input devices first. Seeing evdev_device_set_output() in > the stack trace with an exploding list manipulation hints that that > might be a problem.
That was right. Initializing the outputs before the input devices fixes the segfault. I have just sent a patch that does that. > I think ideally the order of initialization should not matter, since > both input devices and outputs can come and go dynamically in Weston. > Maybe there is something to fix in that. Perhaps, but since the drm and evdev backends initialize the outputs first, I have changed the rpi backend to do that too. Regards, Emilio _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel