Dave Boutcher | 1 Apr 2004 01:12
Picon
Favicon

Re: [PATCH] ibmvscsi driver - sixth version

On Wed, 31 Mar 2004 17:02:02 -0500, Jeff Garzik <jgarzik <at> pobox.com> wrote:
> Comments:
>
> 1) Would be nice to eliminate  module options for commands-per-lun, 
> max-requests etc. and actually have the driver figure out the real 
> needs.  One or two options could fall into the "performance tuning" 
> category, and stay, but the others are really dependent on the 
> underlying configuration and underlying limits.
Hmmm...well, I could collapse the two together, since commands_per_lun
is not limited by anything specific for this adapter.  I would prefer
to leave them broken out to handle users who have extreme requirements.

> 2) why is one-descriptor a special case in map_sg_data()?  You proceed 
> to do the same thing in a loop, right below that...  AFAICS you can just 
> use the loop, and clamp the number of scatterlist elements to one.
The SRP spec has two different buffer formats: SRP_DIRECT_BUFFER for a
single buffer, and SRP_INDIRECT_BUFFER for lists of buffers, and the
layout of the buffers in the request is different for those two cases.

> 3) in the following code...
>
> +	if ((evt_struct->crq.format == VIOSRP_SRP_FORMAT) &&
> +	    (atomic_dec_if_positive(&hostdata->request_limit) < 0)) {
> +		printk("ibmvscsi: Warning, request_limit exceeded\n");
> +		unmap_cmd_data(&evt_struct->evt->srp.cmd, hostdata->dev);
> +		ibmvscsi_free_event_struct(&hostdata->pool, evt_struct);
> +		return SCSI_MLQUEUE_HOST_BUSY;
> +	}
>
> is the code prepared to deal with hostdata->request_limit being negative?
(Continue reading)

Mike Christie | 1 Apr 2004 01:15
Picon
Favicon

Re: [PATCH] improvement of fastfail operation

Jens Axboe wrote:
> On Wed, Mar 31 2004, James Bottomley wrote:
> 
>>On Wed, 2004-03-31 at 17:04, Jens Axboe wrote:
>>
>>>So the new patch you sent with this mail is no good. Your previous one
>>>should be adopted ;-)
>>
>>And the:
>>
>>
>>		if (blk_pc_request(req))
>>			leftover = req->data_len - bytes;
>>
>>Since end_that_request chunk won't muck with that, is that OK?
> 
> 
> It's a bit messy right now really, but it's up to the drivers to modify
> that one. So for partial completions, it should be updated to be
> 
> 	leftover = req->data_len;
> 
> as well.
> 

Is that a typo? If drivers are to account for it, scsi should do
	leftover = req->data_len - bytes;
?

-
(Continue reading)

James Bottomley | 1 Apr 2004 01:39
Favicon

Re: [PATCH] ibmvscsi driver - sixth version

On Wed, 2004-03-31 at 18:12, Dave Boutcher wrote:
> OK, two issues.  There are a bunch of SCSI LLDDs that use this same
> logic in abort and reset handlers to wait for adapter events to
> complete, so I think the logic is OK.  The issue of spin_lock_irq
> vs spin_lock is a good one...and points out that there are a bunch
> of LLDDs that are broke :-)  I'll resubmit without the _irq

Actually, no, with the irq is correct.  Wait_for_completion will sleep,
and sleeping with interrupts disabled is wrong.

The reason for this is that the error handler takes the host lock around
calls to the driver error handler functions.  The rationale was that
"simple" drivers didn't want to bother with locking, but it's obviously
causing more problems than it solves.

> > 14) why are you faking a PCI bus?  The following is very, very wrong:
> >
> > +static struct pci_dev iseries_vscsi_dev = {
> > +	.dev.bus = &pci_bus_type,
> > +	.dev.bus_id = "vscsi",
> > +	.dev.release = noop_release
> >
> > Did I mention "very" wrong?  :)
> Because for iseries it is implemented in the pci code.  While it may
> look wrong, it is actually correct.  Check out
> arch/ppc64/kernel/iSeries_iommu.c and arch/ppc64/kernel/dma.c.
> This device has to have dev->bus == &pci_bus_type otherwise the
> dma_mapping_foo functions won't work correctly.

Erm, something is very wrong in the iSeries code then.  This
(Continue reading)

Dave Boutcher | 1 Apr 2004 01:51
Picon
Favicon

Re: [PATCH] ibmvscsi driver - sixth version

On 31 Mar 2004 18:39:57 -0500, James Bottomley 
<James.Bottomley <at> SteelEye.com> wrote:
>> > 14) why are you faking a PCI bus?  The following is very, very wrong:
>> >
>> > +static struct pci_dev iseries_vscsi_dev = {
>> > +	.dev.bus = &pci_bus_type,
>> > +	.dev.bus_id = "vscsi",
>> > +	.dev.release = noop_release
>> >
>> > Did I mention "very" wrong?  :)
>> Because for iseries it is implemented in the pci code.  While it may
>> look wrong, it is actually correct.  Check out
>> arch/ppc64/kernel/iSeries_iommu.c and arch/ppc64/kernel/dma.c.
>> This device has to have dev->bus == &pci_bus_type otherwise the
>> dma_mapping_foo functions won't work correctly.
>
> Erm, something is very wrong in the iSeries code then.  This
> iseries_vio_device is a struct device.  As such, it should contain all
> the information it needs for the DMA API to act on it without performing
> silly pci device tricks.
>
> This looks like it's done because the iseries should be converted to the
> generic device infrastructure, but in fact it's not.  Since the generic
> API has been around for over a year and was designed to solve precisely
> these very problems it needs fixing rather than trying to work around it
> in a driver.
There will always be 1 (no more, no less) of these struct devices in the
system, so I'll move the definition of this into iSeries_iommu and then
just reference it from the driver.  I think that should abstract things
sufficiently.
(Continue reading)

Jeff Garzik | 1 Apr 2004 02:01
Picon
Favicon

[PATCH] remove ->emulated from host template


I think the comment and usage in drivers/block/scsi_ioctl.c says it all, 
but just in case...

This ->emulated exists solely to export an unneeded distinction to 
userspace.  As you can see from sg_emulated_host() in scsi_ioctl.c, the 
value in today's 2.6.x kernels is pretty much completely meaningless.

===== arch/mips/kernel/ioctl32.c 1.17 vs edited =====
--- 1.17/arch/mips/kernel/ioctl32.c	Sun Mar  7 02:04:56 2004
+++ edited/arch/mips/kernel/ioctl32.c	Wed Mar 31 17:57:59 2004
 <at>  <at>  -1074,7 +1074,6  <at>  <at> 
 /* SG stuff */
 COMPATIBLE_IOCTL(SG_SET_TIMEOUT)
 COMPATIBLE_IOCTL(SG_GET_TIMEOUT)
-COMPATIBLE_IOCTL(SG_EMULATED_HOST)
 COMPATIBLE_IOCTL(SG_SET_TRANSFORM)
 COMPATIBLE_IOCTL(SG_GET_TRANSFORM)
 COMPATIBLE_IOCTL(SG_SET_RESERVED_SIZE)
===== drivers/block/scsi_ioctl.c 1.41 vs edited =====
--- 1.41/drivers/block/scsi_ioctl.c	Thu Mar 11 07:19:52 2004
+++ edited/drivers/block/scsi_ioctl.c	Wed Mar 31 17:58:29 2004
 <at>  <at>  -96,15 +96,6  <at>  <at> 
 	return 0;
 }

-/*
- * will always return that we are ATAPI even for a real SCSI drive, I'm not
(Continue reading)

Jeff Garzik | 1 Apr 2004 02:06
Picon
Favicon

[PATCH] remove ->emulated from host template, part 2


and once all the uses are gone, we can kill it from the struct itself.

===== include/scsi/scsi_host.h 1.14 vs edited =====
--- 1.14/include/scsi/scsi_host.h	Thu Mar  4 17:29:02 2004
+++ edited/include/scsi/scsi_host.h	Wed Mar 31 19:05:42 2004
 <at>  <at>  -309,11 +309,6  <at>  <at> 
 	unsigned use_clustering:1;

 	/*
-	 * True for emulated SCSI host adapters (e.g. ATAPI)
-	 */
-	unsigned emulated:1;
-
-	/*
 	 * Countdown for host blocking with no commands outstanding
 	 */
 	unsigned int max_host_blocked;
Jeff Garzik | 1 Apr 2004 02:10
Picon
Favicon

Re: [PATCH] ibmvscsi driver - sixth version

Dave Boutcher wrote:
> There will always be 1 (no more, no less) of these struct devices in the
> system, so I'll move the definition of this into iSeries_iommu and then
> just reference it from the driver.  I think that should abstract things
> sufficiently.

Sounds like a small module declaring devices such as this would be more 
appropriate than unrelated iommu code?

In a regular PCI system, the PCI bus probing code creates devices.  For 
platform-specific virtual devices, ppc64 needs "create my virtual 
devices" initialization code, it looks like.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jeff Garzik | 1 Apr 2004 02:16
Picon
Favicon

Re: [PATCH] ibmvscsi driver - sixth version

Dave Boutcher wrote:
> On Wed, 31 Mar 2004 17:02:02 -0500, Jeff Garzik <jgarzik <at> pobox.com> wrote:
> 
>> Comments:
>>
>> 1) Would be nice to eliminate  module options for commands-per-lun, 
>> max-requests etc. and actually have the driver figure out the real 
>> needs.  One or two options could fall into the "performance tuning" 
>> category, and stay, but the others are really dependent on the 
>> underlying configuration and underlying limits.
> 
> Hmmm...well, I could collapse the two together, since commands_per_lun
> is not limited by anything specific for this adapter.  I would prefer
> to leave them broken out to handle users who have extreme requirements.

"Do what you need to do, and no more."

Don't engineer code because users _might_ have some outlandish requirement.

>> 2) why is one-descriptor a special case in map_sg_data()?  You proceed 
>> to do the same thing in a loop, right below that...  AFAICS you can 
>> just use the loop, and clamp the number of scatterlist elements to one.
> 
> The SRP spec has two different buffer formats: SRP_DIRECT_BUFFER for a
> single buffer, and SRP_INDIRECT_BUFFER for lists of buffers, and the
> layout of the buffers in the request is different for those two cases.

My mistake here -- I was misreading the code as testing both 
DIRECT_BUFFER and INDIRECT_BUFFER in both the loop and non-sg case.

(Continue reading)

Abhishek Rai | 1 Apr 2004 02:27
Picon
Favicon

problem with 2.6.4 and aic79xx

Hi,
(this is a similar problem to one I posted earlier, but this is 
more severe and is with 2.6)

I have an Adaptec 29320A Ultra320 SCSI HBA with which I connect to a SCSI 
array of 9 disks. Each disk is capable of 320MBps. I am using a 2.6.4 
vanilla kernel with an aic79xx module (version 2.0.8, marked 3/16) as 
taken from Justin's page. This configuration works just fine if I configure the disks to 
operate at 160MBps. However, at 320 MBps, insmod of the aic79xx module 
gives some errors which vary between different attempts to insmod. I've 
attaced the log generated by these operations. I don't know what is going 
wrong, and why with 320MBps ?

thanks in advance!
Abhishek

## modprobe aic79xx (before this I insmoded sd_mod, scsi_mod)

Mar 31 19:05:41 t3 kernel: scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, 
Rev 2.0.8
Mar 31 19:05:41 t3 kernel:         <Adaptec 29320A Ultra320 SCSI adapter>
Mar 31 19:05:41 t3 kernel:         aic7901: Ultra320 Wide Channel A, SCSI 
Id=7, PCI 33 or 66Mhz, 512 SCBs
Mar 31 19:05:41 t3 kernel: 
Mar 31 19:05:56 t3 kernel: (scsi0:A:0): 320.000MB/s transfers (160.000MHz 
DT|IU|RTI|QAS, 16bit)
Mar 31 19:05:56 t3 kernel: scsi0: ILLEGAL_PHASE 0x80
Mar 31 19:05:56 t3 kernel: (scsi0:A:0:0): Abort Message Sent
Mar 31 19:06:11 t3 kernel: (scsi0:A:0): 160.000MB/s transfers (80.000MHz 
DT|IU|QAS, 16bit)
(Continue reading)

Brian King | 1 Apr 2004 06:25
Picon
Favicon

[PATCH] Allow LLDs to modify disk r/w timeout

Attached is a patch that adds a rw_timeout field to the scsi_device 
struct which LLDs can setup in their slave_configure routines to 
override the read/write timeout used by sd. Various disk device types 
(i.e. RAID array devices) need longer timeout values than regular scsi 
disks, and this patch allows for this. This would get remove one of the 
reasons the ipr driver modifies the scsi timer today.

Brian King
eServer Storage I/O
IBM Linux Technology Center

This patch adds a r/w timeout field to the scsi_device struct
to allow LLDs to modify the r/w timeout used by the scsi disk
driver. LLDs may setup this field in their slave_configure
routines if they require a different timeout to be used for
certain devices, such as RAID arrays.

---

 linux-2.6.5-rc3-bjking1/drivers/scsi/sd.c          |   11 ++++++++---
 linux-2.6.5-rc3-bjking1/include/scsi/scsi_device.h |    2 ++
 2 files changed, 10 insertions(+), 3 deletions(-)

diff -puN drivers/scsi/sd.c~sd_timeout_mod drivers/scsi/sd.c
--- linux-2.6.5-rc3/drivers/scsi/sd.c~sd_timeout_mod	2004-03-31 19:55:51.000000000 -0600
+++ linux-2.6.5-rc3-bjking1/drivers/scsi/sd.c	2004-03-31 21:41:31.000000000 -0600
 <at>  <at>  -203,9 +203,7  <at>  <at>  static int sd_init_command(struct scsi_c
 	sector_t block;
(Continue reading)


Gmane