Re: reminder, 2.6.18 window...
Phil Dibowitz wrote: As for the clearing, in this case, the clearing is done by a command to the hardware - and I believe the hardware does that atomically. However, I could certainly add a spinlock around it if someone sees a need. No, because then you'd also have to add the spin-lock in the hot path to keep rx/tx threads from accessing counters at the same time. There is no way a patch that hurts performance like this will be accepted, but I'm still hopeful that a patch with zero or very near zero performance impact will be accepted. Ben -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
On Wed, 24 May 2006, Jeff Garzik wrote: Brent Cook wrote: Note that this is just clearing the hardware statistics on the interface, and would not require any kind of atomic_increment addition for interfaces that support that. It would be kind-of awkward to implement this on drivers that increment stats in hardware though (lo, vlan, br, etc.) This also brings up the question of resetting the stats for 'netstat -s' If you don't atomically clear the statistics, then you are leaving open a window where the stats could easily be corrupted, if the network interface is under load. This 'clearing' operation has implications on the rest of the statistics usage. More complexity, and breaking of apps, when we could just use the existing, working system? I'll take the do nothing, break nothing, everything still works route any day. I'll admit to not knowing all the intricacies of the kernel coding involved, but I don't offhand see how zeroing the stats would be significantly more complex than updating the stats during normal usage. But I'll have to leave that argument to the experts. To me the main argument is that such a stat zeroing feature would be extremely useful. When trying to track down nasty networking problems that traverse a multitude of devices, it is often highly desirable to zero the interface statistics on all the interfaces in the path (which is available on all networking switches and routers I have worked with), run some kind of stress test across the path, and then examine the packet and error counters on all the involved interfaces. This makes it easy to pinpoint where packets are getting lost or errors are being introduced, especially when there are scores of stats per device and you may not even know a priori exactly what you are looking for. Using such a scheme, the human mind can quickly discern patterns in the data and focus in on any likely problem areas. The human mind (at least speaking for myself) is not nearly as adept when having to deal with deltas. Yes, you can record the initial state of all the devices, run the stress test, record the new state of all the devices, and then spend a large amount of time devising a script to calculate all the deltas for all the scores of variables on all the involved devices, and then finally try and figure out what is wrong. But it would be so much better, easier, and more efficient, if the kernel simply provided such a feature that almost all other networking devices provide. I also think the SNMP/mgt apps argument is specious. A) SNMP isn't even an issue with all networks. B) As has been pointed out by others, there is no requirement to have to use such a new stats zeroing feature. It would simply be a tool in the network engineer's toolbelt, just like possibly taking an interface down and back up to see if it corrects a problem. The network engineer has to balance the potential benefit/harm of any action he chooses to take, but let him have that choice. And C) I don't think any decent SNMP/mgt app will be particularly bothered by zeroing interface stats. I believe they are fairly decent about dealing with such events (I don't recall our MRTG graphs getting any giant spikes when I've zeroed interface stats on our GigE/10-GigE switches). I think the main harm in such a case would be the loss of a sampling interval. -Bill - 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: reminder, 2.6.18 window...
On Wed, 24 May 2006, Phil Dibowitz wrote: Right. I think the point here is that it does _NOT_ inherently break things. If you don't like the behavior, don't run ethtool -z eth0, it's that simple. A co-worker suggested today, that maybe it'd appease people if the final ethtool patch made it a capitol option that you can only run by itself. I.e. if you can't call it with anything else, it's more difficult to call my accident. I'd be willing to this. I think that's a good idea. Since it is changing (zeroing) the stats, it probably should be a capitol option. -Bill - 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/4] myri10ge - Driver core
On Wed, 2006-05-24 at 01:39 +1000, Anton Blanchard wrote: +#ifdef CONFIG_MTRR + mgp-mtrr = mtrr_add(mgp-iomem_base, mgp-board_span, +MTRR_TYPE_WRCOMB, 1); +#endif ... + mgp-sram = ioremap(mgp-iomem_base, mgp-board_span); Not sure how we are meant to specify write through in drivers. Any ideas Ben? No proper interface exposed, he'll have to do an #ifdef powerpc here or such and use __ioremap with explicit page attributes. I have a hack to do that automatically for memory covered by prefetchable PCI BARs when mmap'ing from userland but not for kernel ioremap. Ben. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] myri10ge - Driver core
On Wed, 2006-05-24 at 10:04 +0200, Brice Goglin wrote: I am not sure what you mean. The only ppc64 with PCI-E that we have seen so far (a G5) couldn't do write combining according to Apple. That is not 100% true I don't know what apple had in mind. It also depends in what slot you are. Do you have ways to measure the difference ? Try doing __ioremap(mgp-iomem_base, mgp-board_span, _PAGE_NO_CACHE); instead of using the normal ioremap for #ifdef powerpc and tell us if it makes a difference. Ben. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] TCP Veno module for kernel 2.6.16.13
Yes, I agree. Actually the main contribution of TCP Veno is not in this AI
phase. No matter the ABC is added or not, TCP Veno can always improve the
performance over wireless networks, according to our tests.
Best Regards,
Zhou Bin
-Original Message-
From: Stephen Hemminger [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 25, 2006 12:47 AM
To: Baruch Even
Cc: #ZHOU BIN#; [EMAIL PROTECTED]; netdev@vger.kernel.org
Subject: Re: [PATCH] TCP Veno module for kernel 2.6.16.13
On Wed, 24 May 2006 17:16:52 +0100
Baruch Even [EMAIL PROTECTED] wrote:
#ZHOU BIN# wrote:
From: Bin Zhou [EMAIL PROTECTED]
+ else if (sysctl_tcp_abc) {
+ /* RFC3465: Apppriate Byte Count
+ * increase once for each full cwnd acked.
+ * Veno has no idear about it so far, so we keep
+ * it as Reno.
+ */
+ if (tp-bytes_acked = tp-snd_cwnd*tp-mss_cache) {
+ tp-bytes_acked -= tp-snd_cwnd*tp-mss_cache;
+ if (tp-snd_cwnd tp-snd_cwnd_clamp)
+ tp-snd_cwnd++;
+ }
You should prefer to ignore abc instead. At least that's what everyone
else is doing, the only place where abc is active is in NewReno.
Baruch
That was intentional. When ABC was added, the desire was to not change existing
behavior for other congestion control methods.
-
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
MIB ipInHdrErrors error
Hi All:
When I test linux kernel 2.6.9-34, and find that kernel statistics
about ipInHdrErrors which exsits in file /proc/net/snmp doesn't increase
correctly. The criteria conform to RFC2011:
ipInHdrErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
The number of input datagrams discarded due to errors in
their IP headers, including bad checksums, version number
mismatch, other format errors, time-to-live exceeded, errors
discovered in processing their IP options, etc.
When kernel receives an IP packet containing error protocol in IP
header, kernel doesn't increase this counter ipInHdrErrors. Also, when
kernel receives an IP packet and need to forward, but TTL=1 or TTL=0,
kernel just sends an ICMP packet to inform the sender TTL count
exceeded, and doesn't increase this counter.
The patch for this problem is shown as the following:
diff -ruN old/net/ipv4/ip_forward.c new/net/ipv4/ip_forward.c
--- old/net/ipv4/ip_forward.c 2006-05-10 10:43:30.0 +0800
+++ new/net/ipv4/ip_forward.c 2006-05-12 15:06:57.0 +0800
@@ -120,6 +120,7 @@
too_many_hops:
/* Tell the sender its packet died... */
+IP_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS);
icmp_send(skb, ICMP_TIME_EXCEEDED, ICMP_EXC_TTL, 0);
drop:
kfree_skb(skb);
diff -ruN old/net/ipv4/ip_input.c new/net/ipv4/ip_input.c
--- old/net/ipv4/ip_input.c 2006-05-10 10:43:31.0 +0800
+++ new/net/ipv4/ip_input.c 2006-05-12 15:07:27.0 +0800
@@ -249,6 +249,7 @@
if (!raw_sk) {
if (xfrm4_policy_check(NULL,
XFRM_POLICY_IN, skb)) {
IP_INC_STATS_BH(IPSTATS_MIB_INUNKNOWNPROTOS);
+
IP_INC_STATS_BH(IPSTATS_MIB_INHDRERRORS);
icmp_send(skb,
ICMP_DEST_UNREACH,
ICMP_PROT_UNREACH, 0);
}
Signed-off-by: Wei Dong [EMAIL PROTECTED]
Regards
Wei Dong
-
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/4] myri10ge - Driver core
Benjamin Herrenschmidt wrote: On Wed, 2006-05-24 at 10:04 +0200, Brice Goglin wrote: I am not sure what you mean. The only ppc64 with PCI-E that we have seen so far (a G5) couldn't do write combining according to Apple. That is not 100% true I don't know what apple had in mind. It also depends in what slot you are. Do you have ways to measure the difference ? No, we don't have any PPC with PCIe running Linux. The only G5 PCIe that we have is running MacOSX. Try doing __ioremap(mgp-iomem_base, mgp-board_span, _PAGE_NO_CACHE); instead of using the normal ioremap for #ifdef powerpc and tell us if it makes a difference. I'll try it as soon as we get our G5 PCIe to run Linux. thanks, Brice - 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: sky2 hw csum failure [was Re: sky2 large MTU problems]
Hi Stephen, Thanks for your feedback. On 24/05/06, Stephen Hemminger [EMAIL PROTECTED] wrote: Daniel J Blueman [EMAIL PROTECTED] wrote: Having done some more stress testing with sky2 1.4 (in 2.6.17-rc4) and the latest patch, I have found problems when streaming lots of data out of the sky2 interface (eg via samba serving a large file to GigE client). Ultimately, the interface will stop sending. Before this happens, I see lots of: kernel: lan0: hw csum failure. kernel: [__skb_checksum_complete+86/96] __skb_checksum_complete+0x56/0x60 kernel: [tcp_error+300/512] tcp_error+0x12c/0x200 kernel: [poison_obj+41/96] poison_obj+0x29/0x60 kernel: [tcp_error+0/512] tcp_error+0x0/0x200 kernel: [ip_conntrack_in+157/1072] ip_conntrack_in+0x9d/0x430 kernel: [kfree_skbmem+8/128] kfree_skbmem+0x8/0x80 kernel: [arp_process+102/1408] arp_process+0x66/0x580 kernel: [check_poison_obj+36/416] check_poison_obj+0x24/0x1a0 kernel: [arp_process+102/1408] arp_process+0x66/0x580 kernel: [nf_iterate+99/144] nf_iterate+0x63/0x90 kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 kernel: [nf_hook_slow+89/240] nf_hook_slow+0x59/0xf0 kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 kernel: [ip_rcv+386/1104] ip_rcv+0x182/0x450 kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 kernel: [packet_rcv_spkt+216/320] packet_rcv_spkt+0xd8/0x140 kernel: [netif_receive_skb+476/784] netif_receive_skb+0x1dc/0x310 kernel: [sky2_poll+879/2096] sky2_poll+0x36f/0x830 kernel: [_spin_lock_irqsave+9/16] _spin_lock_irqsave+0x9/0x10 kernel: [run_timer_softirq+290/416] run_timer_softirq+0x122/0x1a0 kernel: [net_rx_action+108/256] net_rx_action+0x6c/0x100 kernel: [__do_softirq+66/160] __do_softirq+0x42/0xa0 kernel: [do_softirq+78/96] do_softirq+0x4e/0x60 kernel: === kernel: [do_IRQ+90/160] do_IRQ+0x5a/0xa0 kernel: [remove_vma+69/80] remove_vma+0x45/0x50 kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20 kernel: [get_offset_pmtmr+151/3584] get_offset_pmtmr+0x97/0xe00 kernel: [do_gettimeofday+26/208] do_gettimeofday+0x1a/0xd0 kernel: [sys_gettimeofday+26/144] sys_gettimeofday+0x1a/0x90 kernel: [syscall_call+7/11] syscall_call+0x7/0xb What ever the netfilter chain is, it is trimming or altering the packet without clearing or altering the hardware checksum. It is not a driver problem, we saw these in VLAN's and ebtables already. No ebtables or VLAN used; the relevant part of iptables I have: iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t filter -A INPUT -p tcp -m tcp --dport 445 --syn -j ACCEPT # SMB iptables -t filter -A INPUT -j DROP This may be linked to the use of the large MTU (7500 or 9000) for the sky2 linux box and the client was transmitting back to the sky2 with an MTU of 1500. One of these was preceeded by: kernel: sky2 lan0: rx error, status 0x977d977d length 0 The receive FIFO got overrun. You must not be running hardware flow control. This 'status 0x977d977d' message is received before the above problem occurs and I couldn't reproduce the 'hw csum failure' last night. The client is a Broadcom NetExtreme PCI-E card purportedly with flow control on. I have got the reproducer down to: 1. use 2.6.17-rc4 w/ sky2 MTU patch 2. increase MTU to = 7500 3. decrease MTU to 1500 4. send ~1-2GB out of sky2 NIC 5. rx error, status 0x977d977d length 0 messages received I have found that without raising the MTU initially to 7500/9000, this problem does not occur. Perhaps chip tx buffers aren't shrunk when the MTU is dropped? Is there a tunable low-watermark for starting the DMA transfer from the chip on rx? The client isn't sending back that much (TCP acks every segment, SMB protocol acks every 64KB), but I guess there are fewer rx buffers are available, as larger tx buffers are used on the sky2 chip for the large tx packets. This was happening with the default MTU of 1500, not just at MTU size 9000 (but it was changed down from 9000). Hardware is Yukon-EC (0xb6) rev 1. I'll do some more stress testing tonight without the MTU patch and without the MTU being raised to 9000 initially and see what happens. Thanks for all your great work so far! Let me know if this is a scenario that isn't expected to work, or if there is anything else I can look at or try. Thanks again! -- Daniel J Blueman - 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: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
Hi Pavel (I've removed linux-kernel from CC, this is only network related and added Herman to the CC, since he's not subscribed) Pavel Machek wrote: Hi! FLAME stands for Forwarding Layer for Meshing FLAME provides an intermediate layer between the network layer (e.g. IPv4/IPv6) and the link (MAC) layer, providing L2.5 meshing. Both network layer and MAC layer What is wrong with meshing on L3? Well, I think mostly that L3 meshing is not quite ready to be usable, especially if you want to mix IPv4 and IPv6 stacks in the same network (dual-stack). L3 meshing is better for mixing multiple different link layers, but you still need to solve address assignment problems and routing, which can become quite complicated at L3. In our case, we use dual-stack in a hopping network behind a mobile router (which delegates a mobile network prefix, NEMO: rfc 3963). In a short-range hopping network (e.g. a PAN) using 802.xxx type network interfaces, FLAME is much faster and easier to implement than trying to solve it at L3 (twice; dual-stack). We are of course also interested in good L3 solutions, but so far, we haven't come across a good one ;-) (It is called flame so lets at least have nice flamewar :-) Pavel flamewars are highly overrated IMHO ;-) Cheers Simon - 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: reminder, 2.6.18 window...
On Wed, 24 May 2006, Phil Dibowitz wrote: On Wed, May 24, 2006 at 02:23:05PM -0400, Jeff Garzik wrote: I disagree that we should bother about clearing statistics. It always adds more complication than necessary. Few (if any) other statistics in Linux permit easy clearing, often because adding operations other than 'increment' or 'read' requires adding expensive spinlocks or atomic operations. Every networking device in the world supports clearing interface statistics. Why should linux not be able to do the most basic operation on any cisco/juniper/enterasys/whatever managed switch or router? AFAIK, note that clearing interface statistics on such routers doesn't clear SNMP statistics, just the statistics available through CLI. So you really have two levels of statistics, and I suspect clearing slave statistics shouldn't be too difficult to implement. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - 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: sky2 hw csum failure [was Re: sky2 large MTU problems]
Stephen Hemminger wrote: On Wed, 24 May 2006 10:28:52 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: Having done some more stress testing with sky2 1.4 (in 2.6.17-rc4) and the latest patch, I have found problems when streaming lots of data out of the sky2 interface (eg via samba serving a large file to GigE client). Ultimately, the interface will stop sending. Before this happens, I see lots of: kernel: lan0: hw csum failure. kernel: [__skb_checksum_complete+86/96] __skb_checksum_complete+0x56/0x60 kernel: [tcp_error+300/512] tcp_error+0x12c/0x200 kernel: [poison_obj+41/96] poison_obj+0x29/0x60 kernel: [tcp_error+0/512] tcp_error+0x0/0x200 kernel: [ip_conntrack_in+157/1072] ip_conntrack_in+0x9d/0x430 kernel: [kfree_skbmem+8/128] kfree_skbmem+0x8/0x80 kernel: [arp_process+102/1408] arp_process+0x66/0x580 kernel: [check_poison_obj+36/416] check_poison_obj+0x24/0x1a0 kernel: [arp_process+102/1408] arp_process+0x66/0x580 kernel: [nf_iterate+99/144] nf_iterate+0x63/0x90 kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 kernel: [nf_hook_slow+89/240] nf_hook_slow+0x59/0xf0 kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 kernel: [ip_rcv+386/1104] ip_rcv+0x182/0x450 kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 kernel: [packet_rcv_spkt+216/320] packet_rcv_spkt+0xd8/0x140 kernel: [netif_receive_skb+476/784] netif_receive_skb+0x1dc/0x310 kernel: [sky2_poll+879/2096] sky2_poll+0x36f/0x830 kernel: [_spin_lock_irqsave+9/16] _spin_lock_irqsave+0x9/0x10 kernel: [run_timer_softirq+290/416] run_timer_softirq+0x122/0x1a0 kernel: [net_rx_action+108/256] net_rx_action+0x6c/0x100 kernel: [__do_softirq+66/160] __do_softirq+0x42/0xa0 kernel: [do_softirq+78/96] do_softirq+0x4e/0x60 kernel: === kernel: [do_IRQ+90/160] do_IRQ+0x5a/0xa0 kernel: [remove_vma+69/80] remove_vma+0x45/0x50 kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20 kernel: [get_offset_pmtmr+151/3584] get_offset_pmtmr+0x97/0xe00 kernel: [do_gettimeofday+26/208] do_gettimeofday+0x1a/0xd0 kernel: [sys_gettimeofday+26/144] sys_gettimeofday+0x1a/0x90 kernel: [syscall_call+7/11] syscall_call+0x7/0xb What ever the netfilter chain is, it is trimming or altering the packet without clearing or altering the hardware checksum. It is not a driver problem, we saw these in VLAN's and ebtables already. The call chain looks pretty messed up, but the point where an invalid HW checksum is detected is in TCP connection tracking, which is basically the first thing netfilter does, unless you use the raw table. There are no packet modifications done by conntrack, so I doubt that netfilter is the culprit here. Of course we had some big checksumming cleanups, so there is a possibilty of bugs there, but I did test them with sky2 and HW checksumming, so I don't think thats the case. Daniel, is there an easy way to reproduce the checksum failure? - 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 0/9] Resending NetXen 1G/10G NIC driver patch
Hi, I'll be sending a NetXen (formerly Universal Network Machines) 1G/10G in subsequent emails. This is a revised version of the UNM driver posted earlier. We have tried to make changes as per the feedback received. We would like this driver to be inluded in mainline kernel. Kindly review it and feel free to get back to me for any further feedback/queries/comments. Thanks. -Amit Signed-off-by: Amit S. Kale [EMAIL PROTECTED] Kconfig |5 Makefile |1 netxen/Makefile | 35 + netxen/netxen_nic.h | 950 +++ netxen/netxen_nic_ethtool.c | 802 ++ netxen/netxen_nic_hdr.h | 682 ++ netxen/netxen_nic_hw.c | 1289 +++ netxen/netxen_nic_hw.h | 339 +++ netxen/netxen_nic_init.c | 1219 netxen/netxen_nic_ioctl.h| 75 ++ netxen/netxen_nic_isr.c | 428 ++ netxen/netxen_nic_main.c | 1209 netxen/netxen_nic_niu.c | 770 + netxen/netxen_nic_phan_reg.h | 195 ++ 14 files changed, 7999 insertions(+) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/9] Resending NetXen 1G/10G NIC driver patch
diff -Naru linux-2.6.16.18.orig/drivers/net/Kconfig
linux-2.6.16.18/drivers/net/Kconfig
--- linux-2.6.16.18.orig/drivers/net/Kconfig2006-05-24 06:57:55.0
-0700
+++ linux-2.6.16.18/drivers/net/Kconfig 2006-05-24 07:00:29.0 -0700
@@ -2313,6 +2313,11 @@
If in doubt, say N.
+config NETXEN_NIC
+ tristate NetXen Multi port (1/10) Gigabit Ethernet NIC
+ help
+ This enables the support for NetXen's Gigabit Ethernet card.
+
endmenu
if !UML
diff -Naru linux-2.6.16.18.orig/drivers/net/Makefile
linux-2.6.16.18/drivers/net/Makefile
--- linux-2.6.16.18.orig/drivers/net/Makefile 2006-05-24 06:57:55.0
-0700
+++ linux-2.6.16.18/drivers/net/Makefile2006-05-24 07:02:30.0
-0700
@@ -213,3 +213,4 @@
obj-$(CONFIG_FS_ENET) += fs_enet/
+obj-$(CONFIG_NETXEN_NIC) += netxen/
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/Makefile
linux-2.6.16.18/drivers/net/netxen/Makefile
--- linux-2.6.16.18.orig/drivers/net/netxen/Makefile1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/Makefile 2006-05-25 02:43:22.0
-0700
@@ -0,0 +1,35 @@
+# Copyright (C) 2003 - 2006 NetXen, Inc.
+# All rights reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+# MA 02111-1307, USA.
+#
+# The full GNU General Public License is included in this distribution
+# in the file called LICENSE.
+#
+# Contact Information:
+#[EMAIL PROTECTED]
+# NetXen,
+# 3965 Freedom Circle, Fourth floor,
+# Santa Clara, CA 95054
+#
+# Makefile for the NetXen NIC Driver
+#
+
+
+obj-$(CONFIG_NETXEN_NIC) := netxen_nic.o
+
+netxen_nic-y := netxen_nic_hw.o netxen_nic_main.o netxen_nic_init.o \
+ netxen_nic_isr.o netxen_nic_ethtool.o netxen_nic_niu.o
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_ethtool.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_ethtool.c
1969-12-31 16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_ethtool.c 2006-05-25
02:43:22.0 -0700
@@ -0,0 +1,802 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * ethtool support for netxen nic
+ *
+ */
+
+#include linux/types.h
+#include asm/uaccess.h
+#include linux/pci.h
+#include asm/io.h
+#include linux/netdevice.h
+#include linux/ethtool.h
+#include linux/version.h
+
+#include netxen_nic_hw.h
+#include netxen_nic.h
+#include netxen_nic_phan_reg.h
+#include netxen_nic_ioctl.h
+
+struct netxen_nic_stats {
+ char stat_string[ETH_GSTRING_LEN];
+ int sizeof_stat;
+ int stat_offset;
+};
+
+#define NETXEN_NIC_STAT(m) sizeof(((struct netxen_port *)0)-m), \
+offsetof(struct netxen_port, m)
+
+static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
+ {rcvd_bad_skb, NETXEN_NIC_STAT(stats.rcvdbadskb)},
+ {xmit_called, NETXEN_NIC_STAT(stats.xmitcalled)},
+ {xmited_frames, NETXEN_NIC_STAT(stats.xmitedframes)},
+ {xmit_finished, NETXEN_NIC_STAT(stats.xmitfinished)},
+ {bad_skb_len, NETXEN_NIC_STAT(stats.badskblen)},
+ {no_cmd_desc, NETXEN_NIC_STAT(stats.nocmddescriptor)},
+ {polled, NETXEN_NIC_STAT(stats.polled)},
[PATCH 2/9] Resending NetXen 1G/10G NIC driver patch
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h linux-2.6.16.18/drivers/net/netxen/netxen_nic.h --- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h1969-12-31 16:00:00.0 -0800 +++ linux-2.6.16.18/drivers/net/netxen/netxen_nic.h 2006-05-25 02:43:22.0 -0700 @@ -0,0 +1,950 @@ +/* + * Copyright (C) 2003 - 2006 NetXen, Inc. + * All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, + * MA 02111-1307, USA. + * + * The full GNU General Public License is included in this distribution + * in the file called LICENSE. + * + * Contact Information: + *[EMAIL PROTECTED] + * NetXen, + * 3965 Freedom Circle, Fourth floor, + * Santa Clara, CA 95054 + */ + +#ifndef _NETXEN_NIC_H_ +#define _NETXEN_NIC_H_ + +#include linux/config.h +#include linux/module.h +#include linux/kernel.h +#include linux/types.h +#include linux/compiler.h +#include linux/slab.h +#include linux/delay.h +#include linux/init.h +#include linux/ioport.h +#include linux/pci.h +#include linux/netdevice.h +#include linux/etherdevice.h +#include linux/ip.h +#include linux/in.h +#include linux/tcp.h +#include linux/skbuff.h +#include linux/version.h + +#include linux/ethtool.h +#include linux/mii.h +#include linux/interrupt.h +#include linux/timer.h + +#include linux/mm.h +#include linux/mman.h + +#include asm/system.h +#include asm/io.h +#include asm/byteorder.h +#include asm/uaccess.h +#include asm/pgtable.h + +#include linux/skbuff.h + +#include netxen_nic_hw.h +#include netxen_nic_hdr.h + +#define NETXEN_NIC_BUILD_NO 231 +#define _NETXEN_NIC_LINUX_MAJOR 2 +#define _NETXEN_NIC_LINUX_MINOR 1 +#define _NETXEN_NIC_LINUX_SUBVERSION 39 +#define NETXEN_NIC_LINUX_VERSIONID 2.1.39 +#define NETXEN_NIC_FW_VERSIONID 2.1.39 +#define NETXEN_NIC_TIMESTAMP Mon May 1 01:34:07 PDT 2006 + +#define RCV_DESC_RINGSIZE \ + (sizeof(struct rcv_desc_t) * adapter-max_rx_desc_count) +#define STATUS_DESC_RINGSIZE \ + (sizeof(struct status_desc_t)* adapter-max_rx_desc_count) +#define TX_RINGSIZE\ + (sizeof(struct netxen_cmd_buffer) * adapter-max_tx_desc_count) +#define RCV_BUFFSIZE \ + (sizeof(struct netxen_rx_buffer) * rcv_desc-max_rx_desc_count) +#define find_diff_among(a,b,range) ((a)(b)?((b)-(a)):((b)+(range)-(a))) + +#define NETXEN_NETDEV_STATUS 0x1 + +#define ADDR_IN_WINDOW1(off) \ + ((off NETXEN_CRB_PCIX_HOST2) (off NETXEN_CRB_MAX)) ? 1 : 0 + +/* + * normalize a 64MB crb address to 32MB PCI window + * To use NETXEN_CRB_NORMALIZE, window _must_ be set to 1 + */ +#define NETXEN_CRB_NORMALIZE(adapter, reg) \ + (void *)(ptrdiff_t)(adapter-ahw.pci_base+ (reg)\ + - NETXEN_CRB_PCIX_HOST2 + NETXEN_CRB_PCIX_HOST) + +#define IP_ALIGNMENT_BYTES 2 /* make ip aligned on 16 bytes addr */ +#define MAX_RX_BUFFER_LENGTH 2000 +#define MAX_RX_JUMBO_BUFFER_LENGTH 9046 +#define RX_DMA_MAP_LEN (MAX_RX_BUFFER_LENGTH - IP_ALIGNMENT_BYTES) +#define RX_JUMBO_DMA_MAP_LEN \ + (MAX_RX_JUMBO_BUFFER_LENGTH - IP_ALIGNMENT_BYTES) + +/* Opcodes to be used with the commands */ +#defineTX_ETHER_PKT 0x01 +/* The following opcodes are for IP checksum */ +#defineTX_TCP_PKT 0x02 +#defineTX_UDP_PKT 0x03 +#defineTX_IP_PKT 0x04 +#defineTX_TCP_LSO 0x05 +#defineTX_IPSEC0x06 +#defineTX_IPSEC_CMD0x07 + +/* The following opcodes are for internal consumption. */ +#define NETXEN_CONTROL_OP 0x10 +#define PEGNET_REQUEST 0x11 + +#defineMAX_NUM_CARDS 4 + +#define MAX_BUFFERS_PER_CMD32 + +/* + * Following are the states of the Phantom. Phantom will set them and + * Host will read to check if the fields are correct. + */ +#define PHAN_INITIALIZE_START 0xff00 +#define PHAN_INITIALIZE_FAILED 0x +#define PHAN_INITIALIZE_COMPLETE 0xff01 + +/* Host writes the following to notify that it has done the init-handshake */ +#define PHAN_INITIALIZE_ACK0xf00f + +#define NUM_RCV_DESC_RINGS 2 /* No of Rcv Descriptor contexts */ + +/* descriptor types */ +#define RCV_DESC_NORMAL0x01 +#define RCV_DESC_JUMBO 0x02 +#define RCV_DESC_NORMAL_CTXID 0 +#define
[PATCH 3/9] Resending NetXen 1G/10G NIC driver patch
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hdr.h linux-2.6.16.18/drivers/net/netxen/netxen_nic_hdr.h --- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hdr.h1969-12-31 16:00:00.0 -0800 +++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_hdr.h 2006-05-25 02:43:22.0 -0700 @@ -0,0 +1,682 @@ +/* + * Copyright (C) 2003 - 2006 NetXen, Inc. + * All rights reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, + * MA 02111-1307, USA. + * + * The full GNU General Public License is included in this distribution + * in the file called LICENSE. + * + * Contact Information: + *[EMAIL PROTECTED] + * NetXen, + * 3965 Freedom Circle, Fourth floor, + * Santa Clara, CA 95054 + */ + +#ifndef __NETXEN_NIC_HDR_H_ +#define __NETXEN_NIC_HDR_H_ + +#include linux/module.h +#include linux/kernel.h +#include linux/config.h +#include linux/version.h + +#include asm/semaphore.h +#include linux/spinlock.h +#include asm/irq.h +#include linux/init.h +#include linux/errno.h +#include linux/pci.h +#include linux/types.h +#include asm/uaccess.h +#include asm/string.h/* for memset */ + +extern struct netxen_adapter *g_adapter; + +/* + * The basic unit of access when reading/writing control registers. + */ + +typedef u32 netxen_crbword_t; /* single word in CRB space */ + +#define NETXEN_HW_H0_CH_HUB_ADR0x05 +#define NETXEN_HW_H1_CH_HUB_ADR0x0E +#define NETXEN_HW_H2_CH_HUB_ADR0x03 +#define NETXEN_HW_H3_CH_HUB_ADR0x01 +#define NETXEN_HW_H4_CH_HUB_ADR0x06 +#define NETXEN_HW_H5_CH_HUB_ADR0x07 +#define NETXEN_HW_H6_CH_HUB_ADR0x08 + +/* Hub 0 */ +#define NETXEN_HW_MN_CRB_AGT_ADR 0x15 +#define NETXEN_HW_MS_CRB_AGT_ADR 0x25 + +/* Hub 1 */ +#define NETXEN_HW_PS_CRB_AGT_ADR 0x73 +#define NETXEN_HW_SS_CRB_AGT_ADR 0x20 +#define NETXEN_HW_RPMX3_CRB_AGT_ADR0x0b +#define NETXEN_HW_QMS_CRB_AGT_ADR 0x00 +#define NETXEN_HW_SQGS0_CRB_AGT_ADR0x01 +#define NETXEN_HW_SQGS1_CRB_AGT_ADR0x02 +#define NETXEN_HW_SQGS2_CRB_AGT_ADR0x03 +#define NETXEN_HW_SQGS3_CRB_AGT_ADR0x04 +#define NETXEN_HW_C2C0_CRB_AGT_ADR 0x58 +#define NETXEN_HW_C2C1_CRB_AGT_ADR 0x59 +#define NETXEN_HW_C2C2_CRB_AGT_ADR 0x5a +#define NETXEN_HW_RPMX2_CRB_AGT_ADR0x0a +#define NETXEN_HW_RPMX4_CRB_AGT_ADR0x0c +#define NETXEN_HW_RPMX7_CRB_AGT_ADR0x0f +#define NETXEN_HW_RPMX9_CRB_AGT_ADR0x12 +#define NETXEN_HW_SMB_CRB_AGT_ADR 0x18 + +/* Hub 2 */ +#define NETXEN_HW_NIU_CRB_AGT_ADR 0x31 +#define NETXEN_HW_I2C0_CRB_AGT_ADR 0x19 +#define NETXEN_HW_I2C1_CRB_AGT_ADR 0x29 + +#define NETXEN_HW_SN_CRB_AGT_ADR 0x10 +#define NETXEN_HW_I2Q_CRB_AGT_ADR 0x20 +#define NETXEN_HW_LPC_CRB_AGT_ADR 0x22 +#define NETXEN_HW_ROMUSB_CRB_AGT_ADR 0x21 +#define NETXEN_HW_QM_CRB_AGT_ADR 0x66 +#define NETXEN_HW_SQG0_CRB_AGT_ADR 0x60 +#define NETXEN_HW_SQG1_CRB_AGT_ADR 0x61 +#define NETXEN_HW_SQG2_CRB_AGT_ADR 0x62 +#define NETXEN_HW_SQG3_CRB_AGT_ADR 0x63 +#define NETXEN_HW_RPMX1_CRB_AGT_ADR0x09 +#define NETXEN_HW_RPMX5_CRB_AGT_ADR0x0d +#define NETXEN_HW_RPMX6_CRB_AGT_ADR0x0e +#define NETXEN_HW_RPMX8_CRB_AGT_ADR0x11 + +/* Hub 3 */ +#define NETXEN_HW_PH_CRB_AGT_ADR 0x1A +#define NETXEN_HW_SRE_CRB_AGT_ADR 0x50 +#define NETXEN_HW_EG_CRB_AGT_ADR 0x51 +#define NETXEN_HW_RPMX0_CRB_AGT_ADR0x08 + +/* Hub 4 */ +#define NETXEN_HW_PEGN0_CRB_AGT_ADR0x40 +#define NETXEN_HW_PEGN1_CRB_AGT_ADR0x41 +#define NETXEN_HW_PEGN2_CRB_AGT_ADR0x42 +#define NETXEN_HW_PEGN3_CRB_AGT_ADR0x43 +#define NETXEN_HW_PEGNI_CRB_AGT_ADR0x44 +#define NETXEN_HW_PEGND_CRB_AGT_ADR0x45 +#define NETXEN_HW_PEGNC_CRB_AGT_ADR0x46 +#define NETXEN_HW_PEGR0_CRB_AGT_ADR0x47 +#define NETXEN_HW_PEGR1_CRB_AGT_ADR0x48 +#define NETXEN_HW_PEGR2_CRB_AGT_ADR0x49 +#define NETXEN_HW_PEGR3_CRB_AGT_ADR0x4a + +/* Hub 5 */ +#define NETXEN_HW_PEGS0_CRB_AGT_ADR0x40 +#define NETXEN_HW_PEGS1_CRB_AGT_ADR0x41 +#define NETXEN_HW_PEGS2_CRB_AGT_ADR0x42 +#define NETXEN_HW_PEGS3_CRB_AGT_ADR0x43 +#define NETXEN_HW_PEGSI_CRB_AGT_ADR0x44 +#define NETXEN_HW_PEGSD_CRB_AGT_ADR0x45 +#define NETXEN_HW_PEGSC_CRB_AGT_ADR0x46 + +/* Hub 6
[PATCH 4/9] Resending NetXen 1G/10G NIC driver patch
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.c 2006-05-25
02:43:22.0 -0700
@@ -0,0 +1,1289 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * Source file for NIC routines to access the Phantom hardware
+ *
+ */
+
+#include linux/delay.h
+#include linux/netdevice.h
+#include linux/ethtool.h
+#include linux/version.h
+#include netxen_nic.h
+#include netxen_nic_hw.h
+#include netxen_nic_phan_reg.h
+
+/* PCI Windowing for DDR regions. */
+
+#define ADDR_IN_RANGE(addr, low, high) \
+ (((addr) = (high)) ((addr) = (low)))
+
+static unsigned long netxen_nic_pci_set_window(unsigned long long pci_base,
+ unsigned long long addr);
+void netxen_free_hw_resources(struct netxen_adapter *adapter);
+
+int netxen_nic_set_mac(struct net_device *netdev, void *p)
+{
+ struct netxen_port *port = netdev_priv(netdev);
+ struct sockaddr *addr = p;
+
+ if (netif_running(netdev))
+ return -EBUSY;
+
+ if (!is_valid_ether_addr(addr-sa_data))
+ return -EADDRNOTAVAIL;
+
+ DPRINTK(INFO, valid ether addr\n);
+ memcpy(netdev-dev_addr, addr-sa_data, netdev-addr_len);
+ memcpy(port-hw.mac_addr, addr-sa_data, netdev-addr_len);
+
+ netxen_nic_macaddr_set(port, addr-sa_data);
+
+ return 0;
+}
+
+/**
+ * netxen_nic_set_multi - Multicast
+ **/
+void netxen_nic_set_multi(struct net_device *netdev)
+{
+ struct netxen_port *port = netdev_priv(netdev);
+ struct dev_mc_list *mc_ptr;
+
+ mc_ptr = netdev-mc_list;
+ if (netdev-flags IFF_PROMISC)
+ netxen_nic_set_promisc_mode(port);
+ else
+ netxen_nic_unset_promisc_mode(port);
+}
+
+/*
+ * netxen_nic_change_mtu - Change the Maximum Transfer Unit
+ * @returns 0 on success, negative on failure
+ */
+int netxen_nic_change_mtu(struct net_device *netdev, int new_mtu)
+{
+ struct netxen_port *port = netdev_priv(netdev);
+
+ if (new_mtu 0x)
+ return -EINVAL;
+
+ if (new_mtu 8000) {
+ printk(KERN_ERR %s: %s MTU 8000 is not supported\n,
+ netxen_nic_driver_name, netdev-name);
+ return -EINVAL;
+ }
+
+ netxen_nic_set_mtu(port, new_mtu);
+ netdev-mtu = new_mtu;
+ port-hw.mtu = new_mtu;
+
+ return 0;
+}
+
+/*
+ * check if the firmware has been downloaded and ready to run and
+ * setup the address for the descriptors in the adapter
+ */
+int netxen_nic_hw_resources(struct netxen_adapter *adapter)
+{
+ struct netxen_hardware_context *hw = adapter-ahw;
+ int i;
+ u32 state = 0;
+ void *addr;
+ int loops = 0, err = 0;
+ int ctx, ring;
+ u32 card_cmdring = 0;
+ struct netxen_rcv_desc_crb *rcv_desc_crb = NULL;
+ struct netxen_recv_context *recv_ctx;
+ struct netxen_rcv_desc_ctx *rcv_desc;
+ struct cmd_desc_type0_t *pcmd;
+
+ DPRINTK(INFO, pci_base: %lx\n, adapter-ahw.pci_base);
+ DPRINTK(INFO, crb_base: %lx %lx, NETXEN_PCI_CRBSPACE,
+ adapter-ahw.pci_base + NETXEN_PCI_CRBSPACE);
+ DPRINTK(INFO, cam base: %lx %lx, NETXEN_CRB_CAM,
+ adapter-ahw.pci_base + NETXEN_CRB_CAM);
+ DPRINTK(INFO, cam RAM: %lx %lx, NETXEN_CAM_RAM_BASE,
+ adapter-ahw.pci_base + NETXEN_CAM_RAM_BASE);
+ DPRINTK(INFO, NIC base:%lx %lx\n, NIC_CRB_BASE_PORT1,
+ adapter-ahw.pci_base + NIC_CRB_BASE_PORT1);
+
+ /* Window 1 call */
+ read_lock(adapter-adapter_lock);
+ card_cmdring = readl(NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_CMDRING));
+ read_unlock(adapter-adapter_lock);
+
+
Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
jamal wrote: Essentially you are extending the broadcast domain i.e a bridge within on top of a bridge. I would question the scalability of such a beast in the presence of many nodes. Also take a look at some of the work Radia Perlman (who invented bridging really) is up to these days. Hi Jamal I agree with your analysis, and recently I read an interesting interview with her (I think it was linked from slashdot, an interview with the mother of the Internet ;-) I'm not sure her work (I don't exactly recall the specifics) is applicable to our problem though. Regarding the scalability, I think it rather depends on the number of hops how usable FLAME is. I don't think it would scale well to a campus or city wide network, but in the case of a few mobile nodes, it has very little overhead both in bandwidth and delay. Cheers Simon - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/9] Resending NetXen 1G/10G NIC driver patch
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.h
linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.h
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_hw.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_hw.h 2006-05-25
02:43:22.0 -0700
@@ -0,0 +1,339 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * Structures, enums, and macros for the MAC
+ *
+ */
+
+#ifndef __NETXEN_NIC_HW_H_
+#define __NETXEN_NIC_HW_H_
+
+#include netxen_nic_hdr.h
+
+/* Hardware memory size of 128 meg */
+#define NETXEN_MEMADDR_MAX (128 * 1024 * 1024)
+
+#ifndef readq
+static inline u64 readq(void __iomem * addr)
+{
+ return readl(addr) | (((u64) readl(addr + 4)) 32LL);
+}
+#endif
+
+#ifndef writeq
+static inline void writeq(u64 val, void __iomem * addr)
+{
+ writel(((u32) (val)), (addr));
+ writel(((u32) (val 32)), (addr + 4));
+}
+#endif
+
+#define NETXEN_NIC_HW_BLOCK_WRITE_64(DATA_PTR, ADDR, NUM_WORDS) \
+do {\
+int num;\
+u64 *a = (u64 *) (DATA_PTR);\
+u64 *b = (u64 *) (ADDR);\
+for (num = 0; num (NUM_WORDS); num++) { \
+writeq(readq(a), b);\
+b++;\
+a++;\
+} \
+} while (0)
+
+#define NETXEN_NIC_HW_BLOCK_READ_64(DATA_PTR, ADDR, NUM_WORDS)\
+do { \
+int num; \
+u64 *a = (u64 *) (DATA_PTR); \
+u64 *b = (u64 *) (ADDR); \
+for (num = 0; num (NUM_WORDS); num++) { \
+writeq(readq(b), a); \
+b++; \
+a++; \
+} \
+} while (0)
+
+#define NETXEN_PCI_MAPSIZE_BYTES (NETXEN_PCI_MAPSIZE 20)
+
+#define NETXEN_NIC_LOCKED_READ_REG(X, Y) \
+addr = (void *)(adapter-ahw.pci_base + X); \
+*(u32 *)Y = readl(addr);
+
+#define NETXEN_NIC_LOCKED_WRITE_REG(X, Y) \
+ addr = (void *)(adapter-ahw.pci_base + X); \
+ writel(*(u32 *)Y, addr);
+
+struct netxen_port;
+void netxen_nic_set_link_parameters(struct netxen_port *port);
+struct netxen_adapter;
+void netxen_nic_flash_print(struct netxen_adapter *adapter);
+
+int netxen_nic_hw_write_wx(struct netxen_adapter *adapter, u64 off,
+ void *data, int len);
+void netxen_crb_writelit_adapter(struct netxen_adapter *adapter,
+unsigned long off, int data);
+int netxen_nic_hw_read_wx(struct netxen_adapter *adapter, u64 off,
+ void *data, int len);
+
+typedef u8 netxen_ethernet_macaddr_t[6];
+
+/* Nibble or Byte mode for phy interface (GbE mode only) */
+typedef enum {
+ NETXEN_NIU_10_100_MB = 0,
+ NETXEN_NIU_1000_MB
+} netxen_niu_gbe_ifmode_t;
+
+/*
+ * NIU GB MAC Config Register 0 (applies to GB0, GB1, GB2, GB3)
+ */
+struct netxen_niu_gb_mac_config_0_t {
+ netxen_crbword_t tx_enable:1, /* 1:enable frame xmit, 0:disable */
+tx_synched:1, /* R/O: xmit enable synched to xmit stream */
+rx_enable:1, /* 1:enable frame recv, 0:disable */
+rx_synched:1, /* R/O: recv enable synched to
Re: sky2 hw csum failure [was Re: sky2 large MTU problems]
On 25/05/06, Patrick McHardy [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: On Wed, 24 May 2006 10:28:52 +0100 Daniel J Blueman [EMAIL PROTECTED] wrote: Having done some more stress testing with sky2 1.4 (in 2.6.17-rc4) and the latest patch, I have found problems when streaming lots of data out of the sky2 interface (eg via samba serving a large file to GigE client). Ultimately, the interface will stop sending. Before this happens, I see lots of: kernel: lan0: hw csum failure. kernel: [__skb_checksum_complete+86/96] __skb_checksum_complete+0x56/0x60 kernel: [tcp_error+300/512] tcp_error+0x12c/0x200 kernel: [poison_obj+41/96] poison_obj+0x29/0x60 kernel: [tcp_error+0/512] tcp_error+0x0/0x200 kernel: [ip_conntrack_in+157/1072] ip_conntrack_in+0x9d/0x430 kernel: [kfree_skbmem+8/128] kfree_skbmem+0x8/0x80 kernel: [arp_process+102/1408] arp_process+0x66/0x580 kernel: [check_poison_obj+36/416] check_poison_obj+0x24/0x1a0 kernel: [arp_process+102/1408] arp_process+0x66/0x580 kernel: [nf_iterate+99/144] nf_iterate+0x63/0x90 kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 kernel: [nf_hook_slow+89/240] nf_hook_slow+0x59/0xf0 kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 kernel: [ip_rcv+386/1104] ip_rcv+0x182/0x450 kernel: [ip_rcv_finish+0/608] ip_rcv_finish+0x0/0x260 kernel: [packet_rcv_spkt+216/320] packet_rcv_spkt+0xd8/0x140 kernel: [netif_receive_skb+476/784] netif_receive_skb+0x1dc/0x310 kernel: [sky2_poll+879/2096] sky2_poll+0x36f/0x830 kernel: [_spin_lock_irqsave+9/16] _spin_lock_irqsave+0x9/0x10 kernel: [run_timer_softirq+290/416] run_timer_softirq+0x122/0x1a0 kernel: [net_rx_action+108/256] net_rx_action+0x6c/0x100 kernel: [__do_softirq+66/160] __do_softirq+0x42/0xa0 kernel: [do_softirq+78/96] do_softirq+0x4e/0x60 kernel: === kernel: [do_IRQ+90/160] do_IRQ+0x5a/0xa0 kernel: [remove_vma+69/80] remove_vma+0x45/0x50 kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20 kernel: [get_offset_pmtmr+151/3584] get_offset_pmtmr+0x97/0xe00 kernel: [do_gettimeofday+26/208] do_gettimeofday+0x1a/0xd0 kernel: [sys_gettimeofday+26/144] sys_gettimeofday+0x1a/0x90 kernel: [syscall_call+7/11] syscall_call+0x7/0xb What ever the netfilter chain is, it is trimming or altering the packet without clearing or altering the hardware checksum. It is not a driver problem, we saw these in VLAN's and ebtables already. The call chain looks pretty messed up, but the point where an invalid HW checksum is detected is in TCP connection tracking, which is basically the first thing netfilter does, unless you use the raw table. There are no packet modifications done by conntrack, so I doubt that netfilter is the culprit here. Of course we had some big checksumming cleanups, so there is a possibilty of bugs there, but I did test them with sky2 and HW checksumming, so I don't think thats the case. Daniel, is there an easy way to reproduce the checksum failure? In short, no. This was seen when packets may have been truncated by large MTU (eg 9000) problems in the sky2 driver transmit path. There is a small chance that this could relate to transmitting with an MTU of 9000 (possibly with receiving with an MTU of 1500 too) On that interface, the only rules that were being exercised were: iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t filter -A INPUT -p tcp -m tcp --dport 445 --syn -j ACCEPT # SMB iptables -t filter -A INPUT -j DROP HTB and SFQ are active on other interfaces. -- Daniel J Blueman - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/9] Resending NetXen 1G/10G NIC driver patch
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_init.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_init.c
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_init.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_init.c2006-05-25
02:43:22.0 -0700
@@ -0,0 +1,1219 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * Source file for NIC routines to initialize the Phantom Hardware
+ *
+ */
+
+#include linux/netdevice.h
+#include linux/delay.h
+#include netxen_nic.h
+#include netxen_nic_hw.h
+#include netxen_nic_ioctl.h
+#include netxen_nic_phan_reg.h
+
+struct crb_addr_pair {
+ long addr;
+ long data;
+};
+
+#define NETXEN_MAX_CRB_XFORM 60
+static unsigned int crb_addr_xform[NETXEN_MAX_CRB_XFORM];
+#define NETXEN_ADDR_ERROR ((unsigned long ) 0x )
+
+#define crb_addr_transform(name) \
+crb_addr_xform[NETXEN_HW_PX_MAP_CRB_##name] = \
+NETXEN_HW_CRB_HUB_AGT_ADR_##name 20
+
+#define NETXEN_FLASH_BASE (BOOTLD_START)
+#define NETXEN_PHANTOM_MEM_BASE(NETXEN_FLASH_BASE)
+
+static void crb_addr_transform_setup(void)
+{
+ crb_addr_transform(XDMA);
+ crb_addr_transform(TIMR);
+ crb_addr_transform(SRE);
+ crb_addr_transform(SQN3);
+ crb_addr_transform(SQN2);
+ crb_addr_transform(SQN1);
+ crb_addr_transform(SQN0);
+ crb_addr_transform(SQS3);
+ crb_addr_transform(SQS2);
+ crb_addr_transform(SQS1);
+ crb_addr_transform(SQS0);
+ crb_addr_transform(RPMX7);
+ crb_addr_transform(RPMX6);
+ crb_addr_transform(RPMX5);
+ crb_addr_transform(RPMX4);
+ crb_addr_transform(RPMX3);
+ crb_addr_transform(RPMX2);
+ crb_addr_transform(RPMX1);
+ crb_addr_transform(RPMX0);
+ crb_addr_transform(ROMUSB);
+ crb_addr_transform(SN);
+ crb_addr_transform(QMN);
+ crb_addr_transform(QMS);
+ crb_addr_transform(PGNI);
+ crb_addr_transform(PGND);
+ crb_addr_transform(PGN3);
+ crb_addr_transform(PGN2);
+ crb_addr_transform(PGN1);
+ crb_addr_transform(PGN0);
+ crb_addr_transform(PGSI);
+ crb_addr_transform(PGSD);
+ crb_addr_transform(PGS3);
+ crb_addr_transform(PGS2);
+ crb_addr_transform(PGS1);
+ crb_addr_transform(PGS0);
+ crb_addr_transform(PS);
+ crb_addr_transform(PH);
+ crb_addr_transform(NIU);
+ crb_addr_transform(I2Q);
+ crb_addr_transform(EG);
+ crb_addr_transform(MN);
+ crb_addr_transform(MS);
+ crb_addr_transform(CAS2);
+ crb_addr_transform(CAS1);
+ crb_addr_transform(CAS0);
+ crb_addr_transform(CAM);
+ crb_addr_transform(C2C1);
+ crb_addr_transform(C2C0);
+}
+
+int init_firmware(struct netxen_adapter *adapter)
+{
+ u32 state = 0, loops = 0, err = 0;
+
+ /* Window 1 call */
+ read_lock(adapter-adapter_lock);
+ state = readl(NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
+ read_unlock(adapter-adapter_lock);
+
+ while (state != PHAN_INITIALIZE_COMPLETE loops 20) {
+ udelay(100);
+ /* Window 1 call */
+ read_lock(adapter-adapter_lock);
+ state = readl(NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
+ read_unlock(adapter-adapter_lock);
+
+ loops++;
+ }
+ if (loops = 20) {
+ printk(KERN_ERR Cmd Peg initialization not complete:%x.\n,
+ state);
+ err = -EIO;
+ return err;
+ }
+ /* Window 1 call */
+ read_lock(adapter-adapter_lock);
+ writel(PHAN_INITIALIZE_ACK,
+ NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
+ read_unlock(adapter-adapter_lock);
+
+ return err;
+}
+
+void initialize_adapter_sw(struct netxen_adapter *adapter)
+{
+
[PATCH 8/9] Resending NetXen 1G/10G NIC driver patch
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_main.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_main.c
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_main.c 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_main.c2006-05-25
02:43:22.0 -0700
@@ -0,0 +1,1209 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * Main source file for NetXen NIC Driver on Linux
+ *
+ */
+
+#include netxen_nic.h
+
+#define DEFINE_GLOBAL_RECV_CRB
+#include netxen_nic_phan_reg.h
+#include netxen_nic_ioctl.h
+
+MODULE_DESCRIPTION(NetXen Multi port (1/10) Gigabit Network Driver);
+MODULE_LICENSE(GPL);
+MODULE_VERSION(NETXEN_NIC_LINUX_VERSIONID);
+
+char netxen_nic_driver_name[] = netxen;
+char netxen_nic_driver_string[] = NetXen Network Driver version
+NETXEN_NIC_LINUX_VERSIONID
+- NETXEN_NIC_BUILD_NO generated NETXEN_NIC_TIMESTAMP;
+
+#define NETXEN_NETDEV_WEIGHT 120
+#define NETXEN_ADAPTER_UP_MAGIC 777
+
+static int netxen_nic_probe_err = 0;
+
+/* Local functions to NetXen NIC driver */
+static int __devinit netxen_nic_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent);
+static void __devexit netxen_nic_remove(struct pci_dev *pdev);
+static int netxen_nic_open(struct net_device *netdev);
+static int netxen_nic_close(struct net_device *netdev);
+static int netxen_nic_xmit_frame(struct sk_buff *, struct net_device *);
+static void netxen_tx_timeout(struct net_device *netdev);
+static void netxen_tx_timeout_task(struct net_device *netdev);
+static void netxen_watchdog(unsigned long);
+static int netxen_handle_int(struct netxen_adapter *, struct net_device *);
+static int netxen_nic_ioctl(struct net_device *netdev,
+ struct ifreq *ifr, int cmd);
+static int netxen_nic_poll(struct net_device *dev, int *budget);
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void netxen_nic_poll_controller(struct net_device *netdev);
+#endif
+static irqreturn_t netxen_intr(int irq, void *data, struct pt_regs *regs);
+
+/* PCI Device ID Table */
+static struct pci_device_id netxen_pci_tbl[] __devinitdata = {
+ NETXEN_PCI_ID(PCI_DEVICE_ID_NX_QG),
+ NETXEN_PCI_ID(PCI_DEVICE_ID_NX_XG),
+ NETXEN_PCI_ID(PCI_DEVICE_ID_NX_CX4),
+ NETXEN_PCI_ID(PCI_DEVICE_ID_NX_IMEZ),
+ NETXEN_PCI_ID(PCI_DEVICE_ID_NX_HMEZ),
+ {0,}
+};
+
+MODULE_DEVICE_TABLE(pci, netxen_pci_tbl);
+
+struct netxen_adapter *adapterlist[MAX_NUM_CARDS];
+
+/*
+ * netxen_nic_probe()
+ *
+ * Linux system will invoke this after identifying the vendor ID and device Id
+ * in the pci_tbl where this module will search for NetXen vendor and device
ID for
+ * quad port adapter.
+ *
+ * Even though there are 4 seperate devices (functions) on the quad port NIC,
but
+ * the probe will be invoked for the first device (function) only. This will
+ * initialize the adapter, and setup the global parameters along with the
port's
+ * specific structure.
+ */
+static int __devinit
+netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+ struct net_device *netdev = NULL;
+ struct netxen_adapter *adapter = NULL;
+ struct netxen_port *port = NULL;
+ u8 *mem_ptr = NULL;
+ unsigned long mem_base, mem_len;
+ int pci_using_dac, i, err;
+ int boardno = 0;
+ int ring;
+ struct netdev_list *netlist = NULL;
+ struct netxen_recv_context *recv_ctx = NULL;
+ struct netxen_rcv_desc_ctx *rcv_desc = NULL;
+ struct netxen_cmd_buffer *cmd_buf_arr = NULL;
+ static int netxen_cards_found = 0;
+ u64 mac_addr[FLASH_NUM_PORTS + 1];
+ int valid_mac;
+
+ if ((err = pci_enable_device(pdev))) {
+ netxen_nic_probe_err = err;
+ return err;
+ }
+ if (!(pci_resource_flags(pdev, 0) IORESOURCE_MEM)) {
+ err = -ENODEV;
+
[PATCH 9/9] Resending NetXen 1G/10G NIC driver patch
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_niu.c
linux-2.6.16.18/drivers/net/netxen/netxen_nic_niu.c
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic_niu.c1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic_niu.c 2006-05-25
02:43:22.0 -0700
@@ -0,0 +1,770 @@
+/*
+ * Copyright (C) 2003 - 2006 NetXen, Inc.
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston,
+ * MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution
+ * in the file called LICENSE.
+ *
+ * Contact Information:
+ *[EMAIL PROTECTED]
+ * NetXen,
+ * 3965 Freedom Circle, Fourth floor,
+ * Santa Clara, CA 95054
+ *
+ *
+ * Provides access to the Network Interface Unit h/w block.
+ *
+ */
+
+#include netxen_nic.h
+#include linux/delay.h
+
+void netxen_delay(int value)
+{
+ unsigned long remainder;
+
+ remainder = value / 5;
+ do {
+ if (remainder 1000) {
+ udelay(1000);
+ remainder -= 1000;
+ } else {
+ udelay(remainder + 1);
+ remainder = 0;
+ }
+ } while (remainder 0);
+}
+
+/**
+ * netxen_niu_gbe_phy_read - read a register from the GbE PHY via
+ * mii management interface.
+ *
+ * Note: The MII management interface goes through port 0.
+ * Individual phys are addressed as follows:
+ * @param phy [15:8] phy id
+ * @param reg [7:0] register number
+ *
+ * @returns 0 on success
+ * -1 on error
+ *
+ **/
+long netxen_niu_gbe_phy_read(struct netxen_adapter *adapter, long phy,
+long reg, netxen_crbword_t * readval)
+{
+ long timeout = 0;
+ long result = 0;
+ long restore = 0;
+ struct netxen_niu_gb_mii_mgmt_address address;
+ struct netxen_niu_gb_mii_mgmt_command command;
+ struct netxen_niu_gb_mii_mgmt_indicators status;
+ struct netxen_niu_gb_mii_mgmt_config mii_cfg;
+ struct netxen_niu_gb_mac_config_0_t mac_cfg0;
+
+ /* MII mgmt all goes through port 0 MAC interface, so it cannot be in
reset */
+ if (netxen_nic_hw_read_wx(adapter, NETXEN_NIU_GB_MAC_CONFIG_0(0),
+ mac_cfg0, 4))
+ return -1;
+ if (mac_cfg0.soft_reset) {
+ struct netxen_niu_gb_mac_config_0_t temp;
+ *(netxen_crbword_t *) temp = 0;
+ temp.tx_reset_pb = 1;
+ temp.rx_reset_pb = 1;
+ temp.tx_reset_mac = 1;
+ temp.rx_reset_mac = 1;
+ if (netxen_nic_hw_write_wx(adapter,
+ NETXEN_NIU_GB_MAC_CONFIG_0(0),
+ temp, 4))
+ return -1;
+ restore = 1;
+ }
+
+ /* reset MII management interface */
+ *(netxen_crbword_t *) mii_cfg = 0;
+ mii_cfg.clockselect = 7;
+ mii_cfg.reset = 1;
+ if (netxen_nic_hw_write_wx(adapter, NETXEN_NIU_GB_MII_MGMT_CONFIG(0),
+ mii_cfg, 4))
+ return -1;
+ mii_cfg.reset = 0;
+ if (netxen_nic_hw_write_wx(adapter, NETXEN_NIU_GB_MII_MGMT_CONFIG(0),
+ mii_cfg, 4))
+ return -1;
+
+ *(netxen_crbword_t *) address = 0;
+ address.reg_addr = reg;
+ address.phy_addr = phy;
+ if (netxen_nic_hw_write_wx(adapter, NETXEN_NIU_GB_MII_MGMT_ADDR(0),
+ address, 4))
+ return -1;
+ *(netxen_crbword_t *) command = 0;/* turn off any prior activity
*/
+ if (netxen_nic_hw_write_wx(adapter, NETXEN_NIU_GB_MII_MGMT_COMMAND(0),
+ command, 4))
+ return -1;
+ /* send read command */
+ command.read_cycle = 1;
+ if (netxen_nic_hw_write_wx(adapter, NETXEN_NIU_GB_MII_MGMT_COMMAND(0),
+ command, 4))
+ return -1;
+
+ *(netxen_crbword_t *) status = 0;
+ do {
+ if (netxen_nic_hw_read_wx(adapter,
+
Re: sky2 hw csum failure [was Re: sky2 large MTU problems]
Daniel J Blueman wrote: On 25/05/06, Patrick McHardy [EMAIL PROTECTED] wrote: Daniel, is there an easy way to reproduce the checksum failure? In short, no. This was seen when packets may have been truncated by large MTU (eg 9000) problems in the sky2 driver transmit path. There is a small chance that this could relate to transmitting with an MTU of 9000 (possibly with receiving with an MTU of 1500 too) Unfortunately I can't test this myself because my other NICs don't support MTUs 1500. On that interface, the only rules that were being exercised were: iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t filter -A INPUT -p tcp -m tcp --dport 445 --syn -j ACCEPT # SMB iptables -t filter -A INPUT -j DROP That shouldn't cause any packet modifications. Can you trigger the checksum failures without netfilter? - 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] TCP Compound
From: Angelo P. Castellani [EMAIL PROTECTED]
TCP Compound is a sender-side only change to TCP that uses
a mixed Reno/Vegas approach to calculate the cwnd.
For further details look here:
ftp://ftp.research.microsoft.com/pub/tr/TR-2005-86.pdf
Signed-off-by: Angelo P. Castellani [EMAIL PROTECTED]
---
This new revision of the TCP Compound implementation fixes some issues
present in the previous patch and has been reverted to a stand-alone
file (thanks to Stephen suggestion).
Regards,
Angelo P. Castellani
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 326676b..e577eb8 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -542,6 +542,16 @@ config TCP_CONG_LP
``fair share`` of bandwidth as targeted by TCP.
See http://www-ece.rice.edu/networks/TCP-LP/
+config TCP_CONG_COMPOUND
+ tristate TCP Compound
+ depends on EXPERIMENTAL
+ default n
+ ---help---
+ TCP Compound is a sender-side only change to TCP that uses
+ a mixed Reno/Vegas approach to calculate the cwnd.
+ For further details look here:
+ ftp://ftp.research.microsoft.com/pub/tr/TR-2005-86.pdf
+
endmenu
config TCP_CONG_BIC
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
index 5c65487..f0697c4 100644
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.
obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
+obj-$(CONFIG_TCP_CONG_COMPOUND) += tcp_compound.o
obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
xfrm4_output.o
/*
* TCP Vegas congestion control
*
* This is based on the congestion detection/avoidance scheme described in
*Lawrence S. Brakmo and Larry L. Peterson.
*TCP Vegas: End to end congestion avoidance on a global internet.
*IEEE Journal on Selected Areas in Communication, 13(8):1465--1480,
*October 1995. Available from:
* ftp://ftp.cs.arizona.edu/xkernel/Papers/jsac.ps
*
* See http://www.cs.arizona.edu/xkernel/ for their implementation.
* The main aspects that distinguish this implementation from the
* Arizona Vegas implementation are:
* o We do not change the loss detection or recovery mechanisms of
* Linux in any way. Linux already recovers from losses quite well,
* using fine-grained timers, NewReno, and FACK.
* o To avoid the performance penalty imposed by increasing cwnd
* only every-other RTT during slow start, we increase during
* every RTT during slow start, just like Reno.
* o Largely to allow continuous cwnd growth during slow start,
* we use the rate at which ACKs come back as the actual
* rate, rather than the rate at which data is sent.
* o To speed convergence to the right rate, we set the cwnd
* to achieve the right (actual) rate when we exit slow start.
* o To filter out the noise caused by delayed ACKs, we use the
* minimum RTT sample observed during the last RTT to calculate
* the actual rate.
* o When the sender re-starts from idle, it waits until it has
* received ACKs for an entire flight of new data before making
* a cwnd adjustment decision. The original Vegas implementation
* assumed senders never went idle.
*
*
* TCP Compound based on TCP Vegas
*
* further details can be found here:
* ftp://ftp.research.microsoft.com/pub/tr/TR-2005-86.pdf
*/
#include linux/config.h
#include linux/mm.h
#include linux/module.h
#include linux/skbuff.h
#include linux/inet_diag.h
#include net/tcp.h
/* Default values of the Vegas variables, in fixed-point representation
* with V_PARAM_SHIFT bits to the right of the binary point.
*/
#define V_PARAM_SHIFT 1
#define TCP_COMPOUND_ALPHA 3U
#define TCP_COMPOUND_BETA 1U
#define TCP_COMPOUND_KAPPA_POW 3
#define TCP_COMPOUND_KAPPA_NSQRT2
#define TCP_COMPOUND_GAMMA 30
#define TCP_COMPOUND_ZETA 1
/* TCP compound variables */
struct compound {
u32 beg_snd_nxt; /* right edge during last RTT */
u32 beg_snd_una; /* left edge during last RTT */
u32 beg_snd_cwnd; /* saves the size of the cwnd */
u8 doing_vegas_now; /* if true, do vegas for this RTT */
u16 cntRTT; /* # of RTTs measured within last RTT */
u32 minRTT; /* min of RTTs measured within last RTT (in usec) */
u32 baseRTT; /* the min of all Vegas RTT measurements seen (in usec) */
u32 cwnd;
u32 dwnd;
};
/* There are several situations when we must re-start Vegas:
*
* o when a connection is established
* o after an RTO
* o after fast recovery
* o when we send a packet and there is no outstanding
*unacknowledged data (restarting an idle connection)
*
* In these circumstances we cannot do a Vegas calculation at the
* end of the first RTT, because any calculation we do is using
* stale info -- both the saved cwnd and congestion feedback are
* stale.
*
* Instead we must wait until the completion of an RTT during
* which we actually receive ACKs.
Re: reminder, 2.6.18 window...
Phil Dibowitz [EMAIL PROTECTED] : [...] Right. I think the point here is that it does _NOT_ inherently break things. If you don't like the behavior, don't run ethtool -z eth0, it's that simple. It would be better to explain why several sysadmins want this feature and why it can't be done in an hardware-independent way at the application level. -- Ueimor - 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: reminder, 2.6.18 window...
On Thursday 25 May 2006 02:23, Bill Fink wrote: On Wed, 24 May 2006, Jeff Garzik wrote: Brent Cook wrote: Note that this is just clearing the hardware statistics on the interface, and would not require any kind of atomic_increment addition for interfaces that support that. It would be kind-of awkward to implement this on drivers that increment stats in hardware though (lo, vlan, br, etc.) This also brings up the question of resetting the stats for 'netstat -s' If you don't atomically clear the statistics, then you are leaving open a window where the stats could easily be corrupted, if the network interface is under load. This 'clearing' operation has implications on the rest of the statistics usage. More complexity, and breaking of apps, when we could just use the existing, working system? I'll take the do nothing, break nothing, everything still works route any day. I'll admit to not knowing all the intricacies of the kernel coding involved, but I don't offhand see how zeroing the stats would be significantly more complex than updating the stats during normal usage. But I'll have to leave that argument to the experts. What it boils down to is that currently, a single CPU or thread ever touches the stats concurrently, so it doesn't have to lock them or do anything special to ensure that the continue incrementing. If you want to make sure that the statistics actually reset when you want them to, you have to account for this case: CPU0 reads current value from memory (increment) CPU1 writes 0 to current value in memory (reset) CPU0 writes incremented value to memory (increment complete) Check out do_add_counters() in net/ipv4/netfilter/ip_tables.c to see what's required to do this reliably in the kernel. The current patch is fine if your hardware implements the required atomicity itself. Otherwise, you need a locking infrastructure to extend it to all network devices if you want zeroing to always work. What I'm seeing here in response to this is that it doesn't matter if zeroing just _mostly_ works, which is what you would get if you didn't lock. Eh, I'm OK with that too, but I think people are worried about the bugs that would get filed by admins when just zeroing the stats on cheap NIC x only works 90% of the time, less under load. Or not at all (not implemented in driver.) Then you're back to the userspace solution or actually implement stat locking / atomic ops. - Brent - 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] bridge: fix locking and memory leak in br_add_bridge
There are several problems in error handling in br_add_bridge: - when dev_alloc_name fails, allocated net_device is not freed - unregister_netdev is called when rtnl lock is held - free_netdev is called before netdev_run_todo has a chance to be run after unregistering net_device This patch should fix these issues. Signed-off-by: Jiri Benc [EMAIL PROTECTED] --- net/bridge/br_if.c |9 - 1 files changed, 4 insertions(+), 5 deletions(-) --- dscape.orig/net/bridge/br_if.c +++ dscape/net/bridge/br_if.c @@ -306,20 +306,19 @@ int br_add_bridge(const char *name) ret = register_netdevice(dev); if (ret) - goto err2; + goto err1; ret = br_sysfs_addbr(dev); if (ret) - goto err3; + goto err2; rtnl_unlock(); return 0; - err3: - unregister_netdev(dev); err2: - free_netdev(dev); + unregister_netdevice(dev); err1: rtnl_unlock(); + free_netdev(dev); return ret; } -- Jiri Benc SUSE Labs - 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: reminder, 2.6.18 window...
On Thu, 2006-05-25 at 03:23 -0400, Bill Fink wrote: likely problem areas. The human mind (at least speaking for myself) is not nearly as adept when having to deal with deltas. Yes, you can record the initial state of all the devices, run the stress test, record the new state of all the devices, and then spend a large amount of time devising a script to calculate all the deltas for all the scores of variables on all the involved devices, and then finally try and figure out what is wrong. But it would be so much better, easier, and more efficient, if the kernel simply provided such a feature that almost all other networking devices provide. ftp://ftp.cup.hp.com/dist/networking/tools/beforeafter.tar.gz as Rick mentioned earlier, and then you won't need to write a complicated script. -- Dave Dillow [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: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
[EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=6613 Summary: iptables broken on 32-bit PReP (ARCH=ppc) Kernel Version: 2.6.17-rc4 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: none known, this is a fresh install Distribution: Debian unstable Hardware Environment: 32-bit PowerPC 604 with PReP subarch (using old ARCH=ppc) Software Environment: usual 32-bit ppc userspace, gcc 4.0.3 Problem Description: iptables operations usually just give Incalida operation. modprobe iptable_filter and adding rules to the nat table have failed in testing while iptable_nat can be modprobed and listed. Steps to reproduce: modprobe iptable_filter (errors out with Invalid Argument) iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -j SNAT --to 192.168.1.1 (usually errors out with Invalid Argument, sometimes succeeds, when succeeds then the rule works 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] bridge: fix locking and memory leak in br_add_bridge
On Thu, 25 May 2006 15:31:24 +0200, Jiri Benc wrote: err2: - free_netdev(dev); + unregister_netdevice(dev); err1: rtnl_unlock(); + free_netdev(dev); return ret; Sorry, this is wrong. I didn't notice that br_dev_setup sets dev-destructor to free_netdev. Corrected patch will follow. Jiri -- Jiri Benc SUSE Labs - 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 v2] bridge: fix locking and memory leak in br_add_bridge
There are several bugs in error handling in br_add_bridge:
- when dev_alloc_name fails, allocated net_device is not freed
- unregister_netdev is called when rtnl lock is held
- free_netdev is called before netdev_run_todo has a chance to be run after
unregistering net_device
This patch should fix these issues.
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
---
net/bridge/br_if.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
--- dscape.orig/net/bridge/br_if.c
+++ dscape/net/bridge/br_if.c
@@ -301,25 +301,22 @@ int br_add_bridge(const char *name)
if (strchr(dev-name, '%')) {
ret = dev_alloc_name(dev, dev-name);
if (ret 0)
- goto err1;
+ goto err;
}
ret = register_netdevice(dev);
if (ret)
- goto err2;
+ goto err;
ret = br_sysfs_addbr(dev);
if (ret)
- goto err3;
+ unregister_netdevice(dev);
rtnl_unlock();
- return 0;
+ return ret;
- err3:
- unregister_netdev(dev);
- err2:
- free_netdev(dev);
- err1:
+ err:
rtnl_unlock();
+ free_netdev(dev);
return ret;
}
--
Jiri Benc
SUSE Labs
-
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
[RFC PATCH 1/2] Hardware button support for Wireless cards: radiobtn
Add radiobtn driver.
This driver creates an iput device for each registered button
and will poll the device frequently to check the latest status of the button.
Once the status has changed it will try to enable or disable the radio
and send an event to the input device.
Signed-off-by: Ivo van Doorn [EMAIL PROTECTED]
diff -uprN wireless-dev/drivers/input/misc/Kconfig
wireless-dev-radiobtn/drivers/input/misc/Kconfig
--- wireless-dev/drivers/input/misc/Kconfig 2006-04-27 00:52:53.0
+0200
+++ wireless-dev-radiobtn/drivers/input/misc/Kconfig2006-05-25
16:29:23.0 +0200
@@ -79,4 +79,13 @@ config HP_SDC_RTC
Say Y here if you want to support the built-in real time clock
of the HP SDC controller.
+config RADIOBTN
+ tristate Hardware radio button support
+ help
+ Say Y here if you have an integrated WiFi or Bluetooth device
+ which contains an hardware button for enabling or disabling the radio.
+ When this driver is used, this driver will make sure the radio will
+ be correctly enabled and disabled when needed. It will then also
+ use the created input device to signal user space of this event
+ which allows userspace to take additional actions.
endif
diff -uprN wireless-dev/drivers/input/misc/Makefile
wireless-dev-radiobtn/drivers/input/misc/Makefile
--- wireless-dev/drivers/input/misc/Makefile2006-04-27 00:52:53.0
+0200
+++ wireless-dev-radiobtn/drivers/input/misc/Makefile 2006-05-25
16:25:43.0 +0200
@@ -11,3 +11,4 @@ obj-$(CONFIG_INPUT_UINPUT)+= uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_HP_SDC_RTC) += hp_sdc_rtc.o
obj-$(CONFIG_INPUT_IXP4XX_BEEPER) += ixp4xx-beeper.o
+obj-$(CONFIG_RADIOBTN) += radiobtn.o
diff -uprN wireless-dev/drivers/input/misc/radiobtn.c
wireless-dev-radiobtn/drivers/input/misc/radiobtn.c
--- wireless-dev/drivers/input/misc/radiobtn.c 1970-01-01 01:00:00.0
+0100
+++ wireless-dev-radiobtn/drivers/input/misc/radiobtn.c 2006-05-25
16:23:59.0 +0200
@@ -0,0 +1,158 @@
+/*
+ Copyright (C) 2006 Ivo van Doorn
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the
+ Free Software Foundation, Inc.,
+ 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/*
+ Radio hardware button support
+ Poll frequently all registered hardware for hardware button status,
+ if changed enabled or disable the radio of that hardware device.
+ Send signal to input device to inform userspace about the new status.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/input.h
+#include linux/radiobtn.h
+
+MODULE_AUTHOR(Ivo van Doorn [EMAIL PROTECTED]);
+MODULE_VERSION(1.0);
+MODULE_DESCRIPTION(Radio hardware button support);
+MODULE_LICENSE(GPL);
+
+void radiobtn_poll(unsigned long data)
+{
+ struct radio_button *radiobtn = (struct radio_button*)data;
+ int state;
+
+ /*
+* Poll for the new state.
+* Check if the state has changed.
+*/
+ state = !!radiobtn-button_poll(radiobtn-data);
+ if (state != radiobtn-current_state) {
+ radiobtn-current_state = state;
+
+ /*
+* Enable or disable the radio when this
+* should be done in software.
+*/
+ if (state radiobtn-enable_radio)
+ radiobtn-enable_radio(radiobtn-data);
+ else if (!state radiobtn-disable_radio)
+ radiobtn-disable_radio(radiobtn-data);
+
+ /*
+* Report key event.
+*/
+ input_report_key(radiobtn-input_dev, KEY_RADIO, 1);
+ input_sync(radiobtn-input_dev);
+ input_report_key(radiobtn-input_dev, KEY_RADIO, 0);
+ input_sync(radiobtn-input_dev);
+ }
+
+ /*
+* Check if polling has been disabled.
+*/
+ if (radiobtn-poll_delay != 0) {
+ radiobtn-poll_timer.expires =
+ jiffies + msecs_to_jiffies(radiobtn-poll_delay);
+ add_timer(radiobtn-poll_timer);
+ }
+}
+
+int radiobtn_register_device(struct radio_button *radiobtn)
+{
+ int status;
+
+ /*
[RFC PATCH 0/2] Hardware button support for Wireless cards
Hi, As discussed previously on this list hardware button support for wireless cards and Bluetooth devices could use a seperate generalized driver. I have made a first attempt to do this with the suggestions from the discussion. This means that in all cases the hardware will be requested to enable or disable the radio (if this command needs to be issued from software) and it will send a signal to the input device created for the button. At the moment a input device will be created for each registered button, not sure if this is the desired situation, but thats why this is a RFC patch. ;) I am also not sure where to place this driver so at the moment I have placed it in /drivers/input/misc The second patch is an example of the implementation in rt2x00. That is just an example since that already contained a similar approach with hardware button support. All hints/tips/comments are welcome. :) Ivo pgpqLMMvLVd8o.pgp Description: PGP signature
Re: reminder, 2.6.18 window...
On Wed, 2006-24-05 at 13:25 -0700, Rick Jones wrote: The lanadmin (think ethtool) command of HP-UX has had a way to clear the statistics reported by lanadmin. I do not know however, if that affects the stats in the actual SNMP interface MIBs as I've never had occasion to look. I still suggest beforeafter to people because clearing the lanadmin stats requires root privs and because it may not be a kosher thing to do on a customer system. HP-UX does not provide a way to clear the stats reported by netstat. Which also are snmp stats. So far the reasoning of why this is needed has been around debugging which is in itself reasonable as long as it doesnt break things: it does. For debugging: I can name about 3 ways you can achieve the counting without touching the driver/hardware level stats. Someone needs to put effort and create a tool to it. [ Actually now that i spent 2 minutes looking at the patch i can understand jgarziks concerns]. On Wed, 2006-24-05 at 16:44 -0400, Brian Haley wrote: So how is this different than if an SNMP station probes my system,then I reboot, then they probe again. Things will seem to have gone backwards, but they deal with that just fine. Rick has already answered this question i hope. There are triggers that management tools use to identify reboots. DEC/Compaq/HP has allowed this on Tru64 UNIX since 1999 because we had customers that wanted it, noone ever complained about complications with SNMP. I am sure if we did things because your customer wanted it, we would approach anarchy at best. We did save the last time the stats were zero'd in the struct for posterity, but that was never get-able via SNMP: Because it is not part of the MIB i would suspect. -- netstat -I tu0 -s tu0 Ethernet counters at Wed May 24 16:30:05 2006 609415 seconds since last zeroed 3943458720 bytes received 113576310 bytes sent ... Maybe saving a ztime would make people happier? It may be insufficient. Management tools use the resetting as a trigger to indicate rollover of the counters. I dont know if you can go and fix everyone out there to have this new ztime in mind. Can you ask internally on how openview would handle this? It carriers the major chunk of management tools market so it may provide good insight. On Wed, 2006-24-05 at 14:04 -0700, Rick Jones wrote: Phil Dibowitz wrote: Well, I can show you support on my home switch (cabletron) - the network guys will be a little unhappy if I clear stats on our production network (cisco) without warning them: Isn't that last bit an example of why it might not be good to play-out that rope?-) I dont mind him hanging himself, he just wants to hang us all ;- cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] FLAME: external kernel module for L2.5 meshing
On Thu, 2006-25-05 at 12:53 +0200, Simon Oosthoek wrote: I agree with your analysis, and recently I read an interesting interview with her (I think it was linked from slashdot, an interview with the mother of the Internet ;-) I'm not sure her work (I don't exactly recall the specifics) is applicable to our problem though. Look at her effort ion rbridges, i think youll find theres a lot in common. Regarding the scalability, I think it rather depends on the number of hops how usable FLAME is. I don't think it would scale well to a campus or city wide network, but in the case of a few mobile nodes, it has very little overhead both in bandwidth and delay. You should mention this limitation in the paper. BTW, something else: You ability to create loops of broadcast storms is highly probable. Eventually you may have to go to L3 (TTL is of value there) ;- cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: reminder, 2.6.18 window...
On Thu, 25 May 2006, Brent Cook wrote: On Thursday 25 May 2006 02:23, Bill Fink wrote: On Wed, 24 May 2006, Jeff Garzik wrote: Brent Cook wrote: Note that this is just clearing the hardware statistics on the interface, and would not require any kind of atomic_increment addition for interfaces that support that. It would be kind-of awkward to implement this on drivers that increment stats in hardware though (lo, vlan, br, etc.) This also brings up the question of resetting the stats for 'netstat -s' If you don't atomically clear the statistics, then you are leaving open a window where the stats could easily be corrupted, if the network interface is under load. This 'clearing' operation has implications on the rest of the statistics usage. More complexity, and breaking of apps, when we could just use the existing, working system? I'll take the do nothing, break nothing, everything still works route any day. I'll admit to not knowing all the intricacies of the kernel coding involved, but I don't offhand see how zeroing the stats would be significantly more complex than updating the stats during normal usage. But I'll have to leave that argument to the experts. What it boils down to is that currently, a single CPU or thread ever touches the stats concurrently, so it doesn't have to lock them or do anything special to ensure that the continue incrementing. If you want to make sure that the statistics actually reset when you want them to, you have to account for this case: CPU0 reads current value from memory (increment) CPU1 writes 0 to current value in memory (reset) CPU0 writes incremented value to memory (increment complete) Check out do_add_counters() in net/ipv4/netfilter/ip_tables.c to see what's required to do this reliably in the kernel. Thanks for the info. I have a possibly naive question. Would it increase the reliability of clearing the stats using lazy zeroing (no locking), if the zeroing app (ethtool) bound itself to the same CPU that was handling interrupts for the device (assuming no sharing of interrupts across CPUs)? The current patch is fine if your hardware implements the required atomicity itself. Otherwise, you need a locking infrastructure to extend it to all network devices if you want zeroing to always work. What I'm seeing here in response to this is that it doesn't matter if zeroing just _mostly_ works, which is what you would get if you didn't lock. Eh, I'm OK with that too, but I think people are worried about the bugs that would get filed by admins when just zeroing the stats on cheap NIC x only works 90% of the time, less under load. Or not at all (not implemented in driver.) Then you're back to the userspace solution or actually implement stat locking / atomic ops. I would be fine with the lazy clearing of the stats (with a note describing the limitations in the ethtool man page). Being somewhat anal, I would always check that the stats had in fact been zeroed successfully before proceeding. BTW I am in 100% agreement not to do anything that would affect performance of the fast path, as I understand proper locking would necessitate. I will also look into the beforeafter utility that has been suggested, to see how easy it is to use and how much extra work would be required over just a direct visual examination of the interface statistics. -Bill - 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 v2] bridge: fix locking and memory leak in br_add_bridge
There are several bugs in error handling in br_add_bridge:
- when dev_alloc_name fails, allocated net_device is not freed
- unregister_netdev is called when rtnl lock is held
- free_netdev is called before netdev_run_todo has a chance to be run after
unregistering net_device
This patch should fix these issues.
Minor rearrangement of to use common path of earlier patch. Dave please apply.
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- br.orig/net/bridge/br_if.c
+++ br/net/bridge/br_if.c
@@ -301,25 +301,20 @@ int br_add_bridge(const char *name)
if (strchr(dev-name, '%')) {
ret = dev_alloc_name(dev, dev-name);
if (ret 0)
- goto err1;
+ goto err;
}
ret = register_netdevice(dev);
if (ret)
- goto err2;
+ goto err;
ret = br_sysfs_addbr(dev);
if (ret)
- goto err3;
- rtnl_unlock();
- return 0;
-
- err3:
- unregister_netdev(dev);
- err2:
- free_netdev(dev);
- err1:
+ unregister_netdevice(dev);
+ err:
rtnl_unlock();
+ if (ret)
+ free_netdev(dev);
return ret;
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] Resending NetXen 1G/10G NIC driver patch
Minor nits.
On Thu, 25 May 2006 03:48:38 -0700 (PDT)
Linsys Contractor Amit S. Kale [EMAIL PROTECTED] wrote:
+/*
+ * Note: This change will be reflected in all the four ports as there is
+ * only one common adapter.
+ */
+static int
+netxen_nic_set_ringparam(struct net_device *dev, struct ethtool_ringparam
*ring)
+{
+ return 0;
+}
Why not just return have no hook if you can't set parameters. Then the ioctl
will return not supported -EOPNOTSUPP
+static u32 netxen_nic_get_rx_csum(struct net_device *dev)
+{
+ return (dev-features NETIF_F_HW_CSUM);
+}
You got receive and transmit checksum confused. You need to separate
checksumming on output (dev-features NETIF_F_HW_CSUM) versus receive
checksum (controlled by hardware and usually a flag in private data structure).
+static int netxen_nic_set_rx_csum(struct net_device *dev, u32 data)
+{
+ if (data)
+ dev-features |= NETIF_F_HW_CSUM;
+ else
+ dev-features = (~NETIF_F_HW_CSUM);
+
+ if (netif_running(dev)) {
+ dev-stop(dev); /* verify */
+ dev-open(dev);
What if open fail fails? Then you have an interesting recovery
situation.
+ }
+ return 0;
+}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] Resending NetXen 1G/10G NIC driver patch
On Thu, 25 May 2006 03:51:03 -0700 (PDT)
Linsys Contractor Amit S. Kale [EMAIL PROTECTED] wrote:
diff -Naru linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h
linux-2.6.16.18/drivers/net/netxen/netxen_nic.h
--- linux-2.6.16.18.orig/drivers/net/netxen/netxen_nic.h 1969-12-31
16:00:00.0 -0800
+++ linux-2.6.16.18/drivers/net/netxen/netxen_nic.h 2006-05-25
02:43:22.0 -0700
@@ -0,0 +1,950 @@
+#define IP_ALIGNMENT_BYTES 2 /* make ip aligned on 16 bytes addr */
Please use NET_IP_ALIGN, it does the right architecture dependent
offset.
...
+#define NETXEN_PCI_ID(X) { PCI_DEVICE(PCI_VENDOR_ID_NX, (X)) }
Nested macro's on macro's, just use PCI_DEVICE()
+
+#define PFX netxen:
+
+/* Note: Make sure to not call this before adapter-port is valid */
+#if !defined(NETXEN_DEBUG)
+#define DPRINTK(klevel, fmt, args...)do { \
+ } while (0)
+#else
+#define DPRINTK(klevel, fmt, args...)do { \
+ printk(KERN_##klevel PFX %s: %s: fmt, __FUNCTION__,\
+ (adapter != NULL adapter-port != NULL \
+ adapter-port[0] != NULL \
+ adapter-port[0]-netdev != NULL) ? \
+ adapter-port[0]-netdev-name : NULL, \
+ ## args); } while(0)
+#endif
+
Ugh. Macro with magic variable. if you need to keep this, pass adapter.
+struct netdev_list {
+ struct netdev_list *next;
+ struct net_device *netdev;
+};
Why not use regular list.h or simple linked list. Even better
figure out how to not need need list of devices at all
+struct netxen_port_hw {
+ unsigned char mac_addr[MAX_ADDR_LEN];
+ int mtu;
+ struct pci_dev *pdev;
+ struct netxen_port *port;
+};
Isn't mtu redundant with dev-mtu and mac_addr redundant
with dev-dev_addr
+/* Following structure is for specific port information*/
+
+#define NETXEN_PORT_UP 0
+#define NETXEN_PORT_DOWN1
+#define NETXEN_PORT_INITIALIAZED2
+#define NETXEN_PORT_SUSPEND 3
Don't mirror port state with netdevice state because you risk
getting the two out of sync. Isn't this redundant with
netif_running()
-
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: reminder, 2.6.18 window...
Can you ask internally on how openview would handle this? It carriers the major chunk of management tools market so it may provide good insight. I've asked the question in an internal, informal communications channel. No guarantees it will reach any OpenView types, but if it does I'll try to provide the gist of the replies. rick jones - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] Resending NetXen 1G/10G NIC driver patch
+static int __devinit
+netxen_nic_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+#if defined(CONFIG_PCI_MSI)
+adapter-flags |= NETXEN_NIC_MSI_ENABLED;
+if (pci_enable_msi(pdev)) {
+adapter-flags = ~NETXEN_NIC_MSI_ENABLED;
+printk(KERN_WARNING %s: unable to allocate MSI interrupt
+error\n, netxen_nic_driver_name);
+}
+#endif
No need for the #ifdef -- pci_enable_msi() is stubbed out so it will
always just return failure if CONFIG_PCI_MSI is not set.
+adapterlist[netxen_cards_found++] = adapter;
+adapter-number = netxen_cards_found;
Having a static array of adapters is a bad idea. Just allocate a
data structure for each card as you probe it.
- R.
-
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 6/9] Resending NetXen 1G/10G NIC driver patch
Why is this necessary. Additional private API seems like leftover
debug code.
+int
+netxen_nic_do_ioctl(struct netxen_adapter *adapter, void *u_data,
+ struct netxen_port *port)
+{
+ struct netxen_nic_ioctl_data data;
+ struct netxen_nic_ioctl_data *up_data;
+ int retval = 0;
+ struct netxen_statistics netxen_stats;
+
+ up_data = (void *)u_data;
+
+ DPRINTK(INFO, doing ioctl for %p\n, adapter);
+ if (copy_from_user(data, up_data, sizeof(data))) {
+ /* evil user tried to crash the kernel */
+ DPRINTK(ERR, bad copy from userland: %d\n, (int)sizeof(data));
+ retval = -EFAULT;
+ goto error_out;
+ }
+
+ /* Shouldn't access beyond legal limits of char u[64]; member */
+ if (!data.ptr (data.size sizeof(data.u))) {
+ /* evil user tried to crash the kernel */
+ DPRINTK(ERR, bad size: %d\n, data.size);
+ retval = -EFAULT;
+ goto error_out;
+ }
+
+ switch (data.cmd) {
+ case netxen_nic_cmd_pci_read:
+ if ((retval = netxen_nic_hw_read_wx(adapter, data.off,
+ (data.u), data.size)))
+ goto error_out;
+ if (copy_to_user((void *)(up_data-u), (data.u), data.size)) {
+ DPRINTK(ERR, bad copy to userland: %d\n,
+ (int)sizeof(data));
+ retval = -EFAULT;
+ goto error_out;
+ }
+ data.rv = 0;
+ break;
+
Can't you access the same registers area with ethtool.
+ case netxen_nic_cmd_pci_write:
+ data.rv = netxen_nic_hw_write_wx(adapter, data.off, (data.u),
+ data.size);
+ break;
+
+ case netxen_nic_cmd_pci_mem_read:
+ DPRINTK(INFO, doing %s for %p\n,
+ netxen_nic_cmd_pci_mm_rd, adapter);
+ netxen_nic_pci_mem_read(adapter, data.off, (data.u),
+ data.size);
+ if (copy_to_user((void *)(up_data-u), (data.u), data.size)) {
+ DPRINTK(ERR, bad copy to userland: %d\n,
+ (int)sizeof(data));
+ retval = -EFAULT;
+ goto error_out;
+ }
+ data.rv = 0;
+ DPRINTK(INFO, read %lx\n, (unsigned long)data.u);
+ break;
PCI memory is accessible directly through sysfs for diagnostic tools.
+ case netxen_nic_cmd_pci_mem_write:
+ netxen_nic_pci_mem_write(adapter, data.off, (data.u),
+ data.size);
+ data.rv = 0;/* write always succeeds */
+ break;
+
+ case netxen_nic_cmd_pci_config_read:
+ switch (data.size) {
+ case 1:
+ data.rv = pci_read_config_byte(adapter-ahw.pdev,
+data.off,
+(char *)(data.u));
+ break;
+ case 2:
+ data.rv = pci_read_config_word(adapter-ahw.pdev,
+data.off,
+(short *)(data.u));
+ break;
+ case 4:
+ data.rv = pci_read_config_dword(adapter-ahw.pdev,
+ data.off,
+ (u32 *) (data.u));
+ break;
+ }
+ if (copy_to_user((void *)(up_data-u), (data.u), data.size)) {
+ DPRINTK(ERR, bad copy to userland: %d\n,
+ (int)sizeof(data));
+ retval = -EFAULT;
+ goto error_out;
+ }
+ break;
+
+ case netxen_nic_cmd_pci_config_write:
+ switch (data.size) {
+ case 1:
+ data.rv = pci_write_config_byte(adapter-ahw.pdev,
+ data.off,
+ *(char *)(data.u));
+ break;
+ case 2:
+ data.rv = pci_write_config_word(adapter-ahw.pdev,
+ data.off,
+ *(short *)(data.u));
+ break;
+ case 4:
+ data.rv = pci_write_config_dword(adapter-ahw.pdev,
+ data.off,
+ *(u32 *) (data.u));
+ break;
+ }
+ break;
Re: [PATCH 8/9] Resending NetXen 1G/10G NIC driver patch
The object factoring is a mess here. You have too many allocations
and indirections. My expectation would be:
1. One PCI device maps to one board and that is the adapter structure
allocated with kzalloc. (You are doing this right)
2. An adapter can have up to four ports. Each of these should be a
netdevice and any port specific memory should be part of netdev_priv().
3. Have an array of pointers in the adapter structure for the maximum
possible value, if the board has less the memory waste for three
extra pointers is less than cost of dynamically sized array.
Something like
pci_prvdata - adapter -- dev[0] - netdevice { private data }
-- dev[1] ...
or
pci_privdata - adapter - port[0] - private data
- port[1]
In the later case, you need to have port-netdev pointer back to the
start of the net_device data structure.
If you do it this way, you won't need:
+ adapter-port = kcalloc(adapter-ahw.max_ports,
+ sizeof(struct netxen_adapter), GFP_KERNEL);
and
+ netlist = kzalloc(sizeof(struct netdev_list), GFP_KERNEL);
+ if (netlist == NULL)
+ goto err_out_free_dev;
Also, do you really need to have such a big TX ring that it requires
a vmalloc?
-
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 9/9] Resending NetXen 1G/10G NIC driver patch
+void netxen_delay(int value)
+{
+ unsigned long remainder;
+
+ remainder = value / 5;
+ do {
+ if (remainder 1000) {
+ udelay(1000);
+ remainder -= 1000;
+ } else {
+ udelay(remainder + 1);
+ remainder = 0;
+ }
+ } while (remainder 0);
+}
+
Defined, but never used. Why not just use mdelay if you
really are waiting that long?
+
+
+/**
+ * netxen_niu_gbe_set_mii_mode- Set 10/100 Mbit Mode for GbE MAC
+ *
+ **/
+void netxen_niu_gbe_set_mii_mode(struct netxen_adapter *adapter,
+long port, long enable)
+{
+ netxen_crb_writelit_adapter(adapter, NETXEN_NIU_MODE, 0x2);
+ netxen_crb_writelit_adapter(adapter, NETXEN_NIU_GB_MAC_CONFIG_0(port),
+ 0x8000);
+ netxen_crb_writelit_adapter(adapter, NETXEN_NIU_GB_MAC_CONFIG_0(port),
+ 0xf0025);
+ netxen_crb_writelit_adapter(adapter, NETXEN_NIU_GB_MAC_CONFIG_1(port),
+ 0xf1ff);
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_NIU_GB0_GMII_MODE + (port 3), 0);
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_NIU_GB0_MII_MODE + (port 3), 1);
+ netxen_crb_writelit_adapter(adapter,
+ (NETXEN_NIU_GB0_HALF_DUPLEX + port * 4), 0);
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_NIU_GB_MII_MGMT_CONFIG(port), 0x7);
+
+ if (enable) {
+ /*
+* Do NOT enable flow control until a suitable solution for
+* shutting down pause frames is found.
+*/
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_NIU_GB_MAC_CONFIG_0(port),
+ 0x5);
+ }
+
+ if (netxen_niu_gbe_enable_phy_interrupts(adapter, port))
+ printk(1ERROR enabling PHY interrupts\n);
Please use KERN_ERR not 1
+ if (netxen_niu_gbe_clear_phy_interrupts(adapter, port))
+ printk(1ERROR clearing PHY interrupts\n);
+}
+
+long netxen_niu_gbe_init_port(struct netxen_adapter *adapter, long port)
+{
+ long result = 0;
+ struct netxen_niu_phy_status status;
+
+ if (0 ==
+ netxen_niu_gbe_phy_read(adapter, port,
+ NETXEN_NIU_GB_MII_MGMT_ADDR_PHY_STATUS,
+ (netxen_crbword_t *) status)) {
You seem to like the style:
if (0 == foo())
It is not the current kernel fashion, but I'm okay with it.
+ if (status.link) {
+ if (status.speed == 2) {
+ netxen_niu_gbe_set_gmii_mode(adapter, port, 1);
+ } else if ((status.speed == 1) || (status.speed == 0)) {
+ netxen_niu_gbe_set_mii_mode(adapter, port, 1);
+ } else {
+ result = -1;
+ }
+
+ } else {
+ /* We don't have link. Cable must be unconnected. */
+ /* Enable phy interrupts so we take action when plugged
in */
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_NIU_GB_MAC_CONFIG_0
+ (port), 0x8000);
+ netxen_crb_writelit_adapter(adapter,
+ NETXEN_NIU_GB_MAC_CONFIG_0
+ (port), 0xf0025);
+ if (netxen_niu_gbe_clear_phy_interrupts(adapter, port))
+ printk(1ERROR clearing PHY interrupts\n);
+ if (netxen_niu_gbe_enable_phy_interrupts(adapter, port))
+ printk(1ERROR enabling PHY interrupts\n);
+ if (netxen_niu_gbe_clear_phy_interrupts(adapter, port))
+ printk(1ERROR clearing PHY interrupts\n);
+ result = -1;
+ }
+ } else {
+ result = -1;
+ }
+ return result;
+}
Wouldn't this just be clearer with:
long netxen_niu_gbe_init_port(struct netxen_adapter *adapter, long port)
{
int err;
struct netxen_niu_phy_status status;
err = netxen_niu_gbe_phy_read(adapter, port,
NETXEN_NIU_GB_MII_MGMT_ADDR_PHY_STATUS,
(netxen_crbword_t *) status);
if (err)
return err;
if (status.link) {
if (status.speed == 2)
netxen_niu_gbe_set_gmii_mode(adapter, port, 1);
else if
Re: reminder, 2.6.18 window...
On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote: I'll admit to not knowing all the intricacies of the kernel coding involved, but I don't offhand see how zeroing the stats would be significantly more complex than updating the stats during normal usage. But I'll have to leave that argument to the experts. What it boils down to is that currently, a single CPU or thread ever touches the stats concurrently, so it doesn't have to lock them or do anything special to ensure that the continue incrementing. If you want to make sure that the statistics actually reset when you want them to, you have to account for this case: CPU0 reads current value from memory (increment) CPU1 writes 0 to current value in memory (reset) CPU0 writes incremented value to memory (increment complete) Perhaps I'm missing something here, but these counters are only incrimented in hardware... i.e. attomically. And the reset I do is via a command register, which should also be atomic. Now in a driver that was keeping this all in a local struct, I could understand that need for locking, but in the skge case, and in fact in many drivers I've looked at, the numbers are all kept in the hardware, incremented by the hardware, as it gets packets. So clearing them via command registershouldn't need locking as far as I can tell. But please, correct me if I'm wrong. -- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin, 1759 signature.asc Description: Digital signature
Re: [PATCH 3/4] [IrDA] stir4200, switching to the kthread API
On Thu, 25 May 2006 06:19:44 + Samuel Ortiz [EMAIL PROTECTED] wrote: stir4200 uses a kernel thread for its TX/RX operations, and it is now converted to the kernel kthread API. Tested on an STIR4200 based dongle. Signed-off-by: Christoph Hellwig [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Looks 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
[PATCH] arlan: fix section mismatch warnings
From: Randy Dunlap [EMAIL PROTECTED]
Fix section mismatch warnings:
WARNING: drivers/net/wireless/arlan.o - Section mismatch: reference to
.init.text:arlan_probe from .text between 'init_module' (at offset
0x3526) and 'cleanup_module'
WARNING: drivers/net/wireless/arlan.o - Section mismatch: reference to
.init.text:init_arlan_proc from .text between 'init_module' (at offset
0x3539) and 'cleanup_module'
WARNING: drivers/net/wireless/arlan.o - Section mismatch: reference to
.exit.text:cleanup_arlan_proc from .text between 'cleanup_module' (at
offset 0x356c) and 'arlan_diagnostic_info_string'
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
drivers/net/wireless/arlan-main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2617-rc5.orig/drivers/net/wireless/arlan-main.c
+++ linux-2617-rc5/drivers/net/wireless/arlan-main.c
@@ -1838,7 +1838,7 @@ struct net_device * __init arlan_probe(i
}
#ifdef MODULE
-int init_module(void)
+int __init init_module(void)
{
int i = 0;
@@ -1860,7 +1860,7 @@ int init_module(void)
}
-void cleanup_module(void)
+void __exit cleanup_module(void)
{
int i = 0;
struct net_device *dev;
---
-
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] wavelan: fix section mismatch
From: Randy Dunlap [EMAIL PROTECTED]
Fix section mismatch warning:
WARNING: drivers/net/wireless/wavelan.o - Section mismatch: reference to
.init.text: from .text between 'init_module' (at offset 0x371e) and
'cleanup_module'
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
drivers/net/wireless/wavelan.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2617-rc5.orig/drivers/net/wireless/wavelan.c
+++ linux-2617-rc5/drivers/net/wireless/wavelan.c
@@ -4306,7 +4306,7 @@ out:
* Insertion of the module
* I'm now quite proud of the multi-device support.
*/
-int init_module(void)
+int __init init_module(void)
{
int ret = -EIO; /* Return error if no cards found */
int 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
[PATCH] ibmveth change buffer pools dynamically
Jeff,
Can you consider applying this patch? I haven't received any feedback
from netdev, but the changes are pretty straightforward (the majority of
the patch is setting up the sysfs interface).
This patch provides a sysfs interface to change some properties of the
ibmveth buffer pools (size of the buffers, number of buffers per pool,
and whether a pool is active). Ethernet drivers use ethtool to provide
this type of functionality. However, the buffers in the ibmveth driver
can have an arbitrary size (not only regular, mini, and jumbo which are
the only sizes that ethtool can change), and also ibmveth can have an
arbitrary number of buffer pools
Under heavy load we have seen dropped packets which obviously kills TCP
performance. We have created several fixes that mitigate this issue,
but we definitely need a way of changing the number of buffers for an
adapter dynamically. Also, changing the size of the buffers allows
users to change the MTU to something big (bigger than a jumbo frame)
greatly improving performance on partition to partition transfers.
The patch creates directories pool1...pool4 in the device directory in
sysfs, each with files: num, size, and active (which default to the
values in the mainline version).
Signed-off-by: Santiago Leon [EMAIL PROTECTED]
--
ibmveth.c | 211 +-
ibmveth.h |7 +-
2 files changed, 174 insertions(+), 44 deletions(-)
--- a/drivers/net/ibmveth.h 2006-01-02 21:21:10.0 -0600
+++ b/drivers/net/ibmveth.h 2006-04-18 10:20:00.102520432 -0500
@@ -75,10 +75,13 @@
#define IbmVethNumBufferPools 5
#define IBMVETH_BUFF_OH 22 /* Overhead: 14 ethernet header + 8 opaque handle */
+#define IBMVETH_MAX_MTU 68
+#define IBMVETH_MAX_POOL_COUNT 4096
+#define IBMVETH_MAX_BUF_SIZE (1024 * 128)
-/* pool_size should be sorted */
static int pool_size[] = { 512, 1024 * 2, 1024 * 16, 1024 * 32, 1024 * 64 };
static int pool_count[] = { 256, 768, 256, 256, 256 };
+static int pool_active[] = { 1, 1, 0, 0, 0};
#define IBM_VETH_INVALID_MAP ((u16)0x)
@@ -94,6 +97,7 @@ struct ibmveth_buff_pool {
dma_addr_t *dma_addr;
struct sk_buff **skbuff;
int active;
+struct kobject kobj;
};
struct ibmveth_rx_q {
@@ -118,6 +122,7 @@ struct ibmveth_adapter {
dma_addr_t filter_list_dma;
struct ibmveth_buff_pool rx_buff_pool[IbmVethNumBufferPools];
struct ibmveth_rx_q rx_queue;
+int pool_config;
/* adapter specific stats */
u64 replenish_task_cycles;
--- a/drivers/net/ibmveth.c 2006-01-02 21:21:10.0 -0600
+++ b/drivers/net/ibmveth.c 2006-04-18 10:19:55.624532480 -0500
@@ -96,6 +96,7 @@ static void ibmveth_proc_register_adapte
static void ibmveth_proc_unregister_adapter(struct ibmveth_adapter *adapter);
static irqreturn_t ibmveth_interrupt(int irq, void *dev_instance, struct
pt_regs *regs);
static inline void ibmveth_rxq_harvest_buffer(struct ibmveth_adapter *adapter);
+static struct kobj_type ktype_veth_pool;
#ifdef CONFIG_PROC_FS
#define IBMVETH_PROC_DIR net/ibmveth
@@ -133,12 +134,13 @@ static inline int ibmveth_rxq_frame_leng
}
/* setup the initial settings for a buffer pool */
-static void ibmveth_init_buffer_pool(struct ibmveth_buff_pool *pool, u32
pool_index, u32 pool_size, u32 buff_size)
+static void ibmveth_init_buffer_pool(struct ibmveth_buff_pool *pool, u32
pool_index, u32 pool_size, u32 buff_size, u32 pool_active)
{
pool-size = pool_size;
pool-index = pool_index;
pool-buff_size = buff_size;
pool-threshold = pool_size / 2;
+ pool-active = pool_active;
}
/* allocate and setup an buffer pool - called during open */
@@ -180,7 +182,6 @@ static int ibmveth_alloc_buffer_pool(str
atomic_set(pool-available, 0);
pool-producer_index = 0;
pool-consumer_index = 0;
- pool-active = 0;
return 0;
}
@@ -301,7 +302,6 @@ static void ibmveth_free_buffer_pool(str
kfree(pool-skbuff);
pool-skbuff = NULL;
}
- pool-active = 0;
}
/* remove a buffer from a pool */
@@ -433,7 +433,9 @@ static void ibmveth_cleanup(struct ibmve
}
for(i = 0; iIbmVethNumBufferPools; i++)
- ibmveth_free_buffer_pool(adapter, adapter-rx_buff_pool[i]);
+ if (adapter-rx_buff_pool[i].active)
+ ibmveth_free_buffer_pool(adapter,
+adapter-rx_buff_pool[i]);
}
static int ibmveth_open(struct net_device *netdev)
@@ -489,9 +491,6 @@ static int ibmveth_open(struct net_devic
adapter-rx_queue.num_slots = rxq_entries;
adapter-rx_queue.toggle = 1;
- /* call change_mtu to init the buffer pools based in initial mtu */
- ibmveth_change_mtu(netdev, netdev-mtu);
-
memcpy(mac_address, netdev-dev_addr, netdev-addr_len);
mac_address = mac_address 16;
@@ -522,6 +521,17 @@
Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem
Hi, On Tue, May 23, 2006 at 05:20:12PM -0700, Chris Leech wrote: +EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf); +EXPORT_SYMBOL(dma_async_memcpy_buf_to_pg); +EXPORT_SYMBOL(dma_async_memcpy_pg_to_pg); Is there a specific reason for why you chose to export 3 different memcpu calls? They're all just wrapped to the same internals. It would seem to make sense to have the client do their own page_address(page) + offset calculations and just export one function? -Olof - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] [I/OAT] Driver for the Intel(R) I/OAT DMA engine
Hi, Minor nitpick below: On Tue, May 23, 2006 at 05:20:13PM -0700, Chris Leech wrote: +static int enumerate_dma_channels(struct ioat_device *device) [...] + enumerate_dma_channels(device); Return value is never used, might as well change the function declaration to void. -Olof - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem
On Thu, May 25, 2006 at 10:59:40AM -0700, Olof Johansson wrote: Is there a specific reason for why you chose to export 3 different memcpu calls? They're all just wrapped to the same internals. It would seem to make sense to have the client do their own page_address(page) + offset calculations and just export one function? Nevermind. I'm too used to 64-bit environments where all memory is always addressable to the kernel. There's obvious reasons to do it on 32-bit platforms to avoid the extra kernel mapping. -Olof - 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] wavelan: fix section mismatch
On Thu, May 25, 2006 at 11:09:21AM -0700, Randy.Dunlap wrote:
From: Randy Dunlap [EMAIL PROTECTED]
Fix section mismatch warning:
WARNING: drivers/net/wireless/wavelan.o - Section mismatch: reference to
.init.text: from .text between 'init_module' (at offset 0x371e) and
'cleanup_module'
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
I did not check that kernel, but it seems a no brainer. Would
you mind sending to John Linville or Jeff Garzik as I'm about to go on
vacvation.
Thanks !
Jean
---
drivers/net/wireless/wavelan.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2617-rc5.orig/drivers/net/wireless/wavelan.c
+++ linux-2617-rc5/drivers/net/wireless/wavelan.c
@@ -4306,7 +4306,7 @@ out:
* Insertion of the module
* I'm now quite proud of the multi-device support.
*/
-int init_module(void)
+int __init init_module(void)
{
int ret = -EIO; /* Return error if no cards found */
int 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: reminder, 2.6.18 window...
On Thursday 25 May 2006 12:59, Phil Dibowitz wrote: On Thu, May 25, 2006 at 08:05:37AM -0500, Brent Cook wrote: I'll admit to not knowing all the intricacies of the kernel coding involved, but I don't offhand see how zeroing the stats would be significantly more complex than updating the stats during normal usage. But I'll have to leave that argument to the experts. What it boils down to is that currently, a single CPU or thread ever touches the stats concurrently, so it doesn't have to lock them or do anything special to ensure that the continue incrementing. If you want to make sure that the statistics actually reset when you want them to, you have to account for this case: CPU0 reads current value from memory (increment) CPU1 writes 0 to current value in memory (reset) CPU0 writes incremented value to memory (increment complete) Perhaps I'm missing something here, but these counters are only incrimented in hardware... i.e. attomically. No, you're right - I'm just thinking that once one driver has this ability, users are going to want it for all network devices, and implementation on some devices (namely virtual ones - lo, tun, tap, br, vlan) is trickier than just setting a register. Some hardware devices too - mv643xx_eth.c just increments the network stats in software, for instance. Lockless software reset is fine though as long as people understand the consequences - it's absolutely fine, given the way I would use reset in my environment, MMV. - 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: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Andrew Morton wrote: [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=6613 Summary: iptables broken on 32-bit PReP (ARCH=ppc) Kernel Version: 2.6.17-rc4 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: none known, this is a fresh install Distribution: Debian unstable Hardware Environment: 32-bit PowerPC 604 with PReP subarch (using old ARCH=ppc) Software Environment: usual 32-bit ppc userspace, gcc 4.0.3 Problem Description: iptables operations usually just give Incalida operation. modprobe iptable_filter and adding rules to the nat table have failed in testing while iptable_nat can be modprobed and listed. Steps to reproduce: modprobe iptable_filter (errors out with Invalid Argument) iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -j SNAT --to 192.168.1.1 (usually errors out with Invalid Argument, sometimes succeeds, when succeeds then the rule works fine) Meelis, it would really help if you could try 2.6.16 and in case that doesn't work 2.6.15 to give an idea about whether this is a recent regression or an old problem. We had a number of changes in this area in the last two kernel versions that could be related. - 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] wavelan: fix section mismatch
On Thu, 25 May 2006 11:39:49 -0700 Jean Tourrilhes wrote: On Thu, May 25, 2006 at 11:09:21AM -0700, Randy.Dunlap wrote: From: Randy Dunlap [EMAIL PROTECTED] Fix section mismatch warning: WARNING: drivers/net/wireless/wavelan.o - Section mismatch: reference to .init.text: from .text between 'init_module' (at offset 0x371e) and 'cleanup_module' Signed-off-by: Randy Dunlap [EMAIL PROTECTED] I did not check that kernel, but it seems a no brainer. Would you mind sending to John Linville or Jeff Garzik as I'm about to go on vacvation. Thanks ! Jean Hi, John L. was copied on the patch. Thanks, have a nice vacation. --- ~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: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Meelis, it would really help if you could try 2.6.16 and in case that doesn't work 2.6.15 to give an idea about whether this is a recent regression or an old problem. We had a number of changes in this area in the last two kernel versions that could be related. Yes, I'm still compiling 2.6.16, since just before sending the report. Will let you know ASAP. -- Meelis Roos ([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
[RFC 0/4] NetLabel
This patch introduces a new kernel feature designed to support labeled networking protocols such as RIPSO and CIPSO. These protocols are required to interoperate with existing trusted operating systems such as Trusted Solaris. I am posting the patch now not because I feel it is ready for inclusion into any of the main kernel trees but because it is usable and I would like to solicit comments from the community sooner rather than later. I know there has been at least one previous effort to get CIPSO support into the kernel and that was rejected. I have tried to take the feedback from that patch into consideration with this patch and create a new mechanism which treads as lightly as possible on the core networking stack. I have also worked to make the new patch LSM agnostic so that this code can be shared amongst multiple LSMs; while I am only providing a patch for SELinux at this point I do understand that there is at least one other LSM that is interested in making use of this new mechanism. I understand that there will probably need to be a lengthy review period due to the size and complexity of this patch. I also understand that my relative inexperience with submitting patches to the Linux kernel will not do much to help my cause but I appreciate your patience and any comments you may have. There is a more information as well as a basic userspace tool for configuration of the NetLabel subsystem here: * http://free.linux.hp.com/~pmoore/projects/linux_cipso Thanks. CREDITS |7 Documentation/00-INDEX|2 Documentation/netlabel/00-INDEX | 10 Documentation/netlabel/cipso_ipv4.txt | 48 Documentation/netlabel/draft-ietf-cipso-ipsecurity-01.txt | 791 + Documentation/netlabel/introduction.txt | 44 Documentation/netlabel/lsm_interface.txt | 47 include/linux/ip.h|1 include/linux/netlink.h |1 include/net/cipso_ipv4.h | 179 + include/net/inet_sock.h |2 include/net/netlabel.h| 355 ++ net/Kconfig |2 net/Makefile |1 net/ipv4/Makefile |1 net/ipv4/cipso_ipv4.c | 1568 ++ net/ipv4/ip_fragment.c| 38 net/ipv4/ip_options.c | 19 net/netlabel/Kconfig | 47 net/netlabel/Makefile | 15 net/netlabel/netlabel_cipso_v4.c | 519 +++ net/netlabel/netlabel_cipso_v4.h | 185 + net/netlabel/netlabel_domainhash.c| 629 net/netlabel/netlabel_domainhash.h| 64 net/netlabel/netlabel_kapi.c | 374 ++ net/netlabel/netlabel_mgmt.c | 686 net/netlabel/netlabel_mgmt.h | 265 + net/netlabel/netlabel_unlabeled.c | 289 + net/netlabel/netlabel_unlabeled.h | 90 net/netlabel/netlabel_user.c | 166 + net/netlabel/netlabel_user.h | 42 security/selinux/hooks.c | 64 security/selinux/include/security.h |6 security/selinux/ss/ebitmap.c | 155 security/selinux/ss/ebitmap.h |6 security/selinux/ss/mls.c | 160 + security/selinux/ss/mls.h | 25 security/selinux/ss/services.c| 252 + security/selinux/xfrm.c | 22 39 files changed, 7156 insertions(+), 21 deletions(-) -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] pci_ids: add new device ids
This patch adds new device ids for MCP61 and MCP65 chips. Signed-Off-By: Ayaz Abdulla [EMAIL PROTECTED] --- a/include/linux/pci_ids.h 2006-05-25 13:02:56.0 -0400 +++ b/include/linux/pci_ids.h 2006-05-25 13:03:09.0 -0400 @@ -1182,6 +1182,14 @@ #define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E #define PCI_DEVICE_ID_NVIDIA_NVENET_14 0x0372 #define PCI_DEVICE_ID_NVIDIA_NVENET_15 0x0373 +#define PCI_DEVICE_ID_NVIDIA_NVENET_16 0x03E5 +#define PCI_DEVICE_ID_NVIDIA_NVENET_17 0x03E6 +#define PCI_DEVICE_ID_NVIDIA_NVENET_18 0x03EE +#define PCI_DEVICE_ID_NVIDIA_NVENET_19 0x03EF +#define PCI_DEVICE_ID_NVIDIA_NVENET_20 0x0450 +#define PCI_DEVICE_ID_NVIDIA_NVENET_21 0x0451 +#define PCI_DEVICE_ID_NVIDIA_NVENET_22 0x0452 +#define PCI_DEVICE_ID_NVIDIA_NVENET_23 0x0453 #define PCI_VENDOR_ID_IMS 0x10e0 #define PCI_DEVICE_ID_IMS_TT1280x9128
[PATCH 1/2] [TCP-LP] Kconfig and Makefile
TCP Low Priority is a distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the ``fair share`` of bandwidth as targeted by TCP. Available from: http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf Original Author: Aleksandar Kuzmanovic [EMAIL PROTECTED] See http://www-ece.rice.edu/networks/TCP-LP/ for their implementation. As of 2.6.13, Linux supports pluggable congestion control algorithms. Due to the limitation of the API, we take the following changes from the original TCP-LP implementation: o We use newReno in most core CA handling. Only add some checking within cong_avoid. o Error correcting in remote HZ, therefore remote HZ will be keeped on checking and updating. o Handling calculation of One-Way-Delay (OWD) within rtt_sample, sicne OWD have a similar meaning as RTT. Also correct the buggy formular. o Handle reaction for Early Congestion Indication (ECI) within pkts_acked, as mentioned within pseudo code. o OWD is handled in relative format, where local time stamp will in tcp_time_stamp format. Port from 2.4.19 to 2.6.16 as module by: Wong Hoi Sing Edison [EMAIL PROTECTED] Hung Hing Lun [EMAIL PROTECTED] Signed-off-by: Wong Hoi Sing Edison [EMAIL PROTECTED] --- diff -urpN linux-2.6.16.14/net/ipv4/Kconfig linux/net/ipv4/Kconfig --- linux-2.6.16.14/net/ipv4/Kconfig2006-05-05 08:03:45.0 +0800 +++ linux/net/ipv4/Kconfig 2006-05-07 01:41:33.0 +0800 @@ -531,6 +531,27 @@ config TCP_CONG_SCALABLE properties, though is known to have fairness issues. See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/ +config TCP_CONG_LP + tristate TCP Low Priority + depends on EXPERIMENTAL + default n + ---help--- + TCP Low Priority (TCP-LP), a distributed algorithm whose goal is + to utiliza only the excess network bandwidth as compared to the + ``fair share`` of bandwidth as targeted by TCP. + See http://www-ece.rice.edu/networks/TCP-LP/ + +config TCP_CONG_LP_DEBUG + bool TCP-LP Debug + depends on TCP_CONG_LP + default n + ---help--- + Turn on/off the debug message for TCP-LP. The debug message will + print to default kernel debug log file, e.g. /var/log/debug as + default. You can use dmesg to obtain the log too. + + If unsure, say N. + endmenu config TCP_CONG_BIC diff -urpN linux-2.6.16.14/net/ipv4/Makefile linux/net/ipv4/Makefile --- linux-2.6.16.14/net/ipv4/Makefile 2006-05-05 08:03:45.0 +0800 +++ linux/net/ipv4/Makefile 2006-05-07 01:41:33.0 +0800 @@ -41,6 +41,7 @@ obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybl obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o +obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \ xfrm4_output.o - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [TCP-LP] congestion control module
Signed-off-by: Wong Hoi Sing Edison [EMAIL PROTECTED]
---
diff -urpN linux-2.6.16.14/net/ipv4/tcp_lp.c linux/net/ipv4/tcp_lp.c
--- linux-2.6.16.14/net/ipv4/tcp_lp.c 1970-01-01 08:00:00.0 +0800
+++ linux/net/ipv4/tcp_lp.c 2006-05-07 01:41:33.0 +0800
@@ -0,0 +1,343 @@
+/*
+ * TCP Low Priority (TCP-LP)
+ *
+ * TCP Low Priority is a distributed algorithm whose goal is to utilize only
+ * the excess network bandwidth as compared to the ``fair share`` of
+ * bandwidth as targeted by TCP. Available from:
+ * http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf
+ *
+ * Original Author:
+ * Aleksandar Kuzmanovic [EMAIL PROTECTED]
+ *
+ * See http://www-ece.rice.edu/networks/TCP-LP/ for their implementation.
+ * As of 2.6.13, Linux supports pluggable congestion control algorithms.
+ * Due to the limitation of the API, we take the following changes from
+ * the original TCP-LP implementation:
+ * o We use newReno in most core CA handling. Only add some checking
+ * within cong_avoid.
+ * o Error correcting in remote HZ, therefore remote HZ will be keeped
+ * on checking and updating.
+ * o Handling calculation of One-Way-Delay (OWD) within rtt_sample, sicne
+ * OWD have a similar meaning as RTT. Also correct the buggy formular.
+ * o Handle reaction for Early Congestion Indication (ECI) within
+ * pkts_acked, as mentioned within pseudo code.
+ * o OWD is handled in relative format, where local time stamp will in
+ * tcp_time_stamp format.
+ *
+ * Port from 2.4.19 to 2.6.16 as module by:
+ * Wong Hoi Sing Edison [EMAIL PROTECTED]
+ * Hung Hing Lun [EMAIL PROTECTED]
+ *
+ * Version: $Id: tcp_lp.c,v 1.22 2006-05-02 18:18:19 hswong3i Exp $
+ */
+
+#include linux/config.h
+#include linux/module.h
+#include net/tcp.h
+
+#ifndef CONFIG_TCP_CONG_LP_DEBUG
+#define CONFIG_TCP_CONG_LP_DEBUG 0
+#endif
+
+/* resolution of owd */
+#define LP_RESOL 1000
+
+/**
+ * enum tcp_lp_state
+ * @LP_VALID_RHZ: is remote HZ valid?
+ * @LP_VALID_OWD: is OWD valid?
+ * @LP_WITHIN_THR: are we within threshold?
+ * @LP_WITHIN_INF: are we within inference?
+ *
+ * TCP-LP's state flags.
+ * We create this set of state flag mainly for debugging.
+ */
+enum tcp_lp_state {
+ LP_VALID_RHZ = (1 0),
+ LP_VALID_OWD = (1 1),
+ LP_WITHIN_THR = (1 3),
+ LP_WITHIN_INF = (1 4),
+};
+
+/**
+ * struct lp
+ * @flag: TCP-LP state flag
+ * @sowd: smoothed OWD 3
+ * @owd_min: min OWD
+ * @owd_max: max OWD
+ * @owd_max_rsv: resrved max owd
+ * @remote_hz: estimated remote HZ
+ * @remote_ref_time: remote reference time
+ * @local_ref_time: local reference time
+ * @last_drop: time for last active drop
+ * @inference: current inference
+ *
+ * TCP-LP's private struct.
+ * We get the idea from original TCP-LP implementation where only left those we
+ * found are really useful.
+ */
+struct lp {
+ u32 flag;
+ u32 sowd;
+ u32 owd_min;
+ u32 owd_max;
+ u32 owd_max_rsv;
+ u32 remote_hz;
+ u32 remote_ref_time;
+ u32 local_ref_time;
+ u32 last_drop;
+ u32 inference;
+};
+
+/**
+ * tcp_lp_init
+ *
+ * Init all required variables.
+ * Clone the handling from Vegas module implementation.
+ */
+static void tcp_lp_init(struct sock *sk)
+{
+ struct lp *lp = inet_csk_ca(sk);
+
+ lp-flag = 0;
+ lp-sowd = 0;
+ lp-owd_min = 0x;
+ lp-owd_max = 0;
+ lp-owd_max_rsv = 0;
+ lp-remote_hz = 0;
+ lp-remote_ref_time = 0;
+ lp-local_ref_time = 0;
+ lp-last_drop = 0;
+ lp-inference = 0;
+}
+
+/**
+ * tcp_lp_cong_avoid
+ *
+ * Implementation of cong_avoid.
+ * Will only call newReno CA when away from inference.
+ * From TCP-LP's paper, this will be handled in additive increasement.
+ */
+static void tcp_lp_cong_avoid(struct sock *sk, u32 ack, u32 rtt, u32 in_flight,
+ int flag)
+{
+ struct lp *lp = inet_csk_ca(sk);
+
+ if (!(lp-flag LP_WITHIN_INF))
+ tcp_reno_cong_avoid(sk, ack, rtt, in_flight, flag);
+}
+
+/**
+ * tcp_lp_remote_hz_estimator
+ *
+ * Estimate remote HZ.
+ * We keep on updating the estimated value, where original TCP-LP
+ * implementation only guest it for once and use forever.
+ */
+static inline u32 tcp_lp_remote_hz_estimator(struct sock *sk)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct lp *lp = inet_csk_ca(sk);
+ s64 rhz = lp-remote_hz 6; /* remote HZ 6 */
+ s64 m = 0;
+
+ /* not yet record reference time
+* go away!! record it before come back!! */
+ if (lp-remote_ref_time == 0 || lp-local_ref_time == 0)
+ goto out;
+
+ /* we can't calc remote HZ with no different!! */
+ if (tp-rx_opt.rcv_tsval == lp-remote_ref_time
+ || tp-rx_opt.rcv_tsecr == lp-local_ref_time)
+ goto out;
+
+ m = HZ * (tp-rx_opt.rcv_tsval -
+ lp-remote_ref_time) / (tp-rx_opt.rcv_tsecr -
+
Re: ipv6 routing broken in 2.6.17-rc3,4
On my home 6to4 gw, ipv6 routing seems to be broken and everything is sent to 6to4 tunnel (the default route). It worked with fine for a long time and with 2.6.17-rc2-g4d5c34ec and it's broken with vmlinuz-2.6.17-rc3-g3cd73eed and 2.6.17-rc4-g9be2f7c3 (yesterdays kernel). So far I have narrowed it down to break between 2.6.16 (working) and 2.6.17-rc1 (not working). -- Meelis Roos ([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] ibmveth change buffer pools dynamically
Santiago Leon wrote: Jeff, Can you consider applying this patch? I haven't received any feedback from netdev, but the changes are pretty straightforward (the majority of the patch is setting up the sysfs interface). It's already in netdev-2.6.git#upstream... - 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 Veno module for kernel 2.6.16.13
From: #ZHOU BIN# [EMAIL PROTECTED] Date: Thu, 25 May 2006 16:30:48 +0800 Yes, I agree. Actually the main contribution of TCP Veno is not in this AI phase. No matter the ABC is added or not, TCP Veno can always improve the performance over wireless networks, according to our tests. It seems to me that the wireless issue is seperate from congestion control. The key is to identify true loss due to overflow of intermediate router queues, vs. false loss which is due to temporary radio signal interference. This determination is a job for the loss detection in the generic ACK processing code in tcp_input.c, not for a congestion control algorithm. The congestion control algorithm uses the true loss information to make congestion control decisions. We already have code that tries to make this differentiation, in the form of FRTO, and your techniques can likely be placed there as well. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ixgb: add performance enhancements to the buffer_info struct
o modify the rx refill logic and tail bump
o add counter for failures
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Signed-off-by: John Ronciak [EMAIL PROTECTED]
---
drivers/net/ixgb/ixgb.h |1 +
drivers/net/ixgb/ixgb_main.c | 74 +-
2 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
index b9c37fd..bdbaf5a 100644
--- a/drivers/net/ixgb/ixgb.h
+++ b/drivers/net/ixgb/ixgb.h
@@ -200,6 +200,7 @@ struct ixgb_adapter {
struct ixgb_hw hw;
u16 msg_enable;
struct ixgb_hw_stats stats;
+ uint32_t alloc_rx_buff_failed;
#ifdef CONFIG_PCI_MSI
boolean_t have_msi;
#endif
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 0905a82..27034b3 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -929,17 +929,20 @@ ixgb_unmap_and_free_tx_resource(struct i
struct ixgb_buffer *buffer_info)
{
struct pci_dev *pdev = adapter-pdev;
- if(buffer_info-dma) {
- pci_unmap_page(pdev,
- buffer_info-dma,
- buffer_info-length,
- PCI_DMA_TODEVICE);
- buffer_info-dma = 0;
- }
- if(buffer_info-skb) {
+
+ if (buffer_info-dma)
+ pci_unmap_page(pdev, buffer_info-dma, buffer_info-length,
+ PCI_DMA_TODEVICE);
+
+ if (buffer_info-skb)
dev_kfree_skb_any(buffer_info-skb);
- buffer_info-skb = NULL;
- }
+
+ buffer_info-skb = NULL;
+ buffer_info-dma = 0;
+ buffer_info-time_stamp = 0;
+ /* these fields must always be initialized in tx
+* buffer_info-length = 0;
+* buffer_info-next_to_watch = 0; */
}
/**
@@ -1314,6 +1317,7 @@ ixgb_tx_map(struct ixgb_adapter *adapter
size,
PCI_DMA_TODEVICE);
buffer_info-time_stamp = jiffies;
+ buffer_info-next_to_watch = 0;
len -= size;
offset += size;
@@ -1345,6 +1349,7 @@ ixgb_tx_map(struct ixgb_adapter *adapter
size,
PCI_DMA_TODEVICE);
buffer_info-time_stamp = jiffies;
+ buffer_info-next_to_watch = 0;
len -= size;
offset += size;
@@ -1940,6 +1945,7 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a
#endif
status = rx_desc-status;
skb = buffer_info-skb;
+ buffer_info-skb = NULL;
prefetch(skb-data);
@@ -2013,7 +2019,6 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a
rxdesc_done:
/* clean up descriptor, might be written over by hw */
rx_desc-status = 0;
- buffer_info-skb = NULL;
/* use prefetched values */
rx_desc = next_rxd;
@@ -2053,12 +2058,18 @@ ixgb_alloc_rx_buffers(struct ixgb_adapte
/* leave three descriptors unused */
while(--cleancount 2) {
- rx_desc = IXGB_RX_DESC(*rx_ring, i);
-
- skb = dev_alloc_skb(adapter-rx_buffer_len + NET_IP_ALIGN);
+ /* recycle! its good for you */
+ if (!(skb = buffer_info-skb))
+ skb = dev_alloc_skb(adapter-rx_buffer_len
+ + NET_IP_ALIGN);
+ else {
+ skb_trim(skb, 0);
+ goto map_skb;
+ }
- if(unlikely(!skb)) {
+ if (unlikely(!skb)) {
/* Better luck next round */
+ adapter-alloc_rx_buff_failed++;
break;
}
@@ -2072,33 +2083,36 @@ ixgb_alloc_rx_buffers(struct ixgb_adapte
buffer_info-skb = skb;
buffer_info-length = adapter-rx_buffer_len;
- buffer_info-dma =
- pci_map_single(pdev,
- skb-data,
- adapter-rx_buffer_len,
- PCI_DMA_FROMDEVICE);
+map_skb:
+ buffer_info-dma = pci_map_single(pdev,
+ skb-data,
+ adapter-rx_buffer_len,
+ PCI_DMA_FROMDEVICE);
+ rx_desc = IXGB_RX_DESC(*rx_ring, i);
rx_desc-buff_addr = cpu_to_le64(buffer_info-dma);
/* guarantee DD bit not set now before h/w gets descriptor
* this is the rest of the workaround for h/w double
* writeback. */
[PATCH 2/3] ixgb: use rx copybreak/skb recycle
o use rx copybreak/skb recycle
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Signed-off-by: John Ronciak [EMAIL PROTECTED]
---
drivers/net/ixgb/ixgb_main.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index 27034b3..0e23994 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -1990,6 +1990,26 @@ ixgb_clean_rx_irq(struct ixgb_adapter *a
goto rxdesc_done;
}
+ /* code added for copybreak, this should improve
+* performance for small packets with large amounts
+* of reassembly being done in the stack */
+#define IXGB_CB_LENGTH 256
+ if (length IXGB_CB_LENGTH) {
+ struct sk_buff *new_skb =
+ dev_alloc_skb(length + NET_IP_ALIGN);
+ if (new_skb) {
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ new_skb-dev = netdev;
+ memcpy(new_skb-data - NET_IP_ALIGN,
+ skb-data - NET_IP_ALIGN,
+ length + NET_IP_ALIGN);
+ /* save the skb in buffer_info as good */
+ buffer_info-skb = skb;
+ skb = new_skb;
+ }
+ }
+ /* end copybreak code */
+
/* Good Receive */
skb_put(skb, length);
--
Auke Kok [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: reminder, 2.6.18 window...
From: Phil Dibowitz [EMAIL PROTECTED] Date: Thu, 25 May 2006 12:22:39 -0700 So at least, for the _current_ implimentations, this should have no performance impacts. Regardless, I think this is something that userspace _can_ take care of reasonably and therefore has no buisness in the kernel. We do not duplicate functionality that is already possible _unless_ it is incredibly difficult for userland to do so. And in this case I do not think it is difficult for userland to interpret the counters in the way you want it to. So, major NACK on this stuff. - 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 Compound
The existing code did a 64 bit divide directly, which won't work on
32 bit platforms. This is what I am testing, it uses math similar to
TCP CUBIC to do a quad root. It seemed more efficient to just do
one operation rather than two square roots.
-
diff --git a/net/ipv4/tcp_compound.c b/net/ipv4/tcp_compound.c
index 01048e2..74c26a0 100644
--- a/net/ipv4/tcp_compound.c
+++ b/net/ipv4/tcp_compound.c
@@ -52,8 +52,6 @@
#define TCP_COMPOUND_ALPHA 3U
#define TCP_COMPOUND_BETA 1U
-#define TCP_COMPOUND_KAPPA_POW 3
-#define TCP_COMPOUND_KAPPA_NSQRT2
#define TCP_COMPOUND_GAMMA 30
#define TCP_COMPOUND_ZETA 1
@@ -156,6 +154,58 @@ static void tcp_compound_state(struct so
vegas_disable(sk);
}
+
+/* 64bit divisor, dividend and result. dynamic precision */
+static inline u64 div64_64(u64 dividend, u64 divisor)
+{
+ u32 d = divisor;
+
+ if (divisor 0xULL) {
+ unsigned int shift = fls(divisor 32);
+
+ d = divisor shift;
+ dividend = shift;
+ }
+
+ /* avoid 64 bit division if possible */
+ if (dividend 32)
+ do_div(dividend, d);
+ else
+ dividend = (u32) dividend / d;
+
+ return dividend;
+}
+
+/* calculate the quartic root of a using Newton-Raphson */
+static u32 qroot(u64 a)
+{
+ u32 x, x1;
+
+ /* Initial estimate is based on:
+* qrt(x) = exp(log(x) / 4)
+*/
+ x = 1u (fls64(a) 2);
+
+ /*
+* Iteration based on:
+* 3
+* x= ( 3 * x + a / x ) / 4
+* k+1 k k
+*/
+ do {
+ u64 x3 = x;
+
+ x1 = x;
+ x3 *= x;
+ x3 *= x;
+
+ x = (3 * x + (u32) div64_64(a, x3)) / 4;
+ } while (abs(x1 - x) 1);
+
+ return x;
+}
+
+
/*
* If the connection is idle and we are restarting,
* then we don't want to do any Vegas calculations
@@ -307,29 +357,23 @@ static void tcp_compound_cong_avoid(stru
dwnd = vegas-dwnd;
if (diff (TCP_COMPOUND_GAMMA V_PARAM_SHIFT)) {
- u32 i, j, x, x2;
- u64 v;
-
- v = 1;
-
- for (i = 0; i TCP_COMPOUND_KAPPA_POW; i++)
- v *= old_wnd;
-
- for (i = 0; i TCP_COMPOUND_KAPPA_NSQRT; i++) {
- x = 1;
- for (j = 0; j 200; j++) {
- x2 = (x + v / x) / 2;
-
- if (x2 == x || !x2)
- break;
-
- x = x2;
- }
- v = x;
- }
+ u64 win3;
- x = (u32) v TCP_COMPOUND_ALPHA;
+ /*
+* The TCP Compound paper describes the choice
+* of k determines the agressiveness,
+* ie. slope of the response function.
+*
+* For same value as HSTCP would be 0.8
+* but for computaional reasons, both the
+* original authors and this implementation
+* use 0.75.
+*/
+ win3 = old_wnd;
+ win3 *= old_wnd;
+ win3 *= old_wnd;
+ x = qroot(win3) TCP_COMPOUND_ALPHA;
if (x 1)
dwnd = x - 1;
else
-
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 Veno module for kernel 2.6.16.13
On Thu, 25 May 2006 13:23:50 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: #ZHOU BIN# [EMAIL PROTECTED] Date: Thu, 25 May 2006 16:30:48 +0800 Yes, I agree. Actually the main contribution of TCP Veno is not in this AI phase. No matter the ABC is added or not, TCP Veno can always improve the performance over wireless networks, according to our tests. It seems to me that the wireless issue is seperate from congestion control. The key is to identify true loss due to overflow of intermediate router queues, vs. false loss which is due to temporary radio signal interference. Is it really possible to tell the two apart. Also, a lot of times when an access point is overloaded, performance is killed because of congestion overload. This determination is a job for the loss detection in the generic ACK processing code in tcp_input.c, not for a congestion control algorithm. The congestion control algorithm uses the true loss information to make congestion control decisions. We already have code that tries to make this differentiation, in the form of FRTO, and your techniques can likely be placed there as well. The general idea of resetting cwnd to an estimate of capacity seems to be a general feature of Westwood, Veno, Compound and Africa. Also FreeBSD does the same thing, but they don't have a cool name. - 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: reminder, 2.6.18 window...
From: Phil Dibowitz [EMAIL PROTECTED] Date: Thu, 25 May 2006 14:04:12 -0700 why would specifically not support a _feature_ of the hardware. Sparc64 chips support a hash table like hw assist feature for TLB reloading, I didn't use it for 8+ years and went with a virtual page table approach instead. I mean, your statement is totally meaningless. Just because the hardware can do something, doesn't mean we have any reason to use that functionality. - 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 Veno module for kernel 2.6.16.13
From: Stephen Hemminger [EMAIL PROTECTED] Date: Thu, 25 May 2006 13:50:11 -0700 The general idea of resetting cwnd to an estimate of capacity seems to be a general feature of Westwood, Veno, Compound and Africa. Also FreeBSD does the same thing, but they don't have a cool name. Interesting point. Eventually such an idea would need to be integrated into another scheme such as CUBIC, instead of being an entirely different congestion control scheme, if we ever want to have this facility in a default congestion control algorithm. - 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
e1000: add WoL fix for 2.6.17rc
Jeff,
Please queue the 'e1000: add shutdown handler back for WoL' for 2.6.17rc's.
Since this fix is already committed to jgarzik/netdev-2.6#upstream, you can
cherrypick it into #upstream-fixes:
$ git-cherry-pick c653e6351e371b33b29871e5eedf610ffb3be037
Cheers,
Auke
e1000: add shutdown handler back to fix WOL
Someone was waaay too aggressive and removed e1000's reboot notifier
instead of porting it to the new way of the shutdown handler. This change
broke wake on lan. Add the shutdown handler back in using the same method
as e100 uses.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index fb8cef6..b224e40 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -221,6 +221,7 @@ static void e1000_restore_vlan(struct e1
static int e1000_suspend(struct pci_dev *pdev, pm_message_t state);
static int e1000_resume(struct pci_dev *pdev);
#endif
+static void e1000_shutdown(struct pci_dev *pdev);
#ifdef CONFIG_NET_POLL_CONTROLLER
/* for netdump / net console */
@@ -236,8 +237,9 @@ static struct pci_driver e1000_driver =
/* Power Managment Hooks */
#ifdef CONFIG_PM
.suspend = e1000_suspend,
- .resume = e1000_resume
+ .resume = e1000_resume,
#endif
+ .shutdown = e1000_shutdown
};
MODULE_AUTHOR(Intel Corporation, [EMAIL PROTECTED]);
@@ -4605,6 +4607,12 @@ e1000_resume(struct pci_dev *pdev)
return 0;
}
#endif
+
+static void e1000_shutdown(struct pci_dev *pdev)
+{
+ e1000_suspend(pdev, PMSG_SUSPEND);
+}
+
#ifdef CONFIG_NET_POLL_CONTROLLER
/*
* Polling 'interrupt' - used by things like netconsole to send skbs
RE: [PATCH] TCP Veno module for kernel 2.6.16.13
[EMAIL PROTECTED] wrote: On Thu, 25 May 2006 13:23:50 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: #ZHOU BIN# [EMAIL PROTECTED] Date: Thu, 25 May 2006 16:30:48 +0800 Yes, I agree. Actually the main contribution of TCP Veno is not in this AI phase. No matter the ABC is added or not, TCP Veno can always improve the performance over wireless networks, according to our tests. It seems to me that the wireless issue is seperate from congestion control. The key is to identify true loss due to overflow of intermediate router queues, vs. false loss which is due to temporary radio signal interference. Is it really possible to tell the two apart. Loss due to true congestion as opposed to loss due to radio signal interference (true loss, but falsely inferred to be congestion) is actually very possible, at L2 and only if the hop experiencing problems is the first or last hop. There are numerous indicators that the link is experiencing link-related drops (FEC corrections, signal to noise, etc.). The *desirability* of using this data is debatable, but it most certainly is possible. - 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 0/4] NetLabel
Stephen Hemminger wrote: On Thu, 25 May 2006 16:06:01 -0400 Paul Moore [EMAIL PROTECTED] wrote: This patch introduces a new kernel feature designed to support labeled networking protocols such as RIPSO and CIPSO. These protocols are required to interoperate with existing trusted operating systems such as Trusted Solaris. I am posting the patch now not because I feel it is ready for inclusion into any of the main kernel trees but because it is usable and I would like to solicit comments from the community sooner rather than later. Maybe this would be easier and better done via existing netfilter infrastructure? I think this would be rather difficult on the outbound side as protocols like CIPSO and RIPSO add IP options to the packet. I may be wrong but I thought that adding to the size of the packet was a no-no in netfilter? Also, doesn't netfilter get the packet after the checksum has been calculated and the packet has gone through the xfrm infrastructure? -- paul moore linux security @ hp - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] pci: bcm43xx kill pci_find_device
On Thursday 25 May 2006 02:45, you wrote:
Jiri Slaby wrote:
bcm43xx kill pci_find_device
Change pci_find_device to safer pci_get_device.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 75664d3c6fe1d8d00b87e42cc001cb5d90613dae
tree ebcec31955a991f1661197c7e8bcdd682e030681
parent 431ef31d431939bc9370f952d9510ab9e5b0ad47
author Jiri Slaby [EMAIL PROTECTED] Thu, 25 May 2006 02:04:38 +0159
committer Jiri Slaby [EMAIL PROTECTED] Thu, 25 May 2006 02:04:38 +0159
drivers/net/wireless/bcm43xx/bcm43xx_main.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index b488f77..f770f59 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2142,9 +2142,10 @@ #ifdef CONFIG_BCM947XX
if (bcm-pci_dev-bus-number == 0) {
struct pci_dev *d = NULL;
/* FIXME: we will probably need more device IDs here... */
- d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
+ d = pci_get_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
if (d != NULL) {
bcm-irq = d-irq;
+ pci_dev_put(d);
Given the FIXME, if you are going to touch this area, it seems logical
to add a PCI device match table.
Yes, you may want to discuss that with the openwrt people, as this
code is only openwrt related.
-
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 Veno module for kernel 2.6.16.13
From: Caitlin Bestler [EMAIL PROTECTED] Date: Thu, 25 May 2006 14:11:03 -0700 The *desirability* of using this data is debatable, but it most certainly is possible. Right, I don't think these kinds of schemes scale very well personally. I think TCP can certainly infer these attributes using existing information. With %100 precision, no of course not, but definitely a good enough approximation for real use. - 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/5] LLC SOCK_DGRAM enhancements
From: Stephen Hemminger [EMAIL PROTECTED] Date: Tue, 23 May 2006 17:04:14 -0700 I want to use AF_LLC and SOCK_DGRAM for handling Spanning Tree Protocol packets in user space. The existing code doesn't work and also doesn't support multicast. These basic problems and add some cleanups. All applied, thanks Stephen. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6610] New: dummy interface broadcast destination hardware address is not ff:ff:ff:ff:ff:ff
From: Herbert Xu [EMAIL PROTECTED] Date: Wed, 24 May 2006 11:10:54 +1000 David Miller [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] Date: Tue, 23 May 2006 16:31:42 -0700 Summary: dummy interface broadcast destination hardware address is not ff:ff:ff:ff:ff:ff Very strange because the dummy device driver calls ether_setup() which does: It's caused by the NO_ARP flag. Perhaps RTN_BROADCAST should take precedence over IFF_NOARP (but not IFF_LOOPBACK)? I'm talking about the code in net/ipv4/arp.c that causes this behavior. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] bridge patches for 2.6.18
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 24 May 2006 10:12:16 -0700 Some stuff for 2.6.18. The most important is adding netlink support for managing interfaces; this allows building STP as an application. Applied to net-2.6.18, thanks Stephen. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] [IrDA] *_DONGLE should depend on IRTTY_SIR
From: Samuel Ortiz [EMAIL PROTECTED] Date: Thu, 25 May 2006 06:18:51 + If a SIR dongle is built in the kernel while IRTTY_SIR is built as a module, kernel compilation will fail. Thus, the SIR dongle config should depend on the IRTTY_SIR. Closes kernel bug# 6512 (http://bugzilla.kernel.org/show_bug.cgi?id=6512) Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Bug fix, so applied to net-2.6, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] [IrDA] Initial support for MCS7780 based dongles
From: Samuel Ortiz [EMAIL PROTECTED] Date: Thu, 25 May 2006 06:19:27 + The MosChip MCS7780 chipset is an IrDA USB bridge that doesn't conform with the IrDA-USB standard and thus needs its separate driver. Tested on an actual MCS7780 based dongle. Original implementation by Brian Pugh [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] New feature, so applied to net-2.6.18, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] [IrDA] ali-ircc: using device model power management
From: Samuel Ortiz [EMAIL PROTECTED] Date: Thu, 25 May 2006 06:20:52 + This patch gets rid of the old power management code and now uses the device model for the ali-ircc driver. Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Enhancement, thus applied to net-2.6.18 Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] [IrDA] stir4200, switching to the kthread API
From: Samuel Ortiz [EMAIL PROTECTED] Date: Thu, 25 May 2006 06:19:44 + stir4200 uses a kernel thread for its TX/RX operations, and it is now converted to the kernel kthread API. Tested on an STIR4200 based dongle. Signed-off-by: Christoph Hellwig [EMAIL PROTECTED] Signed-off-by: Samuel Ortiz [EMAIL PROTECTED] Enhancement, cleanup, and not a bug fix, so applied to net-2.6.18 Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.17-rc5] pcnet32: remove incorrect pcnet32_free_ring
During a code scan for another change I discovered that this call to pcnet32_free_ring must be removed. If the open fails due to a lack of memory all the ring structures are removed via the call to free_ring and a subsequent call to open will dereference a null pointer in pcnet32_init_ring. Please apply to 2.6.17. Signed-off-by: Don Fry [EMAIL PROTECTED] --- linux-2.6.17-rc5/drivers/net/orig.pcnet32.c 2006-05-25 15:59:12.0 -0700 +++ linux-2.6.17-rc5/drivers/net/pcnet32.c 2006-05-25 16:09:40.0 -0700 @@ -1774,8 +1774,6 @@ static int pcnet32_open(struct net_devic lp-rx_dma_addr[i] = 0; } - pcnet32_free_ring(dev); - /* * Switch back to 16bit mode to avoid problems with dumb * DOS packet driver after a warm reboot -- Don Fry [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: ipv6 routing broken in 2.6.17-rc3,4
(To YOSHIFUJI Hideaki: this is about the http://comments.gmane.org/gmane.linux.network/35262 thread) Tracked it down to IPV6 merge at 2006-03-21: commit cd85f6e2f58282186ad720fc18482be228f0b972 is good (right before the bunch of patches) commit b00055aacdb172c05067612278ba27265fcd05ce is bad (right after the bunch of changes) http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog;h=705af309505681f197f81618440954d10f120dc0;pg=44 shows the list of committs at that range. -- Meelis Roos ([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: [RFC 0/4] NetLabel
On Thu, 25 May 2006, Paul Moore wrote:
This patch introduces a new kernel feature designed to support labeled
networking protocols such as RIPSO and CIPSO. These protocols are required to
interoperate with existing trusted operating systems such as Trusted
Solaris.
A few initial comments.
- Did you decide that you definitely need to verify labels on fragments?
I can see the code's been added to do that, but wonder about a comment
made during earlier discussion that mislabeled fragments could only come
from a misbehaving trusted system. What is the threat model here?
- Can you explain how module loading and module refcounting for these
modules work? (e.g. what causes netlabel_cipso_v4 to be loaded, is it
always safe to unload if the refcount is zero?)
- What about user APIs for setting and retrieving labels?
- What about labeling of kernel-generated packets?
- Don't put #ifdef'd code into mainline code.
e.g. in net/ipv4/ip_fragment.c
+#ifdef CONFIG_NETLABEL_CIPSOV4
+ if (sopt-cipso) {
This needs to be a function which is compiled away as a static inline when
not selected. This stuff should have zero impact on the networking code
if not enabled.
- Try and add entries for security/selinux/nlmsgtab.c for the new Netlink
protocol.
- This does not follow normal kernel coding practices:
+ if (netlbl_netlink_init() != 0) {
+ netlbl_domhsh_exit();
+ return -ENOMEM;
This should be:
{
err = netlbl_netlink_init();
if (err)
goto err_domhsh;
...
err_domhsh:
netlbl_domhsh_exit();
return err;
}
i.e. a single error path when you have cleanups to perform, and
propagation of error codes.
- This kind of stuff should be removed before merging:
+static void __exit netlbl_exit(void)
+{
+ printk(KERN_INFO NetLabel: Exiting\n);
+int netlbl_netlink_init(void)
+{
+ BUG_ON(netlbl_nl);
+int netlbl_netlink_exit(void)
+{
+ BUG_ON(!netlbl_nl);
Should the above two be marked __init and __exit? And why does the last
one return an int when the only possible return value is zero? (it needs
to return void).
- Why does this module have a version number?
+ printk(KERN_INFO NetLabel: Initializing (v%s %s)\n,
+ NETLBL_VER_STR, NETLBL_VER_DATE);
--
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
[PATCH 0/3 #2] avoid pci_find_device
Hello, there are some patches to avoid pci_find_device in drivers, next will come in future. Take #2. It's against 2.6.17-rc4-mm3 tree. 01-i2c-scx200-acb-avoid-pci-find-device.patch 02-bcm43xx-avoid-pci-find-device.patch 03-gt96100eth-avoid-pci-find-device.patch i2c/busses/scx200_acb.c |9 ++--- net/gt96100eth.c| 10 +++--- net/wireless/bcm43xx/bcm43xx_main.c | 20 3 files changed, 29 insertions(+), 10 deletions(-) Thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] pci: bcm43xx avoid pci_find_device
Jiri Slaby wrote:
bcm43xx avoid pci_find_device
Change pci_find_device to safer pci_get_device with support for more
devices.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 1d3b6caf027fe53351c645523587aeac40bc3e47
tree ae37c86b633442cdf8a7a19ac287542724081c90
parent ab3443d79c94d0ae6a9e020daefa4d29eccff50d
author Jiri Slaby [EMAIL PROTECTED] Fri, 26 May 2006 01:49:12 +0159
committer Jiri Slaby [EMAIL PROTECTED] Fri, 26 May 2006 01:49:12 +0159
drivers/net/wireless/bcm43xx/bcm43xx_main.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index b488f77..56d2fc6 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2131,6 +2131,13 @@ out:
return err;
}
+#ifdef CONFIG_BCM947XX
+static struct pci_device_id bcm43xx_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4324) },
+ { 0 }
+};
+#endif
+
static int bcm43xx_initialize_irq(struct bcm43xx_private *bcm)
{
int res;
@@ -2141,10 +2148,15 @@ static int bcm43xx_initialize_irq(struct
#ifdef CONFIG_BCM947XX
if (bcm-pci_dev-bus-number == 0) {
struct pci_dev *d = NULL;
- /* FIXME: we will probably need more device IDs here... */
- d = pci_find_device(PCI_VENDOR_ID_BROADCOM, 0x4324, NULL);
- if (d != NULL) {
- bcm-irq = d-irq;
+ struct pci_device_id *id = bcm43xx_ids;
+ while (id-vendor) {
+ d = pci_get_device(id-vendor, id-device, NULL);
+ if (d != NULL) {
+ bcm-irq = d-irq;
+ pci_dev_put(d);
+ break;
You'll want to use pci_match_device() or pci_match_one_device()
[I forget which one]
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] pci: gt96100eth avoid pci_find_device
Jiri Slaby wrote:
gt96100eth avoid pci_find_device
Change pci_find_device to safer pci_get_device.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit f656671e9da9d33bd7a2fb3f5c0d0f7009925698
tree b92c808b6a9eecce58b0f7b0ffe1237631dbd65a
parent 1d3b6caf027fe53351c645523587aeac40bc3e47
author Jiri Slaby [EMAIL PROTECTED] Fri, 26 May 2006 01:55:23 +0159
committer Jiri Slaby [EMAIL PROTECTED] Fri, 26 May 2006 01:55:23 +0159
drivers/net/gt96100eth.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gt96100eth.c b/drivers/net/gt96100eth.c
index 2d24354..beac56d 100644
--- a/drivers/net/gt96100eth.c
+++ b/drivers/net/gt96100eth.c
@@ -613,9 +613,9 @@ static int gt96100_init_module(void)
/*
* Stupid probe because this really isn't a PCI device
*/
- if (!(pci = pci_find_device(PCI_VENDOR_ID_MARVELL,
+ if (!(pci = pci_get_device(PCI_VENDOR_ID_MARVELL,
PCI_DEVICE_ID_MARVELL_GT96100, NULL))
- !(pci = pci_find_device(PCI_VENDOR_ID_MARVELL,
+ !(pci = pci_get_device(PCI_VENDOR_ID_MARVELL,
PCI_DEVICE_ID_MARVELL_GT96100A, NULL))) {
printk(KERN_ERR __FILE__ : GT96100 not found!\n);
return -ENODEV;
Seems OK to me, though you may wish to use a pci_device_id list with
pci_match_[one_]device() here too.
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: [Bugme-new] [Bug 6610] New: dummy interface broadcast destination hardware address is not ff:ff:ff:ff:ff:ff
On Thu, May 25, 2006 at 03:16:02PM -0700, David Miller wrote:
Perhaps RTN_BROADCAST should take precedence over IFF_NOARP
(but not IFF_LOOPBACK)? I'm talking about the code in
net/ipv4/arp.c that causes this behavior.
Sure, I don't see any harm in that.
However, I'm curious as to the purpose of all this. What application
is there for sending broadcasts through a dummy device with the
Ethernet broadcast address?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6610] New: dummy interface broadcast destination hardware address is not ff:ff:ff:ff:ff:ff
From: Herbert Xu [EMAIL PROTECTED] Date: Fri, 26 May 2006 10:43:24 +1000 On Thu, May 25, 2006 at 03:16:02PM -0700, David Miller wrote: Perhaps RTN_BROADCAST should take precedence over IFF_NOARP (but not IFF_LOOPBACK)? I'm talking about the code in net/ipv4/arp.c that causes this behavior. Sure, I don't see any harm in that. However, I'm curious as to the purpose of all this. What application is there for sending broadcasts through a dummy device with the Ethernet broadcast address? Good point. dummy is just a black hole to point routes to while your real connection is down. Running tcpdump on it and having any kind of expectations about broadcast addresses and whatnot is pointless. - 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 routing broken in 2.6.17-rc3,4
In article [EMAIL PROTECTED] (at Fri, 26 May 2006 02:24:19 +0300 (EEST)),
Meelis Roos [EMAIL PROTECTED] says:
(To YOSHIFUJI Hideaki: this is about the
http://comments.gmane.org/gmane.linux.network/35262 thread)
Tracked it down to IPV6 merge at 2006-03-21:
commit cd85f6e2f58282186ad720fc18482be228f0b972 is good (right before
the bunch of patches)
commit b00055aacdb172c05067612278ba27265fcd05ce is bad (right after the
bunch of changes)
I guess rt6_select() is returning ip6_null_entry and
the caller is finding next best route; e.g. default route.
Does this solve your problem?
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 0190e39..93eb33c 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -280,10 +280,12 @@ static int inline rt6_check_neigh(struct
{
struct neighbour *neigh = rt-rt6i_nexthop;
int m = 0;
- if (neigh) {
+ if (rt-rt6i_flags RTF_NONEXTHOP)
+ m = 1;
+ else if (neigh) {
read_lock_bh(neigh-lock);
if (neigh-nud_state NUD_VALID)
- m = 1;
+ m = 2;
read_unlock_bh(neigh-lock);
}
return m;
@@ -292,15 +294,18 @@ static int inline rt6_check_neigh(struct
static int rt6_score_route(struct rt6_info *rt, int oif,
int strict)
{
- int m = rt6_check_dev(rt, oif);
+ int m, n
+
+ m = rt6_check_dev(rt, oif);
if (!m (strict RT6_SELECT_F_IFACE))
return -1;
#ifdef CONFIG_IPV6_ROUTER_PREF
m |= IPV6_DECODE_PREF(IPV6_EXTRACT_PREF(rt-rt6i_flags)) 2;
#endif
- if (rt6_check_neigh(rt))
+ n = rt6_check_neigh(rt);
+ if (n 1)
m |= 16;
- else if (strict RT6_SELECT_F_REACHABLE)
+ else if (!n strict RT6_SELECT_F_REACHABLE)
return -1;
return 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 0/9] Resending NetXen 1G/10G NIC driver patch
Stephen, Roland, Thanks a lot for feedback. We'll implement the minor changes rightaway and post an update. We are also thinking about what's the best way to incorporate the data structure changes you have suggested. Will post a reply on that too soon. -Amit On Thursday 25 May 2006 16:15, Linsys Contractor Amit S. Kale wrote: Hi, I'll be sending a NetXen (formerly Universal Network Machines) 1G/10G in subsequent emails. This is a revised version of the UNM driver posted earlier. We have tried to make changes as per the feedback received. We would like this driver to be inluded in mainline kernel. Kindly review it and feel free to get back to me for any further feedback/queries/comments. Thanks. -Amit Signed-off-by: Amit S. Kale [EMAIL PROTECTED] Kconfig |5 Makefile |1 netxen/Makefile | 35 + netxen/netxen_nic.h | 950 +++ netxen/netxen_nic_ethtool.c | 802 ++ netxen/netxen_nic_hdr.h | 682 ++ netxen/netxen_nic_hw.c | 1289 +++ netxen/netxen_nic_hw.h | 339 +++ netxen/netxen_nic_init.c | 1219 netxen/netxen_nic_ioctl.h| 75 ++ netxen/netxen_nic_isr.c | 428 ++ netxen/netxen_nic_main.c | 1209 netxen/netxen_nic_niu.c | 770 + netxen/netxen_nic_phan_reg.h | 195 ++ 14 files changed, 7999 insertions(+) - 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
