>>The process of capabilities discovery includes turning on isoc and the saa711x, and this results in a bunch of non-valid data packets
David, you have load SAA7115 instead of the older SAA711X module right?
>>I suspect the problem has shifted to where the chip is being asked to send more then the endpoint's actual packet size, or something in that area. Red herring?
The packet size is this... #define USBVISION_MAX_ISOC_PACKET_SIZE 959 // NT1003 Specs Document says 1023 .
It's true, the NT100x spec docs say 1023 is the max, but the snoopy logfiles did say only 959 with any device which we had a snoppy log file from. Try changing this to the 895 and see.
I don't think it's going to help. But we should try it and see.
>>As you did core_debug=36 (1<<2 (DBG_ISOC) + 1<<5 (DBG_FUNC)) you should see it. If not, this is a bug :)
>>Do you have some windows usbsnoop dumps ? If so, we could analyze them to see which alternate is selected and which packet size is selected.
The other devices have the similar packet size. Here is the URL. Looking through memory lane right now.
Here is an example of some digging into the usb code.
Updated to kernel 2.6.14. Still get the -90 error. This is with usbvision 0.9.3 dated November.
Looking in the code for urb.c it looks like all the ways of getting that error have to do with the size of the transfer_buffer. The size being passed is 30688 bytes (32*959). I notice the max size is 0x7FF if (dev->speed == USB_SPEED_HIGH). This hardware only has USB1.1 so I am not sure if that has anything to do with it.
Looking in the code for urb.c it looks like all the ways of getting that error have to do with the size of the transfer_buffer. The size being passed is 30688 bytes (32*959). I notice the max size is 0x7FF if (dev->speed == USB_SPEED_HIGH). This hardware only has USB1.1 so I am not sure if that has anything to do with it.
The max limit on ISOC packet size being enforced by urb.c appears to come from hub.c doing some query against the hub. In my case the "hub" is the one on the VIA motherboard. It was working fine last year with a 2.4 kernel.
So as an experiment I just commented out the check in the usb_submit_urb routine in urb.c. It worked! No more -90 errors and I can grab frames with videodog. But I have no idea about the long term viability of this quick fix. I don't have a set of 2.4 sources to compare with.
The device did work in kernel 2.4.x and seemed to break in 2.6.x.
So as an experiment I just commented out the check in the usb_submit_urb routine in urb.c. It worked! No more -90 errors and I can grab frames with videodog. But I have no idea about the long term viability of this quick fix. I don't have a set of 2.4 sources to compare with.
The device did work in kernel 2.4.x and seemed to break in 2.6.x.
Dwaine
----- Original Message ----
From: David Warman <lanwolf@xxxxxxxxxxx>
To: video4linux-list@xxxxxxxxxx
Cc: Dwaine Garden <dwainegarden@xxxxxxxxxx>; Thierry MERLE <thierry.merle@xxxxxxx>
Sent: Thursday, April 26, 2007 2:40:24 PM
Subject: Re: Belkin USBView II
No, that bit of code is correct, so my problem is not there. I think it is elsewhere entirely.
From: David Warman <lanwolf@xxxxxxxxxxx>
To: video4linux-list@xxxxxxxxxx
Cc: Dwaine Garden <dwainegarden@xxxxxxxxxx>; Thierry MERLE <thierry.merle@xxxxxxx>
Sent: Thursday, April 26, 2007 2:40:24 PM
Subject: Re: Belkin USBView II
Hi Thierry,
The process of capabilities discovery includes turning on isoc and the saa711x, and this results in a bunch of non-valid data packets. I turned on camorama's debug facility also, and it is complaining about VIDEOCGCAPS failing. IIRC, that is a v4l1 ioctls request, and the current system I am building is v4l2. I thought there was a compatibility layer, but it seems not to be working for camorama. Or for vlc, which I just downloaded and looks for v4l-vdev="/dev/video0", and complains "v4l demuxerls -al
error: cannot get capabilities (inval;id argument)".
I am looking for another imager program I can trust. gqcam connects but displays all 0's for camera details, as if it also failed the caps collection but decided to run with the empty struct instead of failing out. xawtv doesn't run. I am about to test with ffmpeg + ffserver; tho that is a more complex setup I trust ffmpeg more. I have the feeling that once I get connected properly, the system will work.
As always , thanks for your continuing help on this project. It looks like when I am done I may have a patch or two to submit.
Regards,
David Warman
On Apr 25, 2007, at 9:56 PM, Thierry MERLE wrote:
Hello David,David Warman a écrit :Implemented the changes mentioned, made a little bit of progress.Now, running camorama with the modprobe usbvision debug flags set (video_debug=4 core_debug=36), I get a stream of full size packets with bad status (len=895, status=FFFFFFB5 - EOVERFLOW?), then a few null packets and then about 42 empty packets before power off completes and camorama abandons the attempt to start up. More than the dmesg buffer can hold, so I do not have the start-up end of the trace.Earlier, in the older v4l1 code, I noticed that the value from the USBVISION_ALTER_REG register was used to compute the packet size for the isoch urbs, but that the computation resulted in a packet size 64 bytes too large (regValue needed -- to get the matching value) when checked against the max packet size reported in the endpoint alternate selected. That particular line of code is no longer in usbvision_init_isoc, and I am hunting down the allocation code now. I suspect the problem has shifted to where the chip is being asked to send more then the endpoint's actual packet size, or something in that area. Red herring?Any comments and/or pointers would be welcomed ....The packet size is taken from the USB descriptor now.In usbvision-core.c:2455 (usbvision_set_alternate):if (dev->ifaceAlt != prev_alt) {dev->isocPacketSize = dev->alt_max_pkt_size[dev->ifaceAlt];PDEBUG(DBG_FUNC,"setting alternate %d with wMaxPacketSize=%u", dev->ifaceAlt,dev->isocPacketSize);As you did core_debug=36 (1<<2 (DBG_ISOC) + 1<<5 (DBG_FUNC)) you should see it. If not, this is a bug :)Do you have some windows usbsnoop dumps ? If so, we could analyze them to see which alternate is selected and which packet size is selected.Regards,Davdid WarmanCheers,Thierry
David Warman
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
