Re: /dev/crypto not being used in 12-STABLE

[Jeremy Chadwick]

I'm not subscribed to -stable.

This is in response to jkim@'s messages here:

https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html
https://lists.freebsd.org/pipermail/freebsd-stable/2018-December/090202.html

Based on what I can tell, OpenSSL 1.1.1 or thereabouts removed the
cryptodev OpenSSL engine, which was a tie-in to BSD's cryptodev(4),
which is accessed via /dev/crypto and related crypto(4) ioctls.

Instead, they offered a replacement engine called devcrypto (what an
awful name), with the primary focus being against something from Linux
called cryptodev-linux, then was made to work on FreeBSD 8.4.  This code
was as of June 2017; 8.4 was EOL'd August 2015.  Interesting.

https://github.com/openssl/openssl/commit/4f79aff is not "add support
for BSD" at all.  It's "tweak further stuff for BSD", probably to get it
to work on newer FreeBSD; they seem to care about crypto/cryptodev.h
details.  I asked myself: why do they care about that if they're doing
it all themselves?  Looking at the code sheds light on that.  The actual
devcrypto engine commits that added BSD support are here:

https://github.com/openssl/openssl/pull/3744
https://github.com/openssl/openssl/pull/3744/files

The commits indicate that the devcrypto is enabled by default on
FreeBSD.  But we can tell from Herbert's post and jkim@'s patch that's
not true at all, i.e. FreeBSD disables it.  Why?  And is that a good
default?  Here's why I ask:

The new devcrypto engine most definitely utilises /dev/crypto (thus
cryptodev(4) and crypto(4)).  cipher_init(), prepare_cipher_methods(),
digest_init(), and prepare_digest_methods() all utilise that interface:

https://github.com/openssl/openssl/pull/3744/files#diff-027f92eb0a10c0986aec873d9fd1ab66

