Re: USB umass hard drive "failed to create xfers" when attaching

[sc.dying%gmail.com@localhost]

On 2020/03/20 07:21, Nick Hudson wrote:
> 
> 
> On 19/03/2020 09:19, sc.dying%gmail.com@localhost wrote:
>> On 2020/03/19 07:10, Nick Hudson wrote:
>>> On 19/03/2020 07:05, sc.dying%gmail.com@localhost wrote:
>>>> On 2020/02/17 21:33, Nick Hudson wrote:
>>>
>>> [snip]
>>>
>>>>> xhci could do better and support multiple DMA segments, but uvm could
>>>>> also help.
>>>>
>>>> To access each DMA segment in usb_dma_t *dma, should it be processed
>>>> like this?
>>>>
>>>> for (i = 0; i < dma->udma_block->nsegs; i++) {
>>>>     bus_dma_segment_t *ds = &dma->udma_block->map->dm_segs[i];
>>>>
>>>>     process_segment(ds->ds_addr, ds->ds_len);
>>>> }
>>>
>>> I started looking into this and have some changes to fix [ou]hci.
>>> xhci and dwc2 seem to be a bit harder.
>>
>> dwc2 is a Greek to me.
> 
> It's quite involved as the HC is pretty dumb, but I think it's well written.
> 
> 
>>
>>> http://src.illumos.org/source/xref/netbsd-src/sys/dev/usb/ehci.c#3011
>>>
>>> Is how ehci currently does it.
>>
>> I've read that part of echi, but I cannot make me understood completely.
>> Does ehci always split the transfer into 4kB chunks even
>> it is physically contiguous?
> 
> That function creates a list of transfer descriptors (TDs) for the xfer
> buffer/length required.  Each ehci TD can handle 5 ehci pages[*] worth
> of buffer.  For each page in the TD we can pass the DMA address and so
> it doesn't matter if the physical memory is contigous or not.
> 
> [ou]hci are very close to being correct, but need a couple of tweaks to
> make sure i) that there are enough TDs and ii) misaligned buffers (wrt
> page boundaries) get handled properly.
> 
> Nick
> 
> [*]  It just so happens that ehci page is 4KB like most arches.

Thank you for your detailed explanation.
How ehci works for multiple segment DMA differs from what I tries to do for xchi.
The xhci.c has to learn it.