FreeBSD_HEAD_amd64_gcc4.9 - Build #235 - Failure
jenkins-admin at FreeBSD.org
jenkins-admin at FreeBSD.org
Fri Jul 24 18:06:28 UTC 2015
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
More information about the freebsd-current
mailing list