BUG in bcm32xx-d80211: sleeping function called with irq's disabled
The latest git pull from wireless-dev (g7844a579) is calling a sleeping function with irq's disabled. The kernel is a UP version with preemption disabled. The dump is as follows: kernel: bcm43xx_d80211: Virtual interface added (type: 0x0002, ID: 4, MAC: 00:06:25:40:6f:03) kernel: bcm43xx_d80211: PHY connected kernel: BUG: sleeping function called from invalid context at kernel/mutex.c:86 kernel: in_atomic():0, irqs_disabled():1 kernel: [] show_trace_log_lvl+0x197/0x1c0 kernel: [] show_trace+0x1b/0x20 kernel: [] dump_stack+0x26/0x30 kernel: [] __might_sleep+0xa2/0xc0 kernel: [] mutex_lock+0x1d/0x30 kernel: [] ssb_core_is_enabled+0x1a/0x50 [ssb] kernel: [] bcm43xx_wireless_core_reset+0x1d/0xc0 [bcm43xx_d80211] kernel: [] bcm43xx_phy_calibrate+0x74/0xe0 [bcm43xx_d80211] kernel: [] wireless_core_up+0x5b/0x700 [bcm43xx_d80211] kernel: [] bcm43xx_select_wireless_core+0x22a/0x8c0 [bcm43xx_d80211] kernel: [] bcm43xx_init_board+0x84/0xb0 [bcm43xx_d80211] kernel: [] bcm43xx_net_open+0x16/0x20 [bcm43xx_d80211] kernel: [] ieee80211_open+0x175/0x360 [80211] kernel: [] dev_open+0x43/0x90 kernel: [] dev_change_flags+0x55/0x130 kernel: [] devinet_ioctl+0x65f/0x6d0 kernel: [] inet_ioctl+0x88/0xb0 kernel: [] sock_ioctl+0xbb/0x260 kernel: [] do_ioctl+0x2b/0x80 kernel: [] vfs_ioctl+0x51/0x290 kernel: [] sys_ioctl+0x41/0x60 kernel: [] sysenter_past_esp+0x56/0x8d kernel: [] 0xb7f35410 kernel: [] show_trace+0x1b/0x20 kernel: [] dump_stack+0x26/0x30 kernel: [] __might_sleep+0xa2/0xc0 kernel: [] mutex_lock+0x1d/0x30 kernel: [] ssb_core_is_enabled+0x1a/0x50 [ssb] kernel: [] bcm43xx_wireless_core_reset+0x1d/0xc0 [bcm43xx_d80211] kernel: [] bcm43xx_phy_calibrate+0x74/0xe0 [bcm43xx_d80211] kernel: [] wireless_core_up+0x5b/0x700 [bcm43xx_d80211] kernel: [] bcm43xx_select_wireless_core+0x22a/0x8c0 [bcm43xx_d80211] kernel: [] bcm43xx_init_board+0x84/0xb0 [bcm43xx_d80211] kernel: [] bcm43xx_net_open+0x16/0x20 [bcm43xx_d80211] kernel: [] ieee80211_open+0x175/0x360 [80211] kernel: [] dev_open+0x43/0x90 kernel: [] dev_change_flags+0x55/0x130 kernel: [] devinet_ioctl+0x65f/0x6d0 kernel: [] inet_ioctl+0x88/0xb0 kernel: [] sock_ioctl+0xbb/0x260 kernel: [] do_ioctl+0x2b/0x80 kernel: [] vfs_ioctl+0x51/0x290 kernel: [] sys_ioctl+0x41/0x60 kernel: [] sysenter_past_esp+0x56/0x8d kernel: bcm43xx_d80211: PHY disconnected -- VGER BF report: U 0.500028 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
neigh_lookup lockdep warning
Seen during boot of a 2.6.18rc5-git1 based kernel.
Dave
===
[ INFO: possible circular locking dependency detected ]
2.6.17-1.2608.fc6 #1
---
swapper/0 is trying to acquire lock:
(&tbl->lock){-+-+}, at: [] neigh_lookup+0x50/0xaf
but task is already holding lock:
(&list->lock#3){-+..}, at: [] neigh_proxy_process+0x20/0xc2
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&list->lock#3){-+..}:
[] lock_acquire+0x4b/0x6d
[] _spin_lock_irqsave+0x22/0x32
[] skb_dequeue+0x12/0x43
[] skb_queue_purge+0x14/0x1b
[] neigh_update+0x34a/0x3a6
[] arp_process+0x4ad/0x4e7
[] arp_rcv+0xd4/0xf1
[] netif_receive_skb+0x205/0x274
[] rhine_napipoll+0x28d/0x449 [via_rhine]
[] net_rx_action+0x9d/0x196
[] __do_softirq+0x78/0xf2
[] do_softirq+0x5a/0xbe
-> #1 (&n->lock){-+..}:
[] lock_acquire+0x4b/0x6d
[] _write_lock+0x19/0x28
[] neigh_periodic_timer+0x98/0x13c
[] run_timer_softirq+0x108/0x167
[] __do_softirq+0x78/0xf2
[] do_softirq+0x5a/0xbe
-> #0 (&tbl->lock){-+-+}:
[] lock_acquire+0x4b/0x6d
[] _read_lock_bh+0x1e/0x2d
[] neigh_lookup+0x50/0xaf
[] neigh_event_ns+0x2c/0x77
[] arp_process+0x369/0x4e7
[] parp_redo+0x8/0xa
[] neigh_proxy_process+0x66/0xc2
[] run_timer_softirq+0x108/0x167
[] __do_softirq+0x78/0xf2
[] do_softirq+0x5a/0xbe
other info that might help us debug this:
1 lock held by swapper/0:
#0: (&list->lock#3){-+..}, at: [] neigh_proxy_process+0x20/0xc2
stack backtrace:
[] show_trace_log_lvl+0x58/0x159
[] show_trace+0xd/0x10
[] dump_stack+0x19/0x1b
[] print_circular_bug_tail+0x59/0x64
[] __lock_acquire+0x80d/0x99c
[] lock_acquire+0x4b/0x6d
[] _read_lock_bh+0x1e/0x2d
[] neigh_lookup+0x50/0xaf
[] neigh_event_ns+0x2c/0x77
[] arp_process+0x369/0x4e7
[] parp_redo+0x8/0xa
[] neigh_proxy_process+0x66/0xc2
[] run_timer_softirq+0x108/0x167
[] __do_softirq+0x78/0xf2
[] do_softirq+0x5a/0xbe
[] irq_exit+0x3d/0x3f
[] smp_apic_timer_interrupt+0x79/0x7e
[] apic_timer_interrupt+0x2a/0x30
DWARF2 unwinder stuck at apic_timer_interrupt+0x2a/0x30
Leftover inexact backtrace:
--
http://www.codemonkey.org.uk
--
VGER BF report: U 0.489161
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM
Krzysztof Halasa <[EMAIL PROTECTED]> :
[...]
> ===
> [ INFO: possible circular locking dependency detected ]
> ---
> swapper/0 is trying to acquire lock:
> (&dev->queue_lock){-+..}, at: [] dev_queue_xmit+0x56/0x290
>
> but task is already holding lock:
> (&dev->_xmit_lock){-+..}, at: [] dev_queue_xmit+0x224/0x290
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (&dev->_xmit_lock){-+..}:
>[] lock_acquire+0x76/0xa0
>[] _spin_lock_bh+0x31/0x40
>[] dev_activate+0x69/0x120
[...]
>[] vfs_ioctl+0x57/0x290
>[] sys_ioctl+0x39/0x60
>[] sysenter_past_esp+0x56/0x8d
>
> -> #0 (&dev->queue_lock){-+..}:
>[] lock_acquire+0x76/0xa0
>[] _spin_lock+0x2c/0x40
>[] dev_queue_xmit+0x56/0x290
[...]
>[] __do_softirq+0x55/0xc0
>[] do_softirq+0x63/0xd0
dev_activate takes BH disabling locks only. How could a softirq happen
on the same cpu and trigger a deadlock ?
--
Ueimor
--
VGER BF report: U 0.500151
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc5 + pata-drivers on MSI K9N Ultra report, AMD64
Ar Sad, 2006-09-02 am 22:14 +0200, ysgrifennodd Krzysztof Halasa: > ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 > ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 > > There is no secondary IDE connector on this motherboard, I think > it's just disabled by BIOS. Its there if it got that far. May not be wired. > scsi3 : pata_amd > ata4: port is slow to respond, please be patient > ata4: port failed to respond (30 secs) Please send me an lspci -vxxx. This might be BIOS or might be us misparsing disable/enable bits. -- VGER BF report: U 0.5 - To unsubscribe from this list: send 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: ProxyARP and IPSec
> > > What I great idea. Now I just have to get every host I want to > interoperate with to support a nonstandard configuration. The scary > part is that if I motivate it with "Linux is too stupid to handle > standard tunnel-mode IPsec" I might actually get away with it. > > Linux handles tunnel-mode IPsec in the same way that most IPsec vendors did and many still do. For example, Cisco IOS has pages and pages of documentation about how to combine IPsec with GRE in order to support securely running OSPF between sites, precisely because its IPsec didn't offer a virtual interface. However, Cisco (along with Netscreen/Juniper and Fortinet) now additionally support IPsec that uses a virtual interface and so you have a choice of using an interface or not as you see fit. I would be useful if Linux offered the option but code talks and I'm not offering a patch so I'm not in a position to complain about what Linux currently supports. > Really... if saying our configuration is so screwed up that we have to > run a different over-wire protocol isn't an admission of failure I don't If you use ipip the over-wire protocol is identical, see RFC 3884 section 3.1 or you can test it right now using manual keying (remote side uses tunnel mode, your side uses transport + ipip). To use IKE pluto would need to be hacked a bit, though most of the changes could be handled via a updown script. > know what is. I suspect this contributes to the growth in OpenVPN as well. Haven't you heard, SSL based VPNs are the future :-) -- VGER BF report: U 0.947229 - To unsubscribe from this list: send 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.18-rc5 with GRE, iptables and Speedtouch ADSL, PPP over ATM
Hi,
FYI: Just enabled kernel lock testers on my old laptop machine
doing "internet services". 2.6.18-rc5, i686. All details available
on request, of course.
There is IP GRE tunnel here running over ADSL connection (USB
Thomson/Alcatel Speedtouch 330, PPP over ATM, in-kernel drivers).
Ethernet is DLink Tulip-based (PC Card 32-bit), probably not
relevant here. Iptables doing mostly ACCEPTs, REJECT and DROPs in
INPUT and FORWARD, there is also MASQUERADE but it probably doesn't
matter. Few ip rules directing some traffic to the GRE tunnel as well.
===
[ INFO: possible circular locking dependency detected ]
---
swapper/0 is trying to acquire lock:
(&dev->queue_lock){-+..}, at: [] dev_queue_xmit+0x56/0x290
but task is already holding lock:
(&dev->_xmit_lock){-+..}, at: [] dev_queue_xmit+0x224/0x290
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&dev->_xmit_lock){-+..}:
[] lock_acquire+0x76/0xa0
[] _spin_lock_bh+0x31/0x40
[] dev_activate+0x69/0x120
[] dev_open+0x59/0x70
[] dev_change_flags+0x51/0x110
[] devinet_ioctl+0x484/0x670
[] inet_ioctl+0x6b/0x80
[] sock_ioctl+0x118/0x200
[] do_ioctl+0x20/0x70
[] vfs_ioctl+0x57/0x290
[] sys_ioctl+0x39/0x60
[] sysenter_past_esp+0x56/0x8d
-> #0 (&dev->queue_lock){-+..}:
[] lock_acquire+0x76/0xa0
[] _spin_lock+0x2c/0x40
[] dev_queue_xmit+0x56/0x290
[] ip_output+0x1ad/0x250
[] ipgre_tunnel_xmit+0x412/0x740 [ip_gre]
[] dev_hard_start_xmit+0x1bb/0x220
[] dev_queue_xmit+0x23b/0x290
[] ip_output+0x1ad/0x250
[] reject+0x37c/0x6d0
[] ipt_do_table+0x2b8/0x330
[] ipt_hook+0x27/0x30
[] nf_iterate+0x59/0x80
[] nf_hook_slow+0x4a/0xc0
[] ip_local_deliver+0x175/0x1c0
[] ip_rcv+0x25c/0x480
[] netif_receive_skb+0x15e/0x1e0
[] process_backlog+0x82/0x110
[] net_rx_action+0x72/0x120
[] __do_softirq+0x55/0xc0
[] do_softirq+0x63/0xd0
other info that might help us debug this:
2 locks held by swapper/0:
#0: (&table->lock){-.-+}, at: [] ipt_do_table+0x51/0x330
#1: (&dev->_xmit_lock){-+..}, at: [] dev_queue_xmit+0x224/0x290
stack backtrace:
[] show_trace+0x12/0x20
[] dump_stack+0x19/0x20
[] print_circular_bug_tail+0x61/0x70
[] __lock_acquire+0xac6/0xd70
[] lock_acquire+0x76/0xa0
[] _spin_lock+0x2c/0x40
[] dev_queue_xmit+0x56/0x290
[] ip_output+0x1ad/0x250
[] ipgre_tunnel_xmit+0x412/0x740 [ip_gre]
[] dev_hard_start_xmit+0x1bb/0x220
[] dev_queue_xmit+0x23b/0x290
[] ip_output+0x1ad/0x250
[] reject+0x37c/0x6d0
[] ipt_do_table+0x2b8/0x330
[] ipt_hook+0x27/0x30
[] nf_iterate+0x59/0x80
[] nf_hook_slow+0x4a/0xc0
[] ip_local_deliver+0x175/0x1c0
[] ip_rcv+0x25c/0x480
[] netif_receive_skb+0x15e/0x1e0
[] process_backlog+0x82/0x110
[] net_rx_action+0x72/0x120
[] __do_softirq+0x55/0xc0
[] do_softirq+0x63/0xd0
===
[] irq_exit+0x35/0x40
[] do_IRQ+0x8f/0xf0
[] common_interrupt+0x25/0x2c
[] cpu_idle+0x39/0x50
[] rest_init+0x1e/0x30
[] start_kernel+0x25e/0x2c0
[] 0xc0100199
--
Krzysztof Halasa
--
VGER BF report: U 0.5
-
To unsubscribe from this list: send 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.18-rc5 + pata-drivers on MSI K9N Ultra report, AMD64
Hi, Keywords: nForce PCIe, forcedeth, nForce PATA, Radeon DRM, ALC883 HDA sound FYI: running 2.6.18-rc5 + pata-drivers on MSI mb K9N Ultra (NVidia MCP55, PCIe, Athlon64, x86_64, no SMP, no preempt) gives the following (all details available on request, of course): "Nvidia board detected. Ignoring ACPI timer override." I don't know if it should be ignored or not, anymore. It's probably ok. PCI: Setting latency timer of device :00:0b.0 to 64 pcie_portdrv_probe->Dev[0374:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0b.0:pcie00] PCI: Setting latency timer of device :00:0c.0 to 64 pcie_portdrv_probe->Dev[0374:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0c.0:pcie00] PCI: Setting latency timer of device :00:0d.0 to 64 pcie_portdrv_probe->Dev[0378:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0d.0:pcie00] PCI: Setting latency timer of device :00:0e.0 to 64 pcie_portdrv_probe->Dev[0375:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0e.0:pcie00] PCI: Setting latency timer of device :00:0f.0 to 64 pcie_portdrv_probe->Dev[0377:10de] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[:00:0f.0:pcie00] The above seem to be some PCIe bridges. ata1 and ata2 are SATA. ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xFFA0 irq 14 ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xFFA8 irq 15 There is no secondary IDE connector on this motherboard, I think it's just disabled by BIOS. scsi3 : pata_amd ata4: port is slow to respond, please be patient ata4: port failed to respond (30 secs) ata4: SRST failed (status 0xFF) ata4: SRST failed (err_mask=0x100) ata4: softreset failed, retrying in 5 secs ata4: SRST failed (status 0xFF) ata4: SRST failed (err_mask=0x100) ata4: softreset failed, retrying in 5 secs ata4: SRST failed (status 0xFF) ata4: SRST failed (err_mask=0x100) ata4: reset failed, giving up While not a big problem, the above sequence takes 40 seconds while booting. hda_codec: Unknown model for ALC883, trying auto-probe from BIOS... ALSA device list: #0: HDA NVidia at 0xfeaf4000 irq 233 eth0: forcedeth.c: subsystem: 01462:7250 bound to :00:08.0 eth1: forcedeth.c: subsystem: 01462:7250 bound to :00:09.0 BUG: warning at /usr/src/linux-2.6/kernel/lockdep.c:1803/trace_hardirqs_on() Call Trace: [] trace_hardirqs_on+0xc5/0x150 [] _spin_unlock_irq+0x2b/0x40 [] :forcedeth:nv_nic_irq_tx+0x7e/0x130 [] handle_IRQ_event+0x2c/0x70 [] __do_IRQ+0xc4/0x140 [] do_IRQ+0xfd/0x110 [] ret_from_intr+0x0/0xf [] _spin_unlock_irq+0x2b/0x40 [] _spin_unlock_irq+0x30/0x40 [] do_setitimer+0x159/0x480 [] trace_hardirqs_on_thunk+0x35/0x37 [] alarm_setitimer+0x35/0x60 [] sys_alarm+0x9/0x10 [] cstar_do_call+0x1b/0x6f [drm] Initialized radeon 1.25.0 20060524 on minor 0 [drm:radeon_do_init_cp] *ERROR* Cannot initialise DRM on this card This card requires a new X.org DDX Apparently IA32 emulation doesn't work for radeon_cp_setparam(DRM_IOCTL_ARGS) -> RADEON_SETPARAM_NEW_MEMMAP (32-bit kernel doesn't have this problem). $ /sbin/lspci 00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2) 00:01.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) 00:06.0 PCI bridge: nVidia Corporation Unknown device 0370 (rev a2) 00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) 00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2) 00:0b.0 PCI bridge: nVidia Corporation Unknown device 0374 (rev a2) 00:0c.0 PCI bridge: nVidia Corporation Unknown device 0374 (rev a2) 00:0d.0 PCI bridge: nVidia Corporation Unknown device 0378 (rev a2) 00:0e.0 PCI bridge: nVidia Corporation Unknown device 0375 (rev a2) 00:0f.0 PCI bridge: nVidia Corporation Unknown device 0377 (rev a2) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:02.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08) 01:02.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 08) 06:00.0 VGA compatible controller: ATI Technologies Inc R430 [Radeon X800 XL] (PCIe) 06:00.1 Display controller: ATI Techn
Re: [IPSEC]: searching SAD without assumming L3 details
On Sat, 2 Sep 2006, jamal wrote:
> On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote:
> > On Sat, 2 Sep 2006, jamal wrote:
>
> > +
> > + spin_lock(&xfrm_state_lock);
> >
> > Shouldn't this be spin_lock_bh()?
> >
> > + spin_unlock(&xfrm_state_lock);
> > +
>
> the call is made at the moment only by pktgen (kernel threads on
> dev_queue_xmit level contending with softirqs essentially). I think
> (although havent tried) the spin_{un}lock_bh() wont work. Thoughts?
If bh's are already disabled when you call this, it'll be ok, but as this
will be a generally exported function, I'd suggest using bh locking. I
guess you could also make a xfrm_stateonly_find_bh() to be called only
with bh's disabled, if needed.
- James
--
James Morris
<[EMAIL PROTECTED]>
--
VGER BF report: U 0.523211
-
To unsubscribe from this list: send 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: [IPSEC]: searching SAD without assumming L3 details
On Sat, 2006-02-09 at 13:16 -0400, jamal wrote:
> the call is made at the moment only by pktgen (kernel threads on
> dev_queue_xmit level contending with softirqs essentially). I think
> (although havent tried) the spin_{un}lock_bh() wont work. Thoughts?
> Obviously the easy thing for me to do is change it and see what
> happens;->
Both your suggestions work. Should i instead just use read_{un}lock_bh?
All i am doing is scanning to find the state.
cheers,
jamal
--
VGER BF report: U 0.502731
-
To unsubscribe from this list: send 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: ProxyARP and IPSec
Stephen J. Bevan wrote: H. Peter Anvin writes: > Fair enough. However, that does beg a question: is there any sane way > to create the pseudo-device model on top of the current model, as a > convenience layer? That way you could get the best of both. I assume you were using tunnel-mode IPsec and depending on exactly what you want to do you may be able to replace it with transport mode IPsec (or stay with tunnel if the extra 20 bytes of IP is not a problem) to handle host<->host IPsec and use gre or ipip for overlay network. That way you get a virtual device (gre or ipip) you can route to, run OSPF on, ... etc. What I great idea. Now I just have to get every host I want to interoperate with to support a nonstandard configuration. The scary part is that if I motivate it with "Linux is too stupid to handle standard tunnel-mode IPsec" I might actually get away with it. Really... if saying our configuration is so screwed up that we have to run a different over-wire protocol isn't an admission of failure I don't know what is. I suspect this contributes to the growth in OpenVPN as well. -hpa -- VGER BF report: U 0.53 - To unsubscribe from this list: send 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: [IPSEC]: searching SAD without assumming L3 details
On Sat, 2006-02-09 at 11:04 -0400, James Morris wrote:
> On Sat, 2 Sep 2006, jamal wrote:
> +
> + spin_lock(&xfrm_state_lock);
>
> Shouldn't this be spin_lock_bh()?
>
> + spin_unlock(&xfrm_state_lock);
> +
the call is made at the moment only by pktgen (kernel threads on
dev_queue_xmit level contending with softirqs essentially). I think
(although havent tried) the spin_{un}lock_bh() wont work. Thoughts?
Obviously the easy thing for me to do is change it and see what
happens;->
> + if (rx)
> + xfrm_state_hold(rx);
>
> I think you need to grab the reference before letting go of the lock.
>
I believe you are right. I will make the change, retest and repost.
>
> Can you please include patches inline, or tell me how to get pine to
> quote attachments? :-)
I could get evolution to inline attachments although last time i tried
it made Dave unhappy with not being to use git am or some such
reason ;-> I think some white spaces get added or some other mangling
happens.
I could try it on the repost.
Thanks for the comments James.
cheers,
jamal
--
VGER BF report: U 0.55
-
To unsubscribe from this list: send 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: ProxyARP and IPSec
H. Peter Anvin writes: > Fair enough. However, that does beg a question: is there any sane way > to create the pseudo-device model on top of the current model, as a > convenience layer? That way you could get the best of both. I assume you were using tunnel-mode IPsec and depending on exactly what you want to do you may be able to replace it with transport mode IPsec (or stay with tunnel if the extra 20 bytes of IP is not a problem) to handle host<->host IPsec and use gre or ipip for overlay network. That way you get a virtual device (gre or ipip) you can route to, run OSPF on, ... etc. -- VGER BF report: U 0.498333 - To unsubscribe from this list: send 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: [IPSEC]: searching SAD without assumming L3 details
On Sat, 2 Sep 2006, jamal wrote:
> Against net-2.6.19
>
> signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
+xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
+ unsigned short family, u32 reqid, u8 mode, u8 proto)
+{
+ unsigned int h = xfrm_dst_hash(daddr, saddr, 0, family);
+ struct xfrm_state *rx = NULL, *x = NULL;
+ struct hlist_node *entry;
+
+ spin_lock(&xfrm_state_lock);
Shouldn't this be spin_lock_bh()?
+ spin_unlock(&xfrm_state_lock);
+
+ if (rx)
+ xfrm_state_hold(rx);
I think you need to grab the reference before letting go of the lock.
Can you please include patches inline, or tell me how to get pine to
quote attachments? :-)
--
James Morris
<[EMAIL PROTECTED]>
--
VGER BF report: U 0.5
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[XFRM]: Fix wildcard as tunnel source
[XFRM]: Fix wildcard as tunnel source
Hashing SAs by source address breaks templates with wildcards as tunnel
source. Remove saddr from the hash key.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 19f7b6f33c0e9fbdf23a33506c2dfc0706b0c731
tree bca60eb94c50fcd66673bd87823fd38364b45b55
parent 6ddbd02eb61532f9af4f28912a09717ab8c71d8a
author Patrick McHardy <[EMAIL PROTECTED]> Sat, 02 Sep 2006 16:43:39 +0200
committer Patrick McHardy <[EMAIL PROTECTED]> Sat, 02 Sep 2006 16:43:39 +0200
net/xfrm/xfrm_hash.h |8
net/xfrm/xfrm_state.c | 17 +++--
2 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
index d3abb0b..deb18ce 100644
--- a/net/xfrm/xfrm_hash.h
+++ b/net/xfrm/xfrm_hash.h
@@ -25,17 +25,17 @@ static inline unsigned int __xfrm6_daddr
saddr->a6[2] ^ saddr->a6[3]);
}
-static inline unsigned int __xfrm_dst_hash(xfrm_address_t *daddr,
xfrm_address_t *saddr,
- u32 reqid, unsigned short family,
+static inline unsigned int __xfrm_dst_hash(xfrm_address_t *daddr, u32 reqid,
+ unsigned short family,
unsigned int hmask)
{
unsigned int h = family ^ reqid;
switch (family) {
case AF_INET:
- h ^= __xfrm4_daddr_saddr_hash(daddr, saddr);
+ h ^= __xfrm4_addr_hash(daddr);
break;
case AF_INET6:
- h ^= __xfrm6_daddr_saddr_hash(daddr, saddr);
+ h ^= __xfrm6_addr_hash(daddr);
break;
}
return (h ^ (h >> 16)) & hmask;
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 9f63edd..0c26a1f 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -56,11 +56,10 @@ static unsigned int xfrm_state_num;
static unsigned int xfrm_state_genid;
static inline unsigned int xfrm_dst_hash(xfrm_address_t *daddr,
-xfrm_address_t *saddr,
u32 reqid,
unsigned short family)
{
- return __xfrm_dst_hash(daddr, saddr, reqid, family, xfrm_state_hmask);
+ return __xfrm_dst_hash(daddr, reqid, family, xfrm_state_hmask);
}
static inline unsigned int xfrm_src_hash(xfrm_address_t *addr,
@@ -87,9 +86,8 @@ static void xfrm_hash_transfer(struct hl
hlist_for_each_entry_safe(x, entry, tmp, list, bydst) {
unsigned int h;
- h = __xfrm_dst_hash(&x->id.daddr, &x->props.saddr,
- x->props.reqid, x->props.family,
- nhashmask);
+ h = __xfrm_dst_hash(&x->id.daddr, x->props.reqid,
+ x->props.family, nhashmask);
hlist_add_head(&x->bydst, ndsttable+h);
h = __xfrm_src_hash(&x->props.saddr, x->props.family,
@@ -506,7 +504,7 @@ xfrm_state_find(xfrm_address_t *daddr, x
struct xfrm_policy *pol, int *err,
unsigned short family)
{
- unsigned int h = xfrm_dst_hash(daddr, saddr, tmpl->reqid, family);
+ unsigned int h = xfrm_dst_hash(daddr, tmpl->reqid, family);
struct hlist_node *entry;
struct xfrm_state *x, *x0;
int acquire_in_progress = 0;
@@ -615,8 +613,7 @@ static void __xfrm_state_insert(struct x
x->genid = ++xfrm_state_genid;
- h = xfrm_dst_hash(&x->id.daddr, &x->props.saddr,
- x->props.reqid, x->props.family);
+ h = xfrm_dst_hash(&x->id.daddr, x->props.reqid, x->props.family);
hlist_add_head(&x->bydst, xfrm_state_bydst+h);
h = xfrm_src_hash(&x->props.saddr, x->props.family);
@@ -652,7 +649,7 @@ static void __xfrm_state_bump_genids(str
struct hlist_node *entry;
unsigned int h;
- h = xfrm_dst_hash(&xnew->id.daddr, &xnew->props.saddr, reqid, family);
+ h = xfrm_dst_hash(&xnew->id.daddr, reqid, family);
hlist_for_each_entry(x, entry, xfrm_state_bydst+h, bydst) {
if (x->props.family == family &&
x->props.reqid == reqid &&
@@ -674,7 +671,7 @@ EXPORT_SYMBOL(xfrm_state_insert);
/* xfrm_state_lock is held */
static struct xfrm_state *__find_acq_core(unsigned short family, u8 mode, u32
reqid, u8 proto, xfrm_address_t *daddr, xfrm_address_t *saddr, int create)
{
- unsigned int h = xfrm_dst_hash(daddr, saddr, reqid, family);
+ unsigned int h = xfrm_dst_hash(daddr, reqid, family);
struct hlist_node *entry;
struct xfrm_state *x;
e1000 Detected Tx Unit Hang
I am getting "e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang" using stock 2.6.17.11, 2.6.17.5 or 2.6.17.4 kernels on centos 4.3. The server is a Tyan GS12 ( 82541GI/PI and 82547GI) and is connected to a Netgear GS724T Gig switch. I can easily reproduce the problem by trying to do a large ftp transfer to the server. It does not happen if the server is connected to a dummy 100 Mb switch, only when is connected to the Gig switch. I have also tried the options line below disabling tso, tx and rx in the modprobe.conf without any luck. options e1000 XsumRX=0 Speed=1000 Duplex=2 InterruptThrottleRate=0 FlowControl=3 RxDescriptors=4096 TxDescriptors=4096 RxIntDelay=0 TxIntDelay=0 in /var/log/kernel I get the following... Sep 1 23:53:01 www kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Sep 1 23:53:01 www kernel: Tx Queue <0> Sep 1 23:53:01 www kernel: TDH <4c4> Sep 1 23:53:01 www kernel: TDT <4c9> Sep 1 23:53:01 www kernel: next_to_use <4c9> Sep 1 23:53:01 www kernel: next_to_clean<4c4> Sep 1 23:53:01 www kernel: buffer_info[next_to_clean] Sep 1 23:53:01 www kernel: time_stamp Sep 1 23:53:01 www kernel: next_to_watch<4c4> Sep 1 23:53:01 www kernel: jiffies Sep 1 23:53:01 www kernel: next_to_watch.status <0> . repeats the same as above a few times . Sep 1 23:53:10 www kernel: NETDEV WATCHDOG: eth0: transmit timed out Sep 1 23:53:13 www kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex then the server locks up, no response from the keyboard at all and must be forced down with a power kill. The suggested tips on how to deal with this issue are not working so if I can help troubleshoot this let me know. Here is my system info, driver: e1000 version: 7.0.33-k2-NAPI firmware-version: N/A bus-info: :02:01.0 lspci -vv output below.. 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02) Subsystem: Intel Corporation 82875P/E7210 Memory Controller Hub Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0 Region 0: Memory at 9000 (32-bit, prefetchable) [size=128M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 3.0 Status: RQ=32 Iso- ArqSz=2 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4 Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate= 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev 02) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Secondary status: 66Mhz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- 00:03.0 PCI bridge: Intel Corporation 82875P/E7210 Processor to PCI to CSA Bridge (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Latency: 32 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 2000-2fff Memory behind bridge: fc10-fc1f Secondary status: 66Mhz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- 00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation: Unknown device 24c0 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 Interrupt: pin A routed to IRQ 18 Region 4: I/O ports at 1400 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation: Unknown device 24c0 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 Interrupt: pin B routed to IRQ 19 Region 4: I/O ports at 1420 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI]) Subsystem: Intel Corporation: Unknown device 24c0 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
[IPSEC]: searching SAD without assumming L3 details
Against net-2.6.19
signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
cheers,
jamal
Allow for searching the SAD from external data path points without
assumming L3 details. The only customer of this exposure currently
is pktgen.
---
commit 33d3060784e6aa55e30ae7d5efc491180e7f955d
tree 707017ff673d1161f46d69fd818035b6bc50bbdb
parent 0169ac1c2a64f04deeff3dae704f34e22ae59cb7
author Jamal Hadi Salim <[EMAIL PROTECTED]> Sat, 02 Sep 2006 09:38:12 -0400
committer Jamal Hadi Salim <[EMAIL PROTECTED](none)> Sat, 02 Sep 2006 09:38:12
-0400
include/net/xfrm.h|4
net/xfrm/xfrm_state.c | 33 +
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index bf8e2df..7b0ea47 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -895,6 +895,10 @@ extern struct xfrm_state *xfrm_state_fin
struct flowi *fl, struct xfrm_tmpl
*tmpl,
struct xfrm_policy *pol, int *err,
unsigned short family);
+extern struct xfrm_state * xfrm_stateonly_find(xfrm_address_t *daddr,
+xfrm_address_t *saddr,
+unsigned short family,
+u32 reqid, u8 mode, u8 proto);
extern int xfrm_state_check_expire(struct xfrm_state *x);
extern void xfrm_state_insert(struct xfrm_state *x);
extern int xfrm_state_add(struct xfrm_state *x);
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 9f63edd..2bfc04e 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -501,6 +501,39 @@ __xfrm_state_locate(struct xfrm_state *x
}
struct xfrm_state *
+xfrm_stateonly_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
+ unsigned short family, u32 reqid, u8 mode, u8 proto)
+{
+ unsigned int h = xfrm_dst_hash(daddr, saddr, 0, family);
+ struct xfrm_state *rx = NULL, *x = NULL;
+ struct hlist_node *entry;
+
+ spin_lock(&xfrm_state_lock);
+ hlist_for_each_entry(x, entry, xfrm_state_bydst+h, bydst) {
+ if (x->props.family == family &&
+ x->props.reqid == reqid &&
+ xfrm_state_addr_check(x, daddr, saddr, family) &&
+ mode == x->props.mode &&
+ proto == x->id.proto) {
+
+ if (x->km.state != XFRM_STATE_VALID)
+ continue;
+ else {
+ rx = x;
+ break;
+ }
+ }
+ }
+ spin_unlock(&xfrm_state_lock);
+
+ if (rx)
+ xfrm_state_hold(rx);
+
+ return rx;
+}
+EXPORT_SYMBOL(xfrm_stateonly_find);
+
+struct xfrm_state *
xfrm_state_find(xfrm_address_t *daddr, xfrm_address_t *saddr,
struct flowi *fl, struct xfrm_tmpl *tmpl,
struct xfrm_policy *pol, int *err,
Re: [PATCH] change netfilter tunables to __read_mostly
Brian Haley wrote: > Sorry, next time I'll send them to you, or > [EMAIL PROTECTED] netfilter-devel is better, that way other people working on netfilter get a chance to see it as well. I think only a handful of people on netfilter-devel also follow netdev. > I'll cook-up another patch for the > others you mentioned and send it out. Thanks. -- VGER BF report: H 1.86495e-12 - To unsubscribe from this list: send 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 UDP Implementation
> It seems that the implementation (at code level) does not match with the > actual behaviour. I would like to seek expertise on clarifying my > understanding in UDP implementation so that this phenomenon can be > explained. How about you just add some printks or use a tool like systemtap to instrument the code path? That should give some insights what is actually going on. -Andi -- VGER BF report: U 0.473534 - To unsubscribe from this list: send 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: TCP send/ack lockstep problem
Hi, found it. This is the tcpdump, for your edification. Note that many packets have "push" set for no good reason, which generally indicates dropped packets if we're doing a bulk transfer. But all packets that are visible in the dump reached their destination..! The culprit turns out to be the traffic shaper, which had a subtly-broken configuration and thus shaped that particular traffic with a scythe instead of a razor. A way to attach tcpdump so that those dropped packets get reported (with an appropriate indication) would probably be helpful. Anyway, this is not a packet that was dropped on the wire. So why set the Push flag? TCP *knows* it couldn' send the thing. 09:16:40.652962 IP (tos 0x0, ttl 53, id 16206, offset 0, flags [DF], proto: TCP (6), length: 60) 62.193.238.120.58818 > 192.109.102.42.3306: S, cksum 0x4ef3 (correct), 692009621:692009621(0) win 5840 09:16:40.653030 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 192.109.102.42.3306 > 62.193.238.120.58818: S, cksum 0xf277 (correct), 3232139371:3232139371(0) ack 692009622 win 5696 09:16:40.705214 IP (tos 0x0, ttl 53, id 16207, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.58818 > 192.109.102.42.3306: ., cksum 0x302f (correct), 1:1(0) ack 1 win 1460 09:16:40.716501 IP (tos 0x38, ttl 64, id 32802, offset 0, flags [DF], proto: TCP (6), length: 127) 192.109.102.42.3306 > 62.193.238.120.58818: P 1:76(75) ack 1 win 1424 09:16:40.754853 IP (tos 0x0, ttl 53, id 16208, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.58818 > 192.109.102.42.3306: ., cksum 0x2fac (correct), 1:1(0) ack 76 win 1460 09:16:40.758899 IP (tos 0x0, ttl 53, id 16209, offset 0, flags [DF], proto: TCP (6), length: 116) 62.193.238.120.58818 > 192.109.102.42.3306: P 1:65(64) ack 76 win 1460 09:16:40.759877 IP (tos 0x34, ttl 64, id 32803, offset 0, flags [DF], proto: TCP (6), length: 52) 192.109.102.42.3306 > 62.193.238.120.58818: ., cksum 0x2f88 (correct), 76:76(0) ack 65 win 1424 09:16:40.768414 IP (tos 0x34, ttl 64, id 32804, offset 0, flags [DF], proto: TCP (6), length: 63) 192.109.102.42.3306 > 62.193.238.120.58818: P, cksum 0x2870 (correct), 76:87(11) ack 65 win 1424 09:16:40.805883 IP (tos 0x0, ttl 53, id 16210, offset 0, flags [DF], proto: TCP (6), length: 73) 62.193.238.120.58818 > 192.109.102.42.3306: P, cksum 0xd2f7 (correct), 65:86(21) ack 87 win 1460 09:16:40.808077 IP (tos 0x38, ttl 64, id 32805, offset 0, flags [DF], proto: TCP (6), length: 140) 192.109.102.42.3306 > 62.193.238.120.58818: P 87:175(88) ack 86 win 1424 09:16:40.847493 IP (tos 0x0, ttl 53, id 16211, offset 0, flags [DF], proto: TCP (6), length: 83) 62.193.238.120.58818 > 192.109.102.42.3306: P 86:117(31) ack 175 win 1460 09:16:40.855500 IP (tos 0x38, ttl 64, id 32806, offset 0, flags [DF], proto: TCP (6), length: 124) 192.109.102.42.3306 > 62.193.238.120.58818: P 175:247(72) ack 117 win 1424 09:16:40.855701 IP (tos 0x34, ttl 64, id 32807, offset 0, flags [DF], proto: TCP (6), length: 52) 192.109.102.42.3306 > 62.193.238.120.58818: F, cksum 0x2e46 (correct), 247:247(0) ack 117 win 1424 09:16:40.896780 IP (tos 0x0, ttl 53, id 16212, offset 0, flags [DF], proto: TCP (6), length: 57) 62.193.238.120.58818 > 192.109.102.42.3306: P, cksum 0x2be4 (correct), 117:122(5) ack 247 win 1460 09:16:40.896811 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 192.109.102.42.3306 > 62.193.238.120.58818: R, cksum 0x1f59 (correct), 3232139618:3232139618(0) win 0 09:16:40.897032 IP (tos 0x0, ttl 53, id 16213, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.58818 > 192.109.102.42.3306: F, cksum 0x2deb (correct), 122:122(0) ack 247 win 1460 09:16:40.897058 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 192.109.102.42.3306 > 62.193.238.120.58818: R, cksum 0x1f59 (correct), 3232139618:3232139618(0) win 0 09:16:40.898497 IP (tos 0x0, ttl 53, id 16214, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.58818 > 192.109.102.42.3306: ., cksum 0x2de8 (correct), 123:123(0) ack 248 win 1460 09:16:40.898517 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 192.109.102.42.3306 > 62.193.238.120.58818: R, cksum 0x1f58 (correct), 3232139619:3232139619(0) win 0 09:16:48.515549 IP (tos 0x0, ttl 53, id 35709, offset 0, flags [DF], proto: TCP (6), length: 60) 62.193.238.120.58819 > 192.109.102.42.3306: S, cksum 0xbb47 (correct), 685289454:685289454(0) win 5840 09:16:48.515601 IP (tos 0x34, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 192.109.102.42.3306 > 62.193.238.120.58819: S, cksum 0x824a (correct), 3248316644:3248316644(0) ack 685289455 win 5696 09:16:48.551765 IP (tos 0x0, ttl 53, id 35710, offset 0, flags [DF], proto: TCP (6), length: 52) 62.193.238.120.58819 > 192.109.102.42.3306: ., cksum 0xc011 (correct), 1:1(0) ack 1 win 1460 09:16:48.555452 IP (to
Re: [PATCH] tcp: turn ABC off
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 01, 2006 at 01:55:15PM -0700, Stephen Hemminger ([EMAIL
> PROTECTED]) wrote:
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 111ff39..159fa3f 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -89,7 +89,7 @@ int sysctl_tcp_frto;
>> int sysctl_tcp_nometrics_save;
>>
>> int sysctl_tcp_moderate_rcvbuf = 1;
>> -int sysctl_tcp_abc = 1;
>> +int sysctl_tcp_abc;
>
> Since it is not static are you sure it will be zero?
Outside a function the static modifier merely modifies whether the
symbol is visible externally. It does not control whether it gets
zeroed. And yes this will get zeroed.
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
--
VGER BF report: U 0.49998
-
To unsubscribe from this list: send 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] tcp: turn ABC off
On Fri, Sep 01, 2006 at 01:55:15PM -0700, Stephen Hemminger ([EMAIL PROTECTED]) wrote: > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index 111ff39..159fa3f 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -89,7 +89,7 @@ int sysctl_tcp_frto; > int sysctl_tcp_nometrics_save; > > int sysctl_tcp_moderate_rcvbuf = 1; > -int sysctl_tcp_abc = 1; > +int sysctl_tcp_abc; Since it is not static are you sure it will be zero? -- Evgeniy Polyakov -- VGER BF report: H 8.21099e-10 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
