Coverity found an issue in this area which I tracked down to the incorrect
definition patched below.
The SID_QUAL macro is (((inq_data)->device & 0xE0) >> 5) which extracts the
peripheral qualifier.
Per SCSI-2 (draft 10L) table 46, the vendor-specific values are "1XXb".
This probably affects al
> I certainly could be wrong - but how to know for sure the cause of the panic?
> MCA: CPU 0 UNCOR PCC OVER DCACHE L2 DRD error
> MCA: Address 0xbd8d4cc0
> MCA: Misc 0x30e386
The "root cause" may be hard to determine, but the immediate cause was
helpfully decoded by the kernel. (Though I don
>We've switched to FreeBSD recently to accomodate large video storage as we are
>running video streaming website.
>So the job of the FreeBSD is to transcode the uploaded videos using ffmpeg and
>serve them to users via nginx webserver
>but so far our experience is not very good with it. It crashe
>Say all objects are connected peer to peer with wifi, some of them are
>connected to internet through gsm network or wifi to a box.
>These object are moving in space, and for some reasons, connections are
>dynamical and can be severely impaired or lost.
>
>They have incoming local streams of dat
The HWPMC hooks are never invoked except when using the soft PMC feature for
performance monitoring. This trivial patch hints as much to the compiler, which
then moves some fairly lengthy code sequences out of the locking primitives (in
particular), reducing their runtime footprint.
This patch
Thanks for this.
The cpu_search problem you reference came up here at Isilon as well. Here's a
patch which should get clang to do the "right thing" (inlining 3 specialized
copies of cpu_search); I haven't checked to make sure it doesn't hurt gcc,
though.
Anton
Index: sched_ule.c
DOT => DOD
444F54 => 444F44
That's a single-bit flip. Bad memory, perhaps?
Anton
-Original Message-
From: owner-freebsd-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of O. Hartmann
Sent: Tuesday, July 01, 2014 8:08 AM
To: Dimitry Andric
Cc: Adrian Chadd; Fre
> If you want interoperability just use /usr/bin/env bash as a shebang.
That doesn't work for this use case -- the user shell coming from LDAP -- but I
agree that the port shouldn't be modifying /usr/bin.
It's easy enough to add the symlink manually after installing the port if
you're in this s
