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.
> 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?
> I recently was given an Omnibook 4100 (P-II, 266Mhz). It works with 2.6.11.
> I was able to "rsync_canon" the jpg files off the camera no problem.
>
> OB4100 has the same USB controller as Omnibook 500 (according to lspci
> at least):
> +-07.2 Intel Corporation 82371AB/EB/MB PIIX4 USB
>
> [EMAIL PROTECTED]:/root$ lspci -vvs 0:7.2
> 0000:00:07.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev
> 01) (prog-if 00 [UHCI])
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 64
> Interrupt: pin D routed to IRQ 10
> Region 4: I/O ports at fcc0 [size=32]
>
> ob500 has identical Control/Flags and a different IRQ and
> I/O port address. OB500 has PIII (750Mhz) and a different
> memory controller/gfx/etc. Timing on the host side matters too.
Yes. Although in cases like this it's not easy to understand exactly
_how_ it matters.
> ok - so no "setup for DMA" gap between pages. For "rsync_canon", this
> would matter since the files are 1-4MB in size and we could end up
> setting up lots of inbound DMA at once.
>
> 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?
> > Your question isn't entirely clear. Error do happen from time to time,
> > even when nobody is physically touching the USB cable. They can be caused
> > by several factors, including electromagnetic interference, faulty
> > electrical termination on the connectors, clock instability, bad firmware
> > on the device, and who knows what else. When an error occurs, error
> > recovery is normal and important.
>
> Yeah, I'm just trying to get a handle on what's "normal" and what isn't.
> SCSI suffers the same issues you listed and "from time to time" I
> would expect errors. But not consistently after reading a certain
> number of blocks.
That's a new one for me as well.
> > USB hardware seems to be of lower quality generally. I've heard good
> > things about NEC's EHCI controller chips; you could try getting a PCI card
> > with one of those. It might work better than your computer's controller.
>
> 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.)
> Interesting experience with the 2.6.12-rc2 kernel I built and tried
> last night. It "Just Worked". I plugged in the HP r707 camera, turned
> on the camera, then ran rsync_canon script. All the files transferred
> just fine. Don't ask me.
>
> Before testing 2.6.12-rc2, I unplugged the "low speed" USB mouse
> ("USB HID v1.00 Mouse [Logitech N43]"). My intent was to simplify
> the configuration. But then I had to figured out if that was the
> difference or was something fixed in the new 2.6.12-rc2 kernel.
> That's what I tried to establish this afternoon.
>
> 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.
> Reboot to 2.6.12-rc2 and repeat the same test. This time the jpg
> files copied from the camera were corrupted. Whimsically, I turned
> off the camera, renamed the target directory (mv 0417 0417-corrupted)
> and powered the camera back on again.
> This time rsync_canon was able to copy all the jpeg files properly
> from the HP r707 to the laptop. I turned off/on the camera
> several times and it properly copy the files without corruption
> each time. Only the first time I powered on the camera *after*
> booting 2.6.12-rc2 did I see corrupted transfers.
>
> Again, no clue what's up here. Sounds like an initialization problem
> of static data someplace.
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.
Alan Stern
-------------------------------------------------------
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
