On Wed, Apr 20, 2005 at 12:25:58PM -0400, Alan Stern wrote: > On Tue, 19 Apr 2005, Grant Grundler wrote: > > > Sorry - I stated what I don't know for sure badly. > > The 2.6.11 definitely fails on the ob500. > > I'm not sure now if 2.6.10 also works or fails. > > It might have been 2.6.8.1 or 2.6.9 that worked. > > I'll try to record more details below so it's not ambiguous. > > At this point it probably doesn't matter much where the breakage occurred, > even if the precise spot can be identified.
*nod* I want to nail down exactly where/how things fail or work. Better documentation. Bloody tedious but necessary since I was too sloppy before. ... > > Two configurations do work: > > o 2.6.11 on ob4100 > > o 2.6.12-rc2 on ob500 *after* turning on the camera the second time. > > Have you tried those usb-storage patches on 2.6.12-rc2 yet? Not yet. I will try those in the next couple of days and report back. The previous excercise was to determine a baseline. Not point in trying a patch if I can't tell you exactly what the previous behavior was and how the patch changes it. ... > > And for dd experiments I was running, that makes sense since > > anticipatory read-ahead will increase the block size as we move > > forward. The dd won't read another block until the previous one > > completes. Maybe that's why it failed at the same location > > in the "disk". > > Did you ever try telling dd to start reading from that particular sector? No. that's a good idea. I'll try "start" param and see how that behaves IFF I have the opportunity to test that config again. ... > > This is an Omnibook 500 laptop - no chance of using a PCI card with it. :^( > > How about a PCMCIA card? (Although you probably won't need it now that > you have this workaround of resetting the camera.) Yeah, it has one PCMCIA slot. But you could understand I would strongly prefer the built-in stuff to "Just Work". ... > > I rebooted to 2.6.11 (sans Mouse) kernel and did the same thing > > again (camera was connected but powered off, then powered on the > > camera and ran rsync_canon). That failed with corrupted jpeg files > > like expected. > > At least it's failing! Things would be much worse if the transfers > appeared to succeed but the files were corrupted. Sorry - my bad again - the "much worse" case is exactly what's happening. See the two examples I've posted on gsyprf10: grundler <504>ls -l hpim1651.jpg-* -r--r--r-- 1 grundler users 1836278 Apr 19 15:03 hpim1651.jpg-corrupted -r--r--r-- 1 grundler users 1836278 Apr 19 16:16 hpim1651.jpg-good The tranfers are completing with the right number of blocks. There is some dmesg output associated with it but it's not visible to the controlling tty. I also can't pin the output to any particular transaction....and I'm wondering WTH I did with the output since I know I captured it someplace. Let me find that and post it along side the other data files. Sorry...getting sloopy again. ... > Could be. You may also find that the new usb-storage patch is able to > recover from this error automatically, with no need to reset the camera. *nod*. I'll have a chance to try that out soon. thanks for you advice and patience...I feel like I'm bumbling about on this one worse than I normally do. I guess that's a clear sign I'm hacking around on this too late at night. thanks, grant ------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
