Re: Netlink send from the interrupt context
On 11/23/05, Robert Iakobashvili [EMAIL PROTECTED] wrote: On 11/23/05, Yu Zhiguo [EMAIL PROTECTED] wrote: Please refer to the function netlink_broadcast(), int netlink_broadcast(struct sock *ssk, struct sk_buff *skb, u32 pid, u32 group, int allocation) I think if allocation=GFP_ATOMIC, it can be used in interrupt context. What's your opinion? Allocation is OK and it uses only spinlocks in all functions called, no semaphores. My concern actually rises from here: http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/0455.html Sincerely, Robert Iakobashvili - NAVIGARE NECESSE EST coroberti at gmail dot 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
Fw: Questions about iproute
-- Forwarded Message --- From: Tiago Mira Amado [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tue, 22 Nov 2005 01:58:20 + Subject: Questions about iproute Good evening, I'm a student trying to implemente a Mobile IPv6 scenario with static routes. I'm using Fedora Core 3, with the kernel 2.6.11 patched with mipv6-2.0-rc3-linux-2.6.11.patch (only for kernel 2.6.11)(avaible at http://www.mobile-ipv6.org/software/). The iproute version is iproute-2.6.9-3. I've some problems with ip route so i used a simple scenario for tests. Scenario: (a::/64)---host1--(b::/64)--host2---(c::/64) [eth0(a::1/64)-eth2(b::1/64)]---[eth1(b::2/64)-eth0(c::2)] when i tried to insert routes: [EMAIL PROTECTED] ~]# ip -6 route add c::2/64 via b::2 dev eth2 RTNETLINK answers: Invalid argument [EMAIL PROTECTED] ~]# route -A inet6 add c::2/64 gw b::2 dev eth2 SIOCADDRT: Invalid argument [EMAIL PROTECTED] ~]# ip -6 route add c::2/64 dev eth2 --this doesn't work I configured the scenario sucessfuly at a few moments, but using global address with the prefix 2000::, or site local with prefix fec0::. Using the scenario with site local address: ip -6 route add ::/0 via fec0:b::1 #Works!! route -A inet6 add ::/0 gw fec0:b::1 #Also Works!! Using the scenario with global address: ip -6 route add ::/0 via 2000:b::1 #Works!! route -A inet6 add ::/0 gw 2000:b::1 #Also Works!! My question now is that a::1 is also global address, and i configure the interface address with sucess(ip -6 addr add a::1/64 dev eth0), so why can't i configure also a route (ip -6 route add ::/0 via b::2)?? Is that a bug?? Or is it because these addresses are reserved (not allocated)??? Following are shown the routing table of the first scenario [EMAIL PROTECTED] ~]# route -A inet6 -n Kernel IPv6 routing table Destination Next Hop Flags Metric RefUse Iface a::/64 :: U 25600 eth0 b::/64 :: U 25600 eth2 c::/64 :: U 1024 00 eth2 fe80::/64 :: U 25600 eth1 fe80::/64 :: U 25600 eth0 fe80::/64 :: U 25600 eth2 ff00::/8:: U 25600 eth2 ff00::/8:: U 25600 eth1 ff00::/8:: U 25600 eth0 ff00::/8:: U 25600 eth2 ::/0:: U 1 00 eth2 ::1/128 :: U 0 34 2 lo a::/128 :: U 0 32 lo a::1/128:: U 0 12 lo b::/128 :: U 0 32 lo b::1/128:: U 0 31 2 lo fe80::/128 :: U 0 02 lo fe80::/128 :: U 0 02 lo fe80::/128 :: U 0 02 lo fe80::201:2ff:fea4:23a7/128 :: U 0 02 lo fe80::211:11ff:fe1c:6653/128:: U 0 02 lo fe80::230:4fff:fe02:bdeb/128:: U 0 82 lo [EMAIL PROTECTED] ~]# Hope you can help me, thanks, Tiago. --- End of Forwarded Message --- -- Webmail alunos ESTG de Leiria (http://webmail.student.estg.ipleiria.pt) - To unsubscribe from this list: send 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 patch] do not select NET_CLS
* David S. Miller [EMAIL PROTECTED] 2005-11-22 14:37 From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 21 Nov 2005 17:16:18 +0100 Adrian Bunk wrote: This patch therefore changes NET_CLS back to the 2.6.14 status quo of being an user-visible option. I disagree with this patch. NET_CLS enables the infrastructure support for classifiers. Users generally don't care about infrastructure but directly usable things, so I'd prefer to have it automatically selected. And there are lots of other cases where enabling a module causes changes in the kernel image. Some examples include some of the netfilter stuff, the IPsec transforms, NET_CLS_ROUTE4, the ieee80211 stuff, and a lot more. I agree with Patrick. In fact Patrick's explanation was exactly the motivation for me to change it in the first place a few weeks back. I thought about making cls_api aware to be built as module but then the same would apply for ematches and the generic scheduling code and it gets real complicated. It is possible with some heavy code shuffling but not worth it I think. - To unsubscribe from this list: send 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 06/13]: [IPV4/6]: Netfilter IPsec input hooks
Hello.
In article [EMAIL PROTECTED] (at Tue, 22 Nov 2005 02:14:26 +0100), Patrick
McHardy [EMAIL PROTECTED] says:
The easiest way would be to store nhoff somewhere in the skb and
use it to continue at the next header. But I still hope there is
a way without keeping data in the skb.
We've coded up this.
Though we have still another issue (call chain issue) to resolve,
we're getting closer to the goal.
i.e. we should continue the loop for common case.
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
Signed-off-by: Yasuyuki Kozawai [EMAIL PROTECTED]
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8c5d600..1101851 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -272,6 +272,9 @@ struct sk_buff {
void(*destructor)(struct sk_buff *skb);
#ifdef CONFIG_NETFILTER
__u32 nfmark;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ unsigned intnf_nhoff;
+#endif
struct nf_conntrack *nfct;
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
struct sk_buff *nfct_reasm;
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 44b979a..0531d0a 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -463,6 +463,8 @@ extern int ip6_dst_lookup(struct sock
extern int ip6_output(struct sk_buff *skb);
extern int ip6_forward(struct sk_buff *skb);
extern int ip6_input(struct sk_buff *skb);
+extern int ip6_input_finish2(struct sk_buff *skb,
+ unsigned int nhoff);
extern int ip6_mc_input(struct sk_buff *skb);
/*
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index e84b3cd..cd0606a 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -134,31 +134,13 @@ out:
* Deliver the packet to the host
*/
-
-static inline int ip6_input_finish(struct sk_buff *skb)
+int ip6_input_finish2(struct sk_buff *skb, unsigned int nhoff)
{
struct inet6_protocol *ipprot;
struct sock *raw_sk;
- unsigned int nhoff;
- int nexthdr;
+ unsigned int nexthdr;
u8 hash;
- skb-h.raw = skb-nh.raw + sizeof(struct ipv6hdr);
-
- /*
-* Parse extension headers
-*/
-
- nexthdr = skb-nh.ipv6h-nexthdr;
- nhoff = offsetof(struct ipv6hdr, nexthdr);
-
- /* Skip hop-by-hop options, they are already parsed. */
- if (nexthdr == NEXTHDR_HOP) {
- nhoff = sizeof(struct ipv6hdr);
- nexthdr = skb-h.raw[0];
- skb-h.raw += (skb-h.raw[1]+1)3;
- }
-
rcu_read_lock();
resubmit:
if (!pskb_pull(skb, skb-h.raw - skb-data))
@@ -221,6 +203,26 @@ discard:
return 0;
}
+static inline int ip6_input_finish(struct sk_buff *skb)
+{
+ unsigned int nhoff;
+
+ skb-h.raw = skb-nh.raw + sizeof(struct ipv6hdr);
+
+ /*
+* Parse extension headers
+*/
+
+ nhoff = offsetof(struct ipv6hdr, nexthdr);
+
+ /* Skip hop-by-hop options, they are already parsed. */
+ if (skb-nh.ipv6h-nexthdr == NEXTHDR_HOP) {
+ nhoff = sizeof(struct ipv6hdr);
+ skb-h.raw += (skb-h.raw[1]+1)3;
+ }
+
+ return ip6_input_finish2(skb, nhoff);
+}
int ip6_input(struct sk_buff *skb)
{
diff --git a/net/ipv6/ipv6_syms.c b/net/ipv6/ipv6_syms.c
index 1648278..6051783 100644
--- a/net/ipv6/ipv6_syms.c
+++ b/net/ipv6/ipv6_syms.c
@@ -15,6 +15,7 @@ EXPORT_SYMBOL(ndisc_mc_map);
EXPORT_SYMBOL(register_inet6addr_notifier);
EXPORT_SYMBOL(unregister_inet6addr_notifier);
EXPORT_SYMBOL(ip6_route_output);
+EXPORT_SYMBOL(ip6_input_finish2);
EXPORT_SYMBOL(addrconf_lock);
EXPORT_SYMBOL(ipv6_setsockopt);
EXPORT_SYMBOL(ipv6_getsockopt);
diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
index 9987416..2e3b28d 100644
--- a/net/ipv6/xfrm6_input.c
+++ b/net/ipv6/xfrm6_input.c
@@ -9,6 +9,7 @@
* IPv6 support
*/
+#include linux/config.h
#include linux/module.h
#include linux/string.h
#include linux/netfilter.h
@@ -17,6 +18,7 @@
#include net/inet_ecn.h
#include net/ip.h
#include net/ipv6.h
+#include net/ip6_route.h
#include net/xfrm.h
static inline void ipip6_ecn_decapsulate(struct sk_buff *skb)
@@ -28,6 +30,25 @@ static inline void ipip6_ecn_decapsulate
IP6_ECN_set_ce(inner_iph);
}
+#ifdef CONFIG_NETFILTER
+static inline int xfrm6_rcv_spi_finish2(struct sk_buff *skb)
+{
+ __skb_pull(skb, skb-h.raw - skb-nh.raw);
+ return ip6_input_finish2(skb, skb-nf_nhoff);
+}
+
+static inline int xfrm6_rcv_spi_finish(struct sk_buff *skb)
+{
+ if (skb-dst == NULL) {
+ ip6_route_input(skb);
+ return dst_input(skb);
+ }
+
+ return NF_HOOK(PF_INET6, NF_IP6_LOCAL_IN, skb, skb-dev, NULL,
+
[PATCH 0/15] ixp2000 updates
This patch series brings the ixp2000 kernel driver up to version 0.2. diffstat information: drivers/net/ixp2000/caleb.c |1 drivers/net/ixp2000/enp2611.c | 21 - drivers/net/ixp2000/ixpdev.c | 67 ++ drivers/net/ixp2000/pm3386.c | 60 - drivers/net/ixp2000/pm3386.h |2 + 5 files changed, 104 insertions(+), 47 deletions(-) - To unsubscribe from this list: send 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 7/15] enp2611: use 'dev' in link status timer
We assign nds[i] to a local variable 'dev', which we never use
afterwards. Use the local variable instead.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
diff -urN linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/enp2611.c
linux-2.6.15-rc1.upstream/drivers/net/ixp2000/enp2611.c
--- linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/enp2611.c
2005-11-22 12:45:15.0 +0100
+++ linux-2.6.15-rc1.upstream/drivers/net/ixp2000/enp2611.c 2005-11-22
12:45:44.0 +0100
@@ -151,12 +151,12 @@
dev = nds[i];
status = pm3386_is_link_up(i);
- if (status !netif_carrier_ok(nds[i])) {
+ if (status !netif_carrier_ok(dev)) {
pm3386_enable_tx(i);
caleb_enable_tx(i);
- netif_carrier_on(nds[i]);
- } else if (!status netif_carrier_ok(nds[i])) {
- netif_carrier_off(nds[i]);
+ netif_carrier_on(dev);
+ } else if (!status netif_carrier_ok(dev)) {
+ netif_carrier_off(dev);
caleb_disable_tx(i);
pm3386_disable_tx(i);
}
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/15] enp2611: report link up/down events
Report carrier going up/down.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
diff -urN linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/enp2611.c
linux-2.6.15-rc1.upstream/drivers/net/ixp2000/enp2611.c
--- linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/enp2611.c
2005-11-22 12:45:15.0 +0100
+++ linux-2.6.15-rc1.upstream/drivers/net/ixp2000/enp2611.c 2005-11-22
12:49:15.0 +0100
@@ -152,10 +152,15 @@
status = pm3386_is_link_up(i);
if (status !netif_carrier_ok(dev)) {
+ /* @@@ Should report autonegotiation status. */
+ printk(KERN_INFO %s: NIC Link is Up\n, dev-name);
+
pm3386_enable_tx(i);
caleb_enable_tx(i);
netif_carrier_on(dev);
} else if (!status netif_carrier_ok(dev)) {
+ printk(KERN_INFO %s: NIC Link is Down\n, dev-name);
+
netif_carrier_off(dev);
caleb_disable_tx(i);
pm3386_disable_tx(i);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/15] caleb/pm3386: include proper header files
Make caleb.c and pm3386.c include their own header files, to catch incorrect prototype definitions. Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] diff -urN linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/caleb.c linux-2.6.15-rc1.upstream/drivers/net/ixp2000/caleb.c --- linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/caleb.c 2005-11-22 11:00:34.0 +0100 +++ linux-2.6.15-rc1.upstream/drivers/net/ixp2000/caleb.c 2005-11-22 12:42:28.0 +0100 @@ -13,6 +13,7 @@ #include linux/module.h #include linux/delay.h #include asm/io.h +#include caleb.h #define CALEB_IDLO 0x00 #define CALEB_IDHI 0x01 diff -urN linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/pm3386.c linux-2.6.15-rc1.upstream/drivers/net/ixp2000/pm3386.c --- linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/pm3386.c 2005-11-22 12:40:42.0 +0100 +++ linux-2.6.15-rc1.upstream/drivers/net/ixp2000/pm3386.c 2005-11-22 12:42:35.0 +0100 @@ -14,6 +14,7 @@ #include linux/delay.h #include linux/netdevice.h #include asm/io.h +#include pm3386.h /* * Read from register 'reg' of PM3386 device 'pm'. - To unsubscribe from this list: send 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 13/15] enp2611: disable/enable SERDES carrier on interface down/up
Disable/enable the SERDES carrier when an interface is administratively
downed/upped.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
diff -urN linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/enp2611.c
linux-2.6.15-rc1.upstream/drivers/net/ixp2000/enp2611.c
--- linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/enp2611.c
2005-11-22 12:49:24.0 +0100
+++ linux-2.6.15-rc1.upstream/drivers/net/ixp2000/enp2611.c 2005-11-22
12:50:57.0 +0100
@@ -175,10 +175,15 @@
{
if (up) {
caleb_enable_rx(port);
+
+ pm3386_set_carrier(port, 1);
pm3386_enable_rx(port);
} else {
caleb_disable_tx(port);
pm3386_disable_tx(port);
+ /* @@@ Flush out pending packets. */
+ pm3386_set_carrier(port, 0);
+
pm3386_disable_rx(port);
caleb_disable_rx(port);
}
-
To unsubscribe from this list: send 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 15/15] ixp2000: add driver version, bump version to 0.2
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED] diff -urN linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/ixpdev.c linux-2.6.15-rc1.upstream/drivers/net/ixp2000/ixpdev.c --- linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/ixpdev.c 2005-11-22 11:43:31.0 +0100 +++ linux-2.6.15-rc1.upstream/drivers/net/ixp2000/ixpdev.c 2005-11-22 15:29:51.0 +0100 @@ -24,6 +24,8 @@ #include ixpdev_priv.h #include ixpdev.h +#define DRV_MODULE_VERSION 0.2 + static int nds_count; static struct net_device **nds; static int nds_open; @@ -302,6 +304,8 @@ __too_many_rx_or_tx_buffers(); } + printk(KERN_INFO IXP2000 MSF ethernet driver %s\n, DRV_MODULE_VERSION); + nds_count = __nds_count; nds = __nds; set_port_admin_status = __set_port_admin_status; - To unsubscribe from this list: send 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 12/15] pm3386: implement reset
Implement pm3386 reset. A reset zeroes out the internally stored MAC
addresses, so we need to save and reload them by hand.
Signed-off-by: Lennert Buytenhek [EMAIL PROTECTED]
diff -urN linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/pm3386.c
linux-2.6.15-rc1.upstream/drivers/net/ixp2000/pm3386.c
--- linux-2.6.15-rc1.upstream.orig/drivers/net/ixp2000/pm3386.c 2005-11-22
12:50:33.0 +0100
+++ linux-2.6.15-rc1.upstream/drivers/net/ixp2000/pm3386.c 2005-11-22
12:50:39.0 +0100
@@ -89,7 +89,37 @@
void pm3386_reset(void)
{
- /* @@@ Implement me. */
+ u8 mac[3][6];
+
+ /* Save programmed MAC addresses. */
+ pm3386_get_mac(0, mac[0]);
+ pm3386_get_mac(1, mac[1]);
+ pm3386_get_mac(2, mac[2]);
+
+ /* Assert analog and digital reset. */
+ pm3386_reg_write(0, 0x002, 0x0060);
+ pm3386_reg_write(1, 0x002, 0x0060);
+ mdelay(1);
+
+ /* Deassert analog reset. */
+ pm3386_reg_write(0, 0x002, 0x0062);
+ pm3386_reg_write(1, 0x002, 0x0062);
+ mdelay(10);
+
+ /* Deassert digital reset. */
+ pm3386_reg_write(0, 0x002, 0x0063);
+ pm3386_reg_write(1, 0x002, 0x0063);
+ mdelay(10);
+
+ /* Restore programmed MAC addresses. */
+ pm3386_set_mac(0, mac[0]);
+ pm3386_set_mac(1, mac[1]);
+ pm3386_set_mac(2, mac[2]);
+
+ /* Disable carrier on all ports. */
+ pm3386_set_carrier(0, 0);
+ pm3386_set_carrier(1, 0);
+ pm3386_set_carrier(2, 0);
}
static u16 swaph(u16 x)
-
To unsubscribe from this list: send 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: Network lockup under load
On Tue, Nov 22, 2005 at 07:39:49PM -0500, Joe Korty wrote:
19:32:01.795103 buttercup.ccur.com.34798 tsunami.ccur.com.ssh: .
1495105:1496553(1448) ack 28242 win 2372 nop,nop,timestamp 4294926135
12059137 (DF) [tos 0x8]
19:32:08.323773 buttercup.ccur.com.34798 tsunami.ccur.com.ssh: .
1495105:1496553(1448) ack 28242 win 2372 nop,nop,timestamp 4294927767
12059137 (DF) [tos 0x8]
19:32:21.381119 buttercup.ccur.com.34798 tsunami.ccur.com.ssh: .
1495105:1496553(1448) ack 28242 win 2372 nop,nop,timestamp 4294931031
12059137 (DF) [tos 0x8]
19:32:26.381626 arp who-has tsunami.ccur.com tell buttercup.ccur.com
19:32:27.381724 arp who-has tsunami.ccur.com tell buttercup.ccur.com
19:32:28.381828 arp who-has tsunami.ccur.com tell buttercup.ccur.com
19:32:39.783051
2974 packets received by filter
2434 packets dropped by kernel
buttercup#
BTW, please run tcpdump with -n next time so that it doesn't lose
packets due to name lookups.
It would appear that the real problem here is that you've lost
connectivity to the box tsunami.
Could you please repeat the test with two tcpdumps, one on buttercup
and one on tsunami (run both with -n, you can skip strace now)?
When it stalls, could you please also do a ping from buttercup to
tsunami?
Please also tell me what network drivers you're using on both sides.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [2.6 patch] net/sunrpc/xdr.c: remove xdr_decode_string()
On Thu, Oct 06, 2005 at 07:13:14AM -0700, Lever, Charles wrote: actually, can we hold off on this change? the RPC transport switch will eventually need most of those EXPORT_SYMBOLs. Am I right to assume this will happen in the foreseeable future? the first portion of the transport switch is in 2.6.15-rcX. at this point i'm expecting the EXPORT_SYMBOL changes to go in 2.6.17 or later. so i don't remember why you are removing xdr_decode_string. are we sure that no-one will need this functionality in the future? it is harmless to remove today, but i wonder if someone is just going to add it back sometime. - To unsubscribe from this list: send 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: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)
Stefan, On Tue, 2005-22-11 at 21:38 +0100, Stefan Rompf wrote: we could protect operstate with a spinlock_irqsave() and then change it either from netif_[carrier|dormant]_on/off() or userspace-supplicant. However, I'm not feeling good about it. Ok, what you have is fine by me. Look at rtnetlink_fill_ifinfo(), it is able to query a consistent snapshot of all interface settings as long as locking with dev_base_lock and rtnl is obeyed. __LINK_STATE flags are already an exemption, and I don't want operstate to be another. That's why I chose setting it from linkwatch in process context, and I really think this is the correct approach. After looking at your patch, however, i realize that using only that approach it will be insufficient; some devices doing kernel based things during dormant state may wish to do the transition to/from dormant. For those, I think we will need to make explicit changes to call netif_carrier_dormant_on etc. But those are a minority of the devices and they can be changed over time. Yes, first user would be Krzysztof, second wireless. summary: avoid any device specific methods Please propose your alternative here. Your call - I dont think we have differences of opinions at the conceptual level; I am still unsure why DORMANT is part of dev-state. Shouldnt something be tracking exactly what state we are in as you had it in your earlier patch? I liked that approach. I have changed to the DORMANT flag as a compromise towards Krzysztof. He made clear that his drivers have several independant layers, one responsible for carrier, mapped to netdev_carrier*(), another one responsible for the protocol, mapped to netdev_dormant*(). I must admit that I'm not so happy with layers interoperating that bad, but on the other hand, I'm not a device driver developer beside occasionally hacking ipw2200 and willing to accept others' jugdement at that point. So discuss with Krzysztof ;-) I saw the discussion with Krzysztof - i think whatever agreement you come up with him is fine as well. So whats left? I note you asked Thomas for help on the other email for something netlink related - is that it? You've proposed netlink events for all transitions from and to the UP state. But an eventual userspace supplicant is more interested in transitions from and to the DORMANT state. The reason is: the typical recommended events/traps are from down state. So this fits for dormant as well. But what about apps like routing daemons? IFF_RUNNING assumes the event has relationship with up/down. As NOTPRESENT and TESTING are just unused enums for completeness, this sums up to all events are interesting, and for simplicity the supplicant should use the same notification mechanism. As long as the apps like quagga etc can also relate should be fine. Ok, i agree after your explanation above; i have some questions on multi-suplicant 802.1x in one node and one ethernet port and relationship to oper state but i wont distract the current discussion. So dont respond, just think about it ;- It's a real interesting question as there are some switches that support multiple 802.1X authentications per port, mainly that one can connect a dumb mini switch behind a protected port. So to answer your question, just use virtual devices with their own MAC address ;-) Well, thats certainly one way. Then the oper state machines you are working on + stacking will work well. But this depends on if you can justify the reason for those virtual devices. With wireless you can probably justify to map the radio layer to a virtual device if you have a card that has multiple radios; i dont know how it would work if you join different access points (and each requiring authentication phase) with a standard 802.11 - someone told me a while back, this may be common for mobility so that handoff from one access point to another is easier. However, 802.1X frames are addressed towards the spanning tree multicast address and I really ask myself how the details work. Got to fetch some packet traces next time I have access to such a beast ;-) What i have seen (on ethernet not wireless) is something that uses MAC address filtering; think of a bridge/L2 switch that doesnt learn src addresses but instead lets the 802.1x deal with it if src is not found in the table. The reason i asked you earlier, btw - is because what you are trying to do is tightly coupling 802.1x to port operational state and that there are exceptions to the rule; unless you turn everything into a netdevice which maybe unreasonable unless you can justify something needs to be a netdevice ;-. Anyways, this has nothing to do with the operational state discussion - thats why i said we can discuss later - even privately. 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
Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)
On Wed, Nov 23, 2005 at 09:24:05AM -0500, jamal wrote: Well, thats certainly one way. Then the oper state machines you are working on + stacking will work well. But this depends on if you can justify the reason for those virtual devices. With wireless you can probably justify to map the radio layer to a virtual device if you have a card that has multiple radios; i dont know how it would work if you join different access points (and each requiring authentication phase) with a standard 802.11 - someone told me a while back, this may be common for mobility so that handoff from one access point to another is easier. The case where one radio in client mode is associating with multiple APs is usually done by having multiple virtual netdevs, i.e., one for each association. At least that's the way I have implemented it and seen another implementation using the same design. In that way, supplicant doesn't even need to know about these associations being done through the same radio and it can just handle them as it would take care of multiple radios. -- Jouni MalinenPGP id EFC895FA - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
multi-supplicant WAS(Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)
I just changed the topic so as not to distract the original discussion On Wed, 2005-23-11 at 06:41 -0800, Jouni Malinen wrote: The case where one radio in client mode is associating with multiple APs is usually done by having multiple virtual netdevs, i.e., one for each association. Sounds reasonable; i wasnt sure if this is how it is done. Enlighten me: can a $5 802.11 card with a single radio form multiple associations and keep them at the same time? A while back i read an interesting paper about someone doing VOIP on linux using such a technique (I can look it up and send you a reference; i think it was either out of berkley or stanford). At least that's the way I have implemented it and seen another implementation using the same design. In that way, supplicant doesn't even need to know about these associations being done through the same radio and it can just handle them as it would take care of multiple radios. yes, this would work. However, i am still interested in the case where you have a single radio but multiple AP connections - unless this is impossible. I have to go back and look at that paper - I know they were using very basic 802.11 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: multi-supplicant WAS(Re: Issue 0 WAS (Re: Oustanding issues WAS(IRe: Consensus? WAS(RFC 2863)
On Wed, 2005-23-11 at 09:54 -0500, jamal wrote: yes, this would work. However, i am still interested in the case where you have a single radio but multiple AP connections - unless this is impossible. I have to go back and look at that paper - I know they were using very basic 802.11 never mind responding - I think you have answered this question. We just need to worry about stacking. 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
[Fwd: [Bug 5644] New: NFS v3 TCP 3-way handshake incorrect, iptables blocks access]
Sorry to be cross-posting, but does this bug ring any bells? I'm having trouble seeing how the sunrpc server code could be at fault. Cheers, Trond ---BeginMessage--- http://bugzilla.kernel.org/show_bug.cgi?id=5644 Summary: NFS v3 TCP 3-way handshake incorrect, iptables blocks access Kernel Version: 2.6.14 Status: NEW Severity: blocking Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: Distribution: Can't remember, possibly FC2. Hardware Environment: Software Environment: Problem Description: Steps to reproduce: 1. Boot NFS v3 TCP client running iptables mount NFS filesystem 2. Do a normal NFS client reboot try mounting the same filesystem again 3. Experience intermittent failure to read superblock The cause of this problem is NFS server's improper response to SYN packet sent by the client. This occurs *after* successful client authorization, when the client tries to open the connection (i.e. sends SYN to the server's nfs port) to read the superblock. The server (sometimes) responds with a pure ACK without the SYN bit set. This is blocked by iptables -- thus, mount fails with a could not read superblock message. Here is an excerpt from ethereal log: 3 0.021733client SERVER TCP 800 nfs [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=24095 TSER=0 WS=2 4 0.021846SERVER client TCP nfs 800 [ACK] Seq=9138391 Ack=3580883479 Win=16022 Len=0 TSV=244936050 TSER=1149400 5 0.021864client SERVER ICMP Destination unreachable (Host administratively prohibited) The above problem occurs with a very simple default+ssh iptables configuration. Disabling iptables on the client makes the problem go away. Even with iptables active, there is no problem when nfsd responds with a proper [SYN,ACK] instead of just pure ACK (this happens intermittently after the client reboot). Please fix nfsd so that it reliably responds to SYN packets with proper [SYN,ACK] packets instead of just ACK packets. Apparently, nfsd state doesn't get properly reset on client reboots. Other people have reported autofs failures which may be related (e.g. on remounts). --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ---End Message---
Re: [Fwd: [Bug 5644] New: NFS v3 TCP 3-way handshake incorrect, iptables blocks access]
On Wed, Nov 23, 2005 at 12:53:43PM -0500, Trond Myklebust wrote: Sorry to be cross-posting, but does this bug ring any bells? I'm having trouble seeing how the sunrpc server code could be at fault. We've seen this previously, and submitted a fix to netfilter which supposedly went into mainline at some point. It seems to be gone from 2.6.14 though. The problem is with conntrack, and filtering on RELATED (I assume your netfilter config does that) What happens is that the client reboots, opens a new TCP connection with the same port as last time (say 800), sends SYN. Server still has an active TCB for this, and thus replies with an ACK containing its current sequence numbers. Now the client is supposed to RST the connection. Unfortunately, conntrack does not expect a lone ACK in this state and ignores it. So the client will retransmit the SYN until timeout. Then it picks a new port, and succeeds (maybe). Olaf -- Olaf Kirch | --- o --- Nous sommes du soleil we love when we play [EMAIL PROTECTED] |/ | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax - To unsubscribe from this list: send 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.15-rc2-mm1
Michal Piotrowski [EMAIL PROTECTED] wrote: Debug: sleeping function called from invalid context at include/asm/semaphore.h:123 in_atomic():1, irqs_disabled():0 [c0103be6] dump_stack+0x17/0x19 [c011a0c3] __might_sleep+0x9c/0xae [fd9a090d] translate_table+0x147/0xc14 [ip_tables] [fd9a2b2a] ipt_register_table+0x93/0x20d [ip_tables] [f98fe027] init+0x27/0x9e [iptable_filter] [c01376d0] sys_init_module+0xd7/0x26c [c0102cc7] sysenter_past_esp+0x54/0x75 --- | preempt count: 0001 ] | 1 level deep critical section nesting: .. [fd9a2aca] ipt_register_table+0x33/0x20d [ip_tables] .[f98fe027] .. ( = init+0x27/0x9e [iptable_filter]) ipt_register_table() does get_cpu() then calls translate_table(), and somewhere under translate_table() we do something which sleeps, only I'm not sure what it is - netfilter likes to hide things in unexpected places. check_entry() will do sleepy things under that get_cpu(), but that doesn't seem to be in this particular call chain. Anyway, the new get_cpu() in ipt_register_table() is the problem. - To unsubscribe from this list: send 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 2/3] ioat: user buffer pin; net DMA client register
diff --git a/net/core/Makefile b/net/core/Makefile
index 630da0f..d02132b 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -8,7 +8,8 @@ obj-y := sock.o request_sock.o skbuff.o
obj-$(CONFIG_SYSCTL) += sysctl_net_core.o
obj-y += dev.o ethtool.o dev_mcast.o dst.o \
- neighbour.o rtnetlink.o utils.o link_watch.o filter.o
+ neighbour.o rtnetlink.o utils.o link_watch.o filter.o \
+ user_dma.o
obj-$(CONFIG_XFRM) += flow.o
obj-$(CONFIG_SYSFS) += net-sysfs.o
diff --git a/net/core/dev.c b/net/core/dev.c
index a44eeef..a81bee8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -113,6 +113,7 @@
#include linux/wireless.h/* Note : will define WIRELESS_EXT */
#include net/iw_handler.h
#endif /* CONFIG_NET_RADIO */
+#include linux/dmaengine.h
#include asm/current.h
/*
@@ -147,6 +148,12 @@ static DEFINE_SPINLOCK(ptype_lock);
static struct list_head ptype_base[16];/* 16 way hashed list */
static struct list_head ptype_all; /* Taps */
+#ifdef CONFIG_NET_DMA
+struct dma_client *net_dma_client;
+DEFINE_PER_CPU(struct dma_chan *, net_dma);
+static unsigned int net_dma_count;
+#endif
+
/*
* The @dev_base list is protected by @dev_base_lock and the rtln
* semaphore.
@@ -1708,6 +1715,9 @@ static void net_rx_action(struct softirq
unsigned long start_time = jiffies;
int budget = netdev_budget;
void *have;
+#ifdef CONFIG_NET_DMA
+ struct dma_chan *chan;
+#endif
local_irq_disable();
@@ -1739,6 +1749,10 @@ static void net_rx_action(struct softirq
}
}
out:
+#ifdef CONFIG_NET_DMA
+ list_for_each_entry(chan, net_dma_client-channels, client_node)
+ dma_async_memcpy_issue_pending(chan);
+#endif
local_irq_enable();
return;
@@ -3171,6 +3185,68 @@ static int dev_cpu_callback(struct notif
}
#endif /* CONFIG_HOTPLUG_CPU */
+#ifdef CONFIG_NET_DMA
+static void net_dma_rebalance(void)
+{
+ unsigned int cpu, i, n;
+ struct dma_chan *chan;
+
+ lock_cpu_hotplug();
+
+ if (net_dma_count == 0) {
+ for_each_online_cpu(cpu)
+ per_cpu(net_dma, cpu) = NULL;
+ unlock_cpu_hotplug();
+ return;
+ }
+
+ i = 0;
+ cpu = first_cpu(cpu_online_map);
+
+ list_for_each_entry(chan, net_dma_client-channels, client_node) {
+ /* cpus_clear(chan-cpumask); */
+ n = ((num_online_cpus() / net_dma_count) + (i
(num_online_cpus() % net_dma_count) ? 1 : 0));
+
+ while(n) {
+ per_cpu(net_dma, cpu) = chan;
+ /* cpu_set(cpu, chan-cpumask); */
+ cpu = next_cpu(cpu, cpu_online_map);
+ n--;
+ }
+ i++;
+ }
+
+ unlock_cpu_hotplug();
+}
+
+static void netdev_dma_event(struct dma_client *client, struct dma_chan *chan,
enum dma_event_t event)
+{
+ switch (event) {
+ case DMA_RESOURCE_ADDED:
+ net_dma_count++;
+ net_dma_rebalance();
+ break;
+ case DMA_RESOURCE_REMOVED:
+ net_dma_count--;
+ net_dma_rebalance();
+ break;
+ default:
+ break;
+ }
+}
+
+static int __init netdev_dma_register(void)
+{
+ net_dma_client = dma_async_client_register(netdev_dma_event);
+
+ dma_async_client_chan_request(net_dma_client, num_online_cpus());
+
+ return 0;
+}
+
+#else
+static int __init netdev_dma_register(void) { return -ENODEV; }
+#endif /* CONFIG_NET_DMA */
/*
* Initialize the DEV module. At boot time this walks the device list and
@@ -3224,6 +3300,8 @@ static int __init net_dev_init(void)
atomic_set(queue-backlog_dev.refcnt, 1);
}
+ netdev_dma_register();
+
dev_boot_phase = 0;
open_softirq(NET_TX_SOFTIRQ, net_tx_action, NULL);
diff --git a/net/core/user_dma.c b/net/core/user_dma.c
new file mode 100644
index 000..958e2c8
--- /dev/null
+++ b/net/core/user_dma.c
@@ -0,0 +1,422 @@
+/*
+ Copyright(c) 2004 - 2005 Intel Corporation
+ Portions based on net/core/datagram.c and copyrighted by their authors.
+
+ This code allows the net stack to make use of a DMA engine for
+ skb to iovec copies.
+*/
+
+#include linux/dmaengine.h
+#include linux/pagemap.h
+#include linux/socket.h
+#include linux/rtnetlink.h /* for BUG_TRAP */
+#include net/tcp.h
+#include asm/io.h
+#include asm/uaccess.h
+
+#ifdef CONFIG_NET_DMA
+
+#define NUM_PAGES_SPANNED(start, length) \
+ ((PAGE_ALIGN((unsigned long)start + length) - \
+ ((unsigned long)start PAGE_MASK)) PAGE_SHIFT)
+
+/*
+ * Lock down all the iovec pages needed for len bytes.
+ * Return a struct dma_locked_list to keep track of pages locked down.
+ *
+ * We are allocating a single chunk of memory, and then carving it up
[RFC] [PATCH 1/3] ioat: DMA subsystem
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 48f446d..fbe5116 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -66,4 +66,6 @@ source drivers/infiniband/Kconfig
source drivers/sn/Kconfig
+source drivers/dma/Kconfig
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 1a109a6..4bd0ab6 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -67,3 +67,4 @@ obj-$(CONFIG_INFINIBAND) += infiniband/
obj-$(CONFIG_SGI_IOC4) += sn/
obj-y += firmware/
obj-$(CONFIG_CRYPTO) += crypto/
+obj-$(CONFIG_DMA_ENGINE) += dma/
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
new file mode 100644
index 000..dde603d
--- /dev/null
+++ b/drivers/dma/Kconfig
@@ -0,0 +1,40 @@
+#
+# DMA engine configuration
+#
+
+menu DMA Engine support
+
+config DMA_ENGINE
+ bool Support for DMA engines
+ ---help---
+ DMA engines offload copy operations from the CPU to dedicated
+ hardware, allowing the copies to happen asynchronously.
+
+config NET_DMA
+ bool Use DMA engines in the network stack
+ depends on DMA_ENGINE
+ ---help---
+ Say Y to enable the use of DMA engines in the network stack to
+ offload receive copy-to-user operations, freeing CPU cycles.
+
+config NET_DMA_EARLY
+ bool Do early DMA copies
+ depends on NET_DMA
+ ---help---
+ Enabling this will cause the network stack to start DMA copies
+ earlier. This can improve throughput, but this is also a more
+ invasive change, and can be unstable.
+
+#
+#
+#
+
+config DMA_TESTCLIENT
+ tristate DMA test client
+ depends on DMA_ENGINE
+ ---help---
+ The CB test client driver performs a DMA-assisted memcpy on module
+ load, and prints the result when unloaded. It is pretty simple, but
+ maybe someday this will grow up into an actually useful test client.
+
+endmenu
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
new file mode 100644
index 000..abb83be
--- /dev/null
+++ b/drivers/dma/Makefile
@@ -0,0 +1,5 @@
+-include $(PWD)/config
+
+obj-y += dmaengine.o
+
+obj-$(CONFIG_DMA_TESTCLIENT) += testclient.o
diff --git a/drivers/dma/cb_list.h b/drivers/dma/cb_list.h
new file mode 100644
index 000..f2cc2d7
--- /dev/null
+++ b/drivers/dma/cb_list.h
@@ -0,0 +1,12 @@
+/* Extra macros that build on linux/list.h */
+#ifndef CB_LIST_H
+#define CB_LIST_H
+
+#include linux/list.h
+
+/* Provide some safty to list_add, which I find easy to swap the arguments to
*/
+
+#define list_add_entry(pos, head, member) list_add(pos-member, head)
+#define list_add_entry_tail(pos, head, member) list_add_tail(pos-member,
head)
+
+#endif /* CB_LIST_H */
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
new file mode 100644
index 000..fe240c8
--- /dev/null
+++ b/drivers/dma/dmaengine.c
@@ -0,0 +1,394 @@
+/***
+
+
+ Copyright(c) 2004 - 2005 Intel Corporation. All rights reserved.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc., 59
+ Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+ The full GNU General Public License is included in this distribution in the
+ file called LICENSE.
+
+***/
+
+#include linux/init.h
+#include linux/module.h
+#include linux/device.h
+#include linux/dmaengine.h
+#include linux/hardirq.h
+#include linux/spinlock.h
+#include linux/percpu.h
+#include cb_list.h
+
+static LIST_HEAD(dma_device_list);
+static LIST_HEAD(dma_client_list);
+
+DEFINE_PER_CPU(struct completion, kick_dma_poll);
+
+/* --- sysfs implementation --- */
+
+static ssize_t show_memcpy_count(struct class_device *cd, char *buf)
+{
+ struct dma_chan *chan = container_of(cd, struct dma_chan, class_dev);
+
+ sprintf(buf, %lu\n, chan-memcpy_count);
+ return strlen(buf) + 1;
+}
+
+static ssize_t show_bytes_transferred(struct class_device *cd, char *buf)
+{
+ struct dma_chan *chan = container_of(cd, struct dma_chan, class_dev);
+
+ sprintf(buf, %lu\n, chan-bytes_transferred);
+ return strlen(buf) + 1;
+}
+
+static ssize_t show_in_use(struct class_device *cd, char *buf)
+{
+ struct dma_chan *chan = container_of(cd, struct dma_chan, class_dev);
+
+
[RFC] [PATCH 0/3] ioat: DMA engine support
As presented in our talk at this year's OLS, the Bensley platform, which will be out in early 2006, will have an asyncronous DMA engine. It can be used to offload copies from the CPU, such as the kernel copies of received packets into the user buffer. The code consists of the following sections: 1) The HW driver for the DMA engine device 2) The DMA subsystem, which abstracts the HW details from users of the async DMA 3) Modifications to net/ to make use of the DMA engine for receive copy offload: 3a) Code to register the net stack as a DMA client 3b) Code to pin and unpin pages associated with a user buffer 3c) Code to initiate async DMA transactions in the net receive path Today we are releasing 2, 3a, and 3b, as well as testclient, a throwaway driver we wrote to demonstrate the DMA subsystem API. We will be releasing 3c shortly. We will be releasing 1 (the HW driver) when the platform ships early next year. Until then, the code doesn't really *do* anything, but we wanted to release what we could right away, and start getting some feedback. Against 2.6.14: patch 1: DMA engine patch 2: iovec pin/unpin code; register net as a DMA client patch 3: testclient overall diffstat information: drivers/Kconfig |2 drivers/Makefile |1 drivers/dma/Kconfig | 40 ++ drivers/dma/Makefile |5 drivers/dma/cb_list.h | 12 drivers/dma/dmaengine.c | 394 drivers/dma/testclient.c | 132 include/linux/dmaengine.h | 268 net/core/Makefile |3 net/core/dev.c| 78 net/core/user_dma.c | 422 ++ 11 files changed, 1356 insertions(+), 1 deletion(-) Regards -- Andy and Chris - To unsubscribe from this list: send 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 3/3] ioat: testclient
diff --git a/drivers/dma/testclient.c b/drivers/dma/testclient.c
new file mode 100644
index 000..9bfb979
--- /dev/null
+++ b/drivers/dma/testclient.c
@@ -0,0 +1,132 @@
+/***
+
+
+ Copyright(c) 2004 - 2005 Intel Corporation. All rights reserved.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc., 59
+ Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+ The full GNU General Public License is included in this distribution in the
+ file called LICENSE.
+
+***/
+
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+#include linux/dmaengine.h
+#include linux/delay.h
+#include asm/io.h
+
+/* MODULE API */
+
+static volatile u8 *buffer1;
+static volatile u8 *buffer2;
+
+struct dma_client *test_dma_client;
+struct dma_chan *test_dma_chan;
+static dma_cookie_t cookie;
+
+void
+test_added_chan(void)
+{
+ int i;
+
+ printk(buffer1 = %p\n, buffer1);
+ printk(buffer2 = %p\n, buffer2);
+ for (i = 0; i 20; i+=4)
+ printk(%u %u %u %u\n, buffer2[i], buffer2[i+1], buffer2[i+2],
buffer2[i+3]);
+
+// for (i = 0; i 10; i++) {
+ cookie = dma_async_memcpy_buf_to_buf(test_dma_chan,
+ (void *)buffer2,
+ (void *)buffer1,
+ 2000);
+ dma_async_memcpy_issue_pending(test_dma_chan);
+// }
+// printk(dma cookie = %i\n, cookie);
+ if (dma_async_memcpy_complete(test_dma_chan, cookie, NULL, NULL) ==
DMA_IN_PROGRESS)
+ printk(DMA cookie == IN PROGRESS\n);
+ else
+ printk(DMA cookie == SUCCESS\n);
+#if 0
+ for (i = 0; i 1000; i++) {
+ if (buffer2[1] != 0)
+ break;
+ mdelay(1);
+ }
+ printk(i = %d\n, i);
+ for (i = 0; i 20; i+=4)
+ printk(%u %u %u %u\n, buffer2[i], buffer2[i+1], buffer2[i+2],
buffer2[i+3]);
+ for (i = 0; i 20; i+=4)
+ printk(%u %u %u %u\n, buffer1[i], buffer1[i+1], buffer1[i+2],
buffer1[i+3]);
+#endif
+}
+
+void test_dma_event(struct dma_client *client, struct dma_chan *chan, enum
dma_event_t event)
+{
+ switch (event) {
+ case DMA_RESOURCE_ADDED:
+ test_dma_chan = chan;
+ test_added_chan();
+ break;
+ case DMA_RESOURCE_REMOVED:
+ test_dma_chan = NULL;
+ break;
+ default:
+ break;
+ }
+}
+
+static int __init
+testclient_init_module(void)
+{
+ int i;
+
+ buffer1 = kmalloc(sizeof(u8) * 2000, SLAB_KERNEL);
+ buffer2 = kmalloc(sizeof(u8) * 2000, SLAB_KERNEL);
+
+ memset((void *)buffer2, 0, 2000);
+ for (i = 0; i 2000; i++)
+ buffer1[i] = i;
+
+ test_dma_client = dma_async_client_register(test_dma_event);
+ if (!test_dma_client) {
+ printk(KERN_ERR Could not register dma client!\n);
+ return 0;
+ }
+
+ dma_async_client_chan_request(test_dma_client, 1);
+
+ return 0;
+}
+
+module_init(testclient_init_module);
+
+static void __exit
+testclient_exit_module(void)
+{
+ int i;
+ for (i = 0; i 20; i+=4)
+ printk(%u %u %u %u\n, buffer2[i], buffer2[i+1], buffer2[i+2],
buffer2[i+3]);
+ if (dma_async_memcpy_complete(test_dma_chan, cookie, NULL, NULL) ==
DMA_SUCCESS)
+ printk(DMA cookie == SUCCESS\n);
+ else
+ printk(DMA cookie == IN PROGRESS\n);
+
+ dma_async_client_unregister(test_dma_client);
+}
+
+module_exit(testclient_exit_module);
+
-
To unsubscribe from this list: send 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: Network lockup under load
On Wed, Nov 23, 2005 at 02:42:39PM -0500, Joe Korty wrote:
Intel(R) PRO/1000 Network Driver - version 6.0.60-k2
Copyright (c) 1999-2005 Intel Corporation.
ACPI: PCI Interrupt :03:01.0[A] - GSI 28 (level, low) - IRQ 169
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.35.
What does ethtool -k say on the e1000 card?
When it stalls, could you please also do a ping from buttercup to
tsunami?
Here is is, also a ping from buttercup to an independent third machine
(soybean), and one from tsunami to buttercup:
buttercup# ping tsunami
buttercup# ping 129.134.30.147
PING 129.134.30.147 (129.134.30.147) 56(84) bytes of data.
--- 129.134.30.147 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2013ms
buttercup# ping soybean
buttercup# ping 129.134.30.129
PING 129.134.30.129 (129.134.30.129) 56(84) bytes of data.
--- 129.134.30.129 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2001ms
Looks like buttercup is completely offline (this tallies with the tcpdump).
Please try bringing the interface down and up to see if that makes it work
again.
Please also eliminate the cable and switch port as potential problems
by swapping them.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network lockup under load
On Thu, Nov 24, 2005 at 07:45:16AM +1100, Herbert Xu wrote: What does ethtool -k say on the e1000 card? buttercup# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp segmentation offload: on Looks like buttercup is completely offline (this tallies with the tcpdump). Please try bringing the interface down and up to see if that makes it work again. Interesting. One 'ifdown eth0; sleep 10; ifup eth0' got it working again; the scp transfered 8 more files before stalling out again. Then, a bunch of 'ifdown eth0; ifup eth0' (no sleep 10 between) had no effect. Then, a following ifdown/ifup with an intervening sleep let another 6 files through before locking up. Please also eliminate the cable and switch port as potential problems by swapping them. Will do in a bit, but as everything works fine with 2.6.13-rc1-git7 and earlier kernels, I don't expect this will be the problem. Joe - To unsubscribe from this list: send 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: Network lockup under load
On Wed, Nov 23, 2005 at 04:01:24PM -0500, Joe Korty wrote:
On Thu, Nov 24, 2005 at 07:45:16AM +1100, Herbert Xu wrote:
What does ethtool -k say on the e1000 card?
buttercup# ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
Please try turning sg and tso off to see if it helps.
Will do in a bit, but as everything works fine with 2.6.13-rc1-git7 and
earlier
kernels, I don't expect this will be the problem.
It's probably the driver. However, since rc1-git7 - rc2 may not have
actually introduced the problem but merely triggered it, it could still
be anything.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network lockup under load
From: Joe Korty [EMAIL PROTECTED] Date: Wed, 23 Nov 2005 16:01:24 -0500 Then, a following ifdown/ifup with an intervening sleep let another 6 files through before locking up. This means the e1000 card's transmitter is wedging when using TSO scatter-gather packet buffers. There are some bugs the e1000 card has wrt. TSO, but all the necessary workarounds for that should be in the current 2.6.x e1000 driver. You can try experimenting with ethtool -K tso off to disable TSO and see if that makes the problem go away. - To unsubscribe from this list: send 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: Network lockup under load
From: Herbert Xu [EMAIL PROTECTED] Date: Thu, 24 Nov 2005 08:11:05 +1100 On Wed, Nov 23, 2005 at 04:01:24PM -0500, Joe Korty wrote: Will do in a bit, but as everything works fine with 2.6.13-rc1-git7 and earlier kernels, I don't expect this will be the problem. It's probably the driver. However, since rc1-git7 - rc2 may not have actually introduced the problem but merely triggered it, it could still be anything. The e1000 does have hardware bugs with TSO and SG, which the e1000 driver should have the necessary workarounds for. I am confident that it's not the change being discussed, but rather an existing problem with the e1000 hardware and/or driver. The chip simply wedges and stops sending any packets at all, not even pings, you can't blame the Linux stack on 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: Network lockup under load
From: Joe Korty [EMAIL PROTECTED] Date: Wed, 23 Nov 2005 16:32:55 -0500 On Thu, Nov 24, 2005 at 08:11:05AM +1100, Herbert Xu wrote: Please try turning sg and tso off to see if it helps. tso sg result -- -- -- on on stallout on off works off on works off off works From your previous letter: I swapped the two ethernet cables going into buttercup; the scp still stalls out with tso=on and sg=on. Yes, and even with the change you quoted removed, you would still wedge the card by doing sendfile() based transfers over that e1000 card under load. That change just made an existing problem with the e1000 card and/or driver more apparent. There is some bug in the e1000 card that causes it to wedge with TSO+SG packets, the driver should have a sufficient workaround but aparently not. Some e1000 experts need to look into this. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] ioat: DMA engine support
Andrew Grover wrote:
As presented in our talk at this year's OLS, the Bensley platform, which
will be out in early 2006, will have an asyncronous DMA engine. It can be
used to offload copies from the CPU, such as the kernel copies of received
packets into the user buffer.
IOAT is super-neat stuff.
In addition to helping speed up network RX, I would like to see how
possible it is to experiment with IOAT uses outside of networking.
Sample ideas: VM page pre-zeroing. ATA PIO data xfers (async copy to
static buffer, to dramatically shorten length of kmap+irqsave time).
Extremely large memcpy() calls.
Additionally, current IOAT is memory-memory. I would love to be able
to convince Intel to add transforms and checksums, to enable offload of
memory-transform-memory and memory-checksum-result operations like
sha-{1,256} hashing[1], crc32*, aes crypto, and other highly common
operations. All of that could be made async.
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: [RFC: 2.6 patch] remove drivers/net/eepro100.c
On Wed, Nov 23, 2005 at 10:15:48PM +, Russell King wrote: On Fri, Nov 18, 2005 at 11:12:28AM -0500, Jeff Garzik wrote: Russell King wrote: On Fri, Nov 18, 2005 at 04:33:02AM +0100, Adrian Bunk wrote: This patch removes the obsolete drivers/net/eepro100.c driver. Is there any reason why it should be kept? Tt's the only driver which works correctly on ARM CPUs. e100 is basically buggy. This has been discussed here on lkml and more recently on linux-netdev. If anyone has any further questions please read the archives of those two lists. After reading the archives, one discovers the current status is: waiting on ARM folks to test e100 Latest reference is public message-id [EMAIL PROTECTED], which was CC'd to you. There is a patch in netdev-2.6.git#e100-sbit and in Andrew's -mm tree that should solve the ARM problems, and finally allow us to kill eepro100. But it's waiting for feedback... Well, I've run 2.6.15-rc2 on what I think was the ARM platform which exhibited the problem, but it doesn't show up. However, that's meaningless as it has been literally _years_ (4 or more) since the problem was reported. It's rather unsurprising that I can't reproduce it - I don't even know if I'm using the right processor module! Additionally, looking back at my 30th June 2004 message, I don't think I've even managed sufficient testing to make any claim of working-ness or non-working-ness against either driver. The test was merely a did it successfully BOOTP because I can't get it to mount and run /sbin/init from the jffs2 rootfs which 2.5.70 was perfectly happy to earlier today. However, the failure point seemed to be when NFS tried to use the card. Whether that means I was or was not using BOOTP back in 2004... your guess is as good as mine. Anyway, that's the end of the issue as far as I'm concerned. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send 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 0/3] ioat: DMA engine support
On Mer, 2005-11-23 at 17:06 -0500, Jeff Garzik wrote: Sample ideas: VM page pre-zeroing. ATA PIO data xfers (async copy to static buffer, to dramatically shorten length of kmap+irqsave time). Extremely large memcpy() calls. ATA PIO copies are 512 bytes of memory per sector and that is usually already in cache and on cache line boundaries. You won't even be able to measure it done by the CPU. I can't see the I/O engine sync cost being worth it. Might just about help large transfers I guess but you don't do multisector which is the only case you'd get perhaps 8K an I/O. Additionally, current IOAT is memory-memory. I would love to be able to convince Intel to add transforms and checksums, Not just transforms but also masks and maybe even merges and textures would be rather handy 8) - To unsubscribe from this list: send 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 0/3] ioat: DMA engine support
On Mer, 2005-11-23 at 12:26 -0800, Andrew Grover wrote: early next year. Until then, the code doesn't really *do* anything, but we wanted to release what we could right away, and start getting some feedback. First comment partly based on Jeff Garziks comments - if you added an operation to the base functions and an operation mask to the DMA engines it becomes possible to support engines that can do other ops (eg abusing an NCR53c8xx for both copy and clear). Second one - you obviously tested this somehow, was that all done by simulation or do you have a CPU memcpy test engine for use before the hardware pops up ? - To unsubscribe from this list: send 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 0/3] ioat: DMA engine support
On Wed, Nov 23, 2005 at 05:06:42PM -0500, Jeff Garzik wrote:
IOAT is super-neat stuff.
The main problem I see is that it'll likely only pay off when you can keep
the queue of copies long (to amortize the cost of
talking to an external chip). At least for the standard recvmsg
skb-user space, user space- skb cases these queues are
likely short in most cases. That's because most applications
do relatively small recvmsg or sendmsgs.
It definitely will need a threshold under which it is disabled.
With bad luck the threshold will be high enough that it doesn't
help very often :/
Longer term the right way to handle this would be likely to use
POSIX AIO on sockets. With that interface it would be easier
to keep long queues of data in flight, which would be best for
the DMA engine.
In addition to helping speed up network RX, I would like to see how
possible it is to experiment with IOAT uses outside of networking.
Sample ideas: VM page pre-zeroing. ATA PIO data xfers (async copy to
static buffer, to dramatically shorten length of kmap+irqsave time).
Extremely large memcpy() calls.
Another proposal was swiotlb.
But it's not clear it's a good idea: a lot of these applications prefer to
have the target in cache. And IOAT will force it out of cache.
Additionally, current IOAT is memory-memory. I would love to be able
to convince Intel to add transforms and checksums, to enable offload of
memory-transform-memory and memory-checksum-result operations like
sha-{1,256} hashing[1], crc32*, aes crypto, and other highly common
operations. All of that could be made async.
I remember the registers in the Amiga Blitter for this and I'm
still scared... Maybe it's better to keep it simple.
-Andi
-
To unsubscribe from this list: send 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 0/3] ioat: DMA engine support
Andrew Grover wrote: As presented in our talk at this year's OLS, the Bensley platform, which will be out in early 2006, will have an asyncronous DMA engine. It can be used to offload copies from the CPU, such as the kernel copies of received packets into the user buffer. More than a one-paragraph description would be nice... URLs to OLS and IDF presentations, other info? 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: [RFC: 2.6 patch] remove drivers/net/eepro100.c
From: Russell King [EMAIL PROTECTED] Date: Wed, 23 Nov 2005 22:15:48 + I leave it up to you how to proceed. Effectively I'm now completely out of the loop on this with no hardware to worry about. Sorry. Finally, please don't assign any blame for this in my direction; I reported it and I kept bugging people about it, and in spite of my best efforts there was very little which was forthcoming. Obviously that wasn't enough. I think you're being unreasonable. They've worked on a fix for the problem, and now you're unable to test the fix, and you're angry at them because they took so long to code up the fix. If you're overextended and have too much work to do and that's stressing you out, that doesn't give you permission to take it out on other people. - To unsubscribe from this list: send 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 2/3] ioat: user buffer pin; net DMA client register
A per-patch description would be nice, as DaveM mentioned... and also please put a diffstat in each email. 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: Network lockup under load
On Wed, Nov 23, 2005 at 02:07:04PM -0800, David S. Miller wrote: There is some bug in the e1000 card that causes it to wedge with TSO+SG packets, the driver should have a sufficient workaround but aparently not. Some e1000 experts need to look into this. Hmmm, I'll find out who that is and bring them onboard, after the T.day break. Thanks, Joe - To unsubscribe from this list: send 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 1/3] ioat: DMA subsystem
Mostly ok, but some minor nits.
Andrew Grover wrote:
index 000..f2cc2d7
--- /dev/null
+++ b/drivers/dma/cb_list.h
@@ -0,0 +1,12 @@
+/* Extra macros that build on linux/list.h */
+#ifndef CB_LIST_H
+#define CB_LIST_H
+
+#include linux/list.h
+
+/* Provide some safty to list_add, which I find easy to swap the arguments to
*/
+
+#define list_add_entry(pos, head, member) list_add(pos-member, head)
+#define list_add_entry_tail(pos, head, member) list_add_tail(pos-member,
head)
+
+#endif /* CB_LIST_H */
Maybe this just adds fuel to the fire, given your code comment, but I
tend to think most people are used to
object_foo(object, other args...)
where the object in question is the list. That would imply a
list_foo(head, others args...)
pattern.
As a side note, I have the same problem as you, WRT swapping the
list_add arguments. I've always thought that was the one big drawback
to Linus's otherwise elegant list implementation.
general nits:
1) docbook-able function headers, with useful documentation, would be
nice. Using libata as an example, even if I don't provide any useful
function description, I at least document the locking details/context
for each function.
2) more inline code commenting would be nice.
+ if (chan-device-device_alloc_chan_resources(chan) =
0) {
+ chan-client = client;
+ list_add_entry_tail(chan, client-channels,
client_node);
+ return chan;
+ }
device_alloc_chan_resources is a very long name. :)
+static void
+dma_client_chan_free(struct dma_chan *chan)
+{
+ BUG_ON(!chan);
+
+ chan-device-device_free_chan_resources(chan);
+ chan-client = NULL;
+}
ditto
+static void
+dma_chans_rebalance(void)
explanation of this function would be nice. remember to answer how?
and why?, not what?.
+{
+ struct dma_client *client;
+ struct dma_chan *chan;
+
+ list_for_each_entry(client, dma_client_list, global_node) {
locking of dma_client_list?
+ while (client-chans_desired client-chan_count) {
+ chan = dma_client_chan_alloc(client);
+ if (!chan)
+ break;
+
+ client-chan_count++;
+ client-event_callback(client, chan,
DMA_RESOURCE_ADDED);
+ }
+
+ while (client-chans_desired client-chan_count) {
+ chan = list_entry(client-channels.next, struct
dma_chan, client_node);
+ list_del(chan-client_node);
+ client-chan_count--;
+ client-event_callback(client, chan,
DMA_RESOURCE_REMOVED);
+ dma_client_chan_free(chan);
In general, this DMA_RESOURCE_REMOVED operation feels like a yanking
the carpet out from under my feet operation, something we should avoid
for object-lifetime reasons.
However in this case, AFAICS dmaengine.c completely controls object
lifetime, so I do not see a real problem. I'm just nervous. :)
+ }
+ }
+}
+
+struct dma_client *
+dma_async_client_register(dma_event_callback event_callback)
+{
+ struct dma_client *client;
+
+ BUG_ON(!event_callback);
+
+ client = kmalloc(sizeof(*client), GFP_KERNEL);
+ if (!client)
+ return NULL;
+
+ INIT_LIST_HEAD(client-channels);
+
+ client-chans_desired = 0;
+ client-chan_count = 0;
+ client-event_callback = event_callback;
+
+ list_add_entry_tail(client, dma_client_list, global_node);
+
+ return client;
Possible SMP bug here?
So far, in my code read, I was presuming that the caller was doing some
sort of locking on dma_client_list and dma_device_list. (Hint: need
locking docs for each function)
But if you are using GFP_KERNEL, it certainly appears that two callers
could race with each other when touching dma_client_list.
+dma_cookie_t
+dma_async_memcpy_buf_to_buf(
+ struct dma_chan *chan,
+ void *dest,
+ void *src,
+ size_t len)
+{
+ chan-bytes_transferred += len;
+ chan-memcpy_count++;
+
+ return chan-device-device_memcpy_buf_to_buf(chan, dest, src, len);
+}
+
+dma_cookie_t
+dma_async_memcpy_buf_to_pg(
+ struct dma_chan *chan,
+ struct page *page,
+ unsigned int offset,
+ void *kdata,
+ size_t len)
+{
+ chan-bytes_transferred += len;
+ chan-memcpy_count++;
+
+ return chan-device-device_memcpy_buf_to_pg(chan, page, offset, kdata,
len);
+}
+
+dma_cookie_t
+dma_async_memcpy_pg_to_pg(
+ struct dma_chan *chan,
+ struct page *dest_pg,
+ unsigned int dest_off,
+ struct page *src_pg,
+ unsigned int src_off,
+ size_t len)
+{
+ chan-bytes_transferred += len;
+ chan-memcpy_count++;
+
+ return
Re: [RFC] [PATCH 3/3] ioat: testclient
Andrew Grover wrote:
diff --git a/drivers/dma/testclient.c b/drivers/dma/testclient.c
new file mode 100644
index 000..9bfb979
--- /dev/null
+++ b/drivers/dma/testclient.c
@@ -0,0 +1,132 @@
+/***
+
+
+ Copyright(c) 2004 - 2005 Intel Corporation. All rights reserved.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your option)
+ any later version.
+
+ This program is distributed in the hope that it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc., 59
+ Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+ The full GNU General Public License is included in this distribution in the
+ file called LICENSE.
+
+***/
+
+#include linux/module.h
+#include linux/init.h
+#include linux/device.h
+#include linux/dmaengine.h
+#include linux/delay.h
+#include asm/io.h
+
+/* MODULE API */
+
+static volatile u8 *buffer1;
+static volatile u8 *buffer2;
why do you think volatile is needed?
+struct dma_client *test_dma_client;
+struct dma_chan *test_dma_chan;
+static dma_cookie_t cookie;
+
+void
+test_added_chan(void)
+{
+ int i;
+
+ printk(buffer1 = %p\n, buffer1);
+ printk(buffer2 = %p\n, buffer2);
+ for (i = 0; i 20; i+=4)
+ printk(%u %u %u %u\n, buffer2[i], buffer2[i+1], buffer2[i+2],
buffer2[i+3]);
+
+// for (i = 0; i 10; i++) {
+ cookie = dma_async_memcpy_buf_to_buf(test_dma_chan,
+ (void *)buffer2,
+ (void *)buffer1,
+ 2000);
+ dma_async_memcpy_issue_pending(test_dma_chan);
+// }
+// printk(dma cookie = %i\n, cookie);
+ if (dma_async_memcpy_complete(test_dma_chan, cookie, NULL, NULL) ==
DMA_IN_PROGRESS)
+ printk(DMA cookie == IN PROGRESS\n);
+ else
+ printk(DMA cookie == SUCCESS\n);
+#if 0
+ for (i = 0; i 1000; i++) {
+ if (buffer2[1] != 0)
+ break;
+ mdelay(1);
ummm
+ printk(i = %d\n, i);
+ for (i = 0; i 20; i+=4)
+ printk(%u %u %u %u\n, buffer2[i], buffer2[i+1], buffer2[i+2],
buffer2[i+3]);
+ for (i = 0; i 20; i+=4)
+ printk(%u %u %u %u\n, buffer1[i], buffer1[i+1], buffer1[i+2],
buffer1[i+3]);
+#endif
+}
+
+void test_dma_event(struct dma_client *client, struct dma_chan *chan, enum
dma_event_t event)
+{
+ switch (event) {
+ case DMA_RESOURCE_ADDED:
+ test_dma_chan = chan;
+ test_added_chan();
+ break;
+ case DMA_RESOURCE_REMOVED:
+ test_dma_chan = NULL;
+ break;
+ default:
+ break;
+ }
+}
what keeps DMA_RESOURCE_ADDED from being called multiple times?
What happens when there is more than one resource?
dma_async_client_chan_request(...,1) prevents this, perhaps?
+static int __init
+testclient_init_module(void)
+{
+ int i;
+
+ buffer1 = kmalloc(sizeof(u8) * 2000, SLAB_KERNEL);
+ buffer2 = kmalloc(sizeof(u8) * 2000, SLAB_KERNEL);
+ memset((void *)buffer2, 0, 2000);
1) GFP_KERNEL not SLAB_KERNEL
2) kzalloc()
3) be consistent: either use 2000 or sizeof * 2000
+ for (i = 0; i 2000; i++)
+ buffer1[i] = i;
+ test_dma_client = dma_async_client_register(test_dma_event);
+ if (!test_dma_client) {
+ printk(KERN_ERR Could not register dma client!\n);
+ return 0;
+ }
+
+ dma_async_client_chan_request(test_dma_client, 1);
+
+ return 0;
+}
+
+module_init(testclient_init_module);
+
+static void __exit
+testclient_exit_module(void)
+{
+ int i;
+ for (i = 0; i 20; i+=4)
+ printk(%u %u %u %u\n, buffer2[i], buffer2[i+1], buffer2[i+2],
buffer2[i+3]);
+ if (dma_async_memcpy_complete(test_dma_chan, cookie, NULL, NULL) ==
DMA_SUCCESS)
+ printk(DMA cookie == SUCCESS\n);
+ else
+ printk(DMA cookie == IN PROGRESS\n);
+
+ dma_async_client_unregister(test_dma_client);
+}
+
+module_exit(testclient_exit_module);
+
-
To unsubscribe from this list: send 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: [RFC: 2.6 patch] remove drivers/net/eepro100.c
On Wed, Nov 23, 2005 at 02:39:46PM -0800, David S. Miller wrote: From: Russell King [EMAIL PROTECTED] Date: Wed, 23 Nov 2005 22:15:48 + I leave it up to you how to proceed. Effectively I'm now completely out of the loop on this with no hardware to worry about. Sorry. Finally, please don't assign any blame for this in my direction; I reported it and I kept bugging people about it, and in spite of my best efforts there was very little which was forthcoming. Obviously that wasn't enough. I think you're being unreasonable. I think you're being unreasonable telling me that I'm being unreasonable. They've worked on a fix for the problem, and now you're unable to test the fix, and you're angry at them because they took so long to code up the fix. If you're overextended and have too much work to do and that's stressing you out, that doesn't give you permission to take it out on other people. No. It's quite simple. I've worked on trying to replicate the problem today. Tomorrow I'm out at a meeting and since I'm no longer working on the problematical hardware, it is being returned. That means there's about 15 minutes left before I go to sleep before having to be up early tomorrow to go on a 2 hour journey to attend a meeting. What do you want me to do with those 15 minutes? Perform a miracle maybe? David, I ask you to retract your unreasonable mail. I'm being quite calm here. I'm just pointing out the facts that as of *now* I'm no longer in a position to test. I was rather hoping that being crystal clear about the reasons about _why_ I'm no longer able to continue participating in his problem that I would be seen not to be unreasonable. I guess I'm just cursed. Sorry. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - To unsubscribe from this list: send 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: 2.6 patch] remove drivers/net/eepro100.c
From: Russell King [EMAIL PROTECTED] Date: Wed, 23 Nov 2005 22:53:19 + That means there's about 15 minutes left before I go to sleep before having to be up early tomorrow to go on a 2 hour journey to attend a meeting. What do you want me to do with those 15 minutes? Perform a miracle maybe? It's perfectly fine that you are not able to test the fix. But being so visibly angry about it, that's the part I don't get. How about a I'm not able to test this due to lack of access to the necessary hardware, but I did give it a try although unsuccessful. Perhaps someone else can lend a hand so we can resolve this for good? That's the calm response. - To unsubscribe from this list: send 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 0/3] ioat: DMA engine support
Alan Cox wrote: Additionally, current IOAT is memory-memory. I would love to be able to convince Intel to add transforms and checksums, Not just transforms but also masks and maybe even merges and textures would be rather handy 8) Ah yes: I totally forgot to mention XOR. Software RAID would love that. 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: [RFC] [PATCH 0/3] ioat: DMA engine support
Andrew Grover wrote: overall diffstat information: drivers/Kconfig |2 drivers/Makefile |1 drivers/dma/Kconfig | 40 ++ drivers/dma/Makefile |5 drivers/dma/cb_list.h | 12 drivers/dma/dmaengine.c | 394 drivers/dma/testclient.c | 132 include/linux/dmaengine.h | 268 net/core/Makefile |3 net/core/dev.c| 78 net/core/user_dma.c | 422 ++ 11 files changed, 1356 insertions(+), 1 deletion(-) overall, there was a distinction lack of any useful description/documentation, over and above the code itself. 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: [RFC] [PATCH 0/3] ioat: DMA engine support
Andi Kleen wrote:
Longer term the right way to handle this would be likely to use
POSIX AIO on sockets. With that interface it would be easier
to keep long queues of data in flight, which would be best for
the DMA engine.
Agreed.
For my own userland projects, I'm starting to feel the need for network
AIO, since it is more natural: the hardware operations themselves are
asynchronous.
In addition to helping speed up network RX, I would like to see how
possible it is to experiment with IOAT uses outside of networking.
Sample ideas: VM page pre-zeroing. ATA PIO data xfers (async copy to
static buffer, to dramatically shorten length of kmap+irqsave time).
Extremely large memcpy() calls.
Another proposal was swiotlb.
That's an interesting thought.
But it's not clear it's a good idea: a lot of these applications prefer to
have the target in cache. And IOAT will force it out of cache.
Additionally, current IOAT is memory-memory. I would love to be able
to convince Intel to add transforms and checksums, to enable offload of
memory-transform-memory and memory-checksum-result operations like
sha-{1,256} hashing[1], crc32*, aes crypto, and other highly common
operations. All of that could be made async.
I remember the registers in the Amiga Blitter for this and I'm
still scared... Maybe it's better to keep it simple.
We're talking about CISC here! ;-) ;-)
[note: I'm the type of person who would stuff the kernel + glibc onto an
FPGA, if I could]
I would love to see Intel, AMD, VIA (others?) compete by adding selected
transforms/checksums/hashs to their chips, though this method. Just
provide a method to enumerate what transforms are supported on this
chip...
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: [2.6 patch] net/sunrpc/xdr.c: remove xdr_decode_string()
On Wednesday November 23, [EMAIL PROTECTED] wrote: On Wed, Nov 23, 2005 at 04:31:14AM -0800, Lever, Charles wrote: so i don't remember why you are removing xdr_decode_string. are we sure that no-one will need this functionality in the future? it is harmless to remove today, but i wonder if someone is just going to add it back sometime. It's unused and you said: the only harmless change i see below is removing xdr_decode_string(). As 'xdr_decode_string' (sometimes) modifies the buffer that it is decoding, I don't think it's usage should be encouraged. If it is no longer in use, then I fully support and encourage removing it. NeilBrown - To unsubscribe from this list: send 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 0/3] ioat: DMA engine support
On Mer, 2005-11-23 at 23:30 +0100, Andi Kleen wrote: Another proposal was swiotlb. I was hoping Intel might have rediscovered the IOMMU by then and be back on feature parity with the VAX 11/750 But it's not clear it's a good idea: a lot of these applications prefer to have the target in cache. And IOAT will force it out of cache. This is true for some cases but not all for iotlb CPU generated data going out that won't be rewritten immediately should be a cheap path not needing the cache. Incoming data would invalidate the cache anyway if it arrives by DMA so the ioat would move it asynchronously of the CPU without cache harm Might also be interesting to use one half of a hypedthread CPU as a copier using the streaming instructions, might be better than turning it off to improve performance ? Alan - To unsubscribe from this list: send 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 0/3] ioat: DMA engine support
Alan Cox wrote: Might also be interesting to use one half of a hypedthread CPU as a copier using the streaming instructions, might be better than turning it off to improve performance ? That's pretty interesting too... Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 1/3] ioat: DMA subsystem
On Wed, Nov 23, 2005 at 12:26:42PM -0800, Andrew Grover wrote:
+static void
+dma_class_release(struct class_device *cd)
+{
+ /* do something */
+}
Well, then actually do something here. Don't try to trick the kernel to
not complain about the lack of a release function by giving it an empty
function. This is wrong.
+static struct class dma_devclass = {
+ .name = dma,
+ .release= dma_class_release,
+ .class_dev_attrs = dma_class_attrs,
+};
Why not just use class_device_create() and friends, instead of building
your own class this way? It will take care of your look at the lack of
my release function issues, and make things easier to handle.
+EXPORT_SYMBOL(dma_async_client_register);
+EXPORT_SYMBOL(dma_async_client_unregister);
+EXPORT_SYMBOL(dma_async_client_chan_request);
+EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf);
+EXPORT_SYMBOL(dma_async_memcpy_buf_to_pg);
+EXPORT_SYMBOL(dma_async_memcpy_pg_to_pg);
+EXPORT_SYMBOL(dma_async_memcpy_complete);
+EXPORT_SYMBOL(dma_async_memcpy_issue_pending);
+EXPORT_SYMBOL(dma_async_device_register);
+EXPORT_SYMBOL(dma_async_device_unregister);
+EXPORT_SYMBOL(dma_async_wait_for_completion);
+EXPORT_PER_CPU_SYMBOL(kick_dma_poll);
EXPORT_SYMBOL_GPL() perhaps?
+/**
+ * enum dma_event_t - resource PNP/power managment events
+ * @DMA_RESOURCE_SUSPEND: DMA device going into low power state
+ * @DMA_RESOURCE_RESUME: DMA device returning to full power
+ * @DMA_RESOURCE_ADDED: DMA device added to the system
+ * @DMA_RESOURCE_REMOVED: DMA device removed from the system
+ */
+enum dma_event_t {
+ DMA_RESOURCE_SUSPEND,
+ DMA_RESOURCE_RESUME,
+ DMA_RESOURCE_ADDED,
+ DMA_RESOURCE_REMOVED,
+};
Why _t for an enum?
+/**
+ * struct dma_device - info on the entity supplying DMA services
+ * @chancnt: how many DMA channels are supported
+ * @channels: the list of struct dma_chan
+ * @global_node: list_head for global dma_device_list
+ * Other func ptrs: used to make use of this device's capabilities
+ */
+struct dma_device {
+
+ unsigned int chancnt;
+ struct list_head channels;
+ struct list_head global_node;
+
+ int dev_id;
+ /*struct class_device class_dev;*/
Commented out?
+ int (*device_alloc_chan_resources)(struct dma_chan *chan);
+ void (*device_free_chan_resources)(struct dma_chan *chan);
+ dma_cookie_t (*device_memcpy_buf_to_buf)(struct dma_chan *chan, void
*dest,
+ void *src, size_t len);
+ dma_cookie_t (*device_memcpy_buf_to_pg)(struct dma_chan *chan, struct
page *page,
+ unsigned int offset, void *kdata, size_t len);
+ dma_cookie_t (*device_memcpy_pg_to_pg)(struct dma_chan *chan, struct
page *dest_pg,
+ unsigned int dest_off, struct page *src_pg, unsigned int
src_off,
+ size_t len);
+ void (*device_arm_interrupt)(struct dma_chan *chan);
+ enum dma_status_t (*device_memcpy_complete)(struct dma_chan *chan,
dma_cookie_t cookie, dma_cookie_t *last, dma_cookie_t *used);
+ void (*device_memcpy_issue_pending)(struct dma_chan *chan);
+};
+
+/* --- public DMA engine API --- */
+
+struct dma_client *
+dma_async_client_register(dma_event_callback event_callback);
+
+void
+dma_async_client_unregister(struct dma_client *client);
+
+void
+dma_async_client_chan_request(struct dma_client *client, unsigned int
number);
Put return types on the same line as the function please.
+dma_cookie_t
+dma_async_memcpy_buf_to_buf(
+ struct dma_chan *chan,
+ void *dest,
+ void *src,
+ size_t len);
Ick, don't duplicate the acpi coding style here please :)
+static inline enum dma_status_t
+dma_async_is_complete(
+ dma_cookie_t cookie,
+ dma_cookie_t last_complete,
+ dma_cookie_t last_used) {
+
Trailing space :(
thanks,
greg k-h
-
To unsubscribe from this list: send 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 0/3] ioat: DMA engine support
From: Benjamin LaHaise [EMAIL PROTECTED] Date: Wed, 23 Nov 2005 19:17:01 -0500 Similarly, we should make sure that network drivers prefetch the header at the earliest possible time, too. Several do already, thankfully :) At last check skge, tg3, chelsio, and ixgb do the necessary prefetching on receive. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Mouse issues in -mm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Morton wrote: Marc Koschewski [EMAIL PROTECTED] wrote: Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported earlier) still persists, You'l probably need to re-report the mouse problem if the previous report didn't get any action. I'm not certain whether this is the same 'mouse problem', but I'll report the mouse problems I've been seeing. In the past several -mm kernels, my touchpad has initially worked at boot, but 'tapping' has stopped working at some point later (with no obvious kernel messages). I've experienced this problem at least with 2.6.15-rc1-mm2 and 2.6.15-rc2-mm1, and reverting input-attempt-to-re-synchronize-mouse-every-5-seconds.patch gives a kernel without the touchpad problems. Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDhSAuaI0dwg4A47wRAvzYAJ94ifBDBTm7MfVsbTOZE8QG3NjZUwCggHv0 SQvehLxz6pLHs+5J+jTeaKU= =Pkg2 -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network lockup under load
Some e1000 experts need to look into this. Hmmm, I'll find out who that is and bring them onboard, after the T.day break. I'll work with Joe to see where we can get on Monday. 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: Mouse issues in -mm
On Wednesday 23 November 2005 21:06, Frank Sorenson wrote: Andrew Morton wrote: Marc Koschewski [EMAIL PROTECTED] wrote: Just booted into 2.6.15-rc2-mm1. The 'mouse problem' (as reported earlier) still persists, You'l probably need to re-report the mouse problem if the previous report didn't get any action. I'm not certain whether this is the same 'mouse problem', but I'll report the mouse problems I've been seeing. In the past several -mm kernels, my touchpad has initially worked at boot, but 'tapping' has stopped working at some point later (with no obvious kernel messages). I've experienced this problem at least with 2.6.15-rc1-mm2 and 2.6.15-rc2-mm1, and reverting input-attempt-to-re-synchronize-mouse-every-5-seconds.patch gives a kernel without the touchpad problems. What kind of touchpad do you have? Could you post your /pros/bus/input/devices please? -- Dmitry - To unsubscribe from this list: send 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 patch] do not select NET_CLS
On Wed, Nov 23, 2005 at 06:13:32PM -0800, Randy.Dunlap wrote: So -q means quick ? From make help: -q, --question Run no commands; exit status says if up to date I wouldn't mind seeing a -quiet (even less quiet than V=0), not even printing the CC, AS, LD, etc. commands -- just let the tools print errors warnings. I always redirect output to a disk file and filter it for errors and warnings anyway, so I want hold my breath for this, but ISTM that V=0 could be even quieter than it is right now. make -s shuld give you this. I've not used it for long though... Sam - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] sk98lin: avoid message confusion with skge
Avoid possible confusion between skge and sk98lin driver by
tagging messages properly.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/sk98lin/skge.c
+++ skge-2.6/drivers/net/sk98lin/skge.c
@@ -4853,7 +4853,7 @@ static int __devinit skge_probe_one(stru
dev-irq = pdev-irq;
error = SkGeInitPCI(pAC);
if (error) {
- printk(SKGE: PCI setup failed: %i\n, error);
+ printk(KERN_ERR sk98lin: PCI setup failed: %i\n, error);
goto out_free_netdev;
}
@@ -4889,7 +4889,7 @@ static int __devinit skge_probe_one(stru
/* Register net device */
if (register_netdev(dev)) {
- printk(KERN_ERR SKGE: Could not register device.\n);
+ printk(KERN_ERR sk98lin: Could not register device.\n);
goto out_free_resources;
}
@@ -4955,7 +4955,7 @@ static int __devinit skge_probe_one(stru
#endif
if (register_netdev(dev)) {
- printk(KERN_ERR SKGE: Could not register device.\n);
+ printk(KERN_ERR sk98lin: Could not register device for
seconf port.\n);
free_netdev(dev);
pAC-dev[1] = pAC-dev[0];
} else {
--
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] sk98lin:
These patches fix some lingering issues with the sk98lin driver. I expect the sk98lin driver to fade from use, but many users still unknowingly use it. They are ordered from most important to least important. Feel free to divide across releases as you see fit. -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] sk98lin: remove redundant fields in device info
Shrink size of per device data by removing redundant fields
or things that are only used at boot up.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/sk98lin/h/skdrv2nd.h
+++ skge-2.6/drivers/net/sk98lin/h/skdrv2nd.h
@@ -268,8 +268,6 @@ typedef struct s_DevNet DEV_NET;
struct s_DevNet {
int PortNr;
int NetNr;
- int Mtu;
- int Up;
SK_AC *pAC;
};
@@ -391,12 +389,10 @@ struct s_AC {
SK_IOC IoBase; /* register set of adapter */
int BoardLevel; /* level of active hw init (0-2) */
- charDeviceStr[80]; /* adapter string from vpd */
+
SK_U32 AllocFlag; /* flag allocation of resources */
struct pci_dev *PciDev;/* for access to pci config space */
- SK_U32 PciDevId; /* pci device id */
struct SK_NET_DEVICE*dev[2];/* pointer to device struct */
- charName[30]; /* driver name */
int RxBufSize; /* length of receive buffers */
struct net_device_stats stats; /* linux 'netstat -i' statistics */
@@ -431,7 +427,6 @@ struct s_AC {
DIM_INFODynIrqModInfo; /* all data related to DIM */
/* Only for tests */
- int PortUp;
int PortDown;
int ChipsetType;/* Chipset family type
* 0 == Genesis family support
--- skge-2.6.orig/drivers/net/sk98lin/skge.c
+++ skge-2.6/drivers/net/sk98lin/skge.c
@@ -206,7 +206,6 @@ static void SkGeSetRxMode(struct SK_NET_
static struct net_device_stats *SkGeStats(struct SK_NET_DEVICE *dev);
static int SkGeIoctl(struct SK_NET_DEVICE *dev, struct ifreq *rq, int cmd);
static voidGetConfiguration(SK_AC*);
-static voidProductStr(SK_AC*);
static int XmitFrame(SK_AC*, TX_PORT*, struct sk_buff*);
static voidFreeTxDescriptors(SK_AC*pAC, TX_PORT*);
static voidFillRxRing(SK_AC*, RX_PORT*);
@@ -300,7 +299,7 @@ int SkGeInitPCI(SK_AC *pAC)
dev-mem_start = pci_resource_start (pdev, 0);
pci_set_master(pdev);
- if (pci_request_regions(pdev, pAC-Name) != 0) {
+ if (pci_request_regions(pdev, sk98lin) != 0) {
retval = 2;
goto out_disable;
}
@@ -578,10 +577,10 @@ SK_BOOL DualNet;
spin_unlock_irqrestore(pAC-SlowPathLock, Flags);
if (pAC-GIni.GIMacsFound == 2) {
-Ret = request_irq(dev-irq, SkGeIsr, SA_SHIRQ, pAC-Name, dev);
+Ret = request_irq(dev-irq, SkGeIsr, SA_SHIRQ, sk98lin, dev);
} else if (pAC-GIni.GIMacsFound == 1) {
Ret = request_irq(dev-irq, SkGeIsrOnePort, SA_SHIRQ,
- pAC-Name, dev);
+ sk98lin, dev);
} else {
printk(KERN_WARNING sk98lin: Illegal number of ports: %d\n,
pAC-GIni.GIMacsFound);
@@ -1265,7 +1264,6 @@ struct SK_NET_DEVICE *dev)
spin_unlock_irqrestore(pAC-SlowPathLock, Flags);
pAC-MaxPorts++;
- pNet-Up = 1;
SK_DBG_MSG(NULL, SK_DBGMOD_DRV, SK_DBGCAT_DRV_ENTRY,
@@ -1395,7 +1393,6 @@ struct SK_NET_DEVICE *dev)
sizeof(SK_PNMI_STRUCT_DATA));
pAC-MaxPorts--;
- pNet-Up = 0;
return (0);
} /* SkGeClose */
@@ -2547,7 +2544,7 @@ unsigned long Flags;
static int SkGeChangeMtu(struct SK_NET_DEVICE *dev, int NewMtu)
{
DEV_NET*pNet;
-DEV_NET*pOtherNet;
+struct net_device *pOtherDev;
SK_AC *pAC;
unsigned long Flags;
inti;
@@ -2577,11 +2574,11 @@ SK_EVPARA EvPara;
}
#endif
- pNet-Mtu = NewMtu;
- pOtherNet = netdev_priv(pAC-dev[1 - pNet-NetNr]);
- if ((pOtherNet-Mtu1500) (NewMtu=1500) (pOtherNet-Up==1)) {
- return(0);
- }
+ pOtherDev = pAC-dev[1 - pNet-NetNr];
+
+ if ( netif_running(pOtherDev) (pOtherDev-mtu 1500)
+ (NewMtu = 1500))
+ return 0;
pAC-RxBufSize = NewMtu + 32;
dev-mtu = NewMtu;
@@ -2743,7 +2740,8 @@ SK_EVPARA EvPara;
EvPara.Para32[1] = -1;
SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_START, EvPara);
- if (pOtherNet-Up) {
+ if (netif_running(pOtherDev)) {
+ DEV_NET *pOtherNet = netdev_priv(pOtherDev);
EvPara.Para32[0] = pOtherNet-PortNr;
SkEventQueue(pAC, SKGE_RLMT, SK_RLMT_START, EvPara);
}
@@ -2817,7 +2815,7 @@ unsigned long Flags; /* for spin
lock
pAC-stats.rx_bytes = (SK_U32) pPnmiStruct-RxOctetsDeliveredCts;
pAC-stats.tx_bytes = (SK_U32) pPnmiStat-StatTxOctetsOkCts;
-if
[PATCH 1/6] sk98lin: fix checksumming code
Remove code from sk98lin that does it's own checksum validation.
This code is incorrect when dealing with nested protocols like
VLAN's, and it is better to use regular receive code path to
handle hardware checksum.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Index: skge-2.6/drivers/net/sk98lin/Makefile
===
--- skge-2.6.orig/drivers/net/sk98lin/Makefile
+++ skge-2.6/drivers/net/sk98lin/Makefile
@@ -27,8 +27,7 @@ sk98lin-objs:=\
sktimer.o \
skvpd.o \
skxmac2.o \
- skproc.o\
- skcsum.o
+ skproc.o
# DBGDEF = \
# -DDEBUG
@@ -77,7 +76,7 @@ endif
# SK_DBGCAT_DRV_INT_SRC 0x0400 interrupts sources
# SK_DBGCAT_DRV_EVENT 0x0800 driver events
-EXTRA_CFLAGS += -Idrivers/net/sk98lin -DSK_DIAG_SUPPORT -DSK_USE_CSUM
-DGENESIS -DYUKON $(DBGDEF) $(SKPARAM)
+EXTRA_CFLAGS += -Idrivers/net/sk98lin -DSK_DIAG_SUPPORT -DGENESIS -DYUKON
$(DBGDEF) $(SKPARAM)
clean:
rm -f core *.o *.a *.s
Index: skge-2.6/drivers/net/sk98lin/h/skdrv2nd.h
===
--- skge-2.6.orig/drivers/net/sk98lin/h/skdrv2nd.h
+++ skge-2.6/drivers/net/sk98lin/h/skdrv2nd.h
@@ -425,10 +425,6 @@ struct s_AC {
TX_PORT TxPort[SK_MAX_MACS][2];
RX_PORT RxPort[SK_MAX_MACS];
- unsigned intCsOfs1; /* for checksum calculation */
- unsigned intCsOfs2; /* for checksum calculation */
- SK_U32 CsOfs; /* for checksum calculation */
-
SK_BOOL CheckQueue; /* check event queue soon */
SK_TIMERDrvCleanupTimer;/* to check for pending descriptors */
DIM_INFODynIrqModInfo; /* all data related to DIM */
Index: skge-2.6/drivers/net/sk98lin/skcsum.c
===
--- skge-2.6.orig/drivers/net/sk98lin/skcsum.c
+++ /dev/null
@@ -1,871 +0,0 @@
-/**
- *
- * Name: skcsum.c
- * Project:GEnesis, PCI Gigabit Ethernet Adapter
- * Version:$Revision: 1.12 $
- * Date: $Date: 2003/08/20 13:55:53 $
- * Purpose:Store/verify Internet checksum in send/receive packets.
- *
-
**/
-
-/**
- *
- * (C)Copyright 1998-2003 SysKonnect GmbH.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * The information in this file is provided AS IS without warranty.
- *
-
**/
-
-#ifdef SK_USE_CSUM /* Check if CSUM is to be used. */
-
-#ifndef lint
-static const char SysKonnectFileId[] =
- @(#) $Id: skcsum.c,v 1.12 2003/08/20 13:55:53 mschmid Exp $ (C)
SysKonnect.;
-#endif /* !lint */
-
-/**
- *
- * Description:
- *
- * This is the GEnesis common module CSUM.
- *
- * This module contains the code necessary to calculate, store, and verify the
- * Internet Checksum of IP, TCP, and UDP frames.
- *
- * GEnesis is an abbreviation of Gigabit Ethernet Network System in Silicon
- * and is the code name of this SysKonnect project.
- *
- * Compilation Options:
- *
- * SK_USE_CSUM - Define if CSUM is to be used. Otherwise, CSUM will be an
- * empty module.
- *
- * SKCS_OVERWRITE_PROTO - Define to overwrite the default protocol id
- * definitions. In this case, all SKCS_PROTO_xxx definitions must be made
- * external.
- *
- * SKCS_OVERWRITE_STATUS - Define to overwrite the default return status
- * definitions. In this case, all SKCS_STATUS_xxx definitions must be made
- * external.
- *
- * Include File Hierarchy:
- *
- * h/skdrv1st.h
- * h/skcsum.h
- * h/sktypes.h
- * h/skqueue.h
- * h/skdrv2nd.h
- *
-
**/
-
-#include h/skdrv1st.h
-#include h/skcsum.h
-#include h/skdrv2nd.h
-
-/* defines
/
-
-/* The size of an Ethernet MAC header. */
-#define SKCS_ETHERNET_MAC_HEADER_SIZE (6+6+2)
-
-/* The size of the used topology's MAC header. */
-#defineSKCS_MAC_HEADER_SIZESKCS_ETHERNET_MAC_HEADER_SIZE
-
-/* The size of the IP header without any option fields. */
-#define SKCS_IP_HEADER_SIZE20
-
-/*
- * Field offsets within the IP
[PATCH 6/6] sk98lin: remove /proc interface
Remove device specific proc interface. It doesn't handle
renames correctly; it ain't worth fixing.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- skge-2.6.orig/drivers/net/sk98lin/Makefile
+++ skge-2.6/drivers/net/sk98lin/Makefile
@@ -26,8 +26,7 @@ sk98lin-objs:=\
skrlmt.o\
sktimer.o \
skvpd.o \
- skxmac2.o \
- skproc.o
+ skxmac2.o
# DBGDEF = \
# -DDEBUG
--- skge-2.6.orig/drivers/net/sk98lin/skge.c
+++ skge-2.6/drivers/net/sk98lin/skge.c
@@ -110,7 +110,6 @@
#include linux/module.h
#include linux/moduleparam.h
#include linux/init.h
-#include linux/proc_fs.h
#include linux/dma-mapping.h
#include linux/ip.h
@@ -234,28 +233,6 @@ static int SkDrvDeInitAdapter(SK_AC
* Extern Function Prototypes
*
**/
-static const char SKRootName[] = net/sk98lin;
-static struct proc_dir_entry *pSkRootDir;
-extern struct file_operations sk_proc_fops;
-
-static inline void SkGeProcCreate(struct net_device *dev)
-{
- struct proc_dir_entry *pe;
-
- if (pSkRootDir
- (pe = create_proc_entry(dev-name, S_IRUGO, pSkRootDir))) {
- pe-proc_fops = sk_proc_fops;
- pe-data = dev;
- pe-owner = THIS_MODULE;
- }
-}
-
-static inline void SkGeProcRemove(struct net_device *dev)
-{
- if (pSkRootDir)
- remove_proc_entry(dev-name, pSkRootDir);
-}
-
extern void SkDimEnableModerationIfNeeded(SK_AC *pAC);
extern void SkDimDisplayModerationSettings(SK_AC *pAC);
extern void SkDimStartModerationTimer(SK_AC *pAC);
@@ -4899,8 +4876,6 @@ static int __devinit skge_probe_one(stru
memcpy(dev-dev_addr, pAC-Addr.Net[0].CurrentMacAddress, 6);
memcpy(dev-perm_addr, dev-dev_addr, dev-addr_len);
- SkGeProcCreate(dev);
-
pNet-PortNr = 0;
pNet-NetNr = 0;
@@ -4948,7 +4923,6 @@ static int __devinit skge_probe_one(stru
free_netdev(dev);
pAC-dev[1] = pAC-dev[0];
} else {
- SkGeProcCreate(dev);
memcpy(dev-dev_addr,
pAC-Addr.Net[1].CurrentMacAddress, 6);
memcpy(dev-perm_addr, dev-dev_addr, dev-addr_len);
@@ -4989,10 +4963,7 @@ static void __devexit skge_remove_one(st
SK_AC *pAC = pNet-pAC;
struct net_device *otherdev = pAC-dev[1];
- SkGeProcRemove(dev);
unregister_netdev(dev);
- if (otherdev != dev)
- SkGeProcRemove(otherdev);
SkGeYellowLED(pAC, pAC-IoBase, 0);
@@ -5137,23 +5108,12 @@ static struct pci_driver skge_driver = {
static int __init skge_init(void)
{
- int error;
-
- pSkRootDir = proc_mkdir(SKRootName, NULL);
- if (pSkRootDir)
- pSkRootDir-owner = THIS_MODULE;
-
- error = pci_register_driver(skge_driver);
- if (error)
- remove_proc_entry(SKRootName, NULL);
- return error;
+ return pci_module_init(skge_driver);
}
static void __exit skge_exit(void)
{
pci_unregister_driver(skge_driver);
- remove_proc_entry(SKRootName, NULL);
-
}
module_init(skge_init);
--- skge-2.6.orig/drivers/net/sk98lin/skproc.c
+++ /dev/null
@@ -1,265 +0,0 @@
-/**
- *
- * Name: skproc.c
- * Project:GEnesis, PCI Gigabit Ethernet Adapter
- * Version:$Revision: 1.11 $
- * Date: $Date: 2003/12/11 16:03:57 $
- * Purpose:Funktions to display statictic data
- *
-
**/
-
-/**
- *
- * (C)Copyright 1998-2002 SysKonnect GmbH.
- * (C)Copyright 2002-2003 Marvell.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * Created 22-Nov-2000
- * Author: Mirko Lindner ([EMAIL PROTECTED])
- *
- * The information in this file is provided AS IS without warranty.
- *
-
**/
-#include linux/proc_fs.h
-#include linux/seq_file.h
-
-#include h/skdrv1st.h
-#include h/skdrv2nd.h
-#include h/skversion.h
-
-static int sk_seq_show(struct seq_file *seq, void *v);
-static int sk_proc_open(struct inode *inode, struct file *file);
-
-struct file_operations sk_proc_fops = {
- .owner = THIS_MODULE,
- .open = sk_proc_open,
- .read = seq_read,
- .llseek =
Re: Mouse issues in -mm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dmitry Torokhov wrote: What kind of touchpad do you have? Could you post your /pros/bus/input/devices please? AlpsPS/2 ALPS GlidePoint /proc/bus/input/devices: I: Bus=0010 Vendor=001f Product=0001 Version=0100 N: Name=PC Speaker P: Phys=isa0061/input0 S: Sysfs=/class/input/input0 H: Handlers=kbd event0 B: EV=40001 B: SND=46 I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name=AT Translated Set 2 keyboard P: Phys=isa0060/serio0/input0 S: Sysfs=/class/input/input1 H: Handlers=kbd event1 B: EV=120013 B: KEY=4 200 3802078 f840d001 f2df ffef fffe B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0008 Version= N: Name=PS/2 Mouse P: Phys=isa0060/serio1/input1 S: Sysfs=/class/input/input2 H: Handlers=mouse0 event2 B: EV=7 B: KEY=7 0 0 0 0 0 0 0 0 B: REL=3 I: Bus=0011 Vendor=0002 Product=0008 Version=7321 N: Name=AlpsPS/2 ALPS GlidePoint P: Phys=isa0060/serio1/input0 S: Sysfs=/class/input/input3 H: Handlers=mouse1 event3 B: EV=f B: KEY=420 0 7 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=103 Note: I believe this issue may also be related to the mouse protocol extension. I typically run with 'psmouse.proto=exps' on the kernel command line, and the psmouse resync patch seems to break tapping in that mode. However, booting without proto=exps seems to continue to work, even with the resync patch (though the touchpad is unusably sensitive--hence the use of exps in the first place). Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDhVpQaI0dwg4A47wRAgxMAKCgcX59rpVR2umCUz4IBNls8L+8EQCfQprd 4v8Qxv3890dRIus0ptIyGxs= =AJGF -END PGP SIGNATURE- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] ioat: DMA engine support
On Wed, Nov 23, 2005 at 07:17:01PM -0500, Benjamin LaHaise wrote: On Wed, Nov 23, 2005 at 11:30:08PM +0100, Andi Kleen wrote: The main problem I see is that it'll likely only pay off when you can keep the queue of copies long (to amortize the cost of talking to an external chip). At least for the standard recvmsg skb-user space, user space- skb cases these queues are likely short in most cases. That's because most applications do relatively small recvmsg or sendmsgs. Don't forget that there are benefits of not polluting the cache with the traffic for the incoming skbs. Is that a general benefit outside benchmarks? I would expect most real programs to actually do something with the data - and that usually involves needing it in cache. But it's not clear it's a good idea: a lot of these applications prefer to have the target in cache. And IOAT will force it out of cache. In the I/O AT case it might make sense to do a few prefetch()es of the userland data on the return-to-userspace code path. Some prefetches for user space might be a good idea yes Similarly, we should make sure that network drivers prefetch the header at the earliest possible time, too. It's done kind of already but tricky to get right because the prefetch distances upto use are not really long enough -Andi - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Setting ipv6 route flags
Hi, I realized that in route.c the inet6_rtm_new_route() function the inet6_rtm_to_rtmsg() does not take into account the user supplied flags. This way it seems to be not possible to set the RTF_DEFAULT flag of a default route (dest address being any). It is true that the new route will end up in the default route list anyway but then the ip6_route_output() function will not call rt6_best_dflt(). I relaized it when I had to modify the default route selection algorithm. The kernel rt6_add_dflt_router() function properly sets the RTF_DEFAULT flag but user space functions cannot set it using netlink (e.g. iproute does not set it either). Is it the intended behaviour? If yes, why? Attached is a one-liner patch that I use now to solve this for me. It is against an usagi kernel but the issue is the same with stock 2.6.x kernels. Thanks, Gabor Fekete PS: I am not on this mailing list. --- linux26/net/ipv6/route.c2005-10-13 11:25:24.0 +0300 +++ linux26-new/net/ipv6/route.c2005-11-16 22:37:05.0 +0200 @@ -1651,7 +1651,7 @@ rtmsg-rtmsg_dst_len = r-rtm_dst_len; rtmsg-rtmsg_src_len = r-rtm_src_len; - rtmsg-rtmsg_flags = RTF_UP; + rtmsg-rtmsg_flags = RTF_UP | r-rtm_flags; if (r-rtm_type == RTN_UNREACHABLE) rtmsg-rtmsg_flags |= RTF_REJECT;
RE: [2.6 patch] net/sunrpc/xdr.c: remove xdr_decode_string()
On Wednesday November 23, [EMAIL PROTECTED] wrote: On Wed, Nov 23, 2005 at 04:31:14AM -0800, Lever, Charles wrote: so i don't remember why you are removing xdr_decode_string. are we sure that no-one will need this functionality in the future? it is harmless to remove today, but i wonder if someone is just going to add it back sometime. It's unused and you said: the only harmless change i see below is removing xdr_decode_string(). As 'xdr_decode_string' (sometimes) modifies the buffer that it is decoding, I don't think it's usage should be encouraged. If it is no longer in use, then I fully support and encourage removing it. actually this is a good point. since it is unused, it is an untested path as we continue to evolve the code base. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
