Re: [Scst-devel] Problems with SCST and QLA 2432 FC Cards
Andrew Vasquez <[EMAIL PROTECTED]> Skrev: > On Fri, 18 May 2007, Johan Kragsterman wrote: > >> >Most probably, the driver by link sent by Matthew Jacob will be a good >> >starting point, where you can see examples how to work with the card, so > >> >you can add it to the qla2x00t driver. Also you will need a manual the >> >firmware interface specification for 2400 series of the cards. It is >> >under NDA, but you maybe lucky to get one from QLogic. Feel free to ask > >> >me any SCST or qla2x00t driver related questions. >> > >> >> I have adequate experience of programming in the SCSI domain, however >i >> >> am not much conversant with the QLA driver code. >> >> That´s a very nice initiativ! Though I believe the most important target >> driver to develope is one for a PCI-Express HBA. I believe QLA24xx >stands >> for PCI-X, doesn´t it? And the PCI-Express HBA is called QLE-something? >But >> maybe with this driver we will come closer to a PCI-Express HBA target >> driver? > >QLogic doesn't formally release target-mode drivers for their ISP >chips. Matthew J. has done a great job at providing a community >available souce-base from which to draw ideas and code from. > >Regards, >Andrew Vasquez > > So, Andrew, do you officially represent Qlogic? If so, your point of view here is interesting, since you seem to consider that: "Matthew J. has done a great job at providing a community available souce-base from which to draw ideas and code from". In what way is Qlogic interested in helping the community with providing open firmware, drivers and tools? Rgrds Johan - 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: [Scst-devel] Problems with SCST and QLA 2432 FC Cards
On Fri, 18 May 2007, Johan Kragsterman wrote: > >Most probably, the driver by link sent by Matthew Jacob will be a good > >starting point, where you can see examples how to work with the card, so > >you can add it to the qla2x00t driver. Also you will need a manual the > >firmware interface specification for 2400 series of the cards. It is > >under NDA, but you maybe lucky to get one from QLogic. Feel free to ask > >me any SCST or qla2x00t driver related questions. > > > >> I have adequate experience of programming in the SCSI domain, however i > >> am not much conversant with the QLA driver code. > > That´s a very nice initiativ! Though I believe the most important target > driver to develope is one for a PCI-Express HBA. I believe QLA24xx stands > for PCI-X, doesn´t it? And the PCI-Express HBA is called QLE-something? But > maybe with this driver we will come closer to a PCI-Express HBA target > driver? QLogic doesn't formally release target-mode drivers for their ISP chips. Matthew J. has done a great job at providing a community available souce-base from which to draw ideas and code from. Regards, Andrew Vasquez - 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: add support for FUA
Back in the beginning of last year we disabled mode page 8 and mode page
3f requests through device quirk bits instead of enhancing the driver to
respond to these mode pages because there was no apparent added value.
The Firmware that supports the new communication commands supports the
ability to force a write around of the adapter cache on a command by
command basis. In the attached patch we enable mode page 8 and 3f and
spoof the results as needed in order to *convince* the layers above to
submit writes with the FUA (Force Unit Attention) bit set if the file
system or application requires it, if the Firmware supports the write
through, or instead to submit a SYNCHRONIZE_CACHE if the Firmware does
not. The added value here is for file systems that benefit from this
functionality and for clustering or redundancy scenarios.
Caveats: By convince, we are responding with a minimal short 3 byte
content mode page 8, with only the data the SCSI layer needs and that we
can fill confidently. Applications that require the customarily larger
mode page 8 results may be confused by this(?). The FUA, or the
SYNCHRONIZE_CACHE only affect the cache on the controller. Our firmware
by default ensure that the underlying physical drives of the array have
their cache turned off so normally this is not a problem.
This attached patch is against current scsi-misc-2.6 and was unit tested
on RHEL5. Since this is a feature enhancement, it should not be
considered for any current stabilization efforts.
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's
handling of patch attachments.
Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
Sincerely -- Mark Salyzyn
> -Original Message-
> From: Mark Haverkamp [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 01, 2006 12:31 PM
> To: linux-scsi; James Bottomley
> Cc: Salyzyn, Mark
> Subject: [PATCH 1/3] aacraid: reduce device probe warnings
>
> Received from Mark Salyzyn.
>
> This patch sets up some device quirks surrounding arrays to inform the
> scsi layer that various mode pages are not supported. This reduces the
> severity of the complaints that show up in the logs as the
> array devices
> are enumerated.
>
> Signed-off-by: Mark Haverkamp <[EMAIL PROTECTED]>
> --- scsi-misc-aac.orig/drivers/scsi/aacraid/linit.c
> 2006-01-31 09:35:32.0 -0800
> +++ scsi-misc-aac/drivers/scsi/aacraid/linit.c
> 2006-01-31 09:35:42.0 -0800
> @@ -386,6 +386,10 @@
> static int aac_slave_configure(struct scsi_device *sdev)
> {
> struct Scsi_Host *host = sdev->host;
> + if (sdev_channel(sdev) == CONTAINER_CHANNEL) {
> + sdev->skip_ms_page_8 = 1;
> + sdev->skip_ms_page_3f = 1;
> + }
>
> if (sdev->tagged_supported)
> scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, 128);
>
> --
> Mark Haverkamp <[EMAIL PROTECTED]>
aacraid_fua.patch
Description: aacraid_fua.patch
Re: [Scst-devel] Problems with SCST and QLA 2432 FC Cards
That´s a very nice initiativ! Though I believe the most important target driver to develope is one for a PCI-Express HBA. I believe QLA24xx stands for PCI-X, doesn´t it? And the PCI-Express HBA is called QLE-something? But maybe with this driver we will come closer to a PCI-Express HBA target driver? 2422 -> PCI-X 2432 -> PCI-E - 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: [Scst-devel] Problems with SCST and QLA 2432 FC Cards
Hi, all! >Vladislav Bolkhovitin <[EMAIL PROTECTED]> Skrev: > sandip shete wrote: >> Hi, >> >> I wish to develop support for QLA 24xx series. If you already have a >> partial implementaion of the same, i would like to take it forward. >> And if there isn't, i would appreciate if you could give me some >> pointers in that direction. > >Most probably, the driver by link sent by Matthew Jacob will be a good >starting point, where you can see examples how to work with the card, so >you can add it to the qla2x00t driver. Also you will need a manual the >firmware interface specification for 2400 series of the cards. It is >under NDA, but you maybe lucky to get one from QLogic. Feel free to ask >me any SCST or qla2x00t driver related questions. > >> I have adequate experience of programming in the SCSI domain, however i >> am not much conversant with the QLA driver code. That´s a very nice initiativ! Though I believe the most important target driver to develope is one for a PCI-Express HBA. I believe QLA24xx stands for PCI-X, doesn´t it? And the PCI-Express HBA is called QLE-something? But maybe with this driver we will come closer to a PCI-Express HBA target driver? Rgrds Johan >> >> Thanks and Regards, >> Sandip S > >- >This SF.net email is sponsored by DB2 Express >Download DB2 Express C - the FREE version of DB2 express and take >control of your XML. No limits. Just data. Click to get it now. >http://sourceforge.net/powerbar/db2/ >___ >Scst-devel mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/scst-devel > > - 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 14/28] scsi: fix CONFIG_SCSI_WAIT_SCAN=m
On Fri, 11 May 2007, Hugh Dickins wrote: > On Thu, 10 May 2007, [EMAIL PROTECTED] wrote: > > From: Hugh Dickins <[EMAIL PROTECTED]> > > > > CONFIG_MODULES=y > > CONFIG_SCSI=y > > CONFIG_SCSI_SCAN_ASYNC=y > > CONFIG_SCSI_WAIT_SCAN=m > > > > 2.6.21-rc5-mm2 VFS panics unable to find my root on /dev/sda2, but boots > > okay if I change drivers/scsi/Kconfig to "default y" instead of "default m" > > for SCSI_WAIT_SCAN. > > > > Make sure there's a late_initcall to scsi_complete_async_scans when it's > > built in, so a monolithic SCSI_SCAN_ASYNC kernel can rely on the scans > > being completed before trying to mount root, even if they're slow. > > Thanks for sending this through to James again, Andrew. > I'd been gearing up to report it to the regression police: > it's certainly still a problem in 2.6.21-git. And still a problem in 2.6.22-rc1-git7. Any further news on this regression since 2.6.21? I was hoping that a fix for 2.6.22-rc2 would emerge in the course of the "Asynchronous scsi scanning" thread, but that doesn't appear to be heading in any useful direction. It wouldn't be a problem for me to undo my CONFIG_SCSI_SCAN_ASYNC=y, but it would still be a little regressive. I thought a late_initcall was guaranteed to be called after all the potential-root scsi scans had been started; but admit I'm ignorant of both initcall sequencing and scsi probing. Would a late_initcall_sync or a rootfs_initcall be more to the point? But ignore my gropings, I'd rather be testing what you believe to be the right fix. Thanks, Hugh > > > > > [EMAIL PROTECTED]: build fixes] > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> > > Cc: James Bottomley <[EMAIL PROTECTED]> > > --- > > James sayeth "This isn't the right fix ... this has to be invoked last in > > the > > call sequence ... I can't see another way of doing this except yet another > > file added as a final component to the link." > > I didn't reply to James' mail at the time, hoping "the right fix" was > about to follow. I don't see what's wrong with the late_initcall myself. > > Hugh > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > --- > > > > drivers/scsi/scsi_scan.c |9 + > > 1 file changed, 9 insertions(+) > > > > diff -puN drivers/scsi/scsi_scan.c~scsi-fix-config_scsi_wait_scan=m > > drivers/scsi/scsi_scan.c > > --- a/drivers/scsi/scsi_scan.c~scsi-fix-config_scsi_wait_scan=m > > +++ a/drivers/scsi/scsi_scan.c > > @@ -184,6 +184,15 @@ int scsi_complete_async_scans(void) > > /* Only exported for the benefit of scsi_wait_scan */ > > EXPORT_SYMBOL_GPL(scsi_complete_async_scans); > > > > +#ifndef MODULE > > +/* > > + * For async scanning we need to wait for all the scans to complete before > > + * trying to mount the root fs. Otherwise non-modular drivers may not be > > ready > > + * yet. > > + */ > > +late_initcall(scsi_complete_async_scans); > > +#endif > > + > > /** > > * scsi_unlock_floptical - unlock device via a special MODE SENSE command > > * @sdev: scsi device to send command to > > _ - 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: [Scst-devel] Problems with SCST and QLA 2432 FC Cards
sandip shete wrote: Hi, I wish to develop support for QLA 24xx series. If you already have a partial implementaion of the same, i would like to take it forward. And if there isn't, i would appreciate if you could give me some pointers in that direction. Most probably, the driver by link sent by Matthew Jacob will be a good starting point, where you can see examples how to work with the card, so you can add it to the qla2x00t driver. Also you will need a manual the firmware interface specification for 2400 series of the cards. It is under NDA, but you maybe lucky to get one from QLogic. Feel free to ask me any SCST or qla2x00t driver related questions. I have adequate experience of programming in the SCSI domain, however i am not much conversant with the QLA driver code. Thanks and Regards, Sandip S - 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: [Scst-devel] Problems with SCST and QLA 2432 FC Cards
Unfortunately, 24xx+ cards have very different interface, so add support for them is almost the same as write another driver. Not completely- but close. Feel free to grab ftp://ftp.feral.com/pub/isp/isp_dist.tgz as an example for code to add to scst. - 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: Asynchronous scsi scanning
Peter Jones wrote: > So really, either way means we need to update the tools. It also > doesn't really solve the problem -- when I insert "usb-storage", the > SCSI scan may still finish while we're still enumerating the bus for USB > devices. (I'd be willing to believe I'm wrong about this specific > example, but I suspect the principle still applies for some other driver.) > > In practice, we wind up doing the compare/timeout loop as on > /proc/scsi/scsi, but on /proc/bus/usb/devices or > /sys/bus/ieee1394/drivers/sbp2 instead. sbp2 and its successor fw-sbp2 are not yet integrated with scsi_wait_scan, but should be _some_ day. http://bugzilla.kernel.org/show_bug.cgi?id=3225#c2 -- Stefan Richter -=-=-=== -=-= =--=- http://arcgraph.de/sr/ - 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: Asynchronous scsi scanning
On 5/18/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote: On Fri, May 18, 2007 at 10:58:05AM +0530, Satyam Sharma wrote: > [ BTW, this is the last time I'll try explaining this to you. ] Oh good. Perhaps you can just drop the idea entirely and give up? Well, I do plan to, at least as far as convincing you or getting some alternative in mainline is concerned. > The one-line patch you're suggesting *would*not*allow* one to use the async > scanning _at_all_. If one really wants to use async scanning reliably (even > in > the future, as it can be turned on at boot-time later, like you very well > know), > that module *must* be built. Making it user-visible and/or optional would > *not* > be a solution but a *problem*. What I have been suggesting is *not* to make > this *dummy module* user-visible and/or optional but to _not_ use this > *dummy module* for this purpose in the first place. That's simply not true. There are other ways of using async scanning reliably -- as Peter Jones pointed out. If you're relying on the earlier semantics of "modprobe returned, therefore scanning is complete", then yes, it's unreliable. But if you're using kevents/udev/etc to find out when devices have been discovered, then it's not unreliable. But I do hope the mainline kernel does want to give (by default) the best way/interface of doing this for users/distros, at least. From Peter's mail, I gather that we can do better than what we are presently doing. > [ This time, I don't see the subject changing, nor a "change in the general > direction of the thread blah blah blah", and still you feel compelled to not > maintain the CC list. Wow. ] I see trimming the CC list as a courtesy to those who've had enough of this pointless thread landing in their mailboxes. Well you trimmed out those original "three users" who did show interest in this in the first place. Anyway, pointless it indeed has become... - 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: Asynchronous scsi scanning
On Fri, May 18, 2007 at 10:58:05AM +0530, Satyam Sharma wrote: > [ BTW, this is the last time I'll try explaining this to you. ] Oh good. Perhaps you can just drop the idea entirely and give up? > The one-line patch you're suggesting *would*not*allow* one to use the async > scanning _at_all_. If one really wants to use async scanning reliably (even > in > the future, as it can be turned on at boot-time later, like you very well > know), > that module *must* be built. Making it user-visible and/or optional would > *not* > be a solution but a *problem*. What I have been suggesting is *not* to make > this *dummy module* user-visible and/or optional but to _not_ use this > *dummy module* for this purpose in the first place. That's simply not true. There are other ways of using async scanning reliably -- as Peter Jones pointed out. If you're relying on the earlier semantics of "modprobe returned, therefore scanning is complete", then yes, it's unreliable. But if you're using kevents/udev/etc to find out when devices have been discovered, then it's not unreliable. > [ This time, I don't see the subject changing, nor a "change in the general > direction of the thread blah blah blah", and still you feel compelled to not > maintain the CC list. Wow. ] I see trimming the CC list as a courtesy to those who've had enough of this pointless thread landing in their mailboxes. - 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: [Scst-devel] Problems with SCST and QLA 2432 FC Cards
sandip shete wrote: Hi, I am working with the SCST 0.9.4 version on linux-2.6.15 with the linux-2.6-qla2xxx-target.patch patch applied. I was using a QLA2312 card on this setup and things were just fine when i used this system as a Target. Now I have switched to a qla2432 card and even though i do enable "Target Mode" (echo "1" > /sys/class/scsi_host/host../target_mode_enabled) on the corresponding port, this port fails to work as a target, and none of the Fileio Luns are exported to the initiator. Also, on the initiator side the "/sys/class/fc_remote_port//role" file should show as "FC Target", which it used to with QLA 2312, but with QLA 2432 the initiator side shows the role of the remote port as "FC Initiator" The initiator has 2312 cards and 2.6.15 kernel compiled on it. Also note that, i have the corresponding ql2400_fw.bin firmware binary at the right location and it gets loaded when i load the modules. To check if the qla2432 card was working fine, i connected this to a different 2312 based target system and had it work as a Initiator, this worked fine and i could see all the luns exported on this box. Now the only problem that i can think of in target mode is, maybe, scst doesn't support the qla 24xx series. Yes, that's correct. Unfortunately, 24xx+ series are not supported yet. But i fail to see any part of the code pointing towards that. You can see in the README for the driver that only 22xx and 23xx series are currently supported. When i did some debugging on the initiator side i see that the "qla2x00_get_port_database" does return the status of the remote port as FCT_INITIATOR, i couldn't actually figure out the code wherein the target returns the response to these mbox_commands. I was wondering if SCST plays a part here and sends a different response when 24xx cards are used. Unfortunately, 24xx+ cards have very different interface, so add support for them is almost the same as write another driver. I saw some posts regarding the problems that people were facing with qla24xx series. If this has been fixed in a different verison of Linux/SCST that what i am using, please let me know. Thanks and Regards. Sandip S - 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
