[lkml]   [2002]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectAPM broken on 2.4.18 with IBM Thinkpad X21

[Please be gentle, this is my first post to lkml].

I have an IBM Thinkpad X21, which worked fine with APM on Redhat 7.1
(2.4.2-2 with a whole bunch of Redhat patches). Now that I have upgraded
to 2.4.18, APM no longer works.

The debugging process I have been through is something like the following:

I think my initial problem was some undefined symbols. I am not sure why
these weren't defined, I should try to find out why sometime...

[root@localhost kernel]# insmod apm
Using /lib/modules/2.4.18/kernel/arch/i386/kernel/apm.o
/lib/modules/2.4.18/kernel/arch/i386/kernel/apm.o: unresolved symbol
/lib/modules/2.4.18/kernel/arch/i386/kernel/apm.o: unresolved symbol

After commenting these function calls out, recompiling the module and
rebooting with an apm=debug, I get:

apm: BIOS version 152.172 Flags 0xd231 (Driver version 1.16)
apm: no 32 bit BIOS support

...And then an ENODEV is returned...

Which is interesting, partially because this looks like random junk, and
partically because because the 2.4.2 kernel says the following (with

apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
apm: entry f000:3f7f cseg16 f000 dseg 40 cseg len ffff, dseg len ffff
cseg16 len ffff
Starting kswapd v1.8
apm: Connection version 1.2
apm: AC off line, battery status high, battery life 76%
apm: battery flag 0x01, battery life 81 minutes

The APM_BIOS_INFO #define in setup.c has not changed between the versions,
and seems to be copied straight to apm_info.bios.

I then printed out the value of the pointer to the apm_info.bios structure
for 2.4.18, and 2.4.2 (on the assumption that this is just a pointer to
some magic config information in RAM) and got:

Mikal: apm.bios points to 0xc3a398ac <---- 2.4.18
Mikal: apm_info.bios points to 0xf0000102 <---- 2.4.2-2 (redhat)

These values don't change across multiple insmods, but this isn't

Anyway, I'm in over my head, and was wondering if anyone has had success
with APM on these machines, and if not, what a reasonable next step in
debugging land might be.



Michael Still ( UMT+10hrs

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:26    [W:0.023 / U:2.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site