On Fri, 20 Aug 2004, Alan Stern wrote:
> If you don't know the answer, there's not much chance I can help. You > know more about the cameras and gphoto2 than I do. But remember, even > though it appears that the same code is being used, you're forgetting > about the code that runs inside the cameras. Obviously that's going to be > different for each camera. > Well, yes, and no, I would suspect. I would guess that so long as two cameras use the same controller chip, they are pretty much identical. The issue with this particular camera could well be, that I seem to have a new chip from the manufacturer of an older chip, for which the driver routine is quite well established. And the new chip runs with the old driver code on one of my boxes, but not on the other. > > > rebooted with kernel parameter "hotplug" passed on the LILO command line. > Making rc.hotplug non-executable would be more than enough. I don't know > about the kernel parameter (and in any case it seems likely that you would > have to say "nohotplug" or "hotplug=off"). Oops. Typo. I used the parameter "nohotplug". The references you see in the > debugging output are there because you didn't rebuild the kernel without > hotplug support. Don't worry about them; it's the runtime routines that > matter. > Thanks. This does clear up the mystery about the log messages. And next time if there is a next time to get into such things, I will know. > > > Also, you could try loading the usbcore module with the usb_snoop=y > > > parameter. That way if any other program is communicating with the camera > > > you'd be able to tell. > > > > > > > Perhaps you meant usbfs_snoop=y instead? > > Yes, sorry about that. > Well, darned good thing that I am not a total greenhorn :) > > > > and received the following outputs in /var/log/debug, /var/log/messages, > > and /var/log/syslog presented in that order below, beginning in each > > case at 20:14:20 or right after that, which is when I restarted the > > system and then plugged in the camera at 20:16:02 and ran gphoto2 -P > > --debug 2>debug: > > Anyway, it looks like at 20:16:43-44 gphoto2 sent a sequence of bulk-in > messages that the camera didn't like. In fact, there appear to be about > 23 bulk transfers, 10 of which didn't succeed. Yes, gphoto2 in debug mode catches that. And for that matter, that's what the photo looks like, too, that one gets out at the other end. Big black stripes across it where there is supposed to be data and there is none. > Then at 20:16:49 the > program sent some control messages that the camera didn't respond to at > all -- probably the camera's firmware had crashed. > > This does seem to exonerate the hotplug system, at least. I am glad to have the opinion of someone more knowledgeable that I am about the "guts" of the system about this. It does help to narrow things down. Still, I do wonder why the camera functions perfectly on one computer and not on the other. I would think that if the camera does not like gphoto2's command sequence, it would not work on either one of the boxes, or if it finds nothing objectionable it would work on both. Don't take this as an argumentative stance, please. I am just restating that I am puzzled. > Whatever the > problems, they appear to be a result of the camera's reaction to gphoto2's > messages, not a result of interference from another program. > As I said, it is good to know that if one has a problem, then X and Y are _not_ the cause. So again thanks for your help. > Maybe with this information you can track down the offending command. It > might help to make gphoto2 write a line to the system log before each > bulk message. > A possibility, yes. Now I am just guessing, but on thinking about the matter I can see another potential source of the problem: Gphoto2 is a "userspace" program which uses libusb to communicate with the USB system. Could it be that the glitches come from somewhere within libusb? If so, then, since apparently your expertise is in the kernel USB area, who is the expert on libusb and how would it be possible to localize the source of any problems from that side? Thanks again for help. Theodore Kilgore ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
