Red Hat Bugzilla – Bug 4546
A fix for APM on Acer Extensa 501T and possibly others.
Last modified: 2013-09-02 01:52:21 EDT
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 apm_bios_info.offset=0x500000 (this is bad adress) working is apm_bios_info.cseg=0xfbbd and apm_bios_info.offset=0 --- 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 << 4)); - apm_bios_entry.offset = apm_bios_info.offset; + apm_bios_entry.offset = apm_bios_info.offset & 0xffff; apm_bios_entry.segment = APM_CS; set_base(gdt[APM_CS >> 3], __va((unsigned long)apm_bios_info.cseg << 4)); -- References: http://www.al.unipmn.it/~sitta/linux503.html http://www.al.unipmn.it/~sitta/linux/apm.html --michael
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