TK1 System Freeze

Hi there

I lately was tasked to run some legacy Qt4e [1] application on Apalis TK1. It should really only draw directly to the Linux frame buffer /dev/fb0. Strangely as soon as that application is started the whole system freezes. Running it with the VNC backend or a pure frame buffer emulation it works just fine. So it must have something to do with the particular way the frame buffer is done on TK1. So far no attempt in debugging this any further bear any fruit. Whether stracing what the application is doing nor tracing the linux kernel side of things revealed where exactly the freeze happens. As I feared some kind of a configuration issue on Apalis TK1 I also tried the same on Jetson TK1 with latest stock Linux kernel 4.14. However the same freeze happens.

Has anybody ever seen a similar complete system freeze? Any ideas what it may be or how we could debug this any further?

[1] https://layers.openembedded.org/layerindex/recipe/43622/

Cheers

Marcel

Hi Marcel, Hi Thierry,

Quoted 13 lines · Marcel Ziswiler

Hi there

I lately was tasked to run some legacy Qt4e [1] application on Apalis TK1. It should really only draw directly to the Linux frame buffer /dev/fb0. Strangely as soon as that application is started the whole system freezes. Running it with the VNC backend or a pure frame buffer emulation it works just fine. So it must have something to do with the particular way the frame buffer is done on TK1. So far no attempt in debugging this any further bear any fruit. Whether stracing what the application is doing nor tracing the linux kernel side of things revealed where exactly the freeze happens. As I feared some kind of a configuration issue on Apalis TK1 I also tried the same on Jetson TK1 with latest stock Linux kernel 4.14. However the same freeze happens.

This is still the case with 4.15-rc7.

While dd is not enough to reproduce it, using a simple fbdev application such as ts_calibrate seems to be sufficient. Qt and ts_calibrate use mmap for the framebuffer. The system seems to freeze when it tries to write into the mapped area (at the memset line):
https://github.com/kergoth/tslib/blob/master/tests/fbutils-linux.c#L160

Is this a known problem? Any idea?

Quoted 9 lines

Has anybody ever seen a similar complete system freeze? Any ideas what it may be or how we could debug this any further?

[1] https://layers.openembedded.org/layerindex/recipe/43622/

Cheers

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 25 lines · Stefan Agner

Hi Marcel, Hi Thierry,

Quoted 13 lines · Marcel Ziswiler

Hi there

I lately was tasked to run some legacy Qt4e [1] application on Apalis TK1. It should really only draw directly to the Linux frame buffer /dev/fb0. Strangely as soon as that application is started the whole system freezes. Running it with the VNC backend or a pure frame buffer emulation it works just fine. So it must have something to do with the particular way the frame buffer is done on TK1. So far no attempt in debugging this any further bear any fruit. Whether stracing what the application is doing nor tracing the linux kernel side of things revealed where exactly the freeze happens. As I feared some kind of a configuration issue on Apalis TK1 I also tried the same on Jetson TK1 with latest stock Linux kernel 4.14. However the same freeze happens.

This is still the case with 4.15-rc7.

While dd is not enough to reproduce it, using a simple fbdev application such as ts_calibrate seems to be sufficient. Qt and ts_calibrate use mmap for the framebuffer. The system seems to freeze when it tries to write into the mapped area (at the memset line):
https://github.com/kergoth/tslib/blob/master/tests/fbutils-linux.c#L160

Quoted 1 line

Is this a known problem? Any idea?

Thierry, anybody else, any idea? This should be easily reproducible on Jetson TK1.

Quoted 25 lines · Stefan Agner

Hi Marcel, Hi Thierry,

Quoted 13 lines · Marcel Ziswiler

Hi there

I lately was tasked to run some legacy Qt4e [1] application on Apalis TK1. It should really only draw directly to the Linux frame buffer /dev/fb0. Strangely as soon as that application is started the whole system freezes. Running it with the VNC backend or a pure frame buffer emulation it works just fine. So it must have something to do with the particular way the frame buffer is done on TK1. So far no attempt in debugging this any further bear any fruit. Whether stracing what the application is doing nor tracing the linux kernel side of things revealed where exactly the freeze happens. As I feared some kind of a configuration issue on Apalis TK1 I also tried the same on Jetson TK1 with latest stock Linux kernel 4.14. However the same freeze happens.

This is still the case with 4.15-rc7.

While dd is not enough to reproduce it, using a simple fbdev application such as ts_calibrate seems to be sufficient. Qt and ts_calibrate use mmap for the framebuffer. The system seems to freeze when it tries to write into the mapped area (at the memset line):
https://github.com/kergoth/tslib/blob/master/tests/fbutils-linux.c#L160

Quoted 1 line

Is this a known problem? Any idea?

Thierry, anybody else, any idea? This should be easily reproducible on Jetson TK1.

Quoted 26 lines · On Tue, Feb 06, 2018 at 08:51:19AM +0100, [email protected]…

Quoted 25 lines · Stefan Agner

Hi Marcel, Hi Thierry,

Quoted 13 lines · Marcel Ziswiler

Hi there

I lately was tasked to run some legacy Qt4e [1] application on Apalis TK1. It should really only draw directly to the Linux frame buffer /dev/fb0. Strangely as soon as that application is started the whole system freezes. Running it with the VNC backend or a pure frame buffer emulation it works just fine. So it must have something to do with the particular way the frame buffer is done on TK1. So far no attempt in debugging this any further bear any fruit. Whether stracing what the application is doing nor tracing the linux kernel side of things revealed where exactly the freeze happens. As I feared some kind of a configuration issue on Apalis TK1 I also tried the same on Jetson TK1 with latest stock Linux kernel 4.14. However the same freeze happens.

This is still the case with 4.15-rc7.

While dd is not enough to reproduce it, using a simple fbdev application such as ts_calibrate seems to be sufficient. Qt and ts_calibrate use mmap for the framebuffer. The system seems to freeze when it tries to write into the mapped area (at the memset line):
https://github.com/kergoth/tslib/blob/master/tests/fbutils-linux.c#L160

Quoted 4 lines

Quoted 1 line

Is this a known problem? Any idea?

Thierry, anybody else, any idea? This should be easily reproducible on Jetson TK1.

I was able to reproduce this on Venice2 (just because I was using it for unrelated work, I'm pretty certain this can be reproduced on Jetson TK1) and came up with a fix. I think the problem is that fbdev has an mmap() implementation that conflicts with what we do in DRM/KMS and therefore causes a hang. I've sent out a series with the fix. It'd be great if you two can check that this indeed fixes the issue for you on Apalis. It did fix the issue for me on Venice2.

Tested using fbdev.c from here:

	https://patchwork.kernel.org/patch/743682/

This seems like it would have been broken since the dawn of time. Have you never encountered this before? Or has it only recently broken with newer kernels? We probably want this backported to all stable releases.