Re: [PATCH] per-task delay accounting taskstats interface: control exit data through cpumasks]
Andrew wrote: Your email client performs space-stuffing. Shailabh, Some of us find that it is easier and more reliable to use a special purpose script to send patches, rather than trying to do so via our email client. Even though my email client, Sylpheed, probably sends patches just fine, I enjoy the convenience of preparing the patches and mailing instructions in my editor, before sending them off with such a utility. One possible such utility is 'sendpatchset', which I maintain: http://www.speakeasy.org/~pj99/sgi/sendpatchset It's a script, with the documentation embedded as the help message. Especially when sending off multiple patches as a set, it provides more reliable results than trying to prepare and send multiple such simultaneous messages from the typical email client. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - 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: RDMA will be reverted
From: Tom Tucker [EMAIL PROTECTED] Date: Thu, 06 Jul 2006 00:25:03 -0500 This patch is about dotting I's and crossing T's, it's not about foundations. You assume that I've flat out rejected RDMA, in fact I haven't. I really don't have enough information to form a final opinion yet. There's about a week of emails on this topic which I need to read and digest first. What I am saying, however, is that we need to understand the technology and the hooks you guys want before we put any of it in. I don't think that's unreasonable. - 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 0/3] Action API fixes
From: jamal [EMAIL PROTECTED] Date: Thu, 06 Jul 2006 08:03:48 -0400 Dave, Did you actually read my comments on the patches? One patch deserved to go to stable and one was the wrong fix. Should i now send a patch against the one? I read your comments. Thomas's patches were correct, you comments were refinements at best. - 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 0/3] Action API fixes
From: Thomas Graf [EMAIL PROTECTED] Date: Thu, 6 Jul 2006 14:45:39 +0200 * jamal [EMAIL PROTECTED] 2006-07-06 08:27 The proper patch is attached as a replacement for [PATCH 3/3] [PKT_SCHED]: Fix error handling while dumping action from Thomas. If you have already submitted it, then i will send a patch against it. I don't understand why you're picky about this but if you really want to then do it properly and remove the now unused err variable, don't leave obscure code behind again. I don't either, I think Thomas's patch was correct and that's why his is the one I applied. Sometimes it is necessary for one to buffer their resistence to the way someone fixes you code and just let it go. Otherwise people won't even bother trying to fix those bugs. People who do the work make the rules, that is my supreme motto. And here that is Thomas, and therefore I will favor in the direction of his judgement. - 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 7/9] 8139cp.c printk fix
From: Andrew Morton [EMAIL PROTECTED]
drivers/net/8139cp.c: In function 'cp_init_one':
drivers/net/8139cp.c:1919: warning: format '%lx' expects type 'long unsigned
int', but argument 4 has type 'resource_size_t'
drivers/net/8139cp.c:1919: warning: format '%lx' expects type 'long unsigned
int', but argument 5 has type 'resource_size_t'
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/8139cp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/8139cp.c~8139cp-printk-fix drivers/net/8139cp.c
--- a/drivers/net/8139cp.c~8139cp-printk-fix
+++ a/drivers/net/8139cp.c
@@ -1916,7 +1916,7 @@ static int cp_init_one (struct pci_dev *
regs = ioremap(pciaddr, CP_REGS_SIZE);
if (!regs) {
rc = -EIO;
- dev_err(pdev-dev, Cannot map PCI MMIO ([EMAIL PROTECTED])\n,
+ dev_err(pdev-dev, Cannot map PCI MMIO ([EMAIL PROTECTED])\n,
(unsigned long long)pci_resource_len(pdev, 1),
(unsigned long long)pciaddr);
goto err_out_res;
_
-
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/9] e1000: irq naming update
From: Andrew Morton [EMAIL PROTECTED] Use the new names. Cc: Auke Kok [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/e1000/e1000_main.c~e1000-irq-naming-update drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c~e1000-irq-naming-update +++ a/drivers/net/e1000/e1000_main.c @@ -283,7 +283,7 @@ static int e1000_request_irq(struct e100 } } if (adapter-have_msi) - flags = ~SA_SHIRQ; + flags = ~IRQF_SHARED; #endif if ((err = request_irq(adapter-pdev-irq, e1000_intr, flags, netdev-name, netdev))) _ - 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 8/9] smsc-ircc2: fix section reference mismatches
From: Dmitry Torokhov [EMAIL PROTECTED]
subsystem_configurations array is only used by an __init function,
therefore it should be marked __initdata, not __devinitdata.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/irda/smsc-ircc2.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN
drivers/net/irda/smsc-ircc2.c~smsc-ircc2-fix-section-reference-mismatches
drivers/net/irda/smsc-ircc2.c
--- a/drivers/net/irda/smsc-ircc2.c~smsc-ircc2-fix-section-reference-mismatches
+++ a/drivers/net/irda/smsc-ircc2.c
@@ -2353,7 +2353,7 @@ static int __init smsc_superio_lpc(unsig
#ifdef CONFIG_PCI
#define PCIID_VENDOR_INTEL 0x8086
#define PCIID_VENDOR_ALI 0x10b9
-static struct smsc_ircc_subsystem_configuration subsystem_configurations[]
__devinitdata = {
+static struct smsc_ircc_subsystem_configuration subsystem_configurations[]
__initdata = {
{
.vendor = PCIID_VENDOR_INTEL, /* Intel 82801DBM LPC bridge */
.device = 0x24cc,
_
-
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 4/9] s2io driver irq fix
From: Ananda Raju [EMAIL PROTECTED]
Modification and bug fixes with respect to irq registration.
- Enable interrupts after request_irq
- Restored MSI data register value at driver unload time
Signed-off-by: Ananda Raju [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/s2io.c | 287 +--
drivers/net/s2io.h |5
2 files changed, 146 insertions(+), 146 deletions(-)
diff -puN drivers/net/s2io.c~s2io-driver-irq-fix drivers/net/s2io.c
--- a/drivers/net/s2io.c~s2io-driver-irq-fix
+++ a/drivers/net/s2io.c
@@ -1976,7 +1976,6 @@ static int start_nic(struct s2io_nic *ni
XENA_dev_config_t __iomem *bar0 = nic-bar0;
struct net_device *dev = nic-dev;
register u64 val64 = 0;
- u16 interruptible;
u16 subid, i;
mac_info_t *mac_control;
struct config_param *config;
@@ -2047,16 +2046,6 @@ static int start_nic(struct s2io_nic *ni
return FAILURE;
}
- /* Enable select interrupts */
- if (nic-intr_type != INTA)
- en_dis_able_nic_intrs(nic, ENA_ALL_INTRS, DISABLE_INTRS);
- else {
- interruptible = TX_TRAFFIC_INTR | RX_TRAFFIC_INTR;
- interruptible |= TX_PIC_INTR | RX_PIC_INTR;
- interruptible |= TX_MAC_INTR | RX_MAC_INTR;
- en_dis_able_nic_intrs(nic, interruptible, ENABLE_INTRS);
- }
-
/*
* With some switches, link might be already up at this point.
* Because of this weird behavior, when we enable laser,
@@ -3749,101 +3738,19 @@ static int s2io_open(struct net_device *
if (err) {
DBG_PRINT(ERR_DBG, %s: H/W initialization failed\n,
dev-name);
- if (err == -ENODEV)
- goto hw_init_failed;
- else
- goto hw_enable_failed;
- }
-
- /* Store the values of the MSIX table in the nic_t structure */
- store_xmsi_data(sp);
-
- /* After proper initialization of H/W, register ISR */
- if (sp-intr_type == MSI) {
- err = request_irq((int) sp-pdev-irq, s2io_msi_handle,
- IRQF_SHARED, sp-name, dev);
- if (err) {
- DBG_PRINT(ERR_DBG, %s: MSI registration \
-failed\n, dev-name);
- goto isr_registration_failed;
- }
- }
- if (sp-intr_type == MSI_X) {
- int i;
-
- for (i=1; (sp-s2io_entries[i].in_use == MSIX_FLG); i++) {
- if (sp-s2io_entries[i].type == MSIX_FIFO_TYPE) {
- sprintf(sp-desc1, %s:MSI-X-%d-TX,
- dev-name, i);
- err = request_irq(sp-entries[i].vector,
- s2io_msix_fifo_handle, 0, sp-desc1,
- sp-s2io_entries[i].arg);
- DBG_PRINT(ERR_DBG, %s @ 0x%llx\n, sp-desc1,
- (unsigned long long)sp-msix_info[i].addr);
- } else {
- sprintf(sp-desc2, %s:MSI-X-%d-RX,
- dev-name, i);
- err = request_irq(sp-entries[i].vector,
- s2io_msix_ring_handle, 0, sp-desc2,
- sp-s2io_entries[i].arg);
- DBG_PRINT(ERR_DBG, %s @ 0x%llx\n, sp-desc2,
-(unsigned long long)sp-msix_info[i].addr);
- }
- if (err) {
- DBG_PRINT(ERR_DBG, %s: MSI-X-%d registration \
-failed\n, dev-name, i);
- DBG_PRINT(ERR_DBG, Returned: %d\n, err);
- goto isr_registration_failed;
- }
- sp-s2io_entries[i].in_use = MSIX_REGISTERED_SUCCESS;
- }
- }
- if (sp-intr_type == INTA) {
- err = request_irq((int) sp-pdev-irq, s2io_isr, IRQF_SHARED,
- sp-name, dev);
- if (err) {
- DBG_PRINT(ERR_DBG, %s: ISR registration failed\n,
- dev-name);
- goto isr_registration_failed;
- }
+ goto hw_init_failed;
}
if (s2io_set_mac_addr(dev, dev-dev_addr) == FAILURE) {
DBG_PRINT(ERR_DBG, Set Mac Address Failed\n);
+ s2io_card_down(sp);
err = -ENODEV;
- goto setting_mac_address_failed;
+ goto hw_init_failed;
}
netif_start_queue(dev);
return 0;
-setting_mac_address_failed:
- if (sp-intr_type != MSI_X)
-
[patch 1/2] via-ircc: fix memory leak
From: Chuck Short [EMAIL PROTECTED]
Fix memory leak.
Coverity id# 653
patch location:
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=a1f34cb68b16807ed9d5ebb0f6a6ec5ff8a5fc78
Signed-off-by: Chuck Short [EMAIL PROTECTED]
Signed-off-by: Ben Collins [EMAIL PROTECTED]
Cc: Samuel Ortiz [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/irda/via-ircc.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff -puN drivers/net/irda/via-ircc.c~via-ircc-fix-memory-leak
drivers/net/irda/via-ircc.c
--- a/drivers/net/irda/via-ircc.c~via-ircc-fix-memory-leak
+++ a/drivers/net/irda/via-ircc.c
@@ -1220,8 +1220,13 @@ static int upload_rxdata(struct via_ircc
IRDA_DEBUG(2, %s(): len=%x\n, __FUNCTION__, len);
+ if ((len - 4) 2) {
+ self-stats.rx_dropped++;
+ return FALSE;
+ }
+
skb = dev_alloc_skb(len + 1);
- if ((skb == NULL) || ((len - 4) 2)) {
+ if (skb == NULL) {
self-stats.rx_dropped++;
return FALSE;
}
_
-
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: [e1000]: flow control on by default - good idea really?
From: jamal [EMAIL PROTECTED] Date: Thu, 06 Jul 2006 09:03:38 -0400 On Wed, 2006-05-07 at 22:45 +0200, Krzysztof Oledzki wrote: On Wed, 5 Jul 2006, Auke Kok wrote: David Miller wrote: From: jamal [EMAIL PROTECTED] Date: Tue, 04 Jul 2006 15:20:39 -0400 BTW, As an addendum this default behavior changed around 2.6.16 it seems. Flow control has been on by default in the tg3 driver since the beginning, Are you sure about this Dave?;- because I do have a tg3 on my laptop. [EMAIL PROTECTED]:~/Desktop/maemo$ sudo ethtool -a eth0 Pause parameters for eth0: Autonegotiate: on RX: off TX: off It's autonegotiated, check you kernel message logs when the link came up, you'll see this: tg3: eth0: Flow control is on for TX and on for RX. Take care. - 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 6/9] lockdep: annotate 8390.c disable_irq(), #2
From: Arjan van de Ven [EMAIL PROTECTED]
The ne2000 drivers use disable_irq as a poor mans locking construct; make
sure lockdep knows about these.
NOTE NOTE: the ne2000 driver calls these *from interrupt context*. That's
a new situation that needs to be analyzed for correctness still; it feels
really wrong to me (but then again so does disable_irq() tricks in general)
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/8390.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff -puN drivers/net/8390.c~lockdep-annotate-8390c-disable_irq-2
drivers/net/8390.c
--- a/drivers/net/8390.c~lockdep-annotate-8390c-disable_irq-2
+++ a/drivers/net/8390.c
@@ -299,7 +299,7 @@ static int ei_start_xmit(struct sk_buff
* Slow phase with lock held.
*/
- disable_irq_nosync(dev-irq);
+ disable_irq_nosync_lockdep(dev-irq);
spin_lock(ei_local-page_lock);
@@ -338,7 +338,7 @@ static int ei_start_xmit(struct sk_buff
netif_stop_queue(dev);
outb_p(ENISR_ALL, e8390_base + EN0_IMR);
spin_unlock(ei_local-page_lock);
- enable_irq(dev-irq);
+ enable_irq_lockdep(dev-irq);
ei_local-stat.tx_errors++;
return 1;
}
@@ -379,7 +379,7 @@ static int ei_start_xmit(struct sk_buff
outb_p(ENISR_ALL, e8390_base + EN0_IMR);
spin_unlock(ei_local-page_lock);
- enable_irq(dev-irq);
+ enable_irq_lockdep(dev-irq);
dev_kfree_skb (skb);
ei_local-stat.tx_bytes += send_length;
@@ -505,9 +505,9 @@ irqreturn_t ei_interrupt(int irq, void *
#ifdef CONFIG_NET_POLL_CONTROLLER
void ei_poll(struct net_device *dev)
{
- disable_irq(dev-irq);
+ disable_irq_lockdep(dev-irq);
ei_interrupt(dev-irq, dev, NULL);
- enable_irq(dev-irq);
+ enable_irq_lockdep(dev-irq);
}
#endif
_
-
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/9] natsemi: Add support for using MII port with no PHY
From: Mark Brown [EMAIL PROTECTED]
Provide a module option which configures the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to it.
The link state will be left as it was when the driver started and can be
configured via ethtool. Any PHYs that are present can be accessed via the MII
ioctl()s.
This is useful for systems where the device is connected without a PHY or
where either information or actions outside the scope of the driver are
required in order to use the PHYs.
Jeff sez:
NAK.
The proper way to do this is via the force_media boolean flag found in
several net drivers.
In general I agree with the motivation to do something like this...
Signed-off-by: Mark Brown [EMAIL PROTECTED]
Cc: Tim Hockin [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/natsemi.c | 105 +---
1 file changed, 67 insertions(+), 38 deletions(-)
diff -puN
drivers/net/natsemi.c~natsemi-add-support-for-using-mii-port-with-no-phy
drivers/net/natsemi.c
--- a/drivers/net/natsemi.c~natsemi-add-support-for-using-mii-port-with-no-phy
+++ a/drivers/net/natsemi.c
@@ -146,7 +146,7 @@ MODULE_PARM_DESC(debug, DP8381x default
MODULE_PARM_DESC(rx_copybreak,
DP8381x copy breakpoint for copy-only-tiny-frames);
MODULE_PARM_DESC(options,
- DP8381x: Bits 0-3: media type, bit 17: full duplex);
+ DP8381x: Bits 0-3: media type, bit 17: full duplex, bit 18: ignore
PHY);
MODULE_PARM_DESC(full_duplex, DP8381x full duplex setting(s) (1));
/*
@@ -568,6 +568,8 @@ struct netdev_private {
u32 intr_status;
/* Do not touch the nic registers */
int hands_off;
+ /* Don't pay attention to the reported link state. */
+ int ignore_phy;
/* external phy that is used: only valid if dev-if_port != PORT_TP */
int mii;
int phy_addr_external;
@@ -696,7 +698,10 @@ static void __devinit natsemi_init_media
struct netdev_private *np = netdev_priv(dev);
u32 tmp;
- netif_carrier_off(dev);
+ if (np-ignore_phy)
+ netif_carrier_on(dev);
+ else
+ netif_carrier_off(dev);
/* get the initial settings from hardware */
tmp= mdio_read(dev, MII_BMCR);
@@ -807,7 +812,19 @@ static int __devinit natsemi_probe1 (str
np-intr_status = 0;
np-eeprom_size = natsemi_pci_info[chip_idx].eeprom_size;
+ option = find_cnt MAX_UNITS ? options[find_cnt] : 0;
+ if (dev-mem_start)
+ option = dev-mem_start;
+
+ /* Ignore the PHY status? */
+ if (option 0x400) {
+ np-ignore_phy = 1;
+ } else {
+ np-ignore_phy = 0;
+ }
+
/* Initial port:
+* - If configured to ignore the PHY set up for external.
* - If the nic was configured to use an external phy and if find_mii
* finds a phy: use external port, first phy that replies.
* - Otherwise: internal port.
@@ -815,7 +832,7 @@ static int __devinit natsemi_probe1 (str
* The address would be used to access a phy over the mii bus, but
* the internal phy is accessed through mapped registers.
*/
- if (readl(ioaddr + ChipConfig) CfgExtPhy)
+ if (np-ignore_phy || readl(ioaddr + ChipConfig) CfgExtPhy)
dev-if_port = PORT_MII;
else
dev-if_port = PORT_TP;
@@ -825,7 +842,9 @@ static int __devinit natsemi_probe1 (str
if (dev-if_port != PORT_TP) {
np-phy_addr_external = find_mii(dev);
- if (np-phy_addr_external == PHY_ADDR_NONE) {
+ /* If we're ignoring the PHY it doesn't matter if we can't
+* find one. */
+ if (!np-ignore_phy np-phy_addr_external == PHY_ADDR_NONE) {
dev-if_port = PORT_TP;
np-phy_addr_external = PHY_ADDR_INTERNAL;
}
@@ -833,10 +852,6 @@ static int __devinit natsemi_probe1 (str
np-phy_addr_external = PHY_ADDR_INTERNAL;
}
- option = find_cnt MAX_UNITS ? options[find_cnt] : 0;
- if (dev-mem_start)
- option = dev-mem_start;
-
/* The lower four bits are the media type. */
if (option) {
if (option 0x200)
@@ -891,6 +906,8 @@ static int __devinit natsemi_probe1 (str
printk(%02x, IRQ %d, dev-dev_addr[i], irq);
if (dev-if_port == PORT_TP)
printk(, port TP.\n);
+ else if (np-ignore_phy)
+ printk(, port MII, ignoring PHY\n);
else
printk(, port MII, phy ad %d.\n,
np-phy_addr_external);
}
@@ -1571,42 +1588,44 @@ static void check_link(struct net_device
{
struct netdev_private *np = netdev_priv(dev);
void __iomem * ioaddr =
[patch 2/2] lockdep: fix sk_dst_check() deadlock
From: Ingo Molnar [EMAIL PROTECTED]
Split off __icmpv6_socket's sk-sk_dst_lock class, because it gets used
from softirqs, which is safe for __icmpv6_sockets (because they never get
directly used via userspace syscalls), but unsafe for normal sockets.
Has no effect on non-lockdep kernels.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: Arjan van de Ven [EMAIL PROTECTED]
Acked-by: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/ipv6/icmp.c | 13 +
1 files changed, 13 insertions(+)
diff -puN net/ipv6/icmp.c~lockdep-fix-sk_dst_check-deadlock net/ipv6/icmp.c
--- a/net/ipv6/icmp.c~lockdep-fix-sk_dst_check-deadlock
+++ a/net/ipv6/icmp.c
@@ -712,6 +712,11 @@ discard_it:
return 0;
}
+/*
+ * Special lock-class for __icmpv6_socket:
+ */
+static struct lock_class_key icmpv6_socket_sk_dst_lock_key;
+
int __init icmpv6_init(struct net_proto_family *ops)
{
struct sock *sk;
@@ -730,6 +735,14 @@ int __init icmpv6_init(struct net_proto_
sk = per_cpu(__icmpv6_socket, i)-sk;
sk-sk_allocation = GFP_ATOMIC;
+ /*
+* Split off their lock-class, because sk-sk_dst_lock
+* gets used from softirqs, which is safe for
+* __icmpv6_socket (because those never get directly used
+* via userspace syscalls), but unsafe for normal sockets.
+*/
+ lockdep_set_class(sk-sk_dst_lock,
+ icmpv6_socket_sk_dst_lock_key);
/* Enough space for 2 64K ICMP packets, including
* sk_buff struct overhead.
_
-
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 5/9] lockdep: fix atm/ipcommon.c deadlock
From: Arjan van de Ven [EMAIL PROTECTED]
Linux version 2.6.17-git22 ([EMAIL PROTECTED]) (gcc version 4.0.3 (Ubuntu
4.0.3-1ubuntu5)) #20 PREEMPT Tue Jul 4 10:35:04 CEST 2006
[ 2381.598609] =
[ 2381.619314] [ INFO: possible recursive locking detected ]
[ 2381.635497] -
[ 2381.651706] atmarpd/2696 is trying to acquire lock:
[ 2381.666354] (skb_queue_lock_key){-+..}, at: [c028c540]
skb_migrate+0x24/0x6c
[ 2381.688848]
ok this is a real potential deadlock in a way, it takes two locks of 2
skbuffs without doing any kind of lock ordering; I think the following
patch should fix it. Just sort the lock taking order by address of the
skb.. it's not pretty but it's the best this can do in a minimally
invasive way.
I still agree with the comment that this code shouldn't live in the atm
layer...
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/atm/ipcommon.c | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff -puN net/atm/ipcommon.c~lockdep-fix-atm-ipcommonc-deadlock
net/atm/ipcommon.c
--- a/net/atm/ipcommon.c~lockdep-fix-atm-ipcommonc-deadlock
+++ a/net/atm/ipcommon.c
@@ -25,8 +25,8 @@
/*
* skb_migrate appends the list at from to to, emptying from in the
* process. skb_migrate is atomic with respect to all other skb operations on
- * from and to. Note that it locks both lists at the same time, so beware
- * of potential deadlocks.
+ * from and to. Note that it locks both lists at the same time, so to deal
+ * with the lock ordering, the locks are taken in address order.
*
* This function should live in skbuff.c or skbuff.h.
*/
@@ -39,8 +39,13 @@ void skb_migrate(struct sk_buff_head *fr
struct sk_buff *skb_to = (struct sk_buff *) to;
struct sk_buff *prev;
- spin_lock_irqsave(from-lock,flags);
- spin_lock(to-lock);
+ if (from to) {
+ spin_lock_irqsave(from-lock,flags);
+ spin_lock_nested(to-lock, SINGLE_DEPTH_NESTING);
+ } else {
+ spin_lock_irqsave(to-lock, flags);
+ spin_lock_nested(from-lock, SINGLE_DEPTH_NESTING);
+ }
prev = from-prev;
from-next-prev = to-prev;
prev-next = skb_to;
_
-
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 9/9] drivers/net/e1000/: possible cleanups
From: Adrian Bunk [EMAIL PROTECTED]
- make needlessly global functions static
- #if 0 the following unused global functions:
- e1000_hw.c: e1000_mc_addr_list_update()
- e1000_hw.c: e1000_read_reg_io()
- e1000_hw.c: e1000_enable_pciex_master()
- e1000_hw.c: e1000_ife_disable_dynamic_power_down()
- e1000_hw.c: e1000_ife_enable_dynamic_power_down()
- e1000_hw.c: e1000_write_ich8_word()
- e1000_hw.c: e1000_duplex_reversal()
- e1000_main.c: e1000_io_read()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Cc: John Ronciak [EMAIL PROTECTED]
Cc: Jesse Brandeburg [EMAIL PROTECTED]
Cc: Jeff Kirsher [EMAIL PROTECTED]
Cc: Auke Kok [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.c | 89 ++-
drivers/net/e1000/e1000_hw.h | 32 ---
drivers/net/e1000/e1000_main.c |2
3 files changed, 67 insertions(+), 56 deletions(-)
diff -puN drivers/net/e1000/e1000_hw.c~drivers-net-e1000-possible-cleanups
drivers/net/e1000/e1000_hw.c
--- a/drivers/net/e1000/e1000_hw.c~drivers-net-e1000-possible-cleanups
+++ a/drivers/net/e1000/e1000_hw.c
@@ -105,6 +105,33 @@ static int32_t e1000_configure_kmrn_for_
uint16_t duplex);
static int32_t e1000_configure_kmrn_for_1000(struct e1000_hw *hw);
+static int32_t e1000_erase_ich8_4k_segment(struct e1000_hw *hw,
+ uint32_t segment);
+static int32_t e1000_get_software_flag(struct e1000_hw *hw);
+static int32_t e1000_get_software_semaphore(struct e1000_hw *hw);
+static int32_t e1000_init_lcd_from_nvm(struct e1000_hw *hw);
+static int32_t e1000_kumeran_lock_loss_workaround(struct e1000_hw *hw);
+static int32_t e1000_read_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
+ uint16_t words, uint16_t *data);
+static int32_t e1000_read_ich8_byte(struct e1000_hw *hw, uint32_t index,
+ uint8_t* data);
+static int32_t e1000_read_ich8_word(struct e1000_hw *hw, uint32_t index,
+ uint16_t *data);
+static int32_t e1000_read_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr,
+ uint16_t *data);
+static void e1000_release_software_flag(struct e1000_hw *hw);
+static void e1000_release_software_semaphore(struct e1000_hw *hw);
+static int32_t e1000_set_pci_ex_no_snoop(struct e1000_hw *hw,
+uint32_t no_snoop);
+static int32_t e1000_verify_write_ich8_byte(struct e1000_hw *hw,
+ uint32_t index, uint8_t byte);
+static int32_t e1000_write_eeprom_ich8(struct e1000_hw *hw, uint16_t offset,
+ uint16_t words, uint16_t *data);
+static int32_t e1000_write_ich8_byte(struct e1000_hw *hw, uint32_t index,
+uint8_t data);
+static int32_t e1000_write_kmrn_reg(struct e1000_hw *hw, uint32_t reg_addr,
+ uint16_t data);
+
/* IGP cable length table */
static const
uint16_t e1000_igp_cable_length_table[IGP01E1000_AGC_LENGTH_TABLE_SIZE] =
@@ -3233,7 +3260,7 @@ e1000_shift_in_mdi_bits(struct e1000_hw
return data;
}
-int32_t
+static int32_t
e1000_swfw_sync_acquire(struct e1000_hw *hw, uint16_t mask)
{
uint32_t swfw_sync = 0;
@@ -3277,7 +3304,7 @@ e1000_swfw_sync_acquire(struct e1000_hw
return E1000_SUCCESS;
}
-void
+static void
e1000_swfw_sync_release(struct e1000_hw *hw, uint16_t mask)
{
uint32_t swfw_sync;
@@ -3575,7 +3602,7 @@ e1000_write_phy_reg_ex(struct e1000_hw *
return E1000_SUCCESS;
}
-int32_t
+static int32_t
e1000_read_kmrn_reg(struct e1000_hw *hw,
uint32_t reg_addr,
uint16_t *data)
@@ -3608,7 +3635,7 @@ e1000_read_kmrn_reg(struct e1000_hw *hw,
return E1000_SUCCESS;
}
-int32_t
+static int32_t
e1000_write_kmrn_reg(struct e1000_hw *hw,
uint32_t reg_addr,
uint16_t data)
@@ -3839,7 +3866,7 @@ e1000_phy_powerdown_workaround(struct e1
*
* hw - struct containing variables accessed by shared code
**/
-int32_t
+static int32_t
e1000_kumeran_lock_loss_workaround(struct e1000_hw *hw)
{
int32_t ret_val;
@@ -4086,7 +4113,7 @@ e1000_phy_igp_get_info(struct e1000_hw *
* hw - Struct containing variables accessed by shared code
* phy_info - PHY information structure
**/
-int32_t
+static int32_t
e1000_phy_ife_get_info(struct e1000_hw *hw,
struct e1000_phy_info *phy_info)
{
@@ -5643,6 +5670,7 @@ e1000_init_rx_addrs(struct e1000_hw *hw)
* for the first 15 multicast addresses, and hashes the rest into the
* multicast table.
*/
+#if 0
Re: Bluetooth update for 2.6
From: Marcel Holtmann [EMAIL PROTECTED] Date: Thu, 06 Jul 2006 22:09:20 +0200 this is the second part of pending updates of the Bluetooth subsystem for the upcoming 2.6.18 kernel. A couple of them are only coding style cleanups which I failed to submit for the previous kernel release. They slipped somehow. The rest is driver model integration stuff. Please push them to Linus as soon as possible. The merge window for 2.6.18 is closed, so you will need to eliminate things like code cleanups and other non-bugfixes. - 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 7/9] 8139cp.c printk fix
[EMAIL PROTECTED] wrote:
From: Andrew Morton [EMAIL PROTECTED]
drivers/net/8139cp.c: In function 'cp_init_one':
drivers/net/8139cp.c:1919: warning: format '%lx' expects type 'long unsigned
int', but argument 4 has type 'resource_size_t'
drivers/net/8139cp.c:1919: warning: format '%lx' expects type 'long unsigned
int', but argument 5 has type 'resource_size_t'
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/8139cp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/8139cp.c~8139cp-printk-fix drivers/net/8139cp.c
--- a/drivers/net/8139cp.c~8139cp-printk-fix
+++ a/drivers/net/8139cp.c
@@ -1916,7 +1916,7 @@ static int cp_init_one (struct pci_dev *
regs = ioremap(pciaddr, CP_REGS_SIZE);
if (!regs) {
rc = -EIO;
- dev_err(pdev-dev, Cannot map PCI MMIO ([EMAIL PROTECTED])\n,
+ dev_err(pdev-dev, Cannot map PCI MMIO ([EMAIL PROTECTED])\n,
(unsigned long long)pci_resource_len(pdev, 1),
(unsigned long long)pciaddr);
should be %llx if I'm not mistaken... (looks like a merge screwup on my
part)
-
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] lockdep: fix sk_dst_check() deadlock
the correct Subject of the patch is:
Subject: lockdep: annotate __icmpv6_socket
Ingo
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Split off __icmpv6_socket's sk-sk_dst_lock class, because it gets used
from softirqs, which is safe for __icmpv6_sockets (because they never get
directly used via userspace syscalls), but unsafe for normal sockets.
Has no effect on non-lockdep kernels.
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: Arjan van de Ven [EMAIL PROTECTED]
Acked-by: Herbert Xu [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/ipv6/icmp.c | 13 +
1 files changed, 13 insertions(+)
diff -puN net/ipv6/icmp.c~lockdep-fix-sk_dst_check-deadlock net/ipv6/icmp.c
--- a/net/ipv6/icmp.c~lockdep-fix-sk_dst_check-deadlock
+++ a/net/ipv6/icmp.c
@@ -712,6 +712,11 @@ discard_it:
return 0;
}
+/*
+ * Special lock-class for __icmpv6_socket:
+ */
+static struct lock_class_key icmpv6_socket_sk_dst_lock_key;
+
int __init icmpv6_init(struct net_proto_family *ops)
{
struct sock *sk;
@@ -730,6 +735,14 @@ int __init icmpv6_init(struct net_proto_
sk = per_cpu(__icmpv6_socket, i)-sk;
sk-sk_allocation = GFP_ATOMIC;
+ /*
+ * Split off their lock-class, because sk-sk_dst_lock
+ * gets used from softirqs, which is safe for
+ * __icmpv6_socket (because those never get directly used
+ * via userspace syscalls), but unsafe for normal sockets.
+ */
+ lockdep_set_class(sk-sk_dst_lock,
+ icmpv6_socket_sk_dst_lock_key);
/* Enough space for 2 64K ICMP packets, including
* sk_buff struct overhead.
_
-
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/7] net_device list cleanup: core
On Fri, Jul 07, 2006 at 01:34:34PM +0900, YOSHIFUJI Hideaki / [EMAIL
PROTECTED](B wrote:
In article [EMAIL PROTECTED] (at Mon, 3 Jul 2006 12:18:51 +0400), Andrey
Savochkin [EMAIL PROTECTED] says:
@@ -3271,22 +3277,22 @@ int unregister_netdevice(struct net_devi
/* And unlink it from device chain. */
for (dp = dev_base; (d = *dp) != NULL; dp = d-next) {
Why not for_each_netdev?
it's a different list
-
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 0/2] NET: Accurate packet scheduling for ATM/ADSL
Russell Stuart wrote: Unfortunately you do things in the wrong order for ATM. See: http://mailman.ds9a.nl/pipermail/lartc/2006q1/018314.html for an overview of the problem, and then the attached email for a detailed description of how the current patch addresses it. It is a trivial fix. Actually that was the part I didn't understand, you keep talking (also in that comment in tc_core.c) about an unknown overhead. What is that and why would it be unknown? The mail you attached is quite long, is there an simple example that shows what you mean? As I said earlier, RTAB and STAB contain the same numbers, just scaled differently. The ATM patch stuffed around with RTAB. With your patch in place it will have to do the same exactly the same thing with STAB - because RTAB and STAB carry the same data. So to me the two patches seem orthogonal. Yes. As I said in the beginning of this thread, we could still do the RTAB thing for qdiscs that support it. But since the visible size should be the same for all qdiscs (including child ones) we need to do the initial calculation anyway, so I don't see any purpose in still adjusting the rate tables and using skb-len instead of using the adjusted size. One observation is the size optimisation you applied to STAB, making it variable length, could also be applied to RTAB. In fact it should be. Then they would be identical, apart from the scaling. Even the lookup operation (performed in qdisc_init_len in your patch) would be identical. We can do that. I'm not attached to the size tables :) However, now you lot have made me go away and think, I have another idea on how to attack this. Perhaps it will be more palatable to you. It would replace RTAB and STAB with a 28 byte structure for most protocol stacks - well all I can think of off the top of my head, anyway. RTAB would have to remain for backwards compatibility, of course. Can you describe in more detail? - 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 NET 00/04]: Increase number of possible routing tables
Patrick McHardy wrote: I took on Ben's challenge to increase the number of possible routing tables, these are the resulting patches. The table IDs are changed to 32 bit values and are contained in a new netlink routing attribute. For compatibility rtm_table in struct rtmsg can still be used to access the first 255 tables and contains the low 8 bit of the table ID in case of dumps. Unfortunately there are no invalid values for rtm_table, so the best userspace can do in case of a new iproute version that tries to access tables 255 on an old kernel is to use RTM_UNSPEC (0) for rtm_table, which will make the kernel allocate an empty table instead of silently adding routes to a more or less random table. The iproute patch will follow shortly. The hash tables are statically sized since on-the-fly resizing would require introducing locking in the packet processing path (currently we need none), if this is a problem we could just directly attach table references to rules, since tables are never deleted or freed this would be a simple change. One spot is still missing (nl_fib_lookup), so these patches are purely a RFC for now. Tested only with IPv4, I mainly converted DECNET as well to keep it in sync and because iteration over all possible table values, as done in many spots, has an unacceptable overhead with 32 bit values. Since there were no objections, I would like to finalize this patch by takeing care of nl_fib_lookup. Since it was introduced as a debugging interface for fib_trie and the interface definitions are not even public (contained in include/net), I wonder if anyone really cares about backwards compatibility or if I can just change it. Robert, Thomas, you are the only two users of the interface I'm aware of, what do you think? - 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
What is RDMA (was: RDMA will be reverted)
On Fri, Jul 07, 2006 at 06:53:20AM +, David Miller wrote:
What I am saying, however, is that we need to understand the
technology and the hooks you guys want before we put any of it in.
Yes indeed.
Here is what I've understood so far so let's see if we can start building
a censensus.
1) RDMA over straight Infiniband is not contentious. In this case no
IP networking is involved.
2) RDMA over TCP/IP (or SCTP) can theoretically run on any network that
supported IP, including Infiniband and Ethernet.
3) When RDMA over TCP is completely done in hardware, i.e., it has its
own IP address, MAC address, and simply presents an RDMA interface
(whatever that may be) to Linux, we're OK with it.
This is similar to how some iSCSI adapters work.
4) When RDMA over TCP is done completely in the Linux networking stack,
we don't have a problem because the existing TCP stack is still in
charge. However, this is pretty pointless.
5) RDMA over TCP on the receive side is offloaded into the NIC. This
allows the NIC to directly place data into the application's buffer.
We're starting to have a little bit of a problem because it means that
part of the incoming IP traffic is now being directly processed by the
NIC, with no input from the Linux TCP/IP stack.
However, as long as the connection establishment/acks are still
controlled/seen by Linux we can probably live with it.
6) RDMA over TCP on the transmit side is offloaded into the NIC. This
is starting to look very worrying.
The reason is that we lose all control to crucial aspects of TCP like
congestion control. It is now completely up to the NIC to do that.
For straight RDMA over Infiniband this isn't an issue because the
traffic is not likely to travel across the Internet.
However, for RDMA over TCP, one of their goals is to support sending
traffic over the Internet so this is a concern. Incidentally, this is
why they need to know about things like MAC/route/MTU changing.
7) RDMA over TCP is completely offloaded into the NIC, however, they still
use Linux's IP address, MAC address, and rely on us to tell it about
events such as MTU updates or MAC changes.
In addition to the problems we have in 5) and 6), we now have a portion
of TCP port space which has suddenly become invisible to Linux. What's
more, we lose control (e.g., netfilter) over what connections may or
may not be established.
So to my mind, RDMA over TCP is most problematic when it shares the same
IP/MAC address as the Linux host, and when the transmit side and/or the
connection establishment (case 6 and 7) is offloaded into the NIC. This
also happens to be the only scenario where they need the notification
patch that started all this discussion.
BTW, this URL gives an interesting perspective on RDMA over TCP
(particularly Q14/Q15):
http://www.rdmaconsortium.org/home/FAQs_Apr25.htm
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] Freescale QE UCC gigabit ethernet driver
-Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 9:45 PM To: Li Yang-r58472 Cc: Andrew Morton; [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH 1/3] Freescale QE UCC gigabit ethernet driver Nack. Here are some high level things that should be addressed: * There is a ton of debug code that should probably be stripped out, such as dump_regs, etc.. The reason I left these debug code in is that, QE is very flexible. User probably needs to fine tune parameters for their own application. It will be good to give them some clue doing that. It's fine to remove them, if you do think they are too verbose. * The phy support should use the phylib instead I'll do this when I do get some time. ;) * convert from being a platform_device to of_device I'm not up against moving to use of_device. But why are we putting extra effort in closing the door to backward compatibility with ppc arch, and doesn't provide any new feature. ;) - kumar - 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] remove CONFIG_HAVE_ARCH_DEV_ALLOC_SKB
skbuff.h has an #ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB to allow architectures to reimplement __dev_alloc_skb. It's not set on any architecture and now that we have an architecture-overrideable NET_SKB_PAD there is not point at all to have one either. Signed-off-by: Christoph Hellwig [EMAIL PROTECTED] Index: linux-2.6/include/linux/skbuff.h === --- linux-2.6.orig/include/linux/skbuff.h 2006-07-06 14:21:20.0 +0200 +++ linux-2.6/include/linux/skbuff.h2006-07-06 15:11:00.0 +0200 @@ -1066,7 +1066,6 @@ kfree_skb(skb); } -#ifndef CONFIG_HAVE_ARCH_DEV_ALLOC_SKB /** * __dev_alloc_skb - allocate an skbuff for sending * @length: length to allocate @@ -1087,9 +1086,6 @@ skb_reserve(skb, NET_SKB_PAD); return skb; } -#else -extern struct sk_buff *__dev_alloc_skb(unsigned int length, int gfp_mask); -#endif /** * dev_alloc_skb - allocate an skbuff for sending - 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] correct dev_alloc_skb kerneldoc
dev_alloc_skb is designated for RX descriptors, not TX. (Some drivers use it for the latter anyway, but that's a different story) Signed-off-by: Christoph Hellwig [EMAIL PROTECTED] Index: linux-2.6/include/linux/skbuff.h === --- linux-2.6.orig/include/linux/skbuff.h 2006-07-07 11:05:30.0 +0200 +++ linux-2.6/include/linux/skbuff.h2006-07-07 11:06:31.0 +0200 @@ -1067,7 +1067,7 @@ } /** - * __dev_alloc_skb - allocate an skbuff for sending + * __dev_alloc_skb - allocate an skbuff for receiving * @length: length to allocate * @gfp_mask: get_free_pages mask, passed to alloc_skb * @@ -1088,7 +1088,7 @@ } /** - * dev_alloc_skb - allocate an skbuff for sending + * dev_alloc_skb - allocate an skbuff for receiving * @length: length to allocate * * Allocate a new sk_buff and assign it a usage count of one. The - 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: SKB BUG: Invalid truesize
Does it harm? SKB BUG: Invalid truesize (380) len=1383, sizeof(sk_buff)=156 SKB BUG: Invalid truesize (316) len=1383, sizeof(sk_buff)=156 SKB BUG: Invalid truesize (348) len=1383, sizeof(sk_buff)=156 SKB BUG: Invalid truesize (316) len=1383, sizeof(sk_buff)=156 SKB BUG: Invalid truesize (380) len=1383, sizeof(sk_buff)=156 I found it in the log of a 2.6.17 box using IPSEC tunnels. it does harm, we need to know which network driver(s) are/were loaded when this happened, for starters. It happened only once during quick mode of an IPSEC tunnel. Two 3c905C cards, both with 3c59x, non-module build. - 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: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
Am Donnerstag 06 Juli 2006 09:42 schrieb Patrick McHardy: I believe this link-state logic was added by someone else. I'm not sure exactly what these flags are supposed to do, so I am not sure if they should be propagated to the VLAN or not. I looked into this. The present flag used to get propagated from the real device until this patch, presumably to make sure no operations on the vlan device will be passed through to the underlying device when it is not present. The present flag is changed by netif_device_attach() and netif_device_detach(), and these functions do not emit a netdev_state_change() afterwards. So there is a good chance that vlan_device_event() won't be called and cannot transfer the flag. netif_device_detach() also sets __LINK_STATE_XOFF implicitely. Ok, let's see who cares for netif_device_present(): -SIOCSIFMAP, dev-set_config() (change media type) -dev_open() -dev_set_mtu() -dev_set_mac_address() -dev_watchdog() -not implemented by VLAN / does not call through to underlying device -multicast ioctls -calls dev_mc_upload() of the underlying device sooner or later, this function checks whether the device is present or not. However, if you change the multicast list on a VLAN while the real device is not present, dev_mc_upload() won't be called on netif_device_attach(). Good thing is that most drivers setup multicast list after attach. Fishy. -several private ioctls -vlan_dev_ioctl() checks whether the real device is present before passing an ioctl So I'd rather drop the __LINK_STATE_PRESENT transfer part, because not guaranteed to be called anyway and mostly unneeded. Ok, let me look through the history now to find who added transferring it (hope this happened after the bitkeeper-git move) Stefan - 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: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
Stefan Rompf wrote: Am Donnerstag 06 Juli 2006 09:42 schrieb Patrick McHardy: I believe this link-state logic was added by someone else. I'm not sure exactly what these flags are supposed to do, so I am not sure if they should be propagated to the VLAN or not. I looked into this. The present flag used to get propagated from the real device until this patch, presumably to make sure no operations on the vlan device will be passed through to the underlying device when it is not present. The present flag is changed by netif_device_attach() and netif_device_detach(), and these functions do not emit a netdev_state_change() afterwards. So there is a good chance that vlan_device_event() won't be called and cannot transfer the flag. netif_device_detach() also sets __LINK_STATE_XOFF implicitely. True. Ok, let's see who cares for netif_device_present(): -SIOCSIFMAP, dev-set_config() (change media type) -dev_open() -dev_set_mtu() -dev_set_mac_address() -dev_watchdog() -not implemented by VLAN / does not call through to underlying device -multicast ioctls -calls dev_mc_upload() of the underlying device sooner or later, this function checks whether the device is present or not. However, if you change the multicast list on a VLAN while the real device is not present, dev_mc_upload() won't be called on netif_device_attach(). Good thing is that most drivers setup multicast list after attach. Fishy. -several private ioctls -vlan_dev_ioctl() checks whether the real device is present before passing an ioctl So I'd rather drop the __LINK_STATE_PRESENT transfer part, because not guaranteed to be called anyway and mostly unneeded. Ok, let me look through the history now to find who added transferring it (hope this happened after the bitkeeper-git move) I tend to agree with you, it doesn't seem to work properly. It was introduced by Stephen (before the move), lets hope he can tell us more. - 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] per-task delay accounting taskstats interface: control exit data through cpumasks]
* Andrew Morton [EMAIL PROTECTED] 2006-07-06 16:05 hm, nla_strlcpy() looks more complex than it needs to be. We really need nla_kstrndup() ;) Oh well. This? Looks good. - 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] per-task delay accounting taskstats interface: control exit data through cpumasks]
* Andrew Morton [EMAIL PROTECTED] 2006-07-06 15:56 Yup. Thomas, what's the testing status of the netlink patch you sent? Should I queue it up and start plagueing people with it? It survived feeding it with oversized strings etc. Feel free to queue it up. - 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: [e1000]: flow control on by default - good idea really?
On Thu, 2006-06-07 at 23:59 -0700, David Miller wrote: It's autonegotiated, check you kernel message logs when the link came up, you'll see this: tg3: eth0: Flow control is on for TX and on for RX. yikes - yes, this would be it. I could be wrong and i will double check: I think when the e1000 says via ethtool rx is on - it means that it is _advertising_ flow control as opposed to detecting partner has flow control capability. Auke, can you also check this as well? cheers, jamal - 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, RFT] bcm43xx: init routine rewrite (bugfix)
On Thursday 06 July 2006 21:35, you wrote: On Sat, Jul 01, 2006 at 10:14:23PM +0200, Michael Buesch wrote: Hi, This patch is a rewrite of the bcm43xx init routine. It is supposed to fix several issues: * up-down-up.. sequence stale-data issue (This may fix dhclient issues) * Fix init vs IRQ race. * Fix init for cards with multiple cores (APHY) (untested) * Fix controller restart breakage. * Make used wireless core (phymode) selectable at runtime. * Well, few others. Don't remember :) Since your subject includes RFT, I'm NOT going to apply this. Please correct me if your desire is otherwise. Yes, that's right. Please don't apply this, yet. I will resend it soon in a submittable mail. As a general rule, don't apply any patches from me to any trees that have RFT in Subject. -- Greetings Michael. - 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] Freescale QE UCC gigabit ethernet driver
On Jul 7, 2006, at 3:59 AM, Li Yang-r58472 wrote: -Original Message- From: Kumar Gala [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 9:45 PM To: Li Yang-r58472 Cc: Andrew Morton; [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH 1/3] Freescale QE UCC gigabit ethernet driver Nack. Here are some high level things that should be addressed: * There is a ton of debug code that should probably be stripped out, such as dump_regs, etc.. The reason I left these debug code in is that, QE is very flexible. User probably needs to fine tune parameters for their own application. It will be good to give them some clue doing that. It's fine to remove them, if you do think they are too verbose. Then I suggest you look at debugfs. * The phy support should use the phylib instead I'll do this when I do get some time. ;) * convert from being a platform_device to of_device I'm not up against moving to use of_device. But why are we putting extra effort in closing the door to backward compatibility with ppc arch, and doesn't provide any new feature. ;) Because the intent is for arch/ppc to go away in the future. You are introducing a new driver and a new platform, this is the ideal time for us to use of_device. The benefits are that the driver is the ideal place to parse the details of the device node rather than platform code in arch/powerpc. - kumar - 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: RDMA will be reverted
On Thu, 2006-07-06 at 23:53 -0700, David Miller wrote: From: Tom Tucker [EMAIL PROTECTED] Date: Thu, 06 Jul 2006 00:25:03 -0500 This patch is about dotting I's and crossing T's, it's not about foundations. You assume that I've flat out rejected RDMA, in fact I haven't. I really don't have enough information to form a final opinion yet. There's about a week of emails on this topic which I need to read and digest first. I realize that there is a tremendous amount of work out there and this is just one thread. What I am saying, however, is that we need to understand the technology and the hooks you guys want before we put any of it in. Absolutely. I don't think that's unreasonable. Not at all. Let me know if I can help. Tom - 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: [Xen-devel] kernel BUG at net/core/dev.c:1133!
Petersson, Mats [EMAIL PROTECTED] wrote:
Looks like the GSO is involved?
It's certainly what crashed your machine :) It's probably not the
guilty party though. Someone is passing through a TSO packet with
checksum set to something other than CHECKSUM_HW.
I bet it's netfilter and we just never noticed before because real
NICS would simply corrupt the checksum silently.
Could you confirm that you have netfilter rules (in particular NAT
rules) and that this goes away if you flush all your netfilter tables?
Patrick, do we really have to zap the checksum on outbound NAT? Could
we update it instead?
I got this while running Dom0 only (no guests), with a
BOINC/[EMAIL PROTECTED] application running on all 4 cores.
changeset: 10649:8e55c5c11475
Build: x86_32p (pae).
[ cut here ]
kernel BUG at net/core/dev.c:1133!
invalid opcode: [#1]
SMP
CPU:0
EIP:0061:[c04dceb0]Not tainted VLI
EFLAGS: 00210297 (2.6.16.13-xen #12)
EIP is at skb_gso_segment+0xf0/0x110
eax: ebx: 0003 ecx: 0002 edx: c06e2e00
esi: 0008 edi: cd9e32e0 ebp: c63a7900 esp: c0de5ad0
ds: 007b es: 007b ss: 0069
Process rosetta_5.25_i6 (pid: 8826, threadinfo=c0de4000 task=cb019560)
Stack: 0c8f69060 ffa3 0003 cd9e32e0 0002 c63a7900
c04dcfb0
cd9e32e0 0003 cd9e32e0 cf8e3000 cf8e3140 c04dd07e
cd9e32e0
cf8e3000 cd9e32e0 cf8e3000 c04ec07e cd9e32e0 cf8e3000
c0895140
Call Trace:
[c04dcfb0] dev_gso_segment+0x30/0xb0
[c04dd07e] dev_hard_start_xmit+0x4e/0x110
[c04ec07e] __qdisc_run+0xbe/0x280
[c04dd4b9] dev_queue_xmit+0x379/0x380
[c05bbe44] br_dev_queue_push_xmit+0xa4/0x140
[c05c2402] br_nf_post_routing+0x102/0x1d0
[c05c22b0] br_nf_dev_queue_xmit+0x0/0x50
[c05bbda0] br_dev_queue_push_xmit+0x0/0x140
[c04f0eab] nf_iterate+0x6b/0xa0
[c05bbda0] br_dev_queue_push_xmit+0x0/0x140
[c05bbda0] br_dev_queue_push_xmit+0x0/0x140
[c04f0f4e] nf_hook_slow+0x6e/0x120
[c05bbda0] br_dev_queue_push_xmit+0x0/0x140
[c05bbf40] br_forward_finish+0x60/0x70
[c05bbda0] br_dev_queue_push_xmit+0x0/0x140
[c05c1b71] br_nf_forward_finish+0x71/0x130
[c05bbee0] br_forward_finish+0x0/0x70
[c05c1d20] br_nf_forward_ip+0xf0/0x1a0
[c05c1b00] br_nf_forward_finish+0x0/0x130
[c05bbee0] br_forward_finish+0x0/0x70
[c04f0eab] nf_iterate+0x6b/0xa0
[c05bbee0] br_forward_finish+0x0/0x70
[c05bbee0] br_forward_finish+0x0/0x70
[c04f0f4e] nf_hook_slow+0x6e/0x120
[c05bbee0] br_forward_finish+0x0/0x70
[c05bc044] __br_forward+0x74/0x80
[c05bbee0] br_forward_finish+0x0/0x70
[c05bceb1] br_handle_frame_finish+0xd1/0x160
[c05bcde0] br_handle_frame_finish+0x0/0x160
[c05c0e0b] br_nf_pre_routing_finish+0xfb/0x480
[c05bcde0] br_handle_frame_finish+0x0/0x160
[c05c0d10] br_nf_pre_routing_finish+0x0/0x480
[c054fe13] ip_nat_in+0x43/0xc0
[c05c0d10] br_nf_pre_routing_finish+0x0/0x480
[c04f0eab] nf_iterate+0x6b/0xa0
[c05c0d10] br_nf_pre_routing_finish+0x0/0x480
[c05c0d10] br_nf_pre_routing_finish+0x0/0x480
[c04f0f4e] nf_hook_slow+0x6e/0x120
[c05c0d10] br_nf_pre_routing_finish+0x0/0x480
[c05c1914] br_nf_pre_routing+0x404/0x580
[c05c0d10] br_nf_pre_routing_finish+0x0/0x480
[c04f0eab] nf_iterate+0x6b/0xa0
[c05bcde0] br_handle_frame_finish+0x0/0x160
[c05bcde0] br_handle_frame_finish+0x0/0x160
[c04f0f4e] nf_hook_slow+0x6e/0x120
[c05bcde0] br_handle_frame_finish+0x0/0x160
[c05bd124] br_handle_frame+0x1e4/0x250
[c05bcde0] br_handle_frame_finish+0x0/0x160
[c04ddae5] netif_receive_skb+0x165/0x2a0
[c04ddcdf] process_backlog+0xbf/0x180
[c04ddebf] net_rx_action+0x11f/0x1d0
[c01262e6] __do_softirq+0x86/0x120
[c01263f5] do_softirq+0x75/0x90
[c0106cef] do_IRQ+0x1f/0x30
[c04271d0] evtchn_do_upcall+0x90/0x100
[c0105315] hypervisor_callback+0x3d/0x48
Code: c2 2b 57 24 29 d0 8d 14 2a 89 87 94 00 00 00 89 57 60 8b 44 24 08
83 c4 0c 5b 5e 5f 5d c3 0f 0
b 69 03 fe 8c 66 c0 e9 69 ff ff ff 0f 0b 6d 04 e8 ab 6c c0 e9 3a ff ff
ff 0f 0b 6c 04 e8 ab 6c c0
0Kernel panic - not syncing: Fatal exception in interrupt
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Document
Important document! Unknown command - IMPORTANT. Try HELP. - 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: [Xen-devel] kernel BUG at net/core/dev.c:1133!
I got the exact same thing when attempting to use BOINC on a single node supporting a 5 node open SSI cluster, (5 guests) and yes the problem went away when I flushed the rules. I attributed this to a quirk with the cluster CVIP, because I had also assigned each node its own outbound IP in addition to the incoming CVIP. Since I felt it was due to my tendency to over-tinker, I didn't mention it on the lists, was a few months ago. Thought I would chime in as it sounds like the same experience, up to and including BOINC. HTH --Tim On Sat, 2006-07-08 at 00:39 +1000, Herbert Xu wrote: Petersson, Mats [EMAIL PROTECTED] wrote: Looks like the GSO is involved? It's certainly what crashed your machine :) It's probably not the guilty party though. Someone is passing through a TSO packet with checksum set to something other than CHECKSUM_HW. I bet it's netfilter and we just never noticed before because real NICS would simply corrupt the checksum silently. Could you confirm that you have netfilter rules (in particular NAT rules) and that this goes away if you flush all your netfilter tables? Patrick, do we really have to zap the checksum on outbound NAT? Could we update it instead? I got this while running Dom0 only (no guests), with a BOINC/[EMAIL PROTECTED] application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). [ cut here ] kernel BUG at net/core/dev.c:1133! invalid opcode: [#1] SMP CPU:0 EIP:0061:[c04dceb0]Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen #12) EIP is at skb_gso_segment+0xf0/0x110 eax: ebx: 0003 ecx: 0002 edx: c06e2e00 esi: 0008 edi: cd9e32e0 ebp: c63a7900 esp: c0de5ad0 ds: 007b es: 007b ss: 0069 Process rosetta_5.25_i6 (pid: 8826, threadinfo=c0de4000 task=cb019560) Stack: 0c8f69060 ffa3 0003 cd9e32e0 0002 c63a7900 c04dcfb0 cd9e32e0 0003 cd9e32e0 cf8e3000 cf8e3140 c04dd07e cd9e32e0 cf8e3000 cd9e32e0 cf8e3000 c04ec07e cd9e32e0 cf8e3000 c0895140 Call Trace: [c04dcfb0] dev_gso_segment+0x30/0xb0 [c04dd07e] dev_hard_start_xmit+0x4e/0x110 [c04ec07e] __qdisc_run+0xbe/0x280 [c04dd4b9] dev_queue_xmit+0x379/0x380 [c05bbe44] br_dev_queue_push_xmit+0xa4/0x140 [c05c2402] br_nf_post_routing+0x102/0x1d0 [c05c22b0] br_nf_dev_queue_xmit+0x0/0x50 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c04f0eab] nf_iterate+0x6b/0xa0 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c05bbf40] br_forward_finish+0x60/0x70 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c05c1b71] br_nf_forward_finish+0x71/0x130 [c05bbee0] br_forward_finish+0x0/0x70 [c05c1d20] br_nf_forward_ip+0xf0/0x1a0 [c05c1b00] br_nf_forward_finish+0x0/0x130 [c05bbee0] br_forward_finish+0x0/0x70 [c04f0eab] nf_iterate+0x6b/0xa0 [c05bbee0] br_forward_finish+0x0/0x70 [c05bbee0] br_forward_finish+0x0/0x70 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05bbee0] br_forward_finish+0x0/0x70 [c05bc044] __br_forward+0x74/0x80 [c05bbee0] br_forward_finish+0x0/0x70 [c05bceb1] br_handle_frame_finish+0xd1/0x160 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05c0e0b] br_nf_pre_routing_finish+0xfb/0x480 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c054fe13] ip_nat_in+0x43/0xc0 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c04f0eab] nf_iterate+0x6b/0xa0 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c05c1914] br_nf_pre_routing+0x404/0x580 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c04f0eab] nf_iterate+0x6b/0xa0 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05bd124] br_handle_frame+0x1e4/0x250 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c04ddae5] netif_receive_skb+0x165/0x2a0 [c04ddcdf] process_backlog+0xbf/0x180 [c04ddebf] net_rx_action+0x11f/0x1d0 [c01262e6] __do_softirq+0x86/0x120 [c01263f5] do_softirq+0x75/0x90 [c0106cef] do_IRQ+0x1f/0x30 [c04271d0] evtchn_do_upcall+0x90/0x100 [c0105315] hypervisor_callback+0x3d/0x48 Code: c2 2b 57 24 29 d0 8d 14 2a 89 87 94 00 00 00 89 57 60 8b 44 24 08 83 c4 0c 5b 5e 5f 5d c3 0f 0 b 69 03 fe 8c 66 c0 e9 69 ff ff ff 0f 0b 6d 04 e8 ab 6c c0 e9 3a ff ff ff 0f 0b 6c 04 e8 ab 6c c0 0Kernel panic - not syncing: Fatal exception in interrupt Cheers, - 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.17-mm6
On 3/07/2006 10:03 p.m., Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm6/ - A major update to the e1000 driver. - 1394 updates Some minor breakage in the e1000... Fedora Core release 5.90 (Test) Kernel 2.6.17-mm6 on an x86_64 tornado.reub.net login: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH a TDT 1c next_to_use 1c next_to_clean8 buffer_info[next_to_clean] time_stamp 100027f1a next_to_watcha jiffies 1000281d4 next_to_watch.status 0 e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH a TDT 1c next_to_use 1c next_to_clean8 buffer_info[next_to_clean] time_stamp 100027f1a next_to_watcha jiffies 1000283c8 next_to_watch.status 0 e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH a TDT 1c next_to_use 1c next_to_clean8 buffer_info[next_to_clean] time_stamp 100027f1a next_to_watcha jiffies 1000285bc next_to_watch.status 0 e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH a TDT 1c next_to_use 1c next_to_clean8 buffer_info[next_to_clean] time_stamp 100027f1a next_to_watcha jiffies 1000287b0 next_to_watch.status 0 e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH a TDT 1c next_to_use 1c next_to_clean8 buffer_info[next_to_clean] time_stamp 100027f1a next_to_watcha jiffies 1000289a4 next_to_watch.status 0 A look through my switch logs and kernel logs over the last few days shows these messages and layer 2/link down disconnections every few hours or so, but of very short duration (I hadn't noticed until now). This output above was under virtually no load. Both the e1000 and switch port on the other end are doing RX and TX flow control. The controller is a built in chip on an Intel D945GNT board. 01:00.0 Ethernet controller: Intel Corporation 82573V Gigabit Ethernet Controller (Copper) (rev 03) Subsystem: Intel Corporation Unknown device 3094 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 313 Region 0: Memory at 4800 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at 2000 [size=32] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+ Address: fee0100c Data: 4142 Capabilities: [e0] Express Endpoint IRQ 0 Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag- Device: Latency L0s 512ns, L1 64us Device: AtnBtn- AtnInd- PwrInd- Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 512 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM unknown, Port 0 Link: Latency L0s 128ns, L1 64us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 [EMAIL PROTECTED] log]# ethtool -i eth0 driver: e1000 version: 7.1.9-k2-NAPI firmware-version: 1.0-5 bus-info: :01:00.0 [EMAIL PROTECTED] log]# Where can I go from here to help debug this further? reuben - 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
starting mc triggers lockdep
With 2.6.18rc1 + a selection of the lockdep tweaks found so far,
midnight commander makes the kernel unhappy.
Dave
===
[ INFO: possible circular locking dependency detected ]
---
mc/4913 is trying to acquire lock:
(sk_lock-AF_INET){--..}, at: [8022800c] tcp_sendmsg+0x1f/0xb1a
but task is already holding lock:
(inode-i_mutex){--..}, at: [802692e0] mutex_lock+0x2a/0x2e
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #2 (inode-i_mutex){--..}:
[802ab6d5] lock_acquire+0x4a/0x69
[80269102] __mutex_lock_slowpath+0xeb/0x29f
[802692df] mutex_lock+0x29/0x2e
[8030f4a0] create_dir+0x2c/0x1e2
[8030fa5b] sysfs_create_dir+0x59/0x78
[8034d2e2] kobject_add+0x114/0x1d8
[803bb1e7] class_device_add+0xb5/0x49d
[804300b1] netdev_register_sysfs+0x98/0xa2
[80426f58] register_netdevice+0x28c/0x376
[8042709c] register_netdev+0x5a/0x69
[8098aa12] loopback_init+0x4e/0x53
[8098a918] net_olddevs_init+0xb/0xb7
[80270918] init+0x177/0x348
[80263cdd] child_rip+0x7/0x12
- #1 (rtnl_mutex){--..}:
[802ab6d5] lock_acquire+0x4a/0x69
[80269102] __mutex_lock_slowpath+0xeb/0x29f
[802692df] mutex_lock+0x29/0x2e
[8042e0a2] rtnl_lock+0xf/0x12
[8045c7b8] ip_mc_leave_group+0x1e/0xae
[804467f7] do_ip_setsockopt+0x6ad/0x9b2
[80446baa] ip_setsockopt+0x2a/0x84
[80454a55] udp_setsockopt+0xd/0x1c
[8041f7ea] sock_common_setsockopt+0xe/0x11
[8041e965] sys_setsockopt+0x8e/0xb4
[80262f19] tracesys+0xd0/0xdb
- #0 (sk_lock-AF_INET){--..}:
[802ab6d5] lock_acquire+0x4a/0x69
[802371ea] lock_sock+0xd4/0xe7
[8022800b] tcp_sendmsg+0x1e/0xb1a
[80248f4b] inet_sendmsg+0x45/0x53
[80259d25] sock_sendmsg+0x110/0x130
[8041f462] kernel_sendmsg+0x3c/0x52
[885399e9] xs_tcp_send_request+0x117/0x320 [sunrpc]
[885388d5] xprt_transmit+0x105/0x21e [sunrpc]
[8853771e] call_transmit+0x1f4/0x239 [sunrpc]
[8853c06e] __rpc_execute+0x9b/0x1e6 [sunrpc]
[8853c1de] rpc_execute+0x1a/0x1d [sunrpc]
[885364ad] rpc_call_sync+0x87/0xb9 [sunrpc]
[885a2587] nfs3_rpc_wrapper+0x2e/0x74 [nfs]
[885a2a14] nfs3_proc_lookup+0xe0/0x163 [nfs]
[88594b10] nfs_lookup+0xef/0x1d6 [nfs]
[8020d300] do_lookup+0xd0/0x18c
[80209f27] __link_path_walk+0xa29/0xf7d
[8020f076] link_path_walk+0x69/0x101
[8020a22b] __link_path_walk+0xd2d/0xf7d
[8020f076] link_path_walk+0x69/0x101
[8020d096] do_path_lookup+0x27b/0x2e7
[802258da] __user_walk_fd+0x40/0x5c
[8022ae4a] vfs_stat_fd+0x26/0x5d
[80225592] sys_newstat+0x21/0x3c
[80262f19] tracesys+0xd0/0xdb
other info that might help us debug this:
1 lock held by mc/4913:
#0: (inode-i_mutex){--..}, at: [802692e0] mutex_lock+0x2a/0x2e
stack backtrace:
Call Trace:
[80271910] show_trace+0xaa/0x23d
[80271ab8] dump_stack+0x15/0x17
[802a992f] print_circular_bug_tail+0x6c/0x77
[802aaf34] __lock_acquire+0x853/0xa54
[802ab6d6] lock_acquire+0x4b/0x69
[802371eb] lock_sock+0xd5/0xe7
[8022800c] tcp_sendmsg+0x1f/0xb1a
[80248f4c] inet_sendmsg+0x46/0x53
[80259d26] sock_sendmsg+0x111/0x130
[8041f463] kernel_sendmsg+0x3d/0x52
[885399ea] :sunrpc:xs_tcp_send_request+0x118/0x320
[885388d6] :sunrpc:xprt_transmit+0x106/0x21e
[8853771f] :sunrpc:call_transmit+0x1f5/0x239
[8853c06f] :sunrpc:__rpc_execute+0x9c/0x1e6
[8853c1df] :sunrpc:rpc_execute+0x1b/0x1d
[885364ae] :sunrpc:rpc_call_sync+0x88/0xb9
[885a2588] :nfs:nfs3_rpc_wrapper+0x2f/0x74
[885a2a15] :nfs:nfs3_proc_lookup+0xe1/0x163
[88594b11] :nfs:nfs_lookup+0xf0/0x1d6
[8020d301] do_lookup+0xd1/0x18c
[80209f28] __link_path_walk+0xa2a/0xf7d
[8020f077] link_path_walk+0x6a/0x101
[8020a22c] __link_path_walk+0xd2e/0xf7d
[8020f077] link_path_walk+0x6a/0x101
[8020d097] do_path_lookup+0x27c/0x2e7
[802258db] __user_walk_fd+0x41/0x5c
[8022ae4b] vfs_stat_fd+0x27/0x5d
[80225593] sys_newstat+0x22/0x3c
[80262f1a] tracesys+0xd1/0xdb
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
Re: [patch 1/7] net_device list cleanup: core
In article [EMAIL PROTECTED] (at Fri, 7 Jul 2006 11:54:25 +0400), Andrey
Savochkin [EMAIL PROTECTED] says:
On Fri, Jul 07, 2006 at 01:34:34PM +0900, YOSHIFUJI Hideaki / [EMAIL
PROTECTED](B wrote:
In article [EMAIL PROTECTED] (at Mon, 3 Jul 2006 12:18:51 +0400), Andrey
Savochkin [EMAIL PROTECTED] says:
@@ -3271,22 +3277,22 @@ int unregister_netdevice(struct net_devi
/* And unlink it from device chain. */
for (dp = dev_base; (d = *dp) != NULL; dp = d-next) {
Why not for_each_netdev?
it's a different list
Sorry, I still do not understand.
In other words, why will we still have dev-next?
After introducing net_device-dev_list, we do not need
dev-next anymore, do we?
--yoshfuji
-
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: [Xen-devel] kernel BUG at net/core/dev.c:1133!
-Original Message- From: Tim Post [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 16:06 To: Herbert Xu Cc: Petersson, Mats; netdev@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Xen-devel] kernel BUG at net/core/dev.c:1133! I got the exact same thing when attempting to use BOINC on a single node supporting a 5 node open SSI cluster, (5 guests) and yes the problem went away when I flushed the rules. I attributed this to a quirk with the cluster CVIP, because I had also assigned each node its own outbound IP in addition to the incoming CVIP. Since I felt it was due to my tendency to over-tinker, I didn't mention it on the lists, was a few months ago. Thought I would chime in as it sounds like the same experience, up to and including BOINC. I haven't been tinkering with anything [on purpose, at least] - the system is a default installation of FC4, with the latest Xen-unstable [bar the last dozen or so changesets - I don't pull the latest every half-hour]. -- Mats HTH --Tim On Sat, 2006-07-08 at 00:39 +1000, Herbert Xu wrote: Petersson, Mats [EMAIL PROTECTED] wrote: Looks like the GSO is involved? It's certainly what crashed your machine :) It's probably not the guilty party though. Someone is passing through a TSO packet with checksum set to something other than CHECKSUM_HW. I bet it's netfilter and we just never noticed before because real NICS would simply corrupt the checksum silently. Could you confirm that you have netfilter rules (in particular NAT rules) and that this goes away if you flush all your netfilter tables? Patrick, do we really have to zap the checksum on outbound NAT? Could we update it instead? I got this while running Dom0 only (no guests), with a BOINC/[EMAIL PROTECTED] application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). [ cut here ] kernel BUG at net/core/dev.c:1133! invalid opcode: [#1] SMP CPU:0 EIP:0061:[c04dceb0]Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen #12) EIP is at skb_gso_segment+0xf0/0x110 eax: ebx: 0003 ecx: 0002 edx: c06e2e00 esi: 0008 edi: cd9e32e0 ebp: c63a7900 esp: c0de5ad0 ds: 007b es: 007b ss: 0069 Process rosetta_5.25_i6 (pid: 8826, threadinfo=c0de4000 task=cb019560) Stack: 0c8f69060 ffa3 0003 cd9e32e0 0002 c63a7900 c04dcfb0 cd9e32e0 0003 cd9e32e0 cf8e3000 cf8e3140 c04dd07e cd9e32e0 cf8e3000 cd9e32e0 cf8e3000 c04ec07e cd9e32e0 cf8e3000 c0895140 Call Trace: [c04dcfb0] dev_gso_segment+0x30/0xb0 [c04dd07e] dev_hard_start_xmit+0x4e/0x110 [c04ec07e] __qdisc_run+0xbe/0x280 [c04dd4b9] dev_queue_xmit+0x379/0x380 [c05bbe44] br_dev_queue_push_xmit+0xa4/0x140 [c05c2402] br_nf_post_routing+0x102/0x1d0 [c05c22b0] br_nf_dev_queue_xmit+0x0/0x50 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c04f0eab] nf_iterate+0x6b/0xa0 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c05bbf40] br_forward_finish+0x60/0x70 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c05c1b71] br_nf_forward_finish+0x71/0x130 [c05bbee0] br_forward_finish+0x0/0x70 [c05c1d20] br_nf_forward_ip+0xf0/0x1a0 [c05c1b00] br_nf_forward_finish+0x0/0x130 [c05bbee0] br_forward_finish+0x0/0x70 [c04f0eab] nf_iterate+0x6b/0xa0 [c05bbee0] br_forward_finish+0x0/0x70 [c05bbee0] br_forward_finish+0x0/0x70 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05bbee0] br_forward_finish+0x0/0x70 [c05bc044] __br_forward+0x74/0x80 [c05bbee0] br_forward_finish+0x0/0x70 [c05bceb1] br_handle_frame_finish+0xd1/0x160 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05c0e0b] br_nf_pre_routing_finish+0xfb/0x480 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c054fe13] ip_nat_in+0x43/0xc0 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c04f0eab] nf_iterate+0x6b/0xa0 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c05c1914] br_nf_pre_routing+0x404/0x580 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c04f0eab] nf_iterate+0x6b/0xa0 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05bd124] br_handle_frame+0x1e4/0x250 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c04ddae5] netif_receive_skb+0x165/0x2a0 [c04ddcdf] process_backlog+0xbf/0x180 [c04ddebf] net_rx_action+0x11f/0x1d0 [c01262e6] __do_softirq+0x86/0x120 [c01263f5]
RE: [Xen-devel] kernel BUG at net/core/dev.c:1133!
-Original Message- From: Herbert Xu [mailto:[EMAIL PROTECTED] Sent: 07 July 2006 15:40 To: Petersson, Mats Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Xen-devel] kernel BUG at net/core/dev.c:1133! Petersson, Mats [EMAIL PROTECTED] wrote: Looks like the GSO is involved? It's certainly what crashed your machine :) It's probably not the guilty party though. Someone is passing through a TSO packet with checksum set to something other than CHECKSUM_HW. I bet it's netfilter and we just never noticed before because real NICS would simply corrupt the checksum silently. Could you confirm that you have netfilter rules (in particular NAT rules) and that this goes away if you flush all your netfilter tables? If by netfilter, you mean iptables, it says: [EMAIL PROTECTED] ~]# iptables --list Chain FORWARD (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination So, nothing going on there... I certainly haven't got NAT on my machine, as my machine is within the AMD network, and doesn't need NAT. AMD probably uses NAT as part of it's external communications, but I doubt it's used at all internally. I also have noticed the crash happens when I try to access another machine within my local switch - if that makes any difference... But not instantly. I can do some communication with the machine next to it [like I did ssh cheetah from my machine quad to get the iptables above, and it works just fine - but when I did xm dmesg from cheetah through ssh on quad, it didn't work - presumably because it's a bit more data being pushed - but I can't say for sure, as I have made no attempt to really debug it]. I hope this info is of help to analyze the situation, and please feel free to ask for further info. -- Mats Patrick, do we really have to zap the checksum on outbound NAT? Could we update it instead? I got this while running Dom0 only (no guests), with a BOINC/[EMAIL PROTECTED] application running on all 4 cores. changeset: 10649:8e55c5c11475 Build: x86_32p (pae). [ cut here ] kernel BUG at net/core/dev.c:1133! invalid opcode: [#1] SMP CPU:0 EIP:0061:[c04dceb0]Not tainted VLI EFLAGS: 00210297 (2.6.16.13-xen #12) EIP is at skb_gso_segment+0xf0/0x110 eax: ebx: 0003 ecx: 0002 edx: c06e2e00 esi: 0008 edi: cd9e32e0 ebp: c63a7900 esp: c0de5ad0 ds: 007b es: 007b ss: 0069 Process rosetta_5.25_i6 (pid: 8826, threadinfo=c0de4000 task=cb019560) Stack: 0c8f69060 ffa3 0003 cd9e32e0 0002 c63a7900 c04dcfb0 cd9e32e0 0003 cd9e32e0 cf8e3000 cf8e3140 c04dd07e cd9e32e0 cf8e3000 cd9e32e0 cf8e3000 c04ec07e cd9e32e0 cf8e3000 c0895140 Call Trace: [c04dcfb0] dev_gso_segment+0x30/0xb0 [c04dd07e] dev_hard_start_xmit+0x4e/0x110 [c04ec07e] __qdisc_run+0xbe/0x280 [c04dd4b9] dev_queue_xmit+0x379/0x380 [c05bbe44] br_dev_queue_push_xmit+0xa4/0x140 [c05c2402] br_nf_post_routing+0x102/0x1d0 [c05c22b0] br_nf_dev_queue_xmit+0x0/0x50 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c04f0eab] nf_iterate+0x6b/0xa0 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c05bbf40] br_forward_finish+0x60/0x70 [c05bbda0] br_dev_queue_push_xmit+0x0/0x140 [c05c1b71] br_nf_forward_finish+0x71/0x130 [c05bbee0] br_forward_finish+0x0/0x70 [c05c1d20] br_nf_forward_ip+0xf0/0x1a0 [c05c1b00] br_nf_forward_finish+0x0/0x130 [c05bbee0] br_forward_finish+0x0/0x70 [c04f0eab] nf_iterate+0x6b/0xa0 [c05bbee0] br_forward_finish+0x0/0x70 [c05bbee0] br_forward_finish+0x0/0x70 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05bbee0] br_forward_finish+0x0/0x70 [c05bc044] __br_forward+0x74/0x80 [c05bbee0] br_forward_finish+0x0/0x70 [c05bceb1] br_handle_frame_finish+0xd1/0x160 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05c0e0b] br_nf_pre_routing_finish+0xfb/0x480 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c054fe13] ip_nat_in+0x43/0xc0 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c04f0eab] nf_iterate+0x6b/0xa0 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c05c1914] br_nf_pre_routing+0x404/0x580 [c05c0d10] br_nf_pre_routing_finish+0x0/0x480 [c04f0eab] nf_iterate+0x6b/0xa0 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c04f0f4e] nf_hook_slow+0x6e/0x120 [c05bcde0] br_handle_frame_finish+0x0/0x160 [c05bd124]
Re: [patch 8/9] smsc-ircc2: fix section reference mismatches
[EMAIL PROTECTED] wrote:
From: Dmitry Torokhov [EMAIL PROTECTED]
subsystem_configurations array is only used by an __init function,
therefore it should be marked __initdata, not __devinitdata.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/irda/smsc-ircc2.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN
drivers/net/irda/smsc-ircc2.c~smsc-ircc2-fix-section-reference-mismatches
drivers/net/irda/smsc-ircc2.c
--- a/drivers/net/irda/smsc-ircc2.c~smsc-ircc2-fix-section-reference-mismatches
+++ a/drivers/net/irda/smsc-ircc2.c
@@ -2353,7 +2353,7 @@ static int __init smsc_superio_lpc(unsig
#ifdef CONFIG_PCI
#define PCIID_VENDOR_INTEL 0x8086
#define PCIID_VENDOR_ALI 0x10b9
-static struct smsc_ircc_subsystem_configuration subsystem_configurations[]
__devinitdata = {
+static struct smsc_ircc_subsystem_configuration subsystem_configurations[]
__initdata = {
Are you sure this fully solves the problem?
It seems like the functions referenced inside this are inappropriately
marked as well...
-
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
e100 lockdep irq lock inversion.
Another one triggered by a Fedora-development user..
e100: eth1: e100_watchdog: link up, 100Mbps, half-duplex
=
[ INFO: possible irq lock inversion dependency detected ]
-
ipcalc/1671 just changed the state of lock:
(skb_queue_lock_key){-+..}, at: [c05ebe2f] udp_ioctl+0x3b/0x6e
but this lock was taken by another, hard-irq-safe lock in the past:
(ai-aux_lock){+...}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
no locks held by ipcalc/1671.
the first lock's dependencies:
- (skb_queue_lock_key){-+..} ops: 0 {
initial-use at:
[c043c546] lock_acquire+0x4b/0x6d
[c060e5c7] _spin_lock_irqsave+0x22/0x32
[c05b0d2d] skb_queue_tail+0x14/0x32
[c05c8a53] netlink_broadcast+0x1bf/0x28e
[c04e414b] kobject_uevent+0x345/0x3b6
[c055080d] class_device_add+0x2a7/0x3e6
[c0594d0c] input_register_device+0x106/0x238
[c059947a] psmouse_connect+0x162/0x20f
[c0590a09] serio_connect_driver+0x1e/0x2e
[c0590a2f] serio_driver_probe+0x16/0x18
[c054f9a6] driver_probe_device+0x45/0x92
[c054fad3] __driver_attach+0x68/0x93
[c054f420] bus_for_each_dev+0x3a/0x5f
[c054f901] driver_attach+0x14/0x17
[c054f0f7] bus_add_driver+0x68/0x106
[c054fda1] driver_register+0x9d/0xa2
[c0591522] serio_thread+0x152/0x27c
[c04365dc] kthread+0xc3/0xef
[c0402005] kernel_thread_helper+0x5/0xb
in-softirq-W at:
[c043c546] lock_acquire+0x4b/0x6d
[c060e5c7] _spin_lock_irqsave+0x22/0x32
[c05b0d2d] skb_queue_tail+0x14/0x32
[c05b05c4] sock_queue_rcv_skb+0xe3/0x11f
[c060adae] packet_rcv_spkt+0x120/0x136
[c05b5b86] netif_receive_skb+0x1d4/0x26b
[e09fa8e8] e100_poll+0x15a/0x2fc [e100]
[c05b7682] net_rx_action+0xa6/0x1df
[c0429809] __do_softirq+0x78/0xf2
[c04065ab] do_softirq+0x5a/0xbe
hardirq-on-W at:
[c043c546] lock_acquire+0x4b/0x6d
[c060e2c8] _spin_lock_bh+0x1e/0x2d
[c05ebe2f] udp_ioctl+0x3b/0x6e
[c05f08e7] inet_ioctl+0x8c/0x91
[c05acabc] sock_ioctl+0x1b5/0x1d3
[c0481e56] do_ioctl+0x22/0x67
[c04820f3] vfs_ioctl+0x258/0x26b
[c048214d] sys_ioctl+0x47/0x62
[c0403f2f] syscall_call+0x7/0xb
}
... key at: [c09b0748] skb_queue_lock_key+0x0/0x18
the second lock's dependencies:
- (ai-aux_lock){+...} ops: 0 {
initial-use at:
[c043c546] lock_acquire+0x4b/0x6d
[c060e5c7] _spin_lock_irqsave+0x22/0x32
[e09b6cd8] mpi_start_xmit+0x79/0xdd [airo]
[c05b5fc5] dev_hard_start_xmit+0x19f/0x1fc
[c05c48d8] __qdisc_run+0xdd/0x197
[c05b7a40] dev_queue_xmit+0x12a/0x222
[c060a98a] packet_sendmsg_spkt+0x172/0x199
[c05ac5df] sock_sendmsg+0xe8/0x103
[c05ad7a7] sys_sendto+0xbe/0xdc
[c05adf27] sys_socketcall+0xfb/0x186
[c0403f2f] syscall_call+0x7/0xb
in-hardirq-W at:
[c043c546] lock_acquire+0x4b/0x6d
[c060e5c7] _spin_lock_irqsave+0x22/0x32
[e09b7b6d] airo_interrupt+0xe31/0xffb [airo]
[c0451020] handle_IRQ_event+0x20/0x4d
[c04510e1] __do_IRQ+0x94/0xef
[c04066c8] do_IRQ+0xb9/0xcd
[c04049d1] common_interrupt+0x25/0x2c
[c04030aa] cpu_idle+0xa7/0xc1
[c0400591] rest_init+0x23/0x26
[c07a7810] start_kernel+0x3a1/0x3a9
[c0400210] 0xc0400210
}
... key at: [e09c2a80] __key.24227+0x0/0x6704 [airo]
- (skb_queue_lock_key){-+..} ops: 0 {
initial-use at:
[c043c546] lock_acquire+0x4b/0x6d
[c060e5c7] _spin_lock_irqsave+0x22/0x32
[c05b0d2d] skb_queue_tail+0x14/0x32
[c05c8a53] netlink_broadcast+0x1bf/0x28e
[c04e414b] kobject_uevent+0x345/0x3b6
[c055080d]
[PATCH] sky2: fix trucated collision threshold mask
Patch to correct broken collision threshold mask in sky2 driver. Should be
three bits wide, but the mask only allows for 1 bit to be set.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
sky2.h |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/sky2.h b/drivers/net/sky2.h
index 8a0bc55..2db8d19 100644
--- a/drivers/net/sky2.h
+++ b/drivers/net/sky2.h
@@ -1480,7 +1480,7 @@ enum {
GM_TXCR_FORCE_JAM = 115, /* Bit 15: Force Jam /
Flow-Control */
GM_TXCR_CRC_DIS = 114, /* Bit 14: Disable insertion of
CRC */
GM_TXCR_PAD_DIS = 113, /* Bit 13: Disable padding of
packets */
- GM_TXCR_COL_THR_MSK = 110, /* Bit 12..10: Collision Threshold */
+ GM_TXCR_COL_THR_MSK = 710, /* Bit 12..10: Collision Threshold */
};
#define TX_COL_THR(x) (((x)10) GM_TXCR_COL_THR_MSK)
--
/***
*Neil Horman
*Software Engineer
*gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu
***/
-
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 NET 00/04]: Increase number of possible routing tables
Patrick McHardy wrote: Patrick McHardy wrote: I took on Ben's challenge to increase the number of possible routing tables, these are the resulting patches. I am seeing problems..though they could be with the way I'm using the tool or pehaps I patched the kernel incorrectly. I applied the 3 patches to 2.6.17..all patches applied without problem, but with a few lines of fuzz. I get the same behaviour with and without the new 'ip' patches applied. If I do an 'ip ru show', then I see lots of tables, though not all it seems. (I have not tried beyond 205 yet). But, if I do an 'ip route show table XX', then I see nothing or incorrect values. For my test, I am creating 200 virtual interfaces (mac-vlans in my case, but 802.1q should work equally well.) I am giving them all IP addrs on the same subnet, and a routing table for each source IP addr. The commands I run to generate the routing tables are found in this file: http://www.candelatech.com/oss/gc.txt When I change back to kernel 2.6.16.16 with only my patchset applied, things seem to be working, so it looks like an issue with the new kernel patches. I can provide access to this machine as well as my full patch set, etc... For whatever reason, table 5 does appear in a bizarre fashion: [EMAIL PROTECTED] lanforge]$ more ~/tmp/ip.txt [EMAIL PROTECTED] lanforge]# ip route show table 5 10.1.2.0/24 via 10.1.2.2 dev eth1#0 default via 10.1.2.1 dev eth1#0 [EMAIL PROTECTED] lanforge]# ip route show table 4 [EMAIL PROTECTED] lanforge]# ip route show table 3 [EMAIL PROTECTED] lanforge]# ip route show table 2 [EMAIL PROTECTED] lanforge]# ip route show table 1 [EMAIL PROTECTED] lanforge]# ip route show table 0 10.1.2.0/24 via 10.1.2.2 dev eth1#0 table 5 default via 10.1.2.1 dev eth1#0 table 5 # Here is a listing of 'ip ru show'. [EMAIL PROTECTED] lanforge]$ more ~/tmp/ru.txt 0: from all lookup local 31203: from 10.1.2.144 lookup 147 31204: from 10.1.2.143 lookup 146 31205: from 10.1.2.142 lookup 145 31206: from 10.1.2.141 lookup 144 31207: from 10.1.2.140 lookup 143 31208: from 10.1.2.139 lookup 142 31209: from 10.1.2.138 lookup 141 31210: from 10.1.2.137 lookup 140 31211: from 10.1.2.136 lookup 139 31212: from 10.1.2.135 lookup 138 31213: from 10.1.2.134 lookup 137 31214: from 10.1.2.133 lookup 136 31215: from 10.1.2.132 lookup 135 31216: from 10.1.2.131 lookup 134 31217: from 10.1.2.130 lookup 133 31218: from 10.1.2.129 lookup 132 31219: from 10.1.2.128 lookup 131 31220: from 10.1.2.127 lookup 130 31221: from 10.1.2.126 lookup 129 31222: from 10.1.2.125 lookup 128 31223: from 10.1.2.124 lookup 127 31224: from 10.1.2.123 lookup 126 31225: from 10.1.2.122 lookup 125 31226: from 10.1.2.121 lookup 124 31227: from 10.1.2.120 lookup 123 31228: from 10.1.2.119 lookup 122 31229: from 10.1.2.118 lookup 121 31230: from 10.1.2.117 lookup 120 31231: from 10.1.2.116 lookup 119 31232: from 10.1.2.115 lookup 118 31233: from 10.1.2.114 lookup 117 31234: from 10.1.2.113 lookup 116 31235: from 10.1.2.201 lookup 204 31236: from 10.1.2.200 lookup 203 31237: from 10.1.2.199 lookup 202 31238: from 10.1.2.198 lookup 201 31239: from 10.1.2.197 lookup 200 31240: from 10.1.2.196 lookup 199 31241: from 10.1.2.195 lookup 198 31242: from 10.1.2.112 lookup 115 31243: from 10.1.2.111 lookup 114 31244: from 10.1.2.110 lookup 113 31245: from 10.1.2.109 lookup 112 31246: from 10.1.2.108 lookup 111 31247: from 10.1.2.107 lookup 110 31248: from 10.1.2.106 lookup 109 31249: from 10.1.2.105 lookup 108 31250: from 10.1.2.104 lookup 107 31251: from 10.1.2.103 lookup 106 31252: from 10.1.2.102 lookup 105 31253: from 10.1.2.101 lookup 104 31254: from 10.1.2.100 lookup 103 31255: from 10.1.2.99 lookup 102 31256: from 10.1.2.98 lookup 101 31257: from 10.1.2.97 lookup 100 31258: from 10.1.2.96 lookup 99 31259: from 10.1.2.95 lookup 98 31260: from 10.1.2.94 lookup 97 31261: from 10.1.2.93 lookup 96 31262: from 10.1.2.92 lookup 95 31263: from 10.1.2.91 lookup 94 31264: from 10.1.2.90 lookup 93 31265: from 10.1.2.89 lookup 92 31266: from 10.1.2.88 lookup 91 31267: from 10.1.2.87 lookup 90 31268: from 10.1.2.86 lookup 89 31269: from 10.1.2.85 lookup 88 31270: from 10.1.2.84 lookup 87 31271: from 10.1.2.83 lookup 86 31272: from 10.1.2.82 lookup 85 31273: from 10.1.2.81 lookup 84 31274: from 10.1.2.80 lookup 83 31275: from 10.1.2.79 lookup 82 Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - 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: rtl8139: NETDEV WATCHDOG: eth0: transmit timed out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (For those haven't followed, this is about http://permalink.gmane.org/gmane.linux.network/38493 ) Francois Romieu wrote: Marcus Better [EMAIL PROTECTED] : I'm seeing this problem on my Acer Travelmate 223X laptop with built-in Realtek 8139: The ethernet stops working, usually after at most a few minutes operation. In a better world, you would narrow the suspect with a git bissect [1] between v2.6.15 and v2.6.16. I did, and the winner after 13 reboots is... commit de227f5f32775d86e5c780a7cffdd2e08574f7fb Author: Dave Airlie [EMAIL PROTECTED](none) Date: Wed Jan 25 15:31:43 2006 +1100 drm: i915 patches from Tungsten Graphics Fix CMDBUFFER path, add heap destroy and flesh out sarea for rotation (Tungsten Graphics) From: Alan Hourihane [EMAIL PROTECTED] Signed-off-by: Dave Airlie [EMAIL PROTECTED] I didn't believe it at first either, but blacklisting the i915 module actually fixes the problem. Now that I know what to look for, I notice that the network errors always started cropping up after X11 started. Wonder what's going on here. Why is the graphics driver killing my network? Marcus -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEroy7XjXn6TzcAQkRAp7bAJ9F7HgWg+VsvQ0fwkK3+b4Ne+tASwCg8+m3 8i5BoW+ujUjoX3DLW0QKAPQ= =MDAc -END PGP SIGNATURE- - 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
auro deadlock (was Re: e100 lockdep irq lock inversion.)
On Fri, 2006-07-07 at 13:19 -0400, Dave Jones wrote:
Another one triggered by a Fedora-development user..
e100: eth1: e100_watchdog: link up, 100Mbps, half-duplex
=
[ INFO: possible irq lock inversion dependency detected ]
-
ipcalc/1671 just changed the state of lock:
(skb_queue_lock_key){-+..}, at: [c05ebe2f] udp_ioctl+0x3b/0x6e
but this lock was taken by another, hard-irq-safe lock in the past:
(ai-aux_lock){+...}
and interrupts could create inverse lock ordering between them.
ok the situation is this:
the airo driver has a per card aux_lock.
This lock is used in the hardirq handler, and thus all uses need to be
irqsave (and they are)
Act 1
Enter the mpi_start_xmit() function, which is airo's xmit function.
This function takes the aux_lock first, with irq's off, then calls
skb_queue_tail(). skb_queue_tail takes the sk_receive_queue.lock (with
irqsave as well).
Act 2
Enter the ipcalc program. This program calls an ioctl, which ends up
calling udp_ioctl. udp_ioctl does
spin_lock_bh(sk-sk_receive_queue.lock);
This is a deadlock
For brevity, lock A is the aux_lock, lock B is the sk_receive_queue.lock
CPU 0 CPU 1
user contextuser context
udp_ioctl takes lock B with _bh
(leaving irqs enabled)
mpi_start_function takes
lock A with _irqsave
mpi_start_function takes
lock B with _irqsave and spins
interrupt happens
the hard irq handler takes lock A
and spins for cpu 0
eg a classic AB-BA deadlock.
Now a question for netdev: what is the interrupt-or-softirq rules for
the sk_receive_queue.lock?
Anyway, the patch below fixes this deadlock; it may or may not be the
correct solution depending on the netdev answer, but the deadlock is
gone ;)
Signed-off-by: Arjan van de Ven
Index: linux-2.6.18-rc1/net/ipv4/udp.c
===
--- linux-2.6.18-rc1.orig/net/ipv4/udp.c
+++ linux-2.6.18-rc1/net/ipv4/udp.c
@@ -725,6 +725,7 @@ out:
int udp_ioctl(struct sock *sk, int cmd, unsigned long arg)
{
+ unsigned long flags;
switch(cmd)
{
case SIOCOUTQ:
@@ -739,7 +740,7 @@ int udp_ioctl(struct sock *sk, int cmd,
unsigned long amount;
amount = 0;
- spin_lock_bh(sk-sk_receive_queue.lock);
+ spin_lock_irqsave(sk-sk_receive_queue.lock, flags);
skb = skb_peek(sk-sk_receive_queue);
if (skb != NULL) {
/*
@@ -749,7 +750,7 @@ int udp_ioctl(struct sock *sk, int cmd,
*/
amount = skb-len - sizeof(struct udphdr);
}
- spin_unlock_bh(sk-sk_receive_queue.lock);
+ spin_unlock_irqrestore(sk-sk_receive_queue.lock,
flags);
return put_user(amount, (int __user *)arg);
}
-
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/9] e1000: irq naming update
[EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] Use the new names. Cc: Auke Kok [EMAIL PROTECTED] Cc: Jeff Garzik [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Of course. I'll check on ixgb. Add my Acked-by: Auke Kok [EMAIL PROTECTED] cheers, Auke --- drivers/net/e1000/e1000_main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/e1000/e1000_main.c~e1000-irq-naming-update drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c~e1000-irq-naming-update +++ a/drivers/net/e1000/e1000_main.c @@ -283,7 +283,7 @@ static int e1000_request_irq(struct e100 } } if (adapter-have_msi) - flags = ~SA_SHIRQ; + flags = ~IRQF_SHARED; #endif if ((err = request_irq(adapter-pdev-irq, e1000_intr, flags, netdev-name, netdev))) _ - 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 - 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: What is RDMA (was: RDMA will be reverted)
Great summation. Comments in-line... On Fri, 2006-07-07 at 18:11 +1000, Herbert Xu wrote: On Fri, Jul 07, 2006 at 06:53:20AM +, David Miller wrote: What I am saying, however, is that we need to understand the technology and the hooks you guys want before we put any of it in. Yes indeed. Here is what I've understood so far so let's see if we can start building a censensus. 1) RDMA over straight Infiniband is not contentious. In this case no IP networking is involved. Some IP networking is involved for this. IP addresses and port numbers are used by the RDMA Connection Manager. The motivation for this was two-fold, I think: 1) to simplify the connection setup model. The IB CM model was very complex. 2) to allow ULPs to be transport independent. Thus a single code base for NFSoRDMA, for example, can run over Infiniband and RDMA/TCP transports without code changes or knowing about transport-specific addressing. The routing table is also consulted to determine which rdma device should be used for connection setup. Each rdma device also installs a netdev device for native stack traffic. The RDMA CM maintains an association between the netdev device and the rdma device. And the Infiniband subsystem uses ARP over IPoIB to map IP addresses to GID/QPN info. This is done by calling arp_send() directly, and snooping all ARP packets to discover when the arp entry is completed. 2) RDMA over TCP/IP (or SCTP) can theoretically run on any network that supported IP, including Infiniband and Ethernet. 3) When RDMA over TCP is completely done in hardware, i.e., it has its own IP address, MAC address, and simply presents an RDMA interface (whatever that may be) to Linux, we're OK with it. This is similar to how some iSCSI adapters work. The Ammasso driver implements this method. It supports 2 mac addresses on the single GigE port: 1 for native host networking traffic only, and one for RDMA/TCP only. The firmware implements a full TCP/IP/ARP/ICMP stack and handles all function of the RDMA/TCP connection setup. However, even these types of devices need some integration with the networking subsystem. Namely the existing Infiniband rdma connection manager assumes it will find a netdev device for each rdma device registered. So it uses the routing table to look up a netdev to determine which rdma device should be used for connection setup. The Ammasso driver installs 2 netdevs, one of which is a virtual device used soley for assigning IP addresses to the RDMA side of the nic, and for the RDMA CM to find this device... 4) When RDMA over TCP is done completely in the Linux networking stack, we don't have a problem because the existing TCP stack is still in charge. However, this is pretty pointless. Indeed. I see one case where this model might be useful: If the optimizations that RDMA gives helps mainly the server side of an application, then the client side might use a software-only rdma stack and a dumb nic. The server buys the deep rnic adapter and gets the perf benefits... 5) RDMA over TCP on the receive side is offloaded into the NIC. This allows the NIC to directly place data into the application's buffer. We're starting to have a little bit of a problem because it means that part of the incoming IP traffic is now being directly processed by the NIC, with no input from the Linux TCP/IP stack. However, as long as the connection establishment/acks are still controlled/seen by Linux we can probably live with it. 6) RDMA over TCP on the transmit side is offloaded into the NIC. This is starting to look very worrying. The reason is that we lose all control to crucial aspects of TCP like congestion control. It is now completely up to the NIC to do that. For straight RDMA over Infiniband this isn't an issue because the traffic is not likely to travel across the Internet. However, for RDMA over TCP, one of their goals is to support sending traffic over the Internet so this is a concern. Incidentally, this is why they need to know about things like MAC/route/MTU changing. 7) RDMA over TCP is completely offloaded into the NIC, however, they still use Linux's IP address, MAC address, and rely on us to tell it about events such as MTU updates or MAC changes. I only know of type 3 rnics (ammasso) and type 7 rnics (chelsio + others). I haven't seen any type 5 or 6 designs yet for RDMA/TCP... In addition to the problems we have in 5) and 6), we now have a portion of TCP port space which has suddenly become invisible to Linux. What's more, we lose control (e.g., netfilter) over what connections may or may not be established. port space issues and netfilter integration can be fixed, I think, if there is a desire to do so. So to my mind, RDMA over TCP is most problematic when it shares the same IP/MAC address as the Linux host,
Re: [Bugme-new] [Bug 6802] New: pktgen cause kernel oops with transmit load balanced bonding
On Fri, 7 Jul 2006 07:37:52 -0700
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=6802
Summary: pktgen cause kernel oops with transmit load balanced
bonding
Kernel Version: 2.4.32, 2.6.17.2
Status: NEW
Severity: high
Owner: [EMAIL PROTECTED]
Submitter: [EMAIL PROTECTED]
Most recent kernel where this bug did not occur:
not found
Distribution:
Fedora Core 4
Hardware Environment:
i386, ppc
Software Environment:
gcc
Problem Description:
If running the kernel packet generator (pktgen), and the output device is set
to bonding interface with mode balance-tlb or balance-alb, then there will be
kernel oops.
I only set the odev, dst and count (as 0 for infinite test) for the pktgen. I
wonder if I made mistake for the pktgen parameters but it doesn't cause
problem
if the odev set to physical device such as eth0, etc.
My investigations shows that the problem happen when the bond_alb_xmit tries
to
access the daddr fields of IP header in skb-nh.iph. If I did the same in
round-
robin mode, it can generate oops too.
Steps to reproduce:
1. Build kernel with pktgen (CONFIG_NET_PKTGEN) and bonding driver
(CONFIG_BONDING).
2. Setup bonding interface.
ifenslave bond0 eth0
3. Create a script for starting packet generator,
the script I start packet generator for kernel 2.4 series is like following:
---cut here
#! /bin/sh
modprobe pktgen
PGDEV=/proc/net/pktgen/pg0
function pgset() {
local result
echo $1 $PGDEV
result=`cat $PGDEV | fgrep Result: OK:`
if [ $result = ]; then
cat $PGDEV | fgrep Result:
fi
}
function pg() {
echo inject $PGDEV
cat $PGDEV
}
pgset odev bond0
pgset dst 127.1.16.1
pgset count 0
pg
---cut here
4. If the odev is set to eth0, the this script will not have problem, problem
only happen when it is set to bond0.
Please send (via an emailed reply-to-all) a copy of the oops output.
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: Add ECN support for TSO
Michael, Are network cards expected to be aware-of and implement RFC3540(ECN with nonces) ? Thanks, Ravi -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Chan Sent: Tuesday, June 27, 2006 8:07 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: netdev@vger.kernel.org Subject: [PATCH]NET: Add ECN support for TSO In the current TSO implementation, NETIF_F_TSO and ECN cannot be turned on together in a TCP connection. The problem is that most hardware that supports TSO does not handle CWR correctly if it is set in the TSO packet. Correct handling requires CWR to be set in the first packet only if it is set in the TSO header. This patch adds the ability to turn on NETIF_F_TSO and ECN using GSO if necessary to handle TSO packets with CWR set. Hardware that handles CWR correctly can turn on NETIF_F_TSO_ECN in the dev- features flag. All TSO packets with CWR set will have the SKB_GSO_TCPV4_ECN set. If the output device does not have the NETIF_F_TSO_ECN feature set, GSO will split the packet up correctly with CWR only set in the first segment. It is further assumed that all hardware will handle ECE properly by replicating the ECE flag in all segments. If that is not the case, a simple extension of the logic will be required. Signed-off-by: Michael Chan [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: starting mc triggers lockdep
On Fri, 2006-07-07 at 12:13 -0400, Dave Jones wrote:
With 2.6.18rc1 + a selection of the lockdep tweaks found so far,
midnight commander makes the kernel unhappy.
Dave
===
[ INFO: possible circular locking dependency detected ]
---
mc/4913 is trying to acquire lock:
(sk_lock-AF_INET){--..}, at: [8022800c] tcp_sendmsg+0x1f/0xb1a
but task is already holding lock:
(inode-i_mutex){--..}, at: [802692e0] mutex_lock+0x2a/0x2e
which lock already depends on the new lock.
ok this looks like a fun three-way variant of the traditional AB-BA
deadlock... an ABCA deadlock :)
Lock A: rtnl_mutex
Lock B: i_mutex
Lock C: sk_lock for AF_INET
i_mutex is taken within rtln_mutex like this:
[8030f4a0] create_dir+0x2c/0x1e2
[8030fa5b] sysfs_create_dir+0x59/0x78
[8034d2e2] kobject_add+0x114/0x1d8
[803bb1e7] class_device_add+0xb5/0x49d
[804300b1] netdev_register_sysfs+0x98/0xa2
[80426f58] register_netdevice+0x28c/0x376
[8042709c] register_netdev+0x5a/0x69
creating the AB dependency
now for the second part:
if you use the IP_DROP_MEMBERSHIP socket option, you end up going into
the function do_ip_setsockopt(), which first does a lock_sock(), and
then a call to ip_mc_leave_group(), which calls rtnl_lock()
So we have the CA dependency right here.
now for the third part, which involves the nfs client:
stat on an nfs file, which ends up taken the i_mutex of a directory in
the path (obvious), and then does
[8022800b] tcp_sendmsg+0x1e/0xb1a
[80248f4b] inet_sendmsg+0x45/0x53
[80259d25] sock_sendmsg+0x110/0x130
[8041f462] kernel_sendmsg+0x3c/0x52
[885399e9] xs_tcp_send_request+0x117/0x320 [sunrpc]
[885388d5] xprt_transmit+0x105/0x21e [sunrpc]
[8853771e] call_transmit+0x1f4/0x239 [sunrpc]
[8853c06e] __rpc_execute+0x9b/0x1e6 [sunrpc]
[8853c1de] rpc_execute+0x1a/0x1d [sunrpc]
[885364ad] rpc_call_sync+0x87/0xb9 [sunrpc]
[885a2587] nfs3_rpc_wrapper+0x2e/0x74 [nfs]
[885a2a14] nfs3_proc_lookup+0xe0/0x163 [nfs]
where tcp_sendmsg calls lock_sock. So this is the BC dependency.
In summary, we have an AB dependency, a BC dependency and a CA
dependency. This is reason for lockdep to conclude that there is a
circular dependency happening, which, looking at my analysis, seems to
be at least reasonably right...
-
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: more rc1 lockdep fun.
On Fri, 2006-07-07 at 14:58 -0400, Dave Jones wrote:
===
[ INFO: possible circular locking dependency detected ]
---
gnome-settings-/3278 is trying to acquire lock:
(sk_lock-AF_INET){--..}, at: [8022800c] tcp_sendmsg+0x1f/0xb1a
this appears to be the same one as the mc one I just looked at.
-
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/7] net_device list cleanup: drivers and non-IP protocols
On Mon, 3 Jul 2006 12:18:54 +0400 Andrey Savochkin [EMAIL PROTECTED] wrote: Cleanup of net_device list use in network device drivers and protocols other than IP. The cleanup consists of - converting the to list_head, to make the list double-linked (thus making remove operation O(1)), and list walks more readable; Maybe this should be RCU'd to get rid of the read_lock. - introducing of for_each_netdev wrapper over list_for_each. Signed-off-by: Andrey Savochkin [EMAIL PROTECTED] Looks good 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] tg3: add amd8131 to write reorder chipsets
On Fri, Jul 07, 2006 at 12:12:20PM -0700, David Miller wrote: From: John W. Linville [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 14:58:36 -0400 Add the AMD 8131 bridge to the list of chipsets that reorder writes. Signed-off-by: John W. Linville [EMAIL PROTECTED] What failure report is this chipset blacklist addition based upon? I just want to look at the paper trail before adding this. What? Due diligence? You must be joking!!! :-) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174019#c48 Hth! John -- John W. Linville [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
more rc1 lockdep fun.
===
[ INFO: possible circular locking dependency detected ]
---
gnome-settings-/3278 is trying to acquire lock:
(sk_lock-AF_INET){--..}, at: [8022800c] tcp_sendmsg+0x1f/0xb1a
but task is already holding lock:
(inode-i_mutex){--..}, at: [802692e0] mutex_lock+0x2a/0x2e
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #2 (inode-i_mutex){--..}:
[802ab6d5] lock_acquire+0x4a/0x69
[80269102] __mutex_lock_slowpath+0xeb/0x29f
[802692df] mutex_lock+0x29/0x2e
[8030f4a0] create_dir+0x2c/0x1e2
[8030fa5b] sysfs_create_dir+0x59/0x78
[8034d2e2] kobject_add+0x114/0x1d8
[803bb1e7] class_device_add+0xb5/0x49d
[804300b1] netdev_register_sysfs+0x98/0xa2
[80426f58] register_netdevice+0x28c/0x376
[8042709c] register_netdev+0x5a/0x69
[8098aa12] loopback_init+0x4e/0x53
[8098a918] net_olddevs_init+0xb/0xb7
[80270918] init+0x177/0x348
[80263cdd] child_rip+0x7/0x12
- #1 (rtnl_mutex){--..}:
[802ab6d5] lock_acquire+0x4a/0x69
[80269102] __mutex_lock_slowpath+0xeb/0x29f
[802692df] mutex_lock+0x29/0x2e
[8042e0a2] rtnl_lock+0xf/0x12
[8045c7b8] ip_mc_leave_group+0x1e/0xae
[804467f7] do_ip_setsockopt+0x6ad/0x9b2
[80446baa] ip_setsockopt+0x2a/0x84
[80454a55] udp_setsockopt+0xd/0x1c
[8041f7ea] sock_common_setsockopt+0xe/0x11
[8041e965] sys_setsockopt+0x8e/0xb4
[80262f19] tracesys+0xd0/0xdb
- #0 (sk_lock-AF_INET){--..}:
[802ab6d5] lock_acquire+0x4a/0x69
[802371ea] lock_sock+0xd4/0xe7
[8022800b] tcp_sendmsg+0x1e/0xb1a
[80248f4b] inet_sendmsg+0x45/0x53
[80259d25] sock_sendmsg+0x110/0x130
[8041f462] kernel_sendmsg+0x3c/0x52
[885359e9] xs_tcp_send_request+0x117/0x320 [sunrpc]
[885348d5] xprt_transmit+0x105/0x21e [sunrpc]
[8853371e] call_transmit+0x1f4/0x239 [sunrpc]
[8853806e] __rpc_execute+0x9b/0x1e6 [sunrpc]
[885381de] rpc_execute+0x1a/0x1d [sunrpc]
[885324ad] rpc_call_sync+0x87/0xb9 [sunrpc]
[8859e587] nfs3_rpc_wrapper+0x2e/0x74 [nfs]
[8859ea14] nfs3_proc_lookup+0xe0/0x163 [nfs]
[88590b10] nfs_lookup+0xef/0x1d6 [nfs]
[8020d300] do_lookup+0xd0/0x18c
[802098b6] __link_path_walk+0x3b8/0xf7d
[8020f076] link_path_walk+0x69/0x101
[8020d096] do_path_lookup+0x27b/0x2e7
[802258da] __user_walk_fd+0x40/0x5c
[802360f7] sys_faccessat+0xf3/0x1aa
[802e08a5] sys_access+0x12/0x15
[80262f19] tracesys+0xd0/0xdb
other info that might help us debug this:
1 lock held by gnome-settings-/3278:
#0: (inode-i_mutex){--..}, at: [802692e0] mutex_lock+0x2a/0x2e
stack backtrace:
Call Trace:
[80271910] show_trace+0xaa/0x23d
[80271ab8] dump_stack+0x15/0x17
[802a992f] print_circular_bug_tail+0x6c/0x77
[802aaf34] __lock_acquire+0x853/0xa54
[802ab6d6] lock_acquire+0x4b/0x69
[802371eb] lock_sock+0xd5/0xe7
[8022800c] tcp_sendmsg+0x1f/0xb1a
[80248f4c] inet_sendmsg+0x46/0x53
[80259d26] sock_sendmsg+0x111/0x130
[8041f463] kernel_sendmsg+0x3d/0x52
[885359ea] :sunrpc:xs_tcp_send_request+0x118/0x320
[885348d6] :sunrpc:xprt_transmit+0x106/0x21e
[8853371f] :sunrpc:call_transmit+0x1f5/0x239
[8853806f] :sunrpc:__rpc_execute+0x9c/0x1e6
[885381df] :sunrpc:rpc_execute+0x1b/0x1d
[885324ae] :sunrpc:rpc_call_sync+0x88/0xb9
[8859e588] :nfs:nfs3_rpc_wrapper+0x2f/0x74
[8859ea15] :nfs:nfs3_proc_lookup+0xe1/0x163
[88590b11] :nfs:nfs_lookup+0xf0/0x1d6
[8020d301] do_lookup+0xd1/0x18c
[802098b7] __link_path_walk+0x3b9/0xf7d
[8020f077] link_path_walk+0x6a/0x101
[8020d097] do_path_lookup+0x27c/0x2e7
[802258db] __user_walk_fd+0x41/0x5c
[802360f8] sys_faccessat+0xf4/0x1aa
[802e08a6] sys_access+0x13/0x15
[80262f1a] tracesys+0xd1/0xdb
--
http://www.codemonkey.org.uk
-
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: auro deadlock
From: Arjan van de Ven [EMAIL PROTECTED] Date: Fri, 07 Jul 2006 20:13:09 +0200 Now a question for netdev: what is the interrupt-or-softirq rules for the sk_receive_queue.lock? Anyway, the patch below fixes this deadlock; it may or may not be the correct solution depending on the netdev answer, but the deadlock is gone ;) The lockdep fixes are starting to cause us to go in and start adding hard IRQ protection to many socket layer objects and I want this thinking to end quickly :) The netlink wireless fix is another example of this, but I accept the temporary fix for that one for the time being. To reiterate, nothing socket or SKB level should be taking anything deeper than software IRQ locking. If drivers manage local SKB queues in hard IRQ context, they need to use a seperate lockdep identifier for that queue's lock. - 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: more rc1 lockdep fun.
From: Arjan van de Ven [EMAIL PROTECTED]
Date: Fri, 07 Jul 2006 21:03:35 +0200
On Fri, 2006-07-07 at 14:58 -0400, Dave Jones wrote:
===
[ INFO: possible circular locking dependency detected ]
---
gnome-settings-/3278 is trying to acquire lock:
(sk_lock-AF_INET){--..}, at: [8022800c] tcp_sendmsg+0x1f/0xb1a
this appears to be the same one as the mc one I just looked at.
This is what I think too, I'll look at Arjan's analysis later this
afternoon.
-
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: auro deadlock
On Fri, 2006-07-07 at 12:09 -0700, David Miller wrote: From: Arjan van de Ven [EMAIL PROTECTED] Date: Fri, 07 Jul 2006 20:13:09 +0200 Now a question for netdev: what is the interrupt-or-softirq rules for the sk_receive_queue.lock? Anyway, the patch below fixes this deadlock; it may or may not be the correct solution depending on the netdev answer, but the deadlock is gone ;) The lockdep fixes are starting to cause us to go in and start adding hard IRQ protection to many socket layer objects and I want this thinking to end quickly :) that's why I asked the question ;) To reiterate, nothing socket or SKB level should be taking anything deeper than software IRQ locking. If drivers manage local SKB queues in hard IRQ context, they need to use a seperate lockdep identifier for that queue's lock. I'm not so sure that;s the case here, but.. if you have time today I hope you can take a look at this one with a wider network view than I can.. - 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 8/9] smsc-ircc2: fix section reference mismatches
On 7/7/06, Jeff Garzik [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
From: Dmitry Torokhov [EMAIL PROTECTED]
subsystem_configurations array is only used by an __init function,
therefore it should be marked __initdata, not __devinitdata.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/irda/smsc-ircc2.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN
drivers/net/irda/smsc-ircc2.c~smsc-ircc2-fix-section-reference-mismatches
drivers/net/irda/smsc-ircc2.c
---
a/drivers/net/irda/smsc-ircc2.c~smsc-ircc2-fix-section-reference-mismatches
+++ a/drivers/net/irda/smsc-ircc2.c
@@ -2353,7 +2353,7 @@ static int __init smsc_superio_lpc(unsig
#ifdef CONFIG_PCI
#define PCIID_VENDOR_INTEL 0x8086
#define PCIID_VENDOR_ALI 0x10b9
-static struct smsc_ircc_subsystem_configuration subsystem_configurations[]
__devinitdata = {
+static struct smsc_ircc_subsystem_configuration subsystem_configurations[]
__initdata = {
Are you sure this fully solves the problem?
I think so, at least I see no more warnigns...
It seems like the functions referenced inside this are inappropriately
marked as well...
subsystem_configurations is only used from
smsc_ircc_preconfigure_subsystems(), which is called from
smsc_ircc_init(). Both of these are __init. All methods in
subsystem_configurations are marked as __init as well. Seems logical
that the strcture should be marked __initdata.
--
Dmitry
-
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] tg3: add amd8131 to write reorder chipsets
John W. Linville wrote: Add the AMD 8131 bridge to the list of chipsets that reorder writes. Signed-off-by: John W. Linville [EMAIL PROTECTED] Hi John, The latest tg3 driver in 2.6.18 has a recovery mechanism to detect and recover from this kind of reordering problem. I suppose we can add this chipset now if we're reasonably sure that it is reordering MMIO. But it will be nice to actually see the recovery mechanism in action catching this chipset. - 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 NET 00/04]: Increase number of possible routing tables
Ben Greear wrote:
Patrick McHardy wrote:
I took on Ben's challenge to increase the number of possible routing
tables, these are the resulting patches.
I am seeing problems..though they could be with the way I'm using the tool
or pehaps I patched the kernel incorrectly.
I applied the 3 patches to 2.6.17..all patches applied without problem,
but with a few lines of fuzz. I get the same behaviour with and
without the new 'ip' patches applied.
If I do an 'ip ru show', then I see lots of tables, though not all it
seems. (I have not tried beyond 205 yet). But, if I do an
'ip route show table XX', then I see nothing or incorrect values.
My patches introduced a bug when dumping tables which could lead to
incorrect routes beeing dumped. A second bug (that already existed)
makes the kernel fail when dumping more rules than fit in a skb.
I think I've already seen the patch to address the second problem
a short time ago sent by someone else. Anyway, this patch should
fix both.
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 3c49e6b..6e1aaa4 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -357,6 +357,7 @@ int inet_dump_fib(struct sk_buff *skb, s
unsigned int e = 0, s_e;
struct fib_table *tb;
struct hlist_node *node;
+ int dumped = 0;
if (NLMSG_PAYLOAD(cb-nlh, 0) = sizeof(struct rtmsg)
((struct rtmsg*)NLMSG_DATA(cb-nlh))-rtm_flagsRTM_F_CLONED)
@@ -365,16 +366,17 @@ int inet_dump_fib(struct sk_buff *skb, s
s_h = cb-args[0];
s_e = cb-args[1];
- for (h = s_h; h FIB_TABLE_HASHSZ; h++) {
+ for (h = s_h; h FIB_TABLE_HASHSZ; h++, s_e = 0) {
e = 0;
hlist_for_each_entry(tb, node, fib_table_hash[h], tb_hlist) {
if (e s_e)
goto next;
- if (e s_e)
- memset(cb-args[1], 0, sizeof(cb-args) -
+ if (dumped)
+ memset(cb-args[2], 0, sizeof(cb-args) -
2 * sizeof(cb-args[0]));
if (tb-tb_dump(tb, skb, cb) 0)
goto out;
+ dumped = 1;
next:
e++;
}
diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
index a41ab4b..6f33f12 100644
--- a/net/ipv4/fib_rules.c
+++ b/net/ipv4/fib_rules.c
@@ -459,13 +459,13 @@ int inet_dump_rules(struct sk_buff *skb,
rcu_read_lock();
hlist_for_each_entry(r, node, fib_rules, hlist) {
-
if (idx s_idx)
- continue;
+ goto next;
if (inet_fill_rule(skb, r, NETLINK_CB(cb-skb).pid,
cb-nlh-nlmsg_seq,
RTM_NEWRULE, NLM_F_MULTI) 0)
break;
+next:
idx++;
}
rcu_read_unlock();
Re: [Xen-devel] kernel BUG at net/core/dev.c:1133!
Herbert Xu wrote: Petersson, Mats [EMAIL PROTECTED] wrote: Looks like the GSO is involved? It's certainly what crashed your machine :) It's probably not the guilty party though. Someone is passing through a TSO packet with checksum set to something other than CHECKSUM_HW. I bet it's netfilter and we just never noticed before because real NICS would simply corrupt the checksum silently. Could you confirm that you have netfilter rules (in particular NAT rules) and that this goes away if you flush all your netfilter tables? Patrick, do we really have to zap the checksum on outbound NAT? Could we update it instead? Are you refering to this code in ip_nat_fn()? /* If we had a hardware checksum before, it's now invalid */ if ((*pskb)-ip_summed == CHECKSUM_HW) if (skb_checksum_help(*pskb, (out == NULL))) return NF_DROP; Doing incremental updates should work fine. This is something I wanted to take care of at some point, but didn't get to it yet. - 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] tg3: add amd8131 to write reorder chipsets
On Fri, Jul 07, 2006 at 12:51:35PM -0700, Michael Chan wrote: John W. Linville wrote: Add the AMD 8131 bridge to the list of chipsets that reorder writes. Signed-off-by: John W. Linville [EMAIL PROTECTED] Hi John, The latest tg3 driver in 2.6.18 has a recovery mechanism to detect and recover from this kind of reordering problem. I suppose we can add this chipset now if we're reasonably sure that it is reordering MMIO. But it will be nice to actually see the recovery mechanism in action catching this chipset. Obviously it is between you and Dave to decide what is best. We are carrying this patch in RHEL4 at the moment, so I didn't want to hold it back from upstream. If you think you have a better solution then it's on you... :-) John -- John W. Linville [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] tg3: add amd8131 to write reorder chipsets
David Miller wrote: From: John W. Linville [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 14:58:36 -0400 Add the AMD 8131 bridge to the list of chipsets that reorder writes. Signed-off-by: John W. Linville [EMAIL PROTECTED] What failure report is this chipset blacklist addition based upon? I just want to look at the paper trail before adding this. Moreover, since e1000 suffers from reordering/write-combining problems on the 8132, I'm starting to see an (ugly) pattern here. I didn't know that tg3 has a whole blacklist for this, could this affect other network cards as well? Auke - 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] tg3: add amd8131 to write reorder chipsets
From: Auke Kok [EMAIL PROTECTED] Date: Fri, 07 Jul 2006 13:21:38 -0700 Moreover, since e1000 suffers from reordering/write-combining problems on the 8132, I'm starting to see an (ugly) pattern here. I didn't know that tg3 has a whole blacklist for this, could this affect other network cards as well? The tg3 is probably more susceptible to this problem because of how it uses a software structure in memory for interrupt status and RX/TX descriptor table head/tail indexes. Whereas the e1000 always has to synchronize with MMIO register reads to get interrupt status and the indexes. - 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: skge error; hangs w/ hardware memory hole
On Mon, 3 Jul 2006 22:52:38 +0200 Martin Michlmayr [EMAIL PROTECTED] wrote: We received the following bug report at http://bugs.debian.org/341801 | I have a Asus A8V with 4GB of RAM. When I turn on the hardware memory | hole in the BIOS, the skge driver prints out this message: | skge hardware error detected (status 0xc00) | and then does not work. Setting debug=16 doesn't really show anything. Another users confirms this bug, saying: | I'm running kernel 2.6.15-1-amd64-generic version 2.6.15-6, and see | the very same thing. | So I have to turn off the memory remapping feature that allows the | system to see all 4 gig of memory, and thus lose the use of about 200 | megabytes of memory. | Hardware: ASUS A8V Deluxe, 4G RAM, Athlon 64 3200+ CPU. This problem has probably been there forever and also happens with the sk98lin driver: | With sk98lin under both 2.6.12 and 2.6.17 I get the following message, | repeated countless times, and finally a hang: [this is copied from | screen on to a sheet a paper and re-typed, beware typos]: | eth0: Adapter failed | eth0: -- ERROR -- | class: Hardware failure | Nr: 0x264 | Msg: unexpected IRQ Status error The bug is still present in 2.6.17 -mm6: | -mm6 does not work with skge and the hardware memory hole. It gave | these messages: | skge eth0: enabling interface | skge :00:0a.0: PCI error cmd=0x117 status=0x22b0 | skge unable to clear error (so ignoring them) | skge eth0: Link is up at 1000 Mbps, full duplex, flow control tx and rx | DHCP never managed to get an IP address. Any idea what to do about this? I don't really have access to the hardware, or know the x86-64 details perhaps Andi Kleen would be of more help. But my suspicion is that the remapping doesn't work for i/o devices because of hardware or BIOS. One simple workaround is to force use of the I/O mmu on the amd64 processor. This has a small performance impact (requires more setup). See Documentation/x86_64/boot-options.txt iommu=force -- Stephen Hemminger [EMAIL PROTECTED] Quis custodiet ipsos custodes? - 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] tg3: add amd8131 to write reorder chipsets
John W. Linville wrote: Obviously it is between you and Dave to decide what is best. We are carrying this patch in RHEL4 at the moment, so I didn't want to hold it back from upstream. If you think you have a better solution then it's on you... :-) Since 2.6.18 already has the recovery logic in place, we can probably holdoff merging this patch upstream. If e1000 is having similar problems with a similar AMD chipset, it must be a fairly widespread problem. It might be a good idea to push this patch to -stable. - 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: [VLAN]: translate IF_OPER_DORMANT to netif_dormant_on()
On Fri, 07 Jul 2006 11:56:28 +0200 Patrick McHardy [EMAIL PROTECTED] wrote: Stefan Rompf wrote: Am Donnerstag 06 Juli 2006 09:42 schrieb Patrick McHardy: I believe this link-state logic was added by someone else. I'm not sure exactly what these flags are supposed to do, so I am not sure if they should be propagated to the VLAN or not. I looked into this. The present flag used to get propagated from the real device until this patch, presumably to make sure no operations on the vlan device will be passed through to the underlying device when it is not present. The present flag is changed by netif_device_attach() and netif_device_detach(), and these functions do not emit a netdev_state_change() afterwards. So there is a good chance that vlan_device_event() won't be called and cannot transfer the flag. netif_device_detach() also sets __LINK_STATE_XOFF implicitely. True. Ok, let's see who cares for netif_device_present(): -SIOCSIFMAP, dev-set_config() (change media type) -dev_open() -dev_set_mtu() -dev_set_mac_address() -dev_watchdog() -not implemented by VLAN / does not call through to underlying device -multicast ioctls -calls dev_mc_upload() of the underlying device sooner or later, this function checks whether the device is present or not. However, if you change the multicast list on a VLAN while the real device is not present, dev_mc_upload() won't be called on netif_device_attach(). Good thing is that most drivers setup multicast list after attach. Fishy. -several private ioctls -vlan_dev_ioctl() checks whether the real device is present before passing an ioctl So I'd rather drop the __LINK_STATE_PRESENT transfer part, because not guaranteed to be called anyway and mostly unneeded. Ok, let me look through the history now to find who added transferring it (hope this happened after the bitkeeper-git move) I tend to agree with you, it doesn't seem to work properly. It was introduced by Stephen (before the move), lets hope he can tell us more. Not really. The flag code last major change was to do the dormant stuff that HDLC wanted. IMHO VLAN device's should mirror the state of the underlying physical device. I can't really follow the thread well. What is broken? -- Stephen Hemminger [EMAIL PROTECTED] Quis custodiet ipsos custodes? - 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: Add ECN support for TSO
From: Michael Chan [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 13:57:11 -0700 RFC3540 is still experimental I believe and it is not implemented in the Linux stack. Even if it is implemented and the NS bit is set, I think the TSO logic can simply replicate the NS bit as each TSO divided segment contains the same acknowledgement information from the original super segment. We should hear Herbert, David, or others' opinions on this. I'm studying the RFC right now just to make sure your assesment is accurate. It probably is :) - 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: Add ECN support for TSO
From: David Miller [EMAIL PROTECTED] Date: Fri, 07 Jul 2006 14:59:32 -0700 (PDT) From: Michael Chan [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 13:57:11 -0700 RFC3540 is still experimental I believe and it is not implemented in the Linux stack. Even if it is implemented and the NS bit is set, I think the TSO logic can simply replicate the NS bit as each TSO divided segment contains the same acknowledgement information from the original super segment. We should hear Herbert, David, or others' opinions on this. I'm studying the RFC right now just to make sure your assesment is accurate. It probably is :) Ok, this is correct. TSO should simply replicate the NS bit because the cumulative ACK is going to be the same in each and every packet emitted. - 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] correct dev_alloc_skb kerneldoc
On Fri, 7 Jul 2006 11:09:57 +0200 Christoph Hellwig [EMAIL PROTECTED] wrote: dev_alloc_skb is designated for RX descriptors, not TX. (Some drivers use it for the latter anyway, but that's a different story) Signed-off-by: Christoph Hellwig [EMAIL PROTECTED] Index: linux-2.6/include/linux/skbuff.h === --- linux-2.6.orig/include/linux/skbuff.h 2006-07-07 11:05:30.0 +0200 +++ linux-2.6/include/linux/skbuff.h 2006-07-07 11:06:31.0 +0200 @@ -1067,7 +1067,7 @@ } /** - * __dev_alloc_skb - allocate an skbuff for sending + * __dev_alloc_skb - allocate an skbuff for receiving * @length: length to allocate * @gfp_mask: get_free_pages mask, passed to alloc_skb * @@ -1088,7 +1088,7 @@ } /** - * dev_alloc_skb - allocate an skbuff for sending + * dev_alloc_skb - allocate an skbuff for receiving * @length: length to allocate * * Allocate a new sk_buff and assign it a usage count of one. The - 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 What is the point of dev_alloc_skb anyway? all it does is add header space. -- Stephen Hemminger [EMAIL PROTECTED] Quis custodiet ipsos custodes? - 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: Bluetooth update for 2.6
Hi Dave, this is the second part of pending updates of the Bluetooth subsystem for the upcoming 2.6.18 kernel. A couple of them are only coding style cleanups which I failed to submit for the previous kernel release. They slipped somehow. The rest is driver model integration stuff. Please push them to Linus as soon as possible. The merge window for 2.6.18 is closed, so you will need to eliminate things like code cleanups and other non-bugfixes. yes, I saw that, but actually these patches were meant to get to you before the merge window closed. I failed to prepare the tree, because I lost remote access to one of my machines were I unfortunately had queued all of these patches. Do you think Linus will make an exception? Regards Marcel - 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: Bluetooth update for 2.6
From: Marcel Holtmann [EMAIL PROTECTED] Date: Sat, 08 Jul 2006 00:54:30 +0200 Do you think Linus will make an exception? I actually hope that he won't. He even let it go beyond a week this time, it was closer to 2 weeks. This gave you ample opportunity to merge your changes in on time, sorry. - 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/core/dev printk message priority
The printk's in the network device interface code should all be tagged with
severity.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/net/core/dev.c2006-07-07 13:02:31.0 -0700
+++ b/net/core/dev.c2006-07-07 16:28:22.0 -0700
@@ -1727,7 +1727,7 @@
if (dev-qdisc_ingress) {
__u32 ttl = (__u32) G_TC_RTTL(skb-tc_verd);
if (MAX_RED_LOOP ttl++) {
- printk(Redir loop detected Dropping packet (%s-%s)\n,
+ printk(KERN_WARNING Redir loop detected Dropping
packet (%s-%s)\n,
skb-input_dev-name, skb-dev-name);
return TC_ACT_SHOT;
}
@@ -2922,7 +2922,7 @@
/* Fix illegal SG+CSUM combinations. */
if ((dev-features NETIF_F_SG)
!(dev-features NETIF_F_ALL_CSUM)) {
- printk(%s: Dropping NETIF_F_SG since no checksum feature.\n,
+ printk(KERN_NOTICE %s: Dropping NETIF_F_SG since no checksum
feature.\n,
dev-name);
dev-features = ~NETIF_F_SG;
}
@@ -2930,7 +2930,7 @@
/* TSO requires that SG is present as well. */
if ((dev-features NETIF_F_TSO)
!(dev-features NETIF_F_SG)) {
- printk(%s: Dropping NETIF_F_TSO since no SG feature.\n,
+ printk(KERN_NOTICE %s: Dropping NETIF_F_TSO since no SG
feature.\n,
dev-name);
dev-features = ~NETIF_F_TSO;
}
-
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/core/dev printk message priority
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 16:41:04 -0700 The printk's in the network device interface code should all be tagged with severity. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] Applied, thanks Stephen. - 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] correct dev_alloc_skb kerneldoc
From: Stephen Hemminger [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 15:52:55 -0700 What is the point of dev_alloc_skb anyway? all it does is add header space. In stone-age times it actually had specific semantics, but yes today it is just a synonym. It's going to be hard to get rid of it, every single network driver out there references 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: [PATCH] tg3: add amd8131 to write reorder chipsets
From: Michael Chan [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 14:22:11 -0700 John W. Linville wrote: Obviously it is between you and Dave to decide what is best. We are carrying this patch in RHEL4 at the moment, so I didn't want to hold it back from upstream. If you think you have a better solution then it's on you... :-) Since 2.6.18 already has the recovery logic in place, we can probably holdoff merging this patch upstream. I think that since we do have a proof positive report, and well documented success of the fix, we should add the fix even though we have the fallback thing to take care of it. This is how we were going to use the fall-back code, to make the the chipset blacklist more robust yet still allow the user's machine to work meanwhile. Here, we have enough information to add the blacklist entry safely. What do you think? - 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] Rough VJ Channel Implementation - vj_core.patch
From: Kelly Daly [EMAIL PROTECTED]
Date: Thu, 22 Jun 2006 12:05:35 +1000
The hash table bits look good, just as they did last time :-)
So I'll put this part into my vj-2.6 tree now, thanks.
Rockin' - thanks...
Sorry for the massive delay - here's the next attempt.
My review delay was just as bad if not worse :-)
+static int sock_add_netchannel(struct sock *sk)
+{
+ struct netchannel *np;
+
+ np = kmalloc(sizeof(struct netchannel), GFP_KERNEL);
+ if (!np)
+ return -ENOMEM;
+ netchannel_init(np, netchannel_wake, (void *)np);
+ sk-sk_channel = np;
+
+ return 0;
+}
This function is unreferenced entirely? It's marked static,
so don't bother including it unless it is being used.
Fix this, give me a good changelog and signed-off-by line
and I'll stick this into the vj-2.6 tree
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] tg3: add amd8131 to write reorder chipsets
David Miller wrote: I think that since we do have a proof positive report, and well documented success of the fix, we should add the fix even though we have the fallback thing to take care of it. This is how we were going to use the fall-back code, to make the the chipset blacklist more robust yet still allow the user's machine to work meanwhile. Here, we have enough information to add the blacklist entry safely. What do you think? OK, no objection to merging it now. - 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][ATM]: Typo in drivers/atm/Kconfig...
please consider for 2.6.18 -- thanks! [ATM]: Typo in drivers/atm/Kconfig... From: Matt LaPlante [EMAIL PROTECTED] Signed-off-by: Charles Williams [EMAIL PROTECTED] --- commit 8bbf3465e23c41b92931e2d2172c184ccd1d2510 tree d1620632c703f8d67790a4f9971f154949399740 parent d0cddc7d78816bf6ceae9730eb51d78a73a62c15 author chas williams [EMAIL PROTECTED] Thu, 06 Jul 2006 12:38:03 -0400 committer chas williams [EMAIL PROTECTED] Thu, 06 Jul 2006 12:38:03 -0400 drivers/atm/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/atm/Kconfig b/drivers/atm/Kconfig index 01a9f1c..cfa5af8 100644 --- a/drivers/atm/Kconfig +++ b/drivers/atm/Kconfig @@ -398,7 +398,7 @@ config ATM_FORE200E_USE_TASKLET default n help This defers work to be done by the interrupt handler to a - tasklet instead of hanlding everything at interrupt time. This + tasklet instead of handling everything at interrupt time. This may improve the responsive of the host. config ATM_FORE200E_TX_RETRY - 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][ATM]: fix possible recursive locking in skb_migrate()
please consider for 2.6.18 -- thanks!
[ATM]: fix possible recursive locking in skb_migrate()
ok this is a real potential deadlock in a way, it takes two locks of 2
skbuffs without doing any kind of lock ordering; I think the following
patch should fix it. Just sort the lock taking order by address of the
skb.. it's not pretty but it's the best this can do in a minimally
invasive way.
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
Signed-off-by: Chas Williams [EMAIL PROTECTED]
---
commit c895a2f42057801ca096f5155e85bc2b2f381250
tree ee64100fdd0302fe5c12ce6c153eea8b94010f2b
parent 8bbf3465e23c41b92931e2d2172c184ccd1d2510
author chas williams [EMAIL PROTECTED] Fri, 07 Jul 2006 18:11:30 -0400
committer chas williams [EMAIL PROTECTED] Fri, 07 Jul 2006 18:11:30 -0400
net/atm/ipcommon.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/atm/ipcommon.c b/net/atm/ipcommon.c
index 4b1faca..1d3de42 100644
--- a/net/atm/ipcommon.c
+++ b/net/atm/ipcommon.c
@@ -25,22 +25,27 @@ #endif
/*
* skb_migrate appends the list at from to to, emptying from in the
* process. skb_migrate is atomic with respect to all other skb operations on
- * from and to. Note that it locks both lists at the same time, so beware
- * of potential deadlocks.
+ * from and to. Note that it locks both lists at the same time, so to deal
+ * with the lock ordering, the locks are taken in address order.
*
* This function should live in skbuff.c or skbuff.h.
*/
-void skb_migrate(struct sk_buff_head *from,struct sk_buff_head *to)
+void skb_migrate(struct sk_buff_head *from, struct sk_buff_head *to)
{
unsigned long flags;
struct sk_buff *skb_from = (struct sk_buff *) from;
struct sk_buff *skb_to = (struct sk_buff *) to;
struct sk_buff *prev;
- spin_lock_irqsave(from-lock,flags);
- spin_lock(to-lock);
+ if ((unsigned long) from (unsigned long) to) {
+ spin_lock_irqsave(from-lock, flags);
+ spin_lock_nested(to-lock, SINGLE_DEPTH_NESTING);
+ } else {
+ spin_lock_irqsave(to-lock, flags);
+ spin_lock_nested(from-lock, SINGLE_DEPTH_NESTING);
+ }
prev = from-prev;
from-next-prev = to-prev;
prev-next = skb_to;
@@ -51,7 +56,7 @@ void skb_migrate(struct sk_buff_head *fr
from-prev = skb_from;
from-next = skb_from;
from-qlen = 0;
- spin_unlock_irqrestore(from-lock,flags);
+ spin_unlock_irqrestore(from-lock, flags);
}
-
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 NET 00/04]: Increase number of possible routing tables
Patrick McHardy wrote: Ben Greear wrote: Patrick McHardy wrote: I took on Ben's challenge to increase the number of possible routing tables, these are the resulting patches. I am seeing problems..though they could be with the way I'm using the tool or pehaps I patched the kernel incorrectly. I applied the 3 patches to 2.6.17..all patches applied without problem, but with a few lines of fuzz. I get the same behaviour with and without the new 'ip' patches applied. If I do an 'ip ru show', then I see lots of tables, though not all it seems. (I have not tried beyond 205 yet). But, if I do an 'ip route show table XX', then I see nothing or incorrect values. My patches introduced a bug when dumping tables which could lead to incorrect routes beeing dumped. A second bug (that already existed) makes the kernel fail when dumping more rules than fit in a skb. I think I've already seen the patch to address the second problem a short time ago sent by someone else. Anyway, this patch should fix both. With this patch applied everything is looking much better. I currently have 400+ interfaces and one routing table per interface, and traffic is passing as expected. This is probably due to my own application polling interfaces for stat updates...but I am seeing over 50% usage (with more system than user-space) in this setup on an otherwise lightly loaded system. top shows no process averaging more than about 2% CPU (and only 2-3 are above 0.0 typically), which I find a little strange. load is around 3.0. I'll dig into my code and see if I can tune the stat-gathering logic a bit... Thanks, Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - 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 patch] fix drivers/net/irda/ali-ircc.c:ali_ircc_init()
The Coverity checker spotted, that from the changes from commit
898b1d16f8230fb912a0c2248df685735c6ceda3 the
if (ret)
platform_driver_unregister(ali_ircc_driver);
was dead code.
This patch changes this function to what seems to have been the
intention.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/net/irda/ali-ircc.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.17-mm6-full/drivers/net/irda/ali-ircc.c.old 2006-07-08
01:44:53.0 +0200
+++ linux-2.6.17-mm6-full/drivers/net/irda/ali-ircc.c 2006-07-08
01:46:46.0 +0200
@@ -142,28 +142,29 @@
*Initialize chip. Find out whay kinds of chips we are dealing with
*and their configuation registers address
*/
static int __init ali_ircc_init(void)
{
ali_chip_t *chip;
chipio_t info;
- int ret = -ENODEV;
+ int ret;
int cfg, cfg_base;
int reg, revision;
int i = 0;
IRDA_DEBUG(2, %s(), Start \n,
__FUNCTION__);
ret = platform_driver_register(ali_ircc_driver);
if (ret) {
IRDA_ERROR(%s, Can't register driver!\n,
ALI_IRCC_DRIVER_NAME);
return ret;
}
+ ret = -ENODEV;
/* Probe for all the ALi chipsets we know about */
for (chip= chips; chip-name; chip++, i++)
{
IRDA_DEBUG(2, %s(), Probing for %s ...\n, __FUNCTION__,
chip-name);
/* Try all config registers for this chip */
-
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: [Xen-devel] kernel BUG at net/core/dev.c:1133!
On Fri, Jul 07, 2006 at 05:03:36PM +0200, Petersson, Mats wrote:
So, nothing going on there... I certainly haven't got NAT on my machine,
as my machine is within the AMD network, and doesn't need NAT. AMD
probably uses NAT as part of it's external communications, but I doubt
it's used at all internally.
Actually, just having it loaded is enough to break TSO. So for all this
time anyone who had ip_nat loaded were silently corrupting all their TSO
checksums!
I'll send a patch soon once I've tested it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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.17-mm3
On Tue, 27 Jun 2006 16:12:42 +0200
Michal Piotrowski [EMAIL PROTECTED] wrote:
Hi,
On 27/06/06, Andrew Morton [EMAIL PROTECTED] wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17/2.6.17-mm3/
It looks like a skge bug
=
[ INFO: possible irq lock inversion dependency detected ]
-
swapper/0 just changed the state of lock:
(tasklist_lock){..-?}, at: [c0128092] send_group_sig_info+0x16/0x34
but this lock took another, soft-irq-unsafe lock in the past:
(sig-stats_lock){--..}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
no locks held by swapper/0.
the first lock's dependencies:
- (tasklist_lock){..-?} ops: 13763 {
initial-use at:
[c01353ab] lock_acquire+0x60/0x80
[c02d0ce2] _write_lock_irq+0x29/0x38
[c011c4e3] copy_process+0xea7/0x13c0
[c011cc6a] do_fork+0x8d/0x18f
[c010136c] kernel_thread+0x6c/0x74
[c0100518] rest_init+0x14/0x3c
[c03b6769] start_kernel+0x388/0x390
[c0100210] 0xc0100210
in-softirq-R at:
[..]
Here is a dmesg log
http://www.stardust.webpages.pl/files/mm/2.6.17-mm3/mm-dmesg
That file no longer exists...
Here is a config file
http://www.stardust.webpages.pl/files/mm/2.6.17-mm3/mm-config
Regards,
Michal
--
If one would give me six lines written by the hand of the most honest
man, I would find something in them to have him hanged. -- Cardinal Richlieu
-
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 NET 00/04]: Increase number of possible routing tables
David Miller wrote: Nice work Patrick. You guys have a lot of time to flesh out any remaining issues and failures, and then submit this for 2.6.19 Will do, I already expected to miss the deadline :) - 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 NET 00/04]: Increase number of possible routing tables
Ben Greear wrote: With this patch applied everything is looking much better. I currently have 400+ interfaces and one routing table per interface, and traffic is passing as expected. This is probably due to my own application polling interfaces for stat updates...but I am seeing over 50% usage (with more system than user-space) in this setup on an otherwise lightly loaded system. top shows no process averaging more than about 2% CPU (and only 2-3 are above 0.0 typically), which I find a little strange. load is around 3.0. I can't imagine this beeing related to the increased number of routing tables, with a number of entries slightly (not even two times) over the hash size it shouldn't make that much of a difference. It may of course be a bug, but I don't see 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: starting mc triggers lockdep
Arjan van de Ven [EMAIL PROTECTED] wrote:
i_mutex is taken within rtln_mutex like this:
[8030f4a0] create_dir+0x2c/0x1e2
[8030fa5b] sysfs_create_dir+0x59/0x78
[8034d2e2] kobject_add+0x114/0x1d8
[803bb1e7] class_device_add+0xb5/0x49d
[804300b1] netdev_register_sysfs+0x98/0xa2
[80426f58] register_netdevice+0x28c/0x376
[8042709c] register_netdev+0x5a/0x69
creating the AB dependency
This is a sysfs inode.
now for the third part, which involves the nfs client:
stat on an nfs file, which ends up taken the i_mutex of a directory in
the path (obvious), and then does
[8022800b] tcp_sendmsg+0x1e/0xb1a
[80248f4b] inet_sendmsg+0x45/0x53
[80259d25] sock_sendmsg+0x110/0x130
[8041f462] kernel_sendmsg+0x3c/0x52
[885399e9] xs_tcp_send_request+0x117/0x320 [sunrpc]
[885388d5] xprt_transmit+0x105/0x21e [sunrpc]
[8853771e] call_transmit+0x1f4/0x239 [sunrpc]
[8853c06e] __rpc_execute+0x9b/0x1e6 [sunrpc]
[8853c1de] rpc_execute+0x1a/0x1d [sunrpc]
[885364ad] rpc_call_sync+0x87/0xb9 [sunrpc]
[885a2587] nfs3_rpc_wrapper+0x2e/0x74 [nfs]
[885a2a14] nfs3_proc_lookup+0xe0/0x163 [nfs]
where tcp_sendmsg calls lock_sock. So this is the BC dependency.
This is an nfs inode.
Did I miss something?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: auro deadlock (was Re: e100 lockdep irq lock inversion.)
Arjan van de Ven [EMAIL PROTECTED] wrote:
Act 1
Enter the mpi_start_xmit() function, which is airo's xmit function.
This function takes the aux_lock first, with irq's off, then calls
skb_queue_tail(). skb_queue_tail takes the sk_receive_queue.lock (with
irqsave as well).
Nope, make that ai-txq.
Act 2
Enter the ipcalc program. This program calls an ioctl, which ends up
calling udp_ioctl. udp_ioctl does
spin_lock_bh(sk-sk_receive_queue.lock);
Different queue.
So no deadlock. Better luck next time :)
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] correct dev_alloc_skb kerneldoc
David Miller [EMAIL PROTECTED] wrote:
What is the point of dev_alloc_skb anyway? all it does is add header space.
In stone-age times it actually had specific semantics, but yes today
it is just a synonym.
Does anyone still need those 16 bytes of header space?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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
[1/2] [NET] gso: Add skb_is_gso
Hi Dave:
These two patches fix the netfilter/checksum/TSO problem where netfilter
destroys the partial checksum which breaks TSO.
[NET] gso: Add skb_is_gso
This patch adds the wrapper function skb_is_gso which can be used instead
of directly testing skb_shinfo(skb)-gso_size. This makes things a little
nicer and allows us to change the primary key for indicating whether an skb
is GSO (if we ever want to do that).
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1639,7 +1639,7 @@ bnx2_tx_int(struct bnx2 *bp)
skb = tx_buf-skb;
#ifdef BCM_TSO
/* partial BD completions possible with TSO packets */
- if (skb_shinfo(skb)-gso_size) {
+ if (skb_is_gso(skb)) {
u16 last_idx, last_ring_idx;
last_idx = sw_cons +
diff --git a/drivers/net/chelsio/sge.c b/drivers/net/chelsio/sge.c
--- a/drivers/net/chelsio/sge.c
+++ b/drivers/net/chelsio/sge.c
@@ -1417,7 +1417,7 @@ int t1_start_xmit(struct sk_buff *skb, s
struct cpl_tx_pkt *cpl;
#ifdef NETIF_F_TSO
- if (skb_shinfo(skb)-gso_size) {
+ if (skb_is_gso(skb)) {
int eth_type;
struct cpl_tx_pkt_lso *hdr;
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2394,7 +2394,7 @@ e1000_tso(struct e1000_adapter *adapter,
uint8_t ipcss, ipcso, tucss, tucso, hdr_len;
int err;
- if (skb_shinfo(skb)-gso_size) {
+ if (skb_is_gso(skb)) {
if (skb_header_cloned(skb)) {
err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
if (err)
@@ -2519,7 +2519,7 @@ e1000_tx_map(struct e1000_adapter *adapt
* tso gets written back prematurely before the data is fully
* DMA'd to the controller */
if (!skb-data_len tx_ring-last_tx_tso
- !skb_shinfo(skb)-gso_size) {
+ !skb_is_gso(skb)) {
tx_ring-last_tx_tso = 0;
size -= 4;
}
@@ -2806,8 +2806,7 @@ e1000_xmit_frame(struct sk_buff *skb, st
#ifdef NETIF_F_TSO
/* Controller Erratum workaround */
- if (!skb-data_len tx_ring-last_tx_tso
- !skb_shinfo(skb)-gso_size)
+ if (!skb-data_len tx_ring-last_tx_tso !skb_is_gso(skb))
count++;
#endif
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -1495,7 +1495,7 @@ static int nv_start_xmit(struct sk_buff
np-tx_skbuff[nr] = skb;
#ifdef NETIF_F_TSO
- if (skb_shinfo(skb)-gso_size)
+ if (skb_is_gso(skb))
tx_flags_extra = NV_TX2_TSO | (skb_shinfo(skb)-gso_size
NV_TX2_TSO_SHIFT);
else
#endif
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1173,7 +1173,7 @@ ixgb_tso(struct ixgb_adapter *adapter, s
uint16_t ipcse, tucse, mss;
int err;
- if(likely(skb_shinfo(skb)-gso_size)) {
+ if (likely(skb_is_gso(skb))) {
if (skb_header_cloned(skb)) {
err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
if (err)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -139,7 +139,7 @@ static int loopback_xmit(struct sk_buff
#endif
#ifdef LOOPBACK_TSO
- if (skb_shinfo(skb)-gso_size) {
+ if (skb_is_gso(skb)) {
BUG_ON(skb-protocol != htons(ETH_P_IP));
BUG_ON(skb-nh.iph-protocol != IPPROTO_TCP);
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -2116,7 +2116,7 @@ abort_linearize:
}
idx = (idx + 1) tx-mask;
} while (idx != last_idx);
- if (skb_shinfo(skb)-gso_size) {
+ if (skb_is_gso(skb)) {
printk(KERN_ERR
myri10ge: %s: TSO but wanted to linearize?!?!?\n,
mgp-dev-name);
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -1159,7 +1159,7 @@ static unsigned tx_le_req(const struct s
count = sizeof(dma_addr_t) / sizeof(u32);
count += skb_shinfo(skb)-nr_frags * count;
- if (skb_shinfo(skb)-gso_size)
+ if (skb_is_gso(skb))
++count;
if
[2/2] [NET] gso: Fix up GSO packets with broken checksums
Hi:
[NET] gso: Fix up GSO packets with broken checksums
Certain subsystems in the stack (e.g., netfilter) can break the partial
checksum on GSO packets. Until they're fixed, this patch allows this to
work by recomputing the partial checksums through the GSO mechanism.
Once they've all been converted to update the partial checksum instead of
clearing it, this workaround can be removed.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -549,6 +549,7 @@ struct packet_type {
struct net_device *);
struct sk_buff *(*gso_segment)(struct sk_buff *skb,
int features);
+ int (*gso_send_check)(struct sk_buff *skb);
void*af_packet_priv;
struct list_headlist;
};
@@ -1001,13 +1002,14 @@ static inline int net_gso_ok(int feature
static inline int skb_gso_ok(struct sk_buff *skb, int features)
{
- return net_gso_ok(features, skb_is_gso(skb) ?
- skb_shinfo(skb)-gso_type : 0);
+ return net_gso_ok(features, skb_shinfo(skb)-gso_type);
}
static inline int netif_needs_gso(struct net_device *dev, struct sk_buff *skb)
{
- return !skb_gso_ok(skb, dev-features);
+ return skb_is_gso(skb)
+ (!skb_gso_ok(skb, dev-features) ||
+ unlikely(skb-ip_summed != CHECKSUM_HW));
}
#endif /* __KERNEL__ */
diff --git a/include/net/protocol.h b/include/net/protocol.h
--- a/include/net/protocol.h
+++ b/include/net/protocol.h
@@ -36,6 +36,7 @@
struct net_protocol {
int (*handler)(struct sk_buff *skb);
void(*err_handler)(struct sk_buff *skb, u32 info);
+ int (*gso_send_check)(struct sk_buff *skb);
struct sk_buff *(*gso_segment)(struct sk_buff *skb,
int features);
int no_policy;
@@ -51,6 +52,7 @@ struct inet6_protocol
int type, int code, int offset,
__u32 info);
+ int (*gso_send_check)(struct sk_buff *skb);
struct sk_buff *(*gso_segment)(struct sk_buff *skb,
int features);
diff --git a/include/net/tcp.h b/include/net/tcp.h
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1086,6 +1086,7 @@ extern struct request_sock_ops tcp_reque
extern int tcp_v4_destroy_sock(struct sock *sk);
+extern int tcp_v4_gso_send_check(struct sk_buff *skb);
extern struct sk_buff *tcp_tso_segment(struct sk_buff *skb, int features);
#ifdef CONFIG_PROC_FS
diff --git a/net/core/dev.c b/net/core/dev.c
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1162,9 +1162,17 @@ int skb_checksum_help(struct sk_buff *sk
unsigned int csum;
int ret = 0, offset = skb-h.raw - skb-data;
- if (inward) {
- skb-ip_summed = CHECKSUM_NONE;
- goto out;
+ if (inward)
+ goto out_set_summed;
+
+ if (unlikely(skb_shinfo(skb)-gso_size)) {
+ static int warned;
+
+ WARN_ON(!warned);
+ warned = 1;
+
+ /* Let GSO fix up the checksum. */
+ goto out_set_summed;
}
if (skb_cloned(skb)) {
@@ -1181,6 +1189,8 @@ int skb_checksum_help(struct sk_buff *sk
BUG_ON(skb-csum + 2 offset);
*(u16*)(skb-h.raw + skb-csum) = csum_fold(csum);
+
+out_set_summed:
skb-ip_summed = CHECKSUM_NONE;
out:
return ret;
@@ -1201,17 +1211,35 @@ struct sk_buff *skb_gso_segment(struct s
struct sk_buff *segs = ERR_PTR(-EPROTONOSUPPORT);
struct packet_type *ptype;
int type = skb-protocol;
+ int err;
BUG_ON(skb_shinfo(skb)-frag_list);
- BUG_ON(skb-ip_summed != CHECKSUM_HW);
skb-mac.raw = skb-data;
skb-mac_len = skb-nh.raw - skb-data;
__skb_pull(skb, skb-mac_len);
+ if (unlikely(skb-ip_summed != CHECKSUM_HW)) {
+ static int warned;
+
+ WARN_ON(!warned);
+ warned = 1;
+
+ if (skb_header_cloned(skb)
+ (err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC)))
+ return ERR_PTR(err);
+ }
+
rcu_read_lock();
list_for_each_entry_rcu(ptype, ptype_base[ntohs(type) 15], list) {
if (ptype-type == type !ptype-dev ptype-gso_segment) {
+ if (unlikely(skb-ip_summed != CHECKSUM_HW)) {
+ err =
Re: airo maybe should select crypto_aes
Robert Schulze [EMAIL PROTECTED] wrote:
I first wrote to the linux-pcmcia ML, but they said it wasn't the right
address for my issue. The driver airo (for Cisco Wlan-Cards) complains
about failed to load transform for AES, when it is loaded and
CRYPTO_AES is not selected in Kconfig.
I've got a patch for that, maybe it's worth it.
First of your patch is space-damaged. Please make sure that the
original tabs are preserved and resend.
Also, wireless patches should be sent to this list with a cc to
John W. Linville [EMAIL PROTECTED].
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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 NET 00/04]: Increase number of possible routing tables
Patrick McHardy wrote: Ben Greear wrote: With this patch applied everything is looking much better. I currently have 400+ interfaces and one routing table per interface, and traffic is passing as expected. This is probably due to my own application polling interfaces for stat updates...but I am seeing over 50% usage (with more system than user-space) in this setup on an otherwise lightly loaded system. top shows no process averaging more than about 2% CPU (and only 2-3 are above 0.0 typically), which I find a little strange. load is around 3.0. I can't imagine this beeing related to the increased number of routing tables, with a number of entries slightly (not even two times) over the hash size it shouldn't make that much of a difference. It may of course be a bug, but I don't see it. I think it was my polling logic that was the problem. I fixed it up to be more clever and the load went away. Ben - 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 -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - 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
