Re: [NET] IPv6 oops bisected

2007-10-07 Thread Denis V. Lunev
David Miller wrote:
> From: "Denis V. Lunev" <[EMAIL PROTECTED]>
> Date: Mon, 08 Oct 2007 10:34:23 +0400
> 
>> OK. I am installing Fedora 7 right now...
> 
> You don't need to install Fedora, just read the code! :-)
> 
> The bug is obvious and it's been explained thoroughly in this
> thread.
> 
> When 'dev' is NULL in ip6_route_add() we need to figure out what
> namespace and/or loopback device you want to use.
> 
> There is no reason to do an entire dist install to work on fixing this
> bug, yikes!

I do understand the conditions when the bug happens. Its completely
clear :) Though I do not understand how to trigger it from command line
to test that the problem is resolved. Jeff was not kind enough to give
exact command line :(

The unfortunate thing with this place is that original Eric's code is
also broken here. I was too optimistic working on the original patchset.
In other way, but broken :(

So, I must stop and think...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NET] IPv6 oops bisected

2007-10-07 Thread David Miller
From: "Denis V. Lunev" <[EMAIL PROTECTED]>
Date: Mon, 08 Oct 2007 10:34:23 +0400

> OK. I am installing Fedora 7 right now...

You don't need to install Fedora, just read the code! :-)

The bug is obvious and it's been explained thoroughly in this
thread.

When 'dev' is NULL in ip6_route_add() we need to figure out what
namespace and/or loopback device you want to use.

There is no reason to do an entire dist install to work on fixing this
bug, yikes!
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Fix rose.ko oops on unload

2007-10-07 Thread David Miller
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Wed, 3 Oct 2007 22:54:13 +0400

> Quick'n'dirty fix to 100% oops on "rmmod rose". Do you want me to
> properly unwind everything before .24?

Patch applied, thanks Alexey.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH net-2.6.24] [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed

2007-10-07 Thread David Miller
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Thu, 4 Oct 2007 23:20:34 +0300 (EEST)

> Dave should apply both the three patch series fix and this one as well to 
> net-2.6.24 (Dave, in case you want me to resubmit, just ask... :-)). I'll 
> send one against .23-rc9 soon after this (sadly enough, it will cause a 
> conflict...).

Ok, all the net-2.6.24 bits are in, I'll take care of -stable...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/3] [TCP]: "Annotate" another fackets_out state reset

2007-10-07 Thread David Miller
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Wed,  3 Oct 2007 14:00:18 +0300

> This should no longer be necessary because fackets_out is
> accurate. It indicates bugs elsewhere, thus report it.
> 
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>

Applied, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] [TCP]: Comment fastpath_cnt_hint off-by-one trap

2007-10-07 Thread David Miller
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Wed,  3 Oct 2007 14:00:17 +0300

> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/3] [TCP]: Fix two off-by-one errors in fackets_out adjusting logic

2007-10-07 Thread David Miller
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Wed,  3 Oct 2007 14:00:16 +0300

> 1) Passing wrong skb to tcp_adjust_fackets_out could corrupt
> fastpath_cnt_hint as tcp_skb_pcount(next_skb) is not included
> to it if hint points exactly to the next_skb (it's lagging
> behind, see sacktag).
> 
> 2) When fastpath_skb_hint is put backwards to avoid dangling
> skb reference, the skb's pcount must also be removed from count
> (not included like above).
> 
> Reported by Cedric Le Goater <[EMAIL PROTECTED]>
> 
> Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>

Applied, thanks Ilpo.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NET] IPv6 oops bisected

2007-10-07 Thread Denis V. Lunev
David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Mon, 8 Oct 2007 14:19:42 +0800
> 
>> On Sun, Oct 07, 2007 at 11:16:08PM -0700, David Miller wrote:
>>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>>> index a7db84c..7109ad6 100644
>>> --- a/net/ipv6/route.c
>>> +++ b/net/ipv6/route.c
>>> @@ -1188,7 +1188,7 @@ int ip6_route_add(struct fib6_config *cfg)
>>> if ((cfg->fc_flags & RTF_REJECT) ||
>>> (dev && (dev->flags&IFF_LOOPBACK) && 
>>> !(addr_type&IPV6_ADDR_LOOPBACK))) {
>>> /* hold loopback dev/idev if we haven't done so. */
>>> -   if (dev != dev->nd_net->loopback_dev) {
>>> +   if (!dev || (dev != dev->nd_net->loopback_dev)) {
>>> if (dev) {
>>> dev_put(dev);
>>> in6_dev_put(idev);
>> Unfortunately this'll still oops a few lines down when it tries
>> to assign dev->nd_net->loopabck_dev to dev.  The issue here is
>> which namespace are we in if dev is NULL.
> 
> Good catch.
> 
> I'm just going to revert my bogus fix and the original change
> for now.  Denis can resubmit the original patch once this
> is resolved.

OK. I am installing Fedora 7 right now...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH][TG3]Some cleanups

2007-10-07 Thread David Miller
From: jamal <[EMAIL PROTECTED]>
Date: Sun, 07 Oct 2007 11:12:21 -0400

> Ok, attached patch against net-2.6.24 from this morning. I am setting up
> some equipment for testing as i type this - so i will test for any
> regressions. If you dont hear from me on the subject then all went ok.

This "cleanup" only makes sense if we go with your TX batching
interfaces.

They make the TX batching support patch for this driver "nice" and
"clean", but it makes zero sense in any other context.  In fact, it
adds more memory references in the TX pacth, and in fact does so by
adding usage of the skb->cb[] which the driver didn't need to do
previously.

So I'm going to hold off on this one for now, keep it in your TX
batching changes instead.

THanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 4/4][TG3]: Update version to 3.82.

2007-10-07 Thread David Miller
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 05 Oct 2007 20:38:13 -0700

> [TG3]: Update version to 3.82.
> 
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>

Also applied, thanks Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/4][TG3]: ASIC decoding and basic CPMU support.

2007-10-07 Thread David Miller
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 05 Oct 2007 20:37:38 -0700

> [TG3]: ASIC decoding and basic CPMU support.
> 
> Newer products change the way the ASIC revision is obtained.  This patch
> implements how the driver will extract the revision number.
> 
> This patch also adds preliminary CPMU support.  CPMU stands for Central
> Power Management Unit.  The CPMU's role is to put the chip into lower
> power states when the operating conditions allow it.
> 
> Signed-off-by: Matt Carlson <[EMAIL PROTECTED]>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/4][TG3]: Add 5784 and 5764 support.

2007-10-07 Thread David Miller
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 05 Oct 2007 20:37:54 -0700

> [TG3]: Add 5784 and 5764 support.
> 
> This patch adds the support for 5784 and 5764 devices.
> 
> Signed-off-by: Matt Carlson <[EMAIL PROTECTED]>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>

Applied.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/4][TG3]: Walk PCI capability lists.

2007-10-07 Thread David Miller
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 05 Oct 2007 20:37:02 -0700

> [TG3]: Walk PCI capability lists.
> 
> Newer tg3 devices shuffle around the registers in PCI configuration
> space.  This patch changes the way the driver accesses the PCI
> capabilities registers.  Hardcoded register locations are replaced with
> offsets from pci_find_capability() return values.
> 
> Signed-off-by: Matt Carlson <[EMAIL PROTECTED]>
> Signed-off-by: Michael Chan <[EMAIL PROTECTED]>

Applied.

This aspect of the driver always bugged me, but if these
capabilities would never move around in PCI config space
I was going to let sleeping dogs lie :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NET] IPv6 oops bisected

2007-10-07 Thread David Miller
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 8 Oct 2007 14:19:42 +0800

> On Sun, Oct 07, 2007 at 11:16:08PM -0700, David Miller wrote:
> >
> > diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> > index a7db84c..7109ad6 100644
> > --- a/net/ipv6/route.c
> > +++ b/net/ipv6/route.c
> > @@ -1188,7 +1188,7 @@ int ip6_route_add(struct fib6_config *cfg)
> > if ((cfg->fc_flags & RTF_REJECT) ||
> > (dev && (dev->flags&IFF_LOOPBACK) && 
> > !(addr_type&IPV6_ADDR_LOOPBACK))) {
> > /* hold loopback dev/idev if we haven't done so. */
> > -   if (dev != dev->nd_net->loopback_dev) {
> > +   if (!dev || (dev != dev->nd_net->loopback_dev)) {
> > if (dev) {
> > dev_put(dev);
> > in6_dev_put(idev);
> 
> Unfortunately this'll still oops a few lines down when it tries
> to assign dev->nd_net->loopabck_dev to dev.  The issue here is
> which namespace are we in if dev is NULL.

Good catch.

I'm just going to revert my bogus fix and the original change
for now.  Denis can resubmit the original patch once this
is resolved.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [patch 0/2] [AF_IUCV] fixes for net-2.6.24

2007-10-07 Thread David Miller
From: Ursula Braun <[EMAIL PROTECTED]>
Date: Thu, 04 Oct 2007 16:46:08 +0200

> the following 2 patches are intended for 2.6.24 and contain:
> - removal of static declarations in af_iucv header file
> - postpone receival of inbound packets in af_iucv

These patches don't apply, for one thing the first patch
rejects because the net-2.6.24 copy of include/net/iucv/af_iucv.h
has this line:

+static int  iucv_sock_create(struct socket *sock, int proto);

but the file you are patching against does not.

Please generate new clean patches against net-2.6.24, thank you.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NET] IPv6 oops bisected

2007-10-07 Thread Herbert Xu
On Sun, Oct 07, 2007 at 11:16:08PM -0700, David Miller wrote:
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index a7db84c..7109ad6 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1188,7 +1188,7 @@ int ip6_route_add(struct fib6_config *cfg)
>   if ((cfg->fc_flags & RTF_REJECT) ||
>   (dev && (dev->flags&IFF_LOOPBACK) && 
> !(addr_type&IPV6_ADDR_LOOPBACK))) {
>   /* hold loopback dev/idev if we haven't done so. */
> - if (dev != dev->nd_net->loopback_dev) {
> + if (!dev || (dev != dev->nd_net->loopback_dev)) {
>   if (dev) {
>   dev_put(dev);
>   in6_dev_put(idev);

Unfortunately this'll still oops a few lines down when it tries
to assign dev->nd_net->loopabck_dev to dev.  The issue here is
which namespace are we in if dev is NULL.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NET] IPv6 oops bisected

2007-10-07 Thread David Miller
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun, 07 Oct 2007 10:56:07 -0400

> /etc/sysconfig/network-scripts/network-functions-ipv6: line 246: 1760 Killed
>   LC_ALL=C /sbin/ip $options
> 
> 
> NULL pointer dereference at 0x03f8
> 
> backtrace:
> :ipv6:ip6_route_add+0x1b1/0x543

'dev' can be NULL in that code branch of ip6_route_add(),
yet we're deferencing it to get dev->nd_net.

if ((cfg->fc_flags & RTF_REJECT) ||
(dev && (dev->flags&IFF_LOOPBACK) && 
!(addr_type&IPV6_ADDR_LOOPBACK))) {
/* hold loopback dev/idev if we haven't done so. */
-   if (dev != init_net.loopback_dev) {
+   if (dev != dev->nd_net->loopback_dev) {

I'll add the appropriate check for NULL as follows:

commit b3c1427c21f9bac4ceaa02e875f3b2c9a5592132
Author: David S. Miller <[EMAIL PROTECTED]>
Date:   Sun Oct 7 23:15:56 2007 -0700

[IPV6]: Fix OOPS introduced by 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09.

In ip6_add_route(), 'dev' can be NULL, so check that before
we try to deref dev->nd_net.

Based upon a crash report by Jeff Garzik.

Signed-off-by: David S. Miller <[EMAIL PROTECTED]>

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a7db84c..7109ad6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1188,7 +1188,7 @@ int ip6_route_add(struct fib6_config *cfg)
if ((cfg->fc_flags & RTF_REJECT) ||
(dev && (dev->flags&IFF_LOOPBACK) && 
!(addr_type&IPV6_ADDR_LOOPBACK))) {
/* hold loopback dev/idev if we haven't done so. */
-   if (dev != dev->nd_net->loopback_dev) {
+   if (!dev || (dev != dev->nd_net->loopback_dev)) {
if (dev) {
dev_put(dev);
in6_dev_put(idev);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [git patches] net driver updates

2007-10-07 Thread David Miller
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 5 Oct 2007 14:20:08 -0400

> Please pull from 'upstream-davem' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
> upstream-davem
> 

Pulled, and pushed back out to net-2.6.24, thanks Jeff.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


NET_BATCH: some results

2007-10-07 Thread jamal

It seems prettier to just draw graphs and since this one is small file;
here it is attached. The graph demos a patched net-2.6.24 vs a plain
net-2.6.24 kernel with a udp app that sends on 4 CPUs as fast as the the
lower layers would allow it. 
Refer to my earlier description of the test setup etc.
As i noted earlier on, for this hardware at about 200B or so, we
approach wire speed, so the app is mostly idle above that as the link
becomes the bottleneck; example it is > 85% idle on 512B and > 90% idle
on 1024B. This is so for either batch or non-batch. So the
differentiation is really in the smaller sized packets.

Enjoy!

cheers,
jamal


batch-pps.pdf
Description: Adobe PDF document


Re: [PATCH 1/4] [NET_SCHED] explict hold dev tx lock

2007-10-07 Thread David Miller
From: jamal <[EMAIL PROTECTED]>
Date: Mon, 24 Sep 2007 19:38:19 -0400

> How is the policy to define the qdisc queues locked/mapped to tx rings? 

For these high performance 10Gbit cards it's a load balancing
function, really, as all of the transmit queues go out to the same
physical port so you could:

1) Load balance on CPU number.
2) Load balance on "flow"
3) Load balance on destination MAC

etc. etc. etc.

It's something that really sits logically between the qdisc and the
card, not something that is a qdisc thing.

In some ways it's similar to bonding, but using anything similar to
bonding's infrastructure (stacking devices) is way overkill for this.

And then we have the virtualization network devices where the queue
selection has to be made precisely, in order for the packet to
reach the proper destination, rather than a performance improvement.
It is also a situation where the TX queue selection is something
to be made between qdisc activity and hitting the device.

I think we will initially have to live with taking the centralized
qdisc lock for the device, get in and out of that as fast as possible,
then only take the TX queue lock of the queue selected.

After we get things that far we can try to find some clever lockless
algorithm for handling the qdisc to get rid of that hot spot.

These queue selection schemes want a common piece of generic code.  A
set of load balancing algorithms, a "select TX queue by MAC with a
default fallback on no match" for virtualization, and interfaces for
both drivers and userspace to change the queue selection scheme.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3][NET_BATCH] net core use batching

2007-10-07 Thread Krishna Kumar2
> jamal wrote:
>
> > > +   while ((skb = __skb_dequeue(skbs)) != NULL)
> > > +  q->ops->requeue(skb, q);
> >
> >
> > ->requeue queues at the head, so this looks like it would reverse
> > the order of the skbs.
>
> Excellent catch!  thanks; i will fix.
>
> As a side note: Any batching driver should _never_ have to requeue; if
> it does it is buggy. And the non-batching ones if they ever requeue will
> be a single packet, so not much reordering.

On the contrary, batching LLTX drivers (if that is not ruled out) will very
often requeue resulting in heavy reordering. Fix looks good though.

- KK

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] rtnl: Simplify ASSERT_RTNL

2007-10-07 Thread Patrick McHardy
Herbert Xu wrote:
> On Tue, Oct 02, 2007 at 05:29:11PM +0200, Patrick McHardy wrote:
> 
>>I think this doesn't completely fix it, when dev_unicast_add is
>>interrupted by dev_mc_add before the unicast changes are performed,
>>they will get committed in the dev_mc_add context, so we might still
>>call change_flags with BH disabled. Taking the TX lock around the
>>dev->uc_count and dev->uc_promisc checks and changes in __dev_set_rx_mode
>>should fix this.
> 
> 
> Good catch.  Digging back in history it seems that you added
> the change_rx_flags function so that the driver didn't have to
> do it under TX lock, right?


Yes, and to make sure the RTNL is held.

> The problem with this is that the stack can now call
> change_rx_flags and set_multicast_list simultaneously
> which presents a potential headache for the driver
> author (if they were to use change_rx_flags).


The change_rx_flags function was intended to be used by software
devices that want to synchronize flags to a different device,
in which case they shouldn't interfere since set_multicast_list
would only be used for the multicast list and not the flags.

> It seems to me what we could do is in fact separate out the
> part that adds the address and the part that syncs it with
> hardware.


That sounds like a really good idea to get rid of all the
confusion.

> That way we can call the hardware from a process context later
> and use the RTNL to guarantee that we only enter the driver
> once.
> 
> So dev_mc_add would look like:
> 
> 1) Hold some form of lock L.
> 2) Modify mc list A (a copy of the current mc list).
> 3) Drop lock.
> 4) Schedule an update to the hardware.
> 
> The update to the hardware would look lie:
> 
> 1) Hold RTNL.
> 2) Hold lock L.
> 3) Copy list A to list B (B would be our current list).
> 4) Drop lock L.
> 5) Call the hardware.
> 6) Drop RTNL.
> 
> For compatibility, set_multicast_list would still be invoked
> under the TX lock while set_rx_mode would do exactly the same
> thing but would only hold the RTNL.
> 
> What do you think about this approach?


