On Mon, Aug 30, 2010 at 11:46:20PM +, Thordur I Bjornsson wrote:
Hi Thib!
> > I have two machines with vr(4) interfaces running 4.7, and I can't seem
> > to find any problem running ping -f against them.
> > vr0 at pci0 dev 12 function 0 "VIA VT6105 RhineIII" rev 0x86: apic 2 int
> > 19 (irq
> How can you tell whether this option is turned on by default
> or not? xorg.conf(5) indicates that the default is platform
> dependent and that this option in general should only be used
> as a work-around to a bug until fixed.
The X documentation is full of lies.
On Mon, Aug 30, 2010 at 11:31:25PM +0200, Mark Kettenis wrote:
> The Xorg xserver runs a scary amount of code in a signal handler.
> It's supposed to make your mouse cursor move more smoothly, but I
> can't spot the difference when I disable that "feature". Instead,
> this "feature" breaks certain
My vr on my firewall hangs for a while until the watchdog kicks it in
the pants every time I push a little traffic through it. I'd love to
see thibs thing go in.
On Mon, Aug 30, 2010 at 11:46:20PM +, Thordur I Bjornsson wrote:
> On Mon, Aug 30, 2010 at 06:46:53PM -0400, Brynet wrote:
> > Even
Mark Kettenis wrote:
The Xorg xserver runs a scary amount of code in a signal handler.
It's supposed to make your mouse cursor move more smoothly, but I
can't spot the difference when I disable that "feature". Instead,
this "feature" breaks certain multi-card setups and god knows what.
So we're
On Mon, Aug 30, 2010 at 06:46:53PM -0400, Brynet wrote:
> Evening,
>
> I have two machines with vr(4) interfaces running 4.7, and I can't seem
> to find any problem running ping -f against them.
>
> vr0 at pci0 dev 12 function 0 "VIA VT6105 RhineIII" rev 0x86: apic 2 int
> 19 (irq 10), address 00
Evening,
I have two machines with vr(4) interfaces running 4.7, and I can't seem
to find any problem running ping -f against them.
vr0 at pci0 dev 12 function 0 "VIA VT6105 RhineIII" rev 0x86: apic 2 int
19 (irq 10), address 00:19:5b:82:a1:e0
vr0 at pci0 dev 16 function 0 "VIA Rhine/RhineII" rev
The Xorg xserver runs a scary amount of code in a signal handler.
It's supposed to make your mouse cursor move more smoothly, but I
can't spot the difference when I disable that "feature". Instead,
this "feature" breaks certain multi-card setups and god knows what.
So we're considering switching
ipsecctl part.
Index: ike.c
===
RCS file: /home/cvs/src/sbin/ipsecctl/ike.c,v
retrieving revision 1.67
diff -u -p -r1.67 ike.c
--- ike.c 4 Oct 2009 11:39:32 - 1.67
+++ ike.c 30 Aug 2010 17:54:19 -
@@ -161,6 +
isakmpd part. both initiator and responder modes work fine.
tested against strongswan/pluto and itself.
note that it defaults to AESGCM-256 (i did it this way because
linux picks largest key).
Index: conf.c
===
RCS file: /home/cvs/s
On Tue, Aug 24, 2010 at 12:57 +0200, Mike Belopuhov wrote:
> On Mon, Aug 23, 2010 at 20:19 +0200, Mike Belopuhov wrote:
> > ESP part gets a nice hack (esp_gcm_init_auth) that fakes an
> > authentication part of GCM from the encryption one. Frankly,
> > I'd rather put this into the userland, but it
deraadt@ pointed out that NetBSD committed a uid_t fix for their
sa(8), and as far as I can tell, it's needed in our tree too.
I'd really appreciate if someone who actually uses sa(8) could test
that this diff still works for them and save me the trouble of
learning how to use it. :) The important
12 matches
Mail list logo
