Re: Plans on 1.99 release - USB issues

[Aleš Nesrsta]

Hi Vladimir,

in fact nothing important changed from my previous e-mail, I have only
few information what I did.

I still have no progress with low-speed keyboard problem as I wrote in
last e-mail. Control transfers are working fine but interrupt transfer
fails even if I tried to send Clear Halt on interrupt pipe - it is not
possible, Clear Feature Halt returns STALL, i.e. Request Error as
described in USB specification.

USB specification says that low speed devices can communicate only via
control and interrupt pipes.
UHCI specification does not specify any difference between bulk and
interrupt TD - with one exception: "The software must schedule low speed
control transfers such that they are guaranteed to complete within the
current frame.". And, additionally, QH with interrupt transfers should
be placed in schedule as the first immediately after isochronous
transfer TDs.
But even I tried to place low speed interrupt transfer to QH with index
0, which is surely executed as the first QH in schedule, I had no
success.
I don't understand why it is not working, there must be something what I
am missing...


There is only one small positive information - probably thanks to your
changes it is now working one of USB mass storage devices which was not
working on UHCI root hub port (but worked on OHCI or non-root hub
connected to UHCI).


Unfortunately I have to cancel testing now because I must go out of home
for approx. two next weeks.

Regards
Ales

> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > > The issue was that we were using getStatus every time we polled for new
> > > devices which suposedly (I fixed few other bugs in the code I used at
> > > the time so, I'm not sure) drove hub in my USB keyboard crazy. The
> > > correct way is to poll interrupt pipe.
> > >   
> > Just to be clear: polling interrupt pipe on hub is what I have
> > implemented in keylayouts, just so you don't implement it again
> > > Another thing I added is the ability to do background transfers. It is
> > > important for USB keyboard support because otherwise we lose messages on
> > > keyboard interrupt pipe. It triggered a bug in uhci module. Now there
> > > are 2 issues:
> > > 1) code is new or modified. Needs testing.
> > > 2) On yeeloong the data read from mass storage is sometimes corrupted.
> > > Happens in mainline, not sure about other branches. It seems that it
> > > wasn't the case before. It's either a regression (perhaps from my code
> > > for partial transfers) or cache issues (some cache isn't correctly 
> > > flushed)
> > >   
> > >> Could I help You with it - at least with testing ?
> > >>   
> > >>     
> > > Yes, a test run of keylayouts branch on your hardware would be helpful.
> > > Especially I'm interested if USB data corruption happens in your case too.
> 
> Hi Vladimir,
> 
> I made some tests on machine with UHCI with kbdlayouts branch (rev.
> 2424).
> I did not notice any evident data corruption. But there were some
> another odd results:
> 
> 1.
> My USB keyboard is low speed device (Genius KB-06XE, model no. K639).
> Low speed device transfer was not properly handled - I made some simple
> patch - see attachment, I did not commit it into repository.
> Control type transfer with keyboard is working with this patch, but bulk
> (interrupt) transfer returns always err=7 and in UHCI TD status&control
> are set bits "CRC/Time Out Error" (bit 18) and "Stalled" (bit 22). It is
> the same behavior as some normal full speed mass-storage devices do also
> (I reported it in some previous e-mails). I have some idea right now -
> probably there is bad handling of UHCI transfer status in uhci.c when
> more than one bit is set - GRUB_USB_ERR_TIMEOUT is returned instead of
> GRUB_USB_ERR_STALL. I will try to play with this part during weekend and
> I will report to You if some success happens...
> 
> 2.
> Next bad thing is some problem with device attachment detection or
> handling of newly attached device on non-root hubs. Behavior of this
> problem looks little bit randomly and probably depends also on used port
> of hub - some ports are often working, some not (but all hub ports are
> working normally in Linux/Windows). I did not find reason yet.
> 
> 3.
> Sometimes partitions of USB mass storage devices were not properly
> detected - maybe disk cache problem again?
> Maybe it is data corruption which is reported by you - but I never
> detected data corruption when I read data from files.
> 
> ---
> I am not sure if interrupt transfers can be handled via bulk queue on
> OHCI - according specification, it should be handled via interrupt
> pointers table which is currently not implemented in ohci.c. Did you
> test background polling of interrupt pipe on some PC with OHCI?
> 
> ---
> At the end some maybe bad idea - if I am not wrong, two simultaneous
> transfers can happen (be active in UHCI/OHCI) with current background
> bulk/interrupt transfer. There is question if are all related functions
> fully reentrant ? I.e., is correct handling of some shared data ?
> For the first look I don't see such problem - with one exception:
> donehead interrupt can be probably incorrectly handled in ohci.c - it
> can be detected and misinterpreted by wrong call of
> grub_ohci_check_transfer. The first aid in this case can be forcing of
> OHCI driver into "bad OHCI" mode, i.e. donehead interrupt ignoring - in
> this mode it should work properly.
> 
> Regards
> Ales
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel