[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