[PATCH 1/2] Fix error checking in Vitesse IRQ config
phy_read() returns a negative number if there's an error, but the error-checking code in the Vitesse driver's config_intr function triggers if phy_read() returns non-zero. Correct that. Signed-off-by: Andy Fleming [EMAIL PROTECTED] --- I made a really stupid mistake in the 4 patches I sent out, earlier. I thought those patches had been tested, but they hadn't been. This one corrects a tiny error in the patch, and they have now been tested. As before this change can be pulled from: http://opensource.freescale.com/pub/scm/linux-2.6-85xx.git netdev Really, REALLY sorry about that. I have been given a paper bag of appropriate size and shape to fit over my head. drivers/net/phy/vitesse.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c index 6a53856..8874497 100644 --- a/drivers/net/phy/vitesse.c +++ b/drivers/net/phy/vitesse.c @@ -109,7 +109,7 @@ static int vsc824x_config_intr(struct phy_device *phydev) */ err = phy_read(phydev, MII_VSC8244_ISTAT); - if (err) + if (err 0) return err; err = phy_write(phydev, MII_VSC8244_IMASK, 0); -- 1.5.0.2.230.gfbe3d-dirty - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Fix error checking in Vitesse IRQ config
On 7/18/07, Andy Fleming [EMAIL PROTECTED] wrote: phy_read() returns a negative number if there's an error, but the error-checking code in the Vitesse driver's config_intr function triggers if phy_read() returns non-zero. Correct that. Signed-off-by: Andy Fleming [EMAIL PROTECTED] --- I made a really stupid mistake in the 4 patches I sent out, earlier. I thought those patches had been tested, but they hadn't been. This one corrects a tiny error in the patch, and they have now been tested. As before this change can be pulled from: http://opensource.freescale.com/pub/scm/linux-2.6-85xx.git netdev Really, REALLY sorry about that. I have been given a paper bag of appropriate size and shape to fit over my head. drivers/net/phy/vitesse.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c index 6a53856..8874497 100644 --- a/drivers/net/phy/vitesse.c +++ b/drivers/net/phy/vitesse.c @@ -109,7 +109,7 @@ static int vsc824x_config_intr(struct phy_device *phydev) */ err = phy_read(phydev, MII_VSC8244_ISTAT); - if (err) + if (err 0) return err; but would that mean, if phy_read returns 0 it is a success? thanks err = phy_write(phydev, MII_VSC8244_IMASK, 0); -- 1.5.0.2.230.gfbe3d-dirty - 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 -- Pradeep - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [drivers/net/cxgb3] removed several unneeded zero initilization
Cc: [EMAIL PROTECTED]
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
---
drivers/net/cxgb3/cxgb3_main.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 6fd1e52..45711f9 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -754,7 +754,7 @@ static int upgrade_fw(struct adapter *adap)
*/
static int cxgb_up(struct adapter *adap)
{
- int err = 0;
+ int err;
if (!(adap-flags FULL_INIT_DONE)) {
err = t3_check_fw_version(adap);
@@ -861,7 +861,7 @@ static int offload_open(struct net_device *dev)
struct adapter *adapter = dev-priv;
struct t3cdev *tdev = T3CDEV(dev);
int adap_up = adapter-open_device_map PORT_MASK;
- int err = 0;
+ int err;
if (test_and_set_bit(OFFLOAD_DEVMAP_BIT, adapter-open_device_map))
return 0;
@@ -1502,7 +1502,7 @@ static int set_eeprom(struct net_device *dev, struct
ethtool_eeprom *eeprom,
u8 * data)
{
u8 *buf;
- int err = 0;
+ int err;
u32 aligned_offset, aligned_len, *p;
struct adapter *adapter = dev-priv;
--
1.5.2.2
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Realtek RTL8111B serious performance issues
[EMAIL PROTECTED] [EMAIL PROTECTED] : [...] Anyone have any suggestions for solving this problem? Try 2.6.23-rc1 when it is published or apply against 2.6.22 one of: http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/ -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Product: Platform Specific/Hardware Version: 2.5 KernelVersion: 2.6.22 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-32 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: not known - was probably already an issue in 2.6.10 Distribution: not relevant for this issue. Hardware Environment: AMCC Ocotea board Software Environment: not relevant for this issue. Problem Description: see title. Steps to reproduce: 1. Compile the 2.6.22 kernel with the attached .config 2. Boot an Ocotea board with this kernel. 3. Observe the output that appears on the serial console. U-Boot 1.1.1 (Nov 10 2005 - 16:29:34) IBM PowerPC 440 GUNKNOWN (PVR=51b21892) Board: IBM 440GX Evaluation Board VCO: 1066 MHz CPU: 533 MHz PLB: 152 MHz OPB: 76 MHz EPB: 76 MHz I2C: ready DRAM: I2c read: failed 4 I2c read: failed 4 256 MB FLASH: 5 MB PCI: Bus Dev VenId DevId Class Int In:serial Out: serial Err: serial KGDB: kgdb ready ready Net: ppc_440x_eth0 BEDBUG:ready = boot Waiting for PHY auto negotiation to complete.. done ENET Speed is 100 Mbps - FULL duplex connection Using ppc_440x_eth0 device TFTP from server 172.30.36.154; our IP address is 172.30.39.77 Filename 'ocotea-vanassb'. Load address: 0x100 Loading: T # # # # # done Bytes transferred = 1415440 (159910 hex) Automatic boot of image at addr 0x0100 ... ## Booting image at 0100 ... Image Name: Linux-2.6.22 Created: 2007-07-18 6:53:56 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1415376 Bytes = 1.3 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 3.4.3 (MontaVista 3.4.7 IBM Ocotea port (MontaVista Software, Inc. [EMAIL PROTECTED]) Zone PFN ranges: DMA 0 -65536 Normal 65536 -65536 early_node_map[1] active PFN ranges 0:0 -65536 Built 1 zonelists. Total pages: 65024 Kernel command line: root=/dev/nfs nfsroot=172.30.36.154:/nfs-export/RFS_MVL4-00 PID hash table entries: 1024 (order: 10, 4096 bytes) | Locking API testsuite: | spin |wlock |rlock |mutex | wsem | rsem | -- A-A deadlock:failed|failed| ok |failed|failed|failed| A-B-B-A deadlock:failed|failed| ok |failed|failed|failed| A-B-B-C-C-A deadlock:failed|failed| ok |failed|failed|failed| A-B-C-A-B-C deadlock:failed|failed| ok |failed|failed|failed| A-B-B-C-C-D-D-A deadlock:failed|failed| ok |failed|failed|failed| A-B-C-D-B-D-D-A deadlock:failed|failed| ok |failed|failed|failed| A-B-C-D-B-C-D-A deadlock:failed|failed| ok |failed|failed|failed| double unlock: ok | ok |failed| ok |failed|failed| initialize held:failed|failed|failed|failed|failed|failed| bad unlock order: ok | ok | ok | ok | ok | ok | -- recursive read-lock: | ok | |failed| recursive read-lock #2: | ok | |failed| mixed read-write-lock: |failed| |failed| mixed write-read-lock: |failed| |failed| -- hard-irqs-on + irq-safe-A/12:failed|failed| ok | soft-irqs-on + irq-safe-A/12:failed|failed| ok | hard-irqs-on + irq-safe-A/21:failed|failed| ok | soft-irqs-on + irq-safe-A/21:failed|failed| ok | sirq-safe-A = hirqs-on/12:failed|failed| ok | sirq-safe-A = hirqs-on/21:failed|failed| ok | hard-safe-A + irqs-on/12:failed|failed| ok | soft-safe-A + irqs-on/12:failed|failed| ok |
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. -- Eugene - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPSec freeze
From: Patrick McHardy [EMAIL PROTECTED] Date: Tue, 17 Jul 2007 18:10:13 +0200 [XFRM]: Fix crash introduced by struct dst_entry reordering XFRM expects xfrm_dst-u.next to be same pointer as dst-next, which was broken by the dst_entry reordering in commit 1e19e02c~, causing an oops in xfrm_bundle_ok when walking the bundle upwards. Kill xfrm_dst-u.next and change the only user to use dst-next instead. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied, thanks a lot Patrick. I'll toss this to -stable too. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IPSec freeze
From: Beschorner Daniel [EMAIL PROTECTED] Date: Tue, 17 Jul 2007 21:03:20 +0200 I managed to reproduce a crash with ipcomp, will try to fix it later. Yes, I can confirm this. After disabling IPComp the crashes went away. The crash happens in xfrm_bundle_ok when walking the bundle upwards following xfrm_dst-u.next. The loop should be stopped when xfrm_dst-u.next == first (the topmost xfrm_dst), but it points to NULL instead. I'm pretty sure the attached patch is responsible, it breaks XFRM's assumption that dst-next and xfrm_dst-u.next are the same pointer and xfrm_dst now shares the next pointer with rcu_head.next in struct dst_entry. Eric, could you look into this please? I fixed it myself. Daniel, can you please test this patch? Many thanks Patrick!!! I tested it and found it working! Thank you for testing. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PPPOL2TP 1/2]: Fix use-after-free
From: Patrick McHardy [EMAIL PROTECTED] Date: Tue, 17 Jul 2007 14:19:45 +0200 [PPPOL2TP]: Fix use-after-free Don't use skb-len after passing it to ip_queue_xmit. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PPPOL2TP 2/2]: Reset meta-data in xmit function
From: Patrick McHardy [EMAIL PROTECTED] Date: Tue, 17 Jul 2007 14:19:50 +0200 [PPPOL2TP]: Reset meta-data in xmit function Reset netfilter data and IP CB, fix dst_entry leak. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Good catch, applied, thanks Patrick. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] negative groups in netlink_setsockopt
From: Johannes Berg [EMAIL PROTECTED] Date: Tue, 17 Jul 2007 14:26:04 +0200 Reading netlink_setsockopt it's not immediately clear why there isn't a bug when you pass in negative numbers, the reason being that the = comparison is really unsigned although 'val' is signed because nlk-ngroups is unsigned. Make 'val' unsigned too. Signed-off-by: Johannes Berg [EMAIL PROTECTED] Applied, but I updated the (int __user *) cast in get_user() to match as well when applying this. Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [net/core] move dev_mc_discard from dev_mcast.c to dev.c
From: Denis Cheng [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 10:41:03 +0800 Because this function is only called by unregister_netdevice, this moving could make this non-global function static, and also remove its declaration in netdevice.h; Any further, function __dev_addr_discard is also just called by dev_mc_discard and dev_unicast_discard, keeping this two functions both in one c file could make __dev_addr_discard also static and remove its declaration in netdevice.h; Futhermore, the sequential call to dev_unicast_discard and then dev_mc_discard in unregister_netdevice have a similar mechanism that: (netif_tx_lock_bh / __dev_addr_discard / netif_tx_unlock_bh), they should merged into one to eliminate duplicates in acquiring and releasing the dev-_xmit_lock, this would be done in my following patch. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Patch applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [net/core] merge dev_unicast_discard and dev_mc_discard into one
From: Denis Cheng [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 10:41:04 +0800 this two functions could share the dev-_xmit_lock acquired context. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] [net/core] move __dev_addr_discard adjacent to dev_addr_discard for readability
From: Denis Cheng [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 10:41:05 +0800 Signed-off-by: Denis Cheng [EMAIL PROTECTED] Also applied, thank you. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux 2.6.22: Leak r=1 1
On Wed, 11 Jul 2007, Sami Farin wrote: That's right, so descriptive is the new Linux kernel 2.6.22. Linux safari.finland.fbi 2.6.22-cfs-v19 #3 SMP Tue Jul 10 00:22:25 EEST 2007 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] /proc/sys/net/ipv4]# grep . * ...snip... tcp_frto:1 ...This is fully unrelated to the issue but I'm a bit curious who enabled frto on your machine (since it's disabled by default), did you do it by yourself or the distribution perhaps? This is interesting because frto to be useful in large scale, sender must have it enabled and therefore it's usually not under control of the host that is attached to the wireless access link. ...In case some distribution (yours) is already enabling it, the deployment is somewhat proceeding already :-)... ...And we also get incremental testing of the code too... -- i. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [IrDA] Fix IrDA build failure
From: Samuel Ortiz [EMAIL PROTECTED] Date: Mon, 16 Jul 2007 14:17:15 +0300 When having built-in IrDA, we hit the following error: `irda_sysctl_unregister' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o `irda_proc_unregister' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o `irsock_cleanup' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o `irttp_cleanup' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o `iriap_cleanup' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o `irda_device_cleanup' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o `irlap_cleanup' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o `irlmp_cleanup' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [_all] Error 2 This is due to the irda_init fix recently added, where we call __exit routines from an __init one. It is a build failure that I didn't catch because it doesn't show up when building IrDA as a module. My apologies for that. The following patch fixes that failure and is against your net-2.6 tree. I hope it can make it to the merge window, and [EMAIL PROTECTED] is CCed on this mail. Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] I've applied this. I realize that alternative suggestions have been made on how to fix this, and when consensus on that is reached someone can send me a follow-on patch. Thanks! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.22-rc7] xfrm beet interfamily support
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED] Date: Mon, 16 Jul 2007 09:56:59 -0300 Sorry for not commented that the code you were using (and David said it was invalid) is in fact valid: skb-transport_header = skb-network_header; This works for both offsets and pointers, i.e. both transport_header and network_header are in the same address space. skb_set_transport_header(skb, skb_network_offset(skb)); Also works, but its too convoluted IMHO, for pointers it would reduce to: skb-transport_header = skb-data + skb-network_header - skb-data; for offsets: skb-transport_header = skb-data - skb-head; skb-transport_header += skb-head + skb-network_header - skb-data; I.e. both reduce to: skb-transport_header = skb-network_header; Some more comments below, but I think this time, sans the above possible cleanup, your patch is OK wrt offsets/pointers. Thanks for the correction, indeed you are correct :) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] ipt_iprange.h must #include linux/types.h
From: Adrian Bunk [EMAIL PROTECTED] Date: Sun, 15 Jul 2007 14:14:19 +0200 ipt_iprange.h must #include linux/types.h since it uses __be32. This patch fixes kernel Bugzilla #7604. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Applied, and I'll push this to -stable too, thanks Adrian. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tc filter add ... fw ... action drop
Abhijit Menon-Sen wrote:
Hi.
Is it a bug that:
# tc filter add dev eth0 parent 1: protocol ip prio 0 handle 0xfff
fw police rate 1 burst 1 mpu 0 mtu 1 action drop
^^^
creates a filter that looks like:
# tc filter ls dev eth0
filter parent 1: protocol ip pref 49152 fw
filter parent 1: protocol ip pref 49152 fw handle 0xfff police 0x1
rate 0bit burst 0b mtu 1b action reclassify
^
ref -543190236 bind 4
(which reclassifies and thus lets 0xfff-marked packets through).
I'm pretty sure this used to work under 2.4.x (though I no longer have a
2.4 box to test with), but it hasn't worked on any of the 2.6.x kernels
I've tried (with both iproute2-ss060323 and 070710).
Good catch. It seems this is merely a parsing error, iproute doesn't
have an action parameter and aborts parsing, so it uses the default
value of RECLASSIFY. It never had this parameter, so this patch
removes it from the help text and makes it return an error.
BTW, Stephen, whats the status of all the patches I sent you?
diff --git a/tc/m_police.c b/tc/m_police.c
index 36a7719..62e37f9 100644
--- a/tc/m_police.c
+++ b/tc/m_police.c
@@ -37,7 +37,7 @@ static void usage(void)
fprintf(stderr, Usage: ... police rate BPS burst BYTES[/BYTES] [ mtu
BYTES[/BYTES] ]\n);
fprintf(stderr, [ peakrate BPS ] [ avrate BPS ]\n);
fprintf(stderr, [ ACTIONTERM ]\n);
- fprintf(stderr, Old Syntax ACTIONTERM := action
EXCEEDACT[/NOTEXCEEDACT] \n);
+ fprintf(stderr, Old Syntax ACTIONTERM := EXCEEDACT[/NOTEXCEEDACT]
\n);
fprintf(stderr, New Syntax ACTIONTERM := conform-exceed
EXCEEDACT[/NOTEXCEEDACT] \n);
fprintf(stderr, Where: *EXCEEDACT := pipe | ok | reclassify | drop |
continue \n);
fprintf(stderr, Where: pipe is only valid for new syntax \n);
@@ -236,7 +236,8 @@ int act_parse_police(struct action_util *a,int *argc_p,
char ***argv_p, int tca_
} else if (strcmp(*argv, help) == 0) {
usage();
} else {
- break;
+ fprintf(stderr, What is \%s\?\n, *argv);
+ return -1;
}
ok++;
argc--; argv++;
Re: [PATCH 1/3] [net/core] move dev_mc_discard from dev_mcast.c to dev.c
On 7/18/07, David Miller [EMAIL PROTECTED] wrote: From: Denis Cheng [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 10:41:03 +0800 Because this function is only called by unregister_netdevice, this moving could make this non-global function static, and also remove its declaration in netdevice.h; Any further, function __dev_addr_discard is also just called by dev_mc_discard and dev_unicast_discard, keeping this two functions both in one c file could make __dev_addr_discard also static and remove its declaration in netdevice.h; Futhermore, the sequential call to dev_unicast_discard and then dev_mc_discard in unregister_netdevice have a similar mechanism that: (netif_tx_lock_bh / __dev_addr_discard / netif_tx_unlock_bh), they should merged into one to eliminate duplicates in acquiring and releasing the dev-_xmit_lock, this would be done in my following patch. Signed-off-by: Denis Cheng [EMAIL PROTECTED] Patch applied, thanks. Thanks for applying, too. And then the dev_mcast.c is now only 256 lines long(versus dev.c 4052 lines), just left a few multicast related functions definition and dev_mcast procfs code, I have an idea to merge all code dev_mcast.c into dev.c, that would: - remove two functions (__dev_addr_delete, __dev_set_rx_mode) from netdevice.h, and then tag them static, those two are also defined in dev.c and only called from dev_mcast.c, - reducing one file would benefit the compilation process. All in one word, I don't think the single file dev_mcast.c is needed anymore. -- Denis Cheng Linux Application Developer One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [net/core] move dev_mc_discard from dev_mcast.c to dev.c
rae l wrote: All in one word, I don't think the single file dev_mcast.c is needed anymore. Agreed. But dev.c is growing larger and larger, maybe dev_addr.c? Or dev_config.c, with some of the other device configuration functions? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [net/core] move dev_mc_discard from dev_mcast.c to dev.c
From: rae l [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 17:59:52 +0800 And then the dev_mcast.c is now only 256 lines long(versus dev.c 4052 lines), just left a few multicast related functions definition and dev_mcast procfs code, I have an idea to merge all code dev_mcast.c into dev.c, that would: - remove two functions (__dev_addr_delete, __dev_set_rx_mode) from netdevice.h, and then tag them static, those two are also defined in dev.c and only called from dev_mcast.c, - reducing one file would benefit the compilation process. All in one word, I don't think the single file dev_mcast.c is needed anymore. Agreed. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [net/core] move dev_mc_discard from dev_mcast.c to dev.c
From: Patrick McHardy [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 12:01:38 +0200 rae l wrote: All in one word, I don't think the single file dev_mcast.c is needed anymore. Agreed. But dev.c is growing larger and larger, maybe dev_addr.c? Or dev_config.c, with some of the other device configuration functions? I don't know, a sizable dev.c is inevitable, allows better refactoring and consolidation. And the be honest you're going to have to likely touch things in dev.c whenever you make changes to dev_addr.c or whatever you want to name it. :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP stalls in current git, possibly splice related
On Mon, 2007-07-16 at 14:02 +0200, Jens Axboe wrote: Yep, it's a sender thing, so upgrading the receiver will not change anything. Ok, I upgraded, but that didn't help. And in fact, I don't see how it could have since synergy doesn't use splice or sendfile. I should've thought of that right away, sorry. It seems that packets are actually coming in during the time that my mouse hangs though (ran wireshark in parallel and saw no pauses in the timeline.) Hence, it actually seems to be on the receiver side, and running the synergy client under strace reveals that during the time my mouse hangs it's in poll() waiting for input on the tcp socket. sysrg-t doesn't show anything useful, it's just scheduling waiting for data. According to wireshark data is sent, but it never shows up at the application layer. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/3] [net/core] move dev_mc_discard from dev_mcast.c to dev.c
David Miller wrote: From: Patrick McHardy [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 12:01:38 +0200 rae l wrote: All in one word, I don't think the single file dev_mcast.c is needed anymore. Agreed. But dev.c is growing larger and larger, maybe dev_addr.c? Or dev_config.c, with some of the other device configuration functions? I don't know, a sizable dev.c is inevitable, allows better refactoring and consolidation. And the be honest you're going to have to likely touch things in dev.c whenever you make changes to dev_addr.c or whatever you want to name it. :-) You're probably right. Killing dev_mcast.c makes sense to me though. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] negative groups in netlink_setsockopt
On Wed, 2007-07-18 at 02:08 -0700, David Miller wrote: From: Johannes Berg [EMAIL PROTECTED] Date: Tue, 17 Jul 2007 14:26:04 +0200 Reading netlink_setsockopt it's not immediately clear why there isn't a bug when you pass in negative numbers, the reason being that the = comparison is really unsigned although 'val' is signed because nlk-ngroups is unsigned. Make 'val' unsigned too. Signed-off-by: Johannes Berg [EMAIL PROTECTED] Applied, but I updated the (int __user *) cast in get_user() to match as well when applying this. Oh, good catch, thanks. johannes signature.asc Description: This is a digitally signed message part
Re: tc filter add ... fw ... action drop
At 2007-07-18 11:49:55 +0200, [EMAIL PROTECTED] wrote:
# tc filter add dev eth0 parent 1: protocol ip prio 0 handle
0xfff fw police rate 1 burst 1 mpu 0 mtu 1 action drop
It seems this is merely a parsing error, iproute doesn't have an
action parameter and aborts parsing, so it uses the default
value of RECLASSIFY.
I can confirm that your patch deals with my command sensibly, and also
that tc filter add ... conform-exceed drop/drop does what I wanted.
It never had this parameter [...]
That command is from a script that used to work with iproute2-ss020116
(2002!), which had the following in tc/m_police.c:
210 } else if (strcmp(*argv, action) == 0) {
211 NEXT_ARG();
212 if (get_police_result(p.action, presult, *argv)) {
I don't know when that bit was dropped, but it used to be there. :-)
Thank you for your help.
-- ams
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tc filter add ... fw ... action drop
Abhijit Menon-Sen wrote:
At 2007-07-18 11:49:55 +0200, [EMAIL PROTECTED] wrote:
# tc filter add dev eth0 parent 1: protocol ip prio 0 handle
0xfff fw police rate 1 burst 1 mpu 0 mtu 1 action drop
It seems this is merely a parsing error, iproute doesn't have an
action parameter and aborts parsing, so it uses the default
value of RECLASSIFY.
I can confirm that your patch deals with my command sensibly, and also
that tc filter add ... conform-exceed drop/drop does what I wanted.
It never had this parameter [...]
That command is from a script that used to work with iproute2-ss020116
(2002!), which had the following in tc/m_police.c:
210 } else if (strcmp(*argv, action) == 0) {
211 NEXT_ARG();
212 if (get_police_result(p.action, presult, *argv)) {
I don't know when that bit was dropped, but it used to be there. :-)
Indeed, I missed that. I'll fix up the patch ..
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tc filter add ... fw ... action drop
Patrick McHardy wrote:
Abhijit Menon-Sen wrote:
That command is from a script that used to work with iproute2-ss020116
(2002!), which had the following in tc/m_police.c:
210 } else if (strcmp(*argv, action) == 0) {
211 NEXT_ARG();
212 if (get_police_result(p.action, presult, *argv)) {
I don't know when that bit was dropped, but it used to be there. :-)
Indeed, I missed that. I'll fix up the patch ..
OK this patch fixes parsing of action I've removed
the erroring on unknown arguments again since in that case
the caller should continue parsing.
diff --git a/tc/m_police.c b/tc/m_police.c
index 36a7719..76cdbe1 100644
--- a/tc/m_police.c
+++ b/tc/m_police.c
@@ -227,7 +227,8 @@ int act_parse_police(struct action_util *a,int *argc_p,
char ***argv_p, int tca_
p.action = TC_POLICE_OK;
} else if (matches(*argv, pipe) == 0) {
p.action = TC_POLICE_PIPE;
- } else if (strcmp(*argv, conform-exceed) == 0) {
+ } else if (strcmp(*argv, action) == 0 ||
+ strcmp(*argv, conform-exceed) == 0) {
NEXT_ARG();
if (get_police_result(p.action, presult, *argv)) {
fprintf(stderr, Illegal \action\\n);
Re: TCP stalls in current git, possibly splice related
On Wed, Jul 18 2007, Johannes Berg wrote: On Mon, 2007-07-16 at 14:02 +0200, Jens Axboe wrote: Yep, it's a sender thing, so upgrading the receiver will not change anything. Ok, I upgraded, but that didn't help. And in fact, I don't see how it could have since synergy doesn't use splice or sendfile. I should've thought of that right away, sorry. It seems that packets are actually coming in during the time that my mouse hangs though (ran wireshark in parallel and saw no pauses in the timeline.) Hence, it actually seems to be on the receiver side, and running the synergy client under strace reveals that during the time my mouse hangs it's in poll() waiting for input on the tcp socket. sysrg-t doesn't show anything useful, it's just scheduling waiting for data. According to wireshark data is sent, but it never shows up at the application layer. OK, then we can put splice off the hook at least :-) If it's easily reproducible (and it sounds like it), then a git bisect might be the easiest way forward. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TCP stalls in current git, possibly splice related
On Wed, 2007-07-18 at 12:49 +0200, Jens Axboe wrote: OK, then we can put splice off the hook at least :-) :) If it's easily reproducible (and it sounds like it), then a git bisect might be the easiest way forward. Yeah, I only need to try to remember when I last *didn't* see the problem, and hope that my analysis about it being on the receiver side is correct :) johannes signature.asc Description: This is a digitally signed message part
[PATCH 1/2] net/core: merge the content of dev_mcast.c into dev.c
- removed three function declarations from header file to mark them static,
- reduced one file
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
---
this one is just merging by concatenating, and I'll try to adjust some
function definitions' order to make it more readable.
include/linux/netdevice.h |3 -
net/core/Makefile |2 +-
net/core/dev.c| 239 +-
net/core/dev_mcast.c | 255 -
4 files changed, 237 insertions(+), 262 deletions(-)
delete mode 100644 net/core/dev_mcast.c
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9820ca1..ca68c58 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1091,15 +1091,12 @@ extern int register_netdev(struct
net_device *dev);
extern voidunregister_netdev(struct net_device *dev);
/* Functions used for secondary unicast and multicast support */
extern voiddev_set_rx_mode(struct net_device *dev);
-extern void__dev_set_rx_mode(struct net_device *dev);
extern int dev_unicast_delete(struct net_device *dev, void *addr,
int alen);
extern int dev_unicast_add(struct net_device *dev, void *addr, int
alen);
extern int dev_mc_delete(struct net_device *dev, void *addr, int
alen, int all);
extern int dev_mc_add(struct net_device *dev, void *addr, int
alen, int newonly);
extern int dev_mc_sync(struct net_device *to, struct net_device
*from);
extern voiddev_mc_unsync(struct net_device *to, struct net_device
*from);
-extern int __dev_addr_delete(struct dev_addr_list **list, int
*count, void *addr, int alen, int all);
-extern int __dev_addr_add(struct dev_addr_list **list, int *count,
void *addr, int alen, int newonly);
extern voiddev_set_promiscuity(struct net_device *dev, int inc);
extern voiddev_set_allmulti(struct net_device *dev, int inc);
extern voidnetdev_state_change(struct net_device *dev);
diff --git a/net/core/Makefile b/net/core/Makefile
index 4751613..54d28dd 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -7,7 +7,7 @@ obj-y := sock.o request_sock.o skbuff.o iovec.o datagram.o
stream.o scm.o \
obj-$(CONFIG_SYSCTL) += sysctl_net_core.o
-obj-y += dev.o ethtool.o dev_mcast.o dst.o netevent.o \
+obj-y += dev.o ethtool.o dst.o netevent.o \
neighbour.o rtnetlink.o utils.o link_watch.o filter.o
obj-$(CONFIG_XFRM) += flow.o
diff --git a/net/core/dev.c b/net/core/dev.c
index 6357f54..16842af 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -18,6 +18,7 @@
* Alexey Kuznetsov [EMAIL PROTECTED]
* Adam Sulmicki [EMAIL PROTECTED]
* Pekka Riikonen [EMAIL PROTECTED]
+ * Denis Cheng [EMAIL PROTECTED]
*
* Changes:
* D.J. Barrow : Fixed bug where dev-refcnt gets set
@@ -70,6 +71,32 @@
* indefinitely on dev-refcnt
* J Hadi Salim: - Backlog queue sampling
* - netif_rx() feedback
+ * Denis Cheng : Merge dev_mcast.c into it
+ */
+
+/*
+ * The original information in dev_mcast.c:
+ *
+ * Linux NET3: Multicast List maintenance.
+ *
+ * Authors:
+ * Tim Kordas [EMAIL PROTECTED]
+ * Richard Underwood [EMAIL PROTECTED]
+ *
+ * Stir fried together from the IP multicast and CAP patches above
+ * Alan Cox [EMAIL PROTECTED]
+ *
+ * Fixes:
+ * Alan Cox: Update the device on a real delete
+ * rather than any time but...
+ * Alan Cox: IFF_ALLMULTI support.
+ * Alan Cox: New format set_multicast_list() calls.
+ * Gleb Natapov: Remove dev_mc_lock.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
*/
#include asm/uaccess.h
@@ -2622,7 +2649,7 @@ void dev_set_allmulti(struct net_device *dev, int inc)
* filtering it is put in promiscous mode while unicast addresses
* are present.
*/
-void __dev_set_rx_mode(struct net_device *dev)
+static void __dev_set_rx_mode(struct net_device *dev)
{
/* dev_open will call this function so the list will stay sane. */
if (!(dev-flagsIFF_UP))
@@ -2657,7 +2684,7 @@ void dev_set_rx_mode(struct net_device *dev)
netif_tx_unlock_bh(dev);
}
-int __dev_addr_delete(struct dev_addr_list **list, int *count,
+static int __dev_addr_delete(struct dev_addr_list **list, int *count,
[PATCH 2/2] net/core: some functions' definition order adjustment for readability
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
---
net/core/dev.c | 407
1 files changed, 201 insertions(+), 206 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 16842af..ee567dd 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2790,6 +2790,134 @@ int dev_unicast_add(struct net_device *dev, void *addr,
int alen)
}
EXPORT_SYMBOL(dev_unicast_add);
+/*
+ * Device multicast list maintenance.
+ *
+ * This is used both by IP and by the user level maintenance functions.
+ * Unlike BSD we maintain a usage count on a given multicast address so
+ * that a casual user application can add/delete multicasts used by
+ * protocols without doing damage to the protocols when it deletes the
+ * entries. It also helps IP as it tracks overlapping maps.
+ *
+ * Device mc lists are changed by bh at least if IPv6 is enabled,
+ * so that it must be bh protected.
+ *
+ * We block accesses to device mc filters with netif_tx_lock.
+ */
+
+/*
+ * Delete a device level multicast
+ */
+int dev_mc_delete(struct net_device *dev, void *addr, int alen, int glbl)
+{
+ int err;
+
+ netif_tx_lock_bh(dev);
+ err = __dev_addr_delete(dev-mc_list, dev-mc_count,
+ addr, alen, glbl);
+ if (!err) {
+ /*
+* We have altered the list, so the card
+* loaded filter is now wrong. Fix it
+*/
+
+ __dev_set_rx_mode(dev);
+ }
+ netif_tx_unlock_bh(dev);
+ return err;
+}
+EXPORT_SYMBOL(dev_mc_delete);
+
+/*
+ * Add a device level multicast
+ */
+int dev_mc_add(struct net_device *dev, void *addr, int alen, int glbl)
+{
+ int err;
+
+ netif_tx_lock_bh(dev);
+ err = __dev_addr_add(dev-mc_list, dev-mc_count, addr, alen, glbl);
+ if (!err)
+ __dev_set_rx_mode(dev);
+ netif_tx_unlock_bh(dev);
+ return err;
+}
+EXPORT_SYMBOL(dev_mc_add);
+
+/**
+ * dev_mc_sync - Synchronize device's multicast list to another device
+ * @to: destination device
+ * @from: source device
+ *
+ * Add newly added addresses to the destination device and release
+ * addresses that have no users left. The source device must be
+ * locked by netif_tx_lock_bh.
+ *
+ * This function is intended to be called from the dev-set_multicast_list
+ * function of layered software devices.
+ */
+int dev_mc_sync(struct net_device *to, struct net_device *from)
+{
+ struct dev_addr_list *da;
+ int err = 0;
+
+ netif_tx_lock_bh(to);
+ for (da = from-mc_list; da != NULL; da = da-next) {
+ if (!da-da_synced) {
+ err = __dev_addr_add(to-mc_list, to-mc_count,
+da-da_addr, da-da_addrlen, 0);
+ if (err 0)
+ break;
+ da-da_synced = 1;
+ da-da_users++;
+ } else if (da-da_users == 1) {
+ __dev_addr_delete(to-mc_list, to-mc_count,
+ da-da_addr, da-da_addrlen, 0);
+ __dev_addr_delete(from-mc_list, from-mc_count,
+ da-da_addr, da-da_addrlen, 0);
+ }
+ }
+ if (!err)
+ __dev_set_rx_mode(to);
+ netif_tx_unlock_bh(to);
+
+ return err;
+}
+EXPORT_SYMBOL(dev_mc_sync);
+
+/**
+ * dev_mc_unsync - Remove synchronized addresses from the destination
+ * device
+ * @to: destination device
+ * @from: source device
+ *
+ * Remove all addresses that were added to the destination device by
+ * dev_mc_sync(). This function is intended to be called from the
+ * dev-stop function of layered software devices.
+ */
+void dev_mc_unsync(struct net_device *to, struct net_device *from)
+{
+ struct dev_addr_list *da;
+
+ netif_tx_lock_bh(from);
+ netif_tx_lock_bh(to);
+
+ for (da = from-mc_list; da != NULL; da = da-next) {
+ if (!da-da_synced)
+ continue;
+ __dev_addr_delete(to-mc_list, to-mc_count,
+ da-da_addr, da-da_addrlen, 0);
+ da-da_synced = 0;
+ __dev_addr_delete(from-mc_list, from-mc_count,
+ da-da_addr, da-da_addrlen, 0);
+ }
+ __dev_set_rx_mode(to);
+
+ netif_tx_unlock_bh(to);
+ netif_tx_unlock_bh(from);
+}
+EXPORT_SYMBOL(dev_mc_unsync);
+
static void __dev_addr_discard(struct dev_addr_list **list)
{
struct dev_addr_list *tmp;
@@ -3963,6 +4091,79 @@ static int __init netdev_dma_register(void)
static int __init netdev_dma_register(void) { return -ENODEV; }
#endif /* CONFIG_NET_DMA */
+#ifdef CONFIG_PROC_FS
+static void *dev_mc_seq_start(struct
pmtu discovery on SA
No more crashes with IPComp and smaller PMTUs. But the pmtu discovery on SA ESP/... messages don't disappear. Thats probably a different issue. Please post the output of ip -x xfrm state (obfuscate keys if you care ..). Linux (MTU 1500) - ADSL router (1492) - ... - Linux (1500) Both boxes show these messages. src 1.1.1.1 dst 2.2.2.2 proto comp spi 0xe901 reqid 16398 mode tunnel replay-window 0 comp deflate 0x src 2.2.2.2 dst 1.1.1.1 proto comp spi 0x01a3 reqid 16398 mode tunnel replay-window 0 comp deflate 0x src 1.1.1.1 dst 2.2.2.2 proto esp spi 0x767eaf0b reqid 16397 mode transport replay-window 32 auth hmac(sha1) 0xx enc cbc(aes) 0xx src 2.2.2.2 dst 1.1.1.1 proto esp spi 0x44c5adda reqid 16397 mode transport replay-window 32 auth hmac(sha1) 0xx enc cbc(aes) 0xx src 2.2.2.2 dst 1.1.1.1 proto (null) spi 0xd527fed2 reqid 0 mode tunnel replay-window 0 src 1.1.1.1 dst 2.2.2.2 proto (null) spi 0x4cf1a149 reqid 0 mode tunnel replay-window 0 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] net/core: some functions' definition order adjustment for readability
This could be done in the patch moving it .. anyways, Denis Cheng wrote: +#ifdef CONFIG_PROC_FS +static void *dev_mc_seq_start(struct seq_file *seq, loff_t *pos) If you're interested in doing more work, it would be nice to generalize the seq-file functions for unicast and multicast address lists and add /proc/net/dev_unicast or something like that. OTOH we could also export this using rtnetlink. The main reason why I didn't do that is that it can only be read, not changed, but this is also true for statistics etc. Any opinions on this? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pmtu discovery on SA
Beschorner Daniel wrote: No more crashes with IPComp and smaller PMTUs. But the pmtu discovery on SA ESP/... messages don't disappear. Thats probably a different issue. Please post the output of ip -x xfrm state (obfuscate keys if you care ..). Linux (MTU 1500) - ADSL router (1492) - ... - Linux (1500) In a previous mail you mentioned: The router on the ADSL line (behind an ADSL Netopia router via Ethernet) crashed too with 1500, now it uses 1492. So its using 1492 now? Otherwise it would be expected since the initial MTU calculation would be based on 1500. Please capture a full ICMP packet (with -s0) and send me the binary dump. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add a network activity LED trigger
Hi all,
This patch adds a new LED trigger, based on network activity. It gathers
activity from net/core/dev.c and can be used as a LED trigger by
specifying network-activity. Further version should allow the user to
specify the network interface to bind a LED to. This trigger is a simple
trigger as defined by the LED subsystem.
Signed-off-by: Florian Fainelli [EMAIL PROTECTED]
--
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 87d2046..fdc5a8a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -128,5 +128,12 @@ config LEDS_TRIGGER_HEARTBEAT
load average.
If unsure, say Y.
+config LEDS_TRIGGER_NETWORK_ACT
+ tristate LED Network Activity Trigger
+ depends on LEDS_TRIGGERS NET
+ help
+ This allow LEDs to be controlled by network activity at layer-3
networking.
+ If unsure, say Y.
+
endmenu
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index aa2c18e..bc899d3 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_LEDS_COBALT) += leds-cobalt.o
obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o
obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)+= ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
+obj-$(CONFIG_LEDS_TRIGGER_NETWORK_ACT) += ledtrig-network-activity.o
diff --git a/drivers/leds/ledtrig-network-activity.c
b/drivers/leds/ledtrig-network-activity.c
new file mode 100644
index 000..5c2e051
--- /dev/null
+++ b/drivers/leds/ledtrig-network-activity.c
@@ -0,0 +1,63 @@
+/*
+ * LED Network Activity Trigger
+ *
+ * based on ledtrig-ide-disk by Richard Purdie
+ *
+ * Copyright 2007 Florian Fainelli [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/module.h
+#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/timer.h
+#include linux/leds.h
+
+static void ledtrig_network_timerfunc(unsigned long data);
+
+DEFINE_LED_TRIGGER(ledtrig_network);
+static DEFINE_TIMER(ledtrig_network_timer, ledtrig_network_timerfunc, 0, 0);
+static int network_activity;
+static int network_lastactivity;
+
+void ledtrig_network_activity(void)
+{
+ network_activity++;
+ if (!timer_pending(ledtrig_network_timer))
+ mod_timer(ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+}
+EXPORT_SYMBOL(ledtrig_network_activity);
+
+static void ledtrig_network_timerfunc(unsigned long data)
+{
+ if (network_lastactivity != network_activity) {
+ network_lastactivity = network_activity;
+ led_trigger_event(ledtrig_network, LED_FULL);
+ mod_timer(ledtrig_network_timer, jiffies +
msecs_to_jiffies(10));
+ } else {
+ led_trigger_event(ledtrig_network, LED_OFF);
+ }
+}
+
+static int __init ledtrig_network_init(void)
+{
+ led_trigger_register_simple(network-activity, ledtrig_network);
+ return 0;
+}
+
+static void __exit ledtrig_network_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_network);
+}
+
+module_init(ledtrig_network_init);
+module_exit(ledtrig_network_exit);
+
+MODULE_AUTHOR(Florian Fainelli [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(LED Network Activity trigger);
+MODULE_LICENSE(GPL);
diff --git a/net/core/dev.c b/net/core/dev.c
index ee051bb..a3a4115 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -117,6 +117,7 @@
#include linux/err.h
#include linux/ctype.h
#include linux/if_arp.h
+#include linux/leds.h
/*
* The list of packet types we will receive (as opposed to discard)
@@ -1523,6 +1524,7 @@ gso:
* stops preemption for RCU.
*/
rcu_read_lock_bh();
+ ledtrig_network_activity();
/* Updates of qdisc are serialized by queue_lock.
* The struct Qdisc which is pointed to by qdisc is now a
signature.asc
Description: This is a digitally signed message part.
Re: [RFC 0/3] lro: Generic Large Receive Offload for TCP traffic (IPv6)
Hi, I suggest we keep the interface open for IPv6 support by adding an additional parameter but first just get IPv4 support only into the kernel. IPv6 support can then incrementially be added. Would that be ok? On Sunday 15 July 2007 11:40, David Miller wrote: From: Christoph Hellwig [EMAIL PROTECTED] Date: Sun, 15 Jul 2007 10:12:53 +0100 I'm not sure that's a good idea. If current chips can't handle ipv6 lro there is no way to actually test it and the code will surely bitrot. Christoph, you can do LRO pretty much completely in software. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
Florian Fainelli wrote: diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 87d2046..fdc5a8a 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -128,5 +128,12 @@ config LEDS_TRIGGER_HEARTBEAT load average. If unsure, say Y. +config LEDS_TRIGGER_NETWORK_ACT + tristate LED Network Activity Trigger Module isn't possible, you call the led trigger from net/core/dev.c. diff --git a/net/core/dev.c b/net/core/dev.c index ee051bb..a3a4115 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -117,6 +117,7 @@ #include linux/err.h #include linux/ctype.h #include linux/if_arp.h +#include linux/leds.h /* * The list of packet types we will receive (as opposed to discard) @@ -1523,6 +1524,7 @@ gso: * stops preemption for RCU. */ rcu_read_lock_bh(); + ledtrig_network_activity(); Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
On Wed, 18 Jul 2007 15:27:38 +0200 Florian Fainelli [EMAIL PROTECTED] wrote: Hi all, This patch adds a new LED trigger, based on network activity. It gathers activity from net/core/dev.c and can be used as a LED trigger by specifying network-activity. Further version should allow the user to specify the network interface to bind a LED to. This trigger is a simple trigger as defined by the LED subsystem. Signed-off-by: Florian Fainelli [EMAIL PROTECTED] -- You are slowing down the network receive path even if LED is not used. Doing mod_timer() is expensive, on a busy system you would be adding another lock roundtrip and list operation for each incoming packet. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
Hello Patrick, Le mercredi 18 juillet 2007, Patrick McHardy a écrit : Module isn't possible, you call the led trigger from net/core/dev.c. You are right, it just occured to me. Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. Could you suggest me a better way to do so ? The code was highly inspired from what is done with the IDE trigger. The declaration is done in linux/leds.h, which is included in dev.c for that purpose. Thank you very much for your answer. signature.asc Description: This is a digitally signed message part.
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote: On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. Would you be opposed to including that patch in mainline? I'd like to have the bug reporter try it and then get it in if it fixes the issue. josh - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
Florian Fainelli wrote: Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. Could you suggest me a better way to do so ? The code was highly inspired from what is done with the IDE trigger. The declaration is done in linux/leds.h, which is included in dev.c for that purpose. Maybe just increment a variable and periodically check it or something like that. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
On Wed, 2007-07-18 at 15:54 +0200, Patrick McHardy wrote: Florian Fainelli wrote: Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. Could you suggest me a better way to do so ? The code was highly inspired from what is done with the IDE trigger. The declaration is done in linux/leds.h, which is included in dev.c for that purpose. Maybe just increment a variable and periodically check it or something like that. Are there not already packet counters that the LED trigger could just look at? If it did that at say 20Hz or 10Hz, it would probably look quite reasonable without impacting on the system too much? Richard - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add a network activity LED trigger
Richard Purdie wrote: On Wed, 2007-07-18 at 15:54 +0200, Patrick McHardy wrote: Florian Fainelli wrote: Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. Could you suggest me a better way to do so ? The code was highly inspired from what is done with the IDE trigger. The declaration is done in linux/leds.h, which is included in dev.c for that purpose. Maybe just increment a variable and periodically check it or something like that. Are there not already packet counters that the LED trigger could just look at? If it did that at say 20Hz or 10Hz, it would probably look quite reasonable without impacting on the system too much The qdisc counters might work, I think all qdiscs properly maintain at least byte and packet counters. Or simply check the queue length, if 0 there is activity. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] net/core: some functions' definition order adjustment for readability
On 7/18/07, Patrick McHardy [EMAIL PROTECTED] wrote: This could be done in the patch moving it .. anyways, What? Denis Cheng wrote: +#ifdef CONFIG_PROC_FS +static void *dev_mc_seq_start(struct seq_file *seq, loff_t *pos) If you're interested in doing more work, it would be nice to generalize the seq-file functions for unicast and multicast address lists and add /proc/net/dev_unicast or something like that. Eh, there is already a dev_multicast file but lack of dev_unicast, but is dev_unicast really useful? OTOH we could also export this using rtnetlink. The main reason why I didn't do that is that it can only be read, not changed, but this is also true for statistics etc. Any opinions on this? how to do that? -- Denis Cheng Linux Application Developer One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Occational lockups during boot with post 2.6.22 kernels
On 07/17/2007 08:20 PM, Peter Osterlund wrote: Current -git kernels sometimes lock up on my computer during boot. I guess it happens about 10-20% of the time. I first saw this maybe a week ago, but never with kernels = 2.6.22. The last reported info on the console is that named is started. SysRq-T still works and reports the non-sleeping tasks below. My guess is that wpa_supplicant and events/0 deadlock and later the named thread also hangs when it needs a deadlocked resource. I'm using the bcm43xx driver. No lockdep errors are reported before the lockup. Earlier during boot the kernel reports: Good, all 218 testcases passed! | Try this, it should at least detect the problem: http://lkml.org/lkml/2007/7/17/202 http://lkml.org/lkml/2007/7/17/204 http://lkml.org/lkml/2007/7/17/203 It's a known bug in wireless/80211, not sure when it will be fixed. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mac80211: fix GCC warning on 64bit platforms
net/mac80211/ieee80211.c: In function ieee80211_register_hw: net/mac80211/ieee80211.c:4989: warning: comparison of distinct pointer types lacks a cast Size of ieee80211_tx_status_rtap_hdr structure will never be greater than unsigned int. Signed-off-by: Jiri Benc [EMAIL PROTECTED] --- On Mon, 16 Jul 2007 14:53:58 -0700 (PDT), David Miller wrote: The macro max_t exists for these kinds of situations, please use it. :-) Ok. --- net/mac80211/ieee80211.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- mac80211-2.6.orig/net/mac80211/ieee80211.c +++ mac80211-2.6/net/mac80211/ieee80211.c @@ -4986,8 +4986,8 @@ int ieee80211_register_hw(struct ieee802 * and we need some headroom for passing the frame to monitor * interfaces, but never both at the same time. */ - local-tx_headroom = max(local-hw.extra_tx_headroom, -sizeof(struct ieee80211_tx_status_rtap_hdr)); + local-tx_headroom = max_t(unsigned, local-hw.extra_tx_headroom, + sizeof(struct ieee80211_tx_status_rtap_hdr)); debugfs_hw_add(local); -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] eHEA: Fix bonding support
The driver didn't allow an interface's MAC address to be modified if the
respective interface wasn't setup - a failing Hcall was the result. Thus
bonding wasn't usable. The fix moves the failing Hcall which was registering
a MAC address for the reception of BC packets in firmware from the port up
and down functions to the port resources setup functions. Additionally the
missing update of the last_rx member of the netdev structure was added.
Signed-off-by: Thomas Klein [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |2 +-
drivers/net/ehea/ehea_main.c | 37 +++--
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 6628fa6..489c8b2 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include asm/io.h
#define DRV_NAME ehea
-#define DRV_VERSIONEHEA_0070
+#define DRV_VERSIONEHEA_0071
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 1d1571c..4c70a93 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -466,6 +466,8 @@ static struct ehea_cqe *ehea_proc_rwqes(struct net_device
*dev,
cqe-vlan_tag);
else
netif_receive_skb(skb);
+
+ dev-last_rx = jiffies;
} else {
pr-p_stats.poll_receive_errors++;
port_reset = ehea_treat_poll_error(pr, rq, cqe,
@@ -1433,7 +1435,8 @@ static int ehea_broadcast_reg_helper(struct ehea_port
*port, u32 hcallid)
port-logical_port_id,
reg_type, port-mac_addr, 0, hcallid);
if (hret != H_SUCCESS) {
- ehea_error(reg_dereg_bcmc failed (tagged));
+ ehea_error(%sregistering bc address failed (tagged),
+ hcallid == H_REG_BCMC ? : de);
ret = -EIO;
goto out_herr;
}
@@ -1444,7 +1447,8 @@ static int ehea_broadcast_reg_helper(struct ehea_port
*port, u32 hcallid)
port-logical_port_id,
reg_type, port-mac_addr, 0, hcallid);
if (hret != H_SUCCESS) {
- ehea_error(reg_dereg_bcmc failed (vlan));
+ ehea_error(%sregistering bc address failed (vlan),
+ hcallid == H_REG_BCMC ? : de);
ret = -EIO;
}
out_herr:
@@ -2170,7 +2174,6 @@ static int ehea_up(struct net_device *dev)
{
int ret, i;
struct ehea_port *port = netdev_priv(dev);
- u64 mac_addr = 0;
if (port-state == EHEA_PORT_UP)
return 0;
@@ -2189,18 +2192,10 @@ static int ehea_up(struct net_device *dev)
goto out_clean_pr;
}
- ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
- if (ret) {
- ret = -EIO;
- ehea_error(out_clean_pr);
- goto out_clean_pr;
- }
- mac_addr = (*(u64*)dev-dev_addr) 16;
-
ret = ehea_reg_interrupts(dev);
if (ret) {
- ehea_error(out_dereg_bc);
- goto out_dereg_bc;
+ ehea_error(reg_interrupts failed. ret:%d, ret);
+ goto out_clean_pr;
}
for(i = 0; i port-num_def_qps + port-num_add_tx_qps; i++) {
@@ -2226,9 +2221,6 @@ static int ehea_up(struct net_device *dev)
out_free_irqs:
ehea_free_interrupts(dev);
-out_dereg_bc:
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
-
out_clean_pr:
ehea_clean_all_portres(port);
out:
@@ -2273,7 +2265,6 @@ static int ehea_down(struct net_device *dev)
port-port_res[i].d_netdev-state))
msleep(1);
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
port-state = EHEA_PORT_DOWN;
ret = ehea_clean_all_portres(port);
@@ -2655,12 +2646,18 @@ struct ehea_port *ehea_setup_single_port(struct
ehea_adapter *adapter,
INIT_WORK(port-reset_task, ehea_reset_port);
+ ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
+ if (ret) {
+ ret = -EIO;
+ goto out_unreg_port;
+ }
+
ehea_set_ethtool_ops(dev);
ret = register_netdev(dev);
if (ret) {
ehea_error(register_netdev failed. ret=%d, ret);
- goto out_unreg_port;
+ goto out_dereg_bc;
}
ret = ehea_get_jumboframe_status(port, jumbo);
@@ -2675,6 +2672,9 @@ struct ehea_port *ehea_setup_single_port(struct
ehea_adapter *adapter,
return port;
+out_dereg_bc:
+ ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
+
out_unreg_port:
ehea_unregister_port(port);
@@ -2694,6 +2694,7 @@ static void
Re: [patch 1/3] netlink: allocate group bitmaps dynamically
On Tue, 2007-07-17 at 17:45 +0200, Patrick McHardy wrote:
--- wireless-dev.orig/net/netlink/af_netlink.c 2007-07-17
14:05:30.210964463 +0200
+++ wireless-dev/net/netlink/af_netlink.c 2007-07-17 14:05:30.720964463
+0200
-static int netlink_alloc_groups(struct sock *sk)
+static int netlink_realloc_groups(struct sock *sk)
{
struct netlink_sock *nlk = nlk_sk(sk);
unsigned int groups;
+ unsigned long *new_groups;
int err = 0;
netlink_lock_table();
This is actually a bug in the current code I think, netlink_lock_table
is a reader lock.
Looks like, changed to netlink_table_grab()
+int netlink_change_ngroups(int unit, unsigned int groups)
I think it would be more consistent to pass the kernel socket
instead of the unit.
Alright, changed. Also added kernel doc for the function.
This might set the group to a value 32. I don't expect it matters,
but when I changed to old code to support 32 groups I enforced
a minimum of 32 so anything outside the kernel multicasting on them
would still work (even though its a really stupid idea). So for
consistency this should probably also use a minimum of 32.
Huh ok. Fixed, and added to documentation.
johannes
signature.asc
Description: This is a digitally signed message part
Re: [patch 2/3] netlink: allow removing multicast groups
On Tue, 2007-07-17 at 17:50 +0200, Patrick McHardy wrote: Having the caller lock the table would save lots of atomic operation in case of netlink_clear_multicast_users. Good point. +void netlink_clear_multicast_users(int unit, unsigned int group) Same as in the last patch, passing the kernel socket would be nicer IMO. Changed. + read_lock(nl_table_lock); Won't this deadlock? netlink_table_grab takes a write-lock. I guess it's valid to update a read lock to a write lock? Or I was just lucky on UP. But moving the lock out of netlink_clear_multicast_users() made this obvious and I just use the write lock now. johannes signature.asc Description: This is a digitally signed message part
[PATCH v2 2/3] netlink: allow removing multicast groups
Allow kicking listeners out of a multicast group when necessary
(for example if that group is going to be removed.)
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
Changes: incorporate Patrick's comments, add kernel-doc.
include/linux/netlink.h |1
net/netlink/af_netlink.c | 57 +--
2 files changed, 46 insertions(+), 12 deletions(-)
--- wireless-dev.orig/include/linux/netlink.h 2007-07-18 15:01:06.042900849
+0200
+++ wireless-dev/include/linux/netlink.h2007-07-18 15:01:22.542900849
+0200
@@ -162,6 +162,7 @@ extern struct sock *netlink_kernel_creat
struct mutex *cb_mutex,
struct module *module);
extern int netlink_change_ngroups(struct sock *sk, unsigned int groups);
+extern void netlink_clear_multicast_users(struct sock *sk, unsigned int group);
extern void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err);
extern int netlink_has_listeners(struct sock *sk, unsigned int group);
extern int netlink_unicast(struct sock *ssk, struct sk_buff *skb, __u32 pid,
int nonblock);
--- wireless-dev.orig/net/netlink/af_netlink.c 2007-07-18 15:01:10.482900849
+0200
+++ wireless-dev/net/netlink/af_netlink.c 2007-07-18 15:02:09.642900849
+0200
@@ -1027,6 +1027,23 @@ void netlink_set_err(struct sock *ssk, u
read_unlock(nl_table_lock);
}
+/* must be called with netlink table grabbed */
+static void netlink_update_socket_mc(struct netlink_sock *nlk,
+unsigned int group,
+int is_new)
+{
+ int old, new = !!is_new, subscriptions;
+
+ old = test_bit(group - 1, nlk-groups);
+ subscriptions = nlk-subscriptions - old + new;
+ if (new)
+ __set_bit(group - 1, nlk-groups);
+ else
+ __clear_bit(group - 1, nlk-groups);
+ netlink_update_subscriptions(nlk-sk, subscriptions);
+ netlink_update_listeners(nlk-sk);
+}
+
static int netlink_setsockopt(struct socket *sock, int level, int optname,
char __user *optval, int optlen)
{
@@ -1052,9 +1069,6 @@ static int netlink_setsockopt(struct soc
break;
case NETLINK_ADD_MEMBERSHIP:
case NETLINK_DROP_MEMBERSHIP: {
- unsigned int subscriptions;
- int old, new = optname == NETLINK_ADD_MEMBERSHIP ? 1 : 0;
-
if (!netlink_capable(sock, NL_NONROOT_RECV))
return -EPERM;
err = netlink_realloc_groups(sk);
@@ -1063,14 +1077,8 @@ static int netlink_setsockopt(struct soc
if (!val || val - 1 = nlk-ngroups)
return -EINVAL;
netlink_table_grab();
- old = test_bit(val - 1, nlk-groups);
- subscriptions = nlk-subscriptions - old + new;
- if (new)
- __set_bit(val - 1, nlk-groups);
- else
- __clear_bit(val - 1, nlk-groups);
- netlink_update_subscriptions(sk, subscriptions);
- netlink_update_listeners(sk);
+ netlink_update_socket_mc(nlk, val,
+optname == NETLINK_ADD_MEMBERSHIP);
netlink_table_ungrab();
err = 0;
break;
@@ -1351,7 +1359,9 @@ out_sock_release:
*
* This changes the number of multicast groups that are available
* on a certain netlink family. Note that it is not possible to
- * change the number of groups to below 32.
+ * change the number of groups to below 32. Also note that it does
+ * not implicitly call netlink_clear_multicast_users() when the
+ * number of groups is reduced.
*
* @sk: The kernel netlink socket, as returned by netlink_kernel_create().
* @groups: The new number of groups.
@@ -1386,6 +1396,29 @@ int netlink_change_ngroups(struct sock *
}
EXPORT_SYMBOL(netlink_change_ngroups);
+/**
+ * netlink_clear_multicast_users - kick off multicast listeners
+ *
+ * This function removes all listeners from the given group.
+ * @ksk: The kernel netlink socket, as returned by
+ * netlink_kernel_create().
+ * @group: The multicast group to clear.
+ */
+void netlink_clear_multicast_users(struct sock *ksk, unsigned int group)
+{
+ struct sock *sk;
+ struct hlist_node *node;
+ struct netlink_table *tbl = nl_table[ksk-sk_protocol];
+
+ netlink_table_grab();
+
+ sk_for_each_bound(sk, node, tbl-mc_list)
+ netlink_update_socket_mc(nlk_sk(sk), group, 0);
+
+ netlink_table_ungrab();
+}
+EXPORT_SYMBOL(netlink_clear_multicast_users);
+
void netlink_set_nonroot(int protocol, unsigned int flags)
{
if ((unsigned int)protocol MAX_LINKS)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH v2 1/3] netlink: allocate group bitmaps dynamically
Allow changing the number of groups for a netlink family
after it has been created, use RCU to protect the listeners
bitmap keeping netlink_has_listeners() lock-free.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
Changes: incorporate Patrick's comments, add kernel-doc
include/linux/netlink.h |1
net/netlink/af_netlink.c | 106 ---
2 files changed, 83 insertions(+), 24 deletions(-)
--- wireless-dev.orig/net/netlink/af_netlink.c 2007-07-18 15:09:02.952900849
+0200
+++ wireless-dev/net/netlink/af_netlink.c 2007-07-18 16:33:33.691236687
+0200
@@ -62,6 +62,7 @@
#include net/netlink.h
#define NLGRPSZ(x) (ALIGN(x, sizeof(unsigned long) * 8) / 8)
+#define NLGRPLONGS(x) (NLGRPSZ(x)/sizeof(unsigned long))
struct netlink_sock {
/* struct sock has to be the first member of netlink_sock */
@@ -314,10 +315,12 @@ netlink_update_listeners(struct sock *sk
unsigned long mask;
unsigned int i;
- for (i = 0; i NLGRPSZ(tbl-groups)/sizeof(unsigned long); i++) {
+ for (i = 0; i NLGRPLONGS(tbl-groups); i++) {
mask = 0;
- sk_for_each_bound(sk, node, tbl-mc_list)
- mask |= nlk_sk(sk)-groups[i];
+ sk_for_each_bound(sk, node, tbl-mc_list) {
+ if (i NLGRPLONGS(nlk_sk(sk)-ngroups))
+ mask |= nlk_sk(sk)-groups[i];
+ }
tbl-listeners[i] = mask;
}
/* this function is only called with the netlink table grabbed, which
@@ -555,26 +558,37 @@ netlink_update_subscriptions(struct sock
nlk-subscriptions = subscriptions;
}
-static int netlink_alloc_groups(struct sock *sk)
+static int netlink_realloc_groups(struct sock *sk)
{
struct netlink_sock *nlk = nlk_sk(sk);
unsigned int groups;
+ unsigned long *new_groups;
int err = 0;
- netlink_lock_table();
+ netlink_table_grab();
+
groups = nl_table[sk-sk_protocol].groups;
- if (!nl_table[sk-sk_protocol].registered)
+ if (!nl_table[sk-sk_protocol].registered) {
err = -ENOENT;
- netlink_unlock_table();
+ goto out_unlock;
+ }
- if (err)
- return err;
+ if (nlk-ngroups = groups)
+ goto out_unlock;
- nlk-groups = kzalloc(NLGRPSZ(groups), GFP_KERNEL);
- if (nlk-groups == NULL)
- return -ENOMEM;
+ new_groups = krealloc(nlk-groups, NLGRPSZ(groups), GFP_ATOMIC);
+ if (new_groups == NULL) {
+ err = -ENOMEM;
+ goto out_unlock;
+ }
+ memset((char*)new_groups + NLGRPSZ(nlk-ngroups), 0,
+ NLGRPSZ(groups) - NLGRPSZ(nlk-ngroups));
+
+ nlk-groups = new_groups;
nlk-ngroups = groups;
- return 0;
+ out_unlock:
+ netlink_table_ungrab();
+ return err;
}
static int netlink_bind(struct socket *sock, struct sockaddr *addr, int
addr_len)
@@ -591,11 +605,9 @@ static int netlink_bind(struct socket *s
if (nladdr-nl_groups) {
if (!netlink_capable(sock, NL_NONROOT_RECV))
return -EPERM;
- if (nlk-groups == NULL) {
- err = netlink_alloc_groups(sk);
- if (err)
- return err;
- }
+ err = netlink_realloc_groups(sk);
+ if (err)
+ return err;
}
if (nlk-pid) {
@@ -839,10 +851,18 @@ retry:
int netlink_has_listeners(struct sock *sk, unsigned int group)
{
int res = 0;
+ unsigned long *listeners;
BUG_ON(!(nlk_sk(sk)-flags NETLINK_KERNEL_SOCKET));
+
+ rcu_read_lock();
+ listeners = rcu_dereference(nl_table[sk-sk_protocol].listeners);
+
if (group - 1 nl_table[sk-sk_protocol].groups)
- res = test_bit(group - 1, nl_table[sk-sk_protocol].listeners);
+ res = test_bit(group - 1, listeners);
+
+ rcu_read_unlock();
+
return res;
}
EXPORT_SYMBOL_GPL(netlink_has_listeners);
@@ -1037,11 +1057,9 @@ static int netlink_setsockopt(struct soc
if (!netlink_capable(sock, NL_NONROOT_RECV))
return -EPERM;
- if (nlk-groups == NULL) {
- err = netlink_alloc_groups(sk);
- if (err)
- return err;
- }
+ err = netlink_realloc_groups(sk);
+ if (err)
+ return err;
if (!val || val - 1 = nlk-ngroups)
return -EINVAL;
netlink_table_grab();
@@ -1328,6 +1346,46 @@ out_sock_release:
return NULL;
}
+/**
+ * netlink_change_ngroups - change number of multicast groups
+ *
+ * This changes the number of multicast groups that are available
+ * on a certain netlink
[PATCH v2 3/3] generic netlink: dynamic multicast groups
Introduce API to dynamically register and unregister multicast groups.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
Changes: update for slightly changed API from v2 of patch 1 and 2, add
kernel-doc, properly register the generic netlink group as well, fix bug
with that group (it isn't ID 1 but ID 0x10)
include/linux/genetlink.h | 13 ++
include/net/genetlink.h | 22
net/netlink/genetlink.c | 235 --
3 files changed, 263 insertions(+), 7 deletions(-)
--- wireless-dev.orig/include/net/genetlink.h 2007-07-18 16:52:31.366081353
+0200
+++ wireless-dev/include/net/genetlink.h2007-07-18 16:54:30.716081353
+0200
@@ -5,6 +5,22 @@
#include net/netlink.h
/**
+ * struct genl_multicast_group - generic netlink multicast group
+ * @name: name of the multicast group, names are per-family
+ * @id: multicast group ID, assigned by the core, to use with
+ * genlmsg_multicast().
+ * @list: list entry for linking
+ * @family: pointer to family, need not be set before registering
+ */
+struct genl_multicast_group
+{
+ struct genl_family *family;/* private */
+ struct list_headlist; /* private */
+ charname[GENL_NAMSIZ];
+ u32 id;
+};
+
+/**
* struct genl_family - generic netlink family
* @id: protocol family idenfitier
* @hdrsize: length of user specific header in bytes
@@ -14,6 +30,7 @@
* @attrbuf: buffer to store parsed attributes
* @ops_list: list of all assigned operations
* @family_list: family list
+ * @mcast_groups: multicast groups list
*/
struct genl_family
{
@@ -25,6 +42,7 @@ struct genl_family
struct nlattr **attrbuf;/* private */
struct list_headops_list; /* private */
struct list_headfamily_list;/* private */
+ struct list_headmcast_groups; /* private */
};
/**
@@ -73,6 +91,10 @@ extern int genl_register_family(struct g
extern int genl_unregister_family(struct genl_family *family);
extern int genl_register_ops(struct genl_family *, struct genl_ops *ops);
extern int genl_unregister_ops(struct genl_family *, struct genl_ops *ops);
+extern int genl_register_mc_group(struct genl_family *family,
+ struct genl_multicast_group *grp);
+extern void genl_unregister_mc_group(struct genl_family *family,
+struct genl_multicast_group *grp);
extern struct sock *genl_sock;
--- wireless-dev.orig/net/netlink/genetlink.c 2007-07-18 16:52:31.456081353
+0200
+++ wireless-dev/net/netlink/genetlink.c2007-07-18 17:04:45.706081353
+0200
@@ -3,6 +3,7 @@
*
* Authors:Jamal Hadi Salim
* Thomas Graf [EMAIL PROTECTED]
+ * Johannes Berg [EMAIL PROTECTED]
*/
#include linux/module.h
@@ -13,6 +14,7 @@
#include linux/string.h
#include linux/skbuff.h
#include linux/mutex.h
+#include linux/bitmap.h
#include net/sock.h
#include net/genetlink.h
@@ -42,6 +44,16 @@ static void genl_unlock(void)
#define GENL_FAM_TAB_MASK (GENL_FAM_TAB_SIZE - 1)
static struct list_head family_ht[GENL_FAM_TAB_SIZE];
+/*
+ * Bitmap of multicast groups that are currently in use.
+ *
+ * To avoid an allocation at boot of just one unsigned long,
+ * declare it global instead.
+ * Bit 0 is marked as already used since group 0 is invalid.
+ */
+static unsigned long mc_group_start = 0x1;
+static unsigned long *mc_groups = mc_group_start;
+static unsigned long mc_groups_longs = 1;
static int genl_ctrl_event(int event, void *data);
@@ -116,6 +128,114 @@ static inline u16 genl_generate_id(void)
return id_gen_idx;
}
+static struct genl_multicast_group notify_grp;
+
+/**
+ * genl_register_mc_group - register a multicast group
+ *
+ * Registers the specified multicast group and notifies userspace
+ * about the new group.
+ *
+ * Returns 0 on success or a negative error code.
+ *
+ * @family: The generic netlink family the group shall be registered for.
+ * @grp: The group to register, must have a name.
+ */
+int genl_register_mc_group(struct genl_family *family,
+ struct genl_multicast_group *grp)
+{
+ int id;
+ unsigned long *new_groups;
+ int err;
+
+ BUG_ON(grp-name[0] == '\0');
+
+ genl_lock();
+
+ /* special-case our own group */
+ if (grp == notify_grp)
+ id = GENL_ID_CTRL;
+ else
+ id = find_first_zero_bit(mc_groups,
+mc_groups_longs * BITS_PER_LONG);
+
+
+ if (id = mc_groups_longs * BITS_PER_LONG) {
+ size_t nlen = (mc_groups_longs + 1) * sizeof(unsigned long);
+
+ if (mc_groups == mc_group_start) {
+ new_groups = kzalloc(nlen, GFP_KERNEL);
+ if (!new_groups) {
+
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote: On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote: On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. Would you be opposed to including that patch in mainline? Yes. I don't think it's the right way to fix this issue. IMO, the right one is to fix slab allocator. You cannot change all drivers to do this kind of cache flushing, and yes, I saw the same problem with PCI based NIC I tried on Ocotea at the time. -- Eugene - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'upstream-davem' branch of wireless-2.6
On Tue, Jul 17, 2007 at 08:17:16PM -0700, David Miller wrote:
From: John W. Linville [EMAIL PROTECTED]
Date: Tue, 17 Jul 2007 22:16:07 -0400
A few more for 2.6.23...individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem
What about this warning which I reported to you right after the last
merge? Did this get fixed?
net/mac80211/ieee80211.c:4989: warning: comparison of distinct pointer types
lacks a cast
Please fix that up first, then I'll pull from your tree.
Fair enough! :-)
John
---
The following changes since commit 4ad1366376bfef32ec0ffa12d1faa483d6f330bd:
NeilBrown (1):
md: change bitmap_unplug and others to void functions
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-davem
Daniel Drake (1):
mac80211: regulatory domain cleanup
Jiri Benc (1):
mac80211: fix GCC warning on 64bit platforms
Johannes Berg (2):
mac80211: use debugfs_rename
mac80211: regdomain.c needs to include ieee80211_i.h
net/mac80211/Makefile |1 +
net/mac80211/debugfs_netdev.c |9 ++-
net/mac80211/ieee80211.c |7 +-
net/mac80211/ieee80211_i.h |5 +-
net/mac80211/ieee80211_ioctl.c | 133 -
net/mac80211/regdomain.c | 158
6 files changed, 173 insertions(+), 140 deletions(-)
create mode 100644 net/mac80211/regdomain.c
diff --git a/net/mac80211/Makefile b/net/mac80211/Makefile
index e9738da..a9c2d07 100644
--- a/net/mac80211/Makefile
+++ b/net/mac80211/Makefile
@@ -13,6 +13,7 @@ mac80211-objs := \
ieee80211_iface.o \
ieee80211_rate.o \
michael.o \
+ regdomain.o \
tkip.o \
aes_ccm.o \
wme.o \
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index a3e01d7..799a920 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -397,6 +397,8 @@ static int netdev_notify(struct notifier_block * nb,
void *ndev)
{
struct net_device *dev = ndev;
+ struct dentry *dir;
+ struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
char buf[10+IFNAMSIZ];
if (state != NETDEV_CHANGENAME)
@@ -408,10 +410,11 @@ static int netdev_notify(struct notifier_block * nb,
if (dev-ieee80211_ptr-wiphy-privid != mac80211_wiphy_privid)
return 0;
- /* TODO
sprintf(buf, netdev:%s, dev-name);
- debugfs_rename(IEEE80211_DEV_TO_SUB_IF(dev)-debugfsdir, buf);
- */
+ dir = sdata-debugfsdir;
+ if (!debugfs_rename(dir-d_parent, dir, dir-d_parent, buf))
+ printk(KERN_ERR mac80211: debugfs: failed to rename debugfs
+ dir to %s\n, buf);
return 0;
}
diff --git a/net/mac80211/ieee80211.c b/net/mac80211/ieee80211.c
index 2ddf4ef..272aae9 100644
--- a/net/mac80211/ieee80211.c
+++ b/net/mac80211/ieee80211.c
@@ -4986,8 +4986,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
* and we need some headroom for passing the frame to monitor
* interfaces, but never both at the same time.
*/
- local-tx_headroom = max(local-hw.extra_tx_headroom,
-sizeof(struct ieee80211_tx_status_rtap_hdr));
+ local-tx_headroom = max_t(unsigned, local-hw.extra_tx_headroom,
+ sizeof(struct ieee80211_tx_status_rtap_hdr));
debugfs_hw_add(local);
@@ -5095,7 +5095,7 @@ int ieee80211_register_hwmode(struct ieee80211_hw *hw,
}
if (!(hw-flags IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED))
- ieee80211_init_client(local-mdev);
+ ieee80211_set_default_regdomain(mode);
return 0;
}
@@ -5246,6 +5246,7 @@ static int __init ieee80211_init(void)
}
ieee80211_debugfs_netdev_init();
+ ieee80211_regdomain_init();
return 0;
}
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 055a2a9..6f7bae7 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -759,7 +759,6 @@ void ieee80211_update_default_wep_only(struct
ieee80211_local *local);
/* ieee80211_ioctl.c */
int ieee80211_set_compression(struct ieee80211_local *local,
struct net_device *dev, struct sta_info *sta);
-int ieee80211_init_client(struct net_device *dev);
int ieee80211_set_channel(struct ieee80211_local *local, int channel, int
freq);
/* ieee80211_sta.c */
void ieee80211_sta_timer(unsigned long data);
@@ -798,6 +797,10 @@ void ieee80211_if_sdata_init(struct ieee80211_sub_if_data
*sdata);
int ieee80211_if_add_mgmt(struct ieee80211_local *local);
void ieee80211_if_del_mgmt(struct ieee80211_local *local);
+/* regdomain.c */
+void ieee80211_regdomain_init(void);
+void
Re: pmtu discovery on SA
Beschorner Daniel wrote: No more crashes with IPComp and smaller PMTUs. But the pmtu discovery on SA ESP/... messages don't disappear. Thats probably a different issue. Please post the output of ip -x xfrm state (obfuscate keys if you care ..). Linux (MTU 1500) - ADSL router (1492) - ... - Linux (1500) In a previous mail you mentioned: The router on the ADSL line (behind an ADSL Netopia router via Ethernet) crashed too with 1500, now it uses 1492. So its using 1492 now? Otherwise it would be expected since the initial MTU calculation would be based on 1500. I'm using 1500 again. Just to make it clear: Is this message an error, or a warning or just for information? Could you explain a bit please. I have no connections hangs or other kind of problems. Thank you Daniel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mac80211: fix GCC warning on 64bit platforms
Jiri Benc wrote: net/mac80211/ieee80211.c: In function ieee80211_register_hw: net/mac80211/ieee80211.c:4989: warning: comparison of distinct pointer types lacks a cast Size of ieee80211_tx_status_rtap_hdr structure will never be greater than unsigned int. Signed-off-by: Jiri Benc [EMAIL PROTECTED] --- On Mon, 16 Jul 2007 14:53:58 -0700 (PDT), David Miller wrote: The macro max_t exists for these kinds of situations, please use it. :-) Ok. --- net/mac80211/ieee80211.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- mac80211-2.6.orig/net/mac80211/ieee80211.c +++ mac80211-2.6/net/mac80211/ieee80211.c @@ -4986,8 +4986,8 @@ int ieee80211_register_hw(struct ieee802 * and we need some headroom for passing the frame to monitor * interfaces, but never both at the same time. */ - local-tx_headroom = max(local-hw.extra_tx_headroom, -sizeof(struct ieee80211_tx_status_rtap_hdr)); + local-tx_headroom = max_t(unsigned, local-hw.extra_tx_headroom, + sizeof(struct ieee80211_tx_status_rtap_hdr)); debugfs_hw_add(local); For my info on how to use max_t, not as a critique of this patch. (1) Is 'unsigned' enough or should it be 'unsigned int'? (2) Because tx_headroom is an int, why use unsigned at all? Larry - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Occational lockups during boot with post 2.6.22 kernels
On Wed, 2007-07-18 at 10:58 -0400, Chuck Ebbert wrote: On 07/17/2007 08:20 PM, Peter Osterlund wrote: Current -git kernels sometimes lock up on my computer during boot. I guess it happens about 10-20% of the time. I first saw this maybe a week ago, but never with kernels = 2.6.22. The last reported info on the console is that named is started. SysRq-T still works and reports the non-sleeping tasks below. My guess is that wpa_supplicant and events/0 deadlock and later the named thread also hangs when it needs a deadlocked resource. I'm using the bcm43xx driver. No lockdep errors are reported before the lockup. Earlier during boot the kernel reports: Good, all 218 testcases passed! | Try this, it should at least detect the problem: http://lkml.org/lkml/2007/7/17/202 http://lkml.org/lkml/2007/7/17/204 http://lkml.org/lkml/2007/7/17/203 It's a known bug in wireless/80211, not sure when it will be fixed. Heh, yes, that's the patchset that came from this bug :) A patch for this is available but due to process issues hasn't percolated up yet. See http://thread.gmane.org/gmane.linux.kernel.wireless.general/3315/focus=3319 johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] mac80211: fix GCC warning on 64bit platforms
On Wed, 18 Jul 2007 11:14:40 -0500, Larry Finger wrote: - local-tx_headroom = max(local-hw.extra_tx_headroom, -sizeof(struct ieee80211_tx_status_rtap_hdr)); + local-tx_headroom = max_t(unsigned, local-hw.extra_tx_headroom, + sizeof(struct ieee80211_tx_status_rtap_hdr)); debugfs_hw_add(local); For my info on how to use max_t, not as a critique of this patch. (1) Is 'unsigned' enough or should it be 'unsigned int'? Don't know. For a C compiler, it doesn't matter, but it's fact that most of the code in the kernel uses unsigned int. (2) Because tx_headroom is an int, why use unsigned at all? Because hw.extra_tx_headroom is unsigned. tx_headroom should be IMO unsigned too but that's not just a matter of changing its type as it would mean a lot of new warnings. We're talking about numbers several orders less than int, so it's not an issue here anyway. If you think int is more appropriate, fine with me, I don't really care. Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pmtu discovery on SA
Beschorner Daniel wrote: Beschorner Daniel wrote: So its using 1492 now? Otherwise it would be expected since the initial MTU calculation would be based on 1500. I'm using 1500 again. Just to make it clear: Is this message an error, or a warning or just for information? Could you explain a bit please. Its a debugging message nowadays (NETDEBUG). I was mostly interested in this since I changed the IPsec MTU calculation in 2.6.22 and it might have been a bug. I have no connections hangs or other kind of problems. Thanks for clarifying this. I guess the reason why you're seeing them now and not before is that we're now always using the maximum room available, while previously packets were usually a bit smaller than possible. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, 2007-07-18 at 08:59 -0700, Eugene Surovegin wrote: On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote: On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote: On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. Would you be opposed to including that patch in mainline? Yes. I don't think it's the right way to fix this issue. IMO, the right one is to fix slab allocator. You cannot change all drivers to do this kind of cache flushing, and yes, I saw the same problem with PCI based NIC I tried on Ocotea at the time. Hm... good point. I'd still like to see if your patch works around the reporter's problem. josh - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] netlink: allocate group bitmaps dynamically
Johannes Berg wrote: Allow changing the number of groups for a netlink family after it has been created, use RCU to protect the listeners bitmap keeping netlink_has_listeners() lock-free. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- Changes: incorporate Patrick's comments, add kernel-doc All three patches look good to me. Acked-by: Patrick McHardy [EMAIL PROTECTED] and for Jamal again .. Acked-by: Jamal Hadi Salim [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mac80211: fix GCC warning on 64bit platforms
Jiri Benc wrote: If you think int is more appropriate, fine with me, I don't really care. No, I'm just trying to learn. Larry - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, 18 Jul 2007 08:59:40 -0700 Eugene Surovegin [EMAIL PROTECTED] wrote: On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote: On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote: On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. Would you be opposed to including that patch in mainline? Yes. I don't think it's the right way to fix this issue. IMO, the right one is to fix slab allocator. You cannot change all drivers to do this kind of cache flushing, and yes, I saw the same problem with PCI based NIC I tried on Ocotea at the time. hm. It should be the case that providing SLAB_HWCACHE_ALIGN at kmem_cache_create() time will override slab-debugging's offsetting of the returned addresses. Or is the problem occurring with memory which is returned from kmalloc(), rather than from kmem_cache_alloc()? A complete description of the problem would help here, please. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mac80211: fix GCC warning on 64bit platforms
On Wed, 2007-07-18 at 17:10 +0200, Jiri Benc wrote: net/mac80211/ieee80211.c: In function ieee80211_register_hw: net/mac80211/ieee80211.c:4989: warning: comparison of distinct pointer types lacks a cast Size of ieee80211_tx_status_rtap_hdr structure will never be greater than unsigned int. Thanks Jiri, just noticed that it was actually my bug. johannes signature.asc Description: This is a digitally signed message part
Re: [Bugme-new] [Bug 8778] New: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y
On Wed, Jul 18, 2007 at 09:55:37AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 08:59:40 -0700 Eugene Surovegin [EMAIL PROTECTED] wrote: On Wed, Jul 18, 2007 at 08:41:10AM -0500, Josh Boyer wrote: On Wed, 2007-07-18 at 01:34 -0700, Eugene Surovegin wrote: On Wed, Jul 18, 2007 at 12:52:53AM -0700, Andrew Morton wrote: On Wed, 18 Jul 2007 00:07:50 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8778 Summary: Ocotea board: kernel reports access of bad area during boot with DEBUG_SLAB=y Slab debugging is probably the culprit here. I had similar problem couple of years ago, not sure something has changed since then, haven't checked. When slab debugging was enabled it made memory allocations non L1 cache line aligned. This is very bad for DMA on non-coherent cache arches (PPC440 is one of those archs). I have a hack for EMAC which tries to workaround this problem: http://kernel.ebshome.net/emac_slab_debug.diff which might help. Would you be opposed to including that patch in mainline? Yes. I don't think it's the right way to fix this issue. IMO, the right one is to fix slab allocator. You cannot change all drivers to do this kind of cache flushing, and yes, I saw the same problem with PCI based NIC I tried on Ocotea at the time. hm. It should be the case that providing SLAB_HWCACHE_ALIGN at kmem_cache_create() time will override slab-debugging's offsetting of the returned addresses. Or is the problem occurring with memory which is returned from kmalloc(), rather than from kmem_cache_alloc()? It's kmalloc, at least this is how I think skbs are allocated. Andrew, I don't have access to PPC hw right now (doing MIPS development these days), so I cannot quickly check that my theory is still correct for the latest kernel. I'd wait for the reporter to try my hack and then we can decide what to do. IIRC there was some provision in slab allocator to enforce alignment, when I was debugging this problem more then a year ago, that option didn't work. BTW, I think slob allocator had the same issue with alignment as slab with enabled debugging (at least at the time I looked at it). -- Eugene - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Socket Buffers and Memory Managment
Stephen Hemminger wrote: You could play tricks with skb frags but it would be fragile and not worth the trouble. The problem is that the receive skb can stay in the system for a really long time (until the application reads the data) so your fixed size buffer pool in hardware would get exhausted. Perhaps you could elaborate on why this is considered fragile? It seems to me that as long as proper page management is performed, this mechanism should be stable for processing non-contiguous receive buffers. I agree that replenishment needs to be addressed, but I see that as an independent issue from using frag lists on receive. Also, if the h/w gives me a single packet in multiple locations (i.e. non-contiguous chunks of memory), can socket buffers handle chains of buffers? I am looking for a facility like mbuf's in netbsd where one can chain multiple buffers together to make construct a single packet. Yes, skb frag list could be used for that but you don't want to do that. See above. Copy the data into an new skb and reserve any necessary bytes so IP header is aligned. I.e. if using ethernet header (14 bytes), do skb_reserve(skb, 2) before copying the data. But isn't avoiding the copy the point of all this? With some hardware models using skbs as receive buffers is inconvenient and can be wasteful if jumbo frames are required. Wouldn't a mechanism where it is possible to create (or populate) an skb from data in a pre existing buffer without copying be more general and address more hardware models? It seems to me that more and more hardware is supporting scatter/gather output for received data, but the page* model in the frag list can be restrictive in how data is placed before being passed into the stack. Thanks Roy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pmtu discovery on SA
Patrick McHardy wrote: Beschorner Daniel wrote: Beschorner Daniel wrote: So its using 1492 now? Otherwise it would be expected since the initial MTU calculation would be based on 1500. I'm using 1500 again. Just to make it clear: Is this message an error, or a warning or just for information? Could you explain a bit please. Its a debugging message nowadays (NETDEBUG). I was mostly interested in this since I changed the IPsec MTU calculation in 2.6.22 and it might have been a bug. And we don't have pmtu discovery for esp yet, right? --Mika - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pmtu discovery on SA
Mika Penttilä wrote: Patrick McHardy wrote: Its a debugging message nowadays (NETDEBUG). I was mostly interested in this since I changed the IPsec MTU calculation in 2.6.22 and it might have been a bug. And we don't have pmtu discovery for esp yet, right? We do. The best I have seen to date in any IPsec implementation :) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pmtu discovery on SA
Patrick McHardy wrote: Mika Penttilä wrote: Patrick McHardy wrote: Its a debugging message nowadays (NETDEBUG). I was mostly interested in this since I changed the IPsec MTU calculation in 2.6.22 and it might have been a bug. And we don't have pmtu discovery for esp yet, right? We do. The best I have seen to date in any IPsec implementation :) - 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 Hmm. esp4_err() looks like this : struct iphdr *iph = (struct iphdr*)skb-data; struct ip_esp_hdr *esph = (struct ip_esp_hdr*)(skb-data+(iph-ihl2)); struct xfrm_state *x; if (icmp_hdr(skb)-type != ICMP_DEST_UNREACH || icmp_hdr(skb)-code != ICMP_FRAG_NEEDED) return; x = xfrm_state_lookup((xfrm_address_t *)iph-daddr, esph-spi, IPPROTO_ESP, AF_INET); if (!x) return; NETDEBUG(KERN_DEBUG pmtu discovery on SA ESP/%08x/%08x\n, ntohl(esph-spi), ntohl(iph-daddr)); xfrm_state_put(x); where could pmtu discovery be happening? --Mika - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pmtu discovery on SA
Mika Penttilä wrote: Hmm. esp4_err() looks like this : struct iphdr *iph = (struct iphdr*)skb-data; struct ip_esp_hdr *esph = (struct ip_esp_hdr*)(skb-data+(iph-ihl2)); struct xfrm_state *x; if (icmp_hdr(skb)-type != ICMP_DEST_UNREACH || icmp_hdr(skb)-code != ICMP_FRAG_NEEDED) return; x = xfrm_state_lookup((xfrm_address_t *)iph-daddr, esph-spi, IPPROTO_ESP, AF_INET); if (!x) return; NETDEBUG(KERN_DEBUG pmtu discovery on SA ESP/%08x/%08x\n, ntohl(esph-spi), ntohl(iph-daddr)); xfrm_state_put(x); where could pmtu discovery be happening? xfrm_init_pmtu, xfrm_bundle_ok, xfrm_state_mtu, esp4_get_mtu, ... - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pmtu discovery on SA
Patrick McHardy wrote: Mika Penttilä wrote: Hmm. esp4_err() looks like this : struct iphdr *iph = (struct iphdr*)skb-data; struct ip_esp_hdr *esph = (struct ip_esp_hdr*)(skb-data+(iph-ihl2)); struct xfrm_state *x; if (icmp_hdr(skb)-type != ICMP_DEST_UNREACH || icmp_hdr(skb)-code != ICMP_FRAG_NEEDED) return; x = xfrm_state_lookup((xfrm_address_t *)iph-daddr, esph-spi, IPPROTO_ESP, AF_INET); if (!x) return; NETDEBUG(KERN_DEBUG pmtu discovery on SA ESP/%08x/%08x\n, ntohl(esph-spi), ntohl(iph-daddr)); xfrm_state_put(x); where could pmtu discovery be happening? xfrm_init_pmtu, xfrm_bundle_ok, xfrm_state_mtu, esp4_get_mtu, ... Okay yes but for instance the current tcp session isn't recovering from from esp4_err() ? The next connect attempt uses the new pmtu? --Mika - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Fix error checking in Vitesse IRQ config
On Jul 18, 2007, at 02:00, pradeep singh wrote: On 7/18/07, Andy Fleming [EMAIL PROTECTED] wrote: - if (err) + if (err 0) return err; but would that mean, if phy_read returns 0 it is a success? Yes. phy_read() returns a 32-bit value. If there's an error, it returns a negative number. If not, it returns whatever was in the register (which is only 16 bits) phy_write() returns 0 on success, and non-zero, otherwise. In hindsight, it would have been better to be consistent. Andy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stalled connection (need help to debug)
Hallo. I have a very strange problem. [] Any advise on how to debug this will be very appreciated. Thanks. Thanks... - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Gabriel C wrote: Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus. rather than add all that extraneous dreck to the Kconfig files, i *really* wish folks would give serious thought to my earlier suggestion about a maturity level attribute that could be used to not only add a parenthesized maturity level during display, but could also be used to activate/deactivate entire levels in one operation. there's no point adding all that redundant content when it can all be done automatically. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus. Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED] --- drivers/net/irda/Kconfig | 14 +++--- drivers/net/usb/Kconfig |4 ++-- drivers/net/wireless/Kconfig |8 drivers/net/wireless/bcm43xx/Kconfig |2 +- drivers/net/wireless/zd1211rw/Kconfig |2 +- net/9p/Kconfig|2 +- net/Kconfig |2 +- net/decnet/netfilter/Kconfig |2 +- net/ieee80211/softmac/Kconfig |2 +- net/ipv4/Kconfig | 16 net/ipv6/Kconfig |2 +- net/ipv6/netfilter/Kconfig|2 +- net/mac80211/Kconfig |2 +- net/rxrpc/Kconfig |2 +- net/wanrouter/Kconfig |2 +- 15 files changed, 32 insertions(+), 32 deletions(-) diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig index 829da9a..87285a1 100644 --- a/drivers/net/irda/Kconfig +++ b/drivers/net/irda/Kconfig @@ -84,7 +84,7 @@ config LITELINK_DONGLE irattach -d litelink. config MA600_DONGLE - tristate Mobile Action MA600 dongle + tristate Mobile Action MA600 dongle (EXPERIMENTAL) depends on IRTTY_SIR DONGLE IRDA EXPERIMENTAL help Say Y here if you want to build support for the Mobile Action MA600 @@ -97,7 +97,7 @@ config MA600_DONGLE irattach -d ma600. config GIRBIL_DONGLE - tristate Greenwich GIrBIL dongle + tristate Greenwich GIrBIL dongle (EXPERIMENTAL) depends on IRTTY_SIR DONGLE IRDA EXPERIMENTAL help Say Y here if you want to build support for the Greenwich GIrBIL @@ -108,7 +108,7 @@ config GIRBIL_DONGLE like this: irattach -d girbil. config MCP2120_DONGLE - tristate Microchip MCP2120 + tristate Microchip MCP2120 (EXPERIMENTAL) depends on IRTTY_SIR DONGLE IRDA EXPERIMENTAL help Say Y here if you want to build support for the Microchip MCP2120 @@ -122,7 +122,7 @@ config MCP2120_DONGLE http://www.eyetap.org/~tangf/irda_sir_linux.html config OLD_BELKIN_DONGLE - tristate Old Belkin dongle + tristate Old Belkin dongle (EXPERIMENTAL) depends on IRTTY_SIR DONGLE IRDA EXPERIMENTAL help Say Y here if you want to build support for the Adaptec Airport 1000 @@ -131,7 +131,7 @@ config OLD_BELKIN_DONGLE at the top of file:drivers/net/irda/old_belkin.c. config ACT200L_DONGLE - tristate ACTiSYS IR-200L dongle + tristate ACTiSYS IR-200L dongle (EXPERIMENTAL) depends on IRTTY_SIR DONGLE IRDA EXPERIMENTAL help Say Y here if you want to build support for the ACTiSYS IR-200L @@ -142,7 +142,7 @@ config ACT200L_DONGLE start irattach like this: irattach -d act200l. config KINGSUN_DONGLE - tristate KingSun/DonShine DS-620 IrDA-USB dongle + tristate KingSun/DonShine DS-620 IrDA-USB dongle (EXPERIMENTAL) depends on IRDA USB EXPERIMENTAL help Say Y or M here if you want to build support for the KingSun/DonShine @@ -433,7 +433,7 @@ config PXA_FICP another. config MCS_FIR - tristate MosChip MCS7780 IrDA-USB dongle + tristate MosChip MCS7780 IrDA-USB dongle (EXPERIMENTAL) depends on IRDA USB EXPERIMENTAL help Say Y or M here if you want to build support for the MosChip diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index 8dc09a3..387ae30 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -214,7 +214,7 @@ config USB_NET_NET1080 optionally with LEDs that indicate traffic config USB_NET_PLUSB - tristate Prolific PL-2301/2302 based cables + tristate Prolific PL-2301/2302 based cables (EXPERIMENTAL) # if the handshake/init/reset problems, from original 'plusb', # are ever resolved ... then remove experimental depends on USB_USBNET EXPERIMENTAL @@ -310,7 +310,7 @@ config USB_EPSON2888 by some sample firmware from Epson. config USB_KC2190 - boolean KT Technology KC2190 based cables (InstaNet) + boolean KT Technology KC2190 based cables (InstaNet) (EXPERIMENTAL) depends on USB_NET_CDC_SUBSET EXPERIMENTAL help Choose this option if you're using a host-to-host cable diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig index ae27af0..636a370 100644 --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -250,7 +250,7 @@ config IPW2200_PROMISCUOUS % echo 1 /sys/bus/pci/drivers/ipw2200/*/rtap_iface config IPW2200_QOS -bool Enable QoS support +bool Enable QoS support (EXPERIMENTAL) depends on IPW2200 EXPERIMENTAL config IPW2200_DEBUG @@ -473,7 +473,7 @@
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: On Wed, 18 Jul 2007, Gabriel C wrote: Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus. rather than add all that extraneous dreck to the Kconfig files, i *really* wish folks would give serious thought to my earlier suggestion about a maturity level attribute that could be used to not only add a parenthesized maturity level during display, but could also be used to activate/deactivate entire levels in one operation. there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
Randy Dunlap wrote: On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? Speaking specifically to adding 'EXPERIMENTAL', I distinctly remember at some point in the past the config system was smart enough to print (EXPERIMENTAL) if that entry depended on CONFIG_EXPERIMENTAL. We should head in that direction. I strongly NAK the original patch from Gabriel C in this thread -- it just adds too much redundant info. Better to add it -once-, somewhere inside Kconfig system. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Randy Dunlap wrote: On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: On Wed, 18 Jul 2007, Gabriel C wrote: Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus. rather than add all that extraneous dreck to the Kconfig files, i *really* wish folks would give serious thought to my earlier suggestion about a maturity level attribute that could be used to not only add a parenthesized maturity level during display, but could also be used to activate/deactivate entire levels in one operation. there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? once upon a time, i'd proposed just adding a couple new config entries, but i eventually decided that a better approach would be to define a whole new Kconfig directive, as in: config FUBAR maturity EXPERIMENTAL (or DEPRECATED or OBSOLETE or ...) that would require extra processing in the parser, but it would allow the maturity attribute to be used for all sorts of new and wacky things, such as automatically displaying it at the end of a config selection, or deselecting everything OBSOLETE in a build, etc. how hard would it be to add processing like that to the Kconfig infrastructure? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
Robert P. J. Day wrote: On Wed, 18 Jul 2007, Gabriel C wrote: Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus. rather than add all that extraneous dreck to the Kconfig files, i *really* wish folks would give serious thought to my earlier suggestion about a maturity level attribute that could be used to not only add a parenthesized maturity level during display, but could also be used to activate/deactivate entire levels in one operation. there's no point adding all that redundant content when it can all be done automatically. I don't know what your suggestion was , I'm sorry. It may be for sure a good idea to add all this maturity levels automatically but for now such an thing does not exists. rday Gabriel - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
Jeff Garzik wrote: Randy Dunlap wrote: On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? Speaking specifically to adding 'EXPERIMENTAL', I distinctly remember at some point in the past the config system was smart enough to print (EXPERIMENTAL) if that entry depended on CONFIG_EXPERIMENTAL. We should head in that direction. I strongly NAK the original patch from Gabriel C in this thread -- it just adds too much redundant info. Better to add it -once-, somewhere inside Kconfig system. Jeff Yes, that's what Robert I are referring to as well (AFAIK). -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Jeff Garzik wrote: Randy Dunlap wrote: On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? Speaking specifically to adding 'EXPERIMENTAL', I distinctly remember at some point in the past the config system was smart enough to print (EXPERIMENTAL) if that entry depended on CONFIG_EXPERIMENTAL. We should head in that direction. there's one point i want to re-iterate. i'd prefer to see EXPERIMENTAL stop being a dependency, as in: depends on SNAFU FUBAR EXPERIMENTAL EXPERIMENTAL is not a dependency in the true sense of the word -- it is more of an attribute, and i think it would far more sense to see entries like: depends on SNAFU FUBAR maturity EXPERIMENTAL sure, it's more work, but i think the cost is worth it in terms of flexibility (particularly if *i'm* not the one doing the work. :-) rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, Jul 18, 2007 at 04:51:33PM -0400, Robert P. J. Day wrote: On Wed, 18 Jul 2007, Jeff Garzik wrote: Randy Dunlap wrote: On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? Speaking specifically to adding 'EXPERIMENTAL', I distinctly remember at some point in the past the config system was smart enough to print (EXPERIMENTAL) if that entry depended on CONFIG_EXPERIMENTAL. We should head in that direction. there's one point i want to re-iterate. i'd prefer to see EXPERIMENTAL stop being a dependency, as in: depends on SNAFU FUBAR EXPERIMENTAL EXPERIMENTAL is not a dependency in the true sense of the word -- it is more of an attribute, and i think it would far more sense to see entries like: depends on SNAFU FUBAR maturity EXPERIMENTAL Plus some special case in the kconfig code that you can somewhere select the maturity levels you want to use (currently it's a normal option kconfig doesn't have to know anything about). Remind me, would there be any big advantage after such a change besides being able to automatically print (EXPERIMENTAL) at the end of the prompt? sure, it's more work, but i think the cost is worth it in terms of flexibility (particularly if *i'm* not the one doing the work. :-) If you are not doing it, noone might do it. And discusing improvements noone will implement is somehow pointless... rday cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Adrian Bunk wrote: On Wed, Jul 18, 2007 at 04:51:33PM -0400, Robert P. J. Day wrote: On Wed, 18 Jul 2007, Jeff Garzik wrote: Randy Dunlap wrote: On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote: there's no point adding all that redundant content when it can all be done automatically. I like it. Are there any kconfig patches to support this plan? Speaking specifically to adding 'EXPERIMENTAL', I distinctly remember at some point in the past the config system was smart enough to print (EXPERIMENTAL) if that entry depended on CONFIG_EXPERIMENTAL. We should head in that direction. there's one point i want to re-iterate. i'd prefer to see EXPERIMENTAL stop being a dependency, as in: depends on SNAFU FUBAR EXPERIMENTAL EXPERIMENTAL is not a dependency in the true sense of the word -- it is more of an attribute, and i think it would far more sense to see entries like: depends on SNAFU FUBAR maturity EXPERIMENTAL Plus some special case in the kconfig code that you can somewhere select the maturity levels you want to use (currently it's a normal option kconfig doesn't have to know anything about). i already described that here: http://readlist.com/lists/vger.kernel.org/linux-kernel/66/334172.html where the top-level config would look something like: [*] Activate maturity attributes [*] EXPERIMENTAL [*] DEPRECATED [*] OBSOLETE [*] BROKEN whereupon you could select any combination of the attributes you want displayed *beyond the regular ones* during the config process. Remind me, would there be any big advantage after such a change besides being able to automatically print (EXPERIMENTAL) at the end of the prompt? defining a new Kconfig attribute means you can process it differently from regular dependencies. and if it's added as a general feature, it can be used for other possible attributes beyond just a maturity level. if you leave these maturity levels as regular dependencies, you're going to have to brute force and manually process them, and why make it that ugly? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Socket Buffers and Memory Managment
On Wed, 18 Jul 2007 13:13:21 -0400 Roy Pledge [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: You could play tricks with skb frags but it would be fragile and not worth the trouble. The problem is that the receive skb can stay in the system for a really long time (until the application reads the data) so your fixed size buffer pool in hardware would get exhausted. Perhaps you could elaborate on why this is considered fragile? It seems to me that as long as proper page management is performed, this mechanism should be stable for processing non-contiguous receive buffers. I agree that replenishment needs to be addressed, but I see that as an independent issue from using frag lists on receive. Imagine you had a 4MB receive area. If you used fraglist to point to the data area, you would still be at risk of receive lock up when you have all the receive area used up in skb's waiting in the receive queue of the sockets. You might get it to work if the receive are was very large (ie much larger than tcp_rmem), but at that point you might as well as be able to access all of system memory. Using a DMA I/O engine would help, but you probably won't have one available. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Realtek RTL8111B serious performance issues
On Wed, 18 Jul 2007, Francois Romieu wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] : [...] Anyone have any suggestions for solving this problem? Try 2.6.23-rc1 when it is published or apply against 2.6.22 one of: http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch Unfortunately, the 20070628 patch did not make any difference. http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/ I tried various patches from that directory (aren't most or all of them included in the 20070628 patch?), but none of them helped either. This problem could be very difficult to track down. Like I said, it definately effects emacs and firefox being drawn on a remote computer. Ping times, however, are not that bad: PING 192.168.26.150: 56 data bytes 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=0. time=0.287 ms 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=1. time=0.279 ms 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=2. time=0.196 ms 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=3. time=0.201 ms 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=4. time=0.159 ms 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=5. time=0.148 ms 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=6. time=0.150 ms Also, wget gets good throughput when retrieving files. It just seems to be X traffic which is extremely slow. Using the old Linksys 10/100 PCI NIC, emacs comes up virtually instantaneously. Using the integrated Realtek 8111B, emacs takes 10 seconds to draw. Thank you very much for trying to help. 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
Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
On Wed, 18 Jul 2007, Adrian Bunk wrote: If you are not doing it, noone might do it. And discusing improvements noone will implement is somehow pointless... sure, i'm willing to help, but i don't think doing *nothing* about it is an option. you may not like gabriel's proposed patch, but you have to admit that he has a valid objection that should be addressed. so you can address it the manual and brute force way, or you can invest a little more time and do it right. but, either way, i think you have to deal with it. now it's just time to make a choice. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Realtek RTL8111B serious performance issues
[EMAIL PROTECTED] [EMAIL PROTECTED] : [...] Unfortunately, the 20070628 patch did not make any difference. @!#$ [...] http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/ I tried various patches from that directory (aren't most or all of them included in the 20070628 patch?), but none of them helped either. The patches from the directory should be applied on top of each other. When they are all applied, you get the 20070628 patch. You are not supposed to apply them in random order (there is some margin of course). [...] This problem could be very difficult to track down. Like I said, it definately effects emacs and firefox being drawn on a remote computer. Ping times, however, are not that bad: PING 192.168.26.150: 56 data bytes 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=0. time=0.287 ms [...] 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=6. time=0.150 ms It looks quite fine. Also, wget gets good throughput when retrieving files. It just seems to be X traffic which is extremely slow. Using the old Linksys 10/100 PCI NIC, emacs comes up virtually instantaneously. Using the integrated Realtek 8111B, emacs takes 10 seconds to draw. Can you take a tethereal -w log.pcap for both cards with the command 'ping -c 4 $someplace emacs' and publish the log.pcap files ? -- Ueimor - 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
updated tcatm patches for kernel/iproute 2.6.22
I got tired of getting 15% packet loss [1] when doing
lots of DNS lookups on my ADSL link...
And that was even when limiting outgoing DNS traffic
to 200 Kbit/s (ADSL modem upstream speed is 512 Kbit/s).
I had used tcatm patch with 2.6.16 kernel and I was
happy with it.
Now I patched Linux kernel 2.6.22 and iproute-2.6.22
for tcatm. Seems to work (TM). Only HTB tested.
Now I get 0% packet loss when doing lots of DNS queries
(270pps) and DNS traffic is limited with
HTB/ESFQ to 504Kbit/s. I used tc class add ... atm overhead 20
but I am not sure is it really 20 (Sonera in Finland).
Without tcatm I had to have there 420Kbit and it still sucked.
I keep patches at
http://safari.iki.fi/tcatm/
I read one thread from this year where there were objections
about tcatm's some parts and then discussion petered out...
I and probably Russell Stuart would probably like to get
these patches fixed so that everyone is pleased
and these can be incorporated into kernel some year,
because I believe ADSL is very popular nowadays ( =) )
and people would probably like if traffic control was
actually usable for them ( =) )...
[1] ping -A 80.223.96.1
--
Do what you love because life is too short for anything else.
#
# include/linux/pkt_sched.h |5 +++--
# include/net/sch_generic.h | 15 +++
# net/sched/act_police.c|4 ++--
# net/sched/sch_cbq.c |2 +-
# net/sched/sch_htb.c |9 -
# net/sched/sch_tbf.c |4 ++--
# 6 files changed, 27 insertions(+), 12 deletions(-)
#
--- linux-2.6.22/include/linux/pkt_sched.h.bak 2007-07-09 21:58:23.559346000
+0300
+++ linux-2.6.22/include/linux/pkt_sched.h 2007-07-18 21:46:00.084770053
+0300
@@ -77,8 +77,9 @@ struct tc_ratespec
{
unsigned char cell_log;
unsigned char __reserved;
- unsigned short feature;
- short addend;
+ unsigned short feature;/* Always 0 in pre-atm patch kernels */
+ charcell_align; /* Always 0 in pre-atm patch kernels */
+ unsigned char __reserved2;
unsigned short mpu;
__u32 rate;
};
--- linux-2.6.22/include/net/sch_generic.h.bak 2007-07-09 02:32:17.0
+0300
+++ linux-2.6.22/include/net/sch_generic.h 2007-07-18 21:44:40.024580754
+0300
@@ -302,4 +302,19 @@ drop:
return NET_XMIT_DROP;
}
+/* Lookup a qdisc_rate_table to determine how long it will take to send a
+ * packet given its size.
+ */
+static inline u32 qdisc_l2t(struct qdisc_rate_table* rtab, int pktlen)
+{
+ int slot = pktlen + rtab-rate.cell_align;
+
+ if (slot 0)
+ slot = 0;
+ slot = rtab-rate.cell_log;
+ if (slot 255)
+ return rtab-data[255] + 1;
+ return rtab-data[slot];
+}
+
#endif
--- linux-2.6.22/net/sched/act_police.c.bak 2007-07-09 02:32:17.0
+0300
+++ linux-2.6.22/net/sched/act_police.c 2007-07-18 21:42:49.275936447 +0300
@@ -32,8 +32,8 @@
#include net/act_api.h
#include net/netlink.h
-#define L2T(p,L) ((p)-tcfp_R_tab-data[(L)(p)-tcfp_R_tab-rate.cell_log])
-#define L2T_P(p,L) ((p)-tcfp_P_tab-data[(L)(p)-tcfp_P_tab-rate.cell_log])
+#define L2T(p,L) qdisc_l2t((p)-tcfp_R_tab,L)
+#define L2T_P(p,L) qdisc_l2t((p)-tcfp_P_tab,L)
#define POL_TAB_MASK 15
static struct tcf_common *tcf_police_ht[POL_TAB_MASK + 1];
--- linux-2.6.22/net/sched/sch_cbq.c.bak2007-07-09 02:32:17.0
+0300
+++ linux-2.6.22/net/sched/sch_cbq.c2007-07-18 21:51:12.794420373 +0300
@@ -192,7 +192,7 @@ struct cbq_sched_data
};
-#define L2T(cl,len)((cl)-R_tab-data[(len)(cl)-R_tab-rate.cell_log])
+#define L2T(cl,len)qdisc_l2t((cl)-R_tab,len)
static __inline__ unsigned cbq_hash(u32 h)
--- linux-2.6.22/net/sched/sch_htb.c.bak2007-07-09 21:17:53.417438000
+0300
+++ linux-2.6.22/net/sched/sch_htb.c2007-07-18 21:50:08.602465126 +0300
@@ -157,12 +157,11 @@ struct htb_class {
static inline long L2T(struct htb_class *cl, struct qdisc_rate_table *rate,
int size)
{
- int slot = size rate-rate.cell_log;
- if (slot 255) {
+ long result = qdisc_l2t(rate, size);
+
+ if (result rate-data[255])
cl-xstats.giants++;
- slot = 255;
- }
- return rate-data[slot];
+ return result;
}
struct htb_sched {
--- linux-2.6.22/net/sched/sch_tbf.c.bak2007-07-09 02:32:17.0
+0300
+++ linux-2.6.22/net/sched/sch_tbf.c2007-07-18 21:52:10.665281840 +0300
@@ -132,8 +132,8 @@ struct tbf_sched_data
struct qdisc_watchdog watchdog; /* Watchdog timer */
};
-#define L2T(q,L) ((q)-R_tab-data[(L)(q)-R_tab-rate.cell_log])
-#define L2T_P(q,L) ((q)-P_tab-data[(L)(q)-P_tab-rate.cell_log])
+#define L2T(q,L) qdisc_l2t((q)-R_tab,L)
+#define L2T_P(q,L) qdisc_l2t((q)-P_tab,L)
static int tbf_enqueue(struct sk_buff *skb, struct Qdisc* sch)
{
#
# include/linux/pkt_sched.h |5 +-
# tc/m_police.c
Re: [PATCH] Add a network activity LED trigger
From: Patrick McHardy [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 15:54:56 +0200 Florian Fainelli wrote: Besides missing a declaration and not linking without the network LED config option, its pretty ridiculous to call this for every packet just to make a led blink. Could you suggest me a better way to do so ? The code was highly inspired from what is done with the IDE trigger. The declaration is done in linux/leds.h, which is included in dev.c for that purpose. Maybe just increment a variable and periodically check it or something like that. Yes please, calling this millions of times per second on a high end router is just not smart. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] lro: Generic Large Receive Offload for TCP traffic (IPv6)
From: Jan-Bernd Themann [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 15:00:59 +0200 Hi, I suggest we keep the interface open for IPv6 support by adding an additional parameter but first just get IPv4 support only into the kernel. IPv6 support can then incrementially be added. Would that be ok? I guess so. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mac80211: fix GCC warning on 64bit platforms
From: Jiri Benc [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 17:10:44 +0200 - local-tx_headroom = max(local-hw.extra_tx_headroom, - sizeof(struct ieee80211_tx_status_rtap_hdr)); + local-tx_headroom = max_t(unsigned, local-hw.extra_tx_headroom, +sizeof(struct ieee80211_tx_status_rtap_hdr)); Please spell out the complete type, unsigned int. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'upstream-jgarzik' branch of wireless-2.6
John W. Linville wrote: A few more for 2.6.23... Thanks! John --- The following changes since commit 4ad1366376bfef32ec0ffa12d1faa483d6f330bd: NeilBrown (1): md: change bitmap_unplug and others to void functions are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-jgarzik Daniel Drake (1): zd1211rw: Add ID for Siemens Gigaset USB Stick 54 Jean Tourrilhes (1): softmac: Channel is listed twice in scan output Masakazu Mokuno (1): zd1211rw: Add ID for Planex GW-US54GXS Zhu Yi (4): ipw2100: Fix `iwpriv set_power` error Fix ipw2200 set wrong power parameter causing firmware error ipw2200: Fix ipw_isr() comments error on shared IRQ Update version ipw2200 stamp to 1.2.2 drivers/net/wireless/ipw2100.c |6 +++--- drivers/net/wireless/ipw2200.c | 18 -- drivers/net/wireless/zd1211rw/zd_usb.c |2 ++ net/ieee80211/ieee80211_wx.c |7 ++- 4 files changed, 15 insertions(+), 18 deletions(-) pulled - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'upstream-davem' branch of wireless-2.6
From: John W. Linville [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 11:34:49 -0400 On Tue, Jul 17, 2007 at 08:17:16PM -0700, David Miller wrote: From: John W. Linville [EMAIL PROTECTED] Date: Tue, 17 Jul 2007 22:16:07 -0400 A few more for 2.6.23...individual patches available here: http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem What about this warning which I reported to you right after the last merge? Did this get fixed? net/mac80211/ieee80211.c:4989: warning: comparison of distinct pointer types lacks a cast Please fix that up first, then I'll pull from your tree. Fair enough! :-) As I pointed out to Jiri, you need to spell out the complete type warning fix, rather than just unsigned. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ibmveth: Enable TCP checksum offload
Brian King wrote:
This patchset enables TCP checksum offload support for IPV4
on ibmveth. This completely eliminates the generation and checking of
the checksum for packets that are completely virtual and never
touch a physical network. A simple TCP_STREAM netperf run on
a virtual network with maximum mtu set yielded a ~30% increase
in throughput. This feature is enabled by default on systems that
support it, but can be disabled with a module option.
Signed-off-by: Brian King [EMAIL PROTECTED]
this should be controllable purely via ethtool...
diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload2007-07-12
08:27:47.0 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-12 09:35:55.0
-0500
@@ -47,6 +47,8 @@
#include linux/mm.h
#include linux/ethtool.h
#include linux/proc_fs.h
+#include linux/in.h
+#include linux/ip.h
#include asm/semaphore.h
#include asm/hvcall.h
#include asm/atomic.h
@@ -103,12 +105,15 @@ static struct proc_dir_entry *ibmveth_pr
static const char ibmveth_driver_name[] = ibmveth;
static const char ibmveth_driver_string[] = IBM i/pSeries Virtual Ethernet
Driver;
+static unsigned int ibmveth_csum_offload = 1;
#define ibmveth_driver_version 1.03
MODULE_AUTHOR(Santiago Leon [EMAIL PROTECTED]);
MODULE_DESCRIPTION(IBM i/pSeries Virtual Ethernet Driver);
MODULE_LICENSE(GPL);
MODULE_VERSION(ibmveth_driver_version);
+module_param_named(csum_offload, ibmveth_csum_offload, uint, 0);
+MODULE_PARM_DESC(csum_offload, Checksum offload (0/1). Default: 1);
/* simple methods of getting data from the current rxq entry */
static inline int ibmveth_rxq_pending_buffer(struct ibmveth_adapter *adapter)
@@ -131,6 +136,11 @@ static inline int ibmveth_rxq_frame_leng
return (adapter-rx_queue.queue_addr[adapter-rx_queue.index].length);
}
+static inline int ibmveth_rxq_csum_good(struct ibmveth_adapter *adapter)
+{
+ return
(adapter-rx_queue.queue_addr[adapter-rx_queue.index].csum_good);
+}
+
/* setup the initial settings for a buffer pool */
static void ibmveth_init_buffer_pool(struct ibmveth_buff_pool *pool, u32
pool_index, u32 pool_size, u32 buff_size, u32 pool_active)
{
@@ -684,6 +694,24 @@ static int ibmveth_start_xmit(struct sk_
desc[0].fields.length, DMA_TO_DEVICE);
desc[0].fields.valid = 1;
+ if (skb-ip_summed == CHECKSUM_PARTIAL
+ ip_hdr(skb)-protocol != IPPROTO_TCP skb_checksum_help(skb)) {
+ ibmveth_error_printk(tx: failed to checksum packet\n);
+ tx_dropped++;
+ goto out;
+ }
+
+ if (skb-ip_summed == CHECKSUM_PARTIAL) {
+ unsigned char *buf = skb_transport_header(skb) +
skb-csum_offset;
+
+ desc[0].fields.no_csum = 1;
+ desc[0].fields.csum_good = 1;
+
+ /* Need to zero out the checksum */
+ buf[0] = 0;
+ buf[1] = 0;
+ }
+
if(dma_mapping_error(desc[0].fields.address)) {
ibmveth_error_printk(tx: unable to map initial fragment\n);
tx_map_failed++;
@@ -702,6 +730,10 @@ static int ibmveth_start_xmit(struct sk_
frag-size, DMA_TO_DEVICE);
desc[curfrag+1].fields.length = frag-size;
desc[curfrag+1].fields.valid = 1;
+ if (skb-ip_summed == CHECKSUM_PARTIAL) {
+ desc[curfrag+1].fields.no_csum = 1;
+ desc[curfrag+1].fields.csum_good = 1;
+ }
if(dma_mapping_error(desc[curfrag+1].fields.address)) {
ibmveth_error_printk(tx: unable to map fragment %d\n,
curfrag);
@@ -792,7 +824,11 @@ static int ibmveth_poll(struct net_devic
} else {
int length = ibmveth_rxq_frame_length(adapter);
int offset = ibmveth_rxq_frame_offset(adapter);
+ int csum_good = ibmveth_rxq_csum_good(adapter);
+
skb = ibmveth_rxq_get_buffer(adapter);
+ if (csum_good)
+ skb-ip_summed = CHECKSUM_UNNECESSARY;
ibmveth_rxq_harvest_buffer(adapter);
@@ -962,8 +998,10 @@ static void ibmveth_poll_controller(stru
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct
vio_device_id *id)
{
int rc, i;
+ long ret;
struct net_device *netdev;
struct ibmveth_adapter *adapter = NULL;
+ union ibmveth_illan_attributes set_attr, ret_attr;
unsigned char *mac_addr_p;
unsigned int *mcastFilterSize_p;
@@ -1058,6 +1096,26 @@ static int __devinit ibmveth_probe(struc
ibmveth_debug_printk(registering netdev...\n);
+ if (ibmveth_csum_offload) {
+ ret = h_illan_attributes(dev-unit_address, 0, 0,
Re: [PATCH 2/4] ibmveth: Implement ethtool hooks to enable/disable checksum offload
Brian King wrote: This patch adds the appropriate ethtool hooks to allow for enabling/disabling of hypervisor assisted checksum offload for TCP. Signed-off-by: Brian King [EMAIL PROTECTED] --- linux-2.6-bjking1/drivers/net/ibmveth.c | 120 +++- linux-2.6-bjking1/drivers/net/ibmveth.h |1 2 files changed, 119 insertions(+), 2 deletions(-) ACK. As noted in previous email, with this, module option is not needed - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] netlink: allocate group bitmaps dynamically
From: Patrick McHardy [EMAIL PROTECTED] Date: Wed, 18 Jul 2007 18:30:04 +0200 Johannes Berg wrote: Allow changing the number of groups for a netlink family after it has been created, use RCU to protect the listeners bitmap keeping netlink_has_listeners() lock-free. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- Changes: incorporate Patrick's comments, add kernel-doc All three patches look good to me. Acked-by: Patrick McHardy [EMAIL PROTECTED] and for Jamal again .. Acked-by: Jamal Hadi Salim [EMAIL PROTECTED] Aha, Johannes did resubmit all 3 patches, they arrived out of order here which confused me :-) I'll apply these, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ibmveth: Add ethtool driver stats hooks
Brian King wrote: Add ethtool hooks to ibmveth to retrieve driver statistics. ACK patches 3-4 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pktgen - define and use pktgen_dbg,err,warn,info
Similar usage to ndev_ and dev_ printk macros
Adds KERN_level indicators to all printks.
Correct a spelling error
Format u64 subtraction to %llu and (unsigned long long)
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index b92a322..5a94cfc 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -162,7 +162,10 @@
#include asm/div64.h /* do_div */
#include asm/timex.h
-#define VERSION pktgen v2.68: Packet Generator for packet performance
testing.\n
+#define PKTGEN_NAMEpktgen
+#define PKTGEN_VERSION v2.68
+#define PKTGEN_DESCPacket Generator for packet performance testing
+#define PKTGEN_FULLINFO PKTGEN_NAME PKTGEN_VERSION : PKTGEN_DESC .\n
/* The buckets are exponential in 'width' */
#define LAT_BUCKETS_MAX 32
@@ -370,6 +373,24 @@ struct pktgen_thread {
wait_queue_head_t queue;
};
+#define pktgen_printk(level, format, arg...) \
+ printk(level PKTGEN_NAME : format, ##arg)
+
+#ifdef DEBUG
+#define pktgen_dbg(format, arg...) pktgen_printk(KERN_DEBUG, format, ##arg)
+#else
+static inline int __attribute__ ((format (printf, 1, 2)))
+pktgen_dbg(const char *fmt, ...)
+{
+ return 0;
+}
+#endif
+
+#define pktgen_err(format, arg...) pktgen_printk(KERN_ERR, format, ##arg)
+#define pktgen_info(format, arg...) pktgen_printk(KERN_INFO, format, ##arg)
+#define pktgen_warn(format, arg...) pktgen_printk(KERN_WARNING, format, ##arg)
+#define pktgen_notice(format, arg...) pktgen_printk(KERN_NOTICE, format, ##arg)
+
#define REMOVE 1
#define FIND 0
@@ -441,7 +462,7 @@ static inline __u64 pg_div(__u64 n, __u32 base)
{
__u64 tmp = n;
do_div(tmp, base);
- /* printk(pktgen: pg_div, n: %llu base: %d rv: %llu\n,
+ /* pktgen_info(pg_div, n: %llu base: %d rv: %llu\n,
n, base, tmp); */
return tmp;
}
@@ -484,8 +505,6 @@ static inline __u64 tv_diff(const struct timeval *a, const
struct timeval *b)
/* old include end */
-static char version[] __initdata = VERSION;
-
static int pktgen_remove_device(struct pktgen_thread *t, struct pktgen_dev *i);
static int pktgen_add_device(struct pktgen_thread *t, const char *ifname);
static struct pktgen_dev *pktgen_find_dev(struct pktgen_thread *t,
@@ -520,7 +539,7 @@ static struct notifier_block pktgen_notifier_block = {
static int pgctrl_show(struct seq_file *seq, void *v)
{
- seq_puts(seq, VERSION);
+ seq_puts(seq, PKTGEN_FULLINFO);
return 0;
}
@@ -551,7 +570,7 @@ static ssize_t pgctrl_write(struct file *file, const char
__user * buf,
pktgen_run_all_threads();
else
- printk(pktgen: Unknown command: %s\n, data);
+ pktgen_info(Unknown command: %s\n, data);
err = count;
@@ -880,14 +899,14 @@ static ssize_t pktgen_if_write(struct file *file,
pg_result = (pkt_dev-result[0]);
if (count 1) {
- printk(pktgen: wrong command format\n);
+ pktgen_err(wrong command format\n);
return -EINVAL;
}
max = count - i;
tmp = count_trail_chars(user_buffer[i], max);
if (tmp 0) {
- printk(pktgen: illegal format\n);
+ pktgen_err(illegal format\n);
return tmp;
}
i += tmp;
@@ -915,8 +934,8 @@ static ssize_t pktgen_if_write(struct file *file,
if (copy_from_user(tb, user_buffer, count))
return -EFAULT;
tb[count] = 0;
- printk(pktgen: %s,%lu buffer -:%s:-\n, name,
- (unsigned long)count, tb);
+ pktgen_info(%s,%lu buffer -:%s:-\n, name,
+ (unsigned long)count, tb);
}
if (!strcmp(name, min_pkt_size)) {
@@ -1212,8 +1231,8 @@ static ssize_t pktgen_if_write(struct file *file,
pkt_dev-cur_daddr = pkt_dev-daddr_min;
}
if (debug)
- printk(pktgen: dst_min set to: %s\n,
- pkt_dev-dst_min);
+ pktgen_info(dst_min set to: %s\n,
+ pkt_dev-dst_min);
i += len;
sprintf(pg_result, OK: dst_min=%s, pkt_dev-dst_min);
return count;
@@ -1235,8 +1254,8 @@ static ssize_t pktgen_if_write(struct file *file,
pkt_dev-cur_daddr = pkt_dev-daddr_max;
}
if (debug)
- printk(pktgen: dst_max set to: %s\n,
- pkt_dev-dst_max);
+ pktgen_info(dst_max set to: %s\n,
+ pkt_dev-dst_max);
i += len;
sprintf(pg_result, OK: dst_max=%s, pkt_dev-dst_max);
return count;
@@ -1258,7 +1277,7 @@ static ssize_t pktgen_if_write(struct file *file,
ipv6_addr_copy(pkt_dev-cur_in6_daddr,
