I am trying to test a particular driver.
Would like to simulate KZALLOC() to fail and verify my driver is working fine.
Can anyone recommend a suitable Kernel Configraiton that helps me with this?
I am using 3.10 as well as 3.4 Linux Kernels please/
Related
I'm new to device drivers in Linux. And my first day task is to debug driver using GDB in Linux.
I need to debug some XYZ (PCIe device driver supports ethernet) device driver to know about the flow and what is going on device's registers and all.
I have installed the driver with patch file and insmod command.
The device is working properly. But am not getting any solution to debug the device driver.
All I know is that how to debug C program using GDB in Linux(fedora20). I got one link similar to my Problem but from that also I have not got any knowledge.
Can anybody please share your thoughts that how can I start from scratch.
I am very specific to learn about Debugging device drivers in Linux. Especially that init or probe function inside my driver I need to know the flow.
The gdb debugger is useful to debug user-space application level programs (since it uses ptrace(2)).
For kernel code, things are different. Consider using kgdb (I don't know the details). You might also add debug prints ....
I recommend at least reading more about operating systems, e.g. Operating Systems: Three Easy Pieces (freely downloadable), and reading something about Linux programming (perhaps the old ALP, and also intro(2), syscalls(2) and related stuff). Don't dare coding Linux loadable kernel modules without good familiarity with Linux programming (in user-land). See also kernelnewbies.
BTW, you should prefer writing user-land code than kernel modules. A very simple rule of thumb is to avoid writing kernel code when possible.
To begin with, you may need to understand basics of device driver and kernel in linux. Subsequently focus as per the type of driver in-hand. You also need to understand the functionality (specification / manual / datasheet) of the device you are working on.
The very basic approach for debugging can be using printk. Normally there will be debug logs that can be enabled through compilation flags. If it is present, enable it so that it can give important pointers else you might need to add it on your own.
Start with verification of driver registration and verification of loading of your driver (static or loadable module as per your requirement). Check whether it is getting listed as part of sysfs or proc as applicable. Check whether probe is successful and subsequently the appropriate read/write/open/close/other calls as per your driver / device functionality.
The dmesg shall be very helpfull for viewing the kernel messages. There are also tools like kdb, LTT, strace that can be useful as per the scenario.
A friend of mine bought a laptop that unfortunately comes with an unsupported touchpad. The good news is that it comes with full documentation.
Is this documentation enough to make a driver with multi-touch support?
Is it advisable to base the driver from another (similar) touchpad driver as a starting point? If so, which one shall I use?
As far as I know, this controller is already supported by Linux. Just make sure your kernel version is recent enough to have the driver/input/mouse/byd.c source file, and that it is enabled by checking for the presence of the CONFIG_MOUSE_PS2_BYD token in your kernel configuration.
Since I'm new here i'll try to be as specific as possible,
I'm working on a project revolving around the ath10k wireless driver on ubuntu linux 12.04 64-bit where I have to profile the aforementioned driver.
I know that it is a kernel module so using gprof won't do any good. So my question is:
Is there any way to profile specific (if possible) functions in the wireless driver on ubuntu 12.04?
Should i do it by hand? (by adding extra code to keep track of the total time each function runs or something like that?)
thanks in advance!
I have a Linux network driver that was originally written for 2.4 kernel. It works perfect.
I want to port it to kernel 2.6.31 and then to ARM Linux with same kernel i.e. 2.6.31. I have actually done some minor changes to the driver so that it is able to compile under kernel 2.6.31 and it also loads and unloads without crashing. It also cross compiles for the ARM Linux. But I am unable to test it on ARM so far.
How do I check that the driver is fully compatible with the target kernel, and what considerations shall be made to make it compatible with ARM.
The driver is a virtual network device driver.
Thanks in advance.
Maybe you could use Qemu ( http://wiki.qemu.org/Main_Page) to emulate an ARM platform to be able to test your driver.
You cannot check the driver like that - you have to consider the API changes within 2.6.x series kernel. The changes are quite significant and the overall of the API's from the 2.4 series which is not currently in use.
I would suggest you to go here to the Amazon book store for this book in particular. The book is called 'Essential Linux Device Drivers', by Sreekrishnan Venkateswaran. A very well detailed explanation that will be your guidance in ensuring it works properly.
Since you mentioned the device driver is a network, presumably char device (You're not accessing it in blocks), well, the good news is that the 2.6.x series kernel APIs for the character devices are significantly easier and more centralized to focus on - in fact a lot of the framework is already in place in which the author of said book explains very clearly.
By the way, the book focusses on the latter 2.6.x series after 2.6.19, so this will help you clue in on what needs to be done to ensure your driver works.
You did not specify the ARM chipset you're targetting?
As for testing... well.. perhaps the best way to do this, this is dependant on how you answer the above question to you regarding ARM chipset - if its ARMv6, then perhaps, a cheap android handset that you can easily unlock and root, and pop the kernel in there and see what happens - sorry for sounding contrived but that's the best thing I can think of and that's what pops into my head, to enable you to test it out for ease of testing :)
PS: A lot of cheap ARMv6 handsets would have kernel 2.6.32 running Froyo if that's of any help!
I'm considering doing some Linux kernel and device driver development under a vmware VM for testing ( Ubuntu 9.04 as a guest under vmware server 2.0 ) while doing the compiles on the Ubuntu 8.04 host.
I don't want to take the performance hit of doing the compiles under the VM.
I know that the kernel obviously doesn't link to anything outside itself so there shouldn't be any problems in that regard, but
are there any special gotcha's I need to watch out for when doing this?
beyond still having a running computer when the kernel crashes are there any other benefits to this setup?
Are there any guides to using this kind of setup?
Edit
I've seen numerous references to remote debugging in VMware via Workstation 6.0 using GDB on the host. Does anyone know if this works with any of the free versions of VMWare such as Server 2.0.
I'm not sure about ubuntu thing. Given that you are not doing a real cross compilation (i.e. x86->arm), I would consider using make-kpkg package. This should produce an installable .deb
archive with kernel for your system. this would work for me on debian, it might for for you
on ubuntu.
more about make-kpkg:
http://www.debianhelp.co.uk/kernel2.6.htm
I'm not aware of any gotchas. But basically it depends what kind of kernel part you
are working with. The more special HW/driver you need, the more likely VM won't work for you.
probably faster boots and my favorite is the possibility to take screenshot (cut'n'paste) of panic message.
try to browse to vmware communities. this thread looks very promising, although it dicusses
topic for MacOS:
http://communities.vmware.com/thread/185781
Compiling, editing, compiling is quite quick anyway, you don't recompile you whole kernel each time you modify the driver.
Before crashing, you can have deadlock, bad usage of resource that leads to unremovable module, memory leak etc ... All kind of things that needs a reboot even if your machine did not crash, so yes, this can be a good idea.
The gotchas can come in the form of the install step and module dependency generation, since you don't want to install your driver in the host, but in the target machine.