[odc] Daily src changes for 2002-10-14
ODC
auto at squish.net
Tue Oct 15 08:00:21 BST 2002
OpenBSD src changes summary for 2002-10-14
==========================================
distrib/notes etc/rc
regress/sbin sbin/pfctl
share/man sys/arch/i386/i386
sys/arch/sparc/sparc sys/kern
sys/net sys/sys
usr.sbin/memconfig
== distrib =========================================================== 01/07 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/distrib
notes
~ i386/hardware
> Syncronize list of supported devices with pciide(4).
> pointed by miod@ (gluk@)
== etc =============================================================== 02/07 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/etc
rc
~ rc
> use stripcom(), not awk. Spotted by form at . > millert@ ok (mpech@)
== regress =========================================================== 03/07 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/regress
sbin
~ pfctl/pf17.ok ~ pfctl/pf17.in
> test binat netblocks
> from ryan (henning@)
== sbin ============================================================== 04/07 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin
pfctl
~ pfctl_parser.c ~ parse.y
> Allow one to specify a netblock in a binat rule:
> binat on fxp0 from 192.168.0.32/27 to any -> 10.0.7.128/27
> Both the network mask on the source and redirect addresses MUST be the
> same, and it works by essentially combining the network section of the
> redirect address with the host section of the source address.
> from ryan
> ok dhartmei@ (henning@)
== share ============================================================= 05/07 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/share
man
~ man5/pf.conf.5
> your -> one's
> From: Gregory Steuck <greg at nest.cx > Thanks! (henning@)
~ man5/bsd.port.mk.5
> document USE_X11; from aleksander.piotrowski at piestrak.waw.plvalchev@)
~ man5/pf.conf.5
> document binat netblocks
> from ryan (henning@)
~ man5/pf.conf.5
> grammar & formatting
> From: Jolan Luff <jolan at cryptonomicon.orgwho is no i386 wheenie ;-)
> Thanks! (henning@)
~ man8/starttls.8
> No need to modify submit.mc when enabling TLS. Noted by Marc Matteo
> (millert@)
~ man4/wi.4tbl
> Mention Prism3 and HostAP bugs in 1.4.0-1.4.2 firmware. (millert@)
~ man5/pf.conf.5
> .Cm inside .Bd -literal screws up (deraadt@)
~ man4/pciide.4
> Remove OPTi 82c621 from list of supported devices.
> It disabled in pciide.c
> deraadt@ ok. (gluk@)
+ man5/elf.5 ~ man5/Makefile
> New manpage elf(5), from FreeBSD, with minor changes due to differences
> between OpenBSD and FreeBSD ELF support.
> Initially written by asmodai at freebsd.org.iod@)
== sys =============================================================== 06/07 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/sys
arch/i386/i386
~ i686_mem.c
> Fix from FreeBSD for atlhon problems with mtrr and XFree86. Ok deraadt@
> FreeBSD commit messages say:
> Some BIOSs are using MTRR values that are only documented under NDA
> to control the mapping of things like the ACPI and APM into memory.
> The problem is that starting X changes these values, so if something
> was using the bits of BIOS mapped into memory (say ACPI or APM),
> then next time they access this memory the machine would hang.
> This patch refuse to change MTRR values it doesn't understand,
> unless a new "force" option is given. This means X doesn't change
> them by accident but someone can override that if they really want
> to.
> PR: 28418
> Tested by: Christopher Masto <chris at netmonger dot net>,
> David Bushong <david at bushong dot net>,
> Santos <casd at myrealbox dot com>
> Make the MTRR code a bit more defensive - this should help people
> trying to run X on some Athlon systems where the BIOS does odd things
> (mines an ASUS A7A266, but it seems to also help on other systems).
> Here's a description of the problem and my fix:
> The problem with the old MTRR code is that it only expects
> to find documented values in the bytes of MTRR registers.
> To convert the MTRR byte into a FreeBSD "Memory Range Type"
> (mrt) it uses the byte value and looks it up in an array.
> If the value is not in range then the mrt value ends up
> containing random junk.
> This isn't an immediate problem. The mrt value is only used
> later when rewriting the MTRR registers. When we finally
> go to write a value back again, the function i686_mtrrtype()
> searches for the junk value and returns -1 when it fails
> to find it. This is converted to a byte (0xff) and written
> back to the register, causing a GPF as 0xff is an illegal
> value for a MTRR byte.
> To work around this problem I've added a new mrt flag
> MDF_UNKNOWN. We set this when we read a MTRR byte which
> we do not understand. If we try to convert a MDF_UNKNOWN
> back into a MTRR value, then the new function, i686_mrt2mtrr,
> just returns the old value of the MTRR byte. This leaves
> the memory range type unchanged.
> I have seen one side effect of the fix, which is that ACPI calls
> after X has been run seem to hang my machine. As running X would
> previously panic the machine, this is still an improvement ;-)
> PR: 28418, 25958
> Tested by: jkh, Christopher Masto <chris at netmonger dot net>
> (matthieu@)
arch/sparc/sparc
~ vm_machdep.c
> Use uvm_km_valloc_prefer_wait instead of doing the same thing manually.
> <miod> well, my comments are "looks sane, works for me, ok to commit"
> (art@)
kern
~ subr_pool.c
> - Do not try to drain other pools if PR_NOWAIT and the allocator can't
> give us pages. PR_NOWAIT most likely means "hey, we're coming from an
> interrupt, don't mess with stuff that doesn't have proper protection".
> - pool_allocator_free is called in too many places so I don't feel
> comfortable without that added protection from splvm (and besides,
> pool_allocator_free is rarely called anyway, so the extra spl will be
> unnoticeable). It shouldn't matter when fiddling with those flags, but
> you never know.
> - Remove a wakeup without a matching tsleep. It's a left-over from
> some other code path that I've been investigating when reworking the
> pool a while ago and it should have been removed before that commit.
> deraadt@ ok (art@)
~ subr_prf.c
> Stuff needed for gcc 3.X.
> gcc has the nice feature of optimizing various common constructs into
> more optimal ones, inlining various calls, etc. The problem with that
> is that it assumes that we have a proper libc backing us. We really
> don't want to loose all those features by defining -ffreestanding and
> right now there is no way to just disable some of them, so we have to
> make the kernel more libc-like in some aspects to make it work with
> newer gcc.
> rename putchar to kputchar because it was nothing like libc putchar (and
> only internal to this function). Implement dummy putchar and puts (not
> prototyped outside this file). (art@)
net
~ pf.c ~ pfvar.h
> Allow one to specify a netblock in a binat rule:
> binat on fxp0 from 192.168.0.32/27 to any -> 10.0.7.128/27
> Both the network mask on the source and redirect addresses MUST be the
> same, and it works by essentially combining the network section of the
> redirect address with the host section of the source address.
> from ryan
> ok dhartmei@ (henning@)
sys
~ memrange.h
> Fix from FreeBSD for atlhon problems with mtrr and XFree86. Ok deraadt@
> FreeBSD commit messages say:
> Some BIOSs are using MTRR values that are only documented under NDA
> to control the mapping of things like the ACPI and APM into memory.
> The problem is that starting X changes these values, so if something
> was using the bits of BIOS mapped into memory (say ACPI or APM),
> then next time they access this memory the machine would hang.
> This patch refuse to change MTRR values it doesn't understand,
> unless a new "force" option is given. This means X doesn't change
> them by accident but someone can override that if they really want
> to.
> PR: 28418
> Tested by: Christopher Masto <chris at netmonger dot net>,
> David Bushong <david at bushong dot net>,
> Santos <casd at myrealbox dot com>
> Make the MTRR code a bit more defensive - this should help people
> trying to run X on some Athlon systems where the BIOS does odd things
> (mines an ASUS A7A266, but it seems to also help on other systems).
> Here's a description of the problem and my fix:
> The problem with the old MTRR code is that it only expects
> to find documented values in the bytes of MTRR registers.
> To convert the MTRR byte into a FreeBSD "Memory Range Type"
> (mrt) it uses the byte value and looks it up in an array.
> If the value is not in range then the mrt value ends up
> containing random junk.
> This isn't an immediate problem. The mrt value is only used
> later when rewriting the MTRR registers. When we finally
> go to write a value back again, the function i686_mtrrtype()
> searches for the junk value and returns -1 when it fails
> to find it. This is converted to a byte (0xff) and written
> back to the register, causing a GPF as 0xff is an illegal
> value for a MTRR byte.
> To work around this problem I've added a new mrt flag
> MDF_UNKNOWN. We set this when we read a MTRR byte which
> we do not understand. If we try to convert a MDF_UNKNOWN
> back into a MTRR value, then the new function, i686_mrt2mtrr,
> just returns the old value of the MTRR byte. This leaves
> the memory range type unchanged.
> I have seen one side effect of the fix, which is that ACPI calls
> after X has been run seem to hang my machine. As running X would
> previously panic the machine, this is still an improvement ;-)
> PR: 28418, 25958
> Tested by: jkh, Christopher Masto <chris at netmonger dot net>
> (matthieu@)
== usr.sbin ========================================================== 07/07 ==
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin
memconfig
~ memconfig.8 ~ memconfig.c
> Fix from FreeBSD for atlhon problems with mtrr and XFree86. Ok deraadt@
> FreeBSD commit messages say:
> Some BIOSs are using MTRR values that are only documented under NDA
> to control the mapping of things like the ACPI and APM into memory.
> The problem is that starting X changes these values, so if something
> was using the bits of BIOS mapped into memory (say ACPI or APM),
> then next time they access this memory the machine would hang.
> This patch refuse to change MTRR values it doesn't understand,
> unless a new "force" option is given. This means X doesn't change
> them by accident but someone can override that if they really want
> to.
> PR: 28418
> Tested by: Christopher Masto <chris at netmonger dot net>,
> David Bushong <david at bushong dot net>,
> Santos <casd at myrealbox dot com>
> Make the MTRR code a bit more defensive - this should help people
> trying to run X on some Athlon systems where the BIOS does odd things
> (mines an ASUS A7A266, but it seems to also help on other systems).
> Here's a description of the problem and my fix:
> The problem with the old MTRR code is that it only expects
> to find documented values in the bytes of MTRR registers.
> To convert the MTRR byte into a FreeBSD "Memory Range Type"
> (mrt) it uses the byte value and looks it up in an array.
> If the value is not in range then the mrt value ends up
> containing random junk.
> This isn't an immediate problem. The mrt value is only used
> later when rewriting the MTRR registers. When we finally
> go to write a value back again, the function i686_mtrrtype()
> searches for the junk value and returns -1 when it fails
> to find it. This is converted to a byte (0xff) and written
> back to the register, causing a GPF as 0xff is an illegal
> value for a MTRR byte.
> To work around this problem I've added a new mrt flag
> MDF_UNKNOWN. We set this when we read a MTRR byte which
> we do not understand. If we try to convert a MDF_UNKNOWN
> back into a MTRR value, then the new function, i686_mrt2mtrr,
> just returns the old value of the MTRR byte. This leaves
> the memory range type unchanged.
> I have seen one side effect of the fix, which is that ACPI calls
> after X has been run seem to hang my machine. As running X would
> previously panic the machine, this is still an improvement ;-)
> PR: 28418, 25958
> Tested by: jkh, Christopher Masto <chris at netmonger dot net>
> (matthieu@)
===============================================================================
More information about the odc
mailing list