mkinitrd on missing list?

[Gene Heskett]

On Friday 15 March 2013 09:42:59 Basil Chupin did opine:

> On 15/03/13 17:37, Gene Heskett wrote:
> > On Friday 15 March 2013 02:35:33 Tom H did opine:
> >> On Thu, Mar 14, 2013 at 6:51 PM, Gene Heskett <gheskett at wdtv.com> 
wrote:
> >>> Just tried to build a new kernel & found that mkinitrd is missing.
> >>> So what are we using now in 10.04-4 LTS?
> >> 
> >> It's been a while that the default is initramfs-tools with the
> >> "mkinitramfs" and "update-initramfs" (the latter is a wrapper for the
> >> former).
> >> 
> >> Since you're using 10.04 and if you insist on using "mkinitrd", you
> >> should be able to install yaird ("yet another initrd").
> > 
> > I found it had been renamed with a small syntax change, got it
> > working, but now it can't find my mouse or keyboard.  More putzing
> > around tomorrow I expect.
> 
> Gene, what's it like banging your head against a brick wall? :-)
> 
> BC

Not exactly a good experience Basil, however it was time I got my hand back 
in at building a recent kernel.  I have spent a good 10 years building and 
using Linus's latest starting at about -rc2 of each cycle, but had stopped 
because I wanted to have exactly the same install on this machine that 
actually runs my hardware in the shop.

I hadn't done kernel build since I had installed the same ubuntu LTS on 
this machine that manages to run my pair of cnc metal carving machines, 
which require a certain kernel patch kit called rtai in order to meet the 
timing requirements of telling a piece of machinery what to do every 25 
microseconds, based on a new calculation of what it is supposed to be doing 
every millisecond.  Capable of positioning the machine its running to sub-
micron accuracy while moving the cutting tool at speeds of 60 inches a 
minute for my toys, but can move the bigger stuff in terms of feet per 
second at similar accuracies for well tuned servo systems.

A normal linux install can't do that, by about 2 orders of magnitude, its 
geared to 'feel good' to the user, who in fairness to his perceptions of 
real time, actually has, even for the gamers, no clue what real time means 
for a machine that just tripped a limit switch 1/8 of an inch from crashing 
into a fixture and breaking a $400 tool or carving up a $4,000 fixture, and 
which has 10 milliseconds to decelerate and stop a moving table that might 
weigh 100,000 pounds in order to prevent that.  To put that in perspective, 
there is a Cincinnati Millicron milling machine about 50 years old over in 
Cinci at a machine shop, whose work table is 26 feet long and weighs about 
that much just for the table.  Now being run by linuxcnc at speeds the 
maker never dreamed of 50 years ago. They can see it running on the 
seismographic stuff at the university, 12 miles away.

The gent who wrote those patches is now working on making it work with the 
newer kernels, but at the moment we are stuck with a 2.6.32-122-rtai build, 
which while it works great /if/the hardware is suitable, and ATM that 
hardware is an intel atom powered economy board.  My quad core phenom, 
supposedly a faster machine, is actually about 3x slower due to the time it 
takes on this phenom to do a context switch.

So I figured if I can make a recent kernel run well here, then I might be 
able to apply the current patch, which is changing daily, and perhaps do 
some of the heavy lifting needed to bring linuxcnc forward about 3 years.  
It has made lots of progress in the last 3 years, but the kernel under it 
has not.  And we need to fix that.  The present kernel has warts of its own 
and isn't the ideal kernel for a smoothly running desktop.  First off, its 
a memory hog, rebooted several times yesterday, it is not into swap ATM, 
but will be as much as 700 megs into swap in 2 weeks uptime.  That leads to 
very sucky desktop performance as you can imagine.

Right now, we need a newer kernel to be designated as a long term kernel, 
and that one would be the next patch target for us.  Something newer than 
the now year+ old 3.x which is still getting backports.

The most damaging item in terms of destroying even that patches ability to 
do this is, not surprisingly, the proprietary video driver from NVidia.  
One of the things that makes it look blindingly fast is its IRQ lockouts, 
for as long as 200 milliseconds according to our latency testing.  Not at 
all good when a stepper motor driven machine needs a heartbeat steady 
within 3 to 5 microseconds for decent performance.

Equally amazing is the onboard video on the atom boards is totally not a 
detectable problem. Onboard video is usually the deal breaker.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views 
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
Preserve the old, but know the new.
I was taught to respect my elders, but its getting 
harder and harder to find any...