Sounds great :)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] [343/2many] MAINTAINERS - IPVS

2007-10-07 Thread Simon Horman
On Sun, Aug 12, 2007 at 11:32:48PM -0700, [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
> 
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dbfdb75..a8fb231 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3300,6 +3300,8 @@ P:  Julian Anastasov
>  M:   [EMAIL PROTECTED]
>  L:   netdev@vger.kernel.org
>  S:   Maintained
> +F:   Documentation/networking/ipvs-sysctl.txt
> +F:   net/ipv4/ipvs

Should the following also be added:?

+F: include/net/ip_vs.h

>  
>  NFS CLIENT
>  P:   Trond Myklebust
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [BNX2X][PATCH 0/8] New driver for Broadcom 10Gb Ethernet, take two.

2007-10-07 Thread Matti Aarnio
On Sun, Oct 07, 2007 at 06:20:56PM +0200, Eliezer Tamir wrote:
> This is an initial version of the BNX2X, the Linux driver for the
> BCM5771X 10Gb Ethernet controller family.
> Although the chip is very different from the 5706-8 family we based the
> driver code on the BNX2 driver.
> Since the hardware is supposed to be generally available soon I have
> posted an initial version and after hearing all the comments I am reposting 
> with changes to address them.
> Some planned feature are still under development, but we want to get
> whatever we have out now so people can start using the HW.

Your patch-posting procedure is yet in a bit problem state..

 +{
 +static const u32 EVST_TSEM_FAST_MEMORY_COMMON_MEMORY_INIT_EMULATION_7[] = {
 +0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
 0x0, 0x0,
 +0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
 0x0, 0x0,
 +0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
 0x0, 0x0,

It does look like your Thunderbird 2.0 did wrap long text lines when you
included the texts into the posts.

The result is that currently your patches are not usable at all.

Your options:
   - instead of including the patch in message body, use Attach
   - use some other email program that does not scramble your texts
 (e.g. mutt + emacs)
   - publish the patch file on network somewhere, and just tell URL
 to that one in email

> Main changes from first version.
>
> * Fixed most issues raised by Michael Buesch. (Thanks Michael!)
> * Some slow path bug fixes.
> * Yitchak Gertner re-grouped the code in a more logical manner.
> * A lot of work was done to get the generated code to comply with coding 
> style requirements.
>
> Known issues/TODO.
> * Move slowpath event handling from tasklet to workqueue context. This will 
> allow replacing the busy waits in the link management code with sleeps.
>
> Please consider applying to 2.6.24
>
> Thanks
> Eliezer

/Matti Aarnio  -- one of  <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/5] forcedeth: interrupt handling cleanup

2007-10-07 Thread Jeff Garzik

Yinghai Lu wrote:

On 10/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:

Yinghai Lu wrote:

On 10/6/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:

commit a606d2a111cdf948da5d69eb1de5526c5c2dafef
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date:   Fri Oct 5 22:56:05 2007 -0400

[netdrvr] forcedeth: interrupt handling cleanup

* nv_nic_irq_optimized() and nv_nic_irq_other() were complete duplicates
  of nv_nic_irq(), with the exception of one function call.  Consolidate
  all three into a single interrupt handler, deleting a lot of redundant
  code.

* greatly simplify irq handler locking.

  Prior to this change, the irq handler(s) would acquire and release
  np->lock for each action (RX, TX, other events).

  For the common case -- RX or TX work -- the lock is always acquired,
  making all successive acquire/release combinations largely redundant.

  Acquire the lock at the beginning of the irq handler, and release it at
  the end of the irq handler.  This is simple, easy, and obvious.

* remove irq handler work loop.

  All interesting events emanating from the irq handler either have
  their own work loops, or they poke a timer into action.

  Therefore, delete the pointless master interrupt handler work loop.

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>


Do you have ideas/suggestions for a different method?


in the e1000 driver, it has seperate handler for msi and ioapic.

but in forcedeth, the nv_nic_irq_optimized keep check msi_flags...,
with num of msi interrupt number, that could cause cpu loading get a
little bit high..., even the network performance is ok.


With all the activity in the interrupt handler, a few in-cache branches 
are definitely going to be lost in the noise.


Separating the interrupt handlers between MSI and non-MSI tends to be of 
more benefit when the separation is accompanied by more efficient 
locking in the MSI interrupt handler, or a different mode of interrupt 
clear, or some other attribute.


Though CPU usage would be a good thing to measure, with these patches.

Jeff




-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/5] forcedeth: several proposed updates for testing

2007-10-07 Thread Jeff Garzik

Yinghai Lu wrote:

On 10/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:

Jeff Garzik wrote:

The 'fe-lock' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock

OK, I've successfully tested patches 1-5 on an AMD64 system with

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)


need to test that with mcp55 based, that will use MSI.


I would love to see an MSI-X test too (might have to turn on throughput 
mode).


Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/5] forcedeth: several proposed updates for testing

2007-10-07 Thread Yinghai Lu
On 10/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Jeff Garzik wrote:
> > The 'fe-lock' branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock
> OK, I've successfully tested patches 1-5 on an AMD64 system with
>
> 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)

need to test that with mcp55 based, that will use MSI.

YH
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/5] forcedeth: interrupt handling cleanup

2007-10-07 Thread Yinghai Lu
On 10/7/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Yinghai Lu wrote:
> > On 10/6/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >> commit a606d2a111cdf948da5d69eb1de5526c5c2dafef
> >> Author: Jeff Garzik <[EMAIL PROTECTED]>
> >> Date:   Fri Oct 5 22:56:05 2007 -0400
> >>
> >> [netdrvr] forcedeth: interrupt handling cleanup
> >>
> >> * nv_nic_irq_optimized() and nv_nic_irq_other() were complete 
> >> duplicates
> >>   of nv_nic_irq(), with the exception of one function call.  
> >> Consolidate
> >>   all three into a single interrupt handler, deleting a lot of 
> >> redundant
> >>   code.
> >>
> >> * greatly simplify irq handler locking.
> >>
> >>   Prior to this change, the irq handler(s) would acquire and release
> >>   np->lock for each action (RX, TX, other events).
> >>
> >>   For the common case -- RX or TX work -- the lock is always acquired,
> >>   making all successive acquire/release combinations largely redundant.
> >>
> >>   Acquire the lock at the beginning of the irq handler, and release it 
> >> at
> >>   the end of the irq handler.  This is simple, easy, and obvious.
> >>
> >> * remove irq handler work loop.
> >>
> >>   All interesting events emanating from the irq handler either have
> >>   their own work loops, or they poke a timer into action.
> >>
> >>   Therefore, delete the pointless master interrupt handler work loop.
> >>
> >> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
> >>
> Do you have ideas/suggestions for a different method?

in the e1000 driver, it has seperate handler for msi and ioapic.

but in forcedeth, the nv_nic_irq_optimized keep check msi_flags...,
with num of msi interrupt number, that could cause cpu loading get a
little bit high..., even the network performance is ok.

YH
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/3][NET_BATCH] kill dev->gso_skb

2007-10-07 Thread jamal
This patch removes dev->gso_skb as it is no longer necessary with
batching code.

cheers,
jamal
[NET_BATCH] kill dev->gso_skb
The batching code does what gso used to batch at the drivers.
There is no more need for gso_skb. If for whatever reason the
requeueing is a bad idea we are going to leave packets in dev->blist
(and still not need dev->gso_skb)

Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>

---
commit 7ebf50f0f43edd4897b88601b4133612fc36af61
tree 5d942ecebc14de6254ab3c812d542d524e148e92
parent cd602aa5f84fcef6359852cd99c95863eeb91015
author Jamal Hadi Salim <[EMAIL PROTECTED]> Sun, 07 Oct 2007 09:30:19 -0400
committer Jamal Hadi Salim <[EMAIL PROTECTED]> Sun, 07 Oct 2007 09:30:19 -0400

 include/linux/netdevice.h |3 ---
 net/sched/sch_generic.c   |   12 
 2 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index b31df5c..4ddc6eb 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -577,9 +577,6 @@ struct net_device
struct list_headqdisc_list;
unsigned long   tx_queue_len;   /* Max frames per queue allowed 
*/
 
-   /* Partially transmitted GSO packet. */
-   struct sk_buff  *gso_skb;
-
/* ingress path synchronizer */
spinlock_t  ingress_lock;
struct Qdisc*qdisc_ingress;
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 80ac56b..772e7fe 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -172,13 +172,6 @@ static int xmit_get_pkts(struct net_device *dev,
struct sk_buff *skb;
int count = dev->xmit_win;
 
-   if (count  && dev->gso_skb) {
-   skb = dev->gso_skb;
-   dev->gso_skb = NULL;
-   count -= xmit_count_skbs(skb);
-   __skb_queue_tail(pktlist, skb);
-   }
-
while (count > 0) {
skb = q->dequeue(q);
if (!skb)
@@ -659,7 +652,6 @@ void dev_activate(struct net_device *dev)
 void dev_deactivate(struct net_device *dev)
 {
struct Qdisc *qdisc;
-   struct sk_buff *skb;
 
spin_lock_bh(&dev->queue_lock);
qdisc = dev->qdisc;
@@ -667,15 +659,11 @@ void dev_deactivate(struct net_device *dev)
 
qdisc_reset(qdisc);
 
-   skb = dev->gso_skb;
-   dev->gso_skb = NULL;
if (!skb_queue_empty(&dev->blist))
skb_queue_purge(&dev->blist);
dev->xmit_win = 1;
spin_unlock_bh(&dev->queue_lock);
 
-   kfree_skb(skb);
-
dev_watchdog_down(dev);
 
/* Wait for outstanding dev_queue_xmit calls. */


[PATCH 2/3][NET_BATCH] net core use batching

2007-10-07 Thread jamal
This patch adds the usage of batching within the core.

cheers,
jamal



[NET_BATCH] net core use batching

This patch adds the usage of batching within the core.
Performance results demonstrating improvement are provided separately.

I have #if-0ed some of the old functions so the patch is more readable.
A future patch will remove all if-0ed content.
Patrick McHardy eyeballed a bug that will cause re-ordering in case
of a requeue.

Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>

---
commit cd602aa5f84fcef6359852cd99c95863eeb91015
tree f31d2dde4f138ff6789682163624bc0f8541aa77
parent 0a0762e2c615a980af284e86d9729d233e1bf7f4
author Jamal Hadi Salim <[EMAIL PROTECTED]> Sun, 07 Oct 2007 09:13:04 -0400
committer Jamal Hadi Salim <[EMAIL PROTECTED]> Sun, 07 Oct 2007 09:13:04 -0400

 net/sched/sch_generic.c |  132 +++
 1 files changed, 120 insertions(+), 12 deletions(-)

diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 95ae119..80ac56b 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -56,6 +56,7 @@ static inline int qdisc_qlen(struct Qdisc *q)
return q->q.qlen;
 }
 
+#if 0
 static inline int dev_requeue_skb(struct sk_buff *skb, struct net_device *dev,
  struct Qdisc *q)
 {
@@ -110,6 +111,97 @@ static inline int handle_dev_cpu_collision(struct sk_buff 
*skb,
 
return ret;
 }
+#endif
+
+static inline int handle_dev_cpu_collision(struct net_device *dev)
+{
+   if (unlikely(dev->xmit_lock_owner == smp_processor_id())) {
+   if (net_ratelimit())
+   printk(KERN_WARNING
+   "Dead loop on netdevice %s, fix it urgently!\n",
+   dev->name);
+   return 1;
+   }
+   __get_cpu_var(netdev_rx_stat).cpu_collision++;
+   return 0;
+}
+
+static inline int
+dev_requeue_skbs(struct sk_buff_head *skbs, struct net_device *dev,
+  struct Qdisc *q)
+{
+
+   struct sk_buff *skb;
+
+   while ((skb = __skb_dequeue_tail(skbs)) != NULL)
+   q->ops->requeue(skb, q);
+
+   netif_schedule(dev);
+   return 0;
+}
+
+static inline int
+xmit_islocked(struct sk_buff_head *skbs, struct net_device *dev,
+   struct Qdisc *q)
+{
+   int ret = handle_dev_cpu_collision(dev);
+
+   if (ret) {
+   if (!skb_queue_empty(skbs))
+   skb_queue_purge(skbs);
+   return qdisc_qlen(q);
+   }
+
+   return dev_requeue_skbs(skbs, dev, q);
+}
+
+static int xmit_count_skbs(struct sk_buff *skb)
+{
+   int count = 0;
+   for (; skb; skb = skb->next) {
+   count += skb_shinfo(skb)->nr_frags;
+   count += 1;
+   }
+   return count;
+}
+
+static int xmit_get_pkts(struct net_device *dev,
+  struct Qdisc *q,
+  struct sk_buff_head *pktlist)
+{
+   struct sk_buff *skb;
+   int count = dev->xmit_win;
+
+   if (count  && dev->gso_skb) {
+   skb = dev->gso_skb;
+   dev->gso_skb = NULL;
+   count -= xmit_count_skbs(skb);
+   __skb_queue_tail(pktlist, skb);
+   }
+
+   while (count > 0) {
+   skb = q->dequeue(q);
+   if (!skb)
+   break;
+
+   count -= xmit_count_skbs(skb);
+   __skb_queue_tail(pktlist, skb);
+   }
+
+   return skb_queue_len(pktlist);
+}
+
+static int xmit_prepare_pkts(struct net_device *dev,
+struct sk_buff_head *tlist)
+{
+   struct sk_buff *skb;
+   struct sk_buff_head *flist = &dev->blist;
+
+   while ((skb = __skb_dequeue(tlist)) != NULL)
+   xmit_prepare_skb(skb, dev);
+
+   return skb_queue_len(flist);
+}
 
 /*
  * NOTE: Called under dev->queue_lock with locally disabled BH.
@@ -130,22 +222,32 @@ static inline int handle_dev_cpu_collision(struct sk_buff 
*skb,
  * >0 - queue is not empty.
  *
  */
-static inline int qdisc_restart(struct net_device *dev)
+
+static inline int qdisc_restart(struct net_device *dev,
+   struct sk_buff_head *tpktlist)
 {
struct Qdisc *q = dev->qdisc;
-   struct sk_buff *skb;
-   int ret;
+   int ret = 0;
 
-   /* Dequeue packet */
-   if (unlikely((skb = dev_dequeue_skb(dev, q)) == NULL))
-   return 0;
+   /* use of tpktlist reduces the amount of time we sit
+* holding the queue_lock
+   */
+   ret = xmit_get_pkts(dev, q, tpktlist);
 
+   if (!ret)
+   return 0;
 
-   /* And release queue */
+   /* We got em packets */
spin_unlock(&dev->queue_lock);
 
+   /* prepare to embark, no locks held moves packets
+   * to dev->blist
+   * */
+   xmit_prepare_pkts(dev, tpktlist);
+
+   /* bye packets */
HARD_TX_LOCK(dev, smp_pr

[PATCHES] TX batching

2007-10-07 Thread jamal

Please provide feedback on the code and/or architecture.
Last time i posted them i received little. They are now updated to 
work with the latest net-2.6.24 from a few hours ago.

Patch 1: Introduces batching interface
Patch 2: Core uses batching interface
Patch 3: get rid of dev->gso_skb

What has changed since i posted last:
1) Fix a bug eyeballed by Patrick McHardy on requeue reordering.
2) Killed ->hard_batch_xmit() 
3) I am going one step back and making this set of patches even simpler
so i can make it easier to review.I am therefore killing dev->hard_prep_xmit()
and focussing just on batching. I plan to re-introduce dev->hard_prep_xmit()
but from now on i will make that a separate effort. (it seems to be creating
confusion in relation to the general work).

Dave please let me know if this meets your desires to allow devices
which are SG and able to compute CSUM benefit just in case i misunderstood. 
Herbert, if you can look at at least patch 3 i will appreaciate it
(since it kills dev->gso_skb that you introduced).

UPCOMING PATCHES
---
As before:
More patches to follow later if i get some feedback - i didnt want to 
overload people by dumping too many patches. Most of these patches 
mentioned below are ready to go; some need some re-testing and others 
need a little porting from an earlier kernel: 
- tg3 driver 
- tun driver
- pktgen
- netiron driver
- e1000 driver (LLTX)
- e1000e driver (non-LLTX)
- ethtool interface
- There is at least one other driver promised to me

Theres also a driver-howto i wrote that was posted on netdev last week
as well as one that describes the architectural decisions made.

PERFORMANCE TESTING

I started testing since yesterday, but these tests take a long time
so i will post results probably at the end of the day sometime and
may stop running more tests and just comparing batch vs non-batch results.
I have optimized the kernel-config so i expect my overall performance
numbers to look better than the last test results i posted for both
batch and non-batch.
My system under test hardware is still a 2xdual core opteron with a 
couple of tg3s. 
A test tool generates udp traffic of different sizes for upto 60 
seconds per run or a total of 30M packets. I have 4 threads each 
running on a specific CPU which keep all the CPUs as busy as they can 
sending packets targetted at a directly connected box's udp discard port.
All 4 CPUs target a single tg3 to send. The receiving box has a tc rule 
which counts and drops all incoming udp packets to discard port - this
allows me to make sure that the receiver is not the bottleneck in the
testing. Packet sizes sent are {8B, 32B, 64B, 128B, 256B, 512B, 1024B}. 
Each packet size run is repeated 10 times to ensure that there are no
transients. The average of all 10 runs is then computed and collected.

I do plan also to run forwarding and TCP tests in the future when the
dust settles.

cheers,
jamal

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 2.6.23-rc8-mm2 BUG: register_netdevice() issue as (ab)used by ISDN

2007-10-07 Thread Andreas Mohr
Hi,

On Sun, Oct 07, 2007 at 03:17:24PM +0200, Andreas Mohr wrote:
> I thus decided to now try plain 2.6.23-rc8 whether it's "corrupted", too.

OK, after 3 hours of compilation the ONLY datapoint I can give right now is:
1 (one) boot on 2.6.23-rc8-mm2 had the BUG in /var/log/messages,
1 (one) boot on 2.6.23-rc8 did NOT have it.

The two .config:s (I did a make oldconfig when going back to
non-mm2) don't seem to have any relevant differences.

I could offer to do more testing on this machine,
but this carries a slight risk for me since I (personally) won't have physical
access to it for a couple days and some people will kill me if the main
internet gateway happened to go down unfixably. ;)

Thanks,

Andreas Mohr
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: MSI interrupts and disable_irq

2007-10-07 Thread Manfred Spraul

Jeff Garzik wrote:


Interested parties should try the forcedeth patches I just posted :)

The patches look good, but I would still prefer to understand why the 
current implementation causes crashes before rewriting everything.


I've just noticed that netpoll_send_skb() calls ->hard_start_xmit() and 
->poll() within local_irq_save().
Thus it seems that  spin_lock_irqsave() must be used in the poll() and 
hard_start_xmit() callbacks, at least in nics that support 
POLL_CONTROLLER :-(


--
   Manfred

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: duplicated u32 filters in tc show output

2007-10-07 Thread jamal
On Sat, 2007-06-10 at 18:40 +0530, Abhijit Menon-Sen wrote:
> The HTB user guide (http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm)
> says the following:
> 
> Note: The U32 classifier has an undocumented design bug which causes
> duplicate entries to be listed by "tc filter show" when you use U32
> classifiers with different prio values.
> 
> What exactly is this bug? (I'm seeing its effects, i.e. the duplicates,
> and it's making my life a little difficult while trying to parse the tc
> output.)

If it is the bug i think it is - then it was fixed a long time ago; the
doc you are referencing seemed to be dated. 
Try a newer kernel if you are not and if it still persists, send the
simplest setup you have that causes duplicates.

cheers,
jamal


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[BNX2X][PATCH 7/8] bnx2x_self_test.h

2007-10-07 Thread Eliezer Tamir

bnx2x_self_test.h
This file contains a self-test derived from HW specs, and the code that 
prints HW/FW/BC assert codes.


Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED] 
>

---
drivers/net/bnx2x_self_test.h | 1387 
+

1 files changed, 1387 insertions(+), 0 deletions(-)

