Date: Mon, 24 Aug 2015 20:53:30 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: cem@FreeBSD.org, adrian@FreeBSD.org, bz@FreeBSD.org, marcel@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: FreeBSD_HEAD_arm64 - Build #952 - Fixed Message-ID: <686270302.49.1440449612791.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <71486083.47.1440440639816.JavaMail.jenkins@jenkins-9.freebsd.org> References: <71486083.47.1440440639816.JavaMail.jenkins@jenkins-9.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
FreeBSD_HEAD_arm64 - Build #952 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/952/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/952/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/952/console Change summaries: 287117 by cem: Import ioat(4) driver I/OAT is also referred to as Crystal Beach DMA and is a Platform Storage Extension (PSE) on some Intel server platforms. This driver currently supports DMA descriptors only and is part of a larger effort to upstream an interconnect between multiple systems using the Non-Transparent Bridge (NTB) PSE. For now, this driver is only built on AMD64 platforms. It may be ported to work on i386 later, if that is desired. The hardware is exclusive to x86. Further documentation on ioat(4), including API documentation and usage, can be found in the new manual page. Bring in a test tool, ioatcontrol(8), in tools/tools/ioat. The test tool is not hooked up to the build and is not intended for end users. Submitted by: jimharris, Carl Delsey <carl.r.delsey@intel.com> Reviewed by: jimharris (reviewed my changes) Approved by: markj (mentor) Relnotes: yes Sponsored by: Intel Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D3456 287116 by adrian: Enable hardfloat for assembly generation. gcc versions later than 4.2 started erroring out on seeing hardware floating point references when soft-float was enabled. Reviewed by: imp 287115 by bz: When forking a child process with PMC_F_DESCENDANTS set in pmc_attach() in the parent, we will inherit the pmcids but cannot execute any operations on them in the child. The reason for this is that pmc_find_pmc() only tries to find the current process on the owners hash list, but given the child does not own the attachment, we cannot find it. Thus, in case the initial lookup fails, try to find the pmc_process state affiliated with the child process, lookup the pmc from there using the row index, and get the owner process from that pmc. Then continue as normal and lookup the pmc context of the owner (process). This allows us to call, e.g., pmc_start() in the child process before we start the work there, but to collect the accumulated results later in the parent. Sponsored by: DARPA,AFRL Obtained from: L41 Tested by: rwatson, L41 MFC after: 4 weeks Reviewed by: gnn Differential Revision: https://reviews.freebsd.org/D2052 287114 by marcel: Fix build for architectures that define wchar_t as an unsigned int. Reported by: bz@
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?686270302.49.1440449612791.JavaMail.jenkins>