[Android 10] Can't get drmfb-composer to run

Michael Goffioul

unread,

Oct 6, 2019, 10:13:10 PM10/6/19

to andro...@googlegroups.com

I'm trying to use drmfb-composer + minigbm/intel, as I did for Android pie, but I can't get drmfb-composer to run properly.

First I had to disable the hotplug thread, because the service couldn't access netlink (Operation not permitted). I didn't add the sepolicy to the build, but at the same time selinux is not enforced, so it shouldn't matter.

Then SurfaceFlinger crashes straight away when starting the boot animation, the logs showing the following:

10-07 01:53:51.127 1573 1573 I SurfaceFlinger: Enter boot animation

10-07 01:53:51.129 1573 1573 I surfaceflinger: type=1400 audit(0.0:156): avc: denied { use } for path="anon_inode:dmabuf" dev="anon_inodefs" ino=5599 scontext=u:r:init:s0 tcontext=u:r:surfaceflinger:s0 tclass=fd permissive=1
10-07 01:53:51.130 1442 1442 I HwBinder:1442_2: type=1400 audit(0.0:158): avc: denied { ioctl } for path="/dev/vndbinder" dev="tmpfs" ino=623 ioctlcmd=0x6201 scontext=u:r:init:s0 tcontext=u:object_r:vndbinder_device:s0 tclass=chr_file permissive=1
10-07 01:53:51.130 1442 1442 I HwBinder:1442_2: type=1400 audit(0.0:159): avc: denied { call } for scontext=u:r:init:s0 tcontext=u:r:vndservicemanager:s0 tclass=binder permissive=1
10-07 01:53:51.132 1442 1510 E /vendor/bin/hw/android.hardware....@2.1-service.drmfb: Failed to get IAshmemDeviceService.
10-07 01:53:51.131 1573 1573 I surfaceflinger: type=1400 audit(0.0:160): avc: denied { ioctl } for path="/dev/dri/renderD128" dev="tmpfs" ino=7395 ioctlcmd=0x642e scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
10-07 01:53:51.132 1573 1573 W HwcComposer: command 0x2000000 generated error 8

Not sure what to do about this one.

Michael Goffioul

unread,

Oct 7, 2019, 12:27:38 PM10/7/19

to andro...@googlegroups.com

I believe the error related to IAshmemDeviceService might be a red herring. Here's the unhelpful backtrace when surfaceflinger crashes, just in case:

0-07 16:09:57.910 1572 1572 F libc : Fatal signal 8 (SIGFPE), code 1 (FPE_INTDIV), fault addr 0xa7c7841a in tid 1572 (surfaceflinger), pid 1572 (surfaceflinger)
10-07 16:09:57.966 1622 1622 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
10-07 16:09:57.967 1480 1480 I /system/bin/tombstoned: received crash request for pid 1572
10-07 16:09:57.967 1622 1622 I crash_dump32: performing dump of process 1572 (target tid = 1572)
10-07 16:09:57.970 1622 1622 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-07 16:09:57.970 1622 1622 F DEBUG : Build fingerprint: 'Android-x86/android_x86/x86:10/QP1A.190711.020/eng.goffio.20191006.193201:eng/test-keys'
10-07 16:09:57.970 1622 1622 F DEBUG : Revision: '0'
10-07 16:09:57.970 1622 1622 F DEBUG : ABI: 'x86'
10-07 16:09:57.970 1622 1622 F DEBUG : Timestamp: 2019-10-07 16:09:57+0000
10-07 16:09:57.970 1622 1622 F DEBUG : pid: 1572, tid: 1572, name: surfaceflinger >>> /system/bin/surfaceflinger <<<
10-07 16:09:57.970 1622 1622 F DEBUG : uid: 0
10-07 16:09:57.970 1622 1622 F DEBUG : signal 8 (SIGFPE), code 1 (FPE_INTDIV), fault addr 0xa7c7841a
10-07 16:09:57.970 1622 1622 F DEBUG : eax 00000000 ebx 00000000 ecx 00000000 edx 00000000
10-07 16:09:57.970 1622 1622 F DEBUG : edi 00000000 esi 00000000
10-07 16:09:57.970 1622 1622 F DEBUG : ebp bfc31888 esp bfc316e4 eip a7c7841a

10-07 16:09:57.984 1622 1622 F DEBUG :
10-07 16:09:57.984 1622 1622 F DEBUG : backtrace:
10-07 16:09:57.985 1622 1622 F DEBUG : #00 pc 0001b41a /system/lib/libutils.so (__moddi3+242) (BuildId: 426f9045217c08c490053b4a49fd485d)

Mauro Rossi

unread,

Oct 7, 2019, 6:01:22 PM10/7/19

to Android-x86

Hi Micheal,

On Monday, October 7, 2019 at 6:27:38 PM UTC+2, Michael Goffioul wrote:

I believe the error related to IAshmemDeviceService might be a red herring. Here's the unhelpful backtrace when surfaceflinger crashes, just in case:

0-07 16:09:57.910 1572 1572 F libc : Fatal signal 8 (SIGFPE), code 1 (FPE_INTDIV), fault addr 0xa7c7841a in tid 1572 (surfaceflinger), pid 1572 (surfaceflinger)
10-07 16:09:57.966 1622 1622 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
10-07 16:09:57.967 1480 1480 I /system/bin/tombstoned: received crash request for pid 1572
10-07 16:09:57.967 1622 1622 I crash_dump32: performing dump of process 1572 (target tid = 1572)
10-07 16:09:57.970 1622 1622 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-07 16:09:57.970 1622 1622 F DEBUG : Build fingerprint: 'Android-x86/android_x86/x86:10/QP1A.190711.020/eng.goffio.20191006.193201:eng/test-keys'
10-07 16:09:57.970 1622 1622 F DEBUG : Revision: '0'
10-07 16:09:57.970 1622 1622 F DEBUG : ABI: 'x86'
10-07 16:09:57.970 1622 1622 F DEBUG : Timestamp: 2019-10-07 16:09:57+0000
10-07 16:09:57.970 1622 1622 F DEBUG : pid: 1572, tid: 1572, name: surfaceflinger >>> /system/bin/surfaceflinger <<<
10-07 16:09:57.970 1622 1622 F DEBUG : uid: 0
10-07 16:09:57.970 1622 1622 F DEBUG : signal 8 (SIGFPE), code 1 (FPE_INTDIV), fault addr 0xa7c7841a
10-07 16:09:57.970 1622 1622 F DEBUG : eax 00000000 ebx 00000000 ecx 00000000 edx 00000000
10-07 16:09:57.970 1622 1622 F DEBUG : edi 00000000 esi 00000000
10-07 16:09:57.970 1622 1622 F DEBUG : ebp bfc31888 esp bfc316e4 eip a7c7841a
10-07 16:09:57.984 1622 1622 F DEBUG :
10-07 16:09:57.984 1622 1622 F DEBUG : backtrace:
10-07 16:09:57.985 1622 1622 F DEBUG : #00 pc 0001b41a /system/lib/libutils.so (__moddi3+242) (BuildId: 426f9045217c08c490053b4a49fd485d)

This is the blocker

We encountered a similar problem in gbm_gralloc module in the past and it was due to a division by zero in the code,

if you have the tombstone_xx file you should be able to identify the line of code using addr2line -Cfe command

On Sun, Oct 6, 2019 at 10:12 PM Michael Goffioul <michael...@gmail.com> wrote:
I'm trying to use drmfb-composer + minigbm/intel, as I did for Android pie, but I can't get drmfb-composer to run properly.

I've never tested that configuration, but

I used IA-HardwareComposer with minigbm intel (gralloc1) and it is working with pie-x86,

it should work also in q-x86, but I will test and confirm as soon as possible

First I had to disable the hotplug thread, because the service couldn't access netlink (Operation not permitted). I didn't add the sepolicy to the build, but at the same time selinux is not enforced, so it shouldn't matter.

Then SurfaceFlinger crashes straight away when starting the boot animation, the logs showing the following:
10-07 01:53:51.127 1573 1573 I SurfaceFlinger: Enter boot animation

10-07 01:53:51.129 1573 1573 I surfaceflinger: type=1400 audit(0.0:156): avc: denied { use } for path="anon_inode:dmabuf" dev="anon_inodefs" ino=5599 scontext=u:r:init:s0 tcontext=u:r:surfaceflinger:s0 tclass=fd permissive=1
10-07 01:53:51.130 1442 1442 I HwBinder:1442_2: type=1400 audit(0.0:158): avc: denied { ioctl } for path="/dev/vndbinder" dev="tmpfs" ino=623 ioctlcmd=0x6201 scontext=u:r:init:s0 tcontext=u:object_r:vndbinder_device:s0 tclass=chr_file permissive=1
10-07 01:53:51.130 1442 1442 I HwBinder:1442_2: type=1400 audit(0.0:159): avc: denied { call } for scontext=u:r:init:s0 tcontext=u:r:vndservicemanager:s0 tclass=binder permissive=1

10-07 01:53:51.132 1442 1510 E /vendor/bin/hw/android.hardware.graphics.composer@2.1-service.drmfb: Failed to get IAshmemDeviceService.

10-07 01:53:51.131 1573 1573 I surfaceflinger: type=1400 audit(0.0:160): avc: denied { ioctl } for path="/dev/dri/renderD128" dev="tmpfs" ino=7395 ioctlcmd=0x642e scontext=u:r:surfaceflinger:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
10-07 01:53:51.132 1573 1573 W HwcComposer: command 0x2000000 generated error 8

Not sure what to do about this one.

The first three digits in the command represent an OPCODE, 0x200 is SET_COLOR_TRANSFORM

https://android.googlesource.com/platform/hardware/interfaces/+/refs/tags/android-10.0.0_r4/graphics/composer/2.1/IComposerClient.hal

the error 8 corresponds to "NOT_SUPPORTED" which may mean that that the requested Color Transformation is not supported

https://android.googlesource.com/platform/hardware/interfaces/+/master/graphics/composer/2.1/types.hal

being the message a Warning it may not be an a fatal Error,

there are examples of hwcomposer modules being too much verbose.

Mauro

Michael Goffioul

unread,

Oct 7, 2019, 6:09:46 PM10/7/19

to andro...@googlegroups.com

On Mon, Oct 7, 2019 at 6:01 PM Mauro Rossi <issor...@gmail.com> wrote:

On Monday, October 7, 2019 at 6:27:38 PM UTC+2, Michael Goffioul wrote:
I believe the error related to IAshmemDeviceService might be a red herring. Here's the unhelpful backtrace when surfaceflinger crashes, just in case:

0-07 16:09:57.910 1572 1572 F libc : Fatal signal 8 (SIGFPE), code 1 (FPE_INTDIV), fault addr 0xa7c7841a in tid 1572 (surfaceflinger), pid 1572 (surfaceflinger)
10-07 16:09:57.966 1622 1622 I crash_dump32: obtaining output fd from tombstoned, type: kDebuggerdTombstone
10-07 16:09:57.967 1480 1480 I /system/bin/tombstoned: received crash request for pid 1572
10-07 16:09:57.967 1622 1622 I crash_dump32: performing dump of process 1572 (target tid = 1572)
10-07 16:09:57.970 1622 1622 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-07 16:09:57.970 1622 1622 F DEBUG : Build fingerprint: 'Android-x86/android_x86/x86:10/QP1A.190711.020/eng.goffio.20191006.193201:eng/test-keys'
10-07 16:09:57.970 1622 1622 F DEBUG : Revision: '0'
10-07 16:09:57.970 1622 1622 F DEBUG : ABI: 'x86'
10-07 16:09:57.970 1622 1622 F DEBUG : Timestamp: 2019-10-07 16:09:57+0000
10-07 16:09:57.970 1622 1622 F DEBUG : pid: 1572, tid: 1572, name: surfaceflinger >>> /system/bin/surfaceflinger <<<
10-07 16:09:57.970 1622 1622 F DEBUG : uid: 0
10-07 16:09:57.970 1622 1622 F DEBUG : signal 8 (SIGFPE), code 1 (FPE_INTDIV), fault addr 0xa7c7841a
10-07 16:09:57.970 1622 1622 F DEBUG : eax 00000000 ebx 00000000 ecx 00000000 edx 00000000
10-07 16:09:57.970 1622 1622 F DEBUG : edi 00000000 esi 00000000
10-07 16:09:57.970 1622 1622 F DEBUG : ebp bfc31888 esp bfc316e4 eip a7c7841a
10-07 16:09:57.984 1622 1622 F DEBUG :
10-07 16:09:57.984 1622 1622 F DEBUG : backtrace:
10-07 16:09:57.985 1622 1622 F DEBUG : #00 pc 0001b41a /system/lib/libutils.so (__moddi3+242) (BuildId: 426f9045217c08c490053b4a49fd485d)

This is the blocker

We encountered a similar problem in gbm_gralloc module in the past and it was due to a division by zero in the code,
if you have the tombstone_xx file you should be able to identify the line of code using addr2line -Cfe command

I'm running in live mode, as I don't want to flash my device at the moment (I still need a stable device for regular development). The problem is that the backtrace only contains the above frame, which makes it completely useless. Not sure the tombstone will contain anything else. I'll keep digging to find a way to get debug. But as the network doesn't start either, I can't adb to the device. My options are limited.

On Sun, Oct 6, 2019 at 10:12 PM Michael Goffioul <michael...@gmail.com> wrote:
I'm trying to use drmfb-composer + minigbm/intel, as I did for Android pie, but I can't get drmfb-composer to run properly.

I've never tested that configuration, but
I used IA-HardwareComposer with minigbm intel (gralloc1) and it is working with pie-x86,
it should work also in q-x86, but I will test and confirm as soon as possible

IA-HardwareComposer doesn't work on my device, it's too old (Baytrail). I think it's related to atomic mode setting, but that's just a wild guess.

The first three digits in the command represent an OPCODE, 0x200 is SET_COLOR_TRANSFORM

https://android.googlesource.com/platform/hardware/interfaces/+/refs/tags/android-10.0.0_r4/graphics/composer/2.1/IComposerClient.hal

the error 8 corresponds to "NOT_SUPPORTED" which may mean that that the requested Color Transformation is not supported

https://android.googlesource.com/platform/hardware/interfaces/+/master/graphics/composer/2.1/types.hal

being the message a Warning it may not be an a fatal Error,
there are examples of hwcomposer modules being too much verbose.

Yes, I think it's just a red herring. But without proper backtrace, that's the only thing that appeared in the logs right before the crash.

Michael.

Michael Goffioul

unread,

Oct 7, 2019, 7:40:27 PM10/7/19

to andro...@googlegroups.com

I managed to get the tombstone: https://drive.google.com/open?id=1D7bbkLmI3aLUJe5pVPepvBIp6RP2aIpK

Mauro Rossi

unread,

Oct 10, 2019, 4:01:29 AM10/10/19

to Android-x86

Just FYI, the add2line command relies on /symbols/system/... binaries in the $(OUT), but in this case there is no suffient lines in backlog.

What patch in which project was necessary to solve?
Mauro

>
>
>
>
> On Sun, Oct 6, 2019 at 10:12 PM Michael Goffioul <michael...@gmail.com> wrote:
>
> I'm trying to use drmfb-composer + minigbm/intel, as I did for Android pie, but I can't get drmfb-composer to run properly.
>
>
>
>
> I've never tested that configuration, but
> I used IA-HardwareComposer with minigbm intel (gralloc1) and it is working with pie-x86,
>
>
> it should work also in q-x86, but I will test and confirm as soon as possible
>
>
> IA-HardwareComposer doesn't work on my device, it's too old (Baytrail). I think it's related to atomic mode setting, but that's just a wild guess.
>

It may be related to lack of RGBA support in primary planes,
I recently had the same issue on Dell e6410,
but the same ISO worked perfectly on Lenovo T460

Michael Goffioul

unread,

Oct 10, 2019, 1:24:24 PM10/10/19

to andro...@googlegroups.com

On Thu, Oct 10, 2019 at 4:01 AM Mauro Rossi <issor...@gmail.com> wrote:

> This is the blocker
>
>
> We encountered a similar problem in gbm_gralloc module in the past and it was due to a division by zero in the code,
> if you have the tombstone_xx file you should be able to identify the line of code using addr2line -Cfe command
>
>
> I'm running in live mode, as I don't want to flash my device at the moment (I still need a stable device for regular development). The problem is that the backtrace only contains the above frame, which makes it completely useless. Not sure the tombstone will contain anything else. I'll keep digging to find a way to get debug. But as the network doesn't start either, I can't adb to the device. My options are limited.

Just FYI, the add2line command relies on /symbols/system/... binaries in the $(OUT), but in this case there is no suffient lines in backlog.

I usually use development/scripts/stack, which provides direct mapping to the source code.

What patch in which project was necessary to solve?

I turned out the crash occured here: https://android.googlesource.com/platform/frameworks/native/+/refs/tags/android-10.0.0_r2/services/surfaceflinger/SurfaceFlinger.cpp#1986

because stats.vsyncPeriod is 0.

What's happening is that surfaceflinger needs at least 2 vsync events from the composer in order to initialize vsyncPeriod correctly. At startup, it waits until synchronization is done before starting sending frame to the composer. On the other end, drmfb-framebuffer only starts its own vsync thread when the first frame is presented from surfaceflinger, so kinda dead-lock situation. Surfaceflinger has a timeout of 1s and will fake a vsync event after that. This faked vsync then triggers the offending code path in surfaceflinger, leading to the crash.

I created a set of patches that fixed all the issues for me: https://github.com/goffioul/drmfb-composer

Michael.

Jon West

unread,

Oct 11, 2019, 4:19:56 PM10/11/19

to Android-x86

I can try and test these on Bliss OS Pie this weekend and report back for you and the others here. :)

Reply all

Reply to author

Forward