I'm trying to debug a USB problem in an Android application which uses libusb. I'm not sure whether the problem is caused by user code or kernel code. I figured, either way, adding some printk statements to trace the execution path in the relevant portions of the kernel code (XHCI driver) would be helpful.
However, when I boot the newly compiled kernel with the printk statements and insert an OTG cable, the kernel panics because of a NULL pointer dereference which appears to be caused by an ENOMEM error in the XHCI code. If I comment out some of the printks, the kernel no longer panics on OTG cable insertion, but it fails to enumerate connected USB devices, again due to an ENOMEM error.
How can it be that simply adding a few printk statements with string literals (which don't occupy stack memory, right?) could cause ENOMEM errors? Is it possible the XHCI code was already dangerously close to filling the 8k stack, and adding the printk calls was just the final straw that broke the camel's back? Or is there a simpler explanation?
Example of the type of printk lines I added:
printk("BUGHUNT: xhci-mem.c: xhci_urb_enqueue(): ENTER\n");