https://bugzilla.redhat.com/show_bug.cgi?id=430391
Bringing up interface bond0:
BUG: unable to handle kernel NULL
pointer dereference at virtual address
printing eip: c0506fd8 *pde = 7f5f8067
Oops: [#1] SMP
Modules linked in: bonding ipv6 xt_pkttype ipt_LOG ipt_iprange
ipt_REJECT x
David Miller <[EMAIL PROTECTED]> writes:
> No IRQ balancing should be done at all for networking device
> interrupts, with zero exceptions. It destroys performance.
Does irqbalanced need to be taught about this? And how about the
initial balancing, so that each network card gets assigned to one
Jarek Poplawski <[EMAIL PROTECTED]> writes:
> Subject: [PATCH] nested VLAN: fix lockdep's recursive locking warning
>
> Allow vlans nesting other vlans without lockdep's warnings (max. 8 levels).
>
> Reported-by: Benny Amorsen
> Tested-by: Benny Amorsen (?
Herbert Xu <[EMAIL PROTECTED]> writes:
> As the name suggests you should use
>
> /proc/sys/net/ipv4/conf/all/arp_accept
The documentation says that if arp_accept is 0, unsolicited arp
replies are dropped. Doesn't that interfere with failover services
such as vrrp, keepalived, ucarp etc? I t
> "DM" == David Miller <[EMAIL PROTECTED]> writes:
DM> When the user does a recvmsg() or a poll() on the socket, we will
DM> notice the bad checksum then and increment InErrors. We could in
DM> this case correct the InDatagrams counter by decrementing it in
DM> this case.
Does that mean that
> "DM" == David Miller <[EMAIL PROTECTED]> writes:
>> Reply:
>> Opcode: reply (0x0002)
>> Sender HW: 00:AA.00:AA:00:AA
>> Sender IP: 192.168.0.1
>> Target HW: 00:AA:00:AA:00:AA
>> Target IP:192.168.0.1
DM> And this is exactly a sensible response in my opinion.
Why send the reply at al
> "AK" == Kok, Auke <[EMAIL PROTECTED]> writes:
AK> actually the impact can be quite negative, imagine doing a tcpdump
AK> on a 10gig interface with vlan's enabled - all of a sudden you
AK> might accidentally flood the system with a 100-fold increase in
AK> traffic and force the stack to dump
> "DM" == David Miller <[EMAIL PROTECTED]> writes:
DM> And some people still use hubs, believe it or not.
Hubs are 100Mbps at most. You could of course make a flooding Gbps
switch, but it would be rather silly. If you care about multicast
performance, you get a switch with IGMP snooping.
/B
> "DM" == David Miller <[EMAIL PROTECTED]> writes:
DM> Containers are I believe a step backwards, and we're better than
DM> that.
Are there any alternative proposals?
I guess it would be a start if you could run processes with a
different policy table as default. Ideally traffic from those
p
> "DM" == David Miller <[EMAIL PROTECTED]> writes:
DM> To be honest I think this form of virtualization is a complete
DM> waste of time, even the openvz approach.
You are only considering the security values of OpenVZ. Where I work,
OpenVZ and Linux-vserver are used for their ability to clean
> "AvdV" == Arjan van de Ven <[EMAIL PROTECTED]> writes:
AvdV> even if you have NO power savings you still don't meet your
AvdV> criteria. That's basic ethernet for you
AvdV> That's what I was trying to say; your criteria is unrealistic
AvdV> regardless of what the kernel does, ethernet a
11 matches
Mail list logo
