Contributed by maxime on from the β dept.
Miod Vallat (miod@) has tagged 4.6-BETA. Snapshots should be available soon for testing, check the mirrors for availability. Read below for the full commit message:
From: Miod VallatTo: source-changes@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src Date: Sat, 20 Jun 2009 17:38:12 -0600 (MDT) CVSROOT: /cvs Module name: src Changes by: miod@cvs.openbsd.org 2009/06/20 17:38:12 Modified files: distrib/sets/lists/base: md.alpha md.amd64 md.armish md.aviion md.hp300 md.hppa md.hppa64 md.i386 md.landisk md.luna88k md.mac68k md.macppc md.mvme68k md.mvme88k md.mvmeppc md.sgi md.socppc md.sparc md.sparc64 md.vax md.zaurus distrib/sets/lists/comp: md.alpha md.amd64 md.armish md.aviion md.hp300 md.hppa md.hppa64 md.i386 md.landisk md.luna88k md.mac68k md.macppc md.mvme68k md.mvme88k md.mvmeppc md.sgi md.socppc md.sparc md.sparc64 md.vax md.zaurus etc/root : root.mail share/mk : sys.mk share/tmac/mdoc: doc-common sys/arch/macppc/stand/tbxidata: bsd.tbxi sys/conf : newvers.sh sys/sys : param.h Log message: 4.6-BETA
We need users to help test all parts of OpenBSD. Please report any critical bugs and problems you can find so we can release a fully functional and stable OpenBSD 4.6.
(Comments are closed)
By Venture37 (venture37) venture37<A>hotmail.com on http://www.geeklan.co.uk
By Cobalt (129.174.114.16) on
Did something utterly tremendous happen at the hackathon that needs the extended testing? Were the ACPI changes just that good? (Can we blame AerieBSD in some twisted and mindboggling manner?)
Bah, I finally got all my boxen up to 4.5, too.
Comments
By thoren (2001:470:a:284::2) on
eh, 4.4-Beta was announced on undeadly July 2 last year.
http://www.undeadly.org/cgi?action=article&sid=20080702151935
Comments
By Cobalt (129.174.112.224) on
>
> eh, 4.4-Beta was announced on undeadly July 2 last year.
>
> http://www.undeadly.org/cgi?action=article&sid=20080702151935
Fair enough, but that post also has a note of a lot of new functionality added during the hackathons. Those hackathons last year were well publicized with undeadly entries, etc. so the quieter improvement process is what prompted the question. I defer to the devs, who clearly know what it takes to make their software right far better than I do.
By Anonymous Coward (85.164.128.49) on
>
> Did something utterly tremendous happen at the hackathon that needs the extended testing? Were the ACPI changes just that good? (Can we blame AerieBSD in some twisted and mindboggling manner?)
>
> Bah, I finally got all my boxen up to 4.5, too.
This is for some breathing room for future changes.
Keep watching the skies!!!
By Marc Espie (163.5.254.20) espie@openbsd.org on
Yes, it's early.
> Did something utterly tremendous happen at the hackathon that needs the extended testing? Were the ACPI changes just that good? (Can we blame AerieBSD in some twisted and mindboggling manner?)
No, nothing that twisted. It's just people's schedule. The release should be finished early so that the next development cycle can begin early.
By Anonymous Coward (84.3.125.243) on
Comments
By Timo Schoeler (2001:1560:2:0:21f:d0ff:fe5c:e8c7) on
So, is this VRF functionality (I presume that this is glue to MPLS) the same or at least similar to what Cisco implements?
Long story made short: A customer of mine wants to replace some Cisco L2TP gear, so we need VRF functionality on OS level pretty soon. Would be nice to add another server with a puffy stick on it, replacing the burning bridge from SF ;)
Comments
By Anonymous Coward (85.164.128.49) on
>
> So, is this VRF functionality (I presume that this is glue to MPLS) the same or at least similar to what Cisco implements?
>
> Long story made short: A customer of mine wants to replace some Cisco L2TP gear, so we need VRF functionality on OS level pretty soon. Would be nice to add another server with a puffy stick on it, replacing the burning bridge from SF ;)
Word on the street is that claudio@ would really enjoy rolling around naked on a pile of money.
Perhaps the two of you can come to an arrangement ;)
By Anonymous Coward (84.206.8.140) on
>
> So, is this VRF functionality (I presume that this is glue to MPLS) the same or at least similar to what Cisco implements?
>
> Long story made short: A customer of mine wants to replace some Cisco L2TP gear, so we need VRF functionality on OS level pretty soon. Would be nice to add another server with a puffy stick on it, replacing the burning bridge from SF ;)
YES similar to Cisco i think...
first cvs commit:
http://kerneltrap.org/mailarchive/openbsd-source-changes/2009/6/5/5875103
By Anonymous Coward (212.77.163.101) on
>
> So, is this VRF functionality (I presume that this is glue to MPLS) the same or at least similar to what Cisco implements?
>
> Long story made short: A customer of mine wants to replace some Cisco L2TP gear, so we need VRF functionality on OS level pretty soon. Would be nice to add another server with a puffy stick on it, replacing the burning bridge from SF ;)
----
I think you can speed it up with some donations ... that will be much nicer.
Comments
By Timo Schoeler (2001:1560:2:0:21f:d0ff:fe5c:e8c7) timo@riscworks.net on
> >
> > So, is this VRF functionality (I presume that this is glue to MPLS) the same or at least similar to what Cisco implements?
> >
> > Long story made short: A customer of mine wants to replace some Cisco L2TP gear, so we need VRF functionality on OS level pretty soon. Would be nice to add another server with a puffy stick on it, replacing the burning bridge from SF ;)
>
> ----
> I think you can speed it up with some donations ... that will be much nicer.
Nicer than what? Besides this, sure, I'd like to donate. What'd be of use for getting VRFs up and running?
Comments
By Anonymous Coward (85.164.133.231) on
> > >
> > > So, is this VRF functionality (I presume that this is glue to MPLS) the same or at least similar to what Cisco implements?
> > >
> > > Long story made short: A customer of mine wants to replace some Cisco L2TP gear, so we need VRF functionality on OS level pretty soon. Would be nice to add another server with a puffy stick on it, replacing the burning bridge from SF ;)
> >
> > ----
> > I think you can speed it up with some donations ... that will be much nicer.
>
> Nicer than what? Besides this, sure, I'd like to donate. What'd be of use for getting VRFs up and running?
Word on the street is that claudio@ would like to roll around naked on a pile of cash...
By SnipX (93.0.217.46) on
Very good job ;)
Comments
By Anonymous Coward (2a01:348:108:100:230:18ff:fea0:6af6) on
>
> Very good job ;)
while that's useful, the best thing to test is the binary snapshots (and associated snapshot packages). try and test the installer too if you can, rather than just untarring sets, it has had a huge amount of work since 4.5.
Comments
By SnipX (83.206.89.177) on
Yes, I have installed with the snapshot ISO, and I have updated the kernel and the binary (via cvs + build), and it's OK.
I have tested the new installer, and it's easier than the previous.
Comments
By Richard Toohey (121.72.10.92) on
>
> Yes, I have installed with the snapshot ISO, and I have updated the kernel and the binary (via cvs + build), and it's OK.
> I have tested the new installer, and it's easier than the previous.
Installed i386 1st July snapshot on Dell Optiplex (P4 3.0 Ghz, 160Gb) and all good so far (dhclient em0; startx; fetch the ports snapshot file; build something) I like the new installer ... but one question ...
My test plan was to install and then immediately build Firefox from ports (to give the system something to do) - all went well for a couple of hours and then stopped because /usr runs out of space (the installer sets to 2Gb on this 160Gb drive) - guess /usr/ports is not going to be the place to build ports, or I've got to do something differently now? I've usually followed the partitioning plan on the CD cover instructions, but made /usr, /var, and /home multi-gigabyte. Advice appreciated ...
As usual, thanks to the developers for their efforts; looking forward to the 4.6 release.
Comments
By sthen (2a01:348:108:100:230:18ff:fea0:6af6) on
If you want to avoid repartitioning, you can point WRKOBJDIR=/path/to/somewhere/with/space in /etc/mk.conf. The defaults are geared around someone using packages rather than building from ports.
Comments
By Richard Toohey (121.72.33.55) on
> If you want to avoid repartitioning, you can point WRKOBJDIR=/path/to/somewhere/with/space in /etc/mk.conf. The defaults are geared around someone using packages rather than building from ports.
Thanks, Stuart. Doing the following (not saying that it is good but it let me finish the build and make this posting from OpenBSD 4.6 beta.)
By Anonymous Coward (77.21.70.77) on
needs a hard reboot
/home is on a softraid crypto partition, flags: nodev,nosuid,noatime,softdep
/mnt is a normal nfs-share mounted from the router
machdep.userldt can be zero or one, makes no difference
apmd with apm -C does not seam to be the reason (crashed even without)
It might be related to the inteldrm (gm965)
The video in question was an X-Files episode.. :-)
Comments
By Anonymous Coward (85.19.213.88) on
> moves still but the rest of the system is plain dead...
>
> needs a hard reboot
>
And you need to sendbug(1) or tell misc@.
By Owain G. Ainsworth (oga) on
>
> needs a hard reboot
>
> /home is on a softraid crypto partition, flags: nodev,nosuid,noatime,softdep
> /mnt is a normal nfs-share mounted from the router
>
> machdep.userldt can be zero or one, makes no difference
> apmd with apm -C does not seam to be the reason (crashed even without)
>
> It might be related to the inteldrm (gm965)
>
>
> The video in question was an X-Files episode.. :-)
Can't reproduce that here on an x61s running amd64.
I do that particular task a lot.
Comments
By Anonymous Coward (96.241.175.54) on
> >
> > needs a hard reboot
> >
> > /home is on a softraid crypto partition, flags: nodev,nosuid,noatime,softdep
> > /mnt is a normal nfs-share mounted from the router
> >
> > machdep.userldt can be zero or one, makes no difference
> > apmd with apm -C does not seam to be the reason (crashed even without)
> >
> > It might be related to the inteldrm (gm965)
> >
> >
> > The video in question was an X-Files episode.. :-)
>
>
> Can't reproduce that here on an x61s running amd64.
>
> I do that particular task a lot.
>
> > mount a NFS share, wtach a video on a ibm x61s -> freeze, mouse moves still but the rest of the system is plain dead...
> >
> > needs a hard reboot
> >
> > /home is on a softraid crypto partition, flags: nodev,nosuid,noatime,softdep
> > /mnt is a normal nfs-share mounted from the router
> >
> > machdep.userldt can be zero or one, makes no difference
> > apmd with apm -C does not seam to be the reason (crashed even without)
> >
> > It might be related to the inteldrm (gm965)
> >
> >
> > The video in question was an X-Files episode.. :-)
>
>
> Can't reproduce that here on an x61s running amd64.
>
> I do that particular task a lot.
The problem is it happens sporadicly! :-(
I can watch like Xfiles (season 4) 1-10 but 11 makes X and everythign else hangs.
I looks, even without traces, like something relate dto inteldrm and memory handling propaly.
I mostly does NOT affect the HW if I watch a single video.
But if I watch a bounch of them, like X-files season 4 1-9 via mplayer xxxx.s04.*0{0,1,2,3,4,5,6,7,8,9}* on a share mounted via NFS it offen happens that X hangs.
I noticed that during: switiching to console and back, commanding mplayer to play the rest (other vides, same seasonof X-files, same codec and co.. *hail pirates*).
So with a single video you might not be able to reporiduce it, you've to watch a lot videos propably but the bug is there...
Regards,
Rembrandt
p.s
If you own a X61A: do you have fucked up spee reports with apmd too? I mean the following speeds: 1600Mhz and 1601Mhz, they are both 2 seperate values (and thus states) for my APM... pretty "omg".
Also the laptop itself gets pretty warm during apm -C...
p.p.s
I use i386, windows codecs, you know? and somebody might update them...