OpenBSD Journal

OpenBSD Moves To 3.9-beta

Contributed by jolan on from the nearing-release-time dept.

Theo has bumped the version identifier (with an unfortunate typo in the commit log) from 3.8-current to 3.9-beta in CVS HEAD. The most notable recent developments have been major bumps due to type changes and an X.org upgrade to 6.9.0. Now is an especially good time to test snapshots.

(Comments are closed)

Comments

  1. By Anonymous Coward (202.45.98.23) on

    Can that typo be edited to be corrected?

    Comments

    1. By Anonymous Coward (202.6.138.33) on

      Haha, yeah. Then run around breaking into all the web archives to change it there too.

      Comments

      1. By Anonymous Coward (216.120.176.146) on

        I assume he meant in CVS. Correcting it in CVS would be somewhat useful even if you can't fix it on the mailing list archives.

    2. By Anonymous Coward (64.254.225.66) on

      That's why they use CVS.. they need to keep track of these things, regardless of importance, location or person. Theo doesn't hold himself to a lower standard than anyone else who commits; thus, if he makes a mistake, he fixes it. No big deal.

  2. By Anonymous Coward (66.11.66.41) on

    I recall some "we need more RAM to get > 4GB working" emails back around hackathon time, did anything ever come of that? Can we use 16GB of RAM in openbsd now?

    Comments

    1. By Anonymous Coward (143.166.226.18) on

      yes when using iommu

      Comments

      1. By Anonymous Coward (70.27.15.123) on

        "When using iommu"? What does that mean? When you change the source to enable something that is broken, so you have an unsupported system that panics instead of working?

        Comments

        1. By tedu (71.139.175.127) on

          it certainly doesn't support > 4GB RAM without iommu.

        2. By Brad (70.27.182.132) brad at comstyle dot com on

          That means when using real amd64 hardware from AMD as opposed to Intel EMT64 CPUs.

          Comments

          1. By Anonymous Coward (66.11.66.41) on

            http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/pci/iommu.c?rev=1.12&content-type=text/x-cvsweb-markup Its disabled because it panics on SMP machines. You need SMP to use 16GB of RAM on AMD64. So the answer then would be no, its still limited to 4GB?

            Comments

            1. By Anonymous Coward (143.166.226.18) on

              That only happens with SATA drives on some shitty on board chip, forget the vendor. Ask yourself this: if I need 16GB in my server do I want to use SATA?

              If you answered yes you should maybe try another profession.

              Comments

              1. By Anonymous Coward (66.11.66.41) on

                So then yes, it is "When you change the source to enable something that is broken, so you have an unsupported system that panics instead of working?". Who says its only problematic on certain boards with SATA drives? Since its not enabled, its neither well tested, nor supported.

                Comments

                1. By Anonymous Coward (143.166.255.17) on

                  Did you even look in cvs?

                  It's enabled by default however it only attaches when there is more than 4GB of RAM. What part of it runs on ALL high mem systems don't you get?

                  Comments

                  1. By Brad (216.138.195.228) brad at comstyle dot com on

                    on all high mem systems with an AMD processor and not an Intel EM64T processor.

              2. By Brad (216.138.195.228) brad at comstyle dot com on

                AFAIK the issue was resolved ..

            2. By tedu (69.12.168.114) on

              if you're gonna use cvs, use it properly. :)

              http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/machdep.c.diff?r1=1.33&r2=1.34

    2. By Anonymous Coward (68.148.1.194) on

      We may even be able to commit it...

      -T.

      Comments

      1. By Anonymous Coward (70.27.15.123) on

        Which diff is that? All I saw was a PAE diff. I don't have any i386 machines with > 4GB of RAM, nor do I want any.

  3. By Andy (82.44.215.41) on

    Hmmm, no x<archive>.tgz files on the Zaurus snapshot yet.... I wonder if there are problems or if this is because it takes forever to build these bits on the Z.

  4. By sthen (81.168.66.229) on

    Don't forget the libraries have debug information now, making them significantly larger than they were for 3.8 (the increased size isn't reflected in the disk space use section of the INSTALL.xx files yet)...so check how much space you have free (/usr is the main potential problem area, especially likely to occur with comp39.tgz).

    If there's enough space but it's a tight fit, make sure softdep is disabled before you start unpacking as the delayed-file-removal is likely to get you unstuck. If you're still short and have upgraded from 3.7 or earlier, you might have some old `uname -m`-unknown-openbsd directories hanging around that locate will find for you that would give you a little extra breathing space.

Latest Articles

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.]