weston-1.4.0: rpi-backend is broken

[Emilio Pozuelo Monfort]

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
>>>>> 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