diff --git a/drivers/net/bnx2x_self_test.h b/drivers/net/bnx2x_self_test.h
new file mode 100644
index 000..b1d62e7
--- /dev/null
+++ b/drivers/net/bnx2x_self_test.h
@@ -0,0 +1,1387 @@
+/* bnx2x_self_test.h: Broadcom Everest network driver.
+ *
+ * Copyright (c) 2007 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+/* self test */
+static int bnx2x_idle_chk(struct bnx2x *bp)
+{
+ u32 val, i, val2;
+ u32 errors = 0;
+ u32 warnings = 0;
+ u32 varr[32];
+ u32 usem_foc_credits[4] = {26, 78, 16, 32};
+ u32 xsem_foc_credits[4] = {0, 24, 12, 102};
+ u32 csem_foc_credits[4] = {16, 18, 48, 14};
+ u32 tsem_foc_credits[4] = { 52, 24, 12, 32};
+ u32 foc_num = 0;
+ u8  err_pkt = 0;
+ u32 pci_reg;
+/* Disable timer scans for port 0,1 */
+/* is_enable_timer0 = lm_disable_timer(pdev, 0); */
+/* is_enable_timer1 = lm_disable_timer(pdev, 1); */
+
+
+/* Check errors on PCI configuration space ucorr_err_status 0x114 */
+/* check port 0 */
+ val = REG_RD(bp, GRCBASE_PXPCS, 0x2114);
+ if ((val & 0x1FF010) != 0x0) {
+ BNX2X_ERR("Error PCIE IP function %d,"
+" ucorr_err_status is not 0x0. Equal to 0x%x\n",
+bp->port, val);
+ err_pkt = 1;
+ errors++;
+ }
+
+ val = REG_RD(bp, GRCBASE_PXPCS, 0x2120);
+ if (((val & 0x31C1) != 0x2000) && ((val & 0x31C1) != 0)) {
+ BNX2X_ERR("Error PCIE IP function %d,"
+" corr_err_status is not 0x2000. Equal to 0x%x\n",
+bp->port, val);
+ err_pkt = 1;
+ errors++;
+ }
+
+ val = REG_RD(bp, GRCBASE_PXPCS, 0x2814);
+ if ((val != 0x40100) && (val != 0)) {
+ BNX2X_ERR("Error PCIE IP function %d,"
+" attentions register is not 0x40100. Equal to 0x%x\n",
+bp->port, val);
+ err_pkt = 1;
+ errors++;
+ }
+
+ if (err_pkt) {
+ pci_reg = 0x212c;
+ for (i = 0; i < 4; i++) {
+ val = REG_RD(bp, GRCBASE_PXPCS, pci_reg+i*4);
+ BNX2X_ERR("Error PCIE IP function %d,"
+" error packet header %d  Equal to 0x%x\n",
+bp->port, i, val);
+ }
+ }
+
+/* Check that all VQs in PXP are empty */
+ varr[0] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ0_ENTRY_CNT);
+ varr[1] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ1_ENTRY_CNT);
+ varr[2] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ2_ENTRY_CNT);
+ varr[3] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ3_ENTRY_CNT);
+ varr[4] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ4_ENTRY_CNT);
+ varr[5] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ5_ENTRY_CNT);
+ varr[6] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ6_ENTRY_CNT);
+ varr[7] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ7_ENTRY_CNT);
+ varr[8] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ8_ENTRY_CNT);
+ varr[9] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ9_ENTRY_CNT);
+ varr[10] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ10_ENTRY_CNT);
+ varr[11] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ11_ENTRY_CNT);
+ varr[12] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ12_ENTRY_CNT);
+ varr[13] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ13_ENTRY_CNT);
+ varr[14] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ14_ENTRY_CNT);
+ varr[15] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ15_ENTRY_CNT);
+ varr[16] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ16_ENTRY_CNT);
+ varr[17] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ17_ENTRY_CNT);
+ varr[18] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ18_ENTRY_CNT);
+ varr[19] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ19_ENTRY_CNT);
+ varr[20] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ20_ENTRY_CNT);
+ varr[21] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ21_ENTRY_CNT);
+ varr[22] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ22_ENTRY_CNT);
+ varr[23] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ23_ENTRY_CNT);
+ varr[24] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ24_ENTRY_CNT);
+ varr[25] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ25_ENTRY_CNT);
+ varr[26] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ26_ENTRY_CNT);
+ varr[27] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ27_ENTRY_CNT);
+ varr[28] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ28_ENTRY_CNT);
+ varr[29] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ29_ENTRY_CNT);
+ varr[30] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ30_ENTRY_CNT);
+ varr[31] = REG_RD(bp, GRCBASE_PXP2, PXP2_REGISTERS_RQ_VQ31_ENTRY_CNT);
+
+ for (i = 0; i < 32; i++) {
+ if (varr[i] != 0) {
+ if ((i == 3) && (varr[i] <= 2)) {
+ continue;
+ } else {
+ BNX2X_ERR("Error, PXP, VQ%d is not empty."
+   " Fill level equal to %d\n",
+   i, varr[i]);
+ errors++;
+ }
+ }
+ }
+
+/*

[BNX2X][PATCH 5/8] bnx2x_init.h

2007-10-07 Thread Eliezer Tamir

bnx2x_init.h - Various bits of init code.

Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED] 
>

---
drivers/net/bnx2x_init.h |  555 
++

1 files changed, 555 insertions(+), 0 deletions(-)

diff --git a/drivers/net/bnx2x_init.h b/drivers/net/bnx2x_init.h
new file mode 100644
index 000..c46f064
--- /dev/null
+++ b/drivers/net/bnx2x_init.h
@@ -0,0 +1,555 @@
+/* bnx2x_init.h: Broadcom Everest network driver.
+ *
+ * Copyright (c) 2007 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ *
+ * Written by: Eliezer Tamir <[EMAIL PROTECTED] 
>
+ */
+#ifndef EVEREST_INIT_FUNCTIONS_H

