On Thu, 19 Aug 2004, Theodore Kilgore wrote: > Why do I have problems only with > this camera and not with others, not even with other cameras suported by > the same libgphoto2/camlibs/sq905 driver?
> And, to recapitulate, on my other box things work very well for this same > camera, using the same code. And also all other cameras in my possession > which use the same driver (four of them, or so) will work on both > machines, just fine. 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. > Still not sure I actually succeeded in turning off hotplugging. What is > one supposed to do? Delete all references to it from the system? To repeat > what I did: I removed executability from /etc/rc.d/rc.hotplug, and also > rebooted with kernel parameter "hotplug" passed on the LILO command line. > According to what I read, either one of these separately is supposed to be > enough. The procedure certainly did keep the USB modules from loading. > But I still see references to hotplugging in the debug output, after that. 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"). 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. > > 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, that gives some more error > messages. I located that parameter option in drivers/usb/core (and no > other parameter options that I could see, then completely restarted the > usb system, using > > modprobe ehci_hcd > modprobe uhci_hcd > modprobe usbcore usbfs_snoop=y > > (and of course manually remounting usbfs) > > 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: It would be a lot easier to see what's going on if you got all the kernel messages in a single file instead of splitting them up into three. You will have to edit /etc/syslog.conf and add a line something like this: kernel.* /var/log/kernel Or even do: *.* /var/log/all Alternatively you could use dmesg. But that has a limited buffer size and doesn't add timestamps. 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. 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. 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. Maybe with this information you can track down the offending command. It might help to make ghoto2 write a line to the system log before each bulk message. Alan Stern ------------------------------------------------------- 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
