[2.6 patch] drivers/scsi/dpti.h: remove kernel 2.2 #if's
This patch removes #if's for kernel 2.2 . Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/scsi/dpti.h | 10 -- 1 files changed, 10 deletions(-) --- linux-2.6.11-mm2-full/drivers/scsi/dpti.h.old 2005-03-12 12:22:23.0 +0100 +++ linux-2.6.11-mm2-full/drivers/scsi/dpti.h 2005-03-12 12:22:46.0 +0100 @@ -20,15 +20,9 @@ #ifndef _DPT_H #define _DPT_H -#ifndef LINUX_VERSION_CODE #include -#endif -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,00) -#define MAX_TO_IOP_MESSAGES (210) -#else #define MAX_TO_IOP_MESSAGES (255) -#endif #define MAX_FROM_IOP_MESSAGES (255) @@ -321,10 +313,6 @@ static void adpt_delay(int millisec); #endif -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0) -static struct pci_dev* adpt_pci_find_device(uint vendor, struct pci_dev* from); -#endif - #if defined __ia64__ static void adpt_ia64_info(sysInfo_S* si); #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
Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
Alex Aizman wrote: This is to announce Open-iSCSI project: High-Performance iSCSI Initiator for Linux. MOTIVATION == Our initial motivations for the project were: (1) implement the right user/kernel split, and (2) design iSCSI data path for performance. Recently we added (3): get accepted into the mainline kernel. As far as user/kernel, the existing iSCSI initiators bloat the kernel with ever-growing control plane code, including but not limited to: iSCSI discovery, Login (Authentication and Operational), session and connection management, connection-level error processing, iSCSI Text, Nop-Out/In, Async Message, iSNS, SLP, Radius... Open-iSCSI puts the entire control plane in the user space. This control plane talks to the data plane via well defined interface over the netlink transport. (Side note: prior to closing on the netlink we considered: sysfs, ioctl, and syscall. Because the entire control plane logic resides in the user space, we needed a real bi-directional transport that could support asynchronous API to transfer iSCSI control PDUs: Login, Logout, Nop-in, Nop-Out, Text, Async Message. Performance. This is the major goal and motivation for this project. As it happens, iSCSI has to compete with Fibre Channel, which is a more entrenched technology in the storage space. In addition, the "soft" iSCSI implementation have to show good results in presence of specialized hardware offloads. Our today's performance numbers are: - 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block size); - 320MB/sec Write on a single connection (2-way 2.4Ghz Opteron, 64KB block size); - 50,000 Read IOPS on a single connection (2-way 2.4Ghz Opteron, 4KB block size). Has anyone on the list verified these #'s? I'm trying to get open-iscsi to work but it looks like it's got a problem in the very initial stages of lun scanning that prevents my target from working. Open-iscsi guys I have a trace if you want to look at it. Looks like despite the fact that report luns is returned successfully and only 1 lun is returned (lun 0), the initiator is still sending inquiry commands to luns > 0, and it looks like it gets confused when it gets a 0x3f inquiry response from the target (for an inquiry to lun 1), tries to issue a TMF abort task on the previous inquiry which has already completed, and the target responds with "task not in task set", which is understandable since the command has already completed. I used the latest .169 code. I don't see this problem with the latest linux-iscsi.sfnet code and have interoperated with many other initiators, so I'm fairly confident there's a bug in open-iscsi somewhere. Prior to starting from-scratch the data path code we did evaluate the sfnet Initiator. And eventually decided against patching it. Instead, we reused its Discovery, Login, etc. control plane code. Technically, it was the shortest way to achieve the (1) and (2) goals stated above. We believe that it remains the easiest and the most practical thing on the larger scale of: iSCSI for Linux. STATUS == There's a 100% working code that interoperates with all (count=5) iSCSI targets we could get our hands on. The software was tested on AMD Opteron (TM) and Intel Xeon (TM). Code is available online via either Subversion source control database or the latest development release (i.e., the tarball containing Open-iSCSI sources, including user space, that will build and run on kernels starting 2.6.10). http://www.open-iscsi.org Features: - highly optimized and small-footprint data path; - multiple outstanding R2Ts; - thread-less receive; - sendpage() based transmit; - zero-copy header processing on receive; - no data path memory allocations at runtime; - persistent configuration database; - SendTargets discovery; - CHAP; - DataSequenceInOrder=No; - PDU header Digest; - multiple sessions; - MC/S (note: disabled in the patch); - SCSI-level recovery via Abort Task and session re-open. TODO The near term plan is: test, test, and test. We need to stabilize the existing code, after 5 months of development this seems to be the right thing to do. Other short-term plans include: a) process community feedback, implement comments and apply patches; b) cleanup user side of the iSCSI open interface; use API calls (instead of directly constructing events); c) eliminate runtime control path memory allocations (for Nop-In, Nop-Out, etc.); d) implement Write path optimizations (delayed because of the self-imposed submission deadline); e) oProfile the data path, use the reports for further optimization; f) complete the readme. Comments, code reviews, patches - are greatly appreciated! THANKS == Special thanks to our first reviewers: Christoph Hellwig and Mike Christie. Special thanks to Ming Zhang for help in testing and for insightful questions. Regards, Alex Aizman & Dmitry Yusupov ===
[PATCH 1/2] SCSI tape fixes (new version): sense descriptor init, bsf->weof, blkno, debugging
This is an updated version of the patch I sent March 7. The sense descriptor
initialization has been made lighter.
The patch at the end of this message applies to 2.6.11-bk7 + st descriptor sense
patch + st auto eof patch (i.e., st patches currently in scsi-misc-2.6). The
patch fixes the following problems:
- the sense descriptor fields are properly initialized
- BSF and BSFM are added to the commands causing automatic writing of filemark
if the previous operation was write (tar expects this)
- the block number is set to unknown (-1) if spacing forward ends at BLANK CHECK
- debugging printout of spacing counts fixed to work also with 64-bit systems
Signed-off-by: Kai Makisara <[EMAIL PROTECTED]>
--- linux-2.6.11-bk7-k1/drivers/scsi/st.c 2005-03-12 13:38:32.0
+0200
+++ linux-2.6.11-bk7-k2/drivers/scsi/st.c 2005-03-12 13:52:30.0
+0200
@@ -17,7 +17,7 @@
Last modified: 18-JAN-1998 Richard Gooch <[EMAIL PROTECTED]> Devfs support
*/
-static char *verstr = "20050213";
+static char *verstr = "20050312";
#include
@@ -269,8 +269,10 @@ static void st_analyze_sense(struct scsi
const u8 *sense = SRpnt->sr_sense_buffer;
s->have_sense = scsi_request_normalize_sense(SRpnt, &s->sense_hdr);
+ s->flags = 0;
if (s->have_sense) {
+ s->deferred = 0;
s->remainder_valid =
scsi_get_sense_info_fld(sense, SCSI_SENSE_BUFFERSIZE,
&s->uremainder64);
switch (sense[0] & 0x7f) {
@@ -287,8 +289,6 @@ static void st_analyze_sense(struct scsi
ucp = scsi_sense_desc_find(sense,
SCSI_SENSE_BUFFERSIZE, 4);
s->flags = ucp ? (ucp[3] & 0xe0) : 0;
break;
- default:
- s->flags = 0;
}
}
}
@@ -306,7 +306,7 @@ static int st_chk_result(struct scsi_tap
if (!result)
return 0;
- cmdstatp = &STp->buffer->cmdstat;
+ cmdstatp = &STp->buffer->cmdstat;
st_analyze_sense(STp->buffer->last_SRpnt, cmdstatp);
if (cmdstatp->have_sense)
@@ -2413,6 +2413,22 @@ static int do_load_unload(struct scsi_ta
return retval;
}
+#if DEBUG
+#define ST_DEB_FORWARD 0
+#define ST_DEB_BACKWARD 1
+static void deb_space_print(char *name, int direction, char *units, unsigned
char *cmd)
+{
+ s32 sc;
+
+ sc = cmd[2] & 0x80 ? 0xff00 : 0;
+ sc |= (cmd[2] << 16) | (cmd[3] << 8) | cmd[4];
+ if (direction)
+ sc = -sc;
+ printk(ST_DEB_MSG "%s: Spacing tape %s over %d %s.\n", name,
+ direction ? "backward" : "forward", sc, units);
+}
+#endif
+
/* Internal ioctl function */
static int st_int_ioctl(struct scsi_tape *STp, unsigned int cmd_in, unsigned
long arg)
@@ -2451,8 +2467,7 @@ static int st_int_ioctl(struct scsi_tape
cmd[2] = (arg >> 16);
cmd[3] = (arg >> 8);
cmd[4] = arg;
-DEBC(printk(ST_DEB_MSG "%s: Spacing tape forward over %d
filemarks.\n",
- name, cmd[2] * 65536 + cmd[3] * 256 + cmd[4]));
+DEBC(deb_space_print(name, ST_DEB_FORWARD, "filemarks", cmd);)
if (fileno >= 0)
fileno += arg;
blkno = 0;
@@ -2467,14 +2482,7 @@ static int st_int_ioctl(struct scsi_tape
cmd[2] = (ltmp >> 16);
cmd[3] = (ltmp >> 8);
cmd[4] = ltmp;
-DEBC(
- if (cmd[2] & 0x80)
- ltmp = 0xff00;
- ltmp = ltmp | (cmd[2] << 16) | (cmd[3] << 8) | cmd[4];
- printk(ST_DEB_MSG
-"%s: Spacing tape backward over %ld filemarks.\n",
-name, (-ltmp));
- )
+DEBC(deb_space_print(name, ST_DEB_BACKWARD, "filemarks", cmd);)
if (fileno >= 0)
fileno -= arg;
blkno = (-1); /* We can't know the block number */
@@ -2486,8 +2494,7 @@ static int st_int_ioctl(struct scsi_tape
cmd[2] = (arg >> 16);
cmd[3] = (arg >> 8);
cmd[4] = arg;
-DEBC(printk(ST_DEB_MSG "%s: Spacing tape forward %d
blocks.\n", name,
- cmd[2] * 65536 + cmd[3] * 256 + cmd[4]));
+DEBC(deb_space_print(name, ST_DEB_FORWARD, "blocks", cmd);)
if (blkno >= 0)
blkno += arg;
at_sm &= (arg == 0);
@@ -2499,13 +2506,7 @@ static int st_int_ioctl(struct scsi_tape
[PATCH 2/2] SCSI tape fixes: remove f_pos handling
This patch applies over the previous patch in this thread. The patch removes
updating filp->f_pos. It has been dead code since 2.6.8 and nobody has missed
it.
Signed-off-by: Kai Makisara <[EMAIL PROTECTED]>
--- linux-2.6.11-bk7-k2/drivers/scsi/st.c 2005-03-12 13:52:30.0
+0200
+++ linux-2.6.11-bk7-k3/drivers/scsi/st.c 2005-03-12 18:11:11.0
+0200
@@ -1156,9 +1156,7 @@ static int st_flush(struct file *filp)
if (STps->rw == ST_WRITING && !STp->pos_unknown) {
struct st_cmdstatus *cmdstatp = &STp->buffer->cmdstat;
-DEBC(printk(ST_DEB_MSG "%s: File length %lld bytes.\n",
-name, (long long)filp->f_pos);
- printk(ST_DEB_MSG "%s: Async write waits %d, finished
%d.\n",
+DEBC(printk(ST_DEB_MSG "%s: Async write waits %d, finished
%d.\n",
name, STp->nbr_waits, STp->nbr_finished);
)
@@ -1520,7 +1518,6 @@ st_write(struct file *filp, const char _
}
}
count -= do_count;
- filp->f_pos += do_count;
b_point += do_count;
async_write = STp->block_size == 0 && !STbp->do_dio &&
@@ -1580,7 +1577,6 @@ st_write(struct file *filp, const char _
undone = 0;
if (STp->block_size != 0)
undone *= STp->block_size;
- filp->f_pos -= undone;
if (undone <= do_count) {
/* Only data from this write is not
written */
count += undone;
@@ -1629,7 +1625,6 @@ st_write(struct file *filp, const char _
}
}
} else {
- filp->f_pos -= do_count;
count += do_count;
STps->drv_block = (-1); /* Too
cautious? */
retval = (-EIO);
@@ -1958,7 +1953,6 @@ st_read(struct file *filp, char __user *
goto out;
}
}
- filp->f_pos += transfer;
buf += transfer;
total += transfer;
}
-
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: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
On Sat, 2005-03-12 at 11:55 -0500, Dave Wysochanski wrote: > Alex Aizman wrote: > > > > > This is to announce Open-iSCSI project: High-Performance iSCSI > > Initiator for > > Linux. > > > > MOTIVATION > > == > > > > Our initial motivations for the project were: (1) implement the right > > user/kernel split, and (2) design iSCSI data path for performance. > > Recently > > we added (3): get accepted into the mainline kernel. > > > > As far as user/kernel, the existing iSCSI initiators bloat the kernel > > with > > ever-growing control plane code, including but not limited to: iSCSI > > discovery, Login (Authentication and Operational), session and connection > > management, connection-level error processing, iSCSI Text, Nop-Out/In, > > Async > > Message, iSNS, SLP, Radius... Open-iSCSI puts the entire control plane in > > the user space. This control plane talks to the data plane via well > > defined > > interface over the netlink transport. > > > > (Side note: prior to closing on the netlink we considered: sysfs, > > ioctl, and > > syscall. Because the entire control plane logic resides in the user > > space, > > we needed a real bi-directional transport that could support asynchronous > > API to transfer iSCSI control PDUs: Login, Logout, Nop-in, Nop-Out, Text, > > Async Message. > > > > Performance. > > This is the major goal and motivation for this project. As it happens, > > iSCSI > > has to compete with Fibre Channel, which is a more entrenched > > technology in > > the storage space. In addition, the "soft" iSCSI implementation have > > to show > > good results in presence of specialized hardware offloads. > > > > Our today's performance numbers are: > > > > - 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block > > size); > > > > - 320MB/sec Write on a single connection (2-way 2.4Ghz Opteron, 64KB > > block > > size); > > > > - 50,000 Read IOPS on a single connection (2-way 2.4Ghz Opteron, 4KB > > block > > size). > > > Has anyone on the list verified these #'s? as far I know, no one tried that but me. We've used disktest with O_DIRECT flag set on 10Gbps network with jumbo frames enabled and big big big TCP window & socket buffer. I really would like to see that this number gets reproduced not on my setup only. > I'm trying to > get open-iscsi to work but it looks like it's got a problem > in the very initial stages of lun scanning that prevents > my target from working. Open-iscsi guys I have a trace > if you want to look at it. Looks like despite the fact that > report luns is returned successfully and only 1 lun is > returned (lun 0), the initiator is still sending inquiry > commands to luns > 0, and it looks like it gets confused > when it gets a 0x3f inquiry response from the target > (for an inquiry to lun 1), tries to issue a TMF abort > task on the previous inquiry which has already completed, > and the target responds with "task not in task set", which > is understandable since the command has already completed. > I used the latest .169 code. its too old anyways. try subversion's repository. but I doubt it will help in your case. > I don't see this problem with the latest linux-iscsi.sfnet > code and have interoperated with many other initiators, > so I'm fairly confident there's a bug in open-iscsi somewhere. i'm pretty sure it is a bug in open-iscsi. which target are you using? can we get remote access? > > > Prior to starting from-scratch the data path code we did evaluate the > > sfnet > > Initiator. And eventually decided against patching it. Instead, we reused > > its Discovery, Login, etc. control plane code. > > Technically, it was the shortest way to achieve the (1) and (2) goals > > stated > > above. We believe that it remains the easiest and the most practical > > thing > > on the larger scale of: iSCSI for Linux. > > > > > > STATUS > > == > > > > There's a 100% working code that interoperates with all (count=5) iSCSI > > targets we could get our hands on. > > > > The software was tested on AMD Opteron (TM) and Intel Xeon (TM). > > > > Code is available online via either Subversion source control database or > > the latest development release (i.e., the tarball containing Open-iSCSI > > sources, including user space, that will build and run on kernels > > starting > > 2.6.10). > > > > http://www.open-iscsi.org > > > > Features: > > > > - highly optimized and small-footprint data path; > > - multiple outstanding R2Ts; > > - thread-less receive; > > - sendpage() based transmit; > > - zero-copy header processing on receive; > > - no data path memory allocations at runtime; > > - persistent configuration database; > > - SendTargets discovery; > > - CHAP; > > - DataSequenceInOrder=No; > > - PDU header Digest; > > - multiple sessions; > > - MC/S (note: disabled in the patch); > > - SCSI-level recovery via Abort Task and session re-open. > > > > > > TODO > > ==
sym-2.1.18j Phase Change 6-7
I didn't find anyone else reporting this issue on linux-scsi. Actually, i have only found some fedora core users experiencing the same problem and reporting it (see https://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=139949), although the problem doesnt appear to be redhat-specific (i 've tried it with slackware). Pardon me if this is a known bug, i am first-time poster on this list. I have been giving it a shot with vanilla kernel sources (straight from kernel.org 2.6.9, 2.6.10, 2.6.11), and the error persists. 2.6.11.1 and 2.6.11.2 dont have any changes in SCSI that would affect the sym driver in their tiny changelog, so i havent tried them yet. The box is a dual i386, but i 've also been running non-SMP kernels for my tests, producing the same results. My controller shows up like this in `lspci -v`: 01:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) Flags: bus master, medium devsel, latency 72, IRQ 24 I/O ports at e400 [size=256] Memory at febfe000 (64-bit, non-prefetchable) [size=1K] Memory at febfa000 (64-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 When i run 2.6.9, 2.6.10 or 2.6.11, the sym kernel module produces massive amounts of syslog traffic and logs. The message in syslog looks like this: kernel: sym0:0:0:phase change 6-7 11 2e37a784 resid=6. As a temporary solution to overcome this and do my performance tests, i just adjusted syslogd on that server not to log any kern messages from syslog.conf. Still, performance degrades on my 10K rpm harddrives at 3mb/sec. In my humble opinion(i am not a kernel developer or expert), it appears that some changes done in the code for scsi (API?) in the linux kernel tree, were not correctly implemented in the sym driver. The controller works fine with 2.6.8.1(vanilla). Anything later than 2.6.8.1 in my tests, was prone to these errors and the performance degrade. Has anyone else experienced this issue? Are there any steps i can take(hopefully a patch?) that would fix it? thank you all, Jackie. - 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: kernel 2.6.11.2 / megaraid 2.20.4.5 and /proc question
> >With the 2.6.7 kernel there used to be information in /proc/megaraid. >I do not see the same information using the 2.6.11.2 kernel. >Is there anything in /proc using the 2.6.11.2 kernel setup ? >If not there, then anywhere else ? > It is not so much that you had /proc/megaraid in 2.6.7. There are two distinct series of drivers - megaraid 2.10 and megaraid_mbox 2.20 series. The 2.10 series are intended to be used on 2.4 kernels and 2.20 on 2.6 kernels. The megaraid_mbox (2.20) driver does not export any /proc information. You were using 2.00.3 (part of 2.10 series) on 2.6 kernel which is not really meant to be used that way. >Also, where might I find information on to forward errors >detected bythe >adapter. e.g send mail to an account > I don't fully understand the question. You may want to send a mail to customer service. >Thanks, >Atul >- Thanks, Sreenivas LSI Logic Corporation - 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: sym-2.1.18j Phase Change 6-7
On 13/03/2005, at 5:40, Jackie Ferrera wrote: I didn't find anyone else reporting this issue on linux-scsi. I reported this problem back on November 17, 2004, but got no interest from the list. Actually, i have only found some fedora core users experiencing the same problem and reporting it (see https://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=139949), although the problem doesnt appear to be redhat-specific (i 've tried it with slackware). Pardon me if this is a known bug, i am first-time poster on this list. I have been giving it a shot with vanilla kernel sources (straight from kernel.org 2.6.9, 2.6.10, 2.6.11), and the error persists. 2.6.11.1 and 2.6.11.2 dont have any changes in SCSI that would affect the sym driver in their tiny changelog, so i havent tried them yet. The box is a dual i386, but i 've also been running non-SMP kernels for my tests, producing the same results. My controller shows up like this in `lspci -v`: 01:05.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1010 Ultra3 SCSI Adapter (rev 01) Flags: bus master, medium devsel, latency 72, IRQ 24 I/O ports at e400 [size=256] Memory at febfe000 (64-bit, non-prefetchable) [size=1K] Memory at febfa000 (64-bit, non-prefetchable) [size=8K] Capabilities: [40] Power Management version 2 When i run 2.6.9, 2.6.10 or 2.6.11, the sym kernel module produces massive amounts of syslog traffic and logs. The message in syslog looks like this: kernel: sym0:0:0:phase change 6-7 11 2e37a784 resid=6. As a temporary solution to overcome this and do my performance tests, i just adjusted syslogd on that server not to log any kern messages from syslog.conf. Still, performance degrades on my 10K rpm harddrives at 3mb/sec. In my humble opinion(i am not a kernel developer or expert), it appears that some changes done in the code for scsi (API?) in the linux kernel tree, were not correctly implemented in the sym driver. The problems with the phase change errors seemed to have been fixed for me when I patched the 2.6.10 kernel with the sym_2.1.18n patch released by Mathew Wilcox on December 30. Though this was incorporated in the 2.6.11 kernel, so your issues may be different. All my tests were with kernel.org sources without any distribution specific patches. The controller works fine with 2.6.8.1(vanilla). Anything later than 2.6.8.1 in my tests, was prone to these errors and the performance degrade. Has anyone else experienced this issue? Are there any steps i can take(hopefully a patch?) that would fix it? Try patching 2.6.11.2 with sym2_2.2.0 released yesterday, perhaps? Good luck Mark Vitnell - 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
[no subject]
Sun, 13 Mar 2005 01:37:09 + - 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
