Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I am trying to get kernel 188.8.131.52 to run on a PC104 board. It's an Emcore i613, with a Celeron processor. Roughly 1 out of every 7 boots will hang when it tries to initialize the serial port. I've found that it hangs when it does the 20 millisecond msleep() call in the probe_irq_on() function in autoprobe.c.
Just not sure where to go from here. I've never been down into the guts of the kernel before.
I have tried this, and get the same results, on 3 different boards of the same model, so I do not believe it to be an intermittent board.
It does seem like some timing is just on the hairy edge however, as the hang is more likely to occur if the board has been powered down for a while. (cold). If I keep on trying I may get 25 -30 good boots and see no failure.
F.Y.I. This kernel runs fine on a newer, Geode based PC104 board that we currently use, but we must be able to support our existing products already out in the field.
Thanks for your quick response and also for moving my post to the more appropriate forum onebuck!
We have been running with a 2.6.11 kernel for about 5 years now, and (to my shame),only just found out that the kernel was the source of a long standing 'intermittent checksum error' that I had always blamed on the hardware we communicate with via RS232. The problem turned out to be that 'occasionally' it would take the kernel 10's of milliseconds to respond to an interrupt from the uarts and of course this would cause the uart to overrun. The uncaught loss of data propagated up to a 'checksum error' further up the chain.
When I tried a newer kernel, the random slow response to interrupts problem was gone. But as I tried to get the new kernel ready for deployment to our systems in the field I noticed this random boot problem on the older (i613) boards.