Weekly report:
http://beagleboard-usbsniffer.blogspot.com/2010/07/weekly-report-week-7.html
Best regards,
Nicolas
Hi Nicolas,
One idea for making you debug writes less intrusive might be just writing
the debug-statements to RAM and sending them to the UART in another
thread/process (afterwards) in order to not block you USB thread with
debug-writes - Likewise you should easily be able to speed up the UART to
~1Mbps in case not already done 
In case of any trouble understanding the OMAP DMA system please don't
hesitate to let me know...
Best regards
Søren
S�ren Steen Christensen wrote:
Hi Nicolas,
One idea for making you debug writes less intrusive might be just writing
the debug-statements to RAM and sending them to the UART in another
thread/process (afterwards) in order to not block you USB thread with
debug-writes - Likewise you should easily be able to speed up the UART to
~1Mbps in case not already done
that is my debug serial speed since years 
works nice with e.g. FTDI based usb serial converters:
setserial /dev/ttyUSBx divisor 24 spd_cust
Weekly report:
BeagleBoard - USB Sniffer (GSoC 2010): Weekly report - Week 7Best regards,
Nicolas
===
Status:
* Switched to a more recent kernel, based on 2.6.34, to make sure I have
the latest bug fixes, as recommended by Ajay.
* I shifted focus towards debugging the MUSB driver, and particularly the
code path used when DMA is used. It could be possible to debug the MUSB
driver using my proxy driver, connecting the webcam, but the transfer rate
and packet sizes are rather unpredictable, making it hard to reproduce
problems.
I'd say this is probably due to the image of the webcam. You might try
to point it to e.g. a unform colored and lit piece of paper (or wall).
Maybe try to find an isochronous audio device which can be used as
output device. That'll give you more control
(or use audio as input with line in to a fixed freq source.
Frans
that is my debug serial speed since years
works nice with e.g. FTDI based usb serial converters:
setserial /dev/ttyUSBx divisor 24 spd_cust
With the newer HS FTDI chips you can actually go all the way up to 3Mbps
- You can do this with the old FS-chips as well, but without flow-control
this will cause Windows to drop (far too many) characters in RX direction to
really being reliable for debugging 
I haven't tried if it's better with Linux at 3Mbps?
Søren
Sure, this is due to image compression (the first packet is always 18 bytes, i.e., the header, and the rest is variable).
Isochronous audio does not trigger the bug, since this is generally uncompressed WAV, and all the packets have the maximum size (at least on the device I've tested...).
Anyway, if I can fix the bug with my testing setup, I'm quite confident the bug will also disappear with the webcam.
Best regards,
Nicolas
Well, unfortunately, I have some "MCT232"-based converter, and it doesn't seem to support more than 115200... But well, good idea indeed. Another option is to stop logging to the serial port, and fetch data later using dmesg.