On Thu, 13 Mar 2014, David Mosberger wrote:
To answer my own question: it appears that USB peripherals return NAKs
not only when the peripheral is not ready to accept the data, but also
when the peripheral doesn't know what to do with the data.
No, that's not right. If the device doesn't
Alan,
On Fri, Mar 14, 2014 at 8:02 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 13 Mar 2014, David Mosberger wrote:
To answer my own question: it appears that USB peripherals return NAKs
not only when the peripheral is not ready to accept the data, but also
when the peripheral
On Fri, 14 Mar 2014, David Mosberger wrote:
Alan,
On Fri, Mar 14, 2014 at 8:02 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 13 Mar 2014, David Mosberger wrote:
To answer my own question: it appears that USB peripherals return NAKs
not only when the peripheral is not ready
Alan,
On Fri, Mar 14, 2014 at 9:34 AM, Alan Stern st...@rowland.harvard.edu wrote:
Now, I'm not saying what the device did was correct. According to
section 6.6.1 of the Bulk-Only Transport Mass Storage spec, when the
device expects a CBW packet but gets something else, it is supposed to
On Fri, 14 Mar 2014, David Mosberger wrote:
Alan,
On Fri, Mar 14, 2014 at 9:34 AM, Alan Stern st...@rowland.harvard.edu wrote:
Now, I'm not saying what the device did was correct. According to
section 6.6.1 of the Bulk-Only Transport Mass Storage spec, when the
device expects a CBW
After thinking about this some more, the MAX3421E behavior could be
triggered if a write to the SNDFIFO is not followed by a BULK_OUT
command to the HXFR register. My driver always issues BULK_OUT after
writing the SNDFIFO so this should never happen, but a corrupted SPI
transfer could do this.
OK, I was able to confirm this: switching the FIFO back through a
dummy write after a NAK/error-response fixes the problem I was seeing,
so it truly was a driver-bug, not a chip bug. My apologies to Maxim!
;-)
--david
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the
On Wed, 12 Mar 2014, David Mosberger wrote:
On Wed, Mar 12, 2014 at 2:53 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 12 Mar 2014, David Mosberger wrote:
I see the same WRITE_10 commands of 122,880 bytes (240 sectors), but
the glaring difference is that each such WRITE_10
Yeah, sorry, the READ_10s were a total red herring. They're there
because I forgot to specify bs=1024. ;-(
I'll try to capture better traces today and if they look interesting,
make them available.
--david
--
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.976
--
To
OK, I finally know where the problem is coming from! The MAX3421E
chip uses double-buffering. Specifically, it has two 64-byte send
FIFOs. You write up to 64 bytes to a send FIFO by repeatedly writing
to SPI register 2 (SNDFIFO). Then you tell the chip how many bytes
you just put in the FIFO
On Thu, 13 Mar 2014, David Mosberger wrote:
OK, I finally know where the problem is coming from! The MAX3421E
chip uses double-buffering. Specifically, it has two 64-byte send
FIFOs. You write up to 64 bytes to a send FIFO by repeatedly writing
to SPI register 2 (SNDFIFO). Then you tell
Alan,
On Thu, Mar 13, 2014 at 11:12 AM, Alan Stern st...@rowland.harvard.edu wrote:
Okay. Maybe this would have been easier to see if you had been writing
actual data instead of just a lot of zeros; the errors would have shown
up when you checked the received data (incorrect checksum or
To answer my own question: it appears that USB peripherals return NAKs
not only when the peripheral is not ready to accept the data, but also
when the peripheral doesn't know what to do with the data. So an
infinite series of NAKs basically is just the device's way of saying:
I don't know what
On Thursday 13 March 2014 18:15:06 David Mosberger did opine:
To answer my own question: it appears that USB peripherals return NAKs
not only when the peripheral is not ready to accept the data, but also
when the peripheral doesn't know what to do with the data. So an
infinite series of NAKs
On Thursday 13 March 2014 19:09:41 Gene Heskett did opine:
On Thursday 13 March 2014 18:15:06 David Mosberger did opine:
To answer my own question: it appears that USB peripherals return NAKs
not only when the peripheral is not ready to accept the data, but also
when the peripheral doesn't
David Mosberger wrote:
I couldn't figure out how to force UHCI onto an EHCI chip
I suggested removing the ehci_hcd driver. Did that work?
but I did find I had some old IOGEAR USB 1.1 extenders (USB-over-CAT5
cable) and with those, the device does switch into full-speed mode on my
computer:
On Wed, Mar 12, 2014 at 6:21 AM, Peter Stuge pe...@stuge.se wrote:
David Mosberger wrote:
I couldn't figure out how to force UHCI onto an EHCI chip
I suggested removing the ehci_hcd driver. Did that work?
Nope. UHCI was loaded but it didn't recognize any UHCI-compatible
chips so I was left
David Mosberger wrote:
I couldn't figure out how to force UHCI onto an EHCI chip
I suggested removing the ehci_hcd driver. Did that work?
Nope. UHCI was loaded but it didn't recognize any UHCI-compatible
chips so I was left without any USB devices (not even keyboard).
Hmmm. Did you
On Wed, 12 Mar 2014, Peter Stuge wrote:
David Mosberger wrote:
I couldn't figure out how to force UHCI onto an EHCI chip
I suggested removing the ehci_hcd driver. Did that work?
Nope. UHCI was loaded but it didn't recognize any UHCI-compatible
chips so I was left without any USB
Alan Stern wrote:
lspci should show the UHCI companion controllers on the PCI bus.
Peter, David's computer doesn't have any UHCI controllers.
Everything is handled by EHCI, through a hub on the motherboard.
This is the standard design for current Intel systems.
Thanks, I understand.
I
So, quick question to the collective linux-usb wisdom: when I collect
a USB trace on my work-computer while running the command:
dd if=/dev/zero of=/dev/sdX1
I see the same WRITE_10 commands of 122,880 bytes (240 sectors), but
the glaring difference is that each such WRITE_10 command seems to
On Wed, 12 Mar 2014, David Mosberger wrote:
So, quick question to the collective linux-usb wisdom: when I collect
a USB trace on my work-computer while running the command:
dd if=/dev/zero of=/dev/sdX1
I see the same WRITE_10 commands of 122,880 bytes (240 sectors), but
the glaring
On Wed, Mar 12, 2014 at 2:53 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 12 Mar 2014, David Mosberger wrote:
I see the same WRITE_10 commands of 122,880 bytes (240 sectors), but
the glaring difference is that each such WRITE_10 command seems to be
followed by ~ 27 READ_10 commands
From: Felipe Balbi
On Mon, Mar 10, 2014 at 02:15:36PM -0600, David Mosberger wrote:
I was thinking of the Salea Logic http://www.saleae.com/logic ($150).
Are you aware of any limitations for this one that would get in the way?
for full-speed USB it should work, I guess. Never tried
Thanks for the tips! Yes, the saleae is very simple so it may not do
the trick. I am also concerned about the very basic trigger
capabilities, but I'm hopeful that we can simply collect a long enough
trace and then find the interesting spots after the fact. The
MAX3421E also has a couple of
On Tue, Mar 11, 2014 at 10:16:55AM +, David Laight wrote:
From: Felipe Balbi
On Mon, Mar 10, 2014 at 02:15:36PM -0600, David Mosberger wrote:
I was thinking of the Salea Logic http://www.saleae.com/logic ($150).
Are you aware of any limitations for this one that would get in the way?
On Tue, 11 Mar 2014, David Mosberger wrote:
So I hooked up a Seleae Logic and I still can't find anything obvious
that's wrong. I attached the decoded USB trace for the last WRITE10
request that's ends up with infinite NAKs.
After receiving 8 contiguous NAKs, my driver prints some kernel
On Tue, Mar 11, 2014 at 12:43 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 11 Mar 2014, David Mosberger wrote:
So I hooked up a Seleae Logic and I still can't find anything obvious
that's wrong. I attached the decoded USB trace for the last WRITE10
request that's ends up with
On Tue, 11 Mar 2014, David Mosberger wrote:
It looks like the host controller is behaving correctly, which means
the fault is in the device. Have you tried plugging this device into a
regular Linux PC and running the same test?
Yup, works fine at least at least at hispeed. I suppose I
I couldn't figure out how to force UHCI onto an EHCI chip but I did
find I had some old IOGEAR USB 1.1 extenders (USB-over-CAT5 cable)
and with those, the device does switch into full-speed mode on my
computer:
[ 886.371122] usb 1-1.3.1.1.4.2: USB disconnect, device number 15
[ 950.960459] usb
Hi,
On Mon, Mar 10, 2014 at 01:48:33PM -0600, David Mosberger wrote:
Thanks for taking a look!
I thought that there might be an bug in re-transmitting the OUT requests
that are being NAK'd indefinitely, but a different flash drive works much
longer and with that drive, I see many OUT
[Resend in plain text mode...]
Thanks for taking a look!
I thought that there might be an bug in re-transmitting the OUT requests
that are being NAK'd indefinitely, but a different flash drive works much
longer and with that drive, I see many OUT requests that get NAK'd a couple
of times, but
Hi,
(please avoid top-posting)
On Mon, Mar 10, 2014 at 02:15:36PM -0600, David Mosberger wrote:
I was thinking of the Salea Logic http://www.saleae.com/logic ($150).
Are you aware of any limitations for this one that would get in the way?
for full-speed USB it should work, I guess. Never
So the MAX3421E driver is working quite well but one problem I'm
seeing is that after running devices for a while, they seem to get
into a mode where a bulk out transfer gets stuck soliciting and
endless stream of NAKs. The MAX3421E retries NAK'd transfers in the
next frame again, only to get the
On Fri, Mar 07, 2014 at 06:16:03PM -0700, David Mosberger wrote:
So the MAX3421E driver is working quite well but one problem I'm
seeing is that after running devices for a while, they seem to get
into a mode where a bulk out transfer gets stuck soliciting and
endless stream of NAKs. The
35 matches
Mail list logo
