* Re: [patch] ipv4: fix lock usage in udp_ioctl
From: David Miller @ 2006-06-14 22:16 UTC (permalink / raw)
To: heiko.carstens; +Cc: jgarzik, akpm, linux-kernel, netdev, mingo, fpavlic
In-Reply-To: <20060614194305.GB10391@osiris.ibm.com>
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Wed, 14 Jun 2006 21:43:05 +0200
> From: Heiko Carstens <heiko.carstens@de.ibm.com>
>
> Fix lock usage in udp_ioctl().
>
> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
More likely the qeth driver shouldn't call into the socket code in
hardware interrupt context. From your logs that's what it seems is
happening.
The socket receive queue should only be touched in software
interrupt context, never in hardware interrupt context. That's
why the locking does BH disabling at best.
^ permalink raw reply
* [Ubuntu PATCH] Broadcom wireless patch, PCIE/Mactel support
From: Randy Dunlap @ 2006-06-14 23:22 UTC (permalink / raw)
To: lkml, netdev; +Cc: mb, akpm
From: Matthew Garrett <mjg59@srcf.ucam.org>
Broadcom wireless patch, PCIE/Mactel support
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1373a8487e911b5ee204f4422ddea00929c8a4cc
This patch adds support for PCIE cores to the bcm43xx driver. This is
needed for wireless to work on the Intel imacs. I've submitted it to
bcm43xx upstream.
(cherry picked from d88edf6a433074323a1805365a8dfc9c26fceae3 commit)
(cherry picked from 7dbd83ed3255fde4371edcbb6ad1d30f3e6ddf08 commit)
---
--- a/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -202,6 +202,8 @@
#define BCM43xx_COREID_USB20_HOST 0x819
#define BCM43xx_COREID_USB20_DEV 0x81a
#define BCM43xx_COREID_SDIO_HOST 0x81b
+#define BCM43xx_COREID_PCIE 0x820
+#define BCM43xx_COREID_CHIPCOMMON_NEW 0x900
/* Core Information Registers */
#define BCM43xx_CIR_BASE 0xf00
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -130,6 +130,8 @@ MODULE_PARM_DESC(fwpostfix, "Postfix for
{ PCI_VENDOR_ID_BROADCOM, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4307 802.11b */
{ PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
+ /* Broadcom 4312 80211a/b/g */
+ { PCI_VENDOR_ID_BROADCOM, 0x4312, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
/* Broadcom 4318 802.11b/g */
{ PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
/* Broadcom 4319 802.11a/b/g */
@@ -2580,7 +2582,8 @@ static int bcm43xx_probe_cores(struct bc
core_vendor = (sb_id_hi & 0xFFFF0000) >> 16;
/* if present, chipcommon is always core 0; read the chipid from it */
- if (core_id == BCM43xx_COREID_CHIPCOMMON) {
+ if (core_id == BCM43xx_COREID_CHIPCOMMON ||
+ core_id == BCM43xx_COREID_CHIPCOMMON_NEW) {
chip_id_32 = bcm43xx_read32(bcm, 0);
chip_id_16 = chip_id_32 & 0xFFFF;
bcm->core_chipcommon.available = 1;
@@ -2614,7 +2617,8 @@ static int bcm43xx_probe_cores(struct bc
/* ChipCommon with Core Rev >=4 encodes number of cores,
* otherwise consult hardcoded table */
- if ((core_id == BCM43xx_COREID_CHIPCOMMON) && (core_rev >= 4)) {
+ if (((core_id == BCM43xx_COREID_CHIPCOMMON) && (core_rev >= 4)) ||
+ core_id == BCM43xx_COREID_CHIPCOMMON_NEW) {
core_count = (chip_id_32 & 0x0F000000) >> 24;
} else {
switch (chip_id_16) {
@@ -2686,6 +2690,7 @@ static int bcm43xx_probe_cores(struct bc
core = NULL;
switch (core_id) {
case BCM43xx_COREID_PCI:
+ case BCM43xx_COREID_PCIE:
core = &bcm->core_pci;
if (core->available) {
printk(KERN_WARNING PFX "Multiple PCI cores found.\n");
@@ -2724,6 +2729,7 @@ static int bcm43xx_probe_cores(struct bc
case 6:
case 7:
case 9:
+ case 10:
break;
default:
printk(KERN_ERR PFX "Error: Unsupported 80211 core revision %u\n",
@@ -3002,7 +3008,7 @@ static int bcm43xx_setup_backplane_pci_c
if (err)
goto out;
- if (bcm->core_pci.rev < 6) {
+ if (bcm->core_pci.rev < 6 && bcm->core_pci.id != BCM43xx_COREID_PCIE) {
value = bcm43xx_read32(bcm, BCM43xx_CIR_SBINTVEC);
value |= (1 << backplane_flag_nr);
bcm43xx_write32(bcm, BCM43xx_CIR_SBINTVEC, value);
@@ -3024,7 +3030,7 @@ static int bcm43xx_setup_backplane_pci_c
value |= BCM43xx_SBTOPCI2_PREFETCH | BCM43xx_SBTOPCI2_BURST;
bcm43xx_write32(bcm, BCM43xx_PCICORE_SBTOPCI2, value);
- if (bcm->core_pci.rev < 5) {
+ if (bcm->core_pci.rev < 5 && bcm->core_pci.id != BCM43xx_COREID_PCIE) {
value = bcm43xx_read32(bcm, BCM43xx_CIR_SBIMCONFIGLOW);
value |= (2 << BCM43xx_SBIMCONFIGLOW_SERVICE_TOUT_SHIFT)
& BCM43xx_SBIMCONFIGLOW_SERVICE_TOUT_MASK;
@@ -3351,7 +3357,7 @@ static int bcm43xx_read_phyinfo(struct b
bcm->ieee->freq_band = IEEE80211_24GHZ_BAND;
break;
case BCM43xx_PHYTYPE_G:
- if (phy_rev > 7)
+ if (phy_rev > 8)
phy_rev_ok = 0;
bcm->ieee->modulation = IEEE80211_OFDM_MODULATION |
IEEE80211_CCK_MODULATION;
^ permalink raw reply
* [Ubuntu PATCH] IRDA: Add some IBM think pads
From: Randy Dunlap @ 2006-06-14 23:23 UTC (permalink / raw)
To: netdev; +Cc: akpm, samuel
From: Ben Collins <bcollins@ubuntu.com>
[UBUNTU:nsc-ircc] Add some IBM think pads
Add Thinkpad T60/X60/Z60/T43/R52 Infrared driver support.
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=7b8d2713435a9fb69719a282ba75e117f3f76a5b
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
---
--- a/drivers/net/irda/nsc-ircc.c
+++ b/drivers/net/irda/nsc-ircc.c
@@ -115,8 +115,12 @@ static nsc_chip_t chips[] = {
/* Contributed by Jan Frey - IBM A30/A31 */
{ "PC8739x", { 0x2e, 0x4e, 0x0 }, 0x20, 0xea, 0xff,
nsc_ircc_probe_39x, nsc_ircc_init_39x },
- { "IBM", { 0x2e, 0x4e, 0x0 }, 0x20, 0xf4, 0xff,
- nsc_ircc_probe_39x, nsc_ircc_init_39x },
+ /* IBM ThinkPads using PC8738x (T60/X60/Z60) */
+ { "IBM-PC8738x", { 0x2e, 0x4e, 0x0 }, 0x20, 0xf4, 0xff,
+ nsc_ircc_probe_39x, nsc_ircc_init_39x },
+ /* IBM ThinkPads using PC8394T (T43/R52/?) */
+ { "IBM-PC8394T", { 0x2e, 0x4e, 0x0 }, 0x20, 0xf9, 0xff,
+ nsc_ircc_probe_39x, nsc_ircc_init_39x },
{ NULL }
};
^ permalink raw reply
* [Ubuntu PATCH] Make tulip driver not handle Davicom NICs
From: Randy Dunlap @ 2006-06-14 23:23 UTC (permalink / raw)
To: netdev, akpm, val_henson
Make tulip driver not handle Davicom NICs, let dmfe take over"
Reference: https://launchpad.net/bugs/48287
Source URL of Patch:
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=1804482911a71bee9114cae1c2079507a38e9e7f
--- linux-2.6.17-rc5/drivers/net/tulip/tulip_core.c 2006-06-05 09:20:30.000000000 +0800
+++ ubuntu-kernel/drivers/net/tulip/tulip_core.c 2006-06-05 09:56:55.000000000 +0800
@@ -223,8 +223,12 @@
{ 0x1259, 0xa120, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x11F6, 0x9881, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMPEX9881 },
{ 0x8086, 0x0039, PCI_ANY_ID, PCI_ANY_ID, 0, 0, I21145 },
+ /* dmfe module seems to handle these better. See:
+ * https://launchpad.net/bugs/48287 */
+#if 0
{ 0x1282, 0x9100, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
{ 0x1282, 0x9102, PCI_ANY_ID, PCI_ANY_ID, 0, 0, DM910X },
+#endif
{ 0x1113, 0x1216, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
{ 0x1113, 0x1217, PCI_ANY_ID, PCI_ANY_ID, 0, 0, MX98715 },
{ 0x1113, 0x9511, PCI_ANY_ID, PCI_ANY_ID, 0, 0, COMET },
^ permalink raw reply
* [Ubuntu PATCH] forcedeth: Let the driver work when no PHY is found
From: Randy Dunlap @ 2006-06-14 23:23 UTC (permalink / raw)
To: netdev; +Cc: akpm, manfred, jgarzik
From: Ben Collins <bcollins@ubuntu.com>
[UBUNTU:forcedeth] Let the driver work when no PHY is found
This matches breezy behavior.
Reference: https://launchpad.net/products/launchpad/+bug/45257
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=38c1aaedc1f907e138698e54ceadeb9ae560b0d7
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
---
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -2582,14 +2582,13 @@ static int __devinit nv_probe(struct pci
np->phy_oui = id1 | id2;
break;
}
- if (i == 33) {
+
+ /* Let the damn card work if it can */
+ if (i == 33)
printk(KERN_INFO "%s: open: Could not find a valid PHY.\n",
pci_name(pci_dev));
- goto out_freering;
- }
-
- /* reset it */
- phy_init(dev);
+ else
+ phy_init(dev);
/* set default link speed settings */
np->linkspeed = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10;
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-14 22:25 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Grant Grundler, Valerie Henson, Andrew Morton, netdev
In-Reply-To: <449068C9.1010304@pobox.com>
On Wed, Jun 14, 2006 at 03:51:37PM -0400, Jeff Garzik wrote:
> You need to turn off the thing that generates work (DMA engine), before
> turning off the thing that reaps work (irq handler).
...
> It should be completely obvious that the chip is still generating
> work...
Yes, I agree it still generates work. ie we can still RX packets.
But those will get discarded anyway.
In other words, If work is generated and I don't know it and
don't care, was it really work? :)
> You don't want to leave the hardware in a position where it has
> unacknowledged events.
Ok. Let me repeat two questions I asked a while ago:
| Are you worried about a masked, pending interrupt causing
| problems when the driver is re-opened or resumed?
The answer to "Yes" it seems.
And we will disagree on that since I've proven it's not a problem.
And it can't be a problem anyone else has seen since it's been
this way for 5+ years.
| If firmware left the device in that state at boot time wouldn't
| the driver be required to handle it?
Can you comment on this please?
thanks,
grant
^ permalink raw reply
* Re: PATCHv3 2.6.17-rc5 tulip free_irq() called too late
From: Grant Grundler @ 2006-06-14 22:30 UTC (permalink / raw)
To: Francois Romieu
Cc: Grant Grundler, Jeff Garzik, Valerie Henson, Andrew Morton,
netdev
In-Reply-To: <20060614204720.GA17887@electric-eye.fr.zoreil.com>
On Wed, Jun 14, 2006 at 10:47:20PM +0200, Francois Romieu wrote:
> Grant Grundler <grundler@parisc-linux.org> :
> [...]
> > I'm not keen on adding more code to tulip_interrupt() routine
> > for something that rarely happens (compared to IRQs) and is handled
> > outside the interrupt routine. I'm pretty sure stopping interrupts
> > before stopping DMA is sufficient.
> > Can you show an example where it doesn't work?
>
> Shared irq.
>
> The device has not quiesced, the kernel stop listening to it and the
> neighbor device receives a late interruption from the network device.
I thought we've worked through that already:
http://www.spinics.net/lists/netdev/msg05902.html
Patch v3 takes care of that problem.
The first step in the sequence is to mask IRQs on the tulip.
The "neighbor" device sharing the IRQ will not see any interrupts from
the tulip after that.
thanks,
grant
^ permalink raw reply
* Re: tcp_slow_start_after_idle
From: David Miller @ 2006-06-14 22:30 UTC (permalink / raw)
To: zach.brown; +Cc: netdev, jheffner
In-Reply-To: <449042E0.4020409@oracle.com>
From: Zach Brown <zach.brown@oracle.com>
Date: Wed, 14 Jun 2006 10:09:52 -0700
> Nice, thanks for the heads-up. I'll pass the notice on to the guys who
> were asking about this in that thread.
Which Wall Street brokerage firm was it? :-)
That's basically who wants this stuff, people doing financial
transactions. They seem to open up a connection, and just blast out
data periodically (with frequency > RTO, which is the whole problem)
and they want good latency results from that.
^ permalink raw reply
* Re: tcp_slow_start_after_idle
From: David Miller @ 2006-06-14 23:06 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev, zach.brown, jheffner
In-Reply-To: <44903D82.40007@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Wed, 14 Jun 2006 09:46:58 -0700
> Also, does the congestion window "time out" or does it decay?
The modification made to the cwnd is indeed a decay function,
but the event is a time out, and it is also termed a restart
in other writings and contexts.
I think it's all the same. :)
> > +/* By default, RFC2861 behavior. */
> > +int sysctl_tcp_slow_start_after_idle = 1;
> > +
>
> Is this a candidate for "readmostly?"
All the networking sysctls are, we should do a sweep over them at some
point.
Thanks for reminding me.
^ permalink raw reply
* Re: [patch] ipv4: fix lock usage in udp_ioctl
From: Herbert Xu @ 2006-06-14 23:12 UTC (permalink / raw)
To: Heiko Carstens; +Cc: davem, jgarzik, akpm, linux-kernel, netdev, mingo, fpavlic
In-Reply-To: <20060614194305.GB10391@osiris.ibm.com>
Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
>
> As reported by the lock validator:
>
> ============================
> [ BUG: illegal lock usage! ]
> ----------------------------
> illegal {in-hardirq-W} -> {hardirq-on-W} usage.
> syslogd/739 [HC0[0]:SC0[1]:HE1:SE0] takes:
> (&list->lock){++..}, at: [<002e36d6>] udp_ioctl+0x96/0x100
> {in-hardirq-W} state was registered at:
> [<00062128>] lock_acquire+0x9c/0xc0
> [<0036209e>] _spin_lock_irqsave+0x66/0x84
> [<002912ce>] skb_dequeue+0x32/0xb0
> [<00263160>] qeth_qdio_output_handler+0x3e8/0xf8c
> [<00219fdc>] tiqdio_thinint_handler+0xde0/0x2234
> [<0020448c>] do_adapter_IO+0x5c/0xa8
> [<0020842c>] do_IRQ+0x13c/0x18c
> [<000208a2>] io_no_vtime+0x16/0x1c
> [<0001978c>] cpu_idle+0x1d0/0x20c
This is bogus. These two locks belong to two different queues and they
never intersect.
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: [PATCH 1/2] e1000: fix netpoll with NAPI
From: Mitch Williams @ 2006-06-14 23:44 UTC (permalink / raw)
To: Neil Horman
Cc: Williams, Mitch A, Jeff Moyer, Kok, Auke-jan H, Matt Mackall,
Garzik, Jeff, netdev, Brandeburg, Jesse, Kok, Auke
In-Reply-To: <20060614204158.GA3967@hmsreliant.homelinux.net>
On Wed, 14 Jun 2006, Neil Horman wrote:
> Hey, as promised, I've done some rudimentary performance benchmarking on various
> ways that we have talked about to solve this problem. As I previously mentioned
We see the same results here, Neil. However, we've got a much less
invasive patch undergoing internal review, and which we will post to
netdev once everybody gets happy with it. Basically, we just do our NAPI
scheduling on the "real" netdev structure instead of our polling netdev,
in the case where we only have one RX queue. Since this is the case for
all our currently-shipping parts under Linux, netpoll works again across
the board. It's a short-term fix because we do want to support multiple
queues going forward, but for now we need to get everybody working.
One of our engineers (on the I/O AT team) has been tasked with modifying
the Linux kernel to properly support multiple hardware queues (both TX and
RX). We'll make sure that he looks at the netpoll interface as part of
that process.
Stay tuned for our impending patch.
-Mitch
^ permalink raw reply
* Re: [PATCH 2/2] NET: Accurate packet scheduling for ATM/ADSL (userspace)
From: Russell Stuart @ 2006-06-15 0:47 UTC (permalink / raw)
To: Alan Cox; +Cc: Stephen Hemminger, Jamal Hadi Salim, netdev, linux-kernel
In-Reply-To: <1150282625.3490.23.camel@localhost.localdomain>
On Wed, 2006-06-14 at 11:57 +0100, Alan Cox wrote:
> The other problem I see with this code is it is very tightly tied to ATM
> cell sizes, not to solving the generic question of packetisation.
Others have made this point also. I can't speak for Jesper,
but I did consider making it generic. The issue was that
doing so would add more code, but I don't personally know
of any real world situation that would use the generic
solution. I didn't fancy the thought of arguing on these
lists for code that no one would actually use.
If someone could put up their hand and say "Hey, I need
this," then expanding the patch to accommodate them would
be a pleasure. I like generic code too.
Russell
^ permalink raw reply
* Your health, oil shark
From: Jeannie Dailey @ 2006-06-15 2:52 UTC (permalink / raw)
To: netdev
Even if you have no erectin problems SOFT CIAzLIS
would help you to make BETTER SE X MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ER ECTI ON during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISC OUNT OFER!
http://olgiks.livingpaw.com/?76593014
==========
thing or two about flying!
We came out into the sun and stopped by the boot. Tender reached out for it.
that? What does it feel like? How far can you go?"
could see how pleased he was. His eyes lit up and there was color in his
answer "Woman" is disallowed as too obvious a rejoinder.)
"That's all I wanted cleared up. You're Free to go.
Fletcher Seagull, who loved aerobatics like no one else, conquered
store for me here?"
^ permalink raw reply
* Re: [PATCH] Make in-kernel hostap less annoying
From: Jouni Malinen @ 2006-06-15 3:41 UTC (permalink / raw)
To: Kyle McMartin; +Cc: netdev
In-Reply-To: <20060612191302.GD32443@skunkworks.cabal.ca>
On Mon, Jun 12, 2006 at 03:13:02PM -0400, Kyle McMartin wrote:
> Most user don't want their kern.log/dmesg filled with
> debugging gibberish, and could turn it on if prompted.
>
> ( Example:
> wifi0: TXEXC - status=0x0004 ([Discon]) tx_control=000c
> retry_count=0 tx_rate=0 fc=0x0108 (Data::0 ToDS)
> A1=00:0f:66:43:d7:0a A2=00:05:3c:06:63:01 A3=33:33:00:00:00:16
> A4=00:00:00:00:00:00 )
I agree with removing these by default. However, I would prefer to do
this in more selective manor than disabling all debugging information at
build time. This would probably involve going through all debug messages
using this mechanism and selecting whether they are reasonable to enable
by default or not and ideally doing this as a run-time option.
> Also make hostap default to managed mode, instead of master mode, which
> has bitten a few users expecting it to behave like the orinoco driver
> it is replacing.
NAK. Host AP has been configured to use master mode by default for the
past six years and that is what most users would expect it to continue
to do. I do understand that this default differs from all drivers that
do not support AP mode, but I think it is too late to change this now.
The default could change once Host AP gets replaced with
net/d80211-based implementation for Prism2/2.5/3, but I would not change
this for Host AP driver.
> Two minor things I've been carrying around in my personal tree
> for quite some time. (This is only relevant to the in-kernel driver,
> I see no reason to change the out-of-tree driver.)
That would be even more confusing for the default mode.. I believe that
both versions should continue to use Master mode as the default unless
overridden by user.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [patch] e100 statistic value "rx_bytes" error
From: Wei Dong @ 2006-06-15 4:17 UTC (permalink / raw)
To: netdev; +Cc: davem
Hi All:
When I test linux kernel(2.6.9-16), I found that maybe there is a bug
in e100 driver. See function e100_rx_indicate() at line 1847:
nic->net_stats.rx_bytes += actual_size;
Here, actual_size is the actual size of an ethernent frame sans FCS.And
the e100 driver gets it from skb. Because "rx_bytes" is a statistc value
for a NIC, I think rx_bytes should include the FCS(4 bytes).
The following is the patch for the function in e100.c
diff -ruN old/drivers/net/e100.c new/drivers/net/e100.c
--- old/drivers/net/e100.c 2006-03-20 13:53:29.000000000 +0800
+++ new/drivers/net/e100.c 2006-06-15 11:16:04.000000000 +0800
@@ -1844,7 +1844,8 @@
dev_kfree_skb_any(skb);
} else {
nic->net_stats.rx_packets++;
- nic->net_stats.rx_bytes += actual_size;
+ /* Don't forget FCS */
+ nic->net_stats.rx_bytes += actual_size + 4;
nic->netdev->last_rx = jiffies;
netif_receive_skb(skb);
if(work_done)
BR.
Weidong
Signed-off-by: Weidong <weid@nanjing-fnst.com>
^ permalink raw reply
* Re: [patch] e100 statistic value "rx_bytes" error
From: Auke Kok @ 2006-06-15 4:35 UTC (permalink / raw)
To: Wei Dong; +Cc: netdev, Jesse Brandeburg, Ronciak, John, Auke Kok, Kok, Auke
In-Reply-To: <1150345027.3008.10.camel@L-tech>
Wei Dong wrote:
> Hi All:
> When I test linux kernel(2.6.9-16), I found that maybe there is a bug
> in e100 driver. See function e100_rx_indicate() at line 1847:
> nic->net_stats.rx_bytes += actual_size;
> Here, actual_size is the actual size of an ethernent frame sans FCS.And
> the e100 driver gets it from skb. Because "rx_bytes" is a statistc value
> for a NIC, I think rx_bytes should include the FCS(4 bytes).
> The following is the patch for the function in e100.c
This is definately not an issue, and I'm not for changing this: It always was
like this in the first place. It's done for many drivers like this anyway,
mostly those without real hardware counters do it this way anyway (I count
half a dozen or so on first glance).
On top of that we would be changing statistics numbers after x years of e100
driver. I'm sure everyone doing real performance work will frown upon this.
Next it's unlikely that every driver (or worse, every nic in hardware)
accounts for FCS in the rx_bytes count. It really wouldn't surprise me if a
driver (or chip) got this wrong here or there.
Bottom line is that for e100, it's well known and easily seeable that e100 is
counting skb sizes. That's consistent and I think we should keep it that way.
Auke
PS please cc the driver maintainers when you post patches to a specific driver.
> diff -ruN old/drivers/net/e100.c new/drivers/net/e100.c
> --- old/drivers/net/e100.c 2006-03-20 13:53:29.000000000 +0800
> +++ new/drivers/net/e100.c 2006-06-15 11:16:04.000000000 +0800
> @@ -1844,7 +1844,8 @@
> dev_kfree_skb_any(skb);
> } else {
> nic->net_stats.rx_packets++;
> - nic->net_stats.rx_bytes += actual_size;
> + /* Don't forget FCS */
> + nic->net_stats.rx_bytes += actual_size + 4;
> nic->netdev->last_rx = jiffies;
> netif_receive_skb(skb);
> if(work_done)
>
> BR.
> Weidong
>
> Signed-off-by: Weidong <weid@nanjing-fnst.com>
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco
From: Pavel Roskin @ 2006-06-15 4:45 UTC (permalink / raw)
To: John W. Linville; +Cc: Faidon Liambotis, Dave Jones, netdev, hermes
In-Reply-To: <20060612152434.GA14851@tuxdriver.com>
Hello, John!
On Mon, 2006-06-12 at 11:24 -0400, John W. Linville wrote:
> On Mon, Jun 12, 2006 at 01:49:54AM +0300, Faidon Liambotis wrote:
>
> > Having two drivers supporting the same set of hardware seems pretty
> > pointless to me. Plus, it confuses hotplugging/automatic detection.
>
> This subject comes-up from time to time. In fact, I'm pretty sure
> it came-up very recently w.r.t. orinoco and hostap.
>
> The consensus seems to be that drivers should have IDs for all devices
> they support, even if that means that some devices are supported by
> multiple drivers. This leaves the choice of which driver to use in
> the hands of the user and/or distro.
>
> If the Orinoco guys want this patch, I'll consider it. Otherwise,
> I'm not inclined to take it.
I really appreciate your position in this regard.
The patch in question was never submitted to the orinoco mailing list.
I believe any such changes should be discussed by people using the
driver and participating in its development. It's not some minor change
or API update.
I'm ready to consider disabling some ID's conditionally, primarily for
systems that cannot use udev. But it's far from the top of my TODO
list. And I'm not sure it would actually help users of desktop
distributions.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco
From: Pavel Roskin @ 2006-06-15 4:52 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: John W. Linville, Faidon Liambotis, Dave Jones, netdev, hermes
In-Reply-To: <4807377b0606121710j5be6ce0fhac71b69bf4dce2c2@mail.gmail.com>
On Mon, 2006-06-12 at 17:10 -0700, Jesse Brandeburg wrote:
> my problem is that for my prism 2 adapter both drivers are loaded at
> which point neither of them works. I'm running FC5, and i have to
> keep removing the orinoco*.ko files to keep them from loading, so I'm
> all for this patch.
I believe the right solution would be to do it in userspace. The kernel
should not be making decisions which driver is _better_ for the device.
I'm yet to see any serious arguments why the kernel should be doing it.
As for non-working driver, this should be reported with sufficient
details. I haven't seen any detailed reports of this problem.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [patch] ipv4: fix lock usage in udp_ioctl
From: Ingo Molnar @ 2006-06-15 5:28 UTC (permalink / raw)
To: Herbert Xu
Cc: Heiko Carstens, davem, jgarzik, akpm, linux-kernel, netdev,
fpavlic
In-Reply-To: <E1FqeXX-0008OE-00@gondolin.me.apana.org.au>
* Herbert Xu <herbert@gondor.apana.org.au> wrote:
> This is bogus. These two locks belong to two different queues and
> they never intersect.
yeah - qeth does its own skb-queue management here, and it's done in an
irq-safe manner.
Heiko, in qeth_main.c, could you do something like:
+ static struct lockdep_type_key qdio_out_skb_queue_key;
...
skb_queue_head_init(&card->qdio.out_qs[i]->bufs[j].
skb_list);
+ lockdep_reinit_key(&card->qdio.out_qs[i]->bufs[j].skb_list,
&qdio_out_skb_queue_key)
Ingo
^ permalink raw reply
* Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco
From: Faidon Liambotis @ 2006-06-15 5:15 UTC (permalink / raw)
To: Pavel Roskin; +Cc: John W. Linville, Dave Jones, netdev, hermes
In-Reply-To: <1150346713.26487.24.camel@dv>
Hi,
Pavel Roskin wrote:
> The patch in question was never submitted to the orinoco mailing list.
> I believe any such changes should be discussed by people using the
> driver and participating in its development. It's not some minor change
> or API update.
I'm sorry for not submitting/CCing this to the orinoco mailing list, I
should have.
> I'm ready to consider disabling some ID's conditionally, primarily for
> systems that cannot use udev. But it's far from the top of my TODO
> list. And I'm not sure it would actually help users of desktop
> distributions.
Well, that would be very nice, thanks!
But do you think that it will be enough? I mean, orinoco_{pci,plx,tdm}
exist only to support Prism2 chipsets.
HostAP a rather big and complete driver for Prism2/2.5/3.0 chipsets;
we're going to have another one based on the dscape stack too.
Do you think that there's a point on having the orinoco driver
supporting this chipset any more?
I don't mean to disrespect your work -- orinoco has served us for quite
a few years, but HostAP seems like a better alternative for these cards.
Please don't get offended by this -- I'm sure you've spent quite some
time on the particular code.
Regarding the disabling of IDs, I could prepare a patch for orinoco_cs
that would disable Prism2 support via a configuration option. Would that
be helpful/acceptable?
Best regards,
Faidon
^ permalink raw reply
* Re: [patch] ipv4: fix lock usage in udp_ioctl
From: Heiko Carstens @ 2006-06-15 6:55 UTC (permalink / raw)
To: Ingo Molnar
Cc: Herbert Xu, davem, jgarzik, akpm, linux-kernel, netdev, fpavlic
In-Reply-To: <20060615052806.GA19803@elte.hu>
On Thu, Jun 15, 2006 at 08:28:07AM +0200, Ingo Molnar wrote:
>
> * Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> > This is bogus. These two locks belong to two different queues and
> > they never intersect.
>
> yeah - qeth does its own skb-queue management here, and it's done in an
> irq-safe manner.
>
> Heiko, in qeth_main.c, could you do something like:
>
> + static struct lockdep_type_key qdio_out_skb_queue_key;
>
> ...
> skb_queue_head_init(&card->qdio.out_qs[i]->bufs[j].
> skb_list);
> + lockdep_reinit_key(&card->qdio.out_qs[i]->bufs[j].skb_list,
> &qdio_out_skb_queue_key)
How about the patch below? The warning goes away and I assume "tmp_list" needs
lockdep_reinit_key too, since it should have the same locking rules as the
rest of qeth's skb-queue management.
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Avoid false positive illegal lock usage message in qeth driver.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
drivers/s390/net/qeth_main.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/s390/net/qeth_main.c 2006-06-15 08:46:26.000000000 +0200
+++ b/drivers/s390/net/qeth_main.c 2006-06-15 08:29:58.000000000 +0200
@@ -85,6 +85,8 @@ static debug_info_t *qeth_dbf_qerr = NUL
DEFINE_PER_CPU(char[256], qeth_dbf_txt_buf);
+static struct lockdep_type_key qdio_out_skb_queue_key;
+
/**
* some more definitions and declarations
*/
@@ -3230,6 +3232,9 @@ qeth_alloc_qdio_buffers(struct qeth_card
&card->qdio.out_qs[i]->qdio_bufs[j];
skb_queue_head_init(&card->qdio.out_qs[i]->bufs[j].
skb_list);
+ lockdep_reinit_key(
+ &card->qdio.out_qs[i]->bufs[j].skb_list.lock,
+ &qdio_out_skb_queue_key);
INIT_LIST_HEAD(&card->qdio.out_qs[i]->bufs[j].ctx_list);
}
}
@@ -5273,6 +5278,7 @@ qeth_free_vlan_buffer(struct qeth_card *
struct sk_buff_head tmp_list;
skb_queue_head_init(&tmp_list);
+ lockdep_reinit_key(&tmp_list.lock, &qdio_out_skb_queue_key);
for(i = 0; i < QETH_MAX_BUFFER_ELEMENTS(card); ++i){
while ((skb = skb_dequeue(&buf->skb_list))){
if (vlan_tx_tag_present(skb) &&
^ permalink raw reply
* New’n’hot I am sure it was
From: Noah @ 2006-06-15 8:16 UTC (permalink / raw)
To: newbie-owner
Good day Bro,
Masculine performance has never been so easy to increase with these products
Don’t hesitate and you will love the lowest possible pricing and the fastest possible shipment
These brands keep thousands and thousands of their customers pleased worldwide
Take a look: http://www.kissyii.com
We offer reliable service and 5 years expirience on the marcket!
^ permalink raw reply
* Fresh stuff Every man wants it
From: Ahmed @ 2006-06-15 8:30 UTC (permalink / raw)
To: netdev
Hi,
Rock hard manhood, multiple explosions and several times more semen volume
Get a several month supply of everything you need – in seconds
Unique offers on most recognized and famous brands on Earth.
Just take a look: http://www.lutetiaaj.com
The quality is realt high and the prices are the cheapest on the market!
^ permalink raw reply
* [PATCH 0/2] Runtime configuration of HTB's HYSTERESIS option
From: Russell Stuart @ 2006-06-15 9:00 UTC (permalink / raw)
To: Jamal Hadi Salim, Stephen Hemminger, Martin Devera, netdev, lartc
Cc: Jesper Dangaard Brouer
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
HTB's CPU usage on modern machines using broadband links
is minimal. Currently HYSTERESIS is on by default, and
requires a kernel re-compile to change. Altering it to
be a runtime option will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
This is a combined effort of Jesper Brouer and Russell
Stuart, to get these patches into the upstream kernel.
Let the discussion start about what we need to change to
get this upstream?
We see this as a feature enhancement, as such hope that
it can be queued in davem's net-2.6.18.git tree.
--
Regards
Russell Stuart and Jesper Brouer
^ permalink raw reply
* [PATCH 1/2] Runtime configuration of HTB's HYSTERESIS option (kernel)
From: Russell Stuart @ 2006-06-15 9:01 UTC (permalink / raw)
To: Jamal Hadi Salim, Stephen Hemminger, Martin Devera, netdev, lartc
Cc: Jesper Dangaard Brouer
[-- Attachment #1: Type: text/plain, Size: 5285 bytes --]
The HTB qdisc has a compile time option, HTB_HYSTERESIS,
that trades accuracy of traffic classification for CPU
time. These patches change hysteresis to be a runtime
option under the control of "tc".
The effects of HYSTERESIS on HTB's accuracy are significant
(see chapter 7, section 7.3.1, pp 69-70 in Jesper Brouer's
thesis: http://www.adsl-optimizer.dk/thesis/ ), whereas
HTB's CPU usage on modern machines using broadband links
is minimal. Currently HYSTERESIS is on by default, and
requires a kernel re-compile to change. Altering it to
be a runtime option will make life easier for the bulk of
its users.
Further documentation on the patch and its usage can be
found here:
http://www.stuart.id.au/russell/files/tc/tc-atm
Signed-off-by: Russell Stuart <russell-tcatm@stuart.id.au>
Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
---
diff -Nurp kernel-source-2.6.11.orig/include/linux/pkt_sched.h kernel-source-2.6.11/include/linux/pkt_sched.h
--- kernel-source-2.6.11.orig/include/linux/pkt_sched.h 2005-03-02 17:38:13.000000000 +1000
+++ kernel-source-2.6.11/include/linux/pkt_sched.h 2006-06-13 11:34:25.000000000 +1000
@@ -231,6 +231,10 @@ struct tc_gred_sopt
#define TC_HTB_MAXDEPTH 8
#define TC_HTB_PROTOVER 3 /* the same as HTB and TC's major */
+struct tc_htb_hopt
+{
+ __u32 nohyst;
+};
struct tc_htb_opt
{
struct tc_ratespec rate;
@@ -258,6 +262,7 @@ enum
TCA_HTB_INIT,
TCA_HTB_CTAB,
TCA_HTB_RTAB,
+ TCA_HTB_NOHYST,
__TCA_HTB_MAX,
};
diff -Nurp kernel-source-2.6.11.orig/net/sched/sch_htb.c kernel-source-2.6.11/net/sched/sch_htb.c
--- kernel-source-2.6.11.orig/net/sched/sch_htb.c 2005-03-02 17:38:12.000000000 +1000
+++ kernel-source-2.6.11/net/sched/sch_htb.c 2006-06-13 11:34:25.000000000 +1000
@@ -73,7 +73,6 @@
#define HTB_EWMAC 2 /* rate average over HTB_EWMAC*HTB_HSIZE sec */
#undef HTB_DEBUG /* compile debugging support (activated by tc tool) */
#define HTB_RATECM 1 /* whether to use rate computer */
-#define HTB_HYSTERESIS 1/* whether to use mode hysteresis for speedup */
#define HTB_QLOCK(S) spin_lock_bh(&(S)->dev->queue_lock)
#define HTB_QUNLOCK(S) spin_unlock_bh(&(S)->dev->queue_lock)
#define HTB_VER 0x30011 /* major must be matched with number suplied by TC as version */
@@ -190,6 +189,7 @@ struct htb_class
/* class attached filters */
struct tcf_proto *filter_list;
int filter_cnt;
+ int nohyst; /* Don't use hysteresis htb_class_mode */
int warned; /* only one warning about non work conserving .. */
@@ -622,20 +622,14 @@ static __inline__ enum htb_cmode
htb_class_mode(struct htb_class *cl,long *diff)
{
long toks;
+ long hysteresis =
+ (cl->nohyst || cl->cmode == HTB_CANT_SEND) ? 0 : -cl->cbuffer;
- if ((toks = (cl->ctokens + *diff)) < (
-#if HTB_HYSTERESIS
- cl->cmode != HTB_CANT_SEND ? -cl->cbuffer :
-#endif
- 0)) {
+ if ((toks = (cl->ctokens + *diff)) < hysteresis) {
*diff = -toks;
return HTB_CANT_SEND;
}
- if ((toks = (cl->tokens + *diff)) >= (
-#if HTB_HYSTERESIS
- cl->cmode == HTB_CAN_SEND ? -cl->buffer :
-#endif
- 0))
+ if ((toks = (cl->tokens + *diff)) >= hysteresis)
return HTB_CAN_SEND;
*diff = -toks;
@@ -1323,6 +1317,7 @@ static int htb_dump_class(struct Qdisc *
unsigned char *b = skb->tail;
struct rtattr *rta;
struct tc_htb_opt opt;
+ struct tc_htb_hopt hopt;
HTB_DBG(0,1,"htb_dump_class handle=%X clid=%X\n",sch->handle,cl->classid);
@@ -1342,6 +1337,8 @@ static int htb_dump_class(struct Qdisc *
opt.quantum = cl->un.leaf.quantum; opt.prio = cl->un.leaf.prio;
opt.level = cl->level;
RTA_PUT(skb, TCA_HTB_PARMS, sizeof(opt), &opt);
+ hopt.nohyst = cl->nohyst;
+ RTA_PUT(skb, TCA_HTB_NOHYST, sizeof(hopt), &hopt);
rta->rta_len = skb->tail - b;
HTB_QUNLOCK(sch);
return skb->len;
@@ -1527,11 +1524,12 @@ static int htb_change_class(struct Qdisc
struct htb_class *cl = (struct htb_class*)*arg,*parent;
struct rtattr *opt = tca[TCA_OPTIONS-1];
struct qdisc_rate_table *rtab = NULL, *ctab = NULL;
- struct rtattr *tb[TCA_HTB_RTAB];
+ struct rtattr *tb[TCA_HTB_MAX];
struct tc_htb_opt *hopt;
+ struct tc_htb_hopt *uhopt;
/* extract all subattrs from opt attr */
- if (!opt || rtattr_parse_nested(tb, TCA_HTB_RTAB, opt) ||
+ if (!opt || rtattr_parse_nested(tb, TCA_HTB_MAX, opt) ||
tb[TCA_HTB_PARMS-1] == NULL ||
RTA_PAYLOAD(tb[TCA_HTB_PARMS-1]) < sizeof(*hopt))
goto failure;
@@ -1544,6 +1542,10 @@ static int htb_change_class(struct Qdisc
ctab = qdisc_get_rtab(&hopt->ceil, tb[TCA_HTB_CTAB-1]);
if (!rtab || !ctab) goto failure;
+ uhopt = RTA_DATA(tb[TCA_HTB_NOHYST-1]);
+ if (uhopt != NULL && RTA_PAYLOAD(tb[TCA_HTB_NOHYST-1]) < sizeof(*uhopt))
+ goto failure;
+
if (!cl) { /* new class */
struct Qdisc *new_q;
/* check for valid classid */
@@ -1636,6 +1638,7 @@ static int htb_change_class(struct Qdisc
cl->cbuffer = hopt->cbuffer;
if (cl->rate) qdisc_put_rtab(cl->rate); cl->rate = rtab;
if (cl->ceil) qdisc_put_rtab(cl->ceil); cl->ceil = ctab;
+ if (uhopt) cl->nohyst = uhopt->nohyst;
sch_tree_unlock(sch);
*arg = (unsigned long)cl;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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