RE: [EXT] Re: [PATCH 2/2] usb: ehci: unlink itd/sitds from hardware list if the controller has stopped periodic schedule

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

 



Hi Alan,

> On Tue, Jul 18, 2023 at 07:26:00PM +0800, Xu Yang wrote:
> > In current design, the ehci driver will not unlink itd/sitds from the
> > hardware list when dequeue isochronous urbs. Rather just wait until they
> > complete normally or their time slot expires. However, this will cause
> > issues if the controller has stopped periodic schedule before finished
> > all periodic schedule. The urb will not be done forever in this case and
> > then usb_kill/poison_urb() will always wait there.
> >
> > The ChipIdea IP exactly has a bug: if frame babble occurs during periodic
> > transfer, PE (PORTSC.bit2) will be cleared and the controller will stop
> > periodic schedule immediately. So if the user tries to kill or poison
> > related urb, it will wait there since the urb can't be done forever.
> >
> > This patch will check if this issue occurs, then it will unlink itd/sitds
> > from the hardware list depends on the result.
> 
> This is not the right approach.  There already is code in the driver for
> unlinking itds/sitds when the periodic schedule isn't running: See how
> the "live" variable is used in scan_isoc().  You don't need to add new
> code to do the same thing, you simply have to make sure that live is set
> to false if the controller has stopped the periodic schedule
> unexpectedly.
> 
> (Be very careful about handling the case where CMD_PSE is set and
> STS_PSS is clear.  This can happen when the controller has been told to
> start the periodic schedule but it hasn't done so yet.)

Many thanks for your comments and suggestions.

Yes, there is a "live" variable in scan_isoc() to handle the case where
root hub has stopped periodic schedule. I have rechecked the root cause
of the issue , that is the USB controller has disabled the port (PE cleared)
and asserted USBERRINT when frame babble is detected, but PEC is not
asserted. Therefore, the SW didn't aware that port has been disabled. 
The periodic schedule keeps running at this moment. Then the SW keeps
sending packets to this port, but all of the transfers will fail. But periodic
schedule will also be disabled after a period of time. Finally, all of the linked
itds are penging there. The code can't enter into scan_isoc() if only USBERRINT
is asserted.

For this issue, I think the SW needs to aware that the port has been disabled
although PEC not asserted by HW. I will send another patch to fix this issue
later.

Thanks,
Xu Yang 

> 
> Alan Stern




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux