Re: PS3: sg chaining support
On Tue, Jul 17 2007, Geoff Levand wrote: > Hi Jens. > > Geert Uytterhoeven wrote: > > -- Forwarded message -- > > Date: Mon, 16 Jul 2007 11:47:26 +0200 > > From: Jens Axboe <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED], linux-scsi@vger.kernel.org > > Cc: Jens Axboe <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > Subject: [PATCH 12/33] PPC: sg chaining support > > > > This updates the ppc iommu/pci dma mappers to sg chaining. > > > > Cc: [EMAIL PROTECTED] > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > --- > > arch/powerpc/kernel/dma_64.c|5 +++-- > > arch/powerpc/kernel/ibmebus.c | 11 ++- > > arch/powerpc/kernel/iommu.c | 18 +++--- > > arch/powerpc/platforms/ps3/system-bus.c |5 +++-- > > include/asm-powerpc/dma-mapping.h |2 +- > > include/asm-powerpc/scatterlist.h |2 ++ > > 6 files changed, 26 insertions(+), 17 deletions(-) > > I'm wondering what the status of this work is. The patch I've > seen no longer applies to ps3/system-bus.c. A rebase to > linux-2.6.git a5fcaa210626a79465321e344c91a6a7dc3881fa is below, > but untested, as I don't have the other patches to do the build. I rebased the tree yesterday to resolve that conflict, it's in the sglist-arch branch now. The result is identical to yours. Shall I take this as an acked-by? -- 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: block/bsg.c
[ James, please remeber to cc: linux-ide on IDE patches, thanks. ]
On Wednesday 18 July 2007, Jeff Garzik wrote:
> James Bottomley wrote:
> > @@ -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;
>
>
> At that point you might as well use an 'if'.
>
> But overall -- agreed. ACK.
James/Jeff thanks for following the issue but NAK. ;)
Causes regression wrt ide-floppy CDROMEJECT/CDROMCLOSETRAY support when
compared to 2.6.22 and SG_IO is not supported by ide-{disk,scsi,tape}.
Luckily Linus has already fixed the issue properly.
BTW cmd == 1 IOCTL is not defined/used by IDE driver.
Thanks,
Bart
-
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: block/bsg.c
From: James Bottomley <[EMAIL PROTECTED]>
Subject: Re: block/bsg.c
Date: Tue, 17 Jul 2007 13:53:54 -0500
> On Tue, 2007-07-17 at 12:19 +0200, Jens Axboe wrote:
> > > > Since Linus is happily snoring by now, could you test and see if the
> > > > tree works for you?
> > >
> > > It works for me. I'll submit some minor patches against your bsg
> > > branch to scsi-ml. Can you push them together?
> >
> > Certainly, I'll pull them into the bsg branch.
>
> While you're at it, here's a patch to separate BSG and SCSI again (so
> SCSI can be built modular). The way I did it was simply to move the
> SCSI specific logic into SCSI. When you come up with a generic way to
> register the bsg requiring drivers, then we can move it out again.
Thanks, looks nice.
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -714,6 +714,7 @@ static int attr_add(struct device *dev, struct
> device_attribute *attr)
> int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> {
> int error, i;
> + struct request_queue *rq = sdev->request_queue;
>
> if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
> return error;
> @@ -733,6 +734,16 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> /* take a reference for the sdev_classdev; this is
>* released by the sdev_class .release */
> get_device(&sdev->sdev_gendev);
> +
> + if (rq->kobj.parent)
> + error = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
> + else
> + error = bsg_register_queue(rq,
> kobject_name(&sdev->sdev_gendev.kobj));
> + if (error) {
> + sdev_printk(KERN_INFO, sdev, "Failed to register bsg queue\n");
> + goto out;
Needs more cleanup here?
We might just ignore the error here since it's not fatal not to create
a bsg device, I guess.
I updated the patch against the latest code (which has just be merged
to Linus's tree).
diff --git a/block/Kconfig b/block/Kconfig
index 0768741..93adf61 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -53,7 +53,7 @@ endif # BLOCK
config BLK_DEV_BSG
bool "Block layer SG support v4 (EXPERIMENTAL)"
- depends on (SCSI=y) && EXPERIMENTAL
+ depends on EXPERIMENTAL
---help---
Saying Y here will enable generic SG (SCSI generic) v4 support
for any block device.
diff --git a/block/bsg.c b/block/bsg.c
index baa04e7..4e0be1b 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -1009,29 +1009,6 @@ err:
}
EXPORT_SYMBOL_GPL(bsg_register_queue);
-static int bsg_add(struct class_device *cl_dev, struct class_interface
*cl_intf)
-{
- int ret;
- struct scsi_device *sdp = to_scsi_device(cl_dev->dev);
- struct request_queue *rq = sdp->request_queue;
-
- if (rq->kobj.parent)
- ret = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
- else
- ret = bsg_register_queue(rq,
kobject_name(&sdp->sdev_gendev.kobj));
- return ret;
-}
-
-static void bsg_remove(struct class_device *cl_dev, struct class_interface
*cl_intf)
-{
- bsg_unregister_queue(to_scsi_device(cl_dev->dev)->request_queue);
-}
-
-static struct class_interface bsg_intf = {
- .add= bsg_add,
- .remove = bsg_remove,
-};
-
static struct cdev bsg_cdev = {
.kobj = {.name = "bsg", },
.owner = THIS_MODULE,
@@ -1069,16 +1046,9 @@ static int __init bsg_init(void)
if (ret)
goto unregister_chrdev;
- ret = scsi_register_interface(&bsg_intf);
- if (ret)
- goto remove_cdev;
-
printk(KERN_INFO BSG_DESCRIPTION " version " BSG_VERSION
" loaded (major %d)\n", bsg_major);
return 0;
-remove_cdev:
- printk(KERN_ERR "bsg: failed register scsi interface %d\n", ret);
- cdev_del(&bsg_cdev);
unregister_chrdev:
unregister_chrdev_region(MKDEV(bsg_major, 0), BSG_MAX_DEVS);
destroy_bsg_class:
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index ed72086..9ebd215 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -714,6 +714,7 @@ static int attr_add(struct device *dev,
int scsi_sysfs_add_sdev(struct scsi_device *sdev)
{
int error, i;
+ struct request_queue *rq = sdev->request_queue;
if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
return error;
@@ -733,6 +734,15 @@ int scsi_sysfs_add_sdev(struct scsi_devi
/* take a reference for the sdev_classdev; this is
* released by the sdev_class .release */
get_device(&sdev->sdev_gendev);
+
+ if (rq->kobj.parent)
+ error = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
+ else
+ error = bsg_register_queue(rq,
kobject_name(&sdev->sdev_gendev.kobj));
+
+ if (error)
+ sdev_printk(KERN_INFO, sdev, "Failed to register bsg queue\n");
+
if (sdev->host->hostt->sdev_attrs) {
for (i = 0
Re: [patch 0/4] aha152x.c - Cleanup, need help in testing and auditing
On Mon, 16 Jul 2007 12:22:20 +0300 Boaz Harrosh wrote: > If you could do some testing it is grate. The first 3 patches do not > need scsi-misc specifically. Any post 2.6.20 tree will do. The last patch > could be done together with attached patch on any 2.6.22 tree. > (Apply attached patch anywhere before the last patch (4/4) of the patchset) > Though I do recommend scsi-misc tree. I took 2.6.22, backed out Christoph's aha152x.c patch (using completion for timeouts), added your 5 patches, and then tested. Does that sound OK? > Testing: > Doing a regular Mount, FS testing is good for checking the last (4/4) > patch, and it would be good news if it works, but ... > I'm afraid that it will not exercise the code change all that much, > since my patches touch the Error-handling and Reset code paths. > > Maybe someone can help: > How can we cause an ->eh_device_reset_handler() call from scsi-ml? > > As for the patch 3/4 we need a SAM_STAT_CHECK_CONDITION return > from a device. If you have a device with known bad sectors than > a dd over the bad block should exercise that. Again anyone can > think of an easy way to exercise a Status==SAM_STAT_CHECK_CONDITION? > > Thanks for any testing you can do. Even if it's only the first 3 > it could be nice I booted/tested 4 times. 2 Oopsen and 2 of could-never-mount-the-device-due-to-reset-problems. Log is attached. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** aha152xb.logs Description: Binary data
Re: block/bsg.c
James Bottomley wrote:
@@ -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;
At that point you might as well use an 'if'.
But overall -- agreed. ACK.
Jeff
-
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: block/bsg.c
On Tuesday 17 July 2007, Andrew Morton wrote:
> On Tue, 17 Jul 2007 22:52:25 +0200
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>
> > ide-{disk,scsi,tape} don't support REQ_TYPE_BLOCK_PC requests et all
> > (so attempts to use SG_IO, CDROM_SEND_PACKET and SCSI_IOCTL_SEND_COMMAND
> > will result in requests being failed and error messages in the kernel logs).
>
> In my case it results in a completely tits-up machine. CPU stuck somewhere
> spinning with local interrutps disabled.
>
> If you see the log output I sent, I'm suspecting this might be because
I don't. :(
> this BSG brainfart has exposed underlying bugs in IDE or SCSI.
Possible but ATM I have an (overdue) IDE update to push, people waiting for
(overdue) patches to try and some (overdue) patches to finish and post...
Would be great if somebody beats me to investigate this issue.
Hint: this would be a great way to redempt pushing buggy commit behind
my back. ;-)
Thanks,
Bart
-
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: block/bsg.c
On Tue, 2007-07-17 at 15:54 -0700, Andrew Morton wrote: > On Tue, 17 Jul 2007 17:19:15 -0500 > James Bottomley <[EMAIL PROTECTED]> wrote: > > > > 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. > > An interrupt-off lockup is a pretty bad reaction to an unexpected ioctl > command. It makes one wonder if tht lockup can be triggered by other > means... I think this is pretty much par for the course for IDE drivers ... send it a bogus taskfile (which root is allowed to do) and you'll see it exhibit the same behaviour. I suspect what happened is that the driver expects to treat all REQ_BLOCK_PC requests as taskfiles, so the wrappered SCSI command got treated as a task file ... the rest you know. 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: block/bsg.c
On Tue, 17 Jul 2007 17:19:15 -0500 James Bottomley <[EMAIL PROTECTED]> wrote: > > 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. An interrupt-off lockup is a pretty bad reaction to an unexpected ioctl command. It makes one wonder if tht lockup can be triggered by other means... - 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: block/bsg.c
From: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Subject: Re: block/bsg.c
Date: Tue, 17 Jul 2007 22:52:25 +0200
> /*
> * TODO
> * - Should this get merged, block/scsi_ioctl.c will be migrated into
> *this file. To keep maintenance down, it's easier to have them
> *seperated right now.
> *
> */
>
> This TODO should be fixed/removed.
Yeah, this should be removed now. I'll do.
> Firstly bsg got merged. ;) Moreover bsg depends on SCSI and scsi_ioctl
> doesn't.
> Even if SCSI dependency is fixed bsg requires block driver to have struct
> class devices which is not a case for scsi_ioctl.
>
> ...
>
> static struct bsg_device *__bsg_get_device(int minor)
> {
> struct hlist_head *list = &bsg_device_list[bsg_list_idx(minor)];
>
> bsg_device_list[] access should be done under bsg_mutex lock.
>
> May not be a problem currently because of lock_kernel but worth fixing anyway.
>
> struct bsg_device *bd = NULL;
> struct hlist_node *entry;
>
> mutex_lock(&bsg_mutex);
>
They were fixed. Please check the latest code:
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git bsg
We wait for Linus to pull from it.
> static int
> bsg_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
> unsigned long arg)
> {
> ...
> case SCSI_IOCTL_SEND_COMMAND: {
>
> Do we really want to add support for this *deprecated* ioctl to
> the *new* and shiny bsg driver?
>
> void __user *uarg = (void __user *) arg;
> return scsi_cmd_ioctl(file, bd->queue, NULL, cmd, uarg);
> }
We might remove it.
> int bsg_register_queue(struct request_queue *q, const char *name)
> {
> ...
> memset(bcd, 0, sizeof(*bcd));
> ...
> dev = MKDEV(BSG_MAJOR, bcd->minor);
> class_dev = class_device_create(bsg_class, NULL, dev, bcd->dev, "%s",
> name);
>
> bcd->dev is always 0 (NULL).
>
> Is it OK to pass NULL struct device *dev argument to class_device_create()?
It's ok, I guess.
> It should be fixed by either removing bcd->dev or by setting it to something
> other than zero.
>
> ...
>
> MODULE_AUTHOR("Jens Axboe");
> MODULE_DESCRIPTION("Block layer SGSI generic (sg) driver");
>
> SGSI? :)
It was fixed in the latest code.
Thanks,
-
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: block/bsg.c
On Tue, 2007-07-17 at 13:22 -0700, Andrew Morton wrote:
> On Tue, 17 Jul 2007 12:18:21 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 17 Jul 2007 08:38:11 +0200 Jens Axboe <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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
#include
+#include
+
/* 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; go
Re: block/bsg.c
On Tue, 17 Jul 2007 22:52:25 +0200
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> ide-{disk,scsi,tape} don't support REQ_TYPE_BLOCK_PC requests et all
> (so attempts to use SG_IO, CDROM_SEND_PACKET and SCSI_IOCTL_SEND_COMMAND
> will result in requests being failed and error messages in the kernel logs).
In my case it results in a completely tits-up machine. CPU stuck somewhere
spinning with local interrutps disabled.
If you see the log output I sent, I'm suspecting this might be because
this BSG brainfart has exposed underlying bugs in IDE or SCSI.
Note that I saw literally 20,000 lines of output in the bit which I snipped,
so something has gone pretty wild in the handling of these bogus commands.
-
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
PS3: sg chaining support
Hi Jens.
Geert Uytterhoeven wrote:
> -- Forwarded message --
> Date: Mon, 16 Jul 2007 11:47:26 +0200
> From: Jens Axboe <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], linux-scsi@vger.kernel.org
> Cc: Jens Axboe <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: [PATCH 12/33] PPC: sg chaining support
>
> This updates the ppc iommu/pci dma mappers to sg chaining.
>
> Cc: [EMAIL PROTECTED]
> Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
> ---
> arch/powerpc/kernel/dma_64.c|5 +++--
> arch/powerpc/kernel/ibmebus.c | 11 ++-
> arch/powerpc/kernel/iommu.c | 18 +++---
> arch/powerpc/platforms/ps3/system-bus.c |5 +++--
> include/asm-powerpc/dma-mapping.h |2 +-
> include/asm-powerpc/scatterlist.h |2 ++
> 6 files changed, 26 insertions(+), 17 deletions(-)
I'm wondering what the status of this work is. The patch I've
seen no longer applies to ps3/system-bus.c. A rebase to
linux-2.6.git a5fcaa210626a79465321e344c91a6a7dc3881fa is below,
but untested, as I don't have the other patches to do the build.
-Geoff
Subject: PS3: sg chaining support
This updates the ps3 system bus dma mappers to sg chaining.
CC: Jens Axboe <[EMAIL PROTECTED]>
From: Geoff Levand <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/ps3/system-bus.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -622,17 +622,18 @@ static void ps3_unmap_single(struct devi
}
}
-static int ps3_sb_map_sg(struct device *_dev, struct scatterlist *sg, int
nents,
- enum dma_data_direction direction)
+static int ps3_sb_map_sg(struct device *_dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction direction)
{
#if defined(CONFIG_PS3_DYNAMIC_DMA)
BUG_ON("do");
return -EPERM;
#else
struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
+ struct scatterlist *sg;
int i;
- for (i = 0; i < nents; i++, sg++) {
+ for_each_sg(sgl, sg, nents, i) {
int result = ps3_dma_map(dev->d_region,
page_to_phys(sg->page) + sg->offset, sg->length,
&sg->dma_address, 0);
@@ -650,7 +651,7 @@ static int ps3_sb_map_sg(struct device *
#endif
}
-static int ps3_ioc0_map_sg(struct device *_dev, struct scatterlist *sg,
+static int ps3_ioc0_map_sg(struct device *_dev, struct scatterlist *sgl,
int nents,
enum dma_data_direction direction)
{
@@ -658,7 +659,7 @@ static int ps3_ioc0_map_sg(struct device
return 0;
}
-static void ps3_sb_unmap_sg(struct device *_dev, struct scatterlist *sg,
+static void ps3_sb_unmap_sg(struct device *_dev, struct scatterlist *sgl,
int nents, enum dma_data_direction direction)
{
#if defined(CONFIG_PS3_DYNAMIC_DMA)
@@ -666,7 +667,7 @@ static void ps3_sb_unmap_sg(struct devic
#endif
}
-static void ps3_ioc0_unmap_sg(struct device *_dev, struct scatterlist *sg,
+static void ps3_ioc0_unmap_sg(struct device *_dev, struct scatterlist *sgl,
int nents, enum dma_data_direction direction)
{
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
[PATCH] dm-mpath-rdac: don't stomp on a request's transfer bit.
Signed-off-by: Andrew Vasquez <[EMAIL PROTECTED]> --- On Thu, 12 Jul 2007, Mike Anderson wrote: > Copying this mail to linux-scsi and Ccing Andrew Vasquez to possibly > provide input on the Qlogic behavior. ... > > > Jul 12 17:11:15 jimbo kernel: qla2xxx :02:01.1: ISP System Error - mbx1=0h > > > mbx2=8012h mbx3=8002h. > > > Jul 12 17:11:15 jimbo kernel: qla2xxx :02:01.1: Firmware has been previously > > > dumped (c2000171d000) -- ignoring request... > > > Jul 12 17:11:16 jimbo kernel: qla2xxx :02:01.1: Performing ISP error > > > recovery - ha= 81007e85c530. So what's happening here is the firmware is detecting a Xfer-ready from the storage when in fact the data-direction for a mode-select should be a write (DATA_OUT). The following patch fixes the problem (typo). Verified by Brian, as well. diff --git a/drivers/md/dm-mpath-rdac.c b/drivers/md/dm-mpath-rdac.c index 8b776b8..16b1613 100644 --- a/drivers/md/dm-mpath-rdac.c +++ b/drivers/md/dm-mpath-rdac.c @@ -292,7 +292,7 @@ static struct request *get_rdac_req(struct rdac_handler *h, rq->end_io_data = h; rq->timeout = h->timeout; rq->cmd_type = REQ_TYPE_BLOCK_PC; - rq->cmd_flags = REQ_FAILFAST | REQ_NOMERGE; + rq->cmd_flags |= REQ_FAILFAST | REQ_NOMERGE; return rq; } - 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: aic7xxx: tape always rewinds since linux-2.6.15
Kai Makisara schrieb: The device /dev/st0 is usually the auto-rewind device and, by definition, the tape is rewound after the device is closed. You should use /dev/nst0 if you don't want the tape to be rewound after close. To use /dev/st0 instead of /dev/nst0 was the stupidity. Sorry then for the noise...but thanks for the help! Frank. - 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: block/bsg.c
Hi,
Some more bsg findings...
block/Kconfig:
endif # BLOCK
Shouldn't BLK_DEV_BSG depend on BLOCK?
config BLK_DEV_BSG
bool "Block layer SG support"
depends on (SCSI=y) && EXPERIMENTAL
default y
---help---
Saying Y here will enable generic SG (SCSI generic) v4
support for any block device.
block/bsg.c:
...
/*
* TODO
* - Should this get merged, block/scsi_ioctl.c will be migrated into
*this file. To keep maintenance down, it's easier to have them
*seperated right now.
*
*/
This TODO should be fixed/removed.
Firstly bsg got merged. ;) Moreover bsg depends on SCSI and scsi_ioctl doesn't.
Even if SCSI dependency is fixed bsg requires block driver to have struct
class devices which is not a case for scsi_ioctl.
...
static struct bsg_device *__bsg_get_device(int minor)
{
struct hlist_head *list = &bsg_device_list[bsg_list_idx(minor)];
bsg_device_list[] access should be done under bsg_mutex lock.
May not be a problem currently because of lock_kernel but worth fixing anyway.
struct bsg_device *bd = NULL;
struct hlist_node *entry;
mutex_lock(&bsg_mutex);
...
static int
bsg_ioctl(struct inode *inode, struct file *file, unsigned int cmd,
unsigned long arg)
{
...
case SCSI_IOCTL_SEND_COMMAND: {
Do we really want to add support for this *deprecated* ioctl to
the *new* and shiny bsg driver?
void __user *uarg = (void __user *) arg;
return scsi_cmd_ioctl(file, bd->queue, NULL, cmd, uarg);
}
...
int bsg_register_queue(struct request_queue *q, const char *name)
{
...
memset(bcd, 0, sizeof(*bcd));
...
dev = MKDEV(BSG_MAJOR, bcd->minor);
class_dev = class_device_create(bsg_class, NULL, dev, bcd->dev, "%s",
name);
bcd->dev is always 0 (NULL).
Is it OK to pass NULL struct device *dev argument to class_device_create()?
It should be fixed by either removing bcd->dev or by setting it to something
other than zero.
...
MODULE_AUTHOR("Jens Axboe");
MODULE_DESCRIPTION("Block layer SGSI generic (sg) driver");
SGSI? :)
MODULE_LICENSE("GPL");
Now back to the first bsg commit 3d6392cfbd7dc11f23058e3493683afab4ac13a3:
diff --git a/drivers/ide/ide-floppy.c b/drivers/ide/ide-floppy.c
index f429be8..a21f585 100644
--- a/drivers/ide/ide-floppy.c
+++ b/drivers/ide/ide-floppy.c
@@ -1258,19 +1258,25 @@ static void idefloppy_create_rw_cmd (idefloppy_floppy_t
*floppy, idefloppy_pc_t
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);
Great to see SG_IO support being added to ide-floppy but this change has
nothing to do with the addition of bsg driver so WTF they have been mixed
within the same commit?
I also can't recall seeing this patch on linux-ide mailing list...
+ /*
+* possibly problematic, doesn't look like ide-floppy correctly
+* handled scattered requests if dma fails...
+*/
Could you give some details on this?
+ pc->request_transfer = pc->buffer_size = rq->data_len;
}
/*
@@ -1317,10 +1323,7 @@ static ide_startstop_t idefloppy_do_request (ide_drive_t
*drive, struct request
pc = (idefloppy_pc_t *) rq->buffer;
} else if (blk_pc_request(rq)) {
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");
diff --git a/drivers/ide/ide.c b/drivers/ide/ide.c
index c948a5c..9ae60a7 100644
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
ide.c changes also have nothing to do with addition of bsg driver.
@@ -1049,9 +1049,13 @@ int generic_ide_ioctl(ide_drive_t *drive, struct file
*file, struct block_device
unsigned long flags;
ide_driver_t *drv;
void __user *p = (void __user *)arg;
- int err = 0, (*setfunc)(ide_drive_t *, int);
+ int err, (*setfunc)(ide_drive_t *, int);
u8 *val;
+ err = scsi_cmd_ioctl(file, bdev->b
Re: block/bsg.c
On Tue, 17 Jul 2007 12:18:21 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 17 Jul 2007 08:38:11 +0200 Jens Axboe <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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
ide_do_rw_disk - bad command: dev hdc: type=2, flags=104c8
sector 1515870810, nr/cnr 0/0
bio f73714f8, biotail f73714f8, buffer , data , len 96
cdb: 12 01 80 00 60 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
ide_do_rw_disk - bad command: dev hdc: type=2, flags=104c8
sector 1515870810, nr/cnr 0/0
bio f73714f8, biotail f73714f8, buffer , data , len 96
cdb: 12 01 80 00 60 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
ide_do_rw_disk - bad command: dev hdc: type=2, flags=104c8
sector 1515870810, nr/cnr 0/0
bio f73714f8, biotail f73714f8, buffer , data , len 96
cdb: 12 01 80 00 60 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
ide_do_rw_disk - bad command: dev hdc: type=2, flags=104c8
sector 1515870810, nr/cnr 0/0
bio f73714f8, biotail f73714f8, buffer , data , len 96
cdb: 12 01 80 00 60 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
ide_do_rw_disk - bad command: dev hdc: type=2, flags=104c8
sector 1515870810, nr/cnr 0/0
bio f73714f8, biotail f73714f8, buffer , data , len 96
cdb: 12 01 80 00 60 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
ide_do_rw_disk - bad command: dev hdc: type=2, flags=104c8
sector 1515870810, nr/cnr 0/0
bio f73714f8, biotail f73714f8, buffer , data , len 96
cdb: 12 01 80 00 60 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
ide_do_rw_disk - bad command: dev hdc: type=2, flags=104c8
sector 1515870810, nr/cnr 0/0
bio f73714f8, biotail f73714f8, buffer , data , len 96
cdb: 12 01 80 00 60 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a
ide_do_rw_disk - bad command: dev hdc: type=2, flags=104c8
<2 lines removed>
sector 1515870810, nr/cnr 0/0
bio f7371
Re: advansys cleanup
On Tue, 17 Jul 2007, Matthew Wilcox wrote: I'd be glad to attempt the patches again. It would be easier for me if you sent me the raw patches, if possible. How about I send you a patch on top of the advansys.c you got from that git tree? Certainly... whatever works for you. I'm glad just to see the driver getting a little love again. - 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: block/bsg.c
On Tue, 2007-07-17 at 12:48 -0700, Andrew Morton wrote: > On Tue, 17 Jul 2007 13:53:54 -0500 James Bottomley <[EMAIL PROTECTED]> wrote: > > > On Tue, 2007-07-17 at 12:19 +0200, Jens Axboe wrote: > > > > > Since Linus is happily snoring by now, could you test and see if the > > > > > tree works for you? > > > > > > > > It works for me. I'll submit some minor patches against your bsg > > > > branch to scsi-ml. Can you push them together? > > > > > > Certainly, I'll pull them into the bsg branch. > > > > While you're at it, here's a patch to separate BSG and SCSI again (so > > SCSI can be built modular). The way I did it was simply to move the > > SCSI specific logic into SCSI. When you come up with a generic way to > > register the bsg requiring drivers, then we can move it out again. > > I note that block/scsi_ioctl.c is geting compiled with CONFIG_SCSI=n. > Seems odd. No, that's fine ... the reason scsi_ioctl.c moved to block was precisely so that non SCSI devices could use the ioctls, thus it should be there even if SCSI is not. > (Actually, it's failing to compile (in the middle of the bsg series) so I need > to fix it by hand somehow to continue this bisect) I generally use quilt to help with this (just quilt up the fix and apply and remove it around the bisects). I seem to get tons of trees with unrelated breakage right around where the voyager failures are. 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: block/bsg.c
On Tue, 17 Jul 2007 13:53:54 -0500 James Bottomley <[EMAIL PROTECTED]> wrote: > On Tue, 2007-07-17 at 12:19 +0200, Jens Axboe wrote: > > > > Since Linus is happily snoring by now, could you test and see if the > > > > tree works for you? > > > > > > It works for me. I'll submit some minor patches against your bsg > > > branch to scsi-ml. Can you push them together? > > > > Certainly, I'll pull them into the bsg branch. > > While you're at it, here's a patch to separate BSG and SCSI again (so > SCSI can be built modular). The way I did it was simply to move the > SCSI specific logic into SCSI. When you come up with a generic way to > register the bsg requiring drivers, then we can move it out again. I note that block/scsi_ioctl.c is geting compiled with CONFIG_SCSI=n. Seems odd. (Actually, it's failing to compile (in the middle of the bsg series) so I need to fix it by hand somehow to continue this bisect) - 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: sim710_device_remove seems buggy
On Tue, Jul 17, 2007 at 01:57:48PM -0500, James Bottomley wrote:
> That's certainly the way lasi700 does it ... so it makes sense that this
> driver should as well.
OK. Here's a patch to fix all the other drivers that had copied this
one:
Fix drivers misusing dev_to_shost
Some drivers were using dev_to_shost to go from a struct device to the
corresponding shost. Unfortunately, dev_to_shost only looks up the tree
to find an shost (it's designed to go from a scsi_device or a
scsi_target to the parent scsi_host), and these drivers were calling it
with the parent of the scsi_host.
I've fixed this by saving a pointer to the Scsi_Host in the drvdata,
which matches what most scsi drivers do.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
diff --git a/drivers/scsi/a4000t.c b/drivers/scsi/a4000t.c
index 6a57846..0c758d1 100644
--- a/drivers/scsi/a4000t.c
+++ b/drivers/scsi/a4000t.c
@@ -79,6 +79,7 @@ static int __devinit a4000t_probe(struct device *dev)
goto out_put_host;
}
+ dev_set_drvdata(dev, host);
scsi_scan_host(host);
return 0;
@@ -95,7 +96,7 @@ static int __devinit a4000t_probe(struct device *dev)
static __devexit int a4000t_device_remove(struct device *dev)
{
- struct Scsi_Host *host = dev_to_shost(dev);
+ struct Scsi_Host *host = dev_get_drvdata(dev);
struct NCR_700_Host_Parameters *hostdata = shost_priv(host);
scsi_remove_host(host);
diff --git a/drivers/scsi/bvme6000_scsi.c b/drivers/scsi/bvme6000_scsi.c
index 012cdea..cac3540 100644
--- a/drivers/scsi/bvme6000_scsi.c
+++ b/drivers/scsi/bvme6000_scsi.c
@@ -74,6 +74,7 @@ bvme6000_probe(struct device *dev)
goto out_put_host;
}
+ dev_set_drvdata(dev, host);
scsi_scan_host(host);
return 0;
@@ -89,7 +90,7 @@ bvme6000_probe(struct device *dev)
static __devexit int
bvme6000_device_remove(struct device *dev)
{
- struct Scsi_Host *host = dev_to_shost(dev);
+ struct Scsi_Host *host = dev_get_drvdata(dev);
struct NCR_700_Host_Parameters *hostdata = shost_priv(host);
scsi_remove_host(host);
diff --git a/drivers/scsi/mvme16x_scsi.c b/drivers/scsi/mvme16x_scsi.c
index d6ef22a..1bdddad 100644
--- a/drivers/scsi/mvme16x_scsi.c
+++ b/drivers/scsi/mvme16x_scsi.c
@@ -89,6 +89,7 @@ mvme16x_probe(struct device *dev)
out_be32(0xfff4202c, v);
}
+ dev_set_drvdata(dev, host);
scsi_scan_host(host);
return 0;
@@ -104,7 +105,7 @@ mvme16x_probe(struct device *dev)
static __devexit int
mvme16x_device_remove(struct device *dev)
{
- struct Scsi_Host *host = dev_to_shost(dev);
+ struct Scsi_Host *host = dev_get_drvdata(dev);
struct NCR_700_Host_Parameters *hostdata = shost_priv(host);
/* Disable scsi chip ints */
diff --git a/drivers/scsi/sim710.c b/drivers/scsi/sim710.c
index 018c65f..6ab11b4 100644
--- a/drivers/scsi/sim710.c
+++ b/drivers/scsi/sim710.c
@@ -139,6 +139,7 @@ sim710_probe_common(struct device *dev, unsigned long
base_addr,
goto out_put_host;
}
+ dev_set_drvdata(dev, host);
scsi_scan_host(host);
return 0;
@@ -156,7 +157,7 @@ sim710_probe_common(struct device *dev, unsigned long
base_addr,
static __devexit int
sim710_device_remove(struct device *dev)
{
- struct Scsi_Host *host = dev_to_shost(dev);
+ struct Scsi_Host *host = dev_get_drvdata(dev);
struct NCR_700_Host_Parameters *hostdata =
(struct NCR_700_Host_Parameters *)host->hostdata[0];
diff --git a/drivers/scsi/zorro7xx.c b/drivers/scsi/zorro7xx.c
index 5070387..c822deb 100644
--- a/drivers/scsi/zorro7xx.c
+++ b/drivers/scsi/zorro7xx.c
@@ -130,6 +130,7 @@ static int __devinit zorro7xx_init_one(struct zorro_dev *z,
goto out_put_host;
}
+ zorro_set_drvdata(z, host);
scsi_scan_host(host);
return 0;
@@ -148,7 +149,7 @@ static int __devinit zorro7xx_init_one(struct zorro_dev *z,
static __devexit void zorro7xx_remove_one(struct zorro_dev *z)
{
- struct Scsi_Host *host = dev_to_shost(&z->dev);
+ struct Scsi_Host *host = zorro_get_drvdata(z);
struct NCR_700_Host_Parameters *hostdata = shost_priv(host);
scsi_remove_host(host);
--
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
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: block/bsg.c
On Tue, 17 Jul 2007 08:38:11 +0200 Jens Axboe <[EMAIL PROTECTED]> 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. - 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: aic7xxx: tape always rewinds since linux-2.6.15
On Tue, 17 Jul 2007, Frank Hempel wrote: > Hello, > > I have expierenced a problem with the aic7xxx driver or the scsi tape support > in the linux kernel. > > [Problem Description] > Under linux kernels since 2.6.15 every "action" I issue to the tape drive (I > mainly do this via from the cpio package) is done but additionaly to > every mt call a tape rewind is done too. So for example positioning the tape > at some particular position is impossible because after the positioning itself > it is rewinded automagically. > Under kernels before and including 2.6.14.7 this problem did not occur. > ... > [Attachments] > kernel-config ... the relevant scsi-switches for all the > kernels I used > 14.7.dmesg... the (hopefully) relevant dmesg output from > 2.6.14.7 kernel > 14.7.mt-status-after-boot ... the output of "mt status" after boot (tape > was at block 0) > 14.7.mt-fsf-2.kern.log... the kernel output during "mt fsf 2" > 14.7.mt-status-after-mt-fsf-2 ... the output of "mt status" after "mt fsf 2" > (file number is now *2*) /dev/tape is link to /dev/nst0 or the environment variable TAPE has value /dev/nst0? > 15.dmesg ... the (hopefully) relevant dmesg output from > 2.15 kernel > 15.mt-status-after-boot ... the output of "mt -f /dev/st0 status" after > boot (tape was at block 0) > 15.mt-fsf-2.kern.log ... the kernel output during "mt -f /dev/st0 fsf > 2" The device /dev/st0 is usually the auto-rewind device and, by definition, the tape is rewound after the device is closed. You should use /dev/nst0 if you don't want the tape to be rewound after close. If the tape was not rewound before 2.6.15 when you used /dev/st0, that was a problem. -- Kai - 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] gdth: remove redundant PCI stuff
On Tue, Jul 17, 2007 at 05:25:17AM -0400, Jeff Garzik wrote: > This patch > > * removes struct members that duplicate pci_dev members > * replaces ha->stype usage with ha->pdev->device usage where feasible These two bits look nice. > * removes PCI IDs that are already in include/linux/pci_ids.h note sure about this one. The list of partially unused pci ids in the header is one of the few guidelines what pci ids are actually supported by this driver. And btw, please Cc Achim on your patches, he still maintains the driver although it sometimes seems hard to actually get your patches into his inbox. - 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: sim710_device_remove seems buggy
On Tue, 2007-07-17 at 12:52 -0600, Matthew Wilcox wrote: > On Tue, Jul 17, 2007 at 10:55:21AM -0600, Matthew Wilcox wrote: > > Unfortunately, I don't have a good idea about how to solve this. The > > least lame perhaps is to have separate routines for EISA and MCA > > devices, each of which passes the shost to this routine. > > I had an idea. How does this look? It's what I'm doing in advansys. > Note that I've not tested it more than compilation ... need to get the > EISA configurator running on parisc-linux in order to test it. That's certainly the way lasi700 does it ... so it makes sense that this driver should as well. 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: block/bsg.c
On Tue, 2007-07-17 at 12:19 +0200, Jens Axboe wrote:
> > > Since Linus is happily snoring by now, could you test and see if the
> > > tree works for you?
> >
> > It works for me. I'll submit some minor patches against your bsg
> > branch to scsi-ml. Can you push them together?
>
> Certainly, I'll pull them into the bsg branch.
While you're at it, here's a patch to separate BSG and SCSI again (so
SCSI can be built modular). The way I did it was simply to move the
SCSI specific logic into SCSI. When you come up with a generic way to
register the bsg requiring drivers, then we can move it out again.
James
diff --git a/block/Kconfig b/block/Kconfig
index 6597b60..3468d75 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -53,7 +53,7 @@ endif # BLOCK
config BLK_DEV_BSG
bool "Block layer SG support"
- depends on (SCSI=y) && EXPERIMENTAL
+ depends on EXPERIMENTAL
default y
---help---
Saying Y here will enable generic SG (SCSI generic) v4
diff --git a/block/bsg.c b/block/bsg.c
index 576933f..1d9e6f7 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -1030,29 +1030,6 @@ err:
}
EXPORT_SYMBOL_GPL(bsg_register_queue);
-static int bsg_add(struct class_device *cl_dev, struct class_interface
*cl_intf)
-{
- int ret;
- struct scsi_device *sdp = to_scsi_device(cl_dev->dev);
- struct request_queue *rq = sdp->request_queue;
-
- if (rq->kobj.parent)
- ret = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
- else
- ret = bsg_register_queue(rq,
kobject_name(&sdp->sdev_gendev.kobj));
- return ret;
-}
-
-static void bsg_remove(struct class_device *cl_dev, struct class_interface
*cl_intf)
-{
- bsg_unregister_queue(to_scsi_device(cl_dev->dev)->request_queue);
-}
-
-static struct class_interface bsg_intf = {
- .add= bsg_add,
- .remove = bsg_remove,
-};
-
static struct cdev bsg_cdev = {
.kobj = {.name = "bsg", },
.owner = THIS_MODULE,
@@ -1094,15 +1071,6 @@ static int __init bsg_init(void)
return ret;
}
- ret = scsi_register_interface(&bsg_intf);
- if (ret) {
- printk(KERN_ERR "bsg: failed register scsi interface %d\n",
ret);
- kmem_cache_destroy(bsg_cmd_cachep);
- class_destroy(bsg_class);
- unregister_chrdev(BSG_MAJOR, "bsg");
- return ret;
- }
-
printk(KERN_INFO "%s loaded\n", bsg_version);
return 0;
}
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index ed72086..fcbe94c 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -714,6 +714,7 @@ static int attr_add(struct device *dev, struct
device_attribute *attr)
int scsi_sysfs_add_sdev(struct scsi_device *sdev)
{
int error, i;
+ struct request_queue *rq = sdev->request_queue;
if ((error = scsi_device_set_state(sdev, SDEV_RUNNING)) != 0)
return error;
@@ -733,6 +734,16 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
/* take a reference for the sdev_classdev; this is
* released by the sdev_class .release */
get_device(&sdev->sdev_gendev);
+
+ if (rq->kobj.parent)
+ error = bsg_register_queue(rq, kobject_name(rq->kobj.parent));
+ else
+ error = bsg_register_queue(rq,
kobject_name(&sdev->sdev_gendev.kobj));
+ if (error) {
+ sdev_printk(KERN_INFO, sdev, "Failed to register bsg queue\n");
+ goto out;
+ }
+
if (sdev->host->hostt->sdev_attrs) {
for (i = 0; sdev->host->hostt->sdev_attrs[i]; i++) {
error = attr_add(&sdev->sdev_gendev,
@@ -779,6 +790,7 @@ void __scsi_remove_device(struct scsi_device *sdev)
if (scsi_device_set_state(sdev, SDEV_CANCEL) != 0)
return;
+ bsg_unregister_queue(sdev->request_queue);
class_device_unregister(&sdev->sdev_classdev);
transport_remove_device(dev);
device_del(dev);
-
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: sim710_device_remove seems buggy
On Tue, Jul 17, 2007 at 10:55:21AM -0600, Matthew Wilcox wrote:
> Unfortunately, I don't have a good idea about how to solve this. The
> least lame perhaps is to have separate routines for EISA and MCA
> devices, each of which passes the shost to this routine.
I had an idea. How does this look? It's what I'm doing in advansys.
Note that I've not tested it more than compilation ... need to get the
EISA configurator running on parisc-linux in order to test it.
diff --git a/drivers/scsi/sim710.c b/drivers/scsi/sim710.c
index 018c65f..6ab11b4 100644
--- a/drivers/scsi/sim710.c
+++ b/drivers/scsi/sim710.c
@@ -139,6 +139,7 @@ sim710_probe_common(struct device *dev, unsigned long
base_addr,
goto out_put_host;
}
+ dev_set_drvdata(dev, host);
scsi_scan_host(host);
return 0;
@@ -156,7 +157,7 @@ sim710_probe_common(struct device *dev, unsigned long
base_addr,
static __devexit int
sim710_device_remove(struct device *dev)
{
- struct Scsi_Host *host = dev_to_shost(dev);
+ struct Scsi_Host *host = dev_get_drvdata(dev);
struct NCR_700_Host_Parameters *hostdata =
(struct NCR_700_Host_Parameters *)host->hostdata[0];
--
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
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] aacraid: add vpd to inquiry (take 2)
It was reported to me that the 'ADPT' leading the serial number was bad form, that the inquiry vendor field was enough to differentiate the storage uniquely. Subsequent search found that another Adaptec AAC based driver reported the 8 hex serial number only without such adornments, so dropped ADPT to match. Resubmitting the patch with this alteration. This attached patch is against current scsi-misc-2.6 ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> drivers/scsi/aacraid/aachba.c | 138 + drivers/scsi/aacraid/aacraid.h | 14 2 files changed, 152 insertions(+) Sincerely -- Mark Salyzyn > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Salyzyn, Mark > Sent: Monday, July 16, 2007 5:08 PM > To: linux-scsi@vger.kernel.org > Subject: [PATCH] aacraid: add vpd to inquiry > > Report VPD inquiry page 0x80 with an unique array creation > serial number > (CUID). When an array is created, the metadata stored on the physical > drives gets an unique serial number. This serial number > remains constant > through array morphing or migration to other controllers. > This patch is > a forward port and modification to survive morphing and migration > operations, of a similar piece of (un-attributed author) code added to > the SLES10 SP1 aacraid driver. > > To test the results of the patch, observe that > /dev/disk/by-id/ entries > will show up for the arrays resulting from the udev rules. > Also, as per > the udev rules, 'scsi_id -g -x -a -s /block/sd? -d /dev/sd?' > will report > the ID_SERIAL as constructed from the inquiry data. aacraid_vpd2.patch Description: aacraid_vpd2.patch
aic7xxx: tape always rewinds since linux-2.6.15
Hello, I have expierenced a problem with the aic7xxx driver or the scsi tape support in the linux kernel. [Problem Description] Under linux kernels since 2.6.15 every "action" I issue to the tape drive (I mainly do this via from the cpio package) is done but additionaly to every mt call a tape rewind is done too. So for example positioning the tape at some particular position is impossible because after the positioning itself it is rewinded automagically. Under kernels before and including 2.6.14.7 this problem did not occur. [My Hardware Setup] *i686 pc style hardware *Adaptec 2940 Ultra SCSI adapter (aic7880) *attached tape drive: HP SureStore DAT40 (C5683A) [Kernel Config] see attachments for relevant switches [What I Have Done Until Now] *I testet kernel 2.6.22.1 to verify the problem still exists in latest kernel *I compiled and used mt from latest unpatched cpio-2.9 (to make sure it is not related to the heavily patched debian version) *I compiled debug code for aic7xxx in the kernels (unfortunatly the debug output don't show any inregularities (see attachments)) *I verified that mt is not just telling me wrong file numbers or block positions: with reading a file from tape with dd it turns out that the tape position must have been the tape start (using kernel 2.6.15+) *I reverted the two patches I found stated in changelog of 2.6.15 relating the aic7xxx module. This is "aci7xxx: reset handler selects a wrong command" and "aic7xxx: remove scsi_assign_lock usage". It did not solve the problem, even taking the complete aic7xxx_osm.c from 2.6.14.7 to the 2.6.15 source tree did not change the situation. So the problem may be somewhere else in the aic7xxx-module. [Attachments] kernel-config ... the relevant scsi-switches for all the kernels I used 14.7.dmesg... the (hopefully) relevant dmesg output from 2.6.14.7 kernel 14.7.mt-status-after-boot ... the output of "mt status" after boot (tape was at block 0) 14.7.mt-fsf-2.kern.log... the kernel output during "mt fsf 2" 14.7.mt-status-after-mt-fsf-2 ... the output of "mt status" after "mt fsf 2" (file number is now *2*) 15.dmesg ... the (hopefully) relevant dmesg output from 2.15 kernel 15.mt-status-after-boot ... the output of "mt -f /dev/st0 status" after boot (tape was at block 0) 15.mt-fsf-2.kern.log ... the kernel output during "mt -f /dev/st0 fsf 2" 15.mt-status-after-mt-fsf-2 ... the output of "mt status" after "mt -f /dev/st0 fsf 2" (file number is now *0*) If this might really be a problem in the aic7xxx module I hope I could and can help pointing it out. So if I should do something else to give you more or more precise information please let me know... Thank you very much... Frank # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # # CONFIG_BLK_DEV_SD is not set CONFIG_CHR_DEV_ST=y # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI Transport Attributes # CONFIG_SCSI_SPI_ATTRS=y # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W__RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=2047 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA24XX is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set Linux version 2.6.14.7-vanilla ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 Tue Jul 17 03:22:
RE: [PATCH] mpt fusion: add sysfs attributes to display IOC parameters
On Tuesday, July 17, 2007 3:09 AM, Prakash, Sathya wrote: > Reposting as this patch is not visible in the list yet. > > Resubmitting with the following change suggested by Brian King: > The driver version from scsi_host attribute is redundant as > it is already > available in sysfs: /sys/module/mptscsih/version. > So it is removed from the patch > > --- > New sysfs scsi_host attributes are added to provide > information about Firmware > version, BIOS version, MPI version and other product related > information. > > signed-off-by: Sathya Praksh <[EMAIL PROTECTED]> > --- ACK Eric Moore - 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
sim710_device_remove seems buggy
Hi Richard,
I was looking for inspiration in sim710 when I found what appears to me
to be a bug. Your implementation of sim710_device_remove does:
sim710_device_remove(struct device *dev)
{
struct Scsi_Host *host = dev_to_shost(dev);
Now, this is going to be called with the struct device corresponding to
either the MCA or EISA device which is the *parent* of the shost.
dev_to_shost only looks upwards in the tree, so it will never find the
shost.
Unfortunately, I don't have a good idea about how to solve this. The
least lame perhaps is to have separate routines for EISA and MCA
devices, each of which passes the shost to this routine.
--
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
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] mpt fusion: add support for Brocade branded LSI FC HBA
On Tuesday, July 17, 2007 2:49 AM, Prakash, Sathya wrote: > > Resubmitting with Eric Moore suggested modifications: > --- > Add support for Brocade 410/420 4Gbit FC HBAs. > They are re-branded LSI HBAs [LSI7104EP-LC/LSI7204EP-LC] > > This patch should be applied over the following patches: > 1. mpt fusion: deregister from transport layer if PCI > registration failed > 2. mpt fusion: add sysfs attributes to display IOC parameters > 3. add PCI_VENDOR_ID macro for Brocade in pci_ids.h > > signed-off-by: Sathya Prakash <[EMAIL PROTECTED]> > --- ACK Eric Moore - 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: PS3 Storage Driver O_DIRECT issue
Geert Uytterhoeven wrote: > On Fri, 13 Jul 2007, Olaf Hering wrote: >> This driver (or the generic PS3 code) has appearently problems with >> O_DIRECT. >> glibc aborts parted because the malloc metadata get corrupted. While it >> is reproducible, the place where it crashes changes with every version >> of the debug attempt. >> I dont have a handle right now, all I know is that the metadata after a >> malloc area get overwritten with zeros. >> >> >> Can you have a look at this? >> parted /dev/ps3da >> print (a few times) > > I can't seem to reproduce this with parted 1.7.1-5.1 (from Debian > etch/lenny/sid) and kernel 2.6.22-g77320894. Hi. I found this happens on Fedora 7: [EMAIL PROTECTED] ~]# uname -a Linux ps3-nfs 2.6.22-ps3-linux-dev-g4d898766-dirty #1 SMP Wed Jul 11 13:29:46 PDT 2007 ppc64 ppc64 ppc64 GNU/Linux [EMAIL PROTECTED] ~]# parted --version parted (GNU parted) 1.8.6 Here is the error message from parted: Command History: print Error: SEGV_MAPERR (Address not mapped to object) Backtrace has 20 calls on stack: 20: /usr/lib/libparted-1.8.so.6(ped_assert+0xb0) [0xfb7ea50] 19: parted [0x1000c6dc] 18: [0x100350] 17: [(nil)] 16: /lib/libc.so.6 [0xfdcfe64] 15: /lib/libc.so.6 [0xfdd0b34] 14: /lib/libc.so.6(__libc_memalign+0xec) [0xfdd1e1c] 13: /lib/libc.so.6(posix_memalign+0xbc) [0xfdd207c] 12: /usr/lib/libparted-1.8.so.6 [0xfb8f42c] 11: /usr/lib/libparted-1.8.so.6(ped_device_read+0x164) [0xfb7f5f4] 10: /usr/lib/libparted-1.8.so.6(ped_geometry_read+0x16c) [0xfb89a5c] 9: /usr/lib/libparted-1.8.so.6 [0xfba739c] 8: /usr/lib/libparted-1.8.so.6(ped_file_system_probe_specific+0x104) [0xfb80d04] 7: /usr/lib/libparted-1.8.so.6(ped_file_system_probe+0xec) [0xfb8134c] 6: /usr/lib/libparted-1.8.so.6 [0xfbbcc38] 5: /usr/lib/libparted-1.8.so.6 [0xfbbcfb4] 4: /usr/lib/libparted-1.8.so.6(ped_disk_new+0xc0) [0xfb88bf0] 3: parted [0x10006e00] 2: parted(command_run+0x1c) [0x10004d8c] 1: parted(interactive_mode+0x134) [0x1000e4b4] Aborted - 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: advansys cleanup
On Tue, Jul 17, 2007 at 11:36:11AM -0400, Ken Witherow wrote: > Instead, I pulled the raw advansys.c from the tree provided and dropped > that in place. Hm, sorry about that. I suspect that advansys.c has changed since 2.6.22. > CC drivers/scsi/advansys.o > drivers/scsi/advansys.c:795:2: warning: #warning this driver is still not > properly converted to the DMA API Yeah, I'm not planning on getting rid of that warning. Yet, anyway. > MODPOST vmlinux > WARNING: drivers/built-in.o(.text+0x99045): Section mismatch: reference to > .init.text: (between 'advansys_board_found' and 'advansys_pci_probe') Oops. Probably simple to fix, I'll look into that. > > I've attached my regular dmesg as well as my dmesg with the failure of the > updated advansys driver. The important bit is this one: -ACPI: PCI Interrupt :00:09.0[A] -> GSI 17 (level, low) -> IRQ 16 -scsi0 : AdvanSys SCSI 3.3K: PCI Ultra: IO 0x1800-0x180F, IRQ 0x10 +scsi0 : AdvanSys SCSI 3.3K: PCI Ultra: IO 0x1800-0x180F, IRQ 0x5 +advansys: advansys_detect: unknown bus type: 4 Somehow I've messed up the IRQ. The unknown bus type is just a minor oversight -- i ripped out the handling of PCI bus types from advansys_detect, but let it try to probe for them anyway, which it no longer knows how to handle. > I'd be glad to attempt the patches again. It would be easier for me if you > sent me the raw patches, if possible. How about I send you a patch on top of the advansys.c you got from that git tree? -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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] libsas: fix lockdep issue with ATA
On Tue, 2007-07-17 at 09:12 -0500, James Bottomley wrote:
> > process context, no need to save flags here either.
>
> OK, you caught me ... I was just doing the fastest thing I could to get
> lockdep to shut up. By the way, it dumps about 120KB of logs so it's
> fun to get an actual trace of this...
>
> I'll make the fixes and resubmit
Here's the update.
James
---
>From 0852ea7aafd0368026e8dacd7810c2444adb8d19 Mon Sep 17 00:00:00 2001
From: James Bottomley <[EMAIL PROTECTED]>
Date: Mon, 16 Jul 2007 13:15:51 -0500
Subject: [SCSI] libsas: fix lockdep issue with ATA
lockdep noticed that with ATA support the port->dev_list_lock was
entangled at irq context, so it now needs to become IRQ safe
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/libsas/sas_discover.c | 10 ++
drivers/scsi/libsas/sas_expander.c | 14 --
2 files changed, 14 insertions(+), 10 deletions(-)
Index: BUILD-2.6/drivers/scsi/libsas/sas_discover.c
===
--- BUILD-2.6.orig/drivers/scsi/libsas/sas_discover.c 2007-07-17
11:15:48.0 -0500
+++ BUILD-2.6/drivers/scsi/libsas/sas_discover.c2007-07-17
11:26:47.0 -0500
@@ -304,9 +304,9 @@ static int sas_get_port_device(struct as
port->disc.max_level = 0;
dev->rphy = rphy;
- spin_lock(&port->dev_list_lock);
+ spin_lock_irq(&port->dev_list_lock);
list_add_tail(&dev->dev_list_node, &port->dev_list);
- spin_unlock(&port->dev_list_lock);
+ spin_unlock_irq(&port->dev_list_lock);
return 0;
}
@@ -703,9 +703,9 @@ static void sas_discover_domain(struct w
sas_rphy_free(dev->rphy);
dev->rphy = NULL;
- spin_lock(&port->dev_list_lock);
+ spin_lock_irq(&port->dev_list_lock);
list_del_init(&dev->dev_list_node);
- spin_unlock(&port->dev_list_lock);
+ spin_unlock_irq(&port->dev_list_lock);
kfree(dev); /* not kobject_register-ed yet */
port->port_dev = NULL;
Index: BUILD-2.6/drivers/scsi/libsas/sas_expander.c
===
--- BUILD-2.6.orig/drivers/scsi/libsas/sas_expander.c 2007-07-17
11:15:48.0 -0500
+++ BUILD-2.6/drivers/scsi/libsas/sas_expander.c2007-07-17
11:28:33.0 -0500
@@ -677,9 +677,9 @@ static struct domain_device *sas_ex_disc
child->rphy = rphy;
- spin_lock(&parent->port->dev_list_lock);
+ spin_lock_irq(&parent->port->dev_list_lock);
list_add_tail(&child->dev_list_node, &parent->port->dev_list);
- spin_unlock(&parent->port->dev_list_lock);
+ spin_unlock_irq(&parent->port->dev_list_lock);
res = sas_discover_sata(child);
if (res) {
@@ -701,9 +701,9 @@ static struct domain_device *sas_ex_disc
child->rphy = rphy;
sas_fill_in_rphy(child, rphy);
- spin_lock(&parent->port->dev_list_lock);
+ spin_lock_irq(&parent->port->dev_list_lock);
list_add_tail(&child->dev_list_node, &parent->port->dev_list);
- spin_unlock(&parent->port->dev_list_lock);
+ spin_unlock_irq(&parent->port->dev_list_lock);
res = sas_discover_end_dev(child);
if (res) {
@@ -816,9 +816,9 @@ static struct domain_device *sas_ex_disc
sas_fill_in_rphy(child, rphy);
sas_rphy_add(rphy);
- spin_lock(&parent->port->dev_list_lock);
+ spin_lock_irq(&parent->port->dev_list_lock);
list_add_tail(&child->dev_list_node, &parent->port->dev_list);
- spin_unlock(&parent->port->dev_list_lock);
+ spin_unlock_irq(&parent->port->dev_list_lock);
res = sas_discover_expander(child);
if (res) {
-
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] aacraid: incorrect dma mapping mask during blinkled recover or user initiated reset
Incorrect dma mask was used for blinkled (firmware assert) recovery or user initiated reset during initialization portion. Ensure that all callers of aac_fib_map_free null out the fib allocation references to prevent multiple free. Although serious sounding, no reports of these problems have surfaced... This attached patch is against current scsi-misc-2.6 ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> drivers/scsi/aacraid/commsup.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) Sincerely -- Mark Salyzyn aacraid_mapping_failure.patch Description: aacraid_mapping_failure.patch
[PATCH] aacraid: correct valid container response in management ioctl
During an Adapter Initiated scan request, the query disk ioctl reports a value of 2 rather than 1 for the valid field. This presents a problem for some legacy management applications. This attached patch is against current scsi-misc-2.6 ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> drivers/scsi/aacraid/aachba.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Sincerely -- Mark Salyzyn aacraid_valid_check.patch Description: aacraid_valid_check.patch
Re: advansys cleanup
On Mon, Jul 16, 2007 at 02:28:15PM -0600, Matthew Wilcox wrote: > I have to run, but here's what I've benn working on today if anyone > wants to test: > > http://git.kernel.org/pub/scm/linux/kernel/git/willy/advansys-2.6.git I was in so much of a hurry that I got the URL wrong. It is: http://git.kernel.org/?p=linux/kernel/git/willy/advansys.git;a=summary I've posted the four patches that this git contains. I don't have an advansys card of my own, so I'm looking for testers. It compiles cleanly, but that's about the best I can say about it. I'm looking to do some more work on it today, including fixing the dreadful job somebody did of removing the check_region calls. It'd be helpful to know that this much works (and if it doesn't, at which point in the patch series it stops working). -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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] libsas: fix lockdep issue with ATA
On Tue, 2007-07-17 at 13:29 +0200, Jens Axboe wrote:
> On Mon, Jul 16 2007, James Bottomley wrote:
> > lockdep noticed that with ATA support the port->dev_list_lock was
> > entangled at irq context, so it now needs to become IRQ safe
> >
> > ---
> > This applies against the aic94xx-sas-2.6 tree
> >
> > James
> >
> > diff --git a/drivers/scsi/libsas/sas_discover.c
> > b/drivers/scsi/libsas/sas_discover.c
> > index a18c0f6..ce3385c 100644
> > --- a/drivers/scsi/libsas/sas_discover.c
> > +++ b/drivers/scsi/libsas/sas_discover.c
> > @@ -292,9 +292,9 @@ static int sas_get_port_device(struct asd_sas_port
> > *port)
> > port->disc.max_level = 0;
> >
> > dev->rphy = rphy;
> > - spin_lock(&port->dev_list_lock);
> > + spin_lock_irqsave(&port->dev_list_lock, flags);
> > list_add_tail(&dev->dev_list_node, &port->dev_list);
> > - spin_unlock(&port->dev_list_lock);
> > + spin_unlock_irqrestore(&port->dev_list_lock, flags);
> >
> > return 0;
> > }
>
> already uses GFP_KERNEL, so spin_lock_irq() suffices.
>
> > @@ -688,12 +688,14 @@ static void sas_discover_domain(struct work_struct
> > *work)
> > }
> >
> > if (error) {
> > + unsigned long flags;
> > +
> > sas_rphy_free(dev->rphy);
> > dev->rphy = NULL;
> >
> > - spin_lock(&port->dev_list_lock);
> > + spin_lock_irqsave(&port->dev_list_lock, flags);
> > list_del_init(&dev->dev_list_node);
> > - spin_unlock(&port->dev_list_lock);
> > + spin_unlock_irqrestore(&port->dev_list_lock, flags);
> >
> > kfree(dev); /* not kobject_register-ed yet */
> > port->port_dev = NULL;
>
> process context, no need to save flags here either.
OK, you caught me ... I was just doing the fastest thing I could to get
lockdep to shut up. By the way, it dumps about 120KB of logs so it's
fun to get an actual trace of this...
I'll make the fixes and resubmit
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 19/33] scsi_debug: support sg chaining
On Tue, Jul 17 2007, Boaz Harrosh wrote: > Jens Axboe wrote ... > > Cc: [EMAIL PROTECTED] > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > --- > > drivers/scsi/scsi_debug.c | 30 -- > > 1 files changed, 16 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c > > index 4cd9c58..46a3e07 100644 > > --- a/drivers/scsi/scsi_debug.c > > +++ b/drivers/scsi/scsi_debug.c > > (Majordumo has unsubscribed me from list since yesterday) > (Don't know why. So this will appear out of order ) > > Jens Hi! > > I have queued for submission a: > "convert to use the data buffer accessors and !use_sg cleanup" > for this driver Just the other day. Should we not push the > cleanups first before this. That is what we did with other > drivers. > > I have also sent patches for ide-scsi > > I Have in my Q cleanup patches for: > drivers/scsi/qla1280.c > drivers/scsi/qlogicpti.c > drivers/scsi/aha1542.c > drivers/scsi/advansys.c > And more ... > > And also for this one > drivers/scsi/gdth.c > But that one has a patch in Q and I should rebase. > > If you want I can rebase all your driver patches above > to my patches. Than send cleanup patches to the list and > rebasing of sg-chaining if needed to you. I can send all > cleanup patches tonight, and your rebases tomorrow. Go ahead and submit whatever driver cleanups, I'll just rebase and drop patches from my branch as necessary! Less work for me :-) -- 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 19/33] scsi_debug: support sg chaining
Jens Axboe wrote ... > Cc: [EMAIL PROTECTED] > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > --- > drivers/scsi/scsi_debug.c | 30 -- > 1 files changed, 16 insertions(+), 14 deletions(-) > > diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c > index 4cd9c58..46a3e07 100644 > --- a/drivers/scsi/scsi_debug.c > +++ b/drivers/scsi/scsi_debug.c (Majordumo has unsubscribed me from list since yesterday) (Don't know why. So this will appear out of order ) Jens Hi! I have queued for submission a: "convert to use the data buffer accessors and !use_sg cleanup" for this driver Just the other day. Should we not push the cleanups first before this. That is what we did with other drivers. I have also sent patches for ide-scsi I Have in my Q cleanup patches for: drivers/scsi/qla1280.c drivers/scsi/qlogicpti.c drivers/scsi/aha1542.c drivers/scsi/advansys.c And more ... And also for this one drivers/scsi/gdth.c But that one has a patch in Q and I should rebase. If you want I can rebase all your driver patches above to my patches. Than send cleanup patches to the list and rebasing of sg-chaining if needed to you. I can send all cleanup patches tonight, and your rebases tomorrow. Boaz - 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] Don't define empty struct bsg_class_device if !CONFIG_BLK_DEV_BSG (was: Re: block/bsg.c)
On Tue, Jul 17 2007, Geert Uytterhoeven wrote: > Don't define an empty struct bsg_class_device if !CONFIG_BLK_DEV_BSG. > > It's embedded in struct request_queue, but there we have > > #if defined(CONFIG_BLK_DEV_BSG) > struct bsg_class_device bsg_dev; > #endif > > anyway. Thanks, applied. -- 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
[PATCH] Don't define empty struct bsg_class_device if !CONFIG_BLK_DEV_BSG (was: Re: block/bsg.c)
Don't define an empty struct bsg_class_device if !CONFIG_BLK_DEV_BSG.
It's embedded in struct request_queue, but there we have
#if defined(CONFIG_BLK_DEV_BSG)
struct bsg_class_device bsg_dev;
#endif
anyway.
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
At first I considered dropping the #ifdef around request_queue.bsg_dev, but
that would make the code more error-prone.
include/linux/bsg.h |1 -
1 files changed, 1 deletion(-)
--- a/include/linux/bsg.h
+++ b/include/linux/bsg.h
@@ -60,7 +60,6 @@ struct bsg_class_device {
extern int bsg_register_queue(struct request_queue *, const char *);
extern void bsg_unregister_queue(struct request_queue *);
#else
-struct bsg_class_device { };
#define bsg_register_queue(disk, name) (0)
#define bsg_unregister_queue(disk) do { } while (0)
#endif
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: [PATCH] libsas: fix lockdep issue with ATA
On Mon, Jul 16 2007, James Bottomley wrote:
> lockdep noticed that with ATA support the port->dev_list_lock was
> entangled at irq context, so it now needs to become IRQ safe
>
> ---
> This applies against the aic94xx-sas-2.6 tree
>
> James
>
> diff --git a/drivers/scsi/libsas/sas_discover.c
> b/drivers/scsi/libsas/sas_discover.c
> index a18c0f6..ce3385c 100644
> --- a/drivers/scsi/libsas/sas_discover.c
> +++ b/drivers/scsi/libsas/sas_discover.c
> @@ -292,9 +292,9 @@ static int sas_get_port_device(struct asd_sas_port *port)
> port->disc.max_level = 0;
>
> dev->rphy = rphy;
> - spin_lock(&port->dev_list_lock);
> + spin_lock_irqsave(&port->dev_list_lock, flags);
> list_add_tail(&dev->dev_list_node, &port->dev_list);
> - spin_unlock(&port->dev_list_lock);
> + spin_unlock_irqrestore(&port->dev_list_lock, flags);
>
> return 0;
> }
already uses GFP_KERNEL, so spin_lock_irq() suffices.
> @@ -688,12 +688,14 @@ static void sas_discover_domain(struct work_struct
> *work)
> }
>
> if (error) {
> + unsigned long flags;
> +
> sas_rphy_free(dev->rphy);
> dev->rphy = NULL;
>
> - spin_lock(&port->dev_list_lock);
> + spin_lock_irqsave(&port->dev_list_lock, flags);
> list_del_init(&dev->dev_list_node);
> - spin_unlock(&port->dev_list_lock);
> + spin_unlock_irqrestore(&port->dev_list_lock, flags);
>
> kfree(dev); /* not kobject_register-ed yet */
> port->port_dev = NULL;
process context, no need to save flags here either.
> diff --git a/drivers/scsi/libsas/sas_expander.c
> b/drivers/scsi/libsas/sas_expander.c
> index d05fc23..1c15f37 100644
> --- a/drivers/scsi/libsas/sas_expander.c
> +++ b/drivers/scsi/libsas/sas_expander.c
> @@ -628,6 +628,7 @@ static struct domain_device *sas_ex_discover_end_dev(
> struct domain_device *child = NULL;
> struct sas_rphy *rphy;
> int res;
> + unsigned long flags;
>
> if (phy->attached_sata_host || phy->attached_sata_ps)
> return NULL;
> @@ -677,9 +678,9 @@ static struct domain_device *sas_ex_discover_end_dev(
>
> child->rphy = rphy;
>
> - spin_lock(&parent->port->dev_list_lock);
> + spin_lock_irqsave(&parent->port->dev_list_lock, flags);
> list_add_tail(&child->dev_list_node, &parent->port->dev_list);
> - spin_unlock(&parent->port->dev_list_lock);
> + spin_unlock_irqrestore(&parent->port->dev_list_lock, flags);
>
> res = sas_discover_sata(child);
> if (res) {
ditto
> @@ -701,9 +702,9 @@ static struct domain_device *sas_ex_discover_end_dev(
> child->rphy = rphy;
> sas_fill_in_rphy(child, rphy);
>
> - spin_lock(&parent->port->dev_list_lock);
> + spin_lock_irqsave(&parent->port->dev_list_lock, flags);
> list_add_tail(&child->dev_list_node, &parent->port->dev_list);
> - spin_unlock(&parent->port->dev_list_lock);
> + spin_unlock_irqrestore(&parent->port->dev_list_lock, flags);
>
> res = sas_discover_end_dev(child);
> if (res) {
ditto
> @@ -767,6 +768,7 @@ static struct domain_device *sas_ex_discover_expander(
> struct sas_expander_device *edev;
> struct asd_sas_port *port;
> int res;
> + unsigned long flags;
>
> if (phy->routing_attr == DIRECT_ROUTING) {
> SAS_DPRINTK("ex %016llx:0x%x:D <--> ex %016llx:0x%x is not "
> @@ -816,9 +818,9 @@ static struct domain_device *sas_ex_discover_expander(
> sas_fill_in_rphy(child, rphy);
> sas_rphy_add(rphy);
>
> - spin_lock(&parent->port->dev_list_lock);
> + spin_lock_irqsave(&parent->port->dev_list_lock, flags);
> list_add_tail(&child->dev_list_node, &parent->port->dev_list);
> - spin_unlock(&parent->port->dev_list_lock);
> + spin_unlock_irqrestore(&parent->port->dev_list_lock, flags);
>
> res = sas_discover_expander(child);
> if (res) {
ditto :-)
--
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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 01:05:03PM +0200, Jens Axboe wrote: > > FYI, here's the Calgary diff on top of the outstanding Calgary > > changes. > > When are these bits being merged into mainline? I'll hang on to this > version for helping me rebase the arch bits of chained sglists once > that happens. I sincerely hope they'll make 2.6.23 but Andi appears to have fallen into a black hole. Cheers, Muli - 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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > On Mon, Jul 16, 2007 at 11:47:23AM +0200, Jens Axboe wrote: > > > This prepares x86-64 for sg chaining support. > > > > Additional improvements/fixups for pci-gart from > > Benny Halevy <[EMAIL PROTECTED]> > > > > Cc: [EMAIL PROTECTED] > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > --- > > arch/x86_64/kernel/pci-calgary.c | 25 -- > > arch/x86_64/kernel/pci-gart.c| 63 > > - > > arch/x86_64/kernel/pci-nommu.c |5 ++- > > Calgary and nommu bits are: > > Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]> Great, thanks! > FYI, here's the Calgary diff on top of the outstanding Calgary > changes. When are these bits being merged into mainline? I'll hang on to this version for helping me rebase the arch bits of chained sglists once that happens. -- 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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16, 2007 at 11:47:23AM +0200, Jens Axboe wrote:
> This prepares x86-64 for sg chaining support.
>
> Additional improvements/fixups for pci-gart from
> Benny Halevy <[EMAIL PROTECTED]>
>
> Cc: [EMAIL PROTECTED]
> Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
> ---
> arch/x86_64/kernel/pci-calgary.c | 25 --
> arch/x86_64/kernel/pci-gart.c| 63 -
> arch/x86_64/kernel/pci-nommu.c |5 ++-
Calgary and nommu bits are:
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
FYI, here's the Calgary diff on top of the outstanding Calgary
changes.
diff -r 8642809f9e33 arch/x86_64/kernel/pci-calgary.c
--- a/arch/x86_64/kernel/pci-calgary.c Mon Jul 16 09:38:14 2007 +0300
+++ b/arch/x86_64/kernel/pci-calgary.c Tue Jul 17 13:33:24 2007 +0300
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -387,31 +388,32 @@ static void calgary_unmap_sg(struct devi
struct scatterlist *sglist, int nelems, int direction)
{
struct iommu_table *tbl = find_iommu_table(dev);
+ struct scatterlist *s;
+ int i;
if (!translate_phb(to_pci_dev(dev)))
return;
- while (nelems--) {
+ for_each_sg(sglist, s, nelems, i) {
unsigned int npages;
- dma_addr_t dma = sglist->dma_address;
- unsigned int dmalen = sglist->dma_length;
+ dma_addr_t dma = s->dma_address;
+ unsigned int dmalen = s->dma_length;
if (dmalen == 0)
break;
npages = num_dma_pages(dma, dmalen);
iommu_free(tbl, dma, npages);
- sglist++;
}
}
static int calgary_nontranslate_map_sg(struct device* dev,
struct scatterlist *sg, int nelems, int direction)
{
+ struct scatterlist *s;
int i;
- for (i = 0; i < nelems; i++ ) {
- struct scatterlist *s = &sg[i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s->page);
s->dma_address = virt_to_bus(page_address(s->page) +s->offset);
s->dma_length = s->length;
@@ -423,6 +425,7 @@ static int calgary_map_sg(struct device
int nelems, int direction)
{
struct iommu_table *tbl = find_iommu_table(dev);
+ struct scatterlist *s;
unsigned long vaddr;
unsigned int npages;
unsigned long entry;
@@ -431,8 +434,7 @@ static int calgary_map_sg(struct device
if (!translate_phb(to_pci_dev(dev)))
return calgary_nontranslate_map_sg(dev, sg, nelems, direction);
- for (i = 0; i < nelems; i++ ) {
- struct scatterlist *s = &sg[i];
+ for_each_sg(sg, s, nelems, i) {
BUG_ON(!s->page);
vaddr = (unsigned long)page_address(s->page) + s->offset;
@@ -457,9 +459,9 @@ static int calgary_map_sg(struct device
return nelems;
error:
calgary_unmap_sg(dev, sg, nelems, direction);
- for (i = 0; i < nelems; i++) {
- sg[i].dma_address = bad_dma_address;
- sg[i].dma_length = 0;
+ for_each_sg(sg, s, nelems, i) {
+ s->dma_address = bad_dma_address;
+ s->dma_length = 0;
}
return 0;
}
-
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 4/4] bsg: Kconfig updates
On Tue, Jul 17 2007, FUJITA Tomonori wrote: > - add the detailed explanation. > - remove 'default y'. > - make 'EXPERIMENTAL' keyword visible to the user in menu. Applied all 4, thanks! -- 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: block/bsg.c
On Tue, Jul 17 2007, FUJITA Tomonori wrote: > From: Jens Axboe <[EMAIL PROTECTED]> > Subject: Re: block/bsg.c > Date: Tue, 17 Jul 2007 09:10:45 +0200 > > > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > > From: Jens Axboe <[EMAIL PROTECTED]> > > > Subject: Re: block/bsg.c > > > Date: Tue, 17 Jul 2007 08:59:40 +0200 > > > > > > > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > > > > From: Jens Axboe <[EMAIL PROTECTED]> > > > > > Subject: Re: block/bsg.c > > > > > Date: Tue, 17 Jul 2007 08:38:11 +0200 > > > > > > > > > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > > > > > > > > > > > > A belated review (I've never seen this before and there it is in > > > > > > > mainline) > > > > > > > > > > > > > > > static char bsg_version[] = "block layer sg (bsg) 0.4"; > > > > > > > > > > > > > > `const' would be better. That moves it into a write-protected > > > > > > > memory section. > > > > > > > > > > > > Agree > > > > > > > > > > > > > > #define list_entry_bc(entry)list_entry((entry), struct > > > > > > > > bsg_command, list) > > > > > > > > > > > > > > This makes the code easier to write but harder to read. We > > > > > > > should optimise > > > > > > > for readers. Please open-code this at callsites. > > > > > > > > > > > > > > Or at least convert it into a (commented) (possibly inlined) C > > > > > > > function. > > > > > > > > > > > > list_entry_to_bc(), then? The main objective is to save on typing, > > > > > > and > > > > > > (just as important) make sure we don't bump over the 80 chars per > > > > > > line. > > > > > > > > > > > > > > /* > > > > > > > > * just for testing > > > > > > > > */ > > > > > > > > #define BSG_MAJOR (240) > > > > > > > > > > > > > > What's this doing in mainline? 240 is a "reserved for local use" > > > > > > > major. > > > > > > > This will cause collisions. This code should be using dynamic > > > > > > > major > > > > > > > assignment. > > > > > > > > > > > > Yeah, that's a big error on my part. Will get that fixed up right > > > > > > away. > > > > > > > > > > I've been testing the patchset to fix the issues that Andrew pointed > > > > > out. I can send it soon. > > > > > > > > > > Jens, have you already fixed some? > > > > > > > > I already pushed some of the changes locally, just the idr change is > > > > missing. See the #bsg branch: > > > > > > > > http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=bsg > > > > > > I see. > > > > Since Linus is happily snoring by now, could you test and see if the > > tree works for you? > > It works for me. I'll submit some minor patches against your bsg > branch to scsi-ml. Can you push them together? Certainly, I'll pull them into the bsg branch. -- 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
[PATCH 1/4] bsg: fix initialization error handling bugs
This fixes the following bugs and cleans up the initialization code:
- cdev_del is missing.
- unregister_chrdev_region should be used instead of unregister_chrdev.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
block/bsg.c | 38 ++
1 files changed, 18 insertions(+), 20 deletions(-)
diff --git a/block/bsg.c b/block/bsg.c
index cdb00e5..b253784 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -1057,39 +1057,37 @@ static int __init bsg_init(void)
bsg_class = class_create(THIS_MODULE, "bsg");
if (IS_ERR(bsg_class)) {
- kmem_cache_destroy(bsg_cmd_cachep);
- return PTR_ERR(bsg_class);
+ ret = PTR_ERR(bsg_class);
+ goto destroy_kmemcache;
}
ret = alloc_chrdev_region(&devid, 0, BSG_MAX_DEVS, "bsg");
- if (ret) {
- kmem_cache_destroy(bsg_cmd_cachep);
- class_destroy(bsg_class);
- return ret;
- }
+ if (ret)
+ goto destroy_bsg_class;
bsg_major = MAJOR(devid);
cdev_init(&bsg_cdev, &bsg_fops);
ret = cdev_add(&bsg_cdev, MKDEV(bsg_major, 0), BSG_MAX_DEVS);
- if (ret) {
- kmem_cache_destroy(bsg_cmd_cachep);
- class_destroy(bsg_class);
- unregister_chrdev_region(MKDEV(bsg_major, 0), BSG_MAX_DEVS);
- return ret;
- }
+ if (ret)
+ goto unregister_chrdev;
ret = scsi_register_interface(&bsg_intf);
- if (ret) {
- printk(KERN_ERR "bsg: failed register scsi interface %d\n",
ret);
- kmem_cache_destroy(bsg_cmd_cachep);
- class_destroy(bsg_class);
- unregister_chrdev(bsg_major, "bsg");
- return ret;
- }
+ if (ret)
+ goto remove_cdev;
printk(KERN_INFO "%s loaded (major %d)\n", bsg_version, bsg_major);
return 0;
+remove_cdev:
+ printk(KERN_ERR "bsg: failed register scsi interface %d\n", ret);
+ cdev_del(&bsg_cdev);
+unregister_chrdev:
+ unregister_chrdev_region(MKDEV(bsg_major, 0), BSG_MAX_DEVS);
+destroy_bsg_class:
+ class_destroy(bsg_class);
+destroy_kmemcache:
+ kmem_cache_destroy(bsg_cmd_cachep);
+ return ret;
}
MODULE_AUTHOR("Jens Axboe");
--
1.4.3.2
-
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/4] bsg: minor cleanup
- fix MODULE_DESCRIPTION typo.
- unify MODULE_DESCRIPTION and bsg_version.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
block/bsg.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/block/bsg.c b/block/bsg.c
index 55a4303..8e5fcf2 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -33,7 +33,8 @@ #include
#include
#include
-const static char bsg_version[] = "block layer sg (bsg) 0.4";
+#define BSG_DESCRIPTION"Block layer SCSI generic (bsg) driver"
+#define BSG_VERSION"0.4"
struct bsg_device {
request_queue_t *queue;
@@ -1072,7 +1073,8 @@ static int __init bsg_init(void)
if (ret)
goto remove_cdev;
- printk(KERN_INFO "%s loaded (major %d)\n", bsg_version, bsg_major);
+ printk(KERN_INFO BSG_DESCRIPTION "version " BSG_VERSION
+ " loaded (major %d)\n", bsg_major);
return 0;
remove_cdev:
printk(KERN_ERR "bsg: failed register scsi interface %d\n", ret);
@@ -1087,7 +1089,7 @@ destroy_kmemcache:
}
MODULE_AUTHOR("Jens Axboe");
-MODULE_DESCRIPTION("Block layer SGSI generic (sg) driver");
+MODULE_DESCRIPTION(BSG_DESCRIPTION);
MODULE_LICENSE("GPL");
device_initcall(bsg_init);
--
1.4.3.2
-
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 2/4] bsg: device hash table cleanup
- kill unused bsg_list_idx macro.
- add bsg_dev_idx_hash() that returns an appropriate hlist_head.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
block/bsg.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/block/bsg.c b/block/bsg.c
index b253784..55a4303 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -72,7 +72,6 @@ static DEFINE_MUTEX(bsg_mutex);
static int bsg_device_nr, bsg_minor_idx;
#define BSG_LIST_ARRAY_SIZE8
-#define bsg_list_idx(minor)((minor) & (BSG_LIST_ARRAY_SIZE - 1))
static struct hlist_head bsg_device_list[BSG_LIST_ARRAY_SIZE];
static struct class *bsg_class;
@@ -139,9 +138,9 @@ out:
return bc;
}
-static inline void
-bsg_add_done_cmd(struct bsg_device *bd, struct bsg_command *bc)
+static inline struct hlist_head *bsg_dev_idx_hash(int index)
{
+ return &bsg_device_list[index & (BSG_LIST_ARRAY_SIZE - 1)];
}
static int bsg_io_schedule(struct bsg_device *bd)
@@ -748,8 +747,7 @@ #endif
atomic_set(&bd->ref_count, 1);
bd->minor = iminor(inode);
mutex_lock(&bsg_mutex);
- hlist_add_head(&bd->dev_list,
- &bsg_device_list[bd->minor & (BSG_LIST_ARRAY_SIZE - 1)]);
+ hlist_add_head(&bd->dev_list, bsg_dev_idx_hash(bd->minor));
strncpy(bd->name, rq->bsg_dev.class_dev->class_id, sizeof(bd->name) -
1);
dprintk("bound to <%s>, max queue %d\n",
@@ -761,14 +759,12 @@ #endif
static struct bsg_device *__bsg_get_device(int minor)
{
- struct hlist_head *list;
struct bsg_device *bd = NULL;
struct hlist_node *entry;
mutex_lock(&bsg_mutex);
- list = &bsg_device_list[minor & (BSG_LIST_ARRAY_SIZE - 1)];
- hlist_for_each(entry, list) {
+ hlist_for_each(entry, bsg_dev_idx_hash(minor)) {
bd = hlist_entry(entry, struct bsg_device, dev_list);
if (bd->minor == minor) {
atomic_inc(&bd->ref_count);
--
1.4.3.2
-
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 4/4] bsg: Kconfig updates
- add the detailed explanation. - remove 'default y'. - make 'EXPERIMENTAL' keyword visible to the user in menu. Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> --- block/Kconfig | 13 + 1 files changed, 9 insertions(+), 4 deletions(-) diff --git a/block/Kconfig b/block/Kconfig index 6597b60..0768741 100644 --- a/block/Kconfig +++ b/block/Kconfig @@ -52,11 +52,16 @@ config LSF endif # BLOCK config BLK_DEV_BSG - bool "Block layer SG support" + bool "Block layer SG support v4 (EXPERIMENTAL)" depends on (SCSI=y) && EXPERIMENTAL - default y ---help--- - Saying Y here will enable generic SG (SCSI generic) v4 - support for any block device. + Saying Y here will enable generic SG (SCSI generic) v4 support + for any block device. + + Unlike SG v3 (aka block/scsi_ioctl.c drivers/scsi/sg.c), SG v4 + can handle complicated SCSI commands: tagged variable length cdbs + with bidirectional data transfers and generic request/response + protocols (e.g. Task Management Functions and SMP in Serial + Attached SCSI). source block/Kconfig.iosched -- 1.4.3.2 - 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: block/bsg.c
From: Jens Axboe <[EMAIL PROTECTED]> Subject: Re: block/bsg.c Date: Tue, 17 Jul 2007 09:10:45 +0200 > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > From: Jens Axboe <[EMAIL PROTECTED]> > > Subject: Re: block/bsg.c > > Date: Tue, 17 Jul 2007 08:59:40 +0200 > > > > > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > > > From: Jens Axboe <[EMAIL PROTECTED]> > > > > Subject: Re: block/bsg.c > > > > Date: Tue, 17 Jul 2007 08:38:11 +0200 > > > > > > > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > > > > > > > > > > A belated review (I've never seen this before and there it is in > > > > > > mainline) > > > > > > > > > > > > > static char bsg_version[] = "block layer sg (bsg) 0.4"; > > > > > > > > > > > > `const' would be better. That moves it into a write-protected > > > > > > memory section. > > > > > > > > > > Agree > > > > > > > > > > > > #define list_entry_bc(entry) list_entry((entry), struct > > > > > > > bsg_command, list) > > > > > > > > > > > > This makes the code easier to write but harder to read. We should > > > > > > optimise > > > > > > for readers. Please open-code this at callsites. > > > > > > > > > > > > Or at least convert it into a (commented) (possibly inlined) C > > > > > > function. > > > > > > > > > > list_entry_to_bc(), then? The main objective is to save on typing, and > > > > > (just as important) make sure we don't bump over the 80 chars per > > > > > line. > > > > > > > > > > > > /* > > > > > > > * just for testing > > > > > > > */ > > > > > > > #define BSG_MAJOR (240) > > > > > > > > > > > > What's this doing in mainline? 240 is a "reserved for local use" > > > > > > major. > > > > > > This will cause collisions. This code should be using dynamic major > > > > > > assignment. > > > > > > > > > > Yeah, that's a big error on my part. Will get that fixed up right > > > > > away. > > > > > > > > I've been testing the patchset to fix the issues that Andrew pointed > > > > out. I can send it soon. > > > > > > > > Jens, have you already fixed some? > > > > > > I already pushed some of the changes locally, just the idr change is > > > missing. See the #bsg branch: > > > > > > http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=bsg > > > > I see. > > Since Linus is happily snoring by now, could you test and see if the > tree works for you? It works for me. I'll submit some minor patches against your bsg branch to scsi-ml. Can you push them together? Thanks, - 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] gdth: remove redundant PCI stuff
This patch
* removes struct members that duplicate pci_dev members
* replaces ha->stype usage with ha->pdev->device usage where feasible
* removes PCI IDs that are already in include/linux/pci_ids.h
I did this because I was bored. If this interferes with Christoph's
stuff in any way, feel free to ignore. I thought it would be a good
preparation for PCI hotplug API. (or at the very least, proper pci_dev
refcounting)
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/scsi/gdth.c | 48 ++--
drivers/scsi/gdth.h | 45 +
2 files changed, 23 insertions(+), 70 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index d0b95ce..b0f5687 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -902,11 +902,6 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
return;
/* GDT PCI controller found, resources are already in pdev */
pcistr[*cnt].pdev = pdev;
-pcistr[*cnt].vendor_id = vendor;
-pcistr[*cnt].device_id = device;
-pcistr[*cnt].subdevice_id = pdev->subsystem_device;
-pcistr[*cnt].bus = pdev->bus->number;
-pcistr[*cnt].device_fn = pdev->devfn;
pcistr[*cnt].irq = pdev->irq;
base0 = pci_resource_flags(pdev, 0);
base1 = pci_resource_flags(pdev, 1);
@@ -926,7 +921,8 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
pcistr[*cnt].io= pci_resource_start(pdev, 1);
}
TRACE2(("Controller found at %d/%d, irq %d, dpmem 0x%lx\n",
-pcistr[*cnt].bus, PCI_SLOT(pcistr[*cnt].device_fn),
+pcistr[*cnt].pdev->bus->number,
+ PCI_SLOT(pcistr[*cnt].pdev->devfn),
pcistr[*cnt].irq, pcistr[*cnt].dpmem));
(*cnt)++;
}
@@ -946,20 +942,20 @@ static void __init gdth_sort_pci(gdth_pci_str *pcistr,
int cnt)
changed = FALSE;
for (i = 0; i < cnt-1; ++i) {
if (!reverse_scan) {
-if ((pcistr[i].bus > pcistr[i+1].bus) ||
-(pcistr[i].bus == pcistr[i+1].bus &&
- PCI_SLOT(pcistr[i].device_fn) >
- PCI_SLOT(pcistr[i+1].device_fn))) {
+if ((pcistr[i].pdev->bus->number >
pcistr[i+1].pdev->bus->number) ||
+(pcistr[i].pdev->bus->number ==
pcistr[i+1].pdev->bus->number &&
+ PCI_SLOT(pcistr[i].pdev->devfn) >
+ PCI_SLOT(pcistr[i+1].pdev->devfn))) {
temp = pcistr[i];
pcistr[i] = pcistr[i+1];
pcistr[i+1] = temp;
changed = TRUE;
}
} else {
-if ((pcistr[i].bus < pcistr[i+1].bus) ||
-(pcistr[i].bus == pcistr[i+1].bus &&
- PCI_SLOT(pcistr[i].device_fn) <
- PCI_SLOT(pcistr[i+1].device_fn))) {
+if ((pcistr[i].pdev->bus->number <
pcistr[i+1].pdev->bus->number) ||
+(pcistr[i].pdev->bus->number ==
pcistr[i+1].pdev->bus->number &&
+ PCI_SLOT(pcistr[i].pdev->devfn) <
+ PCI_SLOT(pcistr[i+1].pdev->devfn))) {
temp = pcistr[i];
pcistr[i] = pcistr[i+1];
pcistr[i+1] = temp;
@@ -1176,17 +1172,16 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
TRACE(("gdth_init_pci()\n"));
-if (pcistr->vendor_id == PCI_VENDOR_ID_INTEL)
+if (pcistr->pdev->vendor == PCI_VENDOR_ID_INTEL)
ha->oem_id = OEM_ID_INTEL;
else
ha->oem_id = OEM_ID_ICP;
-ha->brd_phys = (pcistr->bus << 8) | (pcistr->device_fn & 0xf8);
-ha->stype = (ulong32)pcistr->device_id;
-ha->subdevice_id = pcistr->subdevice_id;
+ha->brd_phys = (pcistr->pdev->bus->number << 8) | (pcistr->pdev->devfn &
0xf8);
+ha->stype = (ulong32)pcistr->pdev->device;
ha->irq = pcistr->irq;
ha->pdev = pcistr->pdev;
-if (ha->stype <= PCI_DEVICE_ID_VORTEX_GDT6000B) { /* GDT6000/B */
+if (ha->pdev->device <= PCI_DEVICE_ID_VORTEX_GDT6000B) { /* GDT6000/B */
TRACE2(("init_pci() dpmem %lx irq %d\n",pcistr->dpmem,ha->irq));
ha->brd = ioremap(pcistr->dpmem, sizeof(gdt6_dpram_str));
if (ha->brd == NULL) {
@@ -1293,7 +1288,7 @@ static int __init gdth_init_pci(gdth_pci_str
*pcistr,gdth_ha_str *ha)
ha->dma64_support = 0;
-} else if (ha->stype <= PCI_DEVICE_ID_VORTEX_GDT6555) { /* GDT6110, ... */
+} else if (ha->pdev->device <= PCI_DEVICE_ID_VORTEX_GDT6555) { /* GDT6110,
... */
ha->plx = (gdt6c_plx_regs *)pcistr->io;
TRACE2(("init_pci_new() dpmem %lx irq %d\n",
pcistr->dpmem,ha->irq));
@@ -4601,7 +4596,8 @@ static int __init gdth_detect(Scsi_Host_Template *shtp)
}
/* cont
Re: [PATCH] mpt fusion: add sysfs attributes to display IOC parameters
Reposting as this patch is not visible in the list yet.
Resubmitting with the following change suggested by Brian King:
The driver version from scsi_host attribute is redundant as it is already
available in sysfs: /sys/module/mptscsih/version.
So it is removed from the patch
---
New sysfs scsi_host attributes are added to provide information about Firmware
version, BIOS version, MPI version and other product related information.
signed-off-by: Sathya Praksh <[EMAIL PROTECTED]>
---
diff -Naurp b/drivers/message/fusion/mptbase.c
a/drivers/message/fusion/mptbase.c
--- b/drivers/message/fusion/mptbase.c 2007-07-02 16:20:46.0 +0530
+++ a/drivers/message/fusion/mptbase.c 2007-07-13 09:12:46.0 +0530
@@ -161,6 +161,7 @@ static int mpt_readScsiDevicePageHeaders
static voidmpt_read_ioc_pg_1(MPT_ADAPTER *ioc);
static voidmpt_read_ioc_pg_4(MPT_ADAPTER *ioc);
static voidmpt_timer_expired(unsigned long data);
+static voidmpt_get_manufacturing_pg_0(MPT_ADAPTER *ioc);
static int SendEventNotification(MPT_ADAPTER *ioc, u8 EvSwitch);
static int SendEventAck(MPT_ADAPTER *ioc, EventNotificationReply_t *evnp);
static int mpt_host_page_access_control(MPT_ADAPTER *ioc, u8
access_control_value, int sleepFlag);
@@ -1880,6 +1881,7 @@ mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u3
}
GetIoUnitPage2(ioc);
+ mpt_get_manufacturing_pg_0(ioc);
}
/*
@@ -5190,6 +5192,49 @@ mpt_read_ioc_pg_1(MPT_ADAPTER *ioc)
return;
}
+static void
+mpt_get_manufacturing_pg_0(MPT_ADAPTER *ioc)
+{
+ CONFIGPARMS cfg;
+ ConfigPageHeader_t hdr;
+ dma_addr_t buf_dma;
+ ManufacturingPage0_t*pbuf = NULL;
+
+ memset(&cfg, 0 , sizeof(CONFIGPARMS));
+ memset(&hdr, 0 , sizeof(ConfigPageHeader_t));
+
+ hdr.PageType = MPI_CONFIG_PAGETYPE_MANUFACTURING;
+ cfg.cfghdr.hdr = &hdr;
+ cfg.physAddr = -1;
+ cfg.action = MPI_CONFIG_ACTION_PAGE_HEADER;
+ cfg.timeout = 10;
+
+ if (mpt_config(ioc, &cfg) != 0)
+ goto out;
+
+ if (!cfg.cfghdr.hdr->PageLength)
+ goto out;
+
+ cfg.action = MPI_CONFIG_ACTION_PAGE_READ_CURRENT;
+ pbuf = pci_alloc_consistent(ioc->pcidev, hdr.PageLength * 4, &buf_dma);
+ if (!pbuf)
+ goto out;
+
+ cfg.physAddr = buf_dma;
+
+ if (mpt_config(ioc, &cfg) != 0)
+ goto out;
+
+ memcpy(ioc->board_name, pbuf->BoardName, sizeof(ioc->board_name));
+ memcpy(ioc->board_assembly, pbuf->BoardAssembly,
sizeof(ioc->board_assembly));
+ memcpy(ioc->board_tracer, pbuf->BoardTracerNumber,
sizeof(ioc->board_tracer));
+
+ out:
+
+ if (pbuf)
+ pci_free_consistent(ioc->pcidev, hdr.PageLength * 4, pbuf,
buf_dma);
+}
+
/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
/**
* SendEventNotification - Send EventNotification (on or off) request to
adapter
diff -Naurp b/drivers/message/fusion/mptbase.h
a/drivers/message/fusion/mptbase.h
--- b/drivers/message/fusion/mptbase.h 2007-07-02 16:20:46.0 +0530
+++ a/drivers/message/fusion/mptbase.h 2007-07-13 09:12:46.0 +0530
@@ -538,6 +538,13 @@ typedef struct _MPT_ADAPTER
int pci_irq; /* This irq */
char name[MPT_NAME_LENGTH]; /* "iocN" */
char*prod_name; /* "LSIFC9x9" */
+ char board_name[16];
+ char board_assembly[16];
+ char board_tracer[16];
+ u16 nvdata_version_persistent;
+ u16 nvdata_version_default;
+ u8 io_missing_delay;
+ u8 device_missing_delay;
SYSIF_REGS __iomem *chip; /* == c8817000 (mmap) */
SYSIF_REGS __iomem *pio_chip; /* Programmed IO (downloadboot)
*/
u8 bus_type;
diff -Naurp b/drivers/message/fusion/mptfc.c a/drivers/message/fusion/mptfc.c
--- b/drivers/message/fusion/mptfc.c2007-07-02 16:20:46.0 +0530
+++ a/drivers/message/fusion/mptfc.c2007-07-13 09:12:46.0 +0530
@@ -130,6 +130,7 @@ static struct scsi_host_template mptfc_d
.max_sectors= 8192,
.cmd_per_lun= 7,
.use_clustering = ENABLE_CLUSTERING,
+ .shost_attrs= mptscsih_host_attrs,
};
/
diff -Naurp b/drivers/message/fusion/mptsas.c a/drivers/message/fusion/mptsas.c
--- b/drivers/message/fusion/mptsas.c 2007-07-02 16:20:46.0 +0530
+++ a/drivers/message/fusion/mptsas.c 2007-07-13 09:12:46.0 +0530
@@ -1119,6 +1119,7 @@ static struct scsi_host_tem
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 10:51:23AM +0200, Jens Axboe wrote: > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: > > > > > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > > > > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) > > > > will not be held up on account of the Xen merge (or for any other > > > > reason... CalIOC2 machines which are out there won't boot without > > > > it if CONFIG_CALGARY_IOMMU is enabled). > > > > > > Do you have any comments for the patch to calgary (the mail you are > > > replying to)? > > > > It looks ok, I just didn't want to ACK it before testing (I'm paranoid > > that way). > > That's certainly understandable! Can you mail me an ack once you've had > a chance to test it? Yep, taking it for a spin now. Cheers, Muli - 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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: > > > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) > > > will not be held up on account of the Xen merge (or for any other > > > reason... CalIOC2 machines which are out there won't boot without > > > it if CONFIG_CALGARY_IOMMU is enabled). > > > > Do you have any comments for the patch to calgary (the mail you are > > replying to)? > > It looks ok, I just didn't want to ACK it before testing (I'm paranoid > that way). That's certainly understandable! Can you mail me an ack once you've had a chance to test it? -- 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] mpt fusion: add support for Brocade branded LSI FC HBA
Resubmitting with Eric Moore suggested modifications:
---
Add support for Brocade 410/420 4Gbit FC HBAs.
They are re-branded LSI HBAs [LSI7104EP-LC/LSI7204EP-LC]
This patch should be applied over the following patches:
1. mpt fusion: deregister from transport layer if PCI registration failed
2. mpt fusion: add sysfs attributes to display IOC parameters
3. add PCI_VENDOR_ID macro for Brocade in pci_ids.h
signed-off-by: Sathya Prakash <[EMAIL PROTECTED]>
---
diff -Naurp b/drivers/message/fusion/mptbase.c
a/drivers/message/fusion/mptbase.c
--- b/drivers/message/fusion/mptbase.c 2007-07-13 12:11:12.0 +0530
+++ a/drivers/message/fusion/mptbase.c 2007-07-17 14:11:52.0 +0530
@@ -1132,6 +1132,248 @@ mpt_verify_adapter(int iocid, MPT_ADAPTE
return -1;
}
+/**
+ * mpt_get_product_name - returns product string
+ * @vendor: pci vendor id
+ * @device: pci device id
+ * @revision: pci revision id
+ * @prod_name: string returned
+ *
+ * Returns product string displayed when driver loads,
+ * in /proc/mpt/summary and /sysfs/class/scsi_host/host/version_product
+ *
+ **/
+static void
+mpt_get_product_name(u16 vendor, u16 device, u8 revision, char *prod_name)
+{
+ char *product_str = NULL;
+
+ if (vendor == PCI_VENDOR_ID_BROCADE) {
+ switch (device)
+ {
+ case MPI_MANUFACTPAGE_DEVICEID_FC949E:
+ switch (revision)
+ {
+ case 0x00:
+ product_str = "BRE040 A0";
+ break;
+ case 0x01:
+ product_str = "BRE040 A1";
+ break;
+ default:
+ product_str = "BRE040";
+ break;
+ }
+ break;
+ }
+ goto out;
+ }
+
+ switch (device)
+ {
+ case MPI_MANUFACTPAGE_DEVICEID_FC909:
+ product_str = "LSIFC909 B1";
+ break;
+ case MPI_MANUFACTPAGE_DEVICEID_FC919:
+ product_str = "LSIFC919 B0";
+ break;
+ case MPI_MANUFACTPAGE_DEVICEID_FC929:
+ product_str = "LSIFC929 B0";
+ break;
+ case MPI_MANUFACTPAGE_DEVICEID_FC919X:
+ if (revision < 0x80)
+ product_str = "LSIFC919X A0";
+ else
+ product_str = "LSIFC919XL A1";
+ break;
+ case MPI_MANUFACTPAGE_DEVICEID_FC929X:
+ if (revision < 0x80)
+ product_str = "LSIFC929X A0";
+ else
+ product_str = "LSIFC929XL A1";
+ break;
+ case MPI_MANUFACTPAGE_DEVICEID_FC939X:
+ product_str = "LSIFC939X A1";
+ break;
+ case MPI_MANUFACTPAGE_DEVICEID_FC949X:
+ product_str = "LSIFC949X A1";
+ break;
+ case MPI_MANUFACTPAGE_DEVICEID_FC949E:
+ switch (revision)
+ {
+ case 0x00:
+ product_str = "LSIFC949E A0";
+ break;
+ case 0x01:
+ product_str = "LSIFC949E A1";
+ break;
+ default:
+ product_str = "LSIFC949E";
+ break;
+ }
+ break;
+ case MPI_MANUFACTPAGE_DEVID_53C1030:
+ switch (revision)
+ {
+ case 0x00:
+ product_str = "LSI53C1030 A0";
+ break;
+ case 0x01:
+ product_str = "LSI53C1030 B0";
+ break;
+ case 0x03:
+ product_str = "LSI53C1030 B1";
+ break;
+ case 0x07:
+ product_str = "LSI53C1030 B2";
+ break;
+ case 0x08:
+ product_str = "LSI53C1030 C0";
+ break;
+ case 0x80:
+ product_str = "LSI53C1030T A0";
+ break;
+ case 0x83:
+ product_str = "LSI53C1030T A2";
+ break;
+ case 0x87:
+ product_str = "LSI53C1030T A3";
+ break;
+ case 0xc1:
+ product_str = "LSI53C1020A A1";
+ break;
+ default:
+ product_str = "LSI53C1030";
+ break;
+ }
+ break;
+ case MPI_MANUFACTPAGE_DEVID_1030_53C1035:
+ switch (revision)
+ {
+ case 0x03:
+ product_str = "LSI53C1035 A2";
+
Re: [PATCH 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17, 2007 at 09:38:59AM +0200, Jens Axboe wrote: > On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) > > will not be held up on account of the Xen merge (or for any other > > reason... CalIOC2 machines which are out there won't boot without > > it if CONFIG_CALGARY_IOMMU is enabled). > > Do you have any comments for the patch to calgary (the mail you are > replying to)? It looks ok, I just didn't want to ACK it before testing (I'm paranoid that way). Cheers, Muli - 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] add PCI_VENDOR_ID macro for Brocade in pci_ids.h
Reposting as it is not reached the list. On Fri, Jul 13, 2007 at 02:43:30PM +0530, Prakash, Sathya wrote: Adds PCI_VENDOR_ID_BROCADE macro in include/linux/pci_ids.h file. This macro is used in MPT Fusion FC drivers to support Brocade branded FC controllers signed-off-by: Sathya Prakash <[EMAIL PROTECTED]> --- diff -Naurp b/include/linux/pci_ids.h a/include/linux/pci_ids.h --- b/include/linux/pci_ids.h 2007-07-02 16:20:47.0 +0530 +++ a/include/linux/pci_ids.h 2007-07-13 11:34:32.0 +0530 @@ -2043,6 +2043,8 @@ #define PCI_VENDOR_ID_ARIMA0x161f +#define PCI_VENDOR_ID_BROCADE 0x1657 + #define PCI_VENDOR_ID_SIBYTE 0x166d #define PCI_DEVICE_ID_BCM1250_PCI 0x0001 #define PCI_DEVICE_ID_BCM1250_HT 0x0002 - 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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Jens Axboe wrote: > On Mon, Jul 16 2007, Andrew Morton wrote: > > On Mon, 16 Jul 2007 22:10:03 +0200 > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > > On Mon, 16 Jul 2007 11:47:23 +0200 > > > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > > > > > This prepares x86-64 for sg chaining support. > > > > > > > > > > Additional improvements/fixups for pci-gart from > > > > > Benny Halevy <[EMAIL PROTECTED]> > > > > > > > > > > Cc: [EMAIL PROTECTED] > > > > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > > > > --- > > > > > arch/x86_64/kernel/pci-calgary.c | 25 -- > > > > > arch/x86_64/kernel/pci-gart.c| 63 > > > > > - > > > > > arch/x86_64/kernel/pci-nommu.c |5 ++- > > > > > 3 files changed, 51 insertions(+), 42 deletions(-) > > > > > > > > This causes fairly extensive destruction of 2.6.23 changes which are > > > > pending in Andi's tree. > > > > > > > > I shall drop the block tree until a) Andi has merged the pending Calgary > > > > changes and b) the block tree has been fixed up to account for those > > > > (and > > > > other) changes. > > > > > > > > Really, this was the perfectly worst time possible to go tromping all > > > > over > > > > everyone else's trees. > > > > > > Well, that's a bit hard for me to know, all I can do is push my stuff to > > > for-akpm so that it gets -mm exposure. If I don't, then you are yelling > > > at me as well :-) > > > > It is to be expected that there will be conflicts when making large-scale > > changes like this while there is 25MB of unmerged diff sitting out in 50 > > different trees. Doing it around the -rc1 time would be better. > > > > Even better would be not doing it at all: add the necessary stuff into the > > block core and then send the followup work to the relevant maintainers. ie: > > standard practice. > > I'll do that. Most of the stuff is trivial, but the x86-64 iommu changes > are probably the most tricky and invasive of them all. OK, this is what I did: Split the set into 3, in the following order: CORE -> DRIVERS -> ARCH So that's 3 branches, core is based off master, drivers off core, and arch off drivers. I'll push core+drivers into #for-akpm for testing, then the arch bits will stay undisturbed until acked by maintainers. -- 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: block/bsg.c
On Jul 16 2007 16:57, Andrew Morton wrote: >A belated review (I've never seen this before and there it is in mainline) > >> static char bsg_version[] = "block layer sg (bsg) 0.4"; > >`const' would be better. That moves it into a write-protected memory section. Or perhaps MODULE_DESCRIPTION() and MODULE_VERSION()? Jan -- - 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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Tue, Jul 17 2007, Muli Ben-Yehuda wrote: > On Mon, Jul 16, 2007 at 01:34:27PM -0700, Andrew Morton wrote: > > > > I'll keep rebasing sglist and the other branches I pull into for-akpm, > > > so you can just re-enable the for-akpm pull when the a) is true. > > > > Andi's tree is very out of date and is about to be damaged (to what > > extent I don't yet know) by a xen merge. I don't know if a) is > > going to happen. > > The Xen and Calgary bits are mutually exclusive, so hopefully (a) will > not be held up on account of the Xen merge (or for any other > reason... CalIOC2 machines which are out there won't boot without it > if CONFIG_CALGARY_IOMMU is enabled). Do you have any comments for the patch to calgary (the mail you are replying to)? -- 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: block/bsg.c
From: Jens Axboe <[EMAIL PROTECTED]> Subject: Re: block/bsg.c Date: Tue, 17 Jul 2007 08:38:11 +0200 > > As a reader of this code I'm wondering "hm, why is > > BSG_SUB_PROTOCOL_SCSI_CMD unprivileged, while other modes require > > CAP_SYS_RAWIO"?. > > > > This design/policy decision maybe was discussed on a mailing list > > somewhere, or even perhaps in a changelog (although I can't find it). But > > it is so important, and is so unobvious from a reading of the code that I'd > > suggest that it is worth some discussion right here, in a code comment. > > > It's not unprivileged, it goes through the blk_verify_command() check > list. SCSI commands goes to blk_verify_command() like SG v3 (block/scsi_ioctl.c and drivers/scsi/sg.c). Except for SCSI commands, only SAS Management Protocol (SMP) is supported now. Sending management requests needs CAP_SYS_RAWIO, that's a reasonable policy, I guess. > > And `struct sg_io_v4' has just become part of the kernel ABI? Beware that > > there is a move afoot to require test code, manpages and even LTP testcases > > for new ABI extensions. Is this interface documented anywhere? > > The documentation is likely very scarce atm, if anything. The command > layout was discussed at the storage summit and on linux-scsi. Not the latest, but Doug's RFC: http://lwn.net/Articles/208082/ gives pretty good information. > > Would I be correct in assuming that it offers services to device drivers, > > which have yet to be hooked up? > > Yes. As mentioned many lines up, it is a SCSI generic type driver that > uses the (now) defined version 4 command structure. So it'll get hooked > up to ny capable device. The SAS transport class use bsg to handle SAS Management Protocol. Every SAS object (host, device, expander, etc) has the own bsg device. They call bsg_register_queue() for the own request queue. Users can send SMP requests to any object via its bsg device. http://marc.info/?l=linux-scsi&m=118395317724148&w=2 I guess that James plan to put SMP patches in the second SCSI merge for 2.6.22. - 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: block/bsg.c
On Tue, Jul 17 2007, FUJITA Tomonori wrote: > From: Jens Axboe <[EMAIL PROTECTED]> > Subject: Re: block/bsg.c > Date: Tue, 17 Jul 2007 09:10:45 +0200 > > > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > > From: Jens Axboe <[EMAIL PROTECTED]> > > > Subject: Re: block/bsg.c > > > Date: Tue, 17 Jul 2007 08:59:40 +0200 > > > > > > > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > > > > From: Jens Axboe <[EMAIL PROTECTED]> > > > > > Subject: Re: block/bsg.c > > > > > Date: Tue, 17 Jul 2007 08:38:11 +0200 > > > > > > > > > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > > > > > > > > > > > > A belated review (I've never seen this before and there it is in > > > > > > > mainline) > > > > > > > > > > > > > > > static char bsg_version[] = "block layer sg (bsg) 0.4"; > > > > > > > > > > > > > > `const' would be better. That moves it into a write-protected > > > > > > > memory section. > > > > > > > > > > > > Agree > > > > > > > > > > > > > > #define list_entry_bc(entry)list_entry((entry), struct > > > > > > > > bsg_command, list) > > > > > > > > > > > > > > This makes the code easier to write but harder to read. We > > > > > > > should optimise > > > > > > > for readers. Please open-code this at callsites. > > > > > > > > > > > > > > Or at least convert it into a (commented) (possibly inlined) C > > > > > > > function. > > > > > > > > > > > > list_entry_to_bc(), then? The main objective is to save on typing, > > > > > > and > > > > > > (just as important) make sure we don't bump over the 80 chars per > > > > > > line. > > > > > > > > > > > > > > /* > > > > > > > > * just for testing > > > > > > > > */ > > > > > > > > #define BSG_MAJOR (240) > > > > > > > > > > > > > > What's this doing in mainline? 240 is a "reserved for local use" > > > > > > > major. > > > > > > > This will cause collisions. This code should be using dynamic > > > > > > > major > > > > > > > assignment. > > > > > > > > > > > > Yeah, that's a big error on my part. Will get that fixed up right > > > > > > away. > > > > > > > > > > I've been testing the patchset to fix the issues that Andrew pointed > > > > > out. I can send it soon. > > > > > > > > > > Jens, have you already fixed some? > > > > > > > > I already pushed some of the changes locally, just the idr change is > > > > missing. See the #bsg branch: > > > > > > > > http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=bsg > > > > > > I see. > > > > Since Linus is happily snoring by now, could you test and see if the > > tree works for you? > > Yeah, I'll do and send patches later if necessary. Great, thanks. -- 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: block/bsg.c
From: Jens Axboe <[EMAIL PROTECTED]> Subject: Re: block/bsg.c Date: Tue, 17 Jul 2007 09:10:45 +0200 > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > From: Jens Axboe <[EMAIL PROTECTED]> > > Subject: Re: block/bsg.c > > Date: Tue, 17 Jul 2007 08:59:40 +0200 > > > > > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > > > From: Jens Axboe <[EMAIL PROTECTED]> > > > > Subject: Re: block/bsg.c > > > > Date: Tue, 17 Jul 2007 08:38:11 +0200 > > > > > > > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > > > > > > > > > > A belated review (I've never seen this before and there it is in > > > > > > mainline) > > > > > > > > > > > > > static char bsg_version[] = "block layer sg (bsg) 0.4"; > > > > > > > > > > > > `const' would be better. That moves it into a write-protected > > > > > > memory section. > > > > > > > > > > Agree > > > > > > > > > > > > #define list_entry_bc(entry) list_entry((entry), struct > > > > > > > bsg_command, list) > > > > > > > > > > > > This makes the code easier to write but harder to read. We should > > > > > > optimise > > > > > > for readers. Please open-code this at callsites. > > > > > > > > > > > > Or at least convert it into a (commented) (possibly inlined) C > > > > > > function. > > > > > > > > > > list_entry_to_bc(), then? The main objective is to save on typing, and > > > > > (just as important) make sure we don't bump over the 80 chars per > > > > > line. > > > > > > > > > > > > /* > > > > > > > * just for testing > > > > > > > */ > > > > > > > #define BSG_MAJOR (240) > > > > > > > > > > > > What's this doing in mainline? 240 is a "reserved for local use" > > > > > > major. > > > > > > This will cause collisions. This code should be using dynamic major > > > > > > assignment. > > > > > > > > > > Yeah, that's a big error on my part. Will get that fixed up right > > > > > away. > > > > > > > > I've been testing the patchset to fix the issues that Andrew pointed > > > > out. I can send it soon. > > > > > > > > Jens, have you already fixed some? > > > > > > I already pushed some of the changes locally, just the idr change is > > > missing. See the #bsg branch: > > > > > > http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=bsg > > > > I see. > > Since Linus is happily snoring by now, could you test and see if the > tree works for you? Yeah, I'll do and send patches later if necessary. - 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: block/bsg.c
On Tue, Jul 17 2007, FUJITA Tomonori wrote: > From: Jens Axboe <[EMAIL PROTECTED]> > Subject: Re: block/bsg.c > Date: Tue, 17 Jul 2007 08:59:40 +0200 > > > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > > From: Jens Axboe <[EMAIL PROTECTED]> > > > Subject: Re: block/bsg.c > > > Date: Tue, 17 Jul 2007 08:38:11 +0200 > > > > > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > > > > > > > > A belated review (I've never seen this before and there it is in > > > > > mainline) > > > > > > > > > > > static char bsg_version[] = "block layer sg (bsg) 0.4"; > > > > > > > > > > `const' would be better. That moves it into a write-protected memory > > > > > section. > > > > > > > > Agree > > > > > > > > > > #define list_entry_bc(entry)list_entry((entry), struct > > > > > > bsg_command, list) > > > > > > > > > > This makes the code easier to write but harder to read. We should > > > > > optimise > > > > > for readers. Please open-code this at callsites. > > > > > > > > > > Or at least convert it into a (commented) (possibly inlined) C > > > > > function. > > > > > > > > list_entry_to_bc(), then? The main objective is to save on typing, and > > > > (just as important) make sure we don't bump over the 80 chars per line. > > > > > > > > > > /* > > > > > > * just for testing > > > > > > */ > > > > > > #define BSG_MAJOR (240) > > > > > > > > > > What's this doing in mainline? 240 is a "reserved for local use" > > > > > major. > > > > > This will cause collisions. This code should be using dynamic major > > > > > assignment. > > > > > > > > Yeah, that's a big error on my part. Will get that fixed up right away. > > > > > > I've been testing the patchset to fix the issues that Andrew pointed > > > out. I can send it soon. > > > > > > Jens, have you already fixed some? > > > > I already pushed some of the changes locally, just the idr change is > > missing. See the #bsg branch: > > > > http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=bsg > > I see. Since Linus is happily snoring by now, could you test and see if the tree works for you? > > I'll ask for that to get pulled, and can I then assume that you will > > look after bsg from now on? > > I'm happy to do that. Great! -- 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 30/33] USB storage: sg chaining support
On Tue, Jul 17 2007, Greg KH wrote: > On Tue, Jul 17, 2007 at 09:01:02AM +0200, Jens Axboe wrote: > > On Mon, Jul 16 2007, Greg KH wrote: > > > On Mon, Jul 16, 2007 at 11:47:44AM +0200, Jens Axboe wrote: > > > > [PATCH] USB storage: sg chaining support > > > > > > > > Modify usb_stor_access_xfer_buf() to take a pointer to an sg > > > > entry pointer, so we can keep track of that instead of passing > > > > around an integer index (which we can't use when dealing with > > > > multiple scatterlist arrays). > > > > > > > > Cc: [EMAIL PROTECTED] > > > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > > > > > No objection from me, I'm guessing this needs to go through the scsi > > > tree? > > > > Yes it will, I just want to make sure that the relevant people have seen > > (and preferably acked them :) the changes before they go in eventually. > > You might want to pass this one by the usb-storage developer to make > sure. OK, will do. -- 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: block/bsg.c
From: Jens Axboe <[EMAIL PROTECTED]> Subject: Re: block/bsg.c Date: Tue, 17 Jul 2007 08:59:40 +0200 > On Tue, Jul 17 2007, FUJITA Tomonori wrote: > > From: Jens Axboe <[EMAIL PROTECTED]> > > Subject: Re: block/bsg.c > > Date: Tue, 17 Jul 2007 08:38:11 +0200 > > > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > > > > > > A belated review (I've never seen this before and there it is in > > > > mainline) > > > > > > > > > static char bsg_version[] = "block layer sg (bsg) 0.4"; > > > > > > > > `const' would be better. That moves it into a write-protected memory > > > > section. > > > > > > Agree > > > > > > > > #define list_entry_bc(entry) list_entry((entry), struct bsg_command, > > > > > list) > > > > > > > > This makes the code easier to write but harder to read. We should > > > > optimise > > > > for readers. Please open-code this at callsites. > > > > > > > > Or at least convert it into a (commented) (possibly inlined) C function. > > > > > > list_entry_to_bc(), then? The main objective is to save on typing, and > > > (just as important) make sure we don't bump over the 80 chars per line. > > > > > > > > /* > > > > > * just for testing > > > > > */ > > > > > #define BSG_MAJOR (240) > > > > > > > > What's this doing in mainline? 240 is a "reserved for local use" > > > > major. > > > > This will cause collisions. This code should be using dynamic major > > > > assignment. > > > > > > Yeah, that's a big error on my part. Will get that fixed up right away. > > > > I've been testing the patchset to fix the issues that Andrew pointed > > out. I can send it soon. > > > > Jens, have you already fixed some? > > I already pushed some of the changes locally, just the idr change is > missing. See the #bsg branch: > > http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=bsg I see. > I'll ask for that to get pulled, and can I then assume that you will > look after bsg from now on? I'm happy to do that. - 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 30/33] USB storage: sg chaining support
On Tue, Jul 17, 2007 at 09:01:02AM +0200, Jens Axboe wrote: > On Mon, Jul 16 2007, Greg KH wrote: > > On Mon, Jul 16, 2007 at 11:47:44AM +0200, Jens Axboe wrote: > > > [PATCH] USB storage: sg chaining support > > > > > > Modify usb_stor_access_xfer_buf() to take a pointer to an sg > > > entry pointer, so we can keep track of that instead of passing > > > around an integer index (which we can't use when dealing with > > > multiple scatterlist arrays). > > > > > > Cc: [EMAIL PROTECTED] > > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > > > No objection from me, I'm guessing this needs to go through the scsi > > tree? > > Yes it will, I just want to make sure that the relevant people have seen > (and preferably acked them :) the changes before they go in eventually. You might want to pass this one by the usb-storage developer to make sure. thanks, greg k-h - 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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16 2007, Andrew Morton wrote: > On Mon, 16 Jul 2007 22:10:03 +0200 > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > On Mon, 16 Jul 2007 11:47:23 +0200 > > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > > > This prepares x86-64 for sg chaining support. > > > > > > > > Additional improvements/fixups for pci-gart from > > > > Benny Halevy <[EMAIL PROTECTED]> > > > > > > > > Cc: [EMAIL PROTECTED] > > > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > > > --- > > > > arch/x86_64/kernel/pci-calgary.c | 25 -- > > > > arch/x86_64/kernel/pci-gart.c| 63 > > > > - > > > > arch/x86_64/kernel/pci-nommu.c |5 ++- > > > > 3 files changed, 51 insertions(+), 42 deletions(-) > > > > > > This causes fairly extensive destruction of 2.6.23 changes which are > > > pending in Andi's tree. > > > > > > I shall drop the block tree until a) Andi has merged the pending Calgary > > > changes and b) the block tree has been fixed up to account for those (and > > > other) changes. > > > > > > Really, this was the perfectly worst time possible to go tromping all over > > > everyone else's trees. > > > > Well, that's a bit hard for me to know, all I can do is push my stuff to > > for-akpm so that it gets -mm exposure. If I don't, then you are yelling > > at me as well :-) > > It is to be expected that there will be conflicts when making large-scale > changes like this while there is 25MB of unmerged diff sitting out in 50 > different trees. Doing it around the -rc1 time would be better. > > Even better would be not doing it at all: add the necessary stuff into the > block core and then send the followup work to the relevant maintainers. ie: > standard practice. I'll do that. Most of the stuff is trivial, but the x86-64 iommu changes are probably the most tricky and invasive of them all. > > I'll keep rebasing sglist and the other branches I pull into for-akpm, > > so you can just re-enable the for-akpm pull when the a) is true. > > Andi's tree is very out of date and is about to be damaged (to what extent > I don't yet know) by a xen merge. I don't know if a) is going to happen. > > > Things are more than usually messy this time around. Seems so :) -- 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 30/33] USB storage: sg chaining support
On Mon, Jul 16 2007, Greg KH wrote: > On Mon, Jul 16, 2007 at 11:47:44AM +0200, Jens Axboe wrote: > > [PATCH] USB storage: sg chaining support > > > > Modify usb_stor_access_xfer_buf() to take a pointer to an sg > > entry pointer, so we can keep track of that instead of passing > > around an integer index (which we can't use when dealing with > > multiple scatterlist arrays). > > > > Cc: [EMAIL PROTECTED] > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]> > > No objection from me, I'm guessing this needs to go through the scsi > tree? Yes it will, I just want to make sure that the relevant people have seen (and preferably acked them :) the changes before they go in eventually. -- 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: block/bsg.c
On Tue, Jul 17 2007, FUJITA Tomonori wrote: > From: Jens Axboe <[EMAIL PROTECTED]> > Subject: Re: block/bsg.c > Date: Tue, 17 Jul 2007 08:38:11 +0200 > > > On Mon, Jul 16 2007, Andrew Morton wrote: > > > > > > A belated review (I've never seen this before and there it is in mainline) > > > > > > > static char bsg_version[] = "block layer sg (bsg) 0.4"; > > > > > > `const' would be better. That moves it into a write-protected memory > > > section. > > > > Agree > > > > > > #define list_entry_bc(entry)list_entry((entry), struct bsg_command, > > > > list) > > > > > > This makes the code easier to write but harder to read. We should > > > optimise > > > for readers. Please open-code this at callsites. > > > > > > Or at least convert it into a (commented) (possibly inlined) C function. > > > > list_entry_to_bc(), then? The main objective is to save on typing, and > > (just as important) make sure we don't bump over the 80 chars per line. > > > > > > /* > > > > * just for testing > > > > */ > > > > #define BSG_MAJOR (240) > > > > > > What's this doing in mainline? 240 is a "reserved for local use" major. > > > This will cause collisions. This code should be using dynamic major > > > assignment. > > > > Yeah, that's a big error on my part. Will get that fixed up right away. > > I've been testing the patchset to fix the issues that Andrew pointed > out. I can send it soon. > > Jens, have you already fixed some? I already pushed some of the changes locally, just the idr change is missing. See the #bsg branch: http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=bsg I'll ask for that to get pulled, and can I then assume that you will look after bsg from now on? -- 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
