Development is really fast right now, because of the hackathon in Edmonton.
We are testing as much as we can before we commit, but as always

during these hackathon processes we really depend on our user

community -- to track our changes and help spot the occasional bug we

accidentally introduce.
We are developing really fast and hard; please help us by testing

really fast and hard too.
There are some snapshots being made, of course, but people who are

familiar with checking out their own trees can really help us by building

and running it immediately.

Snapshots as of: Tue Jun 10 05:32:16 MDT 2008
Following Theo request for testing. Same test as previously reported and

same crash 100% reproduce able and reported a few times on misc@ as well

as tech@ using the multi code on amd64.
So, not worst then it used to be for that.
Just doing a simple:
dd if=/dev/zero of=/var/test bs=1m count=1000
Doesn't do it using the single amd64 kernel, nor does it do it using

either the i386 single kernel, or multi core one.
Only with the amd64.mp and is reproducible at will.
Marco@ is aware of it and was also able to reproduce the problem as well

on his X4100 too.
http://marc.info/?l=openbsd-tech&m=120122281409313&w=2
But we do have 8GB or memory now, witch is nice! (;>
dmesg below:
OpenBSD 4.3-current (GENERIC.MP) #1704: Tue Jun 10 05:32:16 MDT 2008

     deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 8576897024 (8179MB)

avail mem = 8330035200 (7944MB)

mainbus0 at root

bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfbd50 (70 entries)

bios0: vendor American Megatrends Inc. version "0ABJX039" date 04/11/2007

bios0: Sun Microsystems Sun Fire X4100 M2

acpi0 at bios0: rev 2

acpi0: tables DSDT FACP APIC SPCR SLIT OEMB HPET IPET SRAT SSDT

acpi0: wakeup devices PS2K(S1) PS2M(S1) USB0(S4) USB1(S4) MAC_(S5)

P0P1(S4) P0P2(S4) P0P3(S4) P0P4(S4) P0P5(S4) IO4B(S4) BR5B(S4) BR5C(S4)

BR5D(S4) BR5E(S4) IOB2(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR2E(S4) PWRB(S1)

acpitimer0 at acpi0: 3579545 Hz, 24 bits

acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat

cpu0 at mainbus0: apid 0 (boot processor)

cpu0: Dual-Core AMD Opteron(tm) Processor 2216, 2393.96 MHz

cpu0:

FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW

cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB

64b/line 16-way L2 cache

cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative

cpu0: DTLB 32 4KB entries fully assoc...
[ message continues ]

I wanted to make a correction here as I got a comment that puzzled me

and that may have created a miss understanding on my part on the way I

wrote my text.
If the perception have been taken by anyone as a complain, or otherwise

I want to apologies for this!
It's possible that some may have taken it to mean bad things and if so I

am very sorry for it and that sure wasn't the intend here.
If Marco took it as a complain as well I want to make sure I correct

this and retract that as well as offering my public apology for that!
And just that I don't create an additional miss understanding, no Marco

didn't comment to me in case anyone thought he did on this post.
Sure this wasn't my intention what so ever and far from it. There have

been lots of chances and improvements and I thought testing the

snapshots and reporting bugs was the intent if any?
The crash on the Sun X4100 M2 is an old issue and it may have been fix

or may so, I tested it as well as to see if the new memory works too. I

only wanted to report my tests that all is still working as it was for

three of the kernel and that on the amd64 bsd.mp, the same issue was

still present.
There was lots of thought at the time that ACPI may have major impact on

this crash and looking at the source changes in the last few weeks there

have been lots of changes there too.
So, I thought it was important to test it and report it.
Obviously I don't write well and some may have taken it as bad from my

part witch really wasn't near my intention or thoughts when I wrote my

previous report.
Again if anyone read something in it, that wasn't intentional for sure,

then again I sure apologies for it!
More importantly as well if Marco took offense to it, I sure deeply

regret that as well and accept my apology for that. It wasn't even near

the intent of it.
I hope this clear any possible miss understanding from my post that sure

wasn't there intentionally from me.
Daniel

Is there a particular time of day most changes are committed (like

pre-dinner) or should we sync and build at whim?

Oh come on.
We are being careful.  The tree builds -- always.  Only one commit done

so far has broken something so far -- for about 3 minutes -- which none

of you noticed.

People are working pretty much all the time, though you may notice a

slight decrease in commit rate around beer o'clock (between 11pm and

1am, TZ=Canada/Mountain).
At any rate, we try to keep things production-stable even during a

hackathon: our productivity during the event depends on it, so you can

sync and build pretty much anytime. If you run into problems check the

most recent commit messages and see if it's been fixed while your

machine was building.

I have 2 units (almost anyway) set up now for pf-pfsync-carp-dhcpd-

ipsec-blahblah-andsomeotherstuff, with some users behind it, all for

testing, no production. Looking forward to keeping up with the tree

when I can.
Good luck in Edmondchuck, and have fun all, we look forward to reading

about it all.
p.s. love the shirt.