[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: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [Patch] [bug #26237] multiple problems with usb devices
Date: Mon, 31 May 2010 14:23:05 +0200
User-agent: Mozilla-Thunderbird (X11/20091109)

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> 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.
I've created a branch "usb" where I put all the yeeloong work and
previous version of your patch. Could you merge your latest patch into
it and test the whole on your systems?
>> Remaining problems:
>> 1.
>> 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.
> Agreed
>> 2.
>> 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
> underpowered.
>> 3.
>> 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
>> Ales
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden

Vladimir 'φ-coder/phcoder' Serbinenko

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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