[PATCH 4/6] [FCoE] hash for fc_local_port: do not use sa_hash_xxx
1. Add hash table/funcs for fc_local_port
2. Remove association with vf_lport_by_fid in fc_virt_fab
3. Remove references to sa_hash_xxx
Signed-off-by: Yi Zou [EMAIL PROTECTED]
---
drivers/scsi/ofc/libfc/fc_local_port.c | 184 +--
drivers/scsi/ofc/libfc/fc_local_port_impl.h |3
2 files changed, 117 insertions(+), 70 deletions(-)
diff --git a/drivers/scsi/ofc/libfc/fc_local_port.c
b/drivers/scsi/ofc/libfc/fc_local_port.c
index 5f28f4a..2a3c256 100644
--- a/drivers/scsi/ofc/libfc/fc_local_port.c
+++ b/drivers/scsi/ofc/libfc/fc_local_port.c
@@ -28,7 +28,6 @@
#include net_types.h
#include ofc_dbg.h
#include sa_event.h
-#include sa_hash.h
#include fc_fs.h
#include fc_gs.h
@@ -92,6 +91,109 @@ static void fc_local_port_port_event(int, void *);
static void fc_local_port_set_fid_int(struct fc_local_port *, fc_fid_t);
static void fc_local_port_gid_pn_error(enum fc_event, void *arg);
+/*
+ * Hash table size for local port
+ */
+#define FC_HASH_LPORT_SHIFT3
+#define FC_HASH_LPORT_BUCKETS (1UL FC_HASH_LPORT_SHIFT)
+#define FC_HASH_LPORT_MASK (FC_HASH_LPORT_BUCKETS - 1)
+
+static u_int32_t lport_hash_entries;
+static struct hlist_head lport_hash_table[FC_HASH_LPORT_BUCKETS];
+
+/**
+ * fc_local_port_match - the compare function for hash lookup
+ * @fid: the ptr to fcid as the input
+ * @lp:the ptr to the local port to be matched
+ */
+static inline int fc_local_port_match(const fc_fid_t *fid,
+ const struct fc_local_port *lp)
+{
+ return *fid == lp-fl_fid;
+}
+
+/**
+ * fc_local_port_hash - a simple hash function of fcid
+ * @fid: the ptr to a given fcid
+ */
+static inline u_int32_t fc_local_port_hash(const fc_fid_t *fid)
+{
+ return (((*fid) 8) ^ (*fid)) FC_HASH_LPORT_MASK;
+}
+
+/**
+ * fc_local_port_hash_lookup - lookup the hash table
+ * @fid: the ptr to a given fcid as key
+ *
+ * caller should acquire the lock appropriately, use RCU lock if
+ * no write, otherwise use spinlock such as vf_lock before calling.
+ */
+static inline struct fc_local_port *fc_local_port_hash_lookup(
+ const fc_fid_t *fid)
+{
+ struct hlist_node *node;
+ struct hlist_head *head;
+ struct fc_local_port *lp;
+
+ head = lport_hash_table[fc_local_port_hash(fid)];
+ hlist_for_each_entry_rcu(lp, node, head, fl_hash_link)
+ if (fc_local_port_match(fid, lp))
+ return lp;
+ return NULL;
+}
+
+/**
+ * fc_local_port_hash_delete - remove the local port from the hash table
+ * @lp:the ptr to the local port to be removed
+ *
+ * caller should acquire the lock before calling, e.g. vf_lock.
+ */
+static inline void fc_local_port_hash_delete(const struct fc_local_port *lp)
+{
+ hlist_del_rcu((struct hlist_node *)lp-fl_hash_link);
+ lport_hash_entries--;
+}
+
+/**
+ * fc_local_port_hash_insert - remove the local port from the hash table
+ * @lp:the ptr to the local port to be removed
+ *
+ * caller should acquire the lock before calling, e.g. vf_lock.
+ */
+static inline void fc_local_port_hash_insert(const struct fc_local_port *lp)
+{
+ struct hlist_head *head;
+
+ head = lport_hash_table[fc_local_port_hash(lp-fl_fid)];
+ hlist_add_head_rcu((struct hlist_node *)lp-fl_hash_link, head);
+ lport_hash_entries++;
+}
+
+/**
+ * fc_local_port_hash_init - initalize the hlist_head for each bucket
+ */
+static void fc_local_port_hash_init(void)
+{
+ int loop;
+ for (loop = 0; loop FC_HASH_LPORT_BUCKETS; loop++)
+ INIT_HLIST_HEAD(lport_hash_table[loop]);
+ lport_hash_entries = 0;
+}
+
+int fc_local_port_table_create(struct fc_virt_fab *vf)
+{
+ fc_local_port_hash_init();
+ INIT_LIST_HEAD(vf-vf_local_ports);
+ return 0;
+}
+
+void fc_local_port_table_destroy(struct fc_virt_fab *vf)
+{
+ WARN_ON(!list_empty(vf-vf_local_ports));
+ fc_local_port_hash_init();
+ INIT_LIST_HEAD(vf-vf_local_ports);
+}
+
static inline void fc_local_port_enter_state(struct fc_local_port *lp,
enum fc_local_port_state state)
{
@@ -225,20 +327,6 @@ static void fc_local_port_retry(struct fc_local_port *lp)
}
/*
- * Declare hash table type for lookup by FCID.
- */
-#define FC_LOCAL_PORT_HASH_SIZE 8 /* smallish for now */
-
-static int fc_local_port_fid_match(sa_hash_key_t, void *);
-static u_int32_t fc_local_port_fid_hash(sa_hash_key_t);
-
-static struct sa_hash_type fc_local_port_hash_by_fid = {
- .st_link_offset = offsetof(struct fc_local_port, fl_hash_link),
- .st_match = fc_local_port_fid_match,
- .st_hash = fc_local_port_fid_hash,
-};
-
-/*
* Return max segment size for local port.
*/
static u_int fc_local_port_mfs(struct fc_local_port *lp)
@@ -842,29 +930,6 @@ static void fc_local_port_enter_logo(struct fc_local_port
*lp)
fc_local_port_els_send(lp, sp, fp);
}
-int
[PATCH 1/6] [FCoE] Fix the openfc Makefile to build as included in kernel
The current build for openfc will fail as it only builds as module. Signed-off-by: Yi Zou [EMAIL PROTECTED] --- drivers/scsi/ofc/openfc/Makefile | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/ofc/openfc/Makefile b/drivers/scsi/ofc/openfc/Makefile index 00606a2..9309266 100644 --- a/drivers/scsi/ofc/openfc/Makefile +++ b/drivers/scsi/ofc/openfc/Makefile @@ -9,7 +9,10 @@ openfc-y := \ openfc_if.o \ openfc_ioctl.o \ openfc_pkt.o \ - openfc_scsi.o \ - ../libfc/libfc.o \ - ../libsa/libsa.o \ - ../libcrc/libcrc.o + openfc_scsi.o + +ifeq ($(CONFIG_OFC),m) + openfc-y += ../libfc/libfc.o \ + ../libsa/libsa.o \ + ../libcrc/libcrc.o +endif - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] [FCoE] hash for fc_sess: do not use sa_hash_xxx
1. Add hash table/funcs for fc_sess
2. Remove association with vf_sess_by_fids in fc_virt_fab
4. Remove refrences to sa_hash_xxx
Signed-off-by: Yi Zou [EMAIL PROTECTED]
---
drivers/scsi/ofc/include/fc_sess.h|2
drivers/scsi/ofc/libfc/fc_sess.c | 226 +++--
drivers/scsi/ofc/libfc/fc_sess_impl.h |2
3 files changed, 162 insertions(+), 68 deletions(-)
diff --git a/drivers/scsi/ofc/include/fc_sess.h
b/drivers/scsi/ofc/include/fc_sess.h
index d0b4f73..5684a18 100644
--- a/drivers/scsi/ofc/include/fc_sess.h
+++ b/drivers/scsi/ofc/include/fc_sess.h
@@ -81,6 +81,8 @@ static inline u_int64_t fc_sess_key(fc_fid_t local, fc_fid_t
remote)
int fc_sess_table_create(struct fc_virt_fab *);
void fc_sess_table_destroy(struct fc_virt_fab *);
+struct fc_sess *fc_sess_hash_lookup(const u_int64_t *key);
+
/*
* Lookup or create a new session.
*/
diff --git a/drivers/scsi/ofc/libfc/fc_sess.c b/drivers/scsi/ofc/libfc/fc_sess.c
index 1eb3bc3..4e4acfd 100644
--- a/drivers/scsi/ofc/libfc/fc_sess.c
+++ b/drivers/scsi/ofc/libfc/fc_sess.c
@@ -32,7 +32,6 @@
#include ofc_dbg.h
#include sa_event.h
-#include sa_hash.h
#include fc_fs.h
#include fc_els.h
@@ -64,20 +63,6 @@
static int fc_sess_debug;
/*
- * Declare hash type for lookup of session by local and remote FCID.
- */
-#defineFC_SESS_HASH_SIZE 32 /* XXX increase later */
-
-static int fc_sess_match(const sa_hash_key_t, void *);
-static u_int32_t fc_sess_hash(const sa_hash_key_t);
-
-static struct sa_hash_type fc_sess_hash_type = {
- .st_link_offset = offsetof(struct fc_sess, fs_hash_link),
- .st_match = fc_sess_match,
- .st_hash = fc_sess_hash,
-};
-
-/*
* static functions.
*/
static void fc_sess_enter_init(struct fc_sess *);
@@ -99,6 +84,157 @@ static void fc_sess_recv_logo_req(struct fc_sess *,
struct fc_seq *, struct fc_frame *);
static void fc_sess_delete(struct fc_sess *, void *);
static void fc_sess_timeout(unsigned long);
+static void fc_sess_iterate(struct fc_virt_fab *vf,
+ void (*func) (struct fc_sess *, void *), void *arg);
+
+static void fc_sess_debug_print(void *sess_arg, void *arg);
+
+/*
+ * Hash table size for session
+ */
+#define FC_HASH_SESS_SHIFT 5
+#define FC_HASH_SESS_BUCKETS (1UL FC_HASH_SESS_SHIFT)
+#define FC_HASH_SESS_MASK (FC_HASH_SESS_BUCKETS - 1)
+
+static u_int32_t sess_hash_entries;
+static struct hlist_head sess_hash_table[FC_HASH_SESS_BUCKETS];
+
+/**
+ * fc_sess_hash_match - session hash table match functio
+ * @key: the ptr to the key for match up compare
+ * @sess: the ptr to the fc_sess structure
+ */
+static inline int fc_sess_hash_match(const u_int64_t *key,
+ struct fc_sess *sess)
+{
+ return *key == fc_sess_key(sess-fs_local_fid, sess-fs_remote_fid);
+}
+
+/**
+ * fc_sess_hash - session hash table hash functio
+ * @key: the ptr to the key doing the hash
+ */
+static inline u_int32_t fc_sess_hash(const u_int64_t *key)
+{
+ return ((u_int32_t) (((*key) 20) ^ (*key))) FC_HASH_SESS_MASK;
+}
+
+/**
+ * fc_sess_hash_delete - remove the give session from the hash table
+ * @key: the ptr to the key for match up compare
+ * @sess: the ptr to the fc_sess structure
+ *
+ * caller should aquire the lock before calling. use vf_lock.
+ */
+static inline void fc_sess_hash_delete(const struct fc_sess *sess,
+ struct fc_virt_fab *vf)
+{
+ hlist_del_rcu((struct hlist_node *)sess-fs_hash_link);
+ sess_hash_entries--;
+}
+
+/**
+ * fc_sess_hash_insert - session hash table match functio
+ * @key: the ptr to the key for match up compare
+ * @sess: the ptr to the fc_sess structure
+ *
+ * caller should aquire the lock before calling. use vf_lock.
+ */
+static inline void fc_sess_hash_insert(const u_int64_t *key,
+ const struct fc_sess *sess,
+ struct fc_virt_fab *vf)
+{
+ struct hlist_head *head;
+
+ head = sess_hash_table[fc_sess_hash(key)];
+ hlist_add_head_rcu((struct hlist_node *)sess-fs_hash_link, head);
+ sess_hash_entries++;
+}
+
+/**
+ * fc_sess_hash_lookup - Lookup the session hash table by key.
+ * @key: ptr to the key to hash bucket
+ *
+ * the caller should acquire either RCU lock for read or spinlock
+ * e.g., vf_lock, for write before calling.
+ */
+inline struct fc_sess *fc_sess_hash_lookup(const u_int64_t *key)
+{
+ struct hlist_node *node;
+ struct hlist_head *head;
+ struct fc_sess *sess;
+
+ head = sess_hash_table[fc_sess_hash(key)];
+ hlist_for_each_entry_rcu(sess, node, head, fs_hash_link)
+ if (fc_sess_hash_match(key, sess))
+ return sess;
+ return NULL;
+}
+
+/**
+ * fc_sess_hash_iterate - iterate all items in all buckets of hash table
+ * @callback: callback function for iterator
+ * @arg: the arg to be passed to callback as the 2nd arg
+ *
+ * this function uses RCU lock so the
[PATCH 5/6] [FCoE] remove hash tables from fc_virt_fab
Remove vf_rport_by_fid, vf_rport_by_wwn, vf_lport_by_fid, vf_sess_by_fids
in struct fc_virt_fab of fc_virt_fab_impl.h
Signed-off-by: Yi Zou [EMAIL PROTECTED]
---
drivers/scsi/ofc/libfc/fc_virt_fab_impl.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ofc/libfc/fc_virt_fab_impl.h
b/drivers/scsi/ofc/libfc/fc_virt_fab_impl.h
index e19714a..51d4543 100644
--- a/drivers/scsi/ofc/libfc/fc_virt_fab_impl.h
+++ b/drivers/scsi/ofc/libfc/fc_virt_fab_impl.h
@@ -23,10 +23,6 @@
struct fc_virt_fab {
uintvf_tag; /* virtual fabric tag (or zero) */
struct list_head vf_remote_ports; /* remote ports */
- struct sa_hash *vf_rport_by_fid; /* remote ports by FCID */
- struct sa_hash *vf_rport_by_wwpn; /* remote ports by WWPN */
- struct sa_hash *vf_lport_by_fid; /* local ports by FCID */
- struct sa_hash *vf_sess_by_fids; /* sessions by FCID pairs */
struct list_head vf_local_ports;/* list of local ports */
struct fc_exch_mgr *vf_exch_mgr;/* exchange mgr for fabric */
spinlock_t vf_lock;/* lock for all tables and lists */
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] [FCoE] remove sa_hash_kern.c/sa_hash.h
1. Remove libsa/sa_hash_kern.c
2. Remove include/sa_hash.h
3. Remove all references to sa_hash_xxx
4. Update Makefile accordingly in libsa
Signed-off-by: Yi Zou [EMAIL PROTECTED]
---
drivers/scsi/ofc/include/sa_hash.h| 65 ---
drivers/scsi/ofc/libfc/fc_exch.c |1
drivers/scsi/ofc/libfc/fc_sess_impl.h |1
drivers/scsi/ofc/libsa/Makefile |4 -
drivers/scsi/ofc/libsa/sa_hash_kern.c | 141 -
5 files changed, 1 insertions(+), 211 deletions(-)
delete mode 100644 drivers/scsi/ofc/include/sa_hash.h
delete mode 100644 drivers/scsi/ofc/libsa/sa_hash_kern.c
diff --git a/drivers/scsi/ofc/include/sa_hash.h
b/drivers/scsi/ofc/include/sa_hash.h
deleted file mode 100644
index d4ee6be..000
--- a/drivers/scsi/ofc/include/sa_hash.h
+++ /dev/null
@@ -1,65 +0,0 @@
-/*
- * Copyright(c) 2007 Intel Corporation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.,
- * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
- *
- * Maintained at www.Open-FCoE.org
- */
-
-#ifndef _LIBSA_HASH_H_
-#define _LIBSA_HASH_H_
-
-#include linux/list.h
-
-/*
- * Hash table facility.
- */
-struct sa_hash;
-
-/*
- * Hash key value.
- */
-typedef void * sa_hash_key_t; /* pointer hash key */
-typedef u_int32_t sa_hash_key32_t;/* fixed-size 32-bit hash key */
-
-struct sa_hash_type {
- u_int16_t st_link_offset; /* offset of linkage in the element */
- int (*st_match)(const sa_hash_key_t, void *elem);
- u_int32_t (*st_hash)(const sa_hash_key_t);
-};
-
-/*
- * Element linkage on the hash.
- * The collision list is circular.
- */
-#define sa_hash_linkhlist_node
-
-struct sa_hash *sa_hash_create(const struct sa_hash_type *, u_int32_t size);
-
-void sa_hash_destroy(struct sa_hash *);
-
-void *sa_hash_lookup(struct sa_hash *, const sa_hash_key_t);
-
-void sa_hash_insert(struct sa_hash *, const sa_hash_key_t, void *elem);
-
-void sa_hash_insert_next(struct sa_hash *, sa_hash_key32_t *,
-sa_hash_key32_t min_key, sa_hash_key32_t max_key,
-void *elem);
-
-void *sa_hash_lookup_delete(struct sa_hash *, const sa_hash_key_t);
-
-void sa_hash_iterate(struct sa_hash *,
- void (*callback)(void *entry, void *arg), void *arg);
-
-#endif /* _LIBSA_HASH_H_ */
diff --git a/drivers/scsi/ofc/libfc/fc_exch.c b/drivers/scsi/ofc/libfc/fc_exch.c
index db67d98..1ceab9c 100644
--- a/drivers/scsi/ofc/libfc/fc_exch.c
+++ b/drivers/scsi/ofc/libfc/fc_exch.c
@@ -27,7 +27,6 @@
#include sa_kernel.h
#include net_types.h
#include ofc_dbg.h
-#include sa_hash.h
#include fc_fcip.h
#include fc_fc2.h
diff --git a/drivers/scsi/ofc/libfc/fc_sess_impl.h
b/drivers/scsi/ofc/libfc/fc_sess_impl.h
index c600186..84befab 100644
--- a/drivers/scsi/ofc/libfc/fc_sess_impl.h
+++ b/drivers/scsi/ofc/libfc/fc_sess_impl.h
@@ -22,7 +22,6 @@
#include linux/timer.h
#include fc_exch.h
-#include sa_hash.h
#include linux/rcupdate.h
diff --git a/drivers/scsi/ofc/libsa/Makefile b/drivers/scsi/ofc/libsa/Makefile
index 3453608..fa6da75 100644
--- a/drivers/scsi/ofc/libsa/Makefile
+++ b/drivers/scsi/ofc/libsa/Makefile
@@ -4,6 +4,4 @@ EXTRA_CFLAGS += -I$(OFC_DIR)/include
obj-y += libsa.o
-libsa-y := \
- sa_event.o \
- sa_hash_kern.o
+libsa-y := sa_event.o
diff --git a/drivers/scsi/ofc/libsa/sa_hash_kern.c
b/drivers/scsi/ofc/libsa/sa_hash_kern.c
deleted file mode 100644
index f1103a5..000
--- a/drivers/scsi/ofc/libsa/sa_hash_kern.c
+++ /dev/null
@@ -1,141 +0,0 @@
-/*
- * Copyright(c) 2007 Intel Corporation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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.,
- * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
- *
- * Maintained at www.Open-FCoE.org
- */
-
-#include sa_kernel.h
-#include
[PATCH 2/6] [FCoE] hash for fc_remote_port: do not use sa_hash_xxx
1. Add hash table/funcs for fc_remote_port
2. Remove association with vf_rport_by_fid in fc_virt_fab
3. Remove association with vf_rport_by_wwpn in fc_virt_fab
4. Remove references to sa_hash_xxx
Signed-off-by: Yi Zou [EMAIL PROTECTED]
---
drivers/scsi/ofc/include/fc_remote_port.h |5
drivers/scsi/ofc/libfc/fc_remote_port.c | 387 +++--
2 files changed, 254 insertions(+), 138 deletions(-)
diff --git a/drivers/scsi/ofc/include/fc_remote_port.h
b/drivers/scsi/ofc/include/fc_remote_port.h
index 07b20fb..a2d294f 100644
--- a/drivers/scsi/ofc/include/fc_remote_port.h
+++ b/drivers/scsi/ofc/include/fc_remote_port.h
@@ -21,7 +21,6 @@
#define _LIBFC_REMOTE_PORT_H_
#include sa_kernel.h
-#include sa_hash.h
/*
* Fibre Channel Remote Ports.
@@ -46,8 +45,8 @@ struct fc_remote_port {
void*rp_client_priv; /* HBA driver private data */
void*rp_fcs_priv; /* FCS driver private data */
struct sa_event_list *rp_events; /* event list */
- struct sa_hash_link rp_fid_hash_link;
- struct sa_hash_link rp_wwpn_hash_link;
+ struct hlist_node rp_fid_hash_link;
+ struct hlist_node rp_wwpn_hash_link;
/*
* For now, there's just one session per remote port.
diff --git a/drivers/scsi/ofc/libfc/fc_remote_port.c
b/drivers/scsi/ofc/libfc/fc_remote_port.c
index b0061f5..9d48e8e 100644
--- a/drivers/scsi/ofc/libfc/fc_remote_port.c
+++ b/drivers/scsi/ofc/libfc/fc_remote_port.c
@@ -27,7 +27,6 @@
#include sa_kernel.h
#undef LIST_HEAD
#include sa_event.h
-#include sa_hash.h
#include ofc_dbg.h
#include fc_types.h
@@ -36,71 +35,246 @@
#include fc_virt_fab_impl.h
/*
- * Declare hash table type for lookup by FCID.
+ * Hash table size for remote port
*/
-#defineFC_REMOTE_PORT_HASH_SIZE32 /* XXX smallish for now
*/
+#define FC_HASH_RPORT_SHIFT3
+#define FC_HASH_RPORT_BUCKETS (1UL FC_HASH_RPORT_SHIFT)
+#define FC_HASH_RPORT_MASK (FC_HASH_RPORT_BUCKETS - 1)
-static int fc_remote_port_fid_match(sa_hash_key_t, void *);
-static u_int32_t fc_remote_port_fid_hash(sa_hash_key_t);
+static u_int32_t rport_fid_entries;
+static struct hlist_head rport_fid_hash[FC_HASH_RPORT_BUCKETS];
-static struct sa_hash_type fc_remote_port_hash_by_fid = {
- .st_link_offset = offsetof(struct fc_remote_port, rp_fid_hash_link),
- .st_match = fc_remote_port_fid_match,
- .st_hash = fc_remote_port_fid_hash,
-};
+/**
+ * fc_remote_port_fid_match - the compare function by fcid
+ * @fid: the ptr to fcid as the input
+ * @rp:the ptr to the remote port to be matched
+ */
+static inline int fc_remote_port_fid_match(const fc_fid_t *fid,
+ const struct fc_remote_port *rp)
+{
+ return *fid == rp-rp_fid;
+}
-#ifdef FC_REMOTE_PORT_BY_WWPN
-/*
- * Declare hash table type for lookup by WWPN.
+/**
+ * fc_remote_port_fid_hash - hash remote port by fcid
+ * @fid: the ptr to fcid as the input
+ *
+ * this hash currently does nothing but return directly
*/
-static int fc_remote_port_wwpn_match(sa_hash_key_t, void *);
-static u_int32_t fc_remote_port_wwpn_hash(sa_hash_key_t);
-
-static struct sa_hash_type fc_remote_port_hash_by_wwpn = {
- .st_link_offset = offsetof(struct fc_remote_port, rp_wwpn_hash_link),
- .st_match = fc_remote_port_wwpn_match,
- .st_hash = fc_remote_port_wwpn_hash,
-};
-#endif /* FC_REMOTE_PORT_BY_WWPN */
+static inline u_int32_t fc_remote_port_fid_hash(const fc_fid_t *fid)
+{
+ return (*fid) FC_HASH_RPORT_MASK;
+}
-int fc_remote_port_table_create(struct fc_virt_fab *vp)
+/**
+ * fc_remote_port_fid_hash_lookup - lookup a remote port by fcid
+ * @fid: the ptr to the fc id as key for lookup
+ *
+ * the caller should should acquire appropriate lock before calling.
+ * use rcu_read_lock/unlock for read, use fc_virt_fab_lock/unlock
+ * for write.
+ */
+static inline struct fc_remote_port *fc_remote_port_fid_hash_lookup(
+ const fc_fid_t *fid)
{
+ struct hlist_node *node;
+ struct hlist_head *head;
+ struct fc_remote_port *rp;
- INIT_LIST_HEAD(vp-vf_remote_ports);
+ head = rport_fid_hash[fc_remote_port_fid_hash(fid)];
+ hlist_for_each_entry_rcu(rp, node, head, rp_fid_hash_link)
+ if (fc_remote_port_fid_match(fid, rp))
+ return rp;
+ return NULL;
+}
- vp-vf_rport_by_fid = sa_hash_create(fc_remote_port_hash_by_fid,
-FC_REMOTE_PORT_HASH_SIZE);
+/**
+ * fc_remote_port_fid_hash_delete - delete the remote port from the fcid hash
+ * @rp:the ptr to the remote port to be deleted
+ *
+ * caller should acquire the lock before calling. use fc_virt_fab_lock/unlock.
+ */
+static inline void fc_remote_port_fid_hash_delete(
+ const struct fc_remote_port *rp)
+{
+ hlist_del_rcu((struct hlist_node *)rp-rp_fid_hash_link);
+ rport_fid_entries--;
+}
-
no INQUIRY from userspace please (was Re: [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE)
Mike Anderson wrote: A number of user apps like lvm scanning that execute media access commands already have filter capability to filter devices that one does not want to scan. Another class of device scanners just use inquiries which are not effected by the passive state (though some could probably use udevinfo and reduce the amount of repeated SCSI inquiries execute on the system. To expand on this: At least on desktop systems and SOHO server systems, userspace should _never_ issue INQUIRY. There are too many broken firmwares out there which assume that there will never be more than one INQUIRY sent. They start to return garbled data or crash if they get a second INQUIRY. -- Stefan Richter -=-==--- --=- --=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest git oopses during boot
On 2/7/08, Andrew Morton [EMAIL PROTECTED] wrote: (cc's restored, and expanded a bit) Ah, sorry, not used to gmail's web interface. Clicked the wrong button. Seems to be the advansys driver, so I tried to remove it - and indeed, the kernel now boots. So I guess it's either that driver or my ancient Nikon Coolscan II that is the only thing attached to the board. Thanks. I uploaded the oops picture to http://userweb.kernel.org/~akpm/oops.jpg Cc to the Matthew Wilcox added. mm... looks like all Matthew's changes were in 2.6.23. And 2.6.23 worked OK, yes? Both 2.6.23 and 2.6.24 are ok. The only recent changes to drivers/scsi/advansys.c are commit b80ca4f7ee36c26d300c5a8f429e73372d153379 Author: FUJITA Tomonori [EMAIL PROTECTED] Date: Sun Jan 13 15:46:13 2008 +0900 [SCSI] replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE This replaces sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE in several LLDs. It's a preparation for the future changes to remove sense_buffer array in scsi_cmnd structure. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Signed-off-by: James Bottomley [EMAIL PROTECTED] :100644 100644 9dd3952... 492702b... M drivers/scsi/advansys.c commit 747d016e7e25e216b31022fe2b012508d99fb682 Author: Randy Dunlap [EMAIL PROTECTED] Date: Mon Jan 14 00:55:18 2008 -0800 advansys: fix section mismatch warning Fix section mismatch warning: WARNING: vmlinux.o(.exit.text+0x152a): Section mismatch: reference to .init. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Cc: Matthew Wilcox [EMAIL PROTECTED] Cc: James Bottomley [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] which seem fairly benign. gcc inlining is going to make it rather a lot of work to find out which statement has actually oopsed there. -- Hilsen Harald - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest git oopses during boot
On Thu, Feb 07, 2008 at 12:14:56PM +0100, Harald Arnesen wrote: The only recent changes to drivers/scsi/advansys.c are commit b80ca4f7ee36c26d300c5a8f429e73372d153379 Author: FUJITA Tomonori [EMAIL PROTECTED] Date: Sun Jan 13 15:46:13 2008 +0900 [SCSI] replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE This replaces sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE in several LLDs. It's a preparation for the future changes to remove sense_buffer array in scsi_cmnd structure. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] Signed-off-by: James Bottomley [EMAIL PROTECTED] The sense buffer changes have cause a fair amount of trouble, so I'd look into this one for debugging the problem.. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
Since the focus of this thread shifted somewhat in the last few messages, I'll try to summarize what has been discussed so far: - There was a number of participants who joined this discussion spontaneously. This suggests that there is considerable interest in networked storage and iSCSI. - It has been motivated why iSCSI makes sense as a storage protocol (compared to ATA over Ethernet and Fibre Channel over Ethernet). - The direct I/O performance results for block transfer sizes below 64 KB are a meaningful benchmark for storage target implementations. - It has been discussed whether an iSCSI target should be implemented in user space or in kernel space. It is clear now that an implementation in the kernel can be made faster than a user space implementation (http://kerneltrap.org/mailarchive/linux-kernel/2008/2/4/714804). Regarding existing implementations, measurements have a.o. shown that SCST is faster than STGT (30% with the following setup: iSCSI via IPoIB and direct I/O block transfers with a size of 512 bytes). - It has been discussed which iSCSI target implementation should be in the mainstream Linux kernel. There is no agreement on this subject yet. The short-term options are as follows: 1) Do not integrate any new iSCSI target implementation in the mainstream Linux kernel. 2) Add one of the existing in-kernel iSCSI target implementations to the kernel, e.g. SCST or PyX/LIO. 3) Create a new in-kernel iSCSI target implementation that combines the advantages of the existing iSCSI kernel target implementations (iETD, STGT, SCST and PyX/LIO). As an iSCSI user, I prefer option (3). The big question is whether the various storage target authors agree with this ? Bart Van Assche. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] New: Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 Summary: Unable to handle kernel NULL pointer dereference at 0010 (mptsas_probe_expander_phys+0x62/0x427) Product: IO/Storage Version: 2.5 KernelVersion: 2.6.23 - 2.6.23.14 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: SCSI AssignedTo: linux-scsi@vger.kernel.org ReportedBy: [EMAIL PROTECTED] Latest working kernel version: 2.6.22-2.6.22.17 Distribution: Gentoo Hardware Environment: 00:00.0 Host bridge [0600]: Intel Corporation 5000X Chipset Memory Controller Hub [8086:25c0] (rev 12) 00:02.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 2 [8086:25e2] (rev 12) 00:03.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 3 [8086:25e3] (rev 12) 00:04.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 [8086:25f8] (rev 12) 00:05.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 5 [8086:25e5] (rev 12) 00:06.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 [8086:25f9] (rev 12) 00:07.0 PCI bridge [0604]: Intel Corporation 5000 Series Chipset PCI Express x4 Port 7 [8086:25e7] (rev 12) 00:08.0 System peripheral [0880]: Intel Corporation 5000 Series Chipset DMA Engine [8086:1a38] (rev 12) 00:10.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset FSB Registers [8086:25f0] (rev 12) 00:10.1 Host bridge [0600]: Intel Corporation 5000 Series Chipset FSB Registers [8086:25f0] (rev 12) 00:10.2 Host bridge [0600]: Intel Corporation 5000 Series Chipset FSB Registers [8086:25f0] (rev 12) 00:11.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset Reserved Registers [8086:25f1] (rev 12) 00:13.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset Reserved Registers [8086:25f3] (rev 12) 00:15.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset FBD Registers [8086:25f5] (rev 12) 00:16.0 Host bridge [0600]: Intel Corporation 5000 Series Chipset FBD Registers [8086:25f6] (rev 12) 00:1c.0 PCI bridge [0604]: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 [8086:2690] (rev 09) 00:1d.0 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 [8086:2688] (rev 09) 00:1d.1 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 [8086:2689] (rev 09) 00:1d.7 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller [8086:268c] (rev 09) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d9) 00:1f.0 ISA bridge [0601]: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller [8086:2670] (rev 09) 00:1f.1 IDE interface [0101]: Intel Corporation 631xESB/632xESB IDE Controller [8086:269e] (rev 09) 00:1f.2 IDE interface [0101]: Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller [8086:2680] (rev 09) 01:00.0 SCSI storage controller [0100]: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS [1000:0058] (rev 08) 02:00.0 PCI bridge [0604]: Broadcom EPB PCI-Express to PCI-X Bridge [1166:0103] (rev c3) 03:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet [14e4:164c] (rev 12) 04:00.0 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port [8086:3500] (rev 01) 04:00.3 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge [8086:350c] (rev 01) 05:00.0 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 [8086:3510] (rev 01) 05:01.0 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E2 [8086:3514] (rev 01) 06:00.0 PCI bridge [0604]: Broadcom EPB PCI-Express to PCI-X Bridge [1166:0103] (rev c3) 07:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet [14e4:164c] (rev 12) 0e:0d.0 VGA compatible controller [0300]: ATI Technologies Inc ES1000 [1002:515e] (rev 02) Software Environment: Gnu C 4.1.2 Gnu make 3.81 binutils Binutils util-linux 2.12r mount 2.12r module-init-tools 3.4 e2fsprogs 1.40.5 Linux C Library2.7 Dynamic linker (ldd) 2.7 Procps 3.2.7 Net-tools 1.60 Kbd1.13 Sh-utils 6.9 Attaching dmesg with oopses (2.6.23 and 2.6.23.14) and dmesg from 2.6.14.17 (working kernel). Please also note that 2.6.23.14 is not able to dump a full Oops msg! -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line
Re: Latest git oopses during boot
On Thu, 7 Feb 2008 12:14:56 +0100
Harald Arnesen [EMAIL PROTECTED] wrote:
On 2/7/08, Andrew Morton [EMAIL PROTECTED] wrote:
(cc's restored, and expanded a bit)
Ah, sorry, not used to gmail's web interface. Clicked the wrong button.
Seems to be the advansys driver, so I tried to remove it - and indeed,
the kernel now boots. So I guess it's either that driver or my ancient
Nikon Coolscan II that is the only thing attached to the board.
Thanks. I uploaded the oops picture to
http://userweb.kernel.org/~akpm/oops.jpg
Cc to the Matthew Wilcox added.
mm... looks like all Matthew's changes were in 2.6.23. And 2.6.23 worked
OK, yes?
Both 2.6.23 and 2.6.24 are ok.
The only recent changes to drivers/scsi/advansys.c are
commit b80ca4f7ee36c26d300c5a8f429e73372d153379
Author: FUJITA Tomonori [EMAIL PROTECTED]
Date: Sun Jan 13 15:46:13 2008 +0900
[SCSI] replace sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE
This replaces sizeof sense_buffer with SCSI_SENSE_BUFFERSIZE in
several LLDs. It's a preparation for the future changes to remove
sense_buffer array in scsi_cmnd structure.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
:100644 100644 9dd3952... 492702b... M drivers/scsi/advansys.c
commit 747d016e7e25e216b31022fe2b012508d99fb682
Author: Randy Dunlap [EMAIL PROTECTED]
Date: Mon Jan 14 00:55:18 2008 -0800
advansys: fix section mismatch warning
Fix section mismatch warning:
WARNING: vmlinux.o(.exit.text+0x152a): Section mismatch: reference to
.init.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
Cc: Matthew Wilcox [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
which seem fairly benign.
gcc inlining is going to make it rather a lot of work to find out which
statement has actually oopsed there.
--
Can you try this?
Thanks,
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 374ed02..f5dde12 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -566,7 +566,7 @@ typedef struct asc_dvc_var {
ASC_SCSI_BIT_ID_TYPE unit_not_ready;
ASC_SCSI_BIT_ID_TYPE queue_full_or_busy;
ASC_SCSI_BIT_ID_TYPE start_motor;
- uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
+ uchar *overrun_buf;
dma_addr_t overrun_dma;
uchar scsi_reset_wait;
uchar chip_no;
@@ -13833,6 +13833,12 @@ static int __devinit advansys_board_found(struct
Scsi_Host *shost,
*/
if (ASC_NARROW_BOARD(boardp)) {
ASC_DBG(2, AscInitAsc1000Driver()\n);
+
+ asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE,
GFP_KERNEL);
+ if (!asc_dvc_varp-overrun_buf) {
+ ret = -ENOMEM;
+ goto err_free_wide_mem;
+ }
warn_code = AscInitAsc1000Driver(asc_dvc_varp);
if (warn_code || asc_dvc_varp-err_code) {
@@ -13840,8 +13846,10 @@ static int __devinit advansys_board_found(struct
Scsi_Host *shost,
warn 0x%x, error 0x%x\n,
asc_dvc_varp-init_state, warn_code,
asc_dvc_varp-err_code);
- if (asc_dvc_varp-err_code)
+ if (asc_dvc_varp-err_code) {
ret = -ENODEV;
+ kfree(asc_dvc_varp-overrun_buf);
+ }
}
} else {
if (advansys_wide_init_chip(shost))
@@ -13891,9 +13899,11 @@ static int advansys_release(struct Scsi_Host *shost)
free_dma(shost-dma_channel);
}
if (ASC_NARROW_BOARD(board)) {
+ ASC_DVC_VAR *asc_dvc_varp = board-dvc_var.asc_dvc_var;
dma_unmap_single(board-dev,
board-dvc_var.asc_dvc_var.overrun_dma,
ASC_OVERRUN_BSIZE, DMA_FROM_DEVICE);
+ kfree(asc_dvc_varp-overrun_buf);
} else {
iounmap(board-ioremap_addr);
advansys_wide_free_mem(board);
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 --- Comment #5 from [EMAIL PROTECTED] 2008-02-07 06:26 --- Created an attachment (id=14736) -- (http://bugzilla.kernel.org/attachment.cgi?id=14736action=view) Oops from 2.6.24 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #4 from [EMAIL PROTECTED] 2008-02-07 06:25 --- The same problem exists in 2.6.24. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bugfix for an underflow condition in usb storage isd200.c
On Wed, 6 Feb 2008, James Bottomley wrote: Did you mean scsi_kmap_atomic_sg()? Yes .. I replied from memory rather than looking in the source. That appears to do only part of what usb_stor_access_xfer_buf() does. In fact, all it does is map a single page. Um, it does everything you asked about above. It's designed as a helper for SCSI devices that need to modify data for automatically generated returns (RAID devices and INQUIRY strings for instance). It's also used by some of the less well automated devices that might need to do an effective PIO feed on DMA engine halts. It allows you to address a sg list by offset and length (although it will adjust the length if there's a mapping problem). Since the only way to guarantee access to highmem is by kmap_atomic (which has limited slots), any API that does this sort of thing is necessarily page based and does single page mappings at a time. Why don't you tell me what you think is missing rather than me having to dig around in the usb sources to try to work it out. Sure. The USB routine takes as arguments a pointer to a memory buffer, a length, a scsi_cmnd, an offset value, and a direction flag. It copies data between the memory buffer and the scsi_cmnd's transfer buffer, starting at the specified offset in the transfer buffer. It works regardless of whether use_sg is 0 in the scsi_cmnd, by mapping the pages in the scatter-gather list one at a time (if use_sg 0) and looping over these pages as needed. It also updates the offset value so that a subsequent call will pick up from where the current call left off, allowing a large transfer buffer to be read/written in multiple smaller increments. The added value here is that the USB routine automatically keeps track of all the details and automatically does the copying. The caller doesn't have to worry about anything other than supplying the memory buffer and the length. Comparing the USB routine with the SCSI routine shows one potential weakness: The USB routine uses kmap() and not kmap_atomic(). Perhaps it should call scsi_kmap_atomic_sg() to do that part of its work. (And perhaps the whole thing should be moved into the SCSI core.) Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest git oopses during boot
On Thu, 7 Feb 2008, Harald Arnesen wrote:
OK, tried it. Another screen shot attached
(I must really get another box to use as a serial terminal).
This oops decodes to
8b 44 24 10 mov0x10(%esp),%eax
8b 90 7c 02 00 00 mov0x27c(%eax),%edx
83 ea 54sub$0x54,%edx
24 18 and$0x18,%al
8b 4c 24 14 mov0x14(%esp),%ecx
f6 41 04 04 testb $0x4,0x4(%ecx)
75 57 jne0x70
ba d0 80 00 00 mov$0x80d0,%edx
b8 68 bf 30 c0 mov$0xc030bf68,%eax
e8 2f 8a 38 c7 call 0xc7388a57
** a3 14 00 00 00 mov%eax,0x14 **
85 c0 test %eax,%eax
0f 84 b3 14 00 00 je 0x14c0
8b 44 24 14 mov0x14(%esp),%eax
83 c0 0cadd$0xc,%eax
and the oopsing instruction is literally an insane store to absolute
address 0x14 which will definitely oops unconditionally.
Quit frankly, that code makes no sense. It smells like code corruption,
especially as it is right at a return point of a function call (ie maybe
the function screwed up the stack accesses somehow).
Actually, it look slike the call address itself is screwed up too. I
don't think 0xc7388a57 is likely to be a valid address.
The code *looks* like the test
if (ASC_NARROW_BOARD(boardp)) {
ASC_DBG(1, narrow board\n);
asc_dvc_varp = boardp-dvc_var.asc_dvc_var;
asc_dvc_varp-bus_type = bus_type;
but with strange corruption.
Can you do a
make drivers/scsi/advansys.lst
and see what it should be?
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9872] Driver 'sd' needs updating - please use bus_type methods
http://bugzilla.kernel.org/show_bug.cgi?id=9872 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] ||bugs.osdl.org -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no INQUIRY from userspace please (was Re: [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE)
--- On Thu, 2/7/08, James Bottomley [EMAIL PROTECTED] wrote: This is all a tradeoff. If you want userspace *never* to issue raw SCSI commands like INQUIRY, we're going to have to provide the needed information from the kernel via sysfs ... including VPD strings. This is something we've always shovelled off into userspace before. What if a user-space application client _does_ send an INQUIRY to a device anyway? It would probably be better to preserve application client behaviour and simulate/emulate n-th INQUIRY, after the 1st for such broken device firmwares that break on any subsequent INQUIRY. Possibly in the LLDD or via blacklisting in the mid-layer. Luben - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|linux-scsi@vger.kernel.org |[EMAIL PROTECTED] -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no INQUIRY from userspace please
(adding Cc linux-hotplug) James Bottomley wrote: On Thu, 2008-02-07 at 11:08 +0100, Stefan Richter wrote: Mike Anderson wrote: A number of user apps like lvm scanning that execute media access commands already have filter capability to filter devices that one does not want to scan. Another class of device scanners just use inquiries which are not effected by the passive state (though some could probably use udevinfo and reduce the amount of repeated SCSI inquiries execute on the system. To expand on this: At least on desktop systems and SOHO server systems, userspace should _never_ issue INQUIRY. There are too many broken firmwares out there which assume that there will never be more than one INQUIRY sent. They start to return garbled data or crash if they get a second INQUIRY. It's all very well to say this, but I think if you look at what udev does, you'll find that it uses scsi_id to send a VPD inquiry to the device so it can populate /dev/disk/by-id, so the point is already conceded (and I think looking at a recent camera crash that seems to have been precipitated by this, it's already causing us problems). This is all a tradeoff. If you want userspace *never* to issue raw SCSI commands like INQUIRY, we're going to have to provide the needed information from the kernel via sysfs ... including VPD strings. This is something we've always shovelled off into userspace before. Well, it's definitely awkward to have to deal with less than perfect firmwares. But there is still potential to optimize udev based on what we already have in sysfs. For example, on Gentoo I see calls of scsi_id and usb_id for FireWire disks (by udev? by HAL? I don't know), even though udev actually also reads the FireWire driver specific sysfs attribute with the target port ID and LUN. I.e. udev knows where to look but calls pointless helpers anyway. (BTW, how about sysfs attributes for the target port identifier and for the logical unit identifier --- at transport independent sysfs paths --- to simplify userspace's life? What else?) -- Stefan Richter -=-==--- --=- --=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
On Thu, 2008-02-07 at 14:13 +0100, Bart Van Assche wrote: Since the focus of this thread shifted somewhat in the last few messages, I'll try to summarize what has been discussed so far: - There was a number of participants who joined this discussion spontaneously. This suggests that there is considerable interest in networked storage and iSCSI. - It has been motivated why iSCSI makes sense as a storage protocol (compared to ATA over Ethernet and Fibre Channel over Ethernet). - The direct I/O performance results for block transfer sizes below 64 KB are a meaningful benchmark for storage target implementations. - It has been discussed whether an iSCSI target should be implemented in user space or in kernel space. It is clear now that an implementation in the kernel can be made faster than a user space implementation (http://kerneltrap.org/mailarchive/linux-kernel/2008/2/4/714804). Regarding existing implementations, measurements have a.o. shown that SCST is faster than STGT (30% with the following setup: iSCSI via IPoIB and direct I/O block transfers with a size of 512 bytes). - It has been discussed which iSCSI target implementation should be in the mainstream Linux kernel. There is no agreement on this subject yet. The short-term options are as follows: 1) Do not integrate any new iSCSI target implementation in the mainstream Linux kernel. 2) Add one of the existing in-kernel iSCSI target implementations to the kernel, e.g. SCST or PyX/LIO. 3) Create a new in-kernel iSCSI target implementation that combines the advantages of the existing iSCSI kernel target implementations (iETD, STGT, SCST and PyX/LIO). As an iSCSI user, I prefer option (3). The big question is whether the various storage target authors agree with this ? I think the other data point here would be that final target design needs to be as generic as possible. Generic in the sense that the engine eventually needs to be able to accept NDB and other ethernet based target mode storage configurations to an abstracted device object (struct scsi_device, struct block_device, or struct file) just as it would for an IP Storage based request. We know that NDB and *oE will have their own naming and discovery, and the first set of IO tasks to be completed would be those using (iscsi_cmd_t-cmd_flags ICF_SCSI_DATA_SG_IO_CDB) in iscsi_target_transport.c in the current code.These are single READ_* and WRITE_* codepaths that perform DMA memory pre-proceessing in v2.9 LIO-SE. Also, being able to tell the engine to accelerate to DMA ring operation (say to underlying struct scsi_device or struct block_device) instead of fileio in some cases you will see better performance when using hardware (ie: not a underlying kernel thread queueing IO into block). But I have found FILEIO with sendpage with MD to be faster in single threaded tests than struct block_device. I am currently using IBLOCK for LVM for core LIO operation (which actually sits on software MD raid6). I do this because using submit_bio() with se_mem_t mapped arrays of struct scatterlist - struct bio_vec can handle power failures properly, and not send back StatSN Acks to the Initiator who thinks that everything has already made it to disk. This is the case with doing IO to struct file in the kernel today without a kernel level O_DIRECT. Also for proper kernel-level target mode support, using struct file with O_DIRECT for storage blocks and emulating control path CDBS is one of the work items. This can be made generic or obtained from the underlying storage object (anything that can be exported from LIO Subsystem TPI) For real hardware (struct scsi_device in just about all the cases these days). Last time I looked this was due to fs/direct-io.c:dio_refill_pages() using get_user_pages()... For really transport specific CDB and control code, which in good amount of cases, we are going eventually be expected to emulate in software. I really like how STGT breaks this up into per device type code segments; spc.c sbc.c mmc.c ssc.c smc.c etc. Having all of these split out properly is one strong point of STGT IMHO, and really makes learning things much easier. Also, being able to queue these IOs into a userspace and receive a asynchronous response back up the storage stack. I think this is actually a pretty interesting potential for passing storage protocol packets into userspace apps and leave the protocol state machines and recovery paths in the kernel with a generic target engine. Also, I know that the SCST folks have put alot of time into getting the very SCSI hardware specific target mode control modes to work. I personally own a bunch of this adapters, and would really like to see better support for target mode on non iSCSI type adapters with a single target mode storage engine that abstracts storage subsystems and wire protocol fabrics. --nab - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 [EMAIL PROTECTED] changed: What|Removed |Added KernelVersion|2.6.23 - 2.6.23.14 |2.6.23, 2.6.23.14, 2.6.24 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #14733|Oops from 2.6.23 (truncated)|Oops from 2.6.23.14 description||(truncated) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 --- Comment #1 from [EMAIL PROTECTED] 2008-02-07 05:53 --- Created an attachment (id=14732) -- (http://bugzilla.kernel.org/attachment.cgi?id=14732action=view) Oops from 2.6.23 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Integration of SCST in the mainstream Linux kernel
Bart Van Assche wrote: Since the focus of this thread shifted somewhat in the last few messages, I'll try to summarize what has been discussed so far: - There was a number of participants who joined this discussion spontaneously. This suggests that there is considerable interest in networked storage and iSCSI. - It has been motivated why iSCSI makes sense as a storage protocol (compared to ATA over Ethernet and Fibre Channel over Ethernet). - The direct I/O performance results for block transfer sizes below 64 KB are a meaningful benchmark for storage target implementations. - It has been discussed whether an iSCSI target should be implemented in user space or in kernel space. It is clear now that an implementation in the kernel can be made faster than a user space implementation (http://kerneltrap.org/mailarchive/linux-kernel/2008/2/4/714804). Regarding existing implementations, measurements have a.o. shown that SCST is faster than STGT (30% with the following setup: iSCSI via IPoIB and direct I/O block transfers with a size of 512 bytes). - It has been discussed which iSCSI target implementation should be in the mainstream Linux kernel. There is no agreement on this subject yet. The short-term options are as follows: 1) Do not integrate any new iSCSI target implementation in the mainstream Linux kernel. 2) Add one of the existing in-kernel iSCSI target implementations to the kernel, e.g. SCST or PyX/LIO. 3) Create a new in-kernel iSCSI target implementation that combines the advantages of the existing iSCSI kernel target implementations (iETD, STGT, SCST and PyX/LIO). As an iSCSI user, I prefer option (3). The big question is whether the various storage target authors agree with this ? I tend to agree with some important notes: 1. IET should be excluded from this list, iSCSI-SCST is IET updated for SCST framework with a lot of bugfixes and improvements. 2. I think, everybody will agree that Linux iSCSI target should work over some standard SCSI target framework. Hence the choice gets narrower: SCST vs STGT. I don't think there's a way for a dedicated iSCSI target (i.e. PyX/LIO) in the mainline, because of a lot of code duplication. Nicholas could decide to move to either existing framework (although, frankly, I don't think there's a possibility for in-kernel iSCSI target and user space SCSI target framework) and if he decide to go with SCST, I'll be glad to offer my help and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. The better one should win. Vlad - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel
Is there an open iSCSI Target implementation which does NOT issue commands to sub-target devices via the SCSI mid-layer, but bypasses it completely? Luben - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest git oopses during boot
On 2/7/08, Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 7 Feb 2008, Harald Arnesen wrote:
I'll try applying the patch to a freshly downloaded git-tree.
Ok, good.
Shall I try another compiler? I have at least these two:
gcc version 3.4.6 (Ubuntu 3.4.6-6ubuntu2)
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
I would suggest a patch mis-application problem first (or possibly even
the patch itself being broken - I simply didn't look very closely at the
patch, but it *looked* ok).
If it's a compiler bug, it's a pretty big one, and quite frankly, I doubt
it. Compiler bugs do happen, but they are pretty rare, and they tend to
have more subtle effects than the one you see.
However:
in addition to the self-compiled 4.2.3 I used for the tests.
4.2.3? Really? That's pretty damn recent, and so almost totally untested.
That does make a compiler bug at least more likely.
So yes, if you already have other compilers installed, you should try
them. If it really is a compiler bug, it's a really bad one, and you would
want to let the gcc people know.
Still, I'd double-check that the
asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL);
line was added properly first. You should see it way after the point where
it did
asc_dvc_varp = boardp-dvc_var.asc_dvc_var;
to initialize it (and both statements should be inside a
if (ASC_NARROW_BOARD(boardp)) {
conditional - please check that the source code looks sane too).
Linus
I just re-downloaded an re-patched and re-compiled (with gcc 4.2.3),
and now the kernel boots. I must have screwed up the previous
patching.
It now works, with Fujita's patch applied.
--
Hilsen Harald
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest git oopses during boot
Linus Torvalds [EMAIL PROTECTED] writes: On Thu, 7 Feb 2008, Harald Arnesen wrote: Can you do a make drivers/scsi/advansys.lst and see what it should be? Anyway, here it is, as an attachment. Ok, I was wrong. The code really *does* compile to that insane a3 14 00 00 00 mov%eax,0x14 by your compiler. That's the asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL); thing, and gcc seems to have decided that it can statically prove that asc_dvc_varp is NULL. Quite frankly, I don't see that being true. But you have some patches in your tree that I haven't followed, so.. Are you sure the patches applied to the right spot? The patch I saw added that kzalloc() to the _end_ of the function (long after asc_dvc_varp was initialized), maybe that one got mis-applied? Or maybe your compiler version is simply totally broken. Linus I'll try applying the patch to a freshly downloaded git-tree. Shall I try another compiler? I have at least these two: gcc version 3.4.6 (Ubuntu 3.4.6-6ubuntu2) gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) in addition to the self-compiled 4.2.3 I used for the tests. -- Hilsen Harald. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Integration of SCST in the mainstream Linux kernel
On Thu, 7 Feb 2008, Vladislav Bolkhovitin wrote: Bart Van Assche wrote: - It has been discussed which iSCSI target implementation should be in the mainstream Linux kernel. There is no agreement on this subject yet. The short-term options are as follows: 1) Do not integrate any new iSCSI target implementation in the mainstream Linux kernel. 2) Add one of the existing in-kernel iSCSI target implementations to the kernel, e.g. SCST or PyX/LIO. 3) Create a new in-kernel iSCSI target implementation that combines the advantages of the existing iSCSI kernel target implementations (iETD, STGT, SCST and PyX/LIO). As an iSCSI user, I prefer option (3). The big question is whether the various storage target authors agree with this ? I tend to agree with some important notes: 1. IET should be excluded from this list, iSCSI-SCST is IET updated for SCST framework with a lot of bugfixes and improvements. 2. I think, everybody will agree that Linux iSCSI target should work over some standard SCSI target framework. Hence the choice gets narrower: SCST vs STGT. I don't think there's a way for a dedicated iSCSI target (i.e. PyX/LIO) in the mainline, because of a lot of code duplication. Nicholas could decide to move to either existing framework (although, frankly, I don't think there's a possibility for in-kernel iSCSI target and user space SCSI target framework) and if he decide to go with SCST, I'll be glad to offer my help and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. The better one should win. why should linux as an iSCSI target be limited to passthrough to a SCSI device. the most common use of this sort of thing that I would see is to load up a bunch of 1TB SATA drives in a commodity PC, run software RAID, and then export the resulting volume to other servers via iSCSI. not a 'real' SCSI device in sight. As far as how good a standard iSCSI is, at this point I don't think it really matters. There are too many devices and manufacturers out there that implement iSCSI as their storage protocol (from both sides, offering storage to other systems, and using external storage). Sometimes the best technology doesn't win, but Linux should be interoperable with as much as possible and be ready to support the winners and the loosers in technology options, for as long as anyone chooses to use the old equipment (after all, we support things like Arcnet networking, which lost to Ethernet many years ago) David Lang - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest git oopses during boot
On Thu, 7 Feb 2008, Harald Arnesen wrote: Can you do a make drivers/scsi/advansys.lst and see what it should be? Anyway, here it is, as an attachment. Ok, I was wrong. The code really *does* compile to that insane a3 14 00 00 00 mov%eax,0x14 by your compiler. That's the asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL); thing, and gcc seems to have decided that it can statically prove that asc_dvc_varp is NULL. Quite frankly, I don't see that being true. But you have some patches in your tree that I haven't followed, so.. Are you sure the patches applied to the right spot? The patch I saw added that kzalloc() to the _end_ of the function (long after asc_dvc_varp was initialized), maybe that one got mis-applied? Or maybe your compiler version is simply totally broken. Linus - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9909] Unable to handle kernel NULL pointer dereference at 0000000000000010 (mptsas_probe_expander_phys+0x62/0x427)
http://bugzilla.kernel.org/show_bug.cgi?id=9909 --- Comment #2 from [EMAIL PROTECTED] 2008-02-07 05:54 --- Created an attachment (id=14733) -- (http://bugzilla.kernel.org/attachment.cgi?id=14733action=view) Oops from 2.6.23 (truncated) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no INQUIRY from userspace please (was Re: [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE)
On Thu, 2008-02-07 at 11:08 +0100, Stefan Richter wrote: Mike Anderson wrote: A number of user apps like lvm scanning that execute media access commands already have filter capability to filter devices that one does not want to scan. Another class of device scanners just use inquiries which are not effected by the passive state (though some could probably use udevinfo and reduce the amount of repeated SCSI inquiries execute on the system. To expand on this: At least on desktop systems and SOHO server systems, userspace should _never_ issue INQUIRY. There are too many broken firmwares out there which assume that there will never be more than one INQUIRY sent. They start to return garbled data or crash if they get a second INQUIRY. It's all very well to say this, but I think if you look at what udev does, you'll find that it uses scsi_id to send a VPD inquiry to the device so it can populate /dev/disk/by-id, so the point is already conceded (and I think looking at a recent camera crash that seems to have been precipitated by this, it's already causing us problems). This is all a tradeoff. If you want userspace *never* to issue raw SCSI commands like INQUIRY, we're going to have to provide the needed information from the kernel via sysfs ... including VPD strings. This is something we've always shovelled off into userspace before. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Oops in megaraid_mbox_dpc(), kernel 2.6.23.9-85.fc8.i686
On 02/06/2008 02:38 PM, Yang, Bo wrote:
Andrew/Scott,
Can you give me more details about this issue? Such as: MegaRAID
Controller name, FW version, RAID configuration, host system info, how
to reproduce this issue. Also do you see the issue on other kernel
versions.
He has hit the BUG() here in megaraid_mbox_dpc():
// Make sure f/w has completed a valid command
if (scb-state != SCB_ISSUED) {
con_log(CL_ANN, (KERN_CRIT
megaraid critical err: invalid command %d:%d:%p\n,
scb-sno, scb-state, scp));
BUG();
continue; // Must never happen!
}
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest git oopses during boot
On Thu, 7 Feb 2008, Harald Arnesen wrote:
I'll try applying the patch to a freshly downloaded git-tree.
Ok, good.
Shall I try another compiler? I have at least these two:
gcc version 3.4.6 (Ubuntu 3.4.6-6ubuntu2)
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
I would suggest a patch mis-application problem first (or possibly even
the patch itself being broken - I simply didn't look very closely at the
patch, but it *looked* ok).
If it's a compiler bug, it's a pretty big one, and quite frankly, I doubt
it. Compiler bugs do happen, but they are pretty rare, and they tend to
have more subtle effects than the one you see.
However:
in addition to the self-compiled 4.2.3 I used for the tests.
4.2.3? Really? That's pretty damn recent, and so almost totally untested.
That does make a compiler bug at least more likely.
So yes, if you already have other compilers installed, you should try
them. If it really is a compiler bug, it's a really bad one, and you would
want to let the gcc people know.
Still, I'd double-check that the
asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL);
line was added properly first. You should see it way after the point where
it did
asc_dvc_varp = boardp-dvc_var.asc_dvc_var;
to initialize it (and both statements should be inside a
if (ASC_NARROW_BOARD(boardp)) {
conditional - please check that the source code looks sane too).
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: no INQUIRY from userspace please
James Bottomley wrote: It's all very well to say this, but I think if you look at what udev does, you'll find that it uses scsi_id to send a VPD inquiry to the device so it can populate /dev/disk/by-id, so the point is already conceded PS: Alas we don't have a practicable way to know how many of the - doesn't work with Linux but works to some degree with Windows, - doesn't work with a 2.6 based Linux distro but did work with a 2.4 based distro kinds of devices are those with this INQUIRY bug or similar bugs. While non-udev distros slowly went out of fashion on the desktop, there was a certain frequency of reports of the latter kind of FireWire devices, but this was before I became aware of that kind of firmware bug, therefore I don't have any data whether it played a role for these cases. -- Stefan Richter -=-==--- --=- --=== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest git oopses during boot
On Thu, 7 Feb 2008 23:24:00 +0100
Harald Arnesen [EMAIL PROTECTED] wrote:
On 2/7/08, Linus Torvalds [EMAIL PROTECTED] wrote:
On Thu, 7 Feb 2008, Harald Arnesen wrote:
I'll try applying the patch to a freshly downloaded git-tree.
Ok, good.
Shall I try another compiler? I have at least these two:
gcc version 3.4.6 (Ubuntu 3.4.6-6ubuntu2)
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
I would suggest a patch mis-application problem first (or possibly even
the patch itself being broken - I simply didn't look very closely at the
patch, but it *looked* ok).
If it's a compiler bug, it's a pretty big one, and quite frankly, I doubt
it. Compiler bugs do happen, but they are pretty rare, and they tend to
have more subtle effects than the one you see.
However:
in addition to the self-compiled 4.2.3 I used for the tests.
4.2.3? Really? That's pretty damn recent, and so almost totally untested.
That does make a compiler bug at least more likely.
So yes, if you already have other compilers installed, you should try
them. If it really is a compiler bug, it's a really bad one, and you would
want to let the gcc people know.
Still, I'd double-check that the
asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE, GFP_KERNEL);
line was added properly first. You should see it way after the point where
it did
asc_dvc_varp = boardp-dvc_var.asc_dvc_var;
to initialize it (and both statements should be inside a
if (ASC_NARROW_BOARD(boardp)) {
conditional - please check that the source code looks sane too).
Linus
I just re-downloaded an re-patched and re-compiled (with gcc 4.2.3),
and now the kernel boots. I must have screwed up the previous
patching.
It now works, with Fujita's patch applied.
Thanks Harald and Linus,
The bug has been in the advansys driver. 2.6.23 and 2.6.24 works just
because the size of Scsi_Host structure was multiples of 8. After
2.6.24, some patches change Scsi_Host structure and now the size is
not multiples of 8. So we hit this bug.
I'll resend the patch with a proper description.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] aacraid: add optional MSI support.
On Wed, 2008-02-06 at 13:20 -0800, Salyzyn, Mark wrote: Added support for MSI utilizing the aacraid.msi=1 parameter. This patch adds some localized or like-minded janitor fixes. Since the default is disabled, there is no impact on the code paths unless the customer wishes to experiment with the MSI performance. This patch is against current scsi-misc-2.6 It doesn't seem to compile: drivers/scsi/aacraid/sa.c: In function 'aac_sa_init': drivers/scsi/aacraid/sa.c:388: error: dereferencing pointer to incomplete type drivers/scsi/aacraid/sa.c:406: error: dereferencing pointer to incomplete type It looks like this can be corrected by #include linux/pci.h since it's struct pci_dev that's the incomplete type. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 05/13] MegaRAID driver management char device moved to misc
On Mon, 2008-02-04 at 23:53 -0800, [EMAIL PROTECTED] wrote: From: Thomas Horsten [EMAIL PROTECTED] The MegaRAID driver's common management module (megaraid_mm.c) creates a char device used by the management tool megarc from LSI Logic (and possibly other management tools). In 2.6 with udev, this device doesn't get created because it is not registered in sysfs. I first fixed this by registering a class megaraid_mm, but realized that this should probably be moved to misc devices, instead of taking up a char major. This is because only 1 device is used, even if there are multiple adapters - the minor is never used (the adapter info is in the ioctl block sent to the driver, not detected based on the minor number as one might think). So it is a complete waste to have an entire major taken by this. So it now uses a misc device which I named megadev0 (the name that megarc expects), and has a dynamic minor (previoulsy a dynamic major was used). I have tested this on my own system with the megarc tool, and it works just as fine as before (only now the device gets created correctly by udev). Cc: [EMAIL PROTECTED] Cc: Neela Syam Kolli [EMAIL PROTECTED] Cc: Ju, Seokmann [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Neela and Sekomann or Sumant, can I ping on this ... I've no idea what this will do to the raid management tools, so I really need someone to sign off on this. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 03/13] mptbase: reset ioc initiator during PCI resume
On Mon, 2008-02-04 at 23:53 -0800, [EMAIL PROTECTED] wrote: From: Darrick J. Wong [EMAIL PROTECTED] It appears that the LSI SAS 1064E chip needs to be reset after a suspend/resume cycle before the driver attempts further communications with the chip. Without this patch, resuming the chip results in this error message being printed repeatedly and no more disk I/O. mptbase: ioc0: ERROR - Invalid IOC facts reply, msgLength=0 offsetof=6! So far it seems to fix suspend/resume on all the MPT Fusion cards I have (SAS and U320 SCSI) but since I don't know the internals of that chip I can't say for sure if this is a proper fix. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Ping on this, please Eric. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] advansys: fix overrun_buf aligned bug
struct asc_dvc_var needs overrun buffer to be placed on an 8 byte
boundary. advansys defines struct asc_dvc_var:
struct asc_dvc_var {
...
uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
The problem is that struct asc_dvc_var is placed on
shost-hostdata. So if the hostdata is not on an 8 byte boundary, the
advansys crashes. The hostdata is placed on a sizeof(unsigned long)
boundary so the 8 byte boundary is not garanteed with x86_32.
With 2.6.23 and 2.6.24, the hostdata is on an 8 byte boundary by
chance, but with the current git, it's not.
This patch removes overrun_buf static array and use kzalloc.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
drivers/scsi/advansys.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index ccef891..3c2d688 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -566,7 +566,7 @@ typedef struct asc_dvc_var {
ASC_SCSI_BIT_ID_TYPE unit_not_ready;
ASC_SCSI_BIT_ID_TYPE queue_full_or_busy;
ASC_SCSI_BIT_ID_TYPE start_motor;
- uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
+ uchar *overrun_buf;
dma_addr_t overrun_dma;
uchar scsi_reset_wait;
uchar chip_no;
@@ -13833,6 +13833,12 @@ static int __devinit advansys_board_found(struct
Scsi_Host *shost,
*/
if (ASC_NARROW_BOARD(boardp)) {
ASC_DBG(2, AscInitAsc1000Driver()\n);
+
+ asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE,
GFP_KERNEL);
+ if (!asc_dvc_varp-overrun_buf) {
+ ret = -ENOMEM;
+ goto err_free_wide_mem;
+ }
warn_code = AscInitAsc1000Driver(asc_dvc_varp);
if (warn_code || asc_dvc_varp-err_code) {
@@ -13840,8 +13846,10 @@ static int __devinit advansys_board_found(struct
Scsi_Host *shost,
warn 0x%x, error 0x%x\n,
asc_dvc_varp-init_state, warn_code,
asc_dvc_varp-err_code);
- if (asc_dvc_varp-err_code)
+ if (asc_dvc_varp-err_code) {
ret = -ENODEV;
+ kfree(asc_dvc_varp-overrun_buf);
+ }
}
} else {
if (advansys_wide_init_chip(shost))
@@ -13894,6 +13902,7 @@ static int advansys_release(struct Scsi_Host *shost)
dma_unmap_single(board-dev,
board-dvc_var.asc_dvc_var.overrun_dma,
ASC_OVERRUN_BSIZE, DMA_FROM_DEVICE);
+ kfree(board-dvc_var.asc_dvc_var.overrun_buf);
} else {
iounmap(board-ioremap_addr);
advansys_wide_free_mem(board);
--
1.5.3.7
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCH] final SCSI updates for 2.6.24 merge window
Quite a bit of this is fixing things broken previously (the advansys fix is still pending resolution, but I'll send it as an -rc fix when we have it). There's the final elimination of all drivers that are esp based but don't use the scsi_esp core (that's mostly m68k and alpha). Plus the usual bunch of driver updates and the addition of a new enclosure services driver and the corresponding ULD. The patch is available from: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git The short changelog is: Adrian Bunk (2): advansys: make 3 functions static libiscsi: make __iscsi_complete_pdu() static Aegis Lin (1): ps3rom: sector size should be 512 bytes Andrew Morton (1): dc395x: fix uninitialized var warning Andrew Vasquez (9): qla2xxx: Update version number to 8.02.00-k8. qla2xxx: Correct issue where incorrect init-fw mailbox command was used on qla2xxx: Move RISC-interrupt-register modifications to qla2x00_request_irq qla2xxx: Consolidate RISC-parity enablement codes. qla2xxx: Cleanse memory allocation logic during probe. qla2xxx: Clear EFT buffer before firmware reinitialization. qla2xxx: Cleanup any outstanding SRB resources during shutdown. qla2xxx: Add MODULE_FIRMWARE hint for ISP25XX firmware. qla2xxx: Correct resource_size_t usages. Boaz Harrosh (1): arm: convert to accessors and !use_sg cleanup James Bottomley (10): ses: add new Enclosure ULD enclosure: add support for enclosure services sr: fix test unit ready responses NCR53C9x: remove driver remove m68k NCR53C9x based drivers dec_esp: Remove driver update my email address add protocol definitions sd: handle bad lba in sense information mca_53c9x: remove driver Mike Christie (12): iscsi: bump version to 2.0-868 libiscsi: fix session age rollover and remove cid encoding iscsi: fix up iscsi printk prefix iscsi class: fix iscsi conn attr counter libiscsi: fix setting of nop timer qla4xxx: add async scan support iscsi class: add async scan helper qla4xxx: fix recovery timer and session unblock race iscsi class: add session scanning qla4xxx: use iscsi class session state check ready qla4xxx: directly call iscsi recovery functions iscsi class, libiscsi: add iscsi sysfs session state file Nick Cheng (1): arcmsr: updates (1.20.00.15) Pavel Machek (1): Small cleanups for scsi_host.h Randy Dunlap (1): kernel-doc: fix scsi docbook Roel Kluin (1): u14-34f: fix data direction bug Salyzyn, Mark (3): aacraid: do not set valid bit in sense information aacraid: pci_set_dma_max_seg_size opened up for late model controllers aacraid: fib context lock for management ioctls (take 2) Seokmann Ju (2): qla2xxx: Access the proper 'physical' port in FC-transport callbacks. qla2xxx: Correct issue where vport-state was not updated during an ISP_ABO Thomas Bogendoerfer (1): sun3x_esp: convert to esp_scsi Tony Battersby (2): fix BUG when sum(scatterlist) bufflen sym53c8xx: fix resid calculation and the diffstat: Documentation/DocBook/scsi.tmpl |2 Documentation/scsi/ChangeLog.arcmsr | 41 Documentation/scsi/scsi_mid_low_api.txt |2 drivers/misc/Kconfig|9 drivers/misc/Makefile |1 drivers/misc/enclosure.c| 484 drivers/scsi/Kconfig| 93 drivers/scsi/Makefile | 12 drivers/scsi/NCR53C9x.c | 3654 drivers/scsi/NCR53C9x.h | 668 - drivers/scsi/aacraid/aachba.c | 81 drivers/scsi/aacraid/commctrl.c | 26 drivers/scsi/aacraid/linit.c| 28 drivers/scsi/advansys.c |6 drivers/scsi/arcmsr/arcmsr.h|4 drivers/scsi/arcmsr/arcmsr_hba.c| 87 drivers/scsi/arm/acornscsi.c| 14 drivers/scsi/arm/scsi.h | 87 drivers/scsi/blz1230.c | 353 --- drivers/scsi/blz2060.c | 306 -- drivers/scsi/cyberstorm.c | 377 --- drivers/scsi/cyberstormII.c | 314 -- drivers/scsi/dc395x.c |2 drivers/scsi/dec_esp.c | 687 -- drivers/scsi/fastlane.c | 421 --- drivers/scsi/iscsi_tcp.c| 57 drivers/scsi/libiscsi.c | 137 - drivers/scsi/mac_esp.c | 751 -- drivers/scsi/mca_53c9x.c| 520 drivers/scsi/oktagon_esp.c | 606 - drivers/scsi/oktagon_io.S | 194 - drivers/scsi/ps3rom.c |2 drivers/scsi/qla2xxx/qla_attr.c | 24 drivers/scsi/qla2xxx/qla_def.h |2 drivers/scsi/qla2xxx/qla_gbl.h |
Re: [PATCH] advansys: fix overrun_buf aligned bug
On Fri, 2008-02-08 at 09:50 +0900, FUJITA Tomonori wrote:
struct asc_dvc_var needs overrun buffer to be placed on an 8 byte
boundary. advansys defines struct asc_dvc_var:
struct asc_dvc_var {
...
uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
The problem is that struct asc_dvc_var is placed on
shost-hostdata. So if the hostdata is not on an 8 byte boundary, the
advansys crashes. The hostdata is placed on a sizeof(unsigned long)
boundary so the 8 byte boundary is not garanteed with x86_32.
With 2.6.23 and 2.6.24, the hostdata is on an 8 byte boundary by
chance, but with the current git, it's not.
This patch removes overrun_buf static array and use kzalloc.
It's a bit of a waste of a kmallocs. The usual way of fixing this type
of cockup is to float the structure until it becomes aligned, but I
suppose that involves changing all calls to shost_priv in the driver ...
James
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote: Quite a bit of this is fixing things broken previously (the advansys fix is still pending resolution, but I'll send it as an -rc fix when we have it). There's the final elimination of all drivers that are esp based but don't use the scsi_esp core (that's mostly m68k and alpha). Plus the usual bunch of driver updates and the addition of a new enclosure services driver and the corresponding ULD. The patch is available from: I'm going to guess that this is the entry in feature-removal.txt that need an update then: --- What: old NCR53C9x driver When: October 2007 Why:Replaced by the much better esp_scsi driver. Actual low-level driver can be ported over almost trivially. Who:David Miller [EMAIL PROTECTED] Christoph Hellwig [EMAIL PROTECTED] Cheers, Harvey - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 17:04 -0800, Harvey Harrison wrote: On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote: Quite a bit of this is fixing things broken previously (the advansys fix is still pending resolution, but I'll send it as an -rc fix when we have it). There's the final elimination of all drivers that are esp based but don't use the scsi_esp core (that's mostly m68k and alpha). Plus the usual bunch of driver updates and the addition of a new enclosure services driver and the corresponding ULD. The patch is available from: I'm going to guess that this is the entry in feature-removal.txt that need an update then: --- What: old NCR53C9x driver When: October 2007 Why: Replaced by the much better esp_scsi driver. Actual low-level driver can be ported over almost trivially. Who: David Miller [EMAIL PROTECTED] Christoph Hellwig [EMAIL PROTECTED] Not immediately ... I anticipate a few where'd my driver go? type questions from m68k for which this provides a useful reference to point to ... James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 19:07 -0600, James Bottomley wrote: On Thu, 2008-02-07 at 17:04 -0800, Harvey Harrison wrote: On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote: Quite a bit of this is fixing things broken previously (the advansys fix is still pending resolution, but I'll send it as an -rc fix when we have it). There's the final elimination of all drivers that are esp based but don't use the scsi_esp core (that's mostly m68k and alpha). Plus the usual bunch of driver updates and the addition of a new enclosure services driver and the corresponding ULD. The patch is available from: I'm going to guess that this is the entry in feature-removal.txt that need an update then: --- What: old NCR53C9x driver When: October 2007 Why:Replaced by the much better esp_scsi driver. Actual low-level driver can be ported over almost trivially. Who:David Miller [EMAIL PROTECTED] Christoph Hellwig [EMAIL PROTECTED] Not immediately ... I anticipate a few where'd my driver go? type questions from m68k for which this provides a useful reference to point to ... James Well, if not removed, how about updated: What: old NCR53C9x driver When: Removed Feb 2008 Why:Replaced by the much better esp_scsi driver. Actual low-level driver can be ported over almost trivially. Who:James Bottomley [EMAIL PROTECTED] Cheers, Harvey - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] advansys: fix overrun_buf aligned bug
On Thu, 07 Feb 2008 19:01:55 -0600
James Bottomley [EMAIL PROTECTED] wrote:
On Fri, 2008-02-08 at 09:50 +0900, FUJITA Tomonori wrote:
struct asc_dvc_var needs overrun buffer to be placed on an 8 byte
boundary. advansys defines struct asc_dvc_var:
struct asc_dvc_var {
...
uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
The problem is that struct asc_dvc_var is placed on
shost-hostdata. So if the hostdata is not on an 8 byte boundary, the
advansys crashes. The hostdata is placed on a sizeof(unsigned long)
boundary so the 8 byte boundary is not garanteed with x86_32.
With 2.6.23 and 2.6.24, the hostdata is on an 8 byte boundary by
chance, but with the current git, it's not.
This patch removes overrun_buf static array and use kzalloc.
It's a bit of a waste of a kmallocs. The usual way of fixing this type
of cockup is to float the structure until it becomes aligned, but I
suppose that involves changing all calls to shost_priv in the driver ...
Yeah, agreed. It's better but I'm not familiar with the driver so I
use kmalloc. It's not so bad as a short-term solution, I think.
Any chance to push it to final SCSI updates for 2.6.24 merge window?
Though we can push it any time since it's a bug fix.
Anyway, I'm fine with dropping it if Matthew will fix the driver in a
better way. I'm happy unless people blame my IOMMU or sense buffer
patch for this bug. :)
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 03/13] mptbase: reset ioc initiator during PCI resume
On Thu, Feb 07, 2008 at 06:41:25PM -0600, James Bottomley wrote: On Mon, 2008-02-04 at 23:53 -0800, [EMAIL PROTECTED] wrote: From: Darrick J. Wong [EMAIL PROTECTED] It appears that the LSI SAS 1064E chip needs to be reset after a suspend/resume cycle before the driver attempts further communications with the chip. Without this patch, resuming the chip results in this error message being printed repeatedly and no more disk I/O. mptbase: ioc0: ERROR - Invalid IOC facts reply, msgLength=0 offsetof=6! So far it seems to fix suspend/resume on all the MPT Fusion cards I have (SAS and U320 SCSI) but since I don't know the internals of that chip I can't say for sure if this is a proper fix. Signed-off-by: Darrick J. Wong [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Ping on this, please Eric. As far as I can tell, Eric isn't really involved with this patch anymore, and handed it over to [EMAIL PROTECTED] I received email from him (her? Apologies, I'm not sufficiently familiar with Indian names) this morning saying that a modified version of it would go out to linux-scsi in a day or two. --D - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote:
Quite a bit of this is fixing things broken previously (the advansys fix
is still pending resolution, but I'll send it as an -rc fix when we have
it). There's the final elimination of all drivers that are esp based
but don't use the scsi_esp core (that's mostly m68k and alpha). Plus
the usual bunch of driver updates and the addition of a new enclosure
services driver and the corresponding ULD.
OK, the advansys fix came in. I've added it to the patch.
James
From f983323fea178352ed3b69c70561a13825a3ce59 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori [EMAIL PROTECTED]
Date: Fri, 8 Feb 2008 09:50:08 +0900
Subject: [SCSI] advansys: fix overrun_buf aligned bug
struct asc_dvc_var needs overrun buffer to be placed on an 8 byte
boundary. advansys defines struct asc_dvc_var:
struct asc_dvc_var {
...
uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
The problem is that struct asc_dvc_var is placed on
shost-hostdata. So if the hostdata is not on an 8 byte boundary, the
advansys crashes. The hostdata is placed on a sizeof(unsigned long)
boundary so the 8 byte boundary is not garanteed with x86_32.
With 2.6.23 and 2.6.24, the hostdata is on an 8 byte boundary by
chance, but with the current git, it's not.
This patch removes overrun_buf static array and use kzalloc.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
Signed-off-by: James Bottomley [EMAIL PROTECTED]
---
drivers/scsi/advansys.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index ccef891..3c2d688 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -566,7 +566,7 @@ typedef struct asc_dvc_var {
ASC_SCSI_BIT_ID_TYPE unit_not_ready;
ASC_SCSI_BIT_ID_TYPE queue_full_or_busy;
ASC_SCSI_BIT_ID_TYPE start_motor;
- uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
+ uchar *overrun_buf;
dma_addr_t overrun_dma;
uchar scsi_reset_wait;
uchar chip_no;
@@ -13833,6 +13833,12 @@ static int __devinit advansys_board_found(struct
Scsi_Host *shost,
*/
if (ASC_NARROW_BOARD(boardp)) {
ASC_DBG(2, AscInitAsc1000Driver()\n);
+
+ asc_dvc_varp-overrun_buf = kzalloc(ASC_OVERRUN_BSIZE,
GFP_KERNEL);
+ if (!asc_dvc_varp-overrun_buf) {
+ ret = -ENOMEM;
+ goto err_free_wide_mem;
+ }
warn_code = AscInitAsc1000Driver(asc_dvc_varp);
if (warn_code || asc_dvc_varp-err_code) {
@@ -13840,8 +13846,10 @@ static int __devinit advansys_board_found(struct
Scsi_Host *shost,
warn 0x%x, error 0x%x\n,
asc_dvc_varp-init_state, warn_code,
asc_dvc_varp-err_code);
- if (asc_dvc_varp-err_code)
+ if (asc_dvc_varp-err_code) {
ret = -ENODEV;
+ kfree(asc_dvc_varp-overrun_buf);
+ }
}
} else {
if (advansys_wide_init_chip(shost))
@@ -13894,6 +13902,7 @@ static int advansys_release(struct Scsi_Host *shost)
dma_unmap_single(board-dev,
board-dvc_var.asc_dvc_var.overrun_dma,
ASC_OVERRUN_BSIZE, DMA_FROM_DEVICE);
+ kfree(board-dvc_var.asc_dvc_var.overrun_buf);
} else {
iounmap(board-ioremap_addr);
advansys_wide_free_mem(board);
--
1.5.3.8
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] advansys: fix overrun_buf aligned bug
On Fri, 2008-02-08 at 10:16 +0900, FUJITA Tomonori wrote:
On Thu, 07 Feb 2008 19:01:55 -0600
James Bottomley [EMAIL PROTECTED] wrote:
On Fri, 2008-02-08 at 09:50 +0900, FUJITA Tomonori wrote:
struct asc_dvc_var needs overrun buffer to be placed on an 8 byte
boundary. advansys defines struct asc_dvc_var:
struct asc_dvc_var {
...
uchar overrun_buf[ASC_OVERRUN_BSIZE] __aligned(8);
The problem is that struct asc_dvc_var is placed on
shost-hostdata. So if the hostdata is not on an 8 byte boundary, the
advansys crashes. The hostdata is placed on a sizeof(unsigned long)
boundary so the 8 byte boundary is not garanteed with x86_32.
With 2.6.23 and 2.6.24, the hostdata is on an 8 byte boundary by
chance, but with the current git, it's not.
This patch removes overrun_buf static array and use kzalloc.
It's a bit of a waste of a kmallocs. The usual way of fixing this type
of cockup is to float the structure until it becomes aligned, but I
suppose that involves changing all calls to shost_priv in the driver ...
Yeah, agreed. It's better but I'm not familiar with the driver so I
use kmalloc. It's not so bad as a short-term solution, I think.
Any chance to push it to final SCSI updates for 2.6.24 merge window?
Though we can push it any time since it's a bug fix.
Anyway, I'm fine with dropping it if Matthew will fix the driver in a
better way. I'm happy unless people blame my IOMMU or sense buffer
patch for this bug. :)
Sure, will do ... I think it's an OK interim fix.
James
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 07 Feb 2008 18:56:46 -0600 James Bottomley [EMAIL PROTECTED] wrote:
Quite a bit of this is fixing things broken previously (the advansys fix
is still pending resolution, but I'll send it as an -rc fix when we have
it). There's the final elimination of all drivers that are esp based
but don't use the scsi_esp core (that's mostly m68k and alpha). Plus
the usual bunch of driver updates and the addition of a new enclosure
services driver and the corresponding ULD.
Sob. Can we please merge Convert SG from nopage to fault? It has been
sent three times, the first time was Dec 5 last year and it has thus far
received the lead balloon treatment. Despite my explicit request for
consideration last time I sent it
If there is no movement here then I have to carry the moderately intrusive
mm-remove-nopage.patch for another N months and we need to watch out for
new -nopage implementations popping up etc.
From: Nick Piggin [EMAIL PROTECTED]
Convert SG from nopage to fault.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: Douglas Gilbert [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/sg.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff -puN drivers/scsi/sg.c~sg-nopage drivers/scsi/sg.c
--- a/drivers/scsi/sg.c~sg-nopage
+++ a/drivers/scsi/sg.c
@@ -1160,23 +1160,22 @@ sg_fasync(int fd, struct file *filp, int
return (retval 0) ? retval : 0;
}
-static struct page *
-sg_vma_nopage(struct vm_area_struct *vma, unsigned long addr, int *type)
+static int
+sg_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
Sg_fd *sfp;
- struct page *page = NOPAGE_SIGBUS;
unsigned long offset, len, sa;
Sg_scatter_hold *rsv_schp;
struct scatterlist *sg;
int k;
if ((NULL == vma) || (!(sfp = (Sg_fd *) vma-vm_private_data)))
- return page;
+ return VM_FAULT_SIGBUS;
rsv_schp = sfp-reserve;
- offset = addr - vma-vm_start;
+ offset = vmf-pgoff PAGE_SHIFT;
if (offset = rsv_schp-bufflen)
- return page;
- SCSI_LOG_TIMEOUT(3, printk(sg_vma_nopage: offset=%lu, scatg=%d\n,
+ return VM_FAULT_SIGBUS;
+ SCSI_LOG_TIMEOUT(3, printk(sg_vma_fault: offset=%lu, scatg=%d\n,
offset, rsv_schp-k_use_sg));
sg = rsv_schp-buffer;
sa = vma-vm_start;
@@ -1185,21 +1184,21 @@ sg_vma_nopage(struct vm_area_struct *vma
len = vma-vm_end - sa;
len = (len sg-length) ? len : sg-length;
if (offset len) {
+ struct page *page;
page = virt_to_page(page_address(sg_page(sg)) + offset);
get_page(page); /* increment page count */
- break;
+ vmf-page = page;
+ return 0; /* success */
}
sa += len;
offset -= len;
}
- if (type)
- *type = VM_FAULT_MINOR;
- return page;
+ return VM_FAULT_SIGBUS;
}
static struct vm_operations_struct sg_mmap_vm_ops = {
- .nopage = sg_vma_nopage,
+ .fault = sg_vma_fault,
};
static int
_
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 05/13] MegaRAID driver management char device moved tomisc
James, I acked this patch on 11/28. We are fine with the change proposed. Regards, Sumant -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Thursday, February 07, 2008 4:41 PM To: [EMAIL PROTECTED] Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED]; Kolli, Neela; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Patro, Sumant Subject: Re: [patch 05/13] MegaRAID driver management char device moved tomisc On Mon, 2008-02-04 at 23:53 -0800, [EMAIL PROTECTED] wrote: From: Thomas Horsten [EMAIL PROTECTED] The MegaRAID driver's common management module (megaraid_mm.c) creates a char device used by the management tool megarc from LSI Logic (and possibly other management tools). In 2.6 with udev, this device doesn't get created because it is not registered in sysfs. I first fixed this by registering a class megaraid_mm, but realized that this should probably be moved to misc devices, instead of taking up a char major. This is because only 1 device is used, even if there are multiple adapters - the minor is never used (the adapter info is in the ioctl block sent to the driver, not detected based on the minor number as one might think). So it is a complete waste to have an entire major taken by this. So it now uses a misc device which I named megadev0 (the name that megarc expects), and has a dynamic minor (previoulsy a dynamic major was used). I have tested this on my own system with the megarc tool, and it works just as fine as before (only now the device gets created correctly by udev). Cc: [EMAIL PROTECTED] Cc: Neela Syam Kolli [EMAIL PROTECTED] Cc: Ju, Seokmann [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Neela and Sekomann or Sumant, can I ping on this ... I've no idea what this will do to the raid management tools, so I really need someone to sign off on this. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 05/13] MegaRAID driver management char device moved tomisc
On Thu, 2008-02-07 at 19:47 -0700, Patro, Sumant wrote: James, I acked this patch on 11/28. Sorry about that ... that's in the window where my server dropped of the internet while I was on holiday, so I didn't get the email, I'm afraid We are fine with the change proposed. Great, will add it. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 7 Feb 2008, Andrew Morton wrote: Sob. Can we please merge Convert SG from nopage to fault? Heh. I just took it directly then. I think it's more of a VM patch than a SCSI patch anyway, so I don't think you really should even have tried to push it through the SCSI tree. It's not like we ever do the low-level FS changes for VFS issues through the FS maintainers anyway (ie you sent me all those iget/read_inode things directly rather than trying to go through each filesystem). I don't think this is any different, really. Linus - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 2008-02-07 at 18:46 -0800, Andrew Morton wrote: On Thu, 07 Feb 2008 18:56:46 -0600 James Bottomley [EMAIL PROTECTED] wrote: Quite a bit of this is fixing things broken previously (the advansys fix is still pending resolution, but I'll send it as an -rc fix when we have it). There's the final elimination of all drivers that are esp based but don't use the scsi_esp core (that's mostly m68k and alpha). Plus the usual bunch of driver updates and the addition of a new enclosure services driver and the corresponding ULD. Sob. Can we please merge Convert SG from nopage to fault? It has been sent three times, the first time was Dec 5 last year and it has thus far received the lead balloon treatment. Despite my explicit request for consideration last time I sent it If there is no movement here then I have to carry the moderately intrusive mm-remove-nopage.patch for another N months and we need to watch out for new -nopage implementations popping up etc. I agree ... I've pinged Doug privately, this is publicly. Unfortunately, it is an intrusive change and needs testing .. I just don't have the tools that do this for SG. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 10/18] sg: nopage
For the patch shown below:
Signed-off-by: Douglas Gilbert [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Convert SG from nopage to fault.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org
Cc: [EMAIL PROTECTED]
---
drivers/scsi/sg.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
Index: linux-2.6/drivers/scsi/sg.c
===
--- linux-2.6.orig/drivers/scsi/sg.c
+++ linux-2.6/drivers/scsi/sg.c
@@ -1144,23 +1144,22 @@ sg_fasync(int fd, struct file *filp, int
return (retval 0) ? retval : 0;
}
-static struct page *
-sg_vma_nopage(struct vm_area_struct *vma, unsigned long addr, int *type)
+static int
+sg_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
Sg_fd *sfp;
- struct page *page = NOPAGE_SIGBUS;
unsigned long offset, len, sa;
Sg_scatter_hold *rsv_schp;
struct scatterlist *sg;
int k;
if ((NULL == vma) || (!(sfp = (Sg_fd *) vma-vm_private_data)))
- return page;
+ return VM_FAULT_SIGBUS;
rsv_schp = sfp-reserve;
- offset = addr - vma-vm_start;
+ offset = vmf-pgoff PAGE_SHIFT;
if (offset = rsv_schp-bufflen)
- return page;
- SCSI_LOG_TIMEOUT(3, printk(sg_vma_nopage: offset=%lu, scatg=%d\n,
+ return VM_FAULT_SIGBUS;
+ SCSI_LOG_TIMEOUT(3, printk(sg_vma_fault: offset=%lu, scatg=%d\n,
offset, rsv_schp-k_use_sg));
sg = rsv_schp-buffer;
sa = vma-vm_start;
@@ -1169,21 +1168,21 @@ sg_vma_nopage(struct vm_area_struct *vma
len = vma-vm_end - sa;
len = (len sg-length) ? len : sg-length;
if (offset len) {
+ struct page *page;
page = virt_to_page(page_address(sg_page(sg)) + offset);
get_page(page); /* increment page count */
- break;
+ vmf-page = page;
+ return 0; /* success */
}
sa += len;
offset -= len;
}
- if (type)
- *type = VM_FAULT_MINOR;
- return page;
+ return VM_FAULT_SIGBUS;
}
static struct vm_operations_struct sg_mmap_vm_ops = {
- .nopage = sg_vma_nopage,
+ .fault = sg_vma_fault,
};
static int
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 07 Feb 2008 19:37:07 -0600 James Bottomley [EMAIL PROTECTED] wrote: On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote: Quite a bit of this is fixing things broken previously (the advansys fix is still pending resolution, but I'll send it as an -rc fix when we have it). There's the final elimination of all drivers that are esp based but don't use the scsi_esp core (that's mostly m68k and alpha). Plus the usual bunch of driver updates and the addition of a new enclosure services driver and the corresponding ULD. OK, the advansys fix came in. I've added it to the patch. James From f983323fea178352ed3b69c70561a13825a3ce59 Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori [EMAIL PROTECTED] Date: Fri, 8 Feb 2008 09:50:08 +0900 Subject: [SCSI] advansys: fix overrun_buf aligned bug Seems that it was a bit late, Linus pulled scsi-misc before the patch was added. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, Feb 07, 2008 at 07:11:33PM -0800, Linus Torvalds wrote: On Thu, 7 Feb 2008, Andrew Morton wrote: Sob. Can we please merge Convert SG from nopage to fault? Heh. I just took it directly then. I think it's more of a VM patch than a SCSI patch anyway, so I don't think you really should even have tried to push it through the SCSI tree. It's not like we ever do the low-level FS changes for VFS issues through the FS maintainers anyway (ie you sent me all those iget/read_inode things directly rather than trying to go through each filesystem). I don't think this is any different, really. Yes. For -faul Nick should just have sent on the whole batch after giving fs/driver people enough time to review it. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/7] blk_end_request: full I/O completion handler
Hi, Thanks for the information! We would like to know when does the 2.6.25 kernel will be available at kernel.org. Thanks, Chandrakala -Original Message- From: Jens Axboe [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 05, 2008 4:09 PM To: S, Chandrakala (STSD) Cc: Kiyoshi Ueda; [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; [EMAIL PROTECTED]; Miller, Mike (OS Dev); [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [PATCH 0/7] blk_end_request: full I/O completion handler On Tue, Feb 05 2008, S, Chandrakala (STSD) wrote: Hello, We would like to know in which kernel version these patches are available. They were merged after 2.6.24 was released, so they will show up in the 2.6.25 kernel. -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers
On Thu, Jan 31, 2008 at 01:31:56PM -0600, James Bottomley wrote: Is git smart enough to follow history between files that get removed and readded? Yes. git revert on the removal changeset will re-add all the files and try to put the entries back into Kconfig and Makefile. Note that it doesn't really matter. Looking at the existing conversion there's been no line left the same except for the standard #include statements. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 9769] CONFIG_SCSI_WAIT_SCAN configure error
http://bugzilla.kernel.org/show_bug.cgi?id=9769 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED], ||[EMAIL PROTECTED] --- Comment #1 from [EMAIL PROTECTED] 2008-02-07 23:28 --- This appears to be a dependency, but these are not dependent defines. CONFIG_SCSI_SCAN_ASYNC defines the default scan type, which can be overridden by the module parameter. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
