Re: kern/54070: urtwn(4) does not work on OHCI

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

The following reply was made to PR kern/54070; it has been noted by GNATS.

From: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
To: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
 Andreas Gustafsson <gson%gson.org@localhost>
Cc: 
Subject: Re: kern/54070: urtwn(4) does not work on OHCI
Date: Tue, 26 Nov 2019 20:35:27 +0000

 On 26/11/2019 14:45, Andreas Gustafsson wrote:
 > The following reply was made to PR kern/54070; it has been noted by GNAT=
 S.
 >
 > From: Andreas Gustafsson <gson%gson.org@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: kern/54070: urtwn(4) does not work on OHCI
 > Date: Tue, 26 Nov 2019 16:42:26 +0200
 >
 >   Investigating this with a USB protocol analyzer showed that the
 >   first USB bulk IN transfer processed by urtwn_rxeof() was correct,
 >   but in the second transfer, the first 64 bytes were missing from
 >   the data received by urtwn_rxeof() even though they were present
 >   on the wire.
 >
 >   I believe what is happening is that the first transfer ends with a
 >   zero-length packet, which is expected.  The code path in the OHCI
 >   driver that handles short transfers then resets the TD Queue Head
 >   Pointer in the Endpoint Descriptor by writing the entire 32-bit word
 >   containing it, which has the desired side effect of clearing the
 >   Halted bit, but also the undesired side effect of clearing the
 >   toggleCarry bit.  If the first packet of the next transfer then
 >   happens to have a data toggle of "1", it is considered to have a
 >   toggle mismatch and is ignored, causing one packet's worth of data
 >   (64 bytes) to be lost.  The following packet then has the expected
 >   toggle and the remainder of the transfer is received normally.
 >
 >   With the following patch, urtwn at ochi works much better. I intend
 >   to commit it soon unless someone has a really good objection.
 
 The patch adjusts the "endpoint is halted" error handling code path.
 
 http://src.illumos.org/source/xref/netbsd-src/sys/dev/usb/ohci.c#1500
 
 What is the error code OHCI_CC_DATA_UNDERRUN?
 
 Maybe OHCI_TD_R should be used more?
 
 http://src.illumos.org/source/xref/netbsd-src/sys/dev/usb/ohci.c#666
 
 Nick