sense visible despite ide-floppy in 2.6 maybe

sense visible despite ide-floppy in 2.6 maybe

[Pat LaVarre]

Doug G:

Did I do something wrong, or does "everyone know" already,

SCSI pass thru in 2.6 omits ide-floppy, except if we do resort to the
ide-scsi deprecated there?

Or more specifically,

Can ioctl SG_IO fetch the offset 7 Additional Length field of op x03
"REQUEST SENSE" data?

Naively I thought yes of course, I know that works with /dev/scd$n.

But then I tried a /dev/hd$v ide-floppy.  No joy.  perror tells me ioctl
SG_IO fails via "Invalid argument", dmesg has no comment.  sg_scan you
know.  ~/bin/sgio source is the trivial exercise quoted in source far
below, specifically with an O_NONBLOCK|O_RDWR open as you can see.

$ sudo sg3_utils-1.06/sg_scan /dev/hdd /dev/scd0
sg_scan: device /dev/hdd failed on scsi ioctl, skip: Input/output error
/dev/scd0: scsi0 channel=0 id=0 lun=0 [em]
$
$ sudo ~/bin/sgio /dev/hdd /dev/scd0 | strings
ioctl SG_IO: Invalid argument
Iomega  RRD             74.B
$

$ uname -srm
Linux 2.6.7-rc2 i686
$ lsmod | grep ide
ide_floppy             17664  0
$ sudo mount /dev/hdd /mnt/hdd
$ sudo umount /dev/hdd
$ alias xstrings="tr -d ' \r\n' | perl -wpe 's/(..)/chr hex \$1/eg' |
strings"
$ sudo cat /proc/ide/hdd/identify | xstrings
803048B34F460C1E
25.Q    IOMEGA  ZIP 250       ATAPI
(c) Copyright IOMEGA 2002
601//320
$

Pat LaVarre

P.S. I fell into trying all this when a friend not yet living in Linux
noticed my recent linux-ide report of a SATAPI host choking over an
available sense length rudely not aligned to four bytes.

----- ~/bin/sgio.c

#include <fcntl.h>
#include <scsi/sg.h>
#include <stdio.h>
#include <sys/ioctl.h>
#include <string.h>
#include <unistd.h>

static unsigned char static_cdb[0x100];
static unsigned char static_data[0x1000];
static unsigned char static_sense[0x100];

static void populate(sg_io_hdr_t * sih)
{
	memset(sih, '\0', sizeof *sih);
	sih->interface_id = 'S';

	memset(&static_cdb, '\0', sizeof static_cdb);
	sih->cmdp = static_cdb;
	sih->cmd_len = 6;
	memcpy(sih->cmdp, "\x12\0\0\0\x24\0", sih->cmd_len);

	memset(&static_data, '\0', sizeof static_data);
	sih->dxferp = static_data;
	sih->dxfer_len = 0x24;
	sih->dxfer_direction = SG_DXFER_NONE;
	sih->dxfer_direction = SG_DXFER_TO_DEV;
	sih->dxfer_direction = SG_DXFER_FROM_DEV;

	memset(&static_sense, '\0', sizeof static_sense);
	sih->sbp = static_sense;
	sih->mx_sb_len = 0x12; /* SATAPI may need 4 byte alignment */
	sih->timeout = 30 * 1000; /* ms */

	; /* sih->iovec_count sih->flags sih->pack_id sih->usr_ptr */
	; /* sih->status sih->masked_status sih->msg_status */
	; /* sih->sb_len_wr sih->host_status sih->drive_status */
	; /* sih->resid sih->duration sih->info */
}

static void talk(int fd)
{
	static sg_io_hdr_t static_sih;
	sg_io_hdr_t * sih = &static_sih;
	int ii;
	populate(sih);
	ii = ioctl(fd, SG_IO, sih);
	if (ii < 0) {
		perror("ioctl SG_IO");
	} else {
		fwrite(sih->dxferp, sih->dxfer_len, 1, stdout);
		if ((sih->info & SG_INFO_OK_MASK) != SG_INFO_OK) {
			fprintf(stderr, "x %X %X %X\n",
				sih->info, sih->resid, sih->sb_len_wr);
		}
	}
}

int main(int argc, char * argv[])
{
	int ix = 0;
	--argc; ++argv;
	for (ix = 0; ix < argc; ++ix)
	{
		int fd = open(argv[ix], O_NONBLOCK|O_RDWR);
		if (fd < 0) {
			perror("open");
		} else {
			int vn = 0;
			if (0 <= ioctl(fd, SG_GET_VERSION_NUM, &vn)) {
				if (vn < 30000) {
					perror("ioctl SG_GET_VERSION_NUM");
					continue;
				}
			}
			talk(fd);
			close(fd);
		}
	}
	return 0;
}

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Tue, Jun 08 2004, Pat LaVarre wrote:
> Doug G:
> 
> Did I do something wrong, or does "everyone know" already,
> 
> SCSI pass thru in 2.6 omits ide-floppy, except if we do resort to the
> ide-scsi deprecated there?
> 
> Or more specifically,
> 
> Can ioctl SG_IO fetch the offset 7 Additional Length field of op x03
> "REQUEST SENSE" data?
> 
> Naively I thought yes of course, I know that works with /dev/scd$n.
> 
> But then I tried a /dev/hd$v ide-floppy.  No joy.  perror tells me ioctl
> SG_IO fails via "Invalid argument", dmesg has no comment.  sg_scan you
> know.  ~/bin/sgio source is the trivial exercise quoted in source far
> below, specifically with an O_NONBLOCK|O_RDWR open as you can see.

Hmm fudge. There are two problems - first you need to pass through SG_IO
ioctl from the ide layer, ide-cd gets it through cdrom.c currently.
That's the easy part, attached.

Secondly, you need to map struct request to a idefloppy_pc_t packet
command. Currently it just passes through START_STOP, it could in fact
handle any request that doesn't carry data though:

idefloppy_blockpc_cmd()
{
	if (rq->data_len)
		return 1;
	if (rq->cmd_len > sizeof(pc->c))
		return 1;

	idefloppy_init_pc(pc);
	memcpy(pc->c, rq->cmd, sizeof(pc->c));
	return 0;
}

For data transfer, it's more tricky. Well actually, if you restrict
yourself to non-bio backed request, then it becomes pretty trivial!
ide-floppy expects a contig buffer, a bio is scattered by nature.

-- 
Jens Axboe

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Wed, Jun 09 2004, Jens Axboe wrote:
> For data transfer, it's more tricky. Well actually, if you restrict
> yourself to non-bio backed request, then it becomes pretty trivial!
> ide-floppy expects a contig buffer, a bio is scattered by nature.

Since it handles REQ_CMD just fine (*), this should actually just work.
Pat, can you test if it does?

* Scattered handling if dma fails looks very fishy, should be audited.

===== drivers/ide/ide.c 1.149 vs edited =====
--- 1.149/drivers/ide/ide.c	2004-06-04 21:14:59 +02:00
+++ edited/drivers/ide/ide.c	2004-06-09 10:07:46 +02:00
@@ -153,6 +153,7 @@
 #include <linux/cdrom.h>
 #include <linux/seq_file.h>
 #include <linux/device.h>
+#include <scsi/sg.h>
 
 #include <asm/byteorder.h>
 #include <asm/irq.h>
@@ -1605,6 +1606,7 @@
 
 		case CDROMEJECT:
 		case CDROMCLOSETRAY:
+		case SG_IO:
 			return scsi_cmd_ioctl(bdev->bd_disk, cmd, p);
 
 		case HDIO_GET_BUSSTATE:
===== drivers/ide/ide-floppy.c 1.39 vs edited =====
--- 1.39/drivers/ide/ide-floppy.c	2004-06-04 06:12:07 +02:00
+++ edited/drivers/ide/ide-floppy.c	2004-06-09 10:19:48 +02:00
@@ -1210,19 +1210,23 @@
 	set_bit(PC_DMA_RECOMMENDED, &pc->flags);
 }
 
-static int
+static void
 idefloppy_blockpc_cmd(idefloppy_floppy_t *floppy, idefloppy_pc_t *pc, struct request *rq)
 {
-	/*
-	 * just support eject for now, it would not be hard to make the
-	 * REQ_BLOCK_PC support fully-featured
-	 */
-	if (rq->cmd[0] != IDEFLOPPY_START_STOP_CMD)
-		return 1;
-
 	idefloppy_init_pc(pc);
+	pc->callback = &idefloppy_rw_callback;
 	memcpy(pc->c, rq->cmd, sizeof(pc->c));
-	return 0;
+	pc->rq = rq;
+	pc->b_count = rq->data_len;
+	if (rq_data_dir(rq) == WRITE)
+		set_bit(PC_WRITING, &pc->flags);
+	pc->buffer = NULL;
+	/*
+	 * possibly problematic, doesn't look like ide-floppy correctly
+	 * handled scattered requests if dma fails...
+	 */
+	pc->request_transfer = pc->buffer_size = rq->data_len;
+	set_bit(PC_DMA_RECOMMENDED, &pc->flags);
 }
 
 /*
@@ -1267,10 +1271,7 @@
 		pc = (idefloppy_pc_t *) rq->buffer;
 	} else if (rq->flags & REQ_BLOCK_PC) {
 		pc = idefloppy_next_pc_storage(drive);
-		if (idefloppy_blockpc_cmd(floppy, pc, rq)) {
-			idefloppy_do_end_request(drive, 0, 0);
-			return ide_stopped;
-		}
+		idefloppy_blockpc_cmd(floppy, pc, rq);
 	} else {
 		blk_dump_rq_flags(rq,
 			"ide-floppy: unsupported command in queue");

-- 
Jens Axboe

Re: sense visible despite ide-floppy in 2.6 maybe

[Pat LaVarre]

> Hmm fudge.

Sorry, this English I do not understand.

> --- 1.149/drivers/ide/ide.c     2004-06-04 21:14:59 +02:00
> +++ edited/drivers/ide/ide.c    2004-06-09 10:07:46 +02:00

Patch!  Cool, thank you.

> Pat, can you test

Gladly.  Unless redirected, I will try combining:

a) kernel.org 2.6.7-rc3 plus the patch of this thread,
b) PATAPI drive connected as /dev/hdd,
c) open of /dev/hdd with flags O_NONBLOCK|O_RDWR, ioctl SG_IO
d) cdb = x 1B 00:00:00 00 00 // Stop
e) cdb = x 1B 00:00:00 01 00 // Start

Pat LaVarre

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Wed, Jun 09 2004, Pat LaVarre wrote:
> > Hmm fudge.
> 
> Sorry, this English I do not understand.
> 
> > --- 1.149/drivers/ide/ide.c     2004-06-04 21:14:59 +02:00
> > +++ edited/drivers/ide/ide.c    2004-06-09 10:07:46 +02:00
> 
> Patch!  Cool, thank you.
> 
> > Pat, can you test
> 
> Gladly.  Unless redirected, I will try combining:
> 
> a) kernel.org 2.6.7-rc3 plus the patch of this thread,
> b) PATAPI drive connected as /dev/hdd,
> c) open of /dev/hdd with flags O_NONBLOCK|O_RDWR, ioctl SG_IO
> d) cdb = x 1B 00:00:00 00 00 // Stop
> e) cdb = x 1B 00:00:00 01 00 // Start

f) issue some command that transfers data as well.

if you use the 2nd patch I posted.

-- 
Jens Axboe

Re: sense visible despite ide-floppy in 2.6 maybe

[Pat LaVarre]

Jens A:

> a) kernel.org 2.6.7-rc3 plus the patch of this thread,
> b) PATAPI drive connected as /dev/hdd,
> c) open of /dev/hdd with flags O_NONBLOCK|O_RDWR, ioctl SG_IO
> d) cdb = x 1B 00:00:00 00 00 // Stop
> e) cdb = x 1B 00:00:00 01 00 // Start

Yes now "Hn" (i.e. expecting no data) works here, every time I try.

Cool instant demo of how helpful linux-scsi folk are, thank you.

> For data transfer, it's more tricky. Well actually, if you restrict
> yourself to non-bio backed request, then it becomes pretty trivial!
> ide-floppy expects a contig buffer, a bio is scattered by nature.

Yes "Hi" (i.e. expecting data in) gives me zeroes.

> ...

Also something's broken (far far outside of the kernel) in plscsi.  I
found success only by patching the trivial sgio.c that I posted in this
thread, as shown below.

Pat LaVarre

--- sgio.c	2004-06-08 09:33:33.000000000 -0600
+++ sgio-up.c	2004-06-09 12:23:28.901649448 -0600
@@ -17,14 +17,14 @@ static void populate(sg_io_hdr_t * sih)
 	memset(&static_cdb, '\0', sizeof static_cdb);
 	sih->cmdp = static_cdb;
 	sih->cmd_len = 6;
-	memcpy(sih->cmdp, "\x12\0\0\0\x24\0", sih->cmd_len);
+	memcpy(sih->cmdp, "\x1B\0\0\0\x01\0", sih->cmd_len);
 
 	memset(&static_data, '\0', sizeof static_data);
 	sih->dxferp = static_data;
-	sih->dxfer_len = 0x24;
-	sih->dxfer_direction = SG_DXFER_NONE;
+	sih->dxfer_len = 0x00;
 	sih->dxfer_direction = SG_DXFER_TO_DEV;
 	sih->dxfer_direction = SG_DXFER_FROM_DEV;
+	sih->dxfer_direction = SG_DXFER_NONE;
 
 	memset(&static_sense, '\0', sizeof static_sense);
 	sih->sbp = static_sense;
--- sgio-up.c	2004-06-09 12:23:28.901649448 -0600
+++ sgio-dn.c	2004-06-09 12:23:58.069215304 -0600
@@ -17,7 +17,7 @@ static void populate(sg_io_hdr_t * sih)
 	memset(&static_cdb, '\0', sizeof static_cdb);
 	sih->cmdp = static_cdb;
 	sih->cmd_len = 6;
-	memcpy(sih->cmdp, "\x1B\0\0\0\x01\0", sih->cmd_len);
+	memcpy(sih->cmdp, "\x1B\0\0\0\x00\0", sih->cmd_len);
 
 	memset(&static_data, '\0', sizeof static_data);
 	sih->dxferp = static_data;

Re: sense visible despite ide-floppy in 2.6 maybe

[Pat LaVarre]

> Also something's broken (far far outside of the kernel) in plscsi.  I
> found success only by patching the trivial sgio.c that I posted in this
> thread, as shown below.

Ah. That is, despite the patch inserting idefloppy_blockpc_cmd,

ioctl(fd, SG_GET_VERSION_NUM, &vn) returns negative.

Pat LaVarre

P.S. More specifically,

plscsi, with perhaps excessively paranoid automagic, therefore chose not
to try 2.4 style ioctl SG_IO, complaining:

// sgioOpen.ioctl: Invalid argument
// plscsi.sclOpenNext: "/dev/hdd" not opened

By contrast, my back-of-the-envelope sgio.c was quietly stepping past
this trouble without complaint, in fact requiring vn at or beyond 30,000
only from devices that do support ioctl fd SG_GET_VERSION &vn.  The
trivial patch to get that fragment of code to behave as sensitively as
plscsi is of course:

--- sgio.was.c	2004-06-08 09:33:33.000000000 -0600
+++ sgio.c	2004-06-09 12:43:16.899046392 -0600
@@ -61,12 +61,15 @@ int main(int argc, char * argv[])
 	--argc; ++argv;
 	for (ix = 0; ix < argc; ++ix)
 	{
-		int fd = open(argv[ix], O_NONBLOCK|O_RDWR);
+		int fd = open(argv[ix], O_NONBLOCK);
 		if (fd < 0) {
 			perror("open");
 		} else {
 			int vn = 0;
-			if (0 <= ioctl(fd, SG_GET_VERSION_NUM, &vn)) {
+			if (ioctl(fd, SG_GET_VERSION_NUM, &vn) < 0) {
+				perror("ioctl SG_GET_VERSION_NUM");
+				; /* fallthru to talk anyhow */
+			} else {
 				if (vn < 30000) {
 					perror("ioctl SG_GET_VERSION_NUM");
 					continue;

Re: sense visible despite ide-floppy in 2.6 maybe

[Pat LaVarre]

Jens A:

> > a) ...
> > ...
> > e) ...
> ...
> f) issue some command that transfers data as well.

I tried an op x12 (18) Inquiry for up to x24 (36) bytes.

I got back zeroes even when I memset my data originally to equal
catenated copies of "\xAE" (174).

Under such provocations, dmesg then consistently reports:

hdd: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
hdd: unknown partition table
hdd: leftover data in idefloppy_input_buffers, bcount == 36

Also I saw:

$ sudo /sbin/hdparm /dev/hdd
 
/dev/hdd:
 HDIO_GET_MULTCOUNT failed: Invalid argument
 IO_support   =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 239/64/32, sectors = 489472, start = 0
$

Also the open-ioctl-close spins up the disk, despite O_NONBLOCK.

> if you use the 2nd patch I posted.

I tried the only patch I have yet found.  It applied clean.  Below I
quote the resulting diff.

Pat LaVarre

diff -urp linux-2.6.7-rc3/drivers/ide/ide-floppy.c linux-2.6.7-rc3-pel/drivers/ide/ide-floppy.c
--- linux-2.6.7-rc3/drivers/ide/ide-floppy.c	2004-06-09 11:01:25.000000000 -0600
+++ linux-2.6.7-rc3-pel/drivers/ide/ide-floppy.c	2004-06-09 12:04:24.000000000 -0600
@@ -1210,19 +1210,23 @@ static void idefloppy_create_rw_cmd (ide
 	set_bit(PC_DMA_RECOMMENDED, &pc->flags);
 }
 
