Still trying to get nfsserver module working correctly

[Paul Goyette <paul%whooppee.com@localhost>]

Ever since my upgrade from 6.99.23 6.99.24, I've had issues with the 
nfsserver module.  (See [1] and [2] and PR kern/48027).  The issue in 
[2] was resolved by Christos, but the initial problem remains.

I'm still digging in, and today I tried to get more details on what was 
sending the SIGSYS error.

The kernel being used has noth the nfs and nfsserver modules "built-in" 
so there is no need for autoload and auto-unload.

I'm pretty sure that mountd is successfully started, since there are 
numerous successful calls to nfssvc with flags SETEXPORTSLIST set, two 
calls for each entry in /etc/exports

However, when nfsd starts to run, it gets as far calling tryconf() for 
tcp6 and udp6 (src/usr.sbin/nfsd/nfsd.c line 369).  The next step should 
be to create the worker threads.  But it appears that this fails, and 
the kernel signals ENOSYS.  Here's the final part dmesg, including the 
entry to sys_nosys() breakpoint:

....
sys_nfssvc: Enter, lwp 0xfffffe882899b5c0
sys_nfssvc: SETEXPORTSLIST flag set
sys_nfssvc: Exit 9, lwp 0xfffffe882899b5c0, error 0
sys_nfssvc: Enter, lwp 0xfffffe882899b5c0
sys_nfssvc: SETEXPORTSLIST flag set
sys_nfssvc: Exit 9, lwp 0xfffffe882899b5c0, error 0
fatal breakpoint trapfatal breakpoint trap in supervisor mode
 in supervisor mode
trap type 1 code 0 rip ffffffff8020e621 cs 8 rflags 282 cr2 7f7ff67fcd88 ilevel 0
 rsp fffffe813b896bc8
trap type 1 code 0 rip ffffffff8020e621 cs 8 rflags 282 cr2 7f7ff63fbc88 ilevel 0
 rsp fffffe813b899bc8
sys_nfssvc: Enter, lwp 0xfffffe87f4792600
curlwp 0xfffffe87f47921e0 pid 339.4 lowest kstack 0xfffffe813b894000

A backtrace doesn't seem to be very helpful here; it indicates that the 
syscall being handled was syscall 0

crash> bt
_KERNEL_OPT_NVLAN() at 0
_KERNEL_OPT_NVLAN() at 0
db_fncall() at db_fncall
db_command() at db_command+0xf2
db_command_loop() at db_command_loop+0xd8
db_trap() at db_trap+0xe9
kdb_trap() at kdb_trap+0x10d
trap() at trap+0x353
--- trap (number 1) ---
sys_sa_enable() at sys_sa_enable+0x1
syscall() at syscall+0x9a
--- syscall (number 0) ---
7f7ff709d59a:


It is rather curious, however, that sys_sa_enable() is listed in the 
backtrace.  I thought that "sa" (scheduler activations) had been 
removed?  If so, then why would a simple/normal userland call to 
pthread_create()?

And, if this is "normal", why does this not trigger an attempt to 
auto-load the compat module, in order to enable the sa_enable syscall?



[1] http://mail-index.netbsd.org/current-users/2013/07/07/msg023001.html
[2] http://mail-index.netbsd.org/current-users/2013/09/14/msg023299.html

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------