* Re: [PATCH 2.6.24-rc] [IPV6] NDISC: Fix setting base_reachable_time_ms variable.
From: David Miller @ 2007-10-29 8:33 UTC (permalink / raw)
To: yoshfuji; +Cc: netdev, usagi-core
In-Reply-To: <20071029.114954.02253064.yoshfuji@linux-ipv6.org>
From: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Date: Mon, 29 Oct 2007 11:49:54 +0900 (JST)
> This bug was introduced by the commit
> d12af679bcf8995a237560bdf7a4d734f8df5dbb.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Patch applied, thank you!
^ permalink raw reply
* Re: IPVS: use proper timeout instead of fixed value
From: David Miller @ 2007-10-29 8:35 UTC (permalink / raw)
To: horms; +Cc: netdev, lvs-devel, wensong, ja, jmack, graeme, lvs, andy
In-Reply-To: <20071029070555.78D694FA13@tabatha.lab.ultramonkey.org>
From: Simon Horman <horms@verge.net.au>
Date: Mon, 29 Oct 2007 16:05:55 +0900 (JST)
> From: Andy Gospodarek <andy@greyhouse.net>
>
> Instead of using the default timeout of 3 minutes, this uses the timeout
> specific to the protocol used for the connection. The 3 minute timeout
> seems somewhat arbitrary (though I know it is used other places in the
> ipvs code) and when failing over it would be much nicer to use one of
> the configured timeout values.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Acked-by: Simon Horman <horms@verge.net.au>
I would apply this but it does not apply to current 2.6.x,
please resubmit.
Thanks.
^ permalink raw reply
* Re: Oops in 2.6.21-rc4, 2.6.23
From: Jarek Poplawski @ 2007-10-29 8:42 UTC (permalink / raw)
To: Darko K.; +Cc: netdev
In-Reply-To: <20071015173956.6c554387@beavis.confused.org>
On 15-10-2007 17:39, Darko K. wrote:
> Hello,
>
> after recent upgrade to kernel 2.6.23 (from 2.6.20) I have started
> seeing kernel oops-es in networking code. The problem is 100%
> reproducible in my environment. I've seen two slightly different
> backtraces but both seem to be caused by the same commit. Please
> put me on Cc: on replies.
>
> I've performed the git bisect and tracked down the problem to the
> commit:
>
> 53cdcc04c1e85d4e423b2822b66149b6f2e52c2c [TCP]: Fix tcp_mem[]
> initialization
>
> Once I reverse this commit in 2.6.23 the problem goes away (this
> is true also for the kernel version generated by git bisect,
> 2.6.21-rc4).
>
> Description of my machine: Athlon XP1700, VIA KT-333 chipset, 512MB
> RAM, VIA rhine on-board NIC. The problem appears when approximately
> 70% of RAM is in use and I start a large file transfer (via FTP)
> from another machine on the LAN. Sample output from free command:
> total used free shared buffers cached
> Mem: 516508 510600 5908 0 1004 154084
> -/+ buffers/cache: 355512 160996
> Swap: 899600 25240 874360
>
> Backtrace #1:
> page allocation failure. order:1, mode:0x20
> [<c0131581>] __alloc_pages+0x2e1/0x300
> [<c0144bee>] cache_alloc_refill+0x29e/0x4b0
> [<c0144e6e>] __kmalloc+0x6e/0x80
> [<c0227103>] __alloc_skb+0x53/0x110
> [<c024de5c>] tcp_collapse+0x1ac/0x370
Hi,
I hope you've found this by yourself by now, but:
1. These are warnings only - not oopses.
2. It seems this patch you've found to be responsible for this all
slightly changes some limits, which is not necessarily wrong; the
lucky thing is you can change these limits with sysctl or some
echos to /proc/sys/net/ipv4/tcp_mem, I presume. (Or more safely by
adding some memory.)
Regards,
Jarek P.
^ permalink raw reply
* Re: [RFC][BNX2X] .h files rewrite
From: David Miller @ 2007-10-29 8:39 UTC (permalink / raw)
To: eliezert; +Cc: mchan, jeff, netdev, masbock
In-Reply-To: <1193602875.4836.28.camel@eliezer>
From: "Eliezer Tamir" <eliezert@broadcom.com>
Date: Sun, 28 Oct 2007 22:21:14 +0200
Overall things look significantly better, thanks a lot!
However, there is still one set of magic constants in here
which I hope you can clear up:
> +static const struct raw_op init_ops[] = {
> +#define PRS_COMMON_START 0
> + {OP_WR, PRS_REG_INC_VALUE, 0xf},
> + {OP_WR, PRS_REG_EVENT_ID_1, 0x45},
> + {OP_WR, PRS_REG_EVENT_ID_2, 0x84},
> + {OP_WR, PRS_REG_EVENT_ID_3, 0x6},
> + {OP_WR, PRS_REG_NO_MATCH_EVENT_ID, 0x4},
> + {OP_WR, PRS_REG_CM_HDR_TYPE_0, 0x0},
> + {OP_WR, PRS_REG_CM_HDR_TYPE_1, 0x12170000},
> + {OP_WR, PRS_REG_CM_HDR_TYPE_2, 0x22170000},
> + {OP_WR, PRS_REG_CM_HDR_TYPE_3, 0x32170000},
> + {OP_ZR, PRS_REG_CM_HDR_TYPE_4, 0x5},
> + {OP_WR, PRS_REG_CM_HDR_LOOPBACK_TYPE_1, 0x12150000},
> + {OP_WR, PRS_REG_CM_HDR_LOOPBACK_TYPE_2, 0x22150000},
> + {OP_WR, PRS_REG_CM_HDR_LOOPBACK_TYPE_3, 0x32150000},
> + {OP_ZR, PRS_REG_CM_HDR_LOOPBACK_TYPE_4, 0x4},
etc. etc.
Take care.
^ permalink raw reply
* Re: Oops in 2.6.21-rc4, 2.6.23
From: David Miller @ 2007-10-29 8:41 UTC (permalink / raw)
To: jarkao2; +Cc: darko.koruga, netdev
In-Reply-To: <20071029084232.GA2280@ff.dom.local>
From: Jarek Poplawski <jarkao2@o2.pl>
Date: Mon, 29 Oct 2007 09:42:32 +0100
> I hope you've found this by yourself by now, but:
>
> 1. These are warnings only - not oopses.
> 2. It seems this patch you've found to be responsible for this all
> slightly changes some limits, which is not necessarily wrong; the
> lucky thing is you can change these limits with sysctl or some
> echos to /proc/sys/net/ipv4/tcp_mem, I presume. (Or more safely by
> adding some memory.)
Actually, this was caused by a real bug in the SKB_WITH_OVERHEAD macro
definition, which Herbert Xu quickly spotted and fixed.
Which "I hope you've found this by yourself by now".
^ permalink raw reply
* Re: [PATCH] r8169: don't call napi_disable if not doing NAPI
From: Romano Giannetti @ 2007-10-29 8:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ingo Molnar, Francois Romieu, Jeff Garzik, Peter Zijlstra,
Linux Kernel Mailing List, David S. Miller, netdev, Edward Hsu,
Andrew Morton
In-Reply-To: <20071026113305.57dea765@freepuppy.rosehill>
On Fri, 2007-10-26 at 11:33 -0700, Stephen Hemminger wrote:
> Don't call napi_disable if not configured.
> And make sure that any misuse of napi_xxx in future fails
> with a compile error.
>
> Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
>
This fix the problem for me (at least, after 8 suspend/resume cycles).
Thanks.
Tested-by: Romano Giannetti <romano.giannetti@gmail.com>
--
Sorry for the disclaimer --- ¡I cannot stop it!
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.
^ permalink raw reply
* Re: IPVS: use proper timeout instead of fixed value
From: Simon Horman @ 2007-10-29 8:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, lvs-devel, wensong, ja, jmack, graeme, lvs, andy
In-Reply-To: <20071029.013515.07385320.davem@davemloft.net>
On Mon, Oct 29, 2007 at 01:35:15AM -0700, David Miller wrote:
> From: Simon Horman <horms@verge.net.au>
> Date: Mon, 29 Oct 2007 16:05:55 +0900 (JST)
>
> > From: Andy Gospodarek <andy@greyhouse.net>
> >
> > Instead of using the default timeout of 3 minutes, this uses the timeout
> > specific to the protocol used for the connection. The 3 minute timeout
> > seems somewhat arbitrary (though I know it is used other places in the
> > ipvs code) and when failing over it would be much nicer to use one of
> > the configured timeout values.
> >
> > Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> > Acked-by: Simon Horman <horms@verge.net.au>
>
> I would apply this but it does not apply to current 2.6.x,
> please resubmit.
I tried against net-2.6 and it seemed to work.
Was I mistaken or should I be using a different tree?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
^ permalink raw reply
* Re: [PATCH 1/4] e1000e: Fix jumbo frame receive code.
From: Jeff Garzik @ 2007-10-29 9:47 UTC (permalink / raw)
To: Auke Kok; +Cc: netdev
In-Reply-To: <20071025205744.32645.59503.stgit@localhost.localdomain>
Auke Kok wrote:
> Fix allocation and freeing of jumbo frames where several bugs
> were recently introduced by cleanups after we forked this code
> from e1000. This moves ps_pages to buffer_info where it really
> belongs and makes it a dynamically allocated array. The penalty
> is not that high since it's allocated outside of the buffer_info
> struct anyway.
>
> Without this patch all jumbo frames are completely broken and the
> driver panics.
>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> ---
>
> drivers/net/e1000e/e1000.h | 4 +-
> drivers/net/e1000e/netdev.c | 102 ++++++++++++++++++++++---------------------
> 2 files changed, 54 insertions(+), 52 deletions(-)
applied 1-4 to #upstream-fixes
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Jeff Garzik @ 2007-10-29 9:47 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: netdev, Christoph Raisch, Jan-Bernd Themann, linux-kernel,
linux-ppc, Marcus Eder, Thomas Klein, Stefan Roscher
In-Reply-To: <200710261437.29117.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> eHEA resources that are allocated via H_CALLs have a unique identifier each.
> These identifiers are necessary to free the resources. A reboot notifier
> is used to free all eHEA resources before the indentifiers get lost, i.e
> before kexec starts a new kernel.
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
applied to #upstream-fixes
^ permalink raw reply
* Re: Please pull 'fixes-jgarzik' branch of wireless-2.6
From: Jeff Garzik @ 2007-10-29 9:48 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-wireless
In-Reply-To: <20071026030826.GB14080@tuxdriver.com>
John W. Linville wrote:
> Jeff,
>
> A few fixes for 2.6.24...
>
> Thanks,
>
> John
>
> ---
>
> Individual patches available here:
>
> http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik
>
> ---
>
> The following changes since commit c9927c2bf4f45bb85e8b502ab3fb79ad6483c244:
> Linus Torvalds (1):
> Linux 2.6.24-rc1
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
>
> Anton Blanchard (3):
> ipw2100/ipw2200: jiffies_round -> jiffies_round_relative
> rt2x00: jiffies_round -> jiffies_round_relative
> b43/b43legacy: jiffies_round -> jiffies_round_relative
>
> Michael Wu (1):
> rtl8187: Allow multicast frames
>
> Mohamed Abbas (3):
> iwl4965: fix scan problem
> iwl3945: cancel scan on rxon command
> iwl3945: fix direct scan problem
>
> Tomas Winkler (1):
> iwlwifi: fix sending probe request in iwl 4965
>
> mabbas (1):
> iwl4965: fix driver hang related to hardware scan
>
> drivers/net/wireless/b43/main.c | 2 +-
> drivers/net/wireless/b43legacy/main.c | 2 +-
> drivers/net/wireless/ipw2100.c | 11 +++--
> drivers/net/wireless/ipw2200.c | 6 +-
> drivers/net/wireless/iwlwifi/iwl-4965.c | 6 +--
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 56 +++++++++++++++++++++++----
> drivers/net/wireless/iwlwifi/iwl4965-base.c | 56 +++++++++++++++++++++++----
> drivers/net/wireless/rt2x00/rt2x00lib.h | 2 +-
> drivers/net/wireless/rtl8187_dev.c | 20 +++++----
> 9 files changed, 121 insertions(+), 40 deletions(-)
pulled
^ permalink raw reply
* Re: [PATCH 00/04] pull request for 'upstream-jeff' branch
From: Jeff Garzik @ 2007-10-29 9:48 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, Andrew Morton, Edward Hsu
In-Reply-To: <20071028171937.GA24622@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Please pull from branch 'upstream-jeff' in repository
>
> git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git upstream-jeff
>
> to get the changes below.
>
> Distance from 'master' (96fd4cd3e40e240f0c385af87f58e74da8b7099a)
> -----------------------------------------------------------------
>
> d1417862d7355f0b395d83f2884afd614b086695
> bbd82f956e0db6190b16a8a00d3ed5d979f488e8
> 93dd79e87bbc98ef02610d54fe72d4a1931ee15e
> 7fab06c0ca89d99442a4baeddf417add585e2672
>
> Diffstat
> --------
>
> drivers/net/Kconfig | 13 +++++++------
> drivers/net/r8169.c | 12 ++++++------
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> Shortlog
> --------
>
> Francois Romieu (2):
> ipg: missing Kconfig dependency
> ipg: Kconfig whitepaces/tab damages
>
> Stephen Hemminger (2):
> r8169: napi config
> r8169: remove poll_locked logic
pulled
^ permalink raw reply
* Re: [PATCH 2.6.24 1/1]S2io: Fixed memory leak by freeing MSI-X local entry memories when vector allocation fails
From: Jeff Garzik @ 2007-10-29 9:55 UTC (permalink / raw)
To: Sivakumar Subramani; +Cc: netdev, support
In-Reply-To: <Pine.GSO.4.10.10710280403250.29009-100000@guinness>
Sivakumar Subramani wrote:
> - Fixed memory leak by freeing MSI-X local entry memories when vector allocation
> fails in s2io_add_isr.
> - Added two utility functions do_rem_msix_isr and do_rem_inta_isr to eliminate
> code duplication.
>
> Signed-off-by: Veena Parat <veena.parat@neterion.com>
> Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
> Signed-off-by: Santosh Rastapur <santosh.rastapur@neterion.com>
Comments:
1) stats->mem_freed is redundant to general kernel debugging facilities
2) synchronize_irq() is redundant, free_irq() does same
3) "rem" isn't very clear. few if any other kernel drivers use this to
indicate "remove"
4) "do_" prefix is redundant
5) scripts/checkpatch.pl fails on this patch. please clean up problems.
The main issue for this patch is #2, though presumably the other stuff
can be cleaned on the next resubmit
^ permalink raw reply
* Re: [PATCH v4.3] FEC - fast ethernet controller for mpc52xx
From: Jeff Garzik @ 2007-10-29 9:59 UTC (permalink / raw)
To: Domen Puncer; +Cc: Dale Farnsworth, netdev, linuxppc-dev
In-Reply-To: <20071026160749.GA21374@nd47.coderock.org>
Domen Puncer wrote:
> On 26/10/07 07:18 -0700, Dale Farnsworth wrote:
>> On Fri, Oct 26, 2007 at 01:59:09PM +0200, Domen Puncer wrote:
>>> +static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
>>> +{
>>> + struct net_device *dev = dev_id;
>>> + struct mpc52xx_fec_priv *priv = netdev_priv(dev);
>>> +
>>> + spin_lock(&priv->lock);
>>> +
>>> + while (bcom_buffer_done(priv->tx_dmatsk)) {
>>> + struct sk_buff *skb;
>>> + struct bcom_fec_bd *bd;
>>> + skb = bcom_retrieve_buffer(priv->tx_dmatsk, NULL,
>>> + (struct bcom_bd **)&bd);
>>> + /* Here (and in rx routines) would be a good place for
>>> + * dma_unmap_single(), but bcom doesn't return bcom_bd of the
>>> + * finished transfer, and _unmap is empty on this platfrom.
>>> + */
>> Oops, you forgot to remove the above comment. :)
>
> Argh!
>
> Repost w/o the comment.
> Sorry for receiving all this almost-spam.
>
>
>> Otherwise,
>> Acked-by: Dale Farnsworth <dale@farnsworth.org>
>>
>> Domen, thanks for all your work on this. It's good to see it finally go in.
>>
>> -Dale
>
> --- again, use your scisors here ;-) ---
>
>
> Driver for ethernet on mpc5200/mpc5200b SoCs (FEC).
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
> Acked-by: Dale Farnsworth <dale@farnsworth.org>
>
> ---
> drivers/net/Kconfig | 24
> drivers/net/Makefile | 4
> drivers/net/fec_mpc52xx.c | 1112 ++++++++++++++++++++++++++++++++++++++++++
> drivers/net/fec_mpc52xx.h | 313 +++++++++++
> drivers/net/fec_mpc52xx_phy.c | 198 +++++++
> 5 files changed, 1651 insertions(+)
applied to #upstream-fixes
it's not strictly a fix, but I did not want to hold this back until
2.6.25 either
^ permalink raw reply
* Re: IPVS: use proper timeout instead of fixed value
From: David Miller @ 2007-10-29 10:01 UTC (permalink / raw)
To: horms; +Cc: netdev, lvs-devel, wensong, ja, jmack, graeme, lvs, andy
In-Reply-To: <20071029085921.GB30256@verge.net.au>
From: Simon Horman <horms@verge.net.au>
Date: Mon, 29 Oct 2007 17:59:23 +0900
> On Mon, Oct 29, 2007 at 01:35:15AM -0700, David Miller wrote:
> > From: Simon Horman <horms@verge.net.au>
> > Date: Mon, 29 Oct 2007 16:05:55 +0900 (JST)
> >
> > > From: Andy Gospodarek <andy@greyhouse.net>
> > >
> > > Instead of using the default timeout of 3 minutes, this uses the timeout
> > > specific to the protocol used for the connection. The 3 minute timeout
> > > seems somewhat arbitrary (though I know it is used other places in the
> > > ipvs code) and when failing over it would be much nicer to use one of
> > > the configured timeout values.
> > >
> > > Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> > > Acked-by: Simon Horman <horms@verge.net.au>
> >
> > I would apply this but it does not apply to current 2.6.x,
> > please resubmit.
>
> I tried against net-2.6 and it seemed to work.
> Was I mistaken or should I be using a different tree?
Nope, that should be good.
Maybe I did something stupid or it got clobbered in transit somehow.
Please resend it privately to me under seperate cover and we'll sort
it out.
Thanks Simon!
^ permalink raw reply
* Re: [PATCH] pcnet: fix sparse triviality
From: Jeff Garzik @ 2007-10-29 10:04 UTC (permalink / raw)
To: Auke Kok; +Cc: pcnet32, netdev
In-Reply-To: <20071026221132.1913.24518.stgit@localhost.localdomain>
Auke Kok wrote:
> Since data can never exceed u32, it can't even be larger than LONG_MAX/HZ.
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> Cc: pcnet32@verizon.net
> ---
>
> drivers/net/pcnet32.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/pcnet32.c b/drivers/net/pcnet32.c
> index ff92aca..3573e77 100644
> --- a/drivers/net/pcnet32.c
> +++ b/drivers/net/pcnet32.c
> @@ -1101,9 +1101,8 @@ static int pcnet32_phys_id(struct net_device *dev, u32 data)
> mod_timer(&lp->blink_timer, jiffies);
> set_current_state(TASK_INTERRUPTIBLE);
>
> - /* AV: the limit here makes no sense whatsoever */
> - if ((!data) || (data > (u32) (MAX_SCHEDULE_TIMEOUT / HZ)))
> - data = (u32) (MAX_SCHEDULE_TIMEOUT / HZ);
> + if (!data)
> + data = INT_MAX;
>
> msleep_interruptible(data * 1000);
> del_timer_sync(&lp->blink_timer);
Two comments:
1) I would prefer to pick a sane limit, like "1 day". The unit of
'data' is seconds, so IMO we should not allow stupid timeouts, much less
INT_MAX ones :) But hey, then again, maybe we should permit root to
hang themselves with own rope...
2) [tangent] someone really should add the obvious ssleep_interruptible()
^ permalink raw reply
* Re: [PATCH] skye/skge: sparse fix - data can't ever be bigger than LONG_MAX / HZ
From: Jeff Garzik @ 2007-10-29 10:05 UTC (permalink / raw)
To: Auke Kok; +Cc: shemminger, netdev
In-Reply-To: <20071026221028.1873.3005.stgit@localhost.localdomain>
Auke Kok wrote:
> Trivial replacement - use INT_MAX instead here.
>
> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
> Cc: shemminger@linux-foundation.org
> ---
>
> drivers/net/sk98lin/skethtool.c | 4 ++--
> drivers/net/skge.c | 8 ++++----
> drivers/net/sky2.c | 8 ++++----
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/sk98lin/skethtool.c b/drivers/net/sk98lin/skethtool.c
> index 5a6da89..4549b97 100644
> --- a/drivers/net/sk98lin/skethtool.c
> +++ b/drivers/net/sk98lin/skethtool.c
> @@ -430,8 +430,8 @@ static int locateDevice(struct net_device *dev, u32 data)
> DEV_NET *pNet = netdev_priv(dev);
> SK_AC *pAC = pNet->pAC;
>
> - if(!data || data > (u32)(MAX_SCHEDULE_TIMEOUT / HZ))
> - data = (u32)(MAX_SCHEDULE_TIMEOUT / HZ);
> + if (!data)
> + data = INT_MAX;
>
> /* start blinking */
> pAC->LedsOn = 0;
> diff --git a/drivers/net/skge.c b/drivers/net/skge.c
> index b9961dc..696a79e 100644
> --- a/drivers/net/skge.c
> +++ b/drivers/net/skge.c
> @@ -783,10 +783,10 @@ static int skge_phys_id(struct net_device *dev, u32 data)
> unsigned long ms;
> enum led_mode mode = LED_MODE_TST;
>
> - if (!data || data > (u32)(MAX_SCHEDULE_TIMEOUT / HZ))
> - ms = jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT / HZ) * 1000;
> - else
> - ms = data * 1000;
> + if (!data)
> + data = INT_MAX;
> +
> + ms = data * HZ;
>
> while (ms > 0) {
> skge_led(skge, mode);
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index c27c7d6..1381d04 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -3336,10 +3336,10 @@ static int sky2_phys_id(struct net_device *dev, u32 data)
> int interrupted;
> int onoff = 1;
>
> - if (!data || data > (u32) (MAX_SCHEDULE_TIMEOUT / HZ))
> - ms = jiffies_to_msecs(MAX_SCHEDULE_TIMEOUT);
> - else
> - ms = data * 1000;
> + if (!data)
> + data = INT_MAX:
> +
> + ms = data * HZ;
ditto comments in previous email...
^ permalink raw reply
* Re: [PATCH] Fix ethernet multicast for ucc_geth.
From: Jeff Garzik @ 2007-10-29 10:05 UTC (permalink / raw)
To: joakim.tjernlund, Li Yang-r58472; +Cc: Netdev
In-Reply-To: <1192611942.7848.19.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund wrote:
>>From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Wed, 17 Oct 2007 11:01:44 +0200
> Subject: [PATCH] Fix ethernet multicast for ucc_geth.
> hw_add_addr_in_hash() already swaps byte
> order, don't do it in ucc_geth_set_multi() too.
>
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> drivers/net/ucc_geth.c | 15 ++-------------
> 1 files changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index 61f5cce..f649b1e 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -2214,9 +2214,7 @@ static void ucc_geth_set_multi(struct net_device *dev)
> struct dev_mc_list *dmi;
> struct ucc_fast *uf_regs;
> struct ucc_geth_82xx_address_filtering_pram *p_82xx_addr_filt;
> - u8 tempaddr[6];
> - u8 *mcptr, *tdptr;
> - int i, j;
> + int i;
>
> ugeth = netdev_priv(dev);
>
> @@ -2255,19 +2253,10 @@ static void ucc_geth_set_multi(struct net_device *dev)
> if (!(dmi->dmi_addr[0] & 1))
> continue;
>
> - /* The address in dmi_addr is LSB first,
> - * and taddr is MSB first. We have to
> - * copy bytes MSB first from dmi_addr.
> - */
> - mcptr = (u8 *) dmi->dmi_addr + 5;
> - tdptr = (u8 *) tempaddr;
> - for (j = 0; j < 6; j++)
> - *tdptr++ = *mcptr--;
> -
> /* Ask CPM to run CRC and set bit in
> * filter mask.
> */
> - hw_add_addr_in_hash(ugeth, tempaddr);
> + hw_add_addr_in_hash(ugeth, dmi->dmi_addr);
did the maintainer ever ACK this?
^ permalink raw reply
* RE: [PATCH] Fix ethernet multicast for ucc_geth.
From: Li Yang-r58472 @ 2007-10-29 10:07 UTC (permalink / raw)
To: Jeff Garzik, joakim.tjernlund; +Cc: Netdev
In-Reply-To: <4725B06F.7070304@garzik.org>
> > @@ -2255,19 +2253,10 @@ static void
> ucc_geth_set_multi(struct net_device *dev)
> > if (!(dmi->dmi_addr[0] & 1))
> > continue;
> >
> > - /* The address in dmi_addr is LSB first,
> > - * and taddr is MSB first. We have to
> > - * copy bytes MSB first from dmi_addr.
> > - */
> > - mcptr = (u8 *) dmi->dmi_addr + 5;
> > - tdptr = (u8 *) tempaddr;
> > - for (j = 0; j < 6; j++)
> > - *tdptr++ = *mcptr--;
> > -
> > /* Ask CPM to run CRC and set bit in
> > * filter mask.
> > */
> > - hw_add_addr_in_hash(ugeth, tempaddr);
> > + hw_add_addr_in_hash(ugeth,
> dmi->dmi_addr);
>
> did the maintainer ever ACK this?
Yes, I did. :)
- Leo
^ permalink raw reply
* Re: [PATCH] Fix ethernet multicast for ucc_geth.
From: Jeff Garzik @ 2007-10-29 10:11 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: Netdev, Li Yang-r58472
In-Reply-To: <1192611942.7848.19.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund wrote:
>>From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Wed, 17 Oct 2007 11:01:44 +0200
> Subject: [PATCH] Fix ethernet multicast for ucc_geth.
> hw_add_addr_in_hash() already swaps byte
> order, don't do it in ucc_geth_set_multi() too.
>
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> drivers/net/ucc_geth.c | 15 ++-------------
> 1 files changed, 2 insertions(+), 13 deletions(-)
applied
^ permalink raw reply
* RE: [PATCH 2.6.24 1/1]S2io: Support for add/delete/store/restore ethernet addresses
From: Sreenivasa Honnur @ 2007-10-29 10:31 UTC (permalink / raw)
To: Sreenivasa Honnur, jeff, netdev; +Cc: support
In-Reply-To: <Pine.GSO.4.10.10710190146510.17153-100000@guinness>
Jeff,
Is this patch reviewed/applied?
-srini
-----Original Message-----
From: Sreenivasa Honnur [mailto:Sreenivasa.Honnur@neterion.com]
Sent: Friday, October 19, 2007 11:23 AM
To: jeff@garzik.org; netdev@vger.kernel.org
Cc: support
Subject: [PATCH 2.6.24 1/1]S2io: Support for add/delete/store/restore
ethernet addresses
- Support to add/delete/store/restore 64 and 128 Ethernet addresses for
Xframe I and Xframe II respectively.
Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>
---
diff -urpN org/drivers/net/s2io.c patch_1/drivers/net/s2io.c
--- org/drivers/net/s2io.c 2007-09-26 00:01:14.000000000 +0530
+++ patch_1/drivers/net/s2io.c 2007-09-26 22:42:11.000000000 +0530
@@ -84,7 +84,7 @@
#include "s2io.h"
#include "s2io-regs.h"
-#define DRV_VERSION "2.0.26.5"
+#define DRV_VERSION "2.0.26.6"
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion"; @@ -3363,6 +3363,9 @@
static void s2io_reset(struct s2io_nic *
/* Set swapper to enable I/O register access */
s2io_set_swapper(sp);
+ /* restore mac address entries */
+ do_s2io_restore_unicast_mc(sp);
+
/* Restore the MSIX table entries from local variables */
restore_xmsi_data(sp);
@@ -3421,9 +3424,6 @@ static void s2io_reset(struct s2io_nic *
writeq(val64, &bar0->pcc_err_reg);
}
- /* restore the previously assigned mac address */
- do_s2io_prog_unicast(sp->dev, (u8
*)&sp->def_mac_addr[0].mac_addr);
-
sp->device_enabled_once = FALSE;
}
@@ -3896,8 +3896,17 @@ hw_init_failed:
static int s2io_close(struct net_device *dev) {
struct s2io_nic *sp = dev->priv;
+ struct config_param *config = &sp->config;
+ u64 tmp64;
+ int off;
netif_stop_queue(dev);
+ /* delete all populated mac entries */
+ for(off =1; off < config->max_mc_addr; off++) {
+ tmp64 = do_s2io_read_unicast_mc(sp,off);
+ if(tmp64 != S2IO_DISABLE_MAC_ENTRY)
+ do_s2io_delete_unicast_mc(sp, tmp64);
+ }
napi_disable(&sp->napi);
/* Reset card, kill tasklet and free Tx and Rx buffers. */
s2io_card_down(sp);
@@ -4699,8 +4708,9 @@ static void s2io_set_multicast(struct ne
struct XENA_dev_config __iomem *bar0 = sp->bar0;
u64 val64 = 0, multi_mac = 0x010203040506ULL, mask =
0xfeffffffffffULL;
- u64 dis_addr = 0xffffffffffffULL, mac_addr = 0;
+ u64 dis_addr = S2IO_DISABLE_MAC_ENTRY, mac_addr = 0;
void __iomem *add;
+ struct config_param *config = &sp->config;
if ((dev->flags & IFF_ALLMULTI) && (!sp->m_cast_flg)) {
/* Enable all Multicast addresses */ @@ -4710,7 +4720,7
@@ static void s2io_set_multicast(struct ne
&bar0->rmac_addr_data1_mem);
val64 = RMAC_ADDR_CMD_MEM_WE |
RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD |
- RMAC_ADDR_CMD_MEM_OFFSET(MAC_MC_ALL_MC_ADDR_OFFSET);
+ RMAC_ADDR_CMD_MEM_OFFSET(config->max_mc_addr -
1);
writeq(val64, &bar0->rmac_addr_cmd_mem);
/* Wait till command completes */
wait_for_cmd_complete(&bar0->rmac_addr_cmd_mem,
@@ -4718,7 +4728,7 @@ static void s2io_set_multicast(struct ne
S2IO_BIT_RESET);
sp->m_cast_flg = 1;
- sp->all_multi_pos = MAC_MC_ALL_MC_ADDR_OFFSET;
+ sp->all_multi_pos = config->max_mc_addr - 1;
} else if ((dev->flags & IFF_ALLMULTI) && (sp->m_cast_flg)) {
/* Disable all Multicast addresses */
writeq(RMAC_ADDR_DATA0_MEM_ADDR(dis_addr),
@@ -4787,7 +4797,7 @@ static void s2io_set_multicast(struct ne
/* Update individual M_CAST address list */
if ((!sp->m_cast_flg) && dev->mc_count) {
if (dev->mc_count >
- (MAX_ADDRS_SUPPORTED - MAC_MC_ADDR_START_OFFSET -
1)) {
+ (config->max_mc_addr - config->max_mac_addr)) {
DBG_PRINT(ERR_DBG, "%s: No more Rx filters ",
dev->name);
DBG_PRINT(ERR_DBG, "can be added, please enable
"); @@ -4807,7 +4817,7 @@ static void s2io_set_multicast(struct ne
val64 = RMAC_ADDR_CMD_MEM_WE |
RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD |
RMAC_ADDR_CMD_MEM_OFFSET
- (MAC_MC_ADDR_START_OFFSET + i);
+ (config->mc_start_offset + i);
writeq(val64, &bar0->rmac_addr_cmd_mem);
/* Wait for command completes */
@@ -4839,7 +4849,7 @@ static void s2io_set_multicast(struct ne
val64 = RMAC_ADDR_CMD_MEM_WE |
RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD |
RMAC_ADDR_CMD_MEM_OFFSET
- (i + MAC_MC_ADDR_START_OFFSET);
+ (i + config->mc_start_offset);
writeq(val64, &bar0->rmac_addr_cmd_mem);
/* Wait for command completes */
@@ -4855,8 +4865,76 @@ static void s2io_set_multicast(struct ne
}
}
-/* add unicast MAC address to CAM */
-static int do_s2io_add_unicast(struct s2io_nic *sp, u64 addr, int off)
+/* read from CAM unicast & multicast addresses and store it in
+def_mac_addr structure
++ **/
+void do_s2io_store_unicast_mc(struct s2io_nic *sp) {
+ int offset;
+ u64 mac_addr=0x0;
+ struct config_param *config = &sp->config;
+
+ /* store unicast & multicast mac addresses */
+ for(offset = 0; offset < config->max_mc_addr; offset++) {
+ mac_addr = do_s2io_read_unicast_mc(sp,offset);
+ /* if read fails disable the entry */
+ if(mac_addr == FAILURE)
+ mac_addr = S2IO_DISABLE_MAC_ENTRY;
+ do_s2io_copy_mac_addr(sp, offset, mac_addr);
+ }
+}
+
+/* restore unicast addresses & multicast to CAM from def_mac_addr
+structure */ static void do_s2io_restore_unicast_mc(struct s2io_nic
+*sp) {
+ int offset;
+ struct config_param *config = &sp->config;
+
+ /* restore unicast mac address */
+ for(offset = 0; offset < config->max_mac_addr; offset++)
+
do_s2io_prog_unicast(sp->dev,sp->def_mac_addr[offset].mac_addr);
+
+ /* restore multicast mac address */
+ for(offset = config->mc_start_offset;
+ offset < config->max_mc_addr; offset++)
+ do_s2io_add_mc(sp, sp->def_mac_addr[offset].mac_addr);
+}
+
+/* add a multicast MAC address to CAM */ static int
+do_s2io_add_mc(struct s2io_nic *sp, u8* addr) {
+ int i;
+ u64 mac_addr=0;
+ struct config_param *config = &sp->config;
+
+ for (i = 0; i < ETH_ALEN; i++) {
+ mac_addr <<= 8;
+ mac_addr |= addr[i];
+ }
+ if((0ULL == mac_addr) || (mac_addr == S2IO_DISABLE_MAC_ENTRY))
+ return SUCCESS;
+
+ /* check if the multicast mac already preset in CAM */
+ for(i = config->mc_start_offset; i < config->max_mc_addr; i++) {
+ u64 tmp64;
+ tmp64 = do_s2io_read_unicast_mc(sp,i);
+ if(tmp64 == S2IO_DISABLE_MAC_ENTRY) /* CAM entry is
empty */
+ break;
+
+ if(tmp64 == mac_addr)
+ return SUCCESS;
+ }
+ if(i == config->max_mc_addr) {
+ DBG_PRINT(ERR_DBG,"CAM full no space left for multicast
MAC\n");
+ return FAILURE;
+ }
+ /* Update the internal structure with this new mac address */
+ do_s2io_copy_mac_addr(sp, i, mac_addr);
+
+ return (do_s2io_add_mac(sp,mac_addr,i)); }
+
+/* add MAC address to CAM memory */
+static int do_s2io_add_mac(struct s2io_nic *sp, u64 addr, int off)
{
u64 val64;
struct XENA_dev_config __iomem *bar0 = sp->bar0; @@ -4879,6
+4957,53 @@ static int do_s2io_add_unicast(struct s2
return SUCCESS;
}
+/* deletes a specified unicast/multicast mac entry from CAM */ static
+int do_s2io_delete_unicast_mc(struct s2io_nic *sp, u64 addr) {
+ int off;
+ u64 dis_addr = S2IO_DISABLE_MAC_ENTRY,tmp64;
+ struct config_param *config = &sp->config;
+
+ for(off = 1;
+ off < config->max_mc_addr; off++) {
+ tmp64 = do_s2io_read_unicast_mc(sp,off);
+ if(tmp64 == addr) {
+ /* disable the entry by writing
0xffffffffffffULL */
+ if(do_s2io_add_mac(sp,dis_addr,off) == FAILURE)
+ return FAILURE;
+ /* store the new mac list from CAM */
+ do_s2io_store_unicast_mc(sp);
+ return SUCCESS;
+ }
+ }
+ DBG_PRINT(ERR_DBG,"MAC address 0x%llx not found in CAM\n",
+ (unsigned long long)addr);
+ return FAILURE;
+}
+
+/* read mac entries from CAM */
+static u64 do_s2io_read_unicast_mc(struct s2io_nic *sp, int offset) {
+ u64 tmp64=0xffffffffffff0000ULL, val64;
+ struct XENA_dev_config __iomem *bar0 = sp->bar0;
+
+ /* read mac addr */
+ val64 =
+ RMAC_ADDR_CMD_MEM_RD | RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD
|
+ RMAC_ADDR_CMD_MEM_OFFSET(offset);
+ writeq(val64, &bar0->rmac_addr_cmd_mem);
+
+ /* Wait till command completes */
+ if (wait_for_cmd_complete(&bar0->rmac_addr_cmd_mem,
+ RMAC_ADDR_CMD_MEM_STROBE_CMD_EXECUTING,
+ S2IO_BIT_RESET)) {
+ DBG_PRINT(INFO_DBG, "do_s2io_read_unicast_mc failed\n");
+ return FAILURE;
+ }
+ tmp64 = readq(&bar0->rmac_addr_data0_mem);
+ return (tmp64 >> 16);
+}
+
/**
* s2io_set_mac_addr driver entry point
*/
@@ -4909,6 +5034,8 @@ static int do_s2io_prog_unicast(struct n
struct s2io_nic *sp = dev->priv;
register u64 mac_addr = 0, perm_addr = 0;
int i;
+ u64 tmp64;
+ struct config_param *config = &sp->config;
/*
* Set the new MAC address as the new unicast filter and reflect
this @@ -4926,9 +5053,27 @@ static int do_s2io_prog_unicast(struct n
if (mac_addr == perm_addr)
return SUCCESS;
+ /* check if the mac already preset in CAM */
+ for(i = 1; i < config->max_mac_addr; i++) {
+ tmp64 = do_s2io_read_unicast_mc(sp,i);
+ if(tmp64 == S2IO_DISABLE_MAC_ENTRY) /* CAM entry is
empty */
+ break;
+
+ if(tmp64 == mac_addr) {
+ DBG_PRINT(INFO_DBG,
+ "MAC addr:0x%llx already present in
CAM\n",
+ (unsigned long long)mac_addr);
+ return SUCCESS;
+ }
+ }
+ if(i == config->max_mac_addr) {
+ DBG_PRINT(ERR_DBG,"CAM full no space left for Unicast
MAC\n");
+ return FAILURE;
+ }
+
/* Update the internal structure with this new mac address */
- do_s2io_copy_mac_addr(sp, 0, mac_addr);
- return (do_s2io_add_unicast(sp, mac_addr, 0));
+ do_s2io_copy_mac_addr(sp, i, mac_addr);
+ return (do_s2io_add_mac(sp,mac_addr,i));
}
/**
@@ -7625,7 +7770,7 @@ s2io_init_nic(struct pci_dev *pdev, cons
*/
bar0 = sp->bar0;
val64 = RMAC_ADDR_CMD_MEM_RD | RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD
|
- RMAC_ADDR_CMD_MEM_OFFSET(0 + MAC_MAC_ADDR_START_OFFSET);
+ RMAC_ADDR_CMD_MEM_OFFSET(0 +
S2IO_MAC_ADDR_START_OFFSET);
writeq(val64, &bar0->rmac_addr_cmd_mem);
wait_for_cmd_complete(&bar0->rmac_addr_cmd_mem,
RMAC_ADDR_CMD_MEM_STROBE_CMD_EXECUTING,
S2IO_BIT_RESET); @@ -7645,7 +7790,22 @@ s2io_init_nic(struct pci_dev
*pdev, cons
memcpy(dev->dev_addr, sp->def_mac_addr, ETH_ALEN);
memcpy(dev->perm_addr, dev->dev_addr, ETH_ALEN);
- /* Store the values of the MSIX table in the s2io_nic structure
*/
+ /* initialize number of multicast & unicast MAC entries
variables */
+ if (sp->device_type == XFRAME_I_DEVICE) {
+ config->max_mc_addr = S2IO_XENA_MAX_MC_ADDRESSES;
+ config->max_mac_addr = S2IO_XENA_MAX_MAC_ADDRESSES;
+ config->mc_start_offset =
S2IO_XENA_MC_ADDR_START_OFFSET;
+ }
+ else if (sp->device_type == XFRAME_II_DEVICE) {
+ config->max_mc_addr = S2IO_HERC_MAX_MC_ADDRESSES;
+ config->max_mac_addr = S2IO_HERC_MAX_MAC_ADDRESSES;
+ config->mc_start_offset =
S2IO_HERC_MC_ADDR_START_OFFSET;
+ }
+
+ /* store mac addresses from CAM to s2io_nic structure */
+ do_s2io_store_unicast_mc(sp);
+
+ /* Store the values of the MSIX table in the s2io_nic structure
*/
store_xmsi_data(sp);
/* reset Nic and bring it to known state */
s2io_reset(sp);
diff -urpN org/drivers/net/s2io.h patch_1/drivers/net/s2io.h
--- org/drivers/net/s2io.h 2007-09-26 00:01:14.000000000 +0530
+++ patch_1/drivers/net/s2io.h 2007-09-26 02:34:11.000000000 +0530
@@ -31,6 +31,7 @@
#define SUCCESS 0
#define FAILURE -1
#define S2IO_MINUS_ONE 0xFFFFFFFFFFFFFFFFULL
+#define S2IO_DISABLE_MAC_ENTRY 0xFFFFFFFFFFFFULL
#define S2IO_MAX_PCI_CONFIG_SPACE_REINIT 100 #define S2IO_BIT_RESET 1
#define S2IO_BIT_SET 2 @@ -458,6 +459,9 @@ struct config_param {
#define MAX_MTU_JUMBO (MAX_PYLD_JUMBO+18)
#define MAX_MTU_JUMBO_VLAN (MAX_PYLD_JUMBO+22)
u16 bus_speed;
+ int max_mc_addr; /* xena=64 herc=256 */
+ int max_mac_addr; /* xena=16 herc=64 */
+ int mc_start_offset; /* xena=16 herc=64 */
};
/* Structure representing MAC Addrs */
@@ -824,9 +828,8 @@ struct s2io_nic {
void __iomem *bar0;
void __iomem *bar1;
#define MAX_MAC_SUPPORTED 16
-#define MAX_SUPPORTED_MULTICASTS MAX_MAC_SUPPORTED
- struct mac_addr def_mac_addr[MAX_MAC_SUPPORTED];
+ struct mac_addr def_mac_addr[256];
struct net_device_stats stats;
int high_dma_flag;
@@ -850,10 +853,9 @@ struct s2io_nic {
#define PROMISC 1
#define ALL_MULTI 2
-#define MAX_ADDRS_SUPPORTED 64
u16 usr_addr_count;
u16 mc_addr_count;
- struct usr_addr usr_addrs[MAX_ADDRS_SUPPORTED];
+ struct usr_addr usr_addrs[256];
u16 m_cast_flg;
u16 all_multi_pos;
@@ -1066,6 +1068,12 @@ static int s2io_add_isr(struct s2io_nic static
void s2io_rem_isr(struct s2io_nic * sp);
static void restore_xmsi_data(struct s2io_nic *nic);
+static void do_s2io_store_unicast_mc(struct s2io_nic *sp); static void
+do_s2io_restore_unicast_mc(struct s2io_nic *sp); static u64
+do_s2io_read_unicast_mc(struct s2io_nic *sp, int offset); static int
+do_s2io_add_mc(struct s2io_nic *sp, u8 *addr); static int
+do_s2io_add_mac(struct s2io_nic *sp, u64 addr, int offset); static int
+do_s2io_delete_unicast_mc(struct s2io_nic *sp, u64 addr);
static int
s2io_club_tcp_session(u8 *buffer, u8 **tcp, u32 *tcp_len, struct lro
**lro, diff -urpN org/drivers/net/s2io-regs.h
patch_1/drivers/net/s2io-regs.h
--- org/drivers/net/s2io-regs.h 2007-09-26 00:01:14.000000000 +0530
+++ patch_1/drivers/net/s2io-regs.h 2007-09-26 02:37:53.000000000
+0530
@@ -721,12 +721,16 @@ struct XENA_dev_config {
u64 rmac_cfg_key;
#define RMAC_CFG_KEY(val) vBIT(val,0,16)
+#define S2IO_MAC_ADDR_START_OFFSET 0
-#define MAX_MAC_ADDRESSES 16
-#define MAX_MC_ADDRESSES 32 /* Multicast addresses */
-#define MAC_MAC_ADDR_START_OFFSET 0
-#define MAC_MC_ADDR_START_OFFSET 16
-#define MAC_MC_ALL_MC_ADDR_OFFSET 63 /* enables all multicast pkts */
+#define S2IO_XENA_MAX_MC_ADDRESSES 64 /* multicast
addresses */
+#define S2IO_HERC_MAX_MC_ADDRESSES 256
+
+#define S2IO_XENA_MAX_MAC_ADDRESSES 16
+#define S2IO_HERC_MAX_MAC_ADDRESSES 64
+
+#define S2IO_XENA_MC_ADDR_START_OFFSET 16 #define
+S2IO_HERC_MC_ADDR_START_OFFSET 64
u64 rmac_addr_cmd_mem;
#define RMAC_ADDR_CMD_MEM_WE BIT(7)
#define RMAC_ADDR_CMD_MEM_RD 0
^ permalink raw reply
* Re: HFSC dangerous behaviour (not a bug)
From: Patrick McHardy @ 2007-10-29 10:55 UTC (permalink / raw)
To: Denys; +Cc: netdev
In-Reply-To: <20071028235224.M3269@visp.net.lb>
Denys wrote:
> Hi All
>
> During testing i found very strange thing.
> After applying even example shaper:
> http://linux-ip.net/tc/hfsc.en/
> -------------
> [...]
> ---------------
> I had all traffic on eth0 stopped. Tried on br0 - same result. Even ARP
> becoming non-functional.
>
> After specifying correct default class everything worked fine.
>
> In HTB if you dont specify default class, traffic just pass without
> "shaping".
HFSC drops unclassified packets. If you don't classify ARP properly,
things will break,
> Is it possible to keep same behaviour on both disciplines?
> Probably just dropping all traffic not good idea, cause if user working on
> remote box by forgetting specifying default class or by mistake using
> incorrect class number he will loose access to the box, if same interface is
> used for tests on shaping and access.
> In same time it is good, and can show accurate results on shaping, without
> bypassing some "forgotten" traffic.
> But at least it must be same, IMHO, on HTB and HFSC.
This came up a couple of times already. I don't like HTB's behaviour
since you don't notice when your classifiers are incomplete. So I'm
against changing HFSC to behave similar. HTB OTOH can't be changed
since users probably rely on that, not classifying ARP is a common
mistake.
^ permalink raw reply
* Re: HFSC dangerous behaviour (not a bug)
From: Patrick McHardy @ 2007-10-29 10:56 UTC (permalink / raw)
To: Denys; +Cc: netdev
In-Reply-To: <20071029005547.M47431@visp.net.lb>
Denys wrote:
> Additionally, it doesn't show rate in stats (so it is difficult to measure,
> how much is really using each class).
>
> qdisc hfsc 1: root default 200
> Sent 1392761062 bytes 965768 pkt (dropped 52, overlimits 1620539 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
Thats what rate estimators are for. Add something like "estimator 1 4"
to your qdisc and class creation commands to measure the rate.
^ permalink raw reply
* Re: HFSC dangerous behaviour (not a bug)
From: Denys @ 2007-10-29 11:45 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <4725BC23.7000907@trash.net>
After thinking about that, i can say only thanks.
I like your idea, and it is better to avoid mistakes and missed traffic, then
have a lot of complaints from users "why my shaper not working well". And
seems i will try to switch to HFSC.
Thanks for explanation.
On Mon, 29 Oct 2007 11:55:31 +0100, Patrick McHardy wrote
> Denys wrote:
> > Hi All
> >
> > During testing i found very strange thing.
> > After applying even example shaper:
> > http://linux-ip.net/tc/hfsc.en/
> > -------------
> > [...]
> > ---------------
> > I had all traffic on eth0 stopped. Tried on br0 - same result. Even ARP
> > becoming non-functional.
> >
> > After specifying correct default class everything worked fine.
> >
> > In HTB if you dont specify default class, traffic just pass without
> > "shaping".
>
> HFSC drops unclassified packets. If you don't classify ARP properly,
> things will break,
>
> > Is it possible to keep same behaviour on both disciplines?
> > Probably just dropping all traffic not good idea, cause if user working
on
> > remote box by forgetting specifying default class or by mistake using
> > incorrect class number he will loose access to the box, if same interface
is
> > used for tests on shaping and access.
> > In same time it is good, and can show accurate results on shaping,
without
> > bypassing some "forgotten" traffic.
> > But at least it must be same, IMHO, on HTB and HFSC.
>
> This came up a couple of times already. I don't like HTB's behaviour
> since you don't notice when your classifiers are incomplete. So I'm
> against changing HFSC to behave similar. HTB OTOH can't be changed
> since users probably rely on that, not classifying ARP is a common
> mistake.
>
> -
> 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
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: [PATCH] ucc_geth: add support for netpoll
From: Anton Vorontsov @ 2007-10-29 12:17 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: Sergei Shtylyov, netdev, linux-kernel, linuxppc-dev
In-Reply-To: <989B956029373F45A0B8AF0297081890019B61BF@zch01exm26.fsl.freescale.net>
On Mon, Oct 29, 2007 at 02:12:07PM +0800, Li Yang-r58472 wrote:
[...]
> > > > +#ifdef CONFIG_NET_POLL_CONTROLLER
> > > > +/*
> > > > + * Polling 'interrupt' - used by things like netconsole to send
> > > > +skbs
> > > > + * without having to re-enable interrupts. It's not called while
> > > > + * the interrupt routine is executing.
> > > > + */
> > > > +static void ucc_netpoll(struct net_device *dev) {
> > > > + struct ucc_geth_private *ugeth = netdev_priv(dev);
> > > > +
> > > > + disable_irq(ugeth->ug_info->uf_info.irq);
> > > > + ucc_geth_irq_handler(ugeth->ug_info->uf_info.irq, dev);
> > > > + enable_irq(ugeth->ug_info->uf_info.irq);
> > >
> > > Why not make it less complex (for a reader and gcc too :-) ?
> >
> > Yup, I'm agree here but it's too late. Again. ;-)
> >
> > This patch already accepted into the -mm (a week or so after
> > the silence), so.. now I'd rather not bother Andrew with such
> > really cosmetic changes. But if Jeff would directly apply
> > modfied patch, I'll send it. ;-)
>
> Oops. The original patch happened to hit the Junk mail box. :(
That one as well? http://lkml.org/lkml/2007/10/11/128
> I think
> the patch is good to merge after the cosmetic change. I can do it in
> next pull request to Jeff.
Ok, great. Thanks.
Here it is:
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [PATCH] ucc_geth: add support for netpoll
This patch adds netpoll support for the QE UCC Gigabit Ethernet
driver. Tested using netconsole and KGDBoE.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/ucc_geth.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index bec413b..94e78d8 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3678,6 +3678,23 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
return IRQ_HANDLED;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+/*
+ * Polling 'interrupt' - used by things like netconsole to send skbs
+ * without having to re-enable interrupts. It's not called while
+ * the interrupt routine is executing.
+ */
+static void ucc_netpoll(struct net_device *dev)
+{
+ struct ucc_geth_private *ugeth = netdev_priv(dev);
+ int irq = ugeth->ug_info->uf_info.irq;
+
+ disable_irq(irq);
+ ucc_geth_irq_handler(irq, dev);
+ enable_irq(irq);
+}
+#endif /* CONFIG_NET_POLL_CONTROLLER */
+
/* Called when something needs to use the ethernet device */
/* Returns 0 for success. */
static int ucc_geth_open(struct net_device *dev)
@@ -3963,6 +3980,9 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
#ifdef CONFIG_UGETH_NAPI
netif_napi_add(dev, &ugeth->napi, ucc_geth_poll, UCC_GETH_DEV_WEIGHT);
#endif /* CONFIG_UGETH_NAPI */
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ dev->poll_controller = ucc_netpoll;
+#endif
dev->stop = ucc_geth_close;
// dev->change_mtu = ucc_geth_change_mtu;
dev->mtu = 1500;
--
1.5.2.2
^ permalink raw reply related
* Re: IPVS: use proper timeout instead of fixed value
From: Andy Gospodarek @ 2007-10-29 12:50 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, lvs-devel, wensong, ja, Joseph Mack NA3T, Graeme Fowler,
Andreas Lundqvist, Andy Gospodarek
In-Reply-To: <20071029070555.78D694FA13@tabatha.lab.ultramonkey.org>
On Mon, Oct 29, 2007 at 04:05:55PM +0900, Simon Horman wrote:
> From: Andy Gospodarek <andy@greyhouse.net>
>
> Instead of using the default timeout of 3 minutes, this uses the timeout
> specific to the protocol used for the connection. The 3 minute timeout
> seems somewhat arbitrary (though I know it is used other places in the
> ipvs code) and when failing over it would be much nicer to use one of
> the configured timeout values.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Acked-by: Simon Horman <horms@verge.net.au>
>
Thanks for re-visiting this, Simon! It's too bad that the other work
never got done, but I'm glad to see this will get included.
^ 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