[Bug 217159] ps default to 79 characters can break ps|grep in shell scripts

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217159

Bug ID: 217159
   Summary: ps default to 79 characters can break ps|grep in shell
scripts
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: n.dee...@gmail.com

Created attachment 180064
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180064=edit
Patch to set unlimited terminal size if we can't determine terminal
characteristics

FreeBSD ps defaults to output width of 79 characters if it cannot determine tty
width.  This can hurt scripts that use "ps | grep" and run, for example, ssh on
a non-interactive shell.

I've provided more context here:

http://deepix.github.io/2016/10/10/psww.html

I've also provided a patch as an attachment in unified diff format.

Note that this problem does not exist on Linux or OS X.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #5 from Franco Fichtner  ---
Thank you. A public call for testing will be out today based on your diff. :)


Cheers,
Franco

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

Mateusz Guzik  changed:

   What|Removed |Added

 CC||m...@freebsd.org

--- Comment #4 from Mateusz Guzik  ---
Please reproduce with:
https://people.freebsd.org/~mjg/patches/rwlock-debug.diff

the patch is against 11.0

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 217138] head (e.g.) -r313783 sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted"

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138

--- Comment #2 from Mark Millard  ---
If one is going to look into this in a amd64
context it is important to be using head -r313772
or later in order to avoid fork sometimes not
preserving the stack pointer on the child-process
side of things --at least if experimenting with
port or buildworld buildkernel builds as a means
of testing.

Getting past that stack pointer problem is what
allowed me to see this problem during build
activity, which started me down this exploration.

[My tests for aborting in sh`forkshell if fork changes
the stack pointer are still in place but there have
been no failures so far.]

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 217144] procstat -e fails to report changes to environment.

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217144

Konstantin Belousov  changed:

   What|Removed |Added

 CC||k...@freebsd.org
 Status|New |Closed
 Resolution|--- |Works As Intended

--- Comment #2 from Konstantin Belousov  ---
This is perfectly normal.  Kernel can reliably see the environment for a
process only during execve(2), when old program passes the environment to a new
executed program through the syscall.  New program (address space) gets the
envirnment as a set of strings on top of the main thread stack.  procstat -e
best guess is to access these strings and show them as good enough
approximation.

During the normal operations, the environment changes do not need to be
reflected into the strings and they are not, as you discovered.  Still procstat
-e is useful because typical program only consumes the environment without
changing it.  Shells of course do change env vars, but maintaining env as
externally visible strings set is not needed until something is execed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 217156] Kernel panic using Netmap with selected NIC queue

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217156

Bug ID: 217156
   Summary: Kernel panic using Netmap with selected NIC queue
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: milosz.kaniew...@gmail.com
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

Created attachment 180063
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=180063=edit
Test program which ends with kernel panic.

Hello,

when I try to use netmap with specified NIC queue (ie. when I use flag
NR_REG_ONE_NIC) I get kernel panic:

panic: Assertion slot != NULL failed at
/usr/src/sys/modules/cxgbe/if_cxgbe/../../../dev/cxgbe/t4_netmap.c:353
cpuid = 14
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0660f53000
vpanic() at vpanic+0x186/frame 0xfe0660f53080
kassert_panic() at kassert_panic+0x126/frame 0xfe0660f530f0
cxgbe_netmap_reg() at cxgbe_netmap_reg+0x8d8/frame 0xfe0660f531c0
netmap_hw_reg() at netmap_hw_reg+0x2c/frame 0xfe0660f531f0
netmap_do_regif() at netmap_do_regif+0x2cb/frame 0xfe0660f53230
netmap_ioctl() at netmap_ioctl+0xa57/frame 0xfe0660f53620
freebsd_netmap_ioctl() at freebsd_netmap_ioctl+0x3e/frame 0xfe0660f53650
devfs_ioctl() at devfs_ioctl+0xc3/frame 0xfe0660f536a0
VOP_IOCTL_APV() at VOP_IOCTL_APV+0xe0/frame 0xfe0660f536d0
vn_ioctl() at vn_ioctl+0x124/frame 0xfe0660f537d0
devfs_ioctl_f() at devfs_ioctl_f+0x1f/frame 0xfe0660f537f0
kern_ioctl() at kern_ioctl+0x2b0/frame 0xfe0660f53850
sys_ioctl() at sys_ioctl+0x13f/frame 0xfe0660f53930
amd64_syscall() at amd64_syscall+0x2f9/frame 0xfe0660f53ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0660f53ab0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80097c97a, rsp =
0x7fffea88, rbp = 0x7fffeb20 ---
KDB: enter: panic

If the queue is not specified then everything works ok.

To repeat this error:
1. Run 'pkt-gen -i vcxl0-1' or
2. Run program netmap_test.c.

uname -a:
FreeBSD test0 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r313561: Fri Feb 10 20:18:01
UTC 2017 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

network card:
Chelsio T540-CR

/boot/loader.conf content:
hw.cxgbe.num_vis=2

root@freebsd:~ # ifconfig vcxl0
vcxl0: flags=8843 metric 0 mtu 1500
  
options=ec07bb
ether 00:07:43:31:cf:52
nd6 options=29
media: Ethernet 10Gbase-SR 
status: active

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216868] sed extended regex case ignored

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216868

--- Comment #7 from Aldis Berjoza  ---
Created fresh FreeBSD 11.0-RELEASE-p7 instance on DigitalOcean.
Logged in.
Didn't modify anything.
Have the same issue.


ENV on that instance:

PAGER=more
LANG=en_US.UTF-8
MAIL=/var/mail/freebsd
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/home/freebsd/bin
EDITOR=vi
ENV=/usr/home/freebsd/.shrc
PWD=/usr/home/freebsd
TERM=xterm-256color
SSH_TTY=/dev/pts/0
HOME=/usr/home/freebsd
USER=freebsd
SSH_CONNECTION=**
SHELL=/bin/sh
BLOCKSIZE=K

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 216868] sed extended regex case ignored

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216868

--- Comment #6 from Aldis Berjoza  ---
After I upgraded my server to 11.0-RELEASE-p7 it has the same issue

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 217149] seq(1) inconsistently omits 'last' when using float increment

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217149

Bug ID: 217149
   Summary: seq(1) inconsistently omits 'last' when using float
increment
   Product: Base System
   Version: 11.0-STABLE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: mcdutc...@hotmail.com

With a 'first' parameter up to 1.6, seq(1) will not print the '2':

$ seq 1.6 .05 2
1.6
1.65
1.7
1.75
1.8
1.85
1.9
1.95

but, starting from 1.65, it will:

$ seq 1.65 .05 2
1.65
1.7
1.75
1.8
1.85
1.9
1.95
2

GNU 'seq' always prints the 2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 213903] Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213903

--- Comment #3 from Franco Fichtner  ---
We have over a dozen user reports on this collected in two weeks, some with
daily crashes.  Trying to bring in a developer now...

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 217144] procstat -e fails to report changes to environment.

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217144

--- Comment #1 from mrT  ---
I was using shell: ksh93 version sh (AT Research) 93u+ 2012-08-01
and also tested using '/bin/sh' and got the same results.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 217144] procstat -e fails to report changes to environment.

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217144

Bug ID: 217144
   Summary: procstat -e fails to report changes to environment.
   Product: Base System
   Version: 10.3-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: mrt1188...@gmail.com
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

procstat -e (PID) (for printing the environment variables of specified PID) 
fails to show updated environments.

This was noticed in the following scenario:
konsole-A  --- 
   procstat -e pidOf-konsole-B  > baseline.txt

konsole-B ---
   export MYTEST="ThisIsMy test string. mrT"

konsole-A ---
   procstat -e pidOf-konsole-B  > test1.txt

---> Both outputs was identical.
 Therefore, any environment changes are NOT reflected in 'procstat -e'
output.
 Got same result even when I ran the same 'procstat -e' on konsole-B.
 Note: other options of procstat, such as '-f' and '-r' (file descriptor,
resource usage)
   did sow updated info as expected.

konsole version 2.14.2
Using KDE Development Platform 4.14.10
kern.osrelease: 10.3-RELEASE-p5
kern.osrevision: 199506
kern.version: FreeBSD 10.3-RELEASE-p5 #0: Thu Jun 30 03:52:15 UTC 2016
r...@amd64-builder.pcbsd.org:/usr/obj/usr/src/sys/GENERIC

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Patchcord Production Line Solutions_Sun Telecom

2017-02-16 Thread Sun Telecom 

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

[Bug 217138] head (e.g.) -r313783 sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted"

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138

--- Comment #1 from Mark Millard  ---
(In reply to Mark Millard from comment #0)
It turns out that the sh failure during buildworld
also gets to __je_tsd_get (but a different way) and
then fails the same assertion for "tsd_booted":

: /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:687:
Failed assertion: "tsd_booted"

A back trace is:

(lldb) bt
* thread #1: tid = 100194, 0x40554e18 libc.so.7`_thr_kill + 8, name =
'sh', stop reason = signal SIGABRT
  * frame #0: 0x40554e18 libc.so.7`_thr_kill + 8
frame #1: 0x40554ddc libc.so.7`__raise(s=6) + 64 at raise.c:52
frame #2: 0x40554d50 libc.so.7`abort + 84 at abort.c:65
frame #3: 0x40528790 libc.so.7`__je_tsd_fetch [inlined]
__je_tsd_get + 248 at tsd.h:687
frame #4: 0x4052876c libc.so.7`__je_tsd_fetch [inlined]
__je_tsd_fetch_impl(init=true) at tsd.h:692
frame #5: 0x4052876c libc.so.7`__je_tsd_fetch + 212 at tsd.h:717
frame #6: 0x40550cc0 libc.so.7`__free(ptr=0x40a17720) + 64
at jemalloc_jemalloc.c:2011
frame #7: 0x00411328 sh`ckfree(p=) + 32 at
memalloc.c:88
frame #8: 0x00407cd8 sh`clearcmdentry + 76 at exec.c:505
frame #9: 0x00406bfc sh`evalcommand(cmd=,
flags=, backcmd=) + 3476 at eval.c:1182
frame #10: 0x00405570 sh`evaltree(n=0x40a1cde8,
flags=) + 212 at eval.c:290
frame #11: 0x0041105c sh`cmdloop(top=) + 252 at
main.c:231
frame #12: 0x00410ed0 sh`main(argc=,
argv=) + 660 at main.c:178
frame #13: 0x00402f30 sh`__start + 360
frame #14: 0x40434658 ld-elf.so.1`.rtld_start + 24 at
rtld_start.S:41

