weston-1.4.0: rpi-backend is broken
Emilio Pozuelo Monfort
pochu27 at gmail.com
Mon Feb 3 08:03:42 PST 2014
On 28/01/14 12:00, Pekka Paalanen wrote:
> On Tue, 28 Jan 2014 00:49:06 +0100
> "Yann E. MORIN" <yann.morin.1998 at 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.1998 at 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
>>>>> I tried applying 8fe412d:
>>>>> Revert part of 17bccae[...]
>>>>> (17bccae is the failing cset), but this does not fix the
>>>>> 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' :
>>> Date: 2014-01-26 UTC
>>> [20:03:09.606] weston 1.4.0
>>> Bug reports to:
>>> [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
>> And here is the backtrace (as asked by Daniel on IRC):
>> (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
>> 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,
>> 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.
> 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.
More information about the wayland-devel