on 08/02/2013 01:41 Rick Macklem said the following:
> Sounds good. I've attached a slightly updated patch with Andriy's
> suggested addition of a check for zfsvfs->z_shares_dir != 0.
>
> I can't do any commits until April, so if one of you guys is comfortable
> enough with the patch to commit it,
Could you please review and/or test the following patch?
The idea is exactly the same as for cpu_stop() invocation in the shutdown path.
Please note that I've kept intr_disable() just because potentially mtx_lock_spin
could be implemented in such a way that it wouldn't block all interrupts via CP
On 7 February 2013 18:40, Kimmo Paasiala wrote:
>> Ports are largely independent of the base system, and their compilation
>> flags are different from port to port. You could set -fstack-protector
>> for your ports in either make.conf or ports.conf, if you wanted.
>
> Is there any work being done
SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169)
http://www.mail-archive.com/openssl-announce@openssl.org/msg00124.html
http://www.isg.rhul.ac.uk/tls/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fr
Hello,
do not run the game using sdl.
% uname -a
FreeBSD x220.local 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r246229: Sat
Feb 2 17:42:00 UTC 2013
andrey@x220.local:/usr/obj/usr/src/sys/W_BOOK amd64
# cat /etc/make.conf
WITH_NEW_XORG=true
WITH_KMS=true
X.Org X Server 1.10.6
Release Date: 2012-02-10
Sergey Kandaurov wrote:
> Sergey Kandaurov wrote:
> > On 7 February 2013 19:42, Andriy Gapon wrote:
> > > on 07/02/2013 17:36 Sergey Kandaurov said the following:
> > >> I tested the patch without the (*vpp != dvp) change.
> > >> It works well.
> > >>
> > >> It's something unrelated but when doing
Sergey Kandaurov wrote:
> On 7 February 2013 19:42, Andriy Gapon wrote:
> > on 07/02/2013 17:36 Sergey Kandaurov said the following:
> >> I tested the patch without the (*vpp != dvp) change.
> >> It works well.
> >>
> >> It's something unrelated but when doing ls -l
> >> on server (patched) and cl
On Thu, Feb 7, 2013 at 11:06 PM, Dimitry Andric wrote:
> On 2013-02-07 20:42, Kimmo Paasiala wrote:
>>
>> Does the -fstack-protector option work on CLANG 3.1 and 3.2?
>
>
> Yes, it works with both clang and gcc.
>
Good to know thank you!
>
>> There is thread on FreeBSD forums about the stack pro
Andriy Gapon wrote:
> on 07/02/2013 17:04 Rick Macklem said the following:
> > The other thing I wondered about is "can zfsvfs->z_shares_dir ever
> > not
> > fit in 32bits?".
>
> Usually it should be one of the first objects created in a new
> filesystem, so it
> should have a small ID (typically
Hi!
Thanks so much for your hard work to date. I'm so glad that FreeBSD's
802.11s support is growing in leaps and bounds.
Adrian
On 7 February 2013 13:45, Monthadar Al Jaberi wrote:
> Hi everyone!
>
> I am pleased to say that FreeBSD has gotten a little closer to getting
> a working IEEE802.1
Hi Kimmo,
On Thu, Feb 07, 2013 at 10:06:49PM +0100, Dimitry Andric wrote:
> On 2013-02-07 20:42, Kimmo Paasiala wrote:
> > Does the -fstack-protector option work on CLANG 3.1 and 3.2?
>
> Yes, it works with both clang and gcc.
>
>
> > There is thread on FreeBSD forums about the stack protector
Hi everyone!
I am pleased to say that FreeBSD has gotten a little closer to getting
a working IEEE802.11 Mesh.
A lot more is to be done.
Please try it out! You have to update to head revision 246520. Check
out the great wiki we have about Mesh :)
https://wiki.freebsd.org/WifiMesh
There is still
On Tue, Feb 05, 2013 at 03:46:43PM -0500, John Baldwin wrote:
> I've written an implementation of open_memstream() and
> open_wmemstream() along with a set of regression tests. I'm pretty
> sure open_memstream() is correct, and I believe open_wmemstream() is
> correct for expected usage. The latt
On 2013-02-07 20:42, Kimmo Paasiala wrote:
Does the -fstack-protector option work on CLANG 3.1 and 3.2?
Yes, it works with both clang and gcc.
There is thread on FreeBSD forums about the stack protector and ports
and I'm wondering if it's possible to use the -fstack-protector option
with CLA
You need to dig through the patch and the freebsd tree you're using
and try to figure out where that is defined and why it isn't being
found.
Luis' patch is against -HEAD from a couple years ago, and you're (I
think) trying to patch -9. There's likely some code drift since then..
Adrian
On 7
Hello,
Does the -fstack-protector option work on CLANG 3.1 and 3.2?
There is thread on FreeBSD forums about the stack protector and ports
and I'm wondering if it's possible to use the -fstack-protector option
with CLANG.
http://forums.freebsd.org/showthread.php?t=36927
-Kimmo
__
hi,
i yesterday i was tried to patch file on my freensd code, because it was my
custom code so i had to patch my code by update file to file, with my
calculation everything should go perfectly it didn`t, i am getting some
errors like
cc -c -O -pipe -march=mips32 -std=c99 -g -Wall -Wredundant-decl
On Thu, Feb 07, 2013 at 01:20:16PM -0500, John Baldwin wrote:
> On Thursday, February 07, 2013 1:14:41 pm Steve Kargl wrote:
> > What's the preferred method for compiling libc
> > and libthr with debugging enable?
>
> I just do:
>
> cd /path/to/src/lib/libc
> make clean
> make DEBUG_FLAGS=-g
>
>
On Thursday, February 07, 2013 1:14:41 pm Steve Kargl wrote:
> What's the preferred method for compiling libc
> and libthr with debugging enable?
I just do:
cd /path/to/src/lib/libc
make clean
make DEBUG_FLAGS=-g
Then when I run the binary I use a custom LD_LIBRARY_PATH that points at the
direc
What's the preferred method for compiling libc
and libthr with debugging enable?
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr..
On Thu, 2013-02-07 at 15:33:22 +0100, Fabian Keil wrote:
> Ulrich Spörlein wrote:
>
> > Yes, it's pretty much as weird as it sounds. All new machine, forklifted
> > the image from on old i386 machine running 8.x to current on amd64.
> >
> > Everything seemingly works fine, attaching geli volumes
On 7 February 2013 19:42, Andriy Gapon wrote:
> on 07/02/2013 17:36 Sergey Kandaurov said the following:
>> I tested the patch without the (*vpp != dvp) change.
>> It works well.
>>
>> It's something unrelated but when doing ls -l
>> on server (patched) and client (unpatched) sides,
>> I found som
on 07/02/2013 17:36 Sergey Kandaurov said the following:
> I tested the patch without the (*vpp != dvp) change.
> It works well.
>
> It's something unrelated but when doing ls -l
> on server (patched) and client (unpatched) sides,
> I found some inconsistency in returned stats.
> Or more precisely
On 7 February 2013 17:43, Andriy Gapon wrote:
> on 07/02/2013 04:13 Rick Macklem said the following:
>> Andriy Gapon wrote:
>>> on 06/02/2013 17:15 Rick Macklem said the following:
Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
knows to
switch over to using VOP_LOOK
on 07/02/2013 17:04 Rick Macklem said the following:
> The other thing I wondered about is "can zfsvfs->z_shares_dir ever not
> fit in 32bits?".
Usually it should be one of the first objects created in a new filesystem, so it
should have a small ID (typically 7).
> I notice it is a uint64_t, but
Andriy Gapon wrote:
> on 07/02/2013 04:13 Rick Macklem said the following:
> > Andriy Gapon wrote:
> >> on 06/02/2013 17:15 Rick Macklem said the following:
> >>> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
> >>> knows to
> >>> switch over to using VOP_LOOKUP(). If the .zfs/snap
Ulrich Spörlein wrote:
> Yes, it's pretty much as weird as it sounds. All new machine, forklifted
> the image from on old i386 machine running 8.x to current on amd64.
>
> Everything seemingly works fine, attaching geli volumes shortly after
> boot is fine, attached devices continue to work fine
Yes, it's pretty much as weird as it sounds. All new machine, forklifted
the image from on old i386 machine running 8.x to current on amd64.
Everything seemingly works fine, attaching geli volumes shortly after
boot is fine, attached devices continue to work fine. There are no
strange crashes with
on 07/02/2013 04:13 Rick Macklem said the following:
> Andriy Gapon wrote:
>> on 06/02/2013 17:15 Rick Macklem said the following:
>>> Well, zfs_vget() returns EOPNOTSUPP for .zfs, so the NFS server
>>> knows to
>>> switch over to using VOP_LOOKUP(). If the .zfs/snapshot and
>>> .zfs/share
>>> do t
29 matches
Mail list logo