It appears that setvar was not used but clearcmdentry
(indirectly) gets the same sort of problem when this
happens:

(lldb) up 9
frame #9: 0x00406bfc sh`evalcommand(cmd=,
flags=, backcmd=) + 3476 at eval.c:1182
   1179 if (lastarg)
   1180 setvar("_", lastarg, 0);
   1181 if (do_clearcmdentry)
-> 1182 clearcmdentry();
   1183 }

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 217138] head (e.g.) -r313783 sh vs. jemalloc asserts: include/jemalloc/internal/tsd.h:687: Failed assertion: "tsd_booted"

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217138

Bug ID: 217138
   Summary: head (e.g.) -r313783 sh vs. jemalloc asserts:
include/jemalloc/internal/tsd.h:687: Failed assertion:
"tsd_booted"
   Product: Base System
   Version: CURRENT
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: mar...@dsl-only.net
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

For head -r313783 I built with a production arm64 kernel
but world without MALLOC_PRODUCTION . I intermittently
get the following sort of thing when, for example, I use
^z to put a process in the background and to get back
to the shell --or quitting a program and getting back to
the shell. The context involves already having been
su'd to root. I can not cause the crash on demand: it
is intermittent and fairly rare so far.

[Note: This was found while trying to track down why sh
fails sometimes during buildworld on a pine64 when
world was built with MALLOC_PRODUCTION.]

: /usr/src/contrib/jemalloc/include/jemalloc/internal/tsd.h:687:
Failed assertion: "tsd_booted"

(lldb) bt
* thread #1: tid = 100164, 0x40554e18 libc.so.7`_thr_kill + 8, name =
'sh', stop reason = signal SIGABRT
  * frame #0: 0x40554e18 libc.so.7`_thr_kill + 8
frame #1: 0x40554ddc libc.so.7`__raise(s=6) + 64 at raise.c:52
frame #2: 0x40554d50 libc.so.7`abort + 84 at abort.c:65
frame #3: 0x40528790 libc.so.7`__je_tsd_fetch [inlined]
__je_tsd_get + 248 at tsd.h:687
frame #4: 0x4052876c libc.so.7`__je_tsd_fetch [inlined]
__je_tsd_fetch_impl(init=true) at tsd.h:692
frame #5: 0x4052876c libc.so.7`__je_tsd_fetch + 212 at tsd.h:717
frame #6: 0x40550214 libc.so.7`ialloc_body(size=11,
zero=, tsdn=0xe650, usize=0xe648,
slow_path=true) + 56 at jemalloc_jemalloc.c:1586
frame #7: 0x40550184 libc.so.7`__malloc(size=1) + 184 at
jemalloc_jemalloc.c:1645
frame #8: 0x0041126c sh`ckmalloc(nbytes=) + 32 at
memalloc.c:61
frame #9: 0x0041bb6c sh`setvar(name=,
val=, flags=) + 176 at var.c:256
frame #10: 0x00406bf4 sh`evalcommand(cmd=,
flags=, backcmd=) + 3468 at eval.c:1180
frame #11: 0x00405570 sh`evaltree(n=0x40ab9060,
flags=) + 212 at eval.c:290
frame #12: 0x0041105c sh`cmdloop(top=) + 252 at
main.c:231
frame #13: 0x00410ed0 sh`main(argc=,
argv=) + 660 at main.c:178
frame #14: 0x00402f30 sh`__start + 360
frame #15: 0x40434658 ld-elf.so.1`.rtld_start + 24 at
rtld_start.S:41
(lldb) up 10
frame #10: 0x00406bf4 sh`evalcommand(cmd=,
flags=, backcmd=) + 3468 at eval.c:1180
   1177 
   1178 out:
   1179 if (lastarg)
-> 1180 setvar("_", lastarg, 0);
   1181 if (do_clearcmdentry)
   1182 clearcmdentry();
   1183 }

Unless tsd_booted has been trashed it would appear that
tsd_boot0() never happened before the attempted setvar
above indirectly tries the __je_tsd_get. Supporting
details from the source code:

/usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_defs.h
establishes:

#define JEMALLOC_MALLOC_THREAD_CLEANUP 
#define JEMALLOC_TLS 

which is context that is needed when looking things up.

/* malloc_tsd_externs(). */
#ifdef JEMALLOC_MALLOC_THREAD_CLEANUP
#define malloc_tsd_externs(a_name, a_type)  \
extern __thread a_type  a_name##tsd_tls;\
extern __thread boola_name##tsd_initialized;\
extern bool a_name##tsd_booted;
. . .
#ifdef JEMALLOC_MALLOC_THREAD_CLEANUP
#define malloc_tsd_data(a_attr, a_name, a_type, a_initializer)  \
. . .\
a_attr bool a_name##tsd_booted = false;
. . .

#ifdef JEMALLOC_MALLOC_THREAD_CLEANUP
#define malloc_tsd_funcs(a_attr, a_name, a_type, a_initializer, \
a_cleanup)  \
. . .
a_name##tsd_boot0(void) \
{   \
\
if (a_cleanup != malloc_tsd_no_cleanup) {   \
malloc_tsd_cleanup_register(\
_name##tsd_cleanup_wrapper);  \
}   \
a_name##tsd_booted = true;  \
return (false); \
}

[Bug 217128] Kernel panic on 11.0-Release when executing files over NFS(AutoFS) before it's automounted

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217128

Chang, Ching-hao  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

--- Comment #6 from Chang, Ching-hao  ---
Thanks guys, The r311284 patch worked like a charm.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 217128] Kernel panic on 11.0-Release when executing files over NFS(AutoFS) before it's automounted

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217128

--- Comment #5 from Chang, Ching-hao  ---
I'll try to apply the patch provided in r311284 and see if it work.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 217128] Kernel panic on 11.0-Release when executing files over NFS(AutoFS) before it's automounted

2017-02-16 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217128

--- Comment #4 from Chang, Ching-hao  ---
We use autofs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"