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 > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel >
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
