Re: [Patch] [bug #26237] multiple problems with usb devices

[Aleš Nesrsta]

Hi Vladimir and others,

first of all thanks for immediate advice about Bazaar.

Attached is the usb patch related to OHCI and USB MS (SCSI).
(There is also very small patch for uhci.c - it signals in debug print
failed transaction even if it finished correctly.)
Patch is done against Bazaar source revision 2391 but.
I checked if files changed by me were changed by somebody other between
version 1.98 and current Bazaar revision - it looks like none of files
was changed in the meantime. So, in fact the patch should work also
against 1.98 release.

I partially cleaned some parts of code before making diff, I hope I did
not any mistake - I very shortly tested this patch and it looks OK.

There is lot of changes in many files - unfortunately some general
things was necessary to change.
(Some solutions could be made better maybe - I made the first simple
solutions, first ideas, to make things go on...)

Changes are (sometimes...) commented to clarify why it was done (and
what...). There are (I hope) no exact citations from specifications but
some keywords in comments are the same as in OHCI (or another)
specification - it is done only to "speak by the same language" and it
could be removed.

In patch remains some added or extended debug prints - You can delete
them.
I have them still in my source because I will probably sooner or later
continue in "researching" mainly in these directions:
- Why STALL (or maybe NAK?) is not properly indicated on OHCI (at least
on my computer) and instead of it timeout occurs (or hang in old source,
before timeout was added).
- OHCI can switch itself into Unrecoverable Error in some cases - it
should be detected and recovered by some reset
- Some devices are not working on UHCI
- UHCI is not working properly when module is removed and inserted again
- Maybe in future I change EDs into more "static" allocation - because
there is too big performance penalty with safe EDs and TDs allocation
and setup in OHCI registers and then reseting in OHCI registers and
deallocation of them - we should wait twice for SOF, i.e we lost approx.
2ms per each USB access. In suggested example of OHCI driver in OHCI
specification are EDs allocated permanently (whole time of driver
activity, not only on communication time) - it should improve speed of
OHCI because we will not need to change ED addresses in registers on
OHCI and we will not have to wait for SOF more.

Some members in SCSI command structures I changed and named according to
their role - only to have better overview of functions and values set in
related SCSI functions, I don't insist on usage of these names...

Maybe it is not fully true the comment "Each SCSI command should be
followed by Request Sense. If not so, many devices STALLs or definitely
freezes.". I discovered it in time when also some others bugs were not
solved and maybe it is not necessary in many cases, who knows...? But I
dont have sufficient patience to do such deep testing (every command on
every device...).

I found at home one device which has another USB MS subclass -
SFF-8070i. I tried to look into specifications of other subclasses than
SCSI and I discover that all of them are SCSI based and with exception
of QIC-157 (which is tape oriented) all should have implemented basic
SCSI command which are used in GRUB. There is only one thing which can
cause incompatibility - ATAPI SCSI commands must have size of command
block length set to 12 bytes (instead of variable length 6,8,10,...
defined in "normal" SCSI). It could make troubles on SCSI subclass
devices but I tried all my devices with SCSI subclass with
ATAPI-compatible length of command and all devices are working normally
- so I think it should be safe to use ATAPI format of commands
universally for any subclass and I tried to "add support" for most of
USB MS subclasses - in fact I only extended one condition in usbms.c...
I did not testing devices subclasses RBC, UFI and MMC-2 - I don't have
such devices - can do somebody such tests ?

Tests and "researching" were made on 10 devices, all of them are working
now (3 USB flash disks, 3 cameras - problem with control packet max.
length and also another subclass support, 1 USB external disk, 1
universal card reader "21 in one" - problem with more LUNs, 1 SDHC card
reader, 1 mobile phone - problem with "the same" enpoint numbers 01 & 81
and toggling of bulk transfer).

There is also potential problem with powering and current GRUB USB
"philosophy" - unfortunately, USB bus is enumerated in time when OHCI
module is loaded and activated.
It can make trouble on PC where it is necessary to do "SMM ownership
change" - which results (on my computer) in power-off and power-on of
USB bus - or on computers which have not powered USB bus before OHCI
module is loaded. Many devices has very long time between powering of
then and proper function on USB bus - it could be also problem of
Yeeloong.
But currently I have no idea how to solve it in GRUB. In "normal" OS the
registering of new USB device (enumerating) is done probably via
interrupt from hub port status change when newly attached USB device
becomes really ready. But in GRUB we cannot do such solution. What we
can do now is:
- set longer waiting period after powering of USB bus
- "rmmod usbms" (if loaded), "rmmod ohci", connect device and wait for
when becomes ready, "insmod ohci", "insmod usbms" (this sequence does
not work on UHCI, I currently don't know why).

Best regards
Ales


P.S. I received e-mails from Vladimir today, there are my quick
reactions:

Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> > What I was not solved till now:
> > - Some devices are not working on UHCI
> > - If I connect some device and load uhci module, I cannot connect
> > another device without rebooting. On OHCI it is possible without
> > rebooting in this sequence:
> >     rmmod usbms
> >     rmmod ohci
> >     (unplug old device and plug new one)
> >     insmod ohci
> >     insmod usbms
> >   
> In my yeeloongfw branch I have hotplug support for ATA. I'm planning on
> adding usbms hotplugging support but first I want to make Geode USB work.

I will look into yeeloongfw branch, I got Bazaar working yesterday
evening only... I agree with You, first should be solved known problems
on simple base.
Unfortunately, I probably cannot help You as I don't have GEODE or
Yeeloong... I can hope only that my corrections would help You or
inspire You in some other ways.
For me were very "disgusting", unexpected and hard to find problems with
short max. packet size on control pipe and problem with toggling bulk
transfers when EP have numbers 0x01 and 0x81.

> > - It looks like my OHCI is not properly reporting STALL state of pipe -
> > it is probably reason why done-head loop hanged if some problem happened
> > in communication.
> >   
> In general there should be timeout in any loop which may hang if device
> doesn't behave the way it's supposed to.

> The fixes I've come up with are available in yeeloongfw branch. I've
> adjusted your previous patch to work on top of yeeloongfw branch.

I implemented also such timeouts independently, You can use finally the
better solution...
But the timeout probably should never happen if all is programmed well,
so probably there is still something bad somewhere...


Vladimir 'φ-coder/phcoder' Serbinenko wrote: 

> > I also find that my concept is sometimes not working well, so there is
> > probably some bug (at least the one what it is mentioned in previous
> > sentence). But still I think the my way could be better and more closed
> > to specification and suggested OHCI control then original algorithm
> > which was probably taken from (or inspired by) UHCI - for example OHCI
> > is more "intelligent" than UHCI, because it takes done TDs and puts them
> > into "done queue" - and because it is working asynchronously it can be
> > done later then in time of transaction end detection in the way by
> > comparison head TD and last TD - it can be source of possible hazard.
> >   
> AFAIR According to spec if  these values are the same queue is empty.
> 
Yes, but there is question WHEN it is done. OHCI HC is doing things
sequentially (and in parallel with CPU via DMA). OHCI HC is doing so
called "retiring" of TDs AFTER values in ED are the same. I.e., when You
detect the same value in ED and make deallocation of ED and TDs, OHCI
can do something in TDs memory location at this time. "Retiring finish"
signaled by interrupt from DoneHead should be the LAST thing which OHCI
HC is doing, so it is more safe to use it - and such interrupt is used
by driver in Linux and Windows also (as it is in example in OHCI
specification).

But if You have better results with the old style of transfer end
detection, it is signal that I have still something wrong in my code -
maybe it is related to problem with mising STALL or NAK indication from
OHCI (or possibly also Unrecoverable error state).
Or it can be also some HW bug - when You look into Linux USB drivers
source code, You will find some workarounds related to HW "specialites"
of some OHCI chips...

> > Also I tested influences of BIOS settings - USB 2.0 can be enabled in
> > BIOS but "Legacy support" makes mostly troubles (but it depends on used
> > computer, there are probably many variations... - for example on my
> > computer with UHCI "Legacy Support" means also "USB booting support" but
> > on second computer with OHCI "Legacy Support" means keyboard&mouse
> > support only and unfortunately it is done in another way than it is
> > written in OHCI Legacy Support specification...).
> > Question - how can BIOS influence GRUB2 ? Are somewhere in GRUB2
> > callings of BIOS functions or something like that ? Can BIOS do
> > something via its previously claimed interrupts (which are all disabled
> > in GRUB2 - if I good understand) ?
> >   
> This legacy support is real trouble because it uses SMI which are colled
> e.g. on register writes. In specifications you can find the expected
> handoff BIOS->OS protocol but not all BIOSes implement it correctly. You
> can have a look at my mail a while ago entitled " [PATCH] reset USB
> controller".
I did not noticed this mail, I will look into it - I made also some
simple workaround in OHCI initialization function but I don't know if it
is correct. Another bad thing is also re-powering of USB bus which I
mentioned above.

Best regards
Ales

usb_patch_100523_0
Description: Text Data