From: Zachary Amsden <zach@vmware.com>
To: Rohit Seth <rohit.seth@intel.com>
Cc: akpm@osdl.org, sfr@canb.auug.org.au, mm-commits@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
sfr@linuxcare.com.au, david@lechnyr.com, kontakt@hanno.de
Subject: Does anyone undefine APM_RELAX_SEGMENTS?
Date: Mon, 14 Nov 2005 20:04:23 -0800 [thread overview]
Message-ID: <43795E47.70507@vmware.com> (raw)
In-Reply-To: <1132024003.6760.16.camel@akash.sc.intel.com>
Rohit Seth wrote:
>On Thu, 2005-11-10 at 00:23 -0800, akpm@osdl.org wrote:
>
>
>>The patch titled
>>
>> x86: Always relax segments
>>
>>has been added to the -mm tree. Its filename is
>>
>> x86-always-relax-segments.patch
>>
>>
>>From: Zachary Amsden <zach@vmware.com>
>>
>>APM BIOSes have many bugs regarding proper representation of the appropriate
>>segment limits for calling the BIOS. By default, APM_RELAX_SEGMENTS is always
>>turned on to support running the APM BIOS on these buggy machines. Keeping
>>64k limits poses very little danger to the kernel, because the pages where the
>>APM BIOS is located will always be in low physical memory BIOS areas, which
>>should already be marked reserved, and only buggy BIOSes would possibly
>>overstep the segment bounds with writes to data anyway.
>>
>>Since forcing stricter limits breaks many machines and is not default
>>behavior, it seems reasonable to deprecate the older code which may cause APM
>>BIOS to fault.
>>
>>
>>
>
>But I presume it make some other machines to work?
>
>
It would make the APM thread panic on machines with broken APM BIOS -
which is not very useful except for proving a BIOS bug. But APM is
inherently safer than PnP, since there is no transfer segment which can
corrupt arbitrary kernel memory.
In the history of its introduction, I can not find a single distribution
or use which undefines this macro. If anyone knows otherwise, please
advise.
Zach
parent reply other threads:[~2005-11-15 4:04 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <1132024003.6760.16.camel@akash.sc.intel.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43795E47.70507@vmware.com \
--to=zach@vmware.com \
--cc=akpm@osdl.org \
--cc=david@lechnyr.com \
--cc=kontakt@hanno.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=rohit.seth@intel.com \
--cc=sfr@canb.auug.org.au \
--cc=sfr@linuxcare.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.