* Re: [PATCH] sky2: fix for Yukon FE (regression in 2.6.25)
From: Jeff Garzik @ 2008-02-05 18:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Petr Vandrovec, netdev
In-Reply-To: <20080204194513.700f6387@extreme>
Stephen Hemminger wrote:
> The Yukon FE chip has a ram buffer therefore it needs the alignment
> restriction and hang check workarounds.
>
> Therefore:
> * Autodetect the prescence/absence of ram buffer
> * Rename the flag value to reflect this
> * Use it consistently (ie don't reread register)
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
applied
^ permalink raw reply
* Re: [PATCH] [POWERPC] iSeries: fix section mismatch in iseries_veth
From: Jeff Garzik @ 2008-02-05 18:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: paulus, ppc-dev, netdev
In-Reply-To: <20080205141940.c6ddb479.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> WARNING: vmlinux.o(.text+0x25dca0): Section mismatch in reference from the function .veth_probe() to the function .init.text:.veth_probe_one()
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/net/iseries_veth.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Jeff, can this go in through the powerpc tree?
>
> diff --git a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
> index 419861c..58d3bb6 100644
> --- a/drivers/net/iseries_veth.c
> +++ b/drivers/net/iseries_veth.c
> @@ -1020,7 +1020,7 @@ static const struct ethtool_ops ops = {
> .get_link = veth_get_link,
> };
>
> -static struct net_device * __init veth_probe_one(int vlan,
> +static struct net_device *veth_probe_one(int vlan,
> struct vio_dev *vio_dev)
> {
it's trivial enough to not matter, and faster to just... applied
(if you'll pardon the bad grammar)
^ permalink raw reply
* Re: [patch 3/4] mv643xx_eth: fix byte order when checksum offload is enabled
From: Jeff Garzik @ 2008-02-05 18:32 UTC (permalink / raw)
To: akpm; +Cc: netdev, byron.bbradley, dale, mlachwani, viro
In-Reply-To: <200802050746.m157kur6010404@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Byron Bradley <byron.bbradley@gmail.com>
>
> The Marvell Orion system on chips have an integrated mv643xx MAC. On these
> little endian ARM devices mv643xx will oops when checksum offload is
> enabled. Swapping the byte order of the protocol and checksum solves this
> problem.
>
> Signed-off-by: Byron Bradley <byron.bbradley@gmail.com>
> Cc: Dale Farnsworth <dale@farnsworth.org>
> Cc: Manish Lachwani <mlachwani@mvista.com>
> Cc: Jeff Garzik <jeff@garzik.org>
> Cc: Al Viro <viro@zeniv.linux.org.uk>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/mv643xx_eth.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
applied 3-4
^ permalink raw reply
* Re: [PATCH] xircom_cb should return NETDEV_TX_BUSY when there are no descriptors available
From: Jeff Garzik @ 2008-02-05 18:33 UTC (permalink / raw)
To: Erik Mouw; +Cc: netdev, Waskiewicz Jr, Peter P, jamal
In-Reply-To: <20080204175653.GC16952@gateway.home>
Erik Mouw wrote:
> Hi,
>
> Changes in other networking paths uncovered a bug in the xircom_cb
> driver which made the kernel spew lots of the following error messages:
>
> BUG eth1 code -5 qlen 0
>
> It turned out that the driver returned -EIO when there was no
> descriptor available for sending packets. It should return
> NETDEV_TX_BUSY instead. This was discussed on the netdev list before,
> see http://thread.gmane.org/gmane.linux.network/84603 .
>
> Signed-off-by: Erik Mouw <mouw@nl.linux.org>
>
> diff --git a/drivers/net/tulip/xircom_cb.c b/drivers/net/tulip/xircom_cb.c
> index 8fc7274..6b93d01 100644
> --- a/drivers/net/tulip/xircom_cb.c
> +++ b/drivers/net/tulip/xircom_cb.c
> @@ -441,7 +441,7 @@ static int xircom_start_xmit(struct sk_buff *skb, struct net_device *dev)
> spin_unlock_irqrestore(&card->lock,flags);
> trigger_transmit(card);
>
> - return -EIO;
> + return NETDEV_TX_BUSY;
> }
>
>
applied
^ permalink raw reply
* Re: [PATCH 8/8] ixgbe: add real-time traffic counters
From: Jeff Garzik @ 2008-02-05 18:33 UTC (permalink / raw)
To: Auke Kok; +Cc: e1000-devel, netdev
In-Reply-To: <20080201235919.31474.147.stgit@localhost.localdomain>
Auke Kok wrote:
> From: Ayyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
>
> Just like our other drivers before we can switch ixgbe to
> provide real-time packet/byte counters to the stack easily.
>
> Signed-off-by: Ayyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/ixgbe/ixgbe_main.c | 15 +++++++++++----
> 1 files changed, 11 insertions(+), 4 deletions(-)
applied 1-8
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [PATCH 1/3] Generic HDLC - fix kernel panic
From: Jeff Garzik @ 2008-02-05 18:33 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: netdev
In-Reply-To: <m3abmknyxl.fsf@maximus.localdomain>
Krzysztof Halasa wrote:
> Fixes kernel panic in Frame Relay mode
>
> Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
applied 1-3
^ permalink raw reply
* Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: H. Peter Anvin @ 2008-02-05 18:38 UTC (permalink / raw)
To: Jeff Garzik; +Cc: akpm, netdev, michael.pyne, AAbdulla, LKML
In-Reply-To: <47A8A90B.6010602@garzik.org>
Jeff Garzik wrote:
>>
>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> NAK - this fixes one set of users, and breaks a working set of users.
>
> Need to add DMI check for the specific motherboard (dmi_check_system),
> and flip flag according to success/failure of that check.
>
Either that, or detect the Gigabyte prefix used as a suffix, since they
seem to be the source of this particular f*ckup.
-hpa
^ permalink raw reply
* Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: Jeff Garzik @ 2008-02-05 18:42 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: akpm, netdev, michael.pyne, AAbdulla, LKML
In-Reply-To: <47A8AD40.7010007@zytor.com>
H. Peter Anvin wrote:
> Jeff Garzik wrote:
>>>
>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>
>> NAK - this fixes one set of users, and breaks a working set of users.
>>
>> Need to add DMI check for the specific motherboard (dmi_check_system),
>> and flip flag according to success/failure of that check.
>>
>
> Either that, or detect the Gigabyte prefix used as a suffix, since they
> seem to be the source of this particular f*ckup.
Indeed, that would work too... though we would need to put out a call
for Gigabyte testers during 2.6.25-rc.
It is an entirely reasonable scenario for NVIDIA to deploy a fix to
Gigabyte, which would then return us to the same scenario we have today:
some work and some don't.
That's my main reason for leaning more conservative here.
Jeff
^ permalink raw reply
* [PATCH] [IPV4]: Fix compiler error with CONFIG_PROC_FS=n
From: Johann Felix Soden @ 2008-02-05 18:43 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Denis V. Lunev
From: Johann Felix Soden <johfel@users.sourceforge.net>
Handle CONFIG_PROC_FS=n in net/ipv4/fib_frontend.c because:
net/ipv4/fib_frontend.c: In function 'fib_net_init':
net/ipv4/fib_frontend.c:1032: error: implicit declaration of function 'fib_proc_init'
net/ipv4/fib_frontend.c: In function 'fib_net_exit':
net/ipv4/fib_frontend.c:1047: error: implicit declaration of function 'fib_proc_exit'
Signed-off-by: Johann Felix Soden <johfel@users.sourceforge.net>
---
net/ipv4/fib_frontend.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 86ff271..581d588 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -1029,9 +1029,12 @@ static int __net_init fib_net_init(struct net *net)
error = nl_fib_lookup_init(net);
if (error < 0)
goto out_nlfl;
+#ifdef CONFIG_PROC_FS
error = fib_proc_init(net);
if (error < 0)
goto out_proc;
+#endif
+
out:
return error;
@@ -1044,7 +1047,9 @@ out_nlfl:
static void __net_exit fib_net_exit(struct net *net)
{
+#ifdef CONFIG_PROC_FS
fib_proc_exit(net);
+#endif
nl_fib_lookup_exit(net);
ip_fib_net_exit(net);
}
--
1.5.4
^ permalink raw reply related
* Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: Andrew Morton @ 2008-02-05 18:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, michael.pyne, AAbdulla, LKML
In-Reply-To: <47A8A90B.6010602@garzik.org>
On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <jeff@garzik.org> wrote:
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> NAK - this fixes one set of users, and breaks a working set of users.
>
> Need to add DMI check for the specific motherboard (dmi_check_system),
> and flip flag according to success/failure of that check.
OK :) I added the above to the changelog for next time.
You guys can hide, but this patch isn't going away!
^ permalink raw reply
* [patch 2.6.24-git] net/enc28j60: oops fix, low power mode
From: David Brownell @ 2008-02-05 19:01 UTC (permalink / raw)
To: lanconelli.claudio, netdev
From: David Brownell <dbrownell@users.sourceforge.net>
Prevent unaligned packet oops on enc28j60 packet RX.
Keep enc28j60 chips in low-power mode when they're not in use.
At typically 120 mA, these chips run hot even when idle. Low
power mode cuts that power usage by a factor of around 100.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
drivers/net/enc28j60.c | 54 +++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 50 insertions(+), 4 deletions(-)
--- avr.orig/drivers/net/enc28j60.c 2008-02-05 10:04:22.000000000 -0800
+++ avr/drivers/net/enc28j60.c 2008-02-05 10:50:50.000000000 -0800
@@ -594,6 +594,43 @@ static void nolock_txfifo_init(struct en
nolock_regw_write(priv, ETXNDL, end);
}
+/*
+ * Low power mode shrinks power consumption about 100x, so we'd like
+ * the chip to be in that mode whenever it's inactive.
+ */
+static void enc28j60_lowpower(struct enc28j60_net *priv, bool is_low)
+{
+ int tmp;
+
+ dev_dbg(&priv->spi->dev, "%s power...\n", is_low ? "low" : "high");
+
+ mutex_lock(&priv->lock);
+ if (is_low) {
+ nolock_reg_bfclr(priv, ECON1, ECON1_RXEN);
+ for (;;) {
+ tmp = nolock_regb_read(priv, ESTAT);
+ if (!(tmp & ESTAT_RXBUSY))
+ break;
+ }
+ for (;;) {
+ tmp = nolock_regb_read(priv, ECON1);
+ if (!(tmp & ECON1_TXRTS))
+ break;
+ }
+ /* ECON2_VRPS was set during initialization */
+ nolock_reg_bfset(priv, ECON2, ECON2_PWRSV);
+ } else {
+ nolock_reg_bfclr(priv, ECON2, ECON2_PWRSV);
+ for (;;) {
+ tmp = nolock_regb_read(priv, ESTAT);
+ if (tmp & ESTAT_CLKRDY)
+ break;
+ }
+ /* caller sets ECON1_RXEN */
+ }
+ mutex_unlock(&priv->lock);
+}
+
static int enc28j60_hw_init(struct enc28j60_net *priv)
{
u8 reg;
@@ -612,8 +649,8 @@ static int enc28j60_hw_init(struct enc28
priv->tx_retry_count = 0;
priv->max_pk_counter = 0;
priv->rxfilter = RXFILTER_NORMAL;
- /* enable address auto increment */
- nolock_regb_write(priv, ECON2, ECON2_AUTOINC);
+ /* enable address auto increment and voltage regulator powersave */
+ nolock_regb_write(priv, ECON2, ECON2_AUTOINC | ECON2_VRPS);
nolock_rxfifo_init(priv, RXSTART_INIT, RXEND_INIT);
nolock_txfifo_init(priv, TXSTART_INIT, TXEND_INIT);
@@ -690,7 +727,9 @@ static int enc28j60_hw_init(struct enc28
static void enc28j60_hw_enable(struct enc28j60_net *priv)
{
- /* enable interrutps */
+ enc28j60_lowpower(priv, false);
+
+ /* enable interrupts */
if (netif_msg_hw(priv))
printk(KERN_DEBUG DRV_NAME ": %s() enabling interrupts.\n",
__FUNCTION__);
@@ -717,6 +756,8 @@ static void enc28j60_hw_disable(struct e
nolock_reg_bfclr(priv, ECON1, ECON1_RXEN);
priv->hw_enable = false;
mutex_unlock(&priv->lock);
+
+ enc28j60_lowpower(priv, true);
}
static int
@@ -734,6 +775,8 @@ enc28j60_setlink(struct net_device *ndev
"hw_reset() failed\n");
ret = -EINVAL;
}
+ enc28j60_lowpower(priv, true);
+
} else {
if (netif_msg_link(priv))
dev_warn(&ndev->dev,
@@ -900,7 +943,7 @@ static void enc28j60_hw_rx(struct net_de
if (RSV_GETBIT(rxstat, RSV_LENCHECKERR))
ndev->stats.rx_frame_errors++;
} else {
- skb = dev_alloc_skb(len);
+ skb = dev_alloc_skb(len + NET_IP_ALIGN);
if (!skb) {
if (netif_msg_rx_err(priv))
dev_err(&ndev->dev,
@@ -908,6 +951,7 @@ static void enc28j60_hw_rx(struct net_de
ndev->stats.rx_dropped++;
} else {
skb->dev = ndev;
+ skb_reserve(skb, NET_IP_ALIGN);
/* copy the packet from the receive buffer */
enc28j60_mem_read(priv, priv->next_pk_ptr + sizeof(rsv),
len, skb_put(skb, len));
@@ -1536,6 +1580,8 @@ static int __devinit enc28j60_probe(stru
dev->watchdog_timeo = TX_TIMEOUT;
SET_ETHTOOL_OPS(dev, &enc28j60_ethtool_ops);
+ enc28j60_lowpower(priv, true);
+
ret = register_netdev(dev);
if (ret) {
if (netif_msg_probe(priv))
^ permalink raw reply
* Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: Jeff Garzik @ 2008-02-05 19:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, michael.pyne, AAbdulla, LKML
In-Reply-To: <20080205105909.fd8c6dbe.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
Andrew Morton wrote:
> On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <jeff@garzik.org> wrote:
>
>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>> NAK - this fixes one set of users, and breaks a working set of users.
>>
>> Need to add DMI check for the specific motherboard (dmi_check_system),
>> and flip flag according to success/failure of that check.
>
> OK :) I added the above to the changelog for next time.
>
> You guys can hide, but this patch isn't going away!
In the original thread, I even posted a
fill-in-the-blanks-with-the-motherboard-name patch. I'll attach it again...
Jeff
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1459 bytes --]
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 3634223..eab85fa 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -147,6 +147,7 @@
#include <linux/init.h>
#include <linux/if_vlan.h>
#include <linux/dma-mapping.h>
+#include <linux/dmi.h>
#include <asm/irq.h>
#include <asm/io.h>
@@ -4992,6 +4993,26 @@ static int nv_close(struct net_device *dev)
return 0;
}
+static int nv_reversed_macaddr(void)
+{
+ static const struct dmi_system_id sysids[] = {
+ {
+ .ident = "",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, ""),
+ DMI_MATCH(DMI_PRODUCT_NAME, ""),
+ },
+ },
+
+ { } /* terminate list */
+ };
+
+ if (dmi_check_system(sysids))
+ return 1;
+
+ return 0;
+}
+
static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
{
struct net_device *dev;
@@ -5187,8 +5208,9 @@ static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_i
/* check the workaround bit for correct mac address order */
txreg = readl(base + NvRegTransmitPoll);
- if ((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
- (id->driver_data & DEV_HAS_CORRECT_MACADDR)) {
+ if (((txreg & NVREG_TRANSMITPOLL_MAC_ADDR_REV) ||
+ (id->driver_data & DEV_HAS_CORRECT_MACADDR))) &&
+ (!nv_reversed_macaddr())) {
/* mac address is already in correct order */
dev->dev_addr[0] = (np->orig_mac[0] >> 0) & 0xff;
dev->dev_addr[1] = (np->orig_mac[0] >> 8) & 0xff;
^ permalink raw reply related
* Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: Ayaz Abdulla @ 2008-02-04 17:33 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jeff Garzik, netdev, michael.pyne, LKML
In-Reply-To: <20080205105909.fd8c6dbe.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <jeff@garzik.org> wrote:
>
>
>>>Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>
>>NAK - this fixes one set of users, and breaks a working set of users.
>>
>>Need to add DMI check for the specific motherboard (dmi_check_system),
>>and flip flag according to success/failure of that check.
>
>
> OK :) I added the above to the changelog for next time.
>
> You guys can hide, but this patch isn't going away!
I believe Michael determined that a newer BIOS fixes this issue.
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: Jeff Garzik @ 2008-02-05 19:13 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Andrew Morton, netdev, michael.pyne, LKML
In-Reply-To: <47A74C7E.8080101@nvidia.com>
Ayaz Abdulla wrote:
> Andrew Morton wrote:
>> On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <jeff@garzik.org> wrote:
>>
>>
>>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>>
>>> NAK - this fixes one set of users, and breaks a working set of users.
>>>
>>> Need to add DMI check for the specific motherboard
>>> (dmi_check_system), and flip flag according to success/failure of
>>> that check.
>>
>>
>> OK :) I added the above to the changelog for next time.
>>
>> You guys can hide, but this patch isn't going away!
>
> I believe Michael determined that a newer BIOS fixes this issue.
That's a solution that makes vendors happy... but we still have to deal
with it in Linux. There are plenty of the old broken BIOS still out in
the field...
Jeff
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Andi Kleen @ 2008-02-05 20:02 UTC (permalink / raw)
To: Glenn Griffin; +Cc: Andi Kleen, netdev, linux-kernel
In-Reply-To: <c9e534200802051029u5d08cf6dm54866f769e362262@mail.gmail.com>
On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
> > Syncookies are discouraged these days. They disable too many
> > valuable TCP features (window scaling, SACK) and even without them
> > the kernel is usually strong enough to defend against syn floods
> > and systems have much more memory than they used to be.
> >
> > So I don't think it makes much sense to add more code to it, sorry.
>
> As you say the kernel is usually strong enough to defend against syn flood
> attacks, but what about the situations where it isn't? As valuable as the TCP
> features are I would give them up if it means I'm able to connect to my sshd
> port when I otherwise would be unable to. While increased synq sizes, better
> dropping algorithms, and minisocks are a great way to mitigate the attacks and
> in most cases are enough, there are situations where syncookies are nice.
Have you seen such a case in practice with a modern kernel?
They also cause problems unfortunately; e.g. there is no real flow control for connections
anymore in the non DOS case.
> Regardless, I would say as long as ipv4 has syncookie support it will
> accurately be viewed as a deficiency of ipv6 if it lacks support. So perhaps
> the discussion should be we whether all the other defenses are enough to
> warrant the removal of syncookie support from ipv4. That topic may bring in
> more opinions.
That is essentially what I and Alan were discussing.
>
> > Besides you should really move it to the ipv6 module, right now the code
> > would be always compiled in even for ipv4 only kernels.
>
> That is correct. I will gladly move it into it's own section within net/ipv6/.
> Do you have any problem using the same CONFIG and sysctl variables as the ipv4
> implementation?
No.
-Andi
^ permalink raw reply
* Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: Ayaz Abdulla @ 2008-02-04 17:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Andrew Morton, netdev, michael.pyne, LKML
In-Reply-To: <47A8B558.7060605@garzik.org>
Jeff Garzik wrote:
> Ayaz Abdulla wrote:
>
>> Andrew Morton wrote:
>>
>>> On Tue, 05 Feb 2008 13:20:59 -0500 Jeff Garzik <jeff@garzik.org> wrote:
>>>
>>>
>>>>> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>>>>
>>>>
>>>> NAK - this fixes one set of users, and breaks a working set of users.
>>>>
>>>> Need to add DMI check for the specific motherboard
>>>> (dmi_check_system), and flip flag according to success/failure of
>>>> that check.
>>>
>>>
>>>
>>> OK :) I added the above to the changelog for next time.
>>>
>>> You guys can hide, but this patch isn't going away!
>>
>>
>> I believe Michael determined that a newer BIOS fixes this issue.
>
>
>
> That's a solution that makes vendors happy... but we still have to deal
> with it in Linux. There are plenty of the old broken BIOS still out in
> the field...
>
> Jeff
>
>
Michael, can you provide which BIOS version had this issue and which
version fixed the issue?
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Ross Vandegrift @ 2008-02-05 19:25 UTC (permalink / raw)
To: Glenn Griffin; +Cc: Andi Kleen, netdev, linux-kernel
In-Reply-To: <c9e534200802051029u5d08cf6dm54866f769e362262@mail.gmail.com>
On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
> > Syncookies are discouraged these days. They disable too many
> > valuable TCP features (window scaling, SACK) and even without them
> > the kernel is usually strong enough to defend against syn floods
> > and systems have much more memory than they used to be.
> >
> > So I don't think it makes much sense to add more code to it, sorry.
>
> As you say the kernel is usually strong enough to defend against syn flood
> attacks, but what about the situations where it isn't? As valuable as the TCP
> features are I would give them up if it means I'm able to connect to my sshd
> port when I otherwise would be unable to. While increased synq sizes, better
> dropping algorithms, and minisocks are a great way to mitigate the attacks and
> in most cases are enough, there are situations where syncookies are nice.
>
> Regardless, I would say as long as ipv4 has syncookie support it will
> accurately be viewed as a deficiency of ipv6 if it lacks support. So perhaps
> the discussion should be we whether all the other defenses are enough to
> warrant the removal of syncookie support from ipv4. That topic may bring in
> more opinions.
Yes, syncookies, while presenting some tradeoffs, are a necessary tool
to have.
The problem is that any reasonably recent PC can generate enough
forged SYN packets to overwhelm reasonable SYN queues on a much more
powerful server.
Imagine a server with a few hundres Apache virtual hosts. One website
pisses off the wrong person and it impacts service for everyone.
While syncookies isn't always enough, enabling it often helps
make the server more resiliant during attacks. And for web service, most
of the connections are short-lived connections for small pieces of data -
so I'm not really convinced that window scaling and selective ACK are all
that important.
--
Ross Vandegrift
ross@kallisti.us
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Jan Engelhardt @ 2008-02-05 19:57 UTC (permalink / raw)
To: Andi Kleen; +Cc: Glenn Griffin, netdev, linux-kernel
In-Reply-To: <20080205155558.GA23145@one.firstfloor.org>
On Feb 5 2008 16:55, Andi Kleen wrote:
>On Mon, Feb 04, 2008 at 03:01:01PM -0800, Glenn Griffin wrote:
>> Add IPv6 support to TCP SYN cookies. This is written and tested against
>> 2.6.24, and applies cleanly to linus' current HEAD (d2fc0b). Unfortunately
>> linus' HEAD breaks my sky2 card at the moment, so I'm unable to test against
>> that. I see no reason why it would be affected though. Comments/suggestions
>> are welcome.
>
>Syncookies are discouraged these days. They disable too many
>valuable TCP features (window scaling, SACK) and even without them
>the kernel is usually strong enough to defend against syn floods
>and systems have much more memory than they used to be.
>
>So I don't think it makes much sense to add more code to it, sorry.
Distributions should then probably deactivate it by default.
SUSE 10.3 for example still has it enabled on default installs.
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Andi Kleen @ 2008-02-05 20:11 UTC (permalink / raw)
To: Ross Vandegrift; +Cc: Glenn Griffin, Andi Kleen, netdev, linux-kernel
In-Reply-To: <20080205192559.GA10573@kallisti.us>
> The problem is that any reasonably recent PC can generate enough
> forged SYN packets to overwhelm reasonable SYN queues on a much more
> powerful server.
Have you actually seen this with a recent kernel in the wild or are
you just talking theoretically?
Linux uses some heuristics to manage the syn queue that should
still ensure reasonable service even without cookies under attack.
Also SYN-RECV sockets are stored in a special data structure optimized
to use minimal resources.
It is far from the classical head drop method that was so vunerable
to syn flooding.
-Andi
^ permalink raw reply
* Re: [patch 2/4] forcedeth: fix MAC address detection on network card (regression in 2.6.23)
From: H. Peter Anvin @ 2008-02-05 20:11 UTC (permalink / raw)
To: Jeff Garzik; +Cc: akpm, netdev, michael.pyne, AAbdulla, LKML
In-Reply-To: <47A8ADF9.7060507@garzik.org>
Jeff Garzik wrote:
>
> Indeed, that would work too... though we would need to put out a call
> for Gigabyte testers during 2.6.25-rc.
>
> It is an entirely reasonable scenario for NVIDIA to deploy a fix to
> Gigabyte, which would then return us to the same scenario we have today:
> some work and some don't.
>
> That's my main reason for leaning more conservative here.
>
If they deploy a fix, then the Gigabyte prefix will show up as a prefix,
rather than a suffix - no problem. That's actually the reason to deploy
that solution rather than relying on DMI.
-hpa
^ permalink raw reply
* [PATCH] ipvs: Make wrr "no available servers" error message rate-limited
From: Sven Wegener @ 2008-02-05 20:30 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
No available servers is more an error message than something informational. It
should also be rate-limited, else we're going to flood our logs on a busy
director, if all real servers are out of order with a weight of zero.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
---
Actually, do we need this message at all? The wrr scheduler is the only one
printing an error message in such a case.
net/ipv4/ipvs/ip_vs_wrr.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ipvs/ip_vs_wrr.c b/net/ipv4/ipvs/ip_vs_wrr.c
index 749fa04..85c680a 100644
--- a/net/ipv4/ipvs/ip_vs_wrr.c
+++ b/net/ipv4/ipvs/ip_vs_wrr.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include <linux/kernel.h>
+#include <linux/net.h>
#include <net/ip_vs.h>
@@ -169,7 +170,7 @@ ip_vs_wrr_schedule(struct ip_vs_service *svc, const struct sk_buff *skb)
*/
if (mark->cw == 0) {
mark->cl = &svc->destinations;
- IP_VS_INFO("ip_vs_wrr_schedule(): "
+ IP_VS_ERR_RL("ip_vs_wrr_schedule(): "
"no available servers\n");
dest = NULL;
goto out;
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] [IPV4]: Fix compiler error with CONFIG_PROC_FS=n
From: Denis V. Lunev @ 2008-02-05 19:57 UTC (permalink / raw)
To: Johann Felix Soden; +Cc: David S. Miller, netdev
In-Reply-To: <1202237034.9289.8.camel@localhost>
Johann Felix Soden wrote:
> From: Johann Felix Soden <johfel@users.sourceforge.net>
>
> Handle CONFIG_PROC_FS=n in net/ipv4/fib_frontend.c because:
>
> net/ipv4/fib_frontend.c: In function 'fib_net_init':
> net/ipv4/fib_frontend.c:1032: error: implicit declaration of function 'fib_proc_init'
> net/ipv4/fib_frontend.c: In function 'fib_net_exit':
> net/ipv4/fib_frontend.c:1047: error: implicit declaration of function 'fib_proc_exit'
>
> Signed-off-by: Johann Felix Soden <johfel@users.sourceforge.net>
Fix from Li Zefan is already commited.
(cc8274f50f2ad9a97a837451f63a0a3e65f7f490)
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Evgeniy Polyakov @ 2008-02-05 20:39 UTC (permalink / raw)
To: Andi Kleen; +Cc: Glenn Griffin, netdev, linux-kernel
In-Reply-To: <20080205200211.GA26150@one.firstfloor.org>
On Tue, Feb 05, 2008 at 09:02:11PM +0100, Andi Kleen (andi@firstfloor.org) wrote:
> On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
> > > Syncookies are discouraged these days. They disable too many
> > > valuable TCP features (window scaling, SACK) and even without them
> > > the kernel is usually strong enough to defend against syn floods
> > > and systems have much more memory than they used to be.
> > >
> > > So I don't think it makes much sense to add more code to it, sorry.
How does syncookies prevent windows from growing?
Most (if not all) distributions have them enabled and window growing
works just fine. Actually I do not see any reason why connection
establishment handshake should prevent any run-time operations at all,
even if it was setup during handshake.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Andi Kleen @ 2008-02-05 20:53 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: Andi Kleen, Glenn Griffin, netdev, linux-kernel
In-Reply-To: <20080205203911.GA9891@2ka.mipt.ru>
On Tue, Feb 05, 2008 at 11:39:11PM +0300, Evgeniy Polyakov wrote:
> On Tue, Feb 05, 2008 at 09:02:11PM +0100, Andi Kleen (andi@firstfloor.org) wrote:
> > On Tue, Feb 05, 2008 at 10:29:28AM -0800, Glenn Griffin wrote:
> > > > Syncookies are discouraged these days. They disable too many
> > > > valuable TCP features (window scaling, SACK) and even without them
> > > > the kernel is usually strong enough to defend against syn floods
> > > > and systems have much more memory than they used to be.
> > > >
> > > > So I don't think it makes much sense to add more code to it, sorry.
>
> How does syncookies prevent windows from growing?
Syncookies do not allow window scaling so you can't have any windows >64k
> Most (if not all) distributions have them enabled and window growing
> works just fine. Actually I do not see any reason why connection
> establishment handshake should prevent any run-time operations at all,
> even if it was setup during handshake.
TCP only uses options negotiated during the hand shake and syncookies
is incapable to do this.
-Andi
^ permalink raw reply
* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Josh Boyer @ 2008-02-05 21:12 UTC (permalink / raw)
To: jgarzik; +Cc: benh, Stefan Roese, linuxppc-dev, netdev
In-Reply-To: <1201734898.8146.0.camel@pasglop>
On Thu, 31 Jan 2008 10:14:58 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Wed, 2008-01-30 at 07:16 +0100, Stefan Roese wrote:
> > On Wednesday 16 January 2008, Josh Boyer wrote:
> > > On Wed, 16 Jan 2008 20:53:59 +1100
> > >
> > > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > > On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> > > > > With the removal the the "rgmii-interface" device_type property from
> > > > > the dts files, the newemac driver needs an update to only rely on
> > > > > compatible property.
> > > > >
> > > > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > >
> > > > I need to test if it works on CAB, can't change the DT on those. I'll
> > > > let you know tomorrow.
> > >
> > > This should be fine on CAB. The rgmii node has:
> > >
> > > compatible = "ibm,rgmii-axon", "ibm,rgmii"
> > >
> > > so the match should still catch on the latter.
> >
> > How about this patch? Ben, if you think this is ok then we should make sure
> > that it goes in in this merge-window, since the other dts patch relies on it.
>
> It's fine.
Jeff, any chance this can get into .25 soon? I have another patch
queued up behind this one that requires it, and I don't see it in any
of your trees or branches.
Or, if you aren't opposed, I can take it through Paul's tree with your
Ack.
josh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox