All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@SteelEye.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jens Axboe <jens.axboe@oracle.com>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: block/bsg.c
Date: Tue, 17 Jul 2007 17:19:15 -0500	[thread overview]
Message-ID: <1184710755.3378.30.camel@localhost.localdomain> (raw)
In-Reply-To: <20070717132233.ed11362c.akpm@linux-foundation.org>

On Tue, 2007-07-17 at 13:22 -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2007 12:18:21 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > On Tue, 17 Jul 2007 08:38:11 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > > In terms of presentation: this code hit the tree as base patch plus what
> > > > appear to be 20 bugfixes, none of which are really interesting or relevant
> > > > to mainline.  Personally I think it would be nicer if all that out-of-tree
> > > > development work was cleaned up and the new code goes in as a single hit.
> > > > 
> > > > This makes it a lot easier to find out "wtf does this code all do".  One
> > > > finds the first commit and reads the changlog.  But this algorithm yields:
> > > > 
> > > >     bsg: support for full generic block layer SG v3
> > > > 
> > > > which is not helpful.
> > > 
> > > I agree, I did consider rebasing the merging all patches into a single
> > > commit prior to submission. In retrospect that would have been better,
> > > the bug fixes commits prior to inclusion is not that interesting.
> > 
> > I'm doing a git-bisect and....
> > 
> > block/bsg.c: In function 'bsg_register_queue':
> > block/bsg.c:1014: error: 'struct kobject' has no member named 'dentry'
> > 
> > That's easily fixable in config, but it's another reason for doing
> > that consolidation prior to merging.
> 
> So this rather painful and compiler-errorful bisection session ended up at:
> 
> commit 3d6392cfbd7dc11f23058e3493683afab4ac13a3
> Author: Jens Axboe <jens.axboe@oracle.com>
> Date:   Mon Jul 9 12:38:05 2007 +0200
> 
>     bsg: support for full generic block layer SG v3                                 
> 
> 
> What is happening is that my old dual-PIII IDE-PIIX box running
> hacked-about FC1 is locking up early in initscripts, just after "Finding
> module dependencies".
> 
> Config is http://userweb.kernel.org/~akpm/config-vmm.txt with CONFIG_SCSI=n.
> 
> Occasionally I'll get an NMI watchdog timeout, but it's a rather
> uninteresting one: the stack trace just points up into the idle task.
> 
> This:
> 
> --- a/drivers/ide/ide.c~a
> +++ a/drivers/ide/ide.c
> @@ -1052,9 +1052,9 @@ int generic_ide_ioctl(ide_drive_t *drive
>  	int err, (*setfunc)(ide_drive_t *, int);
>  	u8 *val;
>  
> -	err = scsi_cmd_ioctl(file, bdev->bd_disk->queue, bdev->bd_disk, cmd, p);
> -	if (err != -ENOTTY)
> -		return err;
> +//	err = scsi_cmd_ioctl(file, bdev->bd_disk->queue, bdev->bd_disk, cmd, p);
> +//	if (err != -ENOTTY)
> +//		return err;
>  
>  	switch (cmd) {
>  	case HDIO_GET_32BIT:	    val = &drive->io_32bit;	 goto read_val;
> _
> 
> fixes it.
> 
> 
> I added this:
> 
> --- a/drivers/ide/ide.c~a
> +++ a/drivers/ide/ide.c
> @@ -1052,7 +1052,9 @@ int generic_ide_ioctl(ide_drive_t *drive
>  	int err, (*setfunc)(ide_drive_t *, int);
>  	u8 *val;
>  
> +	printk("%s: cmd=%d\n", __FUNCTION__, cmd);
>  	err = scsi_cmd_ioctl(file, bdev->bd_disk->queue, bdev->bd_disk, cmd, p);
> +	printk("%s: err=%d\n", __FUNCTION__, err);
>  	if (err != -ENOTTY)
>  		return err;
>  
> _
> 
> 
> and got:
> 
> default.hotplug used greatest stack depth: 6448 bytes left
> hotplug used greatest stack depth: 6396 bytes left
> hotplug used greatest stack depth: 5540 bytes left
> EXT3 FS on hdc2, internal journal
> Adding 1020116k swap on /dev/hdc3.  Priority:-1 extents:1 across:1020116k
> generic_ide_ioctl: cmd=21382
> generic_ide_ioctl: err=0
> generic_ide_ioctl: cmd=1
> program scsi_unique_id is using a deprecated SCSI ioctl, please convert it to SG_IO

I can tell you what went wrong:

This cmd=1 is SCSI_IOCTL_SEND_COMMAND, but that doesn't seem to be
what's intended ... I'm guessing it's a legacy ide ioctl value which
suddenly has become interpreted as a scsi_ioctl ... and certainly a non
CD IDE device cannot handle a SCSI command, so all hell breaks loose.

I suspect all we really want from this addition is to be able to get
SG_IO on the ide device, in which case this should be the fix (I put a
case statement instead of an if so we can add other ioctl values to it
in case I missed any).

James

diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
index 8cd7694..9e96662 100644
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -156,6 +156,8 @@
 #include <asm/uaccess.h>
 #include <asm/io.h>
 
+#include <scsi/sg.h>
+
 
 /* default maximum number of failures */
 #define IDE_DEFAULT_MAX_FAILURES 	1
@@ -1052,9 +1054,10 @@ int generic_ide_ioctl(ide_drive_t *drive, struct file *file, struct block_device
 	int err, (*setfunc)(ide_drive_t *, int);
 	u8 *val;
 
-	err = scsi_cmd_ioctl(file, bdev->bd_disk->queue, bdev->bd_disk, cmd, p);
-	if (err != -ENOTTY)
-		return err;
+	switch (cmd) {
+	case SG_IO:
+		return scsi_cmd_ioctl(file, bdev->bd_disk->queue, bdev->bd_disk, cmd, p);
+	}
 
 	switch (cmd) {
 	case HDIO_GET_32BIT:	    val = &drive->io_32bit;	 goto read_val;



  reply	other threads:[~2007-07-17 22:19 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-16 23:57 block/bsg.c Andrew Morton
2007-07-17  0:47 ` block/bsg.c Jeff Garzik
2007-07-17  0:53   ` block/bsg.c Andrew Morton
2007-07-17  0:58     ` block/bsg.c Jeff Garzik
2007-07-17  1:09       ` block/bsg.c Andrew Morton
2007-07-17  1:12         ` block/bsg.c Jeff Garzik
2007-07-17  1:47         ` block/bsg.c Jeff Garzik
2007-07-17  1:47           ` block/bsg.c Jeff Garzik
2007-07-17  3:00           ` block/bsg.c Jeremy Fitzhardinge
2007-07-17  3:00             ` block/bsg.c Jeremy Fitzhardinge
2007-07-17  3:03           ` block/bsg.c Andrew Morton
2007-07-17  3:03             ` block/bsg.c Andrew Morton
2007-07-17  0:52 ` block/bsg.c Satyam Sharma
2007-07-17  0:57   ` block/bsg.c FUJITA Tomonori
2007-07-17  1:01   ` block/bsg.c Gabriel C
2007-07-17  4:57 ` block/bsg.c Joseph Fannin
2007-07-17  6:38 ` block/bsg.c Jens Axboe
2007-07-17  6:43   ` block/bsg.c FUJITA Tomonori
2007-07-17  6:59     ` block/bsg.c Jens Axboe
2007-07-17  7:08       ` block/bsg.c FUJITA Tomonori
2007-07-17  7:10         ` block/bsg.c Jens Axboe
2007-07-17  7:17           ` block/bsg.c FUJITA Tomonori
2007-07-17  7:19             ` block/bsg.c Jens Axboe
2007-07-17 10:07           ` block/bsg.c FUJITA Tomonori
2007-07-17 10:19             ` block/bsg.c Jens Axboe
2007-07-17 18:53               ` block/bsg.c James Bottomley
2007-07-17 19:48                 ` block/bsg.c Andrew Morton
2007-07-17 19:52                   ` block/bsg.c James Bottomley
2007-07-18  0:20                 ` block/bsg.c FUJITA Tomonori
2007-07-18 13:54                   ` block/bsg.c James Bottomley
2007-07-18 14:23                     ` block/bsg.c James Bottomley
2007-07-18 23:18                       ` block/bsg.c FUJITA Tomonori
2007-07-17 20:52               ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-17 21:34                 ` block/bsg.c Andrew Morton
2007-07-17 23:19                   ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-17 22:26                 ` block/bsg.c FUJITA Tomonori
2007-07-17 22:26                   ` block/bsg.c FUJITA Tomonori
2007-07-18 20:39                   ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-18 23:44                     ` block/bsg.c FUJITA Tomonori
2007-07-17  7:24   ` block/bsg.c FUJITA Tomonori
2007-07-17 19:18   ` block/bsg.c Andrew Morton
2007-07-17 20:22     ` block/bsg.c Andrew Morton
2007-07-17 22:19       ` James Bottomley [this message]
2007-07-17 22:54         ` block/bsg.c Andrew Morton
2007-07-17 22:57           ` block/bsg.c James Bottomley
2007-07-17 23:37         ` block/bsg.c Jeff Garzik
2007-07-18  0:43           ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-18 14:11             ` block/bsg.c James Bottomley
2007-07-18 20:32               ` block/bsg.c Bartlomiej Zolnierkiewicz
2007-07-18 21:32                 ` block/bsg.c James Bottomley
2007-07-17  7:48 ` block/bsg.c Jan Engelhardt
2007-07-17 12:04 ` [PATCH] Don't define empty struct bsg_class_device if !CONFIG_BLK_DEV_BSG (was: Re: block/bsg.c) Geert Uytterhoeven
2007-07-17 12:10   ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1184710755.3378.30.camel@localhost.localdomain \
    --to=james.bottomley@steeleye.com \
    --cc=akpm@linux-foundation.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.