* Re: KS8695: possible NAPI issue
From: Stephen Hemminger @ 2010-03-05 16:22 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Figo.zhang, Dick Hollenbeck, netdev, zealcook
In-Reply-To: <f69abfc31003050700y57718a6aje3c1ff41d04748ae@mail.gmail.com>
On Fri, 5 Mar 2010 16:00:11 +0100
Yegor Yefremov <yegorslists@googlemail.com> wrote:
> >> My tests look like following:
> >>
> >> 1. system start
> >> 2. ping one host: O.K.
> >> 3. nc -l -p 5000 > /var/test (about 1Mb): O.K.
> >> 4. ping the same host: failed
> > 1. type "arp" command, see the arp is exit or expire?
>
> debian:~# nc -l -p 5000 > /var/zImage
>
> debian:~# ping -c 1 192.168.1.38
>
> PING 192.168.1.38 (192.168.1.38) 56(84) bytes of data.
>
> From 192.168.1.66 icmp_seq=1 Destination Host Unreachable
>
>
>
> --- 192.168.1.38 ping statistics ---
>
> 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
>
>
>
> debian:~# arp
>
> Address HWtype HWaddress Flags Mask Iface
> 192.168.1.38 (incomplete) eth0
>
> 192.168.1.36 ether 00:10:18:39:19:aa C eth0
>
>
> > 2. at this point, see is it still have RX interrpt and receive packet in
> > ks8695_rx()? (in some watchpoint add printk).
>
> I've inserted some printks and I can see that interrupts are coming
> and the received count will be increased. I can also see my system
> sending arp requests. Even this ping request is visible in wireshark
> and its reply, but the ping utility sees nothing of it.
One of the requirements for NAPI to work is that the IRQ is level triggered.
Otherwise there can be a race between packet arrival and the end of
NAPI processing:
static int ks8695_poll(struct napi_struct *napi, int budget)
{
struct ks8695_priv *ksp = container_of(napi, struct ks8695_priv, napi);
unsigned long work_done;
unsigned long isr = readl(KS8695_IRQ_VA + KS8695_INTEN);
unsigned long mask_bit = 1 << ks8695_get_rx_enable_bit(ksp);
work_done = ks8695_rx(ksp, budget);
if (work_done < budget) {
unsigned long flags;
spin_lock_irqsave(&ksp->rx_lock, flags);
>>> packet arrives >>
/*enable rx interrupt*/
writel(isr | mask_bit, KS8695_IRQ_VA + KS8695_INTEN);
>>> or here >>
__napi_complete(napi);
spin_unlock_irqrestore(&ksp->rx_lock, flags);
If the hardware can't be reprogrammed to level mode;
the solution used in some drivers is to poll for lost packet after re-enabling
NAPI.
--
^ permalink raw reply
* Re: Help On function to get IPV6 address of an interface in kernel
From: Venkata Mohan Reddy @ 2010-03-05 15:49 UTC (permalink / raw)
To: Brian Haley; +Cc: netdev
In-Reply-To: <4B8FDD23.3070000@hp.com>
Thanks a lot Brain. ipv6_get_lladdr() helped me. Actually I want to get site-local or univeral(global) address. Though there is no direct function to get theseaddresses, ipv6_get_lladdr() shows how we can get the other addresses too.
Thanks,
Mohan Reddy
On Thu, Mar 04, 2010 at 11:17:39AM -0500, Brian Haley wrote:
> Mohan Reddy wrote:
> > Hi,
> >
> > Is there a function or a way in kernel to get an interface ipv6 address if interface name or net_device object is known? I searched in the kernel i got a function ipv6_get_ifaddr(). But it is expecting an ipv6 address as a parameter.
>
> What type of IPv6 address? For link-locals you can use ipv6_get_lladdr(), but
> for others ipv6_dev_get_saddr() is more comprehensive, but you'll need a
> destination address. There's lots of reference code in addrconf.c to do
> other things.
>
> -Brian
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: Steve.Glendinning @ 2010-03-05 15:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100305.063909.26489418.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote on 05/03/2010 14:39:09:
> From: Steve Glendinning <steve.glendinning@smsc.com>
> Date: Fri, 5 Mar 2010 12:47:05 +0000
>
> > This patch fixes a reproducible null dereference in smsc95xx (and I
> > suspect others) when the device is removed during a control register
> > access. This can be reproduced by rapidly plugging and unplugging
> > the device during its initialisation.
> >
> > Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
>
> The parent shouldn't become NULL until the device is totally quiesced
> and is no longer accesses.
The failure I'm seeing is caused when the usb device is disconnected.
smsc95xx detects that a pending USB control operation failed
and tries to print a message via netdev_printk to report this.
Unfortunately, something else (the USB subsystem?) has already set
parent to null at this time so the netdev_printk causes a null
dereference.
So netdev_printk suddenly changes from safe to use to unsafe to use?
I could change all instances in smsc95xx to defensively check this
at each call, but what should I test to see if the device is still
valid? Is testing parent != null the correct thing to do?
I think other usbnet drivers may have the same problem, but I don't have
any hardware to test them.
> Maybe you can instead fix the smsc95xx driver to abide by this rule
> instead of adding a conditional check to thousands of other drivers in
> the tree that do not need this?
I agree it'd be better to avoid this check where it's unnecessary, but
if netdev_printk isn't necessarily safe to call for *removable* interfaces
then shouldn't all such callers be checking that it's safe to do so?
Steve
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: David Miller @ 2010-03-05 15:43 UTC (permalink / raw)
To: Steve.Glendinning; +Cc: netdev
In-Reply-To: <OF33DF005A.0C447DF0-ON802576DD.00538FB8-802576DD.00552375@smsc.com>
From: Steve.Glendinning@smsc.com
Date: Fri, 5 Mar 2010 15:29:41 +0000
> The failure I'm seeing is caused when the usb device is disconnected.
> smsc95xx detects that a pending USB control operation failed
> and tries to print a message via netdev_printk to report this.
>
> Unfortunately, something else (the USB subsystem?) has already set
> parent to null at this time so the netdev_printk causes a null
> dereference.
>
> So netdev_printk suddenly changes from safe to use to unsafe to use?
It seems to me that really you only need this parent NULL check where
you notice the USB control operation failed and want to print a
message about that.
That should cover all the necessary cases shouldn't it?
Even more importantly, why does a USB disconnect NULL out the netdev
parent device pointer? Until you actually release this USB device in
the driver, the parent pointer should stay there.
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: David Miller @ 2010-03-05 15:03 UTC (permalink / raw)
To: joe; +Cc: steve.glendinning, netdev
In-Reply-To: <1267800620.3832.17.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Fri, 05 Mar 2010 06:50:20 -0800
> On Fri, 2010-03-05 at 06:39 -0800, David Miller wrote:
>> From: Steve Glendinning <steve.glendinning@smsc.com>
>> Date: Fri, 5 Mar 2010 12:47:05 +0000
>>
>> > This patch fixes a reproducible null dereference in smsc95xx (and I
>> > suspect others) when the device is removed during a control register
>> > access. This can be reproduced by rapidly plugging and unplugging
>> > the device during its initialisation.
>> >
>> > Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
>>
>> The parent shouldn't become NULL until the device is totally quiesced
>> and is no longer accesses.
>>
>> Maybe you can instead fix the smsc95xx driver to abide by this rule
>> instead of adding a conditional check to thousands of other drivers in
>> the tree that do not need this?
>>
>> I really have no intention of adding your change, please fix this
>> properly, thanks.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> Perhaps something like this is appropriate in the mean time:
>
> const char *get_netdev_parent_name(const struct net_device *dev)
> {
> if (!dev->dev.parent)
> return "Unparented net_device, please report this";
> return netdev->dev.parent;
> }
Yes, but in the smsc95xx driver. :-)
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Yegor Yefremov @ 2010-03-05 15:03 UTC (permalink / raw)
To: Figo.zhang; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <1267797137.2576.11.camel@myhost>
On Fri, Mar 5, 2010 at 2:52 PM, Figo.zhang <figo1802@gmail.com> wrote:
>
>>
>> and even if the fourth test succeeds, if I then send a file from other
>> host the next ping or any other communication fails. I just tried to
>> make some SSH sessions. It goes without a problem till I issue a ping
>> after that.
>>
>> If I test the system with nuttcp I have no problem.
> the network driver seems work well for system. the "netcat" application
> is build in busybox? you can check busybox configure.
I'm using Debian for ARM. So it is standard netcat for Debian 5.0.
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Yegor Yefremov @ 2010-03-05 15:00 UTC (permalink / raw)
To: Figo.zhang; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <1267798077.2576.17.camel@myhost>
>> My tests look like following:
>>
>> 1. system start
>> 2. ping one host: O.K.
>> 3. nc -l -p 5000 > /var/test (about 1Mb): O.K.
>> 4. ping the same host: failed
> 1. type "arp" command, see the arp is exit or expire?
debian:~# nc -l -p 5000 > /var/zImage
debian:~# ping -c 1 192.168.1.38
PING 192.168.1.38 (192.168.1.38) 56(84) bytes of data.
>From 192.168.1.66 icmp_seq=1 Destination Host Unreachable
--- 192.168.1.38 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
debian:~# arp
Address HWtype HWaddress Flags Mask Iface
192.168.1.38 (incomplete) eth0
192.168.1.36 ether 00:10:18:39:19:aa C eth0
> 2. at this point, see is it still have RX interrpt and receive packet in
> ks8695_rx()? (in some watchpoint add printk).
I've inserted some printks and I can see that interrupts are coming
and the received count will be increased. I can also see my system
sending arp requests. Even this ping request is visible in wireshark
and its reply, but the ping utility sees nothing of it.
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: Joe Perches @ 2010-03-05 14:50 UTC (permalink / raw)
To: David Miller; +Cc: steve.glendinning, netdev
In-Reply-To: <20100305.063909.26489418.davem@davemloft.net>
On Fri, 2010-03-05 at 06:39 -0800, David Miller wrote:
> From: Steve Glendinning <steve.glendinning@smsc.com>
> Date: Fri, 5 Mar 2010 12:47:05 +0000
>
> > This patch fixes a reproducible null dereference in smsc95xx (and I
> > suspect others) when the device is removed during a control register
> > access. This can be reproduced by rapidly plugging and unplugging
> > the device during its initialisation.
> >
> > Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
>
> The parent shouldn't become NULL until the device is totally quiesced
> and is no longer accesses.
>
> Maybe you can instead fix the smsc95xx driver to abide by this rule
> instead of adding a conditional check to thousands of other drivers in
> the tree that do not need this?
>
> I really have no intention of adding your change, please fix this
> properly, thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Perhaps something like this is appropriate in the mean time:
const char *get_netdev_parent_name(const struct net_device *dev)
{
if (!dev->dev.parent)
return "Unparented net_device, please report this";
return netdev->dev.parent;
}
^ permalink raw reply
* Re: [PATCH] Fix netdev_printk null dereference
From: David Miller @ 2010-03-05 14:39 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1267793225-426-1-git-send-email-steve.glendinning@smsc.com>
From: Steve Glendinning <steve.glendinning@smsc.com>
Date: Fri, 5 Mar 2010 12:47:05 +0000
> This patch fixes a reproducible null dereference in smsc95xx (and I
> suspect others) when the device is removed during a control register
> access. This can be reproduced by rapidly plugging and unplugging
> the device during its initialisation.
>
> Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
The parent shouldn't become NULL until the device is totally quiesced
and is no longer accesses.
Maybe you can instead fix the smsc95xx driver to abide by this rule
instead of adding a conditional check to thousands of other drivers in
the tree that do not need this?
I really have no intention of adding your change, please fix this
properly, thanks.
^ permalink raw reply
* Re: [PATCH] s2io: fixing DBG_PRINT() macro
From: Breno Leitao @ 2010-03-05 14:21 UTC (permalink / raw)
To: David Miller; +Cc: sreenivasa.honnur, joe, netdev
In-Reply-To: <1267623697-14781-1-git-send-email-leitao@linux.vnet.ibm.com>
David,
Due my mistake I didn't send this patch to Sreenivasa. After
sending this patch to netdev, I forward to him, and
he acked it privately.
Sorry for the confusion.
Thanks,
Breno
leitao@linux.vnet.ibm.com wrote:
> Patch 9e39f7c5b311a306977c5471f9e2ce4c456aa038 changed the
> DBG_PRINT() macro and the if clause was changed. It means
> that currently all the DBG_PRINT are being printed, flooding
> the kernel log buffer with thinkgs like:
>
> s2io: eth6: Next block at: c0000000b9c90000
> s2io: eth6: In Neterion Tx routine
>
> This patch just fixes the if clause condition.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
> ---
> drivers/net/s2io.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
> index 47c36e0..3b6f45d 100644
> --- a/drivers/net/s2io.h
> +++ b/drivers/net/s2io.h
> @@ -65,7 +65,7 @@ static int debug_level = ERR_DBG;
>
> /* DEBUG message print. */
> #define DBG_PRINT(dbg_level, fmt, args...) do { \
> - if (dbg_level >= debug_level) \
> + if (dbg_level <= debug_level) \
> pr_info(fmt, ##args); \
> } while (0)
>
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Figo.zhang @ 2010-03-05 14:07 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <f69abfc31003050206h4f9ffe65s2b90e6acea014ec2@mail.gmail.com>
>
> My tests look like following:
>
> 1. system start
> 2. ping one host: O.K.
> 3. nc -l -p 5000 > /var/test (about 1Mb): O.K.
> 4. ping the same host: failed
1. type "arp" command, see the arp is exit or expire?
2. at this point, see is it still have RX interrpt and receive packet in
ks8695_rx()? (in some watchpoint add printk).
>
> and even if the fourth test succeeds, if I then send a file from other
> host the next ping or any other communication fails. I just tried to
> make some SSH sessions. It goes without a problem till I issue a ping
> after that.
>
> If I test the system with nuttcp I have no problem.
>
> Do you have any idea how to debug this? If I remove the NAPI support I
> have no problem with the same kernel and environment. I'd really like
> to get the whole stuff working.
>
> Regards,
> Yegor
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Figo.zhang @ 2010-03-05 13:52 UTC (permalink / raw)
To: Yegor Yefremov; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <f69abfc31003050206h4f9ffe65s2b90e6acea014ec2@mail.gmail.com>
>
> and even if the fourth test succeeds, if I then send a file from other
> host the next ping or any other communication fails. I just tried to
> make some SSH sessions. It goes without a problem till I issue a ping
> after that.
>
> If I test the system with nuttcp I have no problem.
the network driver seems work well for system. the "netcat" application
is build in busybox? you can check busybox configure.
>
> Do you have any idea how to debug this? If I remove the NAPI support I
> have no problem with the same kernel and environment. I'd really like
> to get the whole stuff working.
>
> Regards,
> Yegor
^ permalink raw reply
* Re: [PATCH V3 5/8] sctp: use limited socket backlog
From: Vlad Yasevich @ 2010-03-05 13:30 UTC (permalink / raw)
To: Zhu, Yi
Cc: Eric Dumazet, davem@davemloft.net, netdev@vger.kernel.org,
Sridhar Samudrala
In-Reply-To: <DA586906BA1FFC4384FCFD6429ECE860A4604767@shzsmsx502.ccr.corp.intel.com>
Zhu, Yi wrote:
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> As advertized by comment, we should hold the association *before*
>> accessing backlog queue.
>
>> If order is not important, comment should be relaxed somehow ?
>
> I don't see how the order is important here. We are under sock_lock
> here thus nobody will race with us. IMHO, the comment talks about
> if a packet is queued into the backlog, we need to increase the assoc/ep
> reference count. Otherwise the assoc/ep might be disappeared when
> we are about to process it (by sctp_backlog_rcv) sometime later.
>
> Thanks,
> -yi
Yes, that's correct. The order is not really important since we
are under lock and are actually already holding a ref. However
the ref will be dropped once we exit the function, so the function
takes an additional ref that is held while the packet is backloged.
You could get rid of the extra nesting though by returning early
if backlog failed.
-vlad
^ permalink raw reply
* Re: [PATCH V3 1/8] net: add limit for socket backlog
From: Arnaldo Carvalho de Melo @ 2010-03-05 13:00 UTC (permalink / raw)
To: Zhu Yi
Cc: davem, netdev, Pekka Savola (ipv6), Patrick McHardy,
Vlad Yasevich, Sridhar Samudrala, Jon Maloy, Allan Stephens,
Andrew Hendry, Eric Dumazet
In-Reply-To: <1267761707-15605-1-git-send-email-yi.zhu@intel.com>
Em Fri, Mar 05, 2010 at 12:01:40PM +0800, Zhu Yi escreveu:
> We got system OOM while running some UDP netperf testing on the loopback
> device. The case is multiple senders sent stream UDP packets to a single
> receiver via loopback on local host. Of course, the receiver is not able
> to handle all the packets in time. But we surprisingly found that these
> packets were not discarded due to the receiver's sk->sk_rcvbuf limit.
> Instead, they are kept queuing to sk->sk_backlog and finally ate up all
> the memory. We believe this is a secure hole that a none privileged user
> can crash the system.
>
> The root cause for this problem is, when the receiver is doing
> __release_sock() (i.e. after userspace recv, kernel udp_recvmsg ->
> skb_free_datagram_locked -> release_sock), it moves skbs from backlog to
> sk_receive_queue with the softirq enabled. In the above case, multiple
> busy senders will almost make it an endless loop. The skbs in the
> backlog end up eat all the system memory.
>
> The issue is not only for UDP. Any protocols using socket backlog is
> potentially affected. The patch adds limit for socket backlog so that
> the backlog size cannot be expanded endlessly.
>From visual inspection (no testing):
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
- Arnaldo
^ permalink raw reply
* RE: [PATCH V3 5/8] sctp: use limited socket backlog
From: Eric Dumazet @ 2010-03-05 13:24 UTC (permalink / raw)
To: Zhu, Yi
Cc: davem@davemloft.net, netdev@vger.kernel.org, Vlad Yasevich,
Sridhar Samudrala
In-Reply-To: <DA586906BA1FFC4384FCFD6429ECE860A4604767@shzsmsx502.ccr.corp.intel.com>
Le vendredi 05 mars 2010 à 19:05 +0800, Zhu, Yi a écrit :
> I don't see how the order is important here. We are under sock_lock
> here thus nobody will race with us. IMHO, the comment talks about
> if a packet is queued into the backlog, we need to increase the assoc/ep
> reference count. Otherwise the assoc/ep might be disappeared when
> we are about to process it (by sctp_backlog_rcv) sometime later.
>
OK then.
Its strange this protocol has to increase a refcount for each queued
frame in its backlog, but this is unrelated to your changes anyway.
^ permalink raw reply
* Re: [PATCH] e1000e: fix packet corruption and tx hang during NFSv2
From: Neil Horman @ 2010-03-05 13:18 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, Jesse Brandeburg
In-Reply-To: <20100305122131.8250.21132.stgit@localhost.localdomain>
On Fri, Mar 05, 2010 at 04:21:44AM -0800, Jeff Kirsher wrote:
> From: Jesse Brandeburg <jesse.brandeburg@intel.com>
>
> when receiving a particular type of NFS v2 UDP traffic, the hardware could
> DMA some bad data and then hang, possibly corrupting memory.
>
> Disable the NFS parsing in this hardware, verified to fix the bug.
>
> Originally reported and reproduced by RedHat's Neil Horman
> CC: nhorman@tuxdriver.com
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH V3 4/8] llc: use limited socket backlog
From: Arnaldo Carvalho de Melo @ 2010-03-05 13:00 UTC (permalink / raw)
To: Zhu Yi; +Cc: davem, netdev
In-Reply-To: <1267761707-15605-4-git-send-email-yi.zhu@intel.com>
Em Fri, Mar 05, 2010 at 12:01:43PM +0800, Zhu Yi escreveu:
> Make llc adapt to the limited socket backlog change.
>
> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
^ permalink raw reply
* [PATCH] Fix netdev_printk null dereference
From: Steve Glendinning @ 2010-03-05 12:47 UTC (permalink / raw)
To: netdev
This patch fixes a reproducible null dereference in smsc95xx (and I
suspect others) when the device is removed during a control register
access. This can be reproduced by rapidly plugging and unplugging
the device during its initialisation.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
---
include/linux/netdevice.h | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index c79a88b..250dbc0 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2132,9 +2132,10 @@ static inline const char *netdev_name(const struct net_device *dev)
}
#define netdev_printk(level, netdev, format, args...) \
- dev_printk(level, (netdev)->dev.parent, \
+ ({ if ((netdev)->dev.parent) \
+ dev_printk(level, (netdev)->dev.parent, \
"%s: " format, \
- netdev_name(netdev), ##args)
+ netdev_name(netdev), ##args); })
#define netdev_emerg(dev, format, args...) \
netdev_printk(KERN_EMERG, dev, format, ##args)
--
1.6.6.1
^ permalink raw reply related
* Re: Re:[PATCH kernel 2.6.32-rc5] pcnet_cs: add cis of PreMax PE-200 ethernet pcmcia card
From: Ben Hutchings @ 2010-03-05 12:46 UTC (permalink / raw)
To: Ken Kawasaki; +Cc: netdev, David Woodhouse
In-Reply-To: <20100305210151.b27ce31a.ken_kawasaki@spring.nifty.jp>
[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]
On Fri, 2010-03-05 at 21:01 +0900, Ken Kawasaki wrote:
> Hi,
>
> > The CIS files under firmware/ are, according to firmware/WHENCE,
> > 'developed by the pcmcia-cs project'. So I had a look at what's left of
> > the pcmcia-cs project and its last release, and found that it includes:
> >
> > - the tool 'pack_cis' which compiles a text version of CIS to the
> > standard binary format
> > - text versions of most of the CIS files
> >
> > Since the text versions contain comments which are excluded from the
> > binary format, I believe they should be considered the 'preferred form
> > for modification' and included in the linux-2.6 and linux-firmware trees
> > along with the binaries.
> >
>
> Actually, it is better to build CIS by "pack_cis firmware/cis/src/xxx.cis"
> instead of "IHEX firmware/cis/xxx.cis".
>
> In that case, the "pack_cis" tool should be included in the kernel-tree.
We don't include other firmware-building tools in the tree, even where
they are free software. Why this one?
Ben.
--
Ben Hutchings
Q. Which is the greater problem in the world today, ignorance or apathy?
A. I don't know and I couldn't care less.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* radvd 1.6 released
From: Pekka Savola @ 2010-03-05 12:28 UTC (permalink / raw)
To: netdev, radvd-announce-l
Hello,
A new version of radvd has been released. This contains a couple of
bug fixes and some new functionality. Thanks to everyone who
contributed patches (below).
* Decrease MSG_SIZE from 4096 to about 1500B. Send buffer uses a
smaller size in order to avoid sending out fragmented packets, yet
being able to receive full-size frames.
* Keep track of buffer size and exit if the number of
prefixes/routes/etc. would grow too much. Prevent a memory corruption
due to wrong memset. Patches from Jan Gorig, Red Hat bug #554125.
* On BSD use getifaddrs() also in setup_deviceinfo(), fixes a
multiple interfaces problem on NetBSD 5 due to change in data
structures. Patch from Michael Stapelberg.
* Allow radvd.conf prefix, clients, route, and RDNSS options to be
in any order. Patch from Michael Stapelberg.
Get it at: http://www.litech.org/radvd/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply
* [PATCH] e1000e: fix packet corruption and tx hang during NFSv2
From: Jeff Kirsher @ 2010-03-05 12:21 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, nhorman, Jesse Brandeburg, Jeff Kirsher
From: Jesse Brandeburg <jesse.brandeburg@intel.com>
when receiving a particular type of NFS v2 UDP traffic, the hardware could
DMA some bad data and then hang, possibly corrupting memory.
Disable the NFS parsing in this hardware, verified to fix the bug.
Originally reported and reproduced by RedHat's Neil Horman
CC: nhorman@tuxdriver.com
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000e/defines.h | 2 ++
drivers/net/e1000e/ich8lan.c | 10 ++++++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000e/defines.h b/drivers/net/e1000e/defines.h
index db05ec3..e301e26 100644
--- a/drivers/net/e1000e/defines.h
+++ b/drivers/net/e1000e/defines.h
@@ -320,6 +320,8 @@
#define E1000_RXCSUM_IPPCSE 0x00001000 /* IP payload checksum enable */
/* Header split receive */
+#define E1000_RFCTL_NFSW_DIS 0x00000040
+#define E1000_RFCTL_NFSR_DIS 0x00000080
#define E1000_RFCTL_ACK_DIS 0x00001000
#define E1000_RFCTL_EXTEN 0x00008000
#define E1000_RFCTL_IPV6_EX_DIS 0x00010000
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index 54d03a0..8b5e157 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -2740,6 +2740,16 @@ static void e1000_initialize_hw_bits_ich8lan(struct e1000_hw *hw)
reg &= ~(1 << 31);
ew32(STATUS, reg);
}
+
+ /*
+ * work-around descriptor data corruption issue during nfs v2 udp
+ * traffic, just disable the nfs filtering capability
+ */
+ reg = er32(RFCTL);
+ reg |= (E1000_RFCTL_NFSW_DIS | E1000_RFCTL_NFSR_DIS);
+ ew32(RFCTL, reg);
+
+ return;
}
/**
^ permalink raw reply related
* Re:[PATCH kernel 2.6.32-rc5] pcnet_cs: add cis of PreMax PE-200 ethernet pcmcia card
From: Ken Kawasaki @ 2010-03-05 12:01 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Woodhouse
In-Reply-To: <20100305202153.fb39cd64.ken_kawasaki@spring.nifty.jp>
Hi,
> The CIS files under firmware/ are, according to firmware/WHENCE,
> 'developed by the pcmcia-cs project'. So I had a look at what's left of
> the pcmcia-cs project and its last release, and found that it includes:
>
> - the tool 'pack_cis' which compiles a text version of CIS to the
> standard binary format
> - text versions of most of the CIS files
>
> Since the text versions contain comments which are excluded from the
> binary format, I believe they should be considered the 'preferred form
> for modification' and included in the linux-2.6 and linux-firmware trees
> along with the binaries.
>
Actually, it is better to build CIS by "pack_cis firmware/cis/src/xxx.cis"
instead of "IHEX firmware/cis/xxx.cis".
In that case, the "pack_cis" tool should be included in the kernel-tree.
Ken.
^ permalink raw reply
* Re: [PATCH kernel 2.6.32-rc5] pcnet_cs: add cis of PreMax PE-200 ethernet pcmcia card
From: Ken Kawasaki @ 2010-03-05 11:21 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Woodhouse
In-Reply-To: <1267747341.2819.177.camel@localhost>
Hi,
> The CIS files under firmware/ are, according to firmware/WHENCE,
> 'developed by the pcmcia-cs project'. So I had a look at what's left of
> the pcmcia-cs project and its last release, and found that it includes:
>
> - the tool 'pack_cis' which compiles a text version of CIS to the
> standard binary format
> - text versions of most of the CIS files
>
> Since the text versions contain comments which are excluded from the
> binary format, I believe they should be considered the 'preferred form
> for modification' and included in the linux-2.6 and linux-firmware trees
> along with the binaries.
>
Actually, it is better to build CIS by "pack_cis /lib/firmware/cis/src/xxx.cis"
instead of "IHEX /lib/firmware/cis/xxx.cis".
In that case, the "pack_cis" tool should be included in the kernel-tree.
Ken.
^ permalink raw reply
* RE: [PATCH V3 5/8] sctp: use limited socket backlog
From: Zhu, Yi @ 2010-03-05 11:05 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem@davemloft.net, netdev@vger.kernel.org, Vlad Yasevich,
Sridhar Samudrala
In-Reply-To: <1267770483.2867.6.camel@edumazet-laptop>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> As advertized by comment, we should hold the association *before*
> accessing backlog queue.
> If order is not important, comment should be relaxed somehow ?
I don't see how the order is important here. We are under sock_lock
here thus nobody will race with us. IMHO, the comment talks about
if a packet is queued into the backlog, we need to increase the assoc/ep
reference count. Otherwise the assoc/ep might be disappeared when
we are about to process it (by sctp_backlog_rcv) sometime later.
Thanks,
-yi
^ permalink raw reply
* Re: KS8695: possible NAPI issue
From: Yegor Yefremov @ 2010-03-05 10:06 UTC (permalink / raw)
To: figo zhang; +Cc: Dick Hollenbeck, netdev, zealcook
In-Reply-To: <c6ed1ac51003042254g27f65f9dhd9bd731e05a9518@mail.gmail.com>
On Fri, Mar 5, 2010 at 7:54 AM, figo zhang <figo1802@gmail.com> wrote:
> 2010/3/4 Yegor Yefremov <yegorslists@googlemail.com>:
>>>>> I'm using 2.6.33 kernel and I noticed such a strange behavior:
>>>>>
>>>>> after system start I transfer one file via netcat from my development
>>>>> host, after this transfer the network is not functioning i.e. no pings
>>>>> possible etc.
>>>>>
>>>>> To narrow down the problem I checked out this commit
>>>>>
>>>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=451f14439847db302e5104c44458b2dbb4b1829d.
>>>>> Till here the network driver is functioning as intended, but after
>>>>> NAPI introduction I have this issue. With latest git-pull of "Linus'
>>>>> kernel tree" I can't even ping right after the systems start.
>>>>>
>>>>> Any Ideas? What am I missing?
>>>>>
>>>>
>>>> No idea, although I am using the same ARM chip, my kernel is at 2.6.30.5,
>>>> and except for this occasional loss of connection I get, the ethernet driver
>>>> seems to work better than what you are reporting.
>>>
>>> from linux-2.6.32, this ethernet driver have add NAPI support, would
>>> you like to
>>> try using this version?
>>
>> Figo, I just looked at the 2.6.32 kernel and found out that it
>> doesn't' contain NAPI support (see the history
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=history;f=drivers/net/arm/ks8695net.c;h=2a7b7745cc55b54cefada690b0ea47865b54b6b9;hb=HEAD).
>> So 2.6.33 is the first stable kernel to support NAPI.
>>
>> I made some further tests but I can't find the reason for network
>> failures: the interrupts are coming and the packets will be received
>> and sent so that rx/tx counters would be increased, but none of them
>> seem to reach the IP stack. I don't know where and why the things get
>> desynchronized.
>>
>> Could you try the 2.6.33 or Linus tree? Thank you in advance.
>
> yes, i have test it on linux-2.6.33, it is work well.
Thanks for testing. What kind of tests have you made? And with what data amount?
My tests look like following:
1. system start
2. ping one host: O.K.
3. nc -l -p 5000 > /var/test (about 1Mb): O.K.
4. ping the same host: failed
and even if the fourth test succeeds, if I then send a file from other
host the next ping or any other communication fails. I just tried to
make some SSH sessions. It goes without a problem till I issue a ping
after that.
If I test the system with nuttcp I have no problem.
Do you have any idea how to debug this? If I remove the NAPI support I
have no problem with the same kernel and environment. I'd really like
to get the whole stuff working.
Regards,
Yegor
^ 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