date:20121217


On 17.12.2012 03:29, Adrian Chadd wrote:

On 16 December 2012 15:37, Alexander Motin m...@freebsd.org wrote:

Here is one more version. Unless something new will be found/reported this
may be the last one, because me and Davide are quite satisfied with the
results. If everything will be fine, I think we could commit it to HEAD
closer to the end of the week:
http://people.freebsd.org/~mav/calloutng_12_16.patch


Don't you think one week is a little on the low side for reviewing
something this critical?


It was in public development for the last half a year. IIRC, previous 
announce by Davide few months ago caused no any feedback. If you say you 
will review it in two weeks, I will wait for two weeks. But I don't want 
to wait without a purpose.



Would you mind approaching some of the cluster peeps and seeing if
they'll run this up on the ref10* boxes and VMs, just to get some
further exposure?


Are the ref* system have any load to see anything?

--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC/RFT] calloutng


On 17.12.2012 05:38, Adrian Chadd wrote:

On 16 December 2012 18:31, Garrett Cooper yaneg...@gmail.com wrote:


Would you mind approaching some of the cluster peeps and seeing if
they'll run this up on the ref10* boxes and VMs, just to get some
further exposure?


And maybe tinderbox..?


Tinderbox is a great idea.

Maybe hit up the altq/pf using crowd and see if they'll test this stuff out too?


It would be good to test, though I know that at least dummynet is 
written awful from the point of this project with its

callout_reset(dn_timeout, 1, dummynet, NULL);
It should work, but kill most of power benefits. I was promised it will 
be fixed after this project end.



What else gets heavily callout /timer driven? Try some computational
workloads that stress the fairness of ULE/4BSD, maybe?


Schedulers are driven directly by hardclock()/statclock(), so fairness 
is not affected here. If CPU is not idle, it will receive full set of 
required events with maximum available precision.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC/RFT] calloutng

2012-12-17 Thread Adrian Chadd

On 16 December 2012 23:57, Andriy Gapon a...@freebsd.org wrote:

 Thank god that this feature was developed in a branch, it was developed for a
 long period of time and there were people who routinely reviewed and tested 
 (and
 really used) it.  And yeah, its design was announced and discussed well in
 advance too.

I can see that; I was even there at David's presentation at BSDCan
2012 about it.

Now that it's finished though, it would be nice to get some more
stress testing before committing it. Just because it's been developed
in a branch doesn't at all imply that it's had wide testing. It's now
imminently going into the tree, so that may scare (heh!) a few people
into testing it.

I'm sure it'll mostly just work, that it'll not really break anything.
It just to me feels that a week of warning before committing something
like this is a little soon. It's _just_ been finished and the authors
have been doing some last minute changes as they get better ideas on
implementing things. I think it's great work, I'd just like to see
some wider testing.

So to put my money where my mouth is, I bought a new hard disk for my
T60 last week. I'll install -HEAD on it tomorrow and give it a whirl.

Thanks,


Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Clang/LLVM revision 169451

2012-12-17 Thread Sam Fourman Jr.

 No, there is no one-click merge script, it needs humanoid help, I'm
 afraid. :-)  Is there any reason you cannot just install the port, or
 if that is too outdated, just checkout from llvm.org directly and build
 it?

is it currently possible to build FreeBSD world, without clang and
then build clang from ports?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Problem booting FreeBSD 10-CURRENT from my MacBook Pro: Can't load kernel

2012-12-17 Thread Anders Bolt-Evensen

Hi, everyone and good morning! To make a long story short I'm attempting to
install 10-CURRENT on my 2011 model 17 inch MacBook Pro. I downloaded the
appropriate amd64 image from FreeBSD's FTP site, burned it out to DVD and
installed it on my old FreeBSD 9 partition, erasing existing data. However,
when I try to boot the new system, I get a can't load kernel error. Giving
the command ls returns the message Open '/' failed: no such file or
directory. 
When I type lsdev the following is returned:
cd devices:
disk devices:
disk0: BIOS drive C
pxe devices:
I can work around the problem by copying /boot from the FreeBSD 9 installer
to my new FreeBSD 10 system, but I do believe this is not the right
solution? And when I then boot off the system, I get a lot of other system
errors. 
PS: my Mac does not have a real BIOS, so changing any BIOS settings is
unfortunately not an option.

I hope you can help me out and thanks in advance.

Have a great day, everyone!
Best wishes, 
Anders


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: X on ThinkPad X220 with chrome or firefox goes blank

2012-12-17 Thread Artyom Mirgorodskiy

Did you try to rebuild xorg-server with latest clang patch? (this patch 
commited 2-3 days ago)

On Monday 17 December 2012 08:40:37 Erich Dollansky wrote:
 Hi,
 
 I updated my notebook over the last couple of days and have now
 problems starting chrome and firefox. The effect is that the screen
 turns blury leaving hard to recognose characters on a white screen
 after starting any of these applications.
 
 I can use Ctrl-Alt-F2 to come back to the terminal. Of course, this is
 now a flight in the dark. After entering Ctrl-C and restart X, I get a
 new X running until I start firefox or chrome again.
 
 Applications like Claws Mail, Arora or xterm work without problems.
 
 I do not see anything different in the log file of X.
 
 Does anybody have a clue what could cause this?
 
 I will recompile and reinstall all my ports now to see what will come
 out there.
 
 Erich
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
-- 
Artyom Mirgorodskiy
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Clang/LLVM revision 169451

2012-12-17 Thread Dimitry Andric


On 2012-12-17 09:36, Sam Fourman Jr. wrote:

No, there is no one-click merge script, it needs humanoid help, I'm
afraid. :-)  Is there any reason you cannot just install the port, or
if that is too outdated, just checkout from llvm.org directly and build
it?


is it currently possible to build FreeBSD world, without clang and
then build clang from ports?


There is no real need, as you can just put /usr/local/bin before
/usr/bin in your PATH, but if you really want to do so, you can put the
following in /etc/src.conf:

CC=gcc
CXX=g++
CPP=gcpp
WITHOUT_CLANG=

From then on, you build world with gcc, which will also be installed as
/usr/bin/cc again.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: X on ThinkPad X220 with chrome or firefox goes blank

2012-12-17 Thread Erich Dollansky

Hi,

On Mon, 17 Dec 2012 11:44:59 +0200
Artyom Mirgorodskiy artyom.mirgorod...@gmail.com wrote:

 Did you try to rebuild xorg-server with latest clang patch? (this
 patch commited 2-3 days ago)

I do not know as I updated the ports tree around this time. Let me do
it again.

Thanks for the hint.

Erich
 
 On Monday 17 December 2012 08:40:37 Erich Dollansky wrote:
  Hi,
  
  I updated my notebook over the last couple of days and have now
  problems starting chrome and firefox. The effect is that the screen
  turns blury leaving hard to recognose characters on a white screen
  after starting any of these applications.
  
  I can use Ctrl-Alt-F2 to come back to the terminal. Of course, this
  is now a flight in the dark. After entering Ctrl-C and restart X, I
  get a new X running until I start firefox or chrome again.
  
  Applications like Claws Mail, Arora or xterm work without problems.
  
  I do not see anything different in the log file of X.
  
  Does anybody have a clue what could cause this?
  
  I will recompile and reinstall all my ports now to see what will
  come out there.
  
  Erich
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to
  freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Clang/LLVM revision 169451

2012-12-17 Thread Sam Fourman Jr.

On Mon, Dec 17, 2012 at 6:50 AM, Dimitry Andric d...@freebsd.org wrote:
 On 2012-12-17 09:36, Sam Fourman Jr. wrote:

 No, there is no one-click merge script, it needs humanoid help, I'm
 afraid. :-)  Is there any reason you cannot just install the port, or
 if that is too outdated, just checkout from llvm.org directly and build
 it?


 is it currently possible to build FreeBSD world, without clang and
 then build clang from ports?


 There is no real need, as you can just put /usr/local/bin before
 /usr/bin in your PATH, but if you really want to do so, you can put the
 following in /etc/src.conf:

 CC=gcc
 CXX=g++
 CPP=gcpp
 WITHOUT_CLANG=

 From then on, you build world with gcc, which will also be installed as
 /usr/bin/cc again.


I ended up generating and applying this patch, and rebuilt world again

root@www:/root # cat clang-169451.patch

Index: contrib/llvm/tools/clang/include/clang/Sema/Scope.h
===
--- contrib/llvm/tools/clang/include/clang/Sema/Scope.h (revision 244350)
+++ contrib/llvm/tools/clang/include/clang/Sema/Scope.h (working copy)
@@ -84,11 +84,18 @@
 /// TryScope - This is the scope of a C++ try statement.
 TryScope = 0x1000,

+/// CatchScope - This is the scope of a C++ catch statement.
+CatchScope = 0x2000,
+
+/// FnTryCatchScope - This is the scope for a function-level C++ try or
+/// catch scope.
+FnTryCatchScope = 0x4000,
+
 /// FnTryScope - This is the scope of a function-level C++ try scope.
-FnTryScope = 0x3000,
+FnTryScope = TryScope | FnTryCatchScope,

 /// FnCatchScope - This is the scope of a function-level C++ catch scope.
-FnCatchScope = 0x4000
+FnCatchScope = CatchScope | FnTryCatchScope
   };
 private:
   /// The parent scope for this scope.  This is null for the translation-unit
Index: contrib/llvm/tools/clang/lib/Parse/ParseStmt.cpp
===
--- contrib/llvm/tools/clang/lib/Parse/ParseStmt.cpp(revision 244350)
+++ contrib/llvm/tools/clang/lib/Parse/ParseStmt.cpp(working copy)
@@ -2197,7 +2197,7 @@
   // The name in a catch exception-declaration is local to the handler and
   // shall not be redeclared in the outermost block of the handler.
   ParseScope CatchScope(this, Scope::DeclScope | Scope::ControlScope |
-  (FnCatch ? Scope::FnCatchScope : 0));
+  (FnCatch ? Scope::FnCatchScope : Scope::CatchScope));

   // exception-declaration is equivalent to '...' or a parameter-declaration
   // without default arguments.
Index: contrib/llvm/tools/clang/lib/Sema/IdentifierResolver.cpp
===
--- contrib/llvm/tools/clang/lib/Sema/IdentifierResolver.cpp
(revision 244350)
+++ contrib/llvm/tools/clang/lib/Sema/IdentifierResolver.cpp(working copy)
@@ -135,16 +135,13 @@
   // of the controlled statement.
   //
   assert(S-getParent()  No TUScope?);
-  if (S-getFlags()  Scope::FnTryScope)
-return S-getParent()-isDeclScope(D);
   if (S-getParent()-getFlags()  Scope::ControlScope) {
-if (S-getParent()-getFlags()  Scope::FnCatchScope) {
-  S = S-getParent();
-  if (S-isDeclScope(D))
-return true;
-}
+S = S-getParent();
+if (S-isDeclScope(D))
+  return true;
+  }
+  if (S-getFlags()  Scope::FnTryCatchScope)
 return S-getParent()-isDeclScope(D);
-  }
 }
 return false;
   }
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))

2012-12-17 Thread Hugo Silva

On 12/01/12 15:15, Robert Watson wrote:
 
 Dear all:
 
 I've now committed the build glue required to install the recently
 merged Audit Distribution Daemon (auditdistd) contributed by the Pawel
 Dawidek, and sponsored by the FreeBSD Foundation.  This allows
 individual hosts generating audit trails to submit trails to a central
 audit server for review and safe keeping.  Part of the goal is to ensure
 that a host submitting trail data can't later modify the trails.  Pawel
 uses a variety of useful security- and resilience-related features such
 as TLS, Capsicum, etc, in auditdistd.  As the recent security incident
 in the FreeBSD.org cluster illustrated, having reliable and detailed
 audit trails makes a big difference in forensic work, and hopefully this
 will allow the FreeBSD Project (and our users) to do that better in the
 future.
 
 Robert N M Watson
 Computer Laboratory
 University of Cambridge


Wonderful! Personally I think this is a very worthy addition to the
project and I would like to congratulate and thank everyone involved in
this work.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Problem booting FreeBSD 10-CURRENT from my MacBook Pro: Can't load kernel

2012-12-17 Thread Anders Bolt-Evensen


Update:
I said:
I can work around the problem by copying /boot from the FreeBSD 9
installer
to my new FreeBSD 10 system, but I do believe this is not the right
solution? And when I then boot off the system, I get a lot of other system
errors.


It appeared that those other errors occurred because I forgot to copy the
kernel for FreeBSD 10 into the boot directory I copied from the FreeBSD 9
installer.

However, du any of you have any solution how to get rid of the Can't load
kernel error without booting off the FreeBSD 9 installer and copy the
boot directory?

Once again, any help would be appreciated.
-Anders

On 17.12.2012 09:10, Anders Bolt-Evensen andersb...@icloud.com wrote:

Hi, everyone and good morning! To make a long story short I'm attempting
to
install 10-CURRENT on my 2011 model 17 inch MacBook Pro. I downloaded the
appropriate amd64 image from FreeBSD's FTP site, burned it out to DVD and
installed it on my old FreeBSD 9 partition, erasing existing data.
However,
when I try to boot the new system, I get a can't load kernel error.
Giving
the command ls returns the message Open '/' failed: no such file or
directory. 
When I type lsdev the following is returned:
cd devices:
disk devices:
disk0: BIOS drive C
pxe devices:
I can work around the problem by copying /boot from the FreeBSD 9
installer
to my new FreeBSD 10 system, but I do believe this is not the right
solution? And when I then boot off the system, I get a lot of other system
errors. 
PS: my Mac does not have a real BIOS, so changing any BIOS settings is
unfortunately not an option.

I hope you can help me out and thanks in advance.

Have a great day, everyone!
Best wishes, 
Anders


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: clang compiled kernel panic when mounting zfs root on i386

2012-12-17 Thread Volodymyr Kostyrko


13.12.2012 12:25, Andriy Gapon:

on 12/12/2012 21:35 Dimitry Andric said the following:

Especially the recursive spa_load and traverse_visitbp calls are scary,
because that can grow out of hand very quickly.  It is probably tricky
to remove the recursion...


Re-entering spa_load once is normal and is expected.
traverse_visitbp is also expected to recurse depending on data layout.
So yeah, it's probably even trickier than teaching clang to allocate smaller 
stack
frames ;-)


I hit this one again, but this time my world and kernel are compiled 
with stock gcc. Pictures 3 to 5:


https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault

This happens on mounting root after unclean shutdown. I fixed my pool 
with booting amd64 kernel, after this i386 kernel starts fine.


Maybe it's just time to accept that ZFS on i386 is not stable? Current 
handbook elaborates on ZFS like it's known to work on i386.


--
Sphinx of black quartz, judge my vow.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: VirtIO in GENERIC

2012-12-17 Thread Bryan Venteicher

On Mon, Dec 17, 2012 at 12:06 AM, Andrew Thompson thom...@freebsd.org wrote:
 On 17 December 2012 18:06, Jim Harris jimhar...@freebsd.org wrote:



 On Sun, Dec 16, 2012 at 6:53 PM, Andrew Thompson thom...@freebsd.org
 wrote:

 On 17 December 2012 13:17, Bryan Venteicher bry...@freebsd.org wrote:

  There's been lots of requests to have VirtIO in GENERIC for i386 and
  amd64. Anybody have any issues or concerns with this or the patch at
  [1]. This also removes the kludge that was introduced in r239009.
 
  I've compiled LINT for i386 and amd64 so hopefully there won't be any
  surprise breakages.
 
  [1] http://people.freebsd.org/~bryanv/patches/virtio.generic.patch


 It would be great to have the drivers enabled. You do not need the
 sys/conf/files changes, the common and arch files are combined.


 Removing the virtio files from sys/conf/files ensures these drivers can
 only be specified in x86 kernel configuration files.  r239009 added these
 lines to sys/conf/files, but Bryan's patch does it more correctly.



Yes, I think the patch is correct for what I intended - support for
x86 only (for now).

 Linux supports virtio on ARM so I dont think its necessarily x86 MD. I guess
 it can be moved back later.


I think VirtIO on ARM (on QEMU) effectively requires VirtIO-MMIO,
which we don't support yet. And virtio_pci is probably missing some
bus_space_barriers() required for non-x86. Both are on my TODO, but
nobody has prodded me about either yet.


 Andrew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: X on ThinkPad X220 with chrome or firefox goes blank

2012-12-17 Thread Erich Dollansky

Hi,

On Mon, 17 Dec 2012 11:44:59 +0200
Artyom Mirgorodskiy artyom.mirgorod...@gmail.com wrote:

 Did you try to rebuild xorg-server with latest clang patch? (this
 patch commited 2-3 days ago)

it seems that my X server was a bit too old. I just upgraded and all
works fine now?

Thanks!

Erich
 
 On Monday 17 December 2012 08:40:37 Erich Dollansky wrote:
  Hi,
  
  I updated my notebook over the last couple of days and have now
  problems starting chrome and firefox. The effect is that the screen
  turns blury leaving hard to recognose characters on a white screen
  after starting any of these applications.
  
  I can use Ctrl-Alt-F2 to come back to the terminal. Of course, this
  is now a flight in the dark. After entering Ctrl-C and restart X, I
  get a new X running until I start firefox or chrome again.
  
  Applications like Claws Mail, Arora or xterm work without problems.
  
  I do not see anything different in the log file of X.
  
  Does anybody have a clue what could cause this?
  
  I will recompile and reinstall all my ports now to see what will
  come out there.
  
  Erich
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to
  freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

calloutng and dummynet (Re: [RFC/RFT] calloutng)

On Mon, Dec 17, 2012 at 10:14:29AM +0200, Alexander Motin wrote:
 On 17.12.2012 05:38, Adrian Chadd wrote:
...
 Maybe hit up the altq/pf using crowd and see if they'll test this stuff 
 out too?
 
 It would be good to test, though I know that at least dummynet is 
 written awful from the point of this project with its
   callout_reset(dn_timeout, 1, dummynet, NULL);
 It should work, but kill most of power benefits. I was promised it will 
 be fixed after this project end.

never trust italians :)

but it is good that you are reminding me this, hopefully
i will be able to give it a shot after the holidays

cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng

[addressing the various items separately]

On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote:
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
...
- for several functions the only change is the name of an argument
from busy to us. Can you elaborate the reason for the change,
and whether us means microseconds or the pronoun ?)

Please see r242905 by mav@.

i see the goal of this patch is to pass along the amount of
time till the next timer.

I wonder why the choice is to use (actually, call) the value
microseconds rather use a bintime or something scaled and with a
well defined resolution.

In fact looking at the relevant diff

http://svnweb.freebsd.org/base/projects/calloutng/sys/kern/kern_clocksource.c?r1=242905r2=242904pathrev=242905

cpu_idleclock() actually returns a value that is not even microseconds
but 1/(2^20) seconds. The value seems to be ignored right now
so it would be a good time to discuss the resolution.

I am concerned that at some point (5 years from now perhaps ?)
microseconds might start to become too coarse and we would like
something with a more fine-grained resolution. On the
other hand, for the purposes of this change, we can probably
live with an upper limit of some seconds (waking up the machine
once per second is not going to kill performance).

So i would suggest to make the argument to these functions
uint_32 or uint_64 (preferably the same for 32- and 64-bit machines),
rename it to something different from 'us'
and have at least 28-30 fractional bits to represent a bintime.

Right now you are using a bintime with 20 fractional and 11 or 43
bits for the integer part.

cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng


Hi.

 I wonder why the choice is to use (actually, call) the value
 microseconds rather use a bintime or something scaled and with a
 well defined resolution.

It was kind of engineering choice. I've chosen microseconds, following 
values used by ACPI to represent CPU sleep states exit latencies.  Now 
that is the only usage for that value.  If CPUs so much reduce wakeup 
latencies to make this scale too coarse, this type will be the smallest 
of our optimization tasks. On the other side, I have some doubts that we 
will be able to reach supported 2048 seconds limit on the integer side. 
Now even completely empty idle system has about 30 interrupts per 
second, that is far from 0.0005. From the other side, I don't know any 
system where CPUs have 2048 seconds wakeup latency.


--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

API explosion (Re: [RFC/RFT] calloutng)

[again, response to another issue i raised]

On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote:
 On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
...
  Finally, a more substantial comment:
  - a lot of functions which formerly had only a timo argument
now have timo, bt, precision, flags. Take seltdwait() as an example.
 
 
 seltdwait() is not part of the public KPI. It has been modified to
 avoid code duplication. Having seltdwait() and seltdwait_bt(), i.e.
 two separate functions, even though we could share most of the code is
 not a clever approach, IMHO.
 As I told before, seltdwait() is not exposed so we can modify its
 argument without breaking anything.
 
It seems that you have been undecided between two approaches:
for some of these functions you have preserved the original function
that deals with ticks and introduced a new one that deals with the
  bintime,
whereas in other cases you have modified the original function to add
bt, precision, flags.
 
 
 I'm not. All the functions which are part of the public KPI (e.g.
 condvar(9), sleepq(9), *) are still available.  *_flags variants have
 been introduced so that consumers can take advantage of the new
 'precision tolerance mechanism' implemented. Also, *_bt variants have
 been introduced. I don't see any undecision between the two
 approaches.
 Please note that now the callout backend deals with bintime, so every
 time callout_reset_on() is called, the 'tick' argument passed is
 silently converted to bintime.

I will try to give more specific example, using the latest patch
from mav

http://people.freebsd.org/~mav/calloutng_12_16.patch

In the manpage, for instance, the existing functions
now are extended with two more variants (sometimes;
msleep_spin() for instance is missing msleep_spin_bt()
but perhaps that is just an oversight).

 .Nm sleepq_set_timeout ,
+.Nm sleepq_set_timeout_flags ,
+.Nm sleepq_set_timeout_bt ,

 .Nm msleep ,
+.Nm msleep_flags ,
+.Nm msleep_bt ,
 .Nm msleep_spin ,
+.Nm msleep_spin_flags ,
 .Nm pause ,
+.Nm pause_flags ,
+.Nm pause_bt ,
 .Nm tsleep ,
+.Nm tsleep_flags ,
+.Nm tsleep_bt ,

 .Nm cv_timedwait ,
+.Nm cv_timedwait_bt ,
+.Nm cv_timedwait_flags ,
 .Nm cv_timedwait_sig ,
+.Nm cv_timedwait_sig_bt ,
+.Nm cv_timedwait_sig_flags ,

 .Nm callout_reset ,
+.Nm callout_reset_flags ,
 .Nm callout_reset_on ,
+.Nm callout_reset_flags_on ,
+.Nm callout_reset_bt_on ,

If you look at the backends, they take both a timo and a bintime.

-int_cv_timedwait(struct cv *cvp, struct lock_object *lock, int 
timo);
-int_cv_timedwait_sig(struct cv *cvp, struct lock_object *lock, int 
timo);
+int_cv_timedwait(struct cv *cvp, struct lock_object *lock,
+   struct bintime *bt, struct bintime *precision, int timo,
+   int flags);
+int_cv_timedwait_sig(struct cv *cvp, struct lock_object *lock,
+   struct bintime *bt, struct bintime *precision, int timo,
+   int flags);

and then internally they call the 'timo' or the 'bt' version
depending on the case

+   if (bt == NULL)
+   sleepq_set_timeout_flags(cvp, timo, flags);
+   else
+   sleepq_set_timeout_bt(cvp, bt, precision);

So basically you are doing the following:
   + create two new variant for each existing function

foo(, ... timo, ... )   old method
foo_flags(, ... timo, ... ) new method
foo_bt(... , bt, precision, ...)new method

 (the 'API explosion' i am mentioning in the Subject)

   + the variants are mapped to the same internal function
_foo_internal(..., timo, bt, precision, flags, ...)

   + and then the internal function has a (runtime) conditional

if (bt == NULL) {
// convert timo to bt
} else {
// have a bt + precision
}
...

I would instead do the following:

+ create a new API function that takes only bintime+precision+flags, no ticks.
  I am not sure if there is even a need to have an internal name
_cv_timedwait_sig(  )
  or you can just have
cv_timedwait_sig_bt(...)

+ use a macro or an inline function to remap the old API to
  the (single) new one, making the argument conversion immediately.
#define cv_timedwait_sig(...)   cv_timedwait_sig_bt( ...)

  This has the advantage that conversions might be done at compile
  time perhaps with some advantage in terms of code and performance.

+ do not bother creating yet another cv_timedwait_sig_flags() function.
  Since it did not exist before, you have to do the conversion manually
  anyways, at which point you just change the argument to use bintime
  instead of ticks.

Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng

2012-12-17 Thread Davide Italiano

On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
[addressing the various items separately]

Please see r242905 by mav@.

i see the goal of this patch is to pass along the amount of
time till the next timer.

I wonder why the choice is to use (actually, call) the value
microseconds rather use a bintime or something scaled and with a
well defined resolution.

In fact looking at the relevant diff

http://svnweb.freebsd.org/base/projects/calloutng/sys/kern/kern_clocksource.c?r1=242905r2=242904pathrev=242905

cpu_idleclock() actually returns a value that is not even microseconds
but 1/(2^20) seconds. The value seems to be ignored right now
so it would be a good time to discuss the resolution.

I would talk more about power consumption problem rather than performances.
Yes, you're right because now, even with calloutng changes, the CPU is
woken up at least twice per second.
The wheel scan, in case it doesn't find a new callout to schedule in
the next half-second, schedules an interrupt half a second from now
(where now is the time obtained using getbinuptime()/binuptime()).
This is a threshold we set up empirically, and it resulted is good
for now. But in the future someone may raise the threshold to 1
second, 10 seconds, or something like. So, I don't agree with your
statement.

Right now you are using a bintime with 20 fractional and 11 or 43
bits for the integer part.

cheers
luigi

Thanks

Davide
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: API explosion (Re: [RFC/RFT] calloutng)


Hi.

 I would instead do the following:

I also don't very like the wide API and want to hear fresh ideas, but 
approaches to time measurement there are too different to do what you 
are proposing.  Main problem is that while ticks value is relative, 
bintime is absolute. It is not easy to make conversion between them fast 
and precise. I've managed to do it, but the only function that does it 
now is _callout_reset_on(). All other functions are just passing values 
down. I am not sure I want to duplicate that code in each place, though 
doing it at least for for callout may be a good idea.


Creating sets of three functions I had three different goals:
 - callout_reset() -- it is legacy variant required to keep API 
compatibility;
 - callout_reset_flags() -- it is for cases where custom precision 
specification needs to be added to the existing code, or where direct 
callout execution is needed. Conversion to bintime would additionally 
complicate consumer code, that I would try to avoid.
 - callout_reset_bt() -- API for the new code, which needs high 
precision and doesn't mind to operate bintime. Now there is only three 
such places in kernel now, and I don't think there will be much more.


Respectively, these three options are replicated to other APIs where 
time intervals are used.


PS: Please keep me in CC.

--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng

On Mon, Dec 17, 2012 at 12:17:54PM -0800, Davide Italiano wrote:
On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
[addressing the various items separately]

Please see r242905 by mav@.

i see the goal of this patch is to pass along the amount of
time till the next timer.

I wonder why the choice is to use (actually, call) the value
microseconds rather use a bintime or something scaled and with a
well defined resolution.

In fact looking at the relevant diff

http://svnweb.freebsd.org/base/projects/calloutng/sys/kern/kern_clocksource.c?r1=242905r2=242904pathrev=242905

cpu_idleclock() actually returns a value that is not even microseconds
but 1/(2^20) seconds. The value seems to be ignored right now
so it would be a good time to discuss the resolution.

this is only an issue if we want to use 32 bits.
If we go to 64 bits, there is enogh space for picoseconds
on the fractional part, and a few years in the integer part.
but keep in mind, even powerwise, i doubt the exit from deep
sleep and a callout takes more than 500us so even doing that
once per second gives less than 0.5 per mille increase in
power compared to a machine that is always idle

This is really noise that we should not worry about.

cheers
luigi
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng

2012-12-17 Thread Adrian Chadd

Personally, I'd rather see some consistently used units here..



Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng

2012-12-17 Thread Poul-Henning Kamp


In message 50cf79ad.9040...@freebsd.org, Alexander Motin writes:
Hi.

  I wonder why the choice is to use (actually, call) the value
  microseconds rather use a bintime or something scaled and with a
  well defined resolution.

It was kind of engineering choice. I've chosen microseconds [...]

And that was the wrong choice, the format should be a binary number
so arithmetic and comparisons does not become a nightmare.

If people need milliseconds or microseconds, they can get that
using suitable #defined multiplication factors.

A 64 bit type, with 32bit before and after the binary point would
be sufficient for now, and easily extensible to something larger
should one or more laws of computing nature be changed.

So do the following:

typedef dur_t   int64_t;/* signed for bug catching */
#define DURSEC  ((dur_t)1  32)
#define DURMIN  (DURSEC * 60)
#define DURMSEC (DURSEC / 1000)
#define DURUSEC (DURSEC / 1000)
#define DURNSEC (DURSEC / 1000)

And stop crapping around with mixed-radix numbers, even the british
changed to decimal coinage to avoid that crap...


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: clang compiled kernel panic when mounting zfs root on i386

2012-12-17 Thread Andriy Gapon

on 17/12/2012 14:57 Volodymyr Kostyrko said the following:
 13.12.2012 12:25, Andriy Gapon:
 on 12/12/2012 21:35 Dimitry Andric said the following:
 Especially the recursive spa_load and traverse_visitbp calls are scary,
 because that can grow out of hand very quickly.  It is probably tricky
 to remove the recursion...

 Re-entering spa_load once is normal and is expected.
 traverse_visitbp is also expected to recurse depending on data layout.
 So yeah, it's probably even trickier than teaching clang to allocate smaller
 stack
 frames ;-)
 
 I hit this one again, but this time my world and kernel are compiled with 
 stock
 gcc. Pictures 3 to 5:
 
 https://picasaweb.google.com/104021007361271711472/I386ZfsDoubleFault
 
 This happens on mounting root after unclean shutdown. I fixed my pool with
 booting amd64 kernel, after this i386 kernel starts fine.
 
 Maybe it's just time to accept that ZFS on i386 is not stable? Current 
 handbook
 elaborates on ZFS like it's known to work on i386.

Yes, it is known to work.

It's been already mentioned many times that ZFS works much better on amd64.
It's up to a (potential) user to understand limitations of i386 and to decide
whether to use ZFS, in what situations and how.

You may want to consider using KSTACK_PAGES=4 in your kernel configuration.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC/RFT] calloutng

2012-12-17 Thread David O'Brien

On Sat, Dec 15, 2012 at 11:13:26PM +0200, Alexander Motin wrote:
 On 15.12.2012 23:03, Alexander Motin wrote:
  Sorry, it's my fault. I've tried to save some time on patch generation
  and forgot about that change in lib/. We haven't touched user-level in
  our work except that file. Here is patch with that chunk added:
  http://people.freebsd.org/~mav/calloutng_12_15_1.patch
 
 And one more part I've missed is manual pages update, that probably 
 needs more improvements:
 http://people.freebsd.org/~mav/calloutng_12_15.man.patch

Perhaps use the SCM at what its good at?

Sync your branch with HEAD and then do an 'svn diff ^/head' and your
branch.

-- 
-- David  (obr...@freebsd.org)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [RFC/RFT] calloutng

2012-12-17 Thread Davide Italiano

On Mon, Dec 17, 2012 at 2:39 PM, David O'Brien obr...@freebsd.org wrote:
 On Sat, Dec 15, 2012 at 11:13:26PM +0200, Alexander Motin wrote:
 On 15.12.2012 23:03, Alexander Motin wrote:
  Sorry, it's my fault. I've tried to save some time on patch generation
  and forgot about that change in lib/. We haven't touched user-level in
  our work except that file. Here is patch with that chunk added:
  http://people.freebsd.org/~mav/calloutng_12_15_1.patch

 And one more part I've missed is manual pages update, that probably
 needs more improvements:
 http://people.freebsd.org/~mav/calloutng_12_15.man.patch

 Perhaps use the SCM at what its good at?

 Sync your branch with HEAD and then do an 'svn diff ^/head' and your
 branch.

 --
 -- David  (obr...@freebsd.org)

Last time I tried doing that the way you describe, I got an output
with tons svn:mergeinfo and I didn't find a way to suppress them if
not manually.
e.g.

Property changes on: usr.bin/procstat
___
Modified: svn:mergeinfo
   Merged /head/usr.bin/procstat:r236314-239017
Index: usr.bin/calendar
===
--- usr.bin/calendar(.../head)  (revision 239166)
+++ usr.bin/calendar(.../projects/calloutng)(revision 239166)


Can you help me in understanding what I did wrong?

Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[head tinderbox] failure on arm/arm

TB --- 2012-12-17 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-12-17 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-12-17 22:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2012-12-17 22:40:00 - cleaning the object tree
TB --- 2012-12-17 22:40:00 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-12-17 22:40:00 - cd /tinderbox/HEAD/arm/arm
TB --- 2012-12-17 22:40:00 - /usr/local/bin/svn cleanup /src
TB --- 2012-12-17 22:44:18 - /usr/local/bin/svn update /src
TB --- 2012-12-17 22:44:28 - At svn revision 244368
TB --- 2012-12-17 22:44:29 - building world
TB --- 2012-12-17 22:44:29 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-17 22:44:29 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-17 22:44:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-17 22:44:29 - SRCCONF=/dev/null
TB --- 2012-12-17 22:44:29 - TARGET=arm
TB --- 2012-12-17 22:44:29 - TARGET_ARCH=arm
TB --- 2012-12-17 22:44:29 - TZ=UTC
TB --- 2012-12-17 22:44:29 - __MAKE_CONF=/dev/null
TB --- 2012-12-17 22:44:29 - cd /src
TB --- 2012-12-17 22:44:29 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Mon Dec 17 22:44:39 UTC 2012
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 World build completed on Mon Dec 17 23:43:03 UTC 2012
TB --- 2012-12-17 23:43:03 - generating LINT kernel config
TB --- 2012-12-17 23:43:03 - cd /src/sys/arm/conf
TB --- 2012-12-17 23:43:03 - /usr/bin/make -B LINT
TB --- 2012-12-17 23:43:03 - cd /src/sys/arm/conf
TB --- 2012-12-17 23:43:03 - /usr/sbin/config -m LINT
TB --- 2012-12-17 23:43:03 - building LINT kernel
TB --- 2012-12-17 23:43:03 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-17 23:43:03 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-17 23:43:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-17 23:43:03 - SRCCONF=/dev/null
TB --- 2012-12-17 23:43:03 - TARGET=arm
TB --- 2012-12-17 23:43:03 - TARGET_ARCH=arm
TB --- 2012-12-17 23:43:03 - TZ=UTC
TB --- 2012-12-17 23:43:03 - __MAKE_CONF=/dev/null
TB --- 2012-12-17 23:43:03 - cd /src
TB --- 2012-12-17 23:43:03 - /usr/bin/make -B buildkernel KERNCONF=LINT
 Kernel build for LINT started on Mon Dec 17 23:43:03 UTC 2012
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT completed on Tue Dec 18 00:03:19 UTC 2012
TB --- 2012-12-18 00:03:19 - cd /src/sys/arm/conf
TB --- 2012-12-18 00:03:19 - /usr/sbin/config -m AC100
TB --- 2012-12-18 00:03:19 - skipping AC100 kernel
TB --- 2012-12-18 00:03:19 - cd /src/sys/arm/conf
TB --- 2012-12-18 00:03:19 - /usr/sbin/config -m ARMADAXP
TB --- 2012-12-18 00:03:19 - skipping ARMADAXP kernel
TB --- 2012-12-18 00:03:19 - cd /src/sys/arm/conf
TB --- 2012-12-18 00:03:19 - /usr/sbin/config -m ATMEL
TB --- 2012-12-18 00:03:19 - building ATMEL kernel
TB --- 2012-12-18 00:03:19 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 00:03:19 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 00:03:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 00:03:19 - SRCCONF=/dev/null
TB --- 2012-12-18 00:03:19 - TARGET=arm
TB --- 2012-12-18 00:03:19 - TARGET_ARCH=arm
TB --- 2012-12-18 00:03:19 - TZ=UTC
TB --- 2012-12-18 00:03:19 - __MAKE_CONF=/dev/null
TB --- 2012-12-18 00:03:19 - cd /src
TB --- 2012-12-18 00:03:19 - /usr/bin/make -B buildkernel KERNCONF=ATMEL
 Kernel build for ATMEL started on Tue Dec 18 00:03:19 UTC 2012
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for ATMEL completed on Tue Dec 18 00:07:13 UTC 2012
TB --- 2012-12-18 00:07:13 - cd /src/sys/arm/conf
TB --- 2012-12-18 00:07:13 - /usr/sbin/config -m AVILA
TB --- 2012-12-18 00:07:13 - skipping AVILA kernel
TB --- 2012-12-18 00:07:13 - cd /src/sys/arm/conf
TB --- 2012-12-18 00:07:13 - /usr/sbin/config -m BEAGLEBONE
TB --- 2012-12-18 00:07:14 - skipping BEAGLEBONE kernel
TB --- 2012-12-18 00:07:14 - cd /src/sys/arm/conf
TB --- 2012-12-18 00:07:14 - /usr/sbin/config -m BWCT
TB --- 2012-12-18 00:07:14 - building BWCT kernel
TB --- 2012-12-18 00:07:14 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 00:07:14 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 00:07:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 00:07:14 - SRCCONF=/dev/null
TB --- 2012-12-18 00:07:14 - TARGET=arm
TB --- 2012-12-18 00:07:14 - TARGET_ARCH=arm
TB --- 2012-12-18 00:07:14 -

[head tinderbox] failure on i386/i386

TB --- 2012-12-17 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-12-17 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-12-17 22:40:00 - starting HEAD tinderbox run for i386/i386
TB --- 2012-12-17 22:40:00 - cleaning the object tree
TB --- 2012-12-17 22:40:00 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-12-17 22:40:00 - cd /tinderbox/HEAD/i386/i386
TB --- 2012-12-17 22:40:00 - /usr/local/bin/svn cleanup /src
TB --- 2012-12-17 22:43:33 - /usr/local/bin/svn update /src
TB --- 2012-12-17 22:43:44 - At svn revision 244368
TB --- 2012-12-17 22:43:45 - building world
TB --- 2012-12-17 22:43:45 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-17 22:43:45 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-17 22:43:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-17 22:43:45 - SRCCONF=/dev/null
TB --- 2012-12-17 22:43:45 - TARGET=i386
TB --- 2012-12-17 22:43:45 - TARGET_ARCH=i386
TB --- 2012-12-17 22:43:45 - TZ=UTC
TB --- 2012-12-17 22:43:45 - __MAKE_CONF=/dev/null
TB --- 2012-12-17 22:43:45 - cd /src
TB --- 2012-12-17 22:43:45 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Mon Dec 17 22:43:54 UTC 2012
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 World build completed on Tue Dec 18 01:59:32 UTC 2012
TB --- 2012-12-18 01:59:32 - generating LINT kernel config
TB --- 2012-12-18 01:59:32 - cd /src/sys/i386/conf
TB --- 2012-12-18 01:59:32 - /usr/bin/make -B LINT
TB --- 2012-12-18 01:59:32 - cd /src/sys/i386/conf
TB --- 2012-12-18 01:59:32 - /usr/sbin/config -m LINT
TB --- 2012-12-18 01:59:32 - building LINT kernel
TB --- 2012-12-18 01:59:32 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 01:59:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 01:59:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 01:59:32 - SRCCONF=/dev/null
TB --- 2012-12-18 01:59:32 - TARGET=i386
TB --- 2012-12-18 01:59:32 - TARGET_ARCH=i386
TB --- 2012-12-18 01:59:32 - TZ=UTC
TB --- 2012-12-18 01:59:32 - __MAKE_CONF=/dev/null
TB --- 2012-12-18 01:59:32 - cd /src
TB --- 2012-12-18 01:59:32 - /usr/bin/make -B buildkernel KERNCONF=LINT
 Kernel build for LINT started on Tue Dec 18 01:59:32 UTC 2012
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT completed on Tue Dec 18 02:32:52 UTC 2012
TB --- 2012-12-18 02:32:52 - cd /src/sys/i386/conf
TB --- 2012-12-18 02:32:52 - /usr/sbin/config -m LINT-NOINET
TB --- 2012-12-18 02:32:52 - building LINT-NOINET kernel
TB --- 2012-12-18 02:32:52 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 02:32:52 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 02:32:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 02:32:52 - SRCCONF=/dev/null
TB --- 2012-12-18 02:32:52 - TARGET=i386
TB --- 2012-12-18 02:32:52 - TARGET_ARCH=i386
TB --- 2012-12-18 02:32:52 - TZ=UTC
TB --- 2012-12-18 02:32:52 - __MAKE_CONF=/dev/null
TB --- 2012-12-18 02:32:52 - cd /src
TB --- 2012-12-18 02:32:52 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
 Kernel build for LINT-NOINET started on Tue Dec 18 02:32:52 UTC 2012
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT-NOINET completed on Tue Dec 18 03:03:09 UTC 2012
TB --- 2012-12-18 03:03:09 - cd /src/sys/i386/conf
TB --- 2012-12-18 03:03:09 - /usr/sbin/config -m LINT-NOINET6
TB --- 2012-12-18 03:03:09 - building LINT-NOINET6 kernel
TB --- 2012-12-18 03:03:09 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 03:03:09 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 03:03:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 03:03:09 - SRCCONF=/dev/null
TB --- 2012-12-18 03:03:09 - TARGET=i386
TB --- 2012-12-18 03:03:09 - TARGET_ARCH=i386
TB --- 2012-12-18 03:03:09 - TZ=UTC
TB --- 2012-12-18 03:03:09 - __MAKE_CONF=/dev/null
TB --- 2012-12-18 03:03:09 - cd /src
TB --- 2012-12-18 03:03:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
 Kernel build for LINT-NOINET6 started on Tue Dec 18 03:03:09 UTC 2012
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes

[head tinderbox] failure on amd64/amd64

TB --- 2012-12-17 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-12-17 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-12-17 22:40:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2012-12-17 22:40:00 - cleaning the object tree
TB --- 2012-12-17 22:40:00 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-12-17 22:40:00 - cd /tinderbox/HEAD/amd64/amd64
TB --- 2012-12-17 22:40:00 - /usr/local/bin/svn cleanup /src
TB --- 2012-12-17 22:43:54 - /usr/local/bin/svn update /src
TB --- 2012-12-17 22:44:06 - At svn revision 244368
TB --- 2012-12-17 22:44:07 - building world
TB --- 2012-12-17 22:44:07 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-17 22:44:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-17 22:44:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-17 22:44:07 - SRCCONF=/dev/null
TB --- 2012-12-17 22:44:07 - TARGET=amd64
TB --- 2012-12-17 22:44:07 - TARGET_ARCH=amd64
TB --- 2012-12-17 22:44:07 - TZ=UTC
TB --- 2012-12-17 22:44:07 - __MAKE_CONF=/dev/null
TB --- 2012-12-17 22:44:07 - cd /src
TB --- 2012-12-17 22:44:07 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Mon Dec 17 22:44:15 UTC 2012
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 stage 5.1: building 32 bit shim libraries
 World build completed on Tue Dec 18 02:36:46 UTC 2012
TB --- 2012-12-18 02:36:46 - generating LINT kernel config
TB --- 2012-12-18 02:36:46 - cd /src/sys/amd64/conf
TB --- 2012-12-18 02:36:46 - /usr/bin/make -B LINT
TB --- 2012-12-18 02:36:46 - cd /src/sys/amd64/conf
TB --- 2012-12-18 02:36:46 - /usr/sbin/config -m LINT
TB --- 2012-12-18 02:36:46 - building LINT kernel
TB --- 2012-12-18 02:36:46 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 02:36:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 02:36:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 02:36:46 - SRCCONF=/dev/null
TB --- 2012-12-18 02:36:46 - TARGET=amd64
TB --- 2012-12-18 02:36:46 - TARGET_ARCH=amd64
TB --- 2012-12-18 02:36:46 - TZ=UTC
TB --- 2012-12-18 02:36:46 - __MAKE_CONF=/dev/null
TB --- 2012-12-18 02:36:46 - cd /src
TB --- 2012-12-18 02:36:46 - /usr/bin/make -B buildkernel KERNCONF=LINT
 Kernel build for LINT started on Tue Dec 18 02:36:47 UTC 2012
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT completed on Tue Dec 18 03:09:12 UTC 2012
TB --- 2012-12-18 03:09:12 - cd /src/sys/amd64/conf
TB --- 2012-12-18 03:09:12 - /usr/sbin/config -m LINT-NOINET
TB --- 2012-12-18 03:09:12 - building LINT-NOINET kernel
TB --- 2012-12-18 03:09:12 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 03:09:12 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 03:09:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 03:09:12 - SRCCONF=/dev/null
TB --- 2012-12-18 03:09:12 - TARGET=amd64
TB --- 2012-12-18 03:09:12 - TARGET_ARCH=amd64
TB --- 2012-12-18 03:09:12 - TZ=UTC
TB --- 2012-12-18 03:09:12 - __MAKE_CONF=/dev/null
TB --- 2012-12-18 03:09:12 - cd /src
TB --- 2012-12-18 03:09:12 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
 Kernel build for LINT-NOINET started on Tue Dec 18 03:09:13 UTC 2012
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
 Kernel build for LINT-NOINET completed on Tue Dec 18 03:39:09 UTC 2012
TB --- 2012-12-18 03:39:09 - cd /src/sys/amd64/conf
TB --- 2012-12-18 03:39:09 - /usr/sbin/config -m LINT-NOINET6
TB --- 2012-12-18 03:39:09 - building LINT-NOINET6 kernel
TB --- 2012-12-18 03:39:09 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 03:39:09 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 03:39:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 03:39:09 - SRCCONF=/dev/null
TB --- 2012-12-18 03:39:09 - TARGET=amd64
TB --- 2012-12-18 03:39:09 - TARGET_ARCH=amd64
TB --- 2012-12-18 03:39:09 - TZ=UTC
TB --- 2012-12-18 03:39:09 - __MAKE_CONF=/dev/null
TB --- 2012-12-18 03:39:09 - cd /src
TB --- 2012-12-18 03:39:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
 Kernel build for LINT-NOINET6 started on Tue Dec 18 03:39:09 UTC 2012
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls

[head tinderbox] failure on mips/mips

TB --- 2012-12-18 02:48:50 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-12-18 02:48:50 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-12-18 02:48:50 - starting HEAD tinderbox run for mips/mips
TB --- 2012-12-18 02:48:50 - cleaning the object tree
TB --- 2012-12-18 02:48:50 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-12-18 02:48:50 - cd /tinderbox/HEAD/mips/mips
TB --- 2012-12-18 02:48:50 - /usr/local/bin/svn cleanup /src
TB --- 2012-12-18 02:49:55 - /usr/local/bin/svn update /src
TB --- 2012-12-18 02:50:01 - At svn revision 244372
TB --- 2012-12-18 02:50:02 - building world
TB --- 2012-12-18 02:50:02 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 02:50:02 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 02:50:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 02:50:02 - SRCCONF=/dev/null
TB --- 2012-12-18 02:50:02 - TARGET=mips
TB --- 2012-12-18 02:50:02 - TARGET_ARCH=mips
TB --- 2012-12-18 02:50:02 - TZ=UTC
TB --- 2012-12-18 02:50:02 - __MAKE_CONF=/dev/null
TB --- 2012-12-18 02:50:02 - cd /src
TB --- 2012-12-18 02:50:02 - /usr/bin/make -B buildworld
 Building an up-to-date make(1)
 World build started on Tue Dec 18 02:50:10 UTC 2012
 Rebuilding the temporary build tree
 stage 1.1: legacy release compatibility shims
 stage 1.2: bootstrap tools
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3: cross tools
 stage 4.1: building includes
 stage 4.2: building libraries
 stage 4.3: make dependencies
 stage 4.4: building everything
 World build completed on Tue Dec 18 03:57:41 UTC 2012
TB --- 2012-12-18 03:57:41 - cd /src/sys/mips/conf
TB --- 2012-12-18 03:57:41 - /usr/sbin/config -m ADM5120
TB --- 2012-12-18 03:57:41 - skipping ADM5120 kernel
TB --- 2012-12-18 03:57:41 - cd /src/sys/mips/conf
TB --- 2012-12-18 03:57:41 - /usr/sbin/config -m ALCHEMY
TB --- 2012-12-18 03:57:41 - skipping ALCHEMY kernel
TB --- 2012-12-18 03:57:41 - cd /src/sys/mips/conf
TB --- 2012-12-18 03:57:41 - /usr/sbin/config -m AP91
TB --- 2012-12-18 03:57:41 - building AP91 kernel
TB --- 2012-12-18 03:57:41 - CROSS_BUILD_TESTING=YES
TB --- 2012-12-18 03:57:41 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-12-18 03:57:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-12-18 03:57:41 - SRCCONF=/dev/null
TB --- 2012-12-18 03:57:41 - TARGET=mips
TB --- 2012-12-18 03:57:41 - TARGET_ARCH=mips
TB --- 2012-12-18 03:57:41 - TZ=UTC
TB --- 2012-12-18 03:57:41 - __MAKE_CONF=/dev/null
TB --- 2012-12-18 03:57:41 - cd /src
TB --- 2012-12-18 03:57:41 - /usr/bin/make -B buildkernel KERNCONF=AP91
 Kernel build for AP91 started on Tue Dec 18 03:57:42 UTC 2012
 stage 1: configuring the kernel
 stage 2.1: cleaning up the object tree
 stage 2.2: rebuilding the object tree
 stage 2.3: build tools
 stage 3.1: making dependencies
 stage 3.2: building everything
[...]
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option   -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=768 --param inline-unit-growth=1 
--param large-function-growth=10 --param max-inline-insns-single=1  
-fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float 
-ffreestanding -Werror  /src/sys/netinet/cc/cc.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option   -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=768 --param inline-unit-growth=1 
--param large-function-growth=10 --param max-inline-insns-single=1  
-fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float 
-ffreestanding -Werror  /src/sys/netinet/cc/cc_newreno.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs 
-fdiagnostics-show-option   -nostdinc  -I. -I/src/sys -I/src/sys/contrib/altq 
-I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include 
opt_global.h -fno-common -finline-limit=768 --param inline-unit-growth=1 
--param large-function-growth=10 --param max-inline-insns-single=1  
-fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float 
-ffreestanding -Werror  /src/sys/netinet/tcp_hostcache.c

[head tinderbox] failure on mips64/mips