From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L5hV3-0003wl-4f for qemu-devel@nongnu.org; Thu, 27 Nov 2008 09:05:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L5hV0-0003wD-Kk for qemu-devel@nongnu.org; Thu, 27 Nov 2008 09:05:43 -0500 Received: from [199.232.76.173] (port=58643 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L5hUx-0003vm-RB for qemu-devel@nongnu.org; Thu, 27 Nov 2008 09:05:40 -0500 Received: from nf-out-0910.google.com ([64.233.182.191]:61718) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L5hUx-00060r-74 for qemu-devel@nongnu.org; Thu, 27 Nov 2008 09:05:39 -0500 Received: by nf-out-0910.google.com with SMTP id b2so556925nfb.12 for ; Thu, 27 Nov 2008 06:05:37 -0800 (PST) Message-ID: <43d6ff410811270605p61259au5f3101f97bedf288@mail.gmail.com> Date: Thu, 27 Nov 2008 15:05:36 +0100 From: "Thomas Bandelier" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16957_25927.1227794736708" Subject: [Qemu-devel] USB-OHCI / UHCI: Isochronous transfer not working on Linux host Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: arnon.gilboa@qumranet.com, lemagoup@gmail.com ------=_Part_16957_25927.1227794736708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, Following several tests we did with qemu trunk, Isochronous transfer seems to be broken with the head of qemu. We tried following Os (targets): -WinXP (i386) -Win2k (i386) -Several linux kernel ( 2.6.26-1 (i386), 2.6.27 (ARM) ) On our host we are using Gentoo with 2.6.23 and 2.6.27 kernel. Following USB devices were tested: -USB 2.0 logitech webcams -Terratec USB2.0 Cynergy hybrid XS FM tuner. Both OHCI and UHCI configurations were tested in i386 target. Only OHCI was tested in ARM target. In all these configurations, it was *never* possible to initiate isochronous USB transfer. It was possible to enumerate the devices but as soon as isochronous packets were used, the procedure failed. It means for example that no picture was retrieved from the webcams, and no audio data was retrieved from FM tuner. It is important to mention that all theses devices perfectly work on our host. After some search in this maling list archives, it seems that no work has been made on these aspects since Arnon Gilboa sent some patches more than one year ago. Am I wrong? So It would be very useful for us to have a feedback from the community on this point. Has someone met the same problems? Has someone investigated this aspect? Is someone regularly using this feature? How can we investigate this problem? Thanks Thomas ------=_Part_16957_25927.1227794736708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

Following several tests we did with qemu trunk, Isochronous transfer seems to be broken with the head of qemu.

We tried following Os (targets):
-WinXP (i386)
-Win2k (i386)
-Several linux kernel ( 2.6.26-1 (i386), 2.6.27 (ARM) )

On our host we are using Gentoo with 2.6.23 and 2.6.27 kernel.

Following USB devices were tested:
-USB 2.0 logitech webcams
-Terratec USB2.0 Cynergy hybrid XS FM tuner.

Both OHCI and UHCI configurations were tested in i386 target.
Only OHCI was tested in ARM target.

In all these configurations, it was never possible to initiate isochronous USB transfer. It was possible to enumerate the devices but as soon as isochronous packets were used, the procedure failed. It means for example that no picture was retrieved from the webcams, and no audio data was retrieved from FM tuner.

It is important to mention that all theses devices perfectly work on our host.

After some search in this maling list archives, it seems that no work has been made on these aspects since Arnon Gilboa sent some patches more than one year ago. Am I wrong?

So It would be very useful for us to have a feedback from the community on this point.
Has someone met the same problems? Has someone investigated this aspect?
Is someone regularly using this feature?

How can we investigate this problem?

Thanks

Thomas












------=_Part_16957_25927.1227794736708--