Re: MAX3421E: device giving NAKs forever?

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 th

Re: MAX3421E: device giving NAKs forever?

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. A

Re: MAX3421E: device giving NAKs forever?

On Fri, 14 Mar 2014, David Mosberger wrote: > Alan, > > On Fri, Mar 14, 2014 at 9:34 AM, Alan Stern 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 s

Re: MAX3421E: device giving NAKs forever?

Alan, On Fri, Mar 14, 2014 at 9:34 AM, Alan Stern 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 > accept the packet (ACK,

Re: MAX3421E: device giving NAKs forever?

On Fri, 14 Mar 2014, David Mosberger wrote: > Alan, > > On Fri, Mar 14, 2014 at 8:02 AM, Alan Stern 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

Re: MAX3421E: device giving NAKs forever?

Alan, On Fri, Mar 14, 2014 at 8:02 AM, Alan Stern 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 doesn't know what to

Re: MAX3421E: device giving NAKs forever?

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 k

Re: MAX3421E: device giving NAKs forever?

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 d

Re: MAX3421E: device giving NAKs forever?

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 N

Re: MAX3421E: device giving NAKs forever?

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 the

Re: MAX3421E: device giving NAKs forever?

Alan, On Thu, Mar 13, 2014 at 11:12 AM, Alan Stern 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 something > like that). Pe

Re: MAX3421E: device giving NAKs forever?

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 tel

Re: MAX3421E: device giving NAKs forever?

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 by

Re: MAX3421E: device giving NAKs forever?

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 unsubsc

Re: MAX3421E: device giving NAKs forever?

On Wed, 12 Mar 2014, David Mosberger wrote: > On Wed, Mar 12, 2014 at 2:53 PM, Alan Stern 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

Re: MAX3421E: device giving NAKs forever?

On Wed, Mar 12, 2014 at 2:53 PM, Alan Stern 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 reading 1KB (2 sec

Re: MAX3421E: device giving NAKs forever?

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 glarin

Re: MAX3421E: device giving NAKs forever?

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 be

Re: MAX3421E: device giving NAKs forever?

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.

Re: MAX3421E: device giving NAKs forever?

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

Re: MAX3421E: device giving NAKs forever?

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. Di

Re: MAX3421E: device giving NAKs forever?

On Wed, Mar 12, 2014 at 6:21 AM, 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

Re: MAX3421E: device giving NAKs forever?

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 > compu

Re: MAX3421E: device giving NAKs forever?

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

Re: MAX3421E: device giving NAKs forever?

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 sup

Re: MAX3421E: device giving NAKs forever?

On Tue, Mar 11, 2014 at 12:43 PM, Alan Stern 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 "infinite" NAKs. >> >>

Re: MAX3421E: device giving NAKs forever?

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 ke

Re: MAX3421E: device giving NAKs forever?

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 ($150). > > > Are you aware of any limitations for this one that would get i

Re: MAX3421E: device giving NAKs forever?

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 gpio

RE: MAX3421E: device giving NAKs forever?

From: Felipe Balbi > On Mon, Mar 10, 2014 at 02:15:36PM -0600, David Mosberger wrote: > > I was thinking of the Salea 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 trie

Re: MAX3421E: device giving NAKs forever?

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 ($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

Re: MAX3421E: device giving NAKs forever?

[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 eve

Re: MAX3421E: device giving NAKs forever?

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 re

Re: MAX3421E: device giving NAKs forever?

On Fri, 7 Mar 2014, David Mosberger wrote: > Felipe, > > Thanks for the tip about usbmon --- that looks interesting. Of > course, as luck would have it, turning on usbmon changes behavior: > dd'ing to a mass-storage device (/dev/sda1) used to fail after > ~500KiB. With usbmon, it fails only aft

Re: MAX3421E: device giving NAKs forever?

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 M

MAX3421E: device giving NAKs forever?

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