Re: zpool can't bring online disk2 ----I screwed up

2012-09-26 Thread Mikolaj Golub
On Sun, Sep 23, 2012 at 10:50:28PM -0700, Jose A. Lombera wrote:

 This is the error I got when I run the failover script.
 
  
 
 Sep 24 06:43:39 san1 hastd[3404]: [disk3] (primary) Provider /dev/mfid3 is 
 not part of resource disk3.
 
 Sep 24 06:43:39 san1 hastd[3343]: [disk3] (primary) Worker process exited 
 ungracefully (pid=3404, exitcode=66).
 
 Sep 24 06:43:39 san1 hastd[3413]: [disk6] (primary) Provider /dev/mfid6 is 
 not part of resource disk6.
 
 Sep 24 06:43:39 san1 hastd[3343]: [disk6] (primary) Worker process exited 
 ungracefully (pid=3413, exitcode=66).
 
 Sep 24 06:43:39 san1 hastd[3425]: [disk10] (primary) Unable to open 
 /dev/mfid10: No such file or directory.
 
 Sep 24 06:43:39 san1 hastd[3407]: [disk4] (primary) Provider /dev/mfid4 is 
 not part of resource disk4.

This looks like your disk numbering has changed? Your another email
confirms this. Then you should change it accordingly in hast.conf.

 Sep 24 06:43:40 san1 hastd[3351]: [disk2] (primary) Resource unique ID 
 mismatch (primary=2635341666474957411, secondary=5944493181984227803).
 
 Sep 24 06:43:45 san1 hastd[3348]: [disk1] (primary) Split-brain condition!
 
 Sep 24 06:43:50 san1 hastd[3351]: [disk2] (primary) Resource unique ID 
 mismatch (primary=2635341666474957411, secondary=5944493181984227803).
 
 Sep 24 06:43:55 san1 hastd[3348]: [disk1] (primary) Split-brain condition!

Split-brain can only be fixed manually, deciding what host contains
actual data and recreating HAST resources (disk1 and disk2 in this
case) on another host.

The simplest way to recover from your situation looks like the following:

Supposing that host A is a host where the disk was changed and things
messed up and host B is a good host.

1) Disable auto failovering if you have any.
2) On host A set all HAST resources to init.
3) On host B set all HAST resources to primary.
4) On host B import pool and check that it works ok here and you have
   your data.
5) On host A recreate HAST resources (hastctl create disk1...)
6) On host A change role to secondary for all HAST
   resources. A synchronization process should start.
7) Wait until the synchronization is complete, checking hastctl status on
   B (primary) host

After this you can switch the pool to the host A again if you want and
enable auto failovering.

Actually you can switch to the host A not waiting until the
synchronization is complete. It will work, but read requests will go
to the remote host B until the synchronization is complete, so I would
not do this until there are good reasons for this.

It might be possible to recover faster, without recreating/resyncing
all devices, depending on how things messed up, fixing the disk
numbering in hast.conf and recreating/resyncing only resources in
split-brain state. But it would require more manual work, careful
investigation of logs and good understanding what you are doing.

-- 
Mikolaj Golub
___
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: MPSAFE VFS -- List of upcoming actions

2012-09-26 Thread Harald Schmalzbauer
 schrieb Harald Schmalzbauer am 25.09.2012 20:24 (localtime):
  schrieb Attilio Rao am 21.09.2012 02:22 (localtime):
 On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao atti...@freebsd.org wrote:
 On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao atti...@freebsd.org wrote:
 2012/7/4 Attilio Rao atti...@freebsd.org:
 2012/6/29 Attilio Rao atti...@freebsd.org:
 As already published several times, according to the following plan:
 http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS

 I still haven't heard from Vivien or Edward, anyway as NTFS is
 basically only used RO these days (also the mount_ntfs code just
 permits RO mounting) I stripped all the uncomplete/bogus write support
 with the following patch:
 http://www.freebsd.org/~attilio/ntfs_remove_write.patch

 This is an attempt to make the code smaller and possibly just focus on
 the locking that really matter (as read-only filesystem).
 On some points of the patch I'm a bit less sure as we could easily
 take into account also write for things like vaccess() arguments, and
 make easier to re-add correct write support at some point in the
 future, but still force RO, even if the approach used in the patch is
 more correct IMHO.
 As an added bonus this patch cleans some dirty code in the mount
 operation and fixes a bug as vfs_mountedfrom() is called before real
 mounting is completed and can still fail.
 A quick update on this.
 It looks like NTFS won't be completed for this GSoC thus I seriously
 need to find an alternative to not loose the NTFS support entirely.

 I tried to look into the NTFS implementation right now and it is
 really a poor support. As Peter has also verified, it can deadlock in
 no-time, it compeltely violates VFS rules, etc. IMHO it deserves a
 complete rewrite if we would still support in-kernel NTFS. I also
 tried to look at the NetBSD implementation. Their code is someway
 similar to our, but they used very complicated (and very dirty) code
 to do the locking. Even if I don't know well enough NetBSD VFS, I have
 the impression not all the races are correctly handled. Definitively,
 not something I would like to port.

 Considering all that the only viable option would be meaning an
 userland filesystem implementation. My preferred choice would be to
 import PUFFS and librefuse on top of it but honestly it requires a lot
 of time to be completed, time which I don't currently have as in 2
 months Giant must be gone by the VFS.

 I then decided to switch to gnn's rewamp of FUSE patches. You can find
 his initial e-mail here:
 http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html

 I've precisely got the second version of George's patch and created
 this dolphin branch:
 svn://svn.freebsd.org/base/projects/fuse

 I'm fixing low hanging fruit for the moment (see r238411 for example)
 and I still have to make a throughful review.
 However my idea is to commit the support once:
 - ntfs-3g is well stress-tested and proves to be bug-free
 - there is no major/big technical issue pending after the reviews
 In the last weeks Peter, Florian, Gustau and I have been working in
 stabilizing fuse support. In the specific, Peter has worked hard on
 producing several utilities to nit stress-test fuse and in particular
 ntfs, Florian has improved fuse related ports (as explained later) and
 Gustau has done sparse testing. I feel moderately satisfied by the
 level of stability of fuse now to propose to wider usage, in
 particular given the huge amount of complaints I'm hearing around
 about occasional fuse users.

 The final target of the project is to completely import into base the
 content of fusefs-kmod starting from earlier posted patches by George.
 So far, we took care only of importing in the fuse branch the kernel
 part, so that fusefs-kmod userland part is still needed to be
 installed from ports, but I was studying the mount_fusefs licensing
 before to process with the import for the userland bits of it.

 The fixing has been happening here:
 svn://svn.freebsd.org/base/projects/fuse/

 which is essentially an HEAD branch + fuse kernel components. In order
 to get fuse, please compile a kernel from this branch with FUSE option
 or simply build and load fuse module.
 Alternatively, a kernel patch that should work with HEAD@240684 is here:
 http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch

 I guess the patch can easilly apply to all FreeBSD branches, really,
 but it is not tested to anything else different then -CURRENT.

 As said you still need currently to build fusefs-kmod port. However
 you need these further patches, to be put in the fusefs-kmod/files/
 directory::
 http://www.freebsd.org/~attilio/fuse_import/patch-Makefile
 http://www.freebsd.org/~attilio/fuse_import/patch-mount_fusefs__mount_fusefs2.c

 They both disable the old kernel building/linking and import new
 functionality to let the new kernel support work well in presence of
 many consumers.

 In addition to fusefs-kmod, Bryan and Florian have also updated
 

[PATCH] Add locking to dpt(4)

2012-09-26 Thread John Baldwin
I have patches to add locking to dpt(4) and make it MPSAFE (along with some 
other fixes).  I would appreciate any testing folks are able to do.  The 
patches are against HEAD but should apply to 8 or 9.  Please ensure you have 
INVARIANTS and INVARIANT_SUPPORT enabled for any initial testing that you do.  
Thanks!

http://www.FreeBSD.org/~jhb/patches/dpt_locking.patch

-- 
John Baldwin
___
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: r240825 -current fault with backtrace

2012-09-26 Thread Ian FREISLICH
Gleb Smirnoff wrote:
 On Sat, Sep 22, 2012 at 02:13:58PM -0400, Kim Culhan wrote:
 K serial terminal not available, backtrace is a screen pic:
 Why didn't you make dump?
 
 db call doadump

I reliably get this panic on my routers when I reboot the carp
backup.  Shortly after the syncdev: igb0 looses link, the running
sync host panics:

db bt
Tracing pid 11 tid 100123 td 0xfe000b053480
m_copym() at m_copym+0x37
ip_fragment() at ip_fragment+0x1c4
ip_output() at ip_output+0x6c1
pfsyncintr() at pfsyncintr+0xf5
intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
ithread_loop() at ithread_loop+0x9e
fork_exit() at fork_exit+0x11e
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff8463866cb0, rbp = 0 ---

My kernel dumps are however useless.  I do have serial console to
do whatever debugging we may need.

Ian

-- 
Ian Freislich
___
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: r240825 -current fault with backtrace

2012-09-26 Thread Kim Culhan
On Wed, Sep 26, 2012 at 11:36 AM, Ian FREISLICH i...@clue.co.za wrote:
 Gleb Smirnoff wrote:
 On Sat, Sep 22, 2012 at 02:13:58PM -0400, Kim Culhan wrote:
 K serial terminal not available, backtrace is a screen pic:
 Why didn't you make dump?

 db call doadump

 I reliably get this panic on my routers when I reboot the carp
 backup.  Shortly after the syncdev: igb0 looses link, the running
 sync host panics:

 db bt
 Tracing pid 11 tid 100123 td 0xfe000b053480
 m_copym() at m_copym+0x37
 ip_fragment() at ip_fragment+0x1c4
 ip_output() at ip_output+0x6c1
 pfsyncintr() at pfsyncintr+0xf5
 intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
 ithread_loop() at ithread_loop+0x9e
 fork_exit() at fork_exit+0x11e
 fork_trampoline() at fork_trampoline+0xe
 --- trap 0, rip = 0, rsp = 0xff8463866cb0, rbp = 0 ---

 My kernel dumps are however useless.  I do have serial console to
 do whatever debugging we may need.

I'm not seeing any more panics here for a couple of days, not running
carp.

-kim
___
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: [PATCH] unbreak imake build when clang set as base compiler

2012-09-26 Thread Oliver Pinter
On 9/26/12, Garrett Cooper yaneg...@gmail.com wrote:
 On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter oliver.p...@gmail.com
 wrote:
 Hi all!

 This patch fixed the problem, when buildig imake on a machine where
 clang is the base the compiler (WITH_CLANG_IS_CC).

 (Picking a random message to reply to) Why not create PRs and CC the
 relevant parties?

because I hope, there become this issue a mote attention ;)

of course, I create in near future a PR, but before that, I send an
updated patch, and yes, I know, that this is not a clean solution, but
better than nothing.


___
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: [PATCH] unbreak imake build when clang set as base compiler

2012-09-26 Thread Garrett Cooper
On Wed, Sep 26, 2012 at 2:18 PM, Oliver Pinter oliver.p...@gmail.com wrote:
 On 9/26/12, Garrett Cooper yaneg...@gmail.com wrote:
 On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter oliver.p...@gmail.com
 wrote:
 Hi all!

 This patch fixed the problem, when buildig imake on a machine where
 clang is the base the compiler (WITH_CLANG_IS_CC).

 (Picking a random message to reply to) Why not create PRs and CC the
 relevant parties?

 because I hope, there become this issue a mote attention ;)

Or gets lost in someone's mailbox :(...

 of course, I create in near future a PR, but before that, I send an
 updated patch, and yes, I know, that this is not a clean solution, but
 better than nothing.

Having a PR is better than a random email that will most likely get
lost. I would definitely respond to:

Hey $dev! I filed $PR -- can you please take a look at it? It solves
'$reason'. Thanks!

You might get better results this way too and less duplicated effort
by multiple individuals.. just sayin'...

Thanks!
-Garrett
___
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 i386/i386

2012-09-26 Thread FreeBSD Tinderbox
TB --- 2012-09-26 16:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-09-26 16:50: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-09-26 16:50:00 - starting HEAD tinderbox run for i386/i386
TB --- 2012-09-26 16:50:00 - cleaning the object tree
TB --- 2012-09-26 16:50:00 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-09-26 16:50:00 - cd /tinderbox/HEAD/i386/i386
TB --- 2012-09-26 16:50:00 - /usr/local/bin/svn cleanup /src
TB --- 2012-09-26 16:53:17 - /usr/local/bin/svn update /src
TB --- 2012-09-26 16:53:35 - At svn revision 240965
TB --- 2012-09-26 16:53:36 - building world
TB --- 2012-09-26 16:53:36 - CROSS_BUILD_TESTING=YES
TB --- 2012-09-26 16:53:36 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-09-26 16:53:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-09-26 16:53:36 - SRCCONF=/dev/null
TB --- 2012-09-26 16:53:36 - TARGET=i386
TB --- 2012-09-26 16:53:36 - TARGET_ARCH=i386
TB --- 2012-09-26 16:53:36 - TZ=UTC
TB --- 2012-09-26 16:53:36 - __MAKE_CONF=/dev/null
TB --- 2012-09-26 16:53:36 - cd /src
TB --- 2012-09-26 16:53:36 - /usr/bin/make -B buildworld
 World build started on Wed Sep 26 16:53:38 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 Wed Sep 26 19:21:31 UTC 2012
TB --- 2012-09-26 19:21:31 - generating LINT kernel config
TB --- 2012-09-26 19:21:31 - cd /src/sys/i386/conf
TB --- 2012-09-26 19:21:31 - /usr/bin/make -B LINT
TB --- 2012-09-26 19:21:31 - cd /src/sys/i386/conf
TB --- 2012-09-26 19:21:31 - /usr/sbin/config -m LINT
TB --- 2012-09-26 19:21:31 - building LINT kernel
TB --- 2012-09-26 19:21:31 - CROSS_BUILD_TESTING=YES
TB --- 2012-09-26 19:21:31 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-09-26 19:21:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-09-26 19:21:31 - SRCCONF=/dev/null
TB --- 2012-09-26 19:21:31 - TARGET=i386
TB --- 2012-09-26 19:21:31 - TARGET_ARCH=i386
TB --- 2012-09-26 19:21:31 - TZ=UTC
TB --- 2012-09-26 19:21:31 - __MAKE_CONF=/dev/null
TB --- 2012-09-26 19:21:31 - cd /src
TB --- 2012-09-26 19:21:31 - /usr/bin/make -B buildkernel KERNCONF=LINT
 Kernel build for LINT started on Wed Sep 26 19:21: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 Wed Sep 26 19:55:55 UTC 2012
TB --- 2012-09-26 19:55:55 - cd /src/sys/i386/conf
TB --- 2012-09-26 19:55:55 - /usr/sbin/config -m LINT-NOINET
TB --- 2012-09-26 19:55:55 - building LINT-NOINET kernel
TB --- 2012-09-26 19:55:55 - CROSS_BUILD_TESTING=YES
TB --- 2012-09-26 19:55:55 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-09-26 19:55:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-09-26 19:55:55 - SRCCONF=/dev/null
TB --- 2012-09-26 19:55:55 - TARGET=i386
TB --- 2012-09-26 19:55:55 - TARGET_ARCH=i386
TB --- 2012-09-26 19:55:55 - TZ=UTC
TB --- 2012-09-26 19:55:55 - __MAKE_CONF=/dev/null
TB --- 2012-09-26 19:55:55 - cd /src
TB --- 2012-09-26 19:55:55 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
 Kernel build for LINT-NOINET started on Wed Sep 26 19:55:56 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 Wed Sep 26 20:28:09 UTC 2012
TB --- 2012-09-26 20:28:09 - cd /src/sys/i386/conf
TB --- 2012-09-26 20:28:09 - /usr/sbin/config -m LINT-NOINET6
TB --- 2012-09-26 20:28:09 - building LINT-NOINET6 kernel
TB --- 2012-09-26 20:28:09 - CROSS_BUILD_TESTING=YES
TB --- 2012-09-26 20:28:09 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-09-26 20:28:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-09-26 20:28:09 - SRCCONF=/dev/null
TB --- 2012-09-26 20:28:09 - TARGET=i386
TB --- 2012-09-26 20:28:09 - TARGET_ARCH=i386
TB --- 2012-09-26 20:28:09 - TZ=UTC
TB --- 2012-09-26 20:28:09 - __MAKE_CONF=/dev/null
TB --- 2012-09-26 20:28:09 - cd /src
TB --- 2012-09-26 20:28:09 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
 Kernel build for LINT-NOINET6 started on Wed Sep 26 20:28: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
 Kernel build for LINT-NOINET6 completed on Wed Sep 26 21:00:09 UTC 2012
TB --- 2012-09-26 21:00:09 - cd /src/sys/i386/conf
TB --- 2012-09-26 21:00:09 - /usr/sbin/config 

Re: [PATCH] unbreak imake build when clang set as base compiler

2012-09-26 Thread Oliver Pinter
On 9/26/12, Garrett Cooper yaneg...@gmail.com wrote:
 On Wed, Sep 26, 2012 at 2:18 PM, Oliver Pinter oliver.p...@gmail.com
 wrote:
 On 9/26/12, Garrett Cooper yaneg...@gmail.com wrote:
 On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter oliver.p...@gmail.com
 wrote:
 Hi all!

 This patch fixed the problem, when buildig imake on a machine where
 clang is the base the compiler (WITH_CLANG_IS_CC).

 (Picking a random message to reply to) Why not create PRs and CC the
 relevant parties?

 because I hope, there become this issue a mote attention ;)

 Or gets lost in someone's mailbox :(...

 of course, I create in near future a PR, but before that, I send an
 updated patch, and yes, I know, that this is not a clean solution, but
 better than nothing.

 Having a PR is better than a random email that will most likely get
 lost. I would definitely respond to:

 Hey $dev! I filed $PR -- can you please take a look at it? It solves
 '$reason'. Thanks!

ports/172103 ports/172104 ports/172102 ports/172101 ports/172100 ;)


 You might get better results this way too and less duplicated effort
 by multiple individuals.. just sayin'...

 Thanks!
 -Garrett

___
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: [PATCH] unbreak imake build when clang set as base compiler

2012-09-26 Thread Oliver Pinter
On 9/27/12, Oliver Pinter oliver.p...@gmail.com wrote:
 On 9/26/12, Garrett Cooper yaneg...@gmail.com wrote:
 On Wed, Sep 26, 2012 at 2:18 PM, Oliver Pinter oliver.p...@gmail.com
 wrote:
 On 9/26/12, Garrett Cooper yaneg...@gmail.com wrote:
 On Tue, Sep 25, 2012 at 3:37 PM, Oliver Pinter oliver.p...@gmail.com
 wrote:
 Hi all!

 This patch fixed the problem, when buildig imake on a machine where
 clang is the base the compiler (WITH_CLANG_IS_CC).

 (Picking a random message to reply to) Why not create PRs and CC the
 relevant parties?

 because I hope, there become this issue a mote attention ;)

 Or gets lost in someone's mailbox :(...

 of course, I create in near future a PR, but before that, I send an
 updated patch, and yes, I know, that this is not a clean solution, but
 better than nothing.

 Having a PR is better than a random email that will most likely get
 lost. I would definitely respond to:

 Hey $dev! I filed $PR -- can you please take a look at it? It solves
 '$reason'. Thanks!

 ports/172103 ports/172104 ports/172102 ports/172101 ports/172100 ;)

and the patches are here too:
http://oliverp.teteny.bme.hu/freebsd/patches/ports-clang/



 You might get better results this way too and less duplicated effort
 by multiple individuals.. just sayin'...

 Thanks!
 -Garrett


___
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 mips/mips

2012-09-26 Thread FreeBSD Tinderbox
TB --- 2012-09-27 04:40:22 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-09-27 04:40:22 - 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-09-27 04:40:22 - starting HEAD tinderbox run for mips/mips
TB --- 2012-09-27 04:40:22 - cleaning the object tree
TB --- 2012-09-27 04:40:22 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-09-27 04:40:22 - cd /tinderbox/HEAD/mips/mips
TB --- 2012-09-27 04:40:22 - /usr/local/bin/svn cleanup /src
TB --- 2012-09-27 04:40:54 - /usr/local/bin/svn update /src
TB --- 2012-09-27 04:41:00 - At svn revision 240981
TB --- 2012-09-27 04:41:01 - building world
TB --- 2012-09-27 04:41:01 - CROSS_BUILD_TESTING=YES
TB --- 2012-09-27 04:41:01 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-09-27 04:41:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-09-27 04:41:01 - SRCCONF=/dev/null
TB --- 2012-09-27 04:41:01 - TARGET=mips
TB --- 2012-09-27 04:41:01 - TARGET_ARCH=mips
TB --- 2012-09-27 04:41:01 - TZ=UTC
TB --- 2012-09-27 04:41:01 - __MAKE_CONF=/dev/null
TB --- 2012-09-27 04:41:01 - cd /src
TB --- 2012-09-27 04:41:01 - /usr/bin/make -B buildworld
 World build started on Thu Sep 27 04:41:02 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 Thu Sep 27 05:42:08 UTC 2012
TB --- 2012-09-27 05:42:08 - cd /src/sys/mips/conf
TB --- 2012-09-27 05:42:08 - /usr/sbin/config -m ADM5120
TB --- 2012-09-27 05:42:08 - skipping ADM5120 kernel
TB --- 2012-09-27 05:42:08 - cd /src/sys/mips/conf
TB --- 2012-09-27 05:42:08 - /usr/sbin/config -m ALCHEMY
TB --- 2012-09-27 05:42:08 - skipping ALCHEMY kernel
TB --- 2012-09-27 05:42:08 - cd /src/sys/mips/conf
TB --- 2012-09-27 05:42:08 - /usr/sbin/config -m AP91
TB --- 2012-09-27 05:42:08 - building AP91 kernel
TB --- 2012-09-27 05:42:08 - CROSS_BUILD_TESTING=YES
TB --- 2012-09-27 05:42:08 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-09-27 05:42:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-09-27 05:42:08 - SRCCONF=/dev/null
TB --- 2012-09-27 05:42:08 - TARGET=mips
TB --- 2012-09-27 05:42:08 - TARGET_ARCH=mips
TB --- 2012-09-27 05:42:08 - TZ=UTC
TB --- 2012-09-27 05:42:08 - __MAKE_CONF=/dev/null
TB --- 2012-09-27 05:42:08 - cd /src
TB --- 2012-09-27 05:42:08 - /usr/bin/make -B buildkernel KERNCONF=AP91
 Kernel build for AP91 started on Thu Sep 27 05:42:08 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/dev/pci/pci.c
awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/pci/pci_if.m -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  pci_if.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