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 know what to do with the data (for example, if it doesn't recognize a particular SETUP request), it replies with a STALL. So an infinite series of NAKs basically is just the device's way of saying: I don't know what the heck to do with the data you keep sending me. I expected to get an error result for such a case, but I can see why sending a NAK may be the most natural response for the device. Probably what happens is that the device doesn't queue an internal request for an OUT transfer until it knows that it needs some data. Without a request queued, the device's USB controller doesn't have any place to store the data sent by the host computer, so it NAKs the transfer. It really is saying I'm not ready to accept this data. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MAX3421E: device giving NAKs forever?
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 doesn't know what to do with the data. No, that's not right. If the device doesn't know what to do with the data (for example, if it doesn't recognize a particular SETUP request), it replies with a STALL. Please re-read my statement again. I said that infinite NAKs is one way for a peripheral to say, I don't know what to do with this. I didn't say it's the only way to handle errors. I certainly would have much preferred to get a STALL for my situation because it'd have made it very clear what the offending command was. Probably what happens is that the device doesn't queue an internal request for an OUT transfer until it knows that it needs some data. Without a request queued, the device's USB controller doesn't have any place to store the data sent by the host computer, so it NAKs the transfer. It really is saying I'm not ready to accept this data. Sure, that sounds very plausible. I didn't say the device was doing anything wrong. I just have seen several other questions from developers about infinite NAKs but never an answer as to what would cause that, so I wanted to explain it for the benefit of others. --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 doesn't know what to do with the data. No, that's not right. If the device doesn't know what to do with the data (for example, if it doesn't recognize a particular SETUP request), it replies with a STALL. Please re-read my statement again. I said that infinite NAKs is one way for a peripheral to say, I don't know what to do with this. But it isn't. When a device sends a NAK, it doesn't mean I don't know what to do with this. It means I'm not ready to receive (or send) this data, or (in the status stage of a control transfer) I'm not finished processing this data. I'm serious. A NAK response in a bulk-OUT transaction means that the device simply threw away the data -- it didn't even store the data in an internal buffer, let alone try to parse the data and decide that it didn't understand something. If a device wants to say I don't know what to do with this, it sends a STALL or uses some other class-specific mechanism. I didn't say it's the only way to handle errors. I certainly would have much preferred to get a STALL for my situation because it'd have made it very clear what the offending command was. There was no offending command. In fact, there was no command at all, right? The data got sent from the wrong FIFO, so you ended up sending a packet containing only 0's, not a valid CBW. 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, not NAK), stall the bulk-IN endpoint, and either stall or accept and discard all further bulk-OUT data. Probably what happens is that the device doesn't queue an internal request for an OUT transfer until it knows that it needs some data. Without a request queued, the device's USB controller doesn't have any place to store the data sent by the host computer, so it NAKs the transfer. It really is saying I'm not ready to accept this data. Sure, that sounds very plausible. I didn't say the device was doing anything wrong. I just have seen several other questions from developers about infinite NAKs but never an answer as to what would cause that, so I wanted to explain it for the benefit of others. NAKs mean the device isn't ready to accept the data the host is sending. It could be because of a bug in the device's firmware, or it could be because the host violated the expected protocol somehow. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MAX3421E: device giving NAKs forever?
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 accept the packet (ACK, not NAK), stall the bulk-IN endpoint, and either stall or accept and discard all further bulk-OUT data. Ah, now that's interesting. I tried like half a dozen mass storage devices, not one of them STALLed. It'd have been so much easier to find this problem if I had gotten a STALL for the corrupted OUT. --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 accept the packet (ACK, not NAK), stall the bulk-IN endpoint, and either stall or accept and discard all further bulk-OUT data. Ah, now that's interesting. I tried like half a dozen mass storage devices, not one of them STALLed. It'd have been so much easier to find this problem if I had gotten a STALL for the corrupted OUT. A lot of USB mass-storage devices, especially the cheaper ones, aren't very careful about following the spec. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Also, and perhaps more plausible for my driver, after an OUT transfer gets a response other than ACK (e.g., NAK or error), the MAX3421E doesn't unload that FIFO (assuming that you'll want to retransmit the data). My driver never retransmits the data immediately, so I think it has to issue a dummy write to the SNDBC register to switch back to the original FIFO. I know I tried that at one point and it didn't fix the issue, but I should try this again as it seems the most plausible explanation. --david On Thu, Mar 13, 2014 at 10:46 AM, David Mosberger dav...@egauge.net 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 the chip how many bytes you just put in the FIFO by writing SPI register 7 (the send-byte-count or SNDBC register). Writing SNDBC is supposed to switch the FIFO to the USB-side so it can be transmitted on the USB bus. Unfortunately, it seems that under certain circumstances, writing the SNDBC fails to properly switch the FIFOs and we end up sending data to the USB bus from the wrong FIFO. In the USB mass-storage error situation we're seeing, the driver was trying to send a 31-byte USBC command and we see that command coming over the SPI-bus just fine. However, on the USB-side, the MAX3421E chip instead writes a 64-byte packet full of zeroes (which is the data we were transmitting before). The mass-storage peripheral afterwards NAKs any OUT request because it never saw the new SCSI WRITE_10 command that was encapsulated in the USBC command. The work-around for now is to write outgoing packets twice, so that both FIFOs contain the same data. With that workaround, we have been able to dd 5MB blocks of data repeatedly without any issues (dd if=/dev/zero of=/dev/sda1 count=5000 bs=1024). I should mention this is with rev 0x12 of the MAX3421E chip. The current rev is 0x13 so we'll try with that chip in the next few days. However, we are not aware of any erratas for rev 0x12 that would explain this behavior. Also, for the record, we ran the SPI bus at only 4MHz for this testing so we could reliably capture the data with the Saleae Logic. Giving this low frequency and the fact that the Saleae was able to capture the correct data, I do not think that SPI corruption is to blame. We saw the same error occur even with SPI at 1MHz. I have the full trace data if anyone is interested. It's captures the complete test (from loading the max3421 driver to when the error occurs), so it's 55MiB in size, so I can't attach it to email. --david On Thu, Mar 13, 2014 at 8:55 AM, David Mosberger dav...@egauge.net wrote: 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 -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 reading 1KB (2 sectors), whereas with the MAX3421 driver, I see consecutive WRITE_10 commands. Anybody know where those READ_10 commands are coming from? I'd guess it's some sort of readahead. Not that it makes much sense to read sectors that are about to be overwritten. Did those READ commands occur before you started running dd? Definitely not. I attached a log of a good (working) dd, showing only the USBC transactions. The '\n ( commands are READ_10, the \n * commands are WRITE_10. I can't tell much by looking at that log. (Incidentally, usbmon ought to show much the same information in a more readable form.) I think you can disable readahead by doing echo 0 /sys/block/sdX/queue/read_ahead_kb where X is replaced by the appropriate letter for the USB drive. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 writing SPI register 7 (the send-byte-count or SNDBC register). Writing SNDBC is supposed to switch the FIFO to the USB-side so it can be transmitted on the USB bus. Unfortunately, it seems that under certain circumstances, writing the SNDBC fails to properly switch the FIFOs and we end up sending data to the USB bus from the wrong FIFO. In the USB mass-storage error situation we're seeing, the driver was trying to send a 31-byte USBC command and we see that command coming over the SPI-bus just fine. However, on the USB-side, the MAX3421E chip instead writes a 64-byte packet full of zeroes (which is the data we were transmitting before). The mass-storage peripheral afterwards NAKs any OUT request because it never saw the new SCSI WRITE_10 command that was encapsulated in the USBC command. The work-around for now is to write outgoing packets twice, so that both FIFOs contain the same data. With that workaround, we have been able to dd 5MB blocks of data repeatedly without any issues (dd if=/dev/zero of=/dev/sda1 count=5000 bs=1024). I should mention this is with rev 0x12 of the MAX3421E chip. The current rev is 0x13 so we'll try with that chip in the next few days. However, we are not aware of any erratas for rev 0x12 that would explain this behavior. Also, for the record, we ran the SPI bus at only 4MHz for this testing so we could reliably capture the data with the Saleae Logic. Giving this low frequency and the fact that the Saleae was able to capture the correct data, I do not think that SPI corruption is to blame. We saw the same error occur even with SPI at 1MHz. I have the full trace data if anyone is interested. It's captures the complete test (from loading the max3421 driver to when the error occurs), so it's 55MiB in size, so I can't attach it to email. --david On Thu, Mar 13, 2014 at 8:55 AM, David Mosberger dav...@egauge.net wrote: 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 -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 tell the chip how many bytes you just put in the FIFO by writing SPI register 7 (the send-byte-count or SNDBC register). Writing SNDBC is supposed to switch the FIFO to the USB-side so it can be transmitted on the USB bus. Unfortunately, it seems that under certain circumstances, writing the SNDBC fails to properly switch the FIFOs and we end up sending data to the USB bus from the wrong FIFO. In the USB mass-storage error situation we're seeing, the driver was trying to send a 31-byte USBC command and we see that command coming over the SPI-bus just fine. However, on the USB-side, the MAX3421E chip instead writes a 64-byte packet full of zeroes (which is the data we were transmitting before). The mass-storage peripheral afterwards NAKs any OUT request because it never saw the new SCSI WRITE_10 command that was encapsulated in the USBC command. 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). The work-around for now is to write outgoing packets twice, so that both FIFOs contain the same data. With that workaround, we have been able to dd 5MB blocks of data repeatedly without any issues (dd if=/dev/zero of=/dev/sda1 count=5000 bs=1024). That sounds like you would sacrifice a lot of speed, because you are effectively using single buffering instead of double buffering. I should mention this is with rev 0x12 of the MAX3421E chip. The current rev is 0x13 so we'll try with that chip in the next few days. However, we are not aware of any erratas for rev 0x12 that would explain this behavior. You could try contacting the chip's manufacturer. Also, for the record, we ran the SPI bus at only 4MHz for this testing so we could reliably capture the data with the Saleae Logic. Giving this low frequency and the fact that the Saleae was able to capture the correct data, I do not think that SPI corruption is to blame. We saw the same error occur even with SPI at 1MHz. I have the full trace data if anyone is interested. It's captures the complete test (from loading the max3421 driver to when the error occurs), so it's 55MiB in size, so I can't attach it to email. Thanks for letting us know the end of the story. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MAX3421E: device giving NAKs forever?
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 something like that). Perhaps. The error obviously doesn't happen very easily as otherwise it'd have failed much earlier. I'll be waiting to hear from MAXIM and to try out rev 0x13 before spending time on understanding what triggers the error. The work-around for now is to write outgoing packets twice, so that both FIFOs contain the same data. With that workaround, we have been able to dd 5MB blocks of data repeatedly without any issues (dd if=/dev/zero of=/dev/sda1 count=5000 bs=1024). That sounds like you would sacrifice a lot of speed, because you are effectively using single buffering instead of double buffering. The double-buffering is really only useful for isochronous transactions (which we don't have a need for and which the driver doesn't support), since only those can be 64 bytes. The way the double-buffering is implemented doesn't let us overlap transactions in any way, so the only loss is added CPU overhead and SPI-bus time. --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 heck to do with the data you keep sending me. I expected to get an error result for such a case, but I can see why sending a NAK may be the most natural response for the device. Anyhow, hopefully this will be helpful for others in the future (perhaps it's obvious, but it wasn't to me... ;-). --david On Fri, Mar 7, 2014 at 6:16 PM, David Mosberger dav...@egauge.net 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 MAX3421E retries NAK'd transfers in the next frame again, only to get the same response, forever. I see this both with a mass storage device and a WIFI adapter (which is specifically advertised as being USB 1.1 compatible). Anybody have any ideas where that might be coming from? --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 NAKs basically is just the device's way of saying: I don't know what the heck to do with the data you keep sending me. I expected to get an error result for such a case, but I can see why sending a NAK may be the most natural response for the device. Anyhow, hopefully this will be helpful for others in the future (perhaps it's obvious, but it wasn't to me... ;-). --david I just ran into something very similar David. I have an Epson MFD, printer/scanner which has been turned off because the print head packed up when it was still new, but I kept it for the scanner. Turned off. Asked to scan something and email it by the better half, I turned it on, but unbeknownst to me, something had send about 50 some jobs to it so they were sitting in the queue, feed all the paper still in it on thru as blank, then went into an infinite loop of asking for more paper, and it could not be canceled as the keyboard had been seized, and mouse click any place but on those requesters were acknowledged but ignored. Nothing to do but hit the rest button on the tower. On reboot, I was able to access it and clean out the queue with a browser, then turned it on and did my scanning, twice now with no further problems. I'd squawk at Michael Sweet (cups) but that mailing list went dead after he sold himself and cups to Apple, so there is not now a feedback path that I can find for us peons to use. I knew Michael from school days, long before he ever started cups. Perhaps its time for a cups fork? On Fri, Mar 7, 2014 at 6:16 PM, David Mosberger dav...@egauge.net 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 MAX3421E retries NAK'd transfers in the next frame again, only to get the same response, forever. I see this both with a mass storage device and a WIFI adapter (which is specifically advertised as being USB 1.1 compatible). Anybody have any ideas where that might be coming from? --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 heck to do with the data you keep sending me. I expected to get an error result for such a case, but I can see why sending a NAK may be the most natural response for the device. Anyhow, hopefully this will be helpful for others in the future (perhaps it's obvious, but it wasn't to me... ;-). --david I just ran into something very similar David. I have an Epson MFD, printer/scanner which has been turned off because the print head packed up when it was still new, but I kept it for the scanner. Turned off. Asked to scan something and email it by the better half, I turned it on, but unbeknownst to me, something had send about 50 some jobs to it so they were sitting in the queue, feed all the paper still in it on thru as blank, then went into an infinite loop of asking for more paper, and it could not be canceled as the keyboard had been seized, and mouse click any place but on those requesters were acknowledged but ignored. Nothing to do but hit the rest button on the tower. On reboot, I was able to access it and clean out the queue with a browser, then turned it on and did my scanning, twice now with no further problems. I'd squawk at Michael Sweet (cups) but that mailing list went dead after he sold himself and cups to Apple, so there is not now a feedback path that I can find for us peons to use. I knew Michael from school days, long before he ever started cups. Perhaps its time for a cups fork? On Fri, Mar 7, 2014 at 6:16 PM, David Mosberger dav...@egauge.net 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 MAX3421E retries NAK'd transfers in the next frame again, only to get the same response, forever. I see this both with a mass storage device and a WIFI adapter (which is specifically advertised as being USB 1.1 compatible). Anybody have any ideas where that might be coming from? --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 Cheers, Gene I forgot to add, kernel 3.13.6, 32 bit build on an amd phenom. Uptime then was about a week. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 computer: It might not be comparable. [ 886.371122] usb 1-1.3.1.1.4.2: USB disconnect, device number 15 [ 950.960459] usb 1-1.2: new full-speed USB device number 16 using ehci-pci Looks like it's still using the ehci driver. You could use an FX2 data logger like the Logic or any of the 15 USD boards off eBay (the Logic does nothing more than they do) together with http://sigrok.org/ and the libsigrokdecode USB protocol decoder for protocol analysis. It's obviously not a Beagle 480 but could be more than sufficient for full speed. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MAX3421E: device giving NAKs forever?
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 without any USB devices (not even keyboard). 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: It might not be comparable. I just need proof that the devices can be operated properly with full-speed transactions only. As long as it does that, I should be fine. --david [ 886.371122] usb 1-1.3.1.1.4.2: USB disconnect, device number 15 [ 950.960459] usb 1-1.2: new full-speed USB device number 16 using ehci-pci Looks like it's still using the ehci driver. You could use an FX2 data logger like the Logic or any of the 15 USD boards off eBay (the Logic does nothing more than they do) together with http://sigrok.org/ and the libsigrokdecode USB protocol decoder for protocol analysis. It's obviously not a Beagle 480 but could be more than sufficient for full speed. //Peter -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. Did you unload ehci_hcd after it had been loaded once, or boot a kernel which didn't include ehci_hcd in the first place? You might need to do the latter. lspci should show the UHCI companion controllers on the PCI bus. (OHCI is also allowed by the EHCI spec, so maybe this is it? Check lspci. Then include ohci_hcd instead.) 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: It might not be comparable. I just need proof that the devices can be operated properly with full-speed transactions only. As long as it does that, I should be fine. I'm afraid that it will be more complicated than that. I would make sure to try many different full-speed host controllers. Connecting to the root port of an EHCI controller connects directly to the companion controller for that port, when no ehci_hcd was present in the system since boot. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 without any USB devices (not even keyboard). Hmmm. Did you unload ehci_hcd after it had been loaded once, or boot a kernel which didn't include ehci_hcd in the first place? You might need to do the latter. lspci should show the UHCI companion controllers on the PCI bus. (OHCI is also allowed by the EHCI spec, so maybe this is it? Check lspci. Then include ohci_hcd instead.) 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. 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: It might not be comparable. I just need proof that the devices can be operated properly with full-speed transactions only. As long as it does that, I should be fine. I'm afraid that it will be more complicated than that. I would make sure to try many different full-speed host controllers. Connecting to the root port of an EHCI controller connects directly to the companion controller for that port, when no ehci_hcd was present in the system since boot. David's computer has no companion controller. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. I wouldn't use a system like that for this test, just to be sure. //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 followed by ~ 27 READ_10 commands reading 1KB (2 sectors), whereas with the MAX3421 driver, I see consecutive WRITE_10 commands. Anybody know where those READ_10 commands are coming from? Is it a cheap way to poll the device if it's ready for the next block without having to use expensive OUT transactions that get NAK'd? I'll obviously investigate some more, but that's the first obvious difference I have noticed. --david On Tue, Mar 11, 2014 at 7:10 PM, David Mosberger dav...@egauge.net wrote: 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 1-1.2: new full-speed USB device number 16 using ehci-pci [ 951.055170] usb 1-1.2: not running at top speed; connect to a high speed hub [ 951.061791] usb 1-1.2: New USB device found, idVendor=058f, idProduct=6387 [ 951.061797] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 951.061802] usb 1-1.2: Product: Mass Storage [ 951.061805] usb 1-1.2: Manufacturer: Generic [ 951.061809] usb 1-1.2: SerialNumber: BCABB02D [ 951.062390] scsi5 : usb-storage 1-1.2:1.0 [ 952.060285] scsi 5:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 4 [ 952.061585] sd 5:0:0:0: Attached scsi generic sg3 type 0 [ 952.064648] sd 5:0:0:0: [sdc] 1968128 512-byte logical blocks: (1.00 GB/961 MiB) [ 952.065793] sd 5:0:0:0: [sdc] Write Protect is off [ 952.065801] sd 5:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 952.067012] sd 5:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 952.076695] sdc: sdc1 [ 952.080629] sd 5:0:0:0: [sdc] Attached SCSI removable disk With this setup, I can write to the device just fine: dd if=/dev/zero of=/dev/sdc1 count=1 1+0 records in 1+0 records out 512 bytes (5.1 MB) copied, 15.1192 s, 339 kB/s No infinite NAK issue. Still scratching my head... --david On Tue, Mar 11, 2014 at 1:00 PM, Alan Stern st...@rowland.harvard.edu wrote: 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 should try the enable UHCI only trick to see if I can test the device at full-speed on my computer. Yes, definitely, so that you are testing under the same conditions. Alan Stern -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 glaring difference is that each such WRITE_10 command seems to be followed by ~ 27 READ_10 commands reading 1KB (2 sectors), whereas with the MAX3421 driver, I see consecutive WRITE_10 commands. Anybody know where those READ_10 commands are coming from? I'd guess it's some sort of readahead. Not that it makes much sense to read sectors that are about to be overwritten. Did those READ commands occur before you started running dd? Is it a cheap way to poll the device if it's ready for the next block without having to use expensive OUT transactions that get NAK'd? Definitely not. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MAX3421E: device giving NAKs forever?
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 reading 1KB (2 sectors), whereas with the MAX3421 driver, I see consecutive WRITE_10 commands. Anybody know where those READ_10 commands are coming from? I'd guess it's some sort of readahead. Not that it makes much sense to read sectors that are about to be overwritten. Did those READ commands occur before you started running dd? Definitely not. I attached a log of a good (working) dd, showing only the USBC transactions. The '\n ( commands are READ_10, the \n * commands are WRITE_10. --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 0.1075367,DATA1U S B C '28' } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '134' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','11620' 0.11749112500,DATA0U S B C '29' } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '136' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','18350' 0.12037962500,DATA1U S B C '30' } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '138' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','14500' 0.12338658333,DATA0U S B C '31' } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '140' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','12868' 0.13044325000,DATA0U S B C ! } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '144' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','35792' 0.13647270833,DATA0U S B C # } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '148' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','65082' 0.1395163,DATA1U S B C $ } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '150' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','2766' 0.14351329167,DATA0U S B C % } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '152' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','24580' 0.1493710,DATA0U S B C ' } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '156' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','5614' 0.15239312500,DATA1U S B C ( } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '158' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','46821' 0.15538312500,DATA0U S B C ) } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '160' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','56528' 0.15837558333,DATA1U S B C * } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '162' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','41946' 0.16438162500,DATA1U S B C COMMA } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '166' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','24014' 0.17036941667,DATA1U S B C . } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '170' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','18446' 0.17337262500,DATA0U S B C / } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '172' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','17134' 0.17638162500,DATA1U S B C 0 } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '174' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','19995' 0.1793798,DATA0U S B C 1 } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '176' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','58501' 0.18537245833,DATA0U S B C 3 } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '180' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','37231' 0.1913778,DATA0U S B C 5 } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '184' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','3921' 0.19437162500,DATA1U S B C 6 } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '186' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','28763' 0.19737454167,DATA0U S B C 7 } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '188' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','31419' 0.20038425000,DATA1U S B C 8 } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '190' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','55728' 0.20637004167,DATA1U S B C : } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '194' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','3546' 0.21338287500,DATA1U S B C } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '198' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','62414' 0.21635858333,DATA0U S B C = } '0' '0' '0' '224' '1' '0' '0' '0' \n * '0' '0' '0' '146' '30' '0' '0' '240' '0' '0' '0' '0' '0' '0' '0','56423' 0.37253541667,DATA1U S B C } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '200' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','24069' 0.3775197,DATA0U S B C ? } '0' '0' '0' '4' '0' '0' '128' '0' \n ( '0' '0' '0' '164' '202' '0' '0' '2' '0' '0' '0' '0' '0' '0' '0','25840'
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 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 though. Can it handle differential signalling ? That looks like a simple logic analyser. Even if it can trace the usb signals, it is unlikely to be useful for looking at the USB data - in particular it probably can't trigger on anything inside the packets. We've one of these http://www.mqp.com/usb500.htm but I can't recommend it since I can't manage to get it to trigger sensibly on anything. Being able to centre the trace on an error event would be nice! Possibly I just need to RTFM :-) David -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 ports and since we can detect the error condition in software, we could signal the error condition on the gpio port and use that to stop sampling. In the worst case, we can return it (sparkfun is just around the corner... ;-). --david On Tue, Mar 11, 2014 at 4:16 AM, David Laight david.lai...@aculab.com 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? for full-speed USB it should work, I guess. Never tried though. Can it handle differential signalling ? That looks like a simple logic analyser. Even if it can trace the usb signals, it is unlikely to be useful for looking at the USB data - in particular it probably can't trigger on anything inside the packets. We've one of these http://www.mqp.com/usb500.htm but I can't recommend it since I can't manage to get it to trigger sensibly on anything. Being able to centre the trace on an error event would be nice! Possibly I just need to RTFM :-) David -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 though. Can it handle differential signalling ? That looks like a simple logic analyser. Even if it can trace the usb signals, it is unlikely to be useful for looking at the USB data - in particular it probably can't trigger on anything inside the packets. We've one of these http://www.mqp.com/usb500.htm but I can't recommend it since I can't manage to get it to trigger sensibly on anything. Being able to centre the trace on an error event would be nice! Possibly I just need to RTFM :-) try totalphase with advanged triggering option, it's the best susb sniffer I've ever used (I've had both USB2 and USB3 versions). my 2 cents -- balbi signature.asc Description: Digital signature
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 kernel messages and a command log trace, so that's why after the 8th NAK you see nothing more going on. In reality, the OUT commands keep getting NAKd after the kernel messages are printed. From what I can see, usb-storage sends a valid WRITE10 command indicating that it will write 61440 bytes. Actually it says that it will write 122880 bytes. After ~147x 64-byte writes (~9408 bytes) the NAKs start. Previous WRITE10s with same length work fine. Anybody sees anything wrong in this trace? 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? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MAX3421E: device giving NAKs forever?
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 infinite NAKs. After receiving 8 contiguous NAKs, my driver prints some kernel messages and a command log trace, so that's why after the 8th NAK you see nothing more going on. In reality, the OUT commands keep getting NAKd after the kernel messages are printed. From what I can see, usb-storage sends a valid WRITE10 command indicating that it will write 61440 bytes. Actually it says that it will write 122880 bytes. Ah, OK. After ~147x 64-byte writes (~9408 bytes) the NAKs start. Previous WRITE10s with same length work fine. Anybody sees anything wrong in this trace? 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 should try the enable UHCI only trick to see if I can test the device at full-speed on my computer. --david Alan Stern -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 suppose I should try the enable UHCI only trick to see if I can test the device at full-speed on my computer. Yes, definitely, so that you are testing under the same conditions. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 1-1.2: new full-speed USB device number 16 using ehci-pci [ 951.055170] usb 1-1.2: not running at top speed; connect to a high speed hub [ 951.061791] usb 1-1.2: New USB device found, idVendor=058f, idProduct=6387 [ 951.061797] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 951.061802] usb 1-1.2: Product: Mass Storage [ 951.061805] usb 1-1.2: Manufacturer: Generic [ 951.061809] usb 1-1.2: SerialNumber: BCABB02D [ 951.062390] scsi5 : usb-storage 1-1.2:1.0 [ 952.060285] scsi 5:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 4 [ 952.061585] sd 5:0:0:0: Attached scsi generic sg3 type 0 [ 952.064648] sd 5:0:0:0: [sdc] 1968128 512-byte logical blocks: (1.00 GB/961 MiB) [ 952.065793] sd 5:0:0:0: [sdc] Write Protect is off [ 952.065801] sd 5:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 952.067012] sd 5:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 952.076695] sdc: sdc1 [ 952.080629] sd 5:0:0:0: [sdc] Attached SCSI removable disk With this setup, I can write to the device just fine: dd if=/dev/zero of=/dev/sdc1 count=1 1+0 records in 1+0 records out 512 bytes (5.1 MB) copied, 15.1192 s, 339 kB/s No infinite NAK issue. Still scratching my head... --david On Tue, Mar 11, 2014 at 1:00 PM, Alan Stern st...@rowland.harvard.edu wrote: 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 should try the enable UHCI only trick to see if I can test the device at full-speed on my computer. Yes, definitely, so that you are testing under the same conditions. Alan Stern -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 requests that get NAK'd a couple of times, but eventually go through fine. So I think OUT re-transmissions are fine. That drive still fails eventually with infinite NAKs, but this one on a bulk-IN transaction. I agree, it's time to get a bus analyzer. cheapest you can find is totalphase.com's USB 480. They have the added benefit of working under windows, linux and mac osx. I'd strongly suggest getting usb480 rather than usb12, as usb12 can only do descriptor parsing :-( http://www.totalphase.com/products/beagle-usb480-power-standard/ -- balbi signature.asc Description: Digital signature
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 eventually go through fine. So I think OUT re-transmissions are fine. That drive still fails eventually with infinite NAKs, but this one on a bulk-IN transaction. I agree, it's time to get a bus analyzer. --david On Sun, Mar 9, 2014 at 9:11 AM, Alan Stern st...@rowland.harvard.edu wrote: 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 after about 2MiB. I attached two logs: first one is the usb-storage debug output without usbmon (fails after about 500KB of writing to /dev/sda1), second is with usbmon (fails about 2MiB of writing to /dev/sda1). I didn't see anything unusual in the logs. It looks like you'll have to use a bus analyzer to see the actual packets on the wire. Alan Stern -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 though. Can it handle differential signalling ? -- balbi signature.asc Description: Digital signature
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 same response, forever. I see this both with a mass storage device and a WIFI adapter (which is specifically advertised as being USB 1.1 compatible). Anybody have any ideas where that might be coming from? --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 MAX3421E retries NAK'd transfers in the next frame again, only to get the same response, forever. I see this both with a mass storage device and a WIFI adapter (which is specifically advertised as being USB 1.1 compatible). Anybody have any ideas where that might be coming from? take a look at usbmon and capture some traces of a live session. We need pre- and post- data. The more the merrier ;-) You can read about usbmon on Documentation/usb/usbmon.txt in your kernel source tree. cheers and good luck -- balbi signature.asc Description: Digital signature
