4.1.0.24 geminipda still have call traces like on 3.4.0.22

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): 4.1.0.24
HARDWARE (XA2, Xperia 10…): geminipda
UI LANGUAGE: english us
REGRESSION: (compared to previous public release: Yes, No, ?): No

look also: 3.4.0.22EA: Geminipda call traces on wakeup

DESCRIPTION:

geminipda has trace logs in the journal

PRECONDITIONS:

none

STEPS TO REPRODUCE:

start ‘devel-su journalctl -f’ in a ssh console and do:

close the lid
sleep 7
open the lid
sleep 7
goto 1)

EXPECTED RESULT:

no trace logs

ACTUAL RESULT:

trace logs in the journal like below

ADDITIONAL INFORMATION:

Jun 04 15:36:41 Sailfish kernel: [HIF-SDIO][I]mtk_wcn_wmt_func_ctrl:wmt-exp: OPID(3) type(9) start
Jun 04 15:36:41 Sailfish kernel: [Power/cpufreq] @_cpufreq_set_locked(), MT_CPU_DVFS_LL:(15,0): freq=1118000(1118000), volt =102000(102000), on=1, cur=481000, cci(325000,676000)
Jun 04 15:36:41 Sailfish kernel: [NVT-ts] nvt_ts_resume 1798: end
Jun 04 15:36:41 Sailfish kernel: [NVT-ts] nvt_ts_resume 1778: Touch is already resume
Jun 04 15:36:41 Sailfish kernel: [WMT-CORE][W]opfunc_func_on:func(9) already on
Jun 04 15:36:41 Sailfish kernel: [HIF-SDIO][I]mtk_wcn_wmt_func_ctrl:OPID(3) type(9) ok
Jun 04 15:36:41 Sailfish kernel: [HIF-SDIO][I]wmt_pwr_on_off_handler:WMT turn on LPBK suceed
Jun 04 15:36:41 Sailfish kernel: [Gsensor] bmi160_acc_read_sensor_data 1825 : acc final xyz data: 509,7621,7254, sens:8192
Jun 04 15:36:41 Sailfish kernel: ------------[ cut here ]------------
Jun 04 15:36:41 Sailfish kernel: WARNING: CPU: 0 PID: 185 at /home/abuild/rpmbuild/BUILD/kernel-3.18/kernel/irq/manage.c:454 enable_irq+0x88/0xd0()
Jun 04 15:36:41 Sailfish kernel: Unbalanced enable for IRQ 394
Jun 04 15:36:41 Sailfish kernel: CPU: 0 PID: 185 Comm: kworker/0:1 Tainted: G W 3.18.41 #1
Jun 04 15:36:41 Sailfish kernel: Hardware name: MT6797T (DT)
Jun 04 15:36:41 Sailfish kernel: Workqueue: events aw9523_key_eint_work
Jun 04 15:36:41 Sailfish kernel: Call trace:
Jun 04 15:36:41 Sailfish kernel: [] dump_backtrace+0x0/0x15c
Jun 04 15:36:41 Sailfish kernel: [] show_stack+0x14/0x1c
Jun 04 15:36:41 Sailfish kernel: [] dump_stack+0x80/0xa4
Jun 04 15:36:41 Sailfish kernel: [] warn_slowpath_fmt+0xb4/0xd8
Jun 04 15:36:41 Sailfish kernel: [] enable_irq+0x88/0xd0
Jun 04 15:36:41 Sailfish kernel: [] aw9523_key_eint_work+0x43c/0x5cc
Jun 04 15:36:41 Sailfish kernel: [] process_one_work+0x160/0x468
Jun 04 15:36:41 Sailfish kernel: [] worker_thread+0x140/0x4e4
Jun 04 15:36:41 Sailfish kernel: [] kthread+0xd8/0xec
Jun 04 15:36:41 Sailfish kernel: —[ end trace 5955ff4e4627c596 ]—
Jun 04 15:36:41 Sailfish kernel: __sched_setscheduler 524:mce policy=1 0 0
Jun 04 15:36:41 Sailfish kernel: CPU1: Booted secondary processor
Jun 04 15:36:41 Sailfish kernel: Detected VIPT I-cache on CPU1
Jun 04 15:36:41 Sailfish kernel: CPU1: found redistributor 1 @ffffff80000a0000
Jun 04 15:36:41 Sailfish kernel: CPU2: Booted secondary processor
Jun 04 15:36:41 Sailfish kernel: Detected VIPT I-cache on CPU2
Jun 04 15:36:41 Sailfish kernel: CPU2: found redistributor 2 @ffffff80000c0000
Jun 04 15:36:41 Sailfish kernel: [AAL] led_mode=5 , aal_need_lock=0
Jun 04 15:36:41 Sailfish kernel: CPU3: Booted secondary processor
Jun 04 15:36:41 Sailfish kernel: Detected VIPT I-cache on CPU3
Jun 04 15:36:41 Sailfish kernel: CPU3: found redistributor 3 @ffffff80000e0000
Jun 04 15:36:41 Sailfish kernel: [HPS] (0x7F00)<1>(0)(0) action end (100)(708)(0) (0)(0)(0) (4)(0)(0)(1)(0)(0) (0)(0)(708)(1) <4>(0)(0)
Jun 04 15:36:41 Sailfish kernel: [AAL] led_mode=5 , aal_need_lock=0
Jun 04 15:36:41 Sailfish kernel: [AAL] led_mode=5 , aal_need_lock=0

1 Like

Is this an issue nobody cares? Or is it no issue?

But nice, I got an anniversary badged for it. I do not need that badged and give it to Jolla.

Why are you double posting? You could’ve updated the original topic.

Thanks, I think it is better to keep discussion on the original report if possible. @jolladiho, if there’s new info here that’s crucial to keep and can’t be transferred over, let me know and I can unhide your original post.

I would prefer to continue using this report, because I had accidentally uploaded a log with a custom kernel on the old report. It happens, because I tested with a kernel compiled by myself to check if it has that issue too. I thought that could be the reason nobody takes care of the bug.

And there was no discussion to keep. That’s why I did a link back to the old report. Please unhide this and hide the old one. That makes morde sence to me. Thanks

This is now the case.

Thank you very much. Much discussion misses the mark. :wink: