public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: lurenjianullptr@yeah.net
To: devel@edk2.groups.io
Subject: There is a low probability that the XhciDxe will ASSERT
Date: Mon, 21 Feb 2022 10:33:46 +0800 (CST)	[thread overview]
Message-ID: <1b9294ea.404.17f1a20ba97.Coremail.lurenjianullptr@yeah.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 2232 bytes --]

Hi all,


Please check the Xhci log below. There's a low probability that the Xhci module will assert during a machine startup.


[20220210_16:41:22:796]        UsbHcGetHostAddrForPciAddr-forloop: Block->Buf = 0xF8B4C000, Block->BufLen = 0x10000
[20220210_16:41:22:796]UsbHcGetHostAddrForPciAddr: Enters with Mem = 0xF8B4FFD0, Size = 0x10
[20220210_16:41:22:807]        UsbHcGetHostAddrForPciAddr-forloop: Block->Buf = 0xF8B4C000, Block->BufLen = 0x10000
[20220210_16:41:22:807]UsbHcGetHostAddrForPciAddr: Enters with Mem = 0xF8B4FFE0, Size = 0x10
[20220210_16:41:22:816]        UsbHcGetHostAddrForPciAddr-forloop: Block->Buf = 0xF8B4C000, Block->BufLen = 0x10000
[20220210_16:41:22:848]UsbHcGetHostAddrForPciAddr: Enters with Mem = 0xF8B4FFF0, Size = 0x10
[20220210_16:41:22:849]        UsbHcGetHostAddrForPciAddr-forloop: Block->Buf = 0xF8B4C000, Block->BufLen = 0x10000
[20220210_16:41:23:314]Stop Slot = 1,Dci = 1
[20220210_16:41:23:314]XhcStopEndpoint: Slot = 0x1, Dci = 0x1
[20220210_16:41:23:322]UsbHcGetHostAddrForPciAddr: Enters with Mem = 0xF8B40000, Size = 0x10
[20220210_16:41:23:322]        UsbHcGetHostAddrForPciAddr-forloop: Block->Buf = 0xF8B4C000, Block->BufLen = 0x10000
[20220210_16:41:23:359]ASSERT [XhciDxe] /home/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c(306): (Block != ((void *) 0))


An expert think the issue is that one/more allocated transfer ring for a endpoint crosses the 64K-byte boundary.


When the TRB consumption in the transfer ring is about to cross the 64K-byte boundary (address 0xF8B4FFF0), the timeout happens.
And the expected subsequent TRB consumption should be address 0xF8B50000, but instead address 0xF8B40000 is returned from the Event Ring.


Since in the XHCI spec, it mentions in Section 4.9 that:
TRB Rings may be larger than a Page, however they shall not cross a 64K byte boundary. Refer to section 4.11.5.1 for more information on TRB Rings and page boundaries.

The expert’s suggestion is that somebody can help to add logic (maybe in UsbHcAllocateMem()) to ensure that the allocated memory for TRB Rings will not cross 64K-byte boundary. 


I'm not familiar with XHCI Spec and don't know how to solve it. 


I want to report the issue first and hope somebody can help me.



[-- Attachment #2: Type: text/html, Size: 6587 bytes --]

                 reply	other threads:[~2022-02-21  2:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1b9294ea.404.17f1a20ba97.Coremail.lurenjianullptr@yeah.net \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox