[Bug 236737] recvmsg() under COMPAT_FREEBSD32 returns the wrong msg_controllen value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236737 Jason A. Harmening changed: What|Removed |Added CC||j...@freebsd.org --- Comment #1 from Jason A. Harmening --- Created attachment 203155 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203155&action=edit proposed patch -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236737] recvmsg() under COMPAT_FREEBSD32 returns the wrong msg_controllen value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236737 --- Comment #2 from Jason A. Harmening --- It looks like the 32-bit kernel compat shim for recvmsg() isn't correctly padding the data size for each control message to the required 4-byte alignment when calculating controllen for the output header. I think the fix may be very simple; the attached patch worked for me. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236737] recvmsg() under COMPAT_FREEBSD32 returns the wrong msg_controllen value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236737 Jason A. Harmening changed: What|Removed |Added Status|New |In Progress Assignee|b...@freebsd.org|j...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 235509] BTX Freezes during boot on Supermicro H8DGi-F after update to 12.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235509 j...@feith.com changed: What|Removed |Added CC||j...@feith.com --- Comment #4 from j...@feith.com --- The unified ufs / zfs loader probes all the drives. Details and a patch are in PR 236585. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 235509] BTX Freezes during boot on Supermicro H8DGi-F after update to 12.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235509 --- Comment #5 from j...@feith.com --- If the patch doesn't help, then what you can do is add print statements to find out where the loader is going splat. The PR I mentioned lists some of the routines of interest. To debug I built the loader, copied to /boot/loader.new, and then during boot manually choose loader.new (this way the system would still boot normally while chasing down the issue with the newer loader). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 233769] Possible build race: ld: error: unable to find library -lgcc_s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233769 --- Comment #4 from Ed Maste --- In a successful build we actually install libgcc_s.so three times to the same location. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 221550] kern.bootfile returns only /kernel on mips64 (ERL) platform
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221550 --- Comment #3 from commit-h...@freebsd.org --- A commit references this bug: Author: gonzo Date: Tue Mar 26 18:03:18 UTC 2019 New revision: 345550 URL: https://svnweb.freebsd.org/changeset/base/345550 Log: Change default value of kern.bootfile to reflect reality In most cases kernel.bootfile is populated from the information provided by loader(8). There are certain scenarios when loader is not available, for instance when kernel is loaded by u-boot or some other BootROM directly. In this case the default value "/kernel" points to invalid location and breaks some functinality, like using installkernel on self-hosted system or dtrace's CTF lookup. This can be fixed by setting the value manually but the default that reflects correct location is better than default that points to invalid one. Current default was set around FreeBSD 1, when "/kernel" was the actual path. Transition to /boot/kernel/kernel happened circa FreeBSD 3. PR: 221550 Reviewed by: ian, imp MFC after:1 week Differential Revision:https://reviews.freebsd.org/D18902 Changes: head/sys/kern/kern_mib.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] AMD Jaguar: Only CPU core 0 detects C2 state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513
--- Comment #24 from stockhau...@collogia.de ---
One step further:
The wrong ACPI definitions are indeed the culprit of the wrong C2 state
registration. I implemented a lousy patch in acpi.c:
/*
* Pre-allocate/manage all memory and IO resources. Since rman can't handle
* duplicates, we merge any in the sysresource attach routine.
*/
static int
acpi_sysres_alloc(device_t dev)
{
...
rl = BUS_GET_RESOURCE_LIST(device_get_parent(dev), dev);
STAILQ_FOREACH(rle, rl, link) {
if (rle->res != NULL) {
device_printf(dev, "duplicate resource for %jx\n", rle->start);
continue;
}
if (rle->start == 0x40b
&& rle->count == 1
&& rle->type == SYS_RES_IOPORT) {
printf("ACPI: fake IO port range 0x40b/1 -> 0x400/32\n");
rle->start = 0x400;
rle->count = 32;
}
So when ACPI wants to register a single port 0x40b we expand the range to
0x400-0x420.
With that devinfo -rv shows:
nexus0
...
acpi0
Interrupt request lines:
0x9
I/O ports:
...
0x400-0x41f
...
cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.P000
ACPI I/O ports:
0x414
acpi_perf0
acpi_throttle0
hwpstate0
cpufreq0
cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.P001
ACPI I/O ports:
0x414
acpi_perf1
acpi_throttle1
hwpstate1
Yeah! The second and following cores can register I/O port 0x414. And finally
sysctl shows all C2 states:
# sysctl -a | grep cx_suppo
dev.cpu.3.cx_supported: C1/1/0 C2/2/400
dev.cpu.2.cx_supported: C1/1/0 C2/2/400
dev.cpu.1.cx_supported: C1/1/0 C2/2/400
dev.cpu.0.cx_supported: C1/1/0 C2/2/400
Now I need some assistance:
1. Either patch the BIOS. But how?
2. Implement a workaround in CPU registration if port is not yet registered.
But how?
Thanks in advance.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 221550] kern.bootfile returns only /kernel on mips64 (ERL) platform
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221550 Oleksandr Tymoshenko changed: What|Removed |Added Flags||mfc-stable11?, ||mfc-stable12? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 stockhau...@collogia.de changed: What|Removed |Added Summary|AMD Jaguar: Only CPU core 0 |HP Thin clients T620/T730 |detects C2 state|ACPI: Only CPU core 0 ||detects C2 state -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 233769] Possible build race: ld: error: unable to find library -lgcc_s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233769 --- Comment #5 from Mark Millard --- (In reply to Ed Maste from comment #4) Is there a installworld vs. buildworld confusion? (I'd expect ld to be a buildworld issue, not a installworld one.) I see from recent activity, using: egrep -r '(--- installworld ---|install.*libgcc_s.so)' /root/sys_typescripts/ /root/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2018-10-21:16:45:49:--- installworld --- /root/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2018-10-21:16:45:49:--- installworld --- /root/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2018-10-21:16:45:49:install -s -o root -g wheel -m 444 -S libgcc_s.so.1 /lib/ /root/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2018-10-21:16:45:49:install -o root -g wheel -m 444libgcc_s.so.1.debug /usr/lib/debug/lib/ /root/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2018-10-21:16:45:49:install -l rs -o root -g wheel -m 755 /lib/libgcc_s.so.1 /usr/lib/libgcc_s.so /root/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2018-10-21:16:45:49:install -s -o root -g wheel -m 444 -S libgcc_s.so.1 /usr/lib32/ /root/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2018-10-21:16:45:49:install -o root -g wheel -m 444libgcc_s.so.1.debug /usr/lib/debug/usr/lib32/ /root/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2018-10-21:16:45:49:install -l rs -o root -g wheel -m 755 libgcc_s.so.1 /usr/lib32/libgcc_s.so /root/sys_typescripts/typescript_make_amd64_nodebug_clang-amd64-host-2018-10-22:15:07:14:Command: env __MAKE_CONF=/root/src.configs/make.conf SRCCONF=/dev/null SRC_ENV_CONF=/root/src.configs/src.conf. (So all from the same log file: one for installworld.) No matches found in files without installworld showing. Similarly for all the log history the grep went through. (I run buildworld and installworld in separate runs, not together, so separate log files in the directory.) The logs span amd64, armv7, aarch64, powerpc64, and powerpc builds. I see no evidence of buildworld doing install's of libgcc_s.so materials. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 233769] Possible build race: ld: error: unable to find library -lgcc_s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233769
--- Comment #6 from Ed Maste ---
(In reply to Mark Millard from comment #5)
The installs are done during buildworld as part of the libraries target. In a
submake the _prereq_libs, _startup_libs and _generic_libs targets are built in
turn and each of these builds and installs libgcc_s.so (see the ${_lib}__PL and
${_lib}__L targets in Makefile.inc1)
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224270] Get exit status of process that's piped to another: set -o pipefail is missing for /bin/sh
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224270 --- Comment #15 from commit-h...@freebsd.org --- A commit references this bug: Author: jilles Date: Tue Mar 26 20:47:31 UTC 2019 New revision: 345556 URL: https://svnweb.freebsd.org/changeset/base/345556 Log: MFC r327475: sh: Move various structs from jobs.h to jobs.c These implementation details of jobs.c need not be exposed. PR: 224270 Changes: _U stable/11/ stable/11/bin/sh/jobs.c stable/11/bin/sh/jobs.h -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 233769] Possible build race: ld: error: unable to find library -lgcc_s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233769 --- Comment #7 from Mark Millard --- (In reply to Ed Maste from comment #6) Ahh, I needed to look in the .meta files. Sorry. What you are reporting may mean that some .meta files are written more than once, so I'd see content from only the last pass for each. Messy. For reference (for a first time build of a head -r345520 based tree): # grep -lr 'CMD .*install.*libgcc_s\.so' /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/gnu/lib/libgcc/libgcc_s.so.1.meta /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/gnu/lib/libgcc/_libinstall.meta /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/gnu/lib/libgcc/libgcc_s.so.1.meta /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/gnu/lib/libgcc/_libinstall.meta So 4 meta files, 2 for lib32 activity and 2 not: # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/gnu/lib/libgcc/libgcc_s.so.1.meta CMD /usr/local/powerpc64-unknown-freebsd13.0/bin/objcopy --strip-debug --add-gnu-debuglink=libgcc_s.so.1.debug libgcc_s.so.1.full libgcc_s.so.1 CMD @sh /usr/src/tools/install.sh -l s -o root -g wheel -m 444 libgcc_s.so.1 libgcc_s.so CWD /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/gnu/lib/libgcc TARGET libgcc_s.so.1 # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/gnu/lib/libgcc/_libinstall.meta CMD sh /usr/src/tools/install.sh -o root -g wheel -m 444 -S libgcc_s.so.1 /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lib/ CMD sh /usr/src/tools/install.sh -o root -g wheel -m 444 libgcc_s.so.1.debug /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/debug/lib/ CMD sh /usr/src/tools/install.sh -l rs -o root -g wheel -m 755 /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/lib/libgcc_s.so.1 /usr/obj/powerpc64 vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/libgcc_s.so CWD /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/gnu/lib/libgcc TARGET _libinstall # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/gnu/lib/libgcc/libgcc_s.so.1.meta CMD /usr/local/powerpc64-unknown-freebsd13.0/bin/objcopy --strip-debug --add-gnu-debuglink=libgcc_s.so.1.debug libgcc_s.so.1.full libgcc_s.so.1 CMD @sh /usr/src/tools/install.sh -l s -o root -g wheel -m 444 libgcc_s.so.1 libgcc_s.so CWD /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/gnu/lib/libgcc TARGET libgcc_s.so.1 # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/gnu/lib/libgcc/_libinstall.meta CMD sh /usr/src/tools/install.sh -o root -g wheel -m 444 -S libgcc_s.so.1 /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/lib32/ CMD sh /usr/src/tools/install.sh -o root -g wheel -m 444 libgcc_s.so.1.debug /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/lib/de bug/usr/lib32/ CMD sh /usr/src/tools/install.sh -l rs -o root -g wheel -m 755 libgcc_s.so.1 /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/lib32/lib gcc_s.so CWD /usr/obj/powerpc64vtsc_clang_altbinutils-oldunwind/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/gnu/lib/libgcc TARGET _libinstall -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224270] Get exit status of process that's piped to another: set -o pipefail is missing for /bin/sh
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224270 --- Comment #16 from commit-h...@freebsd.org --- A commit references this bug: Author: jilles Date: Tue Mar 26 21:30:26 UTC 2019 New revision: 345559 URL: https://svnweb.freebsd.org/changeset/base/345559 Log: MFC r328818: sh: Refactor job status printing, preparing for -o pipefail and similar No functional change is intended. PR: 224270 Changes: _U stable/11/ stable/11/bin/sh/jobs.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 233769] Possible build race: ld: error: unable to find library -lgcc_s
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233769 --- Comment #8 from Mark Millard --- (In reply to Mark Millard from comment #7) And, finally what I should have looked for in the overall logs, using a aarch64 build this time (no lib32): # egrep '(libgcc_s\.so|libgcc_s.*_libinstall)' ~/sys_typescripts/typescript_make_cortexA72_nodebug_clang_bootstrap-amd64-host-2019-03-26:01:34:22 Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/libgcc_s/libgcc_s.so.1.full --- libgcc_s.so.1.full --- building shared library libgcc_s.so.1 Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/libgcc_s/libgcc_s.so.1.debug Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/libgcc_s/libgcc_s.so.1 Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/libgcc_s/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/libgcc_s/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/libgcc_s/_libinstall So 3 _libinstall 's for libgcc_s . Looking at other things in the build there are a lot of pairs of _libinstall 's and libgcc_eh has 3: FBSDFSSD# egrep '/_libinstall' ~/sys_typescripts/typescript_make_cortexA72_nodebug_clang_bootstrap-amd64-host-2019-03-26:01:34:22 | sort | more Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/cddl/lib/libavl/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/cddl/lib/libavl/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/cddl/lib/libctf/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/cddl/lib/libctf/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/cddl/lib/libdtrace/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/cddl/lib/libnvpair/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/cddl/lib/libnvpair/_libinstall . . . Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/libgcc_eh/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/libgcc_eh/_libinstall Building /usr/obj/cortexA72_clang/arm64.aarch64/usr/src/arm64.aarch64/lib/libgcc_eh/_libinstall . . . -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224270] Get exit status of process that's piped to another: set -o pipefail is missing for /bin/sh
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224270 --- Comment #17 from commit-h...@freebsd.org --- A commit references this bug: Author: jilles Date: Tue Mar 26 22:34:10 UTC 2019 New revision: 345561 URL: https://svnweb.freebsd.org/changeset/base/345561 Log: MFC r344502: sh: Add set -o pipefail The pipefail option allows checking the exit status of all commands in a pipeline more easily, at a limited cost of complexity in sh itself. It works similarly to the option in bash, ksh93 and mksh. Like ksh93 and unlike bash and mksh, the state of the option is saved when a pipeline is started. Therefore, even in the case of commands like A | B & a later change of the option does not change the exit status, the same way (A | B) & works. Since SIGPIPE is not handled specially, more work in the script is required for a proper exit status for pipelines containing commands such as head that may terminate successfully without reading all input. This can be something like ( cmd1 r=$? if [ "$r" -gt 128 ] && [ "$(kill -l "$r")" = PIPE ]; then exit 0 else exit "$r" fi ) | head PR: 224270 Relnotes: yes Changes: _U stable/11/ stable/11/bin/sh/jobs.c stable/11/bin/sh/options.h stable/11/bin/sh/sh.1 stable/11/bin/sh/tests/execution/Makefile stable/11/bin/sh/tests/execution/pipefail1.0 stable/11/bin/sh/tests/execution/pipefail2.42 stable/11/bin/sh/tests/execution/pipefail3.42 stable/11/bin/sh/tests/execution/pipefail4.42 stable/11/bin/sh/tests/execution/pipefail5.42 stable/11/bin/sh/tests/execution/pipefail6.42 stable/11/bin/sh/tests/execution/pipefail7.0 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 224270] Get exit status of process that's piped to another: set -o pipefail is missing for /bin/sh
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224270 Jilles Tjoelker changed: What|Removed |Added Status|In Progress |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 223516] man(1) ignores the exit status of groff
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223516 Bug 223516 depends on bug 224270, which changed state. Bug 224270 Summary: Get exit status of process that's piped to another: set -o pipefail is missing for /bin/sh https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224270 What|Removed |Added Status|In Progress |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 223516] man(1) ignores the exit status of groff
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223516 Jilles Tjoelker changed: What|Removed |Added CC||jil...@freebsd.org --- Comment #2 from Jilles Tjoelker --- sh now has pipefail, but you do need the additional logic from my commit message to ignore SIGPIPE exits because pagers may exit before reading all their input. This additional logic is definitely simpler than the logic to pass through exit status without pipefail, though. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236371] [new driver] HighPoint RocketRAID 3700 series embedded driver
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236371 --- Comment #1 from Xin LI --- Hi, It seems that the copyright header in the submission does not have a license, which is required for bundled driver, could you please use a compatible license (e.g. https://svnweb.freebsd.org/base/head/share/examples/etc/bsd-style-copyright?view=co ?) By the way, in hpt_match(), the driver is calling into binary blob provided get_supported_device_id() and get_controller_count() methods. Can this be implemented by exposing the device id as fields of 'HIM' directly, so that we don't call the binary blob functions until we know it's a hpt37xx device? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
