This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USB lockup on high frame rate ISP

Other Parts Discussed in Thread: DM3730

Hi all,

 

I'm facing a strange issue on BeagleBoard XM boards (DM3730 cpu). We are using a leopard VGA camera module (MT9v113) connected to the ISP driver. This works but when the frame rate of the ISP driver is high (around 30) at some point in time the USB subsystem will lockup (most of the times beween 10 and 30 secondes) . The ISP and application continue to run fine and no kernel/error messages are shown, only the system is not capable to acces the USB anymore (new devices are not enumerated, and for instance lspci -v gives timeout errors on bus access).

 

We tried to reproduce the issue using a usb cameras but we failed, the issue only shows up when using the MT9v133 device connected to the ISP driver. We can reproduce the error by just capturing pictures using v4l and send those to /dev/null.

I've enabled verbose USB debug and verbose ISP debug but no error messages are shown around the error.

Have anyone else seen this problems before?

 

Thanks,

 

Rudger.

  • I can confirm I can trigger this issue also using the 3MP camera board of leopard imaging. This board is equiped with the MT9T112 3MP sensor.

    To trigger this issue a high framerate 25-30fps should be generated and also some network traffic. At some point in time the network traffic will stop (when other devices are on the USB bus they wil stop too).

     

    Thanks,

    Rudger.

     

  • Rudger,

     

    Are you using USB EHCI port in your test ? There is a known issue of EHCI lockup with heavy DSS traffic and we have a recovery patch on this at http://marc.info/?l=linux-usb&m=129472850014890&q=p3

    Regards,

    Ajay

  • Hi Ajay,

     

    I assume you are right. I've applied the patch and altough it doesn't recover my USB bus automatically I can trigger the recovery mechanism by running "sudo lsusb -v" on the console. I've verified I'm using silicon OMAP3630/DM3730 ES1.0.

    I read on the bug this is solved in ES1.2, can you confirm? Is this silicon available cause this issue will render our product unusable w/o a automatically working work around.

    Regards,

    Rudger.