OpenBSD Journal

OpenBSD turns 4.2-beta

Contributed by merdely on from the its-like-a-half-birthday dept.

Norbert Copones writes:

This news may be late...
OpenBSD turns 4.2-beta:

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt at cvs openbsd org	2007/07/25 14:07:28

Modified files:
	etc/root       : root.mail 
	share/mk       : sys.mk 
	share/tmac/mdoc: doc-common 
	sys/conf       : newvers.sh 
	sys/sys        : param.h 
	sys/arch/macppc/stand/tbxidata: bsd.tbxi 

Log message:
crank to 4.2-beta

This news is indeed a bit late. I wanted to wait until full snapshots sets were available for more architectures (mainly i386, since that's what I use). Be sure to check for, download and test 4.2-beta snapshots for your architecture from your favorite mirror.

(Comments are closed)


Comments
  1. By Anonymous Coward (212.85.74.34) on

    What needs testing?

    I know I'm gonna test that shiny new sis driver for the soekris :)

    Comments
    1. By Anonymous Coward (24.37.242.64) on

      > What needs testing?
      >
      > I know I'm gonna test that shiny new sis driver for the soekris :)

      Same here, and on my WRAP boxes too.

    2. By Jim Razmus II (jim) on http://www.bonetruck.org/

      > What needs testing?
      >
      > I know I'm gonna test that shiny new sis driver for the soekris :)

      Been running it since it was committed. Don't forget all the other network performance improvements too! Great stuff!

    3. By Anonymous Coward (198.175.14.5) on

      > What needs testing?
      >
      > I know I'm gonna test that shiny new sis driver for the soekris :)

      new SIS driver? what are you smoking?

      Comments
      1. By Darren Tucker (dtucker) on

        > > I know I'm gonna test that shiny new sis driver for the soekris :)
        >
        > new SIS driver? what are you smoking?

        It's not a new driver. The interrupt hold-off feature that was already present is now enabled by default, so the chip will wait a small amount of time (1ms) before sending an interrupt when it receives a packet.

        This means that if more packets arrive in that 1ms, they can be handled by the same interrupt, so the CPU usage for interrupts goes down (quite significantly, for boxes with lots of traffic and not much CPU like a busy Soekris). The tradeoff is that the average latency goes up, by up to 1 millisecond depending on your traffic patterns.

        Comments
        1. By Anonymous Coward (74.244.134.44) on

          > The interrupt hold-off feature that was already present is now enabled by default

          Is there some way to enable this under 4.1, or disable it under 4.2? I'd like to experiment with it on my -stable box, but i expect i'll want to keep it off. My WRAP routes traffic for a small dsl network, so even at saturation, load averages are around 12%.

          Comments
          1. By Darren Tucker (dtucker) on

            > > [sis interrupt hold-off]
            > Is there some way to enable this under 4.1, or disable it under 4.2?

            Edit sys/dev/pci/if_sisreg.h, change the NS_IHR_DELAY define, and build a new kernel.

          2. By sthen (85.158.44.149) on

            > > The interrupt hold-off feature that was already present is now enabled by default
            >
            > Is there some way to enable this under 4.1, or disable it under 4.2? I'd like to experiment with it on my -stable box, but i expect i'll want to keep it off. My WRAP routes traffic for a small dsl network, so even at saturation, load averages are around 12%.

            With higher packet load, setting IHR should make noticably more difference under 4.2 than it did in 4.1 (randomness used once per interrupt, instead of once per packet).

            I bet you can peg the cpu at 100% long before you fill the DSL pipe if your WRAP has to pass small packets.

        2. By Anonymous Coward (198.175.14.193) on


          > It's not a new driver. The interrupt hold-off feature that was already present is now enabled by default, so the chip will wait a small amount of time (1ms) before sending an interrupt when it receives a packet.
          >

          There have been patches available for years. It took some time to discover that the interval had to be set so large to be effective on the soekris.

          > This means that if more packets arrive in that 1ms, they can be handled by the same interrupt, so the CPU usage for interrupts goes down (quite significantly, for boxes with lots of traffic and not much CPU like a busy Soekris). The tradeoff is that the average latency goes up, by up to 1 millisecond depending on your traffic patterns.

          It is an unfortunate trade-off. It would be nice if the system could just automatically turn the value up and down based on CPU load or whatever.

          Comments
          1. By Darrin Chandler (dwc) on http://www.stilyagin.com/darrin/

            > It is an unfortunate trade-off. It would be nice if the system could just automatically turn the value up and down based on CPU load or whatever.

            I think it's a fine trade-off. The code remains simpler than putting in something to tweak values. And at least for my soekris usage (fw/AP for adsl), adding ~1ms latency will not cause any irritation or problem at all. I think this fits well as a sensible setting for the vast majority of uses.

            Comments
            1. By Anonymous Coward (198.175.14.193) on

              > > It is an unfortunate trade-off. It would be nice if the system could just automatically turn the value up and down based on CPU load or whatever.
              >
              > I think it's a fine trade-off. The code remains simpler than putting in something to tweak values. And at least for my soekris usage (fw/AP for adsl), adding ~1ms latency will not cause any irritation or problem at all. I think this fits well as a sensible setting for the vast majority of uses.

              While it might be fine at the end of an interleaved ADSL connection, it's not generally desirable.

  2. By jirib (195.212.29.163) on

    some short summary if there would be something 'new'? :)

    Comments
    1. By Pierre-Yves Ritschard (pyr) on http://spootnik.org

      > some short summary if there would be something 'new'? :)

      in the meantime: http://www.openbsd.org/plus.html

      Comments
      1. By Anonymous Coward (90.199.221.143) on

        > > some short summary if there would be something 'new'? :)
        >
        > in the meantime: http://www.openbsd.org/plus.html

        Reading through plus.html, I found this:

        "Drop the current random timestamps and ISN generation code for TCP and replace both with a RFC1948 based method so TCP clients now have monotonic ISN/timestamps."

        What does this mean and is this a retrograde step in security? It appears to make these more predictable again.

        Comments
        1. By Amir S Mesry (66.23.227.241) starkiller@web-illusions.net on

          > > > some short summary if there would be something 'new'? :)
          > >
          > > in the meantime: http://www.openbsd.org/plus.html
          >
          > Reading through plus.html, I found this:
          >
          > "Drop the current random timestamps and ISN generation code for TCP and replace both with a RFC1948 based method so TCP clients now have monotonic ISN/timestamps."
          >
          > What does this mean and is this a retrograde step in security? It appears to make these more predictable again.

          I wonder myself, that doesn't sound good, but I haven't read that RFC yet, but monotonic, that word doesn't sound good.

          Comments
          1. By Janne Johansson (82.182.176.20) jj@inet6.se on

            > > > > some short summary if there would be something 'new'? :)
            > > >
            > > > in the meantime: http://www.openbsd.org/plus.html
            > >
            > > Reading through plus.html, I found this:
            > >
            > > "Drop the current random timestamps and ISN generation code for TCP and replace both with a RFC1948 based method so TCP clients now have monotonic ISN/timestamps."
            > >
            > > What does this mean and is this a retrograde step in security? It appears to make these more predictable again.
            >
            > I wonder myself, that doesn't sound good, but I haven't read that RFC yet, but monotonic, that word doesn't sound good.

            I think this magic point slide says this was a change they had wanted to do:
            http://www.openbsd.org/papers/asiabsdcon07-network_randomness/mgp00042.html

            IIRC, the Basel EuroBSDCon randomness talk also pointed to the RFC 1948 as being the better solution. Also, monotonically means it increases, but not with a fixed amount, so a continously random increment is still a monotonically increasing function.

        2. By Anonymous Coward (206.248.190.11) on

          > "Drop the current random timestamps and ISN generation code for TCP and replace both with a RFC1948 based method so TCP clients now have monotonic ISN/timestamps."
          >
          > What does this mean and is this a retrograde step in security? It appears to make these more predictable again.

          No, it means that they are still random for different hosts, but monotonic from the same host/port combo. So if bad guy tries to connect to get an ISN, it won't help him guess the ISNs of any other connections, as those are all random. But within each host/port tuple the ISNs are monotonic. So if http_load makes thousands of connections to do a load test, each time it reconnects from the same port, it will have a higher ISN and not get stuck waiting for the old connection to be torn down.

    2. By sthen (85.158.44.149) on

      > some short summary if there would be something 'new'? :)

      faster networks, new device support, new X(7) version, softraid(4), hw.cpuspeed and apmd(8) speed control for MP, new timecounter code on many arch, lots of work on package tools, lots of work on audio, 4-byte ASN support for bgpd(8), new sudo(8) version (please merge /etc/sudoers changes), many other improvements and fixes.

      N.B. xbase is now required by many packages/ports since expat has moved there.

      Comments
      1. By Gerardo Santana (201.147.183.57) gerardo.santana gmail on

        N.B. xbase is now required by many packages/ports since expat has moved there.

        I thought for a moment that was crazy. But according to this, expat is part of the base system and the expat you're talking about is another copy.

        In summary, I don't understand why many ports would depend on xbase for expat. What ports are they?

        Comments
        1. By Devin Smith (drs) on

          The expat in the base system hasn't been audited so it is not enabled.

          >
          > In summary, I don't understand why many ports would depend on xbase for expat. What ports are they?
          >

          Subversion or a dependency, at least, requires expat to build. There are probably many others. Building ports without X installed is not really supported anyways.

        2. By sthen (85.158.44.149) on

          > I thought for a moment that was crazy. But according to this, expat is part of the base system

          Not yet, it's not linked into the build (see src/lib/Makefile) because it hasn't been audited. Discussed here: http://marc.info/?l=openbsd-misc&m=118166402911244&w=2.

          > In summary, I don't understand why many ports would depend on xbase for expat. What ports are they?

          gettext is common, and requires expat.

      2. By sthen (85.158.44.149) on

        > > some short summary if there would be something 'new'? :)
        >
        > faster networks, new device support, new X(7) version, softraid(4), hw.cpuspeed and apmd(8) speed control for MP, new timecounter code on many arch, lots of work on package tools, lots of work on audio, 4-byte ASN support for bgpd(8), new sudo(8) version (please merge /etc/sudoers changes), many other improvements and fixes.
        >
        > N.B. xbase is now required by many packages/ports since expat has moved there.

        oh, and how could I have forgotten these?

        ifconfig fxp0 10.20.30.40/24 (no more need for 'netmask a.b.c.d')
        ifconfig vlan5 vlandev bge1 (stating the vlan tag separately is now is optional)

  3. By Anonymous Coward (63.224.82.202) on

    I suppose running a standard set of tests, the things I do with OpenBSD would be the right approach. Is there any sort of framework used to do the tests?

    I see the 'make regress' option, but how do I set up my own regression test set? Does anyone have any advice as to where to start?

    Comments
    1. By rene (202.63.60.49) on

      > I suppose running a standard set of tests, the things I do with OpenBSD would be the right approach. Is there any sort of framework used to do the tests?
      >
      > I see the 'make regress' option, but how do I set up my own regression test set? Does anyone have any advice as to where to start?

      man bsd.regress.mk

  4. By Mike Swanson (24.22.214.92) on

    hmm... I just upgraded from OpenBSD 4.1 to a -current snapshot, however now all my X11 fonts are huge. I'm guessing it's not retaining my old DPI settings, but why not..? Is the configuration still supposed to be /etc/X11/xorg.conf

    Specifically I forced a DPI before with:
    DisplaySize 423 318
    in the Monitor section

    Comments
    1. By Matthieu Herrb (213.41.176.184) on

      > hmm... I just upgraded from OpenBSD 4.1 to a -current snapshot, however now all my X11 fonts are huge. I'm guessing it's not retaining my old DPI settings, but why not..? Is the configuration still supposed to be /etc/X11/xorg.conf
      >
      > Specifically I forced a DPI before with:
      > DisplaySize 423 318
      > in the Monitor section

      You'll need to provide more details. Starting with the /var/log/Xorg.0.log file.

      Xorg now pays more attention to the DPI computed from the geometry reported by the monitors via DDC/EDID. In the past the resolutions reported by the X server were often completely wrong, leading to wrong choices of font sizes in the applications (either by the programmers or by the users by local customizations). Now that the reported values are more accurated, strange things happen. But the right thing to do is to fix the application configuration to use the proper font size, not to force the X server to report wrong values.

      Depending on the toolkit you're using (Gtk+, Qt, Xaw/Motif,...) the ways to configure the default font size are different. But this is another kind of nuisance.

  5. By Anonymous Coward (64.233.230.46) on

    does -current include the pnow.diff?

    Comments
    1. By Gordon Willem Kklok (68.148.17.121) gwk@gwk.ca on

      > does -current include the pnow.diff?

      No and 4.2 will not ship with it, it bloats the kernel binary too greatly. Chris Kuethe and I are working on a more elegant solution I would expect it will be available sometime after the 4.2 release.

      gwk

  6. By Lawrence Teo (lteo) lteo.openbsd1 ! calyptix.com on http://www.calyptix.com/

    I noticed a lot of FFS2-related check-ins and that it is enabled in the GENERIC kernel -- will it be ready for production use in 4.2?

    This misc@ post about FFS2 by Otto dated May 20 says there were "some issues" in both kernel and userland; have those issues been resolved?

    Comments
    1. By Otto Moerbeek (otto) on http://www.drijf.net

      >
      > I noticed a lot of FFS2-related check-ins and that it is enabled in the GENERIC kernel -- will it be ready for production use in 4.2?
      >

      All know bugs have been fixed, and userland utilities have been modified to handle FFS2 where appropriate.

      I'd say FFS2 is ready for serious testing. Only with a lot of testing by a lot op people in different setups I can tell if it's ready for production.

      Note that large disk support is not completely done yet.

      -Otto

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]