On Tue, Apr 19, 2005 at 01:46:06PM -0400, Alan Stern wrote:
> > Sorry - I didn't want to imply I knew 2.6.11 was the first
> > broken rev. I just happen to be using 2.6.11 now.
>
> You said that "dd" worked under 2.6.10 and failed under 2.6.11. Or did I
> misunderstand?
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.
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.
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.
> > Well, the HP r707 camera worked fine with 2.4.25.
> > Are 2.4.x USB storage drivers slower than 2.6.x implementation?
> > async vs sysnc xfer or something like that perhaps?
>
> 2.6 does do USB storage transfers much faster than 2.4. Something like
> async vs. sync, yes. In more detail, 2.6 queues an entire transfer at
> once so it can take place at the maximum speed of the bus and device,
> whereas 2.4 queues only a page or two at a time.
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".
> You could try using the "Low-Performance USB Block driver" (ub) instead of
> usb-storage. As the name implies, it runs more slowly than usb-storage.
> It's under the Device Drivers/Block devices menu in the kernel
> configuration.
I'll try that when things consistently fail.
> > While I've tried to apply these patches to 2.6.11, I feel like we
> > are going down the wrong path. Is error recovery a normal part of
> > block read when talking at device and no one is physically touching
> > the USB bus?
>
> 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.
> > My experience is primarily with SCSI and PCI bus devices where it
> > is not.
>
> 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. :^(
> > I'll pull a 2.6.12-rcX kernel and see if it works better
> > and then apply the patches there if they aren't already included.
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.
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.
BTW, between testing the transfers, I plugged in the USB mouse.
That worked fine and didn't change the (good) test results.
I've copied a good and corrupted version of one of the images:
ftp://gsyprf10.external.hp.com/kernels/ob500/hpim1651\*
And the current version of "rsync_canon":
-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
-rwxr-xr-x 1 grundler users 1011 Apr 19 16:13 rsync_canon*
grundler <514>cksum hpim1651.jpg-*
1619219520 1836278 hpim1651.jpg-corrupted
2669753760 1836278 hpim1651.jpg-good
thanks and hth,
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
