Re: Plans on 1.99 release - USB issues

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 09/04/2010 12:02 AM, Aleš Nesrsta wrote:
> 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.
>
>   
Perhaps has something to do with port number. Or perhaps unlike mine
your router doesn't send initial device status change.
> 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?
>   
I could use USB keyboard just fine on Yeeloong.
> ---
> 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.
>   
It might have been the reason of yeeloong data corruption
> Regards
> Ales
>
>   
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature