• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 654 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

How do I enable VPIF debugging statements to come out?

Helmut Forren
Mastermind 6805 points

I tried setting VPIF_DEBUG=2, just like I set DMAI_DEBUG=2, but that didn't cause the vpif_dbg() function output to be seen on my DM6467T serial port.  How do I get these debugging statements to display, without recompiling and reinstalling the kernel?

Thanks,

Helmut

  • 0
    Mastermind 6805 points

    I finally figured this out myself (plus some back channel assistance w/ another forum user).

    Trace messages from the kernel will come out to the console during boot, but not later while such as while an application is running.  I suspect this is because during boot the kernel has a stdout, but later it does not.  NEVERTHELESS, these trace messages will ALWAYS go to a log file that can be viewed with the "dmesg" command.  So, you can see your kernel messages produced while an application is running by running the "dmesg" command AFTER the application has run.  (Yes, you might have to do some hard thinking or tactical message arranging to synchronize your application's console output with the dmesg result.)

    About the messages,

    v4l_info() messages will be generated in all cases.

    V4l_dbg() messages will only be generated if the kernel is compiled with the particular debug flag turned on.  This comes from the git .config file.  I'm not sure exactly which of the multiple debug flags corresponds to v4l_dbg().  I simply turned on most of them.

    You can also do printk(KERN_CRIT ...) where ... are the same parameters you would pass to printf().  There's a space, not a comma, between "KERN_CRIT" and "...".  This must be handled by a macro to generate compilable C code.  There are also other values than KERN_CRIT, but if you want to be certain it comes out, this will do it.

    Meanwhile, the DMAI debug stuff works with an environmental variable because DMAI is linked into the application, not the kernel.  It's all a question of which side of the fence you're on:  application or kernel (O/S).

    -Helmut