Re: svn commit: r284998 - in stable/10: cddl/contrib/opensolaris/cmd/lockstat sys/kern sys/sys
On Sun, Jul 19, 2015 at 07:03:32AM +0200, Herbert J. Skuhra wrote: > On Wed, Jul 01, 2015 at 10:15:50AM +, Andriy Gapon wrote: > > Author: avg > > Date: Wed Jul 1 10:15:49 2015 > > New Revision: 284998 > > URL: https://svnweb.freebsd.org/changeset/base/284998 > > > > Log: > > MFC r284297: several lockstat improvements > > > > Modified: > > stable/10/cddl/contrib/opensolaris/cmd/lockstat/lockstat.c > > stable/10/sys/kern/kern_mutex.c > > stable/10/sys/kern/kern_rwlock.c > > stable/10/sys/kern/kern_sx.c > > stable/10/sys/sys/lockstat.h > > Directory Properties: > > stable/10/ (props changed) > > Yesterday I tried to upgrade my Soekris Net6501-70 from 10.2-PRERELEASE > (r284583) to 10.2-BETA2 (r285646). All kernels after this commit fail to > boot: > > SMP: AP CPU #1 Launched! > > Fatal double fault: > eip = 0xc08b2e0f > esp = 0xe0febfec > ebp = 0xe0fec008 > cpuid = 1; apic id = 01 > panic: double fault > cpuid = 1 > KDB: stack backtrace: > #0 0xc065ed62 at kdb_backtrace+0x52 > #1 0xc06204eb at vpanic+0x11b > #2 0xc06203cb at panic+0x1b > #3 0xc08a5bbb at dblfault_handler+0xab > Uptime: 2s > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > cpu_reset: Restarting BSP > timeout stopping cpus > cpu_reset_proxy: Stopped CPU 1 > > I am running i386 on my Soekris. Sorry. There is already a PR for this issue: 201642! -- Herbert ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r284998 - in stable/10: cddl/contrib/opensolaris/cmd/lockstat sys/kern sys/sys
On Wed, Jul 01, 2015 at 10:15:50AM +, Andriy Gapon wrote: > Author: avg > Date: Wed Jul 1 10:15:49 2015 > New Revision: 284998 > URL: https://svnweb.freebsd.org/changeset/base/284998 > > Log: > MFC r284297: several lockstat improvements > > Modified: > stable/10/cddl/contrib/opensolaris/cmd/lockstat/lockstat.c > stable/10/sys/kern/kern_mutex.c > stable/10/sys/kern/kern_rwlock.c > stable/10/sys/kern/kern_sx.c > stable/10/sys/sys/lockstat.h > Directory Properties: > stable/10/ (props changed) Yesterday I tried to upgrade my Soekris Net6501-70 from 10.2-PRERELEASE (r284583) to 10.2-BETA2 (r285646). All kernels after this commit fail to boot: SMP: AP CPU #1 Launched! Fatal double fault: eip = 0xc08b2e0f esp = 0xe0febfec ebp = 0xe0fec008 cpuid = 1; apic id = 01 panic: double fault cpuid = 1 KDB: stack backtrace: #0 0xc065ed62 at kdb_backtrace+0x52 #1 0xc06204eb at vpanic+0x11b #2 0xc06203cb at panic+0x1b #3 0xc08a5bbb at dblfault_handler+0xab Uptime: 2s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Restarting BSP timeout stopping cpus cpu_reset_proxy: Stopped CPU 1 I am running i386 on my Soekris. -- Herbert ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285684 - in head/gnu: lib usr.bin
Author: marius Date: Sun Jul 19 00:38:19 2015 New Revision: 285684 URL: https://svnweb.freebsd.org/changeset/base/285684 Log: - Record dependencies of gdb/gdbtui/kgdb on binutils/lib{bfd,iberty,opcodes}, fixing parallel builds. - Don't build gdb/gdbtui/kgdb or libreadline when MK_BINUTILS is "no" for obvious reasons. MFC after:3 days Modified: head/gnu/lib/Makefile head/gnu/usr.bin/Makefile Modified: head/gnu/lib/Makefile == --- head/gnu/lib/Makefile Sat Jul 18 22:47:46 2015(r285683) +++ head/gnu/lib/Makefile Sun Jul 19 00:38:19 2015(r285684) @@ -16,7 +16,7 @@ SUBDIR+= libssp SUBDIR+= tests .endif -.if ${MK_GDB} != "no" +.if ${MK_BINUTILS} != "no" && ${MK_GDB} != "no" SUBDIR+= libreadline .endif Modified: head/gnu/usr.bin/Makefile == --- head/gnu/usr.bin/Makefile Sat Jul 18 22:47:46 2015(r285683) +++ head/gnu/usr.bin/Makefile Sun Jul 19 00:38:19 2015(r285684) @@ -16,6 +16,8 @@ SUBDIR= ${_binutils} \ sdiff \ ${_tests} +SUBDIR_DEPEND_gdb= ${_binutils} + .if ${MK_CXX} != "no" .if ${MK_GCC} != "no" _gperf=gperf @@ -39,13 +41,14 @@ _tests= tests .if ${MK_BINUTILS} != "no" _binutils= binutils +.if ${MK_GDB} != "no" +_gdb= gdb +.endif .endif + .if ${MK_GCC} != "no" _cc= cc .endif -.if ${MK_GDB} != "no" -_gdb= gdb -.endif SUBDIR_PARALLEL= ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r285664 - in head/sys: kern sys
On Sat, Jul 18, 2015 at 08:55:07PM +1000, Bruce Evans wrote: > On Sat, 18 Jul 2015, Mark Johnston wrote: > > > Log: > > Pass the lock object to lockstat_nsecs() and return immediately if > > LO_NOPROFILE is set. Some timecounter handlers acquire a spin mutex, and > > we don't want to recurse if lockstat probes are enabled. > > It is an error to call timecounter code from a low-level place like the > mutex implementation. This workaround depends on all locks in timecounter > handlers being LO_NOPROFILE, and that breaks profiling of these locks. > The breakage is largest if the locks are used for more than timecounters. > E.g., the one for i386's obsolescent i8254 timer has to be used for all > accesses to the i8254. This lock is configured as MTX_SPIN | MTX_NOPROFILE > and is perhaps the main one fixed by this commit. I noticed that lock_profile (which predates lockstat a bit) does the exact same thing to avoid recursion. Specifically, lock_profile_obtain_lock_{success,failed} return immediately if LO_NOPROFILE is set on the target lock. As you pointed out, this change breaks profiling of timecounter locks, but the only timecounter implementation in the tree that currently acquires a lock during a timer read is i8254. The other two locks that set MTX_NOPROFILE are the witness lock and the i386 icu lock. Lock order checking can usually be done without taking the witness lock, so contention would be unusual, and it would strike me as strange to profile locking with witness enabled anyway. :) I'm not sure why i386's icu_lock has profiling disabled; this was done in r166001, but the commit log doesn't explain the reason. It might also be worth noting that lockstat can still be used to observe acquisitions of LO_NOPROFILE locks - the change prevents measurement of the time spent contending for such locks. > > KTR handles this problem badly in a different way. It abuses > get_cyclecount(). The abuse is parametrized by defining KTR_TIME as > get_cyclecount() and using KTR_TIME. The definition of KTR_TIME is > ifdefed but not in a usable way. This is of course undocumented, and > KTR_TIME is not a normal kernel option so it is hard to define in > config files. > > KTR needs to be about as careful about this as lockstat since it is > called from low level mutex code for debugging. I think there is nothing > like LO_NOPROFILE to turn it off. Of course you can turn off the mutex > code's calls to it using MTX_QUIET or MTX_NOWITNESS, but this breaks much > more than lock profiling. (I rarely use any lock debugging, but when > I did I found it useful to use it without WITNESS_SKIPSPIN and with > MTX_QUIET and MTX_NOWITNESS turned off for the locks being debugged. > Some console drivers use spinlocks with MTX_QUIET or MTX_NOWITNESS to > avoid various problems, and this breaks witnessing of them even for > non-console uses. Unbreaking their witnessing uncovered further bugs.) > > Abusing get_cyclecount() in KTR doesn't even fix the problem with > timecounters, since some implementations of get_cyclecount() (some > arm, some i386) use the timecounter. > > Other bugs with using get_cyclecount(): > - even if it returns cycles counted by a clock, the frequency of this >clock is unknown/unobtainable, so there is no way to convert to >human-readable units > - some arches return a shifted binuptime() that wraps very quickly >(256 seconds for arm with ARM_ARCH < 6). Such counters cannot be >monotonic. > - some arches (arm again?) used to use binuptime() with swizzling more >complicated than shifting. Their counters were further from being >monotonic. > - arm is now the only arch that uses binuptime() at a low level. >arm64 use a stub that returns 1. ARM_ARCH < 6 does the above. i386 >returns cpu_ticks(). This is the correct method. It uses the >hardware counter use by cpu_ticks() if possible, else the raw value >of the current hardware timecounter, adjusted to avoid wrap. > (This is not actually a correct method, since its implementation is > no good. The wrap adjustment is down with no locking. Also, > switching the timecounter hardware breaks the get_cyclecount() > use even more than the thread resource usage use. The latter > has incomplete recalibration.) > - KTR of course has no support for converting to human-readable units. >ktrdump prints raw timestamps and their differences in %16ju format. >kern_ktr.c seems to print them only in a ddb command. This prints >the raw value in the much worse format %10.10lld. This uses the >long long abomination and has a sign error (ktr_timestamp has type >uint64_t). > - ktr's "timestamps" are thus at best a cookie that increases strictly >monotonically > - get_cyclecount() is always rdtsc() on modern x86. rdtsc() is not >a serializing instruction. I recently learned how unserial it can >be -- hundreds of cycles on freefall. The hundred-cycle case probably >
svn commit: r285683 - head/sys/boot/arm/ixp425/boot2
Author: jmg Date: Sat Jul 18 22:47:46 2015 New Revision: 285683 URL: https://svnweb.freebsd.org/changeset/base/285683 Log: move the prototype to the lib.h header.. This makes more sense, and it's an API between boot2.c and arm_init.S which calls it.. Modified: head/sys/boot/arm/ixp425/boot2/boot2.c head/sys/boot/arm/ixp425/boot2/lib.h Modified: head/sys/boot/arm/ixp425/boot2/boot2.c == --- head/sys/boot/arm/ixp425/boot2/boot2.c Sat Jul 18 20:21:25 2015 (r285682) +++ head/sys/boot/arm/ixp425/boot2/boot2.c Sat Jul 18 22:47:46 2015 (r285683) @@ -152,8 +152,6 @@ getstr(int c) } } -int main(void); - int main(void) { Modified: head/sys/boot/arm/ixp425/boot2/lib.h == --- head/sys/boot/arm/ixp425/boot2/lib.hSat Jul 18 20:21:25 2015 (r285682) +++ head/sys/boot/arm/ixp425/boot2/lib.hSat Jul 18 22:47:46 2015 (r285683) @@ -30,6 +30,8 @@ #include #include +int main(void); + void DELAY(int); int getc(int); ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r285644 - head/contrib/sqlite3
On 18 Jul 2015, at 00:53, Pedro Giffuni wrote: > > On 07/17/15 17:26, Peter Jeremy wrote: >> On 2015-Jul-16 22:07:14 +, "Pedro F. Giffuni" wrote: >>> Log: >> ... >>> sqlite: clean a couple of invocations of memcpy(3) >>>Found almost accidentally by our native gcc when enhanced with >>> FORTIFY_SOURCE. >> ... >>> - memcpy((void *)&aHdr[1], (void *)&pWal->hdr, sizeof(WalIndexHdr)); >>> + memcpy((void *)&aHdr[1], (const void *)&pWal->hdr, sizeof(WalIndexHdr)); >>> walShmBarrier(pWal); >>> - memcpy((void *)&aHdr[0], (void *)&pWal->hdr, sizeof(WalIndexHdr)); >>> + memcpy((void *)&aHdr[0], (const void *)&pWal->hdr, sizeof(WalIndexHdr)); >> If the compiler complained about that, the compiler is broken. > > The change was rather collateral (read cosmetical) to the real warning > which remains unfixed. > > The compiler warning is this: > ... > ===> lib/libsqlite3 (obj,depend,all,install) > cc1: warnings being treated as errors > /scratch/tmp/pfg/head/lib/libsqlite3/../../contrib/sqlite3/sqlite3.c: In > function 'walIndexWriteHdr': > /scratch/tmp/pfg/head/lib/libsqlite3/../../contrib/sqlite3/sqlite3.c:49490: > warning: passing argument 1 of 'memcpy' discards qualifiers from pointer > target type > /scratch/tmp/pfg/head/lib/libsqlite3/../../contrib/sqlite3/sqlite3.c:49492: > warning: passing argument 1 of 'memcpy' discards qualifiers from pointer > target type > --- sqlite3.So --- > *** [sqlite3.So] Error code 1 > ... > > make[6]: stopped in /scratch/tmp/pfg/head/lib/libsqlite3 > > It only happens when using the experimental FORTIFY_SOURCE support [1], > and it only happens with gcc (the base one is the only tested). > > Yes, I am suspecting a compiler bug but gcc has been really useful to find > bugs in fortify_source. Actually, it is right to warn about this, as the casts drop a volatile specifier: 49482 static void walIndexWriteHdr(Wal *pWal){ 49483volatile WalIndexHdr *aHdr = walIndexHdr(pWal); ... 49490memcpy((void *)&aHdr[1], (void *)&pWal->hdr, sizeof(WalIndexHdr)); 49491walShmBarrier(pWal); 49492memcpy((void *)&aHdr[0], (void *)&pWal->hdr, sizeof(WalIndexHdr)); If you compile this with clang, and a high enough WARNS level, it tells you where the problem is: contrib/sqlite3/sqlite3.c:49490:18: error: cast from 'volatile struct WalIndexHdr *' to 'void *' drops volatile qualifier [-Werror,-Wcast-qual] memcpy((void *)&aHdr[1], (void *)&pWal->hdr, sizeof(WalIndexHdr)); ^ contrib/sqlite3/sqlite3.c:49492:18: error: cast from 'volatile struct WalIndexHdr *' to 'void *' drops volatile qualifier [-Werror,-Wcast-qual] memcpy((void *)&aHdr[0], (void *)&pWal->hdr, sizeof(WalIndexHdr)); ^ Similar with newer versions of gcc: contrib/sqlite3/sqlite3.c:49490:10: error: cast discards 'volatile' qualifier from pointer target type [-Werror=cast-qual] memcpy((void *)&aHdr[1], (void *)&pWal->hdr, sizeof(WalIndexHdr)); ^ contrib/sqlite3/sqlite3.c:49492:10: error: cast discards 'volatile' qualifier from pointer target type [-Werror=cast-qual] memcpy((void *)&aHdr[0], (void *)&pWal->hdr, sizeof(WalIndexHdr)); ^ Removing all the casts does not help, with base gcc it still gives: contrib/sqlite3/sqlite3.c:49490: warning: passing argument 1 of 'memcpy' discards qualifiers from pointer target type contrib/sqlite3/sqlite3.c:49492: warning: passing argument 1 of 'memcpy' discards qualifiers from pointer target type and with clang: contrib/sqlite3/sqlite3.c:49490:10: error: passing 'volatile WalIndexHdr *' (aka 'volatile struct WalIndexHdr *') to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] memcpy(&aHdr[1], &pWal->hdr, sizeof(WalIndexHdr)); ^~~~ /usr/include/string.h:62:31: note: passing argument to parameter here void*memcpy(void * __restrict, const void * __restrict, size_t); ^ contrib/sqlite3/sqlite3.c:49492:10: error: passing 'volatile WalIndexHdr *' (aka 'volatile struct WalIndexHdr *') to parameter of type 'void *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] memcpy(&aHdr[0], &pWal->hdr, sizeof(WalIndexHdr)); ^~~~ /usr/include/string.h:62:31: note: passing argument to parameter here void*memcpy(void * __restrict, const void * __restrict, size_t); ^ >> 'const' >> is a promise to the caller that the given parameter will not be modified >> by the callee. There's no requirement that the passed argument be const. >> As bde commented, the casts are all spurious. > > And since this is contrib'ed code I am not going through the > code churn but upstream has been notified. I don't think it is likely that upstream will go through the trouble of removing -Wcast-qual warnings. There are 152 of them in sqlite3.c. :-) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
svn commit: r285682 - head/sys/boot/arm/ixp425/boot2
Author: jmg Date: Sat Jul 18 20:21:25 2015 New Revision: 285682 URL: https://svnweb.freebsd.org/changeset/base/285682 Log: other fixes to make boot2 compile for IXP... Properly end the asm sections, and for some reason, main needs a prototype... If someone has a better fix, I'm all ears... Pointed out by: Berislav Purgar Modified: head/sys/boot/arm/ixp425/boot2/arm_init.S head/sys/boot/arm/ixp425/boot2/boot2.c Modified: head/sys/boot/arm/ixp425/boot2/arm_init.S == --- head/sys/boot/arm/ixp425/boot2/arm_init.S Sat Jul 18 20:19:51 2015 (r285681) +++ head/sys/boot/arm/ixp425/boot2/arm_init.S Sat Jul 18 20:21:25 2015 (r285682) @@ -43,6 +43,7 @@ ASENTRY_NP(start) /* main should not return. If it does, spin forever */ infiniteLoop: b infiniteLoop +END(start) .Lstart: .word _edata @@ -52,5 +53,6 @@ infiniteLoop: ENTRY(cpu_id) mrc p15, 0, r0, c0, c0, 0 RET +END(cpu_id) /* End */ Modified: head/sys/boot/arm/ixp425/boot2/boot2.c == --- head/sys/boot/arm/ixp425/boot2/boot2.c Sat Jul 18 20:19:51 2015 (r285681) +++ head/sys/boot/arm/ixp425/boot2/boot2.c Sat Jul 18 20:21:25 2015 (r285682) @@ -152,6 +152,8 @@ getstr(int c) } } +int main(void); + int main(void) { ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285681 - head/sys/boot/arm/ixp425/boot2
Author: jmg Date: Sat Jul 18 20:19:51 2015 New Revision: 285681 URL: https://svnweb.freebsd.org/changeset/base/285681 Log: revert r278579, this is in a different compile environment than the kernel, and needs to be named cpu_id... Pointed out by: Berislav Purgar Modified: head/sys/boot/arm/ixp425/boot2/ixp425_board.c Modified: head/sys/boot/arm/ixp425/boot2/ixp425_board.c == --- head/sys/boot/arm/ixp425/boot2/ixp425_board.c Sat Jul 18 19:59:29 2015(r285680) +++ head/sys/boot/arm/ixp425/boot2/ixp425_board.c Sat Jul 18 20:19:51 2015(r285681) @@ -74,7 +74,7 @@ board_init(void) { struct board_config **pbp; - cputype = cpu_ident() & CPU_ID_CPU_MASK; + cputype = cpu_id() & CPU_ID_CPU_MASK; SET_FOREACH(pbp, boards) /* XXX pass down redboot board type */ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285680 - head/sys/kern
Author: kib Date: Sat Jul 18 19:59:29 2015 New Revision: 285680 URL: https://svnweb.freebsd.org/changeset/base/285680 Log: Further cleanup after r285607. Remove useless release semantic for some stores to it_need. For stores where the release is needed, add a comment explaining why. Fence after the atomic_cmpset() op on the it_need should be acquire only, release is not needed (see above). The combination of atomic_cmpset() + fence_acq() is better expressed there as atomic_cmpset_acq(). Use atomic_cmpset() for swi' ih_need read and clear. Discussed with: alc, bde Reviewed by: bde Comments wording provided by: bde Sponsored by: The FreeBSD Foundation MFC after:2 weeks Modified: head/sys/kern/kern_intr.c Modified: head/sys/kern/kern_intr.c == --- head/sys/kern/kern_intr.c Sat Jul 18 18:49:44 2015(r285679) +++ head/sys/kern/kern_intr.c Sat Jul 18 19:59:29 2015(r285680) @@ -830,7 +830,7 @@ ok: * again and remove this handler if it has already passed * it on the list. */ - atomic_store_rel_int(&ie->ie_thread->it_need, 1); + ie->ie_thread->it_need = 1; } else TAILQ_REMOVE(&ie->ie_handlers, handler, ih_next); thread_unlock(ie->ie_thread->it_thread); @@ -897,6 +897,10 @@ intr_event_schedule_thread(struct intr_e * Set it_need to tell the thread to keep running if it is already * running. Then, lock the thread and see if we actually need to * put it on the runqueue. +* +* Use store_rel to arrange that the store to ih_need in +* swi_sched() is before the store to it_need and prepare for +* transfer of this order to loads in the ithread. */ atomic_store_rel_int(&it->it_need, 1); thread_lock(td); @@ -976,7 +980,7 @@ ok: * again and remove this handler if it has already passed * it on the list. */ - atomic_store_rel_int(&it->it_need, 1); + it->it_need = 1; } else TAILQ_REMOVE(&ie->ie_handlers, handler, ih_next); thread_unlock(it->it_thread); @@ -1048,6 +1052,10 @@ intr_event_schedule_thread(struct intr_e * Set it_need to tell the thread to keep running if it is already * running. Then, lock the thread and see if we actually need to * put it on the runqueue. +* +* Use store_rel to arrange that the store to ih_need in +* swi_sched() is before the store to it_need and prepare for +* transfer of this order to loads in the ithread. */ atomic_store_rel_int(&it->it_need, 1); thread_lock(td); @@ -1133,7 +1141,7 @@ swi_sched(void *cookie, int flags) * running it will execute this handler on the next pass. Otherwise, * it will execute it the next time it runs. */ - atomic_store_rel_int(&ih->ih_need, 1); + ih->ih_need = 1; if (!(flags & SWI_DELAY)) { PCPU_INC(cnt.v_soft); @@ -1224,11 +1232,15 @@ intr_event_execute_handlers(struct proc * handlers that have their need flag set. Hardware * interrupt threads always invoke all of their handlers. */ - if (ie->ie_flags & IE_SOFT) { - if (atomic_load_acq_int(&ih->ih_need) == 0) + if ((ie->ie_flags & IE_SOFT) != 0) { + /* +* ih_need can only be 0 or 1. Failed cmpset +* below means that there is no request to +* execute handlers, so a retry of the cmpset +* is not needed. +*/ + if (atomic_cmpset_int(&ih->ih_need, 1, 0) == 0) continue; - else - atomic_store_rel_int(&ih->ih_need, 0); } /* Execute this handler. */ @@ -1326,16 +1338,13 @@ ithread_loop(void *arg) * Service interrupts. If another interrupt arrives while * we are running, it will set it_need to note that we * should make another pass. +* +* The load_acq part of the following cmpset ensures +* that the load of ih_need in ithread_execute_handlers() +* is ordered after the load of it_need here. */ - while (atomic_cmpset_int(&ithd->it_need, 1, 0) != 0) { - /* -* This needs a release barrier to make sure -* that this write posts before any of the -* memory or device accesses in the handlers. -*/ -
svn commit: r285679 - in head/usr.sbin/bsdinstall: partedit scripts
Author: allanjude (doc committer) Date: Sat Jul 18 18:49:44 2015 New Revision: 285679 URL: https://svnweb.freebsd.org/changeset/base/285679 Log: Add support for two workarounds for known issues booting GPT in legacy mode on some hardware For Lenovo laptops with buggy bios (x220, t420, t520): Write the 0xee entry into the second slot in the pmbr instead of the first For some Dell and HP models: The BIOS gives a warning message when booting in legacy mode from a GPT partitioned disk where the 0xee partition in the pmbr is not flagged active For models known to have this problem, mark the pmbr active during installation Use smbios data to identify machines known to be affected by any of the above, and offer the user the option to apply the workaround In bsdinstall's ufs auto mode (autopart partition wizard): Allow users to select which type of partition table to use Keep current defaults: MBR for BIOS, GPT for UEFI This allows users to choose GPT for legacy boot if they wish PR: 184910 PR: 194359 Reviewed by: Michael Dexter Approved by: marcel MFC after:3 days X-MFC-With: r285594 Relnotes: yes Sponsored by: ScaleEngine Inc. Differential Revision:https://reviews.freebsd.org/D3091 Modified: head/usr.sbin/bsdinstall/partedit/gpart_ops.c head/usr.sbin/bsdinstall/partedit/part_wizard.c head/usr.sbin/bsdinstall/partedit/partedit.c head/usr.sbin/bsdinstall/partedit/partedit.h head/usr.sbin/bsdinstall/scripts/auto head/usr.sbin/bsdinstall/scripts/zfsboot Modified: head/usr.sbin/bsdinstall/partedit/gpart_ops.c == --- head/usr.sbin/bsdinstall/partedit/gpart_ops.c Sat Jul 18 16:56:51 2015(r285678) +++ head/usr.sbin/bsdinstall/partedit/gpart_ops.c Sat Jul 18 18:49:44 2015(r285679) @@ -206,12 +206,11 @@ newfs_command(const char *fstype, char * } } -int -gpart_partition(const char *lg_name, const char *scheme) +const char * +choose_part_type(const char *def_scheme) { int cancel, choice; - struct gctl_req *r; - const char *errstr; + const char *scheme = NULL; DIALOG_LISTITEM items[] = { {"APM", "Apple Partition Map", @@ -228,30 +227,61 @@ gpart_partition(const char *lg_name, con "Bootable on Sun SPARC systems", 0 }, }; +parttypemenu: + dialog_vars.default_item = __DECONST(char *, def_scheme); + cancel = dlg_menu("Partition Scheme", + "Select a partition scheme for this volume:", 0, 0, 0, + sizeof(items) / sizeof(items[0]), items, &choice, NULL); + dialog_vars.default_item = NULL; + + if (cancel) + return NULL; + + if (!is_scheme_bootable(items[choice].name)) { + char message[512]; + sprintf(message, "This partition scheme (%s) is not " + "bootable on this platform. Are you sure you want " + "to proceed?", items[choice].name); + dialog_vars.defaultno = TRUE; + cancel = dialog_yesno("Warning", message, 0, 0); + dialog_vars.defaultno = FALSE; + if (cancel) /* cancel */ + goto parttypemenu; + } + + scheme = items[choice].name; + + return scheme; +} + +int +gpart_partition(const char *lg_name, const char *scheme) +{ + int cancel; + struct gctl_req *r; + const char *errstr; + schememenu: if (scheme == NULL) { - dialog_vars.default_item = __DECONST(char *, default_scheme()); - cancel = dlg_menu("Partition Scheme", - "Select a partition scheme for this volume:", 0, 0, 0, - sizeof(items) / sizeof(items[0]), items, &choice, NULL); - dialog_vars.default_item = NULL; + scheme = choose_part_type(default_scheme()); - if (cancel) + if (scheme == NULL) return (-1); - if (!is_scheme_bootable(items[choice].name)) { + if (!is_scheme_bootable(scheme)) { char message[512]; sprintf(message, "This partition scheme (%s) is not " "bootable on this platform. Are you sure you want " - "to proceed?", items[choice].name); + "to proceed?", scheme); dialog_vars.defaultno = TRUE; cancel = dialog_yesno("Warning", message, 0, 0); dialog_vars.defaultno = FALSE; - if (cancel) /* cancel */ + if (cancel) { /* cancel */ + /* Reset scheme so user can choose another */ + scheme = NULL;
svn commit: r285678 - head/sys/dev/mmc
Author: ian Date: Sat Jul 18 16:56:51 2015 New Revision: 285678 URL: https://svnweb.freebsd.org/changeset/base/285678 Log: Deselect the sd card before re-selecting it when working around a problem with some cards that causes them to become deselected after probing for switch capabilities. The old workaround fixes the behavior with some cards, but causes problems with the cards the behave correctly and don't become deselected. Forcing a deselect then reselect appears to work correctly with all cards in initial testing. Modified: head/sys/dev/mmc/mmc.c Modified: head/sys/dev/mmc/mmc.c == --- head/sys/dev/mmc/mmc.c Sat Jul 18 15:28:32 2015(r285677) +++ head/sys/dev/mmc/mmc.c Sat Jul 18 16:56:51 2015(r285678) @@ -1381,17 +1381,18 @@ mmc_discover_cards(struct mmc_softc *sc) } /* -* We reselect the card here. Some cards become -* unselected and timeout with the above two commands, -* although the state tables / diagrams in the standard -* suggest they go back to the transfer state. The only -* thing we use from the sd_status is the erase sector -* size, but it is still nice to get that right. It is -* normally harmless for cards not misbehaving. The -* Atmel bridge will complain about this command timing -* out. Others seem to handle it correctly, so it may -* be a combination of card and controller. +* We deselect then reselect the card here. Some cards +* become unselected and timeout with the above two +* commands, although the state tables / diagrams in the +* standard suggest they go back to the transfer state. +* Other cards don't become deselected, and if we +* atttempt to blindly re-select them, we get timeout +* errors from some controllers. So we deselect then +* reselect to handle all situations. The only thing we +* use from the sd_status is the erase sector size, but +* it is still nice to get that right. */ + mmc_select_card(sc, 0); mmc_select_card(sc, ivar->rca); mmc_app_sd_status(sc, ivar->rca, ivar->raw_sd_status); mmc_app_decode_sd_status(ivar->raw_sd_status, ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285677 - head/sys/netinet
Author: luigi Date: Sat Jul 18 15:28:32 2015 New Revision: 285677 URL: https://svnweb.freebsd.org/changeset/base/285677 Log: fix a typo in a comment Modified: head/sys/netinet/ip_var.h Modified: head/sys/netinet/ip_var.h == --- head/sys/netinet/ip_var.h Sat Jul 18 15:27:12 2015(r285676) +++ head/sys/netinet/ip_var.h Sat Jul 18 15:28:32 2015(r285677) @@ -281,7 +281,7 @@ enum { IPFW_IS_MASK= 0x3000, /* which source ? */ IPFW_IS_DIVERT = 0x2000, IPFW_IS_DUMMYNET =0x1000, - IPFW_IS_PIPE= 0x0800, /* pip1=1, queue = 0 */ + IPFW_IS_PIPE= 0x0800, /* pipe=1, queue = 0 */ }; #define MTAG_IPFW 1148380143 /* IPFW-tagged cookie */ #define MTAG_IPFW_RULE 1262273568 /* rule reference */ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285676 - head/share/man/man4
Author: trasz Date: Sat Jul 18 15:27:12 2015 New Revision: 285676 URL: https://svnweb.freebsd.org/changeset/base/285676 Log: Expand sysctl descriptions in iscsi(4) and ctl(4). MFC after:1 week Sponsored by: The FreeBSD Foundation Modified: head/share/man/man4/ctl.4 head/share/man/man4/iscsi.4 Modified: head/share/man/man4/ctl.4 == --- head/share/man/man4/ctl.4 Sat Jul 18 12:25:47 2015(r285675) +++ head/share/man/man4/ctl.4 Sat Jul 18 15:27:12 2015(r285676) @@ -23,7 +23,7 @@ .\" SUCH DAMAGE. .\" .\" $FreeBSD$ -.Dd July 3, 2015 +.Dd July 11, 2015 .Dt CTL 4 .Os .Sh NAME @@ -100,11 +100,14 @@ Defaults to 1. The number of outstanding commands to advertise to the iSCSI initiator. Technically, it is the difference between ExpCmdSN and MaxCmdSN fields in the iSCSI PDU. +Defaults to 256. .It Va kern.cam.ctl.iscsi.ping_timeout The number of seconds to wait for the iSCSI initiator to respond to a NOP-In PDU. In the event that there is no response within that time the session gets forcibly terminated. +Set to 0 to disable sending NOP-In PDUs. +Defaults to 5. .Sh SEE ALSO .Xr ctladm 8 , .Xr ctld 8 , Modified: head/share/man/man4/iscsi.4 == --- head/share/man/man4/iscsi.4 Sat Jul 18 12:25:47 2015(r285675) +++ head/share/man/man4/iscsi.4 Sat Jul 18 15:27:12 2015(r285676) @@ -23,7 +23,7 @@ .\" SUCH DAMAGE. .\" .\" $FreeBSD$ -.Dd June 20, 2015 +.Dd July 11, 2015 .Dt ISCSI 4 .Os .Sh NAME @@ -77,20 +77,25 @@ The number of seconds to wait for the ta PDU. In the event that there is no response within that time the session gets forcibly restarted. +Set to 0 to disable sending NOP-Out PDUs. +Defaults to 5. .It Va kern.iscsi.iscsid_timeout The number of seconds to wait for -.Xr ctld 8 +.Xr iscsid 8 to establish a session. After that time .Nm will abort and retry. +Defaults to 60. .It Va kern.iscsi.login_timeout The number of seconds to wait for a login attempt to succeed. After that time .Nm will abort and retry. +Defaults to 60. .It Va kern.iscsi.maxtags The maximum number of outstanding IO requests. +Defaults to 255. .It Va kern.iscsi.fail_on_disconnection Controls the behavior after an iSCSI connection has been dropped due to network problems. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r285644 - head/contrib/sqlite3
On 07/18/15 01:26, Bruce Evans wrote: On Fri, 17 Jul 2015, Pedro Giffuni wrote: ... The compiler warning is this: ... ===> lib/libsqlite3 (obj,depend,all,install) cc1: warnings being treated as errors /scratch/tmp/pfg/head/lib/libsqlite3/../../contrib/sqlite3/sqlite3.c: In function 'walIndexWriteHdr': /scratch/tmp/pfg/head/lib/libsqlite3/../../contrib/sqlite3/sqlite3.c:49490: warning: passing argument 1 of 'memcpy' discards qualifiers from pointer target type /scratch/tmp/pfg/head/lib/libsqlite3/../../contrib/sqlite3/sqlite3.c:49492: warning: passing argument 1 of 'memcpy' discards qualifiers from pointer target type --- sqlite3.So --- *** [sqlite3.So] Error code 1 ... make[6]: stopped in /scratch/tmp/pfg/head/lib/libsqlite3 It only happens when using the experimental FORTIFY_SOURCE support [1], and it only happens with gcc (the base one is the only tested). Yes, I am suspecting a compiler bug but gcc has been really useful to find bugs in fortify_source. gcc is correct. This has nothing to do with 'const'. aHdr has a volatile qualifier. OK, I am testing the patch for this. Thanks! Pedro. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285675 - head/etc
Author: trasz Date: Sat Jul 18 12:25:47 2015 New Revision: 285675 URL: https://svnweb.freebsd.org/changeset/base/285675 Log: Remove a comment in the wrong place. MFC after:2 weeks Sponsored by: The FreeBSD Foundation Modified: head/etc/devd.conf Modified: head/etc/devd.conf == --- head/etc/devd.conf Sat Jul 18 12:24:54 2015(r285674) +++ head/etc/devd.conf Sat Jul 18 12:25:47 2015(r285675) @@ -296,7 +296,6 @@ detach 10 { # Button: Button pressed (0 for power, 1 for sleep) # CMBAT: ACPI battery events # Lid: Lid state (0 is closed, 1 is open) -# RCTL:Resource limits # Suspend, Resume: Suspend and resume notification # Thermal: ACPI thermal zone events # ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285674 - head/sbin/devd
Author: trasz Date: Sat Jul 18 12:24:54 2015 New Revision: 285674 URL: https://svnweb.freebsd.org/changeset/base/285674 Log: Document suspend/resume notification in devd.conf(5). MFC after:2 weeks Sponsored by: The FreeBSD Foundation Modified: head/sbin/devd/devd.conf.5 Modified: head/sbin/devd/devd.conf.5 == --- head/sbin/devd/devd.conf.5 Sat Jul 18 12:17:59 2015(r285673) +++ head/sbin/devd/devd.conf.5 Sat Jul 18 12:24:54 2015(r285674) @@ -332,6 +332,10 @@ Battery events. Lid state ($notify=0x00 is closed, 0x01 is open). .It Li PROCESSOR Processor state/configuration ($notify=0x81 is a change in available Cx states). +.It Li Resume +Resume notification. +.It Li Suspend +Suspend notification. .It Li Thermal Thermal zone events. .El ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285673 - head/sbin/devd
Author: trasz Date: Sat Jul 18 12:17:59 2015 New Revision: 285673 URL: https://svnweb.freebsd.org/changeset/base/285673 Log: Add CARP events description to devd.conf(5). MFC after:2 weeks Sponsored by: The FreeBSD Foundation Modified: head/sbin/devd/devd.conf.5 Modified: head/sbin/devd/devd.conf.5 == --- head/sbin/devd/devd.conf.5 Sat Jul 18 12:03:51 2015(r285672) +++ head/sbin/devd/devd.conf.5 Sat Jul 18 12:17:59 2015(r285673) @@ -41,7 +41,7 @@ .\" ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS .\" SOFTWARE. .\" -.Dd May 13, 2015 +.Dd July 11, 2015 .Dt DEVD.CONF 5 .Os .Sh NAME @@ -336,6 +336,26 @@ Processor state/configuration ($notify=0 Thermal zone events. .El .Pp +.It Li CARP +Events related to the +.Xr carp 8 +protocol. +.Bl -tag -width ".Sy Subsystem" -compact +.It Sy Subsystem +.It Ar vhid@interface +The +.Dq subsystem +contains the actual CARP vhid and the name of the network interface +on which the event took place. +.Bl -tag -width ".Li MASTER" -compact +.It Sy Type +.It Li MASTER +Node become the master for a virtual host. +.It Li BACKUP +Node become the backup for a virtual host. +.El +.El +.Pp .It Li IFNET Events related to the network subsystem. .Bl -tag -width ".Sy Subsystem" -compact ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285672 - head/usr.sbin/fstyp
Author: trasz Date: Sat Jul 18 12:03:51 2015 New Revision: 285672 URL: https://svnweb.freebsd.org/changeset/base/285672 Log: fstyp(8) ships with 10.2. MFC after:3 days Sponsored by: The FreeBSD Foundation Modified: head/usr.sbin/fstyp/fstyp.8 Modified: head/usr.sbin/fstyp/fstyp.8 == --- head/usr.sbin/fstyp/fstyp.8 Sat Jul 18 12:03:17 2015(r285671) +++ head/usr.sbin/fstyp/fstyp.8 Sat Jul 18 12:03:51 2015(r285672) @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd June 15, 2015 +.Dd July 11, 2015 .Dt FSTYP 8 .Os .Sh NAME @@ -116,7 +116,7 @@ type is not recognized. The .Nm command appeared in -.Fx 11.0 . +.Fx 10.2 . .Sh AUTHORS The .Nm ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285671 - head/usr.sbin/uefisign
Author: trasz Date: Sat Jul 18 12:03:17 2015 New Revision: 285671 URL: https://svnweb.freebsd.org/changeset/base/285671 Log: uefisign(8) ships with 10.2. MFC after:3 days Sponsored by: The FreeBSD Foundation Modified: head/usr.sbin/uefisign/uefisign.8 Modified: head/usr.sbin/uefisign/uefisign.8 == --- head/usr.sbin/uefisign/uefisign.8 Sat Jul 18 09:02:50 2015 (r285670) +++ head/usr.sbin/uefisign/uefisign.8 Sat Jul 18 12:03:17 2015 (r285671) @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd December 10, 2014 +.Dd July 11, 2015 .Dt UEFISIGN 8 .Os .Sh NAME @@ -84,7 +84,7 @@ View signature: The .Nm command appeared in -.Fx 11.0 . +.Fx 10.2 . .Sh AUTHORS The .Nm ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r285664 - in head/sys: kern sys
On Sat, 18 Jul 2015, Mark Johnston wrote: Log: Pass the lock object to lockstat_nsecs() and return immediately if LO_NOPROFILE is set. Some timecounter handlers acquire a spin mutex, and we don't want to recurse if lockstat probes are enabled. It is an error to call timecounter code from a low-level place like the mutex implementation. This workaround depends on all locks in timecounter handlers being LO_NOPROFILE, and that breaks profiling of these locks. The breakage is largest if the locks are used for more than timecounters. E.g., the one for i386's obsolescent i8254 timer has to be used for all accesses to the i8254. This lock is configured as MTX_SPIN | MTX_NOPROFILE and is perhaps the main one fixed by this commit. KTR handles this problem badly in a different way. It abuses get_cyclecount(). The abuse is parametrized by defining KTR_TIME as get_cyclecount() and using KTR_TIME. The definition of KTR_TIME is ifdefed but not in a usable way. This is of course undocumented, and KTR_TIME is not a normal kernel option so it is hard to define in config files. KTR needs to be about as careful about this as lockstat since it is called from low level mutex code for debugging. I think there is nothing like LO_NOPROFILE to turn it off. Of course you can turn off the mutex code's calls to it using MTX_QUIET or MTX_NOWITNESS, but this breaks much more than lock profiling. (I rarely use any lock debugging, but when I did I found it useful to use it without WITNESS_SKIPSPIN and with MTX_QUIET and MTX_NOWITNESS turned off for the locks being debugged. Some console drivers use spinlocks with MTX_QUIET or MTX_NOWITNESS to avoid various problems, and this breaks witnessing of them even for non-console uses. Unbreaking their witnessing uncovered further bugs.) Abusing get_cyclecount() in KTR doesn't even fix the problem with timecounters, since some implementations of get_cyclecount() (some arm, some i386) use the timecounter. Other bugs with using get_cyclecount(): - even if it returns cycles counted by a clock, the frequency of this clock is unknown/unobtainable, so there is no way to convert to human-readable units - some arches return a shifted binuptime() that wraps very quickly (256 seconds for arm with ARM_ARCH < 6). Such counters cannot be monotonic. - some arches (arm again?) used to use binuptime() with swizzling more complicated than shifting. Their counters were further from being monotonic. - arm is now the only arch that uses binuptime() at a low level. arm64 use a stub that returns 1. ARM_ARCH < 6 does the above. i386 returns cpu_ticks(). This is the correct method. It uses the hardware counter use by cpu_ticks() if possible, else the raw value of the current hardware timecounter, adjusted to avoid wrap. (This is not actually a correct method, since its implementation is no good. The wrap adjustment is down with no locking. Also, switching the timecounter hardware breaks the get_cyclecount() use even more than the thread resource usage use. The latter has incomplete recalibration.) - KTR of course has no support for converting to human-readable units. ktrdump prints raw timestamps and their differences in %16ju format. kern_ktr.c seems to print them only in a ddb command. This prints the raw value in the much worse format %10.10lld. This uses the long long abomination and has a sign error (ktr_timestamp has type uint64_t). - ktr's "timestamps" are thus at best a cookie that increases strictly monotonically - get_cyclecount() is always rdtsc() on modern x86. rdtsc() is not a serializing instruction. I recently learned how unserial it can be -- hundreds of cycles on freefall. The hundred-cycle case probably doesn't happen much in KTR's use. It happens in the test program when the program spins waiting for something and executes rdtsc() after that, or so it thinks. The CPU actually executes rdtsc() speculatively hundreds of cycles earlier while spinning. Back to back rdtsc()s seem to be executed in order on freefall, and the speculation seems to extend to only the first one. So there is a good chance that get_cyclecount() called on the same CPU gives a strictly increasing value. But across CPUs, the hundred-cycle difference are the usual case if there is no synchronization of the threads (even when the TSCs on the different CPUs are perfectly synchronized at the hardware level). - get_cyclecount() doesn't bother with synchronization if it uses the TSC (or equivalent). This is a feature. It is supposed to be efficient even if this requires it to return garbage. But this makes it unusable for almost everything. Certainly for timestamps. - get_cyclecount()'s documentation has rotted to match its misuse. It is now documented as returning a value that is monotonically increasing inside each CPU. But it never obviously did that on x86 (rdtsc isn't a serializing instruction, and
Re: svn commit: r285664 - in head/sys: kern sys
On 18/07/2015 03:57, Mark Johnston wrote: > Author: markj > Date: Sat Jul 18 00:57:30 2015 > New Revision: 285664 > URL: https://svnweb.freebsd.org/changeset/base/285664 > > Log: > Pass the lock object to lockstat_nsecs() and return immediately if > LO_NOPROFILE is set. Some timecounter handlers acquire a spin mutex, and > we don't want to recurse if lockstat probes are enabled. > > PR: 201642 > Reviewed by:avg > MFC after: 3 days Mark, thank you very much for this fix and a couple of others! -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random s
CC’ing to original lists. Kip’s problem has come to conclusion, and our final (private) email is forwarded to the lists with permission. It should be noted that Kip was importing CURRENT to a fork of FreeBSD, and there was a potential merging problem that may have caused a link failure. M > On 17 Jul 2015, at 23:14, K. Macy wrote: > > On Fri, Jul 17, 2015 at 3:01 PM, Mark R V Murray wrote: >> >>> On 17 Jul 2015, at 22:39, K. Macy wrote: >>> Like I said, the linking issue isn't a concern. My problem is that >>> it's not booting because it hangs in an uninterruptible sleep in dd. >>> In addition, I strongly disagree with a change that by default could >>> adversely impact network performance. >> >> I’ve agreed that the fact that it is uninterruptible is cause for >> concern, and I’ve now coded but not tested or committed a fix. >> > > Glad to hear it. > >> The fact that RANDOM_DUMMY never unblocks is a feature not a bug. > > I don't recall having suggested otherwise. Returning with no entropy > would be undesirable. But as you now, presumably, realize - having the > reader be unkillable as a result of this wait is highly undesirable. > > >>> If you say that you've tested RANDOM_DUMMY and it works for you then I >>> guess I'm on my own. >> >> RANDOM_DUMMY is for folks who don’t want a CSPRNG. It sounds like you >> need one. > > Yes. I had already reached the obvious conclusion that enabling > fortuna would have bypassed all this grief. > > > Cheers. > > -K > -- Mark R V Murray ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r285670 - in head: lib/libc/sys lib/libkvm sys/compat/cloudabi sys/compat/linux sys/compat/svr4 sys/fs/procfs sys/kern sys/sys
Author: kib Date: Sat Jul 18 09:02:50 2015 New Revision: 285670 URL: https://svnweb.freebsd.org/changeset/base/285670 Log: The si_status field of the siginfo_t, provided by the waitid(2) and SIGCHLD signal, should keep full 32 bits of the status passed to the _exit(2). Split the combined p_xstat of the struct proc into the separate exit status p_xexit for normal process exit, and signalled termination information p_xsig. Kernel-visible macro KW_EXITCODE() reconstructs old p_xstat from p_xexit and p_xsig. p_xexit contains complete status and copied out into si_status. Requested by: Joerg Schilling Reviewed by: jilles (previous version), pho Tested by:pho Sponsored by: The FreeBSD Foundation Modified: head/lib/libc/sys/wait.2 head/lib/libkvm/kvm_proc.c head/sys/compat/cloudabi/cloudabi_proc.c head/sys/compat/linux/linux_fork.c head/sys/compat/linux/linux_misc.c head/sys/compat/svr4/svr4_misc.c head/sys/fs/procfs/procfs_ctl.c head/sys/fs/procfs/procfs_ioctl.c head/sys/kern/kern_event.c head/sys/kern/kern_exec.c head/sys/kern/kern_exit.c head/sys/kern/kern_kthread.c head/sys/kern/kern_proc.c head/sys/kern/kern_sig.c head/sys/kern/sys_procdesc.c head/sys/kern/sys_process.c head/sys/sys/proc.h head/sys/sys/wait.h Modified: head/lib/libc/sys/wait.2 == --- head/lib/libc/sys/wait.2Sat Jul 18 06:48:30 2015(r285669) +++ head/lib/libc/sys/wait.2Sat Jul 18 09:02:50 2015(r285670) @@ -362,6 +362,15 @@ field set to and the .Fa si_pid field set to the process ID of the process reporting status. +For the exited process, the +.Fa si_status +field of the +.Dv siginfo_t +structure contains the full 32 bit exit status passed to +.Xr _exit 2 ; +the +.Fa status +argument of other calls only returns 8 lowest bits of the exit status. .Pp When the .Dv WNOHANG @@ -656,13 +665,6 @@ is an extension; .Tn POSIX only permits this flag with .Fn waitid . -.Pp -.Tn POSIX -requires -.Fn waitid -to return the full 32 bits passed to -.Xr _exit 2 ; -this implementation only returns 8 bits like the other calls. .Sh HISTORY The .Fn wait Modified: head/lib/libkvm/kvm_proc.c == --- head/lib/libkvm/kvm_proc.c Sat Jul 18 06:48:30 2015(r285669) +++ head/lib/libkvm/kvm_proc.c Sat Jul 18 09:02:50 2015(r285670) @@ -66,6 +66,8 @@ __FBSDID("$FreeBSD$"); #include #include #include +#define_WANT_KW_EXITCODE +#include #include #include #include @@ -389,7 +391,7 @@ nopgrp: kp->ki_siglist = proc.p_siglist; SIGSETOR(kp->ki_siglist, mtd.td_siglist); kp->ki_sigmask = mtd.td_sigmask; - kp->ki_xstat = proc.p_xstat; + kp->ki_xstat = KW_EXITCODE(proc.p_xexit, proc.p_xsig); kp->ki_acflag = proc.p_acflag; kp->ki_lock = proc.p_lock; if (proc.p_state != PRS_ZOMBIE) { Modified: head/sys/compat/cloudabi/cloudabi_proc.c == --- head/sys/compat/cloudabi/cloudabi_proc.cSat Jul 18 06:48:30 2015 (r285669) +++ head/sys/compat/cloudabi/cloudabi_proc.cSat Jul 18 09:02:50 2015 (r285670) @@ -57,7 +57,7 @@ cloudabi_sys_proc_exit(struct thread *td struct cloudabi_sys_proc_exit_args *uap) { - exit1(td, W_EXITCODE(uap->rval, 0)); + exit1(td, uap->rval, 0); /* NOTREACHED */ } Modified: head/sys/compat/linux/linux_fork.c == --- head/sys/compat/linux/linux_fork.c Sat Jul 18 06:48:30 2015 (r285669) +++ head/sys/compat/linux/linux_fork.c Sat Jul 18 09:02:50 2015 (r285670) @@ -398,7 +398,7 @@ linux_exit(struct thread *td, struct lin * exit via pthread_exit() try thr_exit() first. */ kern_thr_exit(td); - exit1(td, W_EXITCODE(args->rval, 0)); + exit1(td, args->rval, 0); /* NOTREACHED */ } Modified: head/sys/compat/linux/linux_misc.c == --- head/sys/compat/linux/linux_misc.c Sat Jul 18 06:48:30 2015 (r285669) +++ head/sys/compat/linux/linux_misc.c Sat Jul 18 09:02:50 2015 (r285670) @@ -1839,7 +1839,7 @@ linux_exit_group(struct thread *td, stru * SIGNAL_EXIT_GROUP is set. We ignore that (temporarily?) * as it doesnt occur often. */ - exit1(td, W_EXITCODE(args->error_code, 0)); + exit1(td, args->error_code, 0); /* NOTREACHED */ } Modified: head/sys/compat/svr4/svr4_misc.c == --- head/sys/compat/svr4/svr4_misc.cSat Jul 18 06:48:30 2015 (r285669) +++ head/sys/compat/