-static int
+static void
 idefloppy_blockpc_cmd(idefloppy_floppy_t *floppy, idefloppy_pc_t *pc, struct request *rq)
 {
-	/*
-	 * just support eject for now, it would not be hard to make the
-	 * REQ_BLOCK_PC support fully-featured
-	 */
-	if (rq->cmd[0] != IDEFLOPPY_START_STOP_CMD)
-		return 1;
-
 	idefloppy_init_pc(pc);
+	pc->callback = &idefloppy_rw_callback;
 	memcpy(pc->c, rq->cmd, sizeof(pc->c));
-	return 0;
+	pc->rq = rq;
+	pc->b_count = rq->data_len;
+	if (rq_data_dir(rq) == WRITE)
+		set_bit(PC_WRITING, &pc->flags);
+	pc->buffer = NULL;
+	/*
+	 * possibly problematic, doesn't look like ide-floppy correctly
+	 * handled scattered requests if dma fails...
+	 */
+	pc->request_transfer = pc->buffer_size = rq->data_len;
+	set_bit(PC_DMA_RECOMMENDED, &pc->flags);
 }
 
 /*
@@ -1267,10 +1271,7 @@ static ide_startstop_t idefloppy_do_requ
 		pc = (idefloppy_pc_t *) rq->buffer;
 	} else if (rq->flags & REQ_BLOCK_PC) {
 		pc = idefloppy_next_pc_storage(drive);
-		if (idefloppy_blockpc_cmd(floppy, pc, rq)) {
-			idefloppy_do_end_request(drive, 0, 0);
-			return ide_stopped;
-		}
+		idefloppy_blockpc_cmd(floppy, pc, rq);
 	} else {
 		blk_dump_rq_flags(rq,
 			"ide-floppy: unsupported command in queue");

Re: sense visible despite ide-floppy in 2.6 maybe

[Douglas Gilbert]

Pat LaVarre wrote:
> Doug G:
> 
> Did I do something wrong, or does "everyone know" already,
> 
> SCSI pass thru in 2.6 omits ide-floppy, except if we do resort to the
> ide-scsi deprecated there?

Pat,
In lk 2.6 the ide-scsi driver is "deprecated" for cd/dvd device types
but not other device types that use the ATAPI protocol. The ide-scsi
driver is in the same group as the usb-storage and sbp2 drivers which
bridge between the SCSI stack and other subsystem stacks. The
ongoing problems we have with this group of drivers is as much to
do with their technical complexity (spanning two different driver
architectures) as it is to do with the politics of kernel
development.

Anyway ide-scsi probably needs some repair work in lk 2.6. Both
Willem Riede and I have tried. IMO the ide-scsi driver looks ok
from the scsi subsystem side ....

> Or more specifically,
> 
> Can ioctl SG_IO fetch the offset 7 Additional Length field of op x03
> "REQUEST SENSE" data?
> 
> Naively I thought yes of course, I know that works with /dev/scd$n.
> 
> But then I tried a /dev/hd$v ide-floppy.  No joy.  perror tells me ioctl
> SG_IO fails via "Invalid argument", dmesg has no comment.  sg_scan you
> know.  ~/bin/sgio source is the trivial exercise quoted in source far
> below, specifically with an O_NONBLOCK|O_RDWR open as you can see.

My method with the SG_IO ioctl was to yield errnos
if the SCSI command could not be sent (or was rejected
at the point of transmission). So if there is an errno
there will be no sense buffer (or any other valid
response data). It is only when a response to the SCSI
command is received that errno will be clear (and the
various status variables should be checked).

> $ sudo sg3_utils-1.06/sg_scan /dev/hdd /dev/scd0
> sg_scan: device /dev/hdd failed on scsi ioctl, skip: Input/output error
> /dev/scd0: scsi0 channel=0 id=0 lun=0 [em]
> $
> $ sudo ~/bin/sgio /dev/hdd /dev/scd0 | strings
> ioctl SG_IO: Invalid argument
> Iomega  RRD             74.B
> $
> 
> $ uname -srm
> Linux 2.6.7-rc2 i686
> $ lsmod | grep ide
> ide_floppy             17664  0
> $ sudo mount /dev/hdd /mnt/hdd
> $ sudo umount /dev/hdd
> $ alias xstrings="tr -d ' \r\n' | perl -wpe 's/(..)/chr hex \$1/eg' |
> strings"
> $ sudo cat /proc/ide/hdd/identify | xstrings
> 803048B34F460C1E
> 25.Q    IOMEGA  ZIP 250       ATAPI
> (c) Copyright IOMEGA 2002
> 601//320
> $

Perhaps you could sent me the "strace" of this failure so
I can have a closer look at what is going on.

> Pat LaVarre
> 
> P.S. I fell into trying all this when a friend not yet living in Linux
> noticed my recent linux-ide report of a SATAPI host choking over an
> available sense length rudely not aligned to four bytes.

The underlying serial protocols used by sATA and SAS do
seem to be in units of "dwords" (i.e. 4 byte quantities).
I have noticed several SCSI standards changing the maximum
allocation length of a one byte field (e.g. in an INQUIRY
and MODE SENSE(6) ) from 255 to 252. The intent seems to be
to have lengths that are multiples of 4.

> ----- ~/bin/sgio.c
> 
> #include <fcntl.h>
> #include <scsi/sg.h>
> #include <stdio.h>
> #include <sys/ioctl.h>
> #include <string.h>
> #include <unistd.h>
> 
> static unsigned char static_cdb[0x100];
> static unsigned char static_data[0x1000];
> static unsigned char static_sense[0x100];
> 
> static void populate(sg_io_hdr_t * sih)
> {
> 	memset(sih, '\0', sizeof *sih);
> 	sih->interface_id = 'S';
> 
> 	memset(&static_cdb, '\0', sizeof static_cdb);
> 	sih->cmdp = static_cdb;
> 	sih->cmd_len = 6;
> 	memcpy(sih->cmdp, "\x12\0\0\0\x24\0", sih->cmd_len);
> 
> 	memset(&static_data, '\0', sizeof static_data);
> 	sih->dxferp = static_data;
> 	sih->dxfer_len = 0x24;
> 	sih->dxfer_direction = SG_DXFER_NONE;
> 	sih->dxfer_direction = SG_DXFER_TO_DEV;
> 	sih->dxfer_direction = SG_DXFER_FROM_DEV;

The three above lines look a bit strange :-)

> 	memset(&static_sense, '\0', sizeof static_sense);
> 	sih->sbp = static_sense;
> 	sih->mx_sb_len = 0x12; /* SATAPI may need 4 byte alignment */
> 	sih->timeout = 30 * 1000; /* ms */
> 
> 	; /* sih->iovec_count sih->flags sih->pack_id sih->usr_ptr */
> 	; /* sih->status sih->masked_status sih->msg_status */
> 	; /* sih->sb_len_wr sih->host_status sih->drive_status */
> 	; /* sih->resid sih->duration sih->info */
> }
> 
> static void talk(int fd)
> {
> 	static sg_io_hdr_t static_sih;
> 	sg_io_hdr_t * sih = &static_sih;
> 	int ii;
> 	populate(sih);
> 	ii = ioctl(fd, SG_IO, sih);
> 	if (ii < 0) {
> 		perror("ioctl SG_IO");
> 	} else {
> 		fwrite(sih->dxferp, sih->dxfer_len, 1, stdout);
> 		if ((sih->info & SG_INFO_OK_MASK) != SG_INFO_OK) {
> 			fprintf(stderr, "x %X %X %X\n",
> 				sih->info, sih->resid, sih->sb_len_wr);
> 		}
> 	}
> }
> 
> int main(int argc, char * argv[])
> {
> 	int ix = 0;
> 	--argc; ++argv;
> 	for (ix = 0; ix < argc; ++ix)
> 	{
> 		int fd = open(argv[ix], O_NONBLOCK|O_RDWR);
> 		if (fd < 0) {
> 			perror("open");
> 		} else {
> 			int vn = 0;
> 			if (0 <= ioctl(fd, SG_GET_VERSION_NUM, &vn)) {
> 				if (vn < 30000) {
> 					perror("ioctl SG_GET_VERSION_NUM");
> 					continue;
> 				}

Note: I have started to drop this SG_GET_VERSION_NUM ioctl()
check. It is still needed in the special case where the sg
driver is working asynchronously (i.e. sending commands with
write() and receiving the response with read() ).

> 			}
> 			talk(fd);
> 			close(fd);
> 		}
> 	}
> 	return 0;
> }

