Re: 2.6.23-rc4-mm1 OOPS in forcedeth?
From: Satyam Sharma [EMAIL PROTECTED] Date: Sun, Sep 02, 2007 at 06:24:29AM +0530 Hi Jurriaan, [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] Date: Fri, Aug 31, 2007 at 09:58:22PM -0700 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ On this machine (Athlon 64 X2 4600, 4 GiB memory, lots of disks), 2.6.23-rc1-mm2 runs fine. 2.6.23-rc4-mm1 reproducably dies within seconds of starting a rsync session on another PC against this machine. NULL pointer dereference code: nv_napi_poll+0x108 trace:net_rx_action+0xab __do_softirq+0x74 call_softirq+0x1c do_softirq+0x3d irq_exit+0x85 do_IRQ+0x85 ret_from_intr+0x0 The dmesg you posted below doesn't cover the messages from this oops itself. As you mentioned you can reproduce this oops easily, please do so, and post the *full* oops log (if it doesn't get logged to disk, you can try taking digicam photo, or write down *all* the messages and post here). I built an x86_64 kernel as per your .config, but don't see any memory dereference at nv_napi_poll+0x108 -- could be toolchain differences. There are 4 pictures of oopses here: http://www.xs4all.nl/~thunder7/oops_2623rc4mm1_1.jpg http://www.xs4all.nl/~thunder7/oops_2623rc4mm1_2.jpg http://www.xs4all.nl/~thunder7/oops_2623rc4mm1_3.jpg http://www.xs4all.nl/~thunder7/oops_2623rc4mm1_4.jpg image quality, well, they're readable. Good luck, Jurriaan -- management n. 1. Corporate power elites distinguished primarily by their distance from actual productive work and their chronic failure to manage (see also suit). Spoken derisively, as in Management decided that 2. Mythically, a vast bureaucracy responsible for all the world's minor irritations. Hackers' satirical public notices are often signed `The Mgt'; this derives from the Illuminatus novels (see the Bibliography in Appendix C). Debian (Unstable) GNU/Linux 2.6.23-rc1-mm2 2x2010 bogomips load 0.43 the Jack Vance Integral Edition: http://www.integralarchive.org - 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: Problem with implementation of TCP_DEFER_ACCEPT?
TJ [EMAIL PROTECTED] writes: Therefore, anyone deploying apache web servers in a web-farm behind the Juniper DX load-balanders and using TCP multiplexing (for which they pay a hefty licence fee!) If they ask for that much money they can surely fix it to work properly too? -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.23-rc4-mm1 net bitops compile error
defconfig fails with the following error on parisc: -- snip -- ... CC net/core/gen_estimator.o In file included from include2/asm/bitops.h:111, from /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/net/core/gen_estimator.c:18: /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/asm-generic/bitops/non-atomic.h: In function '__set_bit': /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/asm-generic/bitops/non-atomic.h:17: error: implicit declaration of function 'BIT_MASK' /home/bunk/linux/kernel-2.6/linux-2.6.23-rc4-mm1/include/asm-generic/bitops/non-atomic.h:18: error: implicit declaration of function 'BIT_WORD' make[3]: *** [net/core/gen_estimator.o] Error 1 -- snip -- Either #include asm/bitops.h must become forbidden and #error or the move of the #define's to include/linux/bitops.h reverted. 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: 2.6.23-rc4-mm1 OOPS in forcedeth?
On Sun, 2 Sep 2007, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On this machine (Athlon 64 X2 4600, 4 GiB memory, lots of disks), 2.6.23-rc1-mm2 runs fine. 2.6.23-rc4-mm1 reproducably dies within seconds of starting a rsync session on another PC against this machine. NULL pointer dereference code: nv_napi_poll+0x108 trace: net_rx_action+0xab __do_softirq+0x74 call_softirq+0x1c do_softirq+0x3d irq_exit+0x85 do_IRQ+0x85 ret_from_intr+0x0 There are 4 pictures of oopses here: http://www.xs4all.nl/~thunder7/oops_2623rc4mm1_1.jpg http://www.xs4all.nl/~thunder7/oops_2623rc4mm1_2.jpg http://www.xs4all.nl/~thunder7/oops_2623rc4mm1_3.jpg http://www.xs4all.nl/~thunder7/oops_2623rc4mm1_4.jpg OK, I've been pouring over forcedeth.c and the newly introduce NAPI code, but didn't debug this yet, so I'll at least lay out the situation so that somebody else who's more experienced @netdev can pick up from here with minimal time wastage. Here's what's happening (repeatedly, reproducibly) on Jurriaan's x64 box: (1) The following NULL dereference oops: nv_rx_process_optimized(), inlined from nv_napi_poll(), found that skb i.e. np-get_rx_ctx-skb == NULL when trying to update skb-ip_summed. (2) The following BUG in napi_complete(): BUG_ON(!test_bit(NAPI_STATE_SCHED, n-state)); from the nv_napi_poll()-__netif_rx_complete()-napi_complete() callchain is triggering. IOW napi_complete() found that a NAPI poll wasn't/shouldn't have been scheduled at all (!) The above two problems appear to be occurring independently, AFAICT. Satyam - 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] remove setup of platform device from jazzsonic.c
remove setup platform device from jazzsonic, which is done in arch code now
Signed-off-by: Thomas Bogendoerfer [EMAIL PROTECTED]
---
diff --git a/drivers/net/jazzsonic.c b/drivers/net/jazzsonic.c
index 75f6f44..435060a 100644
--- a/drivers/net/jazzsonic.c
+++ b/drivers/net/jazzsonic.c
@@ -45,7 +45,6 @@
#include asm/jazzdma.h
static char jazz_sonic_string[] = jazzsonic;
-static struct platform_device *jazz_sonic_device;
#define SONIC_MEM_SIZE 0x100
@@ -70,14 +69,6 @@ static unsigned int sonic_debug = 1;
#endif
/*
- * Base address and interrupt of the SONIC controller on JAZZ boards
- */
-static struct {
- unsigned int port;
- unsigned int irq;
-} sonic_portlist[] = { {JAZZ_ETHERNET_BASE, JAZZ_ETHERNET_IRQ}, {0, 0}};
-
-/*
* We cannot use station (ethernet) address prefixes to detect the
* sonic controller since these are board manufacturer depended.
* So we check for known Silicon Revision IDs instead.
@@ -215,13 +206,12 @@ static int __init jazz_sonic_probe(struct platform_device
*pdev)
{
struct net_device *dev;
struct sonic_local *lp;
+ struct resource *res;
int err = 0;
int i;
- /*
-* Don't probe if we're not running on a Jazz board.
-*/
- if (mips_machgroup != MACH_GROUP_JAZZ)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
return -ENODEV;
dev = alloc_etherdev(sizeof(struct sonic_local));
@@ -235,20 +225,9 @@ static int __init jazz_sonic_probe(struct platform_device
*pdev)
netdev_boot_setup_check(dev);
- if (dev-base_addr = KSEG0) { /* Check a single specified location. */
- err = sonic_probe1(dev);
- } else if (dev-base_addr != 0) { /* Don't probe at all. */
- err = -ENXIO;
- } else {
- for (i = 0; sonic_portlist[i].port; i++) {
- dev-base_addr = sonic_portlist[i].port;
- dev-irq = sonic_portlist[i].irq;
- if (sonic_probe1(dev) == 0)
- break;
- }
- if (!sonic_portlist[i].port)
- err = -ENODEV;
- }
+ dev-base_addr = res-start;
+ dev-irq = platform_get_irq(pdev, 0);
+ err = sonic_probe1(dev);
if (err)
goto out;
err = register_netdev(dev);
@@ -303,38 +282,12 @@ static struct platform_driver jazz_sonic_driver = {
static int __init jazz_sonic_init_module(void)
{
- int err;
-
- if ((err = platform_driver_register(jazz_sonic_driver))) {
- printk(KERN_ERR Driver registration failed\n);
- return err;
- }
-
- jazz_sonic_device = platform_device_alloc(jazz_sonic_string, 0);
- if (!jazz_sonic_device)
- goto out_unregister;
-
- if (platform_device_add(jazz_sonic_device)) {
- platform_device_put(jazz_sonic_device);
- jazz_sonic_device = NULL;
- }
-
- return 0;
-
-out_unregister:
- platform_driver_unregister(jazz_sonic_driver);
-
- return -ENOMEM;
+ return platform_driver_register(jazz_sonic_driver);
}
static void __exit jazz_sonic_cleanup_module(void)
{
platform_driver_unregister(jazz_sonic_driver);
-
- if (jazz_sonic_device) {
- platform_device_unregister(jazz_sonic_device);
- jazz_sonic_device = NULL;
- }
}
module_init(jazz_sonic_init_module);
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.[ RFC1925, 2.3 ]
-
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: That whole Linux stealing our code thing
co-operation. Together we advance our detective work and knowledge of the Macintosh platforms to the good of all Macintosh users dumped Alan Cox circa 1999. http://lists.freedesktop.org/archives/xorg/2007-August/027419.html well I'd be quite happy to see X go GPL but I'm aware thats not the intention of the project ;) Alan Cox circa 2007. What changed? Nothing that I am aware of. You can't take Linux/Mac68K code back into BSD either. BSD code is being used according to the BSD licence. You could adopt a different licence if the way your code is being used bothers you, thats. Where I've reused BSD code I've aways tried to contribute it back to the BSD people or share the knowledge (and the knowledge far more than the code mattered both ways for Mac68K systems) I suggest you read drivers/net/wan/syncppp.c, which is I think the only BSD derived bit of code of mine left in the kernel - and its quite specific what it says. Ath5k isn't my code so I don't get to pick. Having the OpenBSD maintainer make bogus remarks about that doesn't help anyone, especially when he's wrong and doesn't appear to know about the subject in the first place. Alan - 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: Fwd: That whole Linux stealing our code thing
- If you receive ISC or BSD licensed code, you may not delete the license. Same principle, since the notice says so. It's the law. Really. You can shout this all you like but you would be wrong. You can remove the licence if you have permission to do so. For the ath c files there was permission to do so. My understanding is that with dual-licensed code, you choose to comply with all of the terms of either licence. However, you cannot simply remove either of these licences from the code, unless you specifically receive such right from the copyright holder (remember, with the copyright law, unless the rights are specifically given, they are retained). This is what Theo was trying to educate the community on. I don't see anything unethical in explaining the legal issues. Your understanding isn't quite right. One of many things you may get with dual licensed code is the right to pick a licence from several choices, you may also get the right to remove some choices from the recipient. A work that combines GPL and BSD licensed material is not the same as a work which says I may choose between two licences. If both licences must always apply (which is a perfectly possible condition to put in a licence) then putting such a both GPL/BSD licence piece of code into OpenBSD would require any OpenBSD distributed containing it was GPL licenced when conveyed, which I am *very* sure is not the intent. Thus what you appear to be doing by putting the ath5k C code in OpenBSD is conveying it under the BSD licence (making a choice between the two offered) and conveying a right for parties down the chain to convey it under one of the licences only. And as we've already established the header files are quite different. Doesn't mean its not somewhat rude but illegal and rude are two very different things. - 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 1/2] net/: all net/ cleanup with ARRAY_SIZE
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
---
net/atm/proc.c |2 +-
net/decnet/dn_dev.c |2 +-
net/ipv4/af_inet.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/atm/proc.c b/net/atm/proc.c
index 99fc1fe..a3e52ff 100644
--- a/net/atm/proc.c
+++ b/net/atm/proc.c
@@ -175,7 +175,7 @@ static void pvc_info(struct seq_file *seq, struct atm_vcc
*vcc)
seq_printf(seq, %3d %3d %5d %-3s %7d %-5s %7d %-6s,
vcc-dev-number,vcc-vpi,vcc-vci,
- vcc-qos.aal = sizeof(aal_name)/sizeof(aal_name[0]) ? err :
+ vcc-qos.aal = ARRAY_SIZE(aal_name) ? err :
aal_name[vcc-qos.aal],vcc-qos.rxtp.min_pcr,
class_name[vcc-qos.rxtp.traffic_class],vcc-qos.txtp.min_pcr,
class_name[vcc-qos.txtp.traffic_class]);
diff --git a/net/decnet/dn_dev.c b/net/decnet/dn_dev.c
index fa6604f..9470cb9 100644
--- a/net/decnet/dn_dev.c
+++ b/net/decnet/dn_dev.c
@@ -149,7 +149,7 @@ static struct dn_dev_parms dn_dev_list[] = {
}
};
-#define DN_DEV_LIST_SIZE (sizeof(dn_dev_list)/sizeof(struct dn_dev_parms))
+#define DN_DEV_LIST_SIZE ARRAY_SIZE(dn_dev_list)
#define DN_DEV_PARMS_OFFSET(x) ((int) ((char *) ((struct dn_dev_parms
*)0)-x))
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index e681034..d5e8b67 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -939,7 +939,7 @@ static struct inet_protosw inetsw_array[] =
}
};
-#define INETSW_ARRAY_LEN (sizeof(inetsw_array) / sizeof(struct inet_protosw))
+#define INETSW_ARRAY_LEN ARRAY_SIZE(inetsw_array)
void inet_register_protosw(struct inet_protosw *p)
{
--
1.5.3.rc7
-
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 2/2] drivers/net/: all drivers/net/ cleanup with ARRAY_SIZE
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
---
drivers/net/apne.c |2 +-
drivers/net/arm/am79c961a.c|2 +-
drivers/net/atarilance.c |2 +-
drivers/net/atl1/atl1_hw.c |2 +-
drivers/net/bnx2.c |2 +-
drivers/net/cs89x0.c |6 +++---
drivers/net/e1000/e1000_ethtool.c |3 +--
drivers/net/fec_8xx/fec_mii.c |5 ++---
drivers/net/ibm_emac/ibm_emac_debug.c |8
drivers/net/irda/actisys-sir.c |2 +-
drivers/net/ixgb/ixgb_ethtool.c|3 +--
drivers/net/lp486e.c |4 +---
drivers/net/mv643xx_eth.c |3 +--
drivers/net/ne-h8300.c |2 +-
drivers/net/ne.c |2 +-
drivers/net/ne2.c |2 +-
drivers/net/ne2k-pci.c |2 +-
drivers/net/netxen/netxen_nic.h|2 +-
drivers/net/netxen/netxen_nic_hw.c |2 +-
drivers/net/pcmcia/axnet_cs.c |2 +-
drivers/net/pcmcia/pcnet_cs.c |4 ++--
drivers/net/phy/phy.c |2 +-
drivers/net/skfp/smt.c |2 +-
drivers/net/skfp/srf.c |4 ++--
drivers/net/tulip/de4x5.c |6 +++---
drivers/net/wireless/airo.c|6 +++---
drivers/net/wireless/hostap/hostap_ioctl.c |6 +++---
drivers/net/wireless/ipw2100.c |7 +++
drivers/net/wireless/libertas/fw.c |3 +--
drivers/net/wireless/libertas/main.c | 14 +++---
drivers/net/wireless/libertas/wext.c |4 ++--
drivers/net/wireless/netwave_cs.c |6 +++---
drivers/net/wireless/prism54/isl_ioctl.c |7 +++
drivers/net/wireless/ray_cs.c |6 +++---
drivers/net/wireless/wavelan.c |6 +++---
drivers/net/wireless/wavelan_cs.c |6 +++---
drivers/net/wireless/wl3501_cs.c |2 +-
drivers/net/zorro8390.c|2 +-
38 files changed, 71 insertions(+), 80 deletions(-)
diff --git a/drivers/net/apne.c b/drivers/net/apne.c
index 9541911..8806151 100644
--- a/drivers/net/apne.c
+++ b/drivers/net/apne.c
@@ -247,7 +247,7 @@ static int __init apne_probe1(struct net_device *dev, int
ioaddr)
{0x00, NE_EN0_RSARHI},
{E8390_RREAD+E8390_START, NE_CMD},
};
- for (i = 0; i sizeof(program_seq)/sizeof(program_seq[0]); i++) {
+ for (i = 0; i ARRAY_SIZE(program_seq); i++) {
outb(program_seq[i].value, ioaddr + program_seq[i].offset);
}
diff --git a/drivers/net/arm/am79c961a.c b/drivers/net/arm/am79c961a.c
index 2143eeb..7796455 100644
--- a/drivers/net/arm/am79c961a.c
+++ b/drivers/net/arm/am79c961a.c
@@ -414,7 +414,7 @@ static void am79c961_setmulticastlist (struct net_device
*dev)
/*
* Update the multicast hash table
*/
- for (i = 0; i sizeof(multi_hash) / sizeof(multi_hash[0]); i++)
+ for (i = 0; i ARRAY_SIZE(multi_hash); i++)
write_rreg(dev-base_addr, i + LADRL, multi_hash[i]);
/*
diff --git a/drivers/net/atarilance.c b/drivers/net/atarilance.c
index dfa8b9b..a5c20d2 100644
--- a/drivers/net/atarilance.c
+++ b/drivers/net/atarilance.c
@@ -263,7 +263,7 @@ struct lance_addr {
(highest byte stripped) */
};
-#defineN_LANCE_ADDR
(sizeof(lance_addr_list)/sizeof(*lance_addr_list))
+#defineN_LANCE_ADDRARRAY_SIZE(lance_addr_list)
/* Definitions for the Lance */
diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c
index ef886bd..9d3bd22 100644
--- a/drivers/net/atl1/atl1_hw.c
+++ b/drivers/net/atl1/atl1_hw.c
@@ -603,7 +603,7 @@ static struct atl1_spi_flash_dev flash_table[] = {
static void atl1_init_flash_opcode(struct atl1_hw *hw)
{
- if (hw-flash_vendor = sizeof(flash_table) / sizeof(flash_table[0]))
+ if (hw-flash_vendor = ARRAY_SIZE(flash_table))
hw-flash_vendor = 0; /* ATMEL */
/* Init OP table */
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 854d80c..aa9e636 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -3500,7 +3500,7 @@ bnx2_init_nvram(struct bnx2 *bp)
/* Determine the selected interface. */
val = REG_RD(bp, BNX2_NVM_CFG1);
- entry_count = sizeof(flash_table) / sizeof(struct flash_spec);
+ entry_count = ARRAY_SIZE(flash_table);
if (val 0x4000) {
diff --git a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c
index 9774bb1..d0f4a1a 100644
--- a/drivers/net/cs89x0.c
+++ b/drivers/net/cs89x0.c
@@ -806,7 +806,7 @@ cs89x0_probe1(struct net_device *dev, int ioaddr, int
modular)
i = cs8900_irq_map[0];
#else
Re: [Bugme-new] [Bug 8961] New: BUG triggered by oidentd in netlink code
Herbert Xu wrote: Patrick McHardy [EMAIL PROTECTED] wrote: Thanks. I'm not sure either, it would require two concurrent requests to be processed, but AFAICS oidentd only uses a single netlink socket. Perhaps multiple running instances or something else using the inet_diag interface? Since identd serves requests from the outside world it is quite possible for two identd instances to run simultaneously serving two requests. I'm not familiar with oidentd but this is certainly pidentd works. Right, I forgot about inetd. Thanks Herbert :) - 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] ethtool: provide default behavior for a few sub-ioctls
Just checked this in...
commit 2c0205e3480ac39f5b52b2220ff0c77141502936
Author: Jeff Garzik [EMAIL PROTECTED]
Date: Sun Sep 2 07:13:36 2007 -0400
[ETHTOOL] Provide default behaviors for a few ethtool sub-ioctls
For the operations
get-tx-csum
get-sg
get-tso
get-ufo
the default ethtool_op_xxx behavior is fine for all drivers, so we
permit op==NULL to imply the default behavior.
This provides a more uniform behavior across all drivers, eliminating
ethtool(8) ioctl not supported errors on older drivers that had
not been updated for the latest sub-ioctls.
The ethtool_op_xxx() functions are left exported, in case anyone
wishes to call them directly from a driver-private implementation --
a not-uncommon case. Should an ethtool_op_xxx() helper remain unused
for a while, except by net/core/ethtool.c, we can un-export it at a
later date.
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]
drivers/net/8139cp.c|3 ---
drivers/net/atl1/atl1_ethtool.c |3 ---
drivers/net/bnx2.c |3 ---
drivers/net/bonding/bond_main.c |4
drivers/net/chelsio/cxgb2.c |3 ---
drivers/net/cxgb3/cxgb3_main.c |3 ---
drivers/net/e1000/e1000_ethtool.c |2 --
drivers/net/ehea/ehea_ethtool.c |3 ---
drivers/net/epic100.c |2 --
drivers/net/fealnx.c|2 --
drivers/net/fec_8xx/fec_main.c |2 --
drivers/net/forcedeth.c |3 ---
drivers/net/fs_enet/fs_enet-main.c |2 --
drivers/net/ibm_emac/ibm_emac_core.c|2 --
drivers/net/ibmveth.c |2 --
drivers/net/ixgb/ixgb_ethtool.c |2 --
drivers/net/loopback.c |1 -
drivers/net/macvlan.c |4
drivers/net/mv643xx_eth.c |1 -
drivers/net/myri10ge/myri10ge.c |3 ---
drivers/net/ne2k-pci.c |2 --
drivers/net/netxen/netxen_nic_ethtool.c |3 ---
drivers/net/pcnet32.c |3 ---
drivers/net/r8169.c |3 ---
drivers/net/s2io.c |3 ---
drivers/net/sc92031.c |4
drivers/net/skge.c |2 --
drivers/net/sky2.c |3 ---
drivers/net/spider_net_ethtool.c|1 -
drivers/net/tg3.c |3 ---
drivers/net/tulip/de2104x.c |2 --
drivers/net/tulip/winbond-840.c |2 --
drivers/net/typhoon.c |3 ---
drivers/net/ucc_geth_ethtool.c |2 --
drivers/net/via-rhine.c |2 --
drivers/net/xen-netfront.c |3 ---
net/bridge/br_device.c |3 ---
net/core/ethtool.c | 32 +---
38 files changed, 17 insertions(+), 109 deletions(-)
2c0205e3480ac39f5b52b2220ff0c77141502936
diff --git a/drivers/net/8139cp.c b/drivers/net/8139cp.c
index a79f28c..9e674c9 100644
--- a/drivers/net/8139cp.c
+++ b/drivers/net/8139cp.c
@@ -1567,11 +1567,8 @@ static const struct ethtool_ops cp_ethtool_ops = {
.set_msglevel = cp_set_msglevel,
.get_rx_csum= cp_get_rx_csum,
.set_rx_csum= cp_set_rx_csum,
- .get_tx_csum= ethtool_op_get_tx_csum,
.set_tx_csum= ethtool_op_set_tx_csum, /* local! */
- .get_sg = ethtool_op_get_sg,
.set_sg = ethtool_op_set_sg,
- .get_tso= ethtool_op_get_tso,
.set_tso= ethtool_op_set_tso,
.get_regs = cp_get_regs,
.get_wol= cp_get_wol,
diff --git a/drivers/net/atl1/atl1_ethtool.c b/drivers/net/atl1/atl1_ethtool.c
index 1f616c5..53353b6 100644
--- a/drivers/net/atl1/atl1_ethtool.c
+++ b/drivers/net/atl1/atl1_ethtool.c
@@ -489,15 +489,12 @@ const struct ethtool_ops atl1_ethtool_ops = {
.get_pauseparam = atl1_get_pauseparam,
.set_pauseparam = atl1_set_pauseparam,
.get_rx_csum= atl1_get_rx_csum,
- .get_tx_csum= ethtool_op_get_tx_csum,
.set_tx_csum= ethtool_op_set_tx_hw_csum,
.get_link = ethtool_op_get_link,
- .get_sg = ethtool_op_get_sg,
.set_sg = ethtool_op_set_sg,
.get_strings= atl1_get_strings,
.nway_reset = atl1_nway_reset,
.get_ethtool_stats = atl1_get_ethtool_stats,
.get_stats_count= atl1_get_stats_count,
- .get_tso= ethtool_op_get_tso,
.set_tso= ethtool_op_set_tso,
};
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 24e7f9a..87df593 100644
---
[-mm patch] IPV6 must select XFRM
On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote: ... Changes since 2.6.23-rc3-mm1: ... git-net.patch ... git trees ... This patch fixes the following compile error: -- snip -- ... LD .tmp_vmlinux1 net/built-in.o: In function `inet6_csk_xmit': (.text+0x72b0f): undefined reference to `flow_cache_genid' net/built-in.o: In function `inet6_csk_xmit': (.text+0x72be5): undefined reference to `flow_cache_genid' make[1]: *** [.tmp_vmlinux1] Error 1 -- snip -- Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- a/net/ipv6/Kconfig +++ b/net/ipv6/Kconfig @@ -5,6 +5,7 @@ # IPv6 as module will cause a CRASH if you try to unload it config IPV6 tristate The IPv6 protocol + select XFRM default m ---help--- This is complemental support for the IP version 6. - 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: [ofa-general] Re: [PATCH V4 10/10] net/bonding: Destroy bonding master when last slave is gone
Jay Vosburgh wrote: Moni Shoua [EMAIL PROTECTED] wrote: Jay Vosburgh wrote: Moni Shoua [EMAIL PROTECTED] wrote: When bonding enslaves non Ethernet devices it takes pointers to functions in the module that owns the slaves. In this case it becomes unsafe to keep the bonding master registered after last slave was unenslaved because we don't know if the pointers are still valid. Destroying the bond when slave_cnt is zero ensures that these functions be used anymore. Would it not be simpler to run the bonding master through ether_setup() again when the final slave is released (to reset all of the pointers to their ethernet values)? I'm presuming here the pointers of questionable validity are the ones set in the bond_setup_by_slave() copied from the slave_dev-hard_header, et al. Having the bonding master disappear (but only sometimes) after the last slave is removed is a semantic change I'd rather not introduce if it's not necessary. Thanks for the comments. Having the master disappear is one way I could think of to solve the problem of leaving the bonding module with pointers to illegal addresses. The other way is to increase the usage count, with try_module_get(), of the module which owns of the slave. To do that I have to restore the field owner in structure net_device (it was removed in 2.6). What I was asking above is really whether or not it's feasible to simply reset the affected pointers back to the ethernet values from ether_setup(). I would think this should return the bonding master back to the original state it started in before any slaves were added. Unless I'm missing something; I'm willing to believe there's some IB-specific tidbit I'm unaware of that makes this more complicated than it seems. It's possible to reset the bonding master by calling ether_setup but with one exception: its neighbors. When enslaving IPoIB devices, the bonding master neighbors point to a destructor function in the ib_ipoib module. When ib_ipoib goes down the neighbors of the bonding master still exist and when their turn come to die they will try to access this function and the kernel will crash. This is why I want to destroy the bonding master before ib_ipoib is unloaded (to kill its neighbors). For any other issue (i.e. taken pointer), ether_setup would solve the problem. This presumes that I'm correct in thinking that the pointers you're talking about (as being unsafe after removal of last slave) are the ones copied in your new function bond_setup_by_slave(). I don't think it's desirable to acquire a reference to the slave driver module. -J --- -Jay Vosburgh, IBM Linux Technology Center, [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
[OOPS] 2.6.23-rc5 ? network/via-rhine [was: hang with CONFIG_MCYRIXIII]
I have now got an oops trace out of this box, which I presume has been
the cause of the previously observed hangs.
To my inexperienced eye it looks like it is related to via-rhine.
Thanks
Mark
BUG: unable to handle kernel NULL pointer dereference at virtual address
0025
printing eip:
c0259a57
*pde =
Oops: [#1]
PREEMPT
Modules linked in: nfs cpufreq_userspace nfsd exportfs lockd sunrpc ppdev lp ac
battery ipv6 sd_mod cpufreq_ondemand cpufreq_powersave longhaul af_packet
tcp_diag inetv
CPU:0
EIP:0060:[c0259a57]Not tainted VLI
EFLAGS: 00010246 (2.6.23-rc5 #1)
EIP is at tcp_rto_min+0x8/0x12
eax: 00c8 ebx: c7ab1080 ecx: ffee edx:
esi: c7ab1080 edi: ebp: c9a24b20 esp: c0341dec
ds: 007b es: 007b fs: gs: 0033 ss: 0068
Process ssh (pid: 4928, ti=c0341000 task=c963cf90 task.ti=c35b9000)
Stack: c0259b1b c7ab1080 c7ab1080 c025a2e8 c030c8a0 c025b906 0080 0080
c022f433 cacde032 0001 28419aa8 731a8024 28419b18
c011ebc5 28419b18 0282 028b585b 0004 cceb3540
Call Trace:
[c0259b1b] tcp_rtt_estimator+0xba/0x100
[c025a2e8] tcp_ack_saw_tstamp+0x14/0x43
[c025b906] tcp_ack+0x6aa/0x1726
[c022f433] skb_checksum+0x49/0x289
[c011ebc5] local_bh_enable+0x5/0x8c
[c025f1bf] tcp_rcv_established+0x344/0x5ed
[c024b660] ip_route_input+0x3a/0xcdc
[c0264226] tcp_v4_do_rcv+0x27/0x31d
[c0266309] tcp_v4_rcv+0x71a/0x765
[c024e7b6] ip_local_deliver+0x159/0x1bf
[c024e630] ip_rcv+0x44e/0x47b
[c01b9540] rb_insert_color+0x4c/0xad
[c024e630] ip_rcv+0x44e/0x47b
[c0115bb4] enqueue_entity+0x1d2/0x1f3
[c024e1e2] ip_rcv+0x0/0x47b
[c023470b] netif_receive_skb+0x30d/0x38e
[d00d55a8] rhine_napipoll+0x2a7/0x46d [via_rhine]
[c02368c9] net_rx_action+0x85/0x171
[c011ea8e] __do_softirq+0x35/0x75
[c010665c] do_softirq+0x3e/0x8d
[c013c6cc] handle_level_irq+0x0/0xd0
[c011ea20] irq_exit+0x29/0x62
[c010693b] do_IRQ+0x94/0xad
[c0104cf3] common_interrupt+0x23/0x30
===
Code: 00 8b 14 24 8b 82 8c 02 00 00 89 82 10 04 00 00 a1 e0 6e 2f c0 89 82 14
04 00 00 83 c4 0c 5b 5e 5f 5d c3 8b 50 44 b8 c8 00 00 00 f6 42 25 20 74 03 8b
42 54 c3
EIP: [c0259a57] tcp_rto_min+0x8/0x12 SS:ESP 0068:c0341dec
Kernel panic - not syncing: Fatal exception in interrupt
-
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 -mm] net/sched/sch_cbq.c: Shut up uninitialized variable warning
Satyam Sharma wrote: net/sched/sch_cbq.c: In function 'cbq_enqueue': net/sched/sch_cbq.c:383: warning: 'ret' may be used uninitialized in this function has been verified to be a bogus case. So let's shut it up. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] Acked-by: Patrick McHardy [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: Ethernet weirdness on 82xx
Sorry forgot, maybe also arp_ignore is related to that -- Denys Fedoryshchenko Technical Manager Virtual ISP S.A.L. - 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: Ethernet weirdness on 82xx
Thats normal.
Check arp_filter sysctl :
arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.
0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.
arp_filter for the interface will be enabled if at least one of
conf/{all,interface}/arp_filter is set to TRUE,
it will be disabled otherwise
IMHO default setting can mess up things in some conditions.
On Fri, 31 Aug 2007 16:35:19 -0500, Rune Torgersen wrote
I'm not sure if this is by design or an actual bug.
We have a system witb an 8280 with two active ethernets (fcc2 and
fcc3) We are running kernel 2.6.18.1 (and won't be upgrading in a
while) out of arch/ppc
Eth0 and eth1 are in totally different subnets.
We happened to have both ehternets connected to the same network,
and I ran a arping agains the IP on eth0. Both ports (eth0 and eth1)
responded with the same address, but different macs
sudo /sbin/arping -c1 172.23.12.114
ARPING 172.23.12.114 from 172.23.15.21 eth0
Unicast reply from 172.23.12.114 [00:30:D7:00:14:55] 0.838ms
Unicast reply from 172.23.12.114 [00:30:D7:00:14:54] 0.890ms
Sent 1 probes (1 broadcast(s))
Received 2 response(s)
It only gets both responses on the first (broadcast) query from
arping All responses afterward is then from the wrong port
The ethernet setup on the target box:
eth0 Link encap:Ethernet HWaddr 00:30:D7:00:14:54
inet addr:172.23.12.114 Bcast:172.23.15.255
Mask:255.255.248.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:473244 errors:0 dropped:2 overruns:0 frame:0
TX packets:186655 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:162928671 (155.3 Mb) TX bytes:4862 (40.2 Mb)
Base address:0x8500
eth1 Link encap:Ethernet HWaddr 00:30:D7:00:14:55
inet addr:192.168.0.100 Bcast:192.168.0.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1553 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:203182 (198.4 Kb) TX bytes:168 (168.0 b)
Base address:0x8600
-
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
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
-
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: Fwd: That whole Linux stealing our code thing
On Sep 1 2007 18:36, Theo de Raadt wrote: When companies have taken our wireless device drivers, many many of them have given changes and fixes back. Some maybe didn't, but that is OK. For companies it's ok, but for linux people it is not? (1) You do not know how much of the modifications companies did are actually returned (2) You do not know whether the ath5k linux part authors will give back at a later point (much like companies) - 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: Fwd: That whole Linux stealing our code thing
On Sun, Sep 02, 2007 at 01:20:27PM +0200, Igor Sobrado wrote: On Sun, 2 Sep 2007, Alan Cox wrote: You can shout this all you like but you would be wrong. You can remove the licence if you have permission to do so. For the ath c files there was permission to do so. There was permission to do so from Reyk Floeter? Really? Your understanding isn't quite right. One of many things you may get with dual licensed code is the right to pick a licence from several choices, you may also get the right to remove some choices from the recipient. Reyk code was never dual licensed! His code is under truly free licensing terms (BSD). Jiri's patch touched both files containing BSD-only code by Reyk and code Reyk contributed to leaving the file dual licenced. A work that combines GPL and BSD licensed material is not the same as a work which says I may choose between two licences. If both licences must always apply (which is a perfectly possible condition to put in a licence) then putting such a both GPL/BSD licence piece of code into OpenBSD would require any OpenBSD distributed containing it was GPL licenced when conveyed, which I am *very* sure is not the intent. Thus what you appear to be doing by putting the ath5k C code in OpenBSD is conveying it under the BSD licence (making a choice between the two offered) and conveying a right for parties down the chain to convey it under one of the licences only. I think that Theo explained this point clearly quite a few times in the last days. And as we've already established the header files are quite different. Is a simple change in the header files a reason to vindicate the people that changed the licensing terms? Obviously, it isn't. Doesn't mean its not somewhat rude but illegal and rude are two very different things. No, because this change is both rude and illegal. You mixed two completely different things in your email: 1. Jiri's patch (that was never merged into Linux) not only removed the BSD header from dual licenced files but also from not dual licenced files. 2. Theo accused Alan that telling people that it was OK to choose one licence for dual licenced code was advising people to break the law. Jiri's patch was legally not OK regarding 1. - there's no discussion regarding this. The point 2 is what the email of Theo that was forwarded to linux-kernel is about and what the discussion is about. That's quite a rude action by Theo unless he's able to prove that this accusation is correct. Igor 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: [OOPS] 2.6.23-rc5 ? network/via-rhine [was: hang with CONFIG_MCYRIXIII]
On Sun, 2 Sep 2007, Mark Hindley wrote: BUG: unable to handle kernel NULL pointer dereference at virtual address 0025 [...] Call Trace: [c0259b1b] tcp_rtt_estimator+0xba/0x100 [...] EIP: [c0259a57] tcp_rto_min+0x8/0x12 SS:ESP 0068:c0341dec Third report of this oops within past few hours :-) You want the patch available at: (very long URL) http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=blobdiff;f=net/ipv4/tcp_input.c;h=bbad2cdb74b7c18c0ae742be241857b126f06890;hp=1ee72127462bf37ed5ef834ebc7b1cf070d5;hb=5c127c58ae9bf196d787815b1bd6b0aec5aee816;hpb=88282c6ecf0dacefda6090b0289d35e8a3cc6221 - 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: Oops in 2.6.23-rc5
On Sun, 2 Sep 2007, Herbert Xu wrote: You want this patch (by davem). I applied the patch and the box is up for 1hr now. Since I was able to reproduce the oops pretty reliable with this bittorrent thingy, I did the same a few times now, but the box did NOT crash :) Unfortunately people are travelling so I'm not sure when it'll get picked up by Linus. I've seen this patch only in: http://article.gmane.org/gmane.linux.network/70781 And, for the archives, a simliar looking error report: http://article.gmane.org/gmane.linux.network/70777 Thanks for the quick reply, Herbert! Christian. -- BOFH excuse #297: Too many interrupts - 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: Fwd: That whole Linux stealing our code thing
On Sun, 2 Sep 2007, Adrian Bunk wrote: On Sun, Sep 02, 2007 at 01:20:27PM +0200, Igor Sobrado wrote: Reyk code was never dual licensed! His code is under truly free licensing terms (BSD). Jiri's patch touched both files containing BSD-only code by Reyk and code Reyk contributed to leaving the file dual licenced. Ok. You mixed two completely different things in your email: 1. Jiri's patch (that was never merged into Linux) not only removed the BSD header from dual licenced files but also from not dual licenced files. 2. Theo accused Alan that telling people that it was OK to choose one licence for dual licenced code was advising people to break the law. Jiri's patch was legally not OK regarding 1. - there's no discussion regarding this. The point 2 is what the email of Theo that was forwarded to linux-kernel is about and what the discussion is about. That's quite a rude action by Theo unless he's able to prove that this accusation is correct. When code is multi-licensed it must be distributed under *all* these licensing terms concurrently. It is easy to understand. Removing (or changing) the conditions that apply to the program from the source code and documentation *without* an authorization from all the author(s) is illegal. So, a multi-licensed file remains multi-licensed except when all authors agree about a change in the licensing terms. And it is clear on the BSD license that a modification of the distribution terms is illegal. It is the first clause on the BSD license: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer, *without modification. So, removing (or changing) the list of conditions on the BSD license is not allowed. Igor. - 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: Fwd: That whole Linux stealing our code thing
On Sun, 02 Sep 2007 13:20:27 +0200 (CEST) Igor Sobrado [EMAIL PROTECTED] wrote: On Sun, 2 Sep 2007, Alan Cox wrote: You can shout this all you like but you would be wrong. You can remove the licence if you have permission to do so. For the ath c files there was permission to do so. There was permission to do so from Reyk Floeter? Really? The code pieces I quoted contained that choice. As far as I am concerned that is what the discussion was about. Alan - 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: Fwd: That whole Linux stealing our code thing
Igor Sobrado wrote: When code is multi-licensed it must be distributed under *all* these licensing terms concurrently. It is easy to understand. Removing (or changing) the conditions that apply to the program from the source code and documentation *without* an authorization from all the author(s) is illegal. The plain English in the dual-license text directly contradicts this fiction. 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: Fwd: That whole Linux stealing our code thing
So, a multi-licensed file remains multi-licensed except when all authors agree about a change in the licensing terms. And it is clear on the BSD Not strictly true. They can either agree to a change and issue one or they can convey to other parties the right to change the terms. The GPL for example does this for version selection. A multi-licensed work (note work not file - don't assume a file is a boundary of a work) which conveys the choice of licence (as some bits of ath5k did) allows a receiving party to choose the licence it wishes. Failing that OpenBSD would have turned itself GPL by adding that file as according to your argument it must be distributed under *all* these licensing terms concurrently. Alan - 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: Fwd: That whole Linux stealing our code thing
On Sun, 2 Sep 2007, Alan Cox wrote: You can shout this all you like but you would be wrong. You can remove the licence if you have permission to do so. For the ath c files there was permission to do so. There was permission to do so from Reyk Floeter? Really? Your understanding isn't quite right. One of many things you may get with dual licensed code is the right to pick a licence from several choices, you may also get the right to remove some choices from the recipient. Reyk code was never dual licensed! His code is under truly free licensing terms (BSD). A work that combines GPL and BSD licensed material is not the same as a work which says I may choose between two licences. If both licences must always apply (which is a perfectly possible condition to put in a licence) then putting such a both GPL/BSD licence piece of code into OpenBSD would require any OpenBSD distributed containing it was GPL licenced when conveyed, which I am *very* sure is not the intent. Thus what you appear to be doing by putting the ath5k C code in OpenBSD is conveying it under the BSD licence (making a choice between the two offered) and conveying a right for parties down the chain to convey it under one of the licences only. I think that Theo explained this point clearly quite a few times in the last days. And as we've already established the header files are quite different. Is a simple change in the header files a reason to vindicate the people that changed the licensing terms? Obviously, it isn't. Doesn't mean its not somewhat rude but illegal and rude are two very different things. No, because this change is both rude and illegal. Igor - 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: Fwd: That whole Linux stealing our code thing
On Sun, 2 Sep 2007, Alan Cox wrote: So, a multi-licensed file remains multi-licensed except when all authors agree about a change in the licensing terms. And it is clear on the BSD Not strictly true. They can either agree to a change and issue one or they can convey to other parties the right to change the terms. The GPL for example does this for version selection. So, under a dual-licensed BSD/GPL code the latter license allows a developer to remove the GPL license itself and release a single-licensed BSD code if other parties want to do it? A multi-licensed work (note work not file - don't assume a file is a boundary of a work) which conveys the choice of licence (as some bits of ath5k did) allows a receiving party to choose the licence it wishes. Failing that OpenBSD would have turned itself GPL by adding that file as according to your argument it must be distributed under *all* these licensing terms concurrently. I would assume a file as a boundary of a work in the case that file is under different licensing terms to the rest of the software package. On a lot of software packages different modules are covered under different licensing terms. We can choose what license terms we will honor; however, we do not have the ability to remove the licensing terms we do not like. Igor. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.23-rc5: possible irq lock inversion dependency detected
Hi,
after upgrading to 2.6.23-rc5 (and applying davem's fix [0]), lockdep
was quite noisy when I tried to shape my external (wireless) interface:
[ 6400.534545] FahCore_78.exe/3552 just changed the state of lock:
[ 6400.534713] (dev-ingress_lock){-+..}, at: [c038d595]
netif_receive_skb+0x2d5/0x3c0
[ 6400.534941] but this lock took another, soft-read-irq-unsafe lock in the
past:
[ 6400.535145] (police_lock){-.--}
This happened when I executed: http://nerdbynature.de/bits/2.6.23-rc5/qos.sh.txt
(using iproute2-ss070313). The is still running, I just noticed a short
hickup, probably when it was busy writing the warning to the disk.
More details and .config: http://nerdbynature.de/bits/2.6.23-rc5/
I'm not really sure what the application mentioned in the message above
has to do with this: the application[1] has been running since bootup as
a non-privileged user and did so for earlier kernel versions too.
Christian.
[0] http://lkml.org/lkml/2007/9/2/6
[1] http://folding.stanford.edu/linux.html
--
BOFH excuse #294:
PCMCIA slave driver
-
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: Fwd: That whole Linux stealing our code thing
On Sun, Sep 02, 2007 at 03:00:46PM +0200, Igor Sobrado wrote: On Sun, 2 Sep 2007, Alan Cox wrote: So, a multi-licensed file remains multi-licensed except when all authors agree about a change in the licensing terms. And it is clear on the BSD Not strictly true. They can either agree to a change and issue one or they can convey to other parties the right to change the terms. The GPL for example does this for version selection. So, under a dual-licensed BSD/GPL code the latter license allows a developer to remove the GPL license itself and release a single-licensed BSD code if other parties want to do it? Exactly. A multi-licensed work (note work not file - don't assume a file is a boundary of a work) which conveys the choice of licence (as some bits of ath5k did) allows a receiving party to choose the licence it wishes. Failing that OpenBSD would have turned itself GPL by adding that file as according to your argument it must be distributed under *all* these licensing terms concurrently. I would assume a file as a boundary of a work in the case that file is under different licensing terms to the rest of the software package. On a lot of software packages different modules are covered under different licensing terms. We can choose what license terms we will honor; however, we do not have the ability to remove the licensing terms we do not like. We have the ability if the author explicitely allowed it. This is the licencing text we are talking about: /*- * Copyright (c) 2002-2004 Sam Leffler, Errno Consulting * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer, *without modification. * 2. Redistributions in binary form must reproduce at minimum a disclaimer *similar to the NO WARRANTY disclaimer below (Disclaimer) and any *redistribution must be conditioned upon including a substantially *similar Disclaimer requirement for further binary redistribution. * 3. Neither the names of the above-listed copyright holders nor the names *of any contributors may be used to endorse or promote products derived *from this software without specific prior written permission. * * Alternatively, this software may be distributed under the terms of the * GNU General Public License (GPL) version 2 as published by the Free * Software Foundation. * * NO WARRANTY * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT * LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL * THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF * THE POSSIBILITY OF SUCH DAMAGES. */ The author himself offered two _alternatives_ for distributing his code. Igor. 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: Fwd: That whole Linux stealing our code thing
Not strictly true. They can either agree to a change and issue one or they can convey to other parties the right to change the terms. The GPL for example does this for version selection. So, under a dual-licensed BSD/GPL code the latter license allows a developer to remove the GPL license itself and release a single-licensed BSD code if other parties want to do it? If the dual licence permits you to select from two alternatives as appears to be the case in * Alternatively, this software may be distributed under the terms of the * GNU General Public License (GPL) version 2 as published by the Free * Software Foundation. Then there is no problem in doing exactly what it says and distributing it under the terms of the GPL v2 and the GPL v2 alone (or indeed the BSD licence alone). Anyone who took the project code and produced a binary only proprietary product from it would for example select the BSD licence alone and convey almost no rights at all to their customer. I would assume a file as a boundary of a work in the case that file is under different licensing terms to the rest of the software package. On a Assuming is bad, you should consult caselaw. lot of software packages different modules are covered under different licensing terms. We can choose what license terms we will honor; however, we do not have the ability to remove the licensing terms we do not like. If the author has conveyed that right to you, then you may usually do so. Alan - 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: Fwd: That whole Linux stealing our code thing
IANAL, but: Igor Sobrado [EMAIL PROTECTED] writes: So, under a dual-licensed BSD/GPL code the latter license allows a developer to remove the GPL license itself and release a single-licensed BSD code if other parties want to do it? Of course. If it wasn't legal, dual BSD/GPL would just be equal to GPL. Now, dual BSD/GPL equals BSD. OTOH I'd probable leave the original licence text, something like: The actual licence conditions: GPL or BSD or whatever. Portions of this file were licenced under: [the original licence text, not valid as a licence for current file] WRT Atheros driver I'd probably leave the thing as is (i.e., BSD/GPL = in fact BSD), unless something like 50+% of the code is rewritten - it's mostly their hard work after all, isn't it? Not legal requirement, though. -- Krzysztof Halasa - 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: Fwd: That whole Linux stealing our code thing
Krzysztof Halasa wrote: WRT Atheros driver I'd probably leave the thing as is (i.e., BSD/GPL = in fact BSD), unless something like 50+% of the code is rewritten - it's mostly their hard work after all, isn't it? Not legal requirement, though. Yes. This deserves to be reinforced: There is definite value in sharing the ath5k HAL between OpenBSD and Linux. 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 2/2]: [NET_SCHED]: Making rate table lookups more flexible.
Jesper Dangaard Brouer wrote: On Sat, 1 Sep 2007, Patrick McHardy wrote: Am I guessing right that the intention is to resurrect the ATM patch? Yes, you are right. Remember, Jamal ACKed the patch, and you redrew your NAK. Mainly out of frustration/boredom with the discussion, I withdrew that again later and even Russell agreed that this should be done differently. This is not a ATM/ADSL only patch. This patch simply adds more flexibility to the rate tables. Afterwards we can start the discussion about how to use this new flexibility in tc/iproute2. I know, but that discussion should happen *before* merging any changes to the kernel. Its pointless to add functionality that won't be used afterwards or may need to be done differently. - 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: Fwd: That whole Linux stealing our code thing
Igor Sobrado [EMAIL PROTECTED] wrote: When code is multi-licensed it must be distributed under *all* these licensing terms concurrently. No. E.g.: If I don't agree to the GPL (or if I had violated it and therefore have lost it's privileges), I MUST NOT redistribute it under the GPL because I have no license to do that, but the BSD license would still allow me to redistribute. - 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/5] Net: ath5k, use int as retval
2007/9/1, Jiri Slaby [EMAIL PROTECTED]: John W. Linville napsal(a): On Tue, Aug 28, 2007 at 12:00:09PM -0400, Jiri Slaby wrote: ath5k, use int as retval Convert some functions to return int and proper negative return value on error as we are used to. Since I didn't apply 1/5, this one didn't apply either. It seems fine overall, so if you rediff I'll be happy to apply. Ok, I'll do it, thanks, Can somebody commit my resent changes from madwifi-svn (cleanups, kconfig, remove_hw_ from filenames etc) ? I don't have git repository ;-( -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick - 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: Fwd: That whole Linux stealing our code thing
On Sun, 2 Sep 2007, Jeff Garzik wrote: Krzysztof Halasa wrote: WRT Atheros driver I'd probably leave the thing as is (i.e., BSD/GPL = in fact BSD), unless something like 50+% of the code is rewritten - it's mostly their hard work after all, isn't it? Not legal requirement, though. Yes. This deserves to be reinforced: There is definite value in sharing the ath5k HAL between OpenBSD and Linux. Of course. Sharing knowledge and efforts can only improve both the GPL and BSD licensed code. It is important in all cases, but becomes critical when support from manufacturers is limited or even non existent. In these cases, shared efforts are required to write successful code. Cheers, Igor. - 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
RTNL: assertion failed at net/core/dev.c
Wow, I should really update more often. Skipping the last -rc versions AND adding a new device (zd1211rw) to the box turns out to be quite interesting ([0],[1]). However, this time loading of a (proprietary) module is involved. Knowing that lkml cannot really help here (and I should contact vmware), I just wanted to let you netdev guys know, because the only occurences I found on the net were from 1999, but given the amount of changes currently going into net/ I thought this might be interesting: [15604.137408] RTNL: assertion failed at net/core/dev.c (2595) [15604.137772] [c0106aaa] show_trace_log_lvl+0x1a/0x30 [15604.138121] [c0107682] show_trace+0x12/0x20 [15604.138449] [c01076a5] dump_stack+0x15/0x20 [15604.138807] [c038c612] __dev_set_promiscuity+0xc2/0xd0 [15604.139163] [c038c9bb] dev_set_promiscuity+0x1b/0x40 [15604.139515] [f91cb3fb] VNetBridgeStartPromisc+0x2b/0x50 [vmnet] [15604.139896] [f91cb61a] VNetBridgePortsChanged+0x2a/0x40 [vmnet] [15604.140276] [f91c9a65] VNetHubPortsChanged+0x65/0xc0 [vmnet] [15604.140648] [f91c869a] VNetConnect+0x7a/0xb0 [vmnet] [15604.141000] [f91c926d] VNetFileOpOpen+0xbd/0x170 [vmnet] [15604.141362] [c016b213] chrdev_open+0x83/0x180 [15604.141696] [c0167321] __dentry_open+0xa1/0x1a0 [15604.142036] [c01674c5] nameidata_to_filp+0x35/0x40 [15604.142383] [c0167519] do_filp_open+0x49/0x60 [15604.142717] [c0167575] do_sys_open+0x45/0x80 [15604.142957] [c01675ec] sys_open+0x1c/0x20 [15604.143087] [c010598a] sysenter_past_esp+0x6b/0xb5 [15604.143227] === details: http://nerdbynature.de/bits/2.6.23-rc5/ Christian. [0] http://www.spinics.net/lists/netdev/msg40247.html [1] http://www.spinics.net/lists/netdev/msg40281.html -- BOFH excuse #31: cellular telephone interference - 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: RTNL: assertion failed at net/core/dev.c
On Sun, 2007-09-02 at 18:05 +0200, Christian Kujau wrote: but given the amount of changes currently going into net/ I thought this might be interesting: [15604.137408] RTNL: assertion failed at net/core/dev.c (2595) [15604.138807] [c038c612] __dev_set_promiscuity+0xc2/0xd0 [15604.139163] [c038c9bb] dev_set_promiscuity+0x1b/0x40 [15604.139515] [f91cb3fb] VNetBridgeStartPromisc+0x2b/0x50 [vmnet] Not sure why this would be interesting. Clearly, dev_set_promiscuity is called without the RTNL held while it should be. And see who the caller is? johannes signature.asc Description: This is a digitally signed message part
Re: RTNL: assertion failed at net/core/dev.c
On Sun, 2 Sep 2007 18:05:33 +0200 (CEST) Christian Kujau [EMAIL PROTECTED] wrote: Wow, I should really update more often. Skipping the last -rc versions AND adding a new device (zd1211rw) to the box turns out to be quite interesting ([0],[1]). However, this time loading of a (proprietary) module is involved. Knowing that lkml cannot really help here (and I should contact vmware), I just wanted to let you netdev guys know, because the only occurences I found on the net were from 1999, but given the amount of changes currently going into net/ I thought this might be interesting: [15604.137408] RTNL: assertion failed at net/core/dev.c (2595) [15604.137772] [c0106aaa] show_trace_log_lvl+0x1a/0x30 [15604.138121] [c0107682] show_trace+0x12/0x20 [15604.138449] [c01076a5] dump_stack+0x15/0x20 [15604.138807] [c038c612] __dev_set_promiscuity+0xc2/0xd0 [15604.139163] [c038c9bb] dev_set_promiscuity+0x1b/0x40 [15604.139515] [f91cb3fb] VNetBridgeStartPromisc+0x2b/0x50 [vmnet] Vendor module calls kernel api incorrectly. dev_set_promiscuity requires that the calling thread hold rtnl mutex (ie call rtnl_lock). It's their bug, netdev doesn't want to hear about 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: RTNL: assertion failed at net/core/dev.c
On Sun, 2 Sep 2007, Stephen Hemminger wrote: Vendor module calls kernel api incorrectly. dev_set_promiscuity requires that the calling thread hold rtnl mutex (ie call rtnl_lock). It's their bug, netdev doesn't want to hear about it. OK, that's all I needed to know. Thank you both for your comments! Christian. -- BOFH excuse #435: Internet shut down due to maintenance - 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: Fwd: That whole Linux stealing our code thing
On Sun, Sep 02, 2007 at 03:00:46PM +0200, Igor Sobrado wrote: Not strictly true. They can either agree to a change and issue one or they can convey to other parties the right to change the terms. The GPL for example does this for version selection. So, under a dual-licensed BSD/GPL code the latter license allows a developer to remove the GPL license itself and release a single-licensed BSD code if other parties want to do it? Exactly. That's what dual-licensing is. [quote] This is no different from the fact that we have some drivers that are GPLv2/BSD licensed. Within the kernel, they are GPLv2. But on their own, you can choose to use them under the BSD license, make your changes to them, and release them commercially. And correct - I cannot (and neither can anybody else) then accept those *non*GPLv2 changes back. [end quote] That's from Linus and quite recently. FWIW, it's damn hard to codify ... and changes to this code should not change the situation. It's certainly a very good policy and in this case it's the only sane policy. [quote] Actually, normally I *do* have such a trust. It's why I have no problem with drivers that are dual-GPL/BSD, and in fact, I've told people that I don't want them to turn them into GPL-only, because that is simply not polite. [end quote] Same posting from Linus. And that's much more relevant to shooting the patch in question down (and IMO it ought to be shot down) than references to legality. - 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: Fwd: That whole Linux stealing our code thing
This has been pretty interesting for me to watch as I distribute my isp driver under a dual license (at least the portions of it which are common with the *BSD and Solaris ports) that is almost identical to Sam's verbiage. I'll admit that I hadn't thought about whether redistribution included the ability to modify the header (and thus the text of the licensing as I had written) or not. On balance I'd say I believe that the arguments for, on redistribution, picking one or the other license makes sense and honored my general intent. This allows people who modify the code (and presumably improve it) a chef's choice based on where they're serving the meal. IANAL, but I believe that none of this keeps me from continuing to put a dual license on stuff I leave up for distribution, or changing that to restricting the code to Martian Triathalon winners or what have 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: [PATCH 2/2]: [NET_SCHED]: Making rate table lookups more flexible.
On Sun, 2 Sep 2007, Patrick McHardy wrote: Jesper Dangaard Brouer wrote: On Sat, 1 Sep 2007, Patrick McHardy wrote: This is not a ATM/ADSL only patch. This patch simply adds more flexibility to the rate tables. Afterwards we can start the discussion about how to use this new flexibility in tc/iproute2. I know, but that discussion should happen *before* merging any changes to the kernel. Let not try to solve too many things at once. We need to do this in small steps. Please, lets not start long and borrowing discussion again, where we try to solve too many things at once. Its pointless to add functionality that won't be used afterwards or may need to be done differently. I believe that the functionality _will_ be used, also in the general case. Lets focus on the general case, where the functionality actually is needed right away. In the general case: - The rate table needs to be aligned (cell_align=-1). (currently, we miscalculates up to 7 bytes on every lookup) - The existing tc overhead calc can be made more accurate. (by adding overhead before doing the lookup, instead of the current solution where the rate table is modified with its limited resolution) Patrick, note that your STAB solution will _not_ work without the rate table alignment. See you! Jesper Brouer -- --- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk --- - 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 -mm] sunrpc svc: Shut up bogus uninitialized variable warning
net/sunrpc/svc.c: In function ‘__svc_create_thread’: net/sunrpc/svc.c:550: warning: ‘oldmask.bits[0u]’ may be used uninitialized in this function is a bogus warning, but gcc isn't smart enough to see why. We cannot just reorganize the code in the function, because we want the set_cpus_allowed() restore to happen only after the kernel_thread() is forked. Alas, we have to use cpus_clear() to initialize oldmask instead to keep gcc happy. Also add some comments to describe what's happening in the function. Signed-off-by: Satyam Sharma [EMAIL PROTECTED] --- net/sunrpc/svc.c |7 +++ 1 file changed, 7 insertions(+) --- linux-2.6.23-rc4-mm1/net/sunrpc/svc.c~fix 2007-09-02 22:55:25.0 +0530 +++ linux-2.6.23-rc4-mm1/net/sunrpc/svc.c 2007-09-02 23:03:45.0 +0530 @@ -568,17 +568,24 @@ __svc_create_thread(svc_thread_fn func, rqstp-rq_server = serv; rqstp-rq_pool = pool; + /* Only to prevent gcc warning */ + cpus_clear(oldmask); + + /* Temporarily change CPU affinity before forking svc thread */ if (serv-sv_nrpools 1) have_oldmask = svc_pool_map_set_cpumask(pool-sp_id, oldmask); + /* Will inherit current-cpus_allowed */ error = kernel_thread((int (*)(void *)) func, rqstp, 0); + /* Restore old cpus_allowed */ if (have_oldmask) set_cpus_allowed(current, oldmask); if (error 0) goto out_thread; svc_sock_update_bufs(serv); + error = 0; out: return error;
Re: potentially kernel panic on lib/rbtree.c
Hm... Not good. After patch NETCONSOLE log: THERE MANY MESSAGES LIKE DOWN [16038.677029] WARNING: at net/sched/sch_htb.c:362 htb_safe_rb_erase() [16038.677031] [f8862a45] htb_dequeue+0x13d/0x6d2 [sch_htb] [16038.677038] [c02a71af] __qdisc_run+0x2a/0x16b [16038.677043] [c029cfc1] dev_queue_xmit+0x18b/0x2a6 [16038.677048] [c02b94e3] ip_output+0x281/0x2ba [16038.677054] [c02b571c] ip_forward_finish+0x0/0x2e [16038.677059] [c02b59b5] ip_forward+0x26b/0x2c6 [16038.677064] [c02b571c] ip_forward_finish+0x0/0x2e [16038.677070] [c02b4729] ip_rcv+0x484/0x4bd [16038.677075] [c029750b] __netdev_alloc_skb+0x1c/0x35 [16038.677081] [c029ab9c] netif_receive_skb+0x2cd/0x340 [16038.677086] [c0234ef1] e1000_clean_rx_irq+0x379/0x448 [16038.677092] [c0234b78] e1000_clean_rx_irq+0x0/0x448 [16038.677097] [c0233f8f] e1000_clean+0x7a/0x249 [16038.677103] [c029ccad] net_rx_action+0x91/0x17f [16038.677108] [c01225e2] __do_softirq+0x5d/0xc1 [16038.677114] [c0122678] do_softirq+0x32/0x36 [16038.677118] [c010488a] do_IRQ+0x7e/0x90 [16038.677123] [c0111619] smp_apic_timer_interrupt+0x74/0x80 [16038.677128] [c02ea9d5] __sched_text_start+0x54d/0x5ba [16038.677134] [c0100d65] mwait_idle+0x0/0xa [16038.677139] [c01032eb] common_interrupt+0x23/0x28 [16038.677144] [c0100d61] mwait_idle_with_hints+0x3b/0x3f [16038.677149] [c0100d65] mwait_idle+0x0/0xa [16038.677154] [c0100ea4] cpu_idle+0x91/0xaa [16038.677159] === [16038.677161] WARNING: at net/sched/sch_htb.c:362 htb_safe_rb_erase() [16038.677163] [f8862a45] htb_dequeue+0x13d/0x6d2 [sch_htb] [16038.677170] [c02a71af] __qdisc_run+0x2a/0x16b [16038.677175] [c029cfc1] dev_queue_xmit+0x18b/0x2a6 [16038.677180] [c02b94e3] ip_output+0x281/0x2ba [16038.677185] [c02b571c] ip_forward_finish+0x0/0x2e [16038.677191] [c02b59b5] ip_forward+0x26b/0x2c6 [16038.677196] [c02b571c] ip_forward_finish+0x0/0x2e [16038.677202] [c02b4729] ip_rcv+0x484/0x4bd [16038.677207] [c029750b] __netdev_alloc_skb+0x1c/0x35 [16038.677212] [c029ab9c] netif_receive_skb+0x2cd/0x340 [16038.677218] [c0234ef1] e1000_clean_rx_irq+0x379/0x448 [16038.677224] [c0234b78] e1000_clean_rx_irq+0x0/0x448 [16038.677229] [c0233f8f] e1000_clean+0x7a/0x249 [16038.677234] [c029ccad] net_rx_action+0x91/0x17f [16038.677240] [c01225e2] __do_softirq+0x5d/0xc1 [16038.677245] [c0122678] do_softirq+0x32/0x36 [16038.677250] [c010488a] do_IRQ+0x7e/0x90 [16038.677255] [c0111619] smp_apic_timer_interrupt+0x74/0x80 [16038.677260] [c02ea9d5] __sched_text_start+0x54d/0x5ba [16038.677266] [c0100d65] mwait_idle+0x0/0xa [16038.677270] [c01032eb] common_interrupt+0x23/0x28 [16038.677276] [c0100d61] mwait_idle_with_hints+0x3b/0x3f [16038.677281] [c0100d65] mwait_idle+0x0/0xa [16038.677285] [c0100ea4] cpu_idle+0x91/0xaa [16038.677290] === [16038.677293] WARNING: at net/sched/sch_htb.c:362 htb_safe_rb_erase() [16038.677295] [f8862a45] htb_dequeue+0x13d/0x6d2 [sch_htb] [16038.677301] [c02a71af] __qdisc_run+0x2a/0x16b [16038.677306] [c029cfc1] dev_queue_xmit+0x18b/0x2a6 [16038.677312] [c02b94e3] ip_output+0x281/0x2ba [16038.677317] [c02b571c] ip_forward_finish+0x0/0x2e [16038.677323] [c02b59b5] ip_forward+0x26b/0x2c6 [16038.677328] [c02b571c] ip_forward_finish+0x0/0x2e [16038.677333] [c02b4729] ip_rcv+0x484/0x4bd [16038.677339] [c029750b] __netdev_alloc_skb+0x1c/0x35 [16038.677344] [c029ab9c] netif_receive_skb+0x2cd/0x340 [16038.677350] [c0234ef1] e1000_clean_rx_irq+0x379/0x448 [16038.677356] [c0234b78] e1000_clean_rx_irq+0x0/0x448 [16038.677361] [c0233f8f] e1000_clean+0x7a/0x249 [16038.677366] [c029ccad] net_rx_action+0x91/0x17f [16038.677372] [c01225e2] __do_softirq+0x5d/0xc1 [16038.677377] [c0122678] do_softirq+0x32/0x36 [16038.677382] [c010488a] do_IRQ+0x7e/0x90 [16038.677387] [c0111619] smp_apic_timer_interrupt+0x74/0x80 [16038.677393] [c02ea9d5] __sched_text_start+0x54d/0x5ba [16038.677398] [c0100d65] mwait_idle+0x0/0xa [16038.677403] [c01032eb] common_interrupt+0x23/0x28 [16038.677408] [c0100d61] mwait_idle_with_hints+0x3b/0x3f [16038.677413] [c0100d65] mwait_idle+0x0/0xa [16038.677417] [c0100ea4] cpu_idle+0x91/0xaa [16038.677422] === [16038.677425] WARNING: at net/sched/sch_htb.c:362 htb_safe_rb_erase() [16038.677427] [f8862a45] htb_dequeue+0x13d/0x6d2 [sch_htb] [16038.677433] [c02a71af] __qdisc_run+0x2a/0x16b [16038.677439] [c029cfc1] dev_queue_xmit+0x18b/0x2a6 [16038.677444] [c02b94e3] ip_output+0x281/0x2ba [16038.677450] [c02b571c] ip_forward_finish+0x0/0x2e [16038.677455] [c02b59b5] ip_forward+0x26b/0x2c6 [16038.677460] [c02b571c] ip_forward_finish+0x0/0x2e [16038.677466] [c02b4729] ip_rcv+0x484/0x4bd [16038.677471] [c029750b] __netdev_alloc_skb+0x1c/0x35 [16038.677476] [c029ab9c] netif_receive_skb+0x2cd/0x340 [16038.677482] [c0234ef1] e1000_clean_rx_irq+0x379/0x448 [16038.677488] [c0234b78] e1000_clean_rx_irq+0x0/0x448 [16038.677493] [c0233f8f] e1000_clean+0x7a/0x249 [16038.677498] [c029ccad]
Re: 2.6.23-rc4-mm1: unpingable box and NULL dereference at tcp_rto_min()
On Sun, 2 Sep 2007 06:36:19 +0400 Alexey Dobriyan [EMAIL PROTECTED] wrote: On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/ - dynticks-for-x86_64 has returned Good news is that, contary to popular belief, -mm is not horrible piece of crap and NO_HZ on x86_64 worked here straight away. variable. It at least Works For Me before it goes out. The bad news is something knocked off box from the net, then panicked it: Yeah, the net tree has been quite bad lately. Unusually bad - it's usually one of the good ones. It also breaks a lot of the net driver work in several other trees (I dropped git-ixgbe.patch wholesale because of this). But there isn't a lot we can do about 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 2/2]: [NET_SCHED]: Making rate table lookups more flexible.
Jesper Dangaard Brouer wrote: On Sun, 2 Sep 2007, Patrick McHardy wrote: This is not a ATM/ADSL only patch. This patch simply adds more flexibility to the rate tables. Afterwards we can start the discussion about how to use this new flexibility in tc/iproute2. I know, but that discussion should happen *before* merging any changes to the kernel. Let not try to solve too many things at once. We need to do this in small steps. Please, lets not start long and borrowing discussion again, where we try to solve too many things at once. We don't need many, but we do need *one* thing that actually uses this and isn't controversial before merging. Its pointless to add functionality that won't be used afterwards or may need to be done differently. I believe that the functionality _will_ be used, also in the general case. Lets focus on the general case, where the functionality actually is needed right away. In the general case: - The rate table needs to be aligned (cell_align=-1). (currently, we miscalculates up to 7 bytes on every lookup) We will always do that, thats a consequence of storing the transmission times for multiples of 8b. - The existing tc overhead calc can be made more accurate. (by adding overhead before doing the lookup, instead of the current solution where the rate table is modified with its limited resolution) Please demonstrate this with patches (one for the overhead calculation, one for the cell_align thing), then we can continue this discussion. Patrick, note that your STAB solution will _not_ work without the rate table alignment. I can't argue about this without looking into it again first, but it shouldn't really matter for now since we don't have a patch to actually implement 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: 2.6.23-rc4-mm1: unpingable box and NULL dereference at tcp_rto_min()
On Sun, Sep 02, 2007 at 01:52:45PM -0700, Andrew Morton wrote: On Sun, 2 Sep 2007 06:36:19 +0400 Alexey Dobriyan [EMAIL PROTECTED] wrote: The bad news is something knocked off box from the net, then panicked it: Yeah, the net tree has been quite bad lately. Unusually bad - it's usually one of the good ones. It also breaks a lot of the net driver work in several other trees (I dropped git-ixgbe.patch wholesale because of this). But there isn't a lot we can do about that. OK, I'm currently running with dst entry can be NULL fix from net tree, so far it's fine. - 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: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Hi, On 01/09/07, Karl Meyer [EMAIL PROTECTED] wrote: This is what happened today: Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out frege ~ # uname -r 2.6.22.5-cfs-v20.5 Can you reproduce this on 2.6.22 (not 2.6.22.x - it might be a -stable regression)? Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Hi, am am looking for this issue for some time now, but there where no errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2 officially), I also ran git-bisect (for more information see the older messages in this thread). 2007/9/3, Michal Piotrowski [EMAIL PROTECTED]: Hi, On 01/09/07, Karl Meyer [EMAIL PROTECTED] wrote: This is what happened today: Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out frege ~ # uname -r 2.6.22.5-cfs-v20.5 Can you reproduce this on 2.6.22 (not 2.6.22.x - it might be a -stable regression)? Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: BUG: scheduling while atomic: ifconfig/0x00000002/4170
Hi, [Adding netdev and wireless to CC] On 02/09/07, Florian Lohoff [EMAIL PROTECTED] wrote: Hi, with current git i got this when ifconfig eth1 down. eth1 had a mac address which looked really like an eth1394 ethernet although the module was not loaded. Something is really broken in 2.6.23-currentgit. I always get the sysfs rename issues which are discussed to be an udev issue. Then i see a eth1394 mac address on an interface which typically shouldn exist (udev should rename the wireless to eth1) and when issueing an ifconfig eth1 down i get a BUG: scheduling while atomic: ifconfig/0x0002/4170 On the next boot i see the eth1394 mac address on the wireless interface wmaster0_rename whereas eth1 is active (the wireless) and has the correct ip address. I dont get it - this all looks really messed up. udev is debian sid 114-2. eth0 Link encap:Ethernet HWaddr 00:17:42:13:45:8C UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:19 eth1 Link encap:Ethernet HWaddr 00:18:DE:63:F0:B3 inet addr:195.71.97.208 Bcast:195.71.97.223 Mask:255.255.255.224 inet6 addr: fe80::218:deff:fe63:f0b3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2079 errors:0 dropped:0 overruns:0 frame:0 TX packets:2220 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:508959 (497.0 KiB) TX bytes:261123 (255.0 KiB) wmaster0_ Link encap:UNSPEC HWaddr 00-18-DE-63-F0-B3-30-3A-00-00-00-00-00-00-00-00 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) [ 14.300736] VFS: Mounted root (ext3 filesystem) readonly. [ 14.300902] Freeing unused kernel memory: 216k freed [ 17.618804] irda_init() [ 17.618817] NET: Registered protocol family 23 [ 17.636399] ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 19 [ 17.636588] PCI: Setting latency timer of device :02:00.0 to 64 [ 17.636619] sky2 :02:00.0: v1.17 addr 0xf000 irq 19 Yukon-EC Ultra (0xb4) rev 2 [ 17.648081] parport_pc 00:0c: reported by Plug and Play ACPI [ 17.648206] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP] [ 17.653652] sky2 eth0: addr 00:17:42:13:45:8c [ 17.680848] input: Video Bus as /class/input/input6 [ 17.680961] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 17.757019] usbcore: registered new interface driver usbfs [ 17.757139] usbcore: registered new interface driver hub [ 17.757264] usbcore: registered new device driver usb [ 17.824819] Yenta: CardBus bridge found at :08:03.0 [10cf:131e] [ 17.824941] Yenta O2: res at 0x94/0xD4: 00/ea [ 17.825034] Yenta O2: enabling read prefetch/write burst [ 17.828363] hda: ATAPI 24X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33) [ 17.828838] Uniform CD-ROM driver Revision: 3.20 [ 17.891481] USB Universal Host Controller Interface driver v3.0 [ 17.891650] ACPI: PCI Interrupt :00:1d.0[A] - GSI 23 (level, low) - IRQ 22 [ 17.891840] PCI: Setting latency timer of device :00:1d.0 to 64 [ 17.891844] uhci_hcd :00:1d.0: UHCI Host Controller [ 17.892155] uhci_hcd :00:1d.0: new USB bus registered, assigned bus number 1 [ 17.892327] uhci_hcd :00:1d.0: irq 22, io base 0x1820 [ 17.892571] usb usb1: configuration #1 chosen from 1 choice [ 17.892689] hub 1-0:1.0: USB hub found [ 17.892784] hub 1-0:1.0: 2 ports detected [ 17.924265] found SMC SuperIO Chip (devid=0x7a rev=00 base=0x002e): LPC47N227 [ 17.924390] smsc_superio_flat(): fir: 0x6e8, sir: 0x2e8, dma: 03, irq: 3, mode: 0x0e [ 17.924526] smsc_ircc_present: can't get sir_base of 0x2e8 [ 17.954918] Yenta: ISA IRQ mask 0x0c38, PCI irq 19 [ 17.955009] Socket status: 3006 [ 17.955094] Yenta: Raising subordinate bus# of parent bus (#08) from #09 to #0c [ 17.955225] pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff [ 17.955315] cs: IO port probe 0x3000-0x3fff: clean. [ 17.955773] pcmcia: parent PCI bridge Memory window: 0xf020 - 0xf02f [ 17.955864] pcmcia: parent PCI bridge Memory window: 0x3000 - 0x37ff [ 17.956497] Yenta: CardBus bridge found at :08:03.1 [10cf:131e] [ 17.981605] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 0.1.14 [ 17.981752] iwl3945: Copyright(c) 2003-2007 Intel Corporation [ 17.983847] sdhci: Secure Digital Host Controller Interface driver [ 17.983940] sdhci:
[PATCH 3/3] netxen: ethtool fixes
Resubmitting the patch.
This patch improves ethtool support for printing correct ring statistics,
segmentation offload status, etc.
Signed-off by: Dhananjay Phadke [EMAIL PROTECTED]
Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic.h
@@ -918,7 +918,7 @@ struct netxen_adapter {
u16 link_duplex;
u16 state;
u16 link_autoneg;
- int rcsum;
+ int rx_csum;
int status;
spinlock_t stats_lock;
Index: netdev-2.6/drivers/net/netxen/netxen_nic_ethtool.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_ethtool.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_ethtool.c
@@ -518,17 +518,17 @@ netxen_nic_get_ringparam(struct net_devi
ring-rx_jumbo_pending = 0;
for (i = 0; i MAX_RCV_CTX; ++i) {
ring-rx_pending += adapter-recv_ctx[i].
- rcv_desc[RCV_DESC_NORMAL_CTXID].rcv_pending;
+ rcv_desc[RCV_DESC_NORMAL_CTXID].max_rx_desc_count;
ring-rx_jumbo_pending += adapter-recv_ctx[i].
- rcv_desc[RCV_DESC_JUMBO_CTXID].rcv_pending;
+ rcv_desc[RCV_DESC_JUMBO_CTXID].max_rx_desc_count;
}
+ ring-tx_pending = adapter-max_tx_desc_count;
- ring-rx_max_pending = adapter-max_rx_desc_count;
- ring-tx_max_pending = adapter-max_tx_desc_count;
- ring-rx_jumbo_max_pending = adapter-max_jumbo_rx_desc_count;
+ ring-rx_max_pending = MAX_RCV_DESCRIPTORS;
+ ring-tx_max_pending = MAX_CMD_DESCRIPTORS_HOST;
+ ring-rx_jumbo_max_pending = MAX_JUMBO_RCV_DESCRIPTORS;
ring-rx_mini_max_pending = 0;
ring-rx_mini_pending = 0;
- ring-rx_jumbo_pending = 0;
}
static void
@@ -731,6 +731,19 @@ netxen_nic_get_ethtool_stats(struct net_
}
}
+static u32 netxen_nic_get_rx_csum(struct net_device *dev)
+{
+ struct netxen_adapter *adapter = netdev_priv(dev);
+ return adapter-rx_csum;
+}
+
+static int netxen_nic_set_rx_csum(struct net_device *dev, u32 data)
+{
+ struct netxen_adapter *adapter = netdev_priv(dev);
+ adapter-rx_csum = !!data;
+ return 0;
+}
+
struct ethtool_ops netxen_nic_ethtool_ops = {
.get_settings = netxen_nic_get_settings,
.set_settings = netxen_nic_set_settings,
@@ -755,4 +768,7 @@ struct ethtool_ops netxen_nic_ethtool_op
.get_strings = netxen_nic_get_strings,
.get_stats_count = netxen_nic_get_stats_count,
.get_ethtool_stats = netxen_nic_get_ethtool_stats,
+ .get_rx_csum = netxen_nic_get_rx_csum,
+ .set_rx_csum = netxen_nic_set_rx_csum,
+ .get_ufo = ethtool_op_get_ufo,
};
Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -408,6 +408,7 @@ netxen_nic_probe(struct pci_dev *pdev, c
/* This will be reset for mezz cards */
adapter-portnum = pci_func_id;
adapter-status = ~NETXEN_NETDEV_STATUS;
+ adapter-rx_csum = 1;
netdev-open = netxen_nic_open;
netdev-stop = netxen_nic_close;
Index: netdev-2.6/drivers/net/netxen/netxen_nic_init.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_init.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_init.c
@@ -1118,10 +1118,13 @@ netxen_process_rcv(struct netxen_adapter
skb = (struct sk_buff *)buffer-skb;
- if (likely(netxen_get_sts_status(desc) == STATUS_CKSUM_OK)) {
+ if (likely(adapter-rx_csum
+ netxen_get_sts_status(desc) ==
STATUS_CKSUM_OK)) {
adapter-stats.csummed++;
skb-ip_summed = CHECKSUM_UNNECESSARY;
- }
+ } else
+ skb-ip_summed = CHECKSUM_NONE;
+
skb-dev = netdev;
if (desc_ctx == RCV_DESC_LRO_CTXID) {
/* True length was only available on the last pkt */
-
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
