Is there any default mechanism to enable debugging the v4l2 drivers.
Basically I want to check something like dynamic debugging by setting in /d.
Compile time flags in make file also fine.
Currently, I had set as below, however not getting much information.
echo -n 0xFFFF>/sys/module/videobuf2_core/parameters/debug
Can anybody help me to get verbose v4l2 logs?
Have a look in the code: As an example the file
drivers/media/v4l2-core/v4l2-ioctl.c
might be one of the more interesting ones, cause it shows you some of the user/kernel-space interactions.
In this file you see a lot of pr_cont, pr_info and others. While printk is always printed, the others only do something, if enabled. All details on this can be found on http://lwn.net/Articles/487437/ .
The nasty way is to just replace some of the pr_cont or pr_info by printk. You can even use a #define to do this. If you only want to enable 3 or 4 of them and even add your own special ones, this might be the fastest way.
The nice way would be to have a look on how the system is thought to be used. You can try if you can enable dynamic debugging, like it is nicely described here https://lwn.net/Articles/434833/ .
Finally the easiest way might be to have a look in the kernel config. Perhaps you already know the command make menuconfig in the source directory.
You can edit all the different settings, and like in vi, you can search using /.
Next to the specific modules, you can usually also enable or disable debugging options.
If that's not enough, you can always change the global debugging level of the kernel in the .config file.
One specific flag you might be interested in is
CONFIG_VIDEO_ADV_DEBUG
Say Y here to enable advanced debugging functionality on some
V4L devices.
In doubt, say N.
Symbol: VIDEO_ADV_DEBUG [=y]
Prompt: Enable advanced debug functionality on V4L2 drivers
Location:
-> Device Drivers
-> Multimedia support (MEDIA_SUPPORT [=y])
Defined at drivers/media/v4l2-core/Kconfig:11
Depends on: MEDIA_SUPPORT [=y]
good luck
Please refer to the official documentation here:
The ‘dev_debug’ attribute that is created for each video, vbi, radio
or swradio device in /sys/class/video4linux// allows you to
enable logging of file operations.
I tested this on real configuration and it works(it prints all info!), see my command below:
echo 0x1f > /sys/class/video4linux/video1/dev_debug
Related
I am trying to run one of the minifilter samples from Microsoft provided here: https://github.com/Microsoft/Windows-driver-samples/tree/master/filesys/miniFilter/passThrough
I don't know what this minifilter is supposed to do (documentation isn't great), but for starters, if I can just see the output from a DbgPrint() statement, I'll be happy. While running Sysinternals DebugView as admin, I did fltmc load passthrough and fltmc unload passthrough, but did not see any output from the filter. I know that at least the function corresponding to the unload feature in the code has a DbgPrint() message:
PT_DBG_PRINT( PTDBG_TRACE_ROUTINES,
("PassThrough!PtUnload: Entered\n") );
Am I supposed to see these messages? If so, how? If not, how can I debug minifilter development?
PS: I did define the Registry key suggested here: https://www.danclarke.com/debugview
You can do it from the debugger attached using the:
ed nt!Kd_DEFAULT_Mask 0x8
Or check this link out as you can also enable it from the registry.
Make sure you've enabled 'Capture Kernel' under the Capture drop-down menu, instead of 'Capture Global Win32' which is what the article you linked us to mentions.
As for the File-System Mini-Filter device driver sample you linked us to, there's plenty of documentation surrounding development of filter-manager drivers available over at MSDN.
If you go into driver development blind with the Microsoft samples, you can't really expect to understand how it all works with a click of a finger... It is very different to user-mode development, you'll be starting from the bottom again.
Look at PT_DBG_PRINT macros in the source code:
#define PT_DBG_PRINT( _dbgLevel, _string ) \
(FlagOn(gTraceFlags,(_dbgLevel)) ? \
DbgPrint _string : \
((int)0))
There is a condition that checks gTraceFlags variable. By default gTraceFlags is 0. So just set that variable to enable DbgPrint, for example:
ULONG gTraceFlags = PTDBG_TRACE_ROUTINES;
I was wondering if there was any way that I could debug a floppy disk emulation in Linux.
The main thing I want to be able to do is to see the values of registers and custom defined bytes and words as the emulation runs.
Another thing I would like to be able to do is to run the emulation one step at a time, and see what line of code my emulation is currently on.
I am currently just running my floppy disk image under qemu-system-x86_64 and letting it run without any feedback besides the emulation.
If anyone can supply me with something along the lines of command line statements that accomplish this sort of thing, and what programs I could either move to or install alongside to help me out, it would be much appreciated.
I don't have enough idea of qemu because I haven't used it much. But from your requirement perspective, I think you should try bochs emulator. It's quite easy to use and comes with a built-in debugger. Only thing is, you need to compile it from source (if on Linux) making sure the --enable-debug and --enable-disasm switches are enabled (alongwith any other options you might want to enable). (On Windows however, the debugger comes as a pre-built (separate) executable in the installation, but that's sort of irrelevant in your case I guess.)
I am new to kernel mode windows driver development and having issues getting debug information out of the WFP callout samples. I am looking for either more options or tips of what I am doing wrong with the options I have been trying.
To start with I downloaded the WFP sampler and followed the instructions in it's description. I am using a Windows 8.1 x64 host and a Windows 7 x64 target connected via a simulated serial cable. They are both VirtualBox VMs.
The primary command I am debugging with is
WFPSampler.Exe -s PROXY -l FWPM_LAYER_ALE_BIND_REDIRECT_V4 -aaid "C:\Program Files (x86)\Internet Explorer\iexplore.exe" -pla 10.0.2.15 -v
Where 10.0.2.15 is the IP address of a diffrent network interface than the routing table is endign traffic to. I also used the following inspect command as recommended by the instructions:
WFPSampler.exe -s BASIC_PACKET_EXAMINATION -l FWPM_LAYER_INBOUND_IPPACKET_V4 -v
"netsh wfp show state" shows the callout and filter associated with the expected layer
However I never got any messages from traceview as per the last steps of those instructions. Tracelog had similar lack of output. This was true with or without WPP tracing enabled on the driver project. I also tried higher verbosity, all to no effect.
Additionally the remote debugger in visual studio either stopped at "Driver Post Install Actions (x64) (possible reboot): Pass" or "Waiting to reconnect..." rebooting the target did not cause more output in the Debugger Immediate Window (the Output window never got any output). Rebooting the target VM did not get any unusual prompts (some things I read implied it should). The reconnect checkbox when setting up the debugger sometimes caused it to get past the "Waiting to reconnect..." prompt, other times it was not needed. I set a number of breakpoints that should have been hit including one at the top of every classify function and none were ever hit.
I tried to debug with WinDbg, but well, frankly I can't find the documentation about how to use this tool. I start it on the target machine and chose kernel debug, local. then I get a prompt that tells me the symbol search path is invalid and no clue what I am supposed to set it to. Any documentation on how to use this tool as opposed to just installing it may be helpful if it lets me debug these callout drivers.
Finally of course I tried just debugging it based on symptoms and I find that the examination callout does nothing as far as I can tell, while the proxy callout just eats all traffic from the targeted application, with one caveat. That caveat is that when I target firefox or chrome with the proxy callout and try to launch that app it fails to launch a UI and the partially started process cannot be killed from task manager.
I assumed that behavior may be the result of the sample failing to check FwpsQueryPacketInjectionState but modifying as best I can figure out that should be used does not seem to change the behavior.
So in short I am stuck and need direction please?
I started experimenting with the WFPSampler and also discovered that tracing didn't work. Oddly enough, there was a lot of additional code to make WPP tracing work on multiple OS's, but the sample doesn’t capture any trace events. So I debugged it and found the call to the nt!WmiTraceMessage always passed 2 as the TRACE_HANDLE. This seemed bad. Safe it to say, this wasn't exactly straight forward to unscramble WPP macros and then finally find the origin in the .vcxprog file. The definition of WPP_COMPID_LEVEL_LOGGER(COMPID,LEVEL)=2 is incorrect. While I was there, I also converted the DbgPrintEx Levels to match Tace_Level by adding 2 so Error/Warning match the model.
Complete the following steps for SysLib/WFPSampler and Sys/WFPSamplerCalloutDriver
Open the Project
Right Click on WFPSamplerCalloutDriver
Unload Project
Right Cick on WFPSamplerCalloutDriver
Edit WFPSamplerCalloutDriver.vcxproj
Type: WppPreprpocessorDefinitions
Change this definition in both places in the file:
To:
<WppTraceFunction>DbgPrintEx(COMPID,LEVEL,MSG,...)</WppTraceFunction
<WppPreprocessorDefinitions>WPP_COMPID_LEVEL_LOGGER(COMPID,lvl)=(WPP_CONTROL(0).Logger),;WPP_COMPID_LEVEL_ENABLED(COMPID,lvl)=(WPP_CONTROL(0).Level >= lvl+2)</WppPreprocessorDefinitions>
Save the File
Right Cick on WFPSamplerCalloutDriver
Click Reload Project
Rebuild
I believe if you adopt this model of using DbgPrintEx as your trace function, you can switch to WPP without editing the entire project. However, I still think it's better to just convert in your program.
Cheers,
John
Not exactly an answer to this question, I never got a debugger working, but an explanation of why the wfpsampler sample didn't work for proxying by ALE layers. The end goal of this project.
In the Proxy callout there were these lines (i think before my refactor they were in the PerformProxySocketRedirection method):
if (ipProtocol == IPPROTO_TCP)
pBindRequest1->portReservationToken = (pRedirectData)->pProxyData->tcpPortReservationToken;
else if (ipProtocol == IPPROTO_UDP)
pBindRequest1->portReservationToken = (pRedirectData)->pProxyData->udpPortReservationToken;
udpPortReservationToken or tcpPortReservationToken should have been initialized by a call to CreatePersistentUdpPortReservation or CreatePersistentTcpPortReservation and this is handled in a helper function named HlprWinSockCreatePortReservation, but said helper function is never called, from anywhere in the entire solution. Those fields are never set, anywhere, ever.
Additionaly, that value only needed set if the local port was being changed, but that block of code executed regardless.
remove these lines, and so long as you don't change the local port, the ale redirect sample works as you would expect including changing the outgoing interface if you change the local IP. If you do need to change the local port, you will have to use HlprWinSockCreatePortReservation to initialize the appropriate port reservation token variable in the PROXY_DATA. This must be done in user mode, so you need to do it in the service when setting up the filter.
Disclaimer: I think that is the only important change, but if you are here for a solution to this problem know that while tracking this down without a working debugger i changed a ridiculously large amount of code so there may have been more to it I forgot over the course of the last few weeks. But I did go back and verify that that block was always called and those fields were never set in the original.
hi :
i was building kernel for my gentoo linux . when i start the kernel , i
got this message , and can't going on.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
non-volatile memory driver v1.3
i don't know how to solve this problem . and i need help . thanks .
Why don't you try to disable pci hotplug support in kernel (if I recall correctly is in main config menu / PCI support)? You probably don't need this.
I'm going to have to disagree with those voting to close, because I think there really is a question here, and the question is "How to debug this?"
I'm going to propose two approaches:
1) Studious approach: Learn about mechanisms intended for handling boot problems. See if you can increase the kernel debug message level. Disable un-needed drivers as Quizzo suggested.
2) Cowboy approach: grep the kernel sources for strings seen in the final messages, and start shotgunning all possibly relevant bits of code with your own "still alive at" printk messages. Once you know where it's hanging, figure out why and either remove that mechanism or fix it.
At an extreme there's also a tool for debugging the kernel - kgdb - which you could set up if you have a second machine available.
If you already have linux running on this box, see if there's a config.gz in /proc or in a boot folder which you can extract and compare to the configuration you are trying to compile. It might not be a bad idea to first recompile and test exactly the same version and configuration as you have running, and then make desired changes one by one.
Also you might see if there's odd hardware in your system you could temporarily remove. For example, an older PC I have has a bios that hangs during drive enumeration if I have a large USB external drive plugged in during boot.
i have solved the problem by enable all pci hotplug flag in kernel config file.
thinks all.
I've been searching around and can't find a solution for this. The official NVIDIA Tegra 2 Linux SDK (L4T) doesn't include both XRandR or the VideoMode X11 extension for querying available video modes. My next thought was to parse the log file for video modes. Of course most of the time it's at /var/log/Xorg.0.log but I'd rather not always make that assumption. The XF86misc extension provides a way to get the log path but that extension is also not installed by default.
So I'm wondering if anyone knows of any other way to figure out what video modes are available and also what the current video mode of the display is.
The core X protocol does not mention modes. You have to use extensions. There's nothing wrong with that, that's what extensions are for.
Also, remember that there's no guarantee that the machine you're displaying on is the same machine as you're running on, so parsing the X log file is destined to fail if your app ever runs across the network.