WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: apm support in the kernel?  (Read 2486 times)

Offline mcewanw

  • Jr. Member
  • **
  • Posts: 92
apm support in the kernel?
« on: May 12, 2009, 04:12:00 AM »
I don't know much about this apm or the acpi power management topic. However, my old Dell Latitude CPx has suddenly starting crashing (running TC 2.0rc1) now and then, and I suspect it is over-heating. I'm not sure about this, but it doesn't seem to crash with Puppy Linux and I notice that apm is running with that OS. Could that be keeping it cool (idle CPU effects managed by apm?). I've tried loading acpi module stuff as I've seen people discussing on another thread - hwmon... cpureq... acpid and so on - but most of that stuff doesn't seem to modprobe or run or have any effect: I doubt this machine supports acpi at all therefore.

Is it possible then that apm support would help me, and is it available with the tiny core kernel.

I'll have to try Puppy again for a bit longer to double check it runs stable when the log fire in the room is burning at full blast!

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 7818
Re: apm support in the kernel?
« Reply #1 on: May 12, 2009, 04:18:49 AM »
There's no APM support either in tc 1.x or 2.x, because almost anything made after 1996 supports ACPI. (Plus APM can often conflict with ACPI on systems where both are available).

Fan control on temperature is BIOS-controlled, so no extensions needed there (unless one wishes to control it further, with lmsensors). To monitor temperatures the kernel support is in hwmon-cpufreq, userspace in lmsensors. Seems there's no lmsensors extension yet, I might make one soon.

Take a look at your kernel messages (dmesg in console, or a tab in System Stats) for any messages that might give a clue.
The only barriers that can stop you are the ones you create yourself.

Offline mcewanw

  • Jr. Member
  • **
  • Posts: 92
Re: apm support in the kernel?
« Reply #2 on: May 12, 2009, 04:35:46 AM »
Well, I think the Dell Latitude is from around 1999 or 2000 or so.

As far as I've read the kernel used in Puppy supports both apm and acpi, but automatically uses acpi if it finds the BIOS supports it. I guess my BIOS doesn't support acpi because in Puppy running dmesg and later lsmod reveals the following:

With Puppy Linux, dmesg contains this report line:
...
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
...

And when using Puppy Linux, lsmod includes this line in its report:
...
apm                    21372  0
...

Is that why my machine doesn't overheat when running Puppy? That would be bad news if I couldn't do anything about it in TC.

I've tried all the acpi related stuff from this thread: http://forum.tinycorelinux.net/index.php?topic=465.msg4113#msg4113

but with no effect at all.

For example:

After installing the suggested extensions hwmon-cpufreq and  cpufreq.tcel

the command:

sudo modprobe acpi-cpufreq

simply complained that there was no such module (though I checked and it was actually present in the relevant /lib/modules directory).

In TC dmesg didn't mention apm at all, and I didn't see anything relevant related to acpi CPU control (but what to look for?)

Maybe I'll need to learn how to recompile the kernel to add apm support, but I'd rather not face that...

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 6347
Re: apm support in the kernel?
« Reply #3 on: May 12, 2009, 04:59:22 AM »
Seems there's no lmsensors extension yet...
No, but there's an lm-sensors extension  ;)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 7818
Re: apm support in the kernel?
« Reply #4 on: May 12, 2009, 05:11:17 AM »
No, but there's an lm-sensors extension  ;)
Heh, that's right. I only live in TC 2.x now, it didn't cross my mind to check the 1.x repo. Would it need a recompile for tc2?
The only barriers that can stop you are the ones you create yourself.

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 6347
Re: apm support in the kernel?
« Reply #5 on: May 12, 2009, 05:34:50 AM »
My feeling is that, if the names of the kernel modules didn't change, lm-sensors will probably work in tc_2.x

My problem is that I have my laptop running 2.x and it does not have anything that lm-sensors can detect. My old desktop running 1.x has plenty of things for lm-sensors to find, but I'm not ready to upgrade to 2.x yet...

Offline hpstr

  • Newbie
  • *
  • Posts: 19
Re: apm support in the kernel?
« Reply #6 on: December 30, 2010, 03:08:21 PM »
Having several older laptops, I must disagree with the statement that all hardware after 1996 supports ACPI.

At least laptop computers, even of the Intel Pentium III era (1999-2002?), often have problems with ACPI but mostly work fine with apm, like the HP Omnibook 900B or the Panasonic Toughbook CF-71.

As one possible target for TinyCore are older computers, an apm module might be a good candidate to add to the package repository.

Hans
Computers help us solving problems which wouldn`t exist without computers.

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3836
Re: apm support in the kernel?
« Reply #7 on: December 30, 2010, 07:55:30 PM »
Here Thinkpad A20m - manufactury date 06/2000, Mobile P III Coppermine - would not boot TC at all without the 'acpi=off' boot param.

Unfortunately it is not as simple as just compiling an apm module, as a look at the kernel config would show:
# CONFIG_APM is not set
meaning the kernel would have to be recompiled.

I would fully agree that TC even if not specifically targeted at older PCs, nevertheless due to its low requirements and its structure of ultimate flexibility is de facto an optimal candidate to be used as OS on older hardware, therefore I find the lack of APM rather regretful.

It is often stressed that TC is about choice - and it is overall, as hardly any other OS I have seen; but I have to admit that when I was at the point of considering to switch to TC as my primary OS - weighing pros and cons, the lack of choice of APM was one of the biggest cons.

Older laptops have very frequently issues about wearing out batteries, and there is simply no way to get any battery status, if ACPI is not an option and APM is left out.

Having read a lot about Linux power management and playing around with it with older laptops, I have never heard about any conflicts about both power management subsystems being configured into the same kernel - and most stock kernels I have used since ACPI started to become mainstream featured both.
From kernel docs: "If a working ACPI implementation is found, the ACPI driver will override and disable APM, otherwise the APM driver will be used."
Also there is the config option CONFIG_ACPI_BLACKLIST_YEAR=
Common occurence is that if a blacklist year is set, it is usually 2001.

When I would boot the same OS by default with a box from 2000 APM would be enabled, resp. ACPI
with a box from 2002 (I never happened to lay hand at a box from 2001, so I wouldn't know exactly what would happen in a borderline case).
However, all these are simply defaults, which could most easily be overriden by boot params, e.g. acpi=force, acpi=off apm=on etc.
Therefore, having both pm subsystems configured in same kernel provides a matter of choice, which when not explicitely stated by user is handled by default criterias of one subsystem overriding the other.
A look at /var/log/messages would show that an exclusive choice in favour of one pm subsystem while disabling the other one occurs most early in boot sequence. There is no way to reactivate
the disabled pm subsystem before a reboot occurs and therefore I would rather exclude any possibility of a conflict.

As a 64bit stock kernel has been introduced as a choice addressed at high-end PC's, why not in the same spirit of choice introducing a stock kernel with APM enabled addressed at low-end PCs, when TC as already mentioned has a lot of pros for latter?
Also think about that exactly the same hardware which would run better with APM is very often also not the one most suitable to set up a compile environment, to install the kernel sources and to compile the kernel.

Perhaps an approach could be that a user contributed (if any user would be ready to) kernel based on existing kernel config but with APM enabled could get accepted to be hosted in repo, so the devs which already have to handle many other priorities would not be much burdened with an additional task?

Personally I would favour a kernel including both ACPI and APM - e.g. in the case of netboot where a not uncommon scenario may be that the server would preferably run ACPI, but older clients APM, or in case of having a nomadic OS on some removable storage - but even if ACPI resp. APM would remain exclusive to two different kernels, who would complain about some 2MB of storage usage more, when TC overall in comparison to other Linux systems is an ultimate space saver?
« Last Edit: December 30, 2010, 08:13:48 PM by tinypoodle »
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 7818
Re: apm support in the kernel?
« Reply #8 on: December 31, 2010, 01:49:39 AM »
Yay, essays ;)

OK, will consider adding APM to the default for the next build. In the meanwhile, it can be built as a module, so an acpi=off boot (or a machine completely lacking acpi) can do with an user-supplied apm extension.


I feel though that this move serves a very niche segment; those with 486-586 laptops that still have batteries that last more than 10 minutes. Of course there are some oddball P2 and P3 lappies too, to quote Linus on the bios writers the "crack-addled monkeys" don't always get ACPI right.

ACPI-less [45]86 desktops are AT ones, so they would get no benefit. ATX desktops tended to come with ACPI.
The only barriers that can stop you are the ones you create yourself.

Offline hpstr

  • Newbie
  • *
  • Posts: 19
Re: apm support in the kernel?
« Reply #9 on: December 31, 2010, 02:38:09 AM »
OK, will consider adding APM to the default for the next build. In the meanwhile, it can be built as a module, so an acpi=off boot (or a machine completely lacking acpi) can do with an user-supplied apm extension.
That is what I did try tonight, with the the intention to pack the module as an extension, as I would like to leave the default kernel itself as is.

I got the patched source and compiled it on another machine, using the default Tinycore config file but with modular apm.
The resulting apm.ko refuses to load (unknown symbol or unknown parameter) with the standard kernel on the target. I have yet to try to shorter.sh the entire compiled kernel and copy it to the target machine for a second try, and to investigate for eventual dependencies.

Quote
I feel though that this move serves a very niche segment; those with 486-586 laptops that still have batteries that last more than 10 minutes. Of course there are some oddball P2 and P3 lappies too,
As I am using laptops even for desktop work, I had many models in the last years, and used (and still ocasionally use) PI, PII and PIII machines as secondary ones.
I remember none of my PII and PIII laptops to work 100% right with ACPI... and all were premium brands.

Quote
to quote Linus on the bios writers the "crack-addled monkeys" don't always get ACPI right.
;D

Quote
ACPI-less [45]86 desktops are AT ones, so they would get no benefit. ATX desktops tended to come with ACPI.
I have not much experience with desktops, but I regularly used to compile kernels until about 2000 for server use, thus with a reduced feature set. I remember older ATX (PI/PII?) boards for secondary machines like DNS, mail servers, backup rigs ecc. Even with these we had problems with ACPI; but as they were machines running usually 24h/365d, IIRC the only issue was the poweroff function.
Computers help us solving problems which wouldn`t exist without computers.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 7818
Re: apm support in the kernel?
« Reply #10 on: December 31, 2010, 03:17:26 AM »
Ah, that is correct afterall; it can be a module, but not after-the-fact like this. So no, it seems it can't be added to the current TC 3.x kernel.

If you use sorter.sh (/do an incompatible build), you'll also need to replace the modules in the base (and use the extensions it produces instead of those in the repo).
« Last Edit: December 31, 2010, 03:19:07 AM by curaga »
The only barriers that can stop you are the ones you create yourself.

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3836
Re: apm support in the kernel?
« Reply #11 on: December 31, 2010, 08:38:44 AM »
CONFIG_APM  tristate

That's what I had meant to imply allover my essay...
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 7818
Re: apm support in the kernel?
« Reply #12 on: December 31, 2010, 10:17:55 AM »
CONFIG_APM  tristate

That's not what I meant, that just means both module and compiled-in are possible choices for that. It's other code that is compiled in depending on that choice, similarly to the eee pc modules in the 3.0 alpha cycle.
That can't be seen from the config files unfortunately, which is my excuse for believing it's ok as a later-built module some posts up.

Quote
That's what I had meant to imply allover my essay...

No offense meant. Happy new year!
« Last Edit: December 31, 2010, 10:20:23 AM by curaga »
The only barriers that can stop you are the ones you create yourself.

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3836
Re: apm support in the kernel?
« Reply #13 on: December 31, 2010, 08:22:03 PM »
Yeah, I guess the best impression could only been achieved by looking at options and submenus with menuconfig.

No offense taken. Likewise!
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline hpstr

  • Newbie
  • *
  • Posts: 19
Re: apm support in the kernel?
« Reply #14 on: January 02, 2011, 04:40:20 PM »
Ah, that is correct afterall; it can be a module, but not after-the-fact like this. So no, it seems it can't be added to the current TC 3.x kernel.

If you use sorter.sh (/do an incompatible build), you'll also need to replace the modules in the base (and use the extensions it produces instead of those in the repo).

apm, even compiled as a module from the same source, seems to have interesting dependencies in the rest of the kernel, and the kernel docs are not that much helpful, at least for me.

It indeed gets somewhat complicated. After quite some fiddling  I have decided to wait  :-[

Happy new year,

Hans
Computers help us solving problems which wouldn`t exist without computers.