How to debug ARM Linux kernel (msleep ())?
I am primarily looking for tips for debugging. If someone can specify one line of code to change, or one bit of peripheral configuration to install a fix for the problem, that would be awesome. But that's not what I hope for; I am looking more for how should I debug it.
Googling "msleep hang linux kernel site: stackoverflow.com" gives 13 answers and none fit, so I think I'm safe.
I am rebuilding an ARM Linux kernel for a TI AM1808 ARM embedded processor (Sitara / DaVinci?). I can see that all boot log before login login: out of the serial port, but the login attempt doesn't get a response, doesn't even repeat what I typed.
After a lot of debugging, I came to the kernel and added the debug code between lines 828 and 830 (yes, the kernel version is 2.6.37). This is currently in kernel mode prior to calling 'sbin / init':
Right before line 830 I added a forver loop printk and I can see the results. I let it work for about a couple of hours and it totals about 2 million. Example line:
Thus, it delivered 60 million bytes without any problems.
However, if I add msleep (1000) in a loop, it only prints once, i.e. msleep () does not return.
More details: Adding a conditional printk on line 4073 in the scheduler, whose flag conditions, which are set at the start of the forever test loop described above, show that the schedule () is no longer called when it hangs:
The only options in .config / 'Device Drivers' are: Blocking devices I2C support SPI support
The kernel and its ramdisk are loaded using uboot / TFTP. I don't think he is trying to use Ethernet. Since all this happened before '/ sbin / init', very little needs to happen.
More details: I have a very similar board with the same processor. I can run the same uImage and the same ramdisk and it works fine. I can go in and do the usual things.
I checked the memory test (only 64MB, limited the core to 32M and tested the other 32M, this is one DDR2 chip) and found no problem. One board is using UART0 and the other UART2, but the boot log comes out of both, so there shouldn't be a problem.
Any advice on debugging is greatly appreciated. I don't have a corresponding JTAG, so I can't use it.
source to share
doesn't return or jump to
, then we can follow the call stack for debugging.
, which in the default case exits without calling the schedule if the timeout in the jiffies passed to it is <0, so that's one thing to check.
setup_timer_on_stack(&timer, process_timeout, (unsigned long)current);
__mod_timer(&timer, expire, false, TIMER_NOT_PINNED);
before the call
If we don't get to
, then something must be happening in
, either external, if
enabled, or call
init_timer_key(timer, name, key);
, which calls
, followed by
__init_timer(timer, name, key)
, then a whole series of other function calls.
I would suggest starting by putting a printk or two in
, perhaps either side of the call
or either side of the call
source to share
This issue has been resolved.
With the liberal use of prink, it was determined that sched () does indeed switch to another task - a simple task. In this case, being embedded Linux, the original codebase I copied from an installed idle task. This simple task seems inappropriate for my board and has blocked the processor and thus caused a crash. Commenting on an idle task call
works around the problem.
source to share