Please send a cl to revert the change. I believe the major blocker
previously was the dashboard builders which have since been addressed.

You have my support (at least) for fixing this.
On 18 Jan 2015 13:27, "Bill" notifications@github.com wrote:

In #6372 #6372 the use of INT 0x80
instead of the SYSCALL instruction was chosen as the slower but correct
option for a kernel bug on FreeBSD.

Of the 6 current combinations of FreeBSD {8,9,10}-{RELEASE,STABLE} only
8.4-RELEASE doesn't have the fix from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182161

That version was released on June 9, 2013 and has an expected EoL of June
30, 2015

A simple benchmark for getting time ( http://play.golang.org/p/QUwb_r1d0G
) on my FreeBSD 9.3-RELEASE machine shows:

$ benchcmp /tmp/INT80 /tmp/SYSCALL
benchmark old ns/op new ns/op delta
BenchmarkStdTime 275 126 -54.18%

Which is a significant. The Go 1.3 doc states that Go requires FreeBSD 8
or above. So I have a couple questions:

1. Can the definition of FreeBSD 8 be stretched to require -STABLE over
   -RELEASE. If yes, I can send a CL to revert 555da73
   555da73
   .
2. If not, is there a dynamic way to set the SYSCALL instruction at
   runtime? I can't imagine how, but the intricacies of the runtime and linker
   are beyond me.
3. If no to 1 & 2, when do we expect to drop the FBSD 8 requirement?
   Should I just come back on July 1st and we can revisit?

—
Reply to this email directly or view it on GitHub
#9627.

1. SGTM. Send a CL to revert and also update the docs to say FreeBSD 8-STABLE or higher?

Is there an easy way to determine if a system is not affected by the
bug at runtime?

I think we can use something like this for the SYSCALL macro:
#define SYSCALL
CMPB runtime.buggySYSCALL(SB), $1;
JEQ 2(PC);
SYSCALL;
JMP 3(PC);
MOVQ R10, CX;
INT $0x80;

Provided that we have a simple way to set runtime.buggySYSCALL.
The branch should be always predicted correctly, so it won't affect
performance.

I don't think that is worth the effort. When this came up last cycle the
FreeBSD deva confirmed all shipping versions were already fixed. The only
holdouts were our own builders, which have since been fixed.
On 18 Jan 2015 13:38, "Minux Ma" notifications@github.com wrote:

Is there an easy way to determine if a system is not affected by the
bug at runtime?

I think we can use something like this for the SYSCALL macro:
#define SYSCALL
CMPB runtime.buggySYSCALL(SB), $1;
JEQ 2(PC);
SYSCALL;
JMP 3(PC);
MOVQ R10, CX;
INT $0x80;

Provided that we have a simple way to set runtime.buggySYSCALL.
The branch should be always predicted correctly, so it won't affect
performance.

—
Reply to this email directly or view it on GitHub
#9627 (comment).

Aside: maybe @wathiede wants to help with #8639 (move FreeBSD builders to GCE).

I'll get a CL sent when I get the CLA check on git mail figured out. It doesn't recognize me.

@minix I don't know of an easy check. The fix in the FreeBSD kernel doesn't have any API visible differences, so at best I'd have to build some sort of whitelist based on version strings out of uname or sysctl.

@bradfitz that does sound like something I'd be interested in. Let me read up on it and try to get something working this week.

Ugh it looks like I broke the build:

http://build.golang.org/log/977a45e7d1acbb8c464ecca1f714659818f64596

But src/all.bash is completing successfully on my machine. The step that timesout on the builder takes:

##### GOMAXPROCS=2 runtime -cpu=1,2,4
ok      runtime 53.032s

For reference, on my machine, the ##### Testing packages section takes:

real    0m28.597s
user    1m42.035s
sys     0m19.820s

Compared to the value reported on the builder of:

real    1m56.056s
user    2m5.293s
sys 0m23.400s

So a legitimate test run crossing the 10 minute window, based on 53s from my machine, seems unlikely.

I have no idea how to fix this, as I can't reproduce the test timeout locally.

Even if the builder is running an older FreeBSD, @adg said 9.1 in another thread, I wouldn't expect things to break this bad with this change. Prior to #6372 only one build in a couple dozens would have a errant syscall.

Is there any easy way to revert this, or do I just send another CL? Any suggestions on how to test/debug this?