date:20160808

Re: lengthy sdhci timeouts on KBL-Y tester

2016-08-08 Thread O. Hartmann

On Mon, 8 Aug 2016 18:43:42 -0700
"K. Macy"  wrote:

> I have a KBL-Y "Software Development Platform" for purposes of getting
> the i915 KMS working on that system on FreeBSD. I've just installed 11
> BETA4. sdhci timeouts add several minutes to boot time. The dmesg
> output follows:

[...]
A very similar situation here with a Intel NUC5CPYH. I circumvent the problem
by  setting in /boot/device.hints "hint.sdhci_pci.0.disabled=1" as a
workaround. 



[...]
> Copyright (c) 1992-2016 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 11.0-BETA4 #0 r303759: Fri Aug  5 02:26:47 UTC 2016
> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
> LLVM 3.8.0)
> VT(efifb): resolution 2560x1440
> CPU: Intel(R) Core(TM) m5-7Y54 CPU @ 1.20GHz (1608.05-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x806e9  Family=0x6  Model=0x8e  Stepping=9
>   
> Features=0xbfebfbff
>   
> Features2=0x7ffafbbf
>   AMD Features=0x2c100800
>   AMD Features2=0x121
>   Structured Extended
> Features=0x29c67af
>   XSAVE Features=0xf
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 8589934592 (8192 MB)
> avail memory = 8160288768 (7782 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
> random: unblocking device.
> ioapic0  irqs 0-119 on motherboard
> random: entropy device external interface
> kbd1 at kbdmux0
> netmap: loaded module
> module_register_init: MOD_LOAD (vesa, 0x81018940, 0) error 19
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> cryptosoft0:  on motherboard
> acpi0:  on motherboard
> acpi0: Power Button (fixed)
> ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320) ACPI Error: Method parse/execution failed
> [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
> AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
> (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320) ACPI Error: Method parse/execution failed
> [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
> AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
> (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320) ACPI Error: Method parse/execution failed
> [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
> AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
> (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320) ACPI Error: Method parse/execution failed
> [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
> AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
> (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI Error: Region EmbeddedControl (ID=3) has no handler
> (20160527/exfldio-320) ACPI Error: Method parse/execution failed
> [\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
> AE_NOT_EXIST (20160527/psparse-559)
> ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
> (Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
> ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
> [EmbeddedControl] (20160527/evregion-180)
> ACPI

lengthy sdhci timeouts on KBL-Y tester

2016-08-08 Thread K. Macy

I have a KBL-Y "Software Development Platform" for purposes of getting
the i915 KMS working on that system on FreeBSD. I've just installed 11
BETA4. sdhci timeouts add several minutes to boot time. The dmesg
output follows:
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.0-BETA4 #0 r303759: Fri Aug  5 02:26:47 UTC 2016
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
LLVM 3.8.0)
VT(efifb): resolution 2560x1440
CPU: Intel(R) Core(TM) m5-7Y54 CPU @ 1.20GHz (1608.05-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x806e9  Family=0x6  Model=0x8e  Stepping=9
  
Features=0xbfebfbff
  
Features2=0x7ffafbbf
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended
Features=0x29c67af
  XSAVE Features=0xf
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8160288768 (7782 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: unblocking device.
ioapic0  irqs 0-119 on motherboard
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0x81018940, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160527/exfldio-320)
ACPI Error: Method parse/execution failed
[\134_SB.PCI0.LPCB.H_EC.BAT1._STA] (Node 0xf8000641a4c0),
AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.H_EC.BAT1._STA]
(Node 0xf8000641a4c0), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [ECF2] (0xf800063cb000)

Build failed in Jenkins: FreeBSD_HEAD #554

2016-08-08 Thread jenkins-admin

See 

--
[...truncated 324428 lines...]
[192.168.10.2] out: 
usr.sbin/pw/pw_useradd:user_add_account_expiration_date_relative  ->  passed  
[0.114s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_account_expiration_epoch  
->  passed  [0.120s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_already_exists  ->  passed  
[0.114s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_bad_shell  ->  passed  
[0.121s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_comments  ->  passed  
[0.115s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_comments_invalid  ->  
passed  [0.084s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_comments_invalid_noupdate  
->  passed  [0.086s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_comments_noupdate  ->  
passed  [0.079s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_expiration  ->  passed  
[0.588s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_homedir  ->  passed  
[0.119s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_invalid_group_entry  ->  
passed  [0.105s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_invalid_user_entry  ->  
passed  [0.103s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_name_too_long  ->  passed  
[0.075s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_noupdate  ->  passed  
[0.087s]
[192.168.10.2] out: 
usr.sbin/pw/pw_useradd:user_add_password_expiration_date_month  ->  passed  
[0.119s]
[192.168.10.2] out: 
usr.sbin/pw/pw_useradd:user_add_password_expiration_date_numeric  ->  passed  
[0.119s]
[192.168.10.2] out: 
usr.sbin/pw/pw_useradd:user_add_password_expiration_date_relative  ->  passed  
[0.113s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_password_expiration_epoch  
->  passed  [0.115s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_password_from_h  ->  passed 
 [0.127s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_skel  ->  passed  [1.044s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_uid0  ->  passed  [0.156s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_uid_too_large  ->  passed  
[0.074s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_error  ->  passed  
[0.071s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_no  ->  passed  [0.113s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_none  ->  passed  [0.115s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_random  ->  passed  
[0.120s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_w_yes  ->  passed  [0.124s]
[192.168.10.2] out: usr.sbin/pw/pw_useradd:user_add_with_pw_conf  ->  passed  
[0.131s]
[192.168.10.2] out: usr.sbin/pw/pw_userdel:delete_files  ->  passed  [0.606s]
[192.168.10.2] out: usr.sbin/pw/pw_userdel:delete_numeric_name  ->  passed  
[0.117s]
[192.168.10.2] out: usr.sbin/pw/pw_userdel:home_not_a_dir  ->  passed  [0.349s]
[192.168.10.2] out: usr.sbin/pw/pw_userdel:rmuser_seperate_group  ->  passed  
[0.287s]
[192.168.10.2] out: 
usr.sbin/pw/pw_userdel:user_do_not_try_to_delete_root_if_user_unknown  ->  
passed  [0.084s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod  ->  passed  [0.153s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_H  ->  passed  [0.164s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_comments  ->  passed  
[0.152s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_comments_invalid  ->  
passed  [0.140s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_comments_invalid_noupdate  
->  passed  [0.130s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_comments_noupdate  ->  
passed  [0.125s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_h  ->  passed  [0.218s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_name_noupdate  ->  passed  
[0.131s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_nogroups  ->  passed  
[0.277s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_noupdate  ->  passed  
[0.143s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_rename  ->  passed  [0.155s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_rename_multigroups  ->  
passed  [0.260s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_rename_too_long  ->  passed 
 [0.118s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_renamehome  ->  passed  
[2.768s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_uid  ->  passed  [0.144s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_error  ->  passed  
[0.112s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_no  ->  passed  [0.295s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_none  ->  passed  [0.160s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_random  ->  passed  
[0.163s]
[192.168.10.2] out: usr.sbin/pw/pw_usermod:user_mod_w_yes  ->  passed  [0.164s]
[192.168.10.2] out: usr.sbin/pw/pw_usernext:usernext  ->  passed  [0.610s]
[192.168.10.2] out: usr.sbin/pw/pw_usernext:usernext_assigned_group  ->  passed 
 [4.446s]
[192.168.10.2] out:

Re: kernel panic caused by virtualbox(?)

2016-08-08 Thread Don Lewis

On  8 Aug, Konstantin Belousov wrote:
> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote:
>> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote:
>> > Reposted to -current to get some more eyes on this ...
>> > 
>> > I just got a kernel panic when I started up a CentOS 7 VM in virtualbox.
>> > The host is:
>> >FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64
>> > The virtualbox version is:
>> >virtualbox-ose-5.0.26
>> >virtualbox-ose-kmod-5.0.26_1
>> > 
>> > The panic message is:
>> > 
>> > panic: Unregistered use of FPU in kernel
>> > cpuid = 1
>> > KDB: stack backtrace:
>> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> > 0xfe085a55d030
>> > vpanic() at vpanic+0x182/frame 0xfe085a55d0b0
>> > kassert_panic() at kassert_panic+0x126/frame 0xfe085a55d120
>> > trap() at trap+0x7ae/frame 0xfe085a55d330
>> > calltrap() at calltrap+0x8/frame 0xfe085a55d330
>> > --- trap 0x16, rip = 0x827dd3a9, rsp = 0xfe085a55d408, rbp = 
>> > 0xfe085a55d430 ---
>> > g_pLogger() at 0x827dd3a9/frame 0xfe085a55d430
>> > g_pLogger() at 0x8274e5c7/frame 0x3
>> > KDB: enter: panic
>> > 
>> > Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is
>> > the trigger.
>> > 
>> > There are no symbols for the virtualbox kmods, possibly because I
>> > installed them as an upgrade using packages (built with the same source
>> > tree version) instead of by using PORTS_MODULES in make.conf, so ports
>> > kgdb didn't have anything useful to say about what happened before the
>> > trap.
>> > 
>> > This panic is very repeatable.  I just got another one when starting the
>> > same VM., but this time the two calls before the trap were
>> > null_bug_bypass().  Hmn, that symbol is in nullfs ...
>> > 
>> > I don't see this with a Windows 7 VM.
>> > 
>> > All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse
>> > -msoft-float -mno-aes -mno-avx
> Your disassemble listed fxrstor instruction that failing, or did I
> mis-remembered ? This is most likely some context switch code, either
> by virtual machine or erronously executed guest code. It is not a
> spontaneous use of FPU, but more likely something different. Can you
> confirm ?
> 
> In either case, I do not remember any KBI changes around PCB layout or
> fpu_enter() KPI recently.
> 
>> 
>> I suspect head packages are quite likely built against the a "wrong" KBI
>> and are too fragile to use for kmods vs compiling from ports. :-/  I would
>> try a built-from-ports kmod to see if the panics go away.
> 
> FWIW, I will commit the following change shortly. Since third-party
> modules break the invariant, either due to bugs (ndis wrappers) or
> possibly due to KBI breakage, it is worth to have the detection enabled
> for production kernels.

Interesting ... I tried running virtualbox on recent 10.3-STABLE with a
GENERIC kernel and the guest seemed to operate properly.  Then I enabled
INVARIANTS and got the panic.  I suspect that is why nobody has stumbled
across this before.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: some [big] changes to ZPL (ZFS<->VFS )

2016-08-08 Thread Alan Somers

On r303834 I can no longer reproduce the problem.
-Alan

On Sat, Aug 6, 2016 at 5:05 AM, Andriy Gapon  wrote:
> On 05/08/2016 23:31, Alan Somers wrote:
>> I'm not certain it's related, but on a head build at r303767 I see a
>> LOR and a reproducible panic that involve the snapdir code.
>
> Alan,
>
> thank you very much for the clear report and for the very easy
> reproduction scenario.  I am not sure how I missed this simple and
> severe bug.
> Please try r303791, it should fix the problem.
>
> I believe that the LOR is not new and been there since we started using
> distinct tags for .zfs special vnodes.
>
>> First, the LOR:
>> $ zpool destroy foo
>>
>> lock order reversal:
>>  1st 0xf800404c8b78 zfs (zfs) @
>> /usr/home/alans/freebsd/head/sys/kern/vfs_mount.c:1244
>>  2nd 0xf800404c85f0 zfs_gfs (zfs_gfs) @
>> /usr/home/alans/freebsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/gfs.c:484
>> stack backtrace:
>> #0 0x80aa90b0 at witness_debugger+0x70
>> #1 0x80aa8fa4 at witness_checkorder+0xe54
>> #2 0x80a22072 at __lockmgr_args+0x4c2
>> #3 0x80af8e7c at vop_stdlock+0x3c
>> #4 0x81018880 at VOP_LOCK1_APV+0xe0
>> #5 0x80b19f2a at _vn_lock+0x9a
>> #6 0x821b9c53 at gfs_file_create+0x73
>> #7 0x821b9cfd at gfs_dir_create+0x1d
>> #8 0x8228aa07 at zfsctl_mknode_snapdir+0x47
>> #9 0x821ba1a5 at gfs_dir_lookup+0x185
>> #10 0x821ba68d at gfs_vop_lookup+0x1d
>> #11 0x82289a42 at zfsctl_root_lookup+0xf2
>> #12 0x8228a8c3 at zfsctl_umount_snapshots+0x83
>> #13 0x822a1d2b at zfs_umount+0x7b
>> #14 0x80b02a14 at dounmount+0x6f4
>> #15 0x80b0228d at sys_unmount+0x35d
>> #16 0x80ebbb7b at amd64_syscall+0x2db
>> #17 0x80e9b72b at Xfast_syscall+0xfb
>>
>>
>> Here's the panic:
>> $ zpool create testpool da0
>> $ touch /testpool/testfile
>> $ zfs snapshot testpool@testsnap
>> $ cd /testpool/.zfs/snapshots
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 2; apic id = 04
>> fault virtual address   = 0x8
>> fault code  = supervisor read data, page not present
>> instruction pointer = 0x20:0x80b19f1c
>> stack pointer   = 0x28:0xfe0b54bf7430
>> frame pointer   = 0x28:0xfe0b54bf74a0
>> 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 = 966 (bash)
>> trap number = 12
>> panic: page fault
>> cpuid = 2
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> 0xfe0b54bf6fc0
>> vpanic() at vpanic+0x182/frame 0xfe0b54bf7040
>> panic() at panic+0x43/frame 0xfe0b54bf70a0
>> trap_fatal() at trap_fatal+0x351/frame 0xfe0b54bf7100
>> trap_pfault() at trap_pfault+0x1fd/frame 0xfe0b54bf7160
>> trap() at trap+0x284/frame 0xfe0b54bf7370
>> calltrap() at calltrap+0x8/frame 0xfe0b54bf7370
>> --- trap 0xc, rip = 0x80b19f1c, rsp = 0xfe0b54bf7440, rbp
>> = 0xfe0b54bf74a0 ---
>> _vn_lock() at _vn_lock+0x8c/frame 0xfe0b54bf74a0
>> zfs_lookup() at zfs_lookup+0x50d/frame 0xfe0b54bf7540
>> zfs_freebsd_lookup() at zfs_freebsd_lookup+0x91/frame 0xfe0b54bf7680
>> VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xda/frame 0xfe0b54bf76b0
>> vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfe0b54bf7710
>> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xda/frame 0xfe0b54bf7740
>> lookup() at lookup+0x5a2/frame 0xfe0b54bf77d0
>> namei() at namei+0x5b2/frame 0xfe0b54bf7890
>> kern_statat() at kern_statat+0xa8/frame 0xfe0b54bf7a40
>> sys_stat() at sys_stat+0x2d/frame 0xfe0b54bf7ae0
>> amd64_syscall() at amd64_syscall+0x2db/frame 0xfe0b54bf7bf0
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0b54bf7bf0
>>
>>
>> I can provide core files, test scripts, whatever you need.  Thanks for
>> tackling this difficult problem.
>>
>> -Alan
>>
>> On Fri, Aug 5, 2016 at 12:36 AM, Andriy Gapon  wrote:
>>> On 03/08/2016 17:25, Andriy Gapon wrote:
 Another change that was not strictly required and which is probably too
 intrusive is killing the support for case insensitive operations.   My
 thinking was that FreeBSD VFS does not provide support for those anyway.
  But I'll probably restore the code, at least in the bottom half of the
 ZPL, before committing the change.
>>>
>>> It turned out that most of the removed code was dead anyway and it took
>>> just a few lines of code to restore support for case-insensitive
>>> filesystems.  Filesystems with mixed case sensitivity behave exactly the
>>> same as case-sensitive filesystem as it has always been the case on FreeBSD.
>>>
>>> Anyway the big change has just been committed:
>>> https://svnweb.freebsd.org/changeset/base/303763
>>> Please test away.
>>>
>>> Another

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-08 Thread Devin Teske


> On Aug 8, 2016, at 12:39 PM, Bernard Spil  wrote:
> 
> Hi Devin,
> 
> This resource documents the choices pretty well I think
> https://stribika.github.io/2015/01/04/secure-secure-shell.html 
> 
> Author has made some modifications up to Jan 2016
> https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md
>  
> 
> 
> The short answer then is ed25519 or rsa4096, disable both dsa and ecdsa.
> 
> Even 6.5p1 shipped with 9.3 supports ed25519.
> 
> Cheers,
> 
> Bernard.
> 

Thanks for confirming, Bernard!
-- 
Cheers,
Devin


> On 2016-08-08 19:56, Devin Teske wrote:
>> Which would you use?
>> ECDSA?
>> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 
>> 
>> > >
>> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover
>> operation", cryptography experts have also expressed concern over the
>> security of the NIST recommended elliptic curves,[31]
>> > >
>> suggesting a return to encryption based on non-elliptic-curve groups.
>> ""
>> Or perhaps RSA? (as des@ recommends)
>> (not necessarily to Glen but anyone that wants to answer)
>> --
>> Devin
>>> On Aug 4, 2016, at 6:59 PM, Glen Barber  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
>>> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
>>> Please see r303716 for details on the relevant commit, but upstream no
>>> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
>>> keys as soon as possible, otherwise there will be issues when upgrading
>>> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
>>> 11.0-RELEASE build.
>>> Glen
>>> On behalf of:   re@ and secteam@
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb
>>> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK
>>> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl
>>> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR
>>> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u
>>> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs
>>> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c
>>> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8
>>> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r
>>> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL
>>> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx
>>> bLbbH2fh5bxDmDXDMdCF
>>> =LLtP
>>> -END PGP SIGNATURE-
>>> ___
>>> freebsd-annou...@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-announce
>>> To unsubscribe, send any mail to "freebsd-announce-unsubscr...@freebsd.org"
>> ___
>> freebsd-sta...@freebsd.org  mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable 
>> 
>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org 
>> "

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-08 Thread Bernard Spil


Hi Devin,

This resource documents the choices pretty well I think
https://stribika.github.io/2015/01/04/secure-secure-shell.html
Author has made some modifications up to Jan 2016
https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md

The short answer then is ed25519 or rsa4096, disable both dsa and ecdsa.

Even 6.5p1 shipped with 9.3 supports ed25519.

Cheers,

Bernard.

On 2016-08-08 19:56, Devin Teske wrote:

Which would you use?

ECDSA?

https://en.wikipedia.org/wiki/Elliptic_curve_cryptography


"" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover
operation", cryptography experts have also expressed concern over the
security of the NIST recommended elliptic curves,[31]

suggesting a return to encryption based on non-elliptic-curve groups.
""

Or perhaps RSA? (as des@ recommends)

(not necessarily to Glen but anyone that wants to answer)
--
Devin



On Aug 4, 2016, at 6:59 PM, Glen Barber  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is a heads-up that OpenSSH keys are deprecated upstream by 
OpenSSH,

and will be deprecated effective 11.0-RELEASE (and preceeding RCs).

Please see r303716 for details on the relevant commit, but upstream no
longer considers them secure.  Please replace DSA keys with ECDSA or 
RSA
keys as soon as possible, otherwise there will be issues when 
upgrading

from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
11.0-RELEASE build.

Glen
On behalf of:   re@ and secteam@

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb
kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK
rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl
GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR
TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u
c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs
60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c
QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8
7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r
mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL
kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx
bLbbH2fh5bxDmDXDMdCF
=LLtP
-END PGP SIGNATURE-
___
freebsd-annou...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-announce
To unsubscribe, send any mail to 
"freebsd-announce-unsubscr...@freebsd.org"


___
freebsd-sta...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to 
"freebsd-stable-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel panic caused by virtualbox(?)

2016-08-08 Thread Don Lewis

On  8 Aug, Konstantin Belousov wrote:
> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote:
>> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote:
>> > Reposted to -current to get some more eyes on this ...
>> > 
>> > I just got a kernel panic when I started up a CentOS 7 VM in virtualbox.
>> > The host is:
>> >FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64
>> > The virtualbox version is:
>> >virtualbox-ose-5.0.26
>> >virtualbox-ose-kmod-5.0.26_1
>> > 
>> > The panic message is:
>> > 
>> > panic: Unregistered use of FPU in kernel
>> > cpuid = 1
>> > KDB: stack backtrace:
>> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> > 0xfe085a55d030
>> > vpanic() at vpanic+0x182/frame 0xfe085a55d0b0
>> > kassert_panic() at kassert_panic+0x126/frame 0xfe085a55d120
>> > trap() at trap+0x7ae/frame 0xfe085a55d330
>> > calltrap() at calltrap+0x8/frame 0xfe085a55d330
>> > --- trap 0x16, rip = 0x827dd3a9, rsp = 0xfe085a55d408, rbp = 
>> > 0xfe085a55d430 ---
>> > g_pLogger() at 0x827dd3a9/frame 0xfe085a55d430
>> > g_pLogger() at 0x8274e5c7/frame 0x3
>> > KDB: enter: panic
>> > 
>> > Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is
>> > the trigger.
>> > 
>> > There are no symbols for the virtualbox kmods, possibly because I
>> > installed them as an upgrade using packages (built with the same source
>> > tree version) instead of by using PORTS_MODULES in make.conf, so ports
>> > kgdb didn't have anything useful to say about what happened before the
>> > trap.
>> > 
>> > This panic is very repeatable.  I just got another one when starting the
>> > same VM., but this time the two calls before the trap were
>> > null_bug_bypass().  Hmn, that symbol is in nullfs ...
>> > 
>> > I don't see this with a Windows 7 VM.
>> > 
>> > All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse
>> > -msoft-float -mno-aes -mno-avx
> Your disassemble listed fxrstor instruction that failing, or did I
> mis-remembered ? This is most likely some context switch code, either
> by virtual machine or erronously executed guest code. It is not a
> spontaneous use of FPU, but more likely something different. Can you
> confirm ?

That is correct.  My first guess was that it was some guest code
incorrectly getting executed in the host context, but when I
disassembled segments of the code for the two frames leading up to the
trap, I noticed that there is a call from the first to the second, which
would only work if the code was located at these locations in the host
KVA space.  In the guest address space the code locations would likely
be totally different and the call would not work.

My next best guess is that this is some sort of trampoline code that
virtualbox stashed in some allocated memory.

As I mentioned previously, I don't have this problem if I restrict the
guest to one processor.

Another observation is that Linux guests now default to KVM
paravirtualization, whereas the other guests use other methods.  One
experiment that I will try is setting this to "none", but my
12.0-CURRENT box will be busy running poudriere for about the next 12
hours.

I also hope to try this on FreeBSD 10.3-STABLE in the next couple of
hours.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel panic caused by virtualbox(?)

2016-08-08 Thread Don Lewis

On  8 Aug, John Baldwin wrote:
> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote:
>> Reposted to -current to get some more eyes on this ...
>> 
>> I just got a kernel panic when I started up a CentOS 7 VM in virtualbox.
>> The host is:
>>  FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64
>> The virtualbox version is:
>>  virtualbox-ose-5.0.26
>>  virtualbox-ose-kmod-5.0.26_1
>> 
>> The panic message is:
>> 
>> panic: Unregistered use of FPU in kernel
>> cpuid = 1
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>> 0xfe085a55d030
>> vpanic() at vpanic+0x182/frame 0xfe085a55d0b0
>> kassert_panic() at kassert_panic+0x126/frame 0xfe085a55d120
>> trap() at trap+0x7ae/frame 0xfe085a55d330
>> calltrap() at calltrap+0x8/frame 0xfe085a55d330
>> --- trap 0x16, rip = 0x827dd3a9, rsp = 0xfe085a55d408, rbp = 
>> 0xfe085a55d430 ---
>> g_pLogger() at 0x827dd3a9/frame 0xfe085a55d430
>> g_pLogger() at 0x8274e5c7/frame 0x3
>> KDB: enter: panic
>> 
>> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is
>> the trigger.
>> 
>> There are no symbols for the virtualbox kmods, possibly because I
>> installed them as an upgrade using packages (built with the same source
>> tree version) instead of by using PORTS_MODULES in make.conf, so ports
>> kgdb didn't have anything useful to say about what happened before the
>> trap.
>> 
>> This panic is very repeatable.  I just got another one when starting the
>> same VM., but this time the two calls before the trap were
>> null_bug_bypass().  Hmn, that symbol is in nullfs ...
>> 
>> I don't see this with a Windows 7 VM.
>> 
>> All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse
>> -msoft-float -mno-aes -mno-avx
> 
> I suspect head packages are quite likely built against the a "wrong" KBI
> and are too fragile to use for kmods vs compiling from ports. :-/  I would
> try a built-from-ports kmod to see if the panics go away.

The poudriere jail that I used to build the package was the same source
version as the host.

I updated the host to r303762 and manually rebuilt and installed the
kmod from ports and still see the panic.  What is interesting is that if
I configure the Linux guests to use only one processor, the panic goes
away.

See  for the
latest info.

I just figured out a way to test this on recent 10.3-STABLE without
endangering my desktop machine.  I should have some results in a couple
hours after I bring the test machine up to date.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: kernel panic caused by virtualbox(?)

2016-08-08 Thread Konstantin Belousov

On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote:
> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote:
> > Reposted to -current to get some more eyes on this ...
> > 
> > I just got a kernel panic when I started up a CentOS 7 VM in virtualbox.
> > The host is:
> > FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64
> > The virtualbox version is:
> > virtualbox-ose-5.0.26
> > virtualbox-ose-kmod-5.0.26_1
> > 
> > The panic message is:
> > 
> > panic: Unregistered use of FPU in kernel
> > cpuid = 1
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> > 0xfe085a55d030
> > vpanic() at vpanic+0x182/frame 0xfe085a55d0b0
> > kassert_panic() at kassert_panic+0x126/frame 0xfe085a55d120
> > trap() at trap+0x7ae/frame 0xfe085a55d330
> > calltrap() at calltrap+0x8/frame 0xfe085a55d330
> > --- trap 0x16, rip = 0x827dd3a9, rsp = 0xfe085a55d408, rbp = 
> > 0xfe085a55d430 ---
> > g_pLogger() at 0x827dd3a9/frame 0xfe085a55d430
> > g_pLogger() at 0x8274e5c7/frame 0x3
> > KDB: enter: panic
> > 
> > Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is
> > the trigger.
> > 
> > There are no symbols for the virtualbox kmods, possibly because I
> > installed them as an upgrade using packages (built with the same source
> > tree version) instead of by using PORTS_MODULES in make.conf, so ports
> > kgdb didn't have anything useful to say about what happened before the
> > trap.
> > 
> > This panic is very repeatable.  I just got another one when starting the
> > same VM., but this time the two calls before the trap were
> > null_bug_bypass().  Hmn, that symbol is in nullfs ...
> > 
> > I don't see this with a Windows 7 VM.
> > 
> > All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse
> > -msoft-float -mno-aes -mno-avx
Your disassemble listed fxrstor instruction that failing, or did I
mis-remembered ? This is most likely some context switch code, either
by virtual machine or erronously executed guest code. It is not a
spontaneous use of FPU, but more likely something different. Can you
confirm ?

In either case, I do not remember any KBI changes around PCB layout or
fpu_enter() KPI recently.

> 
> I suspect head packages are quite likely built against the a "wrong" KBI
> and are too fragile to use for kmods vs compiling from ports. :-/  I would
> try a built-from-ports kmod to see if the panics go away.

FWIW, I will commit the following change shortly. Since third-party
modules break the invariant, either due to bugs (ndis wrappers) or
possibly due to KBI breakage, it is worth to have the detection enabled
for production kernels.

diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c
index 1b85b32..04c5dcc 100644
--- a/sys/amd64/amd64/trap.c
+++ b/sys/amd64/amd64/trap.c
@@ -443,8 +443,8 @@ trap(struct trapframe *frame)
goto out;
 
case T_DNA:
-   KASSERT(!PCB_USER_FPU(td->td_pcb),
-   ("Unregistered use of FPU in kernel"));
+   if (PCB_USER_FPU(td->td_pcb))
+   panic("Unregistered use of FPU in kernel");
fpudna();
goto out;
 
diff --git a/sys/i386/i386/trap.c b/sys/i386/i386/trap.c
index 40f7204..c540a49 100644
--- a/sys/i386/i386/trap.c
+++ b/sys/i386/i386/trap.c
@@ -540,8 +540,8 @@ trap(struct trapframe *frame)
 
case T_DNA:
 #ifdef DEV_NPX
-   KASSERT(!PCB_USER_FPU(td->td_pcb),
-   ("Unregistered use of FPU in kernel"));
+   if (PCB_USER_FPU(td->td_pcb))
+   panic("Unregistered use of FPU in kernel");
if (npxdna())
goto out;
 #endif
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Glen Barber

On Mon, Aug 08, 2016 at 11:22:27AM -0700, Nathan Whitehorn wrote:
> 
> 
> On 08/08/16 10:56, Glen Barber wrote:
> >On Mon, Aug 08, 2016 at 10:53:26AM -0700, Nathan Whitehorn wrote:
> >>
> >>On 08/08/16 10:43, Lars Engels wrote:
> >>>On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote:
> >On Aug 8, 2016, at 8:02 AM, Lars Engels  wrote:
> >
> >On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:
> >>On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:
> >>>On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> o The new system hardening options have been fixed to avoid 
> overwriting
>   other options selected during install time.
> >>>Can those options also get added to "bsdconfig"?
> >>You would have to ask the bsdconfig maintainer(s).
> >>
> >Cc'ing dteske.
> >
> What aspects of bsdconfig need updating?
> >>>bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig
> >>>share a lot of code, so bsdconfig should probably also offer the
> >>>"hardening" module.
> >>The hardening module should probably just be a part of bsdconfig, actually,
> >>and an option to open bsdconfig be an option at the end of the installer.
> >>
> >In order for that to be an option, I'd strongly suggest updating
> >bsdconfig to properly detect packages on the DVD (which it has not since
> >10.0-RELEASE), as it makes too many incorrect assumptions.
> >
> >
> 
> It's way too late for this for 11.0. I was just making a general statement.
> I think things are fine as they are for the upcoming release.

Agreed on both counts.

Glen



signature.asc
Description: PGP signature

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Nathan Whitehorn




On 08/08/16 10:56, Glen Barber wrote:

On Mon, Aug 08, 2016 at 10:53:26AM -0700, Nathan Whitehorn wrote:


On 08/08/16 10:43, Lars Engels wrote:

On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote:

On Aug 8, 2016, at 8:02 AM, Lars Engels  wrote:

On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:

On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:

On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:

-BEGIN PGP SIGNED MESSAGE-
o The new system hardening options have been fixed to avoid overwriting
  other options selected during install time.

Can those options also get added to "bsdconfig"?

You would have to ask the bsdconfig maintainer(s).


Cc'ing dteske.


What aspects of bsdconfig need updating?

bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig
share a lot of code, so bsdconfig should probably also offer the
"hardening" module.

The hardening module should probably just be a part of bsdconfig, actually,
and an option to open bsdconfig be an option at the end of the installer.


In order for that to be an option, I'd strongly suggest updating
bsdconfig to properly detect packages on the DVD (which it has not since
10.0-RELEASE), as it makes too many incorrect assumptions.

Glen



It's way too late for this for 11.0. I was just making a general 
statement. I think things are fine as they are for the upcoming release.

-Nathan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-08 Thread Allan Jude

On 2016-08-08 14:17, Conrad Meyer wrote:
> The OpenSSH defaults are intentionally sane.  RSA 2048 is anticipated
> to be fine for the next 10 years.  It would not be a bad choice.  I'm
> not aware of any reason not to use EC keys, and presumably the openssh
> authors wouldn't ship them as an option if they knew of any reason to
> believe they were compromised.
> 
> Best,
> Conrad
> 
> On Mon, Aug 8, 2016 at 10:56 AM, Devin Teske  wrote:
>> Which would you use?
>>
>> ECDSA?
>>
>> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 
>> 
>>
>> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover 
>> operation", cryptography experts have also expressed concern over the 
>> security of the NIST recommended elliptic curves,[31] 
>>  
>> suggesting a return to encryption based on non-elliptic-curve groups. ""
>>
>> Or perhaps RSA? (as des@ recommends)
>>
>> (not necessarily to Glen but anyone that wants to answer)
>> --
>> Devin
>>
>>
>>> On Aug 4, 2016, at 6:59 PM, Glen Barber  wrote:
>>>
> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
> 
> Please see r303716 for details on the relevant commit, but upstream no
> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
> keys as soon as possible, otherwise there will be issues when upgrading
> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
> 11.0-RELEASE build.
> 
> Glen
> On behalf of: re@ and secteam@
> 

As far as I know, the "advantage" to ED25519 keys, is that you can build
openssh without openssl, if you forgo supporting RSA etc.


-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-08 Thread Conrad Meyer

The OpenSSH defaults are intentionally sane.  RSA 2048 is anticipated
to be fine for the next 10 years.  It would not be a bad choice.  I'm
not aware of any reason not to use EC keys, and presumably the openssh
authors wouldn't ship them as an option if they knew of any reason to
believe they were compromised.

Best,
Conrad

On Mon, Aug 8, 2016 at 10:56 AM, Devin Teske  wrote:
> Which would you use?
>
> ECDSA?
>
> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 
> 
>
> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover 
> operation", cryptography experts have also expressed concern over the 
> security of the NIST recommended elliptic curves,[31] 
>  
> suggesting a return to encryption based on non-elliptic-curve groups. ""
>
> Or perhaps RSA? (as des@ recommends)
>
> (not necessarily to Glen but anyone that wants to answer)
> --
> Devin
>
>
>> On Aug 4, 2016, at 6:59 PM, Glen Barber  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
>> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
>>
>> Please see r303716 for details on the relevant commit, but upstream no
>> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
>> keys as soon as possible, otherwise there will be issues when upgrading
>> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
>> 11.0-RELEASE build.
>>
>> Glen
>> On behalf of: re@ and secteam@
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb
>> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK
>> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl
>> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR
>> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u
>> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs
>> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c
>> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8
>> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r
>> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL
>> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx
>> bLbbH2fh5bxDmDXDMdCF
>> =LLtP
>> -END PGP SIGNATURE-
>> ___
>> freebsd-annou...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-announce
>> To unsubscribe, send any mail to "freebsd-announce-unsubscr...@freebsd.org"
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-08 Thread Devin Teske

Which would you use?

ECDSA?

https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 


"" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover 
operation", cryptography experts have also expressed concern over the security 
of the NIST recommended elliptic curves,[31] 
 
suggesting a return to encryption based on non-elliptic-curve groups. ""

Or perhaps RSA? (as des@ recommends)

(not necessarily to Glen but anyone that wants to answer)
-- 
Devin


> On Aug 4, 2016, at 6:59 PM, Glen Barber  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
> 
> Please see r303716 for details on the relevant commit, but upstream no
> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
> keys as soon as possible, otherwise there will be issues when upgrading
> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
> 11.0-RELEASE build.
> 
> Glen
> On behalf of: re@ and secteam@
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb
> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK
> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl
> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR
> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u
> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs
> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c
> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8
> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r
> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL
> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx
> bLbbH2fh5bxDmDXDMdCF
> =LLtP
> -END PGP SIGNATURE-
> ___
> freebsd-annou...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-announce
> To unsubscribe, send any mail to "freebsd-announce-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Glen Barber

On Mon, Aug 08, 2016 at 10:53:26AM -0700, Nathan Whitehorn wrote:
> 
> 
> On 08/08/16 10:43, Lars Engels wrote:
> >On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote:
> >>>On Aug 8, 2016, at 8:02 AM, Lars Engels  wrote:
> >>>
> >>>On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:
> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:
> >On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:
> >>-BEGIN PGP SIGNED MESSAGE-
> >>o The new system hardening options have been fixed to avoid overwriting
> >>  other options selected during install time.
> >Can those options also get added to "bsdconfig"?
> You would have to ask the bsdconfig maintainer(s).
> 
> >>>Cc'ing dteske.
> >>>
> >>What aspects of bsdconfig need updating?
> >bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig
> >share a lot of code, so bsdconfig should probably also offer the
> >"hardening" module.
> 
> The hardening module should probably just be a part of bsdconfig, actually,
> and an option to open bsdconfig be an option at the end of the installer.
> 

In order for that to be an option, I'd strongly suggest updating
bsdconfig to properly detect packages on the DVD (which it has not since
10.0-RELEASE), as it makes too many incorrect assumptions.

Glen



signature.asc
Description: PGP signature

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Nathan Whitehorn




On 08/08/16 10:43, Lars Engels wrote:

On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote:

On Aug 8, 2016, at 8:02 AM, Lars Engels  wrote:

On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:

On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:

On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:

-BEGIN PGP SIGNED MESSAGE-
o The new system hardening options have been fixed to avoid overwriting
  other options selected during install time.

Can those options also get added to "bsdconfig"?

You would have to ask the bsdconfig maintainer(s).


Cc'ing dteske.


What aspects of bsdconfig need updating?

bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig
share a lot of code, so bsdconfig should probably also offer the
"hardening" module.


The hardening module should probably just be a part of bsdconfig, 
actually, and an option to open bsdconfig be an option at the end of the 
installer.

-Nathan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Devin Teske


> On Aug 8, 2016, at 8:02 AM, Lars Engels  wrote:
> 
> On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:
>> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:
>>> On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:
 -BEGIN PGP SIGNED MESSAGE-
>>> 
 o The new system hardening options have been fixed to avoid overwriting
  other options selected during install time.
>>> 
>>> Can those options also get added to "bsdconfig"?
>> 
>> You would have to ask the bsdconfig maintainer(s).
>> 
> 
> Cc'ing dteske.
> 

What aspects of bsdconfig need updating?
-- 
Devin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Lars Engels

On Mon, Aug 08, 2016 at 10:15:07AM -0700, Devin Teske wrote:
> 
> > On Aug 8, 2016, at 8:02 AM, Lars Engels  wrote:
> > 
> > On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:
> >> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:
> >>> On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:
>  -BEGIN PGP SIGNED MESSAGE-
> >>> 
>  o The new system hardening options have been fixed to avoid overwriting
>   other options selected during install time.
> >>> 
> >>> Can those options also get added to "bsdconfig"?
> >> 
> >> You would have to ask the bsdconfig maintainer(s).
> >> 
> > 
> > Cc'ing dteske.
> > 
> 
> What aspects of bsdconfig need updating?

bsdinstall has a new "hardening" module. AFAIK bsdinstall and bsdconfig
share a lot of code, so bsdconfig should probably also offer the
"hardening" module.


pgpG3LDevrZoQ.pgp
Description: PGP signature

Re: kernel panic caused by virtualbox(?)

2016-08-08 Thread John Baldwin

On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote:
> Reposted to -current to get some more eyes on this ...
> 
> I just got a kernel panic when I started up a CentOS 7 VM in virtualbox.
> The host is:
>   FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64
> The virtualbox version is:
>   virtualbox-ose-5.0.26
>   virtualbox-ose-kmod-5.0.26_1
> 
> The panic message is:
> 
> panic: Unregistered use of FPU in kernel
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe085a55d030
> vpanic() at vpanic+0x182/frame 0xfe085a55d0b0
> kassert_panic() at kassert_panic+0x126/frame 0xfe085a55d120
> trap() at trap+0x7ae/frame 0xfe085a55d330
> calltrap() at calltrap+0x8/frame 0xfe085a55d330
> --- trap 0x16, rip = 0x827dd3a9, rsp = 0xfe085a55d408, rbp = 
> 0xfe085a55d430 ---
> g_pLogger() at 0x827dd3a9/frame 0xfe085a55d430
> g_pLogger() at 0x8274e5c7/frame 0x3
> KDB: enter: panic
> 
> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is
> the trigger.
> 
> There are no symbols for the virtualbox kmods, possibly because I
> installed them as an upgrade using packages (built with the same source
> tree version) instead of by using PORTS_MODULES in make.conf, so ports
> kgdb didn't have anything useful to say about what happened before the
> trap.
> 
> This panic is very repeatable.  I just got another one when starting the
> same VM., but this time the two calls before the trap were
> null_bug_bypass().  Hmn, that symbol is in nullfs ...
> 
> I don't see this with a Windows 7 VM.
> 
> All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse
> -msoft-float -mno-aes -mno-avx

I suspect head packages are quite likely built against the a "wrong" KBI
and are too fragile to use for kmods vs compiling from ports. :-/  I would
try a built-from-ports kmod to see if the panics go away.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Lars Engels

On Mon, Aug 08, 2016 at 02:44:05PM +, Glen Barber wrote:
> On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:
> > On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > 
> > > o The new system hardening options have been fixed to avoid overwriting
> > >   other options selected during install time.
> > 
> > Can those options also get added to "bsdconfig"?
> 
> You would have to ask the bsdconfig maintainer(s).
> 

Cc'ing dteske.



pgphzR28U4r9O.pgp
Description: PGP signature

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Glen Barber

On Mon, Aug 08, 2016 at 10:48:30AM +0200, Lars Engels wrote:
> On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> 
> > o The new system hardening options have been fixed to avoid overwriting
> >   other options selected during install time.
> 
> Can those options also get added to "bsdconfig"?

You would have to ask the bsdconfig maintainer(s).

Glen



signature.asc
Description: PGP signature

Re: FreeBSD 11.0-BETA4 Now Available

2016-08-08 Thread Lars Engels

On Sat, Aug 06, 2016 at 09:05:26PM +, Glen Barber wrote:
> -BEGIN PGP SIGNED MESSAGE-

> o The new system hardening options have been fixed to avoid overwriting
>   other options selected during install time.

Can those options also get added to "bsdconfig"?


pgpDIfHtky6GL.pgp
Description: PGP signature

Re: lengthy sdhci timeouts on KBL-Y tester

lengthy sdhci timeouts on KBL-Y tester

Build failed in Jenkins: FreeBSD_HEAD #554

Re: kernel panic caused by virtualbox(?)

Re: some [big] changes to ZPL (ZFS<->VFS )

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

Re: kernel panic caused by virtualbox(?)

Re: kernel panic caused by virtualbox(?)

Re: kernel panic caused by virtualbox(?)

Re: FreeBSD 11.0-BETA4 Now Available

Re: FreeBSD 11.0-BETA4 Now Available

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

Re: FreeBSD 11.0-BETA4 Now Available

Re: FreeBSD 11.0-BETA4 Now Available

Re: FreeBSD 11.0-BETA4 Now Available

Re: FreeBSD 11.0-BETA4 Now Available

Re: kernel panic caused by virtualbox(?)

Re: FreeBSD 11.0-BETA4 Now Available

Re: FreeBSD 11.0-BETA4 Now Available

Re: FreeBSD 11.0-BETA4 Now Available

23 matches

Site Navigation

Mail list logo

Footer information