[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Seth Goldberg
Subject: Re: [Patch] [bug #26237] multiple problems with usb devices
Date: Sun, 30 May 2010 21:16:26 -0700 (PDT)
User-agent: Alpine 2.00 (GSO 1167 2008-08-23)

USB devices are notoriously difficult to get right. During development of USB device support (mainly mass-storage devices), we discovered numerous devices, usually super-cheap devices, that were not spec compliant or that didn't implement this-or-that command, etc. It's truly amazing that they work at all (they clearly only test on Windows, and that's all they care about). So prepare yourself for a LOT of working trying to figure this stuff out (or at least try to use Linux's implementation as a technical guide to avoid rediscovering all of this horribleness.


Quoting Vladimir 'φ-coder/phcoder' Serbinenko, who wrote the following on...:

Aleš Nesrsta wrote:
Hello, Aleš. I've seen that your assignment was completed. I added you
to grub contributors. Feel free to create a branch in branches/usb.
Right now I'm busy but next week I should be able to assist. Perhaps
even this week. Right now I send uncommitted changes sitting in my
yeeloongfw branch. It's largely your rebased changes + few other things
like shutting the controller down before booting OS to avoid memory used
by OS to be clobbered by e.g. HCCA.
Branch usb should contain pci improvements + your usb changes. If you
have trouble with bzr or are short on time me (or perhaps someone else)
can give a hand.
This branch can go into mainline. Since mainline usb is in deplorable
state there is no need to pass this changes through experimental at all.
Merging into mainline doesn't mean that no further developpement should
be done on usb, just that this part is already a huge improvement.

Remaining problems:

Some devices (at least my BUFFALO USB clip drive flash disk, more
precisely "ID 0ea0:2168 Ours Technology, Inc. Transcend JetFlash 2.0 /
Astone USB Drive") cannot transfer 4KB data blocks independent on
controller OHCI/UHCI - my workaround is not good.
But it is probably problem with low priority - device is working finally
but it is slower than another device.

Some devices (at least my APACER cardreader "ID 058f:6366 Alcor Micro
Corp. Multi Flash Reader") are not working on UHCI. Such device does not
accept any control message and UHCI returns status 0x450007 - it means
STALL during sending SETUP packet.
It looks to be the same problem as described by Vladimir: "I have
somewhat similar issue with Geode OHCI controller right now: devices and
speeds are correctly seen but trying to send a message results in a halt
in first TD and error code 5.".

The problem was that the port was plainly off due to Geode reaction on
incorrect writes differring from that of other controllers.
But I have problem on UHCI, not on OHCI - on computer with OHCI is this
device working well (it is normal USB Mass Storage Bulk-Only device with
SCSI subclass)! Maybe it depends on "combined controllers" UHCI-EHCI,
OHCI-EHCI (?) - device is working on computer with OHCI only computer
and it is not working on computer with UHCI-EHCI controller. But any
other device is working well on both computers... I don't understand, I
currently have no idea what can be wrong. Does anybody know...?

Does this device work under OS on this computer? Some ports are plainly
There is not working USB hub support, GRUB does not see device connected
via USB hub - does anybody know some details or have some specification
of USB Hub class ? I cannot find it on USB site (maybe I have not
sufficient patience...).

I will probably focus in OHCI speed-up now, i.e. I try to do some other
handling of ED to prevent changes in OHCI registers which are slowing
down OHCI performance (OHCI is approx. 3 times slower than UHCI now from
this reason).

How useful would the interrupts be for this matter? If the answer is
"very useful" I can implement them. Also we need some restructuring of
code of both ohci and grub in general to decrease the wait time. I think
specifically all the waits in init sequence. If system has 2 OHCI
controllers currently you need to wait twice as long as with 1
controllers while it's possible to init them in parallel and not wait
longer than in the case of one controller.

Best regards


Grub-devel mailing list

Vladimir 'φ-coder/phcoder' Serbinenko

reply via email to

[Prev in Thread] Current Thread [Next in Thread]