Re: tg3 module problem with suspend2
Lamarque Souza wrote: I have this problem since I first tried to use suspend. The first kernel I tried was 2.6.13 I guess. Since that time I reload the driver, then I do not know if it works with kernel 2.6.14, 2.6.15 or 2.6.16 without reloading. I just tried SOFTWARE_SUSPEND on 2.6.17 and that seems to work ok. I was able to suspend to RAM, and upon wakeup, even though video never came back, I was able to ping to that machine. This tells me that suspend/resume are working fine on tg3. If I have time I'll try SUSPEND2 but it should be the same as far as tg3 is concerned. Have you had success suspending another non-tg3 NIC on your system? - 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 1/4] kevent: core files.
Nicholas Miell wrote: [...] and was wondering if you were familiar with the Solaris port APIs* and, I wasn't. if so, you could please comment on how your proposed event channels are different/better. There indeed is not much difference. The differences are in the details. The way those ports are specified doesn't allow much room for further optimizations. E.g., the userlevel ring buffer isn't possible. But mostly it's the same semantics. The ec_t type in my text is also better a file descriptor since otherwise it cannot be transported via Unix stream sockets. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: Bug#380411: 3c59x broken after swsuspend
hello michael, sending bugreport to netdev. On Sun, 30 Jul 2006, Michael Banck wrote: Package: linux-2.6 Version: 2.6.17-4 after hibernate, my 3Com Corporation 3c556 Hurricane CardBus [Cyclone] (rev 10) (3c59x driver) fails to come back up. This is written on the console/xterm: Internet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ SIOCSIFADDR: No such device eth0: ERROR while getting interface flags: No such device eth0: ERROR while getting interface flags: No such device FATAL: Module acpi_sbs not found. Bind socket to interface: No such device Failed to bring up eth0. And this is in dmesg: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html :00:0b.0: 3Com PCI 3c556 Laptop Tornado at c8830400. eth1: New link status: Connected (0001) *** EEPROM MAC address is invalid. 3c59x: vortex_probe1 fails. Returns -22 ACPI: PCI interrupt for device :00:0b.0 disabled 3c59x: probe of :00:0b.0 failed with error -22 Michael -- maks - 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] net/*/nf_conntrack_*.c:possible cleanups
This patch contains the following possible cleanups:
- make the following needlessly global functions static:
- net/netfilter/nf_conntrack_core.c: nf_conntrack_register_cache()
- net/netfilter/nf_conntrack_core.c: nf_conntrack_unregister_cache()
- net/netfilter/nf_conntrack_core.c: __nf_conntrack_attach()
- net/netfilter/nf_conntrack_core.c: set_hashsize()
- net/netfilter/nf_conntrack_proto_sctp.c: nf_conntrack_proto_sctp_init()
- net/netfilter/nf_conntrack_proto_sctp.c: nf_conntrack_proto_sctp_fini()
- make the following needlessly global variables/locks/structs static:
- net/ipv6/netfilter/nf_conntrack_reasm.c: nf_ct_frag6_secret_interval
- net/ipv6/netfilter/nf_conntrack_reasm.c: nf_ct_frag6_mem
- net/netfilter/nf_conntrack_core.c: nf_ct_cache_lock
- net/netfilter/nf_conntrack_proto_sctp.c: nf_conntrack_protocol_sctp4
- net/netfilter/nf_conntrack_proto_sctp.c: nf_conntrack_protocol_sctp6
- #if 0 the following unused global functions:
- net/ipv6/netfilter/nf_conntrack_reasm.c: nf_ct_frag6_kfree_frags()
- net/netfilter/nf_conntrack_core.c: nf_conntrack_tuple_taken()
- net/netfilter/nf_conntrack_core.c: nf_ct_helper_find_get()
- net/netfilter/nf_conntrack_core.c: nf_ct_helper_put()
- net/netfilter/nf_conntrack_core.c: nf_ct_invert_tuplepr()
- remove the following unused or write-only variables:
- net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c: nat_module_is_loaded
- net/ipv6/netfilter/nf_conntrack_reasm.c: nf_ct_frag6_nqueues
- remove the following unused hooks:
- net/netfilter/nf_conntrack_core.c: nf_conntrack_destroyed()
- net/netfilter/nf_conntrack_ftp.c: nf_nat_ftp_hook()
- remove the following unused EXPORT_SYMBOL's:
- nf_ct_iterate_cleanup
- nf_ct_protos
- nf_ct_l3protos
Please review which of these changes make sense and which might conflict
with pending patches.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
This patch was already sent on:
- 11 Jul 2006
include/net/netfilter/nf_conntrack.h | 21 -
include/net/netfilter/nf_conntrack_core.h |2 -
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c |4 --
net/ipv6/netfilter/nf_conntrack_reasm.c|9 ++---
net/netfilter/nf_conntrack_core.c | 25 +---
net/netfilter/nf_conntrack_ftp.c | 26 +++--
net/netfilter/nf_conntrack_proto_sctp.c|8 ++---
net/netfilter/nf_conntrack_standalone.c|9 -
8 files changed, 27 insertions(+), 77 deletions(-)
---
linux-2.6.18-rc1-mm1-full/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c.old
2006-07-09 19:20:35.0 +0200
+++ linux-2.6.18-rc1-mm1-full/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c
2006-07-09 19:20:46.0 +0200
@@ -113,12 +113,8 @@
return NF_ACCEPT;
}
-int nat_module_is_loaded = 0;
static u_int32_t ipv4_get_features(const struct nf_conntrack_tuple *tuple)
{
- if (nat_module_is_loaded)
- return NF_CT_F_NAT;
-
return NF_CT_F_BASIC;
}
--- linux-2.6.18-rc1-mm1-full/net/ipv6/netfilter/nf_conntrack_reasm.c.old
2006-07-09 19:21:08.0 +0200
+++ linux-2.6.18-rc1-mm1-full/net/ipv6/netfilter/nf_conntrack_reasm.c
2006-07-09 19:22:45.0 +0200
@@ -99,13 +99,11 @@
static DEFINE_RWLOCK(nf_ct_frag6_lock);
static u32 nf_ct_frag6_hash_rnd;
static LIST_HEAD(nf_ct_frag6_lru_list);
-int nf_ct_frag6_nqueues = 0;
static __inline__ void __fq_unlink(struct nf_ct_frag6_queue *fq)
{
hlist_del(fq-list);
list_del(fq-lru_list);
- nf_ct_frag6_nqueues--;
}
static __inline__ void fq_unlink(struct nf_ct_frag6_queue *fq)
@@ -143,7 +141,7 @@
}
static struct timer_list nf_ct_frag6_secret_timer;
-int nf_ct_frag6_secret_interval = 10 * 60 * HZ;
+static int nf_ct_frag6_secret_interval = 10 * 60 * HZ;
static void nf_ct_frag6_secret_rebuild(unsigned long dummy)
{
@@ -173,7 +171,7 @@
mod_timer(nf_ct_frag6_secret_timer, now + nf_ct_frag6_secret_interval);
}
-atomic_t nf_ct_frag6_mem = ATOMIC_INIT(0);
+static atomic_t nf_ct_frag6_mem = ATOMIC_INIT(0);
/* Memory Tracking Functions. */
static inline void frag_kfree_skb(struct sk_buff *skb, unsigned int *work)
@@ -331,7 +329,6 @@
hlist_add_head(fq-list, nf_ct_frag6_hash[hash]);
INIT_LIST_HEAD(fq-lru_list);
list_add_tail(fq-lru_list, nf_ct_frag6_lru_list);
- nf_ct_frag6_nqueues++;
write_unlock(nf_ct_frag6_lock);
return fq;
}
@@ -842,6 +839,7 @@
nf_conntrack_put_reasm(skb);
}
+#if 0
int nf_ct_frag6_kfree_frags(struct sk_buff *skb)
{
struct sk_buff *s, *s2;
@@ -856,6 +854,7 @@
return 0;
}
+#endif /* 0 */
int nf_ct_frag6_init(void)
{
--- linux-2.6.18-rc1-mm1-full/include/net/netfilter/nf_conntrack_core.h.old
2006-07-09 19:23:09.0 +0200
+++ linux-2.6.18-rc1-mm1-full/include/net/netfilter/nf_conntrack_core.h
2006-07-09 19:23:16.0 +0200
@@ -68,8 +68,6 @@
return ret;
}
-extern
Re: [PATCH] include/linux/netfilter_bridge.h: header cleanup
On Sat, 2006-07-29 at 11:45 +0400, Alexey Dobriyan wrote: Header doesn't use anything from atomic.h. It fixes headers_check warning: include/linux/netfilter_bridge.h requires asm/atomic.h, which does not exist Compile tested on alpha arm i386-up sparcsparc64-up x86_64 alpha-up i386 sparc64 sparc-upx86_64-up Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- include/linux/netfilter_bridge.h |1 - 1 file changed, 1 deletion(-) --- a/include/linux/netfilter_bridge.h +++ b/include/linux/netfilter_bridge.h @@ -6,7 +6,6 @@ #define __LINUX_BRIDGE_NETFILTER_H #include linux/netfilter.h #if defined(__KERNEL__) defined(CONFIG_BRIDGE_NETFILTER) -#include asm/atomic.h #include linux/if_ether.h #endif Hm, that could have been dropped entirely by '#unifdef -U__KERNEL__'. P'raps we could teach unifdef that '#if defined(FOO) ...' is always false if -UFOO. Dropping the include in this case is _also_ the right thing to do though, since it doesn't actually need to be there even for in-kernel compilation. -- dwmw2 - 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
Subsystem/prefix in patch submission format
Hi, I have read through http://linux.yyz.us/patch-format.html, which uses $subsystem as prefix for summary. Could you please clarify what is appropriate prefix for the actual summary in a case where patch touches only a part of a subsystem, that is in my case, FRTO. Should the subsystem be TCP or can I use FRTO directly? Or should I perhaps use them both (I found something similar from netdev archives and also from some logs of the kernel): [TCP] FRTO: summary here Just making sure, so that I can start to use the correct format of log messages in my git tree. Thank you. -- i. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regarding offloading IPv6 addrconf and ndisc
Hi, On the other hand, if a ND daemon loose the synchronization, it is unpredicable, I guess. What do you mean by synchronization in this context? My idea was to keep the ND state machine inside the kernel, and instead have the daemon be reactive. That means it would send messages on behalf of the kernel, and apply information based on received signalling (besides, ND is reseliant to loss of messages). Taking your example, if the kernel is using a neighbor entry and you replace it (either changing it's state or link-layer address), the kernel will adapt, i believe it is predictable. To be honest, i'm only worried about possible lost netlink messages; but the daemon may be implemented to handle this, re-sending while an ACK isn't receiving, thus minimizing any de-synchronization possibilities. BTW, we have a choice which we implement a functionality as a module. I think it can achieve some of what you want. Well, exporting the functionality to a module would be a start to have one moving it out of the kernel. :-) Hugo signature.asc Description: Digital signature
Re: skge driver oops
On Sun, 23 Jul 2006, Krzysztof Oledzki wrote: On Fri, 26 May 2006, Stephen Hemminger wrote: Please give this a try, it rearranges the transmit buffer management, and may avoid issues with partial completions causing SKB reuse. CUT Plase excuse me, I overlooked this patch. Anyway, it seems that this fix went into the 2.6.16 kernel, which is already on the server that caused problems (http://bugzilla.kernel.org/show_bug.cgi?id=6142). I'll disable my workaround (/usr/sbin/ethtool -K eth1 tx off) and let you known about the results. Strange, I had reenabled tx csum and there were no problems for about one week. Yesterday I had upgraded my kernel to the 2.6.17.7 and after one day, about 3 hours ago, my system crashed with following log: 782b6fe4 skge_xmit_frame+0x121/0x2ea 781249b6 raise_softirq_irqoff+0xe/0x59 7833b9b7 qdisc_restart+0xc4/0x16b 78332352 net_tx_action+0x97/0xbd 7812484d __do_softirq+0x59/0xc0 781248e4 do_softirq+0x30/0x35 78124947 local_bh_enable+0x5e/0x7e 78332194 dev_queue_xmit+0x1b6/0x1bd 7834ab2c ip_output+0x1b5/0x1eb 7834af00 ip_queue_xmit+0x39e/0x3e6 78191f3e __ext3_get_inode_loc+0x53/0x201 7819df94 journal_dirty_metadata+0x1d1/0x1eb 7811bafb __wake_up+0x27/0x3b 7819e3dc journal_stop+0x1bd/0x1c9 781963d0 __ext3_journal_stop+0x19/0x37 78192b58 ext3_dirty_inode+0x5d/0x63 78359652 tcp_transmit_skb+0x38e/0x3af 7816d122 touch_atime+0x97/0x9d 7835a89c tcp_write_xmit+0x1ad/0x212 7835a924 __tcp_push_pending_frames+0x23/0x80 78352732 do_tcp_setsockopt+0x12e/0x2f3 7832cd3c sock_common_setsockopt+0x1e/0x22 7832ac7b sys_setsockopt+0x61/0x81 7832b242 sys_socketcall+0x164/0x1a4 7815765d sys_sendfile+0x5d/0x84 78102c93 sysenter_past_esp+0x54/0x75 Bad page state in process 'swapper' page:7985eb20 flags:0x80010008 mapping:e25867a0 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: 78140e43 bad_page+0x43/0x6c 781415e5 free_hot_cold_page+0x5b/0x123 7832d700 skb_release_data+0x50/0x86 7832d741 kfree_skbmem+0xb/0x70 78355b41 tcp_clean_rtx_queue+0x225/0x3e6 783560b1 tcp_ack+0x151/0x27b 78358116 tcp_rcv_established+0x544/0x5ed 7835e972 tcp_v4_do_rcv+0x1f/0xb4 7835ee8e tcp_v4_rcv+0x487/0x6de 7833f4ef nf_hook_slow+0xb3/0xce 78347aac ip_local_deliver+0x11b/0x1ab 78348086 ip_rcv+0x40c/0x446 783324e7 netif_receive_skb+0x16f/0x1a7 782b79a0 skge_poll+0x307/0x3e8 78332661 net_rx_action+0x5c/0xd3 7812484d __do_softirq+0x59/0xc0 781248e4 do_softirq+0x30/0x35 7812499d irq_exit+0x36/0x41 78104edc do_IRQ+0x20/0x28 7810101c default_idle+0x0/0x55 7810373e common_interrupt+0x1a/0x20 7810101c default_idle+0x0/0x55 78101048 default_idle+0x2c/0x55 78101132 cpu_idle+0xad/0xda I know it is incomplete (this is all what I am able to find in my logs) but it looks _very_ similar to the one from: http://bugzilla.kernel.org/show_bug.cgi?id=6142 BTW: During normal work skge driver still logs (about 10 times per 1 hour) informations about hardware error. However, message changed slightly - in 2.6.16 it was: skge hardware error detected (status 0x400) but in 2.6.17 it is: skge :00:0b.0: PCI error cmd=0x7 status=0x82b0 skge :00:0b.0: PCI error cmd=0x147 status=0xc2b0 skge :00:0b.0: PCI error cmd=0x147 status=0xc2b0 skge :00:0b.0: PCI error cmd=0x147 status=0xc2b0 skge :00:0b.0: PCI error cmd=0x147 status=0xc2b0 skge :00:0b.0: PCI error cmd=0x147 status=0xc2b0 (...) Anyway, everything works fine. I don't know if it is somehow related to mentioned crashes. Best regards, Krzysztof Oledzki - 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
IPv6 source address selection
Hello, My network has several IPv6 addresses and they don't route between themselves, due to the current source address selection it means that many times the network is simply not operational since Linux will choose an address for a different network than targeted for the connection. I have seen in thread [1] that there is a patch for this and that another patch was supposed to be applied for 2.6.15(!), yet I'm using 2.6.17 and nothing works. Another report about this is at [2] Could whatever difference exists be resolved and this issue fixed? IPv6 is completely unusable on my network due to this issue. Thanks, Baruch [1] http://marc.theaimsgroup.com/?t=11304534653r=1w=2 [2] http://marc.theaimsgroup.com/?l=linux-netm=111989050303975w=2 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: fix kernel panic from no dev-hard_header_len space
Hello Alexey, Can you clarify this for me, please? Do the semantics (I'm not talking about bugs) allow skb passed to dev-hard_header() (if defined) and then to dev-hard_start_xmit() to have less link layer header space than dev-hard_header_len? I.e., is dev-hard_header_len only advisory? -- Krzysztof Halasa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [parisc-linux] [git patches] tulip fixes from parisc-linux
On Sat, Jul 29, 2006 at 06:43:39PM -0600, Grant Grundler wrote: I just wanted to warn that some of the changes are already in akpm 's tree (-mm). Becuase off hand I've forgotten which ones, would it be better to diff against -mm instead? tulip-fix-shutdown-dma-irq-race.patch tulip: fix shutdown DMA/irq race tulip-fix-for-64-bit-mips.patch tulip: fix for 64-bit mips tulip-natsemi-dp83840a-phy-fix.patch tulip: NatSemi DP83840A PHY fix Are the tulip patches in -mm, found here: http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/broken-out/tulip-fix-for-64-bit-mips.patch http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/broken-out/tulip-fix-shutdown-dma-irq-race.patch http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/broken-out/tulip-natsemi-dp83840a-phy-fix.patch [akpm: I added you to the CC list, if Val acks the patches can you see that they make their way into -mm? git.kernel.org/pub/scm/linux/kernel/git/kyle/tulip-2.6.git#master] Cheers, Kyle M. - 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: [parisc-linux] [git patches] tulip fixes from parisc-linux
On Sun, 30 Jul 2006 12:56:07 -0400 Kyle McMartin [EMAIL PROTECTED] wrote: On Sat, Jul 29, 2006 at 06:43:39PM -0600, Grant Grundler wrote: I just wanted to warn that some of the changes are already in akpm 's tree (-mm). Becuase off hand I've forgotten which ones, would it be better to diff against -mm instead? tulip-fix-shutdown-dma-irq-race.patch tulip: fix shutdown DMA/irq race tulip-fix-for-64-bit-mips.patch tulip: fix for 64-bit mips tulip-natsemi-dp83840a-phy-fix.patch tulip: NatSemi DP83840A PHY fix Are the tulip patches in -mm, found here: http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/broken-out/tulip-fix-for-64-bit-mips.patch http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/broken-out/tulip-fix-shutdown-dma-irq-race.patch http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/broken-out/tulip-natsemi-dp83840a-phy-fix.patch [akpm: I added you to the CC list, if Val acks the patches can you see that they make their way into -mm? git.kernel.org/pub/scm/linux/kernel/git/kyle/tulip-2.6.git#master] hm. A couple of those patches have been futzing around in -mm for over a year and have been nacked by Jeff and are a regular source of grumpygrams. I've been sitting on them in the pathetic hope that someone will one day get down and address the bugs which they fix in an acceptable fashion, whatever that 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
[PATCH] 3x59x: fix PCI resource management
The driver wrongly claimed I/O ports at an address returned by pci_iomap() --
even if it was passed an MMIO address. Fix this by claiming/releasing all PCI
resources in the PCI driver probe/remove handlers instead and get rid of the
must_free_region flag weirdness (why would Cardbus claim anything for us?).
Also, the remove handler was trying to talk to the chip after having disabled
its address decoders (at least on x86) -- fix this and get rid of useless
VORTEX_PCI() calls.
While at it, fix some cases of the overly indented code...
Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED]
Index: linux-2.6/drivers/net/3c59x.c
===
--- linux-2.6.orig/drivers/net/3c59x.c
+++ linux-2.6/drivers/net/3c59x.c
@@ -630,7 +630,6 @@ struct vortex_private {
pm_state_valid:1, /*
pci_dev-saved_config_space has sane contents */
open:1,
medialock:1,
- must_free_region:1, /* Flag: if
zero, Cardbus owns the I/O region */
large_frames:1; /* accept large frames */
int drv_flags;
u16 status_enable;
@@ -956,7 +955,13 @@ static int __devinit vortex_init_one(str
/* wake up and enable device */
rc = pci_enable_device(pdev);
if (rc 0)
- goto out;
+ return rc;
+
+ rc = pci_request_regions(pdev, 3c59x);
+ if (rc 0) {
+ pci_disable_device(pdev);
+ return rc;
+ }
unit = vortex_cards_found;
@@ -976,13 +981,13 @@ static int __devinit vortex_init_one(str
rc = vortex_probe1(pdev-dev, ioaddr, pdev-irq,
ent-driver_data, unit);
if (rc 0) {
- pci_disable_device(pdev);
- goto out;
+ pci_release_regions(pdev);
+ pci_disable_device (pdev);
+ return rc;
}
vortex_cards_found++;
-out:
return rc;
}
@@ -1084,11 +1089,6 @@ static int __devinit vortex_probe1(struc
/* PCI-only startup logic */
if (pdev) {
- /* EISA resources already marked, so only PCI needs to do this
here */
- /* Ignore return value, because Cardbus drivers already
allocate for us */
- if (request_region(dev-base_addr, vci-io_size, print_name) !=
NULL)
- vp-must_free_region = 1;
-
/* enable bus-mastering if necessary */
if (vci-flags PCI_USES_MASTER)
pci_set_master(pdev);
@@ -1120,12 +1120,13 @@ static int __devinit vortex_probe1(struc
vp-mii.reg_num_mask = 0x1f;
/* Makes sure rings are at least 16 byte aligned. */
- vp-rx_ring = pci_alloc_consistent(pdev, sizeof(struct boom_rx_desc) *
RX_RING_SIZE
- + sizeof(struct boom_tx_desc) *
TX_RING_SIZE,
+ vp-rx_ring = pci_alloc_consistent(pdev,
+ sizeof(struct boom_rx_desc) *
RX_RING_SIZE +
+ sizeof(struct boom_tx_desc) *
TX_RING_SIZE,
vp-rx_ring_dma);
retval = -ENOMEM;
if (vp-rx_ring == 0)
- goto free_region;
+ goto free_device;
vp-tx_ring = (struct boom_tx_desc *)(vp-rx_ring + RX_RING_SIZE);
vp-tx_ring_dma = vp-rx_ring_dma + sizeof(struct boom_rx_desc) *
RX_RING_SIZE;
@@ -1406,13 +1407,11 @@ static int __devinit vortex_probe1(struc
free_ring:
pci_free_consistent(pdev,
- sizeof(struct boom_rx_desc) *
RX_RING_SIZE
- + sizeof(struct
boom_tx_desc) * TX_RING_SIZE,
- vp-rx_ring,
- vp-rx_ring_dma);
-free_region:
- if (vp-must_free_region)
- release_region(dev-base_addr, vci-io_size);
+ sizeof(struct boom_rx_desc) * RX_RING_SIZE +
+ sizeof(struct boom_tx_desc) * TX_RING_SIZE,
+ vp-rx_ring,
+ vp-rx_ring_dma);
+free_device:
free_netdev(dev);
printk(KERN_ERR PFX vortex_probe1 fails. Returns %d\n, retval);
out:
@@ -3122,29 +3121,28 @@ static void __devexit vortex_remove_one(
vp = netdev_priv(dev);
if (vp-cb_fn_base)
- pci_iounmap(VORTEX_PCI(vp), vp-cb_fn_base);
+ pci_iounmap(pdev, vp-cb_fn_base);
unregister_netdev(dev);
- if (VORTEX_PCI(vp)) {
- pci_set_power_state(VORTEX_PCI(vp), PCI_D0);/* Go active */
- if (vp-pm_state_valid)
- pci_restore_state(VORTEX_PCI(vp));
-
Re: [parisc-linux] [git patches] tulip fixes from parisc-linux
On Sun, Jul 30, 2006 at 11:35:32AM -0700, Andrew Morton wrote: hm. A couple of those patches have been futzing around in -mm for over a year and have been nacked by Jeff and are a regular source of grumpygrams. I've been sitting on them in the pathetic hope that someone will one day get down and address the bugs which they fix in an acceptable fashion, whatever that is. Jeff/Val seemed willing to merge the fixes as they stood. parisc-linux merged Francois' tulip workqueue patch some time ago, and have been running with it since without issue. This defers the tulip_select_media work to process context, and so should be less of an issue. Cheers, Kyle - 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] fix memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
There's an obvious memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
We are not freeing 'tbuf' on error.
Patch below fixes that.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
net/ipv4/tcp_probe.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.18-rc3-orig/net/ipv4/tcp_probe.c 2006-07-30 13:21:53.0
+0200
+++ linux-2.6.18-rc3/net/ipv4/tcp_probe.c 2006-07-30 21:32:04.0
+0200
@@ -129,8 +129,10 @@ static ssize_t tcpprobe_read(struct file
error = wait_event_interruptible(tcpw.wait,
__kfifo_len(tcpw.fifo) != 0);
- if (error)
+ if (error) {
+ vfree(tbuf);
return error;
+ }
cnt = kfifo_get(tcpw.fifo, tbuf, len);
error = copy_to_user(buf, tbuf, cnt);
-
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
Linux TCP in the presence of delays or drops...
Hi all, I have some questions regarding Linux TCP in the presence of delays or packet drops. It is somehow long mail, but the questions are two or three, just wanted to provide a detailed information so that the problem is clear. thanx for the patience!! Best regards, Oumer Note that for the traces referred here, SACK,timestamps, and FRTO are all disabled... 1) packet drops I have a trace where the tcp sender window is flushed and then the connection speed is changed from 1Mbps to 384kbps... The trace files from both the client and the server side can be found at http://kom.aau.dk/~oumer/drop_0_delay_SERVER.dat http://kom.aau.dk/~oumer/drop_0_delay_CLIENT.dat and the tcptrace time sequence curve can be found in http://kom.aau.dk/~oumer/drop_0_delay.ps as can be seen from the plot and the trace files at around 17:19:35.705733, the window was flushed (both the sender's and receivers), and hence packets with seq numbers from 1840001135 upto 1840058075 were dropped (39 packets)...and also the ACK for 1840001135 was also dropped (from the traces this can be seen as it appears in the client trace but not on the server trace)... and since there were still packets to be sent the sender keeps sending a few more packets and when few of them are received (from the client side trace..) 17:19:35.938017 1840059535:1840060995(1460) ack 3059152863 win 5840 (DF)... 17:19:35.938028 ack 1840001135 win 62780 (DF) [tos 0x8]...first ACK that is going to be received by the sender 17:19:35.969316 1840060995:1840062455(1460) ack 3059152863 win 5840 (DF) 17:19:35.969325 1840001135 win 62780 (DF) [tos 0x8]first duplicate ACK 17:19:36.000519 1840062455:1840063915(1460) ack 3059152863 win 5840 (DF) 17:19:36.000528 ack 1840001135 win 62780 (DF) [tos 0x8]... second duplicate ACK when the server gets this 2nd duplicate ACK, it retransmits the packets (this is clearly visible from the tcptrace curve.)..eventhough a 3rd duplicate ACK soon follows. so my first question why is the second duplicate ACK triggering a retransmission?... also after that, there are a couple of retransmissions triggerd by the reception of the ACK for the new ACKs and at time instant (server side trace) 17:19:36.057149 . 1840001135:1840002595(1460) ack 3059152863 win 5840 (DF)..first packet retransmitted 17:19:36.085569 ack 1840001135 win 62780 (DF) [tos 0x8] ...this is the third duplicate ACK which should have caused the retrans, but lets ignore it for now 17:19:36.248599 ack 1840002595 ...retransmitted packet acked 17:19:36.251382 1840002595:1840004055(1460) ack 3059152863 win 5840 (DF) ... next packet retransmitted 17:19:36.442831 ack 1840004055 win 61320 (DF) [tos 0x8]...2nd packet acked also 17:19:36.445625 1840004055:1840005515(1460) ack 3059152863 win 5840 (DF) .. third packet retransmitted 17:19:36.637224 ack 1840005515 win 61320 (DF) [tos 0x8] ... third packet acked 17:19:37.417022 1840005515:1840006975(1460) ack 3059152863 win 5840 (DF) ... fourth packet retransmitted As you can see there is 0.8 second gap between the ack for the reception of the ACK for the third packet and the sending of the fourth packet...so my second question why didnt the sender immediatly send the fourth packet after the reception of the ack for the third? I generated the same scenario 20 times, and the same thing happens in all of them... 2)packet delays === in the second scenario, I have a 2 second delay, but no packet drops...the downgrade in bandwidth also happens, but the packets in the window are buffered for 2 seconds and released... The trace files from both the client and the server side can be found at http://kom.aau.dk/~oumer/delay_0_drop_SERVER.dat http://kom.aau.dk/~oumer/delay_0_drop_CLIENT.dat and the tcptrace time sequence curve can be found in http://kom.aau.dk/~oumer/delay_0_drop.ps The delay is applied from 17:20:01.066725 to 17:20:03.067022 as can be seen from the traces and plot packets with seq number 1858561966 to 1858618906 ( a total of 40 packets) were queued at the server and one packet from the receiver, which is an ACK for pkt # 1858560506 at around 17:20:03.15 this ack is received and sender thinks this is the result of its retransmission (which actually was dropped, so at this point the receiver hasnot got any retransmissions).. and the normal retransmission is resumed (as well as sending of some new data, as the window allows it) as can be seen from the server side trace upto time instant 17:20:04.539682 ...at which point we can see that on the client trace the retransmissions actually start arriving at the receiver (so far the ACKs that were triggering the retransmissions were acks to the reception of the original but delayed packets)...and this duplicate arrivals lead to multiple duplicate ACKs... what I dont understand is why this duplicate ACKs (there are 40 duplicate ACKs.), no fast retransmission was triggered..
Re: [PATCH] fix memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
On Sun, 30 Jul 2006 21:38:02 +0200 Jesper Juhl [EMAIL PROTECTED] wrote: There's an obvious memory leak in net/ipv4/tcp_probe.c::tcpprobe_read() We are not freeing 'tbuf' on error. Patch below fixes that. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Agreed, thanks for catching it. The whole kfifo interface is kind of annoying have to do an extra copy. - 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] fix memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
On Sun, 30 Jul 2006, Stephen Hemminger wrote: On Sun, 30 Jul 2006 21:38:02 +0200 Jesper Juhl [EMAIL PROTECTED] wrote: There's an obvious memory leak in net/ipv4/tcp_probe.c::tcpprobe_read() We are not freeing 'tbuf' on error. Patch below fixes that. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Agreed, thanks for catching it. The whole kfifo interface is kind of annoying have to do an extra copy. Might be cleaner to make a single return path for cleanup: Signed-off-by: James Morris [EMAIL PROTECTED] --- --- linux-2.6.18-rc2-mm1.o/net/ipv4/tcp_probe.c 2006-07-28 11:01:46.0 -0400 +++ linux-2.6.18-rc2-mm1.w/net/ipv4/tcp_probe.c 2006-07-30 17:45:53.0 -0400 @@ -130,11 +130,12 @@ static ssize_t tcpprobe_read(struct file error = wait_event_interruptible(tcpw.wait, __kfifo_len(tcpw.fifo) != 0); if (error) - return error; + goto out_free; cnt = kfifo_get(tcpw.fifo, tbuf, len); error = copy_to_user(buf, tbuf, cnt); +out_free: vfree(tbuf); return error ? error : cnt; - 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] fix memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
On 30/07/06, James Morris [EMAIL PROTECTED] wrote: On Sun, 30 Jul 2006, Stephen Hemminger wrote: On Sun, 30 Jul 2006 21:38:02 +0200 Jesper Juhl [EMAIL PROTECTED] wrote: There's an obvious memory leak in net/ipv4/tcp_probe.c::tcpprobe_read() We are not freeing 'tbuf' on error. Patch below fixes that. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Agreed, thanks for catching it. The whole kfifo interface is kind of annoying have to do an extra copy. Might be cleaner to make a single return path for cleanup: Signed-off-by: James Morris [EMAIL PROTECTED] Looks ok to me. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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
IBM (Lenovo) T60: e1000 driver high latency
Hello, I recently aquired a Lenovo (IBM) T60 with a e1000 network card. I experience high latency with this networkcard: Pings last upto 1 second where the ping should be around 25 ms. I googled a bit and found the following: - Enable NAPI, which didn't worked for me. 64 bytes from 192.168.0.223: icmp_seq=30 ttl=64 time=1004 ms 64 bytes from 192.168.0.223: icmp_seq=31 ttl=64 time=0.444 ms 64 bytes from 192.168.0.223: icmp_seq=32 ttl=64 time=1006 ms 64 bytes from 192.168.0.223: icmp_seq=33 ttl=64 time=0.739 ms 64 bytes from 192.168.0.223: icmp_seq=34 ttl=64 time=1006 ms 64 bytes from 192.168.0.223: icmp_seq=35 ttl=64 time=0.603 ms 64 bytes from 192.168.0.223: icmp_seq=36 ttl=64 time=1001 ms 64 bytes from 192.168.0.223: icmp_seq=37 ttl=64 time=0.736 ms 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller Subsystem: Lenovo Unknown device 2001 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 98 Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at 3000 [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: fee0 Data: 4062 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 L0s L1, Port 0 Link: Latency L0s 128ns, L1 64us Link: ASPM L1 Enabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 91-9c-58-ff-ff-41-16-00 Any ideas? Thomas - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/23] [PATCH] [XFRM]: Add Kconfig to enable advanced transformation.
On Sat, 29 Jul 2006, Masahide NAKAMURA wrote: This option is for enhanced transformation features and it will be used by Mobile IPv6. Based on MIPL2 kernel patch. --- net/xfrm/Kconfig |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/net/xfrm/Kconfig b/net/xfrm/Kconfig index 0c1c043..95f4f09 100644 --- a/net/xfrm/Kconfig +++ b/net/xfrm/Kconfig @@ -14,6 +14,14 @@ config XFRM_USER If unsure, say Y. +config XFRM_ADVANCED + bool Transformation advanced functions (EXPERIMENTAL) + depends on XFRM EXPERIMENTAL + ---help--- + Support advanced transformation for developers. + + If unsure, say N. + config NET_KEY tristate PF_KEY sockets select XFRM Do we really need to add this config item? I think we should just enable it. - James -- James Morris [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 1/20] [PATCH] [IPV6]: Add Kconfig to enable Mobile IPv6.
On Sat, 29 Jul 2006, Masahide NAKAMURA wrote: +config IPV6_MIP6 + bool IPv6: Mobility (EXPERIMENTAL) + depends on IPV6 EXPERIMENTAL + select XFRM + select XFRM_ADVANCED Why 'select' here instead of 'depends on'? The overall kernel config is getting very messed up because of all of these selects. - James -- James Morris [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: Subsystem/prefix in patch submission format
From: Ilpo Järvinen [EMAIL PROTECTED] Date: Sun, 30 Jul 2006 14:01:09 +0300 (EEST) [TCP] FRTO: summary here This looks perfectly fine. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: fix kernel panic from no dev-hard_header_len space
From: Krzysztof Halasa [EMAIL PROTECTED] Date: Sun, 30 Jul 2006 18:40:04 +0200 Do the semantics (I'm not talking about bugs) allow skb passed to dev-hard_header() (if defined) and then to dev-hard_start_xmit() to have less link layer header space than dev-hard_header_len? I.e., is dev-hard_header_len only advisory? It does seem weird that IP output won't pay attention to dev-hard_header_len if the device does not provide a dev-hard_header() method. That is for sure. - 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/20] [PATCH] [IPV6]: Add Kconfig to enable Mobile IPv6.
From: James Morris [EMAIL PROTECTED] Date: Sun, 30 Jul 2006 18:20:46 -0400 (EDT) The overall kernel config is getting very messed up because of all of these selects. The idea is that the user should be shielded from having to know what random kernel internal subsystem is necessary in order for feature FOO to even appear in their available kernel config selections. - 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] include/linux/netfilter_bridge.h: header cleanup
From: Alexey Dobriyan [EMAIL PROTECTED] Date: Sat, 29 Jul 2006 11:45:45 +0400 Header doesn't use anything from atomic.h. It fixes headers_check warning: include/linux/netfilter_bridge.h requires asm/atomic.h, which does not exist Compile tested on alpha arm i386-up sparcsparc64-up x86_64 alpha-up i386 sparc64 sparc-upx86_64-up Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] Applied, thanks Alexey. - 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: Subsystem/prefix in patch submission format
On Sun, Jul 30, 2006 at 03:28:46PM -0700, David Miller wrote: From: Ilpo J?rvinen [EMAIL PROTECTED] Date: Sun, 30 Jul 2006 14:01:09 +0300 (EEST) [TCP] FRTO: summary here This looks perfectly fine. Looking 100 commits back or so it is obvious we have two distinct notations: subsystem: what was changed and [subsystem] what was changed net related stuff counts for most of the latter but it is used in several other places. From a pure eye-candy perspective it would be nice to use same format all over. From Documentation/SubmittingPatches: -- 12) The canonical patch format The canonical patch subject line is: Subject: [PATCH 001/123] subsystem: summary phrase -- Sam - 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: [NET]: Fix ___pskb_trim when entire frag_list needs dropping
From: Herbert Xu [EMAIL PROTECTED] Date: Sat, 29 Jul 2006 21:45:25 +1000 [NET]: Fix ___pskb_trim when entire frag_list needs dropping When the trim point is within the head and there is no paged data, ___pskb_trim fails to drop the first element in the frag_list. This patch fixes this by moving the len = offset case out of the page data loop. This patch also adds a missing kfree_skb on the frag that we just cloned. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Applied, thanks Herbert. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
From: Herbert Xu [EMAIL PROTECTED] Date: Sat, 29 Jul 2006 14:33:25 +1000 [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls The current users of ip6_dst_lookup can be divided into two classes: 1) The caller holds no locks and is in user-context (UDP). 2) The caller does not want to lookup the dst cache at all. The second class covers everyone except UDP because most people do the cache lookup directly before calling ip6_dst_lookup. This patch adds ip6_sk_dst_lookup for the first class. Similarly ip6_dst_store users can be divded into those that need to take the socket dst lock and those that don't. This patch adds __ip6_dst_store for those (everyone except UDP/datagram) that don't need an extra lock. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Applied, thanks Herbert. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux- 2.6.17.7 undefined reference to `alloc_ltalkdev'
From: Toralf Förster [EMAIL PROTECTED] Date: Sat, 29 Jul 2006 20:55:11 +0200 Subject: linux- 2.6.17.7 undefined reference to `alloc_ltalkdev' Bug is that appletalk is built modular, which is where alloc_ltalkdev is exported from, but we allow users of this symbol, such as the cops driver, to be built non-modular. Luckily the fix is simple, we need to change CONFIG_DEV_APPLETALK to be a 'tristate' instead of a 'bool'. The following patch is what I'll use to fix this bug. Thanks for the report. diff-tree 66d3ad53b6867aa1bc499062bd19f85bfeee2f9e (from d0ccba71dfe903a737d011d93a076c10cf487b19) Author: David S. Miller [EMAIL PROTECTED] Date: Sun Jul 30 15:54:11 2006 -0700 [ATALK]: Make CONFIG_DEV_APPLETALK a tristate. Otherwise we allow building appletalk drivers in-kernel when CONFIG_ATALK is modular. That doesn't work because these drivers use symbols such as alloc_talkdev which is exported from code built by CONFIG_ATALK. Noticed by Toralf Förster. Signed-off-by: David S. Miller [EMAIL PROTECTED] diff --git a/drivers/net/appletalk/Kconfig b/drivers/net/appletalk/Kconfig index b14e890..0a0e0cd 100644 --- a/drivers/net/appletalk/Kconfig +++ b/drivers/net/appletalk/Kconfig @@ -29,7 +29,7 @@ config ATALK even politically correct people are allowed to say Y here. config DEV_APPLETALK - bool Appletalk interfaces support + tristate Appletalk interfaces support depends on ATALK help AppleTalk is the protocol that Apple computers can use to communicate - 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: [parisc-linux] [git patches] tulip fixes from parisc-linux
Andrew Morton wrote: hm. A couple of those patches have been futzing around in -mm for over a year and have been nacked by Jeff and are a regular source of grumpygrams. I've been sitting on them in the pathetic hope that someone will one day get down and address the bugs which they fix in an acceptable fashion, whatever that is. I'm OK with the one sent - Grant - Val - me. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [parisc-linux] [git patches] tulip fixes from parisc-linux
Kyle McMartin wrote: parisc-linux merged Francois' tulip workqueue patch some time ago, and have been running with it since without issue. This defers the tulip_select_media work to process context, and so should be less of an issue. Good to hear. That's definitely my preference for future direction... Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix memory leak in net/ipv4/tcp_probe.c::tcpprobe_read()
From: Jesper Juhl [EMAIL PROTECTED] Date: Sun, 30 Jul 2006 23:51:20 +0200 Looks ok to me. I've applied James's version of the fix, thanks everyone. - 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: Subsystem/prefix in patch submission format
From: Sam Ravnborg [EMAIL PROTECTED] Date: Mon, 31 Jul 2006 00:45:43 +0200 From a pure eye-candy perspective it would be nice to use same format all over. From Documentation/SubmittingPatches: -- 12) The canonical patch format The canonical patch subject line is: Subject: [PATCH 001/123] subsystem: summary phrase -- The patch format specifies things that make no sense when the changes gets into the tree. Especially the sequence numbers, which are implied by the changes placement in the relative changeset history. We are getting into the realm of personal taste, and I fail to see any benefit from enforcing one subsystem to adopt a different schema if what they're doing now provides all the necessary information and works well for them. - 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
On Thu, 2006-07-20 at 14:56 +1000, Russell Stuart wrote: On Wed, 2006-07-19 at 16:50 +0200, Patrick McHardy wrote: Please excuse my silence, I was travelling and am still catching up with my mails. Sorry. Had I realised you were busy I would of waited. - As it stands, it doesn't help the qdiscs that use RTAB. So unless he proposes to remove RTAB entirely the ATM patch as it will still have to go in. Why? The length calculated by my STABs (or something similar) is used by _all_ qdiscs. Not only for transmission time calculation, but also for statistics and estimators. Oh. I didn't see where it is used for the time calculation in your patch. Did I miss something, or is that the unfinished bit? This is possibly my stumbling block. If you don't remove RTAB the ATM patch as stands will be needed. Your patch didn't remove RTAB, and you didn't say it was intended to, so I presume it wasn't going to. It has gone quiet again. In my mind the one unresolved issue is whether Patrick intended to remove RTAB with his patch. If not, the ATM patch as it stands will have to go in. Patrick - it would be nice to hear from you. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/23] [PATCH] [XFRM] STATE: Add a hook to find where to be inserted header in outbound.
On Sat, 29 Jul 2006, Masahide NAKAMURA wrote:
- hdr_len = ip6_find_1stfragopt(skb, prevhdr);
+ if (x-type-place_find)
+ hdr_len = x-type-place_find(x, skb, prevhdr);
+ else
+ hdr_len = ip6_find_1stfragopt(skb, prevhdr);
What about encapsulating this like:
static inline int hdr_offset(...)
{
if (x-type-place_find)
return x-type-place_find(x, skb, prevhdr);
else
return ip6_find_1stfragopt(skb, prevhdr);
}
Maybe also change the naming of -place_find to -hdr_offset
- James
--
James Morris
[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 8/23] [PATCH] [XFRM] STATE: Add a hook to obtain local/remote outbound address.
On Sat, 29 Jul 2006, Masahide NAKAMURA wrote: + remote = (xfrm[i]-type-remote_addr) ? + (struct in6_addr*)xfrm[i]-type-remote_addr(xfrm[i], (xfrm_address_t *)remote): + (struct in6_addr*)xfrm[i]-id.daddr; + local = (xfrm[i]-type-local_addr) ? + (struct in6_addr*)xfrm[i]-type-local_addr(xfrm[i], (xfrm_address_t *)local): + (struct in6_addr*)xfrm[i]-props.saddr; Again, it'd make the code so much cleaner to provide static inline wrappers for all of these types of: foo = op ? op-() : bar; and if (op) bar = op-(); -- James Morris [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: Runtime power management for network interfaces
On Tue, 25 Jul 2006 09:20:06 -0700 Auke Kok wrote: Alan Stern wrote: During a Power Management session at the Ottawa Linux Symposium, it was generally agreed that network interface drivers ought to automatically suspend their devices (if possible) whenever: (1) The interface is ifconfig'ed down, or (2) No link is available. Presumably (1) should be easy enough to implement. (2) might or might not be feasible, depending on how much WOL support is available. (It might not be feasible at all for wireless networking.) Still, there can be no question that it would be a Good Thing for laptops to power-down their ethernet controllers when the network cable is unplugged. Has any progress been made in this direction? If not, a natural approach would be to start with a reference implementation in one driver which could then be copied to other drivers. Intel's newer e1000's (ich7 onboard e1000 and newer versions for instance) already support this feature partially - the MAC stays on but the PHY can be powered off when no link is present. In order to enable this feature you will need to turn it on explicitly at load time: modprobe e1000 SmartPowerDownEnable=1 Please add that to Documentation/networking/e1000.txt. Allthough not the entire NIC is powered off, it still saves a significant part of the power consumed by the NIC. All bits help. The power automatically restores once a cable is plugged in. --- ~Randy - 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: [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
On Sun, Jul 30, 2006 at 03:44:16PM -0700, David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Sat, 29 Jul 2006 14:33:25 +1000
[IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
The current users of ip6_dst_lookup can be divided into two classes:
1) The caller holds no locks and is in user-context (UDP).
2) The caller does not want to lookup the dst cache at all.
The second class covers everyone except UDP because most people do
the cache lookup directly before calling ip6_dst_lookup. This patch
adds ip6_sk_dst_lookup for the first class.
Similarly ip6_dst_store users can be divded into those that need to
take the socket dst lock and those that don't. This patch adds
__ip6_dst_store for those (everyone except UDP/datagram) that don't
need an extra lock.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Applied, thanks Herbert.
I applied this on 2.6.18-rc3, and it panics immediately as the first
IPv6 TCP (ssh) session is initiated to the system.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Bootdata ok (command line is ro root=/dev/VolGroup00/LogVol00
console=ttyS0,115200 console=tty0)
Linux version 2.6.18-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.1 20060721 (Red
Hat 4.1.1-13)) #1 SMP Sun Jul 30 22:08:46 CDT 2006
...
=
[ INFO: possible recursive locking detected ]
-
swapper/0 is trying to acquire lock:
(slock-AF_INET6){-+..}, at: [80414fda] sk_clone+0xd2/0x3a8
but task is already holding lock:
(slock-AF_INET6){-+..}, at: [883d71a8] tcp_v6_rcv+0x30e/0x76e [ipv6]
other info that might help us debug this:
1 lock held by swapper/0:
#0: (slock-AF_INET6){-+..}, at: [883d71a8] tcp_v6_rcv+0x30e/0x76e
[ipv6]
stack backtrace:
Call Trace:
[8026f861] show_trace+0xae/0x30e
[8026fad6] dump_stack+0x15/0x17
[802a73d4] __lock_acquire+0x12e/0xa18
[802a8232] lock_acquire+0x4b/0x69
[8026883b] _spin_lock+0x25/0x31
[80414fda] sk_clone+0xd2/0x3a8
[8043c8a7] inet_csk_clone+0x11/0x6f
[80445615] tcp_create_openreq_child+0x24/0x49c
[883d5d85] :ipv6:tcp_v6_syn_recv_sock+0x2c5/0x6be
[80445c5e] tcp_check_req+0x1d1/0x326
[883d4f0e] :ipv6:tcp_v6_do_rcv+0x15d/0x372
[883d75b9] :ipv6:tcp_v6_rcv+0x71f/0x76e
[883ba49f] :ipv6:ip6_input+0x223/0x315
[883bab4d] :ipv6:ipv6_rcv+0x254/0x2af
[80221883] netif_receive_skb+0x260/0x2dd
[88101292] :e1000:e1000_clean_rx_irq+0x423/0x4c2
[880ff752] :e1000:e1000_clean+0x88/0x17d
[8020caed] net_rx_action+0xac/0x1d1
[80212809] __do_softirq+0x68/0xf5
[802626fa] call_softirq+0x1e/0x28
DWARF2 unwinder stuck at call_softirq+0x1e/0x28
Leftover inexact backtrace:
IRQ [80270b48] do_softirq+0x39/0x9f
[802960b6] irq_exit+0x57/0x59
[80270cab] do_IRQ+0xfd/0x107
[8025b612] mwait_idle+0x0/0x54
[80261985] ret_from_intr+0x0/0xf
EOI1Unable to handle kernel paging request at 8280 RIP:
[8026fa5c] show_trace+0x2a9/0x30e
PGD 203027 PUD 205027 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: ipv6 ipmi_devintf ipmi_si ipmi_msghandler hidp rfcomm l2cap
bluetooth sunrpc ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack
nfnetlink xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq video sbs
i2c_ec i2c_core button battery asus_acpi ac parport_pc lp parport intel_rng
uhci_hcd ehci_hcd ide_cd e752x_edac edac_mc pcspkr serio_raw cdrom sg e1000
dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd ata_piix libata sd_mod scsi_mod
Pid: 0, comm: swapper Not tainted 2.6.18-rc3 #1
RIP: 0010:[8026fa5c] [8026fa5c] show_trace+0x2a9/0x30e
RSP: 0018:8066a8f0 EFLAGS: 00010002
RAX: RBX: RCX: a4ec
RDX: 80561e60 RSI: RDI: 8056e020
RBP: 8066a9e0 R08: 8066a640 R09: 802abf75
R10: 802abf75 R11: R12: 827d
R13: 8066a900 R14: R15:
FS: () GS:80922000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 8280 CR3: 76417000 CR4: 06e0
Process swapper (pid: 0, threadinfo 80952000, task 80561e60)
Stack: 8066a900 805625b0
80953ec8 8066af80 0046
Call Trace:
[8026fad6] dump_stack+0x15/0x17
[802a73d4] __lock_acquire+0x12e/0xa18
[802a8232] lock_acquire+0x4b/0x69
[8026883b] _spin_lock+0x25/0x31
[80414fda] sk_clone+0xd2/0x3a8
Re: [RFC] [IPV6] ADDRCONF: Lifetime handling fixes
From: YOSHIFUJI Hideaki [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 18:25:34 +0900 (JST) Changesets, on top of 2.6.18-rc2, are available on branch addr-lifetime-20060728b at: git://git.skbuff.net/gitroot/yoshfuji/linux-2.6.18-rc2-addr-lifetime Pulled, thank you very much. - 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] SNMPv2 tcpAttemptFails counter error
From: Wei Yongjun [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 07:40:37 -0400 I have changed my patch with your advice and it looks more effective. ... Signed-off-by: Wei Yongjun [EMAIL PROTECTED] This looks very nice, patch applied. Thank you very much. - 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][SECURITY] secmark: nul-terminate secdata
From: James Morris [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 17:00:15 -0400 (EDT) The patch below fixes a problem in the iptables SECMARK target, where the user-supplied 'selctx' string may not be nul-terminated. Applied, thanks James. - 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 Fix bonding active-backup behavior for VLAN interfaces
From: Ben Greear [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 14:55:17 -0700 The skb_bond method assigns skb-dev when it does the 'keep', but the VLAN code immediately over-writes the skb-dev when searching for the vlan device. What is the purpose of assinging skb-dev to the master device? This makes me consider this patch highly dubious, at best. The whole intention of bonding on input is to make all packets incoming on the individual bond slaves to look like they come in via the master device. Therefore, even when the bond slaves are VLAN devices, in the end the skb-dev should be the bond master device _not_ the VLAN device. I'm not applying this patch, it doesn't look correct at all. - 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 Round 5 0/3] Network Event Notifier Mechanism
From: Steve Wise [EMAIL PROTECTED] Date: Fri, 28 Jul 2006 13:28:49 -0500 Dave/Roland, is this patchset about ready to go? All 3 patches applied, thanks Steve. - 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: [XFRM]: Fix protocol field value for outgoing IPv6 GSO packets
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 31 Jul 2006 06:06:37 +0200 Herbert Xu wrote: On Tue, Jul 25, 2006 at 02:09:26AM +0200, Patrick McHardy wrote: [XFRM]: Fix protocol field value for outgoing IPv6 GSO packets Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Acked-by: Herbert Xu [EMAIL PROTECTED] I believe you missed this one. Attached again for your convenience. It's in my tree, but thanks for reminding me. - 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: Subsystem/prefix in patch submission format
On Sun, Jul 30, 2006 at 03:59:56PM -0700, David Miller wrote: From: Sam Ravnborg [EMAIL PROTECTED] Date: Mon, 31 Jul 2006 00:45:43 +0200 From a pure eye-candy perspective it would be nice to use same format all over. From Documentation/SubmittingPatches: -- 12) The canonical patch format The canonical patch subject line is: Subject: [PATCH 001/123] subsystem: summary phrase -- The patch format specifies things that make no sense when the changes gets into the tree. Especially the sequence numbers, which are implied by the changes placement in the relative changeset history. git am removes the patch format specifiers when the change are committed. git applymbox replace the patch format specifier with [PATCH]. So: git am= subsystem: summary phrase git applymbox = [PATCH] subsystem: summary phrase Both variants exists because Linus uses the latter to distingush between what is applied via git tress and what is applied via mail patches. The Signed-off-by: carries same info btw. Sam - 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
BUG: warning at net/core/dev.c:1171/skb_checksum_help() 2.6.18-rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This machine has four NICs running the e1000 kernel module. Other than the BUG() messages, it seems to be running fine. I was running 2.6.15.4 without any issues on the same hardware, although I noticed the e1000 has been updated (and I went for rc3 since I was hitting the panic in -rc2) Now, I'm not sure if it also has anything to do with this message: NAT: no longer support implicit source local NAT NAT: packet src 10.1.1.1 - dst 207.166.203.131 Any suggestions as to how to go about debugging this? BUG: warning at net/core/dev.c:1171/skb_checksum_help() [c02e0412] skb_checksum_help+0x4d/0xf0 [c034e4d3] ip_nat_fn+0x4e/0x19e [c034e78e] ip_nat_local_fn+0x3d/0xb9 [c0314011] dst_output+0x0/0x7 [c03059ee] nf_iterate+0x40/0x6e BUG: warning at net/core/dev.c:1171/skb_checksum_help() [c02e0412] skb_checksum_help+0x4d/0xf0 [c034e4d3] ip_nat_fn+0x4e/0x19e [c034e78e] ip_nat_local_fn+0x3d/0xb9 [c0314011] dst_output+0x0/0x7 [c03059ee] nf_iterate+0x40/0x6e [c0314011] dst_output+0x0/0x7 [c0305a5e] nf_hook_slow+0x42/0x98 [c0314011] dst_output+0x0/0x7 [c03123c4] ip_queue_xmit+0x3a3/0x3fc [c0314011] dst_output+0x0/0x7 [c037f544] xprt_timer+0x0/0x65 [c01e7964] __next_cpu+0x12/0x1f [c0112a8c] find_busiest_group+0x17e/0x473 [c0320d17] tcp_transmit_skb+0x39f/0x3bc [c0321f7a] tcp_write_xmit+0x1a8/0x210 [c0322000] __tcp_push_pending_frames+0x1e/0x6f [c0317d5d] do_tcp_sendpages+0x4fa/0x521 [c0317dcf] tcp_sendpage+0x4b/0x5e [c02d7fa7] sock_sendpage+0x31/0x37 [c013242e] file_send_actor+0x30/0x4a [c0131e0b] do_generic_mapping_read+0x167/0x3d5 [c013248a] generic_file_sendfile+0x42/0x55 [c01323fe] file_send_actor+0x0/0x4a [c019a141] nfs_file_sendfile+0x59/0x60 [c01323fe] file_send_actor+0x0/0x4a [c014ad07] do_sendfile+0x1b8/0x252 [c01323fe] file_send_actor+0x0/0x4a [c014adec] sys_sendfile+0x4b/0x86 [c010272f] syscall_call+0x7/0xb BUG: warning at net/core/dev.c:1225/skb_gso_segment() [c02e053d] skb_gso_segment+0x88/0x179 [c02e06db] dev_gso_segment+0x5c/0x82 [c02e074a] dev_hard_start_xmit+0x49/0xb1 [c02e0957] dev_queue_xmit+0x1a5/0x21f [c0311fea] ip_output+0x1ce/0x205 [c03123d6] ip_queue_xmit+0x3b5/0x3fc [c037f544] xprt_timer+0x0/0x65 [c01e7964] __next_cpu+0x12/0x1f [c0112a8c] find_busiest_group+0x17e/0x473 [c0320d17] tcp_transmit_skb+0x39f/0x3bc [c0321f7a] tcp_write_xmit+0x1a8/0x210 [c0322000] __tcp_push_pending_frames+0x1e/0x6f [c0317d5d] do_tcp_sendpages+0x4fa/0x521 [c0317dcf] tcp_sendpprintk: 19 messages suppressed. age+0x4b/0x5e eth2.300: received packet with own address as source address [c02d7fa7] sock_sendpage+0x31/0x37 [c013242e] file_send_actor+0x30/0x4a [c0131e0b] do_generic_mapping_read+0x167/0x3d5 [c013248a] generic_file_sendfile+0x42/0x55 [c01323fe] file_send_actor+0x0/0x4a [c019a141] nfs_file_sendfile+0x59/0x60 [c01323fe] file_send_actor+0x0/0x4a [c014ad07] do_sendfile+0x1b8/0x252 [c01323fe] file_send_actor+0x0/0x4a [c014adec] sys_sendfile+0x4b/0x86 [c010272f] syscall_call+0x7/0xb [c0314011] dst_output+0x0/0x7 [c0305a5e] nf_hook_slow+0x42/0x98 [c0314011] dst_output+0x0/0x7 [c03123c4] ip_queue_xmit+0x3a3/0x3fc [c0314011] dst_output+0x0/0x7 [c037f544] xprt_timer+0x0/0x65 [c01e7964] __next_cpu+0x12/0x1f [c0112a8c] find_busiest_group+0x17e/0x473 [c0320d17] tcp_transmit_skb+0x39f/0x3bc [c0321f7a] tcp_write_xmit+0x1a8/0x210 [c0322000] __tcp_push_pending_frames+0x1e/0x6f [c0317d5d] do_tcp_sendpages+0x4fa/0x521 [c0317dcf] tcp_sendpage+0x4b/0x5e [c02d7fa7] sock_sendpage+0x31/0x37 [c013242e] file_send_actor+0x30/0x4a [c0131e0b] do_generic_mapping_read+0x167/0x3d5 [c013248a] generic_file_sendfile+0x42/0x55 [c01323fe] file_send_actor+0x0/0x4a [c019a141] nfs_file_sendfile+0x59/0x60 [c01323fe] file_send_actor+0x0/0x4a [c014ad07] do_sendfile+0x1b8/0x252 [c01323fe] file_send_actor+0x0/0x4a [c014adec] sys_sendfile+0x4b/0x86 [c010272f] syscall_call+0x7/0xb David - -- David J. Coulson email: [EMAIL PROTECTED] web: http://www.davidcoulson.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzYQUTIgPQWnLowkRAqHuAKDhAovcE8dIhAofI2KTUXXZOQlXagCcC99R YGveQogGHtJV8yWbeezn45w= =upA0 -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
Re: BUG: warning at net/core/dev.c:1171/skb_checksum_help() 2.6.18-rc3
David Coulson wrote: This machine has four NICs running the e1000 kernel module. Other than the BUG() messages, it seems to be running fine. I was running 2.6.15.4 without any issues on the same hardware, although I noticed the e1000 has been updated (and I went for rc3 since I was hitting the panic in -rc2) Now, I'm not sure if it also has anything to do with this message: NAT: no longer support implicit source local NAT NAT: packet src 10.1.1.1 - dst 207.166.203.131 No, this in unrelated. This message tries to tell you that the old behaviour of changing the source address implicitly to the source address routing would use for a DNATed connection is no longer done. This behaviour changed in 2.6.11, so if everything worked in 2.6.15, you should be fine. Any suggestions as to how to go about debugging this? BUG: warning at net/core/dev.c:1171/skb_checksum_help() [c02e0412] skb_checksum_help+0x4d/0xf0 [c034e4d3] ip_nat_fn+0x4e/0x19e This is a known problem with NAT and HW checksum and will probably get fixed in 2.6.19. The message is just a warning, everything should work fine. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
On Sun, Jul 30, 2006 at 10:32:10PM -0500, Matt Domsch wrote:
On Sun, Jul 30, 2006 at 03:44:16PM -0700, David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Sat, 29 Jul 2006 14:33:25 +1000
[IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
The current users of ip6_dst_lookup can be divided into two classes:
1) The caller holds no locks and is in user-context (UDP).
2) The caller does not want to lookup the dst cache at all.
The second class covers everyone except UDP because most people do
the cache lookup directly before calling ip6_dst_lookup. This patch
adds ip6_sk_dst_lookup for the first class.
Similarly ip6_dst_store users can be divded into those that need to
take the socket dst lock and those that don't. This patch adds
__ip6_dst_store for those (everyone except UDP/datagram) that don't
need an extra lock.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Applied, thanks Herbert.
I applied this on 2.6.18-rc3, and it panics immediately as the first
IPv6 TCP (ssh) session is initiated to the system.
I backed out this patch, and get a somewhat different failure then
with 2.6.18-rc3 plain. The oops repeat continuously with EOI after
each. Again, this occurs as soon as I start an IPv6 ssh session.
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Linux version 2.6.18-rc3 ([EMAIL PROTECTED]) (gcc version 4.1.1 20060721 (Red
Hat 4.1.1-13)) #2 SMP Sun Jul 30 23:06:48 CDT 2006
=
[ INFO: inconsistent lock state ]
-
inconsistent {softirq-on-W} - {in-softirq-R} usage.
swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
(sk-sk_dst_lock){---?}, at: [80415827] sk_dst_check+0x26/0x113
{softirq-on-W} state was registered at:
[802a8231] lock_acquire+0x4a/0x69
[802688a1] _write_lock+0x24/0x31
[8044d9a4] inet_bind+0x198/0x20b
[80412ed4] sys_bind+0x75/0x9c
[8026144d] system_call+0x7d/0x83
irq event stamp: 604084
hardirqs last enabled at (604084): [8020aab2]
kmem_cache_alloc+0xd3/0xf7
hardirqs last disabled at (604083): [8020aa2a]
kmem_cache_alloc+0x4b/0xf7
softirqs last enabled at (604026): [8021288d] __do_softirq+0xec/0xf5
softirqs last disabled at (604029): [802626fa] call_softirq+0x1e/0x28
other info that might help us debug this:
1 lock held by swapper/0:
#0: (slock-AF_INET6){-+..}, at: [883d91df] tcp_v6_rcv+0x30e/0x76f
[ipv6]
stack backtrace:
Call Trace:
[8026f861] show_trace+0xae/0x30e
[8026fad6] dump_stack+0x15/0x17
[802a634f] print_usage_bug+0x259/0x26a
[802a6b38] mark_lock+0x1d5/0x3db
[802a76b8] __lock_acquire+0x412/0xa18
[802a8232] lock_acquire+0x4b/0x69
[802689b8] _read_lock+0x28/0x34
[80415827] sk_dst_check+0x26/0x113
[883ba986] :ipv6:ip6_dst_lookup+0x3a/0x192
[883d6c2f] :ipv6:tcp_v6_send_synack+0x185/0x2e4
[883d7a5a] :ipv6:tcp_v6_conn_request+0x291/0x2f3
[802455c2] tcp_rcv_state_process+0x5f/0xe7c
[883d7015] :ipv6:tcp_v6_do_rcv+0x268/0x372
[883d95f0] :ipv6:tcp_v6_rcv+0x71f/0x76f
[883bc48f] :ipv6:ip6_input+0x223/0x315
[883bcb3d] :ipv6:ipv6_rcv+0x254/0x2af
[80221883] netif_receive_skb+0x260/0x2dd
[88194292] :e1000:e1000_clean_rx_irq+0x423/0x4c2
[88192752] :e1000:e1000_clean+0x88/0x17d
[8020caed] net_rx_action+0xac/0x1d1
[80212809] __do_softirq+0x68/0xf5
[802626fa] call_softirq+0x1e/0x28
DWARF2 unwinder stuck at call_softirq+0x1e/0x28
Leftover inexact backtrace:
IRQ [80270b48] do_softirq+0x39/0x9f
[802960b6] irq_exit+0x57/0x59
[80270cab] do_IRQ+0xfd/0x107
[8025b612] mwait_idle+0x0/0x54
[80261985] ret_from_intr+0x0/0xf
EOI
1Unable to handle kernel paging request at 8280 RIP:
[8026fa5c] show_trace+0x2a9/0x30e
PGD 203027 PUD 205027 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: ipv6 ipmi_devintf ipmi_si ipmi_msghandler hidp rfcomm l2cap
bluetooth sunrpc ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack
nfnetlink xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq video sbs
i2c_ec i2c_core button battery asus_acpi ac parport_pc lp parport intel_rng
e1000 sg ehci_hcd ide_cd cdrom pcspkr serio_raw e752x_edac edac_mc uhci_hcd
dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd ata_piix libata sd_mod scsi_mod
Pid: 0, comm: swapper Not tainted 2.6.18-rc3 #2
RIP: 0010:[8026fa5c] [8026fa5c] show_trace+0x2a9/0x30e
RSP: 0018:8066a850 EFLAGS: 00010002
RAX: RBX: RCX: a4ec
RDX: 80561e60 RSI: RDI: 8056e020
RBP: 8066a940 R08: 8066a5a0 R09: 802abf75
R10: 802abf75 R11:
eth2.100: received packet with own address as source address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a machine running 2.6.18-rc3 with a bridge config that looks like this: cr1:~# brctl show bridge name bridge id STP enabled interfaces vlan100 36b0.0007e90f40c1 yes eth0.100 eth2.100 vlan101 5dc0.0007e90f40c1 yes eth0.101 eth2.101 vlan102 5dc0.00e08163c33f yes eth3 vlan200 5dc0.0007e90f40c1 yes eth0.200 eth2.200 vlan201 5dc0.0007e90f40c1 yes eth0.201 eth2.201 vlan300 5dc0.0007e90f40c1 yes eth0.300 eth2.300 vlan301 5dc0.0007e90f40c1 yes eth0.301 eth2.301 vlan302 5dc0.0007e90f40c1 yes eth0.302 eth2.302 vlan303 5dc0.0007e90f40c1 yes eth0.303 eth2.303 All bridges, except for vlan102, are running STP and appear to have elected themselves the root bridge. I see this on the console: printk: 18 messages suppressed. eth2.100: received packet with own address as source address printk: 20 messages suppressed. eth2.200: received packet with own address as source address This repeats continuously, only indicating an issue on the two specific ports mentioned above. This confuses me: 1) All VLANs (except for 102) are in an identical configuration 2) No other VLANs exhibit the same kernel message 3) I have another machine, running 2.6.18-rc2 with the same config and no kernel message Is this message specifically related to BPDU frames, or is it pertaining to any Ethernet frame on the port? Here is the STP config for one of the bridges. What's the next step to troubleshoot this? vlan200 bridge id 5dc0.0007e90f40c1 designated root5dc0.0007e90f40c1 root port 0path cost 0 max age 20.00 bridge max age 20.00 hello time2.00 bridge hello time 2.00 forward delay 5.00 bridge forward delay 5.00 ageing time 300.01 hello timer 1.67 tcn timer 0.00 topology change timer 0.00 gc timer 0.03 flags eth0.200 (1) port id8001state forwarding designated root5dc0.0007e90f40c1 path cost 19 designated bridge 5dc0.0007e90f40c1 message age timer 0.00 designated port8001forward delay timer 0.00 designated cost 0hold timer 0.67 flags eth2.200 (2) port id8002state blocking designated root5dc0.0007e90f40c1 path cost 4 designated bridge 5dc0.0007e90f40c1 message age timer 19.67 designated port8001forward delay timer 0.00 designated cost 0hold timer 0.00 flags David - -- David J. Coulson email: [EMAIL PROTECTED] web: http://www.davidcoulson.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEzYanTIgPQWnLowkRApT1AJ9yXl/O+rzacF+mpM7hhNtsEh/ufACfQCHk mBGBxl5Iscj7vbFlM0IzY/Y= =ZIs7 -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
Re: BUG: warning at net/core/dev.c:1171/skb_checksum_help() 2.6.18-rc3
On Mon, 31 Jul 2006 00:16:21 -0400 David Coulson [EMAIL PROTECTED] wrote: This machine has four NICs running the e1000 kernel module. Other than the BUG() messages, it seems to be running fine. I was running 2.6.15.4 without any issues on the same hardware, although I noticed the e1000 has been updated (and I went for rc3 since I was hitting the panic in -rc2) Now, I'm not sure if it also has anything to do with this message: NAT: no longer support implicit source local NAT NAT: packet src 10.1.1.1 - dst 207.166.203.131 Any suggestions as to how to go about debugging this? BUG: warning at net/core/dev.c:1171/skb_checksum_help() [c02e0412] skb_checksum_help+0x4d/0xf0 [c034e4d3] ip_nat_fn+0x4e/0x19e [c034e78e] ip_nat_local_fn+0x3d/0xb9 [c0314011] dst_output+0x0/0x7 [c03059ee] nf_iterate+0x40/0x6e Several people are reporting this. It's apparently harmless and serves as a(n odd) way for the net guys to remind themselves that this needs fixing. It'd be nice to not let this escape into 2.6.18, please? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: warning at net/core/dev.c:1171/skb_checksum_help() 2.6.18-rc3
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 31 Jul 2006 06:24:31 +0200 This is a known problem with NAT and HW checksum and will probably get fixed in 2.6.19. I would like to see this fixed for 2.6.18, no later. Either that or disable the bug trap, but taking this route is severely discouraged. :) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: warning at net/core/dev.c:1171/skb_checksum_help() 2.6.18-rc3
David Miller wrote: From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 31 Jul 2006 06:24:31 +0200 This is a known problem with NAT and HW checksum and will probably get fixed in 2.6.19. I would like to see this fixed for 2.6.18, no later. Either that or disable the bug trap, but taking this route is severely discouraged. :) I'm actually updateing my patch for this on top of Herbert's CHECKSUM_PARTIAL patch right now. Unfortunately I targeted 2.6.19, so the fixes are on top of a few cleanups (which unconvered a few unrelated bugs as well). I'll post it when I'm done so we can decide how to proceed. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: warning at net/core/dev.c:1171/skb_checksum_help() 2.6.18-rc3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Now, I started the heartbeat process on the same machine, and it blew up
trying to do something with IPaddr. I can't even sysrq the box back into
life at this point :-/
BUG: unable to handle kernel paging request at virtual address 9e045900
printing eip:
c01119d7
*pde =
Oops: [#1]
SMP
CPU:0
EIP:0060:[c01119d7]Not tainted VLI
EFLAGS: 00010097 (2.6.18-rc3 #2)
EIP is at resched_task+0x11/0x61
eax: c05134e0 ebx: f5024570 ecx: f5046000 edx: f76db540
esi: c200d340 edi: 0001 ebp: f1cc3e00 esp: f1cc3dfc
ds: 007b es: 007b ss: 0068
Process IPaddr (pid: 8939, ti=f1cc2000 task=f5264ab0 task.ti=f1cc2000)
Stack: c2117030 f1cc3e5c c0112034 c0112804 0075 0180 c2011cdc
c2011cdc
c200ca24 0001 007d 01af9500 0001 c200d340 c2011460
0001
000f 0092 c2011460 c200d340
c200c9e0
Call Trace:
[c0112034] try_to_wake_up+0x262/0x285
[c0112804] move_tasks+0xfd/0x207
[c0112f2b] load_balance+0x14a/0x1d7
[c011325e] rebalance_tick+0xc5/0xe5
[c012025f] update_process_times+0x52/0x5c
[c010a2b6] smp_apic_timer_interrupt+0x5b/0x61
[c0103147] apic_timer_interrupt+0x1f/0x24
[c038dbe6] __mutex_lock_slowpath+0x17f/0x18e
[c015f020] touch_atime+0x65/0xa6
[c0153c2b] pipe_readv+0x67/0x272
[c0153e52] pipe_read+0x1c/0x20
[c014a2e7] vfs_read+0x84/0x123
[c014a5df] sys_read+0x3c/0x62
[c010272f] syscall_call+0x7/0xb
Code: 2b 43 18 89 42 08 89 d8 8b 53 30 e8 08 fd ff ff c7 43 30 00 00 00
00 5b 5
EIP: [c01119d7] resched_task+0x11/0x61 SS:ESP 0068:f1cc3dfc
0Kernel panic - not syncing: Fatal exception in interrupt
BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
[c0108ca4] smp_call_function+0x59/0x119
[c01034b7] show_stack_log_lvl+0x91/0x99
[c01185de] printk+0xe/0x11
[c0108daa] smp_send_stop+0x13/0x1c
[c0117dec] panic+0x41/0xdb
[c01038ad] die+0x1c3/0x1da
[c01185de] printk+0xe/0x11
[c010dd0e] do_page_fault+0x3e3/0x4bc
[c010d92b] do_page_fault+0x0/0x4bc
[c01031d5] error_code+0x39/0x40
[c01119d7] resched_task+0x11/0x61
[c0112034] try_to_wake_up+0x262/0x285
[c0112804] move_tasks+0xfd/0x207
[c0112f2b] load_balance+0x14a/0x1d7
[c011325e] rebalance_tick+0xc5/0xe5
[c012025f] update_process_times+0x52/0x5c
[c010a2b6] smp_apic_timer_interrupt+0x5b/0x61
[c0103147] apic_timer_interrupt+0x1f/0x24
[c038dbe6] __mutex_lock_slowpath+0x17f/0x18e
[c015f020] touch_atime+0x65/0xa6
[c0153c2b] pipe_readv+0x67/0x272
[c0153e52] pipe_read+0x1c/0x20
[c014a2e7] vfs_read+0x84/0x123
[c014a5df] sys_read+0x3c/0x62
[c010272f] syscall_call+0x7/0xb
David
- --
David J. Coulson
email: [EMAIL PROTECTED]
web: http://www.davidcoulson.net/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEzYocTIgPQWnLowkRAvuKAKCCRVXMq60qIBwMq6BQ/eWFV/nTPQCgmjIl
Ki3kjhWJ3dG2itFTHn8D/sw=
=/Gf/
-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
