On Fri, 2005-02-11 at 16:36, Alan Stern wrote: > > I get wedged as usual and I have to "kill -9" my viewer program from > > elsewhere in order to rescue the situation. > > Why do things get wedged instead of failing gracefully? >
Well, assuming you hadn't intended to put a smiley on that, they get "wedged" because that's how I describe submitting a URB (8 of them actually) and none ever calls me back with data after some given point (receiving a short URB signalling end-of-frame). It's also graceful in that the kernel doesn't crash, and I can escape from the problem without rebooting, but it's still a "wedge" as far as my camera driver is concerned. Maybe a better word should be thought up... > > However, I also get no messages in /var/log/messages and nothing from > > the output of 'dmesg' either. What did I miss? > > Nothing at all? Not even the normal kernel boot-up messages? > Sorry, no, of course I get all that stuff. Just no new debug messages from anywhere in the USB layers to tell me (or you) what's going on. > > Meanwhile, I ran my driver with detailed debugging of its own and what I > > see is like this: > > > > .... > > Receive 32768 bytes from camera: add it to the image-buffer > > Resubmit URB > > Receive 32768 bytes from camera: add it to the image-buffer > > Resubmit URB > > Receive 20667 bytes from camera: add it to the image-buffer (that marks > > the end of frame). This URB has been composed from 41 full 512 byte > > bulk-packets plus one half-filled 512 byte bulk-packet. > > Resubmit URB > > > > [no more IRQs hit my callback function over the next tenth of a second] > > > > The timebomb goes off. > > Tell the camera to stop streaming. > > Release all URBs. > > > > This is as close as I can get to diagnostics, since I don't have useful > > access to the next layer down. > > Is it possible that the camera stopped transmitting data on its own, and > that's why your completion routine doesn't get called? > I'd always assumed it was camera firmware until I saw the results from the USB logger. That's where it started to look like linux stopped polling. > You said before that your bus analyzer showed the computer had stopped > polling for bulk data. Are you sure that's what happens? There are files > you can read, containing debugging data for the ehci-hcd driver. I don't > remember where those files are located and I don't know what the data > means, but maybe the driver's maintainer can tell you and interpret the > contents. If an URB has been submitted but isn't on the schedule, perhaps > it will show up there. > I was rather hoping that the driver's maintainer might wade in here with suggestions as to how we might home in on this problem. It may well not be as far down as ehci-hcd. Where else can I put a "debug=X" at module load time, and what values of X would be useful do you think? > Is it possible for you to test the camera with a different computer? > Done that. Same results with an Athlon 2100+ and two different P4 based machines. > Does the hardware permit you to run at at USB full speed instead of high > speed? If it does, what happens if you rmmod ehci-hcd? > It can't do that, no. > Alan Stern Steve. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
