Re: Some NFS server V4 questions

2014-10-26 Thread Beeblebrox
Sorry guys, we have a considerable time-zone difference.

 It appears that the sysctl must be set before mountd, nfsd are
 started to take effect. (Or they must be restarted after it is set.)
I had apparently re-started nfsd but not mountd. This time re-starting both and 
launching the PXE client fails at mount_root stage as expected:
exec /sbin/init: error 43
exec /rescue/init: error 43
panic: no init

One cannot set sysctl vfs.nfsd.server_min_nfsvers=4 until one of mountd/nfsd 
is started however, otherwise it gives an error. I have not tried, but I 
suppose this error does not happen when placeed in /etc/sysctl.conf?
sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or directory

 Maybe it was the talk about getting rid of the oldnfs stuff that
 made you think V2, 3 were going away?
Yes, that was it and I obviously misunderstood that thread.

What's the max NFS version that supports mount_root from PXE clients then? As I 
recall, this would be V3. However, root is consistently being mounted as V2.
The fstab for diskless clients:
192.168.2.1:/data/amd64 /   nfs ro,nfsv30  0
192.168.2.1:/usr/local /usr/local nfs   ro,nfsv40  0
192.168.2.1:/home   /home   nfs rw,nfsv4,hard,intr  0  0

nfsstat shows / as NFSV2, while the other two are NFSV4. Changing fstab entry 
to nfsv4 for root gives same result.
I tried set sysctl vfs.nfsd.server_min_nfsvers=3 and I get the same 
mount_root error as when this was set to 4. Im I missing something? It does not 
seem that vfs.nfsd.server_min_nfsvers will be of much use to me, unless I can 
get  V2 to mount as root.

Regards.




-
FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
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: Some NFS server V4 questions

2014-10-26 Thread Daniel Braniss

 On Oct 26, 2014, at 10:48 AM, Beeblebrox zap...@berentweb.com wrote:
 
 Sorry guys, we have a considerable time-zone difference.
 
 It appears that the sysctl must be set before mountd, nfsd are
 started to take effect. (Or they must be restarted after it is set.)
 I had apparently re-started nfsd but not mountd. This time re-starting both 
 and launching the PXE client fails at mount_root stage as expected:
 exec /sbin/init: error 43
 exec /rescue/init: error 43
 panic: no init
 
 One cannot set sysctl vfs.nfsd.server_min_nfsvers=4 until one of 
 mountd/nfsd is started however, otherwise it gives an error. I have not 
 tried, but I suppose this error does not happen when placeed in 
 /etc/sysctl.conf?
 sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or directory
 
 Maybe it was the talk about getting rid of the oldnfs stuff that
 made you think V2, 3 were going away?
 Yes, that was it and I obviously misunderstood that thread.
 
 What's the max NFS version that supports mount_root from PXE clients then? As 
 I recall, this would be V3. However, root is consistently being mounted as V2.

to get pxeboot to do v3, add:
boot-nfsroot-options=“nfsv3”
to /boot/loader.conf

 The fstab for diskless clients:
 192.168.2.1:/data/amd64 /   nfs ro,nfsv30  0
 192.168.2.1:/usr/local /usr/local nfs   ro,nfsv40  0
 192.168.2.1:/home   /home   nfs rw,nfsv4,hard,intr  0  0
 
 nfsstat shows / as NFSV2, while the other two are NFSV4. Changing fstab 
 entry to nfsv4 for root gives same result.
 I tried set sysctl vfs.nfsd.server_min_nfsvers=3 and I get the same 
 mount_root error as when this was set to 4. Im I missing something? It does 
 not seem that vfs.nfsd.server_min_nfsvers will be of much use to me, unless 
 I can get  V2 to mount as root.
 
 Regards.
 
 
 
 
 -
 FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
 --
 View this message in context: 
 http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html
 Sent from the freebsd-current mailing list archive at Nabble.com.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

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

Re: Panic after USB deadlock followed by kldunload umass.ko

2014-10-26 Thread Fabian Keil
Hans Petter Selasky h...@selasky.org wrote:

 On 10/23/14 16:28, Fabian Keil wrote:

  kldunload umass.ko lead to a panic, dumping didn't work.
 
  Screenshots are available at:
  http://www.fabiankeil.de/bilder/freebsd/kernel-panic-r273434-usb/
 
  I've seen locked-up usbconfig processes in the past,
  usually after executing a shell function that does:
 
  | usbconfig_output=$(sudo usbconfig -d ${device} add_quirk 
  UQ_MSC_NO_INQUIRY)
  | [... error handling snipped ]
  | usbconfig_output=$(sudo usbconfig -d ${device} reset)
 
  Sometimes the second command seems to mess up the USB system.

 USB detach is synchronous. If for example umass fails to detach, due to 
 reference counts not reaching zero, that might be the root cause. Try to 
 get a backtrace from the usb_process() processes using kgdb, and 
 you'll see right away what is going on.

Thanks for the quick response. So far I haven't been able to intentionally
reproduce the issue, but I'll try the above the next time I unintentionally
run into this again.

Fabian


signature.asc
Description: PGP signature


Re: Some NFS server V4 questions

2014-10-26 Thread Rick Macklem
Beeblebrox wrote:
 Sorry guys, we have a considerable time-zone difference.
 
  It appears that the sysctl must be set before mountd, nfsd are
  started to take effect. (Or they must be restarted after it is
  set.)
 I had apparently re-started nfsd but not mountd. This time
 re-starting both and launching the PXE client fails at mount_root
 stage as expected:
 exec /sbin/init: error 43
 exec /rescue/init: error 43
 panic: no init
 
 One cannot set sysctl vfs.nfsd.server_min_nfsvers=4 until one of
 mountd/nfsd is started however, otherwise it gives an error. I have
 not tried, but I suppose this error does not happen when placeed in
 /etc/sysctl.conf?
 sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or
 directory
 
It works if it is /etc/sysctl.conf if options NFSD are specified
for the kernel, which is what GENERIC for i386 has.

If options NFSD isn't in your kernel config, I think you'd have to
get nfsd.ko loaded before setting the sysctl and do both before
starting mountd.

I don't know of a clean way to do this?

Putting kldload and sysctl command lines in mountd_precmd() in
/etc/rc.d/mountd would do it I suspect. Maybe rc variables for
this should be added? (I haven't tried this since the only
kernels I have handy have options NFSD in them.)

rick

  Maybe it was the talk about getting rid of the oldnfs stuff that
  made you think V2, 3 were going away?
 Yes, that was it and I obviously misunderstood that thread.
 
 What's the max NFS version that supports mount_root from PXE clients
 then? As I recall, this would be V3. However, root is consistently
 being mounted as V2.
 The fstab for diskless clients:
 192.168.2.1:/data/amd64 /   nfs ro,nfsv30  0
 192.168.2.1:/usr/local /usr/local nfs   ro,nfsv40  0
 192.168.2.1:/home   /home   nfs rw,nfsv4,hard,intr  0  0
 
 nfsstat shows / as NFSV2, while the other two are NFSV4. Changing
 fstab entry to nfsv4 for root gives same result.
 I tried set sysctl vfs.nfsd.server_min_nfsvers=3 and I get the same
 mount_root error as when this was set to 4. Im I missing something?
 It does not seem that vfs.nfsd.server_min_nfsvers will be of much
 use to me, unless I can get  V2 to mount as root.
 
 Regards.
 
 
 
 
 -
 FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
 --
 View this message in context:
 http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html
 Sent from the freebsd-current mailing list archive at Nabble.com.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Some NFS server V4 questions

2014-10-26 Thread Rick Macklem
Beeblebrox wrote:
 Sorry guys, we have a considerable time-zone difference.
 
  It appears that the sysctl must be set before mountd, nfsd are
  started to take effect. (Or they must be restarted after it is
  set.)
 I had apparently re-started nfsd but not mountd. This time
 re-starting both and launching the PXE client fails at mount_root
 stage as expected:
 exec /sbin/init: error 43
 exec /rescue/init: error 43
 panic: no init
 
 One cannot set sysctl vfs.nfsd.server_min_nfsvers=4 until one of
 mountd/nfsd is started however, otherwise it gives an error. I have
 not tried, but I suppose this error does not happen when placeed in
 /etc/sysctl.conf?
 sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or
 directory
 
  Maybe it was the talk about getting rid of the oldnfs stuff that
  made you think V2, 3 were going away?
 Yes, that was it and I obviously misunderstood that thread.
 
 What's the max NFS version that supports mount_root from PXE clients
 then? As I recall, this would be V3. However, root is consistently
 being mounted as V2.
 The fstab for diskless clients:
 192.168.2.1:/data/amd64 /   nfs ro,nfsv30  0
 192.168.2.1:/usr/local /usr/local nfs   ro,nfsv40  0
 192.168.2.1:/home   /home   nfs rw,nfsv4,hard,intr  0  0
Just fyi, hard is the default and intr is an alternative to hard,
so I'm not sure what you get when specifying both? You should choose
one or the other. (You will get hard for the first 2 entries.)

rick

 
 nfsstat shows / as NFSV2, while the other two are NFSV4. Changing
 fstab entry to nfsv4 for root gives same result.
 I tried set sysctl vfs.nfsd.server_min_nfsvers=3 and I get the same
 mount_root error as when this was set to 4. Im I missing something?
 It does not seem that vfs.nfsd.server_min_nfsvers will be of much
 use to me, unless I can get  V2 to mount as root.
 
 Regards.
 
 
 
 
 -
 FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
 --
 View this message in context:
 http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html
 Sent from the freebsd-current mailing list archive at Nabble.com.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Some NFS server V4 questions

2014-10-26 Thread Konstantin Belousov
On Sun, Oct 26, 2014 at 08:14:05AM -0400, Rick Macklem wrote:
 Beeblebrox wrote:
  Sorry guys, we have a considerable time-zone difference.
  
   It appears that the sysctl must be set before mountd, nfsd are
   started to take effect. (Or they must be restarted after it is
   set.)
  I had apparently re-started nfsd but not mountd. This time
  re-starting both and launching the PXE client fails at mount_root
  stage as expected:
  exec /sbin/init: error 43
  exec /rescue/init: error 43
  panic: no init
  
  One cannot set sysctl vfs.nfsd.server_min_nfsvers=4 until one of
  mountd/nfsd is started however, otherwise it gives an error. I have
  not tried, but I suppose this error does not happen when placeed in
  /etc/sysctl.conf?
  sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or
  directory
  
 It works if it is /etc/sysctl.conf if options NFSD are specified
 for the kernel, which is what GENERIC for i386 has.
 
 If options NFSD isn't in your kernel config, I think you'd have to
 get nfsd.ko loaded before setting the sysctl and do both before
 starting mountd.
 
 I don't know of a clean way to do this?
 
 Putting kldload and sysctl command lines in mountd_precmd() in
 /etc/rc.d/mountd would do it I suspect. Maybe rc variables for
 this should be added? (I haven't tried this since the only
 kernels I have handy have options NFSD in them.)

With the following patch, the same variables should work when
set from the loader.conf (i.e. pre-boot) or using kenv(8).

diff --git a/sys/fs/nfsserver/nfs_nfsdkrpc.c b/sys/fs/nfsserver/nfs_nfsdkrpc.c
index d2145cc..4fb9c93 100644
--- a/sys/fs/nfsserver/nfs_nfsdkrpc.c
+++ b/sys/fs/nfsserver/nfs_nfsdkrpc.c
@@ -85,16 +85,16 @@ SYSCTL_DECL(_vfs_nfsd);
 SVCPOOL*nfsrvd_pool;
 
 static int nfs_privport = 0;
-SYSCTL_INT(_vfs_nfsd, OID_AUTO, nfs_privport, CTLFLAG_RW,
+SYSCTL_INT(_vfs_nfsd, OID_AUTO, nfs_privport, CTLFLAG_RWTUN,
 nfs_privport, 0,
 Only allow clients using a privileged port for NFSv2 and 3);
 
 static int nfs_minvers = NFS_VER2;
-SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_min_nfsvers, CTLFLAG_RW,
+SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_min_nfsvers, CTLFLAG_RWTUN,
 nfs_minvers, 0, The lowest version of NFS handled by the server);
 
 static int nfs_maxvers = NFS_VER4;
-SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_max_nfsvers, CTLFLAG_RW,
+SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_max_nfsvers, CTLFLAG_RWTUN,
 nfs_maxvers, 0, The highest version of NFS handled by the server);
 
 static int nfs_proc(struct nfsrv_descript *, u_int32_t, SVCXPRT *xprt,
___
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: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?

2014-10-26 Thread Tomoaki AOKI
On Mon, 20 Oct 2014 18:21:58 -0400
Allan Jude allanj...@freebsd.org wrote:

 On 2014-10-20 17:15, Chris H wrote:
  On Mon, 20 Oct 2014 14:32:53 -0400 Mason Loring Bliss ma...@blisses.org 
  wrote
  
  On Sat, Oct 18, 2014 at 02:58:57PM +0900, Tomoaki AOKI wrote:
 
  I think the advantages of the forum are...
 
*Well moderated by moderators and anministrators.
*Registering email address is needed, but not disclosed by default.
 
  The disadvantages of web fora include:
 
  * I can't read things in my very efficient email client. Related:
  * I have to compose my replies in a web browser edit window.
  * I need to visit periodically and hope that the site makes it possible for
me to attend to unread messages without struggling.
 
  I think wikis are useful. I think web fora exist because folks haven't had
  sufficient exposure to email to make the advantages clear. Not discussed 
  here
  are newsgroups, which are perhaps ideal for the sorts of topics commonly
  found on mailing lists, except perhaps that they're not at all centralized.
  
  This thread reeks of bikeshed.
  There isn't anything wrong with all of the opinions shared in this thread
  except there will surely be no final consensus. :)
  
  --Chris
 
  -- 
  Mason Loring Bliss   ((  In the drowsy dark cave of the mind dreams
  ma...@blisses.org ))  build  their nest  with fragments  dropped
  http://blisses.org/  ((   from day's caravan. - Rabindranath Tagore
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
  
  
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
  
 
 This thread is supposed to be about how to make it easier for people to
 migrate to FreeBSD from Linux. Not a discussion about forums vs mailing
 lists vs newsgroups.
 
 -- 
 Allan Jude
 

I guess.  So I won't post further discussion about Forum vs ML vs ...
in this thread. (Will pop in again if another thread purely for that is
created. But as Chris noted later, there would be no final consensus.)

Sorry for noise and long delay.

-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp
___
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: buildkernel fails on head

2014-10-26 Thread Dimitry Andric
On 25 Oct 2014, at 23:39, Maxim V FIlimonov c...@bein.link wrote:
 
 I'm trying to build the current FreeBSD kernel, and that's what I get:
 
 % sudo make buildkernel
 
 --
 Kernel build for GENERIC started on Sun Oct 26 01:39:13 MSK 2014
 --
 === GENERIC
 mkdir -p /usr/obj/usr/src/head/sys
 
 --
 stage 1: configuring the kernel
 --
 cd /usr/src/head/sys/amd64/conf;  
 PATH=/usr/obj/usr/src/head/tmp/legacy/usr/sbin:/usr/obj/usr/src/head/tmp/legacy/usr/bin:/usr/obj/usr/src/head/tmp/legacy/usr/games:/usr/obj/usr/src/head/tmp/legacy/bin:/usr/obj/usr/src/head/tmp/usr/sbin:/usr/obj/usr/src/head/tmp/usr/bin:/usr/obj/usr/src/head/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin
   
 config  -d /usr/obj/usr/src/head/sys/GENERIC  -I 
 '/usr/src/head/sys/amd64/conf' 
 '/usr/src/head/sys/amd64/conf/GENERIC'
 config: illegal option -- I
 usage: config [-CgmpV] [-d destdir] sysname
   config -x kernel
 *** Error code 64
 
 Stop.
 make[1]: stopped in /usr/src/head
 *** Error code 1
 
 Stop.
 make: stopped in /usr/src/head
 
 
 is there a workaround for that? Is the kernel build broken?

Your config executable is too old.  Most likely, you need to run make
kernel-toolchain first.

-Dimitry

___
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: junior kernel tasks

2014-10-26 Thread Anastasios Mag
Nice info...

On Sat, Oct 25, 2014 at 11:45 PM, Mateusz Guzik mjgu...@gmail.com wrote:

 Hello,

 In short, nice kernel tasks people with C language skills can do in few
 evenings.

 https://wiki.freebsd.org/JuniorJobs

 It is assumed you know how to obtain sources and build the kernel.

 What you can get in return:
 - your own code in FreeBSD tree
 - eternal glory [1]
 - fun [2]

 If you are not interested, but know someone who does, please pass it
 down.

 [1] - not really, no
 [2] - well, I guess that's subjective, so that's not a no

 Cheers,
 --
 Mateusz Guzik mjguzik gmail.com
 ___
 freebsd-hack...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org




-- 
Mageirias Anastasios
www.junkbytes.com
___
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: junior kernel tasks

2014-10-26 Thread Craig Rodrigues
On Sat, Oct 25, 2014 at 1:45 PM, Mateusz Guzik mjgu...@gmail.com wrote:

 Hello,

 In short, nice kernel tasks people with C language skills can do in few
 evenings.

 https://wiki.freebsd.org/JuniorJobs


Thanks for making that list.  I was looking at some other projects,
and noticed that on the front page of http://www.dragonflybsd.org/ ,
they have a Now Hiring section with multiple links to
Code Bounties, Summer of Code, etc., to help attract new people to the
project.

We need something like that on the front page of freebsd.org, to
help attract new blood to the project.  We have all the info,
but it is just scattered across many different web pages,
and is often outdated and not maintained.

--
Craig
___
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: buildkernel fails on head

2014-10-26 Thread Maxim V FIlimonov
On Sunday 26 October 2014 14:18:47 Dimitry Andric wrote:
 
 Your config executable is too old.  Most likely, you need to run make
 kernel-toolchain first.
 

Thank you very much, that helped.
-- 
wbr, Maxim Filimonov
c...@bein.link
___
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: Some NFS server V4 questions

2014-10-26 Thread Beeblebrox
Dan:
 to get pxeboot to do v3, add to /boot/loader.conf
 boot-nfsroot-options=“nfsv3”
Thanks. I'm using grub for the bootloader and menu, and comparable entry should 
be:
set kfreebsd.boot.nfsroot.options=nfsv3
It does not work however. mount_root hangs for a while then reverts to V2. I've 
asked about this on the grub-devel list, and will share the answer here.

Rick:
Would it be worth trying to pass a nolockd option for this? As you had stated 
in another thread,
For NFSv3 mounts, I'd suggest the nolockd option, unless you have multiple 
clients concurrently doing byte range locking on the same file. (With nolockd 
option on the mounts, you shouldn't need to run rpc.lockd, rpc.statd and that 
implies NFSLOCKD shouldn't be needed, too.)
Should I try this? If yes, how is it done?

 Just fyi, hard is the default and intr is an alternative to hard, so 
 I'm not sure what you get when specifying both? You should choose one or the 
 other. (You will get hard for the first 2 entries.)
Thanks. Corrected by removing both.

Konstantin:
Have not gotten around to trying the code yet and thanks.




-
FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959686.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
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: Some NFS server V4 questions

2014-10-26 Thread Rick Macklem
Beeblebrox wrote:
 Dan:
  to get pxeboot to do v3, add to /boot/loader.conf
  boot-nfsroot-options=“nfsv3”
 Thanks. I'm using grub for the bootloader and menu, and comparable
 entry should be:
 set kfreebsd.boot.nfsroot.options=nfsv3
 It does not work however. mount_root hangs for a while then reverts
 to V2. I've asked about this on the grub-devel list, and will share
 the answer here.
 
 Rick:
 Would it be worth trying to pass a nolockd option for this? As you
 had stated in another thread,
 For NFSv3 mounts, I'd suggest the nolockd option, unless you have
 multiple clients concurrently doing byte range locking on the same
 file. (With nolockd option on the mounts, you shouldn't need to
 run rpc.lockd, rpc.statd and that implies NFSLOCKD shouldn't be
 needed, too.)
 Should I try this? If yes, how is it done?
 
Well, I thought that the root fs was remounted (mount -u) using the
options specified in /etc/fstab for the root fs. As far as I know, putting
the nolockd option there should work.

rick

  Just fyi, hard is the default and intr is an alternative to
  hard, so I'm not sure what you get when specifying both? You
  should choose one or the other. (You will get hard for the
  first 2 entries.)
 Thanks. Corrected by removing both.
 
 Konstantin:
 Have not gotten around to trying the code yet and thanks.
 
 
 
 
 -
 FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
 --
 View this message in context:
 http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959686.html
 Sent from the freebsd-current mailing list archive at Nabble.com.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Some NFS server V4 questions

2014-10-26 Thread Rick Macklem
Beeblebrox wrote:
Dan:
 to get pxeboot to do v3, add to /boot/loader.conf
 boot-nfsroot-options=nfsv3
Thanks. I'm using grub for the bootloader and menu, and comparable entry 
should be:
set kfreebsd.boot.nfsroot.options=3Dnfsv3
It does not work however. mount_root hangs for a while then reverts to V2.
I've asked about this on the grub-devel list, and will share the answer here.
 
I'm not sure. I vaguely recall that pxeboot (which is a stripped down version of
boot) uses NFS to read /boot/loader.conf.

I'd try putting it in /boot/loader.conf on the root fs on the server, even if it
is using grub later.

This all assumes that your kernel is built with options NFS_ROOT. If it built
with options BOOTP etc, then it is an entirely different story.

Good luck with it, rick
ps: At some point, capturing the packets and looking at them in wireshark should
tell you what it is doing and when.
[stuff snipped for brevity]
 Regards.
 
 
 
 
 -
 FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
 --
 View this message in context:
 http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html
 Sent from the freebsd-current mailing list archive at Nabble.com.
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to
 freebsd-current-unsubscr...@freebsd.org
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: HEADS UP: Merging projects/bhyve_svm to HEAD

2014-10-26 Thread Zaphod Beeblebrox
I would be using such a patch as soon as it was available.  On a friend's
advice, I upgraded a ZFS server here at home with an AMD 9590 and 32Gig of
RAM.  I'd dearly like to use it to track down the netgraph bug (see my
other recent posts), but it doesn't currently qualify.

On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu neeln...@gmail.com wrote:

 Hi,

 On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox zbee...@gmail.com
 wrote:
  I tried to integrate this patch into 10.1_RC3 and I failed.  Is there a
  timeframe to MFC this to 10.1 or 10-STABLE?
 

 It will be MFCed to 10-STABLE but I don't have a specific time frame in
 mind.

 I'll guess that it'll be towards the end of November but can be
 accelerated if someone has a need for this in 10-STABLE sooner.

 best
 Neel

  On Sun, Oct 19, 2014 at 4:04 PM, Benjamin Perrault 
 ben.perra...@gmail.com
  wrote:
 
  After a few days of extensive testing and abuse, i’ve run into no new
  issues or unknowns what so ever. Everything that worked before still
 works
  now ( and a few bugs from fixed from HEAD ).
 
  Thus, I have gone ahead and pushed r273182 w/ Neel’s patch out to about
 80
  of the assorted AMD boxes in the production and dev pods that I care
 for. If
  end users see something, I’ll let you know, but I have a feeling they
 won’t.
 
  Again - Excellent work.
 
  cheers,
  -bp
 
   On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen w...@digiware.nl
   wrote:
  
   On 16-10-2014 5:00, Anish Gupta wrote:
   Hi all,
  
   The projects/bhyve_svm branch is ready to be merged to HEAD.
  
   This branch contains patches to bhyve to enable it to work on AMD
   processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD
   processor since 2010 will have the features required by bhyve.
  
   bhyve on AMD supports (almost) all the features available with Intel
   [2]. All guest OSes supported on Intel are supported on AMD. All the
   bhyve-related utilities function similarly on both Intel and AMD
   platforms [3].
  
   The patch against HEAD revision 273066 is available for review and
   testing:
   https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web
   directory]
  
   [1]: http://en.wikipedia.org/wiki/X86_virtualization
   [2]: bhyve doesn't support PCI passthru on AMD at this time
   [3]: bhyvectl has grown some processor-specific options
  
   Fetched the patch and compiled.
   Now running: HEAD r273066M and I was able to throw at it all the tests
   and images that in the past works. And perhaps even better.
  
   Great work.
   --WjW
  
  
   ___
   freebsd-virtualizat...@freebsd.org mailing list
   http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
   To unsubscribe, send any mail to
   freebsd-virtualization-unsubscr...@freebsd.org
 
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to 
 freebsd-current-unsubscr...@freebsd.org
 
 

___
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: Some NFS server V4 questions

2014-10-26 Thread Rick Macklem
Kostik wrote:
 On Sun, Oct 26, 2014 at 08:14:05AM -0400, Rick Macklem wrote:
  Beeblebrox wrote:
   Sorry guys, we have a considerable time-zone difference.
   
It appears that the sysctl must be set before mountd, nfsd are
started to take effect. (Or they must be restarted after it is
set.)
   I had apparently re-started nfsd but not mountd. This time
   re-starting both and launching the PXE client fails at mount_root
   stage as expected:
   exec /sbin/init: error 43
   exec /rescue/init: error 43
   panic: no init
   
   One cannot set sysctl vfs.nfsd.server_min_nfsvers=4 until one
   of
   mountd/nfsd is started however, otherwise it gives an error. I
   have
   not tried, but I suppose this error does not happen when placeed
   in
   /etc/sysctl.conf?
   sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file
   or
   directory
   
  It works if it is /etc/sysctl.conf if options NFSD are specified
  for the kernel, which is what GENERIC for i386 has.
  
  If options NFSD isn't in your kernel config, I think you'd have
  to
  get nfsd.ko loaded before setting the sysctl and do both before
  starting mountd.
  
  I don't know of a clean way to do this?
  
  Putting kldload and sysctl command lines in mountd_precmd() in
  /etc/rc.d/mountd would do it I suspect. Maybe rc variables for
  this should be added? (I haven't tried this since the only
  kernels I have handy have options NFSD in them.)
 
 With the following patch, the same variables should work when
 set from the loader.conf (i.e. pre-boot) or using kenv(8).
 
 diff --git a/sys/fs/nfsserver/nfs_nfsdkrpc.c
 b/sys/fs/nfsserver/nfs_nfsdkrpc.c
 index d2145cc..4fb9c93 100644
 --- a/sys/fs/nfsserver/nfs_nfsdkrpc.c
 +++ b/sys/fs/nfsserver/nfs_nfsdkrpc.c
 @@ -85,16 +85,16 @@ SYSCTL_DECL(_vfs_nfsd);
  SVCPOOL  *nfsrvd_pool;
  
  static int   nfs_privport = 0;
 -SYSCTL_INT(_vfs_nfsd, OID_AUTO, nfs_privport, CTLFLAG_RW,
 +SYSCTL_INT(_vfs_nfsd, OID_AUTO, nfs_privport, CTLFLAG_RWTUN,
  nfs_privport, 0,
  Only allow clients using a privileged port for NFSv2 and 3);
  
  static int   nfs_minvers = NFS_VER2;
 -SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_min_nfsvers, CTLFLAG_RW,
 +SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_min_nfsvers, CTLFLAG_RWTUN,
  nfs_minvers, 0, The lowest version of NFS handled by the
  server);
  
  static int   nfs_maxvers = NFS_VER4;
 -SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_max_nfsvers, CTLFLAG_RW,
 +SYSCTL_INT(_vfs_nfsd, OID_AUTO, server_max_nfsvers, CTLFLAG_RWTUN,
  nfs_maxvers, 0, The highest version of NFS handled by the
  server);
  
  static int nfs_proc(struct nfsrv_descript *, u_int32_t, SVCXPRT
  *xprt,

Worked fine for me. Do you mind if I commit this or would you rather
do it.

Thanks, rick

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


Re: zfs recv hangs in kmem arena

2014-10-26 Thread James R. Van Artsdalen
I was able to complete a ZFS replication by manually intervening each
time zfs recv blocked on kmem arena: running the program at the end
was sufficient to unblock zfs each of the 17 times it stalled.

The program is intended to consume about 24GB RAM out of 32GB physical
RAM, thereby pressuring the ARC and kernel cache to shrink: when the
program exits it would leave plenty of free RAM for zfs or whatever
else.  What actually happened is that every time, zfs unblocked as the
program below was growing: it was never necessary to wait for the
program to exit and free memory before zfs unblocked.

On 10/16/2014 6:25 AM, James R. Van Artsdalen wrote:
 The zfs recv / kmem arena hang happens with -CURRENT as well as
 10-STABLE, on two different systems, with 16GB or 32GB of RAM, from
 memstick or normal multi-user environments,

 Hangs usually seem to hapeen 1TB to 3TB in, but last night one run hung
 after only 4.35MB.

 On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote:
 FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2 #2 r272070M:
 Wed Sep 24 17:36:56 CDT 2014
 ja...@blackie.housenet.jrv:/usr/obj/usr/src/sys/GENERIC  amd64

 With current STABLE10 I am unable to replicate a ZFS pool using zfs
 send/recv without zfs hanging in state kmem arena, within the first
 4TB or so (of a 23TB Pool).

 The most recent attempt used this command line

 SUPERTEX:/root# zfs send -R BIGTEX/UNIX@syssnap | ssh BLACKIE zfs recv
 -duvF BIGTOX

 though local replications fail in kmem arena too.

 The two machines I've been attempting this on have 16BG and 32GB of RAM
 each and are otherwise idle.

 Any suggestions on how to get around, or investigate, kmem arena?

 # top
 last pid:  3272;  load averages:  0.22,  0.22,  0.23  up
 0+08:25:02  01:32:07
 34 processes:  1 running, 33 sleeping
 CPU:  0.0% user,  0.0% nice,  0.1% system,  0.0% interrupt, 99.9% idle
 Mem: 21M Active, 82M Inact, 15G Wired, 28M Cache, 450M Free
 ARC: 12G Total, 24M MFU, 12G MRU, 23M Anon, 216M Header, 47M Other
 Swap: 16G Total, 16G Free

   PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU
 COMMAND
  1173 root  1  520 86476K  7780K select  0 124:33   0.00% sshd
  1176 root  1  460 87276K 47732K kmem a  3  48:36   0.00% zfs
   968 root 32  200 12344K  1888K rpcsvc  0   0:13   0.00% nfsd
  1009 root  1  200 25452K  2864K select  3   0:01   0.00% ntpd
 ...

#include stdlib.h
#include string.h

long long s = ( (long long) 1  32) - 65;

main()
{
  char *p;

  p = calloc (s, 1);
  memset (p, 1, s);
  p = calloc (s, 1);
  memset (p, 1, s);
  p = calloc (s, 1);
  memset (p, 1, s);
  p = calloc (s, 1);
  memset (p, 1, s);
  p = calloc (s, 1);
  memset (p, 1, s);
  p = calloc (s, 1);
  memset (p, 1, s);
}

___
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: Ver 2 of the patch [was: Re: i915 driver update testing]

2014-10-26 Thread Chagin Dmitry
On Thu, Oct 23, 2014 at 10:03:29PM +0300, Konstantin Belousov wrote:
 On Wed, Oct 22, 2014 at 03:59:23PM -0400, Adam McDougall wrote:
  On 10/22/2014 08:26, Konstantin Belousov wrote:
 
 Use https://www.kib.kiev.ua/kib/drm/i915.6.patch.  I already have one
 private report of the patch worked from person who got the same panic
 in iicbb.

Hi, Kostik!

i915.6.patch  i7-4700. 


FreeBSD dchagin.static.corbina.net 11.0-CURRENT FreeBSD 11.0-CURRENT #93 
r273708+3ca71ce(lemul)-dirty: Sun Oct 26 23:38:47 MSK 2014 
r...@dchagin.static.corbina.net:/home/rootobj/home/dchagin/head/sys/YOY  amd64

Unread portion of the kernel message buffer:
FDI TX state assertion failure (expected off, current on)
error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on 
Haswell pipe  0
error: [drm:pid840:assert_fdi_rx] *ERROR* Attempting to enable FDI_RX on 
Haswell pipe  0
drmn1: taking over the fictitious range 0xe000-0xf000
info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off
info: [drm] GMBUS [gmbus dpb] timed out, falling back to bit banging on pin 5
panic: _sx_xlock_hard: recursed on non-recursive sx gmbus @ 
/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370

cpuid = 2
Uptime: 27s
Dumping 582 out of 11954 MB:..3%..11%..22%..31%..42%..53%..61%..72%..83%..91%

Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done.
Loaded symbols for /boot/kernel/acpi_ibm.ko.symbols
Reading symbols from /boot/kernel/i915kms.ko.symbols...done.
Loaded symbols for /boot/kernel/i915kms.ko.symbols
Reading symbols from /boot/kernel/drm2.ko.symbols...done.
Loaded symbols for /boot/kernel/drm2.ko.symbols
#0  doadump (textdump=1) at /home/dchagin/head/sys/kern/kern_shutdown.c:261
261 dumptid = curthread-td_tid;
(kgdb) #0  doadump (textdump=1) at 
/home/dchagin/head/sys/kern/kern_shutdown.c:261
#1  0x80691a75 in kern_reboot (howto=260)
at /home/dchagin/head/sys/kern/kern_shutdown.c:447
#2  0x80692670 in vpanic (
fmt=0x80c763b9 _sx_xlock_hard: recursed on non-recursive sx %s @ 
%s:%d\n, ap=0xfe033c750d60)
at /home/dchagin/head/sys/kern/kern_shutdown.c:746
#3  0x8069204c in kassert_panic (
fmt=0x80c763b9 _sx_xlock_hard: recursed on non-recursive sx %s @ 
%s:%d\n) at /home/dchagin/head/sys/kern/kern_shutdown.c:634
#4  0x806a09b0 in _sx_xlock_hard (sx=0xfe00039480e8, 
tid=18446735277793944768, opts=0, 
file=0x8166d4e7 
/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c,
 line=370)
at /home/dchagin/head/sys/kern/kern_sx.c:519
#5  0x8069f9ed in __sx_xlock (sx=0xfe00039480e8, 
td=0xf8000a9324c0, opts=0, 
file=0x8166d4e7 
/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c,
 line=370) at sx.h:154
#6  0x8069f893 in _sx_xlock (sx=0xfe00039480e8, opts=0, 
file=0x8166d4e7 
/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c,
 line=370)
at /home/dchagin/head/sys/kern/kern_sx.c:311
#7  0x816464e6 in intel_gmbus_transfer (idev=0xf80080a99900, 
msgs=0xfe033c7511e0, nmsgs=2)
at 
/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_iic.c:370
#8  0x81646ac7 in intel_gmbus_transfer (idev=value optimized out, 
msgs=value optimized out, nmsgs=value optimized out)
at iicbus_if.h:131
#9  0x8044a445 in IICBUS_TRANSFER (dev=0xf80080a99900, 
msgs=0xfe033c7511e0, nmsgs=2) at iicbus_if.h:131
#10 0x8044a39b in iicbus_transfer (bus=0xf80080a99800, 
msgs=0xfe033c7511e0, nmsgs=2)
at /home/dchagin/head/sys/dev/iicbus/iiconf.c:355
#11 0x8169309d in drm_do_probe_ddc_edid (adapter=0xf80080a99800, 
buf=0xfe033c751257 y, block=value optimized out, len=1)
at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:290
#12 0x816909bc in drm_get_edid (connector=0xf80080826c00, 
adapter=0xf80080a99800)
at /home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_edid.c:388
#13 0x81645690 in intel_hdmi_detect (connector=0xf80080826c00, 
force=value optimized out)
at 
/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_hdmi.c:465
#14 0x8168adf5 in drm_helper_probe_single_connector_modes (
connector=0xf80080826c00, maxX=8192, maxY=8192)
at 
/home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_crtc_helper.c:135
#15 0x8169387f in drm_fb_helper_initial_config (
fb_helper=0xf8008093b200, bpp_sel=32)
at 
/home/dchagin/head/sys/modules/drm2/drm2/../../../dev/drm2/drm_fb_helper.c:1164
#16 0x81643e41 in intel_fbdev_init (dev=value optimized out)
at 
/home/dchagin/head/sys/modules/drm2/i915kms/../../../dev/drm2/i915/intel_fb.c:245
#17 0x81617082 in i915_driver_load (dev=0xf80009807800, flags=0)
at