Re: r273918 buildworld broke at semaphore

2014-11-14 Thread Beeblebrox
I posted the solution to this through the Nabble page, but there's a 
change in setting there and the messages have not gone through. So, 
re-posting to mail list:


I disabled ccache, then buildworld / buildkernel completed.

I had in /etc/make.conf:
.if ${.CURDIR:M/usr/src} || ${.CURDIR:M/usr/src/*} || 
${.CURDIR:M/asp/git/src} || ${.CURDIR:M/asp/git/src/*}

THREADS=16
#CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/clang,1}
#CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/clang++,1}

The only reason I can think of is that somehow ccache was passing the 
older cached code to the buildworld process, and the reason for that 
wold be because certain clang components fail to identify themselves to 
ccache correctly.


Once I installed the newly built kernel/world and re-booted
* I deleted all under /usr/obj
* re-enabled ccache in make.conf
* re-ran # make buildworld  completed without problem.

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


Is libLLVM-3.4.so: part of src or not?

2014-11-14 Thread Beeblebrox

When starting Xorg, AIGLX gets disabled and RadeonKMS complains:

(EE) AIGLX error: dlopen of /usr/local/lib/dri/r600_dri.so failed 
(Shared object libLLVM-3.4.so n

ot found, required by r600_dri.so)
(EE) AIGLX: reverting to software rendering
(II) AIGLX: Screen 0 is not DRI capable
(EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed 
(Shared object libLLVM-3.4.so

 not found, required by swrast_dri.so)
(EE) GLX: could not load software renderer
(II) GLX: no usable GL providers found for screen 0

A search on the system shows libLLVM-3.4.so only exists under 
/usr/local/lib32.
I built and installed devel/llvm34, re-started Xorg and the log shows 
AIGLX as starting normally (no error).


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


Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)

2014-11-14 Thread Peter Pentchev
On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote:
 On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote:
  But please nuke the current list -- it is completely inadequate
  for the code-in candidates and misleading for whoever wants to
  suggest new tasks. Again i am not saying that the projects
  suggested there are not important, just belong somewhere else
  e.g. gsoc.
 
 I refrained from voicing my opinion while the call for help was going
 on, but I completely agree that the target age of this Google initiative
 is inadequate to FreeBSD.  The target population is 13 years to 17 years
 old and I cannot even imagine a 13 year old knowing what FreeBSD is.

...and yet there was pat@ becoming a ports committer at the age of 16
and chris@ becoming a docs committer at the age of 14 :)  I think hmp@,
alepulver@, issyl0@ and jmallett@ were pretty young when they joined,
too.

Just an observation, I know that one or two isolated cases do not prove
a point :)

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: Digital signature


Re: CFR: AES-GCM and OpenCrypto work review

2014-11-14 Thread Konstantin Belousov
On Fri, Nov 14, 2014 at 03:52:39AM +0300, Andrey V. Elsukov wrote:
 On 08.11.2014 07:23, John-Mark Gurney wrote:
  Hello,
  
  Over the last few months, I've been working on a project to add support
  for AES-GCM and AES-CTR modes to our OpenCrypto framework.  The work is
  sponsored by The FreeBSD Foundation and Netgate.
  
  I plan on committing these patches early next week.  If you need more
  time for review, please email me privately and I will make delay.
  
  The code has already been reviewed by Watson Ladd (the software crypto
  implementations) and Trevor Perrin (the aesni module part) and I have
  integrated these changes into the patch.
  
  There are two patches, one is the changes for OpenCrypto and the test
  framework.  The other is the data files used by the test framework.
  The data is from NIST's CAVP program, and is about 20MB worth of test
  vectors.  (I just realized, should we look at compressing these on
  disk?)
  
  Main patch (192KB):
  https://www.funkthat.com/~jmg/patches/aes.ipsec.5.patch
  
  Data files (~20MB):
  https://www.funkthat.com/~jmg/patches/aes.ipsec.5.testing.patch
  
  A list of notable changes in the patch:
  - Replacing crypto(4) w/ NetBSD's version + updates
  - Lots of man page updates, including CIOCFINDDEV and crypto(7) which
adds specifics about restrictions on the modes.
  - Allow sane useage of both _HARDWARE and _SOFTWARE flags.
  - Add a timing safe bcmp for MAC comparision.
  - Add a software implementation of GCM that uses a four bit lookup
table with parallelization.  This algorithm is possibly vulnerable to
timing attacks, but best known mitigation methods are used.  Using
a timing safe version is many times slower.
  - Added a CRYPTDEB macro that defaults to off.
  - Bring in some of OpenBSD's improvements to the OpenCrypto framework.
  - If an mbuf passed to the aesni module is only one segment, don't do
a copy.  This needs to be improved to support segmented buffers.
  - Remove the CRYPTO_F_REL flag.  It was meaningless.  It was used but
did not change any behavior.
  - Add function crypto_mbuftoiov to convert an mbuf to an iov.  This
also converts the software crypto to only use iov's even for a simple
linear buffer, and so simplifies the processing.
  - Add a dtrace probe for errors from the ioctl.
  - Add the CIOCCRYPTAEAD ioctl that allows userland processing (testing)
of AES-GCM and future AEAD modes.
  
  Future improvements:
  - Support IV's longer than 12 bytes for GCM.
  - Make AES-NI support segmented buffers (iov or mbuf) so multisegmented
inputs don't have to be copied.
  
  I know there are more fixes and future improvements, but can't think of
  them now.
 
 I tried your patch with my IPv4 forwarding test. When aesni module is
 loaded and aes-cbc is used I see growing of `invalid outbound packets`
 counter in `netstat -sp ipsec` output. And no packets are forwarded.
 Also while testing I got a panic in aesni_encrypt_cbc().
 
 atal trap 9: general protection fault while in kernel mode
 cpuid = 4; apic id = 04
 instruction pointer   = 0x20:0x80d05c43
 stack pointer = 0x28:0xfe3f7e70
 frame pointer = 0x28:0xfe3f7eb0
 code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags  = interrupt enabled, resume, IOPL = 0
 current process   = 12 (irq286: ix0:que 4)
 
 The backtrace:
 #0  doadump (textdump=276160512) at pcpu.h:219
 #1  0x80355525 in db_fncall (dummy1=value optimized out,
 dummy2=value optimized out, dummy3=value optimized out,
 dummy4=value optimized out)
 at /usr/src/sys/ddb/db_command.c:568
 #2  0x8035520d in db_command (cmd_table=0x0) at
 /usr/src/sys/ddb/db_command.c:440
 #3  0x80354f84 in db_command_loop () at
 /usr/src/sys/ddb/db_command.c:493
 #4  0x80357980 in db_trap (type=value optimized out, code=0)
 at /usr/src/sys/ddb/db_main.c:251
 #5  0x8095c641 in kdb_trap (type=9, code=0, tf=value optimized
 out) at /usr/src/sys/kern/subr_kdb.c:654
 #6  0x80d1edcc in trap_fatal (frame=0xfe3f7dc0,
 eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:861
 #7  0x80d1ea6e in trap (frame=value optimized out) at
 /usr/src/sys/amd64/amd64/trap.c:201
 #8  0x80d04092 in calltrap () at
 /usr/src/sys/amd64/amd64/exception.S:231
 #9  0x80d05c43 in fpudna () at /usr/src/sys/amd64/amd64/fpu.c:85
 #10 0x80d1e7ae in trap (frame=value optimized out) at
 /usr/src/sys/amd64/amd64/trap.c:432
 #11 0x80d04092 in calltrap () at
 /usr/src/sys/amd64/amd64/exception.S:231
 #12 0x8202f96e in aesni_encrypt_cbc (rounds=10,
 key_schedule=0xf8005603d400, len=3, from=0xf8013b0de65a E,
 to=0xf8013b0de65a E,
 iv=0xf8005603d6d0 ???#??8???:n???\r??\f?\v) at
 /usr/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:63
 #13 

Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)

2014-11-14 Thread Mehmet Erol Sanliturk
On Fri, Nov 14, 2014 at 3:38 AM, Mark Saad nones...@longcount.org wrote:



  On Nov 14, 2014, at 4:27 AM, Peter Pentchev r...@ringlet.net wrote:
 
  On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote:
  On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote:
  But please nuke the current list -- it is completely inadequate
  for the code-in candidates and misleading for whoever wants to
  suggest new tasks. Again i am not saying that the projects
  suggested there are not important, just belong somewhere else
  e.g. gsoc.
 

 I have a few ideas for younger and or less experienced google code in
 people

 1. Analyze the CD/USB  install process .
 Does the actual process match the guide and or general docs .

 2. Analyze / comment on the automated install process jumpstart . Does
 the guide and general docs match the actual process .

 3. Test the virtual machine images as vagrant box images , and create
 vagrant box images from the official vm images .

 4. Create a script for the installer bsd install to use glabel to label
 gparts slices as /dev/label/$NAME

 5. Test the ami images , again can the docs be improved are they accurate .

 The

 Now let me preface the docs tasks , by no means am I saying that the docs
 team has made lots of mistakes and their work needs to be rechecked . The
 tasks are small enough that most high school aged people could grasp the
 issue, with out any prior experience in BSD world . Rechecking the docs is
 always a good idea .

 They should allow the code in members to make some good contributions ;
 and maybe even some good improvements .

  I refrained from voicing my opinion while the call for help was going
  on, but I completely agree that the target age of this Google initiative
  is inadequate to FreeBSD.  The target population is 13 years to 17 years
  old and I cannot even imagine a 13 year old knowing what FreeBSD is.
 
  ...and yet there was pat@ becoming a ports committer at the age of 16
  and chris@ becoming a docs committer at the age of 14 :)  I think hmp@,
  alepulver@, issyl0@ and jmallett@ were pretty young when they joined,
  too.
 
  Just an observation, I know that one or two isolated cases do not prove
  a point :)
 
  G'luck,
  Peter
 
  --
  Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
  PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
  Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

 Mark saad | mark.s...@longcount.org




One important program class for the less experienced people ( as users and
programmers ) would be the following :


(1)


For the command line operating system programs , mostly it is necessary to
give parameters on command line .

For example :

$ ifconfig

displays the NIC information .

To apply some operations , it is necessary to give parameters :

$ ifconfig -... ...  ... ...

To give these parameters even by using man pages are very difficult even
for the experienced users .

Task :

By using for selected OS programs , write a routine to the following :

When a user enters only program name , display a form to get parameters for
execution ( this requires some changes to programs doing operations just by
giving its name by specifying a parameter for such cases ) in such a way
that get parameters in an order by supplying form parts with respect to
previously given parameter values , i.e. , do not present all of the items
, let the user some values , and smash the user that such parameters are
given incorrectly .

Manual pages may be used , but sometimes it is necessary to read the source
code of the program to isolate error cases and dependencies .


(2)

Some programs may use many parameters and every time giving them as command
line parameters or by filling forms may not be a very convenient way .

By using Expat libraries ( or any other suitable library ) , write a
routine for a selected command line program to enter parameters from an XML
file with the following structure :


$ program_name  @XML_parameters file_name


Such a result may be obtained by using scripts for executing the programs
with specific parameters , but using the above structure may be more
convenient usage and they may be used in testing also more easily because
some files may be output of other programs .


(3)

Many OS programs are given their outputs in an arbitrary text form .
For automated tests , or input to other programs , these outputs are very
difficult to use .

For selected OS programs , give all of the output in XML ( or any other
selected structured form ) .which
they can be processed by using Expat library .

To process these outputs , also write a routine by using Expat library to
load it into a tree .

Thank you very much .


Mehmet Erol Sanliturk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 

Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)

2014-11-14 Thread Rui Paulo
On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote:
 But please nuke the current list -- it is completely inadequate
 for the code-in candidates and misleading for whoever wants to
 suggest new tasks. Again i am not saying that the projects
 suggested there are not important, just belong somewhere else
 e.g. gsoc.

I refrained from voicing my opinion while the call for help was going on, but I 
completely agree that the target age of this Google initiative is inadequate to 
FreeBSD.  The target population is 13 years to 17 years old and I cannot even 
imagine a 13 year old knowing what FreeBSD is.

I'm not sure we should participate in Code In ever again and perhaps we should 
focus our efforts on Summer of Code only.

--
Rui Paulo



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


Re: comments on code-in tasks for FreeBSD (Re: FreeBSD + Google Code-In 2014 = we need ideas.)

2014-11-14 Thread Mark Saad


 On Nov 14, 2014, at 4:27 AM, Peter Pentchev r...@ringlet.net wrote:
 
 On Thu, Nov 13, 2014 at 07:55:16PM -0800, Rui Paulo wrote:
 On Nov 13, 2014, at 17:40, Luigi Rizzo ri...@iet.unipi.it wrote:
 But please nuke the current list -- it is completely inadequate
 for the code-in candidates and misleading for whoever wants to
 suggest new tasks. Again i am not saying that the projects
 suggested there are not important, just belong somewhere else
 e.g. gsoc.
 

I have a few ideas for younger and or less experienced google code in people

1. Analyze the CD/USB  install process . 
Does the actual process match the guide and or general docs . 

2. Analyze / comment on the automated install process jumpstart . Does the 
guide and general docs match the actual process .

3. Test the virtual machine images as vagrant box images , and create vagrant 
box images from the official vm images . 

4. Create a script for the installer bsd install to use glabel to label 
gparts slices as /dev/label/$NAME 

5. Test the ami images , again can the docs be improved are they accurate .

The 

Now let me preface the docs tasks , by no means am I saying that the docs team 
has made lots of mistakes and their work needs to be rechecked . The tasks are 
small enough that most high school aged people could grasp the issue, with out 
any prior experience in BSD world . Rechecking the docs is always a good idea . 

They should allow the code in members to make some good contributions ; and 
maybe even some good improvements . 

 I refrained from voicing my opinion while the call for help was going
 on, but I completely agree that the target age of this Google initiative
 is inadequate to FreeBSD.  The target population is 13 years to 17 years
 old and I cannot even imagine a 13 year old knowing what FreeBSD is.
 
 ...and yet there was pat@ becoming a ports committer at the age of 16
 and chris@ becoming a docs committer at the age of 14 :)  I think hmp@,
 alepulver@, issyl0@ and jmallett@ were pretty young when they joined,
 too.
 
 Just an observation, I know that one or two isolated cases do not prove
 a point :)
 
 G'luck,
 Peter
 
 -- 
 Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
 PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Mark saad | mark.s...@longcount.org 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: CFR: AES-GCM and OpenCrypto work review

2014-11-14 Thread Andrey V. Elsukov
On 14.11.2014 03:52, Andrey V. Elsukov wrote:
 I tried your patch with my IPv4 forwarding test. When aesni module is
 loaded and aes-cbc is used I see growing of `invalid outbound packets`
 counter in `netstat -sp ipsec` output. And no packets are forwarded.
 Also while testing I got a panic in aesni_encrypt_cbc().
 
 atal trap 9: general protection fault while in kernel mode
 cpuid = 4; apic id = 04
 instruction pointer   = 0x20:0x80d05c43
 stack pointer = 0x28:0xfe3f7e70
 frame pointer = 0x28:0xfe3f7eb0
 code segment  = base 0x0, limit 0xf, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags  = interrupt enabled, resume, IOPL = 0
 current process   = 12 (irq286: ix0:que 4)
 

The full backtrace is here: http://paste.org.ru/?a3f8pw
Screenshot from ddb: http://i.imgur.com/H5mbVi8.png?1
Also I noticed that on higher packet rate sometimes kernel reports about
wrong source route attempts:

kernel: attempted source route from 244.116.138.102 to 225.51.107.139
kernel: attempted source route from 19.120.181.94 to 238.17.74.139
kernel: attempted source route from 186.217.142.184 to 233.165.4.102
kernel: attempted source route from 134.41.78.248 to 231.122.242.144

probably there is mbuf's memory corruption somewhere.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature


Re: Is libLLVM-3.4.so: part of src or not?

2014-11-14 Thread Brooks Davis
On Fri, Nov 14, 2014 at 10:16:10AM +0200, Beeblebrox wrote:
 When starting Xorg, AIGLX gets disabled and RadeonKMS complains:
 
 (EE) AIGLX error: dlopen of /usr/local/lib/dri/r600_dri.so failed 
 (Shared object libLLVM-3.4.so n
 ot found, required by r600_dri.so)
 (EE) AIGLX: reverting to software rendering
 (II) AIGLX: Screen 0 is not DRI capable
 (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed 
 (Shared object libLLVM-3.4.so
   not found, required by swrast_dri.so)
 (EE) GLX: could not load software renderer
 (II) GLX: no usable GL providers found for screen 0
 
 A search on the system shows libLLVM-3.4.so only exists under 
 /usr/local/lib32.
 I built and installed devel/llvm34, re-started Xorg and the log shows 
 AIGLX as starting normally (no error).

libLLVM doesn't provide a stable interface and is thus not a public part
of base.  It sounds like there's a missing port depend.

-- Brooks


pgpY0B34Wzjfz.pgp
Description: PGP signature


Re: geli: Wrong key with a simple passphrase. Doesn't handle the keyboard input

2014-11-14 Thread Aurelien Martin
Hi all,

Is there people that can try to geli an external USB disk with a simple
passphrase on CURRENT and tell me if the passphrase prompt shown the input,
and if it's possible to attach it ?

Cheers,Aurelien


# uname -a
FreeBSD  11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53
UTC 2014 r...@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-
B  arm

#kldstat
 21 0xc2e49000 17000geom_eli.ko
 31 0xc2e6 2a000crypto.ko


# sysctl kern.geom.eli.visible_passphrase=1
kern.geom.eli.visible_passphrase: 0 - 1

 Nothing print in the prompt 

# geli init da0
Enter new passphrase:
Reenter new passphrase:

 Impossible to attach the device with a simple passphrase. Tried 20x

geli attach da0
Enter passphrase:
geli: Wrong key for da0




2014-11-08 21:26 GMT+01:00 Aurelien Martin 01aurel...@gmail.com:

 Dear all,

 I tried to geli my external USB drive da0 with a simple passphrase
 But I'm getting Wrong key for da0 when I want to attach it.
 geli seems not to handle my keyboard input when I type my password.

 Let me know if I have forgot a step.

 Cheers,Aurelien

 Log
 --

 # uname -a
 FreeBSD  11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53
 UTC 2014 r...@grind.freebsd.org:/usr/
 obj/arm.armv6/usr/src/sys/RPI-B  arm

 # sysctl kern.geom.eli.visible_passphrase=1
 kern.geom.eli.visible_passphrase: 0 - 1


 What I have done :
 The prompt doesn't handle my keyboard input, nothing printed

 # geli init da0
 Enter new passphrase:
 Reenter new passphrase:
 Metadata backup can be found in /var/backups/da0.eli and
 ...

 # geli attach da0
 Enter passphrase:
 geli: Wrong key for da0.


 # cat /var/backups/da0.eli | hexdump -c | head -1
 000   G   E   O   M   :   :   E   L   I  \0  \0  \0  \0  \0  \0  \0

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


Re: geli: Wrong key with a simple passphrase. Doesn't handle the keyboard input

2014-11-14 Thread Fabian Keil
Aurelien Martin 01aurel...@gmail.com wrote:

 Is there people that can try to geli an external USB disk with a simple
 passphrase on CURRENT and tell me if the passphrase prompt shown the input,
 and if it's possible to attach it ?
 
 # uname -a
 FreeBSD  11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19 01:18:53
 UTC 2014 r...@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-
 B  arm
 
 #kldstat
  21 0xc2e49000 17000geom_eli.ko
  31 0xc2e6 2a000crypto.ko
 
 
 # sysctl kern.geom.eli.visible_passphrase=1
 kern.geom.eli.visible_passphrase: 0 - 1
 
  Nothing print in the prompt 
 
 # geli init da0
 Enter new passphrase:
 Reenter new passphrase:

The sysctl only applies to the kernel, geli(8) doesn't use it.

  Impossible to attach the device with a simple passphrase. Tried 20x
 
 geli attach da0
 Enter passphrase:
 geli: Wrong key for da0

geli attach works for me on 11-CURRENT amd64, maybe it's an arm issue.

Fabian


pgpdEp6VcT5Qo.pgp
Description: OpenPGP digital signature


Re: geli: Wrong key with a simple passphrase. Doesn't handle the keyboard input

2014-11-14 Thread Aurelien Martin
Many thanks Fabian for your feedbacks !

@freebsd-arm users: Can someone try to geli init and geli attach an USB
external drive ?

Cheers,Aurelien




2014-11-14 18:23 GMT+01:00 Fabian Keil freebsd-lis...@fabiankeil.de:

 Aurelien Martin 01aurel...@gmail.com wrote:

  Is there people that can try to geli an external USB disk with a simple
  passphrase on CURRENT and tell me if the passphrase prompt shown the
 input,
  and if it's possible to attach it ?
  
  # uname -a
  FreeBSD  11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271779: Fri Sep 19
 01:18:53
  UTC 2014 r...@grind.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-
  B  arm
 
  #kldstat
   21 0xc2e49000 17000geom_eli.ko
   31 0xc2e6 2a000crypto.ko
 
 
  # sysctl kern.geom.eli.visible_passphrase=1
  kern.geom.eli.visible_passphrase: 0 - 1
 
   Nothing print in the prompt 
 
  # geli init da0
  Enter new passphrase:
  Reenter new passphrase:

 The sysctl only applies to the kernel, geli(8) doesn't use it.

   Impossible to attach the device with a simple passphrase. Tried 20x
  
  geli attach da0
  Enter passphrase:
  geli: Wrong key for da0

 geli attach works for me on 11-CURRENT amd64, maybe it's an arm issue.

 Fabian

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


Re: CFR: AES-GCM and OpenCrypto work review

2014-11-14 Thread John-Mark Gurney
John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 -0800:
 Well.. It looks like IPSEC is still broken in head...  I can get
 pings to pass, but now on IPv4 transport mode, I can't get syn's to
 be sent out...  I see the output packet in the protocol stats, but
 no packets go out the interface...
 
 If you could provide me w/ a simple set of spdadd commands, or the
 dumps from the machine, that'd be good...
 
 Hmm  I just ran ping -f so I could generate some traffic, and
 managed to get a:
 panic: System call sendto returing with kernel FPU ctx leaked
 
 I'll look into this...

I just verified that this happens on a clean HEAD @ r274534:
FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014
j...@carbon.funkthat.com:/scratch/jmg/clean/sys/amd64/compile/IPSEC amd64

No modifications, nothing, and I got the same panic:
panic: System call sendto returing with kernel FPU ctx leaked
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe001de7a800
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe001de7a8b0
vpanic() at vpanic+0x189/frame 0xfe001de7a930
kassert_panic() at kassert_panic+0x139/frame 0xfe001de7a9a0
amd64_syscall() at amd64_syscall+0x616/frame 0xfe001de7aab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe001de7aab0
--- syscall (64, FreeBSD ELF64, nosys), rip = 0x8011975aa, rsp = 
0x7ffee588, rbp = 0x7ffee5c0 ---
KDB: enter: panic

So, it's clearly not my patch that is causing the issue...

Andrey, can you verify that you do not receive the same panic w/o my
patches?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org