Re: [PATCH] zfcp: fix sense_buffer access bug
On Mon, 28 Jan 2008 08:46:25 +0100
Christof Schmitt <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 27, 2008 at 12:41:50PM +0900, FUJITA Tomonori wrote:
> > The commit de25deb18016f66dcdede165d07654559bb332bc changed
> > scsi_cmnd.sense_buffer from a static array to a dynamically allocated
> > buffer. We can't access to sense_buffer in '&cmd->sense_buffer' way.
> >
> > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> > ---
> > drivers/s390/scsi/zfcp_fsf.c |4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c
> > index fe57941..a9a147d 100644
> > --- a/drivers/s390/scsi/zfcp_fsf.c
> > +++ b/drivers/s390/scsi/zfcp_fsf.c
> > @@ -4224,10 +4224,10 @@ zfcp_fsf_send_fcp_command_task_handler(struct
> > zfcp_fsf_req *fsf_req)
> >
> > ZFCP_LOG_TRACE("%i bytes sense data provided by FCP\n",
> >fcp_rsp_iu->fcp_sns_len);
> > - memcpy(&scpnt->sense_buffer,
> > + memcpy(scpnt->sense_buffer,
> >zfcp_get_fcp_sns_info_ptr(fcp_rsp_iu), sns_len);
> > ZFCP_HEX_DUMP(ZFCP_LOG_LEVEL_TRACE,
> > - (void *) &scpnt->sense_buffer, sns_len);
> > + (void *)scpnt->sense_buffer, sns_len);
> > }
> >
> > /* check for overrun */
>
> ACK for fixing the access to the sense buffer.
>
> We are working internally on cleaning up the zfcp messages. With this
> change, the 'trace' and 'hex dump' messages will disappear. So, could
> you simply remove the ZFCP_HEX_DUMP message above, instead of fixing
> it?
I can but James has already merged the above patch to scsi-misc. So it
would be more convenient for everyone if you could rebase your
patchset on top of scsi-misc?
-
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] zfcp: fix sense_buffer access bug
On Mon, Jan 28, 2008 at 06:29:12PM +0900, FUJITA Tomonori wrote: > > ACK for fixing the access to the sense buffer. > > > > We are working internally on cleaning up the zfcp messages. With this > > change, the 'trace' and 'hex dump' messages will disappear. So, could > > you simply remove the ZFCP_HEX_DUMP message above, instead of fixing > > it? > > I can but James has already merged the above patch to scsi-misc. So it > would be more convenient for everyone if you could rebase your > patchset on top of scsi-misc? Ok, if the pach is already merged, i am fine with that. We will have to rebase the patches we are working on anyway. Thanks for providing the fix. Christof - 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] zfcp: fix sense_buffer access bug
On Mon, 2008-01-28 at 11:04 +0100, Christof Schmitt wrote: > On Mon, Jan 28, 2008 at 06:29:12PM +0900, FUJITA Tomonori wrote: > > > ACK for fixing the access to the sense buffer. > > > > > > We are working internally on cleaning up the zfcp messages. With this > > > change, the 'trace' and 'hex dump' messages will disappear. So, could > > > you simply remove the ZFCP_HEX_DUMP message above, instead of fixing > > > it? > > > > I can but James has already merged the above patch to scsi-misc. So it > > would be more convenient for everyone if you could rebase your > > patchset on top of scsi-misc? > > Ok, if the pach is already merged, i am fine with that. We will have > to rebase the patches we are working on anyway. Thanks for providing > the fix. It's in my upstream tree, but not merged with Linus and I can easily rebase. However, it is a critical bug fix, without it the driver will likely oops from overwriting command structures, so I'd rather keep it separate from any cleanup 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
[PATCH 1/1][] Test opcode, not definition in type_check(), drivers/scsi/aic7xxx/aicasm/aicasm_gram.y
drivers/scsi/aic7xxx_old/sequencer.h:130:#define AIC_OP_JZ 0xf -- Test opcode, not definition Signed-off-by: Roel Kluin <[EMAIL PROTECTED]> --- diff --git a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y index 6066998..702e2db 100644 --- a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y +++ b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y @@ -1837,7 +1837,7 @@ type_check(symbol_t *symbol, expression_t *expression, int opcode) int and_op; and_op = FALSE; - if (opcode == AIC_OP_AND || opcode == AIC_OP_JNZ || AIC_OP_JZ) + if (opcode == AIC_OP_AND || opcode == AIC_OP_JNZ || opcode == AIC_OP_JZ) and_op = TRUE; /* - 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
Unexpected busfree in Data-out phase
Hi, This is my first message on this list. The problem I'm facing are several messages of the form Jan 28 06:49:17 [kernel] (scsi0:A:0:0): Unexpected busfree in Data-out phase Jan 28 06:49:17 [kernel] SEQADDR == 0x86 generated by the aic7xxx driver running my Adaptec 29160. I get a lot of diferrent SEQADDR preceded by the same "Unexpected busfree in Data-out phase". From this morning I have also SEQADDR == 0x54. I started to notice these messages on two database servers since I upgraded their kernels to 2.6.23 (it happens with 2.6.22 also) about a month ago. Before I configured "Maximum number of TCQ commands per device" in the kernel to zero I got tons of other SCSI messages after the starting "Unexpected busfree in Data-out phase" message. I end up relating these bursts of SCSI error messages with kernel panics on the aic driver. Unfortunatelly I don't have more details on the kernel panic but I can try to provide it if necessary. Now that I have "Maximum number of TCQ commands per device" set to zero, I'm apparently only getting the "Unexpected busfree in Data-out phase" error message but no kernel panics. I already turned on the following options in the kernel but got no more info from it: Verbose SCSI error reporting (kernel size +=12K) and SCSI logging facility The "SCSI logging facility" needs some kind of echo "scsi log token [level]" > /proc/scsi/scsi but I couldn't identify which level I should try. Any advice on how to further diagnose this issue? Some basic info on my system: The discs connected to this Adaptec 29160 are quite old 36Gb 10K units from Compaq. I had a problem which looking back seems as exactly the same on other machine with a 39160 Adaptec board and older Seagate Cheetah 18Gb 10K disks but these discs aren't connected right now as they have been replaced by newer ones. # lspci 00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] 00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13) 00:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 00:0e.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02) 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) 00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 80) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] (rev 15) # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: COMPAQ Model: BD03663622 Rev: BDC4 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: COMPAQ Model: BD03663622 Rev: BDC4 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 02 Lun: 00 Vendor: COMPAQ Model: BD03663622 Rev: BDC4 Type: Direct-AccessANSI SCSI revision: 02 Regards, Rodrigo Severo -- --- Rodrigo Severo Fábrica de Idéias SBS Quadra 2 - Bloco S - Ed. Empire Center - Sala 1.301 Brasília - DF - CEP 70070-904 Tel. (61) 3321-1357 Fax (61) 3223-1712 --- - 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 added to scsi-misc-2.6: [SCSI] aacraid: fib context lock for management ioctls
Merde, this patch caused a problem with a system lockup. Please revert it. Sincerely -- Mark Salyzyn > -Original Message- > From: James Bottomley [mailto:[EMAIL PROTECTED] > Sent: Friday, January 25, 2008 12:05 PM > To: [EMAIL PROTECTED]; Salyzyn, Mark; James Bottomley; AACRAID > Subject: Patch added to scsi-misc-2.6: [SCSI] aacraid: fib > context lock for management ioctls > > Your commit: > > [SCSI] aacraid: fib context lock for management ioctls > > Alan noticed the lack of locking surrounding the driver's dealings > with the fib context managed by the trio of ioctls that > are used by > the RAID management applications to retrieve Adapter > Initiated FIBs. I > merely expanded the fib lock to include the fib context. > There have > been no field reports of any issues generally because the > applications > are relatively static and do not come and go often enough > to stress > this area. I bloated this patch a little with some space junk. > > Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> > Signed-off-by: James Bottomley > <[EMAIL PROTECTED]> > > has been added to the upstream SCSI tree > You can find it here: > > http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.g > it;a=commit;h=a119ee8ee3045bf559d4cf02d72b112f3de2a15b > > This patch is scheduled to be pushed when the merge window > opens for 2.6.25 > > James Bottomley > > P.S. If you find this email unwanted, set up a procmail rule > junking on > the header: > > X-Git-Tree: SCSI > - 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: [BUG] 2.6.24-git usb reset problems
On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: > Hi, > > Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and > connecting my cf usb storage device yields and endless stream of: > > Initializing USB Mass Storage driver... > scsi6 : SCSI emulation for USB Mass Storage devices > usb-storage: device found at 2 > usb-storage: waiting for device to settle before scanning > usbcore: registered new interface driver usb-storage > USB Mass Storage support registered. > scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > ANSI: 0 > sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > sd 6:0:0:0: [sdb] Write Protect is off > sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > sd 6:0:0:0: [sdb] Assuming drive cache: write through > sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > sd 6:0:0:0: [sdb] Write Protect is off > sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > sd 6:0:0:0: [sdb] Assuming drive cache: write through > sdb: sdb1 > sd 6:0:0:0: [sdb] Attached SCSI removable disk > sd 6:0:0:0: Attached scsi generic sg1 type 0 > scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > ANSI: 0 > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > [...] > > until I disconnect it. The device doesn't work. Worked fine in 2.6.24. > I'm attaching boot messages and my .config. That's a bit wierd, as we haven't added any USB patches to the -git tree yet after 2.6.24 :) Could this be caused by some scsi changes perhaps? thanks, greg k-h - 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
[2.6 patch] make __iscsi_complete_pdu() static
__iscsi_complete_pdu() can now become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/scsi/libiscsi.c |5 ++---
include/scsi/libiscsi.h |2 --
2 files changed, 2 insertions(+), 5 deletions(-)
4d4f211556f92590bfc32a243f562853c499b314
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 553168a..e794262 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -541,8 +541,8 @@ static int iscsi_handle_reject(struct iscsi_conn *conn,
struct iscsi_hdr *hdr,
* queuecommand or send generic. session lock must be held and verify
* itt must have been called.
*/
-int __iscsi_complete_pdu(struct iscsi_conn *conn, struct iscsi_hdr *hdr,
-char *data, int datalen)
+static int __iscsi_complete_pdu(struct iscsi_conn *conn, struct iscsi_hdr *hdr,
+ char *data, int datalen)
{
struct iscsi_session *session = conn->session;
int opcode = hdr->opcode & ISCSI_OPCODE_MASK, rc = 0;
@@ -672,7 +672,6 @@ int __iscsi_complete_pdu(struct iscsi_conn *conn, struct
iscsi_hdr *hdr,
return rc;
}
-EXPORT_SYMBOL_GPL(__iscsi_complete_pdu);
int iscsi_complete_pdu(struct iscsi_conn *conn, struct iscsi_hdr *hdr,
char *data, int datalen)
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index 889f51f..71eda24 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -349,8 +349,6 @@ extern int iscsi_conn_send_pdu(struct iscsi_cls_conn *,
struct iscsi_hdr *,
char *, uint32_t);
extern int iscsi_complete_pdu(struct iscsi_conn *, struct iscsi_hdr *,
char *, int);
-extern int __iscsi_complete_pdu(struct iscsi_conn *, struct iscsi_hdr *,
- char *, int);
extern int iscsi_verify_itt(struct iscsi_conn *, struct iscsi_hdr *,
uint32_t *);
extern void iscsi_requeue_ctask(struct iscsi_cmd_task *ctask);
-
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 2.6.23.14] SCSI : scsi_device_lookup/scsi_device_lookup_by_target return NULL for an existent scsi_device
James, I am facing issues with device removal being done when there are commands outstanding in the LLD. As explained in my original post, its resulting in effects ranging from the duplicate kobject warnings to the inability of the scsi subsystem to find a valid device (all symptoms are related to the fact that two scsi devices with the same HBTL but in diff states, SDEV_DEL and SDEV_RUNNING, are in the lists). After extensive audit of the code I'm quite certain that the aforementioned patch is the right thing to do. I'll greatly appreciate if you can highlight reason(s) why that might not be a good idea. Pls apply o/w. Thanx, Tomar --- Nagendra Tomar <[EMAIL PROTECTED]> wrote: > Hello James, > My understanding is that the scsi_device in SDEV_DEL state > is there in the scsi_host->devices/scsi_target->devices queue, just > because there is some outstanding command holding a reference to it. > > It will need the device when it completes. Apart from this, for all > practical purposes the scsi_device is gone from the system. It could > as well be removed from scsi_host->devices/scsi_target->devices lists > and be put in some other list, just to hold the scsi_device till > commands refering to it are completed. > > The scanning code should not consider these devices to be present > in the system. This is correctly handled today, as > scsi_device_lookup/scsi_device_lookup_by_target return NULL if there > is an SDEV_DEL device in the list. > > Since a scsi_device in SDEV_DEL state is "gone" from the system we > should not hold any fresh references on to this device. The current > scsi_device_lookup/scsi_device_lookup_by_target implementation rightly > ensures that. And since all the sysfs linkages are also removed (in > __scsi_remove_device->device_del), user space can also not reference > this device. All is good till now. > > The problem happens when we try to add a new scsi_device with the same > HBTL. Since we consider the device "gone" (as described above) we should > allow a new scsi_device with the same HBTL to be added (to the > scsi_host->devices/scsi_target->devices list). This part is also correctly > implemented. > scsi_add_device->...->scsi_probe_and_add_lun->scsi_device_lookup_by_target > will _not_ return the device present in the SDEV_DEL state and hence the > scanning will go ahead and try to add a new scsi_device (this one in > SDEV_RUNNING state) to the devices lists. > > All is good even till now. > > The PROBLEM is, now any scsi_device_lookup call trying to lookup this newly > added scsi_device, fails. This is because, > scsi_device_lookup->__scsi_device_lookup > returns the first device that it finds in the list, which in this case > is the one in the SDEV_DEL state. Now the scsi_device_get call that > scsi_device_lookup makes to get a reference on that device returns ENXIO > as the device is in SDEV_DEL state, resulting in scsi_device_lookup to > return NULL. > > What scsi_device_get does, is right, as we do not want to hold fresh > references on scsi_devices in SDEV_DEL state. The problem is because > of this we fail to lookup the perfectly legitimate device (in SDEV_RUNNING > state) with the same HBTL sitting in the list. > > One of the side effects of this is that the scsi_probe_and_add_lun() > goes ahead with the scanning and tries to add this existent device. > This is the real problem. > > My patch avoids this problem by not breaking from the __scsi_device_lookup > loop, if the device is in SDEV_DEL state. After all we should not consider > these devices to be part of the system. This will allow us to > find the right scsi_device and this "trying to add an existent device" > problem will be avoided. > > And also why should scsi_device_lookup and __scsi_device_lookup be > different in behaviour. One returns devices in SDEV_DEL state, the other > doesn't. The comments suggest that they can be used interchangibly, but > for the locking and the extra reference that the scsi_device_lookup holds. > > This is fixed as a side effect of the patch. > > Comments welcome. > > Thanx, > Tomar > > > > > > --- James Smart <[EMAIL PROTECTED]> wrote: > > > > > This sounds like a return to the old behavior, where sdevs in SDEV_DEL > > were ignored. However, it too had lots of bad effects. We'd have to go > > back to the threads over the last 2 years that justified resurrecting > > the sdev. Start looking at threads like : > > http://marc.info/?l=linux-scsi&m=11788730468&w=2 > > http://marc.info/?l=linux-scsi&m=116837744314913&w=2 > > http://marc.info/?l=linux-scsi&m=117139230702785&w=2 > > http://marc.info/?l=linux-scsi&m=117991046126294&w=2 > > Also, there's multiple parts to this - the sdev struct, and the sysfs > > objects > > and thus namespace associated with the struct, etc. > > > > So, in my mind, if this reverts to ignoring sdevs in SDEV_DEL, and creates > > a duplicate sdev in SDEV_RUNNING, then it's the wrong patch. Wh
[PATCH 1/1] aacraid: fib context lock for management ioctls (take 2)
The first patch was a bit too aggressive and nested the locks (!) unit testing
was in error.
Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
drivers/scsi/aacraid/commctrl.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
Sincerely -- Mark Salyzyn
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Salyzyn, Mark
> Sent: Thursday, January 24, 2008 10:40 AM
> To: 'linux-scsi@vger.kernel.org'
> Cc: 'Alan Cox'; 'Alan Cox'
> Subject: [PATCH 1/1] aacraid: fib context lock for management ioctls
>
> Alan noticed the lack of locking surrounding the driver's
> dealings with the fib context managed by the trio of ioctls
> that are used by the RAID management applications to retrieve
> Adapter Initiated FIBs. I merely expanded the fib lock to
> include the fib context. There have been no field reports of
> any issues generally because the applications are relatively
> static and do not come and go often enough to stress this
> area. I bloated this patch a little with some space junk.
>
> This attached patch is against current scsi-misc-2.6.
>
> ObligatoryDisclaimer: Please accept my condolences regarding
> Outlook's handling of patch attachments. The following inline
> patch is 'diff -rub' to pull out the space junk to enable
> convenient inspection, please use the attached file to patch.
>
> Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>
>
> drivers/scsi/aacraid/commctrl.c | 29 +
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff -rub a/commctrl.c b/commctrl.c
> --- a/drivers/scsi/aacraid/commctrl.c2008-01-24
> 09:44:33.080806785 -0500
> +++ b/drivers/scsi/aacraid/commctrl.c2008-01-24
> 09:50:41.071552674 -0500
> @@ -243,6 +243,7 @@
> * Search the list of AdapterFibContext
> addresses on the adapter
> * to be sure this is a valid address
> */
> + spin_lock_irqsave(&dev->fib_lock, flags);
> entry = dev->fib_list.next;
> fibctx = NULL;
>
> @@ -258,17 +259,18 @@
> fibctx = NULL;
> }
> if (!fibctx) {
> + spin_unlock_irqrestore(&dev->fib_lock, flags);
> dprintk ((KERN_INFO "Fib Context not found\n"));
> return -EINVAL;
> }
>
> if((fibctx->type != FSAFS_NTC_GET_ADAPTER_FIB_CONTEXT) ||
> (fibctx->size != sizeof(struct aac_fib_context))) {
> + spin_unlock_irqrestore(&dev->fib_lock, flags);
> dprintk ((KERN_INFO "Fib Context corrupt?\n"));
> return -EINVAL;
> }
> status = 0;
> - spin_lock_irqsave(&dev->fib_lock, flags);
> /*
> * If there are no fibs to send back, then
> either wait or return
> * -EAGAIN
Here is the offending portion of the previous patch (two chunks):
> @@ -326,7 +328,9 @@
> int aac_close_fib_context(struct aac_dev * dev, struct
> aac_fib_context * fibctx)
> {
> struct fib *fib;
> + unsigned long flags;
>
> + spin_lock_irqsave(&dev->fib_lock, flags);
> /*
> * First free any FIBs that have not been consumed.
> */
> @@ -349,6 +353,7 @@
> * Remove the Context from the AdapterFibContext List
> */
> list_del(&fibctx->next);
> + spin_unlock_irqrestore(&dev->fib_lock, flags);
> /*
> * Invalidate context
> */
>
> Sincerely - Mark Salyzyn
aacraid_fibctx_lock2.patch
Description: aacraid_fibctx_lock2.patch
DMA mapping on SCSI device?
We've got a bit of a problem with the sata_nv driver that I'm trying to figure out a decent solution to (hence all the lists CCed). This is the situation: The nForce4 ADMA hardware has 2 modes: legacy mode, where it acts like a normal ATA controller with 32-bit DMA limits, and ADMA mode where it can access all of 64-bit memory. Each PCI device has 2 SATA ports, and the legacy/ADMA mode can be controlled independently on both of them. The trick is that if an ATAPI device is connected, we (as far as I'm aware) can't use ADMA mode, so we have to switch that port into legacy mode. This means it's only capable of 32-bit DMA. However the other port on the controller may be connected to a hard drive and therefore still capable of 64-bit DMA. (To make things more complicated, devices can be hotplugged and so this can change dynamically.) Since the device that libata is doing DMA mapping against is attached to the PCI device and not the port, it creates a problem here. If we change the mask on one it affects the other one as well. The original solution used by the driver was to leave the DMA mask at 64-bit and use blk_queue_bounce_limit to try to force the block layer not to send any requests with DMA addresses over 4GB into the driver. However it seems on x86_64 this doesn't work, since it pushes high addresses through anyway and expects the IOMMU to take care of it (which it doesn't because of the 64-bit mask). The last solution I tried was to set the DMA mask on both ports to 32-bit on slave_configure when an ATAPI device is connected. However, this runs into complications as well. This is run on initialization and when trying to set the other port into 32-bit DMA, it may not be initialized yet. Plus, it forces the port with a hard drive on it into 32-bit DMA needlessly. The ideal solution would be to do mapping against a different struct device for each port, so that we could maintain the proper DMA mask for each of them at all times. However I'm not sure if that's possible. The thought of using the SCSI struct device for DMA mapping was brought up at one point.. any thoughts on that? - 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: DMA mapping on SCSI device?
On Jan 29, 2008 11:08 AM, Robert Hancock <[EMAIL PROTECTED]> wrote: ... > The last solution I tried was to set the DMA mask on both ports to > 32-bit on slave_configure when an ATAPI device is connected. However, > this runs into complications as well. This is run on initialization and > when trying to set the other port into 32-bit DMA, it may not be > initialized yet. Plus, it forces the port with a hard drive on it into > 32-bit DMA needlessly. Have you measured the impact of setting the PCI dma mask to 32-bit? Last time Alex Williamson (HP) measured this on IA64, we deliberately forced pci_map_sg() to use the IOMMU even for devices that were 64-bit capable. We got 3-5% better throughput since the device had fewer entries to retrieve and the devices (at the time) weren't that good at processing SG lists. > > The ideal solution would be to do mapping against a different struct > device for each port, so that we could maintain the proper DMA mask for > each of them at all times. However I'm not sure if that's possible. The > thought of using the SCSI struct device for DMA mapping was brought up > at one point.. any thoughts on that? I'm pretty sure that's not possible (using two PCI dev structs). I'm skeptical it's worth converting DMA services to use SCSI devs since that's an extremely invasive change for a marginal benefit. hth, grant > - > 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: DMA mapping on SCSI device?
On Mon, Jan 28, 2008 at 06:08:44PM -0600, Robert Hancock wrote: > The > thought of using the SCSI struct device for DMA mapping was brought up > at one point.. any thoughts on that? I believe this will work on some architectures and not others. Anything that uses include/asm-generic/dma-mapping.h will break, for example. It would be nice for those architectures to get fixed ... -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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: DMA mapping on SCSI device?
> The ideal solution would be to do mapping against a different struct > device for each port, so that we could maintain the proper DMA mask for > each of them at all times. However I'm not sure if that's possible. I cannot imagine why it should be that difficult. The PCI subsystem could over a pci_clone_device() or similar function. For all complicated purposes (sysfs etc) the original device could be used, so it would be hopefully not that difficult. The alternative would be to add a new family of PCI mapping functions that take an explicit mask. Disadvantage would be changing all architectures, but on the other hand the interface could be phase in one by one (and nF4 primarily only works on x86 anyways) I suspect the later would be a little cleaner, although they don't make much difference. -Andi - 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: Open-FCoE on linux-scsi
On Jan 15, 2008 2:18 PM, James Smart <[EMAIL PROTECTED]> wrote: > True - it should become rather evident that FC should be its own > i/o bus, with the hba LLDD providing bindings to each of the FC4 stacks. > This would have worked really well for FCOE, with it creating a fc_port > object, which could then layer a scsi_host on top of it, etc. > Right now there's too much assumption that SCSI is the main owner of the > port. The NPIV vport stuff is a good illustration of this concept (why is > the vport a subobject of the scsi_host ?). In thinking about how FC should be represented, it seems to me that in order to provide good interfaces at multiple levels of functionality we have to make sure the we have the right data structures at each level. At the highest level there's scsi_cmd, then there's sequence based interfaces that would need some sort of a sequence structure with a scatter gather list, and at the lowest level interfaces work directly with FC frames. I'd like to talk about how we should go about representing FC frames. Currently, our libfc code introduces an fc_frame struct but allows the LLDD to provide an allocation function and control how the fc_frames are allocated. The fcoe module uses this capability to map the data buffer of an fc_frame to that of an sk_buff. As someone coming from a networking background, and interested in FCoE which ends up sending frames via an Ethernet driver, I tend to think this is overly complex and just want to use sk_buffs directly. Would SCSI/FC developers be opposed to dealing with sk_buffs for frame level interfaces, or do we need to keep a seperate fc_frame structure around? I'd argue that skbs do a fine job of representing all sorts of frame structures, that any device that supports IP over FC has to deal with skbs in its driver anyway, and that at the frame level FC is just another network. But then again, I am biased as skbs seem friendly and familiar to me as I venture further into the alien landscape that is scsi. - Chris - 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: [BUG] 2.6.24-git usb reset problems
On Mon, Jan 28 2008, Greg KH wrote: > On Mon, Jan 28, 2008 at 09:49:35PM +0100, Jens Axboe wrote: > > Hi, > > > > Running latest -git (head 91525300baf162e83e923b09ca286f9205e21522) and > > connecting my cf usb storage device yields and endless stream of: > > > > Initializing USB Mass Storage driver... > > scsi6 : SCSI emulation for USB Mass Storage devices > > usb-storage: device found at 2 > > usb-storage: waiting for device to settle before scanning > > usbcore: registered new interface driver usb-storage > > USB Mass Storage support registered. > > scsi 6:0:0:0: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > > ANSI: 0 > > sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > > sd 6:0:0:0: [sdb] Write Protect is off > > sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > > sd 6:0:0:0: [sdb] Assuming drive cache: write through > > sd 6:0:0:0: [sdb] 4001760 512-byte hardware sectors (2049 MB) > > sd 6:0:0:0: [sdb] Write Protect is off > > sd 6:0:0:0: [sdb] Mode Sense: 02 00 00 00 > > sd 6:0:0:0: [sdb] Assuming drive cache: write through > > sdb: sdb1 > > sd 6:0:0:0: [sdb] Attached SCSI removable disk > > sd 6:0:0:0: Attached scsi generic sg1 type 0 > > scsi 6:0:0:1: Direct-Access Generic STORAGE DEVICE 0125 PQ: 0 > > ANSI: 0 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > usb 5-1: reset high speed USB device using ehci_hcd and address 2 > > [...] > > > > until I disconnect it. The device doesn't work. Worked fine in 2.6.24. > > I'm attaching boot messages and my .config. > > That's a bit wierd, as we haven't added any USB patches to the -git tree > yet after 2.6.24 :) > > Could this be caused by some scsi changes perhaps? Heh, I guess it could! I'll double check, I reproduced it with two distinct boots before posting. -- 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
