headers
Marcin Dalecki | 1 Oct 2005 01:42
Picon

Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel


On 2005-10-01, at 00:01, Luben Tuikov wrote:
> Why should synchronization between Process A and Process B
> reading storage attributes take place in the kernel?
>
> They can synchronize in user space.

In a mandatory and transparent way? How?

-
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
Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Oct 2005 01:54
Picon
Favicon

Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

Greg Freemyer wrote:
> Luben has more than once called for adding a small number of
> additional calls to the existing SCSI core.  These calls would
> implement the new (reduced) functionallity.  The old calls would
> continue to support the full SPI functionallity.  No existing  LLDD
> would need modification.

IOW, what Luben wants is:

	if (Luben)
		do this
	else
		do current stuff

If this is the case, why bother touching drivers/scsi/* at all?

Regards,

	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
Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Oct 2005 01:57
Picon
Favicon

Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

Luben Tuikov wrote:
> MPT-based drivers + James Bottomley's "transport attributes"

You continue to fail to see that a transport class is more than just 
transport attributes.

You continue to fail to see that working on transport class support IS a 
transport layer, that includes management.

Is you don't understand this fundamental stuff, how can we expect you to 
get it right?

	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
Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Oct 2005 02:01
Picon
Favicon

Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

Andrew Patterson wrote:
> SDI is supposed to be a cross-platform spec, so mandating sysfs would
> not work.  I suggested to the author to use a library like HPAAPI (used
> by Fibre channel), so you could hide OS implementation details.  I am in
> fact working on such a beasty (http://libsdi.berlios.de).  He thinks
> that library solutions tend to not work, because the library version is
> never in synch with the standard/LLDD's. Given Linux vendor lead-times,
> he does have a valid point.

Any kernel interface lib should be like libc or libalsa:  it hides the 
kernel details, however nasty they may be, shielding userspace and apps 
from various changes over time.

	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
Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Oct 2005 02:02
Picon
Favicon

Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

Luben Tuikov wrote:
> But you can write a user space library which uses sysfs or whatever
> _that_ OS uses to represent an SDI spec-ed out picture.
> 
> So a user space program would call (uniformly across all OSs)
> a libsdi library which will use whatever OS dependent way there is
> to get the information (be it sysfs or ioctl).

Agreed completely :)

	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
Permalink | Reply | 0 comments |
headers
Chen, Kenneth W | 1 Oct 2005 02:27
Picon
Favicon

RE: mpt fusion driver performance issue in 2.6.14-rc2

Chen, Kenneth W  wrote on Thursday, September 29, 2005 11:59 AM
> Something happened in between kernel 2.6.12 and 2.6.14-rc2, where
> disk performance went 20X slower on the latest release kernel. I
> suspect it has something to do with the fusion driver. This showed
> up in the boot log: "mptscsih: ioc0: DV: Release failed." is it
> significant?

I think the bug is for real, and it is in the mpt fusion driver.  I'm
not an expert of LSI53C1030 host controller, and I won't pretend to be
one. Though I have data to show what is going on:

There are two threads during driver initialization.  One does domain
validation (mptscsih_domainValidation) and one does host controller
initialization (mptspi_probe).  During 2nd host controller bringup,
i.e., bringing up ioc1, it temporary disables first channel (ioc0).
However, DV is in progress on ioc0 in another thread (and possibly
running on another CPU).  The effect of disabling ioc0 during in-
progress-domain-validation is that it causes all subsequent DV
commands to fail and resulting lowest possible performance setting
for almost all disks pending DV.

Here is a fix that I propose: for the period that ioc0 need to be
disabled for bringing up ioc1, ioc->active is marked with a special
flag and have DV thread busy wait on that flag.  This avoid mptspi_probe
thread clash into the DV thread causing brain-damage to DV.

With the patch, all disks are up to the performance expectation and it
also fixed the "mptscsih: ioc0: DV: Release failed" error message.

Signed-off-by: Ken Chen <kenneth.w.chen <at> intel.com>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeff Garzik | 1 Oct 2005 02:33
Picon
Favicon

Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

Luben Tuikov wrote:
> But none of the ideas: 64 bit LUN, HCIL removal, etc.,
> were accepted with "submit a patch".

I concede this may have been the response in the past.  Its not, now.

>>So you're saying fixing the current SCSI subsystem once *now* costs  
>>more than applying all *future* SCSI fixes to _two_ SCSI subsystems,  
>>handling bug reports for _two_ SCSI subsystems, etc.
> 
> 
> I'm saying that the current "old" one is already obsolete,
> when all you have is a SAS chip on your mainboard.
> 
> All you need is a small, tiny, fast, slim SCSI Core.

Then don't use it at all.  Write a block driver, if you really feel we 
need two SCSI cores.

> Politics: "Nah, whatever you say, specs are *crap* and we'll
> do it our way.  We are not interested in your way, even if it
> were better.  Oh, and BTW, REQUEST SENSE clears ACA and LUN
> is a u64."

This is a misrepresentation.  -We- understand the stuff you have posted.

But you continue to demonstrate that you simply do not understand the 
existing SCSI core code.

The SAS transport class supports commonality across all SAS
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Oct 2005 02:38
Picon
Favicon

Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

Luben Tuikov wrote:
> I'm sure you'll do whatever humanly possible to show
> that _your_ idea can be applied: you can do this now:
> just use a big if () { ... } else { ... } statement and
> you're done.

This is not how we do things in Linux.  You're doubling the maintenance 
burden.

If you really want to do this, at least don't fill up drivers/scsi/ with 
an additional, completely unrelated codepath.

> Furthermore I do not see the reasons to umbrella both
> "aic94xx and LSI cards" when they are _completely different_
> in architecture: MPT and open transport (ala USB Storage and SBP).

There is commonality between aic94xx and MPT/LSI stuff.  aic94xx SAS 
transport layer is a superset of MPT/LSI SAS transport:  it clearly 
needs far more management code.

We understand this.  The part you don't understand is that we want to 
emphasize the commonality, rather than let aic94xx and MPT/LSI go in 
completely different directions.

Read it again:  aic94xx/BCMxxx is a superset of functionality, not 
completely different.

	Jeff

-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Willy Tarreau | 1 Oct 2005 06:58

Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel

On Fri, Sep 30, 2005 at 07:54:08PM -0400, Jeff Garzik wrote:
> Greg Freemyer wrote:
> >Luben has more than once called for adding a small number of
> >additional calls to the existing SCSI core.  These calls would
> >implement the new (reduced) functionallity.  The old calls would
> >continue to support the full SPI functionallity.  No existing  LLDD
> >would need modification.
> 
> IOW, what Luben wants is:
> 
> 	if (Luben)
> 		do this
> 	else
> 		do current stuff
> 
> If this is the case, why bother touching drivers/scsi/* at all?

that's the reason why I proposed that this moved to drivers/sas/* or
somewhere else so that there is no maintaining conflict.

Regards,
Willy
Permalink | Reply | 0 comments |
headers
Moore, Eric Moore | 1 Oct 2005 08:19

Re: mpt fusion driver performance issue in 2.6.14-rc2

On Friday, September 30, 2005 6:27 PM, Chen, Kenneth W wrote:
> Chen, Kenneth W  wrote on Thursday, September 29, 2005 11:59 AM
>> Something happened in between kernel 2.6.12 and 2.6.14-rc2, where
>> disk performance went 20X slower on the latest release kernel. I
>> suspect it has something to do with the fusion driver. This showed
>> up in the boot log: "mptscsih: ioc0: DV: Release failed." is it
>> significant?
>
> I think the bug is for real, and it is in the mpt fusion driver.  I'm
> not an expert of LSI53C1030 host controller, and I won't pretend to be
> one. Though I have data to show what is going on:
>
> There are two threads during driver initialization.  One does domain
> validation (mptscsih_domainValidation) and one does host controller
> initialization (mptspi_probe).  During 2nd host controller bringup,
> i.e., bringing up ioc1, it temporary disables first channel (ioc0).
> However, DV is in progress on ioc0 in another thread (and possibly
> running on another CPU).  The effect of disabling ioc0 during in-
> progress-domain-validation is that it causes all subsequent DV
> commands to fail and resulting lowest possible performance setting
> for almost all disks pending DV.
>
> Here is a fix that I propose: for the period that ioc0 need to be
> disabled for bringing up ioc1, ioc->active is marked with a special
> flag and have DV thread busy wait on that flag.  This avoid mptspi_probe
> thread clash into the DV thread causing brain-damage to DV.
>
> With the patch, all disks are up to the performance expectation and it
> also fixed the "mptscsih: ioc0: DV: Release failed" error message.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane