NetBSD-Bugs archive

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

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



On 26/11/2019 14:45, Andreas Gustafsson wrote:
The following reply was made to PR kern/54070; it has been noted by GNATS.

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


Home | Main Index | Thread Index | Old Index