Joe Perches wrote:
> Perhaps it's more sensible to go back to
>
> #ifdef DEBUG
> #define pr_debug(fmt, arg...) do {} while (0)
> #endif
>
> and give up the printf argument verification
I think argument verification is important. Can you keep it
like this:
#ifdef DEBUG
#define pr_debug(fmt, ar
Laszlo Attila Toth wrote:
> Hello,
>
> Different network interfaces can be grouped using the same group ID. With this
> patch fewer netfilter rules are necessary but it may also be used by routing.
This allows an interface to belong to only one group. I expect there are
situations where you want
Florian Fainelli wrote:
> Hi all,
>
> When using the r8169 gigabit ethernet network driver under a Sun Entreprise
> 450, you will encounter a lot of kernel unaligned access on ip_rcv and
> ip_fast_csum. The full report is available here :
> http://www.mail-archive.com/debian-bugs-dist%40lists.d
Sebastian Kuzminsky wrote:
> Why did the packet from the client cause the connection to be added back
> to the conntrack table, but the packet from the server did not?
Because the packet from the client was accepted (by a different
iptables rule).
-
To unsubscribe from this list: send the line "u
Sebastian Kuzminsky wrote:
> Weird. Why does sending a message from the client make it go again?
The rule that allows packets with an "ESTABLISHED" state only matches
packets for which the connection is in netfilter's conntrack table.
The connection is removed from the table after the 5 days of i
Sebastian Kuzminsky wrote:
> I'm seeing some weird behavior in TCP. The issue is perfectly
> reproducible using netcat and other programs. This is what I do:
>
> 1. Open a TCP connection over the loopback (over IPv4).
>
> 2. Send a couple of bytes of data each way. No problems.
>
>
Francois Romieu wrote:
> The experimental r8169 patch of the day against 2.6.21-rc1 is available at:
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.21-rc1/
Is 0006-r8169-confusion-between-hardware-and-IP-header-alignment.txt
the only relevant patch?
This only partially helps. Many of the pack
Francois Romieu wrote:
> Philip Craig <[EMAIL PROTECTED]> :
> [...]
>> This patch caused a drop in throughput from 178 Mbits/sec to 135 Mbits/sec
>> on an Intel XScale IXP465.
>
> Which distribution of packet sizes ?
Just using iperf with the default options, MTU
Francois Romieu wrote:
> Two thirds of packets are lost because of misalignment. Users of
> Asus laptop did apparently not notice it.
>
> Reported on Gigabyte GA-945GM-S2.
>
> Fix for http://bugzilla.kernel.org/show_bug.cgi?id=7517
>
> Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
> ---
>
Francois Romieu wrote:
> Mostly taken from Realtek's driver.
>
> It's a bit yucky but the original is even worse.
This patch fixes a performance regression for my 8169s.
But it appears to have a typo, see below.
>
> Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
> Signed-off-by: Darren Sal
David Miller wrote:
>> I've been sitting on this patch because afaik the problem which it purports
>> to fix remains unfixed.
>>
>> Should I drop it??
>>
>> Thanks.
>
> Please drop it, the patch submitted didn't give us the feedback
> and test results we asked for which is necessary to pinpoint th
Patrick McHardy wrote:
> Joerg Roedel wrote:
>> On Thu, Sep 14, 2006 at 11:21:22AM +1000, Philip Craig wrote:
>>
>>> Joerg Roedel wrote:
>>>
>>>> + To configure tunnels an extra tool is required. You can download
>>>> + it
Joerg Roedel wrote:
> + To configure tunnels an extra tool is required. You can download
> + it from http://zlug.fh-zwickau.de/~joro/projects/ under the
> + EtherIP section. If unsure, say N.
To obtain a list of tunnels, this tool calls SIOCGETTUNNEL
(SIOCDEVPRIVATE + 0) for every d
Lennert Buytenhek wrote:
> I have one machine at home that appears to be on my employer's network
> via such a tunnel. I don't use bridging, because I don't need any other
> machine at home to access this tunnel. I do want bridging, and not proxy
> ARP, because it allows me to run arpwatch, and d
Lennert Buytenhek wrote:
> On Thu, Aug 03, 2006 at 07:14:59PM +1000, Philip Craig wrote:
>
>>> So now you _need_ bridging in the middle to send ethernet traffic over
>>> a GRE tunnel? Ugh.
>> Agreed that would not be nice. What is the usage scenario for this?
>
Lennert Buytenhek wrote:
> So now you _need_ bridging in the middle to send ethernet traffic over
> a GRE tunnel? Ugh.
Agreed that would not be nice. What is the usage scenario for this?
At least one end of the tunnel will be bridged?
> If you really want to send ethernet and non-ethernet traff
Lennert Buytenhek wrote:
> On Mon, Jul 31, 2006 at 10:08:22PM -0700, Stephen Hemminger wrote:
>
Why not use existing bridge code?
>>> It does use the existing bridge code. Perhaps the name is misleading.
>>> All it does is encapsulate the full ethernet header in a gre packet,
>>> rather than
Stephen Hemminger wrote:
> On Wed, 02 Aug 2006 16:17:42 +1000
> Philip Craig <[EMAIL PROTECTED]> wrote:
>> It generates a random mac address for gre ports, and also stores
>> a copy of the mac address for ethernet ports, rather than checking
>> dev->type ever
> Stephen Hemminger wrote:
>> I am not against making the bridge code smarter to handle other
>> encapsulation.
Here's an updated patch that fixes all issues I am aware of.
It generates a random mac address for gre ports, and also stores
a copy of the mac address for ethernet ports, rather than c
Stephen Hemminger wrote:
> I am not against making the bridge code smarter to handle other
> encapsulation.
Do you mean something like this patch?
The only drawback I see for this approach is that it means you
can only encapsulate the ethernet header if the gre interface is
bridged. That's not t
Stephen Hemminger wrote:
> On Mon, 31 Jul 2006 20:06:41 +1000
> Philip Craig <[EMAIL PROTECTED]> wrote:
>
>> This patch implements transparent ethernet bridging for gre tunnels.
>> There are a few outstanding issues.
>
> Why not use existing bridge code?
It
This patch implements transparent ethernet bridging for gre tunnels.
There are a few outstanding issues.
There is no way for userspace to select the type of gre tunnel. The
#if 0 near the top of the patch forces all gre tunnels to be bridges.
The problem is that userspace uses an IPPROTO_ to selec
On 06/22/2006 02:55 PM, Andrew Morton wrote:
> - Is there a better way of doing this?
>
> static void ql_swap_mac_addr(u8 * macAddress)
> {
> #ifdef __BIG_ENDIAN
> u8 temp;
> temp = macAddress[0];
> macAddress[0] = macAddress[1];
> macAddress[1] = temp;
> temp = macAdd
The read command for the 93C46/93C56 EEPROMS should be 3 bits plus
the address. This doesn't appear to affect the operation of the
read command, but similar errors for write commands do cause failures.
Signed-off-by: Philip Craig <[EMAIL PROTECTED]>
Index: linux-2.6.17-rc6/drivers/n
Implement the ethtool eeprom operations for the 8139cp driver.
Tested on x86 and big-endian ARM.
Signed-off-by: Philip Craig <[EMAIL PROTECTED]>
Index: linux-2.6.17-rc6/drivers/net/8139cp.c
===
--- linux-2.6.17-rc6.orig/drive
Implement the ethtool eeprom operations for the 8139cp driver.
Tested on x86 and big-endian ARM.
Signed-off-by: Philip Craig <[EMAIL PROTECTED]>
Index: linux-2.6.17-rc6/drivers/net/8139cp.c
===
--- linux-2.6.17-rc6.orig/drive
The read command for the 93C46/93C56 EEPROMS should be 3 bits plus
the address. This doesn't appear to affect the operation of the
read command, but similar errors for write commands do cause failures.
Signed-off-by: Philip Craig <[EMAIL PROTECTED]>
Index: linux-2.6.17-rc6/drivers/n
On 04/14/2006 06:26 AM, David S. Miller wrote:
> These interfaces were added so that new users of netlink could
> write their code more easily.
>
> Unused does not equate to "comment out or delete".
Does a GENETLINK Kconfig option make sense (possibly dependant on
EMBEDDED)? I'm unsure whether th
28 matches
Mail list logo
