Alan Stern wrote:
>> But when I transfer 64 bytes at a time, on Connectivity.EZHex, I get 19
>> successful transfers (~1.2k) and the 20th gives me an error of -110, or "No
>> error" (the read was successful).
> 
> 110 is ETIMEDOUT (see include/asm-generic/errno*), which means your
> timeout expired before the data could be transferred.  I suggest you
> increase the timeout to something like 1000 (1 second).

So *that's* where those errors are. Thanks. That'll help.

OK, raising it to a second seems to help a lot. Given that I was able to get
a fair amount further.

Depending on the type of file I transfer (there are two types, the
connectivity test and the Configuration update), I can get some different
results.

With the Connectivity test, I transfer the whole thing and nothing happens.
I believe this to be "success," as that's what happens in other OS's.

With the Configuration Update, I transfer a lot (1050x64 bytes on a 716K
file), and then the device reboots, tests its configuration, and either:

  a. Finds it to be "corrupt"
  b. Says "update your config at the website"

Either way, the device isn't usable in this state. Now - the device
_normally_ reboots and tests it's config, so that's not necessarily
surprising. But it happens before I'm done writing, so as one might expect,
I get:

   Write failed: -19 (error reaping URB: No such device)

That part is clearly not right. And looking at
include/asm-generic/errno-base.h confirms that the error message is indeed
'no such device.'

When it finds it 'corrupt', it seems like it's because it's too old (there
seems to be some sort of timestamp - perhaps relative to the Connectivity
check?), and when it's not too old, I get that later message, which I don't
know what to make of.

Then, I took your advice:

> You can change some module parameters on-the-fly.  In this case you would
> have to write to /sys/module/usbcore/parameters/usbfs_snoop.

But sadly, it wasn't all that enlightening. The main thing that I got from
it was that a lot of data is very repeated within the file I'm sending. The
payload seems to repeat itself quite a lot.

So I went back and "fixed" the remote by updating on my mac and noticed the
software "initializes" it before it "uploads" (generic terms in the GUI),
and looking back at the log from the windows box, it sends a few
CONTROL_TRANSFERs before it starts up the INTERRUPT_TRANSFERs. So there's
one thing I think I'm missing - I don't know what those CONTROL TRANSFERS are.

Finally, near the end of the transfers in the log, there's an "unknown"
function that usblog-dump can't interpret from the USBSnoopy logs. I've
emailed the author with the relevant info, but its a function 0x0e7a:

sequence 1966080: URB 42841, number 42841, offset 7710983, time -230749,
allocs 1

Function: UNKNOWN (0x0e7a)
Endpoint: 0 (default)
Pipe handle: 0x00000000
Flags: 1109393408 [00000000 00000000 00000000 00000000]
        Coming: down
Status: 64
Link: 2621440

Length: 0
Direction: device-to-host

URB header:
Length: 30
Status: 109051968
Flags: 51457 [00000000 00000000 00000000 00000001]


So I suspect there's some special "welcome back to the world" packet it
sends at the end there, but I have no idea what it is. I assume that's the
second piece I'm missing.

I've posted the logs in case anyone can interpret something I've missed:

USBSnoopy Log from friends' windows box:
http://www.phildev.net/linux/harmony/harmony_880-upload_capture-1.usblog.gz

usblog-dump of above log:
http://www.phildev.net/linux/harmony/windows.log.gz

Log of my attempt at a transfer from Linux:
http://www.phildev.net/linux/harmony/linux.log.gz


-- 
Phil Dibowitz                             [EMAIL PROTECTED]
Open Source software and tech docs        Insanity Palace of Metallica
http://www.phildev.net/                   http://www.ipom.com/

"Never write it in C if you can do it in 'awk';
 Never do it in 'awk' if 'sed' can handle it;
 Never use 'sed' when 'tr' can do the job;
 Never invoke 'tr' when 'cat' is sufficient;
 Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming


Attachment: signature.asc
Description: OpenPGP digital signature

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to