Re: tg3 module problem with suspend2

2006-07-30 Thread Michael Chan
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.

2006-07-30 Thread Ulrich Drepper
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

2006-07-30 Thread maximilian attems
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

2006-07-30 Thread Adrian Bunk
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

2006-07-30 Thread David Woodhouse
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

2006-07-30 Thread Ilpo Järvinen
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

2006-07-30 Thread Hugo Santos
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

2006-07-30 Thread Krzysztof Oledzki



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

2006-07-30 Thread Baruch Even
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

2006-07-30 Thread Krzysztof Halasa
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

2006-07-30 Thread Kyle McMartin
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

2006-07-30 Thread Andrew Morton
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

2006-07-30 Thread Sergei Shtylylov
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

2006-07-30 Thread Kyle McMartin
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()

2006-07-30 Thread Jesper Juhl
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...

2006-07-30 Thread Oumer Teyeb

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()

2006-07-30 Thread Stephen Hemminger
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()

2006-07-30 Thread James Morris
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()

2006-07-30 Thread Jesper Juhl

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

2006-07-30 Thread Thomas Glanzmann
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.

2006-07-30 Thread James Morris
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.

2006-07-30 Thread James Morris
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread David Miller
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.

2006-07-30 Thread David Miller
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread Sam Ravnborg
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread David Miller
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'

2006-07-30 Thread David Miller
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

2006-07-30 Thread Jeff Garzik

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

2006-07-30 Thread Jeff Garzik

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()

2006-07-30 Thread David Miller
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread Russell Stuart
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.

2006-07-30 Thread James Morris
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.

2006-07-30 Thread James Morris
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

2006-07-30 Thread Randy.Dunlap
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

2006-07-30 Thread Matt Domsch
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread Sam Ravnborg
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

2006-07-30 Thread David Coulson
-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

2006-07-30 Thread Patrick McHardy
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

2006-07-30 Thread Matt Domsch
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

2006-07-30 Thread David Coulson
-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

2006-07-30 Thread Andrew Morton
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

2006-07-30 Thread David Miller
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

2006-07-30 Thread Patrick McHardy
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

2006-07-30 Thread David Coulson
-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