Re: netmap: extension to store user data per packet/slot?
Hi Luigi, On 12 Nov 2014, at 00:00, Luigi Rizzo ri...@iet.unipi.it wrote: apparently you want some user-defined metadata to move along with the packet, but i do not think it is reasonable to put it in the slots. If we do that, what about timestamps, flow IDs, interface and queue index and all the rest of the things that we normally find in an mbuf/skbuf ? This is not going to scale. that's true. I'm only suggesting a small extension to be used freely, but would never consider increasing the slot size beyond 32 bytes in any case. Keeping it sleek is obviously important. Also consider that at some point you may use a different arrangement (with packets passed along VALE switches or physical interfaces etc.) i believe the most reasonable place to put the extra info is at the end of the packet and possibly bump the length in the slot so you are safe in case the packet is copied. I dont believe dirtying the cache lines in the actual packet buffer is a wise choice, but it certainly works. There is no timestamp appended to the packet at the moment, it was a feature i thought somebody may want to have, but between the relative scarcity of hardware that provides per-packet timestamps, and the questionable usefulness of the same, i doubt it will be available. It is a useful feature to have receive timestamps per packet for better accounting, but I can see it being too mystical in its current form inside the packet buffer. It's still in my TODO list to investigate the impact, but a system certainly works without that extra bit of resolution. For now, I'll go with Adrians suggestion and keep track of the buffer index inside the first process away from netmap(4) itself. This setup breaks for non-circular pipe arrangements, but the load-balancing use case at hand is alright. Cheers, Franco ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
New LOR's concerning zfs.
Recently I've installed current in an unusual configuration: root ZFS pool on an USB stick, without any partitioning. It works good, but quite often throws three different LORs, all related to ZFS subsystem. I suspect this is due to the irregular timing pattern of the USB access, and I couldn't find them in the list of known LORs. Hope this would help further integration of ZFS in kernel. Details please see below. Valentin Davydov. uname -a FreeBSD white.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r274379: Tue Nov 11 14:35:45 UTC 2014 root@white.local:/usr/obj/usr/src/sys/GENERIC amd64 LORs themselves: lock order reversal: 1st 0xf80009382d50 syncer (syncer) @ /White/usr/src/sys/kern/vfs_subr.c:1756 2nd 0xf8002d9dfb78 zfs (zfs) @ /White/usr/src/sys/kern/vfs_subr.c:2144 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00857186d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0085718780 witness_checkorder() at witness_checkorder+0xdad/frame 0xfe0085718810 __lockmgr_args() at __lockmgr_args+0x9a4/frame 0xfe0085718940 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe0085718960 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe0085718990 _vn_lock() at _vn_lock+0xaa/frame 0xfe0085718a00 vget() at vget+0x67/frame 0xfe0085718a40 vfs_msync() at vfs_msync+0xa7/frame 0xfe0085718aa0 sync_fsync() at sync_fsync+0xcc/frame 0xfe0085718ae0 VOP_FSYNC_APV() at VOP_FSYNC_APV+0xf7/frame 0xfe0085718b10 sched_sync() at sched_sync+0x34b/frame 0xfe0085718bb0 fork_exit() at fork_exit+0x84/frame 0xfe0085718bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0085718bf0 --- trap 0, rip = 0, rsp = 0xfe0085718cb0, rbp = 0 --- lock order reversal: 1st 0xf80007c9cd50 zfs (zfs) @ /White/usr/src/sys/kern/vfs_mount.c:1223 2nd 0xf80007c9d5f0 devfs (devfs) @ /White/usr/src/sys/kern/vfs_subr.c:2144 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00859b63c0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00859b6470 witness_checkorder() at witness_checkorder+0xdad/frame 0xfe00859b6500 __lockmgr_args() at __lockmgr_args+0x9a4/frame 0xfe00859b6630 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe00859b6650 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe00859b6680 _vn_lock() at _vn_lock+0xaa/frame 0xfe00859b66f0 vget() at vget+0x67/frame 0xfe00859b6730 devfs_allocv() at devfs_allocv+0xfd/frame 0xfe00859b6780 devfs_root() at devfs_root+0x43/frame 0xfe00859b67b0 vflush() at vflush+0x73/frame 0xfe00859b6900 devfs_unmount() at devfs_unmount+0x38/frame 0xfe00859b6930 dounmount() at dounmount+0x424/frame 0xfe00859b69b0 sys_unmount() at sys_unmount+0x2ec/frame 0xfe00859b6ae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe00859b6bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00859b6bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80089213a, rsp = 0x7fffe468, rbp = 0x7fffe580 --- lock order reversal: 1st 0xf800102ad038 filedesc structure (filedesc structure) @ /White/usr/src/sys/kern/kern_descrip.c:1218 2nd 0xf8007abb35f0 zfs (zfs) @ /White/usr/src/sys/kern/vfs_subr.c:4411 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe022d790590 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe022d790640 witness_checkorder() at witness_checkorder+0xdad/frame 0xfe022d7906d0 __lockmgr_args() at __lockmgr_args+0x9a4/frame 0xfe022d790800 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe022d790820 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xfc/frame 0xfe022d790850 _vn_lock() at _vn_lock+0xaa/frame 0xfe022d7908c0 knlist_remove_kq() at knlist_remove_kq+0x82/frame 0xfe022d7908f0 filt_vfsdetach() at filt_vfsdetach+0x28/frame 0xfe022d790910 knote_fdclose() at knote_fdclose+0xc7/frame 0xfe022d790960 closefp() at closefp+0x65/frame 0xfe022d7909a0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe022d790ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe022d790ab0 --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80165c2ca, rsp = 0x7fffdfbfbef8, rbp = 0x7fffdfbfbf10 --- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273918 buildworld broke at semaphore
On Tuesday, November 11, 2014 4:22:05 pm Henry Hu wrote: On Tue, Nov 11, 2014 at 1:33 PM, John Baldwin j...@freebsd.org wrote: On Friday, October 31, 2014 4:08:06 pm Beeblebrox wrote: First breakage in a long time. Error is: In file included from cancelpoints_sem_new.c:47: /usr/src/lib/libc/../../include/semaphore.h:41:16: error: field has incomplete type 'struct _usem2' struct _usem2 _kern; ^ /usr/src/lib/libc/../../include/semaphore.h:41:9: note: forward declaration of 'struct _usem2' struct _usem2 _kern; ^ cancelpoints_sem_new.c:66:33: error: use of undeclared identifier 'USEM_MAX_COUNT' _Static_assert(SEM_VALUE_MAX = USEM_MAX_COUNT, SEM_VALUE_MAX too large); ^ cancelpoints_sem_new.c:335:15: warning: implicit declaration of function 'USEM_COUNT' is invalid in C99 [-Wimplicit-function-declaration] *sval = (int)USEM_COUNT(sem-_kern._count); ^ cancelpoints_sem_new.c:342:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAKE' return _umtx_op(sem, UMTX_OP_SEM2_WAKE, 0, NULL, NULL); ^ cancelpoints_sem_new.c:361:23: error: use of undeclared identifier 'UMTX_OP_SEM2_WAIT' return _umtx_op(sem, UMTX_OP_SEM2_WAIT, 0, ^ cancelpoints_sem_new.c:445:14: error: use of undeclared identifier 'USEM_HAS_WAITERS' if (count USEM_HAS_WAITERS) ^ 1 warning and 5 errors generated. Seems like your tree is not fully up to date? The changes to sem_new.c were committed in the same commit as the changes to sys/umtx.h. Maybe it's another problem. buildworld may be picking up umtx.h from /usr/include which is the old version. 'make buildworld' should always populate an include tree under /usr/obj that is used instead of /usr/include. If this wasn't correct, then every change to add new constants, etc. to any header installed to /usr/include would fail to build. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r273918 buildworld broke at semaphore
I solved this problem about 4 hours ago and posted through the Nabble interface. My email is not posting to the mail list, and stil shows as not-accepted - there's some sort of problem there... Regards. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: netmap: extension to store user data per packet/slot?
On Tue, Nov 11, 2014 at 10:13:54PM +0100, Franco Fichtner wrote:
Hi Luigi,
hi all,
so I was running into logistics issues with netmap(4)
with regard to zero-copy and redirection through pipes:
working on a load-balancing framework revealed that it
is very hard to track a packet's origins to later move
it onward to the respective outgoing interface, be it
another device or the host stack.
Long story short: user data needs to be stored for the
packet buffer or slot.
I think need configurable (by sysctl) space recerved before packet.
This is may be used as user data. Or for insert VLAN/MPLS/QinQ/etc
headers.
More general: tilera have good api for this.
There are three ways that I can see so far:
(1) Allocate a netmap pipe pair for each interface,
in case of transparent mode also a pipe for the
host stack each. That's a lot of pipes and
most likely insane, but it won't extend the ABI.
(2) Store the additional data in the actual buffer.
That is sort of ok, but seems sluggish WRT cache
behaviour -- maybe the buffer won't be read but
it needs to be written. Sure, we can store it at
the end, but there already resides the packet
timestamp if enabled (if I recall correctly).
Wouldn't extend the ABI per se, but might collide
with the timestamping
(3) Make room in struct netmap_slot itself like this:
diff --git a/sys/net/netmap.h b/sys/net/netmap.h
index 15ebf73..d0a9c0e 100644
--- a/sys/net/netmap.h
+++ b/sys/net/netmap.h
@@ -147,6 +147,7 @@ struct netmap_slot {
uint16_t len; /* length for this slot */
uint16_t flags; /* buf changed, etc. */
uint64_t ptr; /* pointer for indirect buffers */
+ uint64_t userdata; /* reserved storage for caller */
};
It could also be broken down in two fields with uint32_t
each; not sure what would be more sensible. This of course
requires an API bump, although it should be backwards
compatible.
Any feedback on this is highly appreciated.
Cheers,
Franco
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CFR: AES-GCM and OpenCrypto work review
Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 21:20 +: On 08/11/14 20:45, John-Mark Gurney wrote: Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +: On 08/11/14 04:23, John-Mark Gurney wrote: Hello, Over the last few months, I've been working on a project to add support for AES-GCM and AES-CTR modes to our OpenCrypto framework. The work is sponsored by The FreeBSD Foundation and Netgate. I plan on committing these patches early next week. If you need more time for review, please email me privately and I will make delay. The code has already been reviewed by Watson Ladd (the software crypto implementations) and Trevor Perrin (the aesni module part) and I have integrated these changes into the patch. There are two patches, one is the changes for OpenCrypto and the test framework. The other is the data files used by the test framework. The data is from NIST's CAVP program, and is about 20MB worth of test vectors. (I just realized, should we look at compressing these on disk?) Main patch (192KB): https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch Data files (~20MB): https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch A list of notable changes in the patch: - Replacing crypto(4) w/ NetBSD's version + updates - Lots of man page updates, including CIOCFINDDEV and crypto(7) which adds specifics about restrictions on the modes. - Allow sane useage of both _HARDWARE and _SOFTWARE flags. - Add a timing safe bcmp for MAC comparision. - Add a software implementation of GCM that uses a four bit lookup table with parallelization. This algorithm is possibly vulnerable to timing attacks, but best known mitigation methods are used. Using a timing safe version is many times slower. - Added a CRYPTDEB macro that defaults to off. - Bring in some of OpenBSD's improvements to the OpenCrypto framework. - If an mbuf passed to the aesni module is only one segment, don't do a copy. This needs to be improved to support segmented buffers. - Remove the CRYPTO_F_REL flag. It was meaningless. It was used but did not change any behavior. - Add function crypto_mbuftoiov to convert an mbuf to an iov. This also converts the software crypto to only use iov's even for a simple linear buffer, and so simplifies the processing. - Add a dtrace probe for errors from the ioctl. - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing) of AES-GCM and future AEAD modes. Future improvements: - Support IV's longer than 12 bytes for GCM. - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented inputs don't have to be copied. I have the question regarding to the algorithm of GF field calculations used in the proposed implementation: why not use the recent researches in GCM calculations, e.g. described in [1], for further speed optimizations? [1] - https://eprint.iacr.org/2013/157.pdf The paper you linked to does not describe a new way of calculating GHASH, but evalutation of a bug in their implementation using the PCLMULQDQ instruction... If you mean, why don't I use OpenSSL's code? The reason is that their code is a perl script that generates assmebly... We don't have perl in base.. and I didn't want more assembly in our tree (see below).. Instead, I decided to use code from Intel's whitepaper: Intel® Carry-Less Multiplication Instruction and its Usage for Computing the GCM Mode I didn't use their assembly version because I wanted to have maintainable code, and also the same code can be used on both i386 and amd64 arches.. This turns out to also be a good thing, as when I add segmented buffer support, it'll be much easier to add to the C version, and I only have to do the work once for two arches... Also, the software GF library that I wrote is using state of the art algorithms... An OpenBSD developer has tested my code and has seen a significant performance improvement over their old code, and are evaluating if they want to/can include it in their tree... Hope this answers your question. If not, please be more specific so I can answer it. I'm sorry, I thought that is the paper that is a transcript of the following presentation: http://2013.diac.cr.yp.to/slides/gueron.pdf made by the same authors. The transcript is not available so far it seems. And regarding assembler/C maintainability I would argue that the current intrinsics based implementation is more readable than the pure assembler solution (and it is still machine dependent). Of course, I'm not the expert in such optimizations, so that is just my own feeling. By the way, do you have some concrete numbers about the performance of your aes-gcm? (I recently could do aes-128-gcm at about 32 gigabits/sec that is not a limit of the modern hardware for sure). So, in bare metal userland testing, iirc, I was able to get around 1GByte/sec on a
Re: netmap: extension to store user data per packet/slot?
On Wed, Nov 12, 2014 at 11:16 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Nov 11, 2014 at 10:13:54PM +0100, Franco Fichtner wrote: Hi Luigi, hi all, so I was running into logistics issues with netmap(4) with regard to zero-copy and redirection through pipes: working on a load-balancing framework revealed that it is very hard to track a packet's origins to later move it onward to the respective outgoing interface, be it another device or the host stack. Long story short: user data needs to be stored for the packet buffer or slot. I think need configurable (by sysctl) space recerved before packet. This is may be used as user data. Or for insert VLAN/MPLS/QinQ/etc headers. this is yet another requirement: not just metadata but also encapsulation. For the records, the VALE switch does have TSO support (implemented through the VHOST header) so that VMs can pass large segments across a switch and they are properly split when traffic goes to a physical interface or a port that does not support the header. We also support scatter-gather I/O at least on the switch (haven't implemented this feature yet on NICs). But please consider that following this route we end up more or less into the same complications that afflict the standard stack: everything is configurable and decided at runtime, and the code becomes a maze of conditionals or indirect function calls with little chance of optimisations. Also, it's not that one sysctl works for all cases. Different ports typically have different encapsulation sizes, NICs may have alignment constraints (even those who don't suffer if buffers not 64-byte aligned), so you'll end up with scatter-gather I/O or copying anyways. After two years of experience with netmap i am not so sure anymore that zero copy makes much sense, except perhaps for the case of large packets (but i am not so sure about that, either). Apart from benchmarks, if you want to do something useful with the packets you need to read the header, at which point the concerns on having data in cache or not are less significant and the cost of the copy is heavily reduced. Tracking ownership of buffers (which is needed for zero copy) is also expensive even when they are not shared (and we have great trouble in managing the extra buffers we recently added to the netmap API to support zero-copy, to the point that I am tempted to remove the feature. cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
shutdown or acpi problem
I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? Are you upgrading from a pre-r273872 world, and if so, did you run make delete-old first ( http://svnweb.freebsd.org/base?view=revisionrevision= )? Cheers! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? Note booting /boot/kernel.old/kernel and then using 'shutdown -p now' works as expected. The old kernel was bulit from r271492 sources. Any guidance on where to start to debug this issue would be welcomed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 03:12:46PM -0800, NGie Cooper wrote: On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? Are you upgrading from a pre-r273872 world, and if so, did you run make delete-old first ( http://svnweb.freebsd.org/base?view=revisionrevision= )? Cheers! ___ I run 'make delete-old' and 'make delete-old-libs' after each installworld. In this case, I was upgrading from r271492 to r274273. The procedure I use is cd /usr/obj rm -rf * cd /usr/src svn update make buildworld make buildkernel make installkernel mergemaster -p (may or may not boot to single user mode here) make installworld mergemaster -iU make delete-old make delete-old-libs shutdown -r +1 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
building stable/10 on -current
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On current r273808, make buildworld in a stable/10 tree fails with: building shared library libc.so.7 /usr/bin/ld: _umtx_unlock.So: relocation R_X86_64_32 against `SYS__umtx_unlock' can not be used when making a shared object; recompile with -fPIC _umtx_unlock.So: could not read symbols: Bad value However, poudriere can build it just fine in its jail. I am curious why that is. Can a -current host be made to build stable/10, or is that impossible? Thanks, Russell -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUY/LeAAoJEFnLrGVSDFaE0IEQAJ3PMZduxTkNpTp8jVTQjPQO L7Ngzp46qpsuIIPDJ2mwFwKUC5R5qA9nh2oHgt0RTJjGYXpj5k7K5PN2Qt/0jZnf sLt6ju05cTfF1gPch1hD54N9ADG2MIiXs+Fa4CI/GiROwP+AWesI+Ri71E8SBqqn yjZF4QLP1S4QlKuhHrsSv2REUj/lv7qmJyxuih9HePJIIvUHguvy/5imKD/3WSxX 6MO1JjEneKvI3lGMcAV15/6z13GPHaj/vCZZ7lGfthHvYUWqtalRx9S3XM3AUgNq MKk2U5L9lAf346RTbVRv/ff3N61+3ahBJ1StJNMetk80WtmokTvAuKC4y8Ywrr8e GiLrYoPm6rPTlEj87/QHTBSg/uiXogI14vcRs/npiS2Uw2B8k6iXOxQxpnNiedqA xkc310MJCSUuB/1p5HC+gU3rIw8k+gEmVVCW9yx/rcdKCm6wLG/h9yGeA0/gI1nb QCTwLvOcq+mjQgH/AQlBm+s0otT4nonU93dcpxRwW/0F1D5zBIqzGzm66O6Gh83Z vgZMXHgfVr1FAer03vRHQjRWYl0CcaQ4DnaIXmJHz+m39x+/C3IFIeuBt9LIu1rM GBdml6+nbAK0B6UahbdpRQfadha5gZ1QKap4Fy2oO9XlR4ovTYcqLzNfHTfANd2Q mBnfMYYLqVY0UzI3hzqu =T1Ia -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown or acpi problem
On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote On Wed, Nov 12, 2014 at 03:12:46PM -0800, NGie Cooper wrote: On Wed, Nov 12, 2014 at 2:42 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? Are you upgrading from a pre-r273872 world, and if so, did you run make delete-old first ( http://svnweb.freebsd.org/base?view=revisionrevision= )? Cheers! ___ I run 'make delete-old' and 'make delete-old-libs' after each installworld. In this case, I was upgrading from r271492 to r274273. The procedure I use is cd /usr/obj Can I throw a chflags -R noschg * here first? Point being, you may well not have gotten everything, otherwise. :) rm -rf * cd /usr/src svn update make buildworld make buildkernel make installkernel mergemaster -p (may or may not boot to single user mode here) make installworld mergemaster -iU make delete-old make delete-old-libs shutdown -r +1 -- Steve --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote: On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote I run 'make delete-old' and 'make delete-old-libs' after each installworld. In this case, I was upgrading from r271492 to r274273. The procedure I use is cd /usr/obj Can I throw a chflags -R noschg * here first? Point being, you may well not have gotten everything, otherwise. :) It's not needed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown or acpi problem
On Wed, 12 Nov 2014 18:08:52 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote: On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote I run 'make delete-old' and 'make delete-old-libs' after each installworld. In this case, I was upgrading from r271492 to r274273. The procedure I use is cd /usr/obj Can I throw a chflags -R noschg * here first? Point being, you may well not have gotten everything, otherwise. :) It's not needed. How so? It's been necessary for as long as I can remember. Just to confirm, I looked to see if anything had changed: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html seems not. Do note; I'm not trying to be argumentative. Just don't see where it's not true (needed). :) --Chris -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 6:27 PM, Chris H bsd-li...@bsdforge.com wrote: ... How so? It's been necessary for as long as I can remember. Just to confirm, I looked to see if anything had changed: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html seems not. Do note; I'm not trying to be argumentative. Just don't see where it's not true (needed). :) It's technically not needed with -DNO_CLEAN (it's handled in Makefile.inc1), however if you're doing that you might as well not specify NO_CLEAN: http://svnweb.freebsd.org/base/head/Makefile.inc1?view=annotate#l481 Cheers! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 6:43 PM, NGie Cooper yaneurab...@gmail.com wrote: On Wed, Nov 12, 2014 at 6:27 PM, Chris H bsd-li...@bsdforge.com wrote: ... How so? It's been necessary for as long as I can remember. Just to confirm, I looked to see if anything had changed: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html seems not. Do note; I'm not trying to be argumentative. Just don't see where it's not true (needed). :) It's technically not needed with -DNO_CLEAN (it's handled in Makefile.inc1), however if you're doing that you might as well not specify NO_CLEAN: http://svnweb.freebsd.org/base/head/Makefile.inc1?view=annotate#l481 My apologies... I was thinking of another build process. Yes, it's very much required according to the process noted in the handbook. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 06:27:13PM -0800, Chris H wrote: On Wed, 12 Nov 2014 18:08:52 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote On Wed, Nov 12, 2014 at 06:03:43PM -0800, Chris H wrote: On Wed, 12 Nov 2014 15:26:55 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote I run 'make delete-old' and 'make delete-old-libs' after each installworld. In this case, I was upgrading from r271492 to r274273. The procedure I use is cd /usr/obj Can I throw a chflags -R noschg * here first? Point being, you may well not have gotten everything, otherwise. :) It's not needed. How so? It's been necessary for as long as I can remember. Just to confirm, I looked to see if anything had changed: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html seems not. Do note; I'm not trying to be argumentative. Just don't see where it's not true (needed). :) It not needed. % su root % script Script started on Wed Nov 12 18:54:16 2014 troutmask:root[201] cd /usr/obj troutmask:root[202] ls usr/ troutmask:root[203] rm -rf usr troutmask:root[204] ls troutmask:root[205] exit exit Script done on Wed Nov 12 18:54:40 2014 QED -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Minor bug in SCSI definition
Coverity found an issue in this area which I tracked down to the incorrect definition patched below. The SID_QUAL macro is (((inq_data)-device 0xE0) 5) which extracts the peripheral qualifier. Per SCSI-2 (draft 10L) table 46, the vendor-specific values are 1XXb. This probably affects almost nobody, but it will clear up a couple of Coverity warnings. Anton Index: sys/cam/scsi/scsi_all.h === --- sys/cam/scsi/scsi_all.h (revision 274352) +++ sys/cam/scsi/scsi_all.h (working copy) @@ -1817,7 +1817,7 @@ * reserved for this peripheral * qualifier. */ -#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) 0x08) != 0) +#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) 0x04) != 0) u_int8_t dev_qual2; #define SID_QUAL2 0x7F #define SID_LU_CONG0x40 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Minor bug in SCSI definition
On Wed, Nov 12, 2014 at 7:30 PM, Rang, Anton anton.r...@isilon.com wrote: Coverity found an issue in this area which I tracked down to the incorrect definition patched below. The SID_QUAL macro is (((inq_data)-device 0xE0) 5) which extracts the peripheral qualifier. Per SCSI-2 (draft 10L) table 46, the vendor-specific values are 1XXb. This probably affects almost nobody, but it will clear up a couple of Coverity warnings. Anton Index: sys/cam/scsi/scsi_all.h === --- sys/cam/scsi/scsi_all.h (revision 274352) +++ sys/cam/scsi/scsi_all.h (working copy) @@ -1817,7 +1817,7 @@ * reserved for this peripheral * qualifier. */ -#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) 0x08) != 0) +#define SID_QUAL_IS_VENDOR_UNIQUE(inq_data) ((SID_QUAL(inq_data) 0x04) != 0) u_int8_t dev_qual2; #define SID_QUAL2 0x7F #define SID_LU_CONG0x40 CCing ken@/mav@/scottl@ -- thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build became unstable: FreeBSD_HEAD-tests2 #237
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-tests2/237/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
