Re: eMMC CMDQ timeout issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/07/21 5:25 am, huyue2@xxxxxxxxxx wrote:
> hi Adrian,
> 
> I'm a developer of Linux mmc driver. I hope i'm not bothering you.
> I met an mmc CMDQ timeout issue in kernel-4.14 under Android MTK platform.

I can't help with old kernels, especially custom kernels.

I have cc'ed the kernel mmc mailing list because there are many people there that might be able to help.

> I never met this kind of issue before in projects.
> So i checked the related code and eMMC 5.1 standard(CMDQ) document. And find the below:
> 
> https://lore.kernel.org/linux-mmc/1500630584-22852-10-git-send-email-adrian.hunter@xxxxxxxxx/ <https://lore.kernel.org/linux-mmc/1500630584-22852-10-git-send-email-adrian.hunter@xxxxxxxxx/
> 
> Then i think the key point should be analyzing the CMDQ registers status firstly.
> 
> The timeout log i met as below:
> 
> ```log
> [384:kworker/2:1H]mmc0: request with tag: 25 flags: 0x103001 timed out
> [384:kworker/2:1H]cmdq-host: ========== REGISTER DUMP (mmc0)==========
> [384:kworker/2:1H]cmdq-host: Caps: 0x100020b6  | Version:  0x00000510
> [384:kworker/2:1H]cmdq-host: Queing config: 0x00001103  | Queue Ctrl:  0x00000000
> [384:kworker/2:1H]cmdq-host: Int stat: 0x00000000  | Int enab:  0x0000000f
> [384:kworker/2:1H]cmdq-host: Int sig: 0x0000000f  | Int Coal:  0x00000000
> [384:kworker/2:1H]cmdq-host: TDL base: 0x9ff97000  | TDL up32:  0x00000000
> [384:kworker/2:1H]cmdq-host: Doorbell: 0x3fffffff  | Comp Notif:  0x00000000
> [384:kworker/2:1H]cmdq-host: Dev queue: 0x00000000  | Dev Pend:  0x3fffffff
> [384:kworker/2:1H]cmdq-host: Task clr: 0x00000000  | Send stat 1:  0x00000040
> [384:kworker/2:1H]cmdq-host: Send stat 2: 0x00000001  | DCMD resp:  0x00000000
> [384:kworker/2:1H]cmdq-host: Resp err mask: 0xfdf9a080  | Task err:  0x00000000
> [384:kworker/2:1H]cmdq-host: Resp idx 0x0000000d  | Resp arg:  0x00000000
> [384:kworker/2:1H]cmdq-host: Vendor cfg 0x08001f0a

You really need to look at the SDHCI registers also because the command, arguments, response, IRQ status etc can give a clue to what went wrong.

You could also enable some dynamic debug messages

> ```
> 
> From /Doorbell/Dev Pend/, we can know the task 25 is already in eMMC queue.
> But task 25 is not ready to be executed by host in timeout since /Dev queue/ is zero.
> So the timeout issue should be eMMC side issue, am i right? 

I can't tell

> 
> Could you help to confirm my analysis if you will or correct me if i'm wrong?
> btw: several devices met the issue. I know it's a downstream issue.

If the issue does not happen with an upstream kernel, then you can either
try to bisect to get closer to when the issue went away, or try to determine
if your kernel is missing any upstream fixes.

> 
> Thanks in advance.
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> huyue2@xxxxxxxxxx





[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux