Re: r273918 buildworld broke at semaphore
I posted the solution to this through the Nabble page, but there's a change in setting there and the messages have not gone through. So, re-posting to mail list: I disabled ccache, then buildworld / buildkernel completed. I had in /etc/make.conf: .if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/asp/git/src} || ${.CURDIR:M/asp/git/src/*} THREADS=16 #CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1} #CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/clang++,1} The only reason I can think of is that somehow ccache was passing the older cached code to the buildworld process, and the reason for that wold be because certain clang components fail to identify themselves to ccache correctly. Once I installed the newly built kernel/world and re-booted * I deleted all under /usr/obj * re-enabled ccache in make.conf * re-ran # make buildworld completed without problem. ___ 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
Is libLLVM-3.4.so: part of src or not?
When starting Xorg, AIGLX gets disabled and RadeonKMS complains: (EE) AIGLX error: dlopen of /usr/local/lib/dri/r600_dri.so failed (Shared object libLLVM-3.4.so n ot found, required by r600_dri.so) (EE) AIGLX: reverting to software rendering (II) AIGLX: Screen 0 is not DRI capable (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (Shared object libLLVM-3.4.so not found, required by swrast_dri.so) (EE) GLX: could not load software renderer (II) GLX: no usable GL providers found for screen 0 A search on the system shows libLLVM-3.4.so only exists under /usr/local/lib32. I built and installed devel/llvm34, re-started Xorg and the log shows AIGLX as starting normally (no error). ___ 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: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)
On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote: But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. I refrained from voicing my opinion while the call for help was going on, but I completely agree that the target age of this Google initiative is inadequate to FreeBSD. The target population is 13 years to 17 years old and I cannot even imagine a 13 year old knowing what FreeBSD is. ...and yet there was pat@ becoming a ports committer at the age of 16 and chris@ becoming a docs committer at the age of 14 :) I think hmp@, alepulver@, issyl0@ and jmallett@ were pretty young when they joined, too. Just an observation, I know that one or two isolated cases do not prove a point :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: Digital signature
Re: CFR: AES-GCM and OpenCrypto work review
On Fri, Nov 14, 2014 at 03:52:39AM +0300, Andrey V. Elsukov wrote: On 08.11.2014 07: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 know there are more fixes and future improvements, but can't think of them now. I tried your patch with my IPv4 forwarding test. When aesni module is loaded and aes-cbc is used I see growing of `invalid outbound packets` counter in `netstat -sp ipsec` output. And no packets are forwarded. Also while testing I got a panic in aesni_encrypt_cbc(). atal trap 9: general protection fault while in kernel mode cpuid = 4; apic id = 04 instruction pointer = 0x20:0x80d05c43 stack pointer = 0x28:0xfe3f7e70 frame pointer = 0x28:0xfe3f7eb0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq286: ix0:que 4) The backtrace: #0 doadump (textdump=276160512) at pcpu.h:219 #1 0x80355525 in db_fncall (dummy1=value optimized out, dummy2=value optimized out, dummy3=value optimized out, dummy4=value optimized out) at /usr/src/sys/ddb/db_command.c:568 #2 0x8035520d in db_command (cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:440 #3 0x80354f84 in db_command_loop () at /usr/src/sys/ddb/db_command.c:493 #4 0x80357980 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:251 #5 0x8095c641 in kdb_trap (type=9, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:654 #6 0x80d1edcc in trap_fatal (frame=0xfe3f7dc0, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:861 #7 0x80d1ea6e in trap (frame=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:201 #8 0x80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #9 0x80d05c43 in fpudna () at /usr/src/sys/amd64/amd64/fpu.c:85 #10 0x80d1e7ae in trap (frame=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:432 #11 0x80d04092 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:231 #12 0x8202f96e in aesni_encrypt_cbc (rounds=10, key_schedule=0xf8005603d400, len=3, from=0xf8013b0de65a E, to=0xf8013b0de65a E, iv=0xf8005603d6d0 ???#??8???:n???\r??\f?\v) at /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63 #13
Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)
On Fri, Nov 14, 2014 at 3:38 AM, Mark Saad nones...@longcount.org wrote: On Nov 14, 2014, at 4:27 AM, Peter Pentchev r...@ringlet.net wrote: On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote: But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. I have a few ideas for younger and or less experienced google code in people 1. Analyze the CD/USB install process . Does the actual process match the guide and or general docs . 2. Analyze / comment on the automated install process jumpstart . Does the guide and general docs match the actual process . 3. Test the virtual machine images as vagrant box images , and create vagrant box images from the official vm images . 4. Create a script for the installer bsd install to use glabel to label gparts slices as /dev/label/$NAME 5. Test the ami images , again can the docs be improved are they accurate . The Now let me preface the docs tasks , by no means am I saying that the docs team has made lots of mistakes and their work needs to be rechecked . The tasks are small enough that most high school aged people could grasp the issue, with out any prior experience in BSD world . Rechecking the docs is always a good idea . They should allow the code in members to make some good contributions ; and maybe even some good improvements . I refrained from voicing my opinion while the call for help was going on, but I completely agree that the target age of this Google initiative is inadequate to FreeBSD. The target population is 13 years to 17 years old and I cannot even imagine a 13 year old knowing what FreeBSD is. ...and yet there was pat@ becoming a ports committer at the age of 16 and chris@ becoming a docs committer at the age of 14 :) I think hmp@, alepulver@, issyl0@ and jmallett@ were pretty young when they joined, too. Just an observation, I know that one or two isolated cases do not prove a point :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 Mark saad | mark.s...@longcount.org One important program class for the less experienced people ( as users and programmers ) would be the following : (1) For the command line operating system programs , mostly it is necessary to give parameters on command line . For example : $ ifconfig displays the NIC information . To apply some operations , it is necessary to give parameters : $ ifconfig -... ... ... ... To give these parameters even by using man pages are very difficult even for the experienced users . Task : By using for selected OS programs , write a routine to the following : When a user enters only program name , display a form to get parameters for execution ( this requires some changes to programs doing operations just by giving its name by specifying a parameter for such cases ) in such a way that get parameters in an order by supplying form parts with respect to previously given parameter values , i.e. , do not present all of the items , let the user some values , and smash the user that such parameters are given incorrectly . Manual pages may be used , but sometimes it is necessary to read the source code of the program to isolate error cases and dependencies . (2) Some programs may use many parameters and every time giving them as command line parameters or by filling forms may not be a very convenient way . By using Expat libraries ( or any other suitable library ) , write a routine for a selected command line program to enter parameters from an XML file with the following structure : $ program_name @XML_parameters file_name Such a result may be obtained by using scripts for executing the programs with specific parameters , but using the above structure may be more convenient usage and they may be used in testing also more easily because some files may be output of other programs . (3) Many OS programs are given their outputs in an arbitrary text form . For automated tests , or input to other programs , these outputs are very difficult to use . For selected OS programs , give all of the output in XML ( or any other selected structured form ) .which they can be processed by using Expat library . To process these outputs , also write a routine by using Expat library to load it into a tree . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)
On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote: But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. I refrained from voicing my opinion while the call for help was going on, but I completely agree that the target age of this Google initiative is inadequate to FreeBSD. The target population is 13 years to 17 years old and I cannot even imagine a 13 year old knowing what FreeBSD is. I'm not sure we should participate in Code In ever again and perhaps we should focus our efforts on Summer of Code only. -- Rui Paulo ___ 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: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)
On Nov 14, 2014, at 4:27 AM, Peter Pentchev r...@ringlet.net wrote: On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote: On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote: But please nuke the current list -- it is completely inadequate for the code-in candidates and misleading for whoever wants to suggest new tasks. Again i am not saying that the projects suggested there are not important, just belong somewhere else e.g. gsoc. I have a few ideas for younger and or less experienced google code in people 1. Analyze the CD/USB install process . Does the actual process match the guide and or general docs . 2. Analyze / comment on the automated install process jumpstart . Does the guide and general docs match the actual process . 3. Test the virtual machine images as vagrant box images , and create vagrant box images from the official vm images . 4. Create a script for the installer bsd install to use glabel to label gparts slices as /dev/label/$NAME 5. Test the ami images , again can the docs be improved are they accurate . The Now let me preface the docs tasks , by no means am I saying that the docs team has made lots of mistakes and their work needs to be rechecked . The tasks are small enough that most high school aged people could grasp the issue, with out any prior experience in BSD world . Rechecking the docs is always a good idea . They should allow the code in members to make some good contributions ; and maybe even some good improvements . I refrained from voicing my opinion while the call for help was going on, but I completely agree that the target age of this Google initiative is inadequate to FreeBSD. The target population is 13 years to 17 years old and I cannot even imagine a 13 year old knowing what FreeBSD is. ...and yet there was pat@ becoming a ports committer at the age of 16 and chris@ becoming a docs committer at the age of 14 :) I think hmp@, alepulver@, issyl0@ and jmallett@ were pretty young when they joined, too. Just an observation, I know that one or two isolated cases do not prove a point :) G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org p.penc...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 Mark saad | mark.s...@longcount.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
On 14.11.2014 03:52, Andrey V. Elsukov wrote: I tried your patch with my IPv4 forwarding test. When aesni module is loaded and aes-cbc is used I see growing of `invalid outbound packets` counter in `netstat -sp ipsec` output. And no packets are forwarded. Also while testing I got a panic in aesni_encrypt_cbc(). atal trap 9: general protection fault while in kernel mode cpuid = 4; apic id = 04 instruction pointer = 0x20:0x80d05c43 stack pointer = 0x28:0xfe3f7e70 frame pointer = 0x28:0xfe3f7eb0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq286: ix0:que 4) The full backtrace is here: http://paste.org.ru/?a3f8pw Screenshot from ddb: http://i.imgur.com/H5mbVi8.png?1 Also I noticed that on higher packet rate sometimes kernel reports about wrong source route attempts: kernel: attempted source route from 244.116.138.102 to 225.51.107.139 kernel: attempted source route from 19.120.181.94 to 238.17.74.139 kernel: attempted source route from 186.217.142.184 to 233.165.4.102 kernel: attempted source route from 134.41.78.248 to 231.122.242.144 probably there is mbuf's memory corruption somewhere. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: Is libLLVM-3.4.so: part of src or not?
On Fri, Nov 14, 2014 at 10:16:10AM +0200, Beeblebrox wrote: When starting Xorg, AIGLX gets disabled and RadeonKMS complains: (EE) AIGLX error: dlopen of /usr/local/lib/dri/r600_dri.so failed (Shared object libLLVM-3.4.so n ot found, required by r600_dri.so) (EE) AIGLX: reverting to software rendering (II) AIGLX: Screen 0 is not DRI capable (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (Shared object libLLVM-3.4.so not found, required by swrast_dri.so) (EE) GLX: could not load software renderer (II) GLX: no usable GL providers found for screen 0 A search on the system shows libLLVM-3.4.so only exists under /usr/local/lib32. I built and installed devel/llvm34, re-started Xorg and the log shows AIGLX as starting normally (no error). libLLVM doesn't provide a stable interface and is thus not a public part of base. It sounds like there's a missing port depend. -- Brooks pgpY0B34Wzjfz.pgp Description: PGP signature
Re: geli: Wrong key with a simple passphrase. Doesn't handle the keyboard input
Hi all, Is there people that can try to geli an external USB disk with a simple passphrase on CURRENT and tell me if the passphrase prompt shown the input, and if it's possible to attach it ? Cheers,Aurelien # uname -a FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53 UTC 2014 r...@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI- B arm #kldstat 21 0xc2e49000 17000geom_eli.ko 31 0xc2e6 2a000crypto.ko # sysctl kern.geom.eli.visible_passphrase=1 kern.geom.eli.visible_passphrase: 0 - 1 Nothing print in the prompt # geli init da0 Enter new passphrase: Reenter new passphrase: Impossible to attach the device with a simple passphrase. Tried 20x geli attach da0 Enter passphrase: geli: Wrong key for da0 2014-11-08 21:26 GMT+01:00 Aurelien Martin 01aurel...@gmail.com: Dear all, I tried to geli my external USB drive da0 with a simple passphrase But I'm getting Wrong key for da0 when I want to attach it. geli seems not to handle my keyboard input when I type my password. Let me know if I have forgot a step. Cheers,Aurelien Log -- # uname -a FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53 UTC 2014 r...@grind.freebsd.org:/usr/ obj/arm.armv6/usr/src/sys/RPI-B arm # sysctl kern.geom.eli.visible_passphrase=1 kern.geom.eli.visible_passphrase: 0 - 1 What I have done : The prompt doesn't handle my keyboard input, nothing printed # geli init da0 Enter new passphrase: Reenter new passphrase: Metadata backup can be found in /var/backups/da0.eli and ... # geli attach da0 Enter passphrase: geli: Wrong key for da0. # cat /var/backups/da0.eli | hexdump -c | head -1 000 G E O M : : E L I \0 \0 \0 \0 \0 \0 \0 ___ 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: geli: Wrong key with a simple passphrase. Doesn't handle the keyboard input
Aurelien Martin 01aurel...@gmail.com wrote: Is there people that can try to geli an external USB disk with a simple passphrase on CURRENT and tell me if the passphrase prompt shown the input, and if it's possible to attach it ? # uname -a FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53 UTC 2014 r...@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI- B arm #kldstat 21 0xc2e49000 17000geom_eli.ko 31 0xc2e6 2a000crypto.ko # sysctl kern.geom.eli.visible_passphrase=1 kern.geom.eli.visible_passphrase: 0 - 1 Nothing print in the prompt # geli init da0 Enter new passphrase: Reenter new passphrase: The sysctl only applies to the kernel, geli(8) doesn't use it. Impossible to attach the device with a simple passphrase. Tried 20x geli attach da0 Enter passphrase: geli: Wrong key for da0 geli attach works for me on 11-CURRENT amd64, maybe it's an arm issue. Fabian pgpdEp6VcT5Qo.pgp Description: OpenPGP digital signature
Re: geli: Wrong key with a simple passphrase. Doesn't handle the keyboard input
Many thanks Fabian for your feedbacks ! @freebsd-arm users: Can someone try to geli init and geli attach an USB external drive ? Cheers,Aurelien 2014-11-14 18:23 GMT+01:00 Fabian Keil freebsd-lis...@fabiankeil.de: Aurelien Martin 01aurel...@gmail.com wrote: Is there people that can try to geli an external USB disk with a simple passphrase on CURRENT and tell me if the passphrase prompt shown the input, and if it's possible to attach it ? # uname -a FreeBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53 UTC 2014 r...@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI- B arm #kldstat 21 0xc2e49000 17000geom_eli.ko 31 0xc2e6 2a000crypto.ko # sysctl kern.geom.eli.visible_passphrase=1 kern.geom.eli.visible_passphrase: 0 - 1 Nothing print in the prompt # geli init da0 Enter new passphrase: Reenter new passphrase: The sysctl only applies to the kernel, geli(8) doesn't use it. Impossible to attach the device with a simple passphrase. Tried 20x geli attach da0 Enter passphrase: geli: Wrong key for da0 geli attach works for me on 11-CURRENT amd64, maybe it's an arm issue. Fabian ___ 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
John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 -0800: Well.. It looks like IPSEC is still broken in head... I can get pings to pass, but now on IPv4 transport mode, I can't get syn's to be sent out... I see the output packet in the protocol stats, but no packets go out the interface... If you could provide me w/ a simple set of spdadd commands, or the dumps from the machine, that'd be good... Hmm I just ran ping -f so I could generate some traffic, and managed to get a: panic: System call sendto returing with kernel FPU ctx leaked I'll look into this... I just verified that this happens on a clean HEAD @ r274534: FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64 No modifications, nothing, and I got the same panic: panic: System call sendto returing with kernel FPU ctx leaked cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe001de7a800 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe001de7a8b0 vpanic() at vpanic+0x189/frame 0xfe001de7a930 kassert_panic() at kassert_panic+0x139/frame 0xfe001de7a9a0 amd64_syscall() at amd64_syscall+0x616/frame 0xfe001de7aab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001de7aab0 --- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffee588, rbp = 0x7ffee5c0 --- KDB: enter: panic So, it's clearly not my patch that is causing the issue... Andrey, can you verify that you do not receive the same panic w/o my patches? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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