Re: [Bugme-new] [Bug 9031] New: TPC window is to cautious on send
On Sun, 16 Sep 2007 17:02:46 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9031 Summary: TPC window is to cautious on send Product: Networking Version: 2.5 KernelVersion: Any Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: IPV4 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This has been a longstanding bug of sorts when talking to a system that has extremely small windows (under 1.5k). The only way to give the stack on the other side a nudge is to ACK twice. Here is a sample transcript, with a max window size of 1025 bytes. 18:25:43.968358 IP dr.ea.ms.http 192.168.80.2.40246: . 37377:37633(256) ack 120 win 5840 18:25:43.992402 IP 192.168.80.2.40246 dr.ea.ms.http: . ack 37121 win 769 mss 256 18:25:44.390305 IP 192.168.80.2.40246 dr.ea.ms.http: . ack 37121 win 1025 mss 256 18:25:44.823084 IP dr.ea.ms.http 192.168.80.2.40246: . 37633:37889(256) ack 120 win 5840 If I take the nudge code out of my IP stack, it sits for an aweful long time, waiting on the next packet, when there clearly is room for a few more. Should I: 1: Have my IP stack lie about the window till it is important? 2: Something else? I can't see any good reason for the large delay, since it is on a serial link, via SLIP. I can point you to source code that will allow you to verify the problem for yourself, if you would like. - 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] trivial typo correction in net/ipv4/xfrm4_policy.c
Hello, This is a trivial typo correction in net/ipv4/xfrm4_policy.c which hunted my eye... Regards, Ian Brown Signed-off-by: [EMAIL PROTECTED] --- linux-2.6.23-rc5-clean/net/ipv4/xfrm4_policy.c 2007-09-01 09:08:24.0 +0300 +++ linux-2.6.23-rc5/net/ipv4/xfrm4_policy.c2007-09-17 09:36:04.0 +0200 @@ -166,7 +166,7 @@ dst_prev-trailer_len = trailer_len; memcpy(dst_prev-metrics, x-route-metrics, sizeof(dst_prev-metrics)); - /* Copy neighbout for reachability confirmation */ + /* Copy neighbour for reachability confirmation */ dst_prev-neighbour = neigh_clone(rt-u.dst.neighbour); dst_prev-input = rt-u.dst.input; /* XXX: When IPv6 module can be unloaded, we should manage reference - 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 PATCH v0.2] net driver: mpc52xx fec
On Sat, Sep 15, 2007 at 02:14:44PM +0200, Domen Puncer wrote: Updated and split version at: http://coderock.org/tmp/fec-v3rc1/ I'll repost to lists once I run-test them. When applying those patches, the build did die with : ERROR: phy_mii_ioctl [drivers/net/fec_mpc52xx/fec_mpc52xx.ko] undefined! Apparently, phy_mii_ioctl is not an exported symbol. Domen, did you maybe forget a little snipplet when you cut the patches in different pieces ? Or did i mess up applying them ? Friendly, Sven Luther - 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][NET_SCHED] explict hold dev tx lock
On Sun, Sep 16, 2007 at 05:10:00PM -0400, jamal ([EMAIL PROTECTED]) wrote: On Sun, 2007-16-09 at 16:52 -0400, jamal wrote: What i should say is if i grabbed the lock explicitly without disabling irqs it wont be much different than what is done today and should always work. No? And to be more explicit, heres a patch using the macros from previous patch. So far tested on 3 NICs. How many cpu collisions you are seeing? Did I understand you right, that you replaced trylock with lock and thus removed collision handling and got better results? -- Evgeniy Polyakov - 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: [RFT] sky2: receive hang check
On Wed, 12 Sep 2007, Stephen Hemminger wrote:
-/* Check for lost IRQ once a second */
+static void sky2_rx_check(struct net_device *dev)
+{
+ struct sky2_port *sky2 = netdev_priv(dev);
+ struct sky2_hw *hw = sky2-hw;
+ unsigned port = sky2-port;
+ unsigned rxq = rxqaddr[port];
+ u32 mac_rp = sky2_read32(hw, SK_REG(port, RX_GMF_RP));
+ u8 mac_lev = sky2_read8(hw, SK_REG(port, RX_GMF_RLEV));
+ u8 fifo_rp = sky2_read8(hw, Q_ADDR(rxq, Q_RP));
+ u8 fifo_lev = sky2_read8(hw, Q_ADDR(rxq, Q_RL));
+
+ /* If not idle and MAC or PCI is stuck */
+ if (sky2-check.last != dev-last_rx
Don't you want == here? You want to run the rest of this test when no
packets has been received for a while.
+ ((mac_rp == sky2-check.mac_rp
+mac_lev != 0 mac_lev = sky2-check.mac_lev) ||
+ /* Check if the PCI RX hang */
+ (fifo_rp == sky2-check.fifo_rp
+fifo_lev != 0 fifo_lev = sky2-check.fifo_lev))) {
+
+ pr_info(PFX %s: receiver hang detected\n, dev-name);
+ schedule_work(hw-restart_work);
+ }
+
+ sky2-check.last = dev-last_rx;
+ sky2-check.mac_rp = mac_rp;
+ sky2-check.mac_lev = mac_lev;
+ sky2-check.fifo_rp = fifo_rp;
+ sky2-check.fifo_lev = fifo_lev;
+}
/Martin
-
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][NETNS] Use list_for_each_entry_continue_reverse in setup_net
I proposed introducing a list_for_each_entry_continue_reverse
macro to be used in setup_net() when unrolling the failed
-init callback.
Here is the macro and some more cleanup in the setup_net() itself
to remove one variable from the stack :) Minor, but the code
looks nicer.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
Acked-by: Eric W. Biederman [EMAIL PROTECTED]
---
include/linux/list.h | 14 ++
net/core/net_namespace.c |8 +++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/linux/list.h b/include/linux/list.h
index f29fc9c..ad9dcb9 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -525,6 +525,20 @@ static inline void list_splice_init_rcu(
pos = list_entry(pos-member.next, typeof(*pos), member))
/**
+ * list_for_each_entry_continue_reverse - iterate backwards from the given
point
+ * @pos: the type * to use as a loop cursor.
+ * @head: the head for your list.
+ * @member:the name of the list_struct within the struct.
+ *
+ * Start to iterate over list of given type backwards, continuing after
+ * the current position.
+ */
+#define list_for_each_entry_continue_reverse(pos, head, member)
\
+ for (pos = list_entry(pos-member.prev, typeof(*pos), member); \
+prefetch(pos-member.prev), pos-member != (head);\
+pos = list_entry(pos-member.prev, typeof(*pos), member))
+
+/**
* list_for_each_entry_from - iterate over list of given type from the current
point
* @pos: the type * to use as a loop cursor.
* @head: the head for your list.
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 1fc513c..a9dd261 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -102,7 +102,6 @@ static int setup_net(struct net *net)
{
/* Must be called with net_mutex held */
struct pernet_operations *ops;
- struct list_head *ptr;
int error;
memset(net, 0, sizeof(struct net));
@@ -110,8 +109,7 @@ static int setup_net(struct net *net)
atomic_set(net-use_count, 0);
error = 0;
- list_for_each(ptr, pernet_list) {
- ops = list_entry(ptr, struct pernet_operations, list);
+ list_for_each_entry(ops, pernet_list, list) {
if (ops-init) {
error = ops-init(net);
if (error 0)
@@ -120,12 +118,12 @@ static int setup_net(struct net *net)
}
out:
return error;
+
out_undo:
/* Walk through the list backwards calling the exit functions
* for the pernet modules whose init functions did not fail.
*/
- for (ptr = ptr-prev; ptr != pernet_list; ptr = ptr-prev) {
- ops = list_entry(ptr, struct pernet_operations, list);
+ list_for_each_entry_continue_reverse(ops, pernet_list, list) {
if (ops-exit)
ops-exit(net);
}
-
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] [-MM, FIX V4] e1000e: incorporate napi_struct changes from net-2.6.24.git
On 12/23/-28158 08:59 PM, Auke Kok wrote:
This incorporates the new napi_struct changes into e1000e. Included
bugfix for ifdown hang from Krishna Kumar for e1000.
Disabling polling is no longer needed at init time, so remove
napi_disable() call from _probe().
This also fixes an endless polling loop where the driver signalled
polling done improperly back to the stack.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000e/e1000.h |2 ++
drivers/net/e1000e/netdev.c | 40
2 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index c57e35a..d2499bb 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -187,6 +187,8 @@ struct e1000_adapter {
struct e1000_ring *tx_ring /* One per active queue */
cacheline_aligned_in_smp;
+ struct napi_struct napi;
+
unsigned long tx_queue_len;
unsigned int restart_queue;
u32 txd_cmd;
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 372da46..eeb40cc 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1149,12 +1149,12 @@ static irqreturn_t e1000_intr_msi(int irq, void *data)
mod_timer(adapter-watchdog_timer, jiffies + 1);
}
- if (netif_rx_schedule_prep(netdev)) {
+ if (netif_rx_schedule_prep(netdev, adapter-napi)) {
adapter-total_tx_bytes = 0;
adapter-total_tx_packets = 0;
adapter-total_rx_bytes = 0;
adapter-total_rx_packets = 0;
- __netif_rx_schedule(netdev);
+ __netif_rx_schedule(netdev, adapter-napi);
} else {
atomic_dec(adapter-irq_sem);
}
@@ -1212,12 +1212,12 @@ static irqreturn_t e1000_intr(int irq, void *data)
mod_timer(adapter-watchdog_timer, jiffies + 1);
}
- if (netif_rx_schedule_prep(netdev)) {
+ if (netif_rx_schedule_prep(netdev, adapter-napi)) {
adapter-total_tx_bytes = 0;
adapter-total_tx_packets = 0;
adapter-total_rx_bytes = 0;
adapter-total_rx_packets = 0;
- __netif_rx_schedule(netdev);
+ __netif_rx_schedule(netdev, adapter-napi);
} else {
atomic_dec(adapter-irq_sem);
}
@@ -1662,10 +1662,10 @@ set_itr_now:
* e1000_clean - NAPI Rx polling callback
* @adapter: board private structure
**/
-static int e1000_clean(struct net_device *poll_dev, int *budget)
+static int e1000_clean(struct napi_struct *napi, int budget)
{
- struct e1000_adapter *adapter;
- int work_to_do = min(*budget, poll_dev-quota);
+ struct e1000_adapter *adapter = container_of(napi, struct
e1000_adapter, napi);
+ struct net_device *poll_dev = adapter-netdev;
int tx_cleaned = 0, work_done = 0;
/* Must NOT use netdev_priv macro here. */
@@ -1684,25 +1684,19 @@ static int e1000_clean(struct net_device *poll_dev,
int *budget)
spin_unlock(adapter-tx_queue_lock);
}
- adapter-clean_rx(adapter, work_done, work_to_do);
- *budget -= work_done;
- poll_dev-quota -= work_done;
+ adapter-clean_rx(adapter, work_done, budget);
/* If no Tx and not enough Rx work done, exit the polling mode */
- if ((!tx_cleaned (work_done == 0)) ||
+ if ((!tx_cleaned (work_done budget)) ||
Hi,
sorry to say that, but this change since last your patch changes nothing on my
machine (ksoftirq spinning at 100 % of CPU usage), I have some traces for you if
it helps:
SysRq : Show Regs
CPU 0:
Modules linked in: floppy sr_mod ehci_hcd cdrom rtc_cmos rtc_core usbhid rtc_lib
Pid: 4, comm: ksoftirqd/0 Not tainted 2.6.23-rc4-mm1_64 #24
RIP: 0010:[803b4ea3] [803b4ea3]
e1000_clean_rx_irq+0x273/0x320
RSP: :80703e18 EFLAGS: 0202
RAX: 8100032b0700 RBX: 80703ea8 RCX:
RDX: RSI: 0001 RDI: 810003097f60
RBP: 80703d90 R08: 810002b85340 R09: 0002
R10: 0002 R11: 8100032b0700 R12: 8020c1f1
R13: 80703d90 R14: 810004eac020 R15:
FS: () GS:806ad000() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 445d9978 CR3: 04c49000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Call Trace:
IRQ [803b4e86] e1000_clean_rx_irq+0x256/0x320
[803b3059] e1000_clean+0x109/0x250
[80250a43] hrtimer_run_queues+0x33/0x1b0
[8046d777] net_rx_action+0xd7/0x190
[8023dc54] __do_softirq+0x74/0xf0
[8020ce6c] call_softirq+0x1c/0x30
EOI
Re: [BUG] tg3 cannot do PXE (loses MAC address) after soft reboot
Michael Chan schrieb: On Fri, 2007-09-14 at 10:14 +0200, Ingo Oeser wrote: Is it enough to parse the first number in the firmware via simple_strtoul()? No, it's not. We need to check the number after the '.' and possibly an alphabet at the end as well. Worse yet, the version may be different for different chips. Ah, I see. I thought the first number is some constantly increasing internal version number from your SCM[1] and the other is the marketing release number. Thank you for explaining this. And that different version for different chips issue make it really hard. I can see that now. We'll see if we can come up with a simple way to detect the problem. That would help your users (like the customers of my employer). Admins and system vendors will love you for that :-) Best Regards Ingo Oeser [1] Source Control Management e.g. cvs, subversion, git - 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/7] CAN: Add maintainer entries
This patch adds entries in the CREDITS and MAINTAINERS file for CAN. Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED] Signed-off-by: Urs Thuermann [EMAIL PROTECTED] --- CREDITS | 16 MAINTAINERS |9 + 2 files changed, 25 insertions(+) Index: net-2.6.24/CREDITS === --- net-2.6.24.orig/CREDITS 2007-09-17 10:26:57.0 +0200 +++ net-2.6.24/CREDITS 2007-09-17 10:27:21.0 +0200 @@ -1331,6 +1331,14 @@ S: 5623 HZ Eindhoven S: The Netherlands +N: Oliver Hartkopp +E: [EMAIL PROTECTED] +W: http://www.volkswagen.de +D: Controller Area Network (network layer core) +S: Brieffach 1776 +S: 38436 Wolfsburg +S: Germany + N: Andrew Haylett E: [EMAIL PROTECTED] D: Selection mechanism @@ -3284,6 +3292,14 @@ S: F-35042 Rennes Cedex S: France +N: Urs Thuermann +E: [EMAIL PROTECTED] +W: http://www.volkswagen.de +D: Controller Area Network (network layer core) +S: Brieffach 1776 +S: 38436 Wolfsburg +S: Germany + N: Jon Tombs E: [EMAIL PROTECTED] W: http://www.esi.us.es/~jon Index: net-2.6.24/MAINTAINERS === --- net-2.6.24.orig/MAINTAINERS 2007-09-17 10:26:57.0 +0200 +++ net-2.6.24/MAINTAINERS 2007-09-17 10:27:21.0 +0200 @@ -975,6 +975,15 @@ L: [EMAIL PROTECTED] S: Maintained +CAN NETWORK LAYER +P: Urs Thuermann +M: [EMAIL PROTECTED] +P: Oliver Hartkopp +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://developer.berlios.de/projects/socketcan/ +S: Maintained + CALGARY x86-64 IOMMU P: Muli Ben-Yehuda M: [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/7] CAN: Add new PF_CAN protocol family, try #6
Hello Dave,
this is the sixth post of the patch series that adds the PF_CAN
protocol family for the Controller Area Network.
Since our last post we have changed the following:
* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.
The changes in try #5 were:
* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.
The changes in try #4 were:
* Change vcan network driver to use the new RTNL API, as suggested by
Patrick.
* Revert our change to use skb-iif instead of skb-cb. After
discussion with Patrick and Jamal it turned out, our first
implementation was correct.
* Use skb_tail_pointer() instead of skb-tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's
The changes in try #3 were:
* Use sbk-sk and skb-pkt_type instead of skb-cb to pass loopback
flags and originating socket down to the driver and back to the
receiving socket. Thanks to Patrick McHardy for pointing out our
wrong use of sbk-cb.
* Use skb-iif instead of skb-cb to pass receiving interface from
raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb-protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
directly into struct raw_sock and bcm_sock resp., like most other
proto implementations do.
* We have found and fixed race conditions between raw_bind(),
raw_{set,get}sockopt() and raw_notifier(). This resulted in
- complete removal of our own notifier list infrastructure in
af_can.c. raw.c and bcm.c now use normal netdevice notifiers.
- removal of ro-lock spinlock. We use lock_sock(sk) now.
- changed deletion of dev_rcv_lists, which are now marked for
deletion in the netdevice notifier in af_can.c and are actually
deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemminger.
The changes in try #2 were:
* reduced RCU callback overhead when deleting receiver lists (thx to
feedback from Paul E. McKenney).
* eliminated some code duplication in net/can/proc.c.
* renamed slock-29 and sk_lock-29 to slock-AF_CAN and sk_lock-AF_CAN in
net/core/sock.c
* added entry for can.txt in Documentation/networking/00-INDEX
* added error frame definitions in include/linux/can/error.h, which are to
be used by CAN network drivers.
This patch series applies against net-2.6.24 and is derived from Subversion
revision r466 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/version.
This patch doesn't touch anything in the kernel except for the allocation
of a couple of numbers for protocol, arp hw type, and a line discipline.
Please review this patch series for integration into your tree.
Thanks very much for your work!
Best regards,
Urs Thuermann
Oliver Hartkopp
--
-
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/7] CAN: Allocate protocol numbers for PF_CAN
This patch adds a protocol/address family number, ARP hardware type, ethernet packet type, and a line discipline number for the SocketCAN implementation. Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED] Signed-off-by: Urs Thuermann [EMAIL PROTECTED] --- include/linux/if_arp.h |1 + include/linux/if_ether.h |1 + include/linux/socket.h |2 ++ include/linux/tty.h |3 ++- net/core/sock.c |4 ++-- 5 files changed, 8 insertions(+), 3 deletions(-) Index: net-2.6.24/include/linux/if_arp.h === --- net-2.6.24.orig/include/linux/if_arp.h 2007-09-17 10:26:58.0 +0200 +++ net-2.6.24/include/linux/if_arp.h 2007-09-17 10:27:06.0 +0200 @@ -52,6 +52,7 @@ #define ARPHRD_ROSE270 #define ARPHRD_X25 271 /* CCITT X.25 */ #define ARPHRD_HWX25 272 /* Boards with X.25 in firmware */ +#define ARPHRD_CAN 280 /* Controller Area Network */ #define ARPHRD_PPP 512 #define ARPHRD_CISCO 513 /* Cisco HDLC */ #define ARPHRD_HDLCARPHRD_CISCO Index: net-2.6.24/include/linux/if_ether.h === --- net-2.6.24.orig/include/linux/if_ether.h2007-09-17 10:26:58.0 +0200 +++ net-2.6.24/include/linux/if_ether.h 2007-09-17 10:27:06.0 +0200 @@ -90,6 +90,7 @@ #define ETH_P_WAN_PPP 0x0007 /* Dummy type for WAN PPP frames*/ #define ETH_P_PPP_MP0x0008 /* Dummy type for PPP MP frames */ #define ETH_P_LOCALTALK 0x0009 /* Localtalk pseudo type*/ +#define ETH_P_CAN 0x000C /* Controller Area Network */ #define ETH_P_PPPTALK 0x0010 /* Dummy type for Atalk over PPP*/ #define ETH_P_TR_802_2 0x0011 /* 802.2 frames */ #define ETH_P_MOBITEX 0x0015 /* Mobitex ([EMAIL PROTECTED]) */ Index: net-2.6.24/include/linux/socket.h === --- net-2.6.24.orig/include/linux/socket.h 2007-09-17 10:26:58.0 +0200 +++ net-2.6.24/include/linux/socket.h 2007-09-17 10:27:06.0 +0200 @@ -185,6 +185,7 @@ #define AF_PPPOX 24 /* PPPoX sockets*/ #define AF_WANPIPE 25 /* Wanpipe API Sockets */ #define AF_LLC 26 /* Linux LLC*/ +#define AF_CAN 29 /* Controller Area Network */ #define AF_TIPC30 /* TIPC sockets */ #define AF_BLUETOOTH 31 /* Bluetooth sockets*/ #define AF_IUCV32 /* IUCV sockets */ @@ -220,6 +221,7 @@ #define PF_PPPOX AF_PPPOX #define PF_WANPIPE AF_WANPIPE #define PF_LLC AF_LLC +#define PF_CAN AF_CAN #define PF_TIPCAF_TIPC #define PF_BLUETOOTH AF_BLUETOOTH #define PF_IUCVAF_IUCV Index: net-2.6.24/include/linux/tty.h === --- net-2.6.24.orig/include/linux/tty.h 2007-09-17 10:26:58.0 +0200 +++ net-2.6.24/include/linux/tty.h 2007-09-17 10:27:06.0 +0200 @@ -24,7 +24,7 @@ #define NR_PTYSCONFIG_LEGACY_PTY_COUNT /* Number of legacy ptys */ #define NR_UNIX98_PTY_DEFAULT 4096 /* Default maximum for Unix98 ptys */ #define NR_UNIX98_PTY_MAX (1 MINORBITS) /* Absolute limit */ -#define NR_LDISCS 17 +#define NR_LDISCS 18 /* line disciplines */ #define N_TTY 0 @@ -45,6 +45,7 @@ #define N_SYNC_PPP 14 /* synchronous PPP */ #define N_HCI 15 /* Bluetooth HCI UART */ #define N_GIGASET_M101 16 /* Siemens Gigaset M101 serial DECT adapter */ +#define N_SLCAN17 /* Serial / USB serial CAN Adaptors */ /* * This character is the same as _POSIX_VDISABLE: it cannot be used as Index: net-2.6.24/net/core/sock.c === --- net-2.6.24.orig/net/core/sock.c 2007-09-17 10:26:58.0 +0200 +++ net-2.6.24/net/core/sock.c 2007-09-17 10:27:06.0 +0200 @@ -154,7 +154,7 @@ sk_lock-AF_ASH , sk_lock-AF_ECONET , sk_lock-AF_ATMSVC , sk_lock-21 , sk_lock-AF_SNA , sk_lock-AF_IRDA , sk_lock-AF_PPPOX , sk_lock-AF_WANPIPE , sk_lock-AF_LLC , - sk_lock-27 , sk_lock-28 , sk_lock-29 , + sk_lock-27 , sk_lock-28 , sk_lock-AF_CAN , sk_lock-AF_TIPC , sk_lock-AF_BLUETOOTH, sk_lock-IUCV, sk_lock-AF_RXRPC , sk_lock-AF_MAX }; @@ -168,7 +168,7 @@ slock-AF_ASH , slock-AF_ECONET , slock-AF_ATMSVC , slock-21 , slock-AF_SNA , slock-AF_IRDA , slock-AF_PPPOX , slock-AF_WANPIPE , slock-AF_LLC , - slock-27 , slock-28 , slock-29 , + slock-27 ,
[PATCH 5/7] CAN: Add virtual CAN netdevice driver
This patch adds the virtual CAN bus (vcan) network driver. The vcan device is just a loopback device for CAN frames, no real CAN hardware is involved. Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED] Signed-off-by: Urs Thuermann [EMAIL PROTECTED] --- drivers/net/Makefile |1 drivers/net/can/Kconfig | 25 drivers/net/can/Makefile |5 drivers/net/can/vcan.c | 260 +++ net/can/Kconfig |3 5 files changed, 294 insertions(+) Index: net-2.6.24/drivers/net/Makefile === --- net-2.6.24.orig/drivers/net/Makefile2007-09-17 10:30:35.0 +0200 +++ net-2.6.24/drivers/net/Makefile 2007-09-17 11:13:45.0 +0200 @@ -10,6 +10,7 @@ obj-$(CONFIG_CHELSIO_T1) += chelsio/ obj-$(CONFIG_CHELSIO_T3) += cxgb3/ obj-$(CONFIG_EHEA) += ehea/ +obj-$(CONFIG_CAN) += can/ obj-$(CONFIG_BONDING) += bonding/ obj-$(CONFIG_ATL1) += atl1/ obj-$(CONFIG_GIANFAR) += gianfar_driver.o Index: net-2.6.24/drivers/net/can/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.24/drivers/net/can/Kconfig 2007-09-17 11:13:45.0 +0200 @@ -0,0 +1,25 @@ +menu CAN Device Drivers + depends on CAN + +config CAN_VCAN + tristate Virtual Local CAN Interface (vcan) + depends on CAN + default N + ---help--- + Similar to the network loopback devices, vcan offers a + virtual local CAN interface. + + This driver can also be built as a module. If so, the module + will be called vcan. + +config CAN_DEBUG_DEVICES + bool CAN devices debugging messages + depends on CAN + default N + ---help--- + Say Y here if you want the CAN device drivers to produce a bunch of + debug messages to the system log. Select this if you are having + a problem with CAN support and want to see more of what is going + on. + +endmenu Index: net-2.6.24/drivers/net/can/Makefile === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.24/drivers/net/can/Makefile 2007-09-17 11:13:45.0 +0200 @@ -0,0 +1,5 @@ +# +# Makefile for the Linux Controller Area Network drivers. +# + +obj-$(CONFIG_CAN_VCAN) += vcan.o Index: net-2.6.24/drivers/net/can/vcan.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.24/drivers/net/can/vcan.c 2007-09-17 11:17:45.0 +0200 @@ -0,0 +1,260 @@ +/* + * vcan.c - Virtual CAN interface + * + * Copyright (c) 2002-2007 Volkswagen Group Electronic Research + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions, the following disclaimer and + *the referenced file 'COPYING'. + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in the + *documentation and/or other materials provided with the distribution. + * 3. Neither the name of Volkswagen nor the names of its contributors + *may be used to endorse or promote products derived from this software + *without specific prior written permission. + * + * Alternatively, provided that this notice is retained in full, this + * software may be distributed under the terms of the GNU General + * Public License (GPL) version 2 as distributed in the 'COPYING' + * file from the main directory of the linux kernel source. + * + * The provided data structures and external interfaces from this code + * are not restricted to be used by modules with a GPL compatible license. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH + * DAMAGE. + * + * Send feedback to [EMAIL PROTECTED] + * + */ + +#include linux/module.h +#include linux/init.h +#include linux/netdevice.h +#include linux/if_arp.h +#include linux/if_ether.h +#include
[PATCH 3/7] CAN: Add raw protocol
This patch adds the CAN raw protocol.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
---
include/linux/can/raw.h | 31 +
net/can/Kconfig | 26 +
net/can/Makefile|3
net/can/raw.c | 767
4 files changed, 827 insertions(+)
Index: net-2.6.24/include/linux/can/raw.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/include/linux/can/raw.h 2007-09-17 11:10:10.0 +0200
@@ -0,0 +1,31 @@
+/*
+ * linux/can/raw.h
+ *
+ * Definitions for raw CAN sockets
+ *
+ * Authors: Oliver Hartkopp [EMAIL PROTECTED]
+ * Urs Thuermann [EMAIL PROTECTED]
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to [EMAIL PROTECTED]
+ *
+ */
+
+#ifndef CAN_RAW_H
+#define CAN_RAW_H
+
+#include linux/can.h
+
+#define SOL_CAN_RAW (SOL_CAN_BASE + CAN_RAW)
+
+/* for socket options affecting the socket (not the global system) */
+
+enum {
+ CAN_RAW_FILTER = 1, /* set 0 .. n can_filter(s) */
+ CAN_RAW_ERR_FILTER, /* set filter for error frames */
+ CAN_RAW_LOOPBACK, /* local loopback (default:on) */
+ CAN_RAW_RECV_OWN_MSGS /* receive my own msgs (default:off) */
+};
+
+#endif
Index: net-2.6.24/net/can/Kconfig
===
--- net-2.6.24.orig/net/can/Kconfig 2007-09-17 10:30:35.0 +0200
+++ net-2.6.24/net/can/Kconfig 2007-09-17 11:10:10.0 +0200
@@ -16,6 +16,32 @@
If you want CAN support, you should say Y here and also to the
specific driver for your controller(s) below.
+config CAN_RAW
+ tristate Raw CAN Protocol (raw access with CAN-ID filtering)
+ depends on CAN
+ default N
+ ---help---
+ The Raw CAN protocol option offers access to the CAN bus via
+ the BSD socket API. You probably want to use the raw socket in
+ most cases where no higher level protocol is being used. The raw
+ socket has several filter options e.g. ID-Masking / Errorframes.
+ To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW.
+
+config CAN_RAW_USER
+ bool Allow non-root users to access Raw CAN Protocol sockets
+ depends on CAN_RAW
+ default N
+ ---help---
+ The Controller Area Network is a local field bus transmitting only
+ broadcast messages without any routing and security concepts.
+ In the majority of cases the user application has to deal with
+ raw CAN frames. Therefore it might be reasonable NOT to restrict
+ the CAN access only to the user root, as known from other networks.
+ Since CAN_RAW sockets can only send and receive frames to/from CAN
+ interfaces this does not affect security of others networks.
+ Say Y here if you want non-root users to be able to access CAN_RAW
+ sockets.
+
config CAN_DEBUG_CORE
bool CAN Core debugging messages
depends on CAN
Index: net-2.6.24/net/can/Makefile
===
--- net-2.6.24.orig/net/can/Makefile2007-09-17 10:30:35.0 +0200
+++ net-2.6.24/net/can/Makefile 2007-09-17 11:10:10.0 +0200
@@ -4,3 +4,6 @@
obj-$(CONFIG_CAN) += can.o
can-objs := af_can.o proc.o
+
+obj-$(CONFIG_CAN_RAW) += can-raw.o
+can-raw-objs := raw.o
Index: net-2.6.24/net/can/raw.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/net/can/raw.c2007-09-17 11:11:10.0 +0200
@@ -0,0 +1,767 @@
+/*
+ * raw.c - Raw sockets for protocol family CAN
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions, the following disclaimer and
+ *the referenced file 'COPYING'.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License (GPL) version 2 as distributed in the 'COPYING'
+ * file from the main directory of the
[PATCH 7/7] CAN: Add documentation
This patch adds documentation for the PF_CAN protocol family. Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED] Signed-off-by: Urs Thuermann [EMAIL PROTECTED] --- Documentation/networking/00-INDEX |2 Documentation/networking/can.txt | 635 ++ 2 files changed, 637 insertions(+) Index: net-2.6.24/Documentation/networking/can.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.24/Documentation/networking/can.txt 2007-09-17 10:27:25.0 +0200 @@ -0,0 +1,635 @@ + + +can.txt + +Readme file for the Controller Area Network Protocol Family (aka Socket CAN) + +This file contains + + 1 Overview / What is Socket CAN + + 2 Motivation / Why using the socket API + + 3 Socket CAN concept +3.1 receive lists +3.2 loopback +3.3 network security issues (capabilities) +3.4 network problem notifications + + 4 How to use Socket CAN +4.1 RAW protocol sockets with can_filters (SOCK_RAW) + 4.1.1 RAW socket option CAN_RAW_FILTER + 4.1.2 RAW socket option CAN_RAW_ERR_FILTER + 4.1.3 RAW socket option CAN_RAW_LOOPBACK + 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS +4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) +4.3 connected transport protocols (SOCK_SEQPACKET) +4.4 unconnected transport protocols (SOCK_DGRAM) + + 5 Socket CAN core module +5.1 can.ko module params +5.2 procfs content +5.3 writing own CAN protocol modules + + 6 CAN network drivers +6.1 general settings +6.2 loopback +6.3 CAN controller hardware filters +6.4 currently supported CAN hardware +6.5 todo + + 7 Credits + + + +1. Overview / What is Socket CAN + + +The socketcan package is an implementation of CAN protocols +(Controller Area Network) for Linux. CAN is a networking technology +which has wide-spread use in automation, embedded devices, and +automotive fields. While there have been other CAN implementations +for Linux based on character devices, Socket CAN uses the Berkeley +socket API, the Linux network stack and implements the CAN device +drivers as network interfaces. The CAN socket API has been designed +as similar as possible to the TCP/IP protocols to allow programmers, +familiar with network programming, to easily learn how to use CAN +sockets. + +2. Motivation / Why using the socket API + + +There have been CAN implementations for Linux before Socket CAN so the +question arises, why we have started another project. Most existing +implementations come as a device driver for some CAN hardware, they +are based on character devices and provide comparatively little +functionality. Usually, there is only a hardware-specific device +driver which provides a character device interface to send and +receive raw CAN frames, directly to/from the controller hardware. +Queueing of frames and higher-level transport protocols like ISO-TP +have to be implemented in user space applications. Also, most +character-device implementations support only one single process to +open the device at a time, similar to a serial interface. Exchanging +the CAN controller requires employment of another device driver and +often the need for adaption of large parts of the application to the +new driver's API. + +Socket CAN was designed to overcome all of these limitations. A new +protocol family has been implemented which provides a socket interface +to user space applications and which builds upon the Linux network +layer, so to use all of the provided queueing functionality. Device +drivers for CAN controller hardware register itself with the Linux +network layer as a network device, so that CAN frames from the +controller can be passed up to the network layer and on to the CAN +protocol family module and also vice-versa. Also, the protocol family +module provides an API for transport protocol modules to register, so +that any number of transport protocols can be loaded or unloaded +dynamically. In fact, the can core module alone does not provide any +protocol and can not be used without loading at least one additional +protocol module. Multiple sockets can be opened at the same time, +on different or the same protocol module and they can listen/send +frames on different or the same CAN IDs. Several sockets listening on +the same interface for frames with the same CAN ID are all passed the +same received matching CAN frames. An application wishing to +communicate using a specific transport protocol, e.g. ISO-TP, just +selects that protocol when opening the socket, and then can read and +write application data byte streams, without having to deal with +CAN-IDs, frames, etc. + +Similar functionality visible from user-space
[PATCH 4/7] CAN: Add broadcast manager (bcm) protocol
This patch adds the CAN broadcast manager (bcm) protocol.
Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED]
Signed-off-by: Urs Thuermann [EMAIL PROTECTED]
---
include/linux/can/bcm.h | 65 +
net/can/Kconfig | 28
net/can/Makefile|3
net/can/bcm.c | 1762
4 files changed, 1858 insertions(+)
Index: net-2.6.24/include/linux/can/bcm.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.24/include/linux/can/bcm.h 2007-09-17 11:12:30.0 +0200
@@ -0,0 +1,65 @@
+/*
+ * linux/can/bcm.h
+ *
+ * Definitions for CAN Broadcast Manager (BCM)
+ *
+ * Author: Oliver Hartkopp [EMAIL PROTECTED]
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to [EMAIL PROTECTED]
+ *
+ */
+
+#ifndef CAN_BCM_H
+#define CAN_BCM_H
+
+/**
+ * struct bcm_msg_head - head of messages to/from the broadcast manager
+ * @opcode:opcode, see enum below.
+ * @flags: special flags, see below.
+ * @count: number of frames to send before changing interval.
+ * @ival1: interval for the first @count frames.
+ * @ival2: interval for the following frames.
+ * @can_id:CAN ID of frames to be sent or received.
+ * @nframes: number of frames appended to the message head.
+ * @frames:array of CAN frames.
+ */
+struct bcm_msg_head {
+ int opcode;
+ int flags;
+ int count;
+ struct timeval ival1, ival2;
+ canid_t can_id;
+ int nframes;
+ struct can_frame frames[0];
+};
+
+enum {
+ TX_SETUP = 1, /* create (cyclic) transmission task */
+ TX_DELETE, /* remove (cyclic) transmission task */
+ TX_READ,/* read properties of (cyclic) transmission task */
+ TX_SEND,/* send one CAN frame */
+ RX_SETUP, /* create RX content filter subscription */
+ RX_DELETE, /* remove RX content filter subscription */
+ RX_READ,/* read properties of RX content filter subscription */
+ TX_STATUS, /* reply to TX_READ request */
+ TX_EXPIRED, /* notification on performed transmissions (count=0) */
+ RX_STATUS, /* reply to RX_READ request */
+ RX_TIMEOUT, /* cyclic message is absent */
+ RX_CHANGED /* updated CAN frame (detected content change) */
+};
+
+#define SETTIMER0x0001
+#define STARTTIMER 0x0002
+#define TX_COUNTEVT 0x0004
+#define TX_ANNOUNCE 0x0008
+#define TX_CP_CAN_ID0x0010
+#define RX_FILTER_ID0x0020
+#define RX_CHECK_DLC0x0040
+#define RX_NO_AUTOTIMER 0x0080
+#define RX_ANNOUNCE_RESUME 0x0100
+#define TX_RESET_MULTI_IDX 0x0200
+#define RX_RTR_FRAME0x0400
+
+#endif /* CAN_BCM_H */
Index: net-2.6.24/net/can/Kconfig
===
--- net-2.6.24.orig/net/can/Kconfig 2007-09-17 11:10:10.0 +0200
+++ net-2.6.24/net/can/Kconfig 2007-09-17 11:12:30.0 +0200
@@ -42,6 +42,34 @@
Say Y here if you want non-root users to be able to access CAN_RAW
sockets.
+config CAN_BCM
+ tristate Broadcast Manager CAN Protocol (with content filtering)
+ depends on CAN
+ default N
+ ---help---
+ The Broadcast Manager offers content filtering, timeout monitoring,
+ sending of RTR-frames and cyclic CAN messages without permanent user
+ interaction. The BCM can be 'programmed' via the BSD socket API and
+ informs you on demand e.g. only on content updates / timeouts.
+ You probably want to use the bcm socket in most cases where cyclic
+ CAN messages are used on the bus (e.g. in automotive environments).
+ To use the Broadcast Manager, use AF_CAN with protocol CAN_BCM.
+
+config CAN_BCM_USER
+ bool Allow non-root users to access CAN broadcast manager sockets
+ depends on CAN_BCM
+ default N
+ ---help---
+ The Controller Area Network is a local field bus transmitting only
+ broadcast messages without any routing and security concepts.
+ In the majority of cases the user application has to deal with
+ raw CAN frames. Therefore it might be reasonable NOT to restrict
+ the CAN access only to the user root, as known from other networks.
+ Since CAN_BCM sockets can only send and receive frames to/from CAN
+ interfaces this does not affect security of others networks.
+ Say Y here if you want non-root users to be able to access CAN_BCM
+ sockets.
+
config CAN_DEBUG_CORE
bool CAN Core debugging messages
depends on CAN
Index: net-2.6.24/net/can/Makefile
===
--- net-2.6.24.orig/net/can/Makefile2007-09-17 11:10:10.0 +0200
+++ net-2.6.24/net/can/Makefile
Re: [PATCH 0/10 REV5] Implement skb batching and support in IPoIB/E1000
On Sun, 2007-16-09 at 20:13 -0700, David Miller wrote: What Herbert and I want to do is basically turn on TSO for devices that can't do it in hardware, and rely upon the GSO framework to do the segmenting in software right before we hit the device. Sensible. This only makes sense for devices which can 1) scatter-gather and 2) checksum on transmit. If you have knowledge there are enough descriptors in the driver to cover all skbs you are passing, do you need to have #1? Note i dont touch fragments, i am assuming the driver is smart enough to handle them otherwise it wont advertise it can handle scatter-gather Otherwise we make too many copies and/or passes over the data. I didnt understand this last bit - you are still going to go over the list regardless of whether you call -hard_start_xmit() once or multiple times over the same list, no? In the later case i am assuming a trimmed down -hard_start_xmit() UDP is too easy a test case in fact :-) I learnt a lot about the behavior out of doing udp (and before that with pktgen); theres a lot of driver habits that may need to be tuned before batching becomes really effective - which is easier to see with udp than with tcp. 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: [RFC][NET_SCHED] explict hold dev tx lock
On Mon, 2007-17-09 at 14:27 +0400, Evgeniy Polyakov wrote: How many cpu collisions you are seeing? On 4 CPUs which were always transmitting very few - there was contention in the range of 100 per million attempts. Note: it doesnt matter that 4 cpus were busy, this lock is contended at max (for all NAPI drivers i poked into) between two CPUs. Did I understand you right, that you replaced trylock with lock and thus removed collision handling and got better results? Yes, a small one with the 4 CPUs and no irq binding. Note that in the test cases i run, the contention for queue lock was high (since all CPUs were busy processing traffic). I think as the the number of CPUs go up, this will become more prominent. The choice is between contending for queue lock or this lock. One lock is contended by max of two cpus, the other by N cpus. As N goes up, you want to have more mercy on the one that is contended by N cpus. Did that make sense? 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: [PATCH][NETNS] Use list_for_each_entry_continue_reverse in setup_net
Pavel Emelyanov [EMAIL PROTECTED] writes:
I proposed introducing a list_for_each_entry_continue_reverse
macro to be used in setup_net() when unrolling the failed
-init callback.
Here is the macro and some more cleanup in the setup_net() itself
to remove one variable from the stack :) Minor, but the code
looks nicer.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
Acked-by: Eric W. Biederman [EMAIL PROTECTED]
Pavel if you are going down this route. Could you look at
cleanup_net as well. The reverse walk there could probably
benefit from being list_for_each_entry_reverse.
Eric
---
include/linux/list.h | 14 ++
net/core/net_namespace.c |8 +++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/linux/list.h b/include/linux/list.h
index f29fc9c..ad9dcb9 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -525,6 +525,20 @@ static inline void list_splice_init_rcu(
pos = list_entry(pos-member.next, typeof(*pos), member))
/**
+ * list_for_each_entry_continue_reverse - iterate backwards from the given
point
+ * @pos: the type * to use as a loop cursor.
+ * @head:the head for your list.
+ * @member: the name of the list_struct within the struct.
+ *
+ * Start to iterate over list of given type backwards, continuing after
+ * the current position.
+ */
+#define list_for_each_entry_continue_reverse(pos, head, member) \
+ for (pos = list_entry(pos-member.prev, typeof(*pos), member); \
+ prefetch(pos-member.prev), pos-member != (head);\
+ pos = list_entry(pos-member.prev, typeof(*pos), member))
+
+/**
* list_for_each_entry_from - iterate over list of given type from the
current
point
* @pos: the type * to use as a loop cursor.
* @head:the head for your list.
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 1fc513c..a9dd261 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -102,7 +102,6 @@ static int setup_net(struct net *net)
{
/* Must be called with net_mutex held */
struct pernet_operations *ops;
- struct list_head *ptr;
int error;
memset(net, 0, sizeof(struct net));
@@ -110,8 +109,7 @@ static int setup_net(struct net *net)
atomic_set(net-use_count, 0);
error = 0;
- list_for_each(ptr, pernet_list) {
- ops = list_entry(ptr, struct pernet_operations, list);
+ list_for_each_entry(ops, pernet_list, list) {
if (ops-init) {
error = ops-init(net);
if (error 0)
@@ -120,12 +118,12 @@ static int setup_net(struct net *net)
}
out:
return error;
+
out_undo:
/* Walk through the list backwards calling the exit functions
* for the pernet modules whose init functions did not fail.
*/
- for (ptr = ptr-prev; ptr != pernet_list; ptr = ptr-prev) {
- ops = list_entry(ptr, struct pernet_operations, list);
+ list_for_each_entry_continue_reverse(ops, pernet_list, list) {
if (ops-exit)
ops-exit(net);
}
-
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: [v3 PATCH 0/2] Add RCU locking to SCTPaddress management
David Miller wrote: From: Vlad Yasevich [EMAIL PROTECTED] Date: Thu, 13 Sep 2007 15:34:35 -0400 Thanks to Sridhar Samudral and Paul McKenney for all the help and comments. I think this is a final version, unless someone else can spot more problems. I've ran this under heavy load and it the patches behaves well. I think patch 1 is a candidate for 2.6.23 since it fixes a bug, but splitting these seems a bit odd to me. I'll leave it to DaveM to decide where to put them. Since you tested this well, I've decided to put both of these patches into net-2.6 I agree it's stupid to split them up. There'll be some merge hassles when I rebase net-2.6.24, but that tree is such a monster that this is inevitable for every bug fix I queue up for 2.6.23 :-) Thanks Dave. If you want me to take a look at these issues, let me know. -vlad - 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
[net-2.6.24][patch 0/2] Dynamically allocate the loopback
This patch allows to dynamically allocate the loopback like an usual network device. This global static variable loopback_dev has been replaced by a netdev pointer and the init function does the usual allocation, initialization and registering of the loopback. This patchset is splitted in two parts, the first one is a big but trivial patch which replace the usage of the static variable loopback_dev by the usage of a pointer. The second patch is the interesting part where the loopback is dynamically allocated. -- - 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
[net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: Daniel Lezcano [EMAIL PROTECTED]
Doing this makes loopback.c a better example of how to do a
simple network device, and it removes the special case
single static allocation of a struct net_device, hopefully
making maintenance easier.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Signed-off-by: Daniel Lezcano [EMAIL PROTECTED]
Acked-By: Kirill Korotaev [EMAIL PROTECTED]
Acked-by: Benjamin Thery [EMAIL PROTECTED]
---
drivers/net/loopback.c | 69 ++---
1 file changed, 43 insertions(+), 26 deletions(-)
Index: net-2.6.24/drivers/net/loopback.c
===
--- net-2.6.24.orig/drivers/net/loopback.c
+++ net-2.6.24/drivers/net/loopback.c
@@ -202,44 +202,61 @@ static const struct ethtool_ops loopback
* The loopback device is special. There is only one instance and
* it is statically allocated. Don't do this for other devices.
*/
-struct net_device __loopback_dev = {
- .name = lo,
- .get_stats = get_stats,
- .mtu= (16 * 1024) + 20 + 20 + 12,
- .hard_start_xmit= loopback_xmit,
- .hard_header= eth_header,
- .hard_header_cache = eth_header_cache,
- .header_cache_update= eth_header_cache_update,
- .hard_header_len= ETH_HLEN, /* 14 */
- .addr_len = ETH_ALEN, /* 6*/
- .tx_queue_len = 0,
- .type = ARPHRD_LOOPBACK, /* 0x0001*/
- .rebuild_header = eth_rebuild_header,
- .flags = IFF_LOOPBACK,
- .features = NETIF_F_SG | NETIF_F_FRAGLIST
+static void loopback_setup(struct net_device *dev)
+{
+ dev-get_stats = get_stats;
+ dev-mtu= (16 * 1024) + 20 + 20 + 12;
+ dev-hard_start_xmit= loopback_xmit;
+ dev-hard_header= eth_header;
+ dev-hard_header_cache = eth_header_cache;
+ dev-header_cache_update = eth_header_cache_update;
+ dev-hard_header_len= ETH_HLEN; /* 14 */
+ dev-addr_len = ETH_ALEN; /* 6*/
+ dev-tx_queue_len = 0;
+ dev-type = ARPHRD_LOOPBACK; /* 0x0001*/
+ dev-rebuild_header = eth_rebuild_header;
+ dev-flags = IFF_LOOPBACK;
+ dev-features = NETIF_F_SG | NETIF_F_FRAGLIST
#ifdef LOOPBACK_TSO
- | NETIF_F_TSO
+ | NETIF_F_TSO
#endif
- | NETIF_F_NO_CSUM | NETIF_F_HIGHDMA
- | NETIF_F_LLTX
- | NETIF_F_NETNS_LOCAL,
- .ethtool_ops= loopback_ethtool_ops,
- .nd_net = init_net,
-};
-
-struct net_device *loopback_dev = __loopback_dev;
+ | NETIF_F_NO_CSUM
+ | NETIF_F_HIGHDMA
+ | NETIF_F_LLTX
+ | NETIF_F_NETNS_LOCAL,
+ dev-ethtool_ops= loopback_ethtool_ops;
+}
/* Setup and register the loopback device. */
static int __init loopback_init(void)
{
- int err = register_netdev(loopback_dev);
+ struct net_device *dev;
+ int err;
+
+ err = -ENOMEM;
+ dev = alloc_netdev(0, lo, loopback_setup);
+ if (!dev)
+ goto out;
+ err = register_netdev(dev);
+ if (err)
+ goto out_free_netdev;
+
+ err = 0;
+ loopback_dev = dev;
+
+out:
if (err)
panic(loopback: Failed to register netdevice: %d\n, err);
+ return err;
+out_free_netdev:
+ free_netdev(dev);
+ goto out;
return err;
};
-module_init(loopback_init);
+fs_initcall(loopback_init);
+struct net_device *loopback_dev;
EXPORT_SYMBOL(loopback_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
[net-2.6.24][patch 1/2] Dynamically allocate the loopback device - mindless changes
From: Daniel Lezcano [EMAIL PROTECTED]
This patch replaces all occurences to the static variable
loopback_dev to a pointer loopback_dev. That provides the
mindless, trivial, uninteressting change part for the dynamic
allocation for the loopback.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
Signed-off-by: Daniel Lezcano [EMAIL PROTECTED]
Acked-By: Kirill Korotaev [EMAIL PROTECTED]
Acked-by: Benjamin Thery [EMAIL PROTECTED]
---
drivers/net/loopback.c |6 --
include/linux/netdevice.h|2 +-
net/core/dst.c |8
net/decnet/dn_dev.c |4 ++--
net/decnet/dn_route.c| 14 +++---
net/ipv4/devinet.c |6 +++---
net/ipv4/ipconfig.c |6 +++---
net/ipv4/ipvs/ip_vs_core.c |2 +-
net/ipv4/route.c | 18 +-
net/ipv4/xfrm4_policy.c |2 +-
net/ipv6/addrconf.c | 15 +--
net/ipv6/ip6_input.c |2 +-
net/ipv6/netfilter/ip6t_REJECT.c |2 +-
net/ipv6/route.c | 15 ++-
net/ipv6/xfrm6_policy.c |2 +-
net/xfrm/xfrm_policy.c |4 ++--
16 files changed, 55 insertions(+), 53 deletions(-)
Index: net-2.6.24/drivers/net/loopback.c
===
--- net-2.6.24.orig/drivers/net/loopback.c
+++ net-2.6.24/drivers/net/loopback.c
@@ -202,7 +202,7 @@ static const struct ethtool_ops loopback
* The loopback device is special. There is only one instance and
* it is statically allocated. Don't do this for other devices.
*/
-struct net_device loopback_dev = {
+struct net_device __loopback_dev = {
.name = lo,
.get_stats = get_stats,
.mtu= (16 * 1024) + 20 + 20 + 12,
@@ -227,10 +227,12 @@ struct net_device loopback_dev = {
.nd_net = init_net,
};
+struct net_device *loopback_dev = __loopback_dev;
+
/* Setup and register the loopback device. */
static int __init loopback_init(void)
{
- int err = register_netdev(loopback_dev);
+ int err = register_netdev(loopback_dev);
if (err)
panic(loopback: Failed to register netdevice: %d\n, err);
Index: net-2.6.24/include/linux/netdevice.h
===
--- net-2.6.24.orig/include/linux/netdevice.h
+++ net-2.6.24/include/linux/netdevice.h
@@ -742,7 +742,7 @@ struct packet_type {
#include linux/interrupt.h
#include linux/notifier.h
-extern struct net_device loopback_dev; /* The loopback
*/
+extern struct net_device *loopback_dev; /* The loopback
*/
extern rwlock_tdev_base_lock; /*
Device list lock */
Index: net-2.6.24/net/core/dst.c
===
--- net-2.6.24.orig/net/core/dst.c
+++ net-2.6.24/net/core/dst.c
@@ -278,13 +278,13 @@ static inline void dst_ifdown(struct dst
if (!unregister) {
dst-input = dst-output = dst_discard;
} else {
- dst-dev = loopback_dev;
- dev_hold(loopback_dev);
+ dst-dev = loopback_dev;
+ dev_hold(dst-dev);
dev_put(dev);
if (dst-neighbour dst-neighbour-dev == dev) {
- dst-neighbour-dev = loopback_dev;
+ dst-neighbour-dev = loopback_dev;
dev_put(dev);
- dev_hold(loopback_dev);
+ dev_hold(dst-neighbour-dev);
}
}
}
Index: net-2.6.24/net/decnet/dn_dev.c
===
--- net-2.6.24.orig/net/decnet/dn_dev.c
+++ net-2.6.24/net/decnet/dn_dev.c
@@ -869,10 +869,10 @@ last_chance:
rv = dn_dev_get_first(dev, addr);
read_unlock(dev_base_lock);
dev_put(dev);
- if (rv == 0 || dev == loopback_dev)
+ if (rv == 0 || dev == loopback_dev)
return rv;
}
- dev = loopback_dev;
+ dev = loopback_dev;
dev_hold(dev);
goto last_chance;
}
Index: net-2.6.24/net/decnet/dn_route.c
===
--- net-2.6.24.orig/net/decnet/dn_route.c
+++ net-2.6.24/net/decnet/dn_route.c
@@ -887,7 +887,7 @@ static int dn_route_output_slow(struct d
.scope = RT_SCOPE_UNIVERSE,
} },
.mark = oldflp-mark,
- .iif = loopback_dev.ifindex,
+ .iif = loopback_dev-ifindex,
.oif = oldflp-oif };
struct dn_route *rt = NULL;
struct net_device *dev_out = NULL, *dev;
[PATCH][NETNS] Use list_for_each_entry_continue_reverse in setup_net
[snip]
Pavel if you are going down this route. Could you look at
cleanup_net as well. The reverse walk there could probably
benefit from being list_for_each_entry_reverse.
Oh! Thanks a lot ;) Here's the new patch.
Log:
I proposed introducing a list_for_each_entry_continue_reverse
macro to be used in setup_net() when unrolling the failed
-init callback.
Here is the macro and some more cleanup in the setup_net() itself
to remove one variable from the stack :) Minor, but the code
looks nicer.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
Acked-by: Eric W. Biederman [EMAIL PROTECTED]
---
diff --git a/include/linux/list.h b/include/linux/list.h
index f29fc9c..ad9dcb9 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -525,6 +525,20 @@ static inline void list_splice_init_rcu(
pos = list_entry(pos-member.next, typeof(*pos), member))
/**
+ * list_for_each_entry_continue_reverse - iterate backwards from the given
point
+ * @pos: the type * to use as a loop cursor.
+ * @head: the head for your list.
+ * @member:the name of the list_struct within the struct.
+ *
+ * Start to iterate over list of given type backwards, continuing after
+ * the current position.
+ */
+#define list_for_each_entry_continue_reverse(pos, head, member)
\
+ for (pos = list_entry(pos-member.prev, typeof(*pos), member); \
+prefetch(pos-member.prev), pos-member != (head);\
+pos = list_entry(pos-member.prev, typeof(*pos), member))
+
+/**
* list_for_each_entry_from - iterate over list of given type from the current
point
* @pos: the type * to use as a loop cursor.
* @head: the head for your list.
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 1fc513c..0e6cb02 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -56,7 +56,6 @@ static void net_free(struct net *net)
static void cleanup_net(struct work_struct *work)
{
struct pernet_operations *ops;
- struct list_head *ptr;
struct net *net;
net = container_of(work, struct net, work);
@@ -69,8 +68,7 @@ static void cleanup_net(struct work_stru
net_unlock();
/* Run all of the network namespace exit methods */
- list_for_each_prev(ptr, pernet_list) {
- ops = list_entry(ptr, struct pernet_operations, list);
+ list_for_each_entry_reverse(ops, pernet_list, list) {
if (ops-exit)
ops-exit(net);
}
@@ -102,7 +100,6 @@ static int setup_net(struct net *net)
{
/* Must be called with net_mutex held */
struct pernet_operations *ops;
- struct list_head *ptr;
int error;
memset(net, 0, sizeof(struct net));
@@ -110,8 +107,7 @@ static int setup_net(struct net *net)
atomic_set(net-use_count, 0);
error = 0;
- list_for_each(ptr, pernet_list) {
- ops = list_entry(ptr, struct pernet_operations, list);
+ list_for_each_entry(ops, pernet_list, list) {
if (ops-init) {
error = ops-init(net);
if (error 0)
@@ -120,12 +116,12 @@ static int setup_net(struct net *net)
}
out:
return error;
+
out_undo:
/* Walk through the list backwards calling the exit functions
* for the pernet modules whose init functions did not fail.
*/
- for (ptr = ptr-prev; ptr != pernet_list; ptr = ptr-prev) {
- ops = list_entry(ptr, struct pernet_operations, list);
+ list_for_each_entry_continue_reverse(ops, pernet_list, list) {
if (ops-exit)
ops-exit(net);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc4-mm1 OOPS in forcedeth?
On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote: I have an Oops that may be related: BUG: unable to handle kernel NULL pointer dereference at virtual address 0025 printing eip: c037d81b *pde = Oops: [#1] last sysfs file: /devices/pci:00/:00:01.0/:01:00.0/class Pid: 0, comm: swapper Not tainted (2.6.23-rc4-mm1-config2 #2) EIP: 0060:[c037d81b] EFLAGS: 00010246 CPU: 0 EIP is at tcp_rto_min+0xb/0x15 EAX: 0032 EBX: c4c98b68 ECX: fffe EDX: ESI: c4c98b68 EDI: c055f600 EBP: c4432e40 ESP: c0596dec DS: 007b ES: 007b FS: GS: SS: 0068 Process swapper (pid: 0, ti=c0596000 task=c052a340 task.ti=c0568000) Stack: c037d8de c4c98b68 c4c98b68 c037e0ec 0001 c037f879 c052a8b4 c052a340 0001 c25e1e60 0001 8c176265 8c17678a 0001 0001 8c17678a 8600 007d8b21 Call Trace: [c037d8de] tcp_rtt_estimator+0xb9/0xfe [c037e0ec] tcp_ack_saw_tstamp+0x14/0x43 [c037f879] tcp_ack+0x6b8/0x17b8 [c03833cc] tcp_rcv_established+0x519/0x5f1 [c038838d] tcp_v4_do_rcv+0x28/0x2f8 [c038a4ce] tcp_v4_rcv+0x7df/0x83d [c0372542] ip_local_deliver+0xcc/0x148 [c0372975] ip_rcv+0x3b7/0x3de [c035fa0e] netif_receive_skb+0x17a/0x1c2 [c02cc121] rtl8139_poll+0x2d9/0x425 [c03616d7] net_rx_action+0xa8/0xc8 [c011e8e0] __do_softirq+0x40/0x90 [c010635d] do_softirq+0x4d/0xb6 === INFO: lockdep is turned off. Code: 24 8b 82 88 03 00 00 89 82 40 05 00 00 a1 a0 23 53 c0 89 82 44 05 00 00 83 c4 0c 5b 5e 5f 5d c3 8b 90 88 00 00 00 b8 32 00 00 00 f6 42 25 20 74 03 8b 42 54 c3 56 85 d2 b9 01 00 00 00 0f 45 ca EIP: [c037d81b] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec Kernel panic - not syncing: Fatal exception in interrupt Hi, Any solutions for this one? I too have been hitting it on my system. === BUG: unable to handle kernel NULL pointer dereference at virtual address 0025 printing eip: c03e790d *pdpt = 097c2001 1*pde = Oops: [#1] SMP last sysfs file: /class/vc/vcs1/dev Modules linked in: Pid: 0, comm: swapper Not tainted (2.6.23-rc4-mm1-cpuctl #12) EIP: 0060:[c03e790d] EFLAGS: 00010246 CPU: 0 EIP is at tcp_rto_min+0xe/0x19 EAX: 0032 EBX: cc4a8180 ECX: 0095 EDX: ESI: cc4a8180 EDI: c05b28e0 EBP: c05c7cfc ESP: c05c7cfc DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Process swapper (pid: 0, ti=c05c6000 task=c0559cc0 task.ti=c05c6000) Stack: c05c7d0c c03e79d2 cc4a8180 cc4a8180 c05c7d18 c03e9eb2 cc48a200 c05c7d68 c03ea37b 0001 ff8f ca52e8c0 005c7d48 006f7c09 0001 86cff480 0001 000c 000333ff c05c7d94 Call Trace: [c0105c64] show_trace_log_lvl+0x19/0x2e [c0105d26] show_stack_log_lvl+0x99/0xa8 [c0105e2e] show_registers+0xb6/0x185 [c010604a] die+0x108/0x1ed [c0419b3e] do_page_fault+0x64e/0x735 [c04180b2] error_code+0x72/0x78 [c03e79d2] tcp_rtt_estimator+0xba/0x100 [c03e9eb2] tcp_ack_saw_tstamp+0x17/0x47 [c03ea37b] tcp_clean_rtx_queue+0x298/0x45d [c03eaac2] tcp_ack+0x183/0x2d4 [c03ec6a0] tcp_rcv_established+0xd3/0x5ba [c03f35ae] tcp_v4_do_rcv+0x25/0xc2 [c03f3ac0] tcp_v4_rcv+0x475/0x7c0 [c03db831] ip_local_deliver+0xd9/0x17a [c03dbcf2] ip_rcv+0x420/0x45a [c03c65be] netif_receive_skb+0x22b/0x249 [c02e215f] tg3_rx+0x24c/0x359 [c02e2349] tg3_poll+0xdd/0x17c [c03c6814] net_rx_action+0x114/0x14a [c0129163] __do_softirq+0x73/0xe6 [c012920f] do_softirq+0x39/0x51 [c012928d] irq_exit+0x47/0x49 [c0106a95] do_IRQ+0x5d/0x71 [c01058a2] common_interrupt+0x2e/0x34 [c0103123] cpu_idle+0x9e/0xb7 [c041557e] rest_init+0x52/0x54 [c05cc73d] start_kernel+0x21f/0x221 [] 0x0 === INFO: lockdep is turned off. Code: 75 07 89 d8 e8 32 fa ff ff 83 7e 50 7f 76 09 89 f2 89 d8 e8 fc fa ff ff 5b 5e 5f 5d c3 55 8b 90 88 00 00 00 89 e5 b8 32 00 00 00 f6 42 25 20 74 03 8b 42 54 5d c3 5 EIP: [c03e790d] tcp_rto_min+0xe/0x19 SS:ESP 0068:c05c7cfc Kernel panic - not syncing: Fatal exception in interrupt .config follows. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc4-mm1-cpuctl # Mon Sep 17 15:54:33 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT
Re: [RFC][NET_SCHED] explict hold dev tx lock
On Mon, Sep 17, 2007 at 09:03:58AM -0400, jamal ([EMAIL PROTECTED]) wrote: Did I understand you right, that you replaced trylock with lock and thus removed collision handling and got better results? Yes, a small one with the 4 CPUs and no irq binding. Note that in the test cases i run, the contention for queue lock was high (since all CPUs were busy processing traffic). I think as the the number of CPUs go up, this will become more prominent. The choice is between contending for queue lock or this lock. One lock is contended by max of two cpus, the other by N cpus. As N goes up, you want to have more mercy on the one that is contended by N cpus. Did that make sense? I think if number of cpus grows and there is no interupt binding, system will not scale very well anyway, but your description makes sense, thanks. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc4-mm1 OOPS in forcedeth?
I have also seen this OOPS on e1000 card. So, looks like driver independent. By the way, this one has been triggered in a semi-stable way by the 'git-pull' Regards, Den Dhaval Giani wrote: On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote: I have an Oops that may be related: BUG: unable to handle kernel NULL pointer dereference at virtual address 0025 printing eip: c037d81b *pde = Oops: [#1] last sysfs file: /devices/pci:00/:00:01.0/:01:00.0/class Pid: 0, comm: swapper Not tainted (2.6.23-rc4-mm1-config2 #2) EIP: 0060:[c037d81b] EFLAGS: 00010246 CPU: 0 EIP is at tcp_rto_min+0xb/0x15 EAX: 0032 EBX: c4c98b68 ECX: fffe EDX: ESI: c4c98b68 EDI: c055f600 EBP: c4432e40 ESP: c0596dec DS: 007b ES: 007b FS: GS: SS: 0068 Process swapper (pid: 0, ti=c0596000 task=c052a340 task.ti=c0568000) Stack: c037d8de c4c98b68 c4c98b68 c037e0ec 0001 c037f879 c052a8b4 c052a340 0001 c25e1e60 0001 8c176265 8c17678a 0001 0001 8c17678a 8600 007d8b21 Call Trace: [c037d8de] tcp_rtt_estimator+0xb9/0xfe [c037e0ec] tcp_ack_saw_tstamp+0x14/0x43 [c037f879] tcp_ack+0x6b8/0x17b8 [c03833cc] tcp_rcv_established+0x519/0x5f1 [c038838d] tcp_v4_do_rcv+0x28/0x2f8 [c038a4ce] tcp_v4_rcv+0x7df/0x83d [c0372542] ip_local_deliver+0xcc/0x148 [c0372975] ip_rcv+0x3b7/0x3de [c035fa0e] netif_receive_skb+0x17a/0x1c2 [c02cc121] rtl8139_poll+0x2d9/0x425 [c03616d7] net_rx_action+0xa8/0xc8 [c011e8e0] __do_softirq+0x40/0x90 [c010635d] do_softirq+0x4d/0xb6 === INFO: lockdep is turned off. Code: 24 8b 82 88 03 00 00 89 82 40 05 00 00 a1 a0 23 53 c0 89 82 44 05 00 00 83 c4 0c 5b 5e 5f 5d c3 8b 90 88 00 00 00 b8 32 00 00 00 f6 42 25 20 74 03 8b 42 54 c3 56 85 d2 b9 01 00 00 00 0f 45 ca EIP: [c037d81b] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec Kernel panic - not syncing: Fatal exception in interrupt - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Linux Network Load Balancing is out :-)
Hi all! I've just released my first beta of Linux Network Load Balancing it's a driver (+ userland tool) to make decentered load balancing clusters. I hope someone is interested in the project and could do some testing in decent environments (I've just done some laboratory test in a 3 virtualized node cluster environment, but nothing more than this). Sources and some documentation on http://lnlb.sourceforge.net/ Greetings, Primiano Tucci - 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] Rename struct net to struct netns
The name struct net is too generic. There already were
some people who wanted to have some better name (for
easier grep for example). I propose the struct netns one.
The patch is (already) huge (sorry), but it's nothing but
sed -e s/struct net\/struct netns/g
If this name is bad as well, let's select a new one
before the struct net floods the kernel.
Signed-off-by: Pavel Emelyanov [EMAIL PROTECTED]
---
drivers/net/pppoe.c |2 -
drivers/net/pppol2tp.c |2 -
drivers/net/pppox.c |2 -
fs/proc/proc_net.c | 18 ++--
include/linux/if_bridge.h|2 -
include/linux/if_pppox.h |2 -
include/linux/if_vlan.h |2 -
include/linux/net.h |4 +-
include/linux/netdevice.h| 30 ++--
include/linux/netlink.h |6 ++--
include/linux/nsproxy.h |2 -
include/linux/proc_fs.h | 14 -
include/net/llc_conn.h |2 -
include/net/net_namespace.h | 22 +++
include/net/rtnetlink.h |2 -
include/net/sock.h |4 +-
include/net/wext.h | 14 -
net/8021q/vlan.c |4 +-
net/appletalk/ddp.c |2 -
net/atm/common.c |2 -
net/atm/common.h |2 -
net/atm/pvc.c|2 -
net/atm/svc.c|4 +-
net/ax25/af_ax25.c |2 -
net/bluetooth/af_bluetooth.c |2 -
net/bluetooth/bnep/sock.c|2 -
net/bluetooth/cmtp/sock.c|2 -
net/bluetooth/hci_sock.c |2 -
net/bluetooth/hidp/sock.c|2 -
net/bluetooth/l2cap.c|4 +-
net/bluetooth/rfcomm/sock.c |4 +-
net/bluetooth/sco.c |4 +-
net/bridge/br_ioctl.c|2 -
net/bridge/br_private.h |2 -
net/core/dev.c | 62 +--
net/core/dev_mcast.c |8 ++---
net/core/ethtool.c |2 -
net/core/fib_rules.c |2 -
net/core/neighbour.c |4 +-
net/core/net_namespace.c | 24
net/core/rtnetlink.c | 20 ++---
net/core/sock.c |4 +-
net/decnet/af_decnet.c |4 +-
net/econet/af_econet.c |2 -
net/ipv4/af_inet.c |2 -
net/ipv6/af_inet6.c |2 -
net/ipx/af_ipx.c |2 -
net/irda/af_irda.c |4 +-
net/irda/irnetlink.c |2 -
net/key/af_key.c |2 -
net/llc/af_llc.c |2 -
net/llc/llc_conn.c |2 -
net/netlink/af_netlink.c | 26 +-
net/netrom/af_netrom.c |2 -
net/packet/af_packet.c |2 -
net/rose/af_rose.c |2 -
net/rxrpc/af_rxrpc.c |2 -
net/socket.c | 12
net/tipc/socket.c|2 -
net/unix/af_unix.c |4 +-
net/wireless/wext.c | 10 +++---
net/x25/af_x25.c |4 +-
62 files changed, 195 insertions(+), 195 deletions(-)
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -486,7 +486,7 @@ static struct proto pppoe_sk_proto = {
* Initialize a new struct sock.
*
**/
-static int pppoe_create(struct net *net, struct socket *sock)
+static int pppoe_create(struct netns *net, struct socket *sock)
{
int error = -ENOMEM;
struct sock *sk;
--- a/drivers/net/pppol2tp.c
+++ b/drivers/net/pppol2tp.c
@@ -1423,7 +1423,7 @@ static struct proto pppol2tp_sk_proto =
/* socket() handler. Initialize a new struct sock.
*/
-static int pppol2tp_create(struct net *net, struct socket *sock)
+static int pppol2tp_create(struct netns *net, struct socket *sock)
{
int error = -ENOMEM;
struct sock *sk;
--- a/drivers/net/pppox.c
+++ b/drivers/net/pppox.c
@@ -104,7 +104,7 @@ int pppox_ioctl(struct socket *sock, uns
EXPORT_SYMBOL(pppox_ioctl);
-static int pppox_create(struct net *net, struct socket *sock, int protocol)
+static int pppox_create(struct netns *net, struct socket *sock, int protocol)
{
int rc = -EPROTOTYPE;
--- a/fs/proc/proc_net.c
+++ b/fs/proc/proc_net.c
@@ -26,14 +26,14 @@
#include internal.h
-struct proc_dir_entry *proc_net_create(struct net *net,
+struct proc_dir_entry *proc_net_create(struct netns *net,
const char *name, mode_t mode, get_info_t *get_info)
{
return create_proc_info_entry(name,mode, net-proc_net, get_info);
}
EXPORT_SYMBOL_GPL(proc_net_create);
-struct proc_dir_entry *proc_net_fops_create(struct net *net,
+struct proc_dir_entry *proc_net_fops_create(struct netns *net,
const char *name, mode_t mode, const struct file_operations *fops)
{
struct proc_dir_entry *res;
@@ -45,13 +45,13 @@ struct proc_dir_entry *proc_net_fops_cre
}
EXPORT_SYMBOL_GPL(proc_net_fops_create);
-void proc_net_remove(struct net *net, const char *name)
+void
Re: [PATCH] Rename struct net to struct netns
Pavel Emelyanov wrote:
The name struct net is too generic. There already were
some people who wanted to have some better name (for
easier grep for example). I propose the struct netns one.
The patch is (already) huge (sorry), but it's nothing but
sed -e s/struct net\/struct netns/g
If this name is bad as well, let's select a new one
before the struct net floods the kernel.
[ SNIP ]
--- a/include/linux/nsproxy.h
+++ b/include/linux/nsproxy.h
@@ -29,7 +29,7 @@ struct nsproxy {
struct mnt_namespace *mnt_ns;
struct pid_namespace *pid_ns;
struct user_namespace *user_ns;
- struct net *net_ns;
+ struct netns *net_ns;
IMHO, if we want to be consistent with all the rest of the namespaces,
that should be net_namespace.
[ SNIP ]
-
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] iw_cxgb3: Support iwarp-only interfaces to avoid 4-tuple conflicts.
Evgeniy Polyakov wrote:
Hi Steve.
On Sat, Sep 15, 2007 at 10:56:46AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote:
The iWARP driver must translate all listens on address 0.0.0.0 to the
set of rdma-only ip addresses for the device in question. This prevents
incoming connect requests to the TCP ipaddresses from going up the
rdma stack.
If the only solutions to solve a problem with hardware are to steal
packets or became a real device, then real device is much more
appropriate. Is that correct?
This is a real device. I don't understand your question? Packets
aren't being stolen.
I meant port from main network stack. Sorry for confusion.
+static void insert_ifa(struct iwch_dev *rnicp, struct in_ifaddr *ifa)
+{
+ struct iwch_addrlist *addr;
+
+ addr = kmalloc(sizeof *addr, GFP_KERNEL);
As a small nitpick: this wants to be sizeof(struct in_ifaddr)
No, insert_ifa() allocates a struct iwch_addrlist, which has 2 fields: a
list_head for linking, and a struct in_ifaddr pointer.
sizeof(struct iwch_addrlist) of course, not (*addr).
To simplify grep.
+ if (!addr) {
+ printk(KERN_ERR MOD %s - failed to alloc memory!\n,
+ __FUNCTION__);
+ return;
+ }
+ addr-ifa = ifa;
+ mutex_lock(rnicp-mutex);
+ list_add_tail(addr-entry, rnicp-addrlist);
+ mutex_unlock(rnicp-mutex);
+}
What about providing error back to caller and fail to register?
There are two causes where this is called: 1) during module init to
populate the list of iwarp addresses. If we failed in that case then, I
_could_ then not register. 2) we get called via the notifier mechanism
when an address is added. If that fails, the caller doesn't care (since
we're on the notifier callout thread). But the code could perhaps
unregister the device. I prefer just logging an error in case 2. I'll
look into not registering if we cannot get any address due to lack of
memory. But there's another case: we load the module and the admin
hasn't yet created the ethX:iw interface.
Perhaps I should change the code to only register as a working rdma
device _when_ we get at least one ethX:iwY interface created? Whatchathink?
Does second case ends up with problem you described in the initial
e-mail not being fixed?
No, the 2nd case (a failure to get the list of iwarp-only ip addresses)
will cause rdma apps to not receive any incoming connections.
Consider we have eth1 with 1.1.1.1/24. Next, the admin creates the
iwarp interface thusly:
ifconfig eth1:iw 2.2.2.2 netmask 255.255.255.0 up
The iw_cxgb3 driver gets a netblock notifier event for the addition of
the eth1:iw interface, but FAILS to alloc the memory to keep track that
2.2.2.2 is the iwarp-only address.
Next an rdma app binds to 0.0.0.0, port X. The iw_cxgb3 attempts to map
0.0.0.0 to the set of valid iwarp addresses, but there are none.
iw_cxgb3 logs a warning saying no addresses are available. The
application ends up not listening to any address.
So TCP apps aren't affected.
Also, if the admin notes the error log entry, and re-initializes the
eth1:iw interface -and- this time the kmalloc() works, then the existing
rdma app bound to 0.0.0.0 port X will then start receiving connect
requests to 2.2.2.2 port X.
Hope this makes sense.
+static inline int is_iwarp_label(char *label)
+{
+ char *colon;
+
+ colon = strchr(label, ':');
+ if (colon !strncmp(colon+1, iw, 2))
+ return 1;
+ return 0;
+}
I.e. it is not allowed to create ':iw' alias for anyone else?
Well, looks crappy, but if it is the only solution...
It is kinda crappy. But I don't see a better solution. Any ideas?
Does creating the whole new netdevice is a too big overhead, or is it
considered bad idea?
I think its too big overhead, and pretty invasive on the low level cxgb3
driver. I think having a device in the 'ifconfig -a' after iw_cxgb3 is
loaded and devices discovered would be a good thing for the admin. This
is the angle Roland suggested. I'm just not sure how to implement it.
But if someone could explain how I might create this full netdevice as a
pseudo device on top of the real one, maybe I could implement it.
Note that non TCP traffic still needs to utilize this interface for ND
to work properly with the RDMA core.
+static struct iwch_listen_entry *alloc_listener(struct iwch_listen_ep
*ep,
+ __be32 addr)
Do you know, that cxgb3 function names suck? :)
Especially get_skb().
+{
+ struct iwch_dev *h = to_iwch_dev(ep-com.cm_id-device);
+ struct iwch_listen_entry *le;
+
+ le = kmalloc(sizeof *le, GFP_KERNEL);
Wants to be sizeof(struct iwch_listen_entry) and in other places too.
Do you mean I shouldn't use sizeof *le, but rather sizeof(struct
iwch_listen_entry)? Is that the preferred coding style?
Yes, exactly.
Ok, now I get it. :)
Steve.
-
To unsubscribe
Re: [PATCH] Rename struct net to struct netns
Daniel Lezcano wrote:
Pavel Emelyanov wrote:
The name struct net is too generic. There already were
some people who wanted to have some better name (for
easier grep for example). I propose the struct netns one.
The patch is (already) huge (sorry), but it's nothing but
sed -e s/struct net\/struct netns/g
If this name is bad as well, let's select a new one
before the struct net floods the kernel.
[ SNIP ]
--- a/include/linux/nsproxy.h
+++ b/include/linux/nsproxy.h
@@ -29,7 +29,7 @@ struct nsproxy {
struct mnt_namespace *mnt_ns;
struct pid_namespace *pid_ns;
struct user_namespace *user_ns;
-struct net *net_ns;
+struct netns *net_ns;
IMHO, if we want to be consistent with all the rest of the namespaces,
that should be net_namespace.
Sure it's a good argument.
But I find that 'net', although it is an uber generic name,
represents its contents appropriately: its function is to store
all data for a network stack, so it is what represent a network
in the kernel.
Anyway, if we want to change it, I think net_namespace is better
than netns because of the consistency argument given by Daniel.
(But it's longer :( )
Just my 2 cents.
Benjamin
[ SNIP ]
-
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
--
B e n j a m i n T h e r y - BULL/DT/Open Software RD
http://www.bull.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: [ofa-general] Re: [PATCH v2] iw_cxgb3: Support iwarp-only interfaces to avoid 4-tuple conflicts.
+addr = kmalloc(sizeof *addr, GFP_KERNEL); As a small nitpick: this wants to be sizeof(struct in_ifaddr) See chapter 14 of CodingStyle document. kmalloc(sizeof *addr... is correct. - Sean - 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: [ofa-general] Re: [PATCH v2] iw_cxgb3: Support iwarp-only interfaces to avoid 4-tuple conflicts.
On Mon, Sep 17, 2007 at 09:09:06AM -0700, Sean Hefty ([EMAIL PROTECTED]) wrote: +addr = kmalloc(sizeof *addr, GFP_KERNEL); As a small nitpick: this wants to be sizeof(struct in_ifaddr) See chapter 14 of CodingStyle document. kmalloc(sizeof *addr... is correct. Come on, do not start a flame war about how parameters into kmalloc should be provided - there are much more serious issues unresolved yes. It does help grepping the code, but if you feel that this is a serious threat, then use your preferred way. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net-2.6.24 plans
From: Jeff Garzik [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 00:10:40 -0400 David Miller wrote: We've touched so much in net-2.6.24 that we really should be auditing the thing and fixing any bugs that have been added. If you're bored and looking for something to do, pick an odd NAPI driver and audit it in the net-2.6.24 tree. You could try that weird post patches on the list thing for review. I dunno about sparc64, but IMO any networking work you do yourself and commit yourself should also be sent to the list for review. I sent every single revision of the NAPI struct patch to netdev 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] [-MM, FIX V4] e1000e: incorporate napi_struct changes from net-2.6.24.git
Jiri Slaby wrote:
On 12/23/-28158 08:59 PM, Auke Kok wrote:
This incorporates the new napi_struct changes into e1000e. Included
bugfix for ifdown hang from Krishna Kumar for e1000.
Disabling polling is no longer needed at init time, so remove
napi_disable() call from _probe().
This also fixes an endless polling loop where the driver signalled
polling done improperly back to the stack.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000e/e1000.h |2 ++
drivers/net/e1000e/netdev.c | 40
2 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index c57e35a..d2499bb 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -187,6 +187,8 @@ struct e1000_adapter {
struct e1000_ring *tx_ring /* One per active queue */
cacheline_aligned_in_smp;
+struct napi_struct napi;
+
unsigned long tx_queue_len;
unsigned int restart_queue;
u32 txd_cmd;
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 372da46..eeb40cc 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1149,12 +1149,12 @@ static irqreturn_t e1000_intr_msi(int irq, void
*data)
mod_timer(adapter-watchdog_timer, jiffies + 1);
}
-if (netif_rx_schedule_prep(netdev)) {
+if (netif_rx_schedule_prep(netdev, adapter-napi)) {
adapter-total_tx_bytes = 0;
adapter-total_tx_packets = 0;
adapter-total_rx_bytes = 0;
adapter-total_rx_packets = 0;
-__netif_rx_schedule(netdev);
+__netif_rx_schedule(netdev, adapter-napi);
} else {
atomic_dec(adapter-irq_sem);
}
@@ -1212,12 +1212,12 @@ static irqreturn_t e1000_intr(int irq, void *data)
mod_timer(adapter-watchdog_timer, jiffies + 1);
}
-if (netif_rx_schedule_prep(netdev)) {
+if (netif_rx_schedule_prep(netdev, adapter-napi)) {
adapter-total_tx_bytes = 0;
adapter-total_tx_packets = 0;
adapter-total_rx_bytes = 0;
adapter-total_rx_packets = 0;
-__netif_rx_schedule(netdev);
+__netif_rx_schedule(netdev, adapter-napi);
} else {
atomic_dec(adapter-irq_sem);
}
@@ -1662,10 +1662,10 @@ set_itr_now:
* e1000_clean - NAPI Rx polling callback
* @adapter: board private structure
**/
-static int e1000_clean(struct net_device *poll_dev, int *budget)
+static int e1000_clean(struct napi_struct *napi, int budget)
{
-struct e1000_adapter *adapter;
-int work_to_do = min(*budget, poll_dev-quota);
+struct e1000_adapter *adapter = container_of(napi, struct
e1000_adapter, napi);
+struct net_device *poll_dev = adapter-netdev;
int tx_cleaned = 0, work_done = 0;
/* Must NOT use netdev_priv macro here. */
@@ -1684,25 +1684,19 @@ static int e1000_clean(struct net_device *poll_dev,
int *budget)
spin_unlock(adapter-tx_queue_lock);
}
-adapter-clean_rx(adapter, work_done, work_to_do);
-*budget -= work_done;
-poll_dev-quota -= work_done;
+adapter-clean_rx(adapter, work_done, budget);
/* If no Tx and not enough Rx work done, exit the polling mode */
-if ((!tx_cleaned (work_done == 0)) ||
+if ((!tx_cleaned (work_done budget)) ||
Hi,
sorry to say that, but this change since last your patch changes nothing on my
machine (ksoftirq spinning at 100 % of CPU usage), I have some traces for you
if
it helps:
davem pulled all the drivers and fixups into net-2.6.24 including e1000e (and
tested it yesterday)... Perhaps you can give that tree a try?
I have no lockups here as well anymore, so I'm wondering if you accidentally
used
V3 of the patch.
Can you give today's net-2.6.24 a try?
Auke
-
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/10 REV5] Implement skb batching and support in IPoIB/E1000
From: jamal [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 08:51:40 -0400 On Sun, 2007-16-09 at 20:13 -0700, David Miller wrote: This only makes sense for devices which can 1) scatter-gather and 2) checksum on transmit. If you have knowledge there are enough descriptors in the driver to cover all skbs you are passing, do you need to have #1? Note i dont touch fragments, i am assuming the driver is smart enough to handle them otherwise it wont advertise it can handle scatter-gather Yes, because you can have multiple descriptors per SKB because we have the head part in skb-data and the rest in the page vector. Thus the device must be able to handle multiple descriptors representing one packet. Otherwise we make too many copies and/or passes over the data. I didnt understand this last bit - you are still going to go over the list regardless of whether you call -hard_start_xmit() once or multiple times over the same list, no? In the later case i am assuming a trimmed down -hard_start_xmit() If the device can't checksum, we have to pass over the data to compute the checksum and stick it into the headers. If the device can't scatter-gather, we have to allocate and copy into a linear buffer. Otherwise it's just bumping page reference counts and adjusting offsets, no data touching at all. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rename struct net to struct netns
From: Pavel Emelyanov [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 18:46:07 +0400 The name struct net is too generic. There already were some people who wanted to have some better name (for easier grep for example). I propose the struct netns one. I don't see any reason to change the name, 'net' is just fine with me. It's in the struct/union namespace so even if you use a variable or a function with the same name it's unambiguous. If C would allow it we'd be using 'if' instead of 'netdevice' 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
Re: e1000 driver and samba
To me it suggests that your speed is not full-duplex. Check `ethtool eth0` output and see if your link is full duplex or not. also check previous kernel messages and see what the e1000 driver posted there for link speed messages (as in e1000: Link is UP speed XXX duplex YYY) from dmesg: device eth4 entered promiscuous mode e1000: eth4: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [It looks like the e1000 driver that came in the kernel is Intel(R) PRO/1000 Network Driver - version 7.3.20-k2 - would there be any benefit to trying the 7.6.5 from the Intel website again?] from ethtool: beehive:~# ethtool eth4 Settings for eth4: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x0007 (7) Link detected: yes As best I can tell, the card is in full duplex mode. Because of a 'running out of ideas' compulsion I disassembled and reassembled the machine completely, ran a memory test overnight, changed the cable AGAIN with a CAT6 of the shortest possible length. That plus samba-3.0.26-1 seem to have cured the disconnects - as a matter of fact I CAN'T get the machine to disconnect anymore, even under completely artificial loads (i.e. stress test quality, not average use) from five clients (I know, that isn't saying much, but it was failing spectacularly at ONE before, so I figure this may be worth mentioning). However, the incorrect file transfer still occurs with large files (500MB+). My original thought behind the disassembly/reassembly/memory test was that possibly the issue was hardware related, but I seem to have eliminated that possiblity. Further, I checked. There are currently 20+ machines in production with the same debian distribution and kernel, running on 975X / P965 boards, all with r8169 drivers, doing RAID5 fileserver duty. They work. With significant numbers (up to 65) of clients. This one doesn't want to. I can't help but think it's the NIC/driver combo, but it seems absurd to me. Rgds, LF Cheers, Auke - 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/2] Add ICMPMsgStats MIB (RFC 4293) [RESEND]
From: David Stevens [EMAIL PROTECTED] Date: Sun, 16 Sep 2007 22:24:27 -0600 Dave, Thanks. That rev2 was for v6-only; I didn't see anythng about the v4 patch (below, in case it fell through the cracks). It did fall through the cracks, I've applied this and will push unless some serious issue is found. Generally, when people post patch updates I delete entirely the original patch set from my mailbox, therefore you should always repost the entire set in order to avoid lossage and any possible confusion about which patch is still relevant. 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: [RFC][PATCH] trivial typo correction in net/ipv4/xfrm4_policy.c
From: Ian Brown [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 09:50:15 +0200 Hello, This is a trivial typo correction in net/ipv4/xfrm4_policy.c which hunted my eye... Regards, Ian Brown Signed-off-by: [EMAIL PROTECTED] Your mail client word-wrapped the patch so it doesn't apply cleanly, please report with full changelog et al. after you've corrected this. 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: e1000 driver and samba
L F wrote: To me it suggests that your speed is not full-duplex. Check `ethtool eth0` output and see if your link is full duplex or not. also check previous kernel messages and see what the e1000 driver posted there for link speed messages (as in e1000: Link is UP speed XXX duplex YYY) from dmesg: device eth4 entered promiscuous mode e1000: eth4: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [It looks like the e1000 driver that came in the kernel is Intel(R) PRO/1000 Network Driver - version 7.3.20-k2 - would there be any benefit to trying the 7.6.5 from the Intel website again?] from ethtool: beehive:~# ethtool eth4 Settings for eth4: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x0007 (7) Link detected: yes As best I can tell, the card is in full duplex mode. Because of a 'running out of ideas' compulsion I disassembled and reassembled the machine completely, ran a memory test overnight, changed the cable AGAIN with a CAT6 of the shortest possible length. The statistic we were looking at _will_ increase when running in half duplex, but if it increases when running in full duplex might indicate a hardware failure. Probably you have fixed the issue with the CAT6 cable. Can you run this new configuration with the old cable? that would eliminate the cable (or not) That plus samba-3.0.26-1 seem to have cured the disconnects - as a matter of fact I CAN'T get the machine to disconnect anymore, even under completely artificial loads (i.e. stress test quality, not average use) from five clients (I know, that isn't saying much, but it was failing spectacularly at ONE before, so I figure this may be worth mentioning). However, the incorrect file transfer still occurs with large files (500MB+). My original thought behind the disassembly/reassembly/memory test was that possibly the issue was hardware related, but I seem to have eliminated that possiblity. Further, I checked. There are currently 20+ machines in production with the same debian distribution and kernel, running on 975X / P965 boards, all with r8169 drivers, doing RAID5 fileserver duty. They work. With significant numbers (up to 65) of clients. This one doesn't want to. I can't help but think it's the NIC/driver combo, but it seems absurd to me. A single port failure on a switch can also happen, and samba is definately a good test for defective hardware. I cannot rule out anything from the information we have gotten yet. Auke - 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 9031] New: TPC window is to cautious on send
On Sun, 16 Sep 2007 23:43:40 -0700 Andrew Morton [EMAIL PROTECTED] wrote: On Sun, 16 Sep 2007 17:02:46 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9031 Summary: TPC window is to cautious on send Product: Networking Version: 2.5 KernelVersion: Any Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: IPV4 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This has been a longstanding bug of sorts when talking to a system that has extremely small windows (under 1.5k). The only way to give the stack on the other side a nudge is to ACK twice. Here is a sample transcript, with a max window size of 1025 bytes. 18:25:43.968358 IP dr.ea.ms.http 192.168.80.2.40246: . 37377:37633(256) ack 120 win 5840 18:25:43.992402 IP 192.168.80.2.40246 dr.ea.ms.http: . ack 37121 win 769 mss 256 18:25:44.390305 IP 192.168.80.2.40246 dr.ea.ms.http: . ack 37121 win 1025 mss 256 18:25:44.823084 IP dr.ea.ms.http 192.168.80.2.40246: . 37633:37889(256) ack 120 win 5840 If I take the nudge code out of my IP stack, it sits for an aweful long time, waiting on the next packet, when there clearly is room for a few more. Should I: 1: Have my IP stack lie about the window till it is important? 2: Something else? I can't see any good reason for the large delay, since it is on a serial link, via SLIP. I can point you to source code that will allow you to verify the problem for yourself, if you would like. See my comment, on bug report, Linux is doing Silly Window Syndrome avoidance (RFC 813) as required in host requirements RFC1122 4.2.3.4 When to Send Data A TCP MUST include a SWS avoidance algorithm in the sender. A TCP SHOULD implement the Nagle Algorithm [TCP:9] to coalesce short segments. However, there MUST be a way for an application to disable the Nagle algorithm on an individual connection. In all cases, sending data is also subject to the limitation imposed by the Slow Start algorithm (Section 4.2.2.15). The Linux mechanism to disable Nagle is setsockopt(TCP_NODELAY). -- Stephen Hemminger [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: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
On Mon, 17 Sep 2007 15:45:11 +0200 [EMAIL PROTECTED] wrote: From: Daniel Lezcano [EMAIL PROTECTED] Doing this makes loopback.c a better example of how to do a simple network device, and it removes the special case single static allocation of a struct net_device, hopefully making maintenance easier. What is before/after code and data size, does it make code smaller? -module_init(loopback_init); +fs_initcall(loopback_init); +struct net_device *loopback_dev; EXPORT_SYMBOL(loopback_dev); -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] CAN: Add documentation
On Mon, 17 Sep 2007 12:03:28 +0200 Urs Thuermann wrote: Hi, Thanks for all of this informative documentation. I have some typo/spello corrections below. This patch adds documentation for the PF_CAN protocol family. Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED] Signed-off-by: Urs Thuermann [EMAIL PROTECTED] --- Documentation/networking/00-INDEX |2 Documentation/networking/can.txt | 635 ++ 2 files changed, 637 insertions(+) Index: net-2.6.24/Documentation/networking/can.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.24/Documentation/networking/can.txt 2007-09-17 10:27:25.0 +0200 @@ -0,0 +1,635 @@ + + +1. Overview / What is Socket CAN + + +The socketcan package is an implementation of CAN protocols +(Controller Area Network) for Linux. CAN is a networking technology +which has wide-spread use in automation, embedded devices, and widespread +automotive fields. While there have been other CAN implementations +for Linux based on character devices, Socket CAN uses the Berkeley +socket API, the Linux network stack and implements the CAN device +drivers as network interfaces. The CAN socket API has been designed +as similar as possible to the TCP/IP protocols to allow programmers, +familiar with network programming, to easily learn how to use CAN +sockets. + +2. Motivation / Why using the socket API + + +Socket CAN was designed to overcome all of these limitations. A new +protocol family has been implemented which provides a socket interface +to user space applications and which builds upon the Linux network +layer, so to use all of the provided queueing functionality. Device +drivers for CAN controller hardware register itself with the Linux A device driver ... registers itself +network layer as a network device, so that CAN frames from the +controller can be passed up to the network layer and on to the CAN +protocol family module and also vice-versa. Also, the protocol family +module provides an API for transport protocol modules to register, so +that any number of transport protocols can be loaded or unloaded +dynamically. In fact, the can core module alone does not provide any +protocol and can not be used without loading at least one additional cannot +protocol module. Multiple sockets can be opened at the same time, +on different or the same protocol module and they can listen/send +frames on different or the same CAN IDs. Several sockets listening on +the same interface for frames with the same CAN ID are all passed the +same received matching CAN frames. An application wishing to +communicate using a specific transport protocol, e.g. ISO-TP, just +selects that protocol when opening the socket, and then can read and +write application data byte streams, without having to deal with +CAN-IDs, frames, etc. + +Similar functionality visible from user-space could be provided by a +character decive, too, but this would lead to a technically inelegant +solution for a couple of reasons: + +* Intricate usage. Instead of passing a protocol argument to + socket(2) and using bind(2) to select a CAN interface and CAN ID, an + application would have to do all these operations using ioctl(2)s. + +* Code duplication. A character device cannot make use of the Linux + network queueing code, so all that code would have to be duplicated + for CAN networking. + +* Abstraction. In most existing character-device implementations, the + hardware-specific device driver for a CAN controller directly + provides the character device for the application to work with. + This is at least very unusual in Unix systems, for both, char and ^drop comma + block devices. For example you don't have a character device for a + certain UART of a serial interface, a certain sound chip in your + computer, a SCSI or IDE controller providing access to your hard + disk or tape streamer device. Instead, you have abstraction layers + which provide a unified character or block device interface to the + application on the one hand, and a interface for hardware-specific + device drivers on the other hand. These abstractions are provided + by subsystems like the tty layer, the audio subsystem or the SCSI + and IDE subsystems for the devices mentioned above. + + The easiest way to implement a CAN device driver is as a character + without such a (complete) abstraction layer, as is done by most + existing drivers. The right way, however, would be to add such a + layer with all the functionality like registering for certain CAN + IDs,
Re: e1000 driver and samba
Kok, Auke wrote: L F wrote: tx_deferred_ok: 486 this one I wonder about, and might cause delays, I'll have to look up what it exactly could implicate though. Please do and let me know. samba 3.0.26 helped, but the issue is still there. ok, from the spec: tx_deferred_ok is what is in the DC stats register. DC stands for Deferred Count. This initially is meant to track how often the TX unit cannot send because the medium is busy in a Half-Duplex link state. To me it suggests that your speed is not full-duplex. Check `ethtool eth0` output and see if your link is full duplex or not. also check previous kernel messages and see what the e1000 driver posted there for link speed messages (as in e1000: Link is UP speed XXX duplex YYY) Shouldn't there then have been at least _some_ collisions reported in the stats? And perhaps some late collisions? 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: why does tcp_v[46]_conn_request not inc MIB stats
I'm rebasing a 500 patch tree which has tons of merge conflicts today, so I lack the time to answer your question. Suffice it to say you could do a little bit of legwork to figure out the answer by researching inet_csk_reqsk_queue_is_full() and determining what sets the state tested by that function. But you typically don't do this, you always push the queries back instead of figuring it out yourself, and that doesn't scale. It can't be all me folks, people have to be as self-sufficient as possible in order for the work to be distributed properly. - 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: why does tcp_v[46]_conn_request not inc MIB stats
David Miller wrote:
From: Rick Jones [EMAIL PROTECTED]
Date: Mon, 10 Sep 2007 11:42:18 -0700
I've been digging around to see about inducing /proc/net/tcp to show
some interesting things for listen sockets (eg backlog depth, its max,
and dropped connection requests). While there I've noticed that both
tcp_v[46]_syn_recv_sock and tcp_v[46]conn_request both check that the
listen queue is full, but only tcp_v[46]_syn_recv_sock increments some
mib stats for dropped connection requests.
They are checking two different things.
tcp_v{4,6}_conn_request is checking whether we are hitting the limit
for allowing the initial SYN and creating a new embryonic mini-socket.
Exceeding that is not a listen overflow.
I'll risk some toe chewing and ask - is the embryonic limit set based on
what one sets in the listen() call and/or system configs?
Seems that _some_ sort of stat should be incremented, even if it isn't
the listen queue overflow one?
rick jones
tcp_v{4,6}_syn_recv_sock() is processing the end of the 3-way
handshake and wants to create a full established state socket to queue
into the listening parent. This is checking the listening socket
queue limits, and indeed is a listen queue overflow if exceeded.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
Since small things fall more easily through cracks I thought I'd make
sure it didn't get lost?
rick jones
Rick Jones wrote:
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
--- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31 2007 +
+++ b/Documentation/networking/proc_net_tcp.txt Tue Sep 11 10:38:23 2007 -0700
@@ -20,8 +20,8 @@ up into 3 parts because of the length of
|| | | |-- number of unrecovered RTO timeouts
|| | |-- number of jiffies until timer expires
|| | timer_active (see below)
- ||-- receive-queue
- |--- transmit-queue
+ ||-- receive-queue or connection backlog
+ |--- transmit-queue or connection limit
10000 54165785 4 cd1e6040 25 4 27 3 -1
| || || | | | | |-- slow start size threshold,
diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--- a/net/ipv4/tcp.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp.cTue Sep 11 10:38:23 2007 -0700
@@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
info-tcpi_snd_mss = tp-mss_cache;
info-tcpi_rcv_mss = icsk-icsk_ack.rcv_mss;
- info-tcpi_unacked = tp-packets_out;
- info-tcpi_sacked = tp-sacked_out;
+ if (sk-sk_state == TCP_LISTEN) {
+ info-tcpi_unacked = sk-sk_ack_backlog;
+ info-tcpi_sacked = sk-sk_max_ack_backlog;
+ }
+ else {
+ info-tcpi_unacked = tp-packets_out;
+ info-tcpi_sacked = tp-sacked_out;
+ }
info-tcpi_lost = tp-lost_out;
info-tcpi_retrans = tp-retrans_out;
info-tcpi_fackets = tp-fackets_out;
diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
--- a/net/ipv4/tcp_diag.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_diag.c Tue Sep 11 10:38:23 2007 -0700
@@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- if (sk-sk_state == TCP_LISTEN)
+ if (sk-sk_state == TCP_LISTEN) {
r-idiag_rqueue = sk-sk_ack_backlog;
- else
+ r-idiag_wqueue = sk-sk_max_ack_backlog;
+ }
+ else {
r-idiag_rqueue = tp-rcv_nxt - tp-copied_seq;
- r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ }
if (info != NULL)
tcp_get_info(sk, info);
}
diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_ipv4.c Tue Sep 11 10:38:23 2007 -0700
@@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
sprintf(tmpbuf, %4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX
%08X %5d %8d %lu %d %p %u %u %u %u %d,
i, src, srcp, dest, destp, sk-sk_state,
- tp-write_seq - tp-snd_una,
+ sk-sk_state == TCP_LISTEN ? sk-sk_max_ack_backlog :
+(tp-write_seq - tp-snd_una),
sk-sk_state == TCP_LISTEN ? sk-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
timer_active,
diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
--- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv6/tcp_ipv6.c Tue Sep 11 10:38:23 2007 -0700
@@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
dest-s6_addr32[0], dest-s6_addr32[1],
dest-s6_addr32[2], dest-s6_addr32[3], destp,
sp-sk_state,
- tp-write_seq-tp-snd_una,
- (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_max_ack_backlog:
+ tp-write_seq-tp-snd_una,
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
+ (tp-rcv_nxt - tp-copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk-icsk_retransmits,
-
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
-
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: e1000 driver and samba
Rick Jones wrote: Kok, Auke wrote: L F wrote: tx_deferred_ok: 486 this one I wonder about, and might cause delays, I'll have to look up what it exactly could implicate though. Please do and let me know. samba 3.0.26 helped, but the issue is still there. ok, from the spec: tx_deferred_ok is what is in the DC stats register. DC stands for Deferred Count. This initially is meant to track how often the TX unit cannot send because the medium is busy in a Half-Duplex link state. To me it suggests that your speed is not full-duplex. Check `ethtool eth0` output and see if your link is full duplex or not. also check previous kernel messages and see what the e1000 driver posted there for link speed messages (as in e1000: Link is UP speed XXX duplex YYY) Shouldn't there then have been at least _some_ collisions reported in the stats? And perhaps some late collisions? well, from the documentation it sounds like the link was half-duplex, but LF reported that it's not. This then points towards a medium issue (bad cable) and after he replaced the cable, the issue went away (?). I still don't fully grasp the reason why this counter would increment and will investigate possibilities for that. My current suspicion is a physical problem, most likely cable-related. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
Stephen Hemminger wrote: On Mon, 17 Sep 2007 15:45:11 +0200 [EMAIL PROTECTED] wrote: From: Daniel Lezcano [EMAIL PROTECTED] Doing this makes loopback.c a better example of how to do a simple network device, and it removes the special case single static allocation of a struct net_device, hopefully making maintenance easier. What is before/after code and data size, does it make code smaller? Interesting question, here are the results based on the same config file. Without the patchset: -- vmlinux: textdata bss dec hex filename 2446606 188243 163840 2798689 2ab461 vmlinux loopback.o textdata bss dec hex filename 4171040 81465 5b9 drivers/net/loopback.o With the patchset: -- vmlinux: textdata bss dec hex filename 2446853 187187 163840 2797880 2ab138 ./vmlinux loopback.o textdata bss dec hex filename 609 4 12 625 271 drivers/net/loopback.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
Re: e1000 driver and samba
On 9/17/07, Kok, Auke [EMAIL PROTECTED] wrote: The statistic we were looking at _will_ increase when running in half duplex, but if it increases when running in full duplex might indicate a hardware failure. Probably you have fixed the issue with the CAT6 cable. Uhm, 'fixed' may be premature: I restarted the machine and with 22 hours uptime I am getting: tx_deferred_ok: 36254 Can you run this new configuration with the old cable? that would eliminate the cable (or not) I most certainly can. This seems to have gotten worse by a factor or 100 or more.. so am I to suspect the new cable? A single port failure on a switch can also happen, and samba is definately a good test for defective hardware. I cannot rule out anything from the information we have gotten yet. True, but I tried changing the switch ports with little change. Putting a client on the same switch port yielded no errors on the client, although unfortunately I don't have ethtool statistics on XP. The switch, btw, is a fairly generic GS108 from Netgear (there actually are two). LF - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: Rick Jones [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 11:38:09 -0700 Since small things fall more easily through cracks I thought I'd make sure it didn't get lost? Reposting the patch is often better because if you quote it then the copy I have has to be meticuliously edited to remove the quoting information. Alternatively forward the original patch posting so it does not get all the quoting material added. As is, what you've forwarded is useless to me since I also don't have the original posting. - 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] [-MM, FIX V4] e1000e: incorporate napi_struct changes from net-2.6.24.git
On 09/17/2007 06:29 PM, Kok, Auke wrote: Jiri Slaby wrote: On 12/23/-28158 08:59 PM, Auke Kok wrote: This incorporates the new napi_struct changes into e1000e. Included bugfix for ifdown hang from Krishna Kumar for e1000. Disabling polling is no longer needed at init time, so remove napi_disable() call from _probe(). This also fixes an endless polling loop where the driver signalled polling done improperly back to the stack. Signed-off-by: Auke Kok [EMAIL PROTECTED] Tested-by: Jiri Slaby [EMAIL PROTECTED] --- drivers/net/e1000e/e1000.h |2 ++ drivers/net/e1000e/netdev.c | 40 2 files changed, 18 insertions(+), 24 deletions(-) [...] I have no lockups here as well anymore, so I'm wondering if you accidentally used V3 of the patch. And so am I, it works, I ported one change to e1000 (non-e) driver and missed the return 0; removal. Fixed both of them now, so one of them caused it. thanks a lot, -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - 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] include listenq max/backlog in tcp_info and related reports - correct version/signorder
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
--- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31 2007 +
+++ b/Documentation/networking/proc_net_tcp.txt Tue Sep 11 10:38:23 2007 -0700
@@ -20,8 +20,8 @@ up into 3 parts because of the length of
|| | | |-- number of unrecovered RTO timeouts
|| | |-- number of jiffies until timer expires
|| | timer_active (see below)
- ||-- receive-queue
- |--- transmit-queue
+ ||-- receive-queue or connection backlog
+ |--- transmit-queue or connection limit
10000 54165785 4 cd1e6040 25 4 27 3 -1
| || || | | | | |-- slow start size threshold,
diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--- a/net/ipv4/tcp.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp.cTue Sep 11 10:38:23 2007 -0700
@@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
info-tcpi_snd_mss = tp-mss_cache;
info-tcpi_rcv_mss = icsk-icsk_ack.rcv_mss;
- info-tcpi_unacked = tp-packets_out;
- info-tcpi_sacked = tp-sacked_out;
+ if (sk-sk_state == TCP_LISTEN) {
+ info-tcpi_unacked = sk-sk_ack_backlog;
+ info-tcpi_sacked = sk-sk_max_ack_backlog;
+ }
+ else {
+ info-tcpi_unacked = tp-packets_out;
+ info-tcpi_sacked = tp-sacked_out;
+ }
info-tcpi_lost = tp-lost_out;
info-tcpi_retrans = tp-retrans_out;
info-tcpi_fackets = tp-fackets_out;
diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
--- a/net/ipv4/tcp_diag.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_diag.c Tue Sep 11 10:38:23 2007 -0700
@@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- if (sk-sk_state == TCP_LISTEN)
+ if (sk-sk_state == TCP_LISTEN) {
r-idiag_rqueue = sk-sk_ack_backlog;
- else
+ r-idiag_wqueue = sk-sk_max_ack_backlog;
+ }
+ else {
r-idiag_rqueue = tp-rcv_nxt - tp-copied_seq;
- r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ }
if (info != NULL)
tcp_get_info(sk, info);
}
diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_ipv4.c Tue Sep 11 10:38:23 2007 -0700
@@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
sprintf(tmpbuf, %4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX
%08X %5d %8d %lu %d %p %u %u %u %u %d,
i, src, srcp, dest, destp, sk-sk_state,
- tp-write_seq - tp-snd_una,
+ sk-sk_state == TCP_LISTEN ? sk-sk_max_ack_backlog :
+(tp-write_seq - tp-snd_una),
sk-sk_state == TCP_LISTEN ? sk-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
timer_active,
diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
--- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv6/tcp_ipv6.c Tue Sep 11 10:38:23 2007 -0700
@@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
dest-s6_addr32[0], dest-s6_addr32[1],
dest-s6_addr32[2], dest-s6_addr32[3], destp,
sp-sk_state,
- tp-write_seq-tp-snd_una,
- (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_max_ack_backlog:
+ tp-write_seq-tp-snd_una,
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
+ (tp-rcv_nxt - tp-copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk-icsk_retransmits,
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
David Miller wrote: From: Rick Jones [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 11:38:09 -0700 Since small things fall more easily through cracks I thought I'd make sure it didn't get lost? Reposting the patch is often better because if you quote it then the copy I have has to be meticuliously edited to remove the quoting information. Alternatively forward the original patch posting so it does not get all the quoting material added. As is, what you've forwarded is useless to me since I also don't have the original posting. I'm batting a thousand today... resent with a different mailer. rick - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
that setting idiag_rqueue and idiag_wqueue are sufficient.
-John
Rick Jones wrote:
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
--- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31 2007 +
+++ b/Documentation/networking/proc_net_tcp.txt Tue Sep 11 10:38:23 2007 -0700
@@ -20,8 +20,8 @@ up into 3 parts because of the length of
|| | | |-- number of unrecovered RTO timeouts
|| | |-- number of jiffies until timer expires
|| | timer_active (see below)
- ||-- receive-queue
- |--- transmit-queue
+ ||-- receive-queue or connection backlog
+ |--- transmit-queue or connection limit
10000 54165785 4 cd1e6040 25 4 27 3 -1
| || || | | | | |-- slow start size threshold,
diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--- a/net/ipv4/tcp.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp.cTue Sep 11 10:38:23 2007 -0700
@@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
info-tcpi_snd_mss = tp-mss_cache;
info-tcpi_rcv_mss = icsk-icsk_ack.rcv_mss;
- info-tcpi_unacked = tp-packets_out;
- info-tcpi_sacked = tp-sacked_out;
+ if (sk-sk_state == TCP_LISTEN) {
+ info-tcpi_unacked = sk-sk_ack_backlog;
+ info-tcpi_sacked = sk-sk_max_ack_backlog;
+ }
+ else {
+ info-tcpi_unacked = tp-packets_out;
+ info-tcpi_sacked = tp-sacked_out;
+ }
info-tcpi_lost = tp-lost_out;
info-tcpi_retrans = tp-retrans_out;
info-tcpi_fackets = tp-fackets_out;
diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
--- a/net/ipv4/tcp_diag.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_diag.c Tue Sep 11 10:38:23 2007 -0700
@@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- if (sk-sk_state == TCP_LISTEN)
+ if (sk-sk_state == TCP_LISTEN) {
r-idiag_rqueue = sk-sk_ack_backlog;
- else
+ r-idiag_wqueue = sk-sk_max_ack_backlog;
+ }
+ else {
r-idiag_rqueue = tp-rcv_nxt - tp-copied_seq;
- r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ }
if (info != NULL)
tcp_get_info(sk, info);
}
diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_ipv4.c Tue Sep 11 10:38:23 2007 -0700
@@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
sprintf(tmpbuf, %4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX
%08X %5d %8d %lu %d %p %u %u %u %u %d,
i, src, srcp, dest, destp, sk-sk_state,
- tp-write_seq - tp-snd_una,
+ sk-sk_state == TCP_LISTEN ? sk-sk_max_ack_backlog :
+(tp-write_seq - tp-snd_una),
sk-sk_state == TCP_LISTEN ? sk-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
timer_active,
diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
--- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv6/tcp_ipv6.c Tue Sep 11 10:38:23 2007 -0700
@@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
dest-s6_addr32[0], dest-s6_addr32[1],
dest-s6_addr32[2], dest-s6_addr32[3], destp,
sp-sk_state,
- tp-write_seq-tp-snd_una,
- (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_max_ack_backlog:
+ tp-write_seq-tp-snd_una,
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
+ (tp-rcv_nxt - tp-copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk-icsk_retransmits,
-
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
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[PATCH] phy: export phy_mii_ioctl
Export phy_mii_ioctl, so network drivers can use it when built as modules too. Signed-off-by: Domen Puncer [EMAIL PROTECTED] --- On 17/09/07 11:53 +0200, Sven Luther wrote: On Sat, Sep 15, 2007 at 02:14:44PM +0200, Domen Puncer wrote: Updated and split version at: http://coderock.org/tmp/fec-v3rc1/ I'll repost to lists once I run-test them. When applying those patches, the build did die with : ERROR: phy_mii_ioctl [drivers/net/fec_mpc52xx/fec_mpc52xx.ko] undefined! Apparently, phy_mii_ioctl is not an exported symbol. Domen, did you maybe forget a little snipplet when you cut the patches in different pieces ? Or did i mess up applying them ? Friendly, Sven Luther drivers/net/phy/phy.c |1 + 1 files changed, 1 insertion(+) Index: linux.git/drivers/net/phy/phy.c === --- linux.git.orig/drivers/net/phy/phy.c +++ linux.git/drivers/net/phy/phy.c @@ -409,6 +409,7 @@ int phy_mii_ioctl(struct phy_device *phy return 0; } +EXPORT_SYMBOL(phy_mii_ioctl); /** * phy_start_aneg - start auto-negotiation for this PHY device - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
John Heffner wrote:
Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
that setting idiag_rqueue and idiag_wqueue are sufficient.
Different fields for different structures. The tcp_info struct doesn't
have the idiag_mumble, so to get the two values shown in /proc/net/tcp I
use tcpi_unacked and tcpi_sacked.
For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that
then covers ss.
rick
-John
Rick Jones wrote:
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
--- a/Documentation/networking/proc_net_tcp.txtSat Sep 01 07:00:31
2007 +
+++ b/Documentation/networking/proc_net_tcp.txtTue Sep 11 10:38:23
2007 -0700
@@ -20,8 +20,8 @@ up into 3 parts because of the length of
|| | | |-- number of unrecovered RTO
timeouts
|| | |-- number of jiffies until timer
expires
|| | timer_active (see below)
- ||-- receive-queue
- |--- transmit-queue
+ ||-- receive-queue or connection
backlog
+ |--- transmit-queue or connection
limit
10000 54165785 4 cd1e6040 25 4 27 3 -1
| || || | | | | |-- slow start size
threshold, diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--- a/net/ipv4/tcp.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp.cTue Sep 11 10:38:23 2007 -0700
@@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
info-tcpi_snd_mss = tp-mss_cache;
info-tcpi_rcv_mss = icsk-icsk_ack.rcv_mss;
-info-tcpi_unacked = tp-packets_out;
-info-tcpi_sacked = tp-sacked_out;
+if (sk-sk_state == TCP_LISTEN) {
+info-tcpi_unacked = sk-sk_ack_backlog;
+info-tcpi_sacked = sk-sk_max_ack_backlog;
+}
+else {
+info-tcpi_unacked = tp-packets_out;
+info-tcpi_sacked = tp-sacked_out;
+}
info-tcpi_lost = tp-lost_out;
info-tcpi_retrans = tp-retrans_out;
info-tcpi_fackets = tp-fackets_out;
diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
--- a/net/ipv4/tcp_diag.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_diag.cTue Sep 11 10:38:23 2007 -0700
@@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
-if (sk-sk_state == TCP_LISTEN)
+if (sk-sk_state == TCP_LISTEN) {
r-idiag_rqueue = sk-sk_ack_backlog;
-else
+r-idiag_wqueue = sk-sk_max_ack_backlog;
+}
+else {
r-idiag_rqueue = tp-rcv_nxt - tp-copied_seq;
-r-idiag_wqueue = tp-write_seq - tp-snd_una;
+r-idiag_wqueue = tp-write_seq - tp-snd_una;
+}
if (info != NULL)
tcp_get_info(sk, info);
}
diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_ipv4.cTue Sep 11 10:38:23 2007 -0700
@@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
sprintf(tmpbuf, %4d: %08X:%04X %08X:%04X %02X %08X:%08X
%02X:%08lX
%08X %5d %8d %lu %d %p %u %u %u %u %d,
i, src, srcp, dest, destp, sk-sk_state,
-tp-write_seq - tp-snd_una,
+sk-sk_state == TCP_LISTEN ? sk-sk_max_ack_backlog :
+ (tp-write_seq - tp-snd_una),
sk-sk_state == TCP_LISTEN ? sk-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
timer_active,
diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
--- a/net/ipv6/tcp_ipv6.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv6/tcp_ipv6.cTue Sep 11 10:38:23 2007 -0700
@@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
dest-s6_addr32[0], dest-s6_addr32[1],
dest-s6_addr32[2], dest-s6_addr32[3], destp,
sp-sk_state,
- tp-write_seq-tp-snd_una,
- (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_max_ack_backlog:
+ tp-write_seq-tp-snd_una,
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
+(tp-rcv_nxt - tp-copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk-icsk_retransmits,
-
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
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH 7/7] CAN: Add documentation
Hi Randy, Thanks for all of this informative documentation. I have some typo/spello corrections below. Thank you very much. I have applied all your suggestions to our SVN repository. To reduce traffic on the list, I only repeat the pointer to the repository: http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/net-2.6.24 If you request, I could send PATCH 7/7 on the list again. urs - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
Rick Jones wrote: John Heffner wrote: Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems that setting idiag_rqueue and idiag_wqueue are sufficient. Different fields for different structures. The tcp_info struct doesn't have the idiag_mumble, so to get the two values shown in /proc/net/tcp I use tcpi_unacked and tcpi_sacked. For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that then covers ss. Maybe I'm missing something. get_tcp[46]_sock() does not use struct tcp_info. The only way I see using this is by doing getsockopt(TCP_INFO) on your listen socket. Is this the intention? -John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] CAN: Add documentation
Urs, On Mon, 2007-09-17 at 22:22 +0200, Urs Thuermann wrote: Thank you very much. I have applied all your suggestions to our SVN repository. To reduce traffic on the list, I only repeat the pointer to the repository: http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/net-2.6.24 If you request, I could send PATCH 7/7 on the list again. Please do, having the patch in mail makes it easier to review and to comment. Thanks, tglx - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] CAN: Add documentation
Thomas Gleixner [EMAIL PROTECTED] writes: Please do, having the patch in mail makes it easier to review and to comment. OK, here it is: This patch adds documentation for the PF_CAN protocol family. Signed-off-by: Oliver Hartkopp [EMAIL PROTECTED] Signed-off-by: Urs Thuermann [EMAIL PROTECTED] --- Documentation/networking/00-INDEX |2 Documentation/networking/can.txt | 635 ++ 2 files changed, 637 insertions(+) Index: net-2.6.24/Documentation/networking/can.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.24/Documentation/networking/can.txt 2007-09-17 21:57:29.0 +0200 @@ -0,0 +1,635 @@ + + +can.txt + +Readme file for the Controller Area Network Protocol Family (aka Socket CAN) + +This file contains + + 1 Overview / What is Socket CAN + + 2 Motivation / Why using the socket API + + 3 Socket CAN concept +3.1 receive lists +3.2 loopback +3.3 network security issues (capabilities) +3.4 network problem notifications + + 4 How to use Socket CAN +4.1 RAW protocol sockets with can_filters (SOCK_RAW) + 4.1.1 RAW socket option CAN_RAW_FILTER + 4.1.2 RAW socket option CAN_RAW_ERR_FILTER + 4.1.3 RAW socket option CAN_RAW_LOOPBACK + 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS +4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) +4.3 connected transport protocols (SOCK_SEQPACKET) +4.4 unconnected transport protocols (SOCK_DGRAM) + + 5 Socket CAN core module +5.1 can.ko module params +5.2 procfs content +5.3 writing own CAN protocol modules + + 6 CAN network drivers +6.1 general settings +6.2 loopback +6.3 CAN controller hardware filters +6.4 currently supported CAN hardware +6.5 todo + + 7 Credits + + + +1. Overview / What is Socket CAN + + +The socketcan package is an implementation of CAN protocols +(Controller Area Network) for Linux. CAN is a networking technology +which has widespread use in automation, embedded devices, and +automotive fields. While there have been other CAN implementations +for Linux based on character devices, Socket CAN uses the Berkeley +socket API, the Linux network stack and implements the CAN device +drivers as network interfaces. The CAN socket API has been designed +as similar as possible to the TCP/IP protocols to allow programmers, +familiar with network programming, to easily learn how to use CAN +sockets. + +2. Motivation / Why using the socket API + + +There have been CAN implementations for Linux before Socket CAN so the +question arises, why we have started another project. Most existing +implementations come as a device driver for some CAN hardware, they +are based on character devices and provide comparatively little +functionality. Usually, there is only a hardware-specific device +driver which provides a character device interface to send and +receive raw CAN frames, directly to/from the controller hardware. +Queueing of frames and higher-level transport protocols like ISO-TP +have to be implemented in user space applications. Also, most +character-device implementations support only one single process to +open the device at a time, similar to a serial interface. Exchanging +the CAN controller requires employment of another device driver and +often the need for adaption of large parts of the application to the +new driver's API. + +Socket CAN was designed to overcome all of these limitations. A new +protocol family has been implemented which provides a socket interface +to user space applications and which builds upon the Linux network +layer, so to use all of the provided queueing functionality. A device +driver for CAN controller hardware registers itself with the Linux +network layer as a network device, so that CAN frames from the +controller can be passed up to the network layer and on to the CAN +protocol family module and also vice-versa. Also, the protocol family +module provides an API for transport protocol modules to register, so +that any number of transport protocols can be loaded or unloaded +dynamically. In fact, the can core module alone does not provide any +protocol and cannot be used without loading at least one additional +protocol module. Multiple sockets can be opened at the same time, +on different or the same protocol module and they can listen/send +frames on different or the same CAN IDs. Several sockets listening on +the same interface for frames with the same CAN ID are all passed the +same received matching CAN frames. An application wishing to +communicate using a specific transport protocol, e.g. ISO-TP, just +selects that protocol when opening the socket, and then can read
RE: e1000 driver and samba
L F wrote: On 9/17/07, Kok, Auke [EMAIL PROTECTED] wrote: The statistic we were looking at _will_ increase when running in half duplex, but if it increases when running in full duplex might indicate a hardware failure. Probably you have fixed the issue with the CAT6 cable. Uhm, 'fixed' may be premature: I restarted the machine and with 22 hours uptime I am getting: tx_deferred_ok: 36254 Can you run this new configuration with the old cable? that would eliminate the cable (or not) I most certainly can. This seems to have gotten worse by a factor or 100 or more.. so am I to suspect the new cable? A single port failure on a switch can also happen, and samba is definately a good test for defective hardware. I cannot rule out anything from the information we have gotten yet. True, but I tried changing the switch ports with little change. Putting a client on the same switch port yielded no errors on the client, although unfortunately I don't have ethtool statistics on XP. The switch, btw, is a fairly generic GS108 from Netgear (there actually are two). it may be not well documented, but the hardware has several states that it can get into that can cause tx_deferred counter to increment. None of them are fatal to traffic, it is mainly an informational statistic. in this case it is in the due to receiving flow control; tx is paused state... he has 488 rx flow control xoff/xon, which means the switch is being overloaded and sending flow control, or the switch is passing through flow control packets (which it should not since they are multicast) and (some) client is overloaded. can you turn off flow control at the server? ethtool -A ethX rx off tx off or load the driver with parameter FlowControl=0 With the 7.6.5 driver at least you'll get confirmation of the flow control change on the Link Up: line. Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc4-mm1 OOPS in forcedeth?
Denis V. Lunev wrote: I have also seen this OOPS on e1000 card. So, looks like driver independent. By the way, this one has been triggered in a semi-stable way by the 'git-pull' Do you have this patch: commit 5c127c58ae9bf196d787815b1bd6b0aec5aee816 Author: David S. Miller [EMAIL PROTECTED] Date: Fri Aug 31 14:39:44 2007 -0700 [TCP]: 'dst' can be NULL in tcp_rto_min() Reported by Rick Jones. Signed-off-by: David S. Miller [EMAIL PROTECTED] diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 1ee7212..bbad2cd 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk) struct dst_entry *dst = __sk_dst_get(sk); u32 rto_min = TCP_RTO_MIN; - if (dst_metric_locked(dst, RTAX_RTO_MIN)) + if (dst dst_metric_locked(dst, RTAX_RTO_MIN)) rto_min = dst-metrics[RTAX_RTO_MIN-1]; return rto_min; } Regards, Den Dhaval Giani wrote: On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote: I have an Oops that may be related: BUG: unable to handle kernel NULL pointer dereference at virtual address 0025 printing eip: c037d81b *pde = Oops: [#1] last sysfs file: /devices/pci:00/:00:01.0/:01:00.0/class Pid: 0, comm: swapper Not tainted (2.6.23-rc4-mm1-config2 #2) EIP: 0060:[c037d81b] EFLAGS: 00010246 CPU: 0 EIP is at tcp_rto_min+0xb/0x15 EAX: 0032 EBX: c4c98b68 ECX: fffe EDX: ESI: c4c98b68 EDI: c055f600 EBP: c4432e40 ESP: c0596dec DS: 007b ES: 007b FS: GS: SS: 0068 Process swapper (pid: 0, ti=c0596000 task=c052a340 task.ti=c0568000) Stack: c037d8de c4c98b68 c4c98b68 c037e0ec 0001 c037f879 c052a8b4 c052a340 0001 c25e1e60 0001 8c176265 8c17678a 0001 0001 8c17678a 8600 007d8b21 Call Trace: [c037d8de] tcp_rtt_estimator+0xb9/0xfe [c037e0ec] tcp_ack_saw_tstamp+0x14/0x43 [c037f879] tcp_ack+0x6b8/0x17b8 [c03833cc] tcp_rcv_established+0x519/0x5f1 [c038838d] tcp_v4_do_rcv+0x28/0x2f8 [c038a4ce] tcp_v4_rcv+0x7df/0x83d [c0372542] ip_local_deliver+0xcc/0x148 [c0372975] ip_rcv+0x3b7/0x3de [c035fa0e] netif_receive_skb+0x17a/0x1c2 [c02cc121] rtl8139_poll+0x2d9/0x425 [c03616d7] net_rx_action+0xa8/0xc8 [c011e8e0] __do_softirq+0x40/0x90 [c010635d] do_softirq+0x4d/0xb6 === INFO: lockdep is turned off. Code: 24 8b 82 88 03 00 00 89 82 40 05 00 00 a1 a0 23 53 c0 89 82 44 05 00 00 83 c4 0c 5b 5e 5f 5d c3 8b 90 88 00 00 00 b8 32 00 00 00 f6 42 25 20 74 03 8b 42 54 c3 56 85 d2 b9 01 00 00 00 0f 45 ca EIP: [c037d81b] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec Kernel panic - not syncing: Fatal exception in interrupt - 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 - 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] ethtool: marvell register update
Update the decode of sky2 registers.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- a/marvell.c 2007-09-17 14:03:08.0 -0700
+++ b/marvell.c 2007-09-17 14:05:44.0 -0700
@@ -183,6 +183,7 @@ static void dump_mac(const u8 *r)
case 0xb4: printf(Yukon-2 EC Ultra); break;
case 0xb6: printf(Yukon-2 EC); break;
case 0xb7: printf(Yukon-2 FE); break;
+ case 0xb8: printf(Yukon-2 FE Plus); break;
default:printf((Unknown));break;
}
@@ -247,6 +248,12 @@ static void dump_control(u8 *r)
printf(Interrupt Mask 0x%08X\n, *(u32 *) (r + 0xc));
printf(Interrupt Hardware Error Source 0x%08X\n, *(u32 *) (r +
0x10));
printf(Interrupt Hardware Error Mask0x%08X\n, *(u32 *) (r +
0x14));
+ printf(Interrupt Control0x%08X\n, *(u32 *) (r +
0x2c));
+ printf(Interrupt Moderation Mask0x%08X\n, *(u32 *) (r +
0x14c));
+ printf(Hardware Moderation Mask 0x%08X\n, *(u32 *) (r +
0x150));
+ dump_timer(Moderation Timer, r + 0x140);
+
+ printf(General Purpose I/O 0x%08X\n, *(u32 *) (r +
0x15c));
}
int skge_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
@@ -273,7 +280,6 @@ int skge_dump_regs(struct ethtool_drvinf
dump_gmac(GMAC 1, regs-data + 0x2800);
dump_timer(Timer, regs-data + 0x130);
- dump_timer(IRQ Moderation, regs-data +0x140);
dump_timer(Blink Source, regs-data +0x170);
dump_queue(Receive Queue 1, regs-data +0x400, 1);
@@ -342,7 +348,7 @@ static void dump_queue2(const char *name
printf(Request 0x%08X%08X\n,
d-req_hi, d-req_lo);
if (rx) {
- printf(Csum1 Offset %4d Position %d\n,
+ printf(Csum1 Offset %4d Position %d\n,
d-csum1, d-csum1_start);
printf(Csum2 Offset %4d Position %d\n,
d-csum2, d-csum2_start);
@@ -351,6 +357,25 @@ static void dump_queue2(const char *name
d-csum1, d-csum2_start, d-csum1_start);
}
+static void dump_prefetch(const char *name, const void *r)
+{
+ const u32 *reg = r;
+
+ printf(\n%s Prefetch\n, name);
+ printf(Control 0x%08X\n, reg[0]);
+ printf(Last Index%u\n, reg[1]);
+ printf(Start Address 0x%08x%08x\n, reg[3], reg[2]);
+ if (*name == 'S') { /* Status unit */
+ printf(TX1 report%u\n, reg[4]);
+ printf(TX2 report%u\n, reg[5]);
+ printf(TX threshold %u\n, reg[6]);
+ printf(Put Index %u\n, reg[7]);
+ } else {
+ printf(Get Index %u\n, reg[4]);
+ printf(Put Index %u\n, reg[5]);
+ }
+}
+
int sky2_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
{
const u32 *r = (const u32 *) regs-data;
@@ -375,23 +400,14 @@ int sky2_dump_regs(struct ethtool_drvinf
dump_mac(regs-data);
- printf(\nStatus BMU:\n---\n);
- printf(Control0x%08X\n,
- *(u32 *) (regs-data + 0x0e80));
- printf(Last Index 0x%04X\n,
- *(u16 *) (regs-data + 0x0e84));
- printf(Put Index 0x%04X\n,
- *(u16 *) (regs-data + 0x0e9c));
- printf(List Address 0x%08X%08X\n,
- *(u32 *) (regs-data + 0x0e8c),
- *(u32 *) (regs-data + 0x0e88));
- printf(Transmit 1 done index 0x%04X\n,
- *(u16 *) (regs-data + 0x0e90));
- if (dual)
- printf(Transmit 2 done index 0x%04X\n,
- *(u16 *) (regs-data + 0x0e94));
- printf(Transmit index threshold 0x%04X\n,
- *(u16 *) (regs-data + 0x0e98));
+ dump_prefetch(Status, regs-data + 0xe80);
+ dump_prefetch(Receive 1, regs-data + 0x450);
+ dump_prefetch(Transmit 1, regs-data + 0x450 + 0x280);
+
+ if (dual) {
+ dump_prefetch(Receive 2, regs-data + 0x450 + 0x80);
+ dump_prefetch(Transmit 2, regs-data + 0x450 + 0x380);
+ }
printf(\nStatus FIFO\n);
printf(\tWrite Pointer0x%02X\n, regs-data[0xea0]);
@@ -399,6 +415,7 @@ int sky2_dump_regs(struct ethtool_drvinf
printf(\tLevel0x%02X\n, regs-data[0xea8]);
printf(\tWatermark0x%02X\n, regs-data[0xeac]);
printf(\tISR Watermark0x%02X\n, regs-data[0xead]);
+
dump_timer(Status level, regs-data + 0xeb0);
dump_timer(TX status, regs-data + 0xec0);
dump_timer(ISR, regs-data + 0xed0);
@@ -415,7 +432,6 @@ int sky2_dump_regs(struct
Re: [2.6.23-rc4-mm1][Bug] kernel BUG at include/linux/netdevice.h:339!
On Mon, 17 Sep 2007 17:46:38 +0530
Kamalesh Babulal [EMAIL PROTECTED] wrote:
Kernel Bug is hit with 2.6.23-rc4-mm1 kernel on ppc64 machine.
kernel BUG at include/linux/netdevice.h:339!
(please cc netdev@vger.kernel.org on networking-related matters)
You died here:
static inline void napi_complete(struct napi_struct *n)
{
BUG_ON(!test_bit(NAPI_STATE_SCHED, n-state));
The NAPI changes have had a few problems and hopefully things have
been fixed up since then. I'll try to get rc6-mm1 out this evening,
so please retest that?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net-2.6.24 plans
From: David Miller [EMAIL PROTECTED] Date: Sun, 16 Sep 2007 20:22:58 -0700 (PDT) Tomorrow (Monday) I want to rebase the net-2.6.24 tree one more time to deal with all of the conflicts which exist between linux-2.6/net-2.6 and net-2.6.24, but I'll likely defer that until the net-2.6 fixes I just pushed to Linus are integrated. I've just completed this rebase. Andrew, I removed the troublesome IOAT patch. The only conflicts and fixes you should need at this point are: 1) Removal of SET_MODULE_OWNER() from any extra drivers you import into your tree. 2) dev_get_by_*() needs init_net added as first parameter in any other code you import outside of the net tree. I guess a lot of this could be avoided if I simply merge in whatever external stuff you're sucking in. I imagine this is just one of Linville's trees (I'm surprised that hasn't been sent to me frankly) and some specific new drivers you're merging in. I don't want to sound like a control freak or a whiner, but these merge conflicts are growing painful at an astronomic rate and I'd therefore prefer if we simply push everything through the net-2.6.24 tree from now until the merge window. Today's rebase took several hours and it took significantly longer to suck in Jeff's netdev tree over the weekend. I'm tired of playing patch monkey, so I can sympathize with how life must be every day for Andrew :-) But on a more serious note there are things I have to actually hack on myself so anything that decreases the amount of time I spend doing mindless patch whacking in the net-2.6.24 tree is appreciated. What say you? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: Rick Jones [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 13:30:12 -0700 Different fields for different structures. The tcp_info struct doesn't have the idiag_mumble, so to get the two values shown in /proc/net/tcp I use tcpi_unacked and tcpi_sacked. For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that then covers ss. I want to reiterate what has been stated earlier in reply to this patch in that we shouldn't be modifying /proc/net/tcp* at all, any change can break some application parsing the strings it spits out. Therefore only the inet_diag thing can have the fields added in a backward compatible manner. Actually, this is why I initially deleted this patch from my inbox without applying it, I didn't see you remove the procfs code based upon the feedback you got stating that was necessary. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net-2.6.24 plans
On Mon, 17 Sep 2007 14:18:26 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: David Miller [EMAIL PROTECTED] Date: Sun, 16 Sep 2007 20:22:58 -0700 (PDT) Tomorrow (Monday) I want to rebase the net-2.6.24 tree one more time to deal with all of the conflicts which exist between linux-2.6/net-2.6 and net-2.6.24, but I'll likely defer that until the net-2.6 fixes I just pushed to Linus are integrated. I've just completed this rebase. Andrew, I removed the troublesome IOAT patch. The only conflicts and fixes you should need at this point are: 1) Removal of SET_MODULE_OWNER() from any extra drivers you import into your tree. 2) dev_get_by_*() needs init_net added as first parameter in any other code you import outside of the net tree. yup, I think I have all of those done now. I guess a lot of this could be avoided if I simply merge in whatever external stuff you're sucking in. external stuff is mainly drivers. These two: git://porch.greyhouse.net/gospo/tehuti-2.6.git ipg-add-ip1000a-driver-to-kernel-tree.patch plus boatloads of stuff in wireless. I imagine this is just one of Linville's trees (I'm surprised that hasn't been sent to me frankly) and some specific new drivers you're merging in. Yeah, git-net versus git-wireless isn't pretty. The huge amount of pending wireless stuff has been a bit of a nuisance for some months. But it's probably a bigger nuisance for John ;) I don't know what remains to be done there, but it would be good to dig in and get it all merged up. Given the damage which net-2.6.24 does to git-wireless, that might be tricky, dunno. I don't want to sound like a control freak or a whiner, but these merge conflicts are growing painful at an astronomic rate and I'd therefore prefer if we simply push everything through the net-2.6.24 tree from now until the merge window. Works for me. Today's rebase took several hours and it took significantly longer to suck in Jeff's netdev tree over the weekend. I'm tired of playing patch monkey, so I can sympathize with how life must be every day for Andrew :-) I'm finding that most problems are caused by maintainers committing stuff to their git trees which affects code which other git-tree owners maintain. Things like git-net playing with git-wireless code, git-block playing with git-scsi-misc code, etc. It would suit _me_ better if people were to try harder to merge changes via the correct maintainer rather than going out-of-scope like this. But it would make life quite a lot harder for the people who are doing this development, so it isn't clear where the line is best drawn. But on a more serious note there are things I have to actually hack on myself so anything that decreases the amount of time I spend doing mindless patch whacking in the net-2.6.24 tree is appreciated. What say you? My current aggregate diff against 2.6.23-rc6 is 28.8MB. I'm just sitting here with my head spinning ;) (I actually got it all to build, boot and run ltp, which was rather stunning) - 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] bonding: update some distro-specific documentation
On Fri, Sep 07, 2007 at 11:27:49AM -0700, Jay Vosburgh wrote: Andy Gospodarek [EMAIL PROTECTED] wrote: This all looks fine except for one nit (well, request for extra detail, really): @@ -802,15 +802,20 @@ BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no +BONDING_OPTS=mode=balance-alb miimon=100 Be sure to change the networking specific lines (IPADDR, NETMASK, NETWORK and BROADCAST) to match your network configuration. +You also need to set the BONDING_OPTS= line to specify the desired +options for your bond0 interface. Specifying bonding options in this +way is the preferred method for configuring bonding interfaces. Can you add something here that mentions that, for the arp_ip_target option, it has to be supplied as arp_ip_target=+10.0.0.1 and not just arp_ip_target=10.0.0.1? Also, multiple targets require multiple instances of the arp_ip_target option; it doesn't work to put multiple IP addresses as in the module option (i.e., arp_ip_target=10.0.0.1,10.0.0.2). This is necessary because ifup-eth isn't adding the + when it translates the option for use with sysfs or parsing the multiple IP address syntax. -J Jay, I took your advice -- here's an updated patch. -andy Signed-off-by: Andy Gospodarek [EMAIL PROTECTED] --- bonding.txt | 53 - 1 files changed, 32 insertions(+), 21 deletions(-) diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 1da5666..2402412 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -755,9 +755,9 @@ the system /etc/modules.conf or /etc/modprobe.conf configuration file. -- This section applies to distros using a version of initscripts -with bonding support, for example, Red Hat Linux 9 or Red Hat -Enterprise Linux version 3 or 4. On these systems, the network -initialization scripts have some knowledge of bonding, and can be +with bonding support, for example, Red Hat Linux 9, Red Hat Enterprise +Linux version 3, 4 or 5, Fedora, etc. On these systems, the network +initialization scripts have some knowledge of bonding, and can be configured to control bonding devices. These distros will not automatically load the network adapter @@ -802,18 +802,27 @@ BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no +BONDING_OPTS=mode=active-backup arp_monitor=+192.168.1.254 Be sure to change the networking specific lines (IPADDR, NETMASK, NETWORK and BROADCAST) to match your network configuration. - - Finally, it is necessary to edit /etc/modules.conf (or +You also need to set the BONDING_OPTS= line to specify the desired +options for your bond0 interface. Specifying bonding options in this +way is the preferred method for configuring bonding interfaces. The +options specified in BONDING_OPTS are identical to the bonding module +parameters except for the arp_monitor field. Each target should be +included as a separate address and should be preceded by a '+' to +indicate it should be added to the list of queried targets. + + It is no longer necessary to edit /etc/modules.conf (or /etc/modprobe.conf, depending upon your distro) to load the bonding module with your desired options when the bond0 interface is brought up. The following lines in /etc/modules.conf (or modprobe.conf) will -load the bonding module, and select its options: +load the bonding module, and select its options but this is no longer +the preferred method. alias bond0 bonding -options bond0 mode=balance-alb miimon=100 +options bond0 mode=active-backup arp_monitor=192.168.1.254 Replace the sample parameters with the appropriate set of options for your configuration. @@ -826,8 +835,9 @@ up and running. - Recent versions of initscripts (the version supplied with -Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do -have support for assigning IP information to bonding devices via DHCP. +Fedora Core 3 and Red Hat Enterprise Linux 4 and later is reported to +work) do have support for assigning IP information to bonding devices +via DHCP. To configure bonding for DHCP, configure it as described above, except replace the line BOOTPROTO=none with BOOTPROTO=dhcp @@ -837,18 +847,19 @@ is case sensitive. 3.2.2 Configuring Multiple Bonds with Initscripts - - At this writing, the initscripts package does not directly -support loading the bonding driver multiple times, so the process for -doing so is the same as described in the Configuring Multiple Bonds -Manually section, below. - - NOTE: It has been observed that some Red Hat supplied kernels -are apparently unable to rename modules at load time (the -o bond1 -part). Attempts to pass that option to modprobe will
Re: InfiniBand/RDMA merge plans for 2.6.24
IPoIB CM handles this properly by gathering together single pages in skbs' fragment lists. Then can we reuse IPoIB CM code here? Yes, if possible, refactoring things so that the rx skb allocation code becomes common between CM and non-CM would definitely make sense. - 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] bonding: update some distro-specific documentation
On Fri, Sep 07, 2007 at 11:27:49AM -0700, Jay Vosburgh wrote: Andy Gospodarek [EMAIL PROTECTED] wrote: This all looks fine except for one nit (well, request for extra detail, really): @@ -802,15 +802,20 @@ BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no +BONDING_OPTS=mode=balance-alb miimon=100 Be sure to change the networking specific lines (IPADDR, NETMASK, NETWORK and BROADCAST) to match your network configuration. +You also need to set the BONDING_OPTS= line to specify the desired +options for your bond0 interface. Specifying bonding options in this +way is the preferred method for configuring bonding interfaces. Can you add something here that mentions that, for the arp_ip_target option, it has to be supplied as arp_ip_target=+10.0.0.1 and not just arp_ip_target=10.0.0.1? Also, multiple targets require multiple instances of the arp_ip_target option; it doesn't work to put multiple IP addresses as in the module option (i.e., arp_ip_target=10.0.0.1,10.0.0.2). This is necessary because ifup-eth isn't adding the + when it translates the option for use with sysfs or parsing the multiple IP address syntax. -J Crap, I just realized I had arp_monitor (huh?) instead of arp_ip_target. Signed-off-by: Andy Gospodarek [EMAIL PROTECTED] --- bonding.txt | 53 - 1 files changed, 32 insertions(+), 21 deletions(-) diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 1da5666..2402412 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -755,9 +755,9 @@ the system /etc/modules.conf or /etc/modprobe.conf configuration file. -- This section applies to distros using a version of initscripts -with bonding support, for example, Red Hat Linux 9 or Red Hat -Enterprise Linux version 3 or 4. On these systems, the network -initialization scripts have some knowledge of bonding, and can be +with bonding support, for example, Red Hat Linux 9, Red Hat Enterprise +Linux version 3, 4 or 5, Fedora, etc. On these systems, the network +initialization scripts have some knowledge of bonding, and can be configured to control bonding devices. These distros will not automatically load the network adapter @@ -802,18 +802,27 @@ BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no +BONDING_OPTS=mode=active-backup arp_ip_target=+192.168.1.254 Be sure to change the networking specific lines (IPADDR, NETMASK, NETWORK and BROADCAST) to match your network configuration. - - Finally, it is necessary to edit /etc/modules.conf (or +You also need to set the BONDING_OPTS= line to specify the desired +options for your bond0 interface. Specifying bonding options in this +way is the preferred method for configuring bonding interfaces. The +options specified in BONDING_OPTS are identical to the bonding module +parameters except for the arp_ip_target field. Each target should be +included as a separate address and should be preceded by a '+' to +indicate it should be added to the list of queried targets. + + It is no longer necessary to edit /etc/modules.conf (or /etc/modprobe.conf, depending upon your distro) to load the bonding module with your desired options when the bond0 interface is brought up. The following lines in /etc/modules.conf (or modprobe.conf) will -load the bonding module, and select its options: +load the bonding module, and select its options but this is no longer +the preferred method. alias bond0 bonding -options bond0 mode=balance-alb miimon=100 +options bond0 mode=active-backup arp_ip_target=192.168.1.254 Replace the sample parameters with the appropriate set of options for your configuration. @@ -826,8 +835,9 @@ up and running. - Recent versions of initscripts (the version supplied with -Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do -have support for assigning IP information to bonding devices via DHCP. +Fedora Core 3 and Red Hat Enterprise Linux 4 and later is reported to +work) do have support for assigning IP information to bonding devices +via DHCP. To configure bonding for DHCP, configure it as described above, except replace the line BOOTPROTO=none with BOOTPROTO=dhcp @@ -837,18 +847,19 @@ is case sensitive. 3.2.2 Configuring Multiple Bonds with Initscripts - - At this writing, the initscripts package does not directly -support loading the bonding driver multiple times, so the process for -doing so is the same as described in the Configuring Multiple Bonds -Manually section, below. - - NOTE: It has been observed that some Red Hat supplied kernels -are apparently unable to rename modules at load time (the -o bond1 -part). Attempts to pass that
Re: [PATCH] phy: export phy_mii_ioctl
On 9/17/07, Domen Puncer [EMAIL PROTECTED] wrote:
Export phy_mii_ioctl, so network drivers can use it when built
as modules too.
Domen, do you want to collect all of these changes for MPC5200 FEC in
to a single patch series? The code is getting scattered around, I'll
check it over to make sure it is all working. I have these patches
applied individually and they all work.
It builds on this series:
[PATCH 0/7] MPC52xx Bestcomm submission for 2.6.24
If you can put this together is a clean series, I should be able to
layer support for the Phytec pcm030 on top of it.
It would be these three combined...
http://coderock.org/tmp/fec-v3rc1/
diff --git a/drivers/net/fec_mpc52xx/fec.c b/drivers/net/fec_mpc52xx/fec.c
index 922e9a8..c4442e0 100644
--- a/drivers/net/fec_mpc52xx/fec.c
+++ b/drivers/net/fec_mpc52xx/fec.c
@@ -1087,11 +1087,13 @@ static struct of_platform_driver mpc52xx_fec_driver = {
/* */
/* Module */
/* */
+extern int fec_mdio_init(void);
+void fec_mdio_exit(void);
static int __init
mpc52xx_fec_init(void)
{
-#ifdef FEC_MPC52xx_MDIO
+#ifdef CONFIG_FEC_MPC52xx_MDIO
int ret;
ret = fec_mdio_init();
if (ret) {
@@ -1106,7 +1108,7 @@ static void __exit
mpc52xx_fec_exit(void)
{
of_unregister_platform_driver(mpc52xx_fec_driver);
-#ifdef FEC_MPC52xx_MDIO
+#ifdef CONFIG_FEC_MPC52xx_MDIO
fec_mdio_exit();
#endif
}
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
---
On 17/09/07 11:53 +0200, Sven Luther wrote:
On Sat, Sep 15, 2007 at 02:14:44PM +0200, Domen Puncer wrote:
Updated and split version at:
http://coderock.org/tmp/fec-v3rc1/
I'll repost to lists once I run-test them.
When applying those patches, the build did die with :
ERROR: phy_mii_ioctl [drivers/net/fec_mpc52xx/fec_mpc52xx.ko] undefined!
Apparently, phy_mii_ioctl is not an exported symbol.
Domen, did you maybe forget a little snipplet when you cut the patches
in different pieces ? Or did i mess up applying them ?
Friendly,
Sven Luther
drivers/net/phy/phy.c |1 +
1 files changed, 1 insertion(+)
Index: linux.git/drivers/net/phy/phy.c
===
--- linux.git.orig/drivers/net/phy/phy.c
+++ linux.git/drivers/net/phy/phy.c
@@ -409,6 +409,7 @@ int phy_mii_ioctl(struct phy_device *phy
return 0;
}
+EXPORT_SYMBOL(phy_mii_ioctl);
/**
* phy_start_aneg - start auto-negotiation for this PHY device
___
Linuxppc-embedded mailing list
[EMAIL PROTECTED]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Jon Smirl
[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: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24
The IGMP enabling patch posted by me on September 2nd isn't on your list http://lists.openfabrics.org/pipermail/general/2007-September/040250.html can you add it? Yes, I lost that somehow. I will add it to my list of things to take a look at (no opinion yet). - 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 01/11] IB/ipoib: Export call to call_netdevice_notifiers and add new private flag
I tried to look at the ipoib stuff in this series... this patch looks fine but it doesn't actually touch ipoib, so the subject line is a bit misleading... - 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 04/11] IB/ipoib: Verify address handle validity on send
Looks fine overall, with one minor nitpick:
-if (unlikely(memcmp(neigh-dgid.raw,
+if (unlikely((memcmp(neigh-dgid.raw,
skb-dst-neighbour-ha + 4,
-sizeof(union ib_gid {
+sizeof(union ib_gid))) ||
+ (neigh-dev != dev))) {
the indentation here makes this confusing to read -- I would just do:
} else if (neigh-ah) {
if (unlikely(memcmp(neigh-dgid.raw,
skb-dst-neighbour-ha + 4,
- sizeof(union ib_gid {
+ sizeof(union ib_gid)) ||
+neigh-dev != 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
Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister
Actually, thinking about this some more... would it be cleaner to more
the knowledge about bonding out of the ipoib driver? in other words,
export something similar to
+static int ipoib_slave_detach(struct net_device *dev)
+{
+int ret = 0;
+if (dev-flags IFF_SLAVE) {
+dev-priv_flags |= IFF_SLAVE_DETACH;
+rtnl_lock();
+ret = call_netdevice_notifiers(NETDEV_CHANGE, dev);
+rtnl_unlock();
+}
+return ret;
+}
for drivers to use, rather than putting use of IFF_SLAVE and
IFF_SLAVE_DETACH outside of the bonding driver.
Also it seems this function could return void, since both call sites
ignore the return value and I don't see anything sensible that IPoIB
could do with the notifier chain return value anyway.
- 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] include listenq max/backlog in tcp_info and related reports - correct version/signorder
John Heffner wrote: Rick Jones wrote: John Heffner wrote: Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems that setting idiag_rqueue and idiag_wqueue are sufficient. Different fields for different structures. The tcp_info struct doesn't have the idiag_mumble, so to get the two values shown in /proc/net/tcp I use tcpi_unacked and tcpi_sacked. For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that then covers ss. Maybe I'm missing something. get_tcp[46]_sock() does not use struct tcp_info. The only way I see using this is by doing getsockopt(TCP_INFO) on your listen socket. Is this the intention? Yes. Sorry I got a triffle turned-around there. rick - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] CAN: Add documentation
On 17 Sep 2007 22:49:34 +0200 Urs Thuermann wrote: Thomas Gleixner [EMAIL PROTECTED] writes: Please do, having the patch in mail makes it easier to review and to comment. OK, here it is: Just a few more minor changes... Thanks again. +3. Socket CAN concept +- + + As described in chapter 2 it is the main goal of Socket CAN to + provide a socket interface to user space applications which builds + upon the Linux networklayer. In contrast to the commonly known network layer. + TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!) + medium that has no MAC-layer addressing like ethernet. The CAN-identifier + (can_id) is used for arbitration on the CAN-bus. Therefore the CAN-IDs + have to be chosen uniquely on the bus. When designing a CAN-ECU + network the CAN-IDs are mapped to be sent by a specific ECU. + For this reason a CAN-ID can be treated best as a kind of source address. + + 3.2 loopback + + As known from other networking concepts the data exchanging + applications may run on the same or different nodes without any + change (except for the according addressing information): + + ___ ___ ___ ___ ___ +| _ | | _ | | _ | | _ _ | | _ | +||A|| ||B|| ||C|| ||A| |B|| ||C|| +|___| |___| |___| |___| |___| + | | | | | +-(1)- CAN bus -(2)--- + + To ensure that application A receives the same information in the + example (2) as it would receive in example (1) there is need for + some kind of local loopback on the appropriate node. + + The Linux network devices (by default) just can handle the + transmission and reception of media dependent frames. Due to the + arbritration on the CAN bus the transmission of a low prio CAN-ID + may be delayed by the recepition of a high prio CAN frame. To reception + reflect the correct* traffic on the node the loopback of the sent + data has to be performed right after a successful transmission. If + the CAN network interface is not capable of performing the loopback for + some reason the SocketCAN core can do this task as a fallback solution. + See chapter 6.2 for details (recommended). + + The loopback functionality is enabled by default to reflect standard + networking behaviour for CAN applications. Due to some requests from + the RT-SocketCAN group the loopback optionally may be disabled for each + separate socket. See sockopts from the CAN RAW sockets in chapter 4.1. + + * = you really like to have this when you're running analyser tools + like 'candump' or 'cansniffer' on the (same) node. + --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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] bonding: update some distro-specific documentation
On Fri, Sep 07, 2007 at 11:27:49AM -0700, Jay Vosburgh wrote: Andy Gospodarek [EMAIL PROTECTED] wrote: This all looks fine except for one nit (well, request for extra detail, really): @@ -802,15 +802,20 @@ BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no +BONDING_OPTS=mode=balance-alb miimon=100 Be sure to change the networking specific lines (IPADDR, NETMASK, NETWORK and BROADCAST) to match your network configuration. +You also need to set the BONDING_OPTS= line to specify the desired +options for your bond0 interface. Specifying bonding options in this +way is the preferred method for configuring bonding interfaces. Can you add something here that mentions that, for the arp_ip_target option, it has to be supplied as arp_ip_target=+10.0.0.1 and not just arp_ip_target=10.0.0.1? Also, multiple targets require multiple instances of the arp_ip_target option; it doesn't work to put multiple IP addresses as in the module option (i.e., arp_ip_target=10.0.0.1,10.0.0.2). This is necessary because ifup-eth isn't adding the + when it translates the option for use with sysfs or parsing the multiple IP address syntax. Third time's the charm, right? (an arp_interval parameter would be nice) Signed-off-by: Andy Gospodarek [EMAIL PROTECTED] --- bonding.txt | 53 - 1 files changed, 32 insertions(+), 21 deletions(-) diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 1da5666..2402412 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -755,9 +755,9 @@ the system /etc/modules.conf or /etc/modprobe.conf configuration file. -- This section applies to distros using a version of initscripts -with bonding support, for example, Red Hat Linux 9 or Red Hat -Enterprise Linux version 3 or 4. On these systems, the network -initialization scripts have some knowledge of bonding, and can be +with bonding support, for example, Red Hat Linux 9, Red Hat Enterprise +Linux version 3, 4 or 5, Fedora, etc. On these systems, the network +initialization scripts have some knowledge of bonding, and can be configured to control bonding devices. These distros will not automatically load the network adapter @@ -802,18 +802,27 @@ BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no +BONDING_OPTS=mode=active-backup arp_interval=60 arp_ip_target=+192.168.1.254 Be sure to change the networking specific lines (IPADDR, NETMASK, NETWORK and BROADCAST) to match your network configuration. - - Finally, it is necessary to edit /etc/modules.conf (or +You also need to set the BONDING_OPTS= line to specify the desired +options for your bond0 interface. Specifying bonding options in this +way is the preferred method for configuring bonding interfaces. The +options specified in BONDING_OPTS are identical to the bonding module +parameters except for the arp_ip_target field. Each target should be +included as a separate address and should be preceded by a '+' to +indicate it should be added to the list of queried targets. + + It is no longer necessary to edit /etc/modules.conf (or /etc/modprobe.conf, depending upon your distro) to load the bonding module with your desired options when the bond0 interface is brought up. The following lines in /etc/modules.conf (or modprobe.conf) will -load the bonding module, and select its options: +load the bonding module, and select its options but this is no longer +the preferred method. alias bond0 bonding -options bond0 mode=balance-alb miimon=100 +options bond0 mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254 Replace the sample parameters with the appropriate set of options for your configuration. @@ -826,8 +835,9 @@ up and running. - Recent versions of initscripts (the version supplied with -Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do -have support for assigning IP information to bonding devices via DHCP. +Fedora Core 3 and Red Hat Enterprise Linux 4 and later is reported to +work) do have support for assigning IP information to bonding devices +via DHCP. To configure bonding for DHCP, configure it as described above, except replace the line BOOTPROTO=none with BOOTPROTO=dhcp @@ -837,18 +847,19 @@ is case sensitive. 3.2.2 Configuring Multiple Bonds with Initscripts - - At this writing, the initscripts package does not directly -support loading the bonding driver multiple times, so the process for -doing so is the same as described in the Configuring Multiple Bonds -Manually section, below. - - NOTE: It has been observed that some Red Hat supplied kernels -are apparently unable to rename modules at load time (the -o bond1 -part).
Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister
OK with me. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/11] IB/ipoib: Bound the net device to the ipoib_neigh structue
Overall idea looks good... one comment:
+if (n-dev-flags IFF_MASTER) {
+/* n-dev is not an IPoIB device and we have
+to take priv from elsewhere */
+neigh = *to_ipoib_neigh(n);
+if (neigh) {
+priv = netdev_priv(neigh-dev);
+ipoib_dbg(priv, neigh_destructor for bonding device:
%s\n,
+ n-dev-name);
+} else
+return;
+}
seems like it would be cleaner not to worry about bonding here and
just use neigh-dev all the time rather than having two ways to look
up the device.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6.23-rc4-mm1][Bug] kernel BUG at include/linux/netdevice.h:339!
From: Andrew Morton [EMAIL PROTECTED]
Date: Mon, 17 Sep 2007 14:16:22 -0700
On Mon, 17 Sep 2007 17:46:38 +0530
Kamalesh Babulal [EMAIL PROTECTED] wrote:
Kernel Bug is hit with 2.6.23-rc4-mm1 kernel on ppc64 machine.
kernel BUG at include/linux/netdevice.h:339!
(please cc netdev@vger.kernel.org on networking-related matters)
You died here:
static inline void napi_complete(struct napi_struct *n)
{
BUG_ON(!test_bit(NAPI_STATE_SCHED, n-state));
The NAPI changes have had a few problems and hopefully things have
been fixed up since then. I'll try to get rc6-mm1 out this evening,
so please retest that?
And if you trigger this still it is absolutely critical that
you tell us what networking device driver you are using at
the time.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] CAN: Add documentation
Hi Randy, Just a few more minor changes... Thanks again. Again, thank you. I have applied these two typo fixes, too. urs - 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 02/11] IB/ipoib: Notify the world before doing unregister
Roland Dreier [EMAIL PROTECTED] wrote:
Actually, thinking about this some more... would it be cleaner to more
the knowledge about bonding out of the ipoib driver? in other words,
export something similar to
+static int ipoib_slave_detach(struct net_device *dev)
+{
+ int ret = 0;
+ if (dev-flags IFF_SLAVE) {
+ dev-priv_flags |= IFF_SLAVE_DETACH;
+ rtnl_lock();
+ ret = call_netdevice_notifiers(NETDEV_CHANGE, dev);
+ rtnl_unlock();
+ }
+ return ret;
+}
for drivers to use, rather than putting use of IFF_SLAVE and
IFF_SLAVE_DETACH outside of the bonding driver.
Conceptually, I see your point and I'm ok with doing it either
way. My only question is, would this change would make the ipoib module
dependent upon having the bonding module loaded (to resolve all of the
symbols)?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [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 02/11] IB/ipoib: Notify the world before doing unregister
Conceptually, I see your point and I'm ok with doing it either way. My only question is, would this change would make the ipoib module dependent upon having the bonding module loaded (to resolve all of the symbols)? Yes, I guess so, if that function is in bonding. Hmm, that wouldn't be a good change. Maybe this new notification function should be in net/core/dev.c instead of exporting call_netdevice_notifiers()? - 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: net-2.6.24 plans
From: Andrew Morton [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 14:40:37 -0700 These two: git://porch.greyhouse.net/gospo/tehuti-2.6.git ipg-add-ip1000a-driver-to-kernel-tree.patch plus boatloads of stuff in wireless. Andrew, can you send these two to me under seperate cover? I'll integrate them once I have them in my inbox. Why don't we sit a bit on the wireless tree, and John please start to merge that stuff to net-2.6.24 and toss the patches my way? 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: net-2.6.24 plans
On Mon, Sep 17, 2007 at 02:40:37PM -0700, Andrew Morton wrote: On Mon, 17 Sep 2007 14:18:26 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: I guess a lot of this could be avoided if I simply merge in whatever external stuff you're sucking in. plus boatloads of stuff in wireless. I imagine this is just one of Linville's trees (I'm surprised that hasn't been sent to me frankly) and some specific new drivers you're merging in. The stuff in wireless-dev is a collection of drivers (some of which probably should be merged now) and some mac80211 gorp that is not yet merge-worthy. Trust me, I'm trying to get as many items out of it as possible. Yeah, git-net versus git-wireless isn't pretty. The huge amount of pending wireless stuff has been a bit of a nuisance for some months. But it's probably a bigger nuisance for John ;) Yeah...sigh...yeah...sigh...yeah... :-( But as hch would surely point-out, it is my own laziness at fault...and driver authors who tremble in fear when I mention merging their drivers upstream...but, I digress... :-) I just (minutes ago) finished the mop-up of the patch mess which had accumulated on me during my KS-related travel and the subsequent period of catching-up. (I'm sure I still missed something or botched something). I think I can get an -mm suitable patch together within the next few hours. John P.S. Andrew, I'll send you a link to a new git-wireless.patch -- I'm sure you don't want a complicated git invocation... Until then, I don't think you should try pulling wireless-dev... -- John W. Linville [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: net-2.6.24 plans
From: John W. Linville [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 19:18:30 -0400 I just (minutes ago) finished the mop-up of the patch mess which had accumulated on me during my KS-related travel and the subsequent period of catching-up. (I'm sure I still missed something or botched something). I think I can get an -mm suitable patch together within the next few hours. I'm happy you're taking care of this, but it would be nice if you could sent this to me as patches for net-2.6.24 inclusion 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
Re: net-2.6.24 plans
On Mon, 17 Sep 2007 19:18:30 -0400 John W. Linville [EMAIL PROTECTED] wrote: P.S. Andrew, I'll send you a link to a new git-wireless.patch -- I'm sure you don't want a complicated git invocation... Until then, I don't think you should try pulling wireless-dev... OK, thanks. The stuff I have now does actually compile, although the chances of it actually working are epsilon. So I'd rather not breathe on it today: I'l shove it out the door as-is with a big this is probably broken label on it. I'll at least test ipw2200 before doing so. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc4-mm1 OOPS in forcedeth?
On Mon, 17 Sep 2007, Denis V. Lunev wrote: Dhaval Giani wrote: On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote: EIP: [c037d81b] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec As Vlad Yasevich mentioned, this one is already fixed in 23-rc6. The forcedeth oops is unrelated, but multiple people have reported that same oops now -- adding Manfred Spraul to CC. [ original thread is at: http://lkml.org/lkml/2007/9/1/115 ] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net-2.6.24 plans
On Mon, 17 Sep 2007 16:39:29 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Andrew Morton [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 14:40:37 -0700 These two: git://porch.greyhouse.net/gospo/tehuti-2.6.git ipg-add-ip1000a-driver-to-kernel-tree.patch plus boatloads of stuff in wireless. Andrew, can you send these two to me under seperate cover? I'll integrate them once I have them in my inbox. The Tehuti driver you should probably pull from the above git tree. Andy sent me a fix-it-for-net-2.6.24 patch which I'll send. It applies on top of the git tree. ipg-add-ip1000a-driver-to-kernel-tree.patch got broken by git-2.6.24 and I just disabled it in Kconfig. I'll send it anyway but someone will need to repair it. For some reason this driver doesn't have a changelog. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: net-2.6.24 plans
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Miller Sent: Monday, September 17, 2007 2:18 PM To: netdev@vger.kernel.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: net-2.6.24 plans [...] Andrew, I removed the troublesome IOAT patch. The only conflicts and fixes you should need at this point are: [...] Which IOAT patch are you referring to? sln -- == Mr. Shannon Nelson LAN Access Division, Intel Corp. [EMAIL PROTECTED]I don't speak for Intel (503) 712-7659Parents can't afford to be squeamish. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net-2.6.24 plans
From: Nelson, Shannon [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 16:57:03 -0700 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Miller Sent: Monday, September 17, 2007 2:18 PM To: netdev@vger.kernel.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: net-2.6.24 plans [...] Andrew, I removed the troublesome IOAT patch. The only conflicts and fixes you should need at this point are: [...] Which IOAT patch are you referring to? The 'uninitialized variable' one, you should have a copy. If not, Andrew definitely does. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net-2.6.24 plans
On Mon, 17 Sep 2007 16:57:03 -0700 Nelson, Shannon [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Miller Sent: Monday, September 17, 2007 2:18 PM To: netdev@vger.kernel.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: net-2.6.24 plans [...] Andrew, I removed the troublesome IOAT patch. The only conflicts and fixes you should need at this point are: [...] Which IOAT patch are you referring to? A dopey one-liner which removes unused variable `u16 chanctrl'. It caused rather a mess due to all the dma changes we have queued. It's under control. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net-2.6.24 plans
From: Andrew Morton [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 16:53:18 -0700 The Tehuti driver you should probably pull from the above git tree. Andy sent me a fix-it-for-net-2.6.24 patch which I'll send. It applies on top of the git tree. ipg-add-ip1000a-driver-to-kernel-tree.patch got broken by git-2.6.24 and I just disabled it in Kconfig. I'll send it anyway but someone will need to repair it. For some reason this driver doesn't have a changelog. I integrated and fixed up the IPG IP1000A driver, I'll work on the Tehuti merge after dinner. Thanks Andrew. - 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
Quick benchmark for Mellanox 2-port 10Gbe NIC.
I just managed to get a 2-port Mellanox 10Gbe pci-e NIC working with 2.6.23-rc6 + my hacks. There are some errors about scheduling while atomic and such in the management path (ie, querying stats, etc), but the data path looks pretty good. At 1500 MTU I was able to send + rx 2.5Gbps on both ports using my pktgen. TCP maxed out at about 1.4Gbps send + rx, generated with my proprietary user-space tool with MTU 1500. With MTU 8000, I can send + rx about 1.8Gbps. When I change MTU to 8000 on the NICs, pktgen can send + rx about 4.5Gbps at 4000 byte pkt sizes. When sending one one port and receiving on the other, I can send 9+Gbps of traffic, using MTU of 8000 and pktgen pkt size of 4000. Using larger pktgen pkt sizes slows traffic down to around 7Gbps, probably due to extra page allocations. So, there are some warts to be worked out in the driver, but the raw performance looks pretty promising! Take it easy, 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: net-2.6.24 plans
From: Andrew Morton [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 16:53:18 -0700 The Tehuti driver you should probably pull from the above git tree. Ok I added in the Tehuti driver to net-2.6.24 and made sure the napi_struct conversion was good too. That only leaves the wireless bits :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: Peter Waskiewicz [EMAIL PROTECTED] Date: Mon, 17 Sep 2007 12:12:24 -0700 This would be a good opportunity to remove the single-allocated queue struct in netdevice (at the bottom) that we had to put in to accomodate the static loopback. Now we can set it back to a zero element list, and have alloc_netdev_mq() just allocate the number of queues requested, not num_queues - 1. I'll put a patch together based on this patchset. Thanks Peter. I'll also let this sit so that Eric can provide any feedback he wants and also figure out how he will use this for the namespace 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][NETNS] Use list_for_each_entry_continue_reverse in setup_net
From: [EMAIL PROTECTED] (Eric W. Biederman) Date: Mon, 17 Sep 2007 07:07:42 -0600 Pavel if you are going down this route. Could you look at cleanup_net as well. The reverse walk there could probably benefit from being list_for_each_entry_reverse. Pavel please resubmit this work after everything has been resolved, thanks. If you have already, please resend as I don't have a copy. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
