From: Dave Jones <[EMAIL PROTECTED]>
Date: Thu, 19 Jan 2006 01:38:24 -0500
> FWIW, the original bug reporter has followed up to report that this
> is still present in a kernel based on 2.6.16rc1
I wonder if this is another -Os miscompile...
I'll try to have a look.
-
To unsubscribe from this lis
On Wed, Jan 11, 2006 at 11:53:15PM -0500, Dave Jones wrote:
> We got this in Fedora bugzilla from a user running a 2.6.15-rc7-git2 vintage
> kernel. This seemed important enough to warrant a closer look by someone
> familiar
> with recent networking changes in case this hasn't been reported/f
jamal wrote:
On Wed, 2006-18-01 at 19:12 -0800, Ben Greear wrote:
jamal wrote:
And if you are serious about performance you should use netlink.
If you can show me a snippet of user-space code similar to the
complexity of what I posted earlier, I'll actually do a benchmark
against it and m
>
> +#ifdef XXX_CONFIG_IXGB_EEH_RECOVERY
> + if(unlikely(icr==EEH_IO_ERROR_VALUE(4))) {
> + if (eeh_slot_is_isolated (adapter->pdev))
> + // disable_irq_nosync (adapter->pdev->irq);
> + return IRQ_NONE; /* Not our interrupt */
So does the return bel
On Wed, 2006-18-01 at 19:12 -0800, Ben Greear wrote:
> jamal wrote:
> > And if you are serious about performance you should use netlink.
>
> If you can show me a snippet of user-space code similar to the
> complexity of what I posted earlier, I'll actually do a benchmark
> against it and my code
jamal wrote:
On Wed, 2006-18-01 at 16:13 -0800, Ben Greear wrote:
shemminger wrote:
It makes no sense to extend ethtool for something generic like that.
It shouldn't be that hard to do netlink in some richer scripting
language (like perl), but I haven't tried.
If you're using perl, you've
On Wed, 2006-18-01 at 16:13 -0800, Ben Greear wrote:
> shemminger wrote:
>
> > It makes no sense to extend ethtool for something generic like that.
> > It shouldn't be that hard to do netlink in some richer scripting
> > language (like perl), but I haven't tried.
>
> If you're using perl, you've
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 13 Jan 2006
--- linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt.old
2006-01-13 15:02:15.0 +0100
+++ linux-2.6.15-mm3-full/Documentation/feature-removal-schedule.txt
2006-01-
> 2) I still do not understand this. Quote from the definition
> of dev_kfree_skb_irq -
>
> /* Use this variant when it is known for sure that it
> * is executing from interrupt context.
> */
Should this comment should be ammended to include the interrupt
disabled case?
Graham
-
To unsubscrib
From: Arnd Bergmann <[EMAIL PROTECTED]>
Date: Thu, 19 Jan 2006 01:57:37 +0100
> I'm not that familiar with the process for non-driver patches for
> netdev (nor for device drivers as it seems ;-)), but my
> understanding is that you should address those to Jeff Garzik as
> well, asking for inclusio
On Wed, Jan 18, 2006 at 04:55:39PM -0800, Kris Katterjohn wrote:
>
> > > -#include
> >
> > We need this for skb->dev->ifindex.
>
> But we know we have struct net_device because it's used in linux/skbuff.h (for
> skb->dev of course). I'm not saying it doesn't make sense, just that it seems
> to
Am Wednesday 18 January 2006 07:56 schrieb Shaun Pereira:
> Assuming you are happy with the state of the patches, is there anyway
> for me to know if they will become a part of the next release?
I don't see any more technical problems with your patches. You still need
to proper patch description
From: Herbert Xu
Sent: 1/18/2006 4:02:18 PM
> On Wed, Jan 18, 2006 at 02:15:37PM -0800, Kris Katterjohn wrote:
> >
> > #include
> > #include
> > -#include
>
> OK.
>
> > -#include
>
> Needed for GFP_*. Replace this with gfp.h if you want.
>
> > -#include
> > -#include
> > -#include
>
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 16:35:28 -0800
> We've had worse kernel bugs in official releases!
Please document the change that made it into an official release that
broke every user of a given piece of hardware, regardless of kernel
configuration or chip revision o
David S. Miller wrote:
It's pretty stupid and counter productive, and in this case here
resulted in Intel's engineering process looking rather poor. This
e1000 incident is one of the worst vendor driver maintainence bombs
I've seen in my 10+ years of doing Linux kernel work.
We've had worse k
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 19:10:32 -0500
> Its just plain inefficient.
I think part of this has to do with Intel's internal legal
policies for public code release. It's time consuming and
highly encourages the engineers to batch code releases so
that they minim
On Wed, 18 Jan 2006, David S. Miller wrote:
>
> I thought we had fixed this already? Guess now :)
>
There was a patch some months ago to allow a bonding
device to use zero-copy if all its slaves did - same
idea (and implemented with the same code.)
--
Arthur
-
To unsubscribe from thi
From: "Ronciak, John" <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 15:46:24 -0800
> What was tested was the entire patch set which included the pre-fetch
> patch.
Therefore, you sent patches you know you had to make major surgery
to before submission compared to what you actually tested.
You submi
shemminger wrote:
It makes no sense to extend ethtool for something generic like that.
It shouldn't be that hard to do netlink in some richer scripting
language (like perl), but I haven't tried.
If you're using perl, you've already given up performance, so just
parse /proc/net/dev.
I implemen
Ronciak, John wrote:
What was tested was the entire patch set which included the pre-fetch
patch. Since there so much controversy over the pre-fetch patch let
last time we moved that patch to the end of the patch set. Then we
asked ourselves if we should send that patch out at all. We decided
Roberto Nibali wrote:
+ * set_rx_all: Set or clear IFF_ACCEPT_ALL_FRAMES, see if.h
+ * get_rx_all: Return 1 if set, 0 if not.
+ * set_save_fcs: Set or clear IFF_SAVE_FCS, see if.h
+ * get_save_fcs: Return 1 if set, 0 if not.
Something we would like to have in the standard kernel?
I'd love
On Wed, Jan 18, 2006 at 02:15:37PM -0800, Kris Katterjohn wrote:
>
> #include
> #include
> -#include
OK.
> -#include
Needed for GFP_*. Replace this with gfp.h if you want.
> -#include
> -#include
> -#include
> -#include
OK.
> -#include
We need this for skb->dev->ifindex.
> -#i
On Wed, 2006-01-18 at 14:37 -0800, Ben Greear wrote:
> Roberto Nibali wrote:
> >>> It looks like the e1000 driver gathers all kinds of stats. How do I
> >>> access these from userspace?
> >>
> >>
> >> /proc/net/dev will have many of the common ones, and ethtool should
> >> get the rest.
> >>
> >>
Hmmm, most (if not all) of those you get using netlink, like so for
example:
ip -s -s link show dev eth0
But I see the incentive to add those to ethtool as well.
Yes, I think you can get everything out of netlink..but I find
the ethtool API much easier to use...
I envision one tool to confi
What was tested was the entire patch set which included the pre-fetch
patch. Since there so much controversy over the pre-fetch patch let
last time we moved that patch to the end of the patch set. Then we
asked ourselves if we should send that patch out at all. We decided not
to stir things up a
Hi Jeff,
Please review, apply and forward upstream as appropriate.
--linas
[PATCH] PCI Error Recovery: e100 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel ethernet e100
device driver. The pat
Hi Jeff,
Please review, apply and forward this patch upstream,
as appropriate.
--linas
[PATCH] PCI Error Recovery: e1000 network device driver
Various PCI bus errors can be signaled by newer PCI controllers. This
patch adds the PCI error recovery callbacks to the intel gigabit
ethernet e100
Jeff,
Please review, apply and forward upstream the patch below,
for the Intel ixgb driver. Similar patches for the Intel e1000
and e100 to follow shortly.
--linas
On Wed, Jan 18, 2006 at 02:13:55PM -0800, Ronciak, John was heard to remark:
> Patches for e100, e1000 and ixgb need to go out to
Roberto Nibali wrote:
Hmmm, most (if not all) of those you get using netlink, like so for
example:
ip -s -s link show dev eth0
But I see the incentive to add those to ethtool as well.
Yes, I think you can get everything out of netlink..but I find
the ethtool API much easier to use...
+ *
I'm manually pasting this out of my consolidated patch..it's against
2.6.15.
You should be able to ignore the send-to-self and crc related logic
w/out incident.
If this won't work, I can send you a link to my full patch, but it has a
lot
more than just this netdev stats hack in it
Thank
From: Arthur Kepner <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 14:37:57 -0800 (PST)
> Add NETIF_F_TSO to BOND_INTERSECT_FEATURES so that it can be
> used by a bonding device iff all its slave devices support TSO.
>
> Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
I thought we had fixed this al
Both applied, thanks John.
-
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
Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
>
> On Wed, 18 Jan 2006, Andrew Morton wrote:
> > git-bisect of mainline claims that the regression was introduced by commit
> > 0fadb0597d240d4ed279042cab632d567510a1a3, "e1000: Fix collision distance".
> > Jeff(K), I can test patches...
>
> it appears
Add NETIF_F_TSO to BOND_INTERSECT_FEATURES so that it can be
used by a bonding device iff all its slave devices support TSO.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
Arthurdiff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
--- a/drivers/net/bonding/bond_ma
Correct location info for net-2.6 git tree.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
MAINTAINERS |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6d1b048..0d0f8a8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1841,7 +1841,7 @
David S. Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 11:12:54 -0800
Well, to answer myself: I found the problem. Pktgen's multi-skb
trick only works if the device makes no change to the skb. But, the
cxgb driver pushes a header on the front of the skb...
So, y
Add an entry to MAINTAINERS for wireless networking, just so people
know whom to bless with patches.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
MAINTAINERS |7 +++
1 files changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6d1b048..23aca6f 100644
--- a/MA
Roberto Nibali wrote:
It looks like the e1000 driver gathers all kinds of stats. How do I
access these from userspace?
/proc/net/dev will have many of the common ones, and ethtool should
get the rest.
If you want a hack, I have a patch against the ethtool logic that
allows user-space to grab
From: Jean Tourrilhes <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 14:24:24 -0800
> They are mostly using BlueTooth nowadays :-(
This is not strictly the case, especially in Asia.
Most of the current LG and Samsung phones out in South Korea
are still IRDA.
In fact my USA Samsung E635 is IRD
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 14:20:28 -0800 (Pacific Standard Time)
> The root cause of the bug is that the receive routine was in a bad state
> because we didn't submit our prefetch patch, which unfortunately didn't
> have just prefetchy things in it.
So di
From: Per Liden <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 01:52:40 +0100 (CET)
> Here is a set of patches in response to the initial criticism/comments
> that TIPC received.
>
> The reason why these patches touch so many files is the fix to avoid
> namespace pullution. Please see diffstat and
On Wed, Jan 18, 2006 at 02:07:18PM -0800, David S. Miller wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Wed, 18 Jan 2006 10:52:26 -0800
>
> > Dave, Jean says he really doesn't have time to much IRDA any more.
> > The following would help motivate someone who has more time.
> >
> >
From: David Stevens <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 15:17:24 -0700
> The below "jumbo" patch fixes the following problems in IGMPv3.
Looks good, applied.
Thanks David.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mor
On Wed, 18 Jan 2006, Andrew Morton wrote:
git-bisect of mainline claims that the regression was introduced by commit
0fadb0597d240d4ed279042cab632d567510a1a3, "e1000: Fix collision distance".
Jeff(K), I can test patches...
it appears git bisect is wrong, there is nothing in that patch that woul
From: Ben Greear <[EMAIL PROTECTED]>
Date: Tue, 17 Jan 2006 17:01:46 -0800
> int rsrv = (odev->hard_header_len + 16) & ~0xF;
>
>
> skb = alloc_skb(info->cur_pkt_size + 64 + rsrv, GFP_ATOMIC);
>
>
> /* Make some extra space, align on 16-byte boundary
>* (helps
From: Herbert Xu
Sent: 1/18/2006 12:26:12 PM
> On Wed, Jan 18, 2006 at 06:42:06AM -0800, Kris Katterjohn wrote:
> >
> > Since it can't be a module and is always built in, we can just remove the
> > EXPORT_SYMBOL()s, right?
>
> No, these are there so that other modules can use these symboles.
Oka
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> Let's see how this goes... if there are further problems, I'll just
> revert the entire thing, and push these changes (and the previous set)
> into upstream-2.6.17 branch.
>
> I don't mind them updating the defconfig files, even though most people
>
The below "jumbo" patch fixes the following problems in IGMPv3.
1) fix "mld_marksources()" to
a) send nothing when all queried sources are excluded
b) send full exclude report when source queried sources are
not excluded
c) don't schedule a timer when there'
From: Ben Greear <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 11:12:54 -0800
> Well, to answer myself: I found the problem. Pktgen's multi-skb
> trick only works if the device makes no change to the skb. But, the
> cxgb driver pushes a header on the front of the skb...
>
> So, you just can't use
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 18 Jan 2006 10:52:26 -0800
> Dave, Jean says he really doesn't have time to much IRDA any more.
> The following would help motivate someone who has more time.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied.
We need to find
On Wed, Jan 18, 2006 at 11:56:26AM -0800, Stephen Hemminger wrote:
> > > Nack. changing module tables in one driver depending on another driver
> > > is always bogus. Better send a patch to udev/modutils/whatever
> > > maintainers
> > > to prefer one over the others.
> > Is there really any
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 19 Jan 2006 07:26:12 +1100
> On Wed, Jan 18, 2006 at 06:42:06AM -0800, Kris Katterjohn wrote:
> >
> > Since it can't be a module and is always built in, we can just remove the
> > EXPORT_SYMBOL()s, right?
>
> No, these are there so that other modul
Sorry about reposting: the message didnt seem to make it to netdev.
---
The following patch is not directly related to the destructor issue,
but I'm posting it here fore completeness since it needs to be applied on top of
the previous pair of patches in the destructor series.
---
Fix error hand
Quoting Shirley Ma <[EMAIL PROTECTED]>:
> Subject: Re: Fwd: [PATCH 1 of 3] move destructor to struct neigh_parms
>
>
> >+ if (neigh->parms->neigh_destructor)
> >+ (neigh->parms->neigh_destructor)(neigh);
>
> Is that safe without checking neigh->p
Jesse Brandeburg wrote:
Adds the ability to disability packet split at compile time and use the legacy
receive path on PCI express hardware. Made this a CONFIG option and modified
the Kconfig, to reflect the new option.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsh
On 1/18/06, Christopher Friesen <[EMAIL PROTECTED]> wrote:
>
> We're seeing an issue with an e1000 device. After some time (4-8 hrs
> typically) it jams itself up and refuses to receive any more packets.
>
> We're running 2.6.10, but with the e1000 driver from 2.6.14.
just so you've got all the l
Sorry about reposting: the message didnt seem to make it to netdev.
---
Hi!
struct neigh_ops currently has a destructor field, unused by in-kernel
drivers outside the infiniband subtree.
infiniband ipoib in-tree driver currently uses this field, and we've
run into problems: since the destructor i
Sorry about reposting: the message didnt seem to make it to netdev.
---
Move destructor from neigh_ops (which is shared between devices)
to neigh_parms which is not, so that multiple drivers can set
it safely.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: linux-2.6.15/drivers/inf
Adds the ability to disability packet split at compile time and use the legacy
receive path on PCI express hardware. Made this a CONFIG option and modified
the Kconfig, to reflect the new option.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Si
These functions help restore the driver to active configuration when coming out
of resume for power management.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |
Added e1000_mc_addr_list_update
Added e1000_read_reg_io
Added e1000_enable_pciex_master
These are not static functions, that is why we have them declared in the header.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[E
in attempting to not send the "prefetch" patch, we broke the receive code,
this patch fixes that issue.
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 37 +
Made the suggested changes to the disable packet split patch. These were
diff'd with Garzik's latest netdev-2.6 head.
!! Please use this patch set instead of the previous 0-6 set
NOTE: because these changes are just regenerating the first 6 and then the
7th and 8th fixes the compile warning and
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c | 72 +---
1 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/dr
On Wed, Jan 18, 2006 at 09:18:26AM +0100, Feyd wrote:
> With fullmac devices the master interface makes no sense, it cannot be
> used for neither the sniffing or QoS. The design where the master device
> is something else than net_device is cleaner, it treats both soft/fullmac
> devices equaly, wi
On Wed, Jan 18, 2006 at 03:48:49PM -0500, John W. Linville wrote:
> On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote:
> > John W. Linville wrote:
>
> > >The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
> > >changes I recently sent to Jeff. Those changes are also a
Align the prefetches to a dword to help speed them up.
Recycle skb's and early replenish.
Force memory writes to complete before fetching more descriptors.
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
Signed-off-by: John Ronciak <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/driv
We're seeing an issue with an e1000 device. After some time (4-8 hrs
typically) it jams itself up and refuses to receive any more packets.
We're running 2.6.10, but with the e1000 driver from 2.6.14.
Outgoing packets seem to be fine, incoming packets just increment the
error count.
ethtoo
On Wed, Jan 18, 2006 at 03:36:59PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:
> >The "master" branch of that tree is (mostly) up-to-date w/ Linus, plus
> >changes I recently sent to Jeff. Those changes are also available on
> >the "upstream-jgarzik" branch, but it is frozen to when I req
John W. Linville wrote:
First, the news everyone will like. Thanks to the kernel.org team
I now have a place to publish a wireless tree:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
The tree there has a number of branches, so many that you need
a scorecard...
Bra
On Wed, 2006-01-18 at 08:08 +0100, Arjan van de Ven wrote:
> the dual license text needs a bit of clarification I suspect to make
> explicit that the "or BSD" part only applies when used entirely outside
> the linux kernel. (that already is the case, just it's not explicit.
> Making that explicit
On Wed, Jan 18, 2006 at 09:19:20PM +0100, Michael Buesch wrote:
> On Wednesday 18 January 2006 21:06, John W. Linville wrote:
> > The tree also has "softmac" and "dscape" branches. The "softmac"
> > branch includes the Johannes Berg softmac code as well as the the
> > BCM43xx driver based upon tha
On Wed, Jan 18, 2006 at 06:42:06AM -0800, Kris Katterjohn wrote:
>
> Since it can't be a module and is always built in, we can just remove the
> EXPORT_SYMBOL()s, right?
No, these are there so that other modules can use these symboles.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert
On Wednesday 18 January 2006 21:06, John W. Linville wrote:
> The tree also has "softmac" and "dscape" branches. The "softmac"
> branch includes the Johannes Berg softmac code as well as the the
> BCM43xx driver based upon that code. The "dscape" branch includes
> the DeviceScape patches from Jir
First, the news everyone will like. Thanks to the kernel.org team
I now have a place to publish a wireless tree:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
The tree there has a number of branches, so many that you need
a scorecard...
Branches
The "maste
I roll it into the next set of skge maintenance patches.
-
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
On Wed, 18 Jan 2006 11:29:09 -0800
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> On Wed, 18 Jan 2006 19:07:42 +
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Jan 18, 2006 at 11:03:13AM -0800, Stephen Hemminger wrote:
> > > The following removes the pci device module alias if b
It looks like the e1000 driver gathers all kinds of stats. How do I
access these from userspace?
/proc/net/dev will have many of the common ones, and ethtool should
get the rest.
If you want a hack, I have a patch against the ethtool logic that
allows user-space to grab the netdev->stats struc
On Wed, 18 Jan 2006 19:07:42 +
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 18, 2006 at 11:03:13AM -0800, Stephen Hemminger wrote:
> > The following removes the pci device module alias if both skge and sk98lin
> > are compiled as modules. This means the clueless user who builds b
On Wed, Jan 18, 2006 at 10:52:26AM -0800, Stephen Hemminger wrote:
> Dave, Jean says he really doesn't have time to much IRDA any more.
> The following would help motivate someone who has more time.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Thanks ;-)
(Unfortunately
Ben Greear wrote:
Hello!
I got my chelsio NICs in a machine running 2.6.15 + my hacks
today and started playing with it...
I noticed one immediate problem with pktgen, and fixed my pktgen to
respect the hard-header-len that the chelsio driver reports. My
pktgen doesn't track mainline very well
On Wed, Jan 18, 2006 at 11:03:13AM -0800, Stephen Hemminger wrote:
> The following removes the pci device module alias if both skge and sk98lin
> are compiled as modules. This means the clueless user who builds both modules
> will get the skge driver loaded. If they really want to run sk98lin, the
The following removes the pci device module alias if both skge and sk98lin
are compiled as modules. This means the clueless user who builds both modules
will get the skge driver loaded. If they really want to run sk98lin, they
can always modprobe it explicitly.
Signed-off-by: Stephen Hemminger <[
Take experimental tag of skge and sky2.
Mark sk98lin driver for future removal.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- git-2.6.orig/Documentation/feature-removal-schedule.txt
+++ git-2.6/Documentation/feature-removal-schedule.txt
@@ -6,6 +6,14 @@ be removed from this file.
--
Dave, Jean says he really doesn't have time to much IRDA any more.
The following would help motivate someone who has more time.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- git-2.6.orig/MAINTAINERS
+++ git-2.6/MAINTAINERS
@@ -1398,7 +1398,7 @@ IRDA SUBSYSTEM
P: Jean Tourrilhes
On Wed, Jan 18, 2006 at 10:19:01AM -0800, Sean Hefty wrote:
> Roland Dreier wrote:
> > > + UCMA_MAX_BACKLOG= 128
> >
> >Is there any reason that we might want to make this a tunable? Maybe
> >as a module parameter that's writable in sysfs...
>
> There's no reason not to make this tunable.
On Wed, Jan 18, 2006 at 04:26:00PM +0100, Olaf Hering wrote:
> I havent checked if this patch is the culprit, but 2.6.16-rc1-git1 does
> lockup after modprobe -v mv643xx_eth , dhcpcd eth2.
> Have to find a serial console for the pegasos, all I get on console is
>
> BUG: spinlock recursion on CPU#0
Roland Dreier wrote:
> + UCMA_MAX_BACKLOG= 128
Is there any reason that we might want to make this a tunable? Maybe
as a module parameter that's writable in sysfs...
There's no reason not to make this tunable.
- Sean
-
To unsubscribe from this list: send the line "unsubscribe netdev
Grant Grundler wrote:
Is this code going to get invoked very often?
In practice, it would be invoked when matching any listen requests
originating from the CMA (RDMA connection abstraction).
hrm..I'm not sure how to translate your answer into a workload.
e.g. which netperf or netpipe test wo
On Wed, Jan 18, 2006 at 04:26:00PM +0100, Olaf Hering wrote:
> On Mon, Jan 16, Dale Farnsworth wrote:
>
> > This driver has historically held a spin_lock during the entire open
> > and stop functions and while receiving multiple packets. This is
> > unecessarily long and holds locks during calls
On Wed, Jan 18, 2006 at 09:46:03AM -0800, Sean Hefty wrote:
> Grant Grundler wrote:
> >>+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
...
> >Is this code going to get invoked very often?
>
> In practice, it would be invoked when matching any listen requests
> originating from the
Grant Grundler wrote:
+static void cm_mask_compare_data(u8 *dst, u8 *src, u8 *mask)
+{
+ int i;
+
+ for (i = 0; i < IB_CM_PRIVATE_DATA_COMPARE_SIZE; i++)
+ dst[i] = src[i] & mask[i];
+}
Is this code going to get invoked very often?
In practice, it would be invoked wh
From: Heiko Carstens <[EMAIL PROTECTED]>
- Remove all CVS generated information like e.g. revision IDs from
drivers/s390 and include/asm-s390 (none present in arch/s390).
- Add newline at end of arch/s390/lib/Makefile to avoid diff message.
Acked-by: Andreas Herrmann <[EMAIL PROTECTED]>
Acked-b
On Wed, Jan 18, 2006 at 12:36:09AM +0100, Stefan Rompf wrote:
> prism2 usb is even worse - the urb is build of some control structure, the
> 802.11 3 address header, a 802.3 header and the 802.11 data part. Some bits
> in the control structure decide whether the 802.11 or the 802.3 header is
> u
Christopher Friesen wrote:
It looks like the e1000 driver gathers all kinds of stats. How do I
access these from userspace?
/proc/net/dev will have many of the common ones, and ethtool should
get the rest.
If you want a hack, I have a patch against the ethtool logic that
allows user-space t
On Wed, Jan 18, 2006 at 09:32:49AM +, Simon Kelley wrote:
> That may be rather over-optimistic: the Atmel hardware dosen't even
> produce consistent results over different chip revs.
But each chip on its own is fairly consistent, which is all that
random users care about. "More bars mean bet
> +UCMA_MAX_BACKLOG= 128
Is there any reason that we might want to make this a tunable? Maybe
as a module parameter that's writable in sysfs...
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
> +struct ucma_file {
> +struct semaphoremutex;
This should be a struct mutex instead, I think.
> +static DECLARE_MUTEX(ctx_mutex);
Same here.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
On Mon, Jan 16, Dale Farnsworth wrote:
> This driver has historically held a spin_lock during the entire open
> and stop functions and while receiving multiple packets. This is
> unecessarily long and holds locks during calls that may sleep.
> This patch reduces the size of windows where locks a
1 - 100 of 113 matches
Mail list logo
