* Re: Does Realtek RTL8110S and RTL8100C work ?
From: Markus Feldmann @ 2010-03-26 17:20 UTC (permalink / raw)
To: netdev
In-Reply-To: <4BABC170.7080008@computer.org>
Thanks for you answer Jan,
do you know the developer e-mail adress?
So 1000Mbit/s is not possible at the moment, but does it work stable?
regards Markus
^ permalink raw reply
* Re: [PATCH] net: ipmr/ip6mr: prevent out-of-bounds vif_table access
From: Nicolas Dichtel @ 2010-03-26 17:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100326.095137.165317348.davem@davemloft.net>
yes, but I think that it is not enough, ip[6]mr_mfc_add() is only called via
setsockopt().
When a multicast packet arrived in ip6_mr_input(), if there is no cache
ip6mr_cache_unresolved() will be called and this function will add an entry with
parent == 65535.
And the second problem is that when a vif is removed, no cleanup is made in
cache entry. Hence, we can have a cache entry which points to an invalid vif
(dev is set ot NULL).
Regards,
Nicolas
Le 26.03.2010 17:51, David Miller a écrit :
> From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
> Date: Fri, 26 Mar 2010 10:45:35 +0100
>
>> please consider the attached patch about IPv4 and IPv6 multicast.
>
> Already fixed by Patrick McHardy recently:
>
> commit a50436f2cd6e85794f7e1aad795ca8302177b896
> Author: Patrick McHardy <kaber@trash.net>
> Date: Wed Mar 17 06:04:14 2010 +0000
>
> net: ipmr/ip6mr: fix potential out-of-bounds vif_table access
>
> mfc_parent of cache entries is used to index into the vif_table and is
> initialised from mfcctl->mfcc_parent. This can take values of to 2^16-1,
> while the vif_table has only MAXVIFS (32) entries. The same problem
> affects ip6mr.
>
> Refuse invalid values to fix a potential out-of-bounds access. Unlike
> the other validity checks, this is checked in ipmr_mfc_add() instead of
> the setsockopt handler since its unused in the delete path and might be
> uninitialized.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index 8582e12..0b9d03c 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -802,6 +802,9 @@ static int ipmr_mfc_add(struct net *net, struct mfcctl *mfc, int mrtsock)
> int line;
> struct mfc_cache *uc, *c, **cp;
>
> + if (mfc->mfcc_parent >= MAXVIFS)
> + return -ENFILE;
> +
> line = MFC_HASH(mfc->mfcc_mcastgrp.s_addr, mfc->mfcc_origin.s_addr);
>
> for (cp = &net->ipv4.mfc_cache_array[line];
> diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
> index 52e0f74..23e4ac0 100644
> --- a/net/ipv6/ip6mr.c
> +++ b/net/ipv6/ip6mr.c
> @@ -1113,6 +1113,9 @@ static int ip6mr_mfc_add(struct net *net, struct mf6cctl *mfc, int mrtsock)
> unsigned char ttls[MAXMIFS];
> int i;
>
> + if (mfc->mf6cc_parent >= MAXMIFS)
> + return -ENFILE;
> +
> memset(ttls, 255, MAXMIFS);
> for (i = 0; i < MAXMIFS; i++) {
> if (IF_ISSET(i, &mfc->mf6cc_ifset))
^ permalink raw reply
* Re: [PATCH] benet: Fix compile warnnings in drivers/net/benet/be_ethtool.c
From: Ajit Khaparde @ 2010-03-26 17:16 UTC (permalink / raw)
To: wzt.wzt; +Cc: linux-kernel, netdev, linux-drivers, sathyap
In-Reply-To: <20100326061259.GB30341@localhost.localdomain>
On 26/03/10 14:12 +0800, wzt.wzt@gmail.com wrote:
> Fix the following warnings:
>
> be_ethtool.c:493: warning: integer constant is too large for 'long' type
> be_ethtool.c:493: warning: integer constant is too large for 'long' type
>
> Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com>
I would suggest using be2net instead of benet during the commit.
be2net: Fix compile warnnings in drivers/net/benet/be_ethtool.c
Acked-by: Ajit Khaparde <ajitk@serverengines.com>
^ permalink raw reply
* [PATCH] net: fix netlink address dumping in IPv4/IPv6
From: Patrick McHardy @ 2010-03-26 17:13 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-net-fix-netlink-address-dumping-in-IPv4-IPv6.patch --]
[-- Type: application/mbox, Size: 1420 bytes --]
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: David Miller @ 2010-03-26 17:04 UTC (permalink / raw)
To: richih.mailinglist; +Cc: alan, linux-kernel, netdev, linux-ppp
In-Reply-To: <20100326.095929.04683456.davem@davemloft.net>
BTW, it seems your email client very thoroughly corrupted your
original patch submission.
This is a common problem with gmail, please read:
linux/Documentation/email-clients.txt
so that you can learn how to adjust your email client settings such
that your outgoing patches are usable by us.
Thanks.
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: James Carlson @ 2010-03-26 17:04 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Alan Cox, linux-kernel, netdev, linux-ppp
In-Reply-To: <v2v2d460de71003260939w4877df7em9e3084a315b0962f@mail.gmail.com>
Richard Hartmann wrote:
> Also, I am not sure if it would not be better to default to no
> fragmentation and enable it optionally. I am aware that changing default
> behaviour is always a bit of a problem but to the best of my knowledge
> enabling fragmentation is a bug in any and all real-world applications.
It worked well and was enabled by default on all the Bay Networks
equipment I used ~15 years ago. And I know for certain that we tested
with other gear (Ascend and Clam, probably) that did it right.
If it works with the equipment you're using, it's a useful feature in
that it can balance out the latencies among the links, resulting in much
lower overall latency observed by higher layers -- especially so on
lower-speed links where MP is more likely to be used. Without it,
you're left either waiting for the one slow link choking on a big packet
to catch up, or (worse) disabling the sequence headers altogether,
resulting in reordering unless you're really "clever."
It's a darned shame that lame implementations would force a change in
the default ...
--
James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Alan Cox @ 2010-03-26 17:04 UTC (permalink / raw)
To: Alexander E. Patrakov; +Cc: Richard Hartmann, linux-kernel, netdev, linux-ppp
In-Reply-To: <4BACE827.4070006@gmail.com>
On Fri, 26 Mar 2010 22:00:23 +0500
"Alexander E. Patrakov" <patrakov@gmail.com> wrote:
> 26.03.2010 21:02, Alan Cox wrote:
>
> > You can then do this
> >
> > static int ml_explode = 1;
> > module_param(ml_explode, int, 0600);
> > MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
> > fragmentation when talking to cisco devices");
> >
> > which will let you load the module with the option ml_explode = 0 if you
> > want that property.
> >
> > Making it runtime per link selectable would be nicer but thats a bit more
> > work.
>
> Doesn't it work already via echoing values to
> /sys/module/ppp/generic/parameters/ml_explode in the above code?
Thats runtime (and why I set 0600 in the permissions for the example) but
not per link.
Alan
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: David Miller @ 2010-03-26 16:59 UTC (permalink / raw)
To: richih.mailinglist; +Cc: alan, linux-kernel, netdev, linux-ppp
In-Reply-To: <v2v2d460de71003260939w4877df7em9e3084a315b0962f@mail.gmail.com>
From: Richard Hartmann <richih.mailinglist@gmail.com>
Date: Fri, 26 Mar 2010 17:39:27 +0100
> At least the last-level support of Telefonica and QSC was definite
> and adamant about not enabling fragmentation on _any_ PPP
> multi-link, ever.
I'm sure we can find just as many counter examples.
I doubt we'll ever be able to change the default here,
sorry.
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Alexander E. Patrakov @ 2010-03-26 17:00 UTC (permalink / raw)
To: Alan Cox; +Cc: Richard Hartmann, linux-kernel, netdev, linux-ppp
In-Reply-To: <20100326160226.0159ac3b@lxorguk.ukuu.org.uk>
26.03.2010 21:02, Alan Cox wrote:
> You can then do this
>
> static int ml_explode = 1;
> module_param(ml_explode, int, 0600);
> MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
> fragmentation when talking to cisco devices");
>
> which will let you load the module with the option ml_explode = 0 if you
> want that property.
>
> Making it runtime per link selectable would be nicer but thats a bit more
> work.
Doesn't it work already via echoing values to
/sys/module/ppp/generic/parameters/ml_explode in the above code?
--
Alexander E. Patrakov
^ permalink raw reply
* Re: [PATCH] net: ipmr/ip6mr: prevent out-of-bounds vif_table access
From: David Miller @ 2010-03-26 16:51 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <4BAC823F.8050409@dev.6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@dev.6wind.com>
Date: Fri, 26 Mar 2010 10:45:35 +0100
> please consider the attached patch about IPv4 and IPv6 multicast.
Already fixed by Patrick McHardy recently:
commit a50436f2cd6e85794f7e1aad795ca8302177b896
Author: Patrick McHardy <kaber@trash.net>
Date: Wed Mar 17 06:04:14 2010 +0000
net: ipmr/ip6mr: fix potential out-of-bounds vif_table access
mfc_parent of cache entries is used to index into the vif_table and is
initialised from mfcctl->mfcc_parent. This can take values of to 2^16-1,
while the vif_table has only MAXVIFS (32) entries. The same problem
affects ip6mr.
Refuse invalid values to fix a potential out-of-bounds access. Unlike
the other validity checks, this is checked in ipmr_mfc_add() instead of
the setsockopt handler since its unused in the delete path and might be
uninitialized.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 8582e12..0b9d03c 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -802,6 +802,9 @@ static int ipmr_mfc_add(struct net *net, struct mfcctl *mfc, int mrtsock)
int line;
struct mfc_cache *uc, *c, **cp;
+ if (mfc->mfcc_parent >= MAXVIFS)
+ return -ENFILE;
+
line = MFC_HASH(mfc->mfcc_mcastgrp.s_addr, mfc->mfcc_origin.s_addr);
for (cp = &net->ipv4.mfc_cache_array[line];
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 52e0f74..23e4ac0 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1113,6 +1113,9 @@ static int ip6mr_mfc_add(struct net *net, struct mf6cctl *mfc, int mrtsock)
unsigned char ttls[MAXMIFS];
int i;
+ if (mfc->mf6cc_parent >= MAXMIFS)
+ return -ENFILE;
+
memset(ttls, 255, MAXMIFS);
for (i = 0; i < MAXMIFS; i++) {
if (IF_ISSET(i, &mfc->mf6cc_ifset))
^ permalink raw reply related
* Re: Problem with talking to the kernel and iproute2/ifconfig
From: David Miller @ 2010-03-26 16:42 UTC (permalink / raw)
To: pstaszewski; +Cc: kaber, netdev
In-Reply-To: <4BABA2C9.3090805@itcare.pl>
From: Paweł Staszewski <pstaszewski@itcare.pl>
Date: Thu, 25 Mar 2010 18:52:09 +0100
> This patch resolve this problem and all is working now correctly.
Patrick, since this is now tested to work, please make a formal
submission of this fix if you haven't already.
Thanks!
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Richard Hartmann @ 2010-03-26 16:39 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, netdev, linux-ppp
In-Reply-To: <20100326160226.0159ac3b@lxorguk.ukuu.org.uk>
On Fri, Mar 26, 2010 at 17:02, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> You should be able to manage that I'm sure:
Hopefully. We will see :)
> MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
> fragmentation when talking to cisco devices");
To be exact, this is not a Linux vs. Cisco issue, but a Linux vs. world
issue.
At least the last-level support of Telefonica and QSC was definite and
adamant about not enabling fragmentation on _any_ PPP multi-link, ever.
Also, I am not sure if it would not be better to default to no
fragmentation and enable it optionally. I am aware that changing default
behaviour is always a bit of a problem but to the best of my knowledge
enabling fragmentation is a bug in any and all real-world applications.
Richard
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Joe Perches @ 2010-03-26 16:33 UTC (permalink / raw)
To: Alan Cox; +Cc: Richard Hartmann, linux-kernel, netdev, linux-ppp
In-Reply-To: <20100326160226.0159ac3b@lxorguk.ukuu.org.uk>
On Fri, 2010-03-26 at 16:02 +0000, Alan Cox wrote:
> > We are fully aware that this code is not nearly up for inclusion into
> > the kernel. What we hope to achieve is that someone with the skills to
> > do this properly will introduce an option to turn off fragmentation on
> > PPP multi-link or to just do away with it completely.
>
> You should be able to manage that I'm sure:
[]
> MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
> fragmentation when talking to cisco devices");
trivial:
It's better to use something like:
MODULE_PARM_DESC(ml_expode, "Set this to zero to disable multilink "
"fragmentation when talking to cisco devices");
so odd spacing from the continuation line aren't
used in the description.
^ permalink raw reply
* Re: [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Alan Cox @ 2010-03-26 16:02 UTC (permalink / raw)
To: Richard Hartmann; +Cc: linux-kernel, netdev, linux-ppp
In-Reply-To: <2d460de71003260850x7f90d04cy79ac853464108182@mail.gmail.com>
> We are fully aware that this code is not nearly up for inclusion into
> the kernel. What we hope to achieve is that someone with the skills to
> do this properly will introduce an option to turn off fragmentation on
> PPP multi-link or to just do away with it completely.
You should be able to manage that I'm sure:
The main thing will be to take this chunk, strip out the // stuff and
then make it a function of its own so you've got clean code in the main
path of the form
#ifdef CONFIG_PPP_MULTILINK
if (ml_explode) {
if (!ppp_mp_explode(...)
..
} else {
ppp_mp_roundrobin(...)
}
and your bits as a new routine. You can then do this
static int ml_explode = 1;
module_param(ml_explode, int, 0600);
MODULE_PARM_DESC(ml_expode, "Set this to zero to disabling multilink \
fragmentation when talking to cisco devices");
which will let you load the module with the option ml_explode = 0 if you
want that property.
Making it runtime per link selectable would be nicer but thats a bit more
work.
Alan
^ permalink raw reply
* [Patch] fix packet loss and massive ping spikes with PPP multi-link
From: Richard Hartmann @ 2010-03-26 15:50 UTC (permalink / raw)
To: linux-kernel, netdev, linux-ppp
Hi all,
as you may be aware, it is recommended to switch of fragmentation when
doing PPP multi-link. Problems which will be seen if you don't do that
involve packet loss and massive spikes in the round-trip times.
An increase of 1.5 seconds(!) is what we usually see.
Every Cisco CPE offers to switch off fragmentation for multi-link, other
manufacturers are likely to offer it, as well.
We implemented a really ugly hack which allows us to do the same with
the Linux kernel. I can confirm that it gets rid of the problem 100%
of the time.
We are fully aware that this code is not nearly up for inclusion into
the kernel. What we hope to achieve is that someone with the skills to
do this properly will introduce an option to turn off fragmentation on
PPP multi-link or to just do away with it completely.
Some stats for a run of 4 hours each:
No patch:
129 lost fragments, 575803 reordered
127/3960 discarded fragments/bytes, 0 lost received
Patch:
0 lost fragments, 0 reordered
0/0 discarded fragments/bytes, 0 lost received
Unfortunately, I don't have paste-able stats for ping times available,
at the moment.
Any and all feedback on this is appreciated,
Richard
PS: Our image which is deployed in the field is using 2.6.32 which is
why we were forced to develop for and test with 2.6.32 instead of
linux-next; sorry for that.
--- /usr/src/linux-2.6.32.3/drivers/net/ppp_generic.c.orig 2010-03-25
16:56:05.000000000 +0100
+++ /usr/src/linux-2.6.32.3/drivers/net/ppp_generic.c 2010-03-26
14:42:42.000000000 +0100
@@ -123,6 +123,7 @@
struct net_device *dev; /* network interface device a4 */
int closing; /* is device closing down? a8 */
#ifdef CONFIG_PPP_MULTILINK
+ int rrsched; /* round robin scheduler for packet distribution */
int nxchan; /* next channel to send something on */
u32 nxseq; /* next sequence number to send */
int mrru; /* MP: max reconst. receive unit */
@@ -1261,6 +1262,7 @@
struct list_head *list;
struct channel *pch;
struct sk_buff *skb = ppp->xmit_pending;
+ int i;
if (!skb)
return;
@@ -1292,10 +1294,40 @@
}
#ifdef CONFIG_PPP_MULTILINK
- /* Multilink: fragment the packet over as many links
- as can take the packet at the moment. */
- if (!ppp_mp_explode(ppp, skb))
- return;
+ ppp->rrsched++;
+// printk(KERN_ERR "ppp: multi new packet, rrsched = %d\n", ppp->rrsched);
+
+ i = 0;
+ list_for_each_entry(pch, &ppp->channels, clist) {
+// printk(KERN_ERR "ppp: channel %d ... \n", i);
+ if(pch->chan == NULL) continue;
+
+ if (ppp->rrsched % ppp->n_channels == i) {
+// printk(KERN_ERR "use channel %d\n", i);
+ spin_lock_bh(&pch->downl);
+ if (pch->chan) {
+// ++ppp->nxseq;
+ if (pch->chan->ops->start_xmit(pch->chan, skb)) {
+ ppp->xmit_pending = NULL;
+ }
+ } else {
+ /* channel got unregistered */
+ kfree_skb(skb);
+ ppp->xmit_pending = NULL;
+ }
+ spin_unlock_bh(&pch->downl);
+ return;
+ }
+ i++;
+ }
+// printk(KERN_ERR "keep in queue\n");
+ return;
+
+
+// /* Multilink: fragment the packet over as many links
+// as can take the packet at the moment. */
+// if (!ppp_mp_explode(ppp, skb))
+// return;
#endif /* CONFIG_PPP_MULTILINK */
ppp->xmit_pending = NULL;
^ permalink raw reply
* Re: [alsa-devel] [PATCH 13/27] drivers/net/of: don't use deprecated field in of_platform_driver
From: Timur Tabi @ 2010-03-26 15:23 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, netdev
In-Reply-To: <20100311182259.13103.87535.stgit@angua>
I'm seeing this error with this patch applied, when building for an mpc8641_hpcn
CC drivers/net/gianfar.o
drivers/net/gianfar.c: In function 'gfar_of_init':
drivers/net/gianfar.c:606: error: 'struct platform_device' has no
member named 'node'
drivers/net/gianfar.c:644: error: 'struct platform_device' has no
member named 'node'
drivers/net/gianfar.c: In function 'gfar_probe':
drivers/net/gianfar.c:891: error: 'struct platform_device' has no
member named 'node'
make[2]: *** [drivers/net/gianfar.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
On Thu, Mar 11, 2010 at 1:23 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> .name, .match_table and .owner are duplicated in both of_platform_driver
> and device_driver, so the of_platform_driver copies will be removed soon.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> drivers/net/can/mscan/mpc5xxx_can.c | 8 +++++---
> drivers/net/can/sja1000/sja1000_of_platform.c | 8 +++++---
> drivers/net/ehea/ehea_main.c | 7 +++++--
> drivers/net/fs_enet/fs_enet-main.c | 7 +++++--
> drivers/net/fs_enet/mii-bitbang.c | 7 +++++--
> drivers/net/fs_enet/mii-fec.c | 7 +++++--
> drivers/net/fsl_pq_mdio.c | 7 +++++--
> drivers/net/gianfar.c | 10 ++++++----
> drivers/net/ibm_newemac/core.c | 8 +++++---
> drivers/net/ibm_newemac/mal.c | 8 +++++---
> drivers/net/ibm_newemac/rgmii.c | 8 +++++---
> drivers/net/ibm_newemac/tah.c | 8 +++++---
> drivers/net/ibm_newemac/zmii.c | 8 +++++---
> drivers/net/ll_temac_main.c | 2 +-
> drivers/net/myri_sbus.c | 7 +++++--
> drivers/net/niu.c | 7 +++++--
> drivers/net/phy/mdio-gpio.c | 7 +++++--
> drivers/net/sunbmac.c | 7 +++++--
> drivers/net/sunhme.c | 7 +++++--
> drivers/net/sunlance.c | 7 +++++--
> drivers/net/sunqe.c | 7 +++++--
> drivers/net/ucc_geth.c | 7 +++++--
> drivers/net/xilinx_emaclite.c | 7 +++++--
> 23 files changed, 112 insertions(+), 54 deletions(-)
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] netdev/fec.c: add phylib supporting to enable carrier detection
From: Wolfram Sang @ 2010-03-26 14:47 UTC (permalink / raw)
To: Bryan Wu
Cc: s.hauer, gerg, amit.kucheria, netdev, kernel-team, linux-kernel,
linux-arm-kernel
In-Reply-To: <1269597052-10104-1-git-send-email-bryan.wu@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 689 bytes --]
On Fri, Mar 26, 2010 at 05:50:52PM +0800, Bryan Wu wrote:
> BugLink: http://bugs.launchpad.net/bugs/457878
>
> - removed old MII phy control code
> - add phylib supporting
> - add ethtool interface to make user space NetworkManager works
>
> Tested on Freescale i.MX51 Babbage board.
>
> This patch is based on a patch from Frederic Rodo <fred.rodo@gmail.com>
>
> Cc: Frederic Rodo <fred.rodo@gmail.com>
> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
Great, will test it soon.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: IPv6 neighbor advertisements
From: Haile Seifu @ 2010-03-26 14:40 UTC (permalink / raw)
To: netdev; +Cc: David Miller
In-Reply-To: <20100325.230733.214002385.davem@davemloft.net>
Hi,
Yes, but the neighbor entry can be checked for the protocol type and
then the confirmed/updated field can be reset if the else condition is
taken.
On Fri, Mar 26, 2010 at 2:07 AM, David Miller <davem@davemloft.net> wrote:
>
> Keep in mind that net/core/neighbour.c is for IPV4 ARP too.
>
> So if there is a conflict between what is allowed by ipv4
> and what is allowed by ipv6 in this scenerio, that would
> explain it.
>
^ permalink raw reply
* Re: WARNING: at net/sched/sch_generic.c:261 dev_watchdog+0x249/0x260()
From: Eric Dumazet @ 2010-03-26 14:34 UTC (permalink / raw)
To: Lee; +Cc: netdev
In-Reply-To: <4BACC1FD.3000609@web.de>
Le vendredi 26 mars 2010 à 15:17 +0100, Lee a écrit :
> Hi again,
>
> As this mail went unanswered, did I forget anything? Was it too verbose?
> Should I file a bug report on bugzilla.kernel.org instead?
>
> Regards,
> Lee
>
Well, many problems with rtl8169, unfortunatly.
You could try Francois patch :
http://www.spinics.net/lists/netdev/msg124131.html
> On 22/03/10 21:52, Lee wrote:
> > Hi everyone,
> >
> > I get a kernel oops on 2.6.32.10 when I use an rt73usb WLAN stick with
> > hostapd 0.6.10. It's bridged with one of my ethernet (r8169) interfaces.
> > When I have the stick plugged in without hostapd, the kernel oops
> > doesn't happen. It's not easily triggered, it usually happens within a
> > few hours of use with hostapd. I have about a dozen of those from while
> > tracking this bug down, if needed.
> >
> > Everything seems to work fine (before and after the oops), but at least
> > on one occasion I had a large delay on my ssh line when the oops happened.
> >
> > I have no idea what is causing this, but will happily test any patches
> > that are handed in my direction :)
> >
> > Kernel oops, .config and hostapd.conf are attached. Please tell me if
> > anything else is needed to hunt down this bug.
> >
> > Regards,
> > Lee
>
^ permalink raw reply
* Re: behavior of recvmmsg() on blocking sockets
From: Eric Dumazet @ 2010-03-26 14:20 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: Brandon Black, netdev, linux-kernel
In-Reply-To: <a36005b51003260500v6d8b7a5av1bbba848cc8998a4@mail.gmail.com>
Le vendredi 26 mars 2010 à 05:00 -0700, Ulrich Drepper a écrit :
> On Wed, Mar 24, 2010 at 16:35, Brandon Black <blblack@gmail.com> wrote:
> > + /* MSG_WAITFORONE turns on MSG_DONTWAIT after one packet */
> > + if (!datagrams++ && flags & MSG_WAITFORONE)
> > + flags |= MSG_DONTWAIT;
>
> There should be an extra pair of parenthesis around the & operands but
> aside from that I could imagine this to work.
>
> Would be nice if the netdev folks would respond.
It seems fine, Brandon please submit a formal patch.
Thanks
^ permalink raw reply
* Re: WARNING: at net/sched/sch_generic.c:261 dev_watchdog+0x249/0x260()
From: Lee @ 2010-03-26 14:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <4BA7D897.9050407@web.de>
Hi again,
As this mail went unanswered, did I forget anything? Was it too verbose?
Should I file a bug report on bugzilla.kernel.org instead?
Regards,
Lee
On 22/03/10 21:52, Lee wrote:
> Hi everyone,
>
> I get a kernel oops on 2.6.32.10 when I use an rt73usb WLAN stick with
> hostapd 0.6.10. It's bridged with one of my ethernet (r8169) interfaces.
> When I have the stick plugged in without hostapd, the kernel oops
> doesn't happen. It's not easily triggered, it usually happens within a
> few hours of use with hostapd. I have about a dozen of those from while
> tracking this bug down, if needed.
>
> Everything seems to work fine (before and after the oops), but at least
> on one occasion I had a large delay on my ssh line when the oops happened.
>
> I have no idea what is causing this, but will happily test any patches
> that are handed in my direction :)
>
> Kernel oops, .config and hostapd.conf are attached. Please tell me if
> anything else is needed to hunt down this bug.
>
> Regards,
> Lee
^ permalink raw reply
* [iproute2] a 'ip rule ...' bug?
From: thomas yang @ 2010-03-26 12:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
in /etc/iproute2/rt_dsfield
...
# Newer RFC2597 values
0x28 AF11
0x30 AF12
0x38 AF13
...
---in ip man page ---
ip rule add - insert a new rule
tos TOS
dsfield TOS
select the TOS value to match.
---
[root@localhost ~]# ip rule add dsfield 0x28 table 200
Error: argument "dsfield" is wrong: Failed to parse rule type
why???
how to match 'dsfield' ?
[root@localhost ~]# ip rule add tos 0x28 table 200
RTNETLINK answers: Invalid argument
(My OS is Fedora 11 : kernel-2.6.30.10-105.2.23.fc11.i586 ,
iproute-2.6.29-2.fc11.i586 ;
on my another linux box ( Fedora 7) 'ip rule' also has the same
problem to match tos and dsfield. )
--
Tom
^ permalink raw reply
* Re: behavior of recvmmsg() on blocking sockets
From: Ulrich Drepper @ 2010-03-26 12:00 UTC (permalink / raw)
To: Brandon Black; +Cc: netdev, linux-kernel
In-Reply-To: <84621a61003241635h65687366t6b28148281d529c9@mail.gmail.com>
On Wed, Mar 24, 2010 at 16:35, Brandon Black <blblack@gmail.com> wrote:
> + /* MSG_WAITFORONE turns on MSG_DONTWAIT after one packet */
> + if (!datagrams++ && flags & MSG_WAITFORONE)
> + flags |= MSG_DONTWAIT;
There should be an extra pair of parenthesis around the & operands but
aside from that I could imagine this to work.
Would be nice if the netdev folks would respond.
^ permalink raw reply
* RE: [PATCHv1 3/4] netxen: added sanity check for pci map
From: Amit Salecha @ 2010-03-26 10:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Ameen Rahman
In-Reply-To: <20100325.120446.98057142.davem@davemloft.net>
David,
Sorry for inconvenience caused. I'll take care in future work.
I have submitted reworked patches.
-Amit
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: Friday, March 26, 2010 12:35 AM
To: Amit Salecha
Cc: netdev@vger.kernel.org; Ameen Rahman
Subject: Re: [PATCHv1 3/4] netxen: added sanity check for pci map
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Thu, 25 Mar 2010 00:06:45 -0700
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
>
> Return value of ioremap is not checked, NULL check added.
You're not even thinking when you make these changes.
Let's try again ok?
These ioremap() calls store the pointers into local variables.
So it doesn't work at all to just jump to err_out to clean
them up and iounmap them.
The unamp code you end up calling in netxen_pci_map() only does an
iounmap() on pointers stored in the netxen_adapter struct. At this
point they haven't been stored there yet.
So they still leak.
Can you tell my patience on this patch set is very much running
out? If you put half of the effort writing these patches as I
am putting into reviewing them, we wouldn't have to go back
and forth on this so many times.
Double check your work, and resubmit this whole patch set once you've
fixed this one, I think the other ones look fine.
Thanks.
^ permalink raw reply
* [PATCHv2 1/4] netxen: fix bios version calculation
From: Amit Kumar Salecha @ 2010-03-26 10:30 UTC (permalink / raw)
To: davem; +Cc: netdev, ameen.rahman
In-Reply-To: <1269599410-17809-1-git-send-email-amit.salecha@qlogic.com>
Bios sub version from unified fw image is calculated incorrect.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
---
drivers/net/netxen/netxen_nic_init.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_init.c b/drivers/net/netxen/netxen_nic_init.c
index 1c63610..7eb925a 100644
--- a/drivers/net/netxen/netxen_nic_init.c
+++ b/drivers/net/netxen/netxen_nic_init.c
@@ -761,7 +761,7 @@ nx_get_bios_version(struct netxen_adapter *adapter)
if (adapter->fw_type == NX_UNIFIED_ROMIMAGE) {
bios_ver = cpu_to_le32(*((u32 *) (&fw->data[prd_off])
+ NX_UNI_BIOS_VERSION_OFF));
- return (bios_ver << 24) + ((bios_ver >> 8) & 0xff00) +
+ return (bios_ver << 16) + ((bios_ver >> 8) & 0xff00) +
(bios_ver >> 24);
} else
return cpu_to_le32(*(u32 *)&fw->data[NX_BIOS_VERSION_OFFSET]);
--
1.6.0.2
^ permalink raw reply related
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