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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I am trying to get kernel 18.104.22.168 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.