Re: Fwd: USB DBC hang during earlyprintk initialization

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 10/16/25 17:31, Milan Oravec wrote:
> Hello Mathias
> 
> On Thu, Oct 16, 2025 at 3:42 PM Mathias Nyman
> <mathias.nyman@linux.intel.com> wrote:
>>
>> On 10/15/25 22:11, Milan Oravec wrote:
>>> Hello Greg,
>>> thank you for looking into it.
>>>
>>> On Wed, Oct 15, 2025 at 11:13 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> On Wed, Oct 15, 2025 at 09:43:02AM +0200, Milan Oravec wrote:
>>>>> Hello, I'm trying to debug some hibernation related problems on my
>>>>> system, and need a USB DBC to see what is going on after screen off.
>>>>> I've connected USB debugging cable and got this error:
>>>> [St okt 15 20:57:24 2025] Linux version 6.17.3 (migo@migoG17) (gcc
>>> (GCC) 15.2.1 20250813, GNU ld (GNU Binutils) 2.45.0) #55 SMP
>>> PREEMPT_DYNAMIC Wed Oct 15 19:24:41 CEST 2025
>>> [St okt 15 20:57:24 2025] Command line: BOOT_IMAGE=/vmlinuz
>>> root=UUID=584262b6-b020-4e4f-95a3-1db754e28b6c earlyprintk=keep,xdbc1
>>> debug ignore_loglevel sysrq_always_enabled
>>> force_early_printk sched_verbose ft usbcore.autosuspend=-1
>>> no_console_suspend hib_compression=lz4
>>> resume=UUID=54ed98b5-56c0-4ab9-95ea-da1a9322ce49
>>> [St okt 15 20:57:24 2025] BIOS-provided physical RAM map:
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x0000000000000000-0x000000000009ffff] usable
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x00000000000a0000-0x00000000000fffff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x0000000000100000-0x0000000009afefff] usable
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x0000000009aff000-0x0000000009ffffff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000000a000000-0x000000000a1fffff] usable
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000000a200000-0x000000000a211fff] ACPI NVS
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000000a212000-0x000000008e43dfff] usable
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000008e43e000-0x000000009443dfff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000009443e000-0x000000009453dfff] ACPI data
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000009453e000-0x000000009653dfff] ACPI NVS
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000009653e000-0x000000009a5fefff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000009a5ff000-0x000000009bffafff] usable
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000009bffb000-0x000000009cffffff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000009d7f3000-0x000000009fffffff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x00000000f0000000-0x00000000f7ffffff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x00000000fd000000-0x00000000ffffffff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x0000000100000000-0x0000000837ffffff] usable
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x0000000838000000-0x0000000857ffffff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x0000000858000000-0x000000085de7ffff] usable
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000085eec0000-0x00000008801fffff] reserved
>>> [St okt 15 20:57:24 2025] BIOS-e820: [mem
>>> 0x000000fd00000000-0x000000ffffffffff] reserved
>>> [St okt 15 20:57:24 2025] xhci_dbc:early_xdbc_parse_parameter: dbgp_num: 1
>>> [St okt 15 20:57:24 2025] ------------[ cut here ]------------
>>> [St okt 15 20:57:24 2025] WARNING: CPU: 0 PID: 0 at
>>> mm/early_ioremap.c:139 __early_ioremap+0xae/0x190
>>
>> This WARN in __early_ioremap() is triggered when the size is too large
>>
>>          /*
>>           * Mappings have to fit in the FIX_BTMAP area.
>>           */
>>          nrpages = size >> PAGE_SHIFT;
>>          if (WARN_ON(nrpages > NR_FIX_BTMAPS))
>>                  return NULL;
>>
>> The size is in this case read from the PCI config space of the second xHCI PCI
>> controller.
>>
>> Maybe the controller returns odd BAR Address0 size, or we parse it incorrectly.
>>
>> what does "lspci -vv -d ::0c03:30" show?
> 
> Here is requested output:
> 
> root@migoG17:/home/migo# lspci -vv -d ::0c03:30
> 07:00.0 USB controller: ASMedia Technology Inc. Device 242c (rev 01)
> (prog-if 30 [XHCI])
>          Subsystem: ASUSTeK Computer Inc. Device 20af
>          Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>          Latency: 0, Cache Line Size: 64 bytes
>          Interrupt: pin A routed to IRQ 25
>          IOMMU group: 20
>          Region 0: Memory at fc600000 (64-bit, non-prefetchable) [size=32K]

The first xHCI reports size=32K

> 
> 09:00.3 USB controller: Advanced Micro Devices, Inc. [AMD]
> Raphael/Granite Ridge USB 3.1 xHCI (prog-if 30 [XHCI])
>          Subsystem: ASUSTeK Computer Inc. Device 20af
>          Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
>          Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>          Latency: 0, Cache Line Size: 64 bytes
>          Interrupt: pin D routed to IRQ 48
>          IOMMU group: 24
>          Region 0: Memory at fc300000 (64-bit, non-prefetchable) [size=1M]
And the second xHCI has size 1M

Best guess is that early_ioremap() doesn't support this large size.

-Mathias