* [RFC-PATCH] dhcp provisioning support in cxgb3i
From: Rakesh Ranjan @ 2009-10-29 13:16 UTC (permalink / raw)
To: Mike Christie
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, James Bottomley, Karen Xie,
Rakesh Ranjan, open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
LKML, linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
Hi Mike,
Herein attached patches for having dhcp provisioning support in cxgb3i.
I have added one new iscsi netlink message ISCSI_UEVENT_REQ_IPCONF.
Please have a look and share suggestions.
Regards
Rakesh Ranjan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-added-one-new-netlink-message-ISCSI_UEVENT_REQ_IPCON.patch --]
[-- Type: text/x-patch, Size: 2922 bytes --]
>From 4b522723ab93b54504eeb738cc02f354635cec53 Mon Sep 17 00:00:00 2001
From: Rakesh Ranjan <rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Date: Thu, 29 Oct 2009 17:41:42 +0530
Subject: [PATCH] added one new netlink message ISCSI_UEVENT_REQ_IPCONF in libiscsi to support dhcp functionality in cxgb3i
Signed-off-by: Rakesh Ranjan <rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
---
drivers/scsi/scsi_transport_iscsi.c | 25 +++++++++++++++++++++++++
include/scsi/iscsi_if.h | 4 ++++
include/scsi/scsi_transport_iscsi.h | 1 +
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c
index ad897df..4897a3f 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -1508,6 +1508,28 @@ iscsi_set_path(struct iscsi_transport *transport, struct iscsi_uevent *ev)
}
static int
+iscsi_req_ipconf(struct iscsi_transport *transport, struct iscsi_uevent *ev)
+{
+ struct Scsi_Host *shost;
+ int err;
+
+ if (!transport->req_ipconf)
+ return -ENOSYS;
+
+ shost = scsi_host_lookup(ev->u.req_ipconf.host_no);
+ if (!shost) {
+ printk(KERN_ERR "ipconf req could not find host no %u\n",
+ ev->u.req_ipconf.host_no);
+ return -ENODEV;
+ }
+
+ err = transport->req_ipconf(shost);
+
+ scsi_host_put(shost);
+ return err;
+}
+
+static int
iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
{
int err = 0;
@@ -1627,6 +1649,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
case ISCSI_UEVENT_PATH_UPDATE:
err = iscsi_set_path(transport, ev);
break;
+ case ISCSI_UEVENT_REQ_IPCONF:
+ err = iscsi_req_ipconf(transport, ev);
+ break;
default:
err = -ENOSYS;
break;
diff --git a/include/scsi/iscsi_if.h b/include/scsi/iscsi_if.h
index d67dda2..939b1d6 100644
--- a/include/scsi/iscsi_if.h
+++ b/include/scsi/iscsi_if.h
@@ -59,6 +59,7 @@ enum iscsi_uevent_e {
ISCSI_UEVENT_TRANSPORT_EP_CONNECT_THROUGH_HOST = UEVENT_BASE + 19,
ISCSI_UEVENT_PATH_UPDATE = UEVENT_BASE + 20,
+ ISCSI_UEVENT_REQ_IPCONF = UEVENT_BASE + 21,
/* up events */
ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
@@ -172,6 +173,9 @@ struct iscsi_uevent {
struct msg_set_path {
uint32_t host_no;
} set_path;
+ struct msg_req_ipconf {
+ uint32_t host_no;
+ } req_ipconf;
} u;
union {
/* messages k -> u */
diff --git a/include/scsi/scsi_transport_iscsi.h b/include/scsi/scsi_transport_iscsi.h
index 349c7f3..3e5fd96 100644
--- a/include/scsi/scsi_transport_iscsi.h
+++ b/include/scsi/scsi_transport_iscsi.h
@@ -134,6 +134,7 @@ struct iscsi_transport {
int (*tgt_dscvr) (struct Scsi_Host *shost, enum iscsi_tgt_dscvr type,
uint32_t enable, struct sockaddr *dst_addr);
int (*set_path) (struct Scsi_Host *shost, struct iscsi_path *params);
+ int (*req_ipconf) (struct Scsi_Host *shost);
};
/*
--
1.6.0.6
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Implemented-dhcp-client-support-in-cxgb3i.patch --]
[-- Type: text/x-patch, Size: 16591 bytes --]
>From c64cae0fc1c281159141d9e624331f00e434f056 Mon Sep 17 00:00:00 2001
From: Rakesh Ranjan <rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Date: Thu, 29 Oct 2009 17:43:51 +0530
Subject: [PATCH] Implemented dhcp client support in cxgb3i
Signed-off-by: Rakesh Ranjan <rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
---
drivers/scsi/cxgb3i/Kbuild | 2 +-
drivers/scsi/cxgb3i/cxgb3i.h | 4 +
drivers/scsi/cxgb3i/cxgb3i_ipconfig.c | 519 +++++++++++++++++++++++++++++++++
drivers/scsi/cxgb3i/cxgb3i_iscsi.c | 23 ++-
drivers/scsi/cxgb3i/cxgb3i_offload.c | 3 +-
5 files changed, 548 insertions(+), 3 deletions(-)
create mode 100644 drivers/scsi/cxgb3i/cxgb3i_ipconfig.c
diff --git a/drivers/scsi/cxgb3i/Kbuild b/drivers/scsi/cxgb3i/Kbuild
index 70d060b..b0f1a3d 100644
--- a/drivers/scsi/cxgb3i/Kbuild
+++ b/drivers/scsi/cxgb3i/Kbuild
@@ -1,4 +1,4 @@
EXTRA_CFLAGS += -I$(srctree)/drivers/net/cxgb3
-cxgb3i-y := cxgb3i_init.o cxgb3i_iscsi.o cxgb3i_pdu.o cxgb3i_offload.o cxgb3i_ddp.o
+cxgb3i-y := cxgb3i_init.o cxgb3i_iscsi.o cxgb3i_pdu.o cxgb3i_offload.o cxgb3i_ddp.o cxgb3i_ipconfig.o
obj-$(CONFIG_SCSI_CXGB3_ISCSI) += cxgb3i.o
diff --git a/drivers/scsi/cxgb3i/cxgb3i.h b/drivers/scsi/cxgb3i/cxgb3i.h
index e3133b5..37b9a0d 100644
--- a/drivers/scsi/cxgb3i/cxgb3i.h
+++ b/drivers/scsi/cxgb3i/cxgb3i.h
@@ -158,4 +158,8 @@ int cxgb3i_conn_xmit_pdu(struct iscsi_task *);
void cxgb3i_release_itt(struct iscsi_task *task, itt_t hdr_itt);
int cxgb3i_reserve_itt(struct iscsi_task *task, itt_t *hdr_itt);
+int cxgb3i_ipconfig_init(struct cxgb3i_hba *hba);
+void cxgb3i_ipconfig_exit(struct cxgb3i_hba *hba);
+int cxgb3i_do_ipconf(struct cxgb3i_hba *hba);
+
#endif
diff --git a/drivers/scsi/cxgb3i/cxgb3i_ipconfig.c b/drivers/scsi/cxgb3i/cxgb3i_ipconfig.c
new file mode 100644
index 0000000..09eddb4
--- /dev/null
+++ b/drivers/scsi/cxgb3i/cxgb3i_ipconfig.c
@@ -0,0 +1,519 @@
+/* cxgb3i_ipconfig.c: Chelsio S3xx iSCSI dhcp client.
+ *
+ * Copyright (c) 2009 Chelsio Communications, Inc.
+ * Copyright (c) 2008 Mike Christie
+ * Copyright (c) 2008 Red Hat, Inc. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ *
+ * Written by: Rakesh Ranjan (rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org)
+ */
+
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/in.h>
+#include <linux/delay.h>
+#include <linux/if_arp.h>
+#include <net/ip.h>
+#include <scsi/iscsi_if.h>
+
+#include "common.h"
+#include "cxgb3i.h"
+
+#define DHCP_REQUEST 1
+#define DHCP_REPLY 2
+#define DHCP_HTYPE_ETHERNET 1
+#define DHCP_HLEN_ETHERNET 6
+#define DHCP_MSG_LEN 236
+
+#define DHCPC_SERVER_PORT 67
+#define DHCPC_CLIENT_PORT 68
+
+/* DHCP message types */
+#define DHCPDISCOVER 1
+#define DHCPOFFER 2
+#define DHCPREQUEST 3
+#define DHCPDECLINE 4
+#define DHCPACK 5
+#define DHCPNAK 6
+#define DHCPRELEASE 7
+#define DHCPINFORM 8
+
+/* DHCP options */
+#define DHCP_OPTION_SUBNET_MASK 1
+#define DHCP_OPTION_ROUTER 3
+#define DHCP_OPTION_DNS_SERVER 6
+#define DHCP_OPTION_MTU 26
+#define DHCP_OPTION_REQ_IPADDR 50
+#define DHCP_OPTION_LEASE_TIME 51
+#define DHCP_OPTION_MSG_TYPE 53
+#define DHCP_OPTION_SERVER_ID 54
+#define DHCP_OPTION_REQ_LIST 55
+#define DHCP_OPTION_VCID 60
+#define DHCP_OPTION_END 255
+
+enum {
+ STATE_INIT = 0,
+ STATE_SENDING,
+ STATE_OFFER_REC,
+ STATE_CONFIG_REC,
+};
+
+struct dhcp_pkt {
+ struct iphdr iph;
+ struct udphdr udph;
+ u8 op;
+ u8 htype;
+ u8 hlen;
+ u8 hops;
+ __be32 xid;
+ __be16 secs;
+ __be16 flags;
+ __be32 cipaddr;
+ __be32 yipaddr;
+ __be32 sipaddr;
+ __be32 ripaddr;
+ u8 chwaddr[16];
+ u8 sname[64];
+ u8 bfile[128];
+ u8 options[312];
+};
+
+struct hba_client_state {
+ struct sk_buff *skb;
+ struct dhcp_pkt *pkt;
+ struct cxgb3i_hba *hba;
+ volatile __u8 state;
+
+ __u8 *mac_addr;
+ __be32 xid;
+ __be32 ltime;
+ __be32 serverid;
+ __be32 ipaddr;
+ __be32 netmask;
+ __be32 dnsaddr;
+ __be32 gipaddr;
+};
+
+
+
+static struct hba_client_state *hcstate[MAX_NPORTS];
+
+static const char *RFC2132_VENDOR_CLASS_ID = "CXGB3I_Client";
+
+static const u8 magic_cookie[4] = { 99, 130, 83, 99 };
+
+
+
+static inline u8 *add_msg_type(u8 *optptr, u8 type)
+{
+ *optptr++ = DHCP_OPTION_MSG_TYPE;
+ *optptr++ = 1;
+ *optptr++ = type;
+ return optptr;
+}
+
+static inline u8 *add_req_options(u8 *optptr)
+{
+ *optptr++ = DHCP_OPTION_REQ_LIST;
+ *optptr++ = 4;
+ *optptr++ = DHCP_OPTION_SUBNET_MASK;
+ *optptr++ = DHCP_OPTION_ROUTER;
+ *optptr++ = DHCP_OPTION_DNS_SERVER;
+ *optptr++ = DHCP_OPTION_MTU;
+ return optptr;
+}
+
+static inline u8 *add_vendor_cid(u8 *optptr)
+{
+ u8 len = strlen(RFC2132_VENDOR_CLASS_ID);
+ *optptr++ = DHCP_OPTION_VCID;
+ *optptr++ = len;
+ memcpy(optptr, RFC2132_VENDOR_CLASS_ID, len);
+ optptr += len;
+ return optptr;
+}
+
+static inline u8 *add_server_id(__be32 *sid, u8 *optptr)
+{
+ *optptr++ = DHCP_OPTION_SERVER_ID;
+ *optptr++ = 4;
+ memcpy(optptr, sid, 4);
+ return optptr + 4;
+}
+
+static inline u8 *add_req_ipaddr(__be32 *ip, u8 *optptr)
+{
+ *optptr++ = DHCP_OPTION_REQ_IPADDR;
+ *optptr++ = 4;
+ memcpy(optptr, ip, 4);
+ return optptr + 4;
+}
+
+static inline u8 *add_end(u8 *optptr)
+{
+ *optptr++ = DHCP_OPTION_END;
+ return optptr;
+}
+
+static void
+cxgb3i_process_dhcp_opts(struct hba_client_state *client, u8 *optptr, int len)
+{
+ u8 *end = optptr + len;
+ u8 type = 0;
+
+ while (optptr < end) {
+ switch (*optptr) {
+ case DHCP_OPTION_SUBNET_MASK:
+ memcpy(&client->netmask, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_ROUTER:
+ memcpy(&client->gipaddr, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_DNS_SERVER:
+ memcpy(&client->dnsaddr, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_MSG_TYPE:
+ type = *(optptr + 2);
+ if (type == DHCPOFFER)
+ client->state = STATE_OFFER_REC;
+ else if (type == DHCPACK)
+ client->state = STATE_CONFIG_REC;
+ break;
+ case DHCP_OPTION_SERVER_ID:
+ memcpy(&client->serverid, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_LEASE_TIME:
+ memcpy(&client->ltime, optptr + 2, 4);
+ break;
+ case DHCP_OPTION_END:
+ break;
+ }
+
+ optptr += optptr[1] + 2;
+ }
+}
+
+static void
+cxgb3i_process_dhcp_pack(struct hba_client_state *client, struct dhcp_pkt *pkt)
+{
+ u8 *start, *end;
+ int opt_len;
+
+ start = &pkt->options[4];
+ end = (u8 *) pkt + ntohs(pkt->iph.tot_len);
+ opt_len = end - start;
+
+ if (pkt->op == DHCP_REPLY &&
+ !memcmp(&pkt->xid, &client->xid, sizeof(client->xid)) &&
+ !memcmp(pkt->chwaddr, client->mac_addr, pkt->hlen)) {
+ memcpy(&client->ipaddr, &pkt->yipaddr, 4);
+ cxgb3i_process_dhcp_opts(client, start, opt_len);
+ }
+}
+
+static int cxgb3i_ipconfig_send(struct port_info *pi, struct sk_buff **skb)
+{
+ int rc = 0;
+ struct sk_buff *lskb = *skb;
+ struct net_device *ndev = (hcstate[pi->port_id])->hba->ndev;
+
+ lskb->dev = ndev;
+ lskb->protocol = htons(ETH_P_IP);
+
+ dev_hard_header(lskb, ndev, ntohs(lskb->protocol), ndev->broadcast,
+ pi->iscsic.mac_addr, lskb->len);
+ rc = dev_queue_xmit(lskb);
+
+ return rc;
+}
+
+static int cxgb3i_ipconfig_recv(struct port_info *pi, struct sk_buff *skb)
+{
+ struct iphdr *iph;
+ struct udphdr *udph;
+ struct ethhdr *eh;
+ struct dhcp_pkt *pkt;
+ struct sk_buff *pskb;
+ int len, opts_len;
+ struct hba_client_state *client = hcstate[pi->port_id];
+ int rc = 0;
+
+ if (unlikely(client->state == STATE_INIT))
+ goto out;
+
+ cxgb3i_log_debug("client->state : %d\n", client->state);
+
+ if (skb->pkt_type != PACKET_OTHERHOST)
+ goto out;
+
+ pskb = skb_copy(skb, GFP_ATOMIC);
+ if (!pskb) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ eh = eth_hdr(pskb);
+ if (!is_valid_ether_addr(eh->h_dest))
+ goto drop;
+
+ if (compare_ether_addr(eh->h_dest, pi->iscsic.mac_addr))
+ goto drop;
+
+ if (!pskb_may_pull(pskb, sizeof(struct iphdr) + sizeof(struct udphdr)))
+ goto drop;
+
+
+ skb_reset_network_header(pskb);
+ pkt = (struct dhcp_pkt *) skb_network_header(pskb);
+ iph = &pkt->iph;
+
+ if (iph->ihl != 5 || iph->version != 4 || iph->protocol != IPPROTO_UDP)
+ goto drop;
+
+ if (iph->frag_off & htons(IP_OFFSET | IP_MF))
+ goto drop;
+
+ if (skb->len < ntohs(iph->tot_len))
+ goto drop;
+
+ if (ip_fast_csum((u8 *)iph, iph->ihl))
+ goto drop;
+
+ udph = &pkt->udph;
+ if (udph->source != htons(67) || udph->dest != htons(68))
+ goto drop;
+
+ if (ntohs(iph->tot_len) < ntohs(udph->len) + sizeof(struct iphdr))
+ goto drop;
+
+ len = ntohs(udph->len) - sizeof(struct udphdr);
+ opts_len = len - (sizeof(*pkt) -
+ sizeof(struct iphdr) -
+ sizeof(struct udphdr) -
+ sizeof(pkt->options));
+ if (opts_len < 0)
+ goto drop;
+
+ if (memcmp(pkt->options, magic_cookie, 4)) {
+ cxgb3i_log_error("Bad DHCP cookie recieved, aborting");
+ goto drop;
+ }
+
+ cxgb3i_log_debug("Received DHCP offer, processing");
+
+ cxgb3i_process_dhcp_pack(client, pkt);
+
+drop:
+ kfree(pskb);
+out:
+ return rc;
+}
+
+static int
+cxgb3i_create_dhcp_msg(struct hba_client_state *client)
+{
+ struct iphdr *iph;
+ struct udphdr *udph;
+ struct sk_buff *skb;
+ struct dhcp_pkt *pkt;
+ int rc = 0;
+ struct port_info *pi = netdev_priv(client->hba->ndev);
+
+ skb = alloc_skb(sizeof(*pkt) +
+ LL_ALLOCATED_SPACE(client->hba->ndev) + 15,
+ GFP_ATOMIC);
+ if (!skb) {
+ rc = -ENOMEM;
+ return rc;
+ }
+
+ client->skb = skb;
+ skb_reserve(skb, LL_RESERVED_SPACE(client->hba->ndev));
+
+ pkt = (struct dhcp_pkt *) skb_put(skb, sizeof(*pkt));
+ client->pkt = pkt;
+ memset(pkt, 0, sizeof(*pkt));
+
+ skb_reset_network_header(skb);
+
+ /* construct IP header */
+ iph = &pkt->iph;
+ iph->version = 4;
+ iph->ihl = 5;
+ iph->tot_len = htons(sizeof(struct dhcp_pkt));
+ iph->frag_off = htons(IP_DF);
+ iph->ttl = 64;
+ iph->protocol = IPPROTO_UDP;
+ iph->daddr = htonl(INADDR_BROADCAST);
+ iph->check = ip_fast_csum((u8 *) iph, iph->ihl);
+
+ /* Construct UDP header */
+ udph = &pkt->udph;
+ udph->source = htons(DHCPC_CLIENT_PORT);
+ udph->dest = htons(DHCPC_SERVER_PORT);
+ udph->len = htons(sizeof(struct dhcp_pkt) - sizeof(struct iphdr));
+
+ pkt->op = DHCP_REQUEST;
+ pkt->htype = DHCP_HTYPE_ETHERNET;
+ pkt->hlen = ETH_ALEN;
+
+ memcpy(pkt->chwaddr, pi->iscsic.mac_addr, ETH_ALEN);
+ pkt->secs = htons(jiffies / HZ);
+ pkt->xid = client->xid;
+
+ memcpy(pkt->options, magic_cookie, sizeof(magic_cookie));
+
+ return rc;
+}
+
+static int cxgb3i_send_dhcp_request(struct hba_client_state *client)
+{
+ int rc = 0;
+ u8 *end;
+ struct port_info *pi = netdev_priv(client->hba->ndev);
+
+ rc = cxgb3i_create_dhcp_msg(client);
+ if (rc)
+ return rc;
+
+ end = add_msg_type(&client->pkt->options[4], DHCPREQUEST);
+ end = add_server_id(&client->serverid, end);
+ end = add_req_ipaddr(&client->ipaddr, end);
+ end = add_vendor_cid(end);
+ end = add_end(end);
+
+ rc = cxgb3i_ipconfig_send(pi, &client->skb);
+
+ return rc;
+}
+
+static int cxgb3i_send_dhcp_discover(struct hba_client_state *client)
+{
+ int rc = 0;
+ u8 *end;
+ struct port_info *pi = netdev_priv(client->hba->ndev);
+
+ rc = cxgb3i_create_dhcp_msg(client);
+ if (rc)
+ return rc;
+
+ end = add_msg_type(&client->pkt->options[4], DHCPDISCOVER);
+ end = add_req_options(end);
+ end = add_vendor_cid(end);
+ end = add_end(end);
+
+ client->state = STATE_SENDING;
+ rc = cxgb3i_ipconfig_send(pi, &client->skb);
+
+ return rc;
+}
+
+static void
+cxgb3i_wait_for_pack(struct hba_client_state *client, u8 state)
+{
+ unsigned long tout, ntout;
+
+ get_random_bytes(&tout, sizeof(tout));
+ tout = (tout % (unsigned)HZ) + (HZ * 2);
+
+ ntout = jiffies + tout;
+ while (time_before(jiffies, ntout) && (client->state != state))
+ schedule_timeout_uninterruptible(1);
+}
+
+int cxgb3i_do_ipconf(struct cxgb3i_hba *hba)
+{
+ int rc = 0;
+ int retry;
+ struct hba_client_state *client = NULL;
+ struct port_info *pi = netdev_priv(hba->ndev);
+
+ client = hcstate[pi->port_id];
+ retry = 2;
+
+ /* show time */
+ for (;;) {
+ get_random_bytes(&client->xid, sizeof(__be32));
+ cxgb3i_send_dhcp_discover(client);
+ cxgb3i_wait_for_pack(client, STATE_OFFER_REC);
+
+ if (client->state == STATE_OFFER_REC) {
+ cxgb3i_log_debug("DHCPOFFER received for hba [%p]\n",
+ hba);
+ cxgb3i_send_dhcp_request(client);
+ cxgb3i_wait_for_pack(client, STATE_CONFIG_REC);
+ if (client->state == STATE_CONFIG_REC) {
+ cxgb3i_log_info("setting ip address of hba %p "
+ "to %pI4\n", hba, &client->ipaddr);
+ cxgb3i_set_private_ipv4addr(hba->ndev,
+ client->ipaddr);
+ client->state = STATE_INIT;
+ break;
+ }
+ }
+
+ if (!--retry) {
+ cxgb3i_log_info("IPCONFIG timed out for hba [%p]\n",
+ hba);
+ rc = -ENETUNREACH;
+ break;
+ }
+ }
+
+ return rc;
+}
+
+int cxgb3i_ipconfig_init(struct cxgb3i_hba *hba)
+{
+ int rc = 0;
+ struct hba_client_state *client = NULL;
+ struct port_info *pi = netdev_priv(hba->ndev);
+
+ client = kzalloc(sizeof(*client), GFP_KERNEL);
+ if (!client) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ client->hba = hba;
+ client->mac_addr = pi->iscsic.mac_addr;
+ client->state = STATE_INIT;
+
+ hcstate[pi->port_id] = client;
+ cxgb3i_log_debug("added hcstate[%d] : %p\n", pi->port_id,
+ hcstate[pi->port_id]);
+
+ pi->iscsic.send = cxgb3i_ipconfig_send;
+ pi->iscsic.recv = cxgb3i_ipconfig_recv;
+ pi->iscsic.flags = 1;
+
+out:
+ return rc;
+}
+
+void cxgb3i_ipconfig_exit(struct cxgb3i_hba *hba)
+{
+ struct net_device *ndev = hba->ndev;
+ struct port_info *pi = netdev_priv(ndev);
+
+ cxgb3i_set_private_ipv4addr(hba->ndev, 0);
+
+ pi->iscsic.flags = 0;
+ pi->iscsic.send = NULL;
+ pi->iscsic.recv = NULL;
+
+ if (hcstate[pi->port_id]) {
+ cxgb3i_log_info("removing hcstate[%d] : %p\n", pi->port_id,
+ hcstate[pi->port_id]);
+ kfree(hcstate[pi->port_id]);
+ }
+
+}
+
diff --git a/drivers/scsi/cxgb3i/cxgb3i_iscsi.c b/drivers/scsi/cxgb3i/cxgb3i_iscsi.c
index 2631bdd..2bb5e63 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_iscsi.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_iscsi.c
@@ -240,6 +240,13 @@ struct cxgb3i_hba *cxgb3i_hba_host_add(struct cxgb3i_adapter *snic,
goto pci_dev_put;
}
+ err = cxgb3i_ipconfig_init(hba);
+ if (err) {
+ cxgb3i_log_info("snic 0x%p, ndev 0x%p, host_add failed.\n",
+ snic, ndev);
+ goto pci_dev_put;
+ }
+
cxgb3i_api_debug("shost 0x%p, hba 0x%p, no %u.\n",
shost, hba, shost->host_no);
@@ -259,6 +266,7 @@ void cxgb3i_hba_host_remove(struct cxgb3i_hba *hba)
{
cxgb3i_api_debug("shost 0x%p, hba 0x%p, no %u.\n",
hba->shost, hba, hba->shost->host_no);
+ cxgb3i_ipconfig_exit(hba);
iscsi_host_remove(hba->shost);
pci_dev_put(hba->snic->pdev);
iscsi_host_free(hba->shost);
@@ -737,13 +745,14 @@ static int cxgb3i_host_get_param(struct Scsi_Host *shost,
enum iscsi_host_param param, char *buf)
{
struct cxgb3i_hba *hba = iscsi_host_priv(shost);
+ struct port_info *pi = netdev_priv(hba->ndev);
int len = 0;
cxgb3i_api_debug("hba %s, param %d.\n", hba->ndev->name, param);
switch (param) {
case ISCSI_HOST_PARAM_HWADDRESS:
- len = sysfs_format_mac(buf, hba->ndev->dev_addr, 6);
+ len = sysfs_format_mac(buf, pi->iscsic.mac_addr, ETH_ALEN);
break;
case ISCSI_HOST_PARAM_NETDEV_NAME:
len = sprintf(buf, "%s\n", hba->ndev->name);
@@ -762,6 +771,17 @@ static int cxgb3i_host_get_param(struct Scsi_Host *shost,
return len;
}
+static int cxgb3i_req_ipconf(struct Scsi_Host *shost)
+{
+ int rc;
+
+ struct cxgb3i_hba *hba = iscsi_host_priv(shost);
+
+ rc = cxgb3i_do_ipconf(hba);
+
+ return rc;
+}
+
/**
* cxgb3i_conn_get_stats - returns iSCSI stats
* @cls_conn: pointer to iscsi cls conn
@@ -976,6 +996,7 @@ static struct iscsi_transport cxgb3i_iscsi_transport = {
.ep_disconnect = cxgb3i_ep_disconnect,
/* Error recovery timeout call */
.session_recovery_timedout = iscsi_session_recovery_timedout,
+ .req_ipconf = cxgb3i_req_ipconf,
};
int cxgb3i_iscsi_init(void)
diff --git a/drivers/scsi/cxgb3i/cxgb3i_offload.c b/drivers/scsi/cxgb3i/cxgb3i_offload.c
index c1d5be4..8fdafeb 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_offload.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_offload.c
@@ -269,7 +269,8 @@ static void make_act_open_req(struct s3_conn *c3cn, struct sk_buff *skb,
req->local_ip = c3cn->saddr.sin_addr.s_addr;
req->peer_ip = c3cn->daddr.sin_addr.s_addr;
req->opt0h = htonl(calc_opt0h(c3cn) | V_L2T_IDX(e->idx) |
- V_TX_CHANNEL(e->smt_idx));
+ V_TX_CHANNEL(e->smt_idx) |
+ V_SRC_MAC_SEL(SAN_MAC_IDX));
req->opt0l = htonl(calc_opt0l(c3cn));
req->params = 0;
}
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: Matt Domsch @ 2009-10-29 13:11 UTC (permalink / raw)
To: Kay Sievers
Cc: dann frazier, linux-hotplug, Narendra_K, netdev, Jordan_Hargrave,
Charles_Rose, Ben Hutchings
In-Reply-To: <ac3eb2510910280123g3c0e3d95wb38a239238906027@mail.gmail.com>
On Wed, Oct 28, 2009 at 09:23:57AM +0100, Kay Sievers wrote:
> On Tue, Oct 27, 2009 at 21:55, Matt Domsch <Matt_Domsch@dell.com> wrote:
> > On Thu, Oct 22, 2009 at 12:36:20AM -0600, dann frazier wrote:
> >> Here's a proof of concept to further the discussion..
> >>
> >> The default filename uses the format:
> >> ?? /dev/netdev/by-ifindex/$ifindex
> >>
> >> This provides the infrastructure to permit udev rules to create aliases for
> >> network devices using symlinks, for example:
> >>
> >> ?? /dev/netdev/by-name/eth0 -> ../by-ifindex/1
> >> ?? /dev/netdev/by-biosname/LOM0 -> ../by-ifindex/3
> >>
> >> A library (such as the proposed libnetdevname) could use this information
> >> to provide an alias->realname mapping for network utilities.
>
> That all sounds very much like something which will hit us back some
> day. I'm not sure, if udev should publish such dead text files in
> /dev, it does not seem to fit the usual APIs/assumptions where /sys
> and /dev match, and libudev provides access to both.
While we could do this without any kernel changes at all, it does
still leave unresolved the concern of the in-kernel users of
netdevice-by-name - everything that uses dev_get_by_name(), and any
userspace tool that doesn't get converted to use the netdevice-by-path
concept.
Which brings us back to still looking for options.
Multiple names for the same device gives us a way out.
Users of the ethX naming convention continue unchanged, and live
with the nondeterminism; Users of other naming conventions can get
names that work for them, with needed determinism.
Netdev team - are you in agreement that having multiple names to
address the same netdevice is a worthwhile thing to add, to allow a
variety of naming schemes to exist simultaneously? If not, this whole
discussion will be moot, and my basic problem, that the ethX naming
convention is nondeterministic, but we need determinism, remains
unresolved.
Assuming we agree it's worthwhile, I'm open to ideas for ways to solve
it. We've proposed char devices for udev to manage, and fixing up
userspace programs, but that doesn't solve in-kernel users by name.
Dann proposed another method (above) which Kay isn't fond of, and
which has the same drawback. I need another option then.
Thanks,
Matt
--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
^ permalink raw reply
* Re: [PATCH] Regression: e100_phy_init() isolates even selected PHY, causes 10 seconds boot delay
From: David Miller @ 2009-10-29 13:02 UTC (permalink / raw)
To: bernhard.kaindl; +Cc: bruce.w.allan, jeffrey.t.kirsher, netdev
In-Reply-To: <4AC3C09B.3040203@gmx.net>
From: Bernhard Kaindl <bernhard.kaindl@gmx.net>
Date: Wed, 30 Sep 2009 22:33:31 +0200
> The current e100.c:e100_phy_init() electrically isolates all
> the PHYs (even the selected PHY -- for a short time!) from the MII.
>
> This happens only for a short duration before the isolation
> of the selected PHY is reverted, but it's enough to cause a
> major disturbance in the startup of our e100-based cards:
>
> On a number of Embedded/Industry Pentium boards which are in use,
> the result is that the initial DHCP negotiation takes more
> than 10 seconds to complete with 2.6.30 and .31, while it's
> done in a fraction of a second with 2.6.29 and earlier
> (kernels tested with no delay range from 2.6.23 to 2.6.29)
>
> That regression was introduced on March 31 in the by a patch
> from Bruce which first appeared in 2.6.30-rc3:
Bruce, can you give some feedback on this? I'd like to see this issue
move forward.
The only reason I haven't applied Bernhard's patch is because I
haven't seen any feedback from Intel. But I will apply it anyways if
I don't see reasonable feedback soon.
Thanks.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 12:59 UTC (permalink / raw)
To: bzolnier-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <200910291345.05888.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 29 Oct 2009 13:45:05 +0100
> That *I* should be fixing the patch in question instead of the
> submitter?
I'm saying that you should work with John to have him send a revert or
whatever to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Fw: [Bug 14470] New: freez in TCP stack
From: Ilpo Järvinen @ 2009-10-29 12:58 UTC (permalink / raw)
To: Eric Dumazet, David Miller
Cc: Andrew Morton, Stephen Hemminger, Netdev, kolo, bugzilla-daemon
In-Reply-To: <4AE9298C.1000204@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 10018 bytes --]
On Thu, 29 Oct 2009, Eric Dumazet wrote:
> Andrew Morton a écrit :
> > On Mon, 26 Oct 2009 08:41:32 -0700
> > Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> >
> >>
> >> Begin forwarded message:
> >>
> >> Date: Mon, 26 Oct 2009 12:47:22 GMT
> >> From: bugzilla-daemon@bugzilla.kernel.org
> >> To: shemminger@linux-foundation.org
> >> Subject: [Bug 14470] New: freez in TCP stack
> >>
> >
> > Stephen, please retain the bugzilla and reporter email cc's when
> > forwarding a report to a mailing list.
> >
> >
> >> http://bugzilla.kernel.org/show_bug.cgi?id=14470
> >>
> >> Summary: freez in TCP stack
> >> Product: Networking
> >> Version: 2.5
> >> Kernel Version: 2.6.31
> >> Platform: All
> >> OS/Version: Linux
> >> Tree: Mainline
> >> Status: NEW
> >> Severity: high
> >> Priority: P1
> >> Component: IPV4
> >> AssignedTo: shemminger@linux-foundation.org
> >> ReportedBy: kolo@albatani.cz
> >> Regression: No
> >>
> >>
> >> We are hiting kernel panics on Dell R610 servers with e1000e NICs; it apears
> >> usualy under a high network trafic ( around 100Mbit/s) but it is not a rule it
> >> has happened even on low trafic.
> >>
> >> Servers are used as reverse http proxy (varnish).
> >>
> >> On 6 equal servers this panic happens aprox 2 times a day depending on network
> >> load. Machine completly freezes till the management watchdog reboots.
> >>
> >
> > Twice a day on six separate machines. That ain't no hardware glitch.
> >
> > Vaclav, are you able to say whether this is a regression? Did those
> > machines run 2.6.30 (for example)?
> >
> > Thanks.
> >
> >> We had to put serial console on these servers to catch the oops. Is there
> >> anything else We can do to debug this?
> >> The RIP is always the same:
> >>
> >> RIP: 0010:[<ffffffff814203cc>] [<ffffffff814203cc>]
> >> tcp_xmit_retransmit_queue+0x8c/0x290
> >>
> >> rest of the oops always differs a litle ... here is an example:
> >>
> >> RIP: 0010:[<ffffffff814203cc>] [<ffffffff814203cc>]
> >> tcp_xmit_retransmit_queue+0x8c/0x290
> >> RSP: 0018:ffffc90000003a40 EFLAGS: 00010246
> >> RAX: ffff8807e7420678 RBX: ffff8807e74205c0 RCX: 0000000000000000
> >> RDX: 000000004598a105 RSI: 0000000000000000 RDI: ffff8807e74205c0
> >> RBP: ffffc90000003a80 R08: 0000000000000003 R09: 0000000000000000
> >> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> >> R13: ffff8807e74205c0 R14: ffff8807e7420678 R15: 0000000000000000
> >> FS: 0000000000000000(0000) GS:ffffc90000000000(0000) knlGS:0000000000000000
> >> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> >> CR2: 0000000000000000 CR3: 0000000001001000 CR4: 00000000000006f0
> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> Process swapper (pid: 0, threadinfo ffffffff81608000, task ffffffff81631440)
> >> Stack:
> >> ffffc90000003a60 0000000000000000 4598a105e74205c0 000000004598a101
> >> <0> 000000000000050e ffff8807e74205c0 0000000000000003 0000000000000000
> >> <0> ffffc90000003b40 ffffffff8141ae4a ffff8807e7420678 0000000000000000
> >> Call Trace:
> >> <IRQ>
> >> [<ffffffff8141ae4a>] tcp_ack+0x170a/0x1dd0
> >> [<ffffffff8141c362>] tcp_rcv_state_process+0x122/0xab0
> >> [<ffffffff81422c6c>] tcp_v4_do_rcv+0xac/0x220
> >> [<ffffffff813fd02f>] ? nf_iterate+0x5f/0x90
> >> [<ffffffff81424b26>] tcp_v4_rcv+0x586/0x6b0
> >> [<ffffffff813fd0c5>] ? nf_hook_slow+0x65/0xf0
> >> [<ffffffff81406b70>] ? ip_local_deliver_finish+0x0/0x120
> >> [<ffffffff81406bcf>] ip_local_deliver_finish+0x5f/0x120
> >> [<ffffffff8140715b>] ip_local_deliver+0x3b/0x90
> >> [<ffffffff81406971>] ip_rcv_finish+0x141/0x340
> >> [<ffffffff8140701f>] ip_rcv+0x24f/0x350
> >> [<ffffffff813e7ced>] netif_receive_skb+0x20d/0x2f0
> >> [<ffffffff813e7e90>] napi_skb_finish+0x40/0x50
> >> [<ffffffff813e82f4>] napi_gro_receive+0x34/0x40
> >> [<ffffffff8133e0c8>] e1000_receive_skb+0x48/0x60
> >> [<ffffffff81342342>] e1000_clean_rx_irq+0xf2/0x330
> >> [<ffffffff813410a1>] e1000_clean+0x81/0x2a0
> >> [<ffffffff81054ce1>] ? ktime_get+0x11/0x50
> >> [<ffffffff813eaf1c>] net_rx_action+0x9c/0x130
> >> [<ffffffff81046940>] ? get_next_timer_interrupt+0x1d0/0x210
> >> [<ffffffff81041bd7>] __do_softirq+0xb7/0x160
> >> [<ffffffff8100c27c>] call_softirq+0x1c/0x30
> >> [<ffffffff8100e04d>] do_softirq+0x3d/0x80
> >> [<ffffffff81041b0b>] irq_exit+0x7b/0x90
> >> [<ffffffff8100d613>] do_IRQ+0x73/0xe0
> >> [<ffffffff8100bb13>] ret_from_intr+0x0/0xa
> >> <EOI>
> >> [<ffffffff81296e6c>] ? acpi_idle_enter_bm+0x245/0x271
> >> [<ffffffff81296e62>] ? acpi_idle_enter_bm+0x23b/0x271
> >> [<ffffffff813c7a08>] ? cpuidle_idle_call+0x98/0xf0
> >> [<ffffffff8100a104>] ? cpu_idle+0x94/0xd0
> >> [<ffffffff81468db6>] ? rest_init+0x66/0x70
> >> [<ffffffff816a082f>] ? start_kernel+0x2ef/0x340
> >> [<ffffffff8169fd54>] ? x86_64_start_reservations+0x84/0x90
> >> [<ffffffff8169fe32>] ? x86_64_start_kernel+0xd2/0x100
> >> Code: 00 eb 28 8b 83 d0 03 00 00 41 39 44 24 40 0f 89 00 01 00 00 41 0f b6 cd
> >> 41 bd 2f 00 00 00 83 e1 03 0f 84 fc 00 00 00 4d 8b 24 24 <49> 8b 04 24 4d 39 f4
> >> 0f 18 08 0f 84 d9 00 00 00 4c 3b a3 b8 01
> >> RIP [<ffffffff814203cc>] tcp_xmit_retransmit_queue+0x8c/0x290
> >> RSP <ffffc90000003a40>
> >> CR2: 0000000000000000
> >> ---[ end trace d97d99c9ae1d52cc ]---
> >> Kernel panic - not syncing: Fatal exception in interrupt
> >> Pid: 0, comm: swapper Tainted: G D 2.6.31 #2
> >> Call Trace:
> >> <IRQ> [<ffffffff8103cab0>] panic+0xa0/0x170
> >> [<ffffffff8100bb13>] ? ret_from_intr+0x0/0xa
> >> [<ffffffff8103c74e>] ? print_oops_end_marker+0x1e/0x20
> >> [<ffffffff8100f38e>] oops_end+0x9e/0xb0
> >> [<ffffffff81025b9a>] no_context+0x15a/0x250
> >> [<ffffffff81025e2b>] __bad_area_nosemaphore+0xdb/0x1c0
> >> [<ffffffff813e89e9>] ? dev_hard_start_xmit+0x269/0x2f0
> >> [<ffffffff81025fae>] bad_area_nosemaphore+0xe/0x10
> >> [<ffffffff8102639f>] do_page_fault+0x17f/0x260
> >> [<ffffffff8147eadf>] page_fault+0x1f/0x30
> >> [<ffffffff814203cc>] ? tcp_xmit_retransmit_queue+0x8c/0x290
> >> [<ffffffff8141ae4a>] tcp_ack+0x170a/0x1dd0
> >> [<ffffffff8141c362>] tcp_rcv_state_process+0x122/0xab0
> >> [<ffffffff81422c6c>] tcp_v4_do_rcv+0xac/0x220
> >> [<ffffffff813fd02f>] ? nf_iterate+0x5f/0x90
> >> [<ffffffff81424b26>] tcp_v4_rcv+0x586/0x6b0
> >> [<ffffffff813fd0c5>] ? nf_hook_slow+0x65/0xf0
> >> [<ffffffff81406b70>] ? ip_local_deliver_finish+0x0/0x120
> >> [<ffffffff81406bcf>] ip_local_deliver_finish+0x5f/0x120
> >> [<ffffffff8140715b>] ip_local_deliver+0x3b/0x90
> >> [<ffffffff81406971>] ip_rcv_finish+0x141/0x340
> >> [<ffffffff8140701f>] ip_rcv+0x24f/0x350
> >> [<ffffffff813e7ced>] netif_receive_skb+0x20d/0x2f0
> >> [<ffffffff813e7e90>] napi_skb_finish+0x40/0x50
> >> [<ffffffff813e82f4>] napi_gro_receive+0x34/0x40
> >> [<ffffffff8133e0c8>] e1000_receive_skb+0x48/0x60
> >> [<ffffffff81342342>] e1000_clean_rx_irq+0xf2/0x330
> >> [<ffffffff813410a1>] e1000_clean+0x81/0x2a0
> >> [<ffffffff81054ce1>] ? ktime_get+0x11/0x50
> >> [<ffffffff813eaf1c>] net_rx_action+0x9c/0x130
> >> [<ffffffff81046940>] ? get_next_timer_interrupt+0x1d0/0x210
> >> [<ffffffff81041bd7>] __do_softirq+0xb7/0x160
> >> [<ffffffff8100c27c>] call_softirq+0x1c/0x30
> >> [<ffffffff8100e04d>] do_softirq+0x3d/0x80
> >> [<ffffffff81041b0b>] irq_exit+0x7b/0x90
> >> [<ffffffff8100d613>] do_IRQ+0x73/0xe0
> >> [<ffffffff8100bb13>] ret_from_intr+0x0/0xa
> >> <EOI> [<ffffffff81296e6c>] ? acpi_idle_enter_bm+0x245/0x271
> >> [<ffffffff81296e62>] ? acpi_idle_enter_bm+0x23b/0x271
> >> [<ffffffff813c7a08>] ? cpuidle_idle_call+0x98/0xf0
> >> [<ffffffff8100a104>] ? cpu_idle+0x94/0xd0
> >> [<ffffffff81468db6>] ? rest_init+0x66/0x70
> >> [<ffffffff816a082f>] ? start_kernel+0x2ef/0x340
> >> [<ffffffff8169fd54>] ? x86_64_start_reservations+0x84/0x90
> >> [<ffffffff8169fe32>] ? x86_64_start_kernel+0xd2/0x100
> >>
>
>
> Code: 00 eb 28 8b 83 d0 03 00 00
> 41 39 44 24 40 cmp %eax,0x40(%r12)
> 0f 89 00 01 00 00 jns ...
> 41 0f b6 cd movzbl %r13b,%ecx
> 41 bd 2f 00 00 00 mov $0x2f000000,%r13d
> 83 e1 03 and $0x3,%ecx
> 0f 84 fc 00 00 00 je ...
> 4d 8b 24 24 mov (%r12),%r12 skb = skb->next
> <>49 8b 04 24 mov (%r12),%rax << NULL POINTER dereference >>
> 4d 39 f4 cmp %r14,%r12
> 0f 18 08 prefetcht0 (%rax)
> 0f 84 d9 00 00 00 je ...
> 4c 3b a3 b8 01 cmp
>
>
> crash is in
> void tcp_xmit_retransmit_queue(struct sock *sk)
> {
>
> << HERE >> tcp_for_write_queue_from(skb, sk) {
>
> }
>
>
> Some skb in sk_write_queue has a NULL ->next pointer
>
> Strange thing is R14 and RAX =ffff8807e7420678 (&sk->sk_write_queue)
> R14 is the stable value during the loop, while RAW is scratch register.
>
> I dont have full disassembly for this function, but I guess we just
> entered the loop (or RAX should be really different at this point)
>
> So, maybe list head itself is corrupted (sk->sk_write_queue->next = NULL)
One more alternative along those lines could perhaps be:
We enter with empty write_queue there and with the hint being null, so we
take the else branch... and skb_peek then gives us the NULL ptr. However,
I cannot see how this could happen as all branches trap with return
before the reach tcp_xmit_retransmit_queue.
> or, retransmit_skb_hint problem ? (we forget to set it to NULL in some
> cases ?)
...I don't understand how a stale reference would yield to a consistent
NULL ptr crash there rather than hard to track corruption for most of the
times and random crashes then here and there. Or perhaps we were just very
lucky to immediately get only those reports which point out to the right
track :-).
...I tried to find what is wrong with it but sadly came up only
ah-this-is-it-oh-wait-it's-ok type of things.
--
i.
^ permalink raw reply
* Hello,
From: cecilia_oma @ 2009-10-29 12:41 UTC (permalink / raw)
Hi,
My name is miss Cecilia Oma, i saw your profile today and became intrested in you,please i want you to send a mail to my email address so that i can give you my picture for you to know whom i am.Here is my email address(ceciliaoma2love@yahoo.com) I believe we can move from here I am waiting for your fast respond.make sure you send me a
mail so that i will know you got my message.
thanks hoping to hear from you
Cecilia..
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 12:45 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <20091029.051509.119751790.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thursday 29 October 2009 13:15:09 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Thu, 29 Oct 2009 12:12:41 +0100
>
> > What is even more disappointing (especially after all that "working with"
> > preaching) is that the patch is now in net-next-2.6..
>
> John is the wireless maintainer, I take his tree in since the changes
> in there have his blessing.
>
> If you have a problem with some change in there, work it out with him
> and he'll send the fixed up changes to me thereafterwards.
What do you mean by that?
That *I* should be fixing the patch in question instead of the submitter?
Do some different rules apply in the networking than in other parts of
the kernel that I'm not aware of?
There were valid concerns raised on the initial rt2800pci patch submission,
yet two days later patch is in John's tree, after few more days it is in yours
tree and happily on his way into 2.6.33.
Until issues mentioned in:
http://lkml.org/lkml/2009/10/17/81
are addressed rt2800pci shouldn't be queued for Linus' tree.
[ Please note that this driver doesn't work at all currently so the standard
argument of having hardware support early upstream cannot be applied here. ]
--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 12:15 UTC (permalink / raw)
To: bzolnier-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <200910291212.41656.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Bartlomiej Zolnierkiewicz <bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 29 Oct 2009 12:12:41 +0100
> What is even more disappointing (especially after all that "working with"
> preaching) is that the patch is now in net-next-2.6..
John is the wireless maintainer, I take his tree in since the changes
in there have his blessing.
If you have a problem with some change in there, work it out with him
and he'll send the fixed up changes to me thereafterwards.
I don't really see what the big deal is, any change can be reverted.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* GRANT AWARD - 2009
From: grantnotification @ 2009-10-29 11:58 UTC (permalink / raw)
You have been choosen by the U.N Foundation to receive a grant donation of
$1,000 000.00USD.Your Qualification Numbers(G-999-747,UZ-900 77),Contact
Ewa Morgan with Name,Address,country for claim: fedilityclaimsagantdept@gmail.com
United Nations Foundation.
http://www.unfoundation.org/
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 11:12 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel, John W. Linville
In-Reply-To: <200910282256.00407.bzolnier@gmail.com>
On Wednesday 28 October 2009 22:56:00 Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 28 October 2009 22:10:32 John W. Linville wrote:
> > Dave,
> >
> > I let my patches pile-up! Yikes!!
> >
> > This request includes the usual ton of stuff for -next -- driver
> > updates, fixes for some earlier -next stuff, a few cfg80211 changes to
> > accomodate the libertas driver, etc. Of note is the rt2800pci support
> > added to the rt2x00 family.
>
> Unfortunately rt2800pci support is non-functioning at the moment... :(
>
> > Pleaset let me know if there are problems!
>
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..
>
> The way rt2800usb and rt2800pci drivers are designed really results
> in making the task of adding working support for RT28x0 and RT30x0
> chipsets to rt2x00 infrastructure more difficult and time consuming
> than it should be... :(
What is even more disappointing (especially after all that "working with"
preaching) is that the patch is now in net-next-2.6..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [PATCH 3/3] net: TCP thin dupack
From: Andreas Petlund @ 2009-10-29 10:48 UTC (permalink / raw)
To: William Allen Simpson
Cc: netdev, linux-kernel, shemminger, ilpo.jarvinen, davem
In-Reply-To: <4AE7AFC4.3040805@gmail.com>
Den 28. okt. 2009 kl. 03.43 skrev William Allen Simpson:
> Andreas Petlund wrote:
>> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
>> index e64368d..f4a05ff 100644
>> --- a/include/linux/tcp.h
>> +++ b/include/linux/tcp.h
>> @@ -97,6 +97,7 @@ enum {
>> #define TCP_CONGESTION 13 /* Congestion control algorithm */
>> #define TCP_MD5SIG 14 /* TCP MD5 Signature (RFC2385) */
>> #define TCP_THIN_RM_EXPB 15 /* Remove exp. backoff for
>> thin streams*/
>> +#define TCP_THIN_DUPACK 16 /* Fast retrans. after 1
>> dupack */
>>
> I've not had the chance to examine the rest, but I've been poking at a
> patch series that's used 15 for over a year, so could you try 16 and
> 17?
Thank you for the feedback. I will address this in the next patch
iteration.
^ permalink raw reply
* Re: [PATCH] net: fix kmemcheck annotations
From: Eric Dumazet @ 2009-10-29 10:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091029.031748.235701096.davem@davemloft.net>
David Miller a écrit :
>
> We may be trading size for performance here, I wonder if
> it's wise to move queue_mapping like that and what
> locality change we get as a result.
I agree, but could not convince me it makes a difference.
On 64bit arches, queue_mapping doesnt change its cache line location
(0xa4 -> 0xa8)
On 32bit arches, sizeof(sk_buf)=0xB0, rx and tx paths touch all
of 3 cache lines anyway.
Only thing I can think at this moment is to reorder skb so that TX
completion path dont touch all cache lines (putting together cb[]
and some not touched fields). We could probably gain one cache line miss.
It's a bit hard because of the next/prev fields that must
be first members of structure, but I believe you had some work in progress
in this area, to stick a standard list_head ?
^ permalink raw reply
* Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: David Miller @ 2009-10-29 10:43 UTC (permalink / raw)
To: B05799; +Cc: netdev, avorontsov
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950364@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Thu, 29 Oct 2009 16:03:30 +0530
> The PATCH v2 series applied cleanly to the above clone.
It absolutely does NOT!
And I just tried it again to verify this, and you can try it yourself:
http://vger.kernel.org/~davem/bundle-640.mbox
davem@sunset:~/src/GIT/net-next-2.6$ git am --signoff bundle-640.mbox
Applying: gianfar: Add per queue structure support
Applying: gianfar: Introduce logical group support.
Applying: gianfar: Add Multiple Queue Support
Applying: fsl_pq_mdio: Add Suport for etsec2.0 devices.
error: patch failed: drivers/net/fsl_pq_mdio.c:405
error: drivers/net/fsl_pq_mdio.c: patch does not apply
Patch failed at 0004 fsl_pq_mdio: Add Suport for etsec2.0 devices.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
davem@sunset:~/src/GIT/net-next-2.6$
So stop telling me it applies cleanly.
Because I've tried to do it multiple times and it absolutely does not.
^ permalink raw reply
* Re: [PATCH] Re: PACKET_TX_RING: packet size is too long
From: David Miller @ 2009-10-29 10:40 UTC (permalink / raw)
To: gombasg; +Cc: netdev, johann.baudy
In-Reply-To: <20091029102923.GA15314@boogie.lpds.sztaki.hu>
From: Gabor Gombas <gombasg@sztaki.hu>
Date: Thu, 29 Oct 2009 11:29:24 +0100
> On Thu, Oct 29, 2009 at 03:19:17AM -0700, David Miller wrote:
>
>> From: Gabor Gombas <gombasg@sztaki.hu>
>> Date: Thu, 15 Oct 2009 22:10:29 +0200
>>
>> > Currently PACKET_TX_RING forces certain amount of every frame to remain
>> > unused. This probably originates from an early version of the
>> > PACKET_TX_RING patch that in fact used the extra space when the (since
>> > removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
>> > code does not make any use of this extra space.
>> >
>> > This patch removes the extra space reservation and lets userspace make
>> > use of the full frame size.
>> >
>> > Signed-off-by: Gabor Gombas <gombasg@sztaki.hu>
>>
>> Applied, thanks!
>
> Thanks! Does it have a chance to be included in 2.6.32, or it is too
> late in the rc series?
It will be merged to Linus for 2.6.23
^ permalink raw reply
* RE: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-29 10:33 UTC (permalink / raw)
To: David Miller; +Cc: netdev, avorontsov
In-Reply-To: <20091029.031610.04742718.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Thursday, October 29, 2009 3:46 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev@vger.kernel.org; avorontsov@ru.mvista.com
>Subject: Re: [PATCH v2 4/7] fsl_pq_mdio: Add Support for
>etsec2.0 devices.
>
>From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
>Date: Thu, 29 Oct 2009 15:41:22 +0530
>
>> This is the tree I generated the patches against initially.
>> The initial set of patches were generated against this tree:
>>
>(http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
>> )
>>
>> Can you please confirm that the above tree is correct.
>
>Yes.
Thank you. I cloned this tree again about 2 hours ago (and updated it 5
mins ago as well).
git describe:
v2.6.32-rc3-464-gb37b62f
The last commit is: b37b62fea1d1bf68ca51818f8eb1035188efd030
>
>> The patches sent by me applies cleanly to the above mentioned
>> net-next-2.6 tree.
>
>It may have applied cleanly when you sent them, but by the
>time I applied them it didn't.
The PATCH v2 series applied cleanly to the above clone.
>
>Resend a fresh patch set against a fresh net-next-2.6 checkout
>and let's see what happens :-)
Ok. But there is NO change to the patch set.
--
Thanks
Sandeep
^ permalink raw reply
* Re: [PATCH] Re: PACKET_TX_RING: packet size is too long
From: Gabor Gombas @ 2009-10-29 10:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, johann.baudy
In-Reply-To: <20091029.031917.255459167.davem@davemloft.net>
On Thu, Oct 29, 2009 at 03:19:17AM -0700, David Miller wrote:
> From: Gabor Gombas <gombasg@sztaki.hu>
> Date: Thu, 15 Oct 2009 22:10:29 +0200
>
> > Currently PACKET_TX_RING forces certain amount of every frame to remain
> > unused. This probably originates from an early version of the
> > PACKET_TX_RING patch that in fact used the extra space when the (since
> > removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
> > code does not make any use of this extra space.
> >
> > This patch removes the extra space reservation and lets userspace make
> > use of the full frame size.
> >
> > Signed-off-by: Gabor Gombas <gombasg@sztaki.hu>
>
> Applied, thanks!
Thanks! Does it have a chance to be included in 2.6.32, or it is too
late in the rc series?
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences,
---------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] Re: PACKET_TX_RING: packet size is too long
From: David Miller @ 2009-10-29 10:19 UTC (permalink / raw)
To: gombasg; +Cc: netdev, johann.baudy
In-Reply-To: <20091015201028.GA9780@boogie.lpds.sztaki.hu>
From: Gabor Gombas <gombasg@sztaki.hu>
Date: Thu, 15 Oct 2009 22:10:29 +0200
> Currently PACKET_TX_RING forces certain amount of every frame to remain
> unused. This probably originates from an early version of the
> PACKET_TX_RING patch that in fact used the extra space when the (since
> removed) CONFIG_PACKET_MMAP_ZERO_COPY option was enabled. The current
> code does not make any use of this extra space.
>
> This patch removes the extra space reservation and lets userspace make
> use of the full frame size.
>
> Signed-off-by: Gabor Gombas <gombasg@sztaki.hu>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] net: fix kmemcheck annotations
From: David Miller @ 2009-10-29 10:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE96A1D.8050300@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Oct 2009 11:10:37 +0100
> @@ -367,7 +367,6 @@ struct sk_buff {
> #endif
>
> int iif;
> - __u16 queue_mapping;
> #ifdef CONFIG_NET_SCHED
> __u16 tc_index; /* traffic control index */
> #ifdef CONFIG_NET_CLS_ACT
> @@ -376,6 +375,7 @@ struct sk_buff {
> #endif
>
> kmemcheck_bitfield_begin(flags2);
> + __u16 queue_mapping:16;
> #ifdef CONFIG_IPV6_NDISC_NODETYPE
> __u8 ndisc_nodetype:2;
> #endif
We may be trading size for performance here, I wonder if
it's wise to move queue_mapping like that and what
locality change we get as a result.
^ permalink raw reply
* Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: David Miller @ 2009-10-29 10:16 UTC (permalink / raw)
To: B05799; +Cc: netdev, avorontsov
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B95035E@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Thu, 29 Oct 2009 15:41:22 +0530
> This is the tree I generated the patches against initially.
> The initial set of patches were generated against this tree:
> (http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git)
>
> Can you please confirm that the above tree is correct.
Yes.
> The patches sent by me applies cleanly to the above mentioned
> net-next-2.6 tree.
It may have applied cleanly when you sent them, but by the
time I applied them it didn't.
Resend a fresh patch set against a fresh net-next-2.6 checkout
and let's see what happens :-)
^ permalink raw reply
* RE: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-29 10:11 UTC (permalink / raw)
To: netdev; +Cc: avorontsov, David Miller
In-Reply-To: <20091029.024546.90958594.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Thursday, October 29, 2009 3:16 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev@vger.kernel.org; avorontsov@ru.mvista.com
>Subject: Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for
>etsec2.0 devices.
>
>From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
>Date: Thu, 29 Oct 2009 15:02:44 +0530
>
>> The absence of the above mentioned commit in the
>net-next-2.6 tree is
>> causing some issues with patches getting applied.
>
>You should never use linux-next as you base for working
>against other people's trees.
>
>Instead, clone net-next-2.6 and work purely against that when
>sending me patches.
This is the tree I generated the patches against initially.
The initial set of patches were generated against this tree:
(http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git)
Can you please confirm that the above tree is correct.
After you reported the failure,
I merged against the linux-next tree, therein I too got a similar
failure.
The reason being the commit from Anton present in linux-next and absent
on net-next.
The patches sent by me applies cleanly to the above mentioned
net-next-2.6 tree.
--
Thanks
Sandeep
^ permalink raw reply
* [PATCH] net: fix kmemcheck annotations
From: Eric Dumazet @ 2009-10-29 10:10 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
struct sk_buff kmemcheck annotations enlarged this structure by 8/16 bytes
Fix this by moving 'protocol' inside flags1 bitfield,
and queue_mapping inside flags2 bitfield.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 0c68fbd..defd51d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -354,8 +354,8 @@ struct sk_buff {
ipvs_property:1,
peeked:1,
nf_trace:1;
+ __be16 protocol:16;
kmemcheck_bitfield_end(flags1);
- __be16 protocol;
void (*destructor)(struct sk_buff *skb);
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
@@ -367,7 +367,6 @@ struct sk_buff {
#endif
int iif;
- __u16 queue_mapping;
#ifdef CONFIG_NET_SCHED
__u16 tc_index; /* traffic control index */
#ifdef CONFIG_NET_CLS_ACT
@@ -376,6 +375,7 @@ struct sk_buff {
#endif
kmemcheck_bitfield_begin(flags2);
+ __u16 queue_mapping:16;
#ifdef CONFIG_IPV6_NDISC_NODETYPE
__u8 ndisc_nodetype:2;
#endif
^ permalink raw reply related
* Re: nfs broken in net-next?
From: Yinghai Lu @ 2009-10-29 10:03 UTC (permalink / raw)
To: Suresh Jayaraman; +Cc: David Miller, Linux Kernel Mailing List, NetDev
In-Reply-To: <4AE9430B.3060105@suse.de>
On Thu, Oct 29, 2009 at 12:23 AM, Suresh Jayaraman <sjayaraman@suse.de> wrote:
> On 10/29/2009 01:43 AM, Yinghai Lu wrote:
>> pk12-3214-189-102:~ # mount -t nfs 10.6.75.100:/data/shared/pxeboot /x
>> mount.nfs: rpc.statd is not running but is required for remote locking.
>> mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
>
> rpc.statd on client should have be started by mount.nfs when a nfs
> filesystem is mounted. Is this not happening for some reason or do you
> see any errors in syslog?
>
>>
>> using opensuse11.1
>>
>
> Are you using 11.1 betas? I know of a problem where non-root user mounts
> fail to start rpc.statd in betas that got fixed later:
>
> http://marc.info/?l=linux-nfs&m=122748525624094&w=2
>
> Is the problem seen only recently (after updating to net-next)?
>
only happen with net-next.
linus tree and tip tree are ok.
YH
^ permalink raw reply
* Re: [RFC] net,socket: introduce build_sockaddr_check helper to catch overflow at build time
From: David Miller @ 2009-10-29 10:00 UTC (permalink / raw)
To: gorcunov; +Cc: netdev
In-Reply-To: <20091024163226.GA5204@lenovo>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Sat, 24 Oct 2009 20:32:26 +0400
> net,socket: introduce DECLARE_SOCKADDR helper to catch overflow at build time
>
> proto_ops->getname implies copying protocol specific data
> into storage unit (particulary to __kernel_sockaddr_storage).
> So when we implement new protocol support we should keep such
> a detail in mind (which is easy to forget about).
>
> Lets introduce DECLARE_SOCKADDR helper which check if
> storage unit is not overfowed at build time.
>
> Eventually inet_getname is switched to use DECLARE_SOCKADDR
> (to show example of usage).
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
I like this, applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: David Miller @ 2009-10-29 9:45 UTC (permalink / raw)
To: B05799; +Cc: netdev, avorontsov
In-Reply-To: <9F4C7D19E8361D4C94921B95BE08B81B950352@zin33exm22.fsl.freescale.net>
From: "Kumar Gopalpet-B05799" <B05799@freescale.com>
Date: Thu, 29 Oct 2009 15:02:44 +0530
> The absence of the above mentioned commit in the net-next-2.6 tree
> is causing some issues with patches getting applied.
You should never use linux-next as you base for working against
other people's trees.
Instead, clone net-next-2.6 and work purely against that when sending
me patches.
^ permalink raw reply
* RE: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: Kumar Gopalpet-B05799 @ 2009-10-29 9:32 UTC (permalink / raw)
To: netdev; +Cc: David Miller, avorontsov
In-Reply-To: <20091028.024325.134189895.davem@davemloft.net>
>-----Original Message-----
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Wednesday, October 28, 2009 3:13 PM
>To: Kumar Gopalpet-B05799
>Cc: netdev@vger.kernel.org
>Subject: Re: [PATCH v2 4/7] fsl_pq_mdio: Add Suport for
>etsec2.0 devices.
>
>From: Sandeep Gopalpet <sandeep.kumar@freescale.com>
>Date: Tue, 27 Oct 2009 22:25:18 +0530
>
>> This patch adds mdio support for etsec2.0 devices.
>>
>> Modified the fsl_pq_mdio structure to include the new mdio members.
>>
>> Signed-off-by: Sandeep Gopalpet <sandeep.kumar@freescale.com>
>
>This is the third time you've submitted this patch, and for
>the third time it DOES NOT apply to net-next-2.6 at all when I
>try to apply this gianfar patch series.
>
>You must be patching against another tree that has some
>changes that conflict with this one.
>
>Sort this out before submitting this again.
>
>If you submit once more this same series, and it doesn't apply
>properly to net-next-2.6, I will flat our ignore your
>submissions for a week or so.
>
>You are wasting that much of my time by doing this over and over.
>
>Get your act together.
>
>
Hi All,
I couldn't find the following commit on the net-next-2.6 tree:
commit e72701acbe0b35e52d3f04d442837c06b4e64f1c
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Date: Wed Oct 14 14:54:52 2009 -0700
net: Fix OF platform drivers coldplug/hotplug when compiled as
modules
Some OF platform drivers are missing module device tables, so they
won't
load automatically on boot. This patch fixes the issue by adding
proper
MODULE_DEVICE_TABLE() macros to the drivers.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The same commit is present on the linux-next tree
I cloned the 2 trees from the following links:
linux-next from:
http://www.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git/
And net-next-2.6 from:
http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
The absence of the above mentioned commit in the net-next-2.6 tree is
causing
some issues with patches getting applied.
Can you let me know if the net-next-2.6 tree that I am cloning is the
proper one ?
I based all my patches on net-next-2.6 tree cloned from the above link.
But some how when David tries to apply
my patches they fail. I took a diff at the linux-next and net-next-2.6
and the said commit is missing.
-Thanks
Sandeep
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox