This ended up comming in over a support ticket. The
informations eems to be quite valid. Submitted as a bug in
case it's any use to others...
Bios of "ACER EXTENSA 501T"
return apm_bios_info.cseg=0xfbbd and
(this is bad adress)
working is apm_bios_info.cseg=0xfbbd and
--- apm.c.orig Fri Jan 15 07:57:25 1999
+++ apm.c Mon Jun 28 14:36:29 1999
@@ -1349,7 +1349,7 @@
__va((unsigned long)0x40 << 4));
_set_limit((char *)&gdt[APM_40 >> 3], 4095 - (0x40
- apm_bios_entry.offset = apm_bios_info.offset;
+ apm_bios_entry.offset = apm_bios_info.offset &
apm_bios_entry.segment = APM_CS;
set_base(gdt[APM_CS >> 3],
__va((unsigned long)apm_bios_info.cseg <<
Doug, could you please evaluate this?
Kernel problem, not apmd.
Doesn't apply to current kernel - guess we can close this?
This is a kernel problem - it's fixed in 2.3.x (CONFIG_APM_BAD_ENTRY_OFFSET),
but it's still present in kernel 2.2.14.
The patch mentioned above doesn't apply to current 2.2 kernels;
the line in question is line 1353 in arch/i386/kernel/apm.c 2.2.14-1.2.0.
I don't see a problem with this patch - IMO it can get in.
Its already handled differently in current 2.2