On Fri, 19 Mar 2004, Brad Campbell wrote:
Funny you should mention that, It's exactly what I spent all morning doing
After more investigation it comes down to 4 bytes that cross the sector boundary
bklaptop:~>hexdump lf3 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 00001f0 0000 0000 0000 0000 0000 0000 0000 ffff 0000200 ffff 0000202
I now have a file that is 514 bytes, it's all zero's until the last 4 bytes. It started with ffbb ffff in that file I posted lastnight, but I have reproduced it with the file hexdumped above.
That suggests a few questions -- you're probably already way ahead of me.
Not quite, but I think were moving in a similar direction.
Does it matter what's in the first 510 bytes (or the 510 that follow, since I/O always goes in multiples of 512 bytes)?
Nope, it's only the 4 bytes (2 pre and 2 post the sector boundary)
Does it have to be four 0xff's? You said 0xbb in one of the
positions would also cause a problem.
I'm not completely sure, I have to research that further but assembling test cases with dd and echo is getting a little tedious. I wish there was a good ncurses based file hex editor like the old Norton Diskedit for linux (he says hoping someone will point him at one). I won't have time to look at it now for a day or so.
Just a thought, but does anyone know if USB does endian swapping of words or something similar? I have an idea I need to look at further.
The difference may be the sequence of bits going across the wire. Certain bit patterns may cause problems for the packet-reassembly circuitry in the Genesys interface.
Thats what I figure. I hope it does not mean we have to inspect each packet before it goes out, I can see the cpu usage skyrocketing. At least it's in a defined place in the packet however. I wish I had my digital storage cro still as it happens at 12mbps also and would not be that difficult to actually capture.
Does it matter which sector boundary, that is, where on the drive the file gets written?
Not that I can tell, I tried padding the test file with different numbers of null sectors (512 bytes) and they all seemed to lock it up the same way. I'll try spitting it to various parts of the disk when I next get a chance to try and damage things further.
I'm going to try an knock up a script to narrow down the combination of bytes, but it's slow going as every time it latches up I have to unplug it, rmmod usb-storage, power cycle the drive and wait for it to do it's power on seek and then re-plug the drive. I'm just waiting for the repeated rapid power cycles to kill the disk now.
Do you have a Windows system you can use to write a file containing the bad byte sequence?
Yes, my laptop has a winxp partition I installed specially for this task and my desktop had a win2000 partition I use for a similar purpose.
It you do, does it work? Apparently so.
If it does, how can we find
out what's different?
I'm not sure, I thought perhaps I could install some usb protocol sniffer and see what gives. I don't have a phone line at home at the moment so I find it difficult to interact out of work hours and it means if I forgot to download something it has to wait until the next day. Damn Etisalat!
Maybe Windows deliberately breaks up the
transmission when it sees the forbidden sequence crossing a sector boundary.
That was my suspicion but I know less about windows and it's usb stack than I know about the linux stack and what I know about the linux stack I could write on a post it note. I am learning however.
Regards, Brad
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
