On Wed, 30 Dec 2020 19:12:46 +0100
Marcus Glocker <[email protected]> wrote:

> On Wed, 30 Dec 2020 16:16:06 +0000
> Mikolaj Kucharski <[email protected]> wrote:
> 
> > On Tue, Dec 29, 2020 at 03:03:06PM +0100, Marcus Glocker wrote:  
> > > On Mon, 28 Dec 2020 20:55:33 +0000
> > > [email protected] wrote:    
> > ...  
> > > > >Fix:      
> > > >         Per email threads on tech@ from above marc.info links
> > > > below is not proper solution, but a workaround:
> > > > 
> > > > --8<--
> > > > Index: dev/usb/ugen.c
> > > > ===================================================================
> > > > RCS file: /cvs/src/sys/dev/usb/ugen.c,v
> > > > retrieving revision 1.109
> > > > diff -u -p -u -r1.109 ugen.c
> > > > --- dev/usb/ugen.c      25 Dec 2020 12:59:52 -0000
> > > > 1.109 +++ dev/usb/ugen.c        27 Dec 2020 22:38:59 -0000
> > > > @@ -441,6 +442,7 @@ ugen_do_close(struct ugen_softc *sc, int
> > > >                 DPRINTFN(5, ("ugenclose: endpt=%d dir=%d
> > > > sce=%p\n", endpt, dir, sce));
> > > >  
> > > > +               usbd_clear_endpoint_stall(sce->pipeh);
> > > >         /* MMM */ usbd_close_pipe(sce->pipeh);
> > > >                 sce->pipeh = NULL;
> > > >      
> > > > -->8--      
> > > > 
> > > > It makes my scanner work reliably. There is still a second
> > > > problem metioned by me in
> > > > https://marc.info/?t=160672895400002&r=1&w=2 but that's
> > > > different issue.
> > > > 
> > > > However my question would be, any idea how to proceed from where
> > > > I am at the moment? Any clues?
> > > > 
> > > > I've also CC'ed Natasha as she may be interested in this thread,
> > > > as she was the one who started email threads from above
> > > > marc.info URLs.    
> > > 
> > > I'll try to reproduce this issue here, but at the moment scanimage
> > > doesn't like my EPSON ET-2750 too much ...    
> > 
> > Maybe you are facing what I'm seeing on my end (separete issue to
> > this one reported in this email thread), is that timeout is a bit
> > too low in sane-backends for my scanner. By default sane-backends
> > has 1000ms timeout, but I see that about 3000ms for my scanner works
> > better.
> > 
> > With default 1 second timeout scanimage would fail a lot with
> > following error:
> > 
> >     scanimage: sane_read: Error during device I/O
> > 
> > Below diff is for sane-backends port, which I'm using for testing
> > and I specify `export SANE_CUSTOM_LIBUSB_TIMEOUT=3000` before
> > starting scanimage, to set 3 seconds timeout.
> > 
> > Not sure are you having same issue, maybe it will help you.  
> 
> Sorry, I was not clear;  I meant to say that 'scanimage -L' isn't
> recognizing my EPSON ET-2750 device at all.  But in the meantime I
> could get my hands on a CANON CanoScan LiDE 400, which gets
> recognized, and it looks like I see similar issues like you do.
> Based on that I can do some further investigations.

It looks like with xhci(4) for some reason the bulk endpoints are
stalling after some operations, which isn't happening with ehci(4).  I
currently can't see why this happens only with xhci(4).  That's why
on your second attempt you see the timeouts happening, because the bulk
endpoints still are in a stalled state.

Using usbd_clear_endpoint_stall() at the pipe closing routine simply
resets all the endpoints, which is why on the next attempt the
transfers are working fine again.  That's probably why this was called
a workaround, because we should understand why the endpoints are
getting stalled in a first line with xhci(4).

I can't tell why the issue disappears on your end when you use
debugging printfs in xhci_device_generic_start().  Looks like a
timing thing.  If you like you can share your xhci(4) debugging diff,
and I'll check if I can see the same effect here.

Btw., my CANON CanoScan LiDE 400 also can't scan on ehci(4), even
though the sane-backends homepage states it's fully supported.  It
looks like people on Linux see the same issue with this device.

https://gitlab.com/sane-project/backends/-/issues/366
https://gitlab.com/sane-project/backends/-/issues/412

Reply via email to