FreeBSD_HEAD_amd64_gcc4.9 - Build #235 - Failure

FreeBSD_HEAD_amd64_gcc4.9 - Build #235 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/235/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/235/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/235/console

Change summaries:

285845 by emaste:
readelf: avoid division by zero on section entry size

ELF Tool Chain tickets #439, #444, #445, #467
Reported by:	Alexander Cherepanov <cherepan_at_mccme.ru> (#467)
Reported by:	antiAgainst (others)

Reviewed by:	brooks
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D2338

285844 by emaste:
ar: add -U (unique) option to disable -D (deterministic) mode

This is required in order for us to support deterministic mode by
default.  If multiple -D or -U options are specified on the command
line, the final one takes precedence.  GNU ar also uses -U for this.

An equivalent change will be applied to ELF Tool Chain's version of ar.

PR:		196929
MFC after:	1 month
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D3175

285843 by marius:
- Since r253161, uart_intr() abuses FILTER_SCHEDULE_THREAD for signaling
  uart_bus_attach() during its test that 20 iterations weren't sufficient
  for clearing all pending interrupts, assuming this means that hardware
  is broken and doesn't deassert interrupts. However, under pressure, 20
  iterations also can be insufficient for clearing all pending interrupts,
  leading to a panic as intr_event_handle() tries to schedule an interrupt
  handler not registered. Solve this by introducing a flag that is set in
  test mode and otherwise restores pre-r253161 behavior of uart_intr(). The
  approach of additionally registering uart_intr() as handler as suggested
  in PR 194979 is not taken as that in turn would abuse special pccard and
  pccbb handling code of intr_event_handle(). [1]
- Const'ify uart_driver_name.
- Fix some minor style bugs.

PR:		194979 [1]
Reviewed by:	marcel (earlier version)
MFC after:	3 days

285842 by emaste:
truss: follow pdfork()ed descendents with -f

PR:		201276
Reported by:	David Drysdale
Reviewed by:	oshogbo
MFC after:	1 week
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D2976

285841 by emaste:
Add RISC-V ELF machine type definition

EM_RISCV is now officially registered as e_machine 243.

MFC after:	1 month
Sponsored by:	The FreeBSD Foundation

285840 by marius:
- In mpt_send_handshake_cmd(), use bus_space_write_stream_4(9) for writing
  raw data to the doorbell offset in order to clarify the intent and for
  avoiding unnecessarily converting the endianess back and forth.
  Unfortunately, the same can't be done in mpt_recv_handshake_reply() as
  16-bit data needs to be read using 32-bit bus accessors.
- In mpt_recv_handshake_reply(), get rid of a redundant variable.

MFC after:	1 fortnight

285839 by marius:
o Revert the other functional half of r239864, i. e. the merge of r134227
  from x86 to use smp_ipi_mtx spin lock not only for smp_rendezvous_cpus()
  but also for the MD cache invalidation, TLB demapping and remote register
  reading IPIs due to the following reasons:
  - The cross-IPI SMP deadlock x86 otherwise is subject to can't happen on
    sparc64. That's because on sparc64, spin locks don't disable interrupts
    completely but only raise the processor interrupt level to PIL_TICK. This
    means that IPIs still get delivered and direct dispatch IPIs such as the
    cache invalidation etc. IPIs in question are still executed.
  - In smp_rendezvous_cpus(), smp_ipi_mtx is held not only while sending an
    IPI_RENDEZVOUS, but until all CPUs have processed smp_rendezvous_action().
    Consequently, smp_ipi_mtx may be locked for an extended amount of time as
    queued IPIs (as opposed to the direct ones) such as IPI_RENDEZVOUS are
    scheduled via a soft interrupt. Moreover, given that this soft interrupt
    is only delivered at PIL_RENDEZVOUS, processing of smp_rendezvous_action()
    on a target may be interrupted by f. e. a tick interrupt at PIL_TICK, in
    turn leading to the target in question trying to send an IPI by itself
    while IPI_RENDEZVOUS isn't fully handled, yet, and, thus, resulting in a
    deadlock.
o As mentioned in the commit message of r245850, on least some sun4u platforms
  concurrent sending of IPIs by different CPUs is fatal. Therefore, hold the
  reintroduced MD ipi_mtx also while delivering cross-traps via MI helpers,
  i. e. ipi_{all_but_self,cpu,selected}().
o Akin to x86, let the last CPU to process cpu_mp_bootstrap() set smp_started
  instead of the BSP in cpu_mp_unleash(). This ensures that all APs actually
  are started, when smp_started is no longer 0.
o In all MD and MI IPI helpers, check for smp_started == 1 rather than for
  smp_cpus > 1 or nothing at all. This avoids races during boot causing IPIs
  trying to be delivered to APs that in fact aren't up and running, yet.
  While at it, move setting of the cpu_ipi_{selected,single}() pointers to
  the appropriate delivery functions from mp_init() to cpu_mp_start() where
  it's better suited and allows to get rid of the global isjbus variable.
o Given that now concurrent IPI delivery no longer is possible, also nuke
  the delays before completely disabling interrupts again in the CPU-specific
  cross-trap delivery functions, previously giving other CPUs a window for
  sending IPIs on their part. Actually, we now should be able to entirely get
  rid of completely disabling interrupts in these functions. Such a change
  needs more testing, though.
o In {s,}tick_get_timecount_mp(), make the {s,}tick variable static. While not
  necessary for correctness, this avoids page faults when accessing the stack
  of a foreign CPU as {s,}tick now is locked into the TLBs as part of static
  kernel data. Hence, {s,}tick_get_timecount_mp() always execute as fast as
  possible, avoiding jitter.

PR:		201245
MFC after:	3 days

285838 by rrs:
Fix silly syntax error emacs chugged in for me.. gesh.

MFC after:	3 weeks

285837 by rrs:
Fix an issue with MAC OS locking and also optimize the case
where we are sending back a stream-reset and a sack timer is running, in
that case we should just send the SACK.

MFC after:	3 weeks



The end of the build log:

Started by upstream project "FreeBSD_HEAD" build number 3000
originally caused by:
 Started by an SCM change
Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace /builds/FreeBSD_HEAD_amd64_gcc4.9
Updating svn://svn.freebsd.org/base/head at revision '2015-07-24T18:03:48.644 +0000'
U         sys/sys/elf_common.h
U         sys/sparc64/sparc64/machdep.c
U         sys/sparc64/sparc64/tick.c
U         sys/sparc64/sparc64/mp_machdep.c
U         sys/sparc64/include/smp.h
U         sys/netinet/sctp_usrreq.c
U         sys/netinet/sctp_output.c
U         sys/netinet/sctp_output.h
U         sys/netinet/sctp_input.c
U         sys/dev/uart/uart_bus.h
U         sys/dev/uart/uart_core.c
U         sys/dev/mpt/mpt.h
U         sys/dev/mpt/mpt.c
U         sys/kern/subr_witness.c
U         usr.bin/elfdump/elfdump.c
U         usr.bin/ar/ar.1
U         usr.bin/ar/ar.c
U         usr.bin/truss/amd64-fbsd.c
U         usr.bin/truss/arm-fbsd.c
U         usr.bin/truss/powerpc-fbsd.c
U         usr.bin/truss/amd64-fbsd32.c
U         usr.bin/truss/sparc64-fbsd.c
U         usr.bin/truss/i386-fbsd.c
U         usr.bin/truss/powerpc64-fbsd.c
U         usr.bin/truss/mips-fbsd.c
U         contrib/elftoolchain/readelf/readelf.c
U         contrib/elftoolchain/common/elfdefinitions.h
At revision 285845
No emails were triggered.
[FreeBSD_HEAD_amd64_gcc4.9] $ /bin/sh -xe /tmp/hudson9133804241737321426.sh
+ cat
+ svn revert Makefile.inc1
+ svn revert sys/boot/i386/Makefile
Reverted 'sys/boot/i386/Makefile'
+ patch -f
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: sys/boot/i386/Makefile
|===================================================================
|--- sys/boot/i386/Makefile	(revision 280912)
|+++ sys/boot/i386/Makefile	(working copy)
--------------------------
Patching file sys/boot/i386/Makefile using Plan A...
Hunk #1 succeeded at 12.
Hmm...  Ignoring the trailing garbage.
done
+ /vm/freebsd-ci/scripts/build/cross-build.sh
+ [ -z /builds/FreeBSD_HEAD_amd64_gcc4.9 ]
+ [ -z amd64 ]
+ export MAKEOBJDIRPREFIX=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj
+ mkdir -p /builds/FreeBSD_HEAD_amd64_gcc4.9/obj
+ echo -e 'NO_WERROR=yes
WERROR=
'
+ cat
+ set +x
--------------------------------------------------------------
>>> /builds/FreeBSD_HEAD_amd64_gcc4.9/make.conf contains:
+ cat /builds/FreeBSD_HEAD_amd64_gcc4.9/make.conf
# Put make.conf entries here
NO_WERROR=yes
WERROR=
+ set +x
--------------------------------------------------------------
+ sudo pkg install -y devel/amd64-xtoolchain-gcc
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
pkg: No packages available to install matching 'devel/amd64-xtoolchain-gcc' have been found in the repositories
Build step 'Execute shell' marked build as failure
[WARNINGS] Skipping publisher since build result is FAILURE
IRC notifier plugin: Sending notification to: #freebsd-commits
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any