You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SOF logs show prints which are actually not errors #939
During suspend cycles and upon boot, we see some kernel logs as below even when there are no errors
[ 344.605545] sof-audio-pci 0000:00:1f.3: error: rx list empty but received 0x0
[ 446.001250] sof-audio-pci 0000:00:1f.3: firmware boot complete
In some cases, (we are yet to receive details from customer) the logs are very frequent.
is there recent change / fix to supress these msgs being flagged as error ?
Hi Pierre, yes you are right.
So i tested with latest upstream set and see the other 2 lines @ every suspend call and resume thereafter.
sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0
sof-audio-pci 0000:00:1f.3: firmware boot complete
I'm still checking with reporter which scenario are these coming frequently, but i wanted to know if we can suppress few of these or move it under debug.
@ranj063 thanks for correction. But can we improve this message , currently it shows as error, so lot of validation / triage starts from Audio for no reason :)
@sathyap-chrome I suppose we could change it to an info instead of an error, we're not really doing anything with the error anyway. @xiulipan@lyakh what do you think?
Also agreed, this may be shown as a notice or perhaps warning but no need to show as error as it doesn't normally impact the flow. I wonder whether this should be a verbose trace though (I think not?).
My Lenovo Thinkpad X1C7 running Ubuntu 20.04 has bee having this issue for a while, although I update my software regularly. I'm glad to provide more information, if this can help solve the issue.
My Lenovo Thinkpad X1C7 running Ubuntu 20.04 has bee having this issue for a while, although I update my software regularly. I'm glad to provide more information, if this can help solve the issue.
Ubuntu 20.04 is on old version of the kernel (5.4 IIRC). I think some fixes might need to be backported there, though if it doesn't impact proper functionality I doubt it's actually gonna be backported.
My Lenovo Thinkpad X1C7 running Ubuntu 20.04 has bee having this issue for a while, although I update my software regularly. I'm glad to provide more information, if this can help solve the issue.
Ubuntu 20.04 is on old version of the kernel (5.4 IIRC). I think some fixes might need to be backported there, though if it doesn't impact proper functionality I doubt it's actually gonna be backported.
Activity
plbossart commentedon May 14, 2019
This looks like an older version of SOF, maybe 2-3 month old already? we don't have this rx list anymore
sathyap-chrome commentedon May 14, 2019
Hi Pierre, yes you are right.
So i tested with latest upstream set and see the other 2 lines @ every suspend call and resume thereafter.
sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0
sof-audio-pci 0000:00:1f.3: firmware boot complete
I'm still checking with reporter which scenario are these coming frequently, but i wanted to know if we can suppress few of these or move it under debug.
xiulipan commentedon May 15, 2019
This should be rom reply message in DSP reset. We are still in discussion about how to make it look nicer.
sathyap-chrome commentedon May 15, 2019
Thanks xiulipan.
Will keep our issue tracker updated on the same
sathyap-chrome commentedon Jul 11, 2019
Hi @xiulipan These 2 prints come at every PCM open / close too.
So we do the below steps and evey cat will print these msgs twice.
Considering these are message reply of a success case, can we move it under debug ?
localhost /sys/devices/pci0000:00/0000:00:1f.3/ehdaudio0D2/widgets # while true; do cat 01/pcm_caps; sleep 1; date; done
[ 87.893276] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0
[ 87.984228] sof-audio-pci 0000:00:1f.3: firmware boot complete
0x00000000
Tue Jun 25 13:43:25 PDT 2019
0x00000000
Tue Jun 25 13:43:26 PDT 2019
0x00000000
Tue Jun 25 13:43:27 PDT 2019
[ 91.194438] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0
[ 91.285987] sof-audio-pci 0000:00:1f.3: firmware boot complete
0x00000000
Tue Jun 25 13:43:28 PDT 2019
0x00000000
Tue Jun 25 13:43:29 PDT 2019
0x00000000
Tue Jun 25 13:43:30 PDT 2019
[ 94.509771] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0
[ 94.601671] sof-audio-pci 0000:00:1f.3: firmware boot complete
0x00000000
Tue Jun 25 13:43:31 PDT 2019
0x00000000
Tue Jun 25 13:43:32 PDT 2019
ranj063 commentedon Jul 11, 2019
not really pcm open/close but really runtime resume and suspend. This happens once during FW boot every time you resume from runtime suspend.
sathyap-chrome commentedon Jul 11, 2019
@ranj063 thanks for correction. But can we improve this message , currently it shows as error, so lot of validation / triage starts from Audio for no reason :)
ranj063 commentedon Jul 11, 2019
@sathyap-chrome I suppose we could change it to an info instead of an error, we're not really doing anything with the error anyway. @xiulipan @lyakh what do you think?
sathyap-chrome commentedon Jul 11, 2019
sounds good.
kv2019i commentedon Nov 7, 2019
@ranj063 ++votes -- having a systematic false error printout in such a common flow is very bad.
paulstelian97 commentedon Nov 7, 2019
Also agreed, this may be shown as a notice or perhaps warning but no need to show as error as it doesn't normally impact the flow. I wonder whether this should be a verbose trace though (I think not?).
plbossart commentedon Nov 7, 2019
@keyonjie and @aiChaoSONG had a proposal to remove this error. It went nowhere I am afraid
keyonjie commentedon Nov 7, 2019
yes, it's here: #1189
@aiChaoSONG can you please proceed it?
wwittbrx commentedon Dec 11, 2019
Is there any update on this? This error has been corrupting logs for a long time now.
plbossart commentedon Jan 17, 2020
@keyonjie and @aiChaoSONG ping!
kv2019i commentedon Mar 19, 2020
This is now fixed with #1189 . Please reopen if still seen.
ggiuffre commentedon Sep 28, 2020
My Lenovo Thinkpad X1C7 running Ubuntu 20.04 has bee having this issue for a while, although I update my software regularly. I'm glad to provide more information, if this can help solve the issue.
paulstelian97 commentedon Sep 28, 2020
Ubuntu 20.04 is on old version of the kernel (5.4 IIRC). I think some fixes might need to be backported there, though if it doesn't impact proper functionality I doubt it's actually gonna be backported.
ggiuffre commentedon Sep 28, 2020
I see. Thank you for the prompt reply, Paul.
btrfs: zoned: fix deadlock on log sync