'qcomsysd' crashes every 5 seconds

Help Fairphone 3
1

Hi there,

I got random reboots of my brand new FP3 today.
dmesg shows numerous entries about ‘qcomsysd’, which keeps crashing every 5 seconds:

<14>[ 1052.208594] init: starting service ‘qcomsysd’…
<36>[ 1052.253459] type=1400 audit(1592572173.403:769): avc: denied { read write } for pid=10809 comm=“qcom-system-dae” name=“diag” dev=“tmpfs” ino=17517 scontext=u:r:vendor_qcomsysd:s0 tcontext=u:object_r:diag_device:s0 tclass=chr_file permissive=0
<36>[ 1052.253473] type=1400 audit(1592572178.423:770): avc: denied { read write } for pid=10810 comm=“qcom-system-dae” name=“diag” dev=“tmpfs” ino=17517 scontext=u:r:vendor_qcomsysd:s0 tcontext=u:object_r:diag_device:s0 tclass=chr_file permissive=0
<14>[ 1052.255390] init: Service ‘qcomsysd’ (pid 10810) exited with status 255
<14>[ 1052.255413] init: Sending signal 9 to service ‘qcomsysd’ (pid 10810) process group…
<14>[ 1057.220561] init: starting service ‘qcomsysd’…
<36>[ 1057.271536] type=1400 audit(1592572178.423:770): avc: denied { read write } for pid=10810 comm=“qcom-system-dae” name=“diag” dev=“tmpfs” ino=17517 scontext=u:r:vendor_qcomsysd:s0 tcontext=u:object_r:diag_device:s0 tclass=chr_file permissive=0
<36>[ 1057.271550] type=1400 audit(1592572183.443:771): avc: denied { read write } for pid=10811 comm=“qcom-system-dae” name=“diag” dev=“tmpfs” ino=17517 scontext=u:r:vendor_qcomsysd:s0 tcontext=u:object_r:diag_device:s0 tclass=chr_file permissive=0
<14>[ 1057.273519] init: Service ‘qcomsysd’ (pid 10811) exited with status 255
<14>[ 1057.273545] init: Sending signal 9 to service ‘qcomsysd’ (pid 10811) process group…

Any idea if this is related to my reboots today?

Thanks,
Simon

2

Hi, welcome on the community forum!
I have no clue about what qcomsysd is, someone who knows more than me may give you one. Are you on stock android for FP3 (i.e not /e/OS)?
In the meantime:
As your phone is brand new, I suppose you don’t have any relevant data on it, did you try a factory reset?
Did you already try anything?

(Edit: Typo)

1 Like
3

I’ve flashed /e/, but wasn’t that happy with it, so i went back to stock rom after 1-2 hours. I’ve used the zip-file to flash back everything to stock rom and no errors where reported.

The only thing I found about qcomsysd was in a chinese forum. Given the name of the service, it may be related to some qualcomm stuff (e.g. modem)

And (when I’ve searched for qcom-system-dae) these, although the error messages differ:


1 Like
4

So that means that your problem was solved ?

5

No, the problem still persists. Just pulled a 27MiB kmesg file from my sdcard as the system rebooted again.

Except for thousands of qcomsysd crashes there was another line shortly before the crash:

<3>[20901.814818] binder_alloc: 21614: binder_alloc_buf, no vma
<6>[20901.814834] binder: 1215:1375 transaction failed 29189/-3, size 60-0 line 3150
<3>[20902.101299] msm_adsp_init_mixer_ctl_pp_event_queue: kctl_prtd is not NULL at initialization.
<3>[20902.124265] q6asm_send_cal: cal_block is NULL or stale
6

Well then it may be a problem with the motherboard, as in the article you showed where they suspect it to be a problem with the CPU…
Did you contact Fairphone support? As your phone is under guarantee, if it is a manufacturing defect they should change it for you.

7

No, I’ve not yet reached out for support, but I’ll do. I’ll update this post if I get any news, maybe someone stumbles upon this problem too

8

Messages like these indicate that the qcom-system-dae program is trying to do things that the “SELinux” policy does not permit. In this case, it is trying to read or write a temporary file from “tmpfs” - a fake temporary file system that stores files in RAM rather than to storage and is cleared on reboot. The likely problem is either:

  1. the SELinux policy on your phone is too restrictive. These policies ship as part of your Android (updates) and should be equal on all phones.
  2. The SELinux policy or the SELinux properties on the tmpfs filesystem need to be regenerated.

Either way this doesn’t sound like hardware failure. It is possible that a factory reset will solve your problems - as I expect that to reset your SELinux configuration. But it might also just be a bug in the current FPOS build.

3 Likes