https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198463
--- Comment #8 from Sibananda Sahu ---
(In reply to sirdice from comment #7)
mrsas(4) is not supporting the mfiutil(8) yet.
You can use the LSI application for the same purpose i.e StorCli, which is
available on www.lsi.com
Below is the d
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198149
--- Comment #7 from ganb...@gmail.com ---
I tried to reproduce it with asterisk in same multicore machine and put some
load on asterisk:
last pid: 1296; load averages: 7.44, 5.22, 3.17
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198149
--- Comment #6 from Adrian Chadd ---
ok, try something multi-threaded and doing system calls. I just tried with
nginx and it's okay - it's all one thread per process.
--
You are receiving this mail because:
You are the assignee for the b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198723
--- Comment #4 from ganb...@gmail.com ---
Some more outputs:
root@bsd:/home/tsgan/himenobmtxpa/src # cpuset -l 1 pmcstat -w 1 -p
CPU_CLK_UNHALTED_CORE -p PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW -p
PARTIAL_RAT_STALLS.MUL_SINGLE_UOP ./himenobmtxpa
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199568
Bug ID: 199568
Summary: tcpdump -C ignored
Product: Base System
Version: 10.1-RELEASE
Hardware: i386
OS: Any
Status: New
Severity: Affects Many Peop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198723
--- Comment #3 from ganb...@gmail.com ---
Ok, my case is probably different, so I see different numbers, but not huge:
cpuset -l 0 pmcstat -w 1 -p CPU_CLK_UNHALTED_CORE -p
PARTIAL_RAT_STALLS.SLOW_LEA_WINDOW -p PARTIAL_RAT_STALLS.MUL_SINGLE_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198208
--- Comment #12 from Dan ---
It died many times in the ipf_frag_known function. I removed 'keep frags' from
my ipfilter rules and it has not crashed in 7 days, which is a record since
installing FreeBSD 10. I am going to let it run a few
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #4 from Ed Maste ---
See http://svnweb.freebsd.org/changeset/base/266609 for the fix for this issue
in the fork() case.
In any case calling the fork syscall directly is going to be error-prone, so it
would be useful to have a b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #3 from Ed Maste ---
userland backtraces:
(lldb) bt
* thread #1: tid = 103971, 0x000800f8e198 libc.so.7`__syscall + 8 at
__syscall.S:3
* frame #0: 0x000800f8e198 libc.so.7`__syscall + 8 at __syscall.S:3
frame #1:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #2 from Ed Maste ---
Pointed out by kib, when invoking the fork syscall directly the child inherits
potentially locked libc mutexes, and it's probably the printf that hangs, not
the sysconf.
What was the original underlying iss
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
--- Comment #1 from Ed Maste ---
Reproduced on FreeBSD 10.1-STABLE r280427+86df2de(stable-10) on the second try.
procstat shows:
PIDTID COMM TDNAME KSTACK
29430 101383 a.out-
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199559
Bug ID: 199559
Summary: [patch][regression] ggatel(8) broken on i386 after
r238119
Product: Base System
Version: 10.1-RELEASE
Hardware: i386
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198463
--- Comment #7 from sird...@gmail.com ---
The system has been running fine using the mrsas(4) driver from FreeBSD (10.1).
One thing I have noticed is that mfiutil(8) doesn't work any more. Is there an
alternative to use?
--
You are receivi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199557
Bug ID: 199557
Summary: Hang on sysconf(_SC_OPEN_MAX)
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects
Hello.
I found a strange behavior with ssd drives trim perfomance.
I have zfs mirror on 2 ssd drives (ashift=12, aligment 4k).
When i migrate sql server to that storage i found that ssd become always
busy and having io queue lenth ~60, some count of read and write, and 128
bio_delele (trim) operati
15 matches
Mail list logo
