weston-1.4.0: rpi-backend is broken

Tue Jan 28 03:00:37 PST 2014

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.

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.

Thanks,
pq