[ltp] Re: Applying undervolting patches

[Andrew Barr]

On Sun, 2006-08-20 at 07:49 -0400, David Abrahams wrote:
> How has it been proceeding, specifically?

I would say this: for me at least, it has been getting better with each
release, especially recently. Back in the days of the single-digit 2.6
releases things were a bit rough, but these days staying with the latest
stable 2.6 release hasn't been a problem for me.

Heck, I've been running 2.6.18-rc4 for a week now without issues.

> > Also, back porting kernels is kind of a project due to the
> > changes in the kernel build structure from release to
> > release.  Ive back ported kernels before, and I must say
> > that it is a pain.

I'm confused as to what you mean by "backporting".

If you mean drivers and patches, the real solution to that is to find a
way to minimize the number of extra drivers and patches that you need so
that you aren't backporting out-of-tree stuff (e.g. use uswusp instead
of suspend2)

Otherwise, any modern distribution like Ubuntu Dapper should be able to
run any available 2.6 kernel. The userspace changes required of
distributions largely happened over the 2.4->2.6 transition.

> From what I've read, it can be substantial.

It can be, depending on how low you can go with your undervolting. In my
case, at 600 MHz (lowest frequency) I was able to go all the way down to
700 mV, which is the lowest you can go.

The machine also runs cooler too as I mentioned previously.

> Anyway, I still have the edgy kernel sources, so I should be able to
> do that build here and apply the undervolting patches to that.

Maybe, maybe not. Like I said, due to the way Ubuntu packages their
kernel sources, it is not simple to tell what they are actually
changing. So you just have to try and see if it works.

You might have better luck too using Debian linux-image and linux-source
packages, even on Ubuntu, as they are very close to upstream.

> I believe the HOWTOs I've found are all using it.

In my opinion there is no reason to use kernel-package unless you wish
to share the same kernel image amongst multiple machines, or otherwise
wish to distribute the image. Installing from a vanilla source tree is
simple:

make [oldconfig|xconfig|gconfig]
make
make install
make modules_install
update-initramfs -t -u -k [kernelversion]
(Be sure you don't have any symlinks to the new kernel files in /boot,
otherwise you will get duplicate GRUB menu entries)
update-grub
(reboot)

Best yet, it's quicker (it does not package documentation and source
code) and the intermediate object files are preserved so that if you
make any changes (configuration, patching) the build will only have to
rebuild affected files.

> > I haven't used it since my old
> > days in Debian and initial forays into Ubuntu, but I would
> > expect it to work still.  I used to follow the bleeding edge
> > on kernels to get the latest and greatest, but Ive grown
> > mundane in my old age and count stability and not having to
> > waste time building kernels over any perceived gain on the
> > bleeding edge.

Bleeding edge is -rcX releases or git snapshots (of which the current
version is working fine for me). The 2.6.xx[.y] releases are called
"stable" for a reason.

I have a 2.6.17 image from Debian official on my boot menu should I
start having problems.

> Ahem.  When you reach true old age, like me, you may find yourself
> getting fussy about how hot your laptop gets, how quietly it can run,
> etc.  I bought this machine because there were too many annoying
> things about a MacBook pro.  I need to make it work better than one of
> those or it will all be for naught.  So even if I don't end up using
> the new kernel much, it's important for me to know now how well it
> *can* work.

You will find that the possibilities with your machine in Linux only get
better with time. Two or three years ago I was fussing with all kinds of
ACPI bugs and misfeatures (some of which were due to a cruddy Dell BIOS)
but those days are long over. Linux has come a long way and isn't
slowing down.

-- 
Andrew Barr | http://www.oakcourt.dyndns.org/~andrew/

All parts should go together without forcing. You must remember that
the parts you are reassembling were disassembled by you. Therefore, if
you can't get them together again, there must be a reason. By all
means, do not use a hammer.
  -- IBM maintenance manual (1925)