Nemosoft wrote:
> > > I have a similar problem: I found out that accessing a CompactFlash
> > > in PIO mode to much will cause the pwc to stop working. It usually
> > > gives this kernel message:
> > >
> > > "pwc_isoc_handler() called with status -75 [Babble (bad cable?)]"
> > >
> > > The user process accessing the camera never returns from read().
> > > Only removing the driver modules and re-inserting them will "solve"
> > > the problem. (this is not a solution because reloading en initializing
> > > the camera driver takes many seconds: I'm building a real-time image
> > > processing application).
>
> Hmm, using an USB camera might not be the best solution (ie. I've found USB
> isn't that reliable with ISOC transfers and such, and random errors crop up
> quite often).
Hi Nemosoft, nice to see you join the discussion ! :-)
For my application I did not encounter *any* stability problems during
literally hundreds days of continuous testing hours. Maybe there's
a frame garbled or dropped every now and then. Don't know, it's not
important for my application. But I never had the system hang or the
USB stop or whatever: it just keeps running.
But that all is of course without any substantial CF access. As soon
as I access the CF there is the "dead camera" problem. You only can
get away with very small writes (<4 disk sectors or so) and that's
what I do now (I need to log data on the CF).
But this severely limits the things I can do with my application.
I'll explore the tests & suggestions from the list !
> > > The problem can be triggered instantaneously by doing a:
> > >
> > > cat /dev/hda > /dev/null
> > >
> > > I'm not sure but I suspect that the problem is in the USB layer and
> > > not in the Philips webcam driver.
>
> Partially. I agree that the PWC error handling could be better, but
> sometimes USB errors are transient and you don't want to return an error
> and close the device at every bit that has fallen over. I'm working on
> this, by only setting an error condition if a number of consecutive USB
> frame errors occur.
Yup, would be nice. I'd prefer the device to not error and close but
just keep on trying. At least for some time.
But note that this is not the problem here. The user application hangs
in a read(), there is no userpace error returned or close.
greetings,
Rob van Nieuwkerk
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