+#define EVEREST_INIT_FUNCTIONS_H
+
+#define COMMON 0x1
+#define PORT0  0x2
+#define PORT1  0x4
+
+#define INIT_EMULATION 0x1
+#define INIT_FPGA 0x2
+#define INIT_ASIC 0x4
+#define INIT_HARDWARE 0x7
+
+#define BLCNUM_PRS  0
+#define BLCNUM_SRCH 1
+#define BLCNUM_TSDM 2
+#define BLCNUM_TCM  3
+#define BLCNUM_BRB1 4
+#define BLCNUM_TSEM 5
+#define BLCNUM_PXPCS6
+#define BLCNUM_EMAC07
+#define BLCNUM_EMAC18
+#define BLCNUM_DBU  9
+#define BLCNUM_MISC 10
+#define BLCNUM_DBG  11
+#define BLCNUM_NIG  12
+#define BLCNUM_MCP  13
+#define BLCNUM_UPB  14
+#define BLCNUM_CSDM 15
+#define BLCNUM_USDM 16
+#define BLCNUM_CCM  17
+#define BLCNUM_UCM  18
+#define BLCNUM_USEM 19
+#define BLCNUM_CSEM 20
+#define BLCNUM_XPB  21
+#define BLCNUM_DQ   22
+#define BLCNUM_TIMERS   23
+#define BLCNUM_XSDM 24
+#define BLCNUM_QM   25
+#define BLCNUM_PBF  26
+#define BLCNUM_XCM  27
+#define BLCNUM_XSEM 28
+#define BLCNUM_CDU  29
+#define BLCNUM_DMAE 30
+#define BLCNUM_PXP  31
+#define BLCNUM_CFC  32
+#define BLCNUM_HC   33
+#define BLCNUM_PXP2 34
+#define BLCNUM_MISC_AEU 35
+
+
+static void bnx2x_reg_wr_ind(struct bnx2x *bp, u32 addr, u32 val);
+
+static void bnx2x_write_dmae(struct bnx2x *bp, dma_addr_t dma_addr,
+  u32 wb_addr, u32 wb_len);
+
+static int bnx2x_gunzip(struct bnx2x *bp, u8 *zbuf, int len);
+
+
+#define MEM_WR(block_addr, reg, value, len32) \
+do { \
+ int __i; \
+ for (__i = 0; __i < len32; __i++) { \
+ REG_WR(bp, block_addr, reg + __i*4, (((u32 *)(value))[__i])); \
+ if (!(__i % 1)) { \
+ touch_softlockup_watchdog(); \
+ cpu_relax(); \
+ } \
+ } \
+} while (0)
+
+#define MEM_IND(block_addr, reg, value, len32) \
+do { \
+ int __i; \
+ for (__i = 0; __i < len32; __i++) { \
+ REG_WR_IND(bp, block_addr, reg + __i*4, \
+ (((u32 *)(value))[__i])); \
+ if (!(__i % 1)) { \
+ touch_softlockup_watchdog(); \
+ cpu_relax(); \
+ } \
+ } \
+} while (0)
+
+#define _DMAE_WR(block_addr, reg, len32) \
+do { \
+ int __len32 = len32, offset = 0; \
+ while (__len32 > DMAE_LEN_MAX) { \
+/* DP(NETIF_MSG_DMAE, "DMAE_WR: offset %d  len32 %d\n", \
+offset, __len32); */ \
+ bnx2x_write_dmae(bp, bp->gunzip_mapping + offset, \
+ block_addr + reg + offset, DMAE_LEN_MAX); \
+ offset += DMAE_LEN_MAX * 4; \
+ __len32 -= DMAE_LEN_MAX; \
+ } \
+/* DP(NETIF_MSG_DMAE, "DMAE_WR: offset %d  len32 %d\n", offset, \
+__len32); */ \
+ bnx2x_write_dmae(bp, bp->gunzip_mapping + offset, \
+ block_addr + reg + offset, __len32); \
+} while (0)
+
+#define DMAE_WR(block_addr, reg, value, len32) \
+do { \
+/* DP(NETIF_MSG_DMAE, "DMAE_WR: block 0x%x  reg 0x%lx  len32 %d\n", \
+block_addr, reg, len32); */ \
+ memcpy(bp->gunzip_buf, value, (len32) * 4); \
+ _DMAE_WR(block_addr, reg, len32); \
+} while (0)
+
+#define DMAE_CLR(bp, block_addr, reg, len32) \
+do { \
+/* DP(NETIF_MSG_DMAE, "DMAE_CLR: block 0x%x  reg 0x%lx  len32 %d\n", \
+block_addr, reg, len32); */ \
+ memset(bp->gunzip_buf, 0, (len32) * 4); \
+ _DMAE_WR(block_addr, reg, len32); \
+} while (0)
+
+#define GUNZIP_DMAE_WR(block_addr, reg, value, len8) \
+do { \
+/* DP(NETIF_MSG_DMAE, "GUNZIP_DMAE_WR: block 0x%x  reg 0x%lx  len8 %d\n", \
+block_addr, reg, len8); */ \
+ bnx2x_gunzip(bp, (u8 *)(value), len8); \
+/* DP(NETIF_MSG_DMAE, "  ==> outlen %d\n", bp->gunzip_outlen); */ \
+ _DMAE_WR(block_addr, reg, bp->gunzip_outlen); \
+} while (0)
+
+
+#define INIT_INTERNAL0_MEM_WR(block_bar, block, reg, \
+   part, hw, value, off, len) \
+ INIT_MEM_WR(block, reg, part, hw, value, off, len);
+
+#define INIT_REG_WR(block, reg, value, part, hw) \
+do { \
+ if ((_block == BLCNUM_##block) && (_part == part) && (_hw & hw)) { \
+ REG_WR(bp, GRCBASE_##block, reg, value); \
+ usage++; \
+ } \
+} while (0)
+
+#define INIT_REG_RD(block, reg, value, part, hw) \
+do { \
+ u32 val; \
+ if ((_block == BLCNUM_##block) && (_part == part) && (_hw & hw)) { \
+ val = REG_RD(bp, GRCBASE_##block, reg); \
+ usage++; \
+ } \
+} while (0)
+
+#define INIT_MEM_WR(block, reg, part, hw, value, off, len) \
+do { \
+ if ((_block == BLCNUM_##block) && (

[BNx2X][PATCH 3/8] bnx2x.h

2007-10-07 Thread Eliezer Tamir

bnx2x.h - main .h file

Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED] 
>

---
drivers/net/bnx2x.h |  997 
+++

1 files changed, 997 insertions(+), 0 deletions(-)

diff --git a/drivers/net/bnx2x.h b/drivers/net/bnx2x.h
new file mode 100644
index 000..b7b2ceb
--- /dev/null
+++ b/drivers/net/bnx2x.h
@@ -0,0 +1,997 @@
+/* bnx2x.h: Broadcom Everest network driver.
+ *
+ * Copyright (c) 2007 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ *
+ * Written by: Eliezer Tamir <[EMAIL PROTECTED] 
>

+ * Based on code from Michael Chan's bnx2 driver
+ */
+
+
+#ifndef BNX2X_H
+#define BNX2X_H
+
+/* error/debug prints */
+
+#define DRV_MODULE_NAME "bnx2x"
+#define PFX DRV_MODULE_NAME ": "
+
+/* for messages that are currently off */
+#define BNX2X_MSG_OFF 0
+#define BNX2X_MSG_MCP 0x1 /* was: NETIF_MSG_HW */
+#define BNX2X_MSG_STATS 0x2 /* was: NETIF_MSG_TIMER */
+#define NETIF_MSG_NVM 0x4 /* was: NETIF_MSG_HW */
+#define NETIF_MSG_DMAE 0x8 /* was: NETIF_MSG_HW */
+
+#define DP_LEVEL KERN_NOTICE /* was: KERN_DEBUG */
+
+/* regular debug print */
+#define DP(__mask, __fmt, __args...) do { \
+ if (bp->msglevel & (__mask)) \
+ printk(DP_LEVEL "[%s:%d(%s)]" __fmt, __FUNCTION__, \
+ __LINE__, bp->dev?(bp->dev->name):"?", ##__args); \
+ } while (0)
+
+/* for errors (never masked) */
+#define BNX2X_ERR(__fmt, __args...) do { \
+ printk(KERN_ERR "[%s:%d(%s)]" __fmt, __FUNCTION__, \
+ __LINE__, bp->dev?(bp->dev->name):"?", ##__args); \
+ } while (0)
+
+/* before we have a dev->name use dev_info() */
+#define BNX2X_DEV_INFO(__fmt, __args...) do { \
+ if (bp->msglevel & NETIF_MSG_PROBE) \
+ dev_info(&bp->pdev->dev, __fmt, ##__args); \
+ } while (0)
+
+
+#ifdef BNX2X_STOP_ON_ERROR
+#define bnx2x_panic() do { \
+ bp->panic = 1; \
+ BNX2X_ERR("driver assert\n"); \
+ bnx2x_disable_int(bp); \
+ bnx2x_panic_dump(bp); \
+ } while (0)
+#else
+#define bnx2x_panic()
+#endif
+
+
+#define U64_LO(x) (((u64)x) & 0x)
+#define U64_HI(x) (((u64)x) >> 32)
+#define HILO_U64(hi, lo)(((u64)hi << 32) + lo)
+
+
+#define REG_ADDR(bp, block, offset) ((u8 *)bp->regview + block + offset)
+
+#define REG_RD(bp, block, offset) readl(REG_ADDR(bp, block, offset))
+#define REG_RD8(bp, block, offset) readb(REG_ADDR(bp, block, offset))
+#define REG_RD64(bp, block, offset) readq(REG_ADDR(bp, block, offset))
+
+#define REG_WR(bp, block, offset, val) \
+ writel((u32)val, REG_ADDR(bp, block, offset))
+#define REG_WR8(bp, block, offset, val) \
+ writeb((u8)val, REG_ADDR(bp, block, offset))
+#define REG_WR16(bp, block, offset, val) \
+ writew((u16)val, REG_ADDR(bp, block, offset))
+#define REG_WR32(bp, block, offset, val) REG_WR(bp, block, offset, val)
+
+#define REG_RD_IND(bp, block, offset) \
+ bnx2x_reg_rd_ind(bp, block + offset)
+#define REG_WR_IND(bp, block, offset, val) \
+ bnx2x_reg_wr_ind(bp, block + offset, val)
+
+#define REG_WR_DMAE(bp, block, offset, val, len32) \
+ do { \
+ memcpy(bnx2x_sp(bp, wb_data[0]), val, len32 * 4); \
+ bnx2x_write_dmae(bp, bnx2x_sp_mapping(bp, wb_data), \
+ block + offset, len32); \
+ } while (0)
+
+#define SHMEM_RD(bp, type) \
+ REG_RD(bp, bp->shmem_base, offsetof(struct shmem_region_t, type))
+#define SHMEM_WR(bp, type, val) \
+ REG_WR(bp, bp->shmem_base, offsetof(struct shmem_region_t, type), val)
+
+#define NIG_WR(reg, val) REG_WR(bp, GRCBASE_NIG, reg, val)
+#define EMAC_WR(reg, val) REG_WR(bp, emac_base, reg, val)
+#define BMAC_WR(reg, val) REG_WR(bp, GRCBASE_NIG, bmac_addr + reg, val)
+
+
+#define for_each_queue(bp, var) for (var = 0; var < bp->num_queues; var++)
+#ifdef BCM_MULTI
+#define for_each_nondefault_queue(bp, var) \
+ for (var = 1; var < bp->num_queues; var++)
+#define is_multi(bp) (bp->num_queues > 1)
+#endif
+
+
+struct regp {
+ u32 lo;
+ u32 hi;
+};
+
+struct bmac_stats {
+ struct regp tx_gtpkt;
+ struct regp tx_gtxpf;
+ struct regp tx_gtfcs;
+ struct regp tx_gtmca;
+ struct regp tx_gtgca;
+ struct regp tx_gtfrg;
+ struct regp tx_gtovr;
+ struct regp tx_gt64;
+ struct regp tx_gt127;
+ struct regp tx_gt255; /* 10 */
+ struct regp tx_gt511;
+ struct regp tx_gt1023;
+ struct regp tx_gt1518;
+ struct regp tx_gt2047;
+ struct regp tx_gt4095;
+ struct regp tx_gt9216;
+ struct regp tx_gt16383;
+ struct regp tx_gtmax;
+ struct regp tx_gtufl;
+ struct regp tx_gterr; /* 20 */
+ struct regp tx_gtbyt;
+
+ struct regp rx_gr64;
+ struct regp rx_gr127;
+ struct regp rx_gr255;
+ struct regp rx_gr511;
+ struct regp rx_gr1023;
+ struct regp rx_gr1518;
+ struct regp rx_gr2047;
+ struct regp rx_gr4095;
+ struct regp rx_gr9216; /* 30 */
+ struct regp rx_gr16383;
+ struct regp rx_grmax;
+ struct regp rx_grpkt;
+ struct regp rx_grfcs;
+ struct regp rx_grmca;
+ struct regp rx_grbca;
+ struct regp rx_grxcf;
+ struct regp rx_grxpf;
+ struct regp rx_gr

[BNX2X][PATCH 1/8] add bnx2x to Kconfig and Makefile

2007-10-07 Thread Eliezer Tamir

Add bnx2x to Kconfig and Makefile

Signed-off-by: Eliezer Tamir <[EMAIL PROTECTED]>
---
drivers/net/Kconfig  |9 +
drivers/net/Makefile |1 +
2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 467532c..fbb69ac 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2630,6 +2630,15 @@ config TEHUTI
help
 Tehuti Networks 10G Ethernet NIC

+config BNX2X
+ tristate "Broadcom NetXtremeII XGb support"
+ depends on PCI
+ help
+   This driver supports Broadcom NetXtremeII 10 gigabit Ethernet cards.
+
+   To compile this driver as a module, choose M here: the module
+   will be called bnx2x.  This is recommended.
+
endif # NETDEV_1

source "drivers/net/tokenring/Kconfig"
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6220c50..51f3ea7 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_STNIC) += stnic.o 8390.o
obj-$(CONFIG_FEALNX) += fealnx.o
obj-$(CONFIG_TIGON3) += tg3.o
obj-$(CONFIG_BNX2) += bnx2.o
+obj-$(CONFIG_BNX2X) += bnx2x.o
spidernet-y += spider_net.o spider_net_ethtool.o
obj-$(CONFIG_SPIDER_NET) += spidernet.o sungem_phy.o
obj-$(CONFIG_GELIC_NET) += ps3_gelic.o
--
1.4.2




-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[BNX2X][PATCH 0/8] New driver for Broadcom 10Gb Ethernet, take two.

2007-10-07 Thread Eliezer Tamir

This is an initial version of the BNX2X, the Linux driver for the
BCM5771X 10Gb Ethernet controller family.

Although the chip is very different from the 5706-8 family we based the
driver code on the BNX2 driver.

Since the hardware is supposed to be generally available soon I have
posted an initial version and after hearing all the comments I am 
reposting with changes to address them.


Some planned feature are still under development, but we want to get
whatever we have out now so people can start using the HW.

Main changes from first version.

* Fixed most issues raised by Michael Buesch. (Thanks Michael!)
* Some slow path bug fixes.
* Yitchak Gertner re-grouped the code in a more logical manner.
* A lot of work was done to get the generated code to comply with coding 
style requirements.


Known issues/TODO.
* Move slowpath event handling from tasklet to workqueue context. This 
will allow replacing the busy waits in the link management code with sleeps.


Please consider applying to 2.6.24

Thanks
Eliezer




-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH][E1000E] some cleanups

2007-10-07 Thread jamal

Ok, here you go; the explanation is below. This is from net-2.6.24 of
early this AM. I saw a patch you posted that is derived from Krishna;
although it hasnt showed up in the tree - i have considered those
changes and this patch adds a little more optimization in case of
errors.

I will send you a patch to kill LLTX the sooner this shows up somewhere.

cheers,
jamal

On Wed, 2007-03-10 at 09:18 -0400, jamal wrote:

> The cleanup is to break up the code so it is functionally more readable
> from a perspective of the 4 distinct parts in ->hard_start_xmit():
> 
> a) packet formatting (example: vlan, mss, descriptor counting, etc.)
> b) chip-specific formatting
> c) enqueueing the packet on a DMA ring
> d) IO operations to complete packet transmit, tell DMA engine to chew
> on, tx completion interrupts, set last tx time, etc.
> 
> Each of those steps sitting in different functions accumulates state
> that is used in the next steps. cb stores this state because it a
> scratchpad the driver owns. You could create some other structure and
> pass it around the iteration, but why waste more bytes.

diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 4a21d7d..26d35bb 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3417,51 +3417,60 @@ static int e1000_maybe_stop_tx(struct net_device *netdev, int size)
 	return __e1000_maybe_stop_tx(netdev, size);
 }
 
+/* This structure cannot be larger than 40B given it uses skb->cb[8] */
+struct e1000_tx_cbdata {
+	int count;
+	unsigned int max_per_txd;
+	unsigned int nr_frags;
+	unsigned int mss;
+	unsigned int tx_flags;
+};
+
+/* we avoid cb[0] because it is used by VLAN cookie
+ * struct vlan_skb_tx_cookie
+*/
+#define E1000_SKB_CB(__skb)   ((struct e1000_tx_cbdata *)&((__skb)->cb[8]))
+#define NETDEV_TX_DROPPED   -5
 #define TXD_USE_COUNT(S, X) (((S) >> (X)) + 1 )
-static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
+
+static int e1000_prep_frame(struct sk_buff *skb, struct net_device *netdev)
 {
 	struct e1000_adapter *adapter = netdev_priv(netdev);
-	struct e1000_ring *tx_ring = adapter->tx_ring;
-	unsigned int first;
-	unsigned int max_per_txd = E1000_MAX_PER_TXD;
-	unsigned int max_txd_pwr = E1000_MAX_TXD_PWR;
-	unsigned int tx_flags = 0;
 	unsigned int len = skb->len;
-	unsigned long irq_flags;
-	unsigned int nr_frags = 0;
-	unsigned int mss = 0;
-	int count = 0;
-	int tso;
+	unsigned int max_txd_pwr; 
+	struct e1000_tx_cbdata *cb;
 	unsigned int f;
-	len -= skb->data_len;
-
-	if (test_bit(__E1000_DOWN, &adapter->state)) {
-		dev_kfree_skb_any(skb);
-		return NETDEV_TX_OK;
-	}
 
 	if (skb->len <= 0) {
 		dev_kfree_skb_any(skb);
-		return NETDEV_TX_OK;
+		return NETDEV_TX_DROPPED;
 	}
 
-	mss = skb_shinfo(skb)->gso_size;
+	max_txd_pwr = E1000_MAX_TXD_PWR;
+	cb = E1000_SKB_CB(skb);
+	cb->nr_frags = 0;
+	cb->mss = 0;
+	cb->count = 0;
+	cb->max_per_txd = E1000_MAX_PER_TXD;
+
+	len -= skb->data_len;
+	cb->mss = skb_shinfo(skb)->gso_size;
 	/* The controller does a simple calculation to
 	 * make sure there is enough room in the FIFO before
 	 * initiating the DMA for each buffer.  The calc is:
 	 * 4 = ceil(buffer len/mss).  To make sure we don't
 	 * overrun the FIFO, adjust the max buffer len if mss
 	 * drops. */
-	if (mss) {
+	if (cb->mss) {
 		u8 hdr_len;
-		max_per_txd = min(mss << 2, max_per_txd);
-		max_txd_pwr = fls(max_per_txd) - 1;
+		cb->max_per_txd = min(cb->mss << 2, cb->max_per_txd);
+		max_txd_pwr = fls(cb->max_per_txd) - 1;
 
 		/* TSO Workaround for 82571/2/3 Controllers -- if skb->data
 		* points to just header, pull a few bytes of payload from
 		* frags into skb->data */
 		hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
-		if (skb->data_len && (hdr_len == (skb->len - skb->data_len))) {
+		if (skb->data_len && (hdr_len == len )) {
 			unsigned int pull_size;
 
 			pull_size = min((unsigned int)4, skb->data_len);
@@ -3469,43 +3478,66 @@ static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
 ndev_err(netdev,
 	 "__pskb_pull_tail failed.\n");
 dev_kfree_skb_any(skb);
-return NETDEV_TX_OK;
+return NETDEV_TX_DROPPED;
 			}
 			len = skb->len - skb->data_len;
 		}
 	}
 
 	/* reserve a descriptor for the offload context */
-	if ((mss) || (skb->ip_summed == CHECKSUM_PARTIAL))
-		count++;
-	count++;
+	if ((cb->mss) || (skb->ip_summed == CHECKSUM_PARTIAL))
+		cb->count++;
+	cb->count++;
 
-	count += TXD_USE_COUNT(len, max_txd_pwr);
+	cb->count += TXD_USE_COUNT(len, max_txd_pwr);
 
-	nr_frags = skb_shinfo(skb)->nr_frags;
-	for (f = 0; f < nr_frags; f++)
-		count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size,
+	cb->nr_frags = skb_shinfo(skb)->nr_frags;
+	for (f = 0; f < cb->nr_frags; f++)
+		cb->count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size,
    max_txd_pwr);
 
 	if (adapter->hw.mac.tx_pkt_filtering)
 		e1000_transfer_dhcp_info(adapter, skb);
 
+	if (adapter->vlgrp && vlan_tx_tag_present(skb)) {
+		cb->tx_flags |= 

Re: [PATCH][TG3]Some cleanups

2007-10-07 Thread jamal
On Wed, 2007-03-10 at 09:18 -0400, jamal wrote:
> On Tue, 2007-02-10 at 16:33 -0700, Michael Chan wrote:
> 
> > Seems ok to me.  I think we should make it more clear that we're
> > skipping over the VLAN tag:
> > 
> > (struct tg3_tx_cbdata *)&((__skb)->cb[sizeof(struct vlan_skb_tx_cookie)])
> > 
> 
> Will do - thanks Michael.

Ok, attached patch against net-2.6.24 from this morning. I am setting up
some equipment for testing as i type this - so i will test for any
regressions. If you dont hear from me on the subject then all went ok.

cheers,
jamal

[TG3] Some cleanups
Make the xmit path code better functionally organized and more readable.
Matt Carlson contributed the moving of the VLAN formatting into
_prep_frame() portion and Michael Chan eyeballed the patch and
made it better.

Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>

---
commit 190674ff1fe0b7bddf038c2bfddf45b9c6418e2a
tree d6f03d10d94a39ad22fd590b30c6d50c81f3eb5c
parent 0a14acec89454d350c1bd141b3309df421433f3c
author Jamal Hadi Salim <[EMAIL PROTECTED]> Sun, 07 Oct 2007 08:10:32 -0400
committer Jamal Hadi Salim <[EMAIL PROTECTED]> Sun, 07 Oct 2007 08:10:32 -0400

 drivers/net/tg3.c |  281 -
 1 files changed, 172 insertions(+), 109 deletions(-)

diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index d4ac6e9..ce6f02f 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3910,47 +3910,72 @@ static void tg3_set_txd(struct tg3 *tp, int entry,
txd->vlan_tag = vlan_tag << TXD_VLAN_TAG_SHIFT;
 }
 
-/* hard_start_xmit for devices that don't have any bugs and
- * support TG3_FLG2_HW_TSO_2 only.
- */
-static int tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
+struct tg3_tx_cbdata {
+   u32 base_flags;
+   unsigned int mss;
+};
+/* using cb[8] skips over the VLAN tag:
+ * (struct tg3_tx_cbdata *)&((__skb)->cb[sizeof(struct vlan_skb_tx_cookie)])
+*/
+#define TG3_SKB_CB(__skb)   ((struct tg3_tx_cbdata *)&((__skb)->cb[8]))
+#define NETDEV_TX_DROPPED   -5
+
+static int tg3_prep_bug_frame(struct sk_buff *skb, struct net_device *dev)
 {
+   struct tg3_tx_cbdata *cb = TG3_SKB_CB(skb);
+#if TG3_VLAN_TAG_USED
struct tg3 *tp = netdev_priv(dev);
-   dma_addr_t mapping;
-   u32 len, entry, base_flags, mss;
+   u32 vlantag = 0;
 
-   len = skb_headlen(skb);
+   if (tp->vlgrp != NULL && vlan_tx_tag_present(skb))
+   vlantag = (TXD_FLAG_VLAN | (vlan_tx_tag_get(skb) << 16));
 
-   /* We are running in BH disabled context with netif_tx_lock
-* and TX reclaim runs via tp->napi.poll inside of a software
-* interrupt.  Furthermore, IRQ processing runs lockless so we have
-* no IRQ context deadlocks to worry about either.  Rejoice!
-*/
-   if (unlikely(tg3_tx_avail(tp) <= (skb_shinfo(skb)->nr_frags + 1))) {
-   if (!netif_queue_stopped(dev)) {
-   netif_stop_queue(dev);
+   cb->base_flags = vlantag;
+#endif
 
-   /* This is a hard error, log it. */
-   printk(KERN_ERR PFX "%s: BUG! Tx Ring full when "
-  "queue awake!\n", dev->name);
+   cb->mss = skb_shinfo(skb)->gso_size;
+   if (cb->mss != 0) {
+   if (skb_header_cloned(skb) &&
+   pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
+   dev_kfree_skb(skb);
+   return NETDEV_TX_DROPPED;
}
-   return NETDEV_TX_BUSY;
+
+   cb->base_flags |= (TXD_FLAG_CPU_PRE_DMA |
+  TXD_FLAG_CPU_POST_DMA);
}
 
-   entry = tp->tx_prod;
-   base_flags = 0;
-   mss = 0;
-   if ((mss = skb_shinfo(skb)->gso_size) != 0) {
+   if (skb->ip_summed == CHECKSUM_PARTIAL)
+   cb->base_flags |= TXD_FLAG_TCPUDP_CSUM;
+
+   return NETDEV_TX_OK;
+}
+
+static int tg3_prep_frame(struct sk_buff *skb, struct net_device *dev)
+{
+   struct tg3_tx_cbdata *cb = TG3_SKB_CB(skb);
+#if TG3_VLAN_TAG_USED
+   struct tg3 *tp = netdev_priv(dev);
+   u32 vlantag = 0;
+
+   if (tp->vlgrp != NULL && vlan_tx_tag_present(skb))
+   vlantag = (TXD_FLAG_VLAN | (vlan_tx_tag_get(skb) << 16));
+
+   cb->base_flags = vlantag;
+#endif
+
+   cb->mss = skb_shinfo(skb)->gso_size;
+   if (cb->mss != 0) {
int tcp_opt_len, ip_tcp_len;
 
if (skb_header_cloned(skb) &&
pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
dev_kfree_skb(skb);
-   goto out_unlock;
+   return NETDEV_TX_DROPPED;
}
 
if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
-   mss |= (skb_headlen(skb) - ETH_HLEN) << 9;
+   cb->mss |= (skb_headlen(skb) - ETH_HLEN) << 9;
else {
struct iphdr *iph = ip_hdr(skb);
 

Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection

2007-10-07 Thread Ilpo Järvinen
...Dropped DaveM from cc, I guess he knows the things I describe below 
already... :-)

On Sat, 6 Oct 2007, David Miller wrote:

> From: TAKANO Ryousei <[EMAIL PROTECTED]>
> Date: Sun, 07 Oct 2007 14:51:00 +0900 (JST)
> 
> > BTW, what is difference among netdev-2.6, 

netdev-2.6 is for network device drivers (stuff under drivers/net)

> net-2.6 (net-2.6.24), and 
> > tcp-2.6? I am not familiar with linux kernel development process.
> 
> net-2.6.24 tree is current new development
> 
> net-2.6 tree is only bug fixes
> 
> tcp-2.6 is an old abandonded tree that holds lots of old
> TCP work, most of which is merged already, but one part
> (my RB-Tree SACK patches) are not integrated yet.

In addition, when Linus releases a new kernel (2.6.23), the net-2.6.24 
becomes net-2.6 (the old one ceases to exist). At some point of 2.6.24-rc 
series, net-2.6.25 gets opened by DaveM, usually it's not available right 
after closure of 2.6.24 merge window. ...Then again, the trees are 
again rotated when a next official release is made...


-- 
 i.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NET] IPv6 oops bisected

2007-10-07 Thread Jeff Garzik

Denis V. Lunev wrote:

Jeff Garzik wrote:

Jeff Garzik wrote:

The commit

commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09
Author: Denis V. Lunev <[EMAIL PROTECTED]>
Date:   Thu Sep 27 12:41:26 2007 -0700

[NET]: Various dst_ifdown routines to catch refcounting bugs

causes a 100% reproducible oops in net-2.6.24.git, in ip6_route_add().

Platform: x86-64 Fedora 7

Config and lspci attached.

And indeed, reverting this commit with 'patch -R' makes things work again.

Jeff


Can you me command to execute to reproduce the problem? and oops if
possible.


The command is Fedora 7 initscripts...

(typing in by hand)

/etc/sysconfig/network-scripts/network-functions-ipv6: line 246: 1760 Killed
LC_ALL=C /sbin/ip $options


NULL pointer dereference at 0x03f8

backtrace:
:ipv6:ip6_route_add+0x1b1/0x543
rtnetlink_rcv_msg
inet6_rtm_newroute
netlink_run_queue
rtnetlink_rcv
netlink_data_ready
netlink_sendskb
netlink_sendmsg
sock_send_msg
mntput_no_expire
autoremove_wake_function
find_lock_page
zone_statistics
get_page_from_freelist
__alloc_pages
move_addr_to_kernel
verify_iovec
sys_sendmsg
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/5] forcedeth: several proposed updates for testing

2007-10-07 Thread Jeff Garzik

Jeff Garzik wrote:

The 'fe-lock' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git fe-lock

contains the following changes that I would like to get tested:

  [netdrvr] forcedeth: make NAPI unconditional
  [netdrvr] forcedeth: interrupt handling cleanup
  [netdrvr] forcedeth: process TX completions using NAPI
  [netdrvr] forcedeth: internal simplification and cleanups
  [netdrvr] forcedeth: timer overhaul


OK, I've successfully tested patches 1-5 on an AMD64 system with

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)

A trivial s/napi/tx_napi/ fix must be applied to patch #3 (sent in 
separate email).  Once that is done, the patchset works flawlessly here, 
passing simple RX, TX, RX+TX TCP stress tests.


I never ran into any TX problems, of the type hinted at by the "Known 
bugs" section at the top of forcedeth.c.  Either (a) my chip does not 
have that bug, (b) my chip needs DEV_NEED_TIMERIRQ for other reasons, or 
(c) the issue is not a hardware issue but a driver bug that is now fixed.


I'm going to hope its (c),   But only testing will tell.

Jeff


P.S.  Depending on when this gets fixed, you might have to revert 
net-2.6.24.git commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09 ("[NET]: 
Various dst_ifdown routines to catch refcounting bugs").

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 6/n] forcedeth: protect slow path with mutex

2007-10-07 Thread Jeff Garzik

Jeff Garzik wrote:

commit abca163a14b28c234df9bf38034bc967ff81c3aa
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date:   Sun Oct 7 07:22:14 2007 -0400

[netdrvr] forcedeth: wrap slow path hw manipulation inside hw_mutex

* This makes sure everybody who wants to start/stop the RX and TX engines

  first acquires this mutex.

* tx_timeout code was deleted, replaced by scheduling reset_task.

* linkchange moved to a workqueue (always inside hw_mutex)

* simplified irq handling a bit

* make sure to disable workqueues before NAPI

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>


 drivers/net/forcedeth.c |  272 ++--
 1 file changed, 175 insertions(+), 97 deletions(-)


You will need the attached patch to even build (oops).

Also, testing shows there is a mutex deadlock somewhere.

diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index d1c1efa..91926b1 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2929,6 +2929,7 @@ static void nv_linkchange_task(struct work_struct *work)
 
 static void nv_link_irq(struct net_device *dev)
 {
+   struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
u32 miistat;
 
@@ -4378,6 +4379,7 @@ static int nv_ethtool_begin (struct net_device *dev)
struct fe_priv *np = get_nvpriv(dev);
 
mutex_lock(&np->hw_mutex);
+   return 0;
 }
 
 static void nv_ethtool_complete (struct net_device *dev)


Re: [PATCH 3/5] forcedeth: process TX completions using NAPI

2007-10-07 Thread Jeff Garzik

Jeff Garzik wrote:

commit 57cbfacc00d69be2ba02b65d1021442273b76263
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date:   Fri Oct 5 23:25:56 2007 -0400

[netdrvr] forcedeth: process TX completions using NAPI

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>


 drivers/net/forcedeth.c |  143 +++-
 1 file changed, 83 insertions(+), 60 deletions(-)


The attached patch fixes an obvious bug.  Once applied, TX NAPI actually 
works :)



diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 1c236e6..e25c05e 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -3059,7 +3059,7 @@ static irqreturn_t nv_nic_irq_tx(int foo, void *data)
 
 static int nv_napi_tx_poll(struct napi_struct *napi, int budget)
 {
-   struct fe_priv *np = container_of(napi, struct fe_priv, napi);
+   struct fe_priv *np = container_of(napi, struct fe_priv, tx_napi);
struct net_device *dev = np->dev;
u8 __iomem *base = get_hwbase(dev);
unsigned long flags;


Re: [NET] IPv6 oops bisected

2007-10-07 Thread Denis V. Lunev
Jeff Garzik wrote:
> Jeff Garzik wrote:
>> The commit
>>
>> commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09
>> Author: Denis V. Lunev <[EMAIL PROTECTED]>
>> Date:   Thu Sep 27 12:41:26 2007 -0700
>>
>> [NET]: Various dst_ifdown routines to catch refcounting bugs
>>
>> causes a 100% reproducible oops in net-2.6.24.git, in ip6_route_add().
>>
>> Platform: x86-64 Fedora 7
>>
>> Config and lspci attached.
> 
> And indeed, reverting this commit with 'patch -R' makes things work again.
> 
> Jeff

Can you me command to execute to reproduce the problem? and oops if
possible.

Regards,
Den
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [NET] IPv6 oops bisected

2007-10-07 Thread Jeff Garzik

Jeff Garzik wrote:

The commit

commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09
Author: Denis V. Lunev <[EMAIL PROTECTED]>
Date:   Thu Sep 27 12:41:26 2007 -0700

[NET]: Various dst_ifdown routines to catch refcounting bugs

causes a 100% reproducible oops in net-2.6.24.git, in ip6_route_add().

Platform: x86-64 Fedora 7

Config and lspci attached.


And indeed, reverting this commit with 'patch -R' makes things work again.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 2.6.23-rc8-mm2 BUG: register_netdevice() issue as (ab)used by ISDN

2007-10-07 Thread Andreas Mohr
On Sun, Oct 07, 2007 at 08:24:45AM -0400, Jeff Garzik wrote:
> It definitely looks like ISDN is somehow to blame.  Any chance you could 
> try git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.24.git ?

I'm afraid I won't make it, since this server is not at my home
location, is a ""production"" server and takes only exactly 200 minutes
for a kernel build (K6-3/150).

I thus decided to now try plain 2.6.23-rc8 whether it's "corrupted", too.

> That would help narrow down the problem to a very-large set of 
> networking changes pending for 2.6.24.

...only if I have a known-working very recent version, which is exactly
the problem now.

Andreas Mohr
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[NET] IPv6 oops bisected

2007-10-07 Thread Jeff Garzik

The commit

commit 5f5dace1ce001b24fb8286e09ffd3c4d2b547e09
Author: Denis V. Lunev <[EMAIL PROTECTED]>
Date:   Thu Sep 27 12:41:26 2007 -0700

[NET]: Various dst_ifdown routines to catch refcounting bugs

causes a 100% reproducible oops in net-2.6.24.git, in ip6_route_add().

Platform: x86-64 Fedora 7

Config and lspci attached.

00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio 
Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
05:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 
Controller (PHY/Link)
40:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
40:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
40:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
40:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
41:04.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] 
(rev a3)
61:04.0 SCSI storage controller: Marvell Technology Group Ltd. Unknown device 
6042 (rev 02)
61:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X 
Fusion-MPT Dual Ultra320 SCSI (rev 07)
61:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X 
Fusion-MPT Dual Ultra320 SCSI (rev 07)
80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc9
# Sun Oct  7 08:44:56 2007
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_ZONE_DMA32=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_DMI=y
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CPUSETS is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG

Re: 2.6.23-rc8-mm2 BUG: register_netdevice() issue as (ab)used by ISDN

2007-10-07 Thread Jeff Garzik

Andreas Mohr wrote:

I intend to still try to get it up and running with 2.6.23-rc8-mm2 today
(with some workarounds hopefully, maybe even disabling ISDN completely)...

The last running kernel (I didn't have newer ones in between), up for some 110
days was 2.6.19-cks2 (IOW, I cannot quite say that
"this is an important regression, it has been broken very recently").



It definitely looks like ISDN is somehow to blame.  Any chance you could 
try git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.24.git ?


That would help narrow down the problem to a very-large set of 
networking changes pending for 2.6.24.


If you can isolate it to net-2.6.24, it should be easily bisect-able 
from there, if you have the patience :)


Jeff


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


2.6.23-rc8-mm2 BUG: register_netdevice() issue as (ab)used by ISDN

2007-10-07 Thread Andreas Mohr
[not necessarily a very recent regression, used 2.6.19 kernels before...]

Hi all,

wondered why my main internet server (headless!) didn't come up properly
on a new 2.6.23-rc8-mm2
(connections almost completely refused: firewalling not executed due to
earlier OOPS?).
Upon LILO emergency fallback into an older version (2.6.16...) saw this
in /var/log/messages:

Oct  7 13:07:34 gate kernel: e100: Intel(R) PRO/100 Network Driver, 
3.5.23-k4-NAPI
Oct  7 13:07:34 gate kernel: e100: Copyright(c) 1999-2006 Intel Corporation
Oct  7 13:07:34 gate kernel: Atmel at76x USB Wireless LAN Driver 0.16 loading
Oct  7 13:07:34 gate kernel: eth2: MAC address 00:05:5d:95:ab:f0
Oct  7 13:07:34 gate kernel: eth2: firmware version 1.101.5-84
Oct  7 13:07:34 gate kernel: eth2: regulatory domain 0x30: ETSI (most of Europe)
Oct  7 13:07:34 gate kernel: usbcore: registered new interface driver at76_usb
Oct  7 13:07:34 gate kernel: Netfilter messages via NETLINK v0.30.
Oct  7 13:07:34 gate kernel: nf_conntrack version 0.5.0 (2048 buckets, 8192 max)
Oct  7 13:07:34 gate kernel: nf_conntrack_ipv4: Unknown parameter `hashsize'
Oct  7 13:07:34 gate kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Oct  7 13:07:34 gate kernel: process `syslogd' is using obsolete setsockopt 
SO_BSD
COMPAT
Oct  7 13:07:40 gate kernel: [ cut here ]
Oct  7 13:07:40 gate kernel: kernel BUG at net/core/dev.c:3485!
Oct  7 13:07:40 gate kernel: invalid opcode:  [#1]
Oct  7 13:07:40 gate kernel: last sysfs file: 
/devices/platform/sis5595.656/temp1_
max
Oct  7 13:07:40 gate kernel: Modules linked in: xt_state xt_limit xt_tcpudp 
xt_mul
tiport iptable_mangle iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables 
nf_na
t_tftp nf_conntrack_tftp nf_nat_h323 nf_conntrack_h323 nf_nat_irc nf_nat_ftp 
nf_co
nntrack_irc nf_conntrack_ftp ipt_MASQUERADE nf_nat nf_conntrack nfnetlink 
ipt_REJE
CT ipt_LOG x_tables at76_usb firmware_class e100 ohci_hcd usbcore i2c_sis630 
i2c_s
is5595 i2c_core sis5595 hisax isdn eepro100
Oct  7 13:07:40 gate kernel:
Oct  7 13:07:40 gate kernel: Pid: 2235, comm: isdnctrl Not tainted 
(2.6.23-rc8-mm2
-gate #1)
Oct  7 13:07:40 gate kernel: EIP: 0060:[] EFLAGS: 00010246 CPU: 0
Oct  7 13:07:40 gate kernel: EIP is at register_netdevice+0x6d/0x2c1
Oct  7 13:07:40 gate kernel: EAX:  EBX: c786501c ECX:  EDX: 
0d
99
Oct  7 13:07:40 gate kernel: ESI: c786501c EDI:  EBP: c1657d08 ESP: 
c1657c
ec
Oct  7 13:07:40 gate kernel:  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
Oct  7 13:07:40 gate kernel: Process isdnctrl (pid: 2235, ti=c1656000 
task=c14c306
0 task.ti=c1656000)
Oct  7 13:07:40 gate kernel: Stack: c786501c  c1657d00 c0309ec6 
c1657d68 c
786501c  c1657d18
Oct  7 13:07:40 gate kernel:c029b010 c1657d68 c7865000 c1657d38 
c885a0fa c
884e39c c8864598 c786501c
Oct  7 13:07:40 gate kernel:c1657d68  bfbf779d c1657f60 
c886484d c
212ef80 c1561980 c1805ab0
Oct  7 13:07:40 gate kernel: Call Trace:
Oct  7 13:07:40 gate kernel:  [] register_netdev+0x32/0x3f
Oct  7 13:07:40 gate kernel:  [] isdn_net_new+0x111/0x2ca [isdn]
Oct  7 13:07:40 gate kernel:  [] isdn_ioctl+0x2b5/0xb46 [isdn]
Oct  7 13:07:40 gate kernel:  [] do_ioctl+0x40/0x50
Oct  7 13:07:40 gate kernel:  [] vfs_ioctl+0x1ec/0x203
Oct  7 13:07:40 gate kernel:  [] sys_ioctl+0x31/0x49
Oct  7 13:07:40 gate kernel:  [] syscall_call+0x7/0xb
Oct  7 13:07:40 gate kernel:  [] 0xb7f54de4
Oct  7 13:07:40 gate kernel:  ===
Oct  7 13:07:40 gate kernel: Code: e8 3f a5 e6 ff ba 99 0d 00 00 b8 b4 3c 38 c0 
e8
 96 82 e7 ff 83 bb 20 02 00 00 00 74 04 0f 0b eb fe 8b 83 80 02 00 00 85 c0 75 
04
<0f> 0b eb fe 89 45 f0 b9 4c 2e 48 c0 ba 8e 3e 38 c0 8d 83 78 01
Oct  7 13:07:40 gate kernel: EIP: [] register_netdevice+0x6d/0x2c1 
SS:ES
P 0068:c1657cec
Oct  7 13:18:17 gate syslogd 1.4.1#20: restart.
Oct  7 13:18:17 gate kernel: klogd 1.4.1#20, log source = /proc/kmsg started.
Oct  7 13:18:17 gate kernel: Linux version 2.6.16-cks11-gate ([EMAIL 
PROTECTED]) (gcc vers
ion 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)) #1 Sat May 27 14:45:18 CEST 
2006

[logging was then back into 2.6.16 above]


2.6.23-rc8-mm2/net/core/dev.c/register_netdevice():

int register_netdevice(struct net_device *dev)
{
struct hlist_head *head;
struct hlist_node *p;
int ret;
struct net *net;

BUG_ON(dev_boot_phase);
ASSERT_RTNL();

might_sleep();

/* When net_device's are persistent, this will be fatal. */
BUG_ON(dev->reg_state != NETREG_UNINITIALIZED);
BUG_ON(!dev->nd_net);
net = dev->nd_net;

spin_lock_init(&dev->queue_lock);
spin_lock_init(&dev->_xmit_lock);
netdev_set_lockdep_class(&dev->_xmit_lock, dev->type);
dev->xmit_lock_owner = -1;
spin_lock_init(&dev->ingress_lock);

dev->iflink = -1;

/* Init, if this function is available */
if (dev->init) {
ret = dev->init(d

Re: [PATCH 2/5] forcedeth: interrupt handling cleanup

2007-10-07 Thread Jeff Garzik

Yinghai Lu wrote:

On 10/6/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:

commit a606d2a111cdf948da5d69eb1de5526c5c2dafef
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date:   Fri Oct 5 22:56:05 2007 -0400

[netdrvr] forcedeth: interrupt handling cleanup

* nv_nic_irq_optimized() and nv_nic_irq_other() were complete duplicates
  of nv_nic_irq(), with the exception of one function call.  Consolidate
  all three into a single interrupt handler, deleting a lot of redundant
  code.

* greatly simplify irq handler locking.

  Prior to this change, the irq handler(s) would acquire and release
  np->lock for each action (RX, TX, other events).

  For the common case -- RX or TX work -- the lock is always acquired,
  making all successive acquire/release combinations largely redundant.

  Acquire the lock at the beginning of the irq handler, and release it at
  the end of the irq handler.  This is simple, easy, and obvious.

* remove irq handler work loop.

  All interesting events emanating from the irq handler either have
  their own work loops, or they poke a timer into action.

  Therefore, delete the pointless master interrupt handler work loop.

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>

 drivers/net/forcedeth.c |  325 +++-
 1 file changed, 77 insertions(+), 248 deletions(-)


any chance to create three verion irq handlers for ioapic, msi, msi-x...?

MACRO or inline function?


MSI-X already has its own separate interrupt handlers.  MSI and INTx 
call the same interrupt handling code, like the unmodified driver goes. 
 Creating an MSI-specific irq handler would not save very much AFAICS, 
but I might be missing something.


Do you have ideas/suggestions for a different method?

Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/5] forcedeth: several proposed updates for testing

2007-10-07 Thread Jeff Garzik

Ingo Molnar wrote:

* Jeff Garzik <[EMAIL PROTECTED]> wrote:


* I feel TX NAPI is a useful tool, because it provides an independent TX
  process control point and system load feedback point.
  Thus I felt this was slightly superior to tasklets.


/me agrees violently

btw., when i played with this tunable under -rt:

 enum {
 NV_OPTIMIZATION_MODE_THROUGHPUT,
 NV_OPTIMIZATION_MODE_CPU
 };
 static int optimization_mode = NV_OPTIMIZATION_MODE_THROUGHPUT;

the MODE_CPU one gave (much) _higher_ bandwidth. The queueing model in 
forcedeth seemed to be not that robust and i think a single queueing 
model should be adopted instead of this tunable. (which i think just hid 
some bug/dependency) But i never got to the bottom of it so it's just 
the impression i got.


That's interesting.  It will be informative to narrow down the variables 
affected by this.  My changes stirred the pot quite a bit :)


* 'throughput' mode enables MSI-X, and separate interrupt vectors for RX 
and TX.  so, NVIDIA's MSI-X implementation, our generic MSI-X support, 
or "Known bugs" (see top of file) may be a factor here.


* 'throughput' mode also changes the NIC's timer interrupt frequency

* do you recall if you were running in NAPI mode?  It defaulted to off 
in Kconfig, but I turned it on unconditionally.


* I think TX NAPI has the potential to make the optimization_mode 
irrelevant (along with the other changes, most notably the interrupt 
handling change)


* and overall, yes, if we can have a single queueing model / 
optimization mode I am strongly in favor of that.


Testing welcome ;-)  Though these patches are raw and "hot off the 
presses", so unrelated bugs are practically a certainty.  And I am 
worrying about the "Known bugs" note at the top.  My gut feeling is that 
this was, in part, misunderstanding on the part of reverse-engineers, 
since corrected when NVIDIA started contributing to the driver.


Jeff



-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 6/n] forcedeth: protect slow path with mutex

2007-10-07 Thread Jeff Garzik

commit abca163a14b28c234df9bf38034bc967ff81c3aa
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date:   Sun Oct 7 07:22:14 2007 -0400

[netdrvr] forcedeth: wrap slow path hw manipulation inside hw_mutex

* This makes sure everybody who wants to start/stop the RX and TX engines
  first acquires this mutex.

* tx_timeout code was deleted, replaced by scheduling reset_task.

* linkchange moved to a workqueue (always inside hw_mutex)

* simplified irq handling a bit

* make sure to disable workqueues before NAPI

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>

 drivers/net/forcedeth.c |  272 ++--
 1 file changed, 175 insertions(+), 97 deletions(-)

abca163a14b28c234df9bf38034bc967ff81c3aa
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index a037f49..d1c1efa 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -63,6 +63,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -647,6 +648,12 @@ struct nv_skb_map {
unsigned int dma_len;
 };
 
+struct nv_mc_info {
+   u32 addr[2];
+   u32 mask[2];
+   u32 pff;
+};
+
 /*
  * SMP locking:
  * All hardware access under dev->priv->lock, except the performance
@@ -709,6 +716,8 @@ struct fe_priv {
unsigned int pkt_limit;
struct timer_list oom_kick;
struct work_struct reset_task;
+   struct work_struct linkchange_task;
+   struct work_struct mcast_task;
struct delayed_work stats_task;
u32 reset_task_irq;
int rx_ring_size;
@@ -731,14 +740,18 @@ struct fe_priv {
int tx_ring_size;
 
/* vlan fields */
-   struct vlan_group *vlangrp;
+   struct vlan_group   *vlangrp;
 
/* msi/msi-x fields */
-   u32 msi_flags;
-   struct msix_entry msi_x_entry[NV_MSI_X_MAX_VECTORS];
+   u32 msi_flags;
+   struct msix_entry   msi_x_entry[NV_MSI_X_MAX_VECTORS];
 
/* flow control */
-   u32 pause_flags;
+   u32 pause_flags;
+
+   struct mutexhw_mutex;
+
+   struct nv_mc_info   mci;
 };
 
 /*
@@ -2120,27 +2133,9 @@ static void nv_tx_timeout(struct net_device *dev)
 
spin_lock_irq(&np->lock);
 
-   /* 1) stop tx engine */
-   nv_stop_tx(dev);
-
-   /* 2) process all pending tx completions */
-   if (!nv_optimized(np))
-   nv_tx_done(dev, np->tx_ring_size);
-   else
-   nv_tx_done_optimized(dev, np->tx_ring_size);
+   np->reset_task_irq = np->irqmask;
+   schedule_work(&np->reset_task);
 
-   /* 3) if there are dead entries: clear everything */
-   if (np->get_tx_ctx != np->put_tx_ctx) {
-   printk(KERN_DEBUG "%s: tx_timeout: dead entries!\n", dev->name);
-   nv_drain_tx(dev);
-   nv_init_tx(dev);
-   setup_hw_rings(dev, NV_SETUP_TX_RING);
-   }
-
-   netif_wake_queue(dev);
-
-   /* 4) restart tx engine */
-   nv_start_tx(dev);
spin_unlock_irq(&np->lock);
 }
 
@@ -2476,6 +2471,7 @@ static int nv_change_mtu(struct net_device *dev, int 
new_mtu)
 * guessed, there is probably a simpler approach.
 * Changing the MTU is a rare event, it shouldn't matter.
 */
+   mutex_lock(&np->hw_mutex);
nv_disable_irq(dev);
netif_tx_lock_bh(dev);
spin_lock(&np->lock);
@@ -2503,6 +2499,7 @@ static int nv_change_mtu(struct net_device *dev, int 
new_mtu)
spin_unlock(&np->lock);
netif_tx_unlock_bh(dev);
nv_enable_irq(dev);
+   mutex_unlock(&np->hw_mutex);
}
return 0;
 }
@@ -2535,6 +2532,8 @@ static int nv_set_mac_address(struct net_device *dev, 
void *addr)
/* synchronized against open : rtnl_lock() held by caller */
memcpy(dev->dev_addr, macaddr->sa_data, ETH_ALEN);
 
+   mutex_lock(&np->hw_mutex);
+
if (netif_running(dev)) {
netif_tx_lock_bh(dev);
spin_lock_irq(&np->lock);
@@ -2552,6 +2551,8 @@ static int nv_set_mac_address(struct net_device *dev, 
void *addr)
} else {
nv_copy_mac_to_hw(dev);
}
+
+   mutex_unlock(&np->hw_mutex);
return 0;
 }
 
@@ -2605,17 +2606,61 @@ static void nv_set_multicast(struct net_device *dev)
}
addr[0] |= NVREG_MCASTADDRA_FORCE;
pff |= NVREG_PFF_ALWAYS;
+
+   if (mutex_trylock(&np->hw_mutex)) {
+   spin_lock_irq(&np->lock);
+
+   nv_stop_rx(dev);
+
+   writel(addr[0], base + NvRegMulticastAddrA);
+   writel(addr[1], base + NvRegMulticastAddrB);
+   writel(mask[0], base + NvRegMulticastMaskA);
+   writel(mask[1], base + NvRegMulticastMaskB);
+   writel(pff, base + NvRegPacketFilterFlags);
+   dprintk(KE

libertas and endianness

2007-10-07 Thread Geert Uytterhoeven
Somehow (haven't found out why it suddenly got compiled, no .config
changes) this showed up in the list of warnings in 2.6.23-rc9 compared
to -rc8 on one of my m68k builds:

| drivers/net/wireless/libertas/cmd.c:189: warning: large integer implicitly 
truncated to unsigned type
| drivers/net/wireless/libertas/cmd.c:195: warning: large integer implicitly 
truncated to unsigned type

The offending lines are:

| wep->keytype[i] = cpu_to_le16(cmd_type_wep_40_bit);
| wep->keytype[i] = cpu_to_le16(cmd_type_wep_104_bit);

I.e. it tries to store 0x0100 resp. 0x0200 into keytype[i], which is is u8.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC/PATCH 2/4] UDP memory usage accounting (take 4): accounting unit and variable

2007-10-07 Thread Evgeniy Polyakov
Hi.

On Sat, Oct 06, 2007 at 12:01:07AM +0900, Satoshi OSHIMA ([EMAIL PROTECTED]) 
wrote:
> --- 2.6.23-rc3-udp_limit.orig/net/ipv4/udp.c
> +++ 2.6.23-rc3-udp_limit/net/ipv4/udp.c
> @@ -113,6 +113,10 @@ DEFINE_SNMP_STAT(struct udp_mib, udp_sta
>  struct hlist_head udp_hash[UDP_HTABLE_SIZE];
>  DEFINE_RWLOCK(udp_hash_lock);
>  
> +atomic_t udp_memory_allocated;
> +
> +EXPORT_SYMBOL(udp_memory_allocated);
> +

Why do you export this variable?
It is not accessed from modules in your patchset.

-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/5] forcedeth: several proposed updates for testing

2007-10-07 Thread Ingo Molnar

* Jeff Garzik <[EMAIL PROTECTED]> wrote:

> * I feel TX NAPI is a useful tool, because it provides an independent TX
>   process control point and system load feedback point.
>   Thus I felt this was slightly superior to tasklets.

/me agrees violently

btw., when i played with this tunable under -rt:

 enum {
 NV_OPTIMIZATION_MODE_THROUGHPUT,
 NV_OPTIMIZATION_MODE_CPU
 };
 static int optimization_mode = NV_OPTIMIZATION_MODE_THROUGHPUT;

the MODE_CPU one gave (much) _higher_ bandwidth. The queueing model in 
forcedeth seemed to be not that robust and i think a single queueing 
model should be adopted instead of this tunable. (which i think just hid 
some bug/dependency) But i never got to the bottom of it so it's just 
the impression i got.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/5] forcedeth: interrupt handling cleanup

2007-10-07 Thread Ingo Molnar

* Jeff Garzik <[EMAIL PROTECTED]> wrote:

> - spin_unlock(&np->lock);
> - printk(KERN_DEBUG "%s: too many iterations (%d) in 
> nv_nic_irq.\n", dev->name, i);
> - break;

i like that! One forcedeth annoyance that triggers frequently on one of 
my testboxes is:

[  120.955202] eth0: too many iterations (6) in nv_nic_irq.
[  121.233865] eth0: too many iterations (6) in nv_nic_irq.
[  129.215450] eth0: too many iterations (6) in nv_nic_irq.
[  139.734408] eth0: too many iterations (6) in nv_nic_irq.
[  144.546811] eth0: too many iterations (6) in nv_nic_irq.
[  153.811005] eth0: too many iterations (6) in nv_nic_irq.
[  154.695879] eth0: too many iterations (6) in nv_nic_irq.
[  155.455078] eth0: too many iterations (6) in nv_nic_irq.
[  173.912162] eth0: too many iterations (6) in nv_nic_irq.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection

2007-10-07 Thread TAKANO Ryousei
From: David Miller <[EMAIL PROTECTED]>
Subject: Re: [RFC][PATCH 1/2] TCP: fix lost retransmit detection
Date: Sat, 06 Oct 2007 23:17:14 -0700 (PDT)

> From: TAKANO Ryousei <[EMAIL PROTECTED]>
> Date: Sun, 07 Oct 2007 14:51:00 +0900 (JST)
> 
> > BTW, what is difference among netdev-2.6, net-2.6 (net-2.6.24), and 
> > tcp-2.6? I am not familiar with linux kernel development process.
> 
> net-2.6.24 tree is current new development
> 
> net-2.6 tree is only bug fixes
> 
> tcp-2.6 is an old abandonded tree that holds lots of old
> TCP work, most of which is merged already, but one part
> (my RB-Tree SACK patches) are not integrated yet.

Thanks, and I got it.

I need to check the related recent posts (SACK block validation, sacktag 
cache usage, and RT-tree SACK) on this list.

Ryousei Takano
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html