Doug Gilbert

Re: sense visible despite ide-floppy in 2.6 maybe

[Willem Riede]

On 2004.06.10 20:23, Douglas Gilbert wrote:
> Pat LaVarre wrote:
> > SCSI pass thru in 2.6 omits ide-floppy, except if we do resort to the
> > ide-scsi deprecated there?
> 
> Pat,
> In lk 2.6 the ide-scsi driver is "deprecated" for cd/dvd device types
> but not other device types that use the ATAPI protocol. The ide-scsi
> driver is in the same group as the usb-storage and sbp2 drivers which
> bridge between the SCSI stack and other subsystem stacks. The
> ongoing problems we have with this group of drivers is as much to
> do with their technical complexity (spanning two different driver
> architectures) as it is to do with the politics of kernel
> development.
> 
> Anyway ide-scsi probably needs some repair work in lk 2.6. Both
> Willem Riede and I have tried. IMO the ide-scsi driver looks ok
> from the scsi subsystem side ....

And actually it works very well for me currently. (That's not to say
there couldn't still be issues with other hardware). If you have 
specific problems I'll be happy to try and help.

Regards, Willem Riede.

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Wed, Jun 09 2004, Pat LaVarre wrote:
> Jens A:
> 
> > a) kernel.org 2.6.7-rc3 plus the patch of this thread,
> > b) PATAPI drive connected as /dev/hdd,
> > c) open of /dev/hdd with flags O_NONBLOCK|O_RDWR, ioctl SG_IO
> > d) cdb = x 1B 00:00:00 00 00 // Stop
> > e) cdb = x 1B 00:00:00 01 00 // Start
> 
> Yes now "Hn" (i.e. expecting no data) works here, every time I try.

Good

> > For data transfer, it's more tricky. Well actually, if you restrict
> > yourself to non-bio backed request, then it becomes pretty trivial!
> > ide-floppy expects a contig buffer, a bio is scattered by nature.
> 
> Yes "Hi" (i.e. expecting data in) gives me zeroes.

Not so good... I'll take a 2nd look and get you something to test,
unfortunately I cannot test here as I have no atapi floppy drives.

-- 
Jens Axboe

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Wed, Jun 09 2004, Pat LaVarre wrote:
> > Also something's broken (far far outside of the kernel) in plscsi.  I
> > found success only by patching the trivial sgio.c that I posted in this
> > thread, as shown below.
> 
> Ah. That is, despite the patch inserting idefloppy_blockpc_cmd,
> 
> ioctl(fd, SG_GET_VERSION_NUM, &vn) returns negative.
> 
> Pat LaVarre
> 
> P.S. More specifically,
> 
> plscsi, with perhaps excessively paranoid automagic, therefore chose not
> to try 2.4 style ioctl SG_IO, complaining:

ide.c needs the whole range of SG ioctls that block/scsi_ioctl.c
supports. I'll add that.

-- 
Jens Axboe

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Wed, Jun 09 2004, Pat LaVarre wrote:
> Jens A:
> 
> > > a) ...
> > > ...
> > > e) ...
> > ...
> > f) issue some command that transfers data as well.
> 
> I tried an op x12 (18) Inquiry for up to x24 (36) bytes.
> 
> I got back zeroes even when I memset my data originally to equal
> catenated copies of "\xAE" (174).
> 
> Under such provocations, dmesg then consistently reports:
> 
> hdd: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
> hdd: unknown partition table
> hdd: leftover data in idefloppy_input_buffers, bcount == 36

Ah that's a good hint. Can you try changing the pc->buffer = NULL in
idefloppy_blockpc_cmd() to pc->buffer = rq->data? Also, only set
PC_DMA_RECOMMENDED if it isn't set. Something ala

	pc->buffer = rq->data;
	if (rq->bio)
		set_bit(PC_DMA_RECOMMENDED, &pc->flags);

that should work, I think. Do this on top of the patch you are already
using.

-- 
Jens Axboe

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Fri, Jun 11 2004, Jens Axboe wrote:
> On Wed, Jun 09 2004, Pat LaVarre wrote:
> > Jens A:
> > 
> > > > a) ...
> > > > ...
> > > > e) ...
> > > ...
> > > f) issue some command that transfers data as well.
> > 
> > I tried an op x12 (18) Inquiry for up to x24 (36) bytes.
> > 
> > I got back zeroes even when I memset my data originally to equal
> > catenated copies of "\xAE" (174).
> > 
> > Under such provocations, dmesg then consistently reports:
> > 
> > hdd: The disk reports a capacity of 250640384 bytes, but the drive only handles 250609664
> > hdd: unknown partition table
> > hdd: leftover data in idefloppy_input_buffers, bcount == 36
> 
> Ah that's a good hint. Can you try changing the pc->buffer = NULL in
> idefloppy_blockpc_cmd() to pc->buffer = rq->data? Also, only set
> PC_DMA_RECOMMENDED if it isn't set. Something ala
> 
> 	pc->buffer = rq->data;
> 	if (rq->bio)
> 		set_bit(PC_DMA_RECOMMENDED, &pc->flags);
> 
> that should work, I think. Do this on top of the patch you are already
> using.

Here's an updated version.

===== drivers/ide/ide.c 1.149 vs edited =====
--- 1.149/drivers/ide/ide.c	2004-06-04 21:14:59 +02:00
+++ edited/drivers/ide/ide.c	2004-06-11 11:37:32 +02:00
@@ -1458,9 +1458,14 @@
 {
 	ide_drive_t *drive = bdev->bd_disk->private_data;
 	ide_settings_t *setting;
-	int err = 0;
+	int err;
 	void __user *p = (void __user *)arg;
 
+	err = scsi_cmd_ioctl(bdev->bd_disk, cmd, p);
+	if (err != -ENOTTY)
+		return err;
+
+	err = 0;
 	down(&ide_setting_sem);
 	if ((setting = ide_find_setting_by_ioctl(drive, cmd)) != NULL) {
 		if (cmd == setting->read_ioctl) {
@@ -1602,10 +1607,6 @@
 			}
 			return 0;
 		}
-
-		case CDROMEJECT:
-		case CDROMCLOSETRAY:
-			return scsi_cmd_ioctl(bdev->bd_disk, cmd, p);
 
 		case HDIO_GET_BUSSTATE:
 			if (!capable(CAP_SYS_ADMIN))
===== drivers/ide/ide-floppy.c 1.39 vs edited =====
--- 1.39/drivers/ide/ide-floppy.c	2004-06-04 06:12:07 +02:00
+++ edited/drivers/ide/ide-floppy.c	2004-06-11 11:36:30 +02:00
@@ -1210,19 +1210,25 @@
 	set_bit(PC_DMA_RECOMMENDED, &pc->flags);
 }
 
-static int
+static void
 idefloppy_blockpc_cmd(idefloppy_floppy_t *floppy, idefloppy_pc_t *pc, struct request *rq)
 {
-	/*
-	 * just support eject for now, it would not be hard to make the
-	 * REQ_BLOCK_PC support fully-featured
-	 */
-	if (rq->cmd[0] != IDEFLOPPY_START_STOP_CMD)
-		return 1;
-
 	idefloppy_init_pc(pc);
+	pc->callback = &idefloppy_rw_callback;
 	memcpy(pc->c, rq->cmd, sizeof(pc->c));
-	return 0;
+	pc->rq = rq;
+	pc->b_count = rq->data_len;
+	if (rq->data_len && rq_data_dir(rq) == WRITE)
+		set_bit(PC_WRITING, &pc->flags);
+	pc->buffer = rq->data;
+	if (rq->bio)
+		set_bit(PC_DMA_RECOMMENDED, &pc->flags);
+		
+	/*
+	 * possibly problematic, doesn't look like ide-floppy correctly
+	 * handled scattered requests if dma fails...
+	 */
+	pc->request_transfer = pc->buffer_size = rq->data_len;
 }
 
 /*
@@ -1267,10 +1273,7 @@
 		pc = (idefloppy_pc_t *) rq->buffer;
 	} else if (rq->flags & REQ_BLOCK_PC) {
 		pc = idefloppy_next_pc_storage(drive);
-		if (idefloppy_blockpc_cmd(floppy, pc, rq)) {
-			idefloppy_do_end_request(drive, 0, 0);
-			return ide_stopped;
-		}
+		idefloppy_blockpc_cmd(floppy, pc, rq);
 	} else {
 		blk_dump_rq_flags(rq,
 			"ide-floppy: unsupported command in queue");

-- 
Jens Axboe

Re: sense visible despite ide-floppy in 2.6 maybe

[Pat LaVarre]

Willem R:

> > ide-scsi ... usb-storage .... sbp2 ...
> > technical complex ...
>
> ... actually works very well for me currently.
> (That's not to say there couldn't still be
> issues with other hardware). If you have
> specific problems I'll be happy to try and
> help.

ide-scsi trouble is now interesting again, if observed since 2.6.5,
especially if observed with ATAPI devices other than DVD/ CD.

is my guess of what we mean after reading this thread and the discussion
of ide-scsi changes at:

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.5

> > From: Douglas Gilbert ...
> > ...
> > In lk 2.6 the ide-scsi driver
> > is "deprecated" for cd/dvd device types
> > but not other device types
> > that use the ATAPI protocol.

Thank you I needed that education.  Therefore another advantage for PDT
x05 among RMB is that SCSI pass thru started working earlier in lk 2.6.

Pat LaVarre

Re: sense visible despite ide-floppy in 2.6 maybe

[Pat LaVarre]

> > should work, I think.

Yes, thank you!

I reverted drivers/ide/ide.c ide-floppy.c to 2.6.7-rc3 and then saw your
updated version applied clean.

> Here's an updated version.

For me now ioctl SG_GET_VERSION_NUM works, and ioctl SG_IO works, ...

Except ioctl SG_IO sg_io_hdr_t.resid always comes back unchanged from
its initial dxfer_len value.  I see nonzero residue reported by the
trivial code I mentioned before, same there as in plscsi.

Pat LaVarre

$ echo -n $'\xAE' >xae.bin
$ hexdump -C xae.bin
00000000  ae                                                |.|
00000001
$
$ sudo plscsi /dev/hdd -f xae.bin -i x24 -x "12 00:00:00 24 00" -v
x 00000000 12 00:00:00 24 00 .. .. .. .. .. .. .. .. .. .. "R@@@$@"
x 00000000 00:80:00:01 75:00:00:00 49:4F:4D:45 47:41:20:20 "@@@Au@@@IOMEGA  "
x 00000010 5A:49:50:20 32:35:30:20 20:20:20:20 20:20:20:20 "ZIP 250         "
x 00000020 32:35:2E:51 .. .. .. .. .. .. .. .. .. .. .. .. "25.Q"
// 36 = x24 = plscsi.main exit int
$
$ sudo plscsi /dev/hdd -f xae.bin -i x7A -x "12 00:00:00 7A 00" -v
x 00000000 12 00:00:00 7A 00 .. .. .. .. .. .. .. .. .. .. "R@@@z@"
x 00000000 00:80:00:01 75:00:00:00 49:4F:4D:45 47:41:20:20 "@@@Au@@@IOMEGA  "
x 00000010 5A:49:50:20 32:35:30:20 20:20:20:20 20:20:20:20 "ZIP 250         "
x 00000020 32:35:2E:51 30:36:2F:31 33:2F:30:32 00:00:00:00 "25.Q06/13/02@@@@"
x 00000030 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 00000050 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000060 28:63:29:20 43:6F:70:79 72:69:67:68 74:20:49:4F "(c) Copyright IO"
x 00000070 4D:45:47:41 20:32:30:30 30:20 .. .. .. .. .. .. "MEGA 2000 "
// 122 = x7A = plscsi.main exit int
$
$ sudo plscsi /dev/hdd -f xae.bin -i xFF -x "12 00:00:00 FF 00" -v
x 00000000 12 00:00:00 FF 00 .. .. .. .. .. .. .. .. .. .. "R@@@?@"
x 00000000 00:80:00:01 75:00:00:00 49:4F:4D:45 47:41:20:20 "@@@Au@@@IOMEGA  "
x 00000010 5A:49:50:20 32:35:30:20 20:20:20:20 20:20:20:20 "ZIP 250         "
x 00000020 32:35:2E:51 30:36:2F:31 33:2F:30:32 00:00:00:00 "25.Q06/13/02@@@@"
x 00000030 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 00000050 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 00000060 28:63:29:20 43:6F:70:79 72:69:67:68 74:20:49:4F "(c) Copyright IO"
x 00000070 4D:45:47:41 20:32:30:30 30:20:00:00 00:00:00:00 "MEGA 2000 @@@@@@"
x 00000080 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
...
x 000000E0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00:00 "@@@@@@@@@@@@@@@@"
x 000000F0 00:00:00:00 00:00:00:00 00:00:00:00 00:00:00 .. "@@@@@@@@@@@@@@@"
// 255 = xFF = plscsi.main exit int
$

Re: sense visible despite ide-floppy in 2.6 maybe

[Pat LaVarre]

Doug G:

> The underlying serial protocols used by sATA and SAS do
> seem to be in units of "dwords" (i.e. 4 byte quantities).
> I have noticed several SCSI standards changing the maximum
> allocation length of a one byte field (e.g. in an INQUIRY
> and MODE SENSE(6) ) from 255 to 252. The intent seems to be
> to have lengths that are multiples of 4.

Aye, analogously, I remember noticing that t10.org op x7F claims to max
out CDB length at x104 rather than the x107 that that additional length
could express.

> > 			int vn = 0;
> > 			if (0 <= ioctl(fd, SG_GET_VERSION_NUM, &vn)) {
> > 				if (vn < 30000) {
> > 					perror("ioctl SG_GET_VERSION_NUM");
> > 					continue;
> > 				}
> 
> Note: I have started to drop this SG_GET_VERSION_NUM ioctl()
> check. It is still needed in the special case where the sg
> driver is working asynchronously (i.e. sending commands with
> write() and receiving the response with read() ).

Help?

I thought the purpose of ioctl SG_GET_VERSION_NUM was to avoid sending
ioctl SG_IO on a Linux so old that ioctl SG_IO meant something
different.

Is that wrong?  Can I expect Linux to behave reasonably whenever I
assault it with a root-privileged ioctl SG_IO, no matter what the ioctl
SG_GET_VERSION_NUM results are?

> > 	sih->dxferp = static_data;
> > 	sih->dxfer_len = 0x24;
> > 	sih->dxfer_direction = SG_DXFER_NONE;
> > 	sih->dxfer_direction = SG_DXFER_TO_DEV;
> > 	sih->dxfer_direction = SG_DXFER_FROM_DEV;
> 
> The three above lines look a bit strange :-)

Help?  Why strange?

These three lines exist because I can easily reorder them to change
quickly among the three main options of expecting data in, data out, or
no data.  Commenting out the two lines that have no effect would
actually make that edit more difficult.

Maybe your ":-)" means you understood that?

> Perhaps you could sent me the "strace" of this failure so
> I can have a closer look at what is going on.

I will try to remember to strace next time I report a failing ioctl.

I will believe the progress of this thread has obsoleted that specific
request unless you say different.

> > Can ioctl SG_IO fetch the offset 7 Additional Length field of op x03
> > "REQUEST SENSE" data?
> > 
> > Naively I thought yes of course, I know that works with /dev/scd$n.
> > 
> > But then I tried a /dev/hd$v ide-floppy.  No joy.  perror tells me ioctl
> > SG_IO fails via "Invalid argument", ...
> 
> My method with the SG_IO ioctl was to yield errnos
> if the SCSI command could not be sent (or was rejected
> at the point of transmission). So if there is an errno
> there will be no sense buffer (or any other valid
> response data).

This much I did understand correctly from the doc.

I did eventually write:

	ii = ioctl(fd, SG_IO, sih);
	if (ii < 0) {
		perror("ioctl SG_IO");
		... die ...
	} else {
		fwrite(sih->dxferp, sih->dxfer_len, 1, stdout);
		if ((sih->info & SG_INFO_OK_MASK) != SG_INFO_OK) {
			... die ...
		} else if (sih->resid != 0) {
			... die ...
		}
		...
	}

The case that falls thru without "die"ing is my guess of when SG_IO
actually has reported complete success.

Pat LaVarre

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Sun, Jun 13 2004, Pat LaVarre wrote:
> > > should work, I think.
> 
> Yes, thank you!
> 
> I reverted drivers/ide/ide.c ide-floppy.c to 2.6.7-rc3 and then saw your
> updated version applied clean.
> 
> > Here's an updated version.
> 
> For me now ioctl SG_GET_VERSION_NUM works, and ioctl SG_IO works, ...

Super!

> Except ioctl SG_IO sg_io_hdr_t.resid always comes back unchanged from
> its initial dxfer_len value.  I see nonzero residue reported by the
> trivial code I mentioned before, same there as in plscsi.

That's expected, I need to change the callback to set these correctly
(it's not modifying any of the sg_io_hdr output values in the test
patch). I'll try and get you a patch tomorrow, if you could check error
reporting + residual with that, we can get something into mainline soon.

-- 
Jens Axboe

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Fri, Jun 11 2004, Douglas Gilbert wrote:
> Pat LaVarre wrote:
> >Doug G:
> >
> >Did I do something wrong, or does "everyone know" already,
> >
> >SCSI pass thru in 2.6 omits ide-floppy, except if we do resort to the
> >ide-scsi deprecated there?
> 
> Pat,
> In lk 2.6 the ide-scsi driver is "deprecated" for cd/dvd device types
> but not other device types that use the ATAPI protocol. The ide-scsi

Direct-device is still clearly superior. ide-scsi is deprecated for any
ATAPI type device using SG_IO, other uses may vary.

> Anyway ide-scsi probably needs some repair work in lk 2.6. Both
> Willem Riede and I have tried. IMO the ide-scsi driver looks ok
> from the scsi subsystem side ....

Should work since months.

> >Or more specifically,
> >
> >Can ioctl SG_IO fetch the offset 7 Additional Length field of op x03
> >"REQUEST SENSE" data?
> >
> >Naively I thought yes of course, I know that works with /dev/scd$n.
> >
> >But then I tried a /dev/hd$v ide-floppy.  No joy.  perror tells me ioctl
> >SG_IO fails via "Invalid argument", dmesg has no comment.  sg_scan you
> >know.  ~/bin/sgio source is the trivial exercise quoted in source far
> >below, specifically with an O_NONBLOCK|O_RDWR open as you can see.
> 
> My method with the SG_IO ioctl was to yield errnos
> if the SCSI command could not be sent (or was rejected
> at the point of transmission). So if there is an errno
> there will be no sense buffer (or any other valid
> response data). It is only when a response to the SCSI
> command is received that errno will be clear (and the
> various status variables should be checked).

The issue here is that ide-floppy doesn't grok REQ_BLOCK_PC requests
correctly, so when SG_IO generates them they are failed.

-- 
Jens Axboe

Re: sense visible despite ide-floppy in 2.6 maybe

[Douglas Gilbert]

Pat LaVarre wrote:
> Doug G:
<snip/>
> 
>>>			int vn = 0;
>>>			if (0 <= ioctl(fd, SG_GET_VERSION_NUM, &vn)) {
>>>				if (vn < 30000) {
>>>					perror("ioctl SG_GET_VERSION_NUM");
>>>					continue;
>>>				}
>>
>>Note: I have started to drop this SG_GET_VERSION_NUM ioctl()
>>check. It is still needed in the special case where the sg
>>driver is working asynchronously (i.e. sending commands with
>>write() and receiving the response with read() ).
> 
> 
> Help?
> 
> I thought the purpose of ioctl SG_GET_VERSION_NUM was to avoid sending
> ioctl SG_IO on a Linux so old that ioctl SG_IO meant something
> different.
> 
> Is that wrong?  Can I expect Linux to behave reasonably whenever I
> assault it with a root-privileged ioctl SG_IO, no matter what the ioctl
> SG_GET_VERSION_NUM results are?

To the best of my knowledge the SG_IO ioctl (request id
0x2285) does not clash with any other ioctl in linux.
With version 2 of the sg driver and earlier ( <= lk 2.2)
the SG_IO ioctl didn't exist. The problem arises when the
asynchronous sg driver interface (i.e. write() a SCSI command
the read() the response when it arrives) is very dangerous
to do on anything other than an sg device! I crunched the
partition table on one of my disks when the SG_IO ioctl was
first introduced to the block layer. This is because I
used a utility in the sg3_utils package that used the
async interface (i.e. write()/read() ) on a block device :-)

>>>	sih->dxferp = static_data;
>>>	sih->dxfer_len = 0x24;
>>>	sih->dxfer_direction = SG_DXFER_NONE;
>>>	sih->dxfer_direction = SG_DXFER_TO_DEV;
>>>	sih->dxfer_direction = SG_DXFER_FROM_DEV;
>>
>>The three above lines look a bit strange :-)
> 
> 
> Help?  Why strange?
> 
> These three lines exist because I can easily reorder them to change
> quickly among the three main options of expecting data in, data out, or
> no data.  Commenting out the two lines that have no effect would
> actually make that edit more difficult.
> 
> Maybe your ":-)" means you understood that?

Well I think the janitors go over the top sometimes
(especially if they hound driver maintainers out of
their support roles) but ...
there is the smaller matter of efficiency and code size.
How about:

// dxfer_direction is one of SG_DXFER_NONE,
//  SG_DXFER_TO_DEV, or  SG_DXFER_FROM_DEV
     sih->dxfer_direction = SG_DXFER_FROM_DEV;

>>Perhaps you could sent me the "strace" of this failure so
>>I can have a closer look at what is going on.
> 
> 
> I will try to remember to strace next time I report a failing ioctl.
> 
> I will believe the progress of this thread has obsoleted that specific
> request unless you say different.

Yes, it seems as though Jens is close to, or has solved
this problem.

>>>Can ioctl SG_IO fetch the offset 7 Additional Length field of op x03
>>>"REQUEST SENSE" data?
>>>
>>>Naively I thought yes of course, I know that works with /dev/scd$n.
>>>
>>>But then I tried a /dev/hd$v ide-floppy.  No joy.  perror tells me ioctl
>>>SG_IO fails via "Invalid argument", ...
>>
>>My method with the SG_IO ioctl was to yield errnos
>>if the SCSI command could not be sent (or was rejected
>>at the point of transmission). So if there is an errno
>>there will be no sense buffer (or any other valid
>>response data).
> 
> 
> This much I did understand correctly from the doc.
> 
> I did eventually write:
> 
> 	ii = ioctl(fd, SG_IO, sih);
> 	if (ii < 0) {
> 		perror("ioctl SG_IO");
> 		... die ...
> 	} else {
> 		fwrite(sih->dxferp, sih->dxfer_len, 1, stdout);

If this fwrite() is outputting something that has be read from
the device then it shouldn't be done _before_ the following
status/warning/error checks.

> 		if ((sih->info & SG_INFO_OK_MASK) != SG_INFO_OK) {
> 			... die ...
> 		} else if (sih->resid != 0) {
> 			... die ...
> 		}
> 		...
> 	}
> 
> The case that falls thru without "die"ing is my guess of when SG_IO
> actually has reported complete success.

It is not quite that simple. There are some statuses like the
sense key of RECOVERED ERROR that imply the operation worked
but "I thought you would like to know that your disk might be
dying ...". Then there are UNIT ATTENTIONs to inform you that
the device has been reset or the reservation you had has been
cleared by someone else. If that information isn't relevant
to your application then executing the command again will most
likely succeed. There can also be deferred errors (i.e. that
write you did earlier failed which can happen when write
caching is employed).

So I'm trying to encourage you and others to check the returned
SCSI status (and other statuses that could flag a command timeout
for example) and if necessary decode the sense buffer. sg_err.[hc]
in sg3_utils does a lot of this work.

Doug Gilbert

Re: sense visible despite ide-floppy in 2.6 maybe

[Pat LaVarre]

> ide-scsi is deprecated for any
> ATAPI type device using SG_IO,
> other uses may vary.

I will next try SG_IO with PATAPI in 2.6.7,
i.e. that's my guess unless corrected of how I can best help next now.

Pat LaVarre

Re: sense visible despite ide-floppy in 2.6 maybe

[Jens Axboe]

On Thu, Jun 17 2004, Pat LaVarre wrote:
> > ide-scsi is deprecated for any
> > ATAPI type device using SG_IO,
> > other uses may vary.
> 
> I will next try SG_IO with PATAPI in 2.6.7,
> i.e. that's my guess unless corrected of how I can best help next now.

Just hold of until tomorrow, you still need the update ide-floppy SG_IO
patch (which I didn't do yet). Or you can look into completing it
yourself, if you have time to spend on that today.

-- 
Jens Axboe