public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
* Re: 2.6.8.1-mm3
@ 2004-08-21 14:43 Mikael Pettersson
  2004-08-21 16:02 ` 2.6.8.1-mm3 James Bottomley
  0 siblings, 1 reply; 8+ messages in thread
From: Mikael Pettersson @ 2004-08-21 14:43 UTC (permalink / raw)
  To: akpm, linux-kernel; +Cc: linux-scsi

On Fri, 20 Aug 2004 03:19:19 -0700, Andrew Morton wrote:
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8.1/2.6.8.1-mm3/
...
> bk-scsi.patch

This one is broken. It causes the kernel to emit a bogus
"program $PROG is using a deprecated SCSI ioctl, please convert it to SG_IO"
message whenever user-space open(2)s a SCSI block device, even
though user-space never did any ioctl() on it.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 2.6.8.1-mm3
  2004-08-21 14:43 2.6.8.1-mm3 Mikael Pettersson
@ 2004-08-21 16:02 ` James Bottomley
  0 siblings, 0 replies; 8+ messages in thread
From: James Bottomley @ 2004-08-21 16:02 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: Andrew Morton, Linux Kernel, SCSI Mailing List

On Sat, 2004-08-21 at 10:43, Mikael Pettersson wrote:
> On Fri, 20 Aug 2004 03:19:19 -0700, Andrew Morton wrote:
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8.1/2.6.8.1-mm3/
> ...
> > bk-scsi.patch
> 
> This one is broken. It causes the kernel to emit a bogus
> "program $PROG is using a deprecated SCSI ioctl, please convert it to SG_IO"
> message whenever user-space open(2)s a SCSI block device, even
> though user-space never did any ioctl() on it.

A simple open of /dev/sda from userland doesn't exhibit this behaviour
for me.  What sort of device is this?  And what is the program?

James



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 2.6.8.1-mm3
@ 2004-08-21 17:15 Mikael Pettersson
  0 siblings, 0 replies; 8+ messages in thread
From: Mikael Pettersson @ 2004-08-21 17:15 UTC (permalink / raw)
  To: James.Bottomley; +Cc: akpm, linux-kernel, linux-scsi

On 21 Aug 2004 12:02:24 -0400, James Bottomley wrote:
> On Sat, 2004-08-21 at 10:43, Mikael Pettersson wrote:
> > On Fri, 20 Aug 2004 03:19:19 -0700, Andrew Morton wrote:
> > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8.1/2.6.8.1-mm3/
> > ...
> > > bk-scsi.patch
> > 
> > This one is broken. It causes the kernel to emit a bogus
> > "program $PROG is using a deprecated SCSI ioctl, please convert it to SG_IO"
> > message whenever user-space open(2)s a SCSI block device, even
> > though user-space never did any ioctl() on it.
> 
> A simple open of /dev/sda from userland doesn't exhibit this behaviour
> for me.  What sort of device is this?  And what is the program?

It happens on my USB flash memory stick, which uses USB_STORAGE and BLK_DEV_SD.
A simple open(2) is enough to trigger the message. I'm about to try -mm3 on a
different machine which has a "true" SCSI controller/disk combo. (I should
have checked that first, sorry.)

/Mikael

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 2.6.8.1-mm3
@ 2004-08-21 18:38 Mikael Pettersson
  2004-08-21 19:14 ` 2.6.8.1-mm3 Patrick Mansfield
  0 siblings, 1 reply; 8+ messages in thread
From: Mikael Pettersson @ 2004-08-21 18:38 UTC (permalink / raw)
  To: James.Bottomley; +Cc: akpm, linux-kernel, linux-scsi

I wrote:
> > > This one is broken. It causes the kernel to emit a bogus
> > > "program $PROG is using a deprecated SCSI ioctl, please convert it to SG_IO"
> > > message whenever user-space open(2)s a SCSI block device, even
> > > though user-space never did any ioctl() on it.
> > 
> > A simple open of /dev/sda from userland doesn't exhibit this behaviour
> > for me.  What sort of device is this?  And what is the program?
> 
> It happens on my USB flash memory stick, which uses USB_STORAGE and BLK_DEV_SD.
> A simple open(2) is enough to trigger the message. I'm about to try -mm3 on a
> different machine which has a "true" SCSI controller/disk combo. (I should
> have checked that first, sorry.)

I checked now, and I can also trigger the message on ide-scsi + sr
(CD writer), but not on ide-scsi + st (ATAPI tape drive) or on
a SCSI disk on a SYM53C8XX controller.

So it seems both usb storage and ide-scsi (or the cdrom module)
generate these ioctls.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 2.6.8.1-mm3
  2004-08-21 18:38 2.6.8.1-mm3 Mikael Pettersson
@ 2004-08-21 19:14 ` Patrick Mansfield
  2004-08-21 19:24   ` 2.6.8.1-mm3 James Bottomley
  0 siblings, 1 reply; 8+ messages in thread
From: Patrick Mansfield @ 2004-08-21 19:14 UTC (permalink / raw)
  To: Mikael Pettersson; +Cc: James.Bottomley, akpm, linux-kernel, linux-scsi

On Sat, Aug 21, 2004 at 08:38:30PM +0200, Mikael Pettersson wrote:

> I checked now, and I can also trigger the message on ide-scsi + sr
> (CD writer), but not on ide-scsi + st (ATAPI tape drive) or on
> a SCSI disk on a SYM53C8XX controller.
> 
> So it seems both usb storage and ide-scsi (or the cdrom module)
> generate these ioctls.

Looks like it will be hit for any scsi removable media, the removable
media check in sd.c sd_media_changed() uses SCSI_IOCTL_TEST_UNIT_READY.

-- Patrick Mansfield

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 2.6.8.1-mm3
  2004-08-21 19:14 ` 2.6.8.1-mm3 Patrick Mansfield
@ 2004-08-21 19:24   ` James Bottomley
  2004-08-21 21:47     ` 2.6.8.1-mm3 Matthew Wilcox
  0 siblings, 1 reply; 8+ messages in thread
From: James Bottomley @ 2004-08-21 19:24 UTC (permalink / raw)
  To: Patrick Mansfield
  Cc: Mikael Pettersson, Andrew Morton, Linux Kernel, SCSI Mailing List

On Sat, 2004-08-21 at 15:14, Patrick Mansfield wrote:
> Looks like it will be hit for any scsi removable media, the removable
> media check in sd.c sd_media_changed() uses SCSI_IOCTL_TEST_UNIT_READY.

Yes, I'm in two minds about this one.

Either we could provide a helper routine to do it and convert all the
internal uses over, or we could define a new ioctl that is correctly
unique, something like

#define SCSI_TEST_UNIT_READY	_IOR('S', 8, int)
or perhaps just 0x5388

and convert the internal users over to it.

Opinions?

James



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 2.6.8.1-mm3
  2004-08-21 19:24   ` 2.6.8.1-mm3 James Bottomley
@ 2004-08-21 21:47     ` Matthew Wilcox
  2004-08-25  3:50       ` 2.6.8.1-mm3 James Bottomley
  0 siblings, 1 reply; 8+ messages in thread
From: Matthew Wilcox @ 2004-08-21 21:47 UTC (permalink / raw)
  To: James Bottomley
  Cc: Patrick Mansfield, Mikael Pettersson, Andrew Morton, Linux Kernel,
	SCSI Mailing List

On Sat, Aug 21, 2004 at 03:24:56PM -0400, James Bottomley wrote:
> Either we could provide a helper routine to do it and convert all the
> internal uses over, or we could define a new ioctl that is correctly
> unique, something like
> 
> #define SCSI_TEST_UNIT_READY	_IOR('S', 8, int)
> or perhaps just 0x5388
> 
> and convert the internal users over to it.
> 
> Opinions?

I prefer the former, something like

int scsi_test_unit_ready(struct scsi_device *sdev);

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: 2.6.8.1-mm3
  2004-08-21 21:47     ` 2.6.8.1-mm3 Matthew Wilcox
@ 2004-08-25  3:50       ` James Bottomley
  0 siblings, 0 replies; 8+ messages in thread
From: James Bottomley @ 2004-08-25  3:50 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Patrick Mansfield, Mikael Pettersson, Andrew Morton, Linux Kernel,
	SCSI Mailing List

On Sat, 2004-08-21 at 17:47, Matthew Wilcox wrote:
> I prefer the former, something like
> 
> int scsi_test_unit_ready(struct scsi_device *sdev);

OK, how about the attached.  It seems to work for me, but then I don't
have any of the problem devices ...

James

===== drivers/scsi/scsi_ioctl.c 1.29 vs edited =====
--- 1.29/drivers/scsi/scsi_ioctl.c	2004-08-19 16:11:54 -05:00
+++ edited/drivers/scsi/scsi_ioctl.c	2004-08-24 22:34:39 -05:00
@@ -432,12 +432,8 @@
 	case SCSI_IOCTL_DOORUNLOCK:
 		return scsi_set_medium_removal(sdev, SCSI_REMOVAL_ALLOW);
 	case SCSI_IOCTL_TEST_UNIT_READY:
-		scsi_cmd[0] = TEST_UNIT_READY;
-		scsi_cmd[1] = 0;
-		scsi_cmd[2] = scsi_cmd[3] = scsi_cmd[5] = 0;
-		scsi_cmd[4] = 0;
-		return ioctl_internal_command(sdev, scsi_cmd,
-				   IOCTL_NORMAL_TIMEOUT, NORMAL_RETRIES);
+		return scsi_test_unit_ready(sdev, IOCTL_NORMAL_TIMEOUT,
+					    NORMAL_RETRIES);
 	case SCSI_IOCTL_START_UNIT:
 		scsi_cmd[0] = START_STOP;
 		scsi_cmd[1] = 0;
===== drivers/scsi/scsi_lib.c 1.130 vs edited =====
--- 1.130/drivers/scsi/scsi_lib.c	2004-08-23 03:14:46 -05:00
+++ edited/drivers/scsi/scsi_lib.c	2004-08-24 22:08:51 -05:00
@@ -1572,6 +1572,34 @@
 	return ret;
 }
 
+int
+scsi_test_unit_ready(struct scsi_device *sdev, int timeout, int retries)
+{
+	struct scsi_request *sreq;
+	char cmd[] = {
+		TEST_UNIT_READY, 0, 0, 0, 0, 0,
+	};
+	int result;
+	
+	sreq = scsi_allocate_request(sdev, GFP_KERNEL);
+	if (!sreq)
+		return -ENOMEM;
+
+		sreq->sr_data_direction = DMA_NONE;
+        scsi_wait_req(sreq, cmd, NULL, 0, timeout, retries);
+
+	if ((driver_byte(sreq->sr_result) & DRIVER_SENSE)
+	    && (sreq->sr_sense_buffer[2] & 0x0f) == UNIT_ATTENTION
+	    && sdev->removable) {
+		sdev->changed = 1;
+		sreq->sr_result = 0;
+	}
+	result = sreq->sr_result;
+	scsi_release_request(sreq);
+	return result;
+}
+EXPORT_SYMBOL(scsi_test_unit_ready);
+
 /**
  *	scsi_device_set_state - Take the given device through the device
  *		state model.
===== drivers/scsi/sd.c 1.157 vs edited =====
--- 1.157/drivers/scsi/sd.c	2004-08-24 18:09:03 -05:00
+++ edited/drivers/scsi/sd.c	2004-08-24 22:36:10 -05:00
@@ -648,7 +648,7 @@
 	 */
 	retval = -ENODEV;
 	if (scsi_block_when_processing_errors(sdp))
-		retval = scsi_ioctl(sdp, SCSI_IOCTL_TEST_UNIT_READY, NULL);
+		retval = scsi_test_unit_ready(sdp, SD_TIMEOUT, SD_MAX_RETRIES);
 
 	/*
 	 * Unable to test, unit probably not ready.   This usually
===== drivers/scsi/sr.c 1.114 vs edited =====
--- 1.114/drivers/scsi/sr.c	2004-08-12 19:03:53 -05:00
+++ edited/drivers/scsi/sr.c	2004-08-24 22:39:41 -05:00
@@ -183,7 +183,7 @@
 		return -EINVAL;
 	}
 
-	retval = scsi_ioctl(cd->device, SCSI_IOCTL_TEST_UNIT_READY, NULL);
+	retval = scsi_test_unit_ready(cd->device, SR_TIMEOUT, MAX_RETRIES);
 	if (retval) {
 		/* Unable to test, unit probably not ready.  This usually
 		 * means there is no disc in the drive.  Mark as changed,
===== include/scsi/scsi_device.h 1.21 vs edited =====
--- 1.21/include/scsi/scsi_device.h	2004-08-22 20:06:22 -05:00
+++ edited/include/scsi/scsi_device.h	2004-08-24 22:11:48 -05:00
@@ -185,6 +185,8 @@
 extern int scsi_mode_sense(struct scsi_device *sdev, int dbd, int modepage,
 			   unsigned char *buffer, int len, int timeout,
 			   int retries, struct scsi_mode_data *data);
+extern int scsi_test_unit_ready(struct scsi_device *sdev, int timeout,
+				int retries);
 extern int scsi_device_set_state(struct scsi_device *sdev,
 				 enum scsi_device_state state);
 extern int scsi_device_quiesce(struct scsi_device *sdev);


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2004-08-25  3:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-21 18:38 2.6.8.1-mm3 Mikael Pettersson
2004-08-21 19:14 ` 2.6.8.1-mm3 Patrick Mansfield
2004-08-21 19:24   ` 2.6.8.1-mm3 James Bottomley
2004-08-21 21:47     ` 2.6.8.1-mm3 Matthew Wilcox
2004-08-25  3:50       ` 2.6.8.1-mm3 James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2004-08-21 17:15 2.6.8.1-mm3 Mikael Pettersson
2004-08-21 14:43 2.6.8.1-mm3 Mikael Pettersson
2004-08-21 16:02 ` 2.6.8.1-mm3 James Bottomley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox