stable/11 r321349 crashing immediately

[Don Lewis]

On 22 Jul, G. Paul Ziemba wrote:
> My previous table had an error in the cumulative size column
> (keyboard made "220" into "20" when I was plugging into the hex
> calculator), so thet stack is 0x200 bigger than I originally thought:
> 
> Frame   Stack Pointer           sz  cumu function
> -----   -------------           --- ---- ----------------
>  44     0xfffffe085cfa8a10               amd64_syscall
>  43     0xfffffe085cfa88b0      160  160 syscallenter
>  42     0xfffffe085cfa87f0      220  380 sys_execve
>  41     0xfffffe085cfa87c0       30  3B0 kern_execve
>  40     0xfffffe085cfa8090      730  AE0 do_execve
>  39     0xfffffe085cfa7ec0      1D0  CB0 namei
>  38     0xfffffe085cfa7d40      180  E30 lookup
>  37     0xfffffe085cfa7cf0       50  E80 VOP_LOOKUP
>  36     0xfffffe085cfa7c80       70  EF0 VOP_LOOKUP_APV
>  35     0xfffffe085cfa7650      630 1520 nfs_lookup
>  34     0xfffffe085cfa75f0       60 1580 VOP_ACCESS
>  33     0xfffffe085cfa7580       70 15F0 VOP_ACCESS_APV
>  32     0xfffffe085cfa7410      170 1760 nfs_access
>  31     0xfffffe085cfa7240      1D0 1930 nfs34_access_otw
>  30     0xfffffe085cfa7060      1E0 1B10 nfsrpc_accessrpc
>  29     0xfffffe085cfa6fb0       B0 1BC0 nfscl_request
>  28     0xfffffe085cfa6b20      490 2050 newnfs_request
>  27     0xfffffe085cfa6980      1A0 21F0 clnt_reconnect_call
>  26     0xfffffe085cfa6520      460 2650 clnt_vc_call
>  25     0xfffffe085cfa64c0       60 26B0 sosend
>  24     0xfffffe085cfa6280      240 28F0 sosend_generic
>  23     0xfffffe085cfa6110      170 2A60 tcp_usr_send
>  22     0xfffffe085cfa5ca0      470 2ED0 tcp_output
>  21     0xfffffe085cfa5900      3A0 3270 ip_output
>  20     0xfffffe085cfa5880       80 32F0 looutput
>  19     0xfffffe085cfa5800       80 3370 if_simloop
>  18     0xfffffe085cfa57d0       30 33A0 netisr_queue
>  17     0xfffffe085cfa5780       50 33F0 netisr_queue_src
>  16     0xfffffe085cfa56f0       90 3480 netisr_queue_internal
>  15     0xfffffe085cfa56a0       50 34D0 swi_sched
>  14     0xfffffe085cfa5620       80 3550 intr_event_schedule_thread
>  13     0xfffffe085cfa55b0       70 35C0 sched_add
>  12     0xfffffe085cfa5490      120 36E0 sched_pickcpu
>  11     0xfffffe085cfa5420       70 3750 sched_lowest
>  10     0xfffffe085cfa52a0      180 38D0 cpu_search_lowest
>   9     0xfffffe085cfa52a0        0 38D0 cpu_search
>   8     0xfffffe085cfa5120      180 3A50 cpu_search_lowest
>   7     0xfffffe085cfa5120        0 3A50 cpu_search
>   6     0xfffffe085cfa4fa0      180 3BD0 cpu_search_lowest
>   5     0xfffffe0839778f40      signal handler

The stack is aligned to a 4096 (0x1000) boundary.  The first access to a
local variable below 0xfffffe085cfa5000 is what triggered the trap.  The
other end of the stack must be at 0xfffffe085cfa9000 less a bit. I don't
know why the first stack pointer value in the trace is
0xfffffe085cfa8a10. That would seem to indicate that amd64_syscall is
using ~1500 bytes of stack space.