So while OpenSSL now uses more of its own native C and assembly code
(e.g. for AES-NI support), and that's certainly faster than all the
overhead that cryptodev(4) brings with it (see jhb@'s post), I wonder:

1. What happens to people using crypto hardware accelerators, ex.
hifn(4), padlock(4), ubsec(4), and safe(4)?  How exactly would OpenSSL
utilise these H/W accelerators if the devcrypto engine is disabled?

2. If the devcrypto engine is *enabled*, and people have aesni(4)
loaded alongside cryptodev(4), which gets priority: OpenSSL's native
AES-NI code or cryptodev(4)/aesni(4)?

Likewise: if the decrypto engine is to remain disabled as a default:
this needs to be made crystal clear in Release Notes, so that folks
using H/W accelerators know they'll no longer benefit from those cards
unless they use a patch (third-party so/module won't work, AFAIT, as
OpenSSL's dynamic engine loading is unavailable per openssl engine -t).
Might I suggest enabling devcrypto be capable via src.conf, ex.
WITH_OPENSSL_ENGINE_DEVCRYPTO=true?

-- 
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administrator  PGP 0x2A389531 |
| Making life hard for others since 1977.|

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

Re: /dev/crypto not being used in 12-STABLE

[Konstantin Belousov]

On Thu, Dec 06, 2018 at 04:48:35PM -0700, John Nielsen wrote:
> Is aesni(4) even required if all you want is userland acceleration?
> 
No, it is not.  Same for rdrand_rng(4), if an application uses hw random
source directly.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: /dev/crypto not being used in 12-STABLE

[Jung-uk Kim]

On 18. 12. 6., Jung-uk Kim wrote:
> On 18. 12. 6., John Nielsen wrote:
>>> On Dec 6, 2018, at 4:04 PM, Xin LI  wrote:
>>>
>>> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen  wrote:

 I have upgraded two physical machines from 11-STABLE to 12-STABLE recently 
 (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). 
 I noticed today that neither machine seems to be utilizing /dev/crypto. 
 Typically I see at least ssh/sshd have the device open plus some programs 
 from ports. But 'fuser' doesn't list any processes on either machine:

 # fuser /dev/crypto
 /dev/crypto:

 Both machines are running custom kernels that include "device crypto" and 
 "device cryptodev". One of them additionally has "device aesni".

 Is anyone else seeing this? Any idea what would cause it?
>>>
>>> Your average OpenSSL applications should not use /dev/crypto, if your
>>> goal is to utilize AES-NI (which does not require /dev/crypto).  On
>>> capable systems, AES-NI would be used automatically (and it's faster
>>> this way).
>>
>> Thanks for the response. Is there a way to verify that AES-NI is being used 
>> for e.g. ssh?
>> I'm also curious why/when/how the change to not use (or support?) 
>> /dev/crypto from base
>> openssl was made.
> 
> OpenSSL 1.1.1 removed the old cryptodev:
> 
> https://svnweb.freebsd.org/base/vendor-crypto/openssl/dist/CHANGES?revision=340690=markup#l400
> 
> Instead, OpenSSL added devcrypto engine for Linux:
> 
> https://github.com/openssl/openssl/commit/619eb33
> 
> and added BSD support:
> 
> https://github.com/openssl/openssl/commit/4f79aff
> 
> then, completely removed BSD-specific cryptodev:
> 
> https://github.com/openssl/openssl/commit/f39a550
> 
> However, it is disabled by default.  Theoretically, it is functionally
> equivalent but it wasn't tested much.
> 
> I can enable the new engine on head if many users request it.

FYI, the attached patch should enable the new engine.

Jung-uk Kim
Index: secure/lib/libcrypto/Makefile
===
--- secure/lib/libcrypto/Makefile	(revision 341666)
+++ secure/lib/libcrypto/Makefile	(working copy)
@@ -192,8 +192,8 @@ SRCS+=	ecp_nistz256-x86.S ecp_nistz256.c
 .endif
 
 # engine
-SRCS+=	eng_all.c eng_cnf.c eng_ctrl.c eng_dyn.c eng_err.c eng_fat.c
-SRCS+=	eng_init.c eng_lib.c eng_list.c eng_openssl.c eng_pkey.c
+SRCS+=	eng_all.c eng_cnf.c eng_ctrl.c eng_devcrypto.c eng_dyn.c eng_err.c
+SRCS+=	eng_fat.c eng_init.c eng_lib.c eng_list.c eng_openssl.c eng_pkey.c
 SRCS+=	eng_rdrand.c eng_table.c tb_asnmth.c tb_cipher.c tb_dh.c tb_digest.c
 SRCS+=	tb_dsa.c tb_eckey.c tb_pkmeth.c tb_rand.c tb_rsa.c
 
Index: secure/lib/libcrypto/opensslconf.h.in
===
--- secure/lib/libcrypto/opensslconf.h.in	(revision 341666)
+++ secure/lib/libcrypto/opensslconf.h.in	(working copy)
@@ -46,9 +46,6 @@ extern "C" {
 #ifndef OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
 # define OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
 #endif
-#ifndef OPENSSL_NO_DEVCRYPTOENG
-# define OPENSSL_NO_DEVCRYPTOENG
-#endif
 #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128
 # define OPENSSL_NO_EC_NISTP_64_GCC_128
 #endif


signature.asc
Description: OpenPGP digital signature

Re: /dev/crypto not being used in 12-STABLE

[Jung-uk Kim]

On 18. 12. 6., John Nielsen wrote:
>> On Dec 6, 2018, at 4:04 PM, Xin LI  wrote:
>>
>> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen  wrote:
>>>
>>> I have upgraded two physical machines from 11-STABLE to 12-STABLE recently 
>>> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). 
>>> I noticed today that neither machine seems to be utilizing /dev/crypto. 
>>> Typically I see at least ssh/sshd have the device open plus some programs 
>>> from ports. But 'fuser' doesn't list any processes on either machine:
>>>
>>> # fuser /dev/crypto
>>> /dev/crypto:
>>>
>>> Both machines are running custom kernels that include "device crypto" and 
>>> "device cryptodev". One of them additionally has "device aesni".
>>>
>>> Is anyone else seeing this? Any idea what would cause it?
>>
>> Your average OpenSSL applications should not use /dev/crypto, if your
>> goal is to utilize AES-NI (which does not require /dev/crypto).  On
>> capable systems, AES-NI would be used automatically (and it's faster
>> this way).
> 
> Thanks for the response. Is there a way to verify that AES-NI is being used 
> for e.g. ssh?
> I'm also curious why/when/how the change to not use (or support?) /dev/crypto 
> from base
> openssl was made.

OpenSSL 1.1.1 removed the old cryptodev:

https://svnweb.freebsd.org/base/vendor-crypto/openssl/dist/CHANGES?revision=340690=markup#l400

Instead, OpenSSL added devcrypto engine for Linux:

https://github.com/openssl/openssl/commit/619eb33

and added BSD support:

https://github.com/openssl/openssl/commit/4f79aff

then, completely removed BSD-specific cryptodev:

https://github.com/openssl/openssl/commit/f39a550

However, it is disabled by default.  Theoretically, it is functionally
equivalent but it wasn't tested much.

I can enable the new engine on head if many users request it.

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature

Re: /dev/crypto not being used in 12-STABLE

[John Nielsen]

> On Dec 6, 2018, at 4:39 PM, John Baldwin  wrote:
> 
> On 12/6/18 3:24 PM, John Nielsen wrote:
>>> On Dec 6, 2018, at 4:04 PM, Xin LI  wrote:
>>> 
>>> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen  wrote:
 
 I have upgraded two physical machines from 11-STABLE to 12-STABLE recently 
 (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). 
 I noticed today that neither machine seems to be utilizing /dev/crypto. 
 Typically I see at least ssh/sshd have the device open plus some programs 
 from ports. But 'fuser' doesn't list any processes on either machine:
 
 # fuser /dev/crypto
 /dev/crypto:
 
 Both machines are running custom kernels that include "device crypto" and 
 "device cryptodev". One of them additionally has "device aesni".
 
 Is anyone else seeing this? Any idea what would cause it?
>>> 
>>> Your average OpenSSL applications should not use /dev/crypto, if your
>>> goal is to utilize AES-NI (which does not require /dev/crypto).  On
>>> capable systems, AES-NI would be used automatically (and it's faster
>>> this way).
>> 
>> Thanks for the response. Is there a way to verify that AES-NI is being used 
>> for e.g. ssh? I'm also curious why/when/how the change to not use (or 
>> support?) /dev/crypto from base openssl was made.
> 
> I suspect it was something we just didn't test in the flurry of other work
> during the OpenSSL upgrade.

I did wonder about that. :)

> However, it is much faster to use the AES-NI
> instructions in userland than to use a system call that copies the data
> into a kernel buffer, uses the sames AES-NI instructions, then copies the
> data back out again along with the overhead of a pair of user <--> kernel
> transitions.  If you have an actual crypto offload device (as in a PCI-e
> card or something), then you might be interested in /dev/crypto (and we
> should fix that eventually), but AES-NI is just faster software crypto and
> is best done directly in userland.

That makes sense and explains some other comments I was just reading. Is 
aesni(4) even required if all you want is userland acceleration?

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

Re: /dev/crypto not being used in 12-STABLE

[Xin LI]

On Thu, Dec 6, 2018 at 3:24 PM John Nielsen  wrote:
>
> > On Dec 6, 2018, at 4:04 PM, Xin LI  wrote:
> >
> > On Thu, Dec 6, 2018 at 11:37 AM John Nielsen  wrote:
> >>
> >> I have upgraded two physical machines from 11-STABLE to 12-STABLE recently 
> >> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). 
> >> I noticed today that neither machine seems to be utilizing /dev/crypto. 
> >> Typically I see at least ssh/sshd have the device open plus some programs 
> >> from ports. But 'fuser' doesn't list any processes on either machine:
> >>
> >> # fuser /dev/crypto
> >> /dev/crypto:
> >>
> >> Both machines are running custom kernels that include "device crypto" and 
> >> "device cryptodev". One of them additionally has "device aesni".
> >>
> >> Is anyone else seeing this? Any idea what would cause it?
> >
> > Your average OpenSSL applications should not use /dev/crypto, if your
> > goal is to utilize AES-NI (which does not require /dev/crypto).  On
> > capable systems, AES-NI would be used automatically (and it's faster
> > this way).
>
> Thanks for the response. Is there a way to verify that AES-NI is being used 
> for e.g. ssh? I'm also curious why/when/how the change to not use (or 
> support?) /dev/crypto from base openssl was made.

You can disable the use of AES by passing environment variable
OPENSSL_ia32cap and compare the speed, e.g.:

OPENSSL_ia32cap="~0x200" openssl speed -evp aes-128-cbc

(disabled bit 57, or ~0x200 means to disable the AES-NI
capability bit).

On most systems, using AES-NI is about twice fast, personally I don't
really see a reason why people would want to disable it in production
(even for security reasons), though, but yes there is an option.

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

Re: /dev/crypto not being used in 12-STABLE

[John Baldwin]

On 12/6/18 3:24 PM, John Nielsen wrote:
>> On Dec 6, 2018, at 4:04 PM, Xin LI  wrote:
>>
>> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen  wrote:
>>>
>>> I have upgraded two physical machines from 11-STABLE to 12-STABLE recently 
>>> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). 
>>> I noticed today that neither machine seems to be utilizing /dev/crypto. 
>>> Typically I see at least ssh/sshd have the device open plus some programs 
>>> from ports. But 'fuser' doesn't list any processes on either machine:
>>>
>>> # fuser /dev/crypto
>>> /dev/crypto:
>>>
>>> Both machines are running custom kernels that include "device crypto" and 
>>> "device cryptodev". One of them additionally has "device aesni".
>>>
>>> Is anyone else seeing this? Any idea what would cause it?
>>
>> Your average OpenSSL applications should not use /dev/crypto, if your
>> goal is to utilize AES-NI (which does not require /dev/crypto).  On
>> capable systems, AES-NI would be used automatically (and it's faster
>> this way).
> 
> Thanks for the response. Is there a way to verify that AES-NI is being used 
> for e.g. ssh? I'm also curious why/when/how the change to not use (or 
> support?) /dev/crypto from base openssl was made.

I suspect it was something we just didn't test in the flurry of other work
during the OpenSSL upgrade.  However, it is much faster to use the AES-NI
instructions in userland than to use a system call that copies the data
into a kernel buffer, uses the sames AES-NI instructions, then copies the
data back out again along with the overhead of a pair of user <--> kernel
transitions.  If you have an actual crypto offload device (as in a PCI-e
card or something), then you might be interested in /dev/crypto (and we
should fix that eventually), but AES-NI is just faster software crypto and
is best done directly in userland.

-- 
John Baldwin


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

Re: /dev/crypto not being used in 12-STABLE

[John Nielsen]

> On Dec 6, 2018, at 4:04 PM, Xin LI  wrote:
> 
> On Thu, Dec 6, 2018 at 11:37 AM John Nielsen  wrote:
>> 
>> I have upgraded two physical machines from 11-STABLE to 12-STABLE recently 
>> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). I 
>> noticed today that neither machine seems to be utilizing /dev/crypto. 
>> Typically I see at least ssh/sshd have the device open plus some programs 
>> from ports. But 'fuser' doesn't list any processes on either machine:
>> 
>> # fuser /dev/crypto
>> /dev/crypto:
>> 
>> Both machines are running custom kernels that include "device crypto" and 
>> "device cryptodev". One of them additionally has "device aesni".
>> 
>> Is anyone else seeing this? Any idea what would cause it?
> 
> Your average OpenSSL applications should not use /dev/crypto, if your
> goal is to utilize AES-NI (which does not require /dev/crypto).  On
> capable systems, AES-NI would be used automatically (and it's faster
> this way).

Thanks for the response. Is there a way to verify that AES-NI is being used for 
e.g. ssh? I'm also curious why/when/how the change to not use (or support?) 
/dev/crypto from base openssl was made.

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

Re: /dev/crypto not being used in 12-STABLE

[Xin LI]

On Thu, Dec 6, 2018 at 11:37 AM John Nielsen  wrote:
>
> I have upgraded two physical machines from 11-STABLE to 12-STABLE recently 
> (one is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). I 
> noticed today that neither machine seems to be utilizing /dev/crypto. 
> Typically I see at least ssh/sshd have the device open plus some programs 
> from ports. But 'fuser' doesn't list any processes on either machine:
>
> # fuser /dev/crypto
> /dev/crypto:
>
> Both machines are running custom kernels that include "device crypto" and 
> "device cryptodev". One of them additionally has "device aesni".
>
> Is anyone else seeing this? Any idea what would cause it?

Your average OpenSSL applications should not use /dev/crypto, if your
goal is to utilize AES-NI (which does not require /dev/crypto).  On
capable systems, AES-NI would be used automatically (and it's faster
this way).

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

Re: /dev/crypto not being used in 12-STABLE

[Herbert J. Skuhra]

On Thu, 06 Dec 2018 20:19:44 +0100, John Nielsen wrote:
> 
> I have upgraded two physical machines from 11-STABLE to 12-STABLE
> recently (one is 12.0-PRERELEASE r341380 and the other is
> 12.0-PRERELEASE r341391). I noticed today that neither machine seems
> to be utilizing /dev/crypto. Typically I see at least ssh/sshd have
> the device open plus some programs from ports. But 'fuser' doesn't
> list any processes on either machine:
> 
> # fuser /dev/crypto
> /dev/crypto:
> 
> Both machines are running custom kernels that include "device
> crypto" and "device cryptodev". One of them additionally has "device
> aesni".
> 
> Is anyone else seeing this? Any idea what would cause it?

With security/openssl (1.0.2q):

% /usr/local/bin/openssl engine
(cryptodev) BSD cryptodev engine
(rdrand) Intel RDRAND engine
(dynamic) Dynamic engine loading support

% /usr/local/bin/openssl speed -engine cryptodev
engine "cryptodev" set.

With openssl 1.1.1a from base (and security/openssl111):

% openssl engine
(rdrand) Intel RDRAND engine
(dynamic) Dynamic engine loading support

% openssl speed -engine cryptodev
invalid engine "cryptodev"
34371112960:error:25066067:DSO support routines:dlfcn_load:could not load the 
shared 
library:/usr/src/crypto/openssl/crypto/dso/dso_dlfcn.c:117:filename(/usr/lib/engines/cryptodev.so):
 Cannot open "/usr/lib/engines/cryptodev.so"
34371112960:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:/usr/src/crypto/openssl/crypto/dso/dso_lib.c:162:
34371112960:error:260B6084:engine routines:dynamic_load:dso not 
found:/usr/src/crypto/openssl/crypto/engine/eng_dyn.c:414:
34371112960:error:2606A074:engine routines:ENGINE_by_id:no such 
engine:/usr/src/crypto/openssl/crypto/engine/eng_list.c:334:id=cryptodev
34371112960:error:25066067:DSO support routines:dlfcn_load:could not load the 
shared 
library:/usr/src/crypto/openssl/crypto/dso/dso_dlfcn.c:117:filename(libcryptodev.so):
 Shared object "libcryptodev.so" not found, required by "openssl"
34371112960:error:25070067:DSO support routines:DSO_load:could not load the 
shared library:/usr/src/crypto/openssl/crypto/dso/dso_lib.c:162:
34371112960:error:260B6084:engine routines:dynamic_load:dso not 
found:/usr/src/crypto/openssl/crypto/engine/eng_dyn.c:414:

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

/dev/crypto not being used in 12-STABLE

[John Nielsen]

I have upgraded two physical machines from 11-STABLE to 12-STABLE recently (one 
is 12.0-PRERELEASE r341380 and the other is 12.0-PRERELEASE r341391). I noticed 
today that neither machine seems to be utilizing /dev/crypto. Typically I see 
at least ssh/sshd have the device open plus some programs from ports. But 
'fuser' doesn't list any processes on either machine:

# fuser /dev/crypto
/dev/crypto:

Both machines are running custom kernels that include "device crypto" and 
"device cryptodev". One of them additionally has "device aesni".

Is anyone else seeing this? Any idea what would cause it?

Thanks,

JN

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

Re: Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)

[Navdeep Parhar]

Can you please file a bug at https://bugs.freebsd.org/bugzilla/ and
assign it to me?

Regards,
Navdeep

On 12/6/18 4:02 AM, Trond Endrestøl wrote:
> After booting stable/12 r341604, running a custom kernel including 
> cxgbe(4), cxgbev(4), and ccr(4), and running swapon -a in SU mode:
> 
> GEOM_ELI: Device gpt/swap0.eli created.
> GEOM_ELI: Encryption: AES-XTS 256
> GEOM_ELI: Crypto: hardware
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 06
> fault virtual address   = 0x0
> fault code  = supervisor write data, page not present
> instruction pointer = 0x20:0x805be1b2
> stack pointer   = 0x28:0xfe00a6253770
> frame pointer   = 0x28:0xfe00a6253770
> 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 = 65 (g_eli[3] gpt/swap0)
> trap number = 12
> panic: page fault
> cpuid = 3
> time = 1544087308
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x8055d9eb = 
> db_trace_self_wrapper+0x2b/frame 0xfe00a6253420
> vpanic() at 0x808754d3 = vpanic+0x1a3/frame 0xfe00a6253480
> panic() at 0x80875323 = panic+0x43/frame 0xfe00a62534e0
> trap_fatal() at 0x80bd745f = trap_fatal+0x35f/frame 0xfe00a6253530
> trap_pfault() at 0x80bd74b9 = trap_pfault+0x49/frame 
> 0xfe00a4b7f590
> trap() at 0x80bd6ade = trap+0x29e/frame 0xfe00a4b7f6a0
> calltrap() at 0x80bb3935 = calltrap+0x8/frame 0xfe00a4b7f6a0
> --- trap 0xc, rip = 0x805be1b2, rsp = 0xfe00a4b7f770, rbp = 
> 0xfe00a4b7f770
> t4_wrq_tx_locked() at 0x805be1b2 = t4_wrq_tx_locked+0x12/frame 
> 0xfe00a6253770
> ccr_process() at 0x805e3fc3 = ccr_process+0x1953/frame 
> 0xfe00a4b7f970
> crypto_dispatch() at 0x80ae3fa4 = crypto_dispatch+0x144/frame 
> 0xfe00a4b7f9b0
> g_eli_crypto_run() at 0x807b5cb3 = g_eli_crypto_run+0x273/frame 
> 0xfe00a4b7fa10
> g_eli_worker() at 0x807aebc8 = g_eli_worker+0x3c8/frame 
> 0xfe00a4b7fa70
> fork_exit() at 0x80834d93 = fork_exit+0x83/frame 0xfe00a4b7fab0
> fork_trampoline() at 0x80bb491e = fork_trampoline+0xe/frame 
> 0xfe00a4b7fab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> Uptime: 14s
> Automatic reboot in 15 seconds - press a key on the console to abort
> --> Press a key on the console to reboot,
> 
> The Chelsio NIC is a T6225-CR.
> 
> Kernel config is 
> https://ximalas.info/~trond/create-zfs/canmount/ENTERPRISE-amd64-stable-12
> 
> I tried stable/12 r341623 with ccr(4) removed from the kernel, and I 
> had no problems engaging geli encrypted swap in SU mode nor in normal 
> mode.
> 
> Has anyone else tried ccr(4) on recent stable/12?
> Are we discouraged from using ccr(4)?
> I was hoping to take advantage of the crypto accelerator.
> 


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

Re: Trouble with headphones and hda audio

[Christian Stærk]

On 12/6/18 3:16 PM, David Wolfskill wrote:

On Thu, Dec 06, 2018 at 03:02:43PM +0100, Christian Stærk wrote:

I have a new laptop. It's running 11.2-RELEASE.

While sound on the speakers works fine, sound through the headphones
does not.
.
Some of us who had a problem of this nature (in the cases with which I
am familiar, the headphones produced a loud hissing/static-type noise,
regardless of volume settings or attempts to play sound through them)
have found that the circumvention in
 has been effective.

It works somewhat.

The sound doesn't switch to headphones automatically when they are 
plugged in, but I can change hw.snd.default_unit to 1 and sound will 
then play on the headphones.


Thank you for the tip.

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

Re: vt(4)-related hang of 11.2

[Eugene Grosbein]

 In most cases it's just wrong info passed from UEFI firmware about FB.
 try to hardcode FrameBuffer params into vt_efb driver, to know exatly.
>>>
>>> Forgot to add importand detail: it boots and works with vt(4) using FreeBSD 
>>> 11.1.
>>>
>>
>> r322258 is known working stable/11 revison that booted such a system with 
>> default console just fine;
>> stable/11 r338465 hangs.
> 
> Looking at the diff, I see I should try hw.vga.acpi_ignore_no_vga=1 that 
> stable/11 got in between...
> I'll try next day and respond.

hw.vga.acpi_ignore_no_vga=1 solved the problem and now it boots with vt(4) just 
fine.

The question is: why it hangs and does not boot "blind" without this setting?
Can it panic maybe?

This box has no COM-port at glance (for serial console) but dmidecode reports 
it has...

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

Re: vt(4)-related hang of 11.2

[Eugene Grosbein]

On 06.12.2018 23:01, Eugene Grosbein wrote:

>>> In most cases it's just wrong info passed from UEFI firmware about FB.
>>> try to hardcode FrameBuffer params into vt_efb driver, to know exatly.
>>
>> Forgot to add importand detail: it boots and works with vt(4) using FreeBSD 
>> 11.1.
>>
>>
> 
> r322258 is known working stable/11 revison that booted such a system with 
> default console just fine;
> stable/11 r338465 hangs.

Looking at the diff, I see I should try hw.vga.acpi_ignore_no_vga=1 that 
stable/11 got in between...
I'll try next day and respond.

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

Re: vt(4)-related hang of 11.2

[Eugene Grosbein]

On 06.12.2018 22:52, Eugene Grosbein wrote:
> On 06.12.2018 20:57, Aleksandr Rybalko wrote:
> 
>> In most cases it's just wrong info passed from UEFI firmware about FB.
>> try to hardcode FrameBuffer params into vt_efb driver, to know exatly.
> 
> Forgot to add importand detail: it boots and works with vt(4) using FreeBSD 
> 11.1.
> 
> 

r322258 is known working stable/11 revison that booted such a system with 
default console just fine;
stable/11 r338465 hangs.

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

Re: vt(4)-related hang of 11.2

[Eugene Grosbein]

On 06.12.2018 20:57, Aleksandr Rybalko wrote:

> In most cases it's just wrong info passed from UEFI firmware about FB.
> try to hardcode FrameBuffer params into vt_efb driver, to know exatly.

Forgot to add importand detail: it boots and works with vt(4) using FreeBSD 
11.1.


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

Re: Trouble with headphones and hda audio

[David Wolfskill]

On Thu, Dec 06, 2018 at 03:02:43PM +0100, Christian Stærk wrote:
> Hello,
> 
> I have a new laptop. It's running 11.2-RELEASE.
> 
> While sound on the speakers works fine, sound through the headphones 
> does not.
> .

Some of us who had a problem of this nature (in the cases with which I
am familiar, the headphones produced a loud hissing/static-type noise,
regardless of volume settings or attempts to play sound through them)
have found that the circumvention in
 has been effective.

You might try it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"... but the rest of the world is not a Trump MAGA rally/."

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: vt(4)-related hang of 11.2

[Eugene Grosbein]

On 06.12.2018 20:57, Aleksandr Rybalko wrote:
> Hi, Eugene!
> 
> In most cases it's just wrong info passed from UEFI firmware about FB.
> try to hardcode FrameBuffer params into vt_efb driver, to know exatly.

I'm not familiar with vt_efb code. Can you please elaborate what should I do to 
debug this, exactly?


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

Trouble with headphones and hda audio

[Christian Stærk]

Hello,

I have a new laptop. It's running 11.2-RELEASE.

While sound on the speakers works fine, sound through the headphones 
does not.


From dmesg:
hdac0:  mem 
0xa1318000-0xa131bfff,0xa100-0xa10f irq 16 at device 31.3 on pci0

hdacc0:  at cad 0 on hdac0
hdaa0:  at nid 1 on hdacc0
pcm0:  at nid 20 and 18 on hdaa0
pcm1:  at nid 33 on hdaa0
hdacc1:  at cad 2 on hdac0
hdaa1:  at nid 1 on hdacc1
pcm2:  at nid 3 on hdaa1

I have tried setting hw.snd.default_unit=1. Then there is no sound 
neither on the speakers or in the headphones.


As I was searching for a solution, I found out that I should do a pindump.

Pindump with the headphones unplugged:
hdaa0: Dumping AFG pins:
hdaa0: nid   0x    as seq device   conn  jack    loc color   misc
hdaa0: 18 b7a60130 3  0  Mic   Fixed Digital Lid-In Unknown 1
hdaa0: Caps: IN
hdaa0: 19 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN
hdaa0: 20 90170110 1  0  Speaker   Fixed Analog  Internal Unknown 1
hdaa0: Caps:    OUT    EAPD  Sense: 0x (disconnected)
hdaa0: 22 4000 0  0  Line-out  None  Unknown 0x00 Unknown 0 DISA
hdaa0: Caps:    OUT HP   Sense: 0x (disconnected)
hdaa0: 23 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps:    OUT HP   Sense: 0x (disconnected)
hdaa0: 24 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN  Sense: 0x (disconnected)
hdaa0: 25 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN VREF Sense: 0x (disconnected)
hdaa0: 26 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN VREF Sense: 0x (disconnected)
hdaa0: 27 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN OUT    EAPD VREF Sense: 0x (disconnected)
hdaa0: 30 42e213f2 15 2  Res.E None  1/4 Front Black   3 DISA
hdaa0: Caps:    OUT
hdaa0: 33 04211020 2  0  Headphones    Jack  1/8 Right Black   0
hdaa0: Caps:    OUT HP EAPD  Sense: 0x (disconnected)
hdaa0: NumGPIO=3 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1
hdaa0:  GPIO0: disabled
hdaa0:  GPIO1: disabled
hdaa0:  GPIO2: disabled

Pindump with the headphones plugged in:
hdaa1: Dumping AFG pins:
hdaa1: nid   0x    as seq device   conn  jack    loc color   misc
hdaa1:  3 18560010 1  0  Digital-out   Jack  Digital 0x18 Unknown 0
hdaa1: Caps:    OUT  Sense: 0x (disconnected)
hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0
hdaa0: Dumping AFG pins:
hdaa0: nid   0x    as seq device   conn  jack    loc color   misc
hdaa0: 18 b7a60130 3  0  Mic   Fixed Digital Lid-In Unknown 1
hdaa0: Caps: IN
hdaa0: 19 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN
hdaa0: 20 90170110 1  0  Speaker   Fixed Analog  Internal Unknown 1
hdaa0: Caps:    OUT    EAPD  Sense: 0x (disconnected)
hdaa0: 22 4000 0  0  Line-out  None  Unknown 0x00 Unknown 0 DISA
hdaa0: Caps:    OUT HP   Sense: 0x (disconnected)
hdaa0: 23 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps:    OUT HP   Sense: 0x (disconnected)
hdaa0: 24 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN  Sense: 0x (disconnected)
hdaa0: 25 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN VREF Sense: 0x (disconnected)
hdaa0: 26 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN VREF Sense: 0x (disconnected)
hdaa0: 27 41f0 15 0  Speaker   None  1/8 Rear Black   1 DISA
hdaa0: Caps: IN OUT    EAPD VREF Sense: 0x (disconnected)
hdaa0: 30 42e213f2 15 2  Res.E None  1/4 Front Black   3 DISA
hdaa0: Caps:    OUT
hdaa0: 33 04211020 2  0  Headphones    Jack  1/8 Right Black   0
hdaa0: Caps:    OUT HP EAPD  Sense: 0x8000 (connected)
hdaa0: NumGPIO=3 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1
hdaa0:  GPIO0: disabled
hdaa0:  GPIO1: disabled
hdaa0:  GPIO2: disabled
hdaa1: Dumping AFG pins:
hdaa1: nid   0x    as seq device   conn  jack    loc color   misc
hdaa1:  3 18560010 1  0  Digital-out   Jack  Digital 0x18 Unknown 0
hdaa1: Caps:    OUT  Sense: 0x (disconnected)
hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0

Can anyone help me fixing this?

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

Re: vt(4)-related hang of 11.2

[Eugene Grosbein]

On 06.12.2018 20:52, Eugene Grosbein wrote:
> Hi!
> 
> I ran across several systems based on AMI Aptio CRB CLBTM210 equiped with 
> Intel J1900 processor
> that hang early at boot in the moment of kernel initialisation unless forced 
> to use syscons(4) console driver
> instead of default vt(4). Here is screen photo of one of such systems in such 
> dead state
> started with vt(4), boot_verbose and verbose_loading enabled:
> 
> http://www.grosbein.net/freebsd/11hang.jpg
> 
> It boots and works just fine with syscons. The system in question is 
> 11.2-STABLE/amd64 r341225.
> 
> One of such boxes is ready to produce additional debug output, if needed, 
> test patches etc.
> for about a week, then it will go in production to some remote site.

Forgot to include its /boot/loader.conf:

alias_cuseeme_load="YES"
alias_dummy_load="YES"
alias_ftp_load="YES"
alias_irc_load="YES"
alias_nbt_load="YES"
alias_pptp_load="YES"
alias_skinny_load="YES"
alias_smedia_load="YES"
libalias_load="YES"

hw.em.rxd=4096
hw.em.txd=4096
hw.em.max_interrupt_rate=32000
hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.max_interrupt_rate=32000

mac_portacl_load="YES"
dummynet_load="YES"
geom_mirror_load="YES"
#EOF


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

Re: vt(4)-related hang of 11.2

[Aleksandr Rybalko]

Hi, Eugene!

In most cases it's just wrong info passed from UEFI firmware about FB.
try to hardcode FrameBuffer params into vt_efb driver, to know exatly.

Thanks.

чт, 6 груд. 2018 о 15:52 Eugene Grosbein  пише:

> Hi!
>
> I ran across several systems based on AMI Aptio CRB CLBTM210 equiped with
> Intel J1900 processor
> that hang early at boot in the moment of kernel initialisation unless
> forced to use syscons(4) console driver
> instead of default vt(4). Here is screen photo of one of such systems in
> such dead state
> started with vt(4), boot_verbose and verbose_loading enabled:
>
> http://www.grosbein.net/freebsd/11hang.jpg
>
> It boots and works just fine with syscons. The system in question is
> 11.2-STABLE/amd64 r341225.
>
> One of such boxes is ready to produce additional debug output, if needed,
> test patches etc.
> for about a week, then it will go in production to some remote site.
>
> It processes nextboot.conf as expected even if started with vt(4), if this
> matters.
>
> Here is its kernel config file:
>
> include GENERIC
> ident   Base11
> options IPDIVERT
> options IPFIREWALL
> options IPFIREWALL_VERBOSE
> options IPFIREWALL_VERBOSE_LIMIT=100
> options IPFIREWALL_DEFAULT_TO_ACCEPT
> device  enc
> #EOF
>
> According to kern.conftxt, it has options VESA and
>
> device  vt
> device  vt_vga
> device  vt_efifb
>
> Its dmesg.boot and pciconf output follow (started with syscons):
>
> Copyright (c) 1992-2018 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.2-STABLE #0 r341225: Thu Nov 29 21:47:09 MSK 2018
> a...@base11.zonov.ru:/data/obj/data/src/sys/Base11 amd64
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM
> 6.0.1)
> CPU: Intel(R) Celeron(R) CPU  J1900  @ 1.99GHz (2000.05-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x30678  Family=0x6  Model=0x37  Stepping=8
>
> Features=0xbfebfbff
>
> Features2=0x41d8e3bf
>   AMD Features=0x28100800
>   AMD Features2=0x101
>   Structured Extended Features=0x2282
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 4294967296 (4096 MB)
> avail memory = 3962818560 (3779 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> WARNING: L1 data cache covers less APIC IDs than a core
> 0 < 1
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 4 core(s)
> Security policy loaded: TrustedBSD MAC/portacl (mac_portacl)
> Firmware Warning (ACPI): 32/64X length mismatch in FADT/Gpe0Block: 128/32
> (20171214/tbfadt-748)
> WARNING: Bogus Interrupt Trigger Mode. Assume CONFORMS.
> WARNING: Bogus Interrupt Polarity. Assume CONFORMS
> ioapic0  irqs 0-86 on motherboard
> SMP: AP CPU #3 Launched!
> SMP: AP CPU #2 Launched!
> SMP: AP CPU #1 Launched!
> Timecounter "TSC" frequency 254736 Hz quality 1000
> random: entropy device external interface
> kbd0 at kbdmux0
> netmap: loaded module
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> nexus0
> cryptosoft0:  on motherboard
> acpi0:  on motherboard
> acpi0: Power Button (fixed)
> unknown: I/O range not supported
> cpu0:  on acpi0
> cpu1:  on acpi0
> cpu2:  on acpi0
> cpu3:  on acpi0
> atrtc0:  port 0x70-0x77 on acpi0
> atrtc0: Warning: Couldn't map I/O.
> atrtc0: registered as a time-of-day clock, resolution 1.00s
> Event timer "RTC" frequency 32768 Hz quality 0
> hpet0:  iomem 0xfed0-0xfed003ff irq 8 on
> acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 950
> Event timer "HPET" frequency 14318180 Hz quality 450
> Event timer "HPET1" frequency 14318180 Hz quality 440
> Event timer "HPET2" frequency 14318180 Hz quality 440
> attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Event timer "i8254" frequency 1193182 Hz quality 100
> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
> pcib0:  port 0xcf8-0xcff on acpi0
> pcib0: _OSC returned error 0x10
> pci0:  on pcib0
> vgapci0:  port 0xf080-0xf087 mem
> 0xd000-0xd03f,0xc000-0xcfff irq 16 at device 2.0 on pci0
> vgapci0: Boot video device
> ahci0:  port
> 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem
> 0xd0a16000-0xd0a167ff irq 19 at device 19.0 on pci0
> ahci0: AHCI v1.30 with 2 3Gbps ports, Port Multiplier not supported
> ahcich0:  at channel 0 on ahci0
> xhci0:  mem 0xd0a0-0xd0a0 irq
> 20 at device 20.0 on pci0
> xhci0: 32 bytes context size, 64-bit DMA
> xhci0: Port routing mask set to 0x
> usbus0 on xhci0
> usbus0: 5.0Gbps Super Speed USB v3.0
> pci0:  at device 26.0 (no driver attached)
> hdac0:  mem 0xd0a1-0xd0a13fff irq 22 at
> 

Re: Upgrading via source build, 10.4->11.2

[Simon Wright]

On 06/12/2018 21:34, George Mitchell wrote:

so that I can installkernel and installworld on them in single user
mode (hard to use NFS when booting in single user).-- George


# cd /usr/src
# make installkernel KERNCONF=GENERIC (or whatever)

reboot then repeat with installworld:

# mount -a -t ufs
# /etc/netstart
then, assuming you have /usr/src nfs mounted in fstab
# mount -a -t nfs
# cd /usr/src
# make installworld


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

vt(4)-related hang of 11.2

[Eugene Grosbein]

Hi!

I ran across several systems based on AMI Aptio CRB CLBTM210 equiped with Intel 
J1900 processor
that hang early at boot in the moment of kernel initialisation unless forced to 
use syscons(4) console driver
instead of default vt(4). Here is screen photo of one of such systems in such 
dead state
started with vt(4), boot_verbose and verbose_loading enabled:

http://www.grosbein.net/freebsd/11hang.jpg

It boots and works just fine with syscons. The system in question is 
11.2-STABLE/amd64 r341225.

One of such boxes is ready to produce additional debug output, if needed, test 
patches etc.
for about a week, then it will go in production to some remote site.

It processes nextboot.conf as expected even if started with vt(4), if this 
matters.

Here is its kernel config file:

include GENERIC
ident   Base11
options IPDIVERT
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFIREWALL_DEFAULT_TO_ACCEPT
device  enc
#EOF

According to kern.conftxt, it has options VESA and

device  vt
device  vt_vga
device  vt_efifb

Its dmesg.boot and pciconf output follow (started with syscons):

Copyright (c) 1992-2018 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.2-STABLE #0 r341225: Thu Nov 29 21:47:09 MSK 2018
a...@base11.zonov.ru:/data/obj/data/src/sys/Base11 amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 
6.0.1)
CPU: Intel(R) Celeron(R) CPU  J1900  @ 1.99GHz (2000.05-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x30678  Family=0x6  Model=0x37  Stepping=8
  
Features=0xbfebfbff
  
Features2=0x41d8e3bf
  AMD Features=0x28100800
  AMD Features2=0x101
  Structured Extended Features=0x2282
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 4294967296 (4096 MB)
avail memory = 3962818560 (3779 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
WARNING: L1 data cache covers less APIC IDs than a core
0 < 1
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
Security policy loaded: TrustedBSD MAC/portacl (mac_portacl)
Firmware Warning (ACPI): 32/64X length mismatch in FADT/Gpe0Block: 128/32 
(20171214/tbfadt-748)
WARNING: Bogus Interrupt Trigger Mode. Assume CONFORMS.
WARNING: Bogus Interrupt Polarity. Assume CONFORMS
ioapic0  irqs 0-86 on motherboard
SMP: AP CPU #3 Launched!
SMP: AP CPU #2 Launched!
SMP: AP CPU #1 Launched!
Timecounter "TSC" frequency 254736 Hz quality 1000
random: entropy device external interface
kbd0 at kbdmux0
netmap: loaded module
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
nexus0
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
unknown: I/O range not supported
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
atrtc0:  port 0x70-0x77 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "RTC" frequency 32768 Hz quality 0
hpet0:  iomem 0xfed0-0xfed003ff irq 8 on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 450
Event timer "HPET1" frequency 14318180 Hz quality 440
Event timer "HPET2" frequency 14318180 Hz quality 440
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pcib0: _OSC returned error 0x10
pci0:  on pcib0
vgapci0:  port 0xf080-0xf087 mem 
0xd000-0xd03f,0xc000-0xcfff irq 16 at device 2.0 on pci0
vgapci0: Boot video device
ahci0:  port 
0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 
0xd0a16000-0xd0a167ff irq 19 at device 19.0 on pci0
ahci0: AHCI v1.30 with 2 3Gbps ports, Port Multiplier not supported
ahcich0:  at channel 0 on ahci0
xhci0:  mem 0xd0a0-0xd0a0 irq 20 at 
device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
xhci0: Port routing mask set to 0x
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
pci0:  at device 26.0 (no driver attached)
hdac0:  mem 0xd0a1-0xd0a13fff irq 22 at 
device 27.0 on pci0
pcib1:  irq 16 at device 28.0 on pci0
pcib1: [GIANT-LOCKED]
pci1:  on pcib1
igb0:  port 
0xe000-0xe01f mem 0xd090-0xd091,0xd092-0xd0923fff irq 16 at device 
0.0 on pci1
igb0: Using MSIX interrupts with 3 vectors
igb0: Ethernet address: 40:62:31:02:18:41
igb0: Bound queue 0 to cpu 0
igb0: Bound queue 1 to cpu 1
igb0: netmap queues/slots: TX 2/4096, RX 2/4096
pcib2:  irq 17 at device 28.1 on pci0
pcib2: 

Re: Upgrading via source build, 10.4->11.2

[George Mitchell]

On 12/5/18 9:31 AM, Miroslav Lachman wrote:
> George Mitchell wrote on 2018/12/05 14:24:
>> [...]
>>  But what I really need to know is
>> whether to make buildworld under 10.4 or 11.2.  Or do I do it twice?
>> And presumably I can't run mergemaster until after buildworld.
> 
> I did upgrade from 10.4 to 11.2 on all our machines, just one builworld,
> buildkernel on shared build server (NFS exported /usr/obj + /usr/src),
> then installkernel, mergemaster -p, installworld, mergemaster, shutdown
> -r now.
> 
> Miroslav Lachman
> [...]

Thanks!  In the end, I did a buildworld under 10.4, reboot into 11.2,
mergemaster -p, installworld, mergemaster, reboot.  That all seemed to
work fine.  Today, out of caution, I'll do another buildworld,
buildkernel, installkernel, reboot, mergemaster -p, installworld,
mergemaster, reboot before I take the really big step: upgrading to a
Ryzen processor and from 8GB memory to 32GB.  Then I can worry about
ports.  I might get brave enough to try poudriere again, though so far
portmaster has done the job for me.

I use rsync to propagate /usr/src and /usr/obj to my other machines
so that I can installkernel and installworld on them in single user
mode (hard to use NFS when booting in single user).-- George



signature.asc
Description: OpenPGP digital signature

Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)

[Trond Endrestøl]

After booting stable/12 r341604, running a custom kernel including 
cxgbe(4), cxgbev(4), and ccr(4), and running swapon -a in SU mode:

GEOM_ELI: Device gpt/swap0.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI: Crypto: hardware


Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 06
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x805be1b2
stack pointer   = 0x28:0xfe00a6253770
frame pointer   = 0x28:0xfe00a6253770
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 = 65 (g_eli[3] gpt/swap0)
trap number = 12
panic: page fault
cpuid = 3
time = 1544087308
KDB: stack backtrace:
db_trace_self_wrapper() at 0x8055d9eb = 
db_trace_self_wrapper+0x2b/frame 0xfe00a6253420
vpanic() at 0x808754d3 = vpanic+0x1a3/frame 0xfe00a6253480
panic() at 0x80875323 = panic+0x43/frame 0xfe00a62534e0
trap_fatal() at 0x80bd745f = trap_fatal+0x35f/frame 0xfe00a6253530
trap_pfault() at 0x80bd74b9 = trap_pfault+0x49/frame 0xfe00a4b7f590
trap() at 0x80bd6ade = trap+0x29e/frame 0xfe00a4b7f6a0
calltrap() at 0x80bb3935 = calltrap+0x8/frame 0xfe00a4b7f6a0
--- trap 0xc, rip = 0x805be1b2, rsp = 0xfe00a4b7f770, rbp = 
0xfe00a4b7f770
t4_wrq_tx_locked() at 0x805be1b2 = t4_wrq_tx_locked+0x12/frame 
0xfe00a6253770
ccr_process() at 0x805e3fc3 = ccr_process+0x1953/frame 
0xfe00a4b7f970
crypto_dispatch() at 0x80ae3fa4 = crypto_dispatch+0x144/frame 
0xfe00a4b7f9b0
g_eli_crypto_run() at 0x807b5cb3 = g_eli_crypto_run+0x273/frame 
0xfe00a4b7fa10
g_eli_worker() at 0x807aebc8 = g_eli_worker+0x3c8/frame 
0xfe00a4b7fa70
fork_exit() at 0x80834d93 = fork_exit+0x83/frame 0xfe00a4b7fab0
fork_trampoline() at 0x80bb491e = fork_trampoline+0xe/frame 
0xfe00a4b7fab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 14s
Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot,

The Chelsio NIC is a T6225-CR.

Kernel config is 
https://ximalas.info/~trond/create-zfs/canmount/ENTERPRISE-amd64-stable-12

I tried stable/12 r341623 with ccr(4) removed from the kernel, and I 
had no problems engaging geli encrypted swap in SU mode nor in normal 
mode.

Has anyone else tried ccr(4) on recent stable/12?
Are we discouraged from using ccr(4)?
I was hoping to take advantage of the crypto accelerator.

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

FreeBSD-12 build question

[Slawa Olhovchenkov]

1. How I can build release media of FreeBSD-12 on FreeBSD-11 system?
Currenly process failed by 'Abort trap'.

585191  121 -rw---1 root wheel  
   8962048 Dec  5 18:58 ./ldconfig.core
585199  121 -rw---1 root wheel  
   8953856 Dec  5 18:58 
./usr/obj/usr/src/amd64.amd64/mktemp.core
585200  249 -rw---1 root wheel  
   9641984 Dec  5 18:58 ./usr/obj/usr/src/amd64.amd64/make.core

2. How I can update FreeBSD-11 (ZFS on Root) to FreeBSD-12 from source?
With new kernel ZFS not mounted, /bin/sh crashed.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"