2012/4/10 Gleb Smirnoff :
> Thanks, Ryan!
(snip)
> Looks okay from my viewpoint. Have you stress tested it? My snap patch
> definitely had problems, AFAIR.
>
> If this patch fixes panics observed by kern/165863 and passes stress
> testing, then it should be committed ASAP, and shouldn't depend on
I noticed this first on a 10G interface, but now there seems
to be a similar issue on the loopback.
Apparently a ping -f has a much lower RTT than one with non-zero
delay between transmissions. Part of the story could be that
the flood version invokes a non-blocking select.
On the other hand, ping
On 4/10/12 3:52 PM, Luigi Rizzo wrote:
I noticed this first on a 10G interface, but now there seems
to be a similar issue on the loopback.
Apparently a ping -f has a much lower RTT than one with non-zero
delay between transmissions. Part of the story could be that
the flood version invokes a non
On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote:
> CPU cache?
> Cx states?
> powerd?
powerd is disabled, and i am going down to C1 at most
> sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C1
dev.cpu.0.cx_supported: C1/1 C2/80 C3/104
which shouldn't take so much. S
CPU cache?
Cx states?
powerd?
On Tue, Apr 10, 2012 at 03:40:27PM -0700, Julian Elischer wrote:
> On 4/10/12 3:52 PM, Luigi Rizzo wrote:
> > I noticed this first on a 10G interface, but now there seems
> > to be a similar issue on the loopback.
> >
> > Apparently a ping -f has a much lower RTT than
>
> [rstone@vm-head ~]ndp -a
> Neighbor Linklayer Address Netif ExpireS
> Flags
> 1::2 08:00:27:1e:b8:16em0 7sR
> fe80::a00:27ff:fefa:8732%em0 08:00:27:fa:87:32em0 permanent R
> rstone@vm-head ~]uname -a
> Fre
On Wed, Apr 11, 2012 at 12:52:57AM +0200, Luigi Rizzo wrote:
> I noticed this first on a 10G interface, but now there seems
> to be a similar issue on the loopback.
>
> Apparently a ping -f has a much lower RTT than one with non-zero
> delay between transmissions. Part of the story could be that
