Re: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Thu, 7 Feb 2008, James Bottomley wrote:
> On Thu, 2008-02-07 at 17:04 -0800, Harvey Harrison wrote:
> > On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote:
> > > Quite a bit of this is fixing things broken previously (the advansys fix
> > > is still pending resolution, but I'll send it as an -rc fix when we have
> > > it). There's the final elimination of all drivers that are esp based
> > > but don't use the scsi_esp core (that's mostly m68k and alpha). Plus
> > > the usual bunch of driver updates and the addition of a new enclosure
> > > services driver and the corresponding ULD.
> > >
> > > The patch is available from:
> > >
> >
> > I'm going to guess that this is the entry in feature-removal.txt
> > that need an update then:
> >
> > ---
> >
> > What: old NCR53C9x driver
> > When: October 2007
> > Why:Replaced by the much better esp_scsi driver. Actual low-level
> > driver can be ported over almost trivially.
> > Who:David Miller <[EMAIL PROTECTED]>
> > Christoph Hellwig <[EMAIL PROTECTED]>
>
> Not immediately ... I anticipate a few "where'd my driver go?" type
> questions from m68k for which this provides a useful reference to point
> to ...
Don't bother, we're fully aware of this.
The shortest feature removal notice in Linux's history (is it?) didn't go
unnoticed ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 0/7] blk_end_request: full I/O completion handler
On Fri, Feb 08 2008, S, Chandrakala (STSD) wrote: > Hi, > > Thanks for the information! > We would like to know when does the 2.6.25 kernel will be available at > kernel.org. So would I, if I locate my crystal ball I'll be sure to let you know :-) Seriously, given past experience, it's probably sometime in April. > > Thanks, > Chandrakala > > -Original Message- > From: Jens Axboe [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 05, 2008 4:09 PM > To: S, Chandrakala (STSD) > Cc: Kiyoshi Ueda; [EMAIL PROTECTED]; > linux-scsi@vger.kernel.org; [EMAIL PROTECTED]; Miller, Mike (OS > Dev); [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [PATCH 0/7] blk_end_request: full I/O completion handler > > On Tue, Feb 05 2008, S, Chandrakala (STSD) wrote: > > Hello, > > > > We would like to know in which kernel version these patches are > > available. > > They were merged after 2.6.24 was released, so they will show up in the > 2.6.25 kernel. > > -- > Jens Axboe > -- 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: Integration of SCST in the mainstream Linux kernel
[EMAIL PROTECTED] wrote: On Thu, 7 Feb 2008, Vladislav Bolkhovitin wrote: Bart Van Assche wrote: - It has been discussed which iSCSI target implementation should be in the mainstream Linux kernel. There is no agreement on this subject yet. The short-term options are as follows: 1) Do not integrate any new iSCSI target implementation in the mainstream Linux kernel. 2) Add one of the existing in-kernel iSCSI target implementations to the kernel, e.g. SCST or PyX/LIO. 3) Create a new in-kernel iSCSI target implementation that combines the advantages of the existing iSCSI kernel target implementations (iETD, STGT, SCST and PyX/LIO). As an iSCSI user, I prefer option (3). The big question is whether the various storage target authors agree with this ? I tend to agree with some important notes: 1. IET should be excluded from this list, iSCSI-SCST is IET updated for SCST framework with a lot of bugfixes and improvements. 2. I think, everybody will agree that Linux iSCSI target should work over some standard SCSI target framework. Hence the choice gets narrower: SCST vs STGT. I don't think there's a way for a dedicated iSCSI target (i.e. PyX/LIO) in the mainline, because of a lot of code duplication. Nicholas could decide to move to either existing framework (although, frankly, I don't think there's a possibility for in-kernel iSCSI target and user space SCSI target framework) and if he decide to go with SCST, I'll be glad to offer my help and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. The better one should win. why should linux as an iSCSI target be limited to passthrough to a SCSI device. the most common use of this sort of thing that I would see is to load up a bunch of 1TB SATA drives in a commodity PC, run software RAID, and then export the resulting volume to other servers via iSCSI. not a 'real' SCSI device in sight. As far as how good a standard iSCSI is, at this point I don't think it really matters. There are too many devices and manufacturers out there that implement iSCSI as their storage protocol (from both sides, offering storage to other systems, and using external storage). Sometimes the best technology doesn't win, but Linux should be interoperable with as much as possible and be ready to support the winners and the loosers in technology options, for as long as anyone chooses to use the old equipment (after all, we support things like Arcnet networking, which lost to Ethernet many years ago) David, your question surprises me a lot. From where have you decided that SCST supports only pass-through backstorage? Does the RAM disk, which Bart has been using for performance tests, look like a SCSI device? SCST supports all backstorage types you can imagine and Linux kernel supports. David Lang - 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 - 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: Integration of SCST in the mainstream Linux kernel
Luben Tuikov wrote: Is there an open iSCSI Target implementation which does NOT issue commands to sub-target devices via the SCSI mid-layer, but bypasses it completely? What do you mean? To call directly low level backstorage SCSI drivers queuecommand() routine? What are advantages of it? Luben - 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 - 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] Integration of SCST in the mainstream Linux kernel
On Thu, 2008-02-07 at 12:37 -0800, Luben Tuikov wrote: > Is there an open iSCSI Target implementation which does NOT > issue commands to sub-target devices via the SCSI mid-layer, but > bypasses it completely? > >Luben > Hi Luben, I am guessing you mean futher down the stack, which I don't know this to be the case. Going futher up the layers is the design of v2.9 LIO-SE. There is a diagram explaining the basic concepts from a 10,000 foot level. http://linux-iscsi.org/builds/user/nab/storage-engine-concept.pdf Note that only traditional iSCSI target is currently implemented in v2.9 LIO-SE codebase in the list of target mode fabrics on left side of the layout. The API between the protocol headers that does encoding/decoding target mode storage packets is probably the least mature area of the LIO stack (because it has always been iSCSI looking towards iSER :). I don't know who has the most mature API between the storage engine and target storage protocol for doing this between SCST and STGT, I am guessing SCST because of the difference in age of the projects. Could someone be so kind to fill me in on this..? Also note, the storage engine plugin for doing userspace passthrough on the right is also currently not implemented. Userspace passthrough in this context is an target engine I/O that is enforcing max_sector and sector_size limitiations, and encodes/decodes target storage protocol packets all out of view of userspace. The addressing will be completely different if we are pointing SE target packets at non SCSI target ports in userspace. --nab > - 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: Integration of SCST in the mainstream Linux kernel
On Thu, 2008-02-07 at 14:51 -0800, [EMAIL PROTECTED] wrote: > On Thu, 7 Feb 2008, Vladislav Bolkhovitin wrote: > > > Bart Van Assche wrote: > >> - It has been discussed which iSCSI target implementation should be in > >> the mainstream Linux kernel. There is no agreement on this subject > >> yet. The short-term options are as follows: > >> 1) Do not integrate any new iSCSI target implementation in the > >> mainstream Linux kernel. > >> 2) Add one of the existing in-kernel iSCSI target implementations to > >> the kernel, e.g. SCST or PyX/LIO. > >> 3) Create a new in-kernel iSCSI target implementation that combines > >> the advantages of the existing iSCSI kernel target implementations > >> (iETD, STGT, SCST and PyX/LIO). > >> > >> As an iSCSI user, I prefer option (3). The big question is whether the > >> various storage target authors agree with this ? > > > > I tend to agree with some important notes: > > > > 1. IET should be excluded from this list, iSCSI-SCST is IET updated for > > SCST > > framework with a lot of bugfixes and improvements. > > > > 2. I think, everybody will agree that Linux iSCSI target should work over > > some standard SCSI target framework. Hence the choice gets narrower: SCST > > vs > > STGT. I don't think there's a way for a dedicated iSCSI target (i.e. > > PyX/LIO) > > in the mainline, because of a lot of code duplication. Nicholas could > > decide > > to move to either existing framework (although, frankly, I don't think > > there's a possibility for in-kernel iSCSI target and user space SCSI target > > framework) and if he decide to go with SCST, I'll be glad to offer my help > > and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. > > The > > better one should win. > > why should linux as an iSCSI target be limited to passthrough to a SCSI > device. > I don't think anyone is saying it should be. It makes sense that the more mature SCSI engines that have working code will be providing alot of the foundation as we talk about options.. >From comparing the designs of SCST and LIO-SE, we know that SCST has supports very SCSI specific target mode hardware, including software target mode forks of other kernel code. This code for the target mode pSCSI, FC and SAS control paths (more for the state machines, that CDB emulation) that will most likely never need to be emulated on non SCSI target engine. SCST has support for the most SCSI fabric protocols of the group (although it is lacking iSER) while the LIO-SE only supports traditional iSCSI using Linux/IP (this means TCP, SCTP and IPv6). The design of LIO-SE was to make every iSCSI initiator that sends SCSI CDBs and data to talk to every potential device in the Linux storage stack on the largest amount of hardware architectures possible. Most of the iSCSI Initiators I know (including non Linux) do not rely on heavy SCSI task management, and I think this would be a lower priority item to get real SCSI specific recovery in the traditional iSCSI target for users. Espically things like SCSI target mode queue locking (affectionally called Auto Contingent Allegiance) make no sense for traditional iSCSI or iSER, because CmdSN rules are doing this for us. > the most common use of this sort of thing that I would see is to load up a > bunch of 1TB SATA drives in a commodity PC, run software RAID, and then > export the resulting volume to other servers via iSCSI. not a 'real' SCSI > device in sight. > I recently moved the last core LIO target machine from a hardware RAID5 to MD RAID6 with struct block_device exported LVM objects via Linux/iSCSI to PVM and HVM domains, and I have been very happy with the results. Being able to export any physical or virtual storage object from whatever layer makes sense for your particular case. This applies to both block and file level access. For example, making an iSCSI Initiator and Target run in the most limited in environments places where NAS (espically userspace server side) would have a really hard time fitting, has always been a requirement. You can imagine a system with a smaller amount of memory (say 32MB) having a difficult time doing I/O to any amount of NAS clients. If are talking about memory required to get best performance, using kernel level DMA ring allocation and submission to a generic target engine uses a significantly smaller amount of memory, than say traditional buffered FILEIO. Going futher up the storage stack with buffered file IO, regardless of if its block or file level, will always start to add overhead. I think that kernel level FILEIO with O_DIRECT and asyncio would probably help alot in this case for general target mode usage of MD and LVM block devices. This is because when we are using PSCSI or IBLOCK to queue I/Os which, may need be different from the original IO from the initiator/client due to OS storage subsystem differences and/or physical HBA limitiations for the layers below block. The current LIO-SE API e
[PATCH 3/3] mpt fusion: Avoid racing when mptsas and mptcl module are loaded in parallel
This patch sets the IOC pointer in drvrdata of pcidev before adding the IOC into the list of IOCs. Without this patch the driver oops when the mptsas and mptctl modules are loaded in parallel. signed-off-by: Sathya Prakash <[EMAIL PROTECTED]> --- diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c index 355c172..d473146 100644 --- a/drivers/message/fusion/mptbase.c +++ b/drivers/message/fusion/mptbase.c @@ -1704,6 +1704,9 @@ mpt_attach(struct pci_dev *pdev, const struct pci_device_id *id) ioc->active = 0; CHIPREG_WRITE32(&ioc->chip->IntStatus, 0); + /* Set IOC ptr in the pcidev's driver data. */ + pci_set_drvdata(ioc->pcidev, ioc); + /* Set lookup ptr. */ list_add_tail(&ioc->list, &ioc_list); @@ -2074,7 +2077,6 @@ mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int sleepFlag) irq_allocated = 1; ioc->pci_irq = ioc->pcidev->irq; pci_set_master(ioc->pcidev);/* ?? */ - pci_set_drvdata(ioc->pcidev, ioc); dprintk(ioc, printk(MYIOC_s_INFO_FMT "installed at interrupt " "%d\n", ioc->name, ioc->pcidev->irq)); } - 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
[Bug 9769] CONFIG_SCSI_WAIT_SCAN configure error
http://bugzilla.kernel.org/show_bug.cgi?id=9769 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |REJECTED Resolution||INVALID --- Comment #3 from [EMAIL PROTECTED] 2008-02-08 07:56 --- Thanks, closing the bug. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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] megaraid: outb_p extermination
>From conversations with the maintainers the _p isn't needed so kill it.
That removes the last non ISA _p user from the SCSI layer to my knowledge.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-mm1/drivers/scsi/megaraid.c
linux-2.6.24-mm1/drivers/scsi/megaraid.c
--- linux.vanilla-2.6.24-mm1/drivers/scsi/megaraid.c2008-02-06
14:14:41.0 +
+++ linux-2.6.24-mm1/drivers/scsi/megaraid.c2008-02-06 14:35:38.0
+
@@ -151,19 +151,19 @@
*/
if( adapter->flag & BOARD_IOMAP ) {
- outb_p(adapter->mbox_dma & 0xFF,
+ outb(adapter->mbox_dma & 0xFF,
adapter->host->io_port + MBOX_PORT0);
- outb_p((adapter->mbox_dma >> 8) & 0xFF,
+ outb((adapter->mbox_dma >> 8) & 0xFF,
adapter->host->io_port + MBOX_PORT1);
- outb_p((adapter->mbox_dma >> 16) & 0xFF,
+ outb((adapter->mbox_dma >> 16) & 0xFF,
adapter->host->io_port + MBOX_PORT2);
- outb_p((adapter->mbox_dma >> 24) & 0xFF,
+ outb((adapter->mbox_dma >> 24) & 0xFF,
adapter->host->io_port + MBOX_PORT3);
- outb_p(ENABLE_MBOX_BYTE,
+ outb(ENABLE_MBOX_BYTE,
adapter->host->io_port + ENABLE_MBOX_REGION);
irq_ack(adapter);
-
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] scsi_error: Fix language abuse.
On Fri, 2008-02-08 at 15:32 +, Alan Cox wrote: > The word "illegal" has a precise dictionary meaning of "prohibited by > law". The error messages are therefore incorrect as so far nobody has > made SCSI violations a criminal offence. Um, I'm really reluctant to do this without an incredibly good reason. Illegal is a defined term under the SCSI standards, and the messages you are changing actually appear with the word Illegal in the actual ASC/ASCQ definition. If I accept this patch, you'll no longer be able to look the messages up in the relevant standard: http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf By a simple text search. I don't think the pedantry is worth the confusion ... 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
[PATCH] scsi_error: Fix language abuse.
The word "illegal" has a precise dictionary meaning of "prohibited by
law". The error messages are therefore incorrect as so far nobody has
made SCSI violations a criminal offence.
This corrects scsi to match various other subsystems I've slowly been
ridding of this.
Pedantically-signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-mm1/drivers/scsi/constants.c
linux-2.6.24-mm1/drivers/scsi/constants.c
--- linux.vanilla-2.6.24-mm1/drivers/scsi/constants.c 2008-02-06
14:14:40.0 +
+++ linux-2.6.24-mm1/drivers/scsi/constants.c 2008-02-06 14:35:16.0
+
@@ -606,10 +606,10 @@
{0x2001, "Access denied - initiator pending-enrolled"},
{0x2002, "Access denied - no access rights"},
{0x2003, "Access denied - invalid mgmt id key"},
- {0x2004, "Illegal command while in write capable state"},
+ {0x2004, "Invalid command while in write capable state"},
{0x2005, "Obsolete"},
- {0x2006, "Illegal command while in explicit address mode"},
- {0x2007, "Illegal command while in implicit address mode"},
+ {0x2006, "Invalid command while in explicit address mode"},
+ {0x2007, "Invalid command while in implicit address mode"},
{0x2008, "Access denied - enrollment conflict"},
{0x2009, "Access denied - invalid LU identifier"},
{0x200A, "Access denied - invalid proxy token"},
@@ -620,7 +620,7 @@
{0x2102, "Invalid address for write"},
{0x2103, "Invalid write crossing layer jump"},
- {0x2200, "Illegal function (use 20 00, 24 00, or 26 00)"},
+ {0x2200, "Invalid function (use 20 00, 24 00, or 26 00)"},
{0x2400, "Invalid field in cdb"},
{0x2401, "CDB decryption error"},
@@ -697,7 +697,7 @@
{0x2C02, "Invalid combination of windows specified"},
{0x2C03, "Current program area is not empty"},
{0x2C04, "Current program area is empty"},
- {0x2C05, "Illegal power condition request"},
+ {0x2C05, "Invalid power condition request"},
{0x2C06, "Persistent prevent conflict"},
{0x2C07, "Previous busy status"},
{0x2C08, "Previous task set full status"},
@@ -1014,7 +1014,7 @@
{0x6300, "End of user area encountered on this track"},
{0x6301, "Packet does not fit in available space"},
- {0x6400, "Illegal mode for this track"},
+ {0x6400, "Invalid mode for this track"},
{0x6401, "Invalid packet size"},
{0x6500, "Voltage fault"},
@@ -1124,7 +1124,7 @@
"Not Ready",/* 2: The addressed target is not ready */
"Medium Error", /* 3: Data error detected on the medium */
"Hardware Error", /* 4: Controller or device failure */
- "Illegal Request", /* 5: Error in request */
+ "Invalid Request", /* 5: Error in request */
"Unit Attention", /* 6: Removable medium was changed, or
the target has been reset, or ... */
"Data Protect", /* 7: Access to the data is blocked */
-
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] bugfix for an underflow condition in usb storage & isd200.c
On Tue, 5 Feb 2008, Matthew Dharm wrote:
> We both agree that the code shouldn't run off the end of the s-g list.
Incidentally, if people want a simple bugfix patch for 2.6.24.stable,
this should do it. Mark, can you confirm that this patch alone fixes
the problem?
Alan Stern
Index: 2.6.24/drivers/usb/storage/protocol.c
===
--- 2.6.24.orig/drivers/usb/storage/protocol.c
+++ 2.6.24/drivers/usb/storage/protocol.c
@@ -194,7 +194,7 @@ unsigned int usb_stor_access_xfer_buf(un
* and the starting offset within the page, and update
* the *offset and *index values for the next loop. */
cnt = 0;
- while (cnt < buflen) {
+ while (cnt < buflen && sg) {
struct page *page = sg_page(sg) +
((sg->offset + *offset) >> PAGE_SHIFT);
unsigned int poff =
@@ -249,6 +249,7 @@ void usb_stor_set_xfer_buf(unsigned char
unsigned int offset = 0;
struct scatterlist *sg = NULL;
+ buflen = min(buflen, srb->request_bufflen);
usb_stor_access_xfer_buf(buffer, buflen, srb, &sg, &offset,
TO_XFER_BUF);
if (buflen < srb->request_bufflen)
-
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 3/3] mpt fusion: Avoid racing when mptsas and mptclmodule are loaded in parallel
James, I tried to submit set of three patches, the other two patches are not showing in the list yet, I don't know the reason, I have resent them again few minutes back. Thanks Sathya -Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Friday, February 08, 2008 10:17 PM To: Prakash, Sathya Cc: linux-scsi@vger.kernel.org; Moore, Eric Subject: Re: [PATCH 3/3] mpt fusion: Avoid racing when mptsas and mptclmodule are loaded in parallel On Fri, 2008-02-08 at 16:35 +0530, Prakash, Sathya wrote: > This patch sets the IOC pointer in drvrdata of pcidev before adding > the IOC into the list of IOCs. Without this patch the driver oops when > the mptsas and mptctl modules are loaded in parallel. Much better, thanks. Would I be correct in assuming that even though this email says [PATCH 3/3] there aren't two missing precursor patches? 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] scsi_error: Fix language abuse.
linux-os (Dick Johnson) wrote: > > The correct word should be "invalid," in spite of > the fact that the SCSI committee used invalid syntax. > > Alan is right. There is nothing illegal in the kernel > and if there is, it must be removed as soon as it > is discovered! > il·le·gal (-lgl) adj. 1. Prohibited by law. *2. Prohibited by official rules: an illegal pass in football. *3. Unacceptable to or not performable by a computer: an illegal operation. Mark - 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: [GIT PATCH] final SCSI updates for 2.6.24 merge window
On Fri, 2008-02-08 at 10:03 +0100, Geert Uytterhoeven wrote: > On Thu, 7 Feb 2008, James Bottomley wrote: > > On Thu, 2008-02-07 at 17:04 -0800, Harvey Harrison wrote: > > > On Thu, 2008-02-07 at 18:56 -0600, James Bottomley wrote: > > > > Quite a bit of this is fixing things broken previously (the advansys fix > > > > is still pending resolution, but I'll send it as an -rc fix when we have > > > > it). There's the final elimination of all drivers that are esp based > > > > but don't use the scsi_esp core (that's mostly m68k and alpha). Plus > > > > the usual bunch of driver updates and the addition of a new enclosure > > > > services driver and the corresponding ULD. > > > > > > > > The patch is available from: > > > > > > > > > > I'm going to guess that this is the entry in feature-removal.txt > > > that need an update then: > > > > > > --- > > > > > > What: old NCR53C9x driver > > > When: October 2007 > > > Why: Replaced by the much better esp_scsi driver. Actual low-level > > > driver can be ported over almost trivially. > > > Who: David Miller <[EMAIL PROTECTED]> > > > Christoph Hellwig <[EMAIL PROTECTED]> > > > > Not immediately ... I anticipate a few "where'd my driver go?" type > > questions from m68k for which this provides a useful reference to point > > to ... > > Don't bother, we're fully aware of this. > > The shortest feature removal notice in Linux's history (is it?) didn't go > unnoticed ;-) I don't know where you get that from. The notice went in on 30 April 2007 and we gave you six months to convert the drivers, hence the October 2007 date for when the deletion will actually be done. I've actually delayed removal until February 2007 giving you a further three months. Even then I only removed the drivers because they no longer compile. I think nine months isn't unreasonable for a feature removal ... unless you work on a different time scale from me? 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] scsi_error: Fix language abuse.
On Fri, 2008-02-08 at 15:59 +, Alan Cox wrote: > > http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf > > > > By a simple text search. > > > > I don't think the pedantry is worth the confusion ... > > Ok so we should file a formal change request with T10 instead perhaps ? As long as that "we" is royal, be my guest and go ahead. If you set up the correct legal trust, your heirs and assigns can submit the patch just as soon as T10 accepts the change ... 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: Integration of SCST in the mainstream Linux kernel
Nicholas A. Bellinger wrote: On Thu, 2008-02-07 at 12:37 -0800, Luben Tuikov wrote: Is there an open iSCSI Target implementation which does NOT issue commands to sub-target devices via the SCSI mid-layer, but bypasses it completely? Luben Hi Luben, I am guessing you mean futher down the stack, which I don't know this to be the case. Going futher up the layers is the design of v2.9 LIO-SE. There is a diagram explaining the basic concepts from a 10,000 foot level. http://linux-iscsi.org/builds/user/nab/storage-engine-concept.pdf Note that only traditional iSCSI target is currently implemented in v2.9 LIO-SE codebase in the list of target mode fabrics on left side of the layout. The API between the protocol headers that does encoding/decoding target mode storage packets is probably the least mature area of the LIO stack (because it has always been iSCSI looking towards iSER :). I don't know who has the most mature API between the storage engine and target storage protocol for doing this between SCST and STGT, I am guessing SCST because of the difference in age of the projects. Could someone be so kind to fill me in on this..? SCST uses scsi_execute_async_fifo() function to submit commands to SCSI devices in the pass-through mode. This function is slightly modified version of scsi_execute_async(), which submits requests in FIFO order instead of LIFO as scsi_execute_async() does (so with scsi_execute_async() they are executed in the reverse order). Scsi_execute_async_fifo() added as a separate patch to the kernel. Also note, the storage engine plugin for doing userspace passthrough on the right is also currently not implemented. Userspace passthrough in this context is an target engine I/O that is enforcing max_sector and sector_size limitiations, and encodes/decodes target storage protocol packets all out of view of userspace. The addressing will be completely different if we are pointing SE target packets at non SCSI target ports in userspace. --nab - 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/3] mpt fusion: Request I/O resources only when required
This patch modifies the I/O resource allocation behavior of FUSION driver.
The current version of driver allocates the I/O resources even if they are not
required and this creates trouble in low resource environments.
This driver now uses pci_enable_device_mem/pci_enable_device functions to
differentiate the resource allocations.
signed-off-by: Sathya Prakash <[EMAIL PROTECTED]>
---
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index 425f60c..c3f33de 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -1470,9 +1470,6 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
if (mpt_debug_level)
printk(KERN_INFO MYNAM ": mpt_debug_level=%xh\n",
mpt_debug_level);
- if (pci_enable_device(pdev))
- return r;
-
ioc = kzalloc(sizeof(MPT_ADAPTER), GFP_ATOMIC);
if (ioc == NULL) {
printk(KERN_ERR MYNAM ": ERROR - Insufficient memory to add
adapter!\n");
@@ -1482,6 +1479,20 @@ mpt_attach(struct pci_dev *pdev, const struct
pci_device_id *id)
ioc->id = mpt_ids++;
sprintf(ioc->name, "ioc%d", ioc->id);
+ ioc->bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_mem(pdev)) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT "pci_enable_device_mem() "
+ "failed\n",ioc->name);
+ return r;
+ }
+ if (pci_request_selected_regions(pdev, ioc->bars, "mpt")) {
+ kfree(ioc);
+ printk(MYIOC_s_ERR_FMT "pci_request_selected_regions() with "
+ "MEM failed\n",ioc->name);
+ return r;
+ }
+
dinitprintk(ioc, printk(MYIOC_s_INFO_FMT ": mpt_adapter_install\n",
ioc->name));
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
@@ -1791,6 +1802,7 @@ mpt_suspend(struct pci_dev *pdev, pm_message_t state)
CHIPREG_WRITE32(&ioc->chip->IntStatus, 0);
pci_disable_device(pdev);
+ pci_release_selected_regions(pdev, ioc->bars);
pci_set_power_state(pdev, device_state);
return 0;
@@ -1807,7 +1819,6 @@ mpt_resume(struct pci_dev *pdev)
MPT_ADAPTER *ioc = pci_get_drvdata(pdev);
u32 device_state = pdev->current_state;
int recovery_state;
- int err;
printk(MYIOC_s_INFO_FMT
"pci-resume: pdev=0x%p, slot=%s, Previous operating state [D%d]\n",
@@ -1815,9 +1826,18 @@ mpt_resume(struct pci_dev *pdev)
pci_set_power_state(pdev, 0);
pci_restore_state(pdev);
- err = pci_enable_device(pdev);
- if (err)
- return err;
+ if (ioc->facts.Flags & MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT) {
+ ioc->bars = pci_select_bars(ioc->pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ if (pci_enable_device(pdev))
+ return 0;
+ } else {
+ ioc->bars = pci_select_bars(pdev, IORESOURCE_MEM);
+ if (pci_enable_device_mem(pdev))
+ return 0;
+ }
+ if (pci_request_selected_regions(pdev, ioc->bars, "mpt"))
+ return 0;
/* enable interrupts */
CHIPREG_WRITE32(&ioc->chip->IntMask, MPI_HIM_DIM);
@@ -1878,6 +1898,7 @@ mpt_signal_reset(u8 index, MPT_ADAPTER *ioc, int
reset_phase)
* -2 if READY but IOCFacts Failed
* -3 if READY but PrimeIOCFifos Failed
* -4 if READY but IOCInit Failed
+ * -5 if failed to enable_device and/or request_selected_regions
*/
static int
mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int sleepFlag)
@@ -1976,6 +1997,18 @@ mpt_do_ioc_recovery(MPT_ADAPTER *ioc, u32 reason, int
sleepFlag)
}
}
+ if ((ret == 0) && (reason == MPT_HOSTEVENT_IOC_BRINGUP) &&
+ (ioc->facts.Flags & MPI_IOCFACTS_FLAGS_FW_DOWNLOAD_BOOT)) {
+ pci_release_selected_regions(ioc->pcidev, ioc->bars);
+ ioc->bars = pci_select_bars(ioc->pcidev, IORESOURCE_MEM |
+ IORESOURCE_IO);
+ if (pci_enable_device(ioc->pcidev))
+ return -5;
+ if (pci_request_selected_regions(ioc->pcidev, ioc->bars,
+ "mpt"))
+ return -5;
+ }
+
/*
* Device is reset now. It must have de-asserted the interrupt line
* (if it was asserted) and it should be safe to register for the
@@ -2381,6 +2414,9 @@ mpt_adapter_dispose(MPT_ADAPTER *ioc)
ioc->memmap = NULL;
}
+ pci_disable_device(ioc->pcidev);
+ pci_release_selected_regions(ioc->pcidev, ioc->bars);
+
#if defined(CONFIG_MTRR) && 0
if (ioc->mtrr_reg > 0) {
mtrr_del(ioc->mtrr_reg, 0, 0);
diff --git a/drivers/message/fusion/mptbase.h b/drivers/message/fusion/mptbase.h
index b49b706..44c98c5 100644
--- a/drivers/message/fusion
Re: [PATCH] scsi_error: Fix language abuse.
The correct word should be "invalid," in spite of the fact that the SCSI committee used invalid syntax. Alan is right. There is nothing illegal in the kernel and if there is, it must be removed as soon as it is discovered! On Fri, 8 Feb 2008, James Bottomley wrote: > > On Fri, 2008-02-08 at 15:32 +, Alan Cox wrote: >> The word "illegal" has a precise dictionary meaning of "prohibited by >> law". The error messages are therefore incorrect as so far nobody has >> made SCSI violations a criminal offence. > > Um, I'm really reluctant to do this without an incredibly good reason. > Illegal is a defined term under the SCSI standards, and the messages you > are changing actually appear with the word Illegal in the actual > ASC/ASCQ definition. If I accept this patch, you'll no longer be able > to look the messages up in the relevant standard: > > http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf > > By a simple text search. > > I don't think the pedantry is worth the confusion ... > > James > Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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/1] aacraid: ignore adapter reset check polarity
The Adapter's Ignore Reset flag and insmod parameter boolean polarity is incorrect in the driver. 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 | 14 -- drivers/scsi/aacraid/commsup.c |2 +- drivers/scsi/aacraid/linit.c |2 +- 3 files changed, 10 insertions(+), 8 deletions(-) Sincerely - Mark Salyzyn aacraid_ignore_reset.patch Description: aacraid_ignore_reset.patch
[PATCH 1/1] aacraid: informational sysfs value corrections
Some sysfs problems reported. The serial number on late model controllers was
truncated. Non-DASD devices (tapes and CDROMs) were showing up as JBOD in the
level report on the physical channel.
This attached patch is against current scsi-misc-2.6.
ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling
of patch attachments (inline gets damaged, please use attachment).
Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
drivers/scsi/aacraid/linit.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff -ru a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
--- a/drivers/scsi/aacraid/linit.c 2008-02-08 11:22:43.497295473 -0500
+++ b/drivers/scsi/aacraid/linit.c 2008-02-08 11:51:52.376880890 -0500
@@ -494,13 +494,14 @@
static ssize_t aac_show_raid_level(struct device *dev, struct device_attribute
*attr, char *buf)
{
- struct scsi_device * sdev = to_scsi_device(dev);
+ struct scsi_device *sdev = to_scsi_device(dev);
+ struct aac_dev *aac = (struct aac_dev *)(sdev->host->hostdata);
if (sdev_channel(sdev) != CONTAINER_CHANNEL)
return snprintf(buf, PAGE_SIZE, sdev->no_uld_attach
- ? "Hidden\n" : "JBOD");
+ ? "Hidden\n" :
+ ((aac->jbod && (sdev->type == TYPE_DISK)) ? "JBOD\n" : ""));
return snprintf(buf, PAGE_SIZE, "%s\n",
- get_container_type(((struct aac_dev *)(sdev->host->hostdata))
- ->fsa_dev[sdev_id(sdev)].type));
+ get_container_type(aac->fsa_dev[sdev_id(sdev)].type));
}
static struct device_attribute aac_raid_level_attr = {
@@ -860,8 +861,8 @@
le32_to_cpu(dev->adapter_info.serial[0]));
if (len &&
!memcmp(&dev->supplement_adapter_info.MfgPcbaSerialNo[
- sizeof(dev->supplement_adapter_info.MfgPcbaSerialNo)+2-len],
- buf, len))
+ sizeof(dev->supplement_adapter_info.MfgPcbaSerialNo)-len],
+ buf, len-1))
len = snprintf(buf, PAGE_SIZE, "%.*s\n",
(int)sizeof(dev->supplement_adapter_info.MfgPcbaSerialNo),
dev->supplement_adapter_info.MfgPcbaSerialNo);
Sincerely - Mark Salyzyn
aacraid_serial_level_sysfs.patch
Description: aacraid_serial_level_sysfs.patch
Re: [PATCH 1/3] mpt fusion: Request I/O resources only when required
On Fri, 2008-02-08 at 22:05 +0530, Prakash, Sathya wrote: > This patch modifies the I/O resource allocation behavior of FUSION driver. > The current version of driver allocates the I/O resources even if they are > not required and this creates trouble in low resource environments. > This driver now uses pci_enable_device_mem/pci_enable_device functions to > differentiate the resource allocations. > > signed-off-by: Sathya Prakash <[EMAIL PROTECTED]> ^ Capital 'S' The patch could also have done with a bit of checkpatch.pl love: WARNING: Signed-off-by: is the preferred form #58: signed-off-by: Sathya Prakash <[EMAIL PROTECTED]> ERROR: need space after that ',' (ctx:VxV) #83: FILE: drivers/message/fusion/mptbase.c:1486: + "failed\n",ioc->name); ^ ERROR: use tabs not spaces #84: FILE: drivers/message/fusion/mptbase.c:1487: + ^I^Ireturn r;$ ERROR: need space after that ',' (ctx:VxV) #89: FILE: drivers/message/fusion/mptbase.c:1492: + "MEM failed\n",ioc->name); ^ ERROR: trailing whitespace #123: FILE: drivers/message/fusion/mptbase.c:1833: +^I^I^Ireturn 0; $ WARNING: line over 80 characters #179: FILE: drivers/message/fusion/mptbase.h:632: + int bars; /* bitmask of BAR's that must be configured */ total: 4 errors, 2 warnings, 105 lines checked YJames - 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: [PATCHSET #upstream] block/libata: update and use block layer padding and draining
On Fri, Feb 08 2008, Jeff Garzik wrote: > Jeff Garzik wrote: > >Tejun Heo wrote: > >>This patchset updates block layer padding and draining support and > >>make libata use it. It's based on James Bottomley's initial work and, > >>of the five, the last two patches are from James with some > >>modifications. > >> > >>Please read the following thread for more info. > >> > >> http://thread.gmane.org/gmane.linux.scsi/37185 > >> > >>This patchset is on top of > >> > >> upstream (a6af42fc9a12165136d82206ad52f18c5955ce87) > >>+ kill-n_iter-and-fix-fsl patch [1] > > > >ACK patchset... lets definitely get these fixes upstream. > > > >Once Jens is happy, I would prefer the merge the lot upstream, if that > >is OK with everyone involved? > > Jens, ping? > > It's a bug fix, so it would be nice to get this in soonish. As noted, > if all looks good, I would prefer to merge via libata-dev... I'm ok with it, but lets please merge the block bits through the block repo, since they are not trivial. Wont be until the week after next, though. -- 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] bugfix for an underflow condition in usb storage & isd200.c
On Fri, 8 Feb 2008 11:46:13 -0500 (EST)
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Feb 2008, Matthew Dharm wrote:
>
> > We both agree that the code shouldn't run off the end of the s-g
> > list.
>
> Incidentally, if people want a simple bugfix patch for 2.6.24.stable,
> this should do it. Mark, can you confirm that this patch alone fixes
> the problem?
Confirmed: works just fine.
Tested-by: Mark Glines <[EMAIL PROTECTED]>
>
> Alan Stern
>
>
>
> Index: 2.6.24/drivers/usb/storage/protocol.c
> ===
> --- 2.6.24.orig/drivers/usb/storage/protocol.c
> +++ 2.6.24/drivers/usb/storage/protocol.c
> @@ -194,7 +194,7 @@ unsigned int usb_stor_access_xfer_buf(un
>* and the starting offset within the page, and
> update
>* the *offset and *index values for the next loop.
> */ cnt = 0;
> - while (cnt < buflen) {
> + while (cnt < buflen && sg) {
> struct page *page = sg_page(sg) +
> ((sg->offset + *offset) >>
> PAGE_SHIFT); unsigned int poff =
> @@ -249,6 +249,7 @@ void usb_stor_set_xfer_buf(unsigned char
> unsigned int offset = 0;
> struct scatterlist *sg = NULL;
>
> + buflen = min(buflen, srb->request_bufflen);
> usb_stor_access_xfer_buf(buffer, buflen, srb, &sg, &offset,
> TO_XFER_BUF);
> if (buflen < srb->request_bufflen)
>
-
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: [PATCHSET #upstream] block/libata: update and use block layer padding and draining
Jeff Garzik wrote: Tejun Heo wrote: This patchset updates block layer padding and draining support and make libata use it. It's based on James Bottomley's initial work and, of the five, the last two patches are from James with some modifications. Please read the following thread for more info. http://thread.gmane.org/gmane.linux.scsi/37185 This patchset is on top of upstream (a6af42fc9a12165136d82206ad52f18c5955ce87) + kill-n_iter-and-fix-fsl patch [1] ACK patchset... lets definitely get these fixes upstream. Once Jens is happy, I would prefer the merge the lot upstream, if that is OK with everyone involved? Jens, ping? It's a bug fix, so it would be nice to get this in soonish. As noted, if all looks good, I would prefer to merge via libata-dev... Thanks, 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: [PATCH 11/9] firewire: fw-sbp2: enforce a retry of __scsi_add_device if bus generation changed
(Adding Cc: LSML) Jarod Wilson wrote: > On Wednesday 06 February 2008 04:09:47 pm Stefan Richter wrote: >> take care that __scsi_add_device does not return success >> even though the SCSI high-level driver probing failed (sd READ_CAPACITY >> and friends) due to bus reset. The trick to do so is to use a different >> error indicator in the command completion as long as __scsi_add_device >> did not return. Or so did I guess, and... >> An actual failure of __scsi_add_device is easy to handle, but an >> incomplete execution of __scsi_add_device with an sdev returned would >> remain undetected and leave the SBP-2 target unusable. >> >> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> >> --- >> >> Jarod, does this work like I assume and fixes your setup of two OXFW911 >> based disks? > > Well, it results in the dmesg spew saying "sd 6:0:0:0: [sdc] Result: > hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK" -- i.e., > DID_NO_CONNECT instead of DID_BUS_BUSY, but other than that, no change in > behavior, sdc remains unusable just as before. ...my guess was wrong then. Either I misunderstood the semantics of the various hostbyte codes in the command completion return (and then these semantics are insufficient) --- or SCSI mid layer or high-level implements them wrong. But before we dive into the SCSI stack or implement parellelism of SBP-2 reconnect and SCSI probing in fw-sbp2, there is another simple and in hindsight obvious trick we can try. Stay tuned. Background for LSML: In case of unrecoverable transport failures during the execution of __scsi_add_device, I would like to send appropriate error indicators from the LLD up to SCSI midlayer so that __scsi_add_device ends in failure (i.e. returns an error pointer rather than a scsi_device pointer). Sometimes SCSI core decides to let __scsi_add_device fail, sometimes it takes the scsi_device offline, sometimes it doesn't do either but pretends to the LLD that __scsi_add_device was an utter success. Except that userspace can't do anything with the scsi_device because e.g. READ CAPACITY couldn't be executed. -- 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: [PATCHSET #upstream] block/libata: update and use block layer padding and draining
Jens Axboe wrote: On Fri, Feb 08 2008, Jeff Garzik wrote: Jeff Garzik wrote: Tejun Heo wrote: This patchset updates block layer padding and draining support and make libata use it. It's based on James Bottomley's initial work and, of the five, the last two patches are from James with some modifications. Please read the following thread for more info. http://thread.gmane.org/gmane.linux.scsi/37185 This patchset is on top of upstream (a6af42fc9a12165136d82206ad52f18c5955ce87) + kill-n_iter-and-fix-fsl patch [1] ACK patchset... lets definitely get these fixes upstream. Once Jens is happy, I would prefer the merge the lot upstream, if that is OK with everyone involved? Jens, ping? It's a bug fix, so it would be nice to get this in soonish. As noted, if all looks good, I would prefer to merge via libata-dev... I'm ok with it, but lets please merge the block bits through the block repo, since they are not trivial. Wont be until the week after next, though. hmmm, rather than delaying the bug fixes for two weeks, since you're OK with it we can push upstream now, and apply further fixes if problems arise during testing? I would rather get these fixes out into wide testing sooner rather than later. 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
[PATCH 11/9 update] firewire: fw-sbp2: enforce a retry of __scsi_add_device if bus generation changed
Date:
From: Stefan Richter <[EMAIL PROTECTED]>
Subject: firewire: fw-sbp2: enforce a retry of __scsi_add_device if bus
generation changed
fw-sbp2 is unable to reconnect while performing __scsi_add_device
because there is only a single workqueue thread context available for
both at the moment. This should be fixed eventually.
An actual failure of __scsi_add_device is easy to handle, but an
incomplete execution of __scsi_add_device with an sdev returned would
remain undetected and leave the SBP-2 target unusable.
Therefore we use a workaround: If there was a bus reset during
__scsi_add_device (i.e. during the SCSI probe), we remove the new sdev
immediately, log out, and attempt login and SCSI probe again.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
The previous patch "firewire: fw-sbp2: retry login if scsi_device was
offlined early" should be folded into this one before upstream
submission.
drivers/firewire/fw-sbp2.c | 43 -
1 file changed, 19 insertions(+), 24 deletions(-)
Index: linux/drivers/firewire/fw-sbp2.c
===
--- linux.orig/drivers/firewire/fw-sbp2.c
+++ linux/drivers/firewire/fw-sbp2.c
@@ -824,36 +824,31 @@ static void sbp2_login(struct work_struc
sdev = __scsi_add_device(shost, 0, 0,
scsilun_to_int(&eight_bytes_lun), lu);
- if (IS_ERR(sdev)) {
- /*
-* The most frequent cause for __scsi_add_device() to fail
-* is a bus reset while sending the SCSI INQUIRY. Try again.
-*/
+ /*
+* FIXME: We are unable to perform reconnects while in sbp2_login().
+* Therefore __scsi_add_device() will get into trouble if a bus reset
+* happens in parallel. It will either fail or leave us with an
+* unusable sdev. As a workaround we check for this and retry the
+* whole login and SCSI probing.
+*/
+
+ if (IS_ERR(sdev))
goto out_logout_login;
- } else if (sdev->sdev_state == SDEV_OFFLINE) {
- /*
-* FIXME: We are unable to perform reconnects while in
-* sbp2_login(). Therefore __scsi_add_device() will get
-* into trouble if a bus reset happens in parallel.
-* It will either fail (that's OK, see above) or take sdev
-* offline. Here is a crude workaround for the latter.
-*/
- scsi_device_put(sdev);
+ scsi_device_put(sdev);
+
+ smp_rmb(); /* get current card generation */
+ if (generation != device->card->generation) {
scsi_remove_device(sdev);
goto out_logout_login;
-
- } else {
- /*
-* Can you believe it? Everything went well.
-*/
- lu->sdev = sdev;
- smp_wmb(); /* We need lu->sdev when we want to block lu. */
- atomic_dec(&lu->tgt->dont_block);
- scsi_device_put(sdev);
- goto out;
}
+ /* Everything went well. */
+ lu->sdev = sdev;
+ smp_wmb(); /* We need lu->sdev when we want to block lu. */
+ atomic_dec(&lu->tgt->dont_block);
+ goto out;
+
out_logout_login:
smp_rmb(); /* generation may have changed */
generation = device->generation;
--
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
[PATCH 1/1] aacraid: add optional MSI support (take 2)
Thanks for performing my compile check for me ;-}. You nailed the problem on the head. In my efforts to trim down the patch from my internal version of the driver, I neglected to pass the '#include ' chunk. Sadly, my only compile check was done against an older FC release, related to the customer request, and one should note that we removed the include line in sa.c in May last year (join_rx_rkt.patch) post that FC release only to need to reinstate it a year later with this patch. Sigh. This patch is against current scsi-misc-2.6. It has been checkpatch.pl and compile tested against today's 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 | 56 ++--- drivers/scsi/aacraid/aacraid.h |2 + drivers/scsi/aacraid/linit.c | 32 --- drivers/scsi/aacraid/rx.c |5 ++- drivers/scsi/aacraid/sa.c |5 ++- 5 files changed, 67 insertions(+), 33 deletions(-) Sincerely -- Mark Salyzyn > -Original Message- > From: James Bottomley [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 07, 2008 7:31 PM > To: Salyzyn, Mark > Cc: 'linux-scsi@vger.kernel.org' > Subject: Re: [PATCH 1/1] aacraid: add optional MSI support. > > > On Wed, 2008-02-06 at 13:20 -0800, Salyzyn, Mark wrote: > > Added support for MSI utilizing the aacraid.msi=1 > parameter. This patch adds some localized or like-minded > janitor fixes. Since the default is disabled, there is no > impact on the code paths unless the customer wishes to > experiment with the MSI performance. > > > > This patch is against current scsi-misc-2.6 > > It doesn't seem to compile: > > drivers/scsi/aacraid/sa.c: In function 'aac_sa_init': > drivers/scsi/aacraid/sa.c:388: error: dereferencing pointer > to incomplete type > drivers/scsi/aacraid/sa.c:406: error: dereferencing pointer > to incomplete type > > It looks like this can be corrected by #include > since it's > struct pci_dev that's the incomplete type. > > James > > > aacraid_msi2.patch Description: aacraid_msi2.patch
Re: [PATCH] scsi_error: Fix language abuse.
> http://www.t10.org/ftp/t10/drafts/spc3/spc3r23.pdf > > By a simple text search. > > I don't think the pedantry is worth the confusion ... Ok so we should file a formal change request with T10 instead perhaps ? Alan - 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 3/3] mpt fusion: Avoid racing when mptsas and mptcl module are loaded in parallel
On Fri, 2008-02-08 at 16:35 +0530, Prakash, Sathya wrote: > This patch sets the IOC pointer in drvrdata of pcidev before adding > the IOC into the list of IOCs. Without this patch the driver oops when > the mptsas and mptctl modules are loaded in parallel. Much better, thanks. Would I be correct in assuming that even though this email says [PATCH 3/3] there aren't two missing precursor patches? 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
[Bug 9769] CONFIG_SCSI_WAIT_SCAN configure error
http://bugzilla.kernel.org/show_bug.cgi?id=9769 --- Comment #2 from [EMAIL PROTECTED] 2008-02-08 07:01 --- Reply-To: [EMAIL PROTECTED] On Thu, 2008-02-07 at 23:28 -0800, [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9769 > > > [EMAIL PROTECTED] changed: > >What|Removed |Added > > CC||[EMAIL PROTECTED], >||[EMAIL PROTECTED] > > > > > --- Comment #1 from [EMAIL PROTECTED] 2008-02-07 23:28 --- > This appears to be a dependency, but these are not dependent defines. > CONFIG_SCSI_SCAN_ASYNC defines the default scan type, which can be overridden > by the module parameter. Yes, this is exactly right. CONFIG_SCSI_ASYNC_SCAN doesn't affect the code (async scan is always included) it affects the boot default. In either case, with the correct kernel parameters, you can boot either sync or async scanning. James -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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/6] lpfc 8.2.5 : Miscellaneous Fixes
Miscellaneous fixes:
- Fix ERRATT flag which was overlapping
- Allow RESTART mbx commands through when stopped.
- Accept incoming PLOGI when connected to an N_Port.
- Fix NPort to NPort pt2pt problems: ADISC and reg_vpi issues
- Fix vport unloading error that erroneously cleaned up RSCN buffers
- Fix memory leak during repeated unloads - in mbox handling
- Fix link bounce vs FLOGI race conditions
Signed-off-by: James Smart <[EMAIL PROTECTED]>
---
lpfc.h |4 ++--
lpfc_attr.c |8 +---
lpfc_els.c | 14 +++---
lpfc_hbadisc.c | 15 ++-
lpfc_init.c | 13 +++--
lpfc_nportdisc.c | 16 +---
lpfc_sli.c |4 +---
7 files changed, 41 insertions(+), 33 deletions(-)
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2008-02-08 18:10:08.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_attr.c 2008-02-08 18:10:59.0 -0500
@@ -1946,11 +1946,13 @@ sysfs_mbox_read(struct kobject *kobj, st
}
/* If HBA encountered an error attention, allow only DUMP
-* mailbox command until the HBA is restarted.
+* or RESTART mailbox commands until the HBA is restarted.
*/
if ((phba->pport->stopped) &&
- (phba->sysfs_mbox.mbox->mb.mbxCommand
- != MBX_DUMP_MEMORY)) {
+ (phba->sysfs_mbox.mbox->mb.mbxCommand !=
+ MBX_DUMP_MEMORY &&
+phba->sysfs_mbox.mbox->mb.mbxCommand !=
+ MBX_RESTART)) {
sysfs_mbox_idle(phba);
spin_unlock_irq(&phba->hbalock);
return -EPERM;
diff -upNr a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
--- a/drivers/scsi/lpfc/lpfc_els.c 2008-02-08 18:10:20.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_els.c 2008-02-08 18:11:36.0 -0500
@@ -2046,7 +2046,8 @@ lpfc_els_retry(struct lpfc_hba *phba, st
retry = 1;
if ((cmd == ELS_CMD_FLOGI) &&
- (phba->fc_topology != TOPOLOGY_LOOP)) {
+ (phba->fc_topology != TOPOLOGY_LOOP) &&
+ !lpfc_error_lost_link(irsp)) {
/* FLOGI retry policy */
retry = 1;
maxretry = 48;
@@ -4091,8 +4092,15 @@ lpfc_els_unsol_buffer(struct lpfc_hba *p
ndlp = lpfc_plogi_confirm_nport(phba, payload, ndlp);
if (vport->port_state < LPFC_DISC_AUTH) {
- rjt_err = LSRJT_UNABLE_TPC;
- break;
+ if (!(phba->pport->fc_flag & FC_PT2PT) ||
+ (phba->pport->fc_flag & FC_PT2PT_PLOGI)) {
+ rjt_err = LSRJT_UNABLE_TPC;
+ break;
+ }
+ /* We get here, and drop thru, if we are PT2PT with
+* another NPort and the other side has initiated
+* the PLOGI before responding to our FLOGI.
+*/
}
shost = lpfc_shost_from_vport(vport);
diff -upNr a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
--- a/drivers/scsi/lpfc/lpfc.h 2008-02-08 18:10:08.0 -0500
+++ b/drivers/scsi/lpfc/lpfc.h 2008-02-08 18:10:53.0 -0500
@@ -1,7 +1,7 @@
/***
* This file is part of the Emulex Linux Device Driver for *
* Fibre Channel Host Bus Adapters.*
- * Copyright (C) 2004-2007 Emulex. All rights reserved. *
+ * Copyright (C) 2004-2008 Emulex. All rights reserved. *
* EMULEX and SLI are trademarks of Emulex.*
* www.emulex.com *
* Portions Copyright (C) 2004-2005 Christoph Hellwig *
@@ -409,7 +409,7 @@ struct lpfc_hba {
/* This flag is set while issuing */
/* INIT_LINK mailbox command */
#define LS_NPIV_FAB_SUPPORTED 0x2 /* Fabric supports NPIV */
-#define LS_IGNORE_ERATT 0x3 /* intr handler should ignore ERATT */
+#define LS_IGNORE_ERATT 0x4 /* intr handler should ignore ERATT */
struct lpfc_sli2_slim *slim2p;
struct lpfc_dmabuf hbqslimp;
diff -upNr a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c 2008-02-08 18:10:08.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c 2008-02-08 18:11:26.0 -0500
@@ -800,21 +800,9 @@ lpfc_mbx_cmpl_clear_la(struct lpfc_hba *
writel(control, phba->HCregaddr);
readl(phba->HCregaddr); /* flush */
spin_unlock_irq(&phba->hbalock)
[PATCH 3/6] lpfc 8.2.5 : Add MSI-X single message support
Add MSI-X single message support
Signed-off-by: James Smart <[EMAIL PROTECTED]>
---
lpfc.h | 10 +-
lpfc_attr.c |6 ++-
lpfc_init.c | 97
3 files changed, 91 insertions(+), 22 deletions(-)
diff -upNr a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
--- a/drivers/scsi/lpfc/lpfc_attr.c 2008-02-08 18:10:59.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_attr.c 2008-02-08 18:12:03.0 -0500
@@ -1592,9 +1592,11 @@ LPFC_ATTR_RW(poll_tmo, 10, 1, 255,
# support this feature
# 0 = MSI disabled (default)
# 1 = MSI enabled
-# Value range is [0,1]. Default value is 0.
+# 2 = MSI-X enabled
+# Value range is [0,2]. Default value is 0.
*/
-LPFC_ATTR_R(use_msi, 0, 0, 1, "Use Message Signaled Interrupts, if possible");
+LPFC_ATTR_R(use_msi, 0, 0, 2, "Use Message Signaled Interrupts (1) or "
+ "MSI-X (2), if possible");
/*
# lpfc_enable_hba_reset: Allow or prevent HBA resets to the hardware.
diff -upNr a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
--- a/drivers/scsi/lpfc/lpfc.h 2008-02-08 18:10:53.0 -0500
+++ b/drivers/scsi/lpfc/lpfc.h 2008-02-08 18:12:03.0 -0500
@@ -392,6 +392,13 @@ enum hba_temp_state {
HBA_OVER_TEMP
};
+enum intr_type_t {
+ NONE = 0,
+ INTx,
+ MSI,
+ MSIX,
+};
+
struct lpfc_hba {
struct lpfc_sli sli;
uint32_t sli_rev; /* SLI2 or SLI3 */
@@ -555,7 +562,8 @@ struct lpfc_hba {
mempool_t *nlp_mem_pool;
struct fc_host_statistics link_stats;
- uint8_t using_msi;
+ enum intr_type_t intr_type;
+ struct msix_entry msix_entries[1];
struct list_head port_list;
struct lpfc_vport *pport; /* physical lpfc_vport pointer */
diff -upNr a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
--- a/drivers/scsi/lpfc/lpfc_init.c 2008-02-08 18:11:20.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_init.c 2008-02-08 18:12:03.0 -0500
@@ -1924,6 +1924,42 @@ void lpfc_host_attrib_init(struct Scsi_H
spin_unlock_irq(shost->host_lock);
}
+static int
+lpfc_enable_msix(struct lpfc_hba *phba)
+{
+ int error;
+
+ phba->msix_entries[0].entry = 0;
+ phba->msix_entries[0].vector = 0;
+
+ error = pci_enable_msix(phba->pcidev, phba->msix_entries,
+ ARRAY_SIZE(phba->msix_entries));
+ if (error) {
+ lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
+ "0420 Enable MSI-X failed (%d), continuing "
+ "with MSI\n", error);
+ pci_disable_msix(phba->pcidev);
+ return error;
+ }
+
+ error = request_irq(phba->msix_entries[0].vector, lpfc_intr_handler, 0,
+ LPFC_DRIVER_NAME, phba);
+ if (error) {
+ lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
+ "0421 MSI-X request_irq failed (%d), "
+ "continuing with MSI\n", error);
+ pci_disable_msix(phba->pcidev);
+ }
+ return error;
+}
+
+static void
+lpfc_disable_msix(struct lpfc_hba *phba)
+{
+ free_irq(phba->msix_entries[0].vector, phba);
+ pci_disable_msix(phba->pcidev);
+}
+
static int __devinit
lpfc_pci_probe_one(struct pci_dev *pdev, const struct pci_device_id *pid)
{
@@ -2125,24 +2161,36 @@ lpfc_pci_probe_one(struct pci_dev *pdev,
lpfc_debugfs_initialize(vport);
pci_set_drvdata(pdev, shost);
+ phba->intr_type = NONE;
+
+ if (phba->cfg_use_msi == 2) {
+ error = lpfc_enable_msix(phba);
+ if (!error)
+ phba->intr_type = MSIX;
+ }
- if (phba->cfg_use_msi) {
+ /* Fallback to MSI if MSI-X initialization failed */
+ if (phba->cfg_use_msi >= 1 && phba->intr_type == NONE) {
retval = pci_enable_msi(phba->pcidev);
if (!retval)
- phba->using_msi = 1;
+ phba->intr_type = MSI;
else
lpfc_printf_log(phba, KERN_INFO, LOG_INIT,
"0452 Enable MSI failed, continuing "
"with IRQ\n");
}
- retval = request_irq(phba->pcidev->irq, lpfc_intr_handler, IRQF_SHARED,
- LPFC_DRIVER_NAME, phba);
- if (retval) {
- lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
- "0451 Enable interrupt handler failed\n");
- error = retval;
- goto out_disable_msi;
+ /* MSI-X is the only case the doesn't need to call request_irq */
+ if (phba->intr_type != MSIX) {
+ retval = request_irq(phba->pcidev->irq, lpfc_intr_handler,
+IRQF_SHARED, LPFC_DRIVER_NA
[PATCH 4/6] lpfc 8.2.5 : Miscellaneous discovery Fixes
Miscellaneous discovery fixes:
- Flush RSCN buffers on vports when reseting HBA.
- Fix incorrect FLOGI after vport reg failed
- Fix a potential fabric ELS race condition
- Fix handling of failed PLOGI command under high lip rates
- Fix FDISC handling
- Fix debug logging for npiv handling
Signed-off-by: James Smart <[EMAIL PROTECTED]>
---
lpfc.h|1
lpfc_ct.c |2
lpfc_disc.h | 33 +++---
lpfc_els.c| 133 --
lpfc_hw.h |1
lpfc_init.c |5 +-
lpfc_logmsg.h | 10 +++-
lpfc_mem.c|4 +
lpfc_sli.c|4 -
9 files changed, 127 insertions(+), 66 deletions(-)
diff -upNr a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
--- a/drivers/scsi/lpfc/lpfc_ct.c 2008-02-08 18:10:08.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_ct.c 2008-02-08 18:13:15.0 -0500
@@ -775,7 +775,7 @@ lpfc_cmpl_ct_cmd_gff_id(struct lpfc_hba
"0267 NameServer GFF Rsp "
"x%x Error (%d %d) Data: x%x x%x\n",
did, irsp->ulpStatus, irsp->un.ulpWord[4],
-vport->fc_flag, vport->fc_rscn_id_cnt)
+vport->fc_flag, vport->fc_rscn_id_cnt);
}
/* This is a target port, unregistered port, or the GFF_ID failed */
diff -upNr a/drivers/scsi/lpfc/lpfc_disc.h b/drivers/scsi/lpfc/lpfc_disc.h
--- a/drivers/scsi/lpfc/lpfc_disc.h 2008-02-08 18:10:08.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_disc.h 2008-02-08 18:12:46.0 -0500
@@ -91,25 +91,26 @@ struct lpfc_nodelist {
};
/* Defines for nlp_flag (uint32) */
-#define NLP_PLOGI_SND 0x20/* sent PLOGI request for this
entry */
-#define NLP_PRLI_SND 0x40/* sent PRLI request for this
entry */
-#define NLP_ADISC_SND 0x80/* sent ADISC request for this
entry */
-#define NLP_LOGO_SND 0x100 /* sent LOGO request for this entry */
-#define NLP_RNID_SND 0x400 /* sent RNID request for this entry */
-#define NLP_ELS_SND_MASK 0x7e0 /* sent ELS request for this entry */
-#define NLP_DEFER_RM 0x1 /* Remove this ndlp if no longer used */
-#define NLP_DELAY_TMO 0x2 /* delay timeout is running for node */
-#define NLP_NPR_2B_DISC0x4 /* node is included in num_disc_nodes */
-#define NLP_RCV_PLOGI 0x8 /* Rcv'ed PLOGI from remote system */
-#define NLP_LOGO_ACC 0x10/* Process LOGO after ACC completes */
-#define NLP_TGT_NO_SCSIID 0x20/* good PRLI but no binding for scsid */
-#define NLP_ACC_REGLOGIN 0x100 /* Issue Reg Login after successful
+#define NLP_PLOGI_SND 0x0020 /* sent PLOGI request for this entry */
+#define NLP_PRLI_SND 0x0040 /* sent PRLI request for this entry */
+#define NLP_ADISC_SND 0x0080 /* sent ADISC request for this entry */
+#define NLP_LOGO_SND 0x0100 /* sent LOGO request for this entry */
+#define NLP_RNID_SND 0x0400 /* sent RNID request for this entry */
+#define NLP_ELS_SND_MASK 0x07e0 /* sent ELS request for this entry */
+#define NLP_DEFER_RM 0x0001 /* Remove this ndlp if no longer used */
+#define NLP_DELAY_TMO 0x0002 /* delay timeout is running for node */
+#define NLP_NPR_2B_DISC0x0004 /* node is included in num_disc_nodes */
+#define NLP_RCV_PLOGI 0x0008 /* Rcv'ed PLOGI from remote system */
+#define NLP_LOGO_ACC 0x0010 /* Process LOGO after ACC completes */
+#define NLP_TGT_NO_SCSIID 0x0020 /* good PRLI but no binding for scsid */
+#define NLP_ACC_REGLOGIN 0x0100 /* Issue Reg Login after successful
ACC */
-#define NLP_NPR_ADISC 0x200 /* Issue ADISC when dq'ed from
+#define NLP_NPR_ADISC 0x0200 /* Issue ADISC when dq'ed from
NPR list */
-#define NLP_RM_DFLT_RPI0x400 /* need to remove leftover dflt RPI */
-#define NLP_NODEV_REMOVE 0x800 /* Defer removal till discovery ends */
+#define NLP_RM_DFLT_RPI0x0400 /* need to remove leftover dflt RPI */
+#define NLP_NODEV_REMOVE 0x0800 /* Defer removal till discovery ends */
#define NLP_TARGET_REMOVE 0x1000 /* Target remove in process */
+#define NLP_SC_REQ 0x2000 /* Target requires authentication */
/* ndlp usage management macros */
#define NLP_CHK_NODE_ACT(ndlp) (((ndlp)->nlp_usg_map \
diff -upNr a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
--- a/drivers/scsi/lpfc/lpfc_els.c 2008-02-08 18:11:36.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_els.c 2008-02-08 18:13:04.0 -0500
@@ -1920,18 +1920,15 @@ lpfc_els_retry(struct lpfc_hba *phba, st
break;
case IOERR_ILLEGAL_COMMAND:
[PATCH 5/6] lpfc 8.2.5 : Fix buffer leaks
Fix buffer leaks:
- HBQ dma buffer leak at dma_pool_destroy when unloading driver
- Fix missing buffer free in slow ring buffer handling
Signed-off-by: James Smart <[EMAIL PROTECTED]>
---
lpfc.h |2 +
lpfc_hbadisc.c | 17 +++--
lpfc_hw.h | 17 +
lpfc_init.c|2 +
lpfc_mem.c |9 +
lpfc_sli.c | 97 +++--
6 files changed, 137 insertions(+), 7 deletions(-)
diff -upNr a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
--- a/drivers/scsi/lpfc/lpfc.h 2008-02-08 18:12:31.0 -0500
+++ b/drivers/scsi/lpfc/lpfc.h 2008-02-08 18:13:41.0 -0500
@@ -495,6 +495,8 @@ struct lpfc_hba {
wait_queue_head_t*work_wait;
struct task_struct *worker_thread;
+ uint32_t hbq_in_use;/* HBQs in use flag */
+ struct list_head hbqbuf_in_list; /* in-fly hbq buffer list */
uint32_t hbq_count; /* Count of configured HBQs */
struct hbq_s hbqs[LPFC_MAX_HBQS]; /* local copy of hbq indicies */
diff -upNr a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c 2008-02-08 18:11:26.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c 2008-02-08 18:13:50.0 -0500
@@ -629,9 +629,8 @@ lpfc_linkdown(struct lpfc_hba *phba)
LPFC_MBOXQ_t *mb;
int i;
- if (phba->link_state == LPFC_LINK_DOWN) {
+ if (phba->link_state == LPFC_LINK_DOWN)
return 0;
- }
spin_lock_irq(&phba->hbalock);
if (phba->link_state > LPFC_LINK_DOWN) {
phba->link_state = LPFC_LINK_DOWN;
@@ -1122,7 +1121,7 @@ lpfc_mbx_cmpl_read_la(struct lpfc_hba *p
if (la->attType == AT_LINK_UP) {
phba->fc_stat.LinkUp++;
if (phba->link_flag & LS_LOOPBACK_MODE) {
- lpfc_printf_log(phba, KERN_INFO, LOG_LINK_EVENT,
+ lpfc_printf_log(phba, KERN_ERR, LOG_LINK_EVENT,
"1306 Link Up Event in loop back mode "
"x%x received Data: x%x x%x x%x x%x\n",
la->eventTag, phba->fc_eventTag,
@@ -1139,11 +1138,21 @@ lpfc_mbx_cmpl_read_la(struct lpfc_hba *p
lpfc_mbx_process_link_up(phba, la);
} else {
phba->fc_stat.LinkDown++;
- lpfc_printf_log(phba, KERN_ERR, LOG_LINK_EVENT,
+ if (phba->link_flag & LS_LOOPBACK_MODE) {
+ lpfc_printf_log(phba, KERN_ERR, LOG_LINK_EVENT,
+ "1308 Link Down Event in loop back mode "
+ "x%x received "
+ "Data: x%x x%x x%x\n",
+ la->eventTag, phba->fc_eventTag,
+ phba->pport->port_state, vport->fc_flag);
+ }
+ else {
+ lpfc_printf_log(phba, KERN_ERR, LOG_LINK_EVENT,
"1305 Link Down Event x%x received "
"Data: x%x x%x x%x\n",
la->eventTag, phba->fc_eventTag,
phba->pport->port_state, vport->fc_flag);
+ }
lpfc_mbx_issue_link_down(phba);
}
diff -upNr a/drivers/scsi/lpfc/lpfc_hw.h b/drivers/scsi/lpfc/lpfc_hw.h
--- a/drivers/scsi/lpfc/lpfc_hw.h 2008-02-08 18:13:04.0 -0500
+++ b/drivers/scsi/lpfc/lpfc_hw.h 2008-02-08 18:13:50.0 -0500
@@ -1,7 +1,7 @@
/***
* This file is part of the Emulex Linux Device Driver for *
* Fibre Channel Host Bus Adapters.*
- * Copyright (C) 2004-2007 Emulex. All rights reserved. *
+ * Copyright (C) 2004-2008 Emulex. All rights reserved. *
* EMULEX and SLI are trademarks of Emulex.*
* www.emulex.com *
* *
@@ -1377,11 +1377,26 @@ typedef struct {/* FireFly BIU registe
#define CMD_QUE_XRI64_CX 0xB3
#define CMD_IOCB_RCV_SEQ64_CX 0xB5
#define CMD_IOCB_RCV_ELS64_CX 0xB7
+#define CMD_IOCB_RET_XRI64_CX 0xB9
#define CMD_IOCB_RCV_CONT64_CX 0xBB
#define CMD_GEN_REQUEST64_CR0xC2
#define CMD_GEN_REQUEST64_CX0xC3
+/* Unhandled SLI-3 Commands */
+#define CMD_IOCB_XMIT_MSEQ64_CR0xB0
+#define CMD_IOCB_XMIT_MSEQ64_CX0xB1
+#define CMD_IOCB_RCV_SEQ_LIST64_CX 0xC1
+#define CMD_IOCB_RCV_ELS_LIST64_CX 0xCD
+#define CMD_IOCB_CLOSE_EXTENDED_CN 0xB6
+#define CMD_IOCB_ABORT_EXTENDED_CN 0xBA
+#define CMD_IOCB_RET_HBQE64_CN 0xCA
+#define CMD_IOCB_FCP_IBIDIR64_CR 0xAC
+#define CMD_IOCB_FCP_IBIDIR
[PATCH 6/6] lpfc 8.2.5 : Update lpfc driver version to 8.2.5
Update lpfc driver version to 8.2.5 Signed-off-by: James Smart <[EMAIL PROTECTED]> --- lpfc_version.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -upNr a/drivers/scsi/lpfc/lpfc_version.h b/drivers/scsi/lpfc/lpfc_version.h --- a/drivers/scsi/lpfc/lpfc_version.h 2008-01-14 13:06:49.0 -0500 +++ b/drivers/scsi/lpfc/lpfc_version.h 2008-02-08 18:14:14.0 -0500 @@ -18,7 +18,7 @@ * included with this package. * ***/ -#define LPFC_DRIVER_VERSION "8.2.4" +#define LPFC_DRIVER_VERSION "8.2.5" #define LPFC_DRIVER_NAME "lpfc" - 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: Integration of SCST in the mainstream Linux kernel
Nicholas A. Bellinger wrote: - It has been discussed which iSCSI target implementation should be in the mainstream Linux kernel. There is no agreement on this subject yet. The short-term options are as follows: 1) Do not integrate any new iSCSI target implementation in the mainstream Linux kernel. 2) Add one of the existing in-kernel iSCSI target implementations to the kernel, e.g. SCST or PyX/LIO. 3) Create a new in-kernel iSCSI target implementation that combines the advantages of the existing iSCSI kernel target implementations (iETD, STGT, SCST and PyX/LIO). As an iSCSI user, I prefer option (3). The big question is whether the various storage target authors agree with this ? I tend to agree with some important notes: 1. IET should be excluded from this list, iSCSI-SCST is IET updated for SCST framework with a lot of bugfixes and improvements. 2. I think, everybody will agree that Linux iSCSI target should work over some standard SCSI target framework. Hence the choice gets narrower: SCST vs STGT. I don't think there's a way for a dedicated iSCSI target (i.e. PyX/LIO) in the mainline, because of a lot of code duplication. Nicholas could decide to move to either existing framework (although, frankly, I don't think there's a possibility for in-kernel iSCSI target and user space SCSI target framework) and if he decide to go with SCST, I'll be glad to offer my help and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. The better one should win. why should linux as an iSCSI target be limited to passthrough to a SCSI device. I don't think anyone is saying it should be. It makes sense that the more mature SCSI engines that have working code will be providing alot of the foundation as we talk about options.. From comparing the designs of SCST and LIO-SE, we know that SCST has supports very SCSI specific target mode hardware, including software target mode forks of other kernel code. This code for the target mode pSCSI, FC and SAS control paths (more for the state machines, that CDB emulation) that will most likely never need to be emulated on non SCSI target engine. ...but required for SCSI. So, it must be, anyway. SCST has support for the most SCSI fabric protocols of the group (although it is lacking iSER) while the LIO-SE only supports traditional iSCSI using Linux/IP (this means TCP, SCTP and IPv6). The design of LIO-SE was to make every iSCSI initiator that sends SCSI CDBs and data to talk to every potential device in the Linux storage stack on the largest amount of hardware architectures possible. Most of the iSCSI Initiators I know (including non Linux) do not rely on heavy SCSI task management, and I think this would be a lower priority item to get real SCSI specific recovery in the traditional iSCSI target for users. Espically things like SCSI target mode queue locking (affectionally called Auto Contingent Allegiance) make no sense for traditional iSCSI or iSER, because CmdSN rules are doing this for us. Sorry, it isn't correct. ACA provides possibility to lock commands queue in case of CHECK CONDITION, so allows to keep commands execution order in case of errors. CmdSN keeps commands execution order only in case of success, in case of error the next queued command will be executed immediately after the failed one, although application might require to have all subsequent after the failed one commands aborted. Think about journaled file systems, for instance. Also ACA allows to retry the failed command and then resume the queue. Vlad - 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 0/6] lpfc 8.2.5 : lpfc 8.2.5 patches
lpfc driver updates for revision 8.2.5. Patches based on scsi-misc-2.6 Changes include: - Correct ndlp referencing issues - Miscellaneous fixes - Add MSI-X single message support - Miscellaneous discovery fixes: - Fix buffer leaks: - Update lpfc driver version to 8.2.5 -- james 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: Integration of SCST in the mainstream Linux kernel
On Fri, 2008-02-08 at 17:36 +0300, Vladislav Bolkhovitin wrote: > Nicholas A. Bellinger wrote: > - It has been discussed which iSCSI target implementation should be in > the mainstream Linux kernel. There is no agreement on this subject > yet. The short-term options are as follows: > 1) Do not integrate any new iSCSI target implementation in the > mainstream Linux kernel. > 2) Add one of the existing in-kernel iSCSI target implementations to > the kernel, e.g. SCST or PyX/LIO. > 3) Create a new in-kernel iSCSI target implementation that combines > the advantages of the existing iSCSI kernel target implementations > (iETD, STGT, SCST and PyX/LIO). > > As an iSCSI user, I prefer option (3). The big question is whether the > various storage target authors agree with this ? > >>> > >>>I tend to agree with some important notes: > >>> > >>>1. IET should be excluded from this list, iSCSI-SCST is IET updated for > >>>SCST > >>>framework with a lot of bugfixes and improvements. > >>> > >>>2. I think, everybody will agree that Linux iSCSI target should work over > >>>some standard SCSI target framework. Hence the choice gets narrower: SCST > >>>vs > >>>STGT. I don't think there's a way for a dedicated iSCSI target (i.e. > >>>PyX/LIO) > >>>in the mainline, because of a lot of code duplication. Nicholas could > >>>decide > >>>to move to either existing framework (although, frankly, I don't think > >>>there's a possibility for in-kernel iSCSI target and user space SCSI > >>>target > >>>framework) and if he decide to go with SCST, I'll be glad to offer my help > >>>and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. > >>>The > >>>better one should win. > >> > >>why should linux as an iSCSI target be limited to passthrough to a SCSI > >>device. > > > > > > > > I don't think anyone is saying it should be. It makes sense that the > > more mature SCSI engines that have working code will be providing alot > > of the foundation as we talk about options.. > > > >>From comparing the designs of SCST and LIO-SE, we know that SCST has > > supports very SCSI specific target mode hardware, including software > > target mode forks of other kernel code. This code for the target mode > > pSCSI, FC and SAS control paths (more for the state machines, that CDB > > emulation) that will most likely never need to be emulated on non SCSI > > target engine. > > ...but required for SCSI. So, it must be, anyway. > > > SCST has support for the most SCSI fabric protocols of > > the group (although it is lacking iSER) while the LIO-SE only supports > > traditional iSCSI using Linux/IP (this means TCP, SCTP and IPv6). The > > design of LIO-SE was to make every iSCSI initiator that sends SCSI CDBs > > and data to talk to every potential device in the Linux storage stack on > > the largest amount of hardware architectures possible. > > > > Most of the iSCSI Initiators I know (including non Linux) do not rely on > > heavy SCSI task management, and I think this would be a lower priority > > item to get real SCSI specific recovery in the traditional iSCSI target > > for users. Espically things like SCSI target mode queue locking > > (affectionally called Auto Contingent Allegiance) make no sense for > > traditional iSCSI or iSER, because CmdSN rules are doing this for us. > > Sorry, it isn't correct. ACA provides possibility to lock commands queue > in case of CHECK CONDITION, so allows to keep commands execution order > in case of errors. CmdSN keeps commands execution order only in case of > success, in case of error the next queued command will be executed > immediately after the failed one, although application might require to > have all subsequent after the failed one commands aborted. Think about > journaled file systems, for instance. Also ACA allows to retry the > failed command and then resume the queue. > Fair enough. The point I was making is that I have never actually seen an iSCSI Initiator use ACA functionality (I don't believe that the Linux SCSI Ml implements this), or actually generate a CLEAR_ACA task management request. --nab > Vlad > - 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
scsi/arm/fas216.c compile error
Commit 30b0c37b27485a9cb897bfe3824f6f517b8c80d6 causes the following compile error: <-- snip --> ... CC drivers/scsi/arm/fas216.o /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/arm/fas216.c: In function 'fas216_std_done': /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/arm/fas216.c:2120: error: 'struct scsi_cmnd' has no member named 'request_bufflen' /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/scsi/arm/fas216.c:2122: error: 'struct scsi_cmnd' has no member named 'use_sg' make[4]: *** [drivers/scsi/arm/fas216.o] Error 1 <-- snip --> cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: Integration of SCST in the mainstream Linux kernel
On Fri, 2008-02-08 at 17:42 +0300, Vladislav Bolkhovitin wrote: > Nicholas A. Bellinger wrote: > > On Thu, 2008-02-07 at 12:37 -0800, Luben Tuikov wrote: > > > >>Is there an open iSCSI Target implementation which does NOT > >>issue commands to sub-target devices via the SCSI mid-layer, but > >>bypasses it completely? > >> > >> Luben > >> > > > > > > Hi Luben, > > > > I am guessing you mean futher down the stack, which I don't know this to > > be the case. Going futher up the layers is the design of v2.9 LIO-SE. > > There is a diagram explaining the basic concepts from a 10,000 foot > > level. > > > > http://linux-iscsi.org/builds/user/nab/storage-engine-concept.pdf > > > > Note that only traditional iSCSI target is currently implemented in v2.9 > > LIO-SE codebase in the list of target mode fabrics on left side of the > > layout. The API between the protocol headers that does > > encoding/decoding target mode storage packets is probably the least > > mature area of the LIO stack (because it has always been iSCSI looking > > towards iSER :). I don't know who has the most mature API between the > > storage engine and target storage protocol for doing this between SCST > > and STGT, I am guessing SCST because of the difference in age of the > > projects. Could someone be so kind to fill me in on this..? > > SCST uses scsi_execute_async_fifo() function to submit commands to SCSI > devices in the pass-through mode. This function is slightly modified > version of scsi_execute_async(), which submits requests in FIFO order > instead of LIFO as scsi_execute_async() does (so with > scsi_execute_async() they are executed in the reverse order). > Scsi_execute_async_fifo() added as a separate patch to the kernel. The LIO-SE PSCSI Plugin also depends on scsi_execute_async() for builds on >= 2.6.18. Note in the core LIO storage engine code (would be iscsi_target_transport.c), there is no subsystem dependence logic. The LIO-SE API is what allows the SE plugins to remain simple and small: -rw-r--r-- 1 root root 35008 2008-02-02 03:25 iscsi_target_pscsi.c -rw-r--r-- 1 root root 7537 2008-02-02 17:27 iscsi_target_pscsi.h -rw-r--r-- 1 root root 18269 2008-02-04 02:23 iscsi_target_iblock.c -rw-r--r-- 1 root root 6834 2008-02-04 02:25 iscsi_target_iblock.h -rw-r--r-- 1 root root 30611 2008-02-02 03:25 iscsi_target_file.c -rw-r--r-- 1 root root 7833 2008-02-02 17:27 iscsi_target_file.h -rw-r--r-- 1 root root 35154 2008-02-02 04:01 iscsi_target_rd.c -rw-r--r-- 1 root root 9900 2008-02-02 17:27 iscsi_target_rd.h It also means that the core LIO-SE code does not have to change when the subsystem APIs change. This has been important in the past for the project, but for upstream code, probably would not make a huge difference. --nab - 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: [PATCHSET #upstream] block/libata: update and use block layer padding and draining
Jeff Garzik wrote: > Jens Axboe wrote: >> On Fri, Feb 08 2008, Jeff Garzik wrote: >>> Jeff Garzik wrote: Tejun Heo wrote: > This patchset updates block layer padding and draining support and > make libata use it. It's based on James Bottomley's initial work and, > of the five, the last two patches are from James with some > modifications. > > Please read the following thread for more info. > > http://thread.gmane.org/gmane.linux.scsi/37185 > > This patchset is on top of > > upstream (a6af42fc9a12165136d82206ad52f18c5955ce87) > + kill-n_iter-and-fix-fsl patch [1] ACK patchset... lets definitely get these fixes upstream. Once Jens is happy, I would prefer the merge the lot upstream, if that is OK with everyone involved? >>> Jens, ping? >>> >>> It's a bug fix, so it would be nice to get this in soonish. As >>> noted, if all looks good, I would prefer to merge via libata-dev... >> >> I'm ok with it, but lets please merge the block bits through the block >> repo, since they are not trivial. Wont be until the week after next, >> though. > > hmmm, rather than delaying the bug fixes for two weeks, since you're OK > with it we can push upstream now, and apply further fixes if problems > arise during testing? > > I would rather get these fixes out into wide testing sooner rather than > later. I have an updated version. Please standby a bit. Thanks. -- tejun - 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 6/7] libata: eliminate the home grown dma padding in favour of that provided by the block layer
From: James Bottomley <[EMAIL PROTECTED]>
ATA requires that all DMA transfers begin and end on word boundaries.
Because of this, a large amount of machinery grew up in ide to adjust
scatterlists on this basis. However, as of 2.5, the block layer has a
dma_alignment variable which ensures both the beginning and length of a
DMA transfer are aligned on the dma_alignment boundary. Although the
block layer does adjust the beginning of the transfer to ensure this
happens, it doesn't actually adjust the length, it merely makes sure
that space is allocated for transfers beyond the declared length. The
upshot of this is that scatterlists may be padded to any size between
the actual length and the length adjusted to the dma_alignment safely
knowing that memory is allocated in this region.
Right at the moment, SCSI takes the default dma_aligment which is on a
512 byte boundary. Note that this aligment only applies to transfers
coming in from user space. However, since all kernel allocations are
automatically aligned on a minimum of 32 byte boundaries, it is safe to
adjust them in this manner as well.
tj: * Adjusting sg after padding is done in block layer. Make libata
set queue alignment correctly for ATAPI devices and drop broken
sg mangling from ata_sg_setup().
* Use request->raw_data_len for ATAPI transfer chunk size.
* Killed qc->raw_nbytes.
* Separated out killing qc->n_iter.
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/ahci.c|5 --
drivers/ata/libata-core.c | 145 +++--
drivers/ata/libata-scsi.c | 23 ++-
drivers/ata/pata_icside.c |8 --
drivers/ata/sata_fsl.c| 13
drivers/ata/sata_mv.c |6 +--
drivers/ata/sata_sil24.c |5 --
drivers/scsi/ipr.c|4 +-
drivers/scsi/libsas/sas_ata.c |4 +-
include/linux/libata.h| 28 +
10 files changed, 21 insertions(+), 220 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 29e71bd..3c06e45 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1975,16 +1975,11 @@ static int ahci_port_start(struct ata_port *ap)
struct ahci_port_priv *pp;
void *mem;
dma_addr_t mem_dma;
- int rc;
pp = devm_kzalloc(dev, sizeof(*pp), GFP_KERNEL);
if (!pp)
return -ENOMEM;
- rc = ata_pad_alloc(ap, dev);
- if (rc)
- return rc;
-
mem = dmam_alloc_coherent(dev, AHCI_PORT_PRIV_DMA_SZ, &mem_dma,
GFP_KERNEL);
if (!mem)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index ecb8275..d49b271 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4474,30 +4474,13 @@ void ata_sg_clean(struct ata_queued_cmd *qc)
struct ata_port *ap = qc->ap;
struct scatterlist *sg = qc->sg;
int dir = qc->dma_dir;
- void *pad_buf = NULL;
WARN_ON(sg == NULL);
- VPRINTK("unmapping %u sg elements\n", qc->mapped_n_elem);
+ VPRINTK("unmapping %u sg elements\n", qc->n_elem);
- /* if we padded the buffer out to 32-bit bound, and data
-* xfer direction is from-device, we must copy from the
-* pad buffer back into the supplied buffer
-*/
- if (qc->pad_len && !(qc->tf.flags & ATA_TFLAG_WRITE))
- pad_buf = ap->pad + (qc->tag * ATA_DMA_PAD_SZ);
-
- if (qc->mapped_n_elem)
- dma_unmap_sg(ap->dev, sg, qc->mapped_n_elem, dir);
- /* restore last sg */
- if (qc->last_sg)
- *qc->last_sg = qc->saved_last_sg;
- if (pad_buf) {
- struct scatterlist *psg = &qc->extra_sg[1];
- void *addr = kmap_atomic(sg_page(psg), KM_IRQ0);
- memcpy(addr + psg->offset, pad_buf, qc->pad_len);
- kunmap_atomic(addr, KM_IRQ0);
- }
+ if (qc->n_elem)
+ dma_unmap_sg(ap->dev, sg, qc->n_elem, dir);
qc->flags &= ~ATA_QCFLAG_DMAMAP;
qc->sg = NULL;
@@ -4748,97 +4731,6 @@ void ata_sg_init(struct ata_queued_cmd *qc, struct
scatterlist *sg,
qc->cursg = qc->sg;
}
-static unsigned int ata_sg_setup_extra(struct ata_queued_cmd *qc,
- unsigned int *n_elem_extra,
- unsigned int *nbytes_extra)
-{
- struct ata_port *ap = qc->ap;
- unsigned int n_elem = qc->n_elem;
- struct scatterlist *lsg, *copy_lsg = NULL, *tsg = NULL, *esg = NULL;
-
- *n_elem_extra = 0;
- *nbytes_extra = 0;
-
- /* needs padding? */
- qc->pad_len = qc->nbytes & 3;
-
- if (likely(!qc->pad_len))
- return n_elem;
-
- /* locate last sg and save it */
- lsg = sg_last(qc->sg, n_elem);
- qc->last_sg = lsg;
- qc->saved_last_sg = *lsg;
-
- sg_init_table(qc
[PATCH 1/7] libata: update ATAPI overflow draining
For misc ATAPI commands which transfer variable length data to the
host, overflow can occur due to application or hardware bug. Such
overflows can be ignored safely as long as overflow data is properly
drained. libata HSM implementation has this implemented in
__atapi_pio_bytes() and recently updated for 2.6.24-rc but it requires
further improvements. Improve drain logic such that...
* Report overflow errors using ehi desc mechanism instead of printing
directly.
* Properly calculate the number of bytes to be drained considering
actual number of consumed bytes for partial draining.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Acked-by: Albert Lee <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 76 +++-
1 files changed, 33 insertions(+), 43 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 3011919..ecb8275 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4656,24 +4656,9 @@ int ata_check_atapi_dma(struct ata_queued_cmd *qc)
*/
static int atapi_qc_may_overflow(struct ata_queued_cmd *qc)
{
- if (qc->tf.protocol != ATAPI_PROT_PIO &&
- qc->tf.protocol != ATAPI_PROT_DMA)
- return 0;
-
- if (qc->tf.flags & ATA_TFLAG_WRITE)
- return 0;
-
- switch (qc->cdb[0]) {
- case READ_10:
- case READ_12:
- case WRITE_10:
- case WRITE_12:
- case GPCMD_READ_CD:
- case GPCMD_READ_CD_MSF:
- return 0;
- }
-
- return 1;
+ return ata_is_atapi(qc->tf.protocol) && ata_is_data(qc->tf.protocol) &&
+ atapi_cmd_type(qc->cdb[0]) == ATAPI_MISC &&
+ !(qc->tf.flags & ATA_TFLAG_WRITE);
}
/**
@@ -5127,13 +5112,14 @@ static void atapi_send_cdb(struct ata_port *ap, struct
ata_queued_cmd *qc)
*/
static int __atapi_pio_bytes(struct ata_queued_cmd *qc, unsigned int bytes)
{
- int do_write = (qc->tf.flags & ATA_TFLAG_WRITE);
+ int rw = (qc->tf.flags & ATA_TFLAG_WRITE) ? WRITE : READ;
struct ata_port *ap = qc->ap;
- struct ata_eh_info *ehi = &qc->dev->link->eh_info;
+ struct ata_device *dev = qc->dev;
+ struct ata_eh_info *ehi = &dev->link->eh_info;
struct scatterlist *sg;
struct page *page;
unsigned char *buf;
- unsigned int offset, count;
+ unsigned int offset, count, consumed;
next_sg:
sg = qc->cursg;
@@ -5146,26 +5132,27 @@ next_sg:
*- for write case, padding zero data to the device
*/
u16 pad_buf[1] = { 0 };
- unsigned int i;
- if (bytes > qc->curbytes - qc->nbytes + ATAPI_MAX_DRAIN) {
+ if (qc->curbytes + bytes > qc->nbytes + ATAPI_MAX_DRAIN) {
ata_ehi_push_desc(ehi, "too much trailing data "
"buf=%u cur=%u bytes=%u",
qc->nbytes, qc->curbytes, bytes);
return -1;
}
-/* overflow is exptected for misc ATAPI commands */
- if (bytes && !atapi_qc_may_overflow(qc))
- ata_dev_printk(qc->dev, KERN_WARNING, "ATAPI %u bytes "
- "trailing data (cdb=%02x nbytes=%u)\n",
- bytes, qc->cdb[0], qc->nbytes);
+ /* allow overflow only for misc ATAPI commands */
+ if (!atapi_qc_may_overflow(qc)) {
+ ata_ehi_push_desc(ehi, "unexpected trailing data "
+ "%u bytes", bytes);
+ return -1;
+ }
- for (i = 0; i < (bytes + 1) / 2; i++)
- ap->ops->data_xfer(qc->dev, (unsigned char *)pad_buf,
2, do_write);
+ consumed = 0;
+ while (consumed < bytes)
+ consumed += ap->ops->data_xfer(dev,
+ (unsigned char *)pad_buf, 2, rw);
qc->curbytes += bytes;
-
return 0;
}
@@ -5192,18 +5179,16 @@ next_sg:
buf = kmap_atomic(page, KM_IRQ0);
/* do the actual data transfer */
- ap->ops->data_xfer(qc->dev, buf + offset, count, do_write);
+ consumed = ap->ops->data_xfer(dev, buf + offset, count, rw);
kunmap_atomic(buf, KM_IRQ0);
local_irq_restore(flags);
} else {
buf = page_address(page);
- ap->ops->data_xfer(qc->dev, buf + offset, count, do_write);
+ consumed = ap->ops->data_xfer(dev, buf + offset, count, rw);
}
- bytes -= count;
- if ((count & 1) && bytes)
- bytes--;
+ bytes -= min(bytes, consumed);
qc->curbytes += count;
qc->cursg_ofs += count;
@@ -5212,9 +5197,11 @@ ne
Re: [PATCH] scsi_error: Fix language abuse.
Alan Cox wrote:
The word "illegal" has a precise dictionary meaning of "prohibited by
law".
Also "contrary to or forbidden by official rules, regulations, etc".
So word meanings are like standards, there are so many to choose
from.
The error messages are therefore incorrect as so far nobody has
made SCSI violations a criminal offence.
Most USB mass storage implementations should result in jail
terms for the responsible parties.
This corrects scsi to match various other subsystems I've slowly been
ridding of this.
Pedantically-signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Please don't do this.
- {0x2004, "Illegal command while in write capable state"},
+ {0x2004, "Invalid command while in write capable state"},
Several reasons:
1) Those strings appear in an international standard.
In this case SPC-3 ANSI INCITS 408-2005.
2) The way that INCITS standard (and others) is structured,
the relevant part of the text refers to a specific
additional sense code + qualifier instance by _name_
(e.g. "Illegal command while in write capable state")
not by number (e.g. 0x20,0x4). So given the Alan Cox
rendition of that string in a log, a diligent debugger
would need to get to constants.c to find the corresponding
asc/ascq numeric sequence, then search Annex D of SPC-3
to find the t10.org version of that string, then search
the body of SPC-3 and other t10 device class specific
standards for a match on the t10 string.
Vendor product manuals would tend to use the t10.org
strings as well.
3) I maintain constants.c and I do that with the help
of a program that compares t10's tables (specifically
http://www.t10.org/lists/asc-num.txt ) with the table
in constants.c . I'm glad to send you a copy so you
can take over maintaining the sanitized list and
cope with the abuse that may follow.
If you feel strongly about this then you could take it
up with ANSI or BS (a great acronym IMO).
Doug Gilbert
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-mm1/drivers/scsi/constants.c
linux-2.6.24-mm1/drivers/scsi/constants.c
--- linux.vanilla-2.6.24-mm1/drivers/scsi/constants.c 2008-02-06
14:14:40.0 +
+++ linux-2.6.24-mm1/drivers/scsi/constants.c 2008-02-06 14:35:16.0
+
@@ -606,10 +606,10 @@
{0x2001, "Access denied - initiator pending-enrolled"},
{0x2002, "Access denied - no access rights"},
{0x2003, "Access denied - invalid mgmt id key"},
- {0x2004, "Illegal command while in write capable state"},
+ {0x2004, "Invalid command while in write capable state"},
{0x2005, "Obsolete"},
- {0x2006, "Illegal command while in explicit address mode"},
- {0x2007, "Illegal command while in implicit address mode"},
+ {0x2006, "Invalid command while in explicit address mode"},
+ {0x2007, "Invalid command while in implicit address mode"},
{0x2008, "Access denied - enrollment conflict"},
{0x2009, "Access denied - invalid LU identifier"},
{0x200A, "Access denied - invalid proxy token"},
@@ -620,7 +620,7 @@
{0x2102, "Invalid address for write"},
{0x2103, "Invalid write crossing layer jump"},
- {0x2200, "Illegal function (use 20 00, 24 00, or 26 00)"},
+ {0x2200, "Invalid function (use 20 00, 24 00, or 26 00)"},
{0x2400, "Invalid field in cdb"},
{0x2401, "CDB decryption error"},
@@ -697,7 +697,7 @@
{0x2C02, "Invalid combination of windows specified"},
{0x2C03, "Current program area is not empty"},
{0x2C04, "Current program area is empty"},
- {0x2C05, "Illegal power condition request"},
+ {0x2C05, "Invalid power condition request"},
{0x2C06, "Persistent prevent conflict"},
{0x2C07, "Previous busy status"},
{0x2C08, "Previous task set full status"},
@@ -1014,7 +1014,7 @@
{0x6300, "End of user area encountered on this track"},
{0x6301, "Packet does not fit in available space"},
- {0x6400, "Illegal mode for this track"},
+ {0x6400, "Invalid mode for this track"},
{0x6401, "Invalid packet size"},
{0x6500, "Voltage fault"},
@@ -1124,7 +1124,7 @@
"Not Ready", /* 2: The addressed target is not ready */
"Medium Error", /* 3: Data error detected on the medium */
"Hardware Error", /* 4: Controller or device failure */
- "Illegal Request", /* 5: Error in request */
+ "Invalid Request", /* 5: Error in request */
"Unit Attention", /* 6: Removable medium was changed, or
the target has been reset, or ... */
"Data Protect", /* 7: Access to the data is blocked */
-
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
-
To unsubscribe from
[PATCH 2/7] block: update bio according to DMA alignment padding
DMA start address and transfer size alignment for PC requests are
achieved using bio_copy_user() instead of bio_map_user(). This works
because bio_copy_user() always uses full pages and block DMA alignment
isn't allowed to go over PAGE_SIZE.
However, the implementation didn't update the last bio of the request
to make this padding visible to lower layers. This patch makes
blk_rq_map_user() extend the last bio such that it includes the
padding area and the size of area pointed to by the request is
properly aligned.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
---
block/blk-map.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/block/blk-map.c b/block/blk-map.c
index 955d75c..103b1df 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -139,6 +139,23 @@ int blk_rq_map_user(struct request_queue *q, struct
request *rq,
ubuf += ret;
}
+ /*
+* __blk_rq_map_user() copies the buffers if starting address
+* or length isn't aligned. As the copied buffer is always
+* page aligned, we know that there's enough room for padding.
+* Extend the last bio and update rq->data_len accordingly.
+*
+* On unmap, bio_uncopy_user() will use unmodified
+* bio_map_data pointed to by bio->bi_private.
+*/
+ if (len & queue_dma_alignment(q)) {
+ unsigned int pad_len = (queue_dma_alignment(q) & ~len) + 1;
+ struct bio *bio = rq->biotail;
+
+ bio->bi_io_vec[bio->bi_vcnt - 1].bv_len += pad_len;
+ bio->bi_size += pad_len;
+ }
+
rq->buffer = rq->data = NULL;
return 0;
unmap_rq:
--
1.5.2.4
-
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
[PATCHSET #upstream] block/libata: update and use block layer padding and draining, take 2
This is the second take of blk-layer-padding-and-draining patchset. Changes from the last take[L] are... * libata-update-ATAPI-overflow-draining patch added. This patch fixes up ATAPI PIO handling before updating it to use block layer draining. consumed accounting and atapi_qc_may_overflow() update will survive blk draining conversion. * blk-clear-drain-buffer-for-writes patch added. This patch makes block layer clear drain buffer before chaining it to the sg list if the command in question is a write. * libata-implement-drain-buffers updated such that atapi_drain_needed() uses the same logic as atapi_qc_may_overflow() and ATAPI PIO drain logic is replaced too. This patchset is against the current upstream (bc5468f52b785ffa1fe0ea289baec2c51384d436). Thanks. -- tejun [L] http://thread.gmane.org/gmane.linux.ide/28048 - 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/7] block: add request->raw_data_len
With padding and draining moved into it, block layer now may extend
requests as directed by queue parameters, so now a request has two
sizes - the original request size and the extended size which matches
the size of area pointed to by bios and later by sgs. The latter size
is what lower layers are primarily interested in when allocating,
filling up DMA tables and setting up the controller.
Both padding and draining extend the data area to accomodate
controller characteristics. As any controller which speaks SCSI can
handle underflows, feeding larger data area is safe.
So, this patch makes the primary data length field, request->data_len,
indicate the size of full data area and add a separate length field,
request->raw_data_len, for the unmodified request size. The latter is
used to report to higher layer (userland) and where the original
request size should be fed to the controller or device.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
---
block/blk-core.c|2 ++
block/blk-map.c |2 ++
block/blk-merge.c |1 +
block/bsg.c |8
block/scsi_ioctl.c |3 ++-
drivers/scsi/scsi_lib.c |8
include/linux/blkdev.h |1 +
7 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 4afb39c..8b004e1 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -116,6 +116,7 @@ void rq_init(struct request_queue *q, struct request *rq)
rq->ref_count = 1;
rq->q = q;
rq->special = NULL;
+ rq->raw_data_len = 0;
rq->data_len = 0;
rq->data = NULL;
rq->nr_phys_segments = 0;
@@ -1982,6 +1983,7 @@ void blk_rq_bio_prep(struct request_queue *q, struct
request *rq,
rq->hard_cur_sectors = rq->current_nr_sectors;
rq->hard_nr_sectors = rq->nr_sectors = bio_sectors(bio);
rq->buffer = bio_data(bio);
+ rq->raw_data_len = bio->bi_size;
rq->data_len = bio->bi_size;
rq->bio = rq->biotail = bio;
diff --git a/block/blk-map.c b/block/blk-map.c
index 103b1df..1588ea3 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -19,6 +19,7 @@ int blk_rq_append_bio(struct request_queue *q, struct request
*rq,
rq->biotail->bi_next = bio;
rq->biotail = bio;
+ rq->raw_data_len += bio->bi_size;
rq->data_len += bio->bi_size;
}
return 0;
@@ -154,6 +155,7 @@ int blk_rq_map_user(struct request_queue *q, struct request
*rq,
bio->bi_io_vec[bio->bi_vcnt - 1].bv_len += pad_len;
bio->bi_size += pad_len;
+ rq->data_len += pad_len;
}
rq->buffer = rq->data = NULL;
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 845ef81..480d2bc 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -228,6 +228,7 @@ new_segment:
((unsigned long)q->dma_drain_buffer) &
(PAGE_SIZE - 1));
nsegs++;
+ rq->data_len += q->dma_drain_size;
}
if (sg)
diff --git a/block/bsg.c b/block/bsg.c
index 8917c51..7f3c095 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -437,14 +437,14 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq,
struct sg_io_v4 *hdr,
}
if (rq->next_rq) {
- hdr->dout_resid = rq->data_len;
- hdr->din_resid = rq->next_rq->data_len;
+ hdr->dout_resid = rq->raw_data_len;
+ hdr->din_resid = rq->next_rq->raw_data_len;
blk_rq_unmap_user(bidi_bio);
blk_put_request(rq->next_rq);
} else if (rq_data_dir(rq) == READ)
- hdr->din_resid = rq->data_len;
+ hdr->din_resid = rq->raw_data_len;
else
- hdr->dout_resid = rq->data_len;
+ hdr->dout_resid = rq->raw_data_len;
/*
* If the request generated a negative error number, return it
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 9675b34..e993cac 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -266,7 +266,7 @@ static int blk_complete_sghdr_rq(struct request *rq, struct
sg_io_hdr *hdr,
hdr->info = 0;
if (hdr->masked_status || hdr->host_status || hdr->driver_status)
hdr->info |= SG_INFO_CHECK;
- hdr->resid = rq->data_len;
+ hdr->resid = rq->raw_data_len;
hdr->sb_len_wr = 0;
if (rq->sense_len && hdr->sbp) {
@@ -528,6 +528,7 @@ static int __blk_send_generic(struct request_queue *q,
struct gendisk *bd_disk,
rq = blk_get_request(q, WRITE, __GFP_WAIT);
rq->cmd_type = REQ_TYPE_BLOCK_PC;
rq->data = NULL;
+ rq->raw_data_len = 0;
rq->data_len = 0;
rq->timeout = BLK_DEFAULT_SG_TIMEOUT;
memset(rq->cmd, 0, sizeof(rq->cmd));
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index f243fc3..afb2
[PATCH 5/7] block: clear drain buffer if draining for write command
Clear drain buffer before chaining if the command in question is a
write.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
block/blk-merge.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index d50cfc8..d0b9031 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -221,6 +221,9 @@ new_segment:
} /* segments in rq */
if (q->dma_drain_size && q->dma_drain_needed(rq)) {
+ if (rq->cmd_flags & REQ_RW)
+ memset(q->dma_drain_buffer, 0, q->dma_drain_size);
+
sg->page_link &= ~0x02;
sg = sg_next(sg);
sg_set_page(sg, virt_to_page(q->dma_drain_buffer),
--
1.5.2.4
-
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 7/7] libata: implement drain buffers
From: James Bottomley <[EMAIL PROTECTED]>
This just updates the libata slave configure routine to take advantage
of the block layer drain buffers. It also adjusts the size lengths in
the atapi code to add the drain buffer to the DMA length so the driver
knows it can rely on it.
I suspect I should also be checking for AHCI as well as ATA_DEV_ATAPI,
but I couldn't see how to do that easily.
tj: * atapi_drain_needed() added such that draining is applied to only
misc ATAPI commands.
* q->bounce_gfp used when allocating drain buffer.
* Now duplicate ATAPI PIO drain logic dropped.
* ata_dev_printk() used instead of sdev_printk().
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 56 +++---
drivers/ata/libata-scsi.c | 59
2 files changed, 57 insertions(+), 58 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d49b271..c03cef4 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4623,28 +4623,6 @@ int ata_check_atapi_dma(struct ata_queued_cmd *qc)
}
/**
- * atapi_qc_may_overflow - Check whether data transfer may overflow
- * @qc: ATA command in question
- *
- * ATAPI commands which transfer variable length data to host
- * might overflow due to application error or hardare bug. This
- * function checks whether overflow should be drained and ignored
- * for @qc.
- *
- * LOCKING:
- * None.
- *
- * RETURNS:
- * 1 if @qc may overflow; otherwise, 0.
- */
-static int atapi_qc_may_overflow(struct ata_queued_cmd *qc)
-{
- return ata_is_atapi(qc->tf.protocol) && ata_is_data(qc->tf.protocol) &&
- atapi_cmd_type(qc->cdb[0]) == ATAPI_MISC &&
- !(qc->tf.flags & ATA_TFLAG_WRITE);
-}
-
-/**
* ata_std_qc_defer - Check whether a qc needs to be deferred
* @qc: ATA command in question
*
@@ -5007,36 +4985,10 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc,
unsigned int bytes)
next_sg:
sg = qc->cursg;
if (unlikely(!sg)) {
- /*
-* The end of qc->sg is reached and the device expects
-* more data to transfer. In order not to overrun qc->sg
-* and fulfill length specified in the byte count register,
-*- for read case, discard trailing data from the device
-*- for write case, padding zero data to the device
-*/
- u16 pad_buf[1] = { 0 };
-
- if (qc->curbytes + bytes > qc->nbytes + ATAPI_MAX_DRAIN) {
- ata_ehi_push_desc(ehi, "too much trailing data "
- "buf=%u cur=%u bytes=%u",
- qc->nbytes, qc->curbytes, bytes);
- return -1;
- }
-
- /* allow overflow only for misc ATAPI commands */
- if (!atapi_qc_may_overflow(qc)) {
- ata_ehi_push_desc(ehi, "unexpected trailing data "
- "%u bytes", bytes);
- return -1;
- }
-
- consumed = 0;
- while (consumed < bytes)
- consumed += ap->ops->data_xfer(dev,
- (unsigned char *)pad_buf, 2, rw);
-
- qc->curbytes += bytes;
- return 0;
+ ata_ehi_push_desc(ehi, "unexpected or too much trailing data "
+ "buf=%u cur=%u bytes=%u",
+ qc->nbytes, qc->curbytes, bytes);
+ return -1;
}
page = sg_page(sg);
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index e54ee6e..b3b3b44 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -826,17 +826,56 @@ static void ata_scsi_sdev_config(struct scsi_device *sdev)
sdev->max_device_blocked = 1;
}
-static void ata_scsi_dev_config(struct scsi_device *sdev,
- struct ata_device *dev)
+/**
+ * atapi_drain_needed - Check whether data transfer may overflow
+ * @request: request to be checked
+ *
+ * ATAPI commands which transfer variable length data to host
+ * might overflow due to application error or hardare bug. This
+ * function checks whether overflow should be drained and ignored
+ * for @request.
+ *
+ * LOCKING:
+ * None.
+ *
+ * RETURNS:
+ * 1 if ; otherwise, 0.
+ */
+static int atapi_drain_needed(struct request *rq)
+{
+ if (likely(!blk_pc_request(rq)))
+ return 0;
+
+ if (!rq->data_len || (rq->cmd_flags & REQ_RW))
+ return 0;
+
+ return atapi_cmd_type(rq->cmd[0]) == ATAPI_MISC;
+}
+
+static int ata_scsi_dev_config(struct scsi_device
[PATCH 4/7] block: implement request_queue->dma_drain_needed
Draining shouldn't be done for commands where overflow may indicate
data integrity issues. Add dma_drain_needed callback to
request_queue. Drain buffer is appened iff this function returns
non-zero.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
---
block/blk-merge.c |2 +-
block/blk-settings.c |7 +--
include/linux/blkdev.h |7 +--
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 480d2bc..d50cfc8 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -220,7 +220,7 @@ new_segment:
bvprv = bvec;
} /* segments in rq */
- if (q->dma_drain_size) {
+ if (q->dma_drain_size && q->dma_drain_needed(rq)) {
sg->page_link &= ~0x02;
sg = sg_next(sg);
sg_set_page(sg, virt_to_page(q->dma_drain_buffer),
diff --git a/block/blk-settings.c b/block/blk-settings.c
index c8d0c57..0a0b3a4 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -296,6 +296,7 @@ EXPORT_SYMBOL(blk_queue_stack_limits);
* blk_queue_dma_drain - Set up a drain buffer for excess dma.
*
* @q: the request queue for the device
+ * @dma_drain_needed: fn which returns non-zero if drain is necessary
* @buf: physically contiguous buffer
* @size: size of the buffer in bytes
*
@@ -315,14 +316,16 @@ EXPORT_SYMBOL(blk_queue_stack_limits);
* device can support otherwise there won't be room for the drain
* buffer.
*/
-int blk_queue_dma_drain(struct request_queue *q, void *buf,
- unsigned int size)
+extern int blk_queue_dma_drain(struct request_queue *q,
+ dma_drain_needed_fn *dma_drain_needed,
+ void *buf, unsigned int size)
{
if (q->max_hw_segments < 2 || q->max_phys_segments < 2)
return -EINVAL;
/* make room for appending the drain */
--q->max_hw_segments;
--q->max_phys_segments;
+ q->dma_drain_needed = dma_drain_needed;
q->dma_drain_buffer = buf;
q->dma_drain_size = size;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index ee0b021..3912c5d 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -257,6 +257,7 @@ struct bio_vec;
typedef int (merge_bvec_fn) (struct request_queue *, struct bio *, struct
bio_vec *);
typedef void (prepare_flush_fn) (struct request_queue *, struct request *);
typedef void (softirq_done_fn)(struct request *);
+typedef int (dma_drain_needed_fn)(struct request *);
enum blk_queue_state {
Queue_down,
@@ -293,6 +294,7 @@ struct request_queue
merge_bvec_fn *merge_bvec_fn;
prepare_flush_fn*prepare_flush_fn;
softirq_done_fn *softirq_done_fn;
+ dma_drain_needed_fn *dma_drain_needed;
/*
* Dispatch queue sorting
@@ -697,8 +699,9 @@ extern void blk_queue_max_hw_segments(struct request_queue
*, unsigned short);
extern void blk_queue_max_segment_size(struct request_queue *, unsigned int);
extern void blk_queue_hardsect_size(struct request_queue *, unsigned short);
extern void blk_queue_stack_limits(struct request_queue *t, struct
request_queue *b);
-extern int blk_queue_dma_drain(struct request_queue *q, void *buf,
- unsigned int size);
+extern int blk_queue_dma_drain(struct request_queue *q,
+ dma_drain_needed_fn *dma_drain_needed,
+ void *buf, unsigned int size);
extern void blk_queue_segment_boundary(struct request_queue *, unsigned long);
extern void blk_queue_prep_rq(struct request_queue *, prep_rq_fn *pfn);
extern void blk_queue_merge_bvec(struct request_queue *, merge_bvec_fn *);
--
1.5.2.4
-
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
[Bug 9775] HOST_MSG_LOOP invalid SCB ff
http://bugzilla.kernel.org/show_bug.cgi?id=9775 --- Comment #8 from [EMAIL PROTECTED] 2008-02-08 18:52 --- Ok, I've spent some time trying different combinations of devices. Against kernel 2.6.24 T0 is Quantum DLT8000 ID0 T1 is Quantum DLT8000 ID1 MTX is STK L80 ID 15 Terminators A, B Channel A B T0,T1,MTX,B Nil Crash Nil T0,T1,MTX,B Parity Error in Data-in Phase Nil T0,MTX,B Ok, Tar test ok, MTX ok Nil T1,MTX,B Ok, Tar test ok, MTX ok -- Both drives work ok T1,MTX,BNil Ok Skipped Tests T1,MTX,ANil Ok Skipped Tests T0,MTX,BNil Crash T0,MTX,ANil Crash -- Not the terminator --Test on two channels T0,MTX,AT1,B Crash T1,BT0,MTX,A Parity Error in Data-in Phase It really doesn't like three devices, on two busses or one. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 9775] HOST_MSG_LOOP invalid SCB ff
http://bugzilla.kernel.org/show_bug.cgi?id=9775 --- Comment #9 from [EMAIL PROTECTED] 2008-02-08 18:54 --- Wrap around doesn't help.. I've also the the 'old' AIC78XX driver. That driver hangs even with no devices attached. So now what? --john -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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: Integration of SCST in the mainstream Linux kernel
On Fri, 8 Feb 2008, Vladislav Bolkhovitin wrote: 2. I think, everybody will agree that Linux iSCSI target should work over some standard SCSI target framework. Hence the choice gets narrower: SCST vs STGT. I don't think there's a way for a dedicated iSCSI target (i.e. PyX/LIO) in the mainline, because of a lot of code duplication. Nicholas could decide to move to either existing framework (although, frankly, I don't think there's a possibility for in-kernel iSCSI target and user space SCSI target framework) and if he decide to go with SCST, I'll be glad to offer my help and support and wouldn't care if LIO-SCST eventually replaced iSCSI-SCST. The better one should win. why should linux as an iSCSI target be limited to passthrough to a SCSI device. the most common use of this sort of thing that I would see is to load up a bunch of 1TB SATA drives in a commodity PC, run software RAID, and then export the resulting volume to other servers via iSCSI. not a 'real' SCSI device in sight. David, your question surprises me a lot. From where have you decided that SCST supports only pass-through backstorage? Does the RAM disk, which Bart has been using for performance tests, look like a SCSI device? I was responding to the start of item #2 that I left in the quote above. it asn't saying that SCST didn't support that, but was stating that any implementation of a iSCSI target should use the SCSI framework. I read this to mean that this would only be able to access things that the SCSI framework can access, and that would not be things like ramdisks, raid arrays, etc. David Lang - 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: Integration of SCST in the mainstream Linux kernel
--- On Fri, 2/8/08, Vladislav Bolkhovitin <[EMAIL PROTECTED]> wrote: > > Is there an open iSCSI Target implementation which > does NOT > > issue commands to sub-target devices via the SCSI > mid-layer, but > > bypasses it completely? > > What do you mean? To call directly low level backstorage > SCSI drivers > queuecommand() routine? What are advantages of it? Yes, that's what I meant. Just curious. Thanks, Luben - 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] Integration of SCST in the mainstream Linux kernel
--- On Fri, 2/8/08, Nicholas A. Bellinger <[EMAIL PROTECTED]> wrote: > > Is there an open iSCSI Target implementation which > does NOT > > issue commands to sub-target devices via the SCSI > mid-layer, but > > bypasses it completely? > > > >Luben > > > > Hi Luben, > > I am guessing you mean futher down the stack, which I > don't know this to Yes, that's what I meant. > be the case. Going futher up the layers is the design of > v2.9 LIO-SE. > There is a diagram explaining the basic concepts from a > 10,000 foot > level. > > http://linux-iscsi.org/builds/user/nab/storage-engine-concept.pdf Thanks! Luben - 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
