Here is a patch for mpt fusion drivers, which
fix's issue of poor performance when driver compiled
built-in to the kernel.
Thanks to Chen, Kenneth W.
History on this:
Between the 3.01.16 and 3.01.18, we introduced new method
to passing command line options to the driver. Some of the
command line options are used for fine tuning dv(domain
validation) in the driver. By accident, these command line options were
wrapped around #ifdef MODULE in the 3.01.18 version of the driver.
What this meant is when the driver is compiled built-in the kernel,
the optimal settings for dv were ignored, thus poor performance.
There was actually a fix for this when I submitted SAS drivers
to the mailing list back in November, however the SAS drivers was
rejected, and later on I overlooked submitting a single patch to
solve this.
Please apply this patch against the 3.01.19 version of the mpt driver
in http://linux-scsi.bkbits.net:8080/scsi-misc-2.6
Signed-off-by: Eric Moore <[email protected]>
On Tue, 2005-03-22 at 11:40 -0700, Moore, Eric Dean wrote:
> History on this:
> Between the 3.01.16 and 3.01.18, we introduced new method
> to passing command line options to the driver. Some of the
> command line options are used for fine tuning dv(domain
> validation) in the driver. By accident, these command line options were
> wrapped around #ifdef MODULE in the 3.01.18 version of the driver.
> What this meant is when the driver is compiled built-in the kernel,
> the optimal settings for dv were ignored, thus poor performance.
OK, I'll add this to the queue.
Could I just point out that if your driver actually printed the results
of negotiation, this would have been an awful lot easier to debug.
Additionally, if you used the SPI transport class domain validation, the
issue wouldn't have arisen in the first place.
James
On Tuesday, March 22, 2005 12:05 PM, James Bottomley wrote:
> On Tue, 2005-03-22 at 11:40 -0700, Moore, Eric Dean wrote:
> > History on this:
> > Between the 3.01.16 and 3.01.18, we introduced new method
> > to passing command line options to the driver. Some of the
> > command line options are used for fine tuning dv(domain
> > validation) in the driver. By accident, these command line
> options were
> > wrapped around #ifdef MODULE in the 3.01.18 version of the driver.
> > What this meant is when the driver is compiled built-in the kernel,
> > the optimal settings for dv were ignored, thus poor performance.
>
> OK, I'll add this to the queue.
>
> Could I just point out that if your driver actually printed
> the results
> of negotiation, this would have been an awful lot easier to debug.
>
> Additionally, if you used the SPI transport class domain
> validation, the
> issue wouldn't have arisen in the first place.
>
> James
>
Yes, I agree with you.
I'm actively working in the background to split the mptscish driver into
separate bus type drivers. One for fiber channel, one for SCSI, and
one for eventually SAS. This was a request from you long time back, at
a time when I tried to submitting a patch having FC transport attributes
support.
I think once I submit that, then we can start taking a looking at supporting
the SPI transport layer.
I still wonder if the SPI transport layer will work for RAID volumes.
Do you know if the spi transport layer supports dv on hidden devices in a
raid volume?
Meaning these hidden physical disks will not been seen by the block layer,
however
spi transport layer would be aware so dv can be performed those hidden disk?
Eric
On Tue, 2005-03-22 at 13:35 -0700, Moore, Eric Dean wrote:
> I still wonder if the SPI transport layer will work for RAID volumes.
> Do you know if the spi transport layer supports dv on hidden devices in a
> raid volume?
> Meaning these hidden physical disks will not been seen by the block layer,
> however
> spi transport layer would be aware so dv can be performed those hidden disk?
I recall this being discussed, and the conclusion being that we could
allow a flag to bar attachment of the ULD. So the underlying discs
would have a scsi_device but no sd device. Then the spi_transport class
will work fine on them but the user wouldn't be able to open them or
mount anything.
James