* Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: Frans Pop @ 2008-01-17 7:51 UTC (permalink / raw)
To: David Miller; +Cc: jesse.brandeburg, slavon, netdev, linux-kernel
In-Reply-To: <20080116.232037.261622584.davem@davemloft.net>
On Thursday 17 January 2008, David Miller wrote:
> From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
>
> > We spent Wednesday trying to reproduce (without the patch) these issues
> > without much luck, and have applied the patch cleanly and will continue
> > testing it. Given the simplicity of the changes, and the community
> > testing, I'll give my ack and we will continue testing.
>
> You need a slow CPU, and you need to make sure you do actually
> trigger the TX limiting code there.
Hmmm. Is a dual core Pentium D 3.20GHz considered slow these days?
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Timo Teräs @ 2008-01-17 7:38 UTC (permalink / raw)
To: David Miller; +Cc: herbert, hadi, netdev
In-Reply-To: <20080116.231654.74131878.davem@davemloft.net>
David Miller wrote:
> From: Timo_Teräs <timo.teras@iki.fi>
> Date: Thu, 17 Jan 2008 08:27:14 +0200
>
>> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
>> So I'd say pfkey might be a bit more portable. Though netlink is definitely
>> more robust and extensive.
>
> The RFCs say absolutely nothing about policy interfaces for AF_KEY,
> everybody rolls their own in slightly incompatible ways.
>
> It is therefore anything but standardized.
Yes, there's non-standardized extensions. But the point was that there are
other implementations of pfkey. And ipsec-tools racoon is an example of
a widely used application that runs in Linux and *BSD using this API. So
for the time being I'd consider having pfkey fixes as a good thing. This
pfkey dumping problem seems to be affecting many users.
- Timo
^ permalink raw reply
* Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: David Miller @ 2008-01-17 7:20 UTC (permalink / raw)
To: jesse.brandeburg; +Cc: slavon, elendil, netdev, linux-kernel
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F520432DA91@orsmsx418.amr.corp.intel.com>
From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
Date: Wed, 16 Jan 2008 23:09:47 -0800
> We spent Wednesday trying to reproduce (without the patch) these issues
> without much luck, and have applied the patch cleanly and will continue
> testing it. Given the simplicity of the changes, and the community
> testing, I'll give my ack and we will continue testing.
You need a slow CPU, and you need to make sure you do actually
trigger the TX limiting code there.
I bet your cpus are fast enough that it simply never triggers.
:-)
> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Thanks for reviewing Jesse.
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: David Miller @ 2008-01-17 7:16 UTC (permalink / raw)
To: timo.teras; +Cc: herbert, hadi, netdev
In-Reply-To: <478EF542.1010702@iki.fi>
From: Timo_Teräs <timo.teras@iki.fi>
Date: Thu, 17 Jan 2008 08:27:14 +0200
> I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
> So I'd say pfkey might be a bit more portable. Though netlink is definitely
> more robust and extensive.
The RFCs say absolutely nothing about policy interfaces for AF_KEY,
everybody rolls their own in slightly incompatible ways.
It is therefore anything but standardized.
^ permalink raw reply
* RE: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: Brandeburg, Jesse @ 2008-01-17 7:09 UTC (permalink / raw)
To: David Miller; +Cc: slavon, elendil, netdev, linux-kernel
In-Reply-To: <20080115.210214.170759690.davem@davemloft.net>
David Miller wrote:
> From: "Brandeburg, Jesse" <jesse.brandeburg@intel.com>
> Date: Tue, 15 Jan 2008 13:53:43 -0800
>
>> The tx code has an "early exit" that tries to limit the amount of tx
>> packets handled in a single poll loop and requires napi or interrupt
>> rescheduling based on the return value from e1000_clean_tx_irq.
>
> That explains everything, thanks Jesse.
>
> Ok, here is the patch I'll propose to fix this. The goal is to make
> it as simple as possible without regressing the thing we were trying
> to fix.
We spent Wednesday trying to reproduce (without the patch) these issues
without much luck, and have applied the patch cleanly and will continue
testing it. Given the simplicity of the changes, and the community
testing, I'll give my ack and we will continue testing.
I think we should fix Robert's (unrelated, but in this thread) reported
issue before 2.6.24 final if we can, and I'll look at that tonight and
tomorrow.
Thanks for your work on this Dave,
Jesse
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
^ permalink raw reply
* [PATCH] e1000e Kconfig: remove ref to nonexistant docs
From: Jason Uhlenkott @ 2008-01-17 7:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Auke Kok
There is no Documentation/networking/e1000e.txt.
Signed-off-by: Jason Uhlenkott <jasonuhl@jasonuhl.org>
Cc: Auke Kok <auke-jan.h.kok@intel.com>
---
Index: linux/drivers/net/Kconfig
===================================================================
--- linux.orig/drivers/net/Kconfig 2008-01-16 17:48:03.041103083 -0800
+++ linux/drivers/net/Kconfig 2008-01-16 23:00:23.647430487 -0800
@@ -1976,9 +1976,6 @@
<http://support.intel.com>
- More specific information on configuring the driver is in
- <file:Documentation/networking/e1000e.txt>.
-
To compile this driver as a module, choose M here. The module
will be called e1000e.
^ permalink raw reply
* [PATCH] BUG_ON() bad input to request_irq
From: Rusty Russell @ 2008-01-17 6:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel, Andrew Morton
In-Reply-To: <200801171757.59026.rusty@rustcorp.com.au>
Is there any reason why these bugs should be treated gently? The
caller might not want to check NR_IRQS and IRQ_NOREQUEST cases, but
a NULL handler or NULL dev_id w/ shared are coding bugs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
kernel/irq/manage.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff -r c2eb8ef5a0be kernel/irq/manage.c
--- a/kernel/irq/manage.c Thu Jan 17 15:48:03 2008 +1100
+++ b/kernel/irq/manage.c Thu Jan 17 15:49:33 2008 +1100
@@ -532,13 +532,12 @@ int request_irq(unsigned int irq, irq_ha
* which interrupt is which (messes up the interrupt freeing
* logic etc).
*/
- if ((irqflags & IRQF_SHARED) && !dev_id)
- return -EINVAL;
+ BUG_ON((irqflags & IRQF_SHARED) && !dev_id);
+ BUG_ON(!handler);
+
if (irq >= NR_IRQS)
return -EINVAL;
if (irq_desc[irq].status & IRQ_NOREQUEST)
- return -EINVAL;
- if (!handler)
return -EINVAL;
action = kmalloc(sizeof(struct irqaction), GFP_ATOMIC);
^ permalink raw reply
* [PATCH] request_irq() always returns -EINVAL with a NULL handler.
From: Rusty Russell @ 2008-01-17 6:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
I assume that these ancient network drivers were trying to find out if
an irq is available. eepro.c expecting +EBUSY was doubly wrong.
I'm not sure that can_request_irq() is the right thing, but these drivers
are definitely wrong.
request_irq should BUG() on bad input, and these would have been found
earlier.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/net/3c503.c | 2 +-
drivers/net/e2100.c | 2 +-
drivers/net/eepro.c | 2 +-
drivers/net/hp.c | 2 +-
kernel/irq/manage.c | 1 +
5 files changed, 5 insertions(+), 4 deletions(-)
diff -r 0b7e4fbb6238 drivers/net/3c503.c
--- a/drivers/net/3c503.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/3c503.c Thu Jan 17 16:40:28 2008 +1100
@@ -379,7 +379,7 @@ el2_open(struct net_device *dev)
outb(EGACFR_NORM, E33G_GACFR); /* Enable RAM and interrupts. */
do {
- if (request_irq (*irqp, NULL, 0, "bogus", dev) != -EBUSY) {
+ if (can_request_irq(*irqp, 0)) {
/* Twinkle the interrupt, and check if it's seen. */
unsigned long cookie = probe_irq_on();
outb_p(0x04 << ((*irqp == 9) ? 2 : *irqp), E33G_IDCFR);
diff -r 0b7e4fbb6238 drivers/net/e2100.c
--- a/drivers/net/e2100.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/e2100.c Thu Jan 17 16:40:28 2008 +1100
@@ -202,7 +202,7 @@ static int __init e21_probe1(struct net_
if (dev->irq < 2) {
int irqlist[] = {15,11,10,12,5,9,3,4}, i;
for (i = 0; i < 8; i++)
- if (request_irq (irqlist[i], NULL, 0, "bogus", NULL) != -EBUSY) {
+ if (can_request_irq(irqlist[i], 0)) {
dev->irq = irqlist[i];
break;
}
diff -r 0b7e4fbb6238 drivers/net/eepro.c
--- a/drivers/net/eepro.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/eepro.c Thu Jan 17 16:40:28 2008 +1100
@@ -914,7 +914,7 @@ static int eepro_grab_irq(struct net_dev
eepro_sw2bank0(ioaddr); /* Switch back to Bank 0 */
- if (request_irq (*irqp, NULL, IRQF_SHARED, "bogus", dev) != EBUSY) {
+ if (can_request_irq(*irqp, IRQF_SHARED)) {
unsigned long irq_mask;
/* Twinkle the interrupt, and check if it's seen */
irq_mask = probe_irq_on();
diff -r 0b7e4fbb6238 drivers/net/hp.c
--- a/drivers/net/hp.c Thu Jan 17 15:49:34 2008 +1100
+++ b/drivers/net/hp.c Thu Jan 17 16:40:28 2008 +1100
@@ -170,7 +170,7 @@ static int __init hp_probe1(struct net_d
int *irqp = wordmode ? irq_16list : irq_8list;
do {
int irq = *irqp;
- if (request_irq (irq, NULL, 0, "bogus", NULL) != -EBUSY) {
+ if (can_request_irq(irq, 0)) {
unsigned long cookie = probe_irq_on();
/* Twinkle the interrupt, and check if it's seen. */
outb_p(irqmap[irq] | HP_RUN, ioaddr + HP_CONFIGURE);
diff -r 0b7e4fbb6238 kernel/irq/manage.c
--- a/kernel/irq/manage.c Thu Jan 17 15:49:34 2008 +1100
+++ b/kernel/irq/manage.c Thu Jan 17 16:40:28 2008 +1100
@@ -252,6 +252,7 @@ int can_request_irq(unsigned int irq, un
return !action;
}
+EXPORT_SYMBOL(can_request_irq);
void compat_irq_chip_set_default_handler(struct irq_desc *desc)
{
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Timo Teräs @ 2008-01-17 6:27 UTC (permalink / raw)
To: Herbert Xu; +Cc: hadi, netdev
In-Reply-To: <E1JFHDM-00010A-00@gondolin.me.apana.org.au>
Herbert Xu wrote:
> jamal <hadi@cyberus.ca> wrote:
>> There are two issues that are inter-mingled in there. The most important
>> is pf_key not being robust on dump. The other being the accurracy of
>
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over xfrm_user since neither is portable. So we
> should discourage people from using af_key wherever possible.
I don't know about netlink. But pfkey works in *BSD too and it is RFC'd.
So I'd say pfkey might be a bit more portable. Though netlink is definitely
more robust and extensive.
Cheers,
Timo
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Timo Teräs @ 2008-01-17 5:54 UTC (permalink / raw)
To: Herbert Xu; +Cc: jamal, netdev
In-Reply-To: <20080117021743.GA5182@gondor.apana.org.au>
jamal wrote:
> On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
>> > No. I'm not creating second copies of the SADB/SPD entries. The entries
>> > are just added to one more list.
>
> Ah, sorry - yes, that sounds reasonable.
> So what happens if i delete an entry; does it get removed from the list?
> Also what happens on modification?
If the entry is removed befored it is dumped, it wont be dumped at all.
The state during dump code execution is returned. Depending when the
modification occurs it might or might not be reflected in the dumped
entry.
>> > If more entries are added, you can get notifications of them.
>
> how would a user app (example racoon) appropriately deal with it?
> Example an entry sits in the dump-list, it gets deleted - an event gets
> generated user-space and later that entry shows up in user space dump.
You listen for the events. It is guaranteed that if the dumping code
does return the entry to be deleted, the deletion notification will
occur after that dump entry.
Herbert Xu wrote:
> On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote:
>> I wouldnt disagree except some apps like racoon which depend on pfkey
>> are unfortunately beyond repair. Timo has a pretty good handle on the
>
> Racoon doesn't use pfkey dumping as far as I know.
ipsec-tools racoon uses pfkey and only pfkey. And it's non trivial to
make it use netlink; it relies heavily all around the code to pfkey
structs. It also runs on BSD so we cannot rip pfkey away; adding a
layer to work with both pfkey and netlink would be doable, but just a
lot of work.
Also ipsec-tools racoon seems to be the default IKE daemon in some
popular distros. So for the time being I think pfkey is an evil we have
to live with.
Cheers,
Timo
^ permalink raw reply
* Re: [PATCH 4/4] bonding: Fix some RTNL taking
From: Makito SHIOKAWA @ 2008-01-17 5:30 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev, Makito SHIOKAWA
In-Reply-To: <20080116124450.GD2307@ff.dom.local>
> Maybe I'm wrong, but since this read_lock() is given and taken anyway,
> it seems this looks a bit better to me (why hold this rtnl longer
> than needed?):
> read_unlock(&bond->lock);
> rtnl_unlock();
> read_lock(&bond->lock);
Seems better.
> On the other hand, probably 'if (bond->kill_timers)' could be repeated
> after this read_lock() retaking.
Sorry, what do you mean? (A case that bond->kill_timers = 1 is done during
lock retaking, and work being queued only to do 'if (bond->kill_timers)'? If
so, I think that won't differ much.)
> If this if () is really necessary here, then this should be better
> before "delay = ..." with a block.
I agree.
--
Makito SHIOKAWA
MIRACLE LINUX CORPORATION
^ permalink raw reply
* Re: [PATCH 3/4] bonding: Fix work rearming
From: Makito SHIOKAWA @ 2008-01-17 5:30 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev, Makito SHIOKAWA
In-Reply-To: <20080116133646.GE2307@ff.dom.local>
> But, since during this change from sysfs cancel_delayed_work_sync()
> could be probably used, and it's rather efficient with killing
> rearming works, it seems this check could be unnecessary yet.
What going to be cancelled in bonding_store_miimon() when setting miimon to 0
is arp monitor, not mii monitor. So, this check will be needed to stop
rearming mii monitor when value 0 is set to miimon.
--
Makito SHIOKAWA
MIRACLE LINUX CORPORATION
^ permalink raw reply
* Re: [patch] add net_device_stats support to ethtool
From: Dan Nicolaescu @ 2008-01-17 5:13 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <478E5122.1060009@candelatech.com>
Ben Greear <greearb@candelatech.com> writes:
> Dan Nicolaescu wrote:
> > Ben Greear <greearb@candelatech.com> writes:
> >
> > > Dan Nicolaescu wrote:
> > > > Hi,
> > > >
> > > > I have posted this patch in the past with absolutely no reply.
> > > > I would appreciate some sort of feedback of the form interested/not
> > > > interested. Should I just drop it?
> > > >
> > > > > I like it, but why not offer this for all devices since
> > they all have
> > > these stats.
> > >
> > > Could add new handlers called something like .get_strings_generic, or
> > > just add this to the higher-level ethtool handling before it looks for
> > > handlers.
> >
> > If I get your point, then the difference would be that drivers would add
> > to the initialization of the ethtool structure something like:
> >
> I meant something more like this (this will not apply..I hand-edited
> it to remove
> some extraneous crap from my patch...and I'm sure it's white-space damaged).
OK.
Hopefully someone can pick up these patches to be merged...
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Herbert Xu @ 2008-01-17 2:17 UTC (permalink / raw)
To: jamal; +Cc: timo.teras, netdev
In-Reply-To: <1200533980.4451.100.camel@localhost>
On Wed, Jan 16, 2008 at 08:39:40PM -0500, jamal wrote:
>
> I wouldnt disagree except some apps like racoon which depend on pfkey
> are unfortunately beyond repair. Timo has a pretty good handle on the
Racoon doesn't use pfkey dumping as far as I know.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: jamal @ 2008-01-17 1:39 UTC (permalink / raw)
To: Herbert Xu; +Cc: timo.teras, netdev
In-Reply-To: <E1JFHDM-00010A-00@gondolin.me.apana.org.au>
On Thu, 2008-17-01 at 09:58 +1100, Herbert Xu wrote:
> IMHO doing significant work on af_key is a waste of time. It has no
> advantages at all over xfrm_user since neither is portable. So we
> should discourage people from using af_key wherever possible.
I wouldnt disagree except some apps like racoon which depend on pfkey
are unfortunately beyond repair. Timo has a pretty good handle on the
issue from what i have seen so far, so it pretty much seems to be there
without significant changes (if the two issues are separated).
cheers,
jamal
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: jamal @ 2008-01-17 1:25 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <478E1479.3020204@iki.fi>
On Wed, 2008-16-01 at 16:28 +0200, Timo Teräs wrote:
[..]
> Creating a separate af_key patch would not be a big problem. I was
> just hoping avoiding it as the xfrm_state / xfrm_policy changes
> modify the API and requires changing af_key also.
The way dumping is done by xfrm_user is consistent across all netlink
not just ipsec. Thats why i said it had broader implications.
OTOH, theres a clear issue with pf_key.
> No. I'm not creating second copies of the SADB/SPD entries. The entries
> are just added to one more list.
Ah, sorry - yes, that sounds reasonable.
So what happens if i delete an entry; does it get removed from the list?
Also what happens on modification?
> If more entries are added, you can get notifications of them.
how would a user app (example racoon) appropriately deal with it?
Example an entry sits in the dump-list, it gets deleted - an event gets
generated user-space and later that entry shows up in user space dump.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: Wang Chen @ 2008-01-17 0:55 UTC (permalink / raw)
To: David Stevens; +Cc: Herbert Xu, davem, netdev
In-Reply-To: <OF0A9FA609.40104566-ON882573D2.0057C6DA-882573D2.005A0894@us.ibm.com>
David Stevens said the following on 2008-1-17 0:23:
> Wang,
> I think your patch is correct; did you test the same case for
> IPv6?
>
I've tested IPv4, but IPv6 not yet.
If Davem accept this one, I will see the IPv6, or you take care of it.
--
WCN
^ permalink raw reply
* Re: [PATCH] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: David Stevens @ 2008-01-17 0:10 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, herbert, netdev, netdev-owner, wangchen
In-Reply-To: <E1JFHVh-00012A-00@gondolin.me.apana.org.au>
netdev-owner@vger.kernel.org wrote on 01/16/2008 03:17:29 PM:
> Fair enough. How about moving this code back into icmp.c and just
> add a new count call in raw.c? The push pending function is used on
> the UDP fast path so the leaner it is the better.
I started out with it there, but it certainly wasn't
cleaner. You have to peek on the queue, which I didn't
want to do for all the SMP issues that brings in, and
then replicate all the code push_pending_frames does to
get you a protocol header pointer in one buffer, and there
are multiple ways in the raw path to get you there (so the
counter code itself would appear in multiple places).
I don't think the 2 instructions measurably impact
anything in the fast path and that is the earliest common
point for the multiple paths to generate ICMP output where
the header and type are available without replicating code.
So, simplicity is exactly why I put it there, rather than
the "obvious" places at the higher layer. :-) It's probably
the better, single place to put the other protocol "out messages"
counters, too, since those probably also have multiple paths
that end up here, but ICMPMsgStats was all that patch was
after.
+-DLS
^ permalink raw reply
* Re: [PATCH] ICMP: ICMP_MIB_OUTMSGS increment duplicated
From: Herbert Xu @ 2008-01-16 23:17 UTC (permalink / raw)
To: David Stevens; +Cc: herbert, davem, netdev, wangchen
In-Reply-To: <OF0A9FA609.40104566-ON882573D2.0057C6DA-882573D2.005A0894@us.ibm.com>
David Stevens <dlstevens@us.ibm.com> wrote:
>
> The patch was to support the ICMPMsgStats table. Since none of
> certain
> types of output ICMP messages are generated by the kernel, but are
> required
> by the RFC, counting raw sockets is intentional (and the only way those
> ICMP
> types can be counted at all).
> Raw UDP packets would not be counted either before or after the
> patch,
> but aren't part of the ICMPMsgStats table. Adding those might be
> worthwhile,
> but it isn't quite the hole that the ICMP out stats were, since there is a
> cooked interface for UDP output that counts the common use, at least.
Fair enough. How about moving this code back into icmp.c and just
add a new count call in raw.c? The push pending function is used on
the UDP fast path so the leaner it is the better.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC][PATCH] Fixing SA/SP dumps on netlink/af_key
From: Herbert Xu @ 2008-01-16 22:58 UTC (permalink / raw)
To: hadi; +Cc: timo.teras, netdev
In-Reply-To: <1200491531.4457.91.camel@localhost>
jamal <hadi@cyberus.ca> wrote:
>
> There are two issues that are inter-mingled in there. The most important
> is pf_key not being robust on dump. The other being the accurracy of
IMHO doing significant work on af_key is a waste of time. It has no
advantages at all over xfrm_user since neither is portable. So we
should discourage people from using af_key wherever possible.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: Jarek Poplawski @ 2008-01-16 22:42 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Herbert Xu, cfriesen, davem, netdev, linux-kernel
In-Reply-To: <20080116200458.GC8953@1wt.eu>
On Wed, Jan 16, 2008 at 09:04:58PM +0100, Willy Tarreau wrote:
...
> you can work with latest release provided that you always have a fallback
> to an earlier one. That way, you don't bet too much on something you don't
> completely control. If it works, it tells you you'll be able to completely
> exploit its new possibilities in next product release, and if it breaks,
> it's easy to issue a fix to get back to earlier, well-tested version.
Of course, this way looks preferable, but sometimes maybe too costly,
especially with some complex systems. Actually, I don't even think
this have to be fully (production ready) implemented or workable.
Probably there would be even enough to maintain some simplified kind
of test checking how current kernel changes could affect such a system,
and how new versions of this system are better, BTW.
Regards,
Jarek P.
^ permalink raw reply
* sctp use-uninitialized warning in net-2.6.25
From: Andrew Morton @ 2008-01-16 21:59 UTC (permalink / raw)
To: netdev
net/sctp/sm_statefuns.c: In function 'sctp_sf_do_5_1C_ack':
net/sctp/sm_statefuns.c:484: warning: 'error' may be used uninitialized in this function
It is not obvious that this is a false positive.
^ permalink raw reply
* Please pull 'fixes-jgarzik' branch of wireless-2.6
From: John W. Linville @ 2008-01-16 21:27 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-wireless
Jeff,
A few more fixes for 2.6.24...note that this branch is based
on 2.6.24-rc8.
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-jgarzik/
---
The following changes since commit cbd9c883696da72b2b1f03f909dbacc04bbf8b58:
Linus Torvalds (1):
Linux 2.6.24-rc8
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-jgarzik
Ivo van Doorn (1):
rt2x00: Fix ieee80211 payload alignment
Marc Pignat (1):
wireless/libertas support for 88w8385 sdio older revision
Randy Dunlap (1):
hostap: section mismatch warning
Stefano Brivio (2):
ipw2200: fix typo in kerneldoc
b43: fix use-after-free rfkill bug
drivers/net/wireless/b43/rfkill.c | 11 ++++++-----
drivers/net/wireless/hostap/hostap_plx.c | 6 +++---
drivers/net/wireless/ipw2200.c | 2 +-
drivers/net/wireless/libertas/if_sdio.c | 4 ++++
drivers/net/wireless/rt2x00/rt2x00pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 11 +++++++++--
6 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c
index 98cf70c..11f53cb 100644
--- a/drivers/net/wireless/b43/rfkill.c
+++ b/drivers/net/wireless/b43/rfkill.c
@@ -138,8 +138,11 @@ void b43_rfkill_init(struct b43_wldev *dev)
rfk->rfkill->user_claim_unsupported = 1;
rfk->poll_dev = input_allocate_polled_device();
- if (!rfk->poll_dev)
- goto err_free_rfk;
+ if (!rfk->poll_dev) {
+ rfkill_free(rfk->rfkill);
+ goto err_freed_rfk;
+ }
+
rfk->poll_dev->private = dev;
rfk->poll_dev->poll = b43_rfkill_poll;
rfk->poll_dev->poll_interval = 1000; /* msecs */
@@ -175,8 +178,7 @@ err_unreg_rfk:
err_free_polldev:
input_free_polled_device(rfk->poll_dev);
rfk->poll_dev = NULL;
-err_free_rfk:
- rfkill_free(rfk->rfkill);
+err_freed_rfk:
rfk->rfkill = NULL;
out_error:
rfk->registered = 0;
@@ -195,6 +197,5 @@ void b43_rfkill_exit(struct b43_wldev *dev)
rfkill_unregister(rfk->rfkill);
input_free_polled_device(rfk->poll_dev);
rfk->poll_dev = NULL;
- rfkill_free(rfk->rfkill);
rfk->rfkill = NULL;
}
diff --git a/drivers/net/wireless/hostap/hostap_plx.c b/drivers/net/wireless/hostap/hostap_plx.c
index 040dc3e..cbf15d7 100644
--- a/drivers/net/wireless/hostap/hostap_plx.c
+++ b/drivers/net/wireless/hostap/hostap_plx.c
@@ -608,7 +608,7 @@ static void prism2_plx_remove(struct pci_dev *pdev)
MODULE_DEVICE_TABLE(pci, prism2_plx_id_table);
-static struct pci_driver prism2_plx_drv_id = {
+static struct pci_driver prism2_plx_driver = {
.name = "hostap_plx",
.id_table = prism2_plx_id_table,
.probe = prism2_plx_probe,
@@ -618,13 +618,13 @@ static struct pci_driver prism2_plx_drv_id = {
static int __init init_prism2_plx(void)
{
- return pci_register_driver(&prism2_plx_drv_id);
+ return pci_register_driver(&prism2_plx_driver);
}
static void __exit exit_prism2_plx(void)
{
- pci_unregister_driver(&prism2_plx_drv_id);
+ pci_unregister_driver(&prism2_plx_driver);
}
diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index 88062c1..003f73f 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -4935,7 +4935,7 @@ static int ipw_queue_reset(struct ipw_priv *priv)
/**
* Reclaim Tx queue entries no more used by NIC.
*
- * When FW adwances 'R' index, all entries between old and
+ * When FW advances 'R' index, all entries between old and
* new 'R' index need to be reclaimed. As result, some free space
* forms. If there is enough free space (> low mark), wake Tx queue.
*
diff --git a/drivers/net/wireless/libertas/if_sdio.c b/drivers/net/wireless/libertas/if_sdio.c
index b24425f..4f1efb1 100644
--- a/drivers/net/wireless/libertas/if_sdio.c
+++ b/drivers/net/wireless/libertas/if_sdio.c
@@ -871,6 +871,10 @@ static int if_sdio_probe(struct sdio_func *func,
if (sscanf(func->card->info[i],
"ID: %x", &model) == 1)
break;
+ if (!strcmp(func->card->info[i], "IBIS Wireless SDIO Card")) {
+ model = 4;
+ break;
+ }
}
if (i == func->card->num_info) {
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index 6d5d9ab..04663eb 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -149,7 +149,7 @@ void rt2x00pci_rxdone(struct rt2x00_dev *rt2x00dev)
* The data behind the ieee80211 header must be
* aligned on a 4 byte boundary.
*/
- align = NET_IP_ALIGN + (2 * (header_size % 4 == 0));
+ align = header_size % 4;
/*
* Allocate the sk_buffer, initialize it and copy
diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index ab4797e..568d738 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -245,13 +245,20 @@ static void rt2x00usb_interrupt_rxdone(struct urb *urb)
* Allocate a new sk buffer to replace the current one.
* If allocation fails, we should drop the current frame
* so we can recycle the existing sk buffer for the new frame.
+ * As alignment we use 2 and not NET_IP_ALIGN because we need
+ * to be sure we have 2 bytes room in the head. (NET_IP_ALIGN
+ * can be 0 on some hardware). We use these 2 bytes for frame
+ * alignment later, we assume that the chance that
+ * header_size % 4 == 2 is bigger then header_size % 2 == 0
+ * and thus optimize alignment by reserving the 2 bytes in
+ * advance.
*/
frame_size = entry->ring->data_size + entry->ring->desc_size;
- skb = dev_alloc_skb(frame_size + NET_IP_ALIGN);
+ skb = dev_alloc_skb(frame_size + 2);
if (!skb)
goto skip_entry;
- skb_reserve(skb, NET_IP_ALIGN);
+ skb_reserve(skb, 2);
skb_put(skb, frame_size);
/*
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply related
* Please pull 'fixes-davem' branch of wireless-2.6
From: John W. Linville @ 2008-01-16 21:26 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Dave,
One more fix for rfkill in 2.6.24...note that this branch is based
on 2.6.24-rc8.
Thanks,
John
---
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/fixes-davem/
---
The following changes since commit cbd9c883696da72b2b1f03f909dbacc04bbf8b58:
Linus Torvalds (1):
Linux 2.6.24-rc8
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git fixes-davem
Eric Paris (1):
rfkill: call rfkill_led_trigger_unregister() on error
net/rfkill/rfkill.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/rfkill/rfkill.c b/net/rfkill/rfkill.c
index 4469a7b..d06d338 100644
--- a/net/rfkill/rfkill.c
+++ b/net/rfkill/rfkill.c
@@ -392,11 +392,14 @@ int rfkill_register(struct rfkill *rfkill)
rfkill_led_trigger_register(rfkill);
error = rfkill_add_switch(rfkill);
- if (error)
+ if (error) {
+ rfkill_led_trigger_unregister(rfkill);
return error;
+ }
error = device_add(dev);
if (error) {
+ rfkill_led_trigger_unregister(rfkill);
rfkill_remove_switch(rfkill);
return error;
}
--
John W. Linville
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org
^ permalink raw reply related
* Re: questions on NAPI processing latency and dropped network packets
From: Willy Tarreau @ 2008-01-16 20:04 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Herbert Xu, cfriesen, davem, netdev, linux-kernel
In-Reply-To: <20080116065836.GA1638@ff.dom.local>
On Wed, Jan 16, 2008 at 07:58:36AM +0100, Jarek Poplawski wrote:
> On Wed, Jan 16, 2008 at 11:17:08AM +1100, Herbert Xu wrote:
> ...
> > Well people are always going to operate on this model for commercial
> > reasons. FWIW I used to work for a company that stuck to a specific
> > version of the Linux kernel, and I suppose I still do even now :)
> >
> > But the important thing is that if you're going to do that, then the
> > cost that comes with it should be borne by the company and not the
> > community.
>
> Sure. But the most sad thing is there seems to be not so much savings
> in this (unless a company isn't sure of its near future). Trying to
> upgrade and test current products with current kernels, even if not
> necessary, should be always useful and make developing of new products
> faster and better fit (and of course, BTW, make the kernel better on
> time).
you can work with latest release provided that you always have a fallback
to an earlier one. That way, you don't bet too much on something you don't
completely control. If it works, it tells you you'll be able to completely
exploit its new possibilities in next product release, and if it breaks,
it's easy to issue a fix to get back to earlier, well-tested version.
Regards,
Willy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox