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:[]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:
[] try_to_wake_up+0x262/0x285
[] move_tasks+0xfd/0x207
[] load_balance+0x14a/0x1d7
[] rebalance_tick+0xc5/0xe5
[] update_process_times+0x52/0x5c
[] smp_apic_timer_interrupt+0x5b/0x61
[] apic_timer_interrupt+0x1f/0x24
[] __mutex_lock_slowpath+0x17f/0x18e
[] touch_atime+0x65/0xa6
[] pipe_readv+0x67/0x272
[] pipe_read+0x1c/0x20
[] vfs_read+0x84/0x123
[] sys_read+0x3c/0x62
[] 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: [] resched_task+0x11/0x61 SS:ESP 0068:f1cc3dfc
<0>Kernel panic - not syncing: Fatal exception in interrupt
BUG: warning at arch/i386/kernel/smp.c:547/smp_call_function()
[] smp_call_function+0x59/0x119
[] show_stack_log_lvl+0x91/0x99
[] printk+0xe/0x11
[] smp_send_stop+0x13/0x1c
[] panic+0x41/0xdb
[] die+0x1c3/0x1da
[] printk+0xe/0x11
[] do_page_fault+0x3e3/0x4bc
[] do_page_fault+0x0/0x4bc
[] error_code+0x39/0x40
[] resched_task+0x11/0x61
[] try_to_wake_up+0x262/0x285
[] move_tasks+0xfd/0x207
[] load_balance+0x14a/0x1d7
[] rebalance_tick+0xc5/0xe5
[] update_process_times+0x52/0x5c
[] smp_apic_timer_interrupt+0x5b/0x61
[] apic_timer_interrupt+0x1f/0x24
[] __mutex_lock_slowpath+0x17f/0x18e
[] touch_atime+0x65/0xa6
[] pipe_readv+0x67/0x272
[] pipe_read+0x1c/0x20
[] vfs_read+0x84/0x123
[] sys_read+0x3c/0x62
[] 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
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
From: Andrew Morton <[EMAIL PROTECTED]> Date: Sun, 30 Jul 2006 21:34:37 -0700 > 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? I'll make sure it doesn't. :) - To unsubscribe from this list: send 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
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() > [] skb_checksum_help+0x4d/0xf0 > [] ip_nat_fn+0x4e/0x19e > [] ip_nat_local_fn+0x3d/0xb9 > [] dst_output+0x0/0x7 > [] 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: 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
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: [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 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: [] sk_dst_check+0x26/0x113
{softirq-on-W} state was registered at:
[] lock_acquire+0x4a/0x69
[] _write_lock+0x24/0x31
[] inet_bind+0x198/0x20b
[] sys_bind+0x75/0x9c
[] system_call+0x7d/0x83
irq event stamp: 604084
hardirqs last enabled at (604084): []
kmem_cache_alloc+0xd3/0xf7
hardirqs last disabled at (604083): []
kmem_cache_alloc+0x4b/0xf7
softirqs last enabled at (604026): [] __do_softirq+0xec/0xf5
softirqs last disabled at (604029): [] call_softirq+0x1e/0x28
other info that might help us debug this:
1 lock held by swapper/0:
#0: (slock-AF_INET6){-+..}, at: [] tcp_v6_rcv+0x30e/0x76f
[ipv6]
stack backtrace:
Call Trace:
[] show_trace+0xae/0x30e
[] dump_stack+0x15/0x17
[] print_usage_bug+0x259/0x26a
[] mark_lock+0x1d5/0x3db
[] __lock_acquire+0x412/0xa18
[] lock_acquire+0x4b/0x69
[] _read_lock+0x28/0x34
[] sk_dst_check+0x26/0x113
[] :ipv6:ip6_dst_lookup+0x3a/0x192
[] :ipv6:tcp_v6_send_synack+0x185/0x2e4
[] :ipv6:tcp_v6_conn_request+0x291/0x2f3
[] tcp_rcv_state_process+0x5f/0xe7c
[] :ipv6:tcp_v6_do_rcv+0x268/0x372
[] :ipv6:tcp_v6_rcv+0x71f/0x76f
[] :ipv6:ip6_input+0x223/0x315
[] :ipv6:ipv6_rcv+0x254/0x2af
[] netif_receive_skb+0x260/0x2dd
[] :e1000:e1000_clean_rx_irq+0x423/0x4c2
[] :e1000:e1000_clean+0x88/0x17d
[] net_rx_action+0xac/0x1d1
[] __do_softirq+0x68/0xf5
[] call_softirq+0x1e/0x28
DWARF2 unwinder stuck at call_softirq+0x1e/0x28
Leftover inexact backtrace:
[] do_softirq+0x39/0x9f
[] irq_exit+0x57/0x59
[] do_IRQ+0xfd/0x107
[] mwait_idle+0x0/0x54
[] ret_from_intr+0x0/0xf
<1>Unable to handle kernel paging request at 8280 RIP:
[] 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:[] [] 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: R12: 827d
R13: 8066a860 R14: R15:
FS: () GS:80922000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 8280 CR3: 72e0b000 CR4: 06e0
Process swapper (pid: 0, threadinfo 80952000, task 80561e60)
Stack: 8066a860 80725708
80953ec8 8066af80 0046
Call Trace:
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() > [] skb_checksum_help+0x4d/0xf0 > [] 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
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() [] skb_checksum_help+0x4d/0xf0 [] ip_nat_fn+0x4e/0x19e [] ip_nat_local_fn+0x3d/0xb9 [] dst_output+0x0/0x7 [] nf_iterate+0x40/0x6e BUG: warning at net/core/dev.c:1171/skb_checksum_help() [] skb_checksum_help+0x4d/0xf0 [] ip_nat_fn+0x4e/0x19e [] ip_nat_local_fn+0x3d/0xb9 [] dst_output+0x0/0x7 [] nf_iterate+0x40/0x6e [] dst_output+0x0/0x7 [] nf_hook_slow+0x42/0x98 [] dst_output+0x0/0x7 [] ip_queue_xmit+0x3a3/0x3fc [] dst_output+0x0/0x7 [] xprt_timer+0x0/0x65 [] __next_cpu+0x12/0x1f [] find_busiest_group+0x17e/0x473 [] tcp_transmit_skb+0x39f/0x3bc [] tcp_write_xmit+0x1a8/0x210 [] __tcp_push_pending_frames+0x1e/0x6f [] do_tcp_sendpages+0x4fa/0x521 [] tcp_sendpage+0x4b/0x5e [] sock_sendpage+0x31/0x37 [] file_send_actor+0x30/0x4a [] do_generic_mapping_read+0x167/0x3d5 [] generic_file_sendfile+0x42/0x55 [] file_send_actor+0x0/0x4a [] nfs_file_sendfile+0x59/0x60 [] file_send_actor+0x0/0x4a [] do_sendfile+0x1b8/0x252 [] file_send_actor+0x0/0x4a [] sys_sendfile+0x4b/0x86 [] syscall_call+0x7/0xb BUG: warning at net/core/dev.c:1225/skb_gso_segment() [] skb_gso_segment+0x88/0x179 [] dev_gso_segment+0x5c/0x82 [] dev_hard_start_xmit+0x49/0xb1 [] dev_queue_xmit+0x1a5/0x21f [] ip_output+0x1ce/0x205 [] ip_queue_xmit+0x3b5/0x3fc [] xprt_timer+0x0/0x65 [] __next_cpu+0x12/0x1f [] find_busiest_group+0x17e/0x473 [] tcp_transmit_skb+0x39f/0x3bc [] tcp_write_xmit+0x1a8/0x210 [] __tcp_push_pending_frames+0x1e/0x6f [] do_tcp_sendpages+0x4fa/0x521 [] tcp_sendpprintk: 19 messages suppressed. age+0x4b/0x5e eth2.300: received packet with own address as source address [] sock_sendpage+0x31/0x37 [] file_send_actor+0x30/0x4a [] do_generic_mapping_read+0x167/0x3d5 [] generic_file_sendfile+0x42/0x55 [] file_send_actor+0x0/0x4a [] nfs_file_sendfile+0x59/0x60 [] file_send_actor+0x0/0x4a [] do_sendfile+0x1b8/0x252 [] file_send_actor+0x0/0x4a [] sys_sendfile+0x4b/0x86 [] syscall_call+0x7/0xb [] dst_output+0x0/0x7 [] nf_hook_slow+0x42/0x98 [] dst_output+0x0/0x7 [] ip_queue_xmit+0x3a3/0x3fc [] dst_output+0x0/0x7 [] xprt_timer+0x0/0x65 [] __next_cpu+0x12/0x1f [] find_busiest_group+0x17e/0x473 [] tcp_transmit_skb+0x39f/0x3bc [] tcp_write_xmit+0x1a8/0x210 [] __tcp_push_pending_frames+0x1e/0x6f [] do_tcp_sendpages+0x4fa/0x521 [] tcp_sendpage+0x4b/0x5e [] sock_sendpage+0x31/0x37 [] file_send_actor+0x30/0x4a [] do_generic_mapping_read+0x167/0x3d5 [] generic_file_sendfile+0x42/0x55 [] file_send_actor+0x0/0x4a [] nfs_file_sendfile+0x59/0x60 [] file_send_actor+0x0/0x4a [] do_sendfile+0x1b8/0x252 [] file_send_actor+0x0/0x4a [] sys_sendfile+0x4b/0x86 [] 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: [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: [XFRM]: Fix protocol field value for outgoing IPv6 GSO packets
Hi Dave, 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. [XFRM]: Fix protocol field value for outgoing IPv6 GSO packets Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> --- commit 8035f60a607630459e4440dbbc5a20f3cfbf97ac tree f1a7061cfd1f923b3991ee8f449cffce86870a3e parent 440848a8e33fc1927bab45bd73f6c8e042ea7abd author Patrick McHardy <[EMAIL PROTECTED]> Tue, 25 Jul 2006 02:02:00 +0200 committer Patrick McHardy <[EMAIL PROTECTED]> Tue, 25 Jul 2006 02:02:00 +0200 net/ipv6/xfrm6_output.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c index 0eea60e..c8c8b44 100644 --- a/net/ipv6/xfrm6_output.c +++ b/net/ipv6/xfrm6_output.c @@ -125,7 +125,7 @@ static int xfrm6_output_finish(struct sk if (!skb_is_gso(skb)) return xfrm6_output_finish2(skb); - skb->protocol = htons(ETH_P_IP); + skb->protocol = htons(ETH_P_IPV6); segs = skb_gso_segment(skb, 0); kfree_skb(skb); if (unlikely(IS_ERR(segs)))
Re: [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls
From: Matt Domsch <[EMAIL PROTECTED]>
Date: Sun, 30 Jul 2006 22:32:10 -0500
> swapper/0 is trying to acquire lock:
> (slock-AF_INET6){-+..}, at: [] sk_clone+0xd2/0x3a8
>
> but task is already holding lock:
> (slock-AF_INET6){-+..}, at: [] tcp_v6_rcv+0x30e/0x76e
> [ipv6]
The tcp_v6_rcv() code path is holding the slock on the parent
listening socket, whereas in sk_clone() we have grabbed the
socket slock on the newly allocated "newsk" socket. These
are thus two seperate locks, although they are in the same
locking class "slock-AF_INET6".
I don't know why the lock validator is complaining about this.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 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][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 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: [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: [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: [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: [] sk_clone+0xd2/0x3a8
but task is already holding lock:
(slock-AF_INET6){-+..}, at: [] 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: [] tcp_v6_rcv+0x30e/0x76e
[ipv6]
stack backtrace:
Call Trace:
[] show_trace+0xae/0x30e
[] dump_stack+0x15/0x17
[] __lock_acquire+0x12e/0xa18
[] lock_acquire+0x4b/0x69
[] _spin_lock+0x25/0x31
[] sk_clone+0xd2/0x3a8
[] inet_csk_clone+0x11/0x6f
[] tcp_create_openreq_child+0x24/0x49c
[] :ipv6:tcp_v6_syn_recv_sock+0x2c5/0x6be
[] tcp_check_req+0x1d1/0x326
[] :ipv6:tcp_v6_do_rcv+0x15d/0x372
[] :ipv6:tcp_v6_rcv+0x71f/0x76e
[] :ipv6:ip6_input+0x223/0x315
[] :ipv6:ipv6_rcv+0x254/0x2af
[] netif_receive_skb+0x260/0x2dd
[] :e1000:e1000_clean_rx_irq+0x423/0x4c2
[] :e1000:e1000_clean+0x88/0x17d
[] net_rx_action+0xac/0x1d1
[] __do_softirq+0x68/0xf5
[] call_softirq+0x1e/0x28
DWARF2 unwinder stuck at call_softirq+0x1e/0x28
Leftover inexact backtrace:
[] do_softirq+0x39/0x9f
[] irq_exit+0x57/0x59
[] do_IRQ+0xfd/0x107
[] mwait_idle+0x0/0x54
[] ret_from_intr+0x0/0xf
<1>Unable to handle kernel paging request at 8280 RIP:
[] 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:[] [] 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:
[] dump_stack+0x15/0x17
[] __lock_acquire+0x12e/0xa18
[] lock_acquire+0x4b/0x69
[] _spin_lock+0x25/0x31
[] sk_clone+0xd2/0x3a8
[] inet_csk_clone+0x11/0x6f
[] tcp_create_openreq_child+0x24/0x49c
[] :ipv6:tcp_v6_syn_recv_sock+0x2c5/0x6be
[] tcp_check_req+0x1d1/0x326
[] :ipv6:tcp_v6_do_rcv+0x15d/0x372
[] :ipv6:tcp_v6_rcv+0x71f/0x76e
[] :ipv6:ip6_input+0x223/0x315
[] :ipv6:ipv6_rcv+0x254/0x2af
[] netif_receive_skb+0x260/0x2dd
[] :e1000:e1000_clean_rx_irq+0x423/0x4c2
[] :e1000:e1000_clean+0x88/0x17d
[] net_rx_action+0xac/0x1d1
[] __do_softirq+0x68/0xf5
[] call_softirq+0x1e/0x28
DWARF2 unwinder stuck at call_softirq+0x1e/0x28
Leftover inexact backtrace
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: [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: [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 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: 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] 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: [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: [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: 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: [stable] [NET]: Update frag_list in pskb_trim
For stable only:
On Tue, Jul 18, 2006 at 04:13:29AM +1000, herbert wrote:
>
> Here is a second attempt:
>
> [NET]: Update frag_list in pskb_trim
Unfortunately there was a bug in the fix which is now fixed. I presume
this hasn't been included yet so I'm simply regenerating the whole patch.
Let me know if you want an incremental version instead.
[NET]: Update frag_list in pskb_trim
When pskb_trim has to defer to ___pksb_trim to trim the frag_list part of
the packet, the frag_list is not updated to reflect the trimming. This
will usually work fine until you hit something that uses the packet length
or tail from the frag_list.
Examples include esp_output and ip_fragment.
Another problem caused by this is that you can end up with a linear packet
with a frag_list attached.
It is possible to get away with this if we audit everything to make sure
that they always consult skb->len before going down onto frag_list. In
fact we can do the samething for the paged part as well to avoid copying
the data area of the skb. For now though, let's do the conservative fix
and update frag_list.
Many thanks to Marco Berizzi for helping me to track down this bug.
This 4-year old bug took 3 months to track down. Marco was very patient
indeed :)
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f8f2347..2c31bb0 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -967,15 +967,16 @@ #ifndef NET_SKB_PAD
#define NET_SKB_PAD16
#endif
-extern int ___pskb_trim(struct sk_buff *skb, unsigned int len, int realloc);
+extern int ___pskb_trim(struct sk_buff *skb, unsigned int len);
static inline void __skb_trim(struct sk_buff *skb, unsigned int len)
{
- if (!skb->data_len) {
- skb->len = len;
- skb->tail = skb->data + len;
- } else
- ___pskb_trim(skb, len, 0);
+ if (unlikely(skb->data_len)) {
+ WARN_ON(1);
+ return;
+ }
+ skb->len = len;
+ skb->tail = skb->data + len;
}
/**
@@ -985,6 +986,7 @@ static inline void __skb_trim(struct sk_
*
* Cut the length of a buffer down by removing data from the tail. If
* the buffer is already under the length specified it is not modified.
+ * The skb must be linear.
*/
static inline void skb_trim(struct sk_buff *skb, unsigned int len)
{
@@ -995,12 +997,10 @@ static inline void skb_trim(struct sk_bu
static inline int __pskb_trim(struct sk_buff *skb, unsigned int len)
{
- if (!skb->data_len) {
- skb->len = len;
- skb->tail = skb->data+len;
- return 0;
- }
- return ___pskb_trim(skb, len, 1);
+ if (skb->data_len)
+ return ___pskb_trim(skb, len);
+ __skb_trim(skb, len);
+ return 0;
}
static inline int pskb_trim(struct sk_buff *skb, unsigned int len)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index fb3770f..f3cfb36 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -250,11 +250,11 @@ nodata:
}
-static void skb_drop_fraglist(struct sk_buff *skb)
+static void skb_drop_list(struct sk_buff **listp)
{
- struct sk_buff *list = skb_shinfo(skb)->frag_list;
+ struct sk_buff *list = *listp;
- skb_shinfo(skb)->frag_list = NULL;
+ *listp = NULL;
do {
struct sk_buff *this = list;
@@ -263,6 +263,11 @@ static void skb_drop_fraglist(struct sk_
} while (list);
}
+static inline void skb_drop_fraglist(struct sk_buff *skb)
+{
+ skb_drop_list(&skb_shinfo(skb)->frag_list);
+}
+
static void skb_clone_fraglist(struct sk_buff *skb)
{
struct sk_buff *list;
@@ -800,49 +805,86 @@ struct sk_buff *skb_pad(struct sk_buff *
return nskb;
}
-/* Trims skb to length len. It can change skb pointers, if "realloc" is 1.
- * If realloc==0 and trimming is impossible without change of data,
- * it is BUG().
+/* Trims skb to length len. It can change skb pointers.
*/
-int ___pskb_trim(struct sk_buff *skb, unsigned int len, int realloc)
+int ___pskb_trim(struct sk_buff *skb, unsigned int len)
{
+ struct sk_buff **fragp;
+ struct sk_buff *frag;
int offset = skb_headlen(skb);
int nfrags = skb_shinfo(skb)->nr_frags;
int i;
+ int err;
- for (i = 0; i < nfrags; i++) {
+ if (skb_cloned(skb) &&
+ unlikely((err = pskb_expand_head(skb, 0, 0, GFP_ATOMIC
+ return err;
+
+ i = 0;
+ if (offset >= len)
+ goto drop_pages;
+
+ for (; i < nfrags; i++) {
int end = offset + skb_shinfo(skb)->frags[i].size;
- if (end > len
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: [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: and [subsystem] 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: [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: [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] 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: 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 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: [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
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- SERR- 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
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 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
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.
[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
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] 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, 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
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: [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
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=11304534653&r=1&w=2 [2] http://marc.theaimsgroup.com/?l=linux-net&m=111989050303975&w=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: 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. 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
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
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: [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 > #if defined(__KERNEL__) && defined(CONFIG_BRIDGE_NETFILTER) > -#include > #include > #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
[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
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
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: 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
