On Wed, Mar 01, 2006 at 08:51:19PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 19:30:16 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> > On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
> > > On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> > >
> > > > Its
On Wed, 1 Mar 2006 19:30:16 -0800, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
> > On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> >
> > > Its response to #11 is what is
> > > broken. It may be getting confused by
A new version of "usbutils" is available from the linux-usb download
area at SourceForge.net:
http://sourceforge.net/project/showfiles.php?group_id=3581&package_id=142529
Changes since 0.71 are in the release notes; notably, removing "usbmodules"
(distros using 2.4 kernels should use older usbu
On Wed, Mar 01, 2006 at 07:30:16PM -0800, David Brownell wrote:
> The thing to understand about test #10 is that it's _trying_ to do things
> that UDC drivers often get wrong. Trying to trigger races ("both events
> in one IRQ"), trying to issue back-to-back faults so that improper cleanup
> of on
On Wed, Mar 01, 2006 at 07:16:26PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 18:44:11 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400
> > 0002ff00 00fa0705 02024000 00070581 0240
> > e2372840 1612603151 S Ci:009:00
On Wed, Mar 01, 2006 at 07:16:26PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 18:44:11 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400
> > 0002ff00 00fa0705 02024000 00070581 0240
> > e2372840 1612603151 S Ci:009:00
On Wednesday 01 March 2006 5:53 pm, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > Its response to #11 is what is
> > broken. It may be getting confused by the second status request *or*
> > it may have sent the STALL (is that the -32?) befor
From: John Zaitseff <[EMAIL PROTECTED]>
The following patch to Linux kernel 2.6.16-rc5 enables the extra
keys found on the Microsoft Natural Ergonomic 4000 USB keyboard. I
had to add a number of keycodes to include/linux/input.h; feel free
to reallocate IDs assigned to these new keys.
Main chang
On Wed, 1 Mar 2006 18:44:11 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400 0002ff00
> 00fa0705 02024000 00070581 0240
> e2372840 1612603151 S Ci:009:00 s 80 06 0200 0400 1024 <
> So, how can this happen? Am I seeing
On Wed, 1 Mar 2006 18:36:57 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>0:33.300555 # 16 s> Ci 009:00 s 80 06 0200 0400 ( DtH st dv
> GET_DESCRIPTOR [CONFIGURATION 0] ) --- 1024 <
> ...
>0:33.322552 # 16 0002ff00 00fa0705 02024000 00070581 0240
>
> What is the -121?
I do n
I have this:
e2372840 1612603151 C Ci:009:00 -121 32 = 09022000 0103fac0 01090400 0002ff00
00fa0705 02024000 00070581 0240
e2372840 1612603151 S Ci:009:00 s 80 06 0200 0400 1024 <
which says to me that the callback was received before the submission.
There is not another e2372840 URB af
I've been using the pxa2xx_udc driver as a basis for comparison. Is
this the best we have at the moment?
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Atten
On Wed, Mar 01, 2006 at 06:07:47PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 18:00:31 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > > Why don't you enable tracing in UDC or whatever that thing is?
> > > I gather that you are hacking on the device, so what does it see?
> >
> > Enabling
On Wed, 1 Mar 2006 18:00:31 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> > Why don't you enable tracing in UDC or whatever that thing is?
> > I gather that you are hacking on the device, so what does it see?
>
> Enabling DEBUG in the UDC driver makes it break even worse. Alan
> Stern recommen
On Wed, Mar 01, 2006 at 05:53:14PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > Its response to #11 is what is
> > broken. It may be getting confused by the second status request *or*
> > it may have sent the STALL (is that the -32?)
On Wed, 1 Mar 2006 17:36:17 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> Its response to #11 is what is
> broken. It may be getting confused by the second status request *or*
> it may have sent the STALL (is that the -32?) before it received the
> second GET_STATUS.
If queueing in HCD works w
On Wed, Mar 01, 2006 at 04:56:51PM -0800, Pete Zaitcev wrote:
> On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
>
> > 0:15.261198 # 10 S Ci 009:00 s 80 00 0002 ( DtH st dv GET_STATUS
> > ) --- 2 <
> > 0:15.261201 # 11 S Ci 009:00 s 80 06 0600 000a ( DtH
On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer <[EMAIL PROTECTED]> wrote:
> 0:15.261198 # 10 S Ci 009:00 s 80 00 0002 ( DtH st dv GET_STATUS )
> --- 2 <
> 0:15.261201 # 11 S Ci 009:00 s 80 06 0600 000a ( DtH st dv
> GET_DESCRIPTOR [DEVICE_QUALIFIER 0] ) --- 10 <
> ...
> 0:15.2
I performed a second capture using the driver as present in the kernel
archive with a couple of changes so that it would compile. The
results are similar.
What isn't clear to me is what this apparent error code means and who
is sending it.
My annotated capture has these entries:
0:15.261198 #
I'd appreciate some feedback about this. I'm attaching the raw log as
well as showing the output of a simple parser. There are a couple of
things that I don't know of they should bother me.
In the following output, the time stamps lead the line and are
computed as offsets from the first value.
On Wed, Mar 01, 2006 at 06:37:35PM +, Martin Michlmayr wrote:
> * Jordan Crouse <[EMAIL PROTECTED]> [2006-03-01 11:30]:
> > Martin Michlmayr spotted this potentially serious bug. Please apply.
>
> Please don't send patches as MIME attachments. Here it is again (with
> a better summary too):
On Wed, 1 Mar 2006, Pete Zaitcev wrote:
> On Wed, 22 Feb 2006 15:28:02 -0500 (EST), Alan Stern <[EMAIL PROTECTED]>
> wrote:
> > On Wed, 22 Feb 2006, Pete Zaitcev wrote:
>
> > > Frankly, I cannot fathom Alan's resistance to it when he actually
> > > suggested
> > > the main idea for the patch.
>
On Wed, 1 Mar 2006, David Brownell wrote:
>
> > > The "-EPROTO" is common after unplug, but that -EILSEQ suggests you
> > > have a real issue in the lh7a40x_udc driver ...
> >
> > Not necessarily. -EILSEQ is a normal code used by uhci-hcd when a CRC or
> > timeout error occurs on an IN transac
On Wed, 1 Mar 2006, Marc Singer wrote:
> What would be handy is if there was a log of the packets being sent by
> the usbtest code, and whether or not those packets had the expected
> result. Is there such a log somewhere? Does the dmesg output show
> this?
You can use usbmon. Read Documentati
Patches should apply-able with -p1 when applied at the top-level of
the source tree. I know that SVN doesn't do this and it's a big PITA.
I've switched to git and found that
a) it's a lot better suited to kernel hacking since it handles
branching properly,
b) it has the right sorts of c
It looks like I'm going to have to go all the way back to the
beginning. I'm seeing a STALL on the device side when I connect the
USB cable between the host and device. I don't know if this is an
issue, but I suspect that there may be several things going on. I
think that the debug messages in t
Jamie,
The patch changes the behavior, but it still fails test 10. Now,
though, I get a bonafide error.
[EMAIL PROTECTED] ~/z/usb > sudo ./testusb -a -t 10
unknown speed /proc/bus/usb/002/012
/proc/bus/usb/002/012 test 10 --> 32 (error 32)
EPIPE?
Since this works for you, I'm going t
Am Mittwoch, 1. März 2006 21:16 schrieb René Rebe:
> Hi,
>
> I wonder if:
>
> drivers/usb/core/devio.c:86
> #define MAX_USBFS_BUFFER_SIZE 16384
>
> is some random, or outdated limit or if there really is some code path that
> could
> not handle bigger URBs.
We are nice to the VM. 16384 is op
On Wed, 22 Feb 2006 15:28:02 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Feb 2006, Pete Zaitcev wrote:
> > Frankly, I cannot fathom Alan's resistance to it when he actually suggested
> > the main idea for the patch.
>
> I'm not at all resistant to the idea. It's just that the
On Wed, Mar 01, 2006 at 03:34:12PM -0500, Jamie Guinan wrote:
> Marc,
>
> Below is a patch against 2.6.16-rc5, which works with CONFIG_USB_ETH
> and CONFIG_USB_ETH_RNDIS.
It looks like you found the same thing tha I did, the portc bits were
set incorrectly. I was kind of hoping that you hadn't
On Wed, Mar 01, 2006 at 10:04:48AM -0800, David Brownell wrote:
> On Wednesday 01 March 2006 9:27 am, Marc Singer wrote:
>
> > > Test #10 taking a few minutes? Sounds troublesome. If this is using
> > > an OHCI or EHCI host controller and you've compiled with USB_DEBUG,
> > > you'll find a /sys/
What would be handy is if there was a log of the packets being sent by
the usbtest code, and whether or not those packets had the expected
result. Is there such a log somewhere? Does the dmesg output show
this?
There is nothing in async when my test10 goes awry. There is a lot in
dmesg, but I'l
On Tue, 28 Feb 2006, Marc Singer wrote:
...
>
> The question is this: what is the simplest gadget to use for debugging
> a UDC driver? I started with the serial gadget because I figured it
> would be easy to verify that it is working.
Marc,
Below is a patch against 2.6.16-rc5, which works with
> > The "-EPROTO" is common after unplug, but that -EILSEQ suggests you
> > have a real issue in the lh7a40x_udc driver ...
>
> Not necessarily. -EILSEQ is a normal code used by uhci-hcd when a CRC or
> timeout error occurs on an IN transaction.
True, but it's usually an either/or: either you
On Wed, 1 Mar 2006, David Brownell wrote:
> > It's getting an error 84.
> >
> > Wed Mar 1 06:49:26 PST 2006
> > ** Control test cases:
> > test 9: ch9 postconfig
> > /proc/bus/usb/002/014 test 9, 55.293133 secs
> > test 10: control queueing
> > /proc/bus/usb/002/014 test
* Jordan Crouse <[EMAIL PROTECTED]> [2006-03-01 11:30]:
> Martin Michlmayr spotted this potentially serious bug. Please apply.
Please don't send patches as MIME attachments. Here it is again (with
a better summary too):
[PATCH] Alchemy OCHI: return if right resources cannot be obtained
From:
Martin Michlmayr spotted this potentially serious bug. Please apply.
Jordan
--
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
[PATCH] Buglet in Alchemy OCHI
From: Jordan Crouse <[EMAIL PROTECTED]>
Failure to get the right resources should immediately return.
From: David Brownell <[EMAIL PROTECTED]>
To: linux-usb-devel@lists.sourceforge.net
CC: "Steve Calfee" <[EMAIL PROTECTED]>
Subject: Re: [linux-usb-devel] Re: Question about OTG operations
Date: Tue, 28 Feb 2006 23:42:35 -0800
On Tuesday 28 February 2006 11:03 pm, Steve Calfee wrote:
> Yes, it is
On Wednesday 01 March 2006 9:27 am, Marc Singer wrote:
> > Test #10 taking a few minutes? Sounds troublesome. If this is using
> > an OHCI or EHCI host controller and you've compiled with USB_DEBUG,
> > you'll find a /sys/class/usb_host/.../async dump of the control and
> > bulk queues. If it d
Hi,
can someone give me some hints how i can implement flow control in the serial
gadget driver ?
Regards
Tobias
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile m
On Wed, Mar 01, 2006 at 07:39:06AM -0800, David Brownell wrote:
> On Wednesday 01 March 2006 1:09 am, Marc Singer wrote:
> > On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote:
> > >
> > > http://www.linux-usb.org/usbtest/#gadgets
> > ...
> >
> > I'm not seeing an explanation of wha
On Wed, Mar 01, 2006 at 02:50:25PM +0100, Oliver Nittka wrote:
>
> Marc Singer wrote:
>
> > The only oddity I've seen so far is that the gadget wasn't detected
> > when the target (gadget) rebooted. I know that the driver has an
> > error in the USB power control. Perhaps that's at fault in the
Hello,
This patch adds support for the Nokia ca42 version 2 cable to the
cypress_m8 driver. The device was tested by others with this patch and
found to be compatible with the cypress_m8 driver. A special note
should be taken that this cable seems to vary in the type of chipset
used. Thi
On Wednesday 01 March 2006 5:13 am, Lennert Buytenhek wrote:
> +static struct hc_driver ohci_ep93xx_hc_driver = {
> + .description= hcd_name,
> + .product_desc = "EP93xx OHCI",
> + .hcd_priv_size = sizeof(struct ohci_hcd),
> + .irq
On Wednesday 01 March 2006 1:09 am, Marc Singer wrote:
> On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote:
> >
> > http://www.linux-usb.org/usbtest/#gadgets
> ...
>
> I'm not seeing an explanation of what the tests should look like. How
> long should each one last? Most take a
On Wed, 1 Mar 2006, Thomas Seiler wrote:
> Hello Alan,
>
> Thanks for the pointers. It is clearer now.
>
> >> It gets the number of ports from the hardware during initialization.
> >> However, it does _not_ know where they are.
> Got it, its comming from the UHCRHDA Root Hub Descrptor Register.
Smart Money Equities would like to thank our valued
readers for making 2005 a great year. Please continue
to support Smart Money Equities by visiting our
sponsors and featured advertisers.
We would like to introduce you to a company involved in
the nanotechnology field. It is widely believed amo
Thanks Alan,
I am very thankful for your patient responses.
Regards,
Mukund Jampala
>-Original Message-
>From: Alan Stern [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, March 01, 2006 8:45 PM
>To: Mukund JB.
>Cc: [EMAIL PROTECTED]; Randy.Dunlap
>Subject: RE: [linux-usb-devel] RE: Analyze th
On Wed, 1 Mar 2006, Mukund JB. wrote:
> >In other words, since low-speed USB runs at 1.5 Mb/s, that's 150
> bits
> >per second, or 1500 bits per frame, or 187.5 bytes per frame. Since
> you
> >can't transfer half a byte, the number is rounded down to 187.
>
> I agree for low speed devices, t
Marc Singer wrote:
> The only oddity I've seen so far is that the gadget wasn't detected
> when the target (gadget) rebooted. I know that the driver has an
> error in the USB power control. Perhaps that's at fault in the
> detection.
Hello Marc,
i wrote a fix for that, but it's not thoroughly
On Wed, Mar 01, 2006 at 02:13:25PM +0100, Lennert Buytenhek wrote:
> (please CC, I'm not on the list.)
>
> Hi!
>
> The ep93xx is an arm920t based embedded CPU from Cirrus which has,
> amongst other things, an AHB OHCI USB host interface. This CPU isn't
> supported in linux yet, but I will be sub
(please CC, I'm not on the list.)
Hi!
The ep93xx is an arm920t based embedded CPU from Cirrus which has,
amongst other things, an AHB OHCI USB host interface. This CPU isn't
supported in linux yet, but I will be submitting the core ARM support
code for 2.6.17, and in the meanwhile, I would love
Hello Alan,
Thanks for the pointers. It is clearer now.
>> It gets the number of ports from the hardware during initialization.
>> However, it does _not_ know where they are.
Got it, its comming from the UHCRHDA Root Hub Descrptor Register.
Aparently the PXA271 OHCI only reports 2 ports (ndp=1),
On Tue, Feb 28, 2006 at 10:29:03PM -0800, David Brownell wrote:
> On Tuesday 28 February 2006 9:48 pm, Marc Singer wrote:
>
> > The question is this: what is the simplest gadget to use for debugging
> > a UDC driver? I started with the serial gadget because I figured it
> > would be easy to verif
Smart Money Equities would like to thank our valued
readers for making 2005 a great year. Please continue
to support Smart Money Equities by visiting our
sponsors and featured advertisers.
We would like to introduce you to a company involved in
the nanotechnology field. It is widely believed amo
Smart Money Equities would like to thank our valued
readers for making 2005 a great year. Please continue
to support Smart Money Equities by visiting our
sponsors and featured advertisers.
We would like to introduce you to a company involved in
the nanotechnology field. It is widely believed amo
56 matches
Mail list logo
