Re: UAS crash with Apricorn USB3 SATA bridge
Hi, On 09-12-14 20:31, Darrick J. Wong wrote: Hi, I have an Apricorn USB 3 disk dongle thing that claims to support UAS. However, the kernel crashes when I plug it in[1]. Yes there are some known issues with uas error handling which are fixed in 3.18, can you try with a 3.18 kernel please ? Note that the device will likely still not work, but it should no longer crash things. When running 3.18 please collect the output of "dmesg" after plugging in the drive and send that to me, then we'll see if we can get it to work from there. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] drivers: scsi: megaraid: Add "megaraid_sas_internal.h" for internal shared functions using
>-Original Message- >From: Chen Gang [mailto:gang.chen.5...@gmail.com] >Sent: Sunday, November 30, 2014 8:37 AM >To: Sumit Saxena >Cc: megaraidli...@lsi.com; linux-scsi@vger.kernel.org; linux- >ker...@vger.kernel.org >Subject: Re: [PATCH] drivers: scsi: megaraid: Add "megaraid_sas_internal.h" >for internal shared functions using > >On 11/17/14 19:51, Sumit Saxena wrote: >>> -Original Message- >>> From: Chen Gang [mailto:gang.chen.5...@gmail.com] >>> Sent: Monday, November 17, 2014 5:17 PM >>> To: Sumit Saxena >>> Cc: megaraidli...@lsi.com; linux-scsi@vger.kernel.org; linux- >>> ker...@vger.kernel.org >>> Subject: RE: [PATCH] drivers: scsi: megaraid: Add >"megaraid_sas_internal.h" >>> for internal shared functions using >>> >>> >>> OK, I will send patch v2 for it. >>> >>> I sent this patch based on Linux next tree, please tell me the tree >>> location (git >>> address) which I shall base on for sending patch v2. >> >> I posted the patch series today, once the patches make it to scsi-next >> tree, I will let you know. >> > >Is it OK? or if possible, please help rebase and send the patch for it >based on >the related branches and patches. Sorry for delay in response, patch series sent by me is accepted at upstream. Please rebase "for-next" branch of scsi.git, here is git address of tree- git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git Please sent out patch v2, I will ACK. Thanks Sumit > >Thanks. >-- >Chen Gang > >Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: scsi: megaraid: Add "megaraid_sas_internal.h" for internal shared functions using
On 12/10/14 16:47, Sumit Saxena wrote: >> From: Chen Gang [mailto:gang.chen.5...@gmail.com] >> Sent: Sunday, November 30, 2014 8:37 AM >> >> Is it OK? or if possible, please help rebase and send the patch for it >> based on >> the related branches and patches. > Sorry for delay in response, patch series sent by me is accepted at > upstream. Please rebase "for-next" branch of scsi.git, here is git address > of tree- > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git > > Please sent out patch v2, I will ACK. > OK, thanks, I shall try to send patch v2 within this week (2014-12-14). Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [V3 PATCH 4/4] scsi:stex.c Add S3/S4 support
On Wed, 2014-12-10 at 09:38 +0800, Charles Chiou wrote:
> From 91868d4afe10533b8a4496075109e411100217bb Mon Sep 17 00:00:00 2001
> From: Charles Chiou
> Date: Fri, 7 Nov 2014 10:15:18 +0800
> Subject: [PATCH 4/4] scsi:stex.c Add S3/S4 support
>
> Add S3/S4 support, add .suspend and .resume function in pci_driver.
>
> Pegasus need 30~40 seconds to boot up. We don't want to OS wait
> in .resume function. Create a thread to handle device boot up.
>
> +static int stex_resume(struct pci_dev *pdev)
> +{
> + struct st_hba *hba = pci_get_drvdata(pdev);
> + struct hba_handshake_workstruct *hswork;
> + int sts;
> +
> + hba->mu_status = MU_STATE_STARTING;
> + hswork = kzalloc(sizeof(struct hba_handshake_workstruct), GFP_KERNEL);
The system is coming back from sleep. You cannot swap or page out
as disks may still be asleep. GFP_KERNEL is automatically changed
to GFP_NOIO. It would be nice to outright use GFP_NOIO.
> + INIT_WORK(&hswork->handshake_work, resume_handshake);
Memory allocations can fail.
I suggest you allocate the memory in suspend(). There you can just
return -ENOMEM in the error case.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UAS crash with Apricorn USB3 SATA bridge
On Wed, Dec 10, 2014 at 09:19:04AM +0100, Hans de Goede wrote: > Hi, > > On 09-12-14 20:31, Darrick J. Wong wrote: > >Hi, > > > >I have an Apricorn USB 3 disk dongle thing that claims to support UAS. > >However, the kernel crashes when I plug it in[1]. > > Yes there are some known issues with uas error handling which are fixed > in 3.18, can you try with a 3.18 kernel please ? The crash pic was from 3.18.0, blk_mq disabled. I'll work on getting a fuller dmesg output. Looking at the code, it looks like we end up in queue_bulk_sg_tx() with a sg list that is shorter than num_sgs, so we fall off the end. (Alas it's now 1am here, so I'm going to bed. :/ ) --D > > Note that the device will likely still not work, but it should no > longer crash things. When running 3.18 please collect the output of > "dmesg" after plugging in the drive and send that to me, then we'll see > if we can get it to work from there. > > Regards, > > Hans -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UAS crash with Apricorn USB3 SATA bridge
On Wed, Dec 10, 2014 at 01:04:58AM -0800, Darrick J. Wong wrote:
> On Wed, Dec 10, 2014 at 09:19:04AM +0100, Hans de Goede wrote:
> > Hi,
> >
> > On 09-12-14 20:31, Darrick J. Wong wrote:
> > >Hi,
> > >
> > >I have an Apricorn USB 3 disk dongle thing that claims to support UAS.
> > >However, the kernel crashes when I plug it in[1].
> >
> > Yes there are some known issues with uas error handling which are fixed
> > in 3.18, can you try with a 3.18 kernel please ?
>
> The crash pic was from 3.18.0, blk_mq disabled. I'll work on getting a fuller
> dmesg output. Looking at the code, it looks like we end up in
> queue_bulk_sg_tx() with a sg list that is shorter than num_sgs, so we fall off
> the end.
>
> (Alas it's now 1am here, so I'm going to bed. :/ )
Eh, nuts to sleeping. dmesg produces this:
[ 231.128074] usbcore: registered new interface driver usb-storage
[ 231.133822] usbcore: registered new interface driver uas
[ 252.121353] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd
[ 252.136927] scsi host6: uas
[ 252.141679] scsi 6:0:0:0: Direct-Access Apricorn 0128
PQ: 0 ANSI: 6
[ 252.145433] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 252.145525] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149
GiB)
[ 252.145527] sd 6:0:0:0: [sdc] 4096-byte physical blocks
[ 252.145891] sd 6:0:0:0: [sdc] Write Protect is off
[ 252.145973] sd 6:0:0:0: [sdc] No Caching mode page found
[ 252.145975] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 252.171739] queue_bulk_sg_tx: num=4294967295 sg=8804584e0b00 addr=
(null) len=0 pagelink=116b8882
[ 252.173706] queue_bulk_sg_tx: num=4294967295 sg= (null), ABORT
I wrote in a printk to spit out num_sgs and some of the sg data right before
the sg_next() call. Looks like num_sgs is originally zero? I then patched
the code to break early if num_sgs == 0:
/* Calculate length for next transfer --
* Are we done queueing all the TRBs for this sg entry?
*/
this_sg_len -= trb_buff_len;
printk(KERN_ERR "%s: num=%u sg=%p addr=%lx len=%u pagelink=%lx\n", __func__,
num_sgs, sg, addr, this_sg_len, sg->page_link);
if (this_sg_len == 0) {
if (num_sgs == 0) {
printk(KERN_ERR "%s: breaking early, no sgs??\n", __func__);
break;
}
--num_sgs;
if (num_sgs == 0)
break;
sg = sg_next(sg);
addr = (u64) sg_dma_address(sg);
this_sg_len = sg_dma_len(sg);
This produced this log[1] which I've excerpted here:
[ 96.944791] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd
[ 96.972881] usbcore: registered new interface driver usb-storage
[ 128.315902] scsi host6: uas
[ 128.318605] usbcore: registered new interface driver uas
[ 128.318691] queue_bulk_sg_tx: num=1 sg=88044650ed00 addr=446958000 len=0
pagelink=ea00111a5602
[ 128.318960] queue_bulk_sg_tx: num=1 sg=880457a03300 addr=446958000 len=0
pagelink=ea00111a5602
[ 128.321144] scsi 6:0:0:0: Direct-Access Apricorn 0128
PQ: 0 ANSI: 6
[ 128.321165] queue_bulk_sg_tx: num=1 sg=880457a03300 addr=45cbb1000 len=0
pagelink=ea001172ec42
[ 128.323714] queue_bulk_sg_tx: num=1 sg=880457a02100 addr=447738000 len=0
pagelink=ea00111dce02
[ 128.326233] queue_bulk_sg_tx: num=1 sg=880457a02600 addr=45a4c8000 len=0
pagelink=ea0011693202
[ 128.329157] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 128.331328] queue_bulk_sg_tx: num=1 sg=88045795ce00 addr=456ad7000 len=0
pagelink=ea00115ab5c2
[ 128.331428] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149
GiB)
[ 128.331431] sd 6:0:0:0: [sdc] 4096-byte physical blocks
[ 128.331448] queue_bulk_sg_tx: num=1 sg=880457a02100 addr=456ad7000 len=0
pagelink=ea00115ab5c2
[ 128.333772] queue_bulk_sg_tx: num=1 sg=880457a03300 addr=44649e000 len=0
pagelink=ea0011192782
[ 128.336191] queue_bulk_sg_tx: num=1 sg=880457a02700 addr=45683b000 len=0
pagelink=ea00115a0ec2
[ 128.338561] queue_bulk_sg_tx: num=1 sg=880457a02600 addr=37355000 len=0
pagelink=eadcd542
[ 128.340979] queue_bulk_sg_tx: num=1 sg=880457a02c00 addr=8a8e3000 len=0
pagelink=ea00022a38c2
[ 128.343246] sd 6:0:0:0: [sdc] Write Protect is off
[ 128.343263] queue_bulk_sg_tx: num=1 sg=880457a02400 addr=8a8e2000 len=0
pagelink=ea00022a3882
[ 128.345461] sd 6:0:0:0: [sdc] No Caching mode page found
[ 128.345463] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[ 128.345475] queue_bulk_sg_tx: num=1 sg=880457a02000 addr=45ba6ba00 len=0
pagelink=ea00116e9ac2
[ 128.347752] queue_bulk_sg_tx: num=1 sg=880457a02000 addr=8ab21000 len=0
pagelink=ea00022ac842
[ 128.352127] queue_bulk_sg_tx: num=1 sg=880457a02c00 addr=8637f000 len=0
pagelink=ea000218dfc
Re: esp_scsi: make number of tags configurable
On Tue, Dec 9, 2014 at 6:36 AM, Linux Kernel Mailing List
wrote:
> Gitweb:
> http://git.kernel.org/linus/;a=commit;h=3707a186c8970e3c4f3c8d9ccf4230b8657e919f
> Commit: 3707a186c8970e3c4f3c8d9ccf4230b8657e919f
> Parent: a87bf29362c763cf35faa17154b699471a8b902e
> Refname:refs/heads/master
> Author: Hannes Reinecke
> AuthorDate: Mon Nov 24 15:37:20 2014 +0100
> Committer: Christoph Hellwig
> CommitDate: Mon Nov 24 16:10:23 2014 +0100
>
> esp_scsi: make number of tags configurable
>
> Add a field 'num_tags' to the esp structure to allow drivers
> to overwrite the number of avialable tags if required.
> Default is ESP_DEFAULT_TAGS.
>
> Reviewed-by: Paolo Bonzini
> Acked-by: David S. Miller
> Signed-off-by: Hannes Reinecke
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/esp_scsi.c | 12 ++--
> drivers/scsi/esp_scsi.h | 3 +--
> 2 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
> index 7e7687f..57ccb14 100644
> --- a/drivers/scsi/esp_scsi.c
> +++ b/drivers/scsi/esp_scsi.c
> @@ -2317,6 +2317,10 @@ int scsi_esp_register(struct esp *esp, struct device
> *dev)
> static int instance;
> int err;
>
> + if (!esp->num_tags)
> + esp->num_tags = ESP_DEFAULT_TAGS;
> + else if (esp->num_tags >= ESP_MAX_TAG)
drivers/scsi/esp_scsi.c: In function ‘scsi_esp_register’:
drivers/scsi/esp_scsi.c:2399: warning: comparison is always false due
to limited range of data type
ESP_MAX_TAG is 256, num_tags is u8.
> + esp->num_tags = ESP_MAX_TAG - 1;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UAS crash with Apricorn USB3 SATA bridge
On Wed, Dec 10, 2014 at 02:15:14AM -0800, Darrick J. Wong wrote:
> On Wed, Dec 10, 2014 at 01:04:58AM -0800, Darrick J. Wong wrote:
> > On Wed, Dec 10, 2014 at 09:19:04AM +0100, Hans de Goede wrote:
> > > Hi,
> > >
> > > On 09-12-14 20:31, Darrick J. Wong wrote:
> > > >Hi,
> > > >
> > > >I have an Apricorn USB 3 disk dongle thing that claims to support UAS.
> > > >However, the kernel crashes when I plug it in[1].
> > >
> > > Yes there are some known issues with uas error handling which are fixed
> > > in 3.18, can you try with a 3.18 kernel please ?
> >
> > The crash pic was from 3.18.0, blk_mq disabled. I'll work on getting a
> > fuller
> > dmesg output. Looking at the code, it looks like we end up in
> > queue_bulk_sg_tx() with a sg list that is shorter than num_sgs, so we fall
> > off
> > the end.
> >
> > (Alas it's now 1am here, so I'm going to bed. :/ )
>
> Eh, nuts to sleeping. dmesg produces this:
>
> [ 231.128074] usbcore: registered new interface driver usb-storage
> [ 231.133822] usbcore: registered new interface driver uas
> [ 252.121353] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd
> [ 252.136927] scsi host6: uas
> [ 252.141679] scsi 6:0:0:0: Direct-Access Apricorn 0128
> PQ: 0 ANSI: 6
> [ 252.145433] sd 6:0:0:0: Attached scsi generic sg2 type 0
> [ 252.145525] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160
> GB/149 GiB)
> [ 252.145527] sd 6:0:0:0: [sdc] 4096-byte physical blocks
> [ 252.145891] sd 6:0:0:0: [sdc] Write Protect is off
> [ 252.145973] sd 6:0:0:0: [sdc] No Caching mode page found
> [ 252.145975] sd 6:0:0:0: [sdc] Assuming drive cache: write through
Huh. 4096-byte physical blocks?? That drive is /not/ a 4k sector drive.
Here's what the kernel said when I plugged in the other ("Plugable" brand) UAS
bridge[1]:
[ 32.466870] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd
[ 32.498996] usbcore: registered new interface driver usb-storage
[ 37.660963] scsi host6: uas
[ 37.661193] usbcore: registered new interface driver uas
[ 37.661292] queue_bulk_sg_tx: num=1 sg=880447764500 addr=45af41000 len=0
pagelink=ea00116bd042
[ 37.661550] queue_bulk_sg_tx: num=1 sg=8804483fb600 addr=45af41000 len=0
pagelink=ea00116bd042
[ 37.661744] scsi 6:0:0:0: Direct-Access Plugable USB3-SATA-UASP1 0
PQ: 0 ANSI: 6
[ 37.661865] queue_bulk_sg_tx: num=1 sg=8804483fba00 addr=45af41000 len=0
pagelink=ea00116bd042
[ 37.662053] queue_bulk_sg_tx: num=1 sg=8804483fba00 addr=45af41000 len=0
pagelink=ea00116bd042
[ 37.662294] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45af41000 len=0
pagelink=ea00116bd042
[ 37.662488] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45b6ab000 len=0
pagelink=ea00116daac2
[ 37.663041] sd 6:0:0:0: Attached scsi generic sg2 type 0
[ 37.663138] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=44897c000 len=0
pagelink=ea0011225f02
[ 37.664420] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149
GiB)
[ 37.664599] queue_bulk_sg_tx: num=1 sg=880447764400 addr=45b5c len=0
pagelink=ea00116d7002
[ 37.664833] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45b5c len=0
pagelink=ea00116d7002
[ 37.665022] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45b5c len=0
pagelink=ea00116d7002
[ 37.665255] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45b5c len=0
pagelink=ea00116d7002
[ 37.665421] sd 6:0:0:0: [sdc] Write Protect is off
[ 37.665532] queue_bulk_sg_tx: num=1 sg=88045b9e0a00 addr=45b5c len=0
pagelink=ea00116d7002
[ 37.665735] queue_bulk_sg_tx: num=1 sg=88045b9e0a00 addr=45b5c len=0
pagelink=ea00116d7002
[ 37.665877] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 37.666003] queue_bulk_sg_tx: num=1 sg=88045b9e1700 addr=4587a8e00 len=0
pagelink=ea001161ea02
[ 37.666293] queue_bulk_sg_tx: num=1 sg=88045b9e1700 addr=45b5c len=0
pagelink=ea00116d7002
[ 37.670190] queue_bulk_sg_tx: num=1 sg=88045b9e1600 addr=44897c000 len=0
pagelink=ea0011225f02
[ 37.676364] queue_bulk_sg_tx: num=1 sg=88045b9e0e00 addr=457692000 len=0
pagelink=ea00115da482
[ 37.681800] queue_bulk_sg_tx: num=1 sg=88045b9e0e00 addr=457692000 len=0
pagelink=ea00115da482
[ 37.687125] queue_bulk_sg_tx: num=1 sg=88045b9e0e00 addr=457692000 len=0
pagelink=ea00115da482
[ 37.692335] queue_bulk_sg_tx: num=1 sg=88045b9e0e00 addr=457692000 len=0
pagelink=ea00115da482
[ 37.697451] queue_bulk_sg_tx: num=1 sg=88045b9e0e00 addr=457692000 len=0
pagelink=ea00115da482
[ 37.702429] queue_bulk_sg_tx: num=1 sg=88045b9e0e00 addr=457692000 len=0
pagelink=ea00115da482
[ 37.707312] queue_bulk_sg_tx: num=1 sg=88045b9e0e00 addr=457692000 len=0
pagelink=ea00115da482
[ 37.712109] queue_bulk_sg_tx: num=1 sg=88045b9e0e00 addr=448b560
Re: [PATCH net v5 2/7] cxgb4i: fix credit check for tx_data_wr
Hello. On 12/10/2014 4:43 AM, Karen Xie wrote: [PATCH net v5 2/7] cxgb4i: fix credit check for tx_data_wr From: Karen Xie make sure any tx credit related checking is done before adding the wr header. Signed-off-by: Karen Xie --- drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c index f119a67..56dbd25 100644 --- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c +++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c @@ -547,15 +547,16 @@ static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb, [...] req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) | - FW_WR_COMPL(1) | - FW_WR_IMMDLEN(dlen)); + FW_WR_COMPL(1) | + FW_WR_IMMDLEN(dlen)); req->flowid_len16 = htonl(FW_WR_FLOWID(csk->tid) | - FW_WR_LEN16(credits)); + FW_WR_LEN16(credits)); The above looks like unrelated cleanup, worth putting in a separate net-next patch... WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v6 2/7] cxgb4i: fix credit check for tx_data_wr
[PATCH net v6 2/7] cxgb4i: fix credit check for tx_data_wr
From: Karen Xie
make sure any tx credit related checking is done before adding the wr header.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index f119a67..abee611 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -547,10 +547,11 @@ static inline void make_tx_data_wr(struct cxgbi_sock
*csk, struct sk_buff *skb,
struct fw_ofld_tx_data_wr *req;
unsigned int submode = cxgbi_skcb_ulp_mode(skb) & 3;
unsigned int wr_ulp_mode = 0;
+ bool imm = is_ofld_imm(skb);
req = (struct fw_ofld_tx_data_wr *)__skb_push(skb, sizeof(*req));
- if (is_ofld_imm(skb)) {
+ if (imm) {
req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
FW_WR_IMMDLEN(dlen));
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v6 1/7] cxgb4i: fix tx immediate data credit check
[PATCH net v6 1/7] cxgb4i: fix tx immediate data credit check
From: Karen Xie
Only data skbs need the wr header added while control skbs do not. Make sure
they are treated differently.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 +++---
drivers/scsi/cxgbi/libcxgbi.h |4 ++--
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1508125..f119a67 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -171,10 +171,14 @@ static int push_tx_frames(struct cxgbi_sock *, int);
* Returns true if a packet can be sent as an offload WR with immediate
* data. We currently use the same limit as for Ethernet packets.
*/
-static inline int is_ofld_imm(const struct sk_buff *skb)
+static inline bool is_ofld_imm(const struct sk_buff *skb)
{
- return skb->len <= (MAX_IMM_TX_PKT_LEN -
- sizeof(struct fw_ofld_tx_data_wr));
+ int len = skb->len;
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ len += sizeof(struct fw_ofld_tx_data_wr);
+
+ return len <= MAX_IMM_TX_PKT_LEN;
}
static void send_act_open_req(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -597,11 +601,15 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
- credits_needed = DIV_ROUND_UP(dlen +
- sizeof(struct fw_ofld_tx_data_wr), 16);
+ credits_needed = DIV_ROUND_UP(dlen, 16);
else
- credits_needed = DIV_ROUND_UP(8*calc_tx_flits_ofld(skb)
- + sizeof(struct fw_ofld_tx_data_wr),
+ credits_needed = DIV_ROUND_UP(
+ 8 * calc_tx_flits_ofld(skb),
+ 16);
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ credits_needed += DIV_ROUND_UP(
+ sizeof(struct fw_ofld_tx_data_wr),
16);
if (csk->wr_cred < credits_needed) {
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 2c7cb1c..aba1af7 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -317,8 +317,8 @@ static inline void cxgbi_skcb_clear_flag(struct sk_buff
*skb,
__clear_bit(flag, &(cxgbi_skcb_flags(skb)));
}
-static inline int cxgbi_skcb_test_flag(struct sk_buff *skb,
- enum cxgbi_skcb_flags flag)
+static inline int cxgbi_skcb_test_flag(const struct sk_buff *skb,
+ enum cxgbi_skcb_flags flag)
{
return test_bit(flag, &(cxgbi_skcb_flags(skb)));
}
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v6 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
[PATCH net v6 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i This patch set fixes cxgb4i's tx credit calculation and adds handling of additional rx message and negative advice types. It also removes the duplicate code in cxgb4i to set the outgoing queues of a packet. Karen Xie (7): cxgb4i: fix tx immediate data credit check cxgb4i: fix credit check for tx_data_wr cxgb4/cxgb4i: set max. outgoing pdu length in the f/w cxgb4i: add more types of negative advice cxgb4i: handle non pdu-aligned rx data cxgb4i: use cxgb4's set_wr_txq() for setting outgoing queues libcxgbi: fix the debug print accessing skb after it is freed Sending to net as the fixes are mostly in the network area and it touches cxgb4's header file (t4fw_api.h). v2 corrects the "CHECK"s flagged by checkpatch.pl --strict. v3 splits the 3rd patch from v2 to two separate patches. Adds detailed commit messages and makes subject more concise. Patch 3/6 also changes the return value of is_neg_adv() from int to bool. v4 -- please ignore. v5 splits the 1st patch from v3 to two separate patches and reduces code duplication in make_tx_data_wr(). v6 removed the code style cleanup in the 2nd patch. The style update will be addressed in a separate patch. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v6 4/7] cxgb4i: additional types of negative advice
[PATCH net v6 4/7] cxgb4i: additional types of negative advice
From: Karen Xie
Treat both CPL_ERR_KEEPALV_NEG_ADVICE and CPL_ERR_PERSIST_NEG_ADVICE as
negative advice.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 5f31eb7..2880f200 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -846,6 +846,13 @@ static void csk_act_open_retry_timer(unsigned long data)
}
+static inline bool is_neg_adv(unsigned int status)
+{
+ return status == CPL_ERR_RTX_NEG_ADVICE ||
+ status == CPL_ERR_KEEPALV_NEG_ADVICE ||
+ status == CPL_ERR_PERSIST_NEG_ADVICE;
+}
+
static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -867,7 +874,7 @@ static void do_act_open_rpl(struct cxgbi_device *cdev,
struct sk_buff *skb)
"csk 0x%p,%u,0x%lx. ", (&csk->saddr), (&csk->daddr),
atid, tid, status, csk, csk->state, csk->flags);
- if (status == CPL_ERR_RTX_NEG_ADVICE)
+ if (is_neg_adv(status))
goto rel_skb;
module_put(THIS_MODULE);
@@ -973,8 +980,7 @@ static void do_abort_req_rss(struct cxgbi_device *cdev,
struct sk_buff *skb)
(&csk->saddr), (&csk->daddr),
csk, csk->state, csk->flags, csk->tid, req->status);
- if (req->status == CPL_ERR_RTX_NEG_ADVICE ||
- req->status == CPL_ERR_PERSIST_NEG_ADVICE)
+ if (is_neg_adv(req->status))
goto rel_skb;
cxgbi_sock_get(csk);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v6 6/7] cxgb4i: use set_wr_txq() to set tx queues
[PATCH net v6 6/7] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie
use cxgb4's set_wr_txq() for setting of the tx queue for a outgoing packet.
Remove the similar function in cxgb4i.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index dff7345..6aa50fc 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -157,12 +157,6 @@ static struct scsi_transport_template *cxgb4i_stt;
#define RCV_BUFSIZ_MASK0x3FFU
#define MAX_IMM_TX_PKT_LEN 128
-static inline void set_queue(struct sk_buff *skb, unsigned int queue,
- const struct cxgbi_sock *csk)
-{
- skb->queue_mapping = queue;
-}
-
static int push_tx_frames(struct cxgbi_sock *, int);
/*
@@ -404,7 +398,7 @@ static void send_abort_req(struct cxgbi_sock *csk)
csk->cpl_abort_req = NULL;
req = (struct cpl_abort_req *)skb->head;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
req->cmd = CPL_ABORT_SEND_RST;
t4_set_arp_err_handler(skb, csk, abort_arp_failure);
INIT_TP_WR(req, csk->tid);
@@ -430,7 +424,7 @@ static void send_abort_rpl(struct cxgbi_sock *csk, int
rst_status)
csk, csk->state, csk->flags, csk->tid, rst_status);
csk->cpl_abort_rpl = NULL;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
INIT_TP_WR(rpl, csk->tid);
OPCODE_TID(rpl) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_RPL, csk->tid));
rpl->cmd = rst_status;
@@ -555,7 +549,7 @@ static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
flowc->mnemval[8].val = 16384;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
"csk 0x%p, tid 0x%x, %u,%u,%u,%u,%u,%u,%u.\n",
@@ -660,7 +654,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
break;
}
__skb_unlink(skb, &csk->write_queue);
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
@@ -1552,7 +1546,7 @@ static int ddp_ppod_write_idata(struct cxgbi_device
*cdev, unsigned int port_id,
return -ENOMEM;
}
req = (struct ulp_mem_io *)skb->head;
- set_queue(skb, CPL_PRIORITY_CONTROL, NULL);
+ set_wr_txq(skb, CPL_PRIORITY_CONTROL, 0);
ulp_mem_io_set_hdr(lldi, req, wr_len, dlen, pm_addr);
idata = (struct ulptx_idata *)(req + 1);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v6 5/7] cxgb4i: handle non-pdu-aligned rx data
[PATCH net v6 5/7] cxgb4i: handle non-pdu-aligned rx data
From: Karen Xie
Abort the connection upon receiving of cpl_rx_data, which means the pdu cannot
be recovered from the tcp stream. This generally is due to pdu header
corruption.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 2880f200..dff7345 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1034,6 +1034,27 @@ rel_skb:
__kfree_skb(skb);
}
+static void do_rx_data(struct cxgbi_device *cdev, struct sk_buff *skb)
+{
+ struct cxgbi_sock *csk;
+ struct cpl_rx_data *cpl = (struct cpl_rx_data *)skb->data;
+ unsigned int tid = GET_TID(cpl);
+ struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
+ struct tid_info *t = lldi->tids;
+
+ csk = lookup_tid(t, tid);
+ if (!csk) {
+ pr_err("can't find connection for tid %u.\n", tid);
+ } else {
+ /* not expecting this, reset the connection. */
+ pr_err("csk 0x%p, tid %u, rcv cpl_rx_data.\n", csk, tid);
+ spin_lock_bh(&csk->lock);
+ send_abort_req(csk);
+ spin_unlock_bh(&csk->lock);
+ }
+ __kfree_skb(skb);
+}
+
static void do_rx_iscsi_hdr(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -1453,6 +1474,7 @@ cxgb4i_cplhandler_func cxgb4i_cplhandlers[NUM_CPL_CMDS] =
{
[CPL_SET_TCB_RPL] = do_set_tcb_rpl,
[CPL_RX_DATA_DDP] = do_rx_data_ddp,
[CPL_RX_ISCSI_DDP] = do_rx_data_ddp,
+ [CPL_RX_DATA] = do_rx_data,
};
int cxgb4i_ofld_init(struct cxgbi_device *cdev)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v6 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
[PATCH net v6 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware.
From: Karen Xie
Programs the firmware of the maximum outgoing iscsi pdu length per connection.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 69 +++-
1 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 3409756..743a350 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -529,6 +529,7 @@ enum fw_flowc_mnem {
FW_FLOWC_MNEM_RCVNXT,
FW_FLOWC_MNEM_SNDBUF,
FW_FLOWC_MNEM_MSS,
+ FW_FLOWC_MNEM_TXDATAPLEN_MAX,
};
struct fw_flowc_mnemval {
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index abee611..5f31eb7 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -75,6 +75,7 @@ typedef void (*cxgb4i_cplhandler_func)(struct cxgbi_device *,
struct sk_buff *);
static void *t4_uld_add(const struct cxgb4_lld_info *);
static int t4_uld_rx_handler(void *, const __be64 *, const struct pkt_gl *);
static int t4_uld_state_change(void *, enum cxgb4_state state);
+static inline int send_tx_flowc_wr(struct cxgbi_sock *);
static const struct cxgb4_uld_info cxgb4i_uld_info = {
.name = DRV_MODULE_NAME,
@@ -391,6 +392,12 @@ static void send_abort_req(struct cxgbi_sock *csk)
if (unlikely(csk->state == CTP_ABORTING) || !skb || !csk->cdev)
return;
+
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ send_tx_flowc_wr(csk);
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
cxgbi_sock_set_state(csk, CTP_ABORTING);
cxgbi_sock_set_flag(csk, CTPF_ABORT_RPL_PENDING);
cxgbi_sock_purge_write_queue(csk);
@@ -493,20 +500,40 @@ static inline unsigned int calc_tx_flits_ofld(const
struct sk_buff *skb)
return flits + sgl_len(cnt);
}
-static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
+#define FLOWC_WR_NPARAMS_MIN 9
+static inline int tx_flowc_wr_credits(int *nparamsp, int *flowclenp)
+{
+ int nparams, flowclen16, flowclen;
+
+ nparams = FLOWC_WR_NPARAMS_MIN;
+ flowclen = offsetof(struct fw_flowc_wr, mnemval[nparams]);
+ flowclen16 = DIV_ROUND_UP(flowclen, 16);
+ flowclen = flowclen16 * 16;
+ /*
+* Return the number of 16-byte credits used by the FlowC request.
+* Pass back the nparams and actual FlowC length if requested.
+*/
+ if (nparamsp)
+ *nparamsp = nparams;
+ if (flowclenp)
+ *flowclenp = flowclen;
+
+ return flowclen16;
+}
+
+static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
{
struct sk_buff *skb;
struct fw_flowc_wr *flowc;
- int flowclen, i;
+ int nparams, flowclen16, flowclen;
- flowclen = 80;
+ flowclen16 = tx_flowc_wr_credits(&nparams, &flowclen);
skb = alloc_wr(flowclen, 0, GFP_ATOMIC);
flowc = (struct fw_flowc_wr *)skb->head;
flowc->op_to_nparams =
- htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(8));
+ htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(nparams));
flowc->flowid_len16 =
- htonl(FW_WR_LEN16(DIV_ROUND_UP(72, 16)) |
- FW_WR_FLOWID(csk->tid));
+ htonl(FW_WR_LEN16(flowclen16) | FW_WR_FLOWID(csk->tid));
flowc->mnemval[0].mnemonic = FW_FLOWC_MNEM_PFNVFN;
flowc->mnemval[0].val = htonl(csk->cdev->pfvf);
flowc->mnemval[1].mnemonic = FW_FLOWC_MNEM_CH;
@@ -525,11 +552,9 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[7].val = htonl(csk->advmss);
flowc->mnemval[8].mnemonic = 0;
flowc->mnemval[8].val = 0;
- for (i = 0; i < 9; i++) {
- flowc->mnemval[i].r4[0] = 0;
- flowc->mnemval[i].r4[1] = 0;
- flowc->mnemval[i].r4[2] = 0;
- }
+ flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
+ flowc->mnemval[8].val = 16384;
+
set_queue(skb, CPL_PRIORITY_DATA, csk);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
@@ -539,6 +564,8 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
csk->advmss);
cxgb4_ofld_send(csk->cdev->ports[csk->port_id], skb);
+
+ return flowclen16;
}
static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -599,6 +626,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
int dlen = skb->len;
int len = skb->len;
unsigned int credits_needed;
+ int flowclen16 = 0;
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
@@ -613,6 +641,17 @@ static int push_tx_frames
[PATCH net v6 7/7] libcxgbi: free skb after debug prints
[PATCH net v6 7/7] libcxgbi: free skb after debug prints From: Karen Xie The debug print was accessing the skb after it was freed. Signed-off-by: Karen Xie --- drivers/scsi/cxgbi/libcxgbi.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c index 7da59c3..eb58afc 100644 --- a/drivers/scsi/cxgbi/libcxgbi.c +++ b/drivers/scsi/cxgbi/libcxgbi.c @@ -2294,10 +2294,12 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task) return err; } - kfree_skb(skb); log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_PDU_TX, "itt 0x%x, skb 0x%p, len %u/%u, xmit err %d.\n", task->itt, skb, skb->len, skb->data_len, err); + + kfree_skb(skb); + iscsi_conn_printk(KERN_ERR, task->conn, "xmit err %d.\n", err); iscsi_conn_failure(task->conn, ISCSI_ERR_XMIT_FAILED); return err; -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net v5 2/7] cxgb4i: fix credit check for tx_data_wr
Thanks for the review. V6 has been submitted to address this. -Original Message- From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com] Sent: Wednesday, December 10, 2014 6:09 AM To: Karen Xie; linux-scsi@vger.kernel.org; net...@vger.kernel.org Cc: Hariprasad S; Anish Bhatt; h...@infradead.org; james.bottom...@hansenpartnership.com; micha...@cs.wisc.edu; da...@davemloft.net Subject: Re: [PATCH net v5 2/7] cxgb4i: fix credit check for tx_data_wr Hello. On 12/10/2014 4:43 AM, Karen Xie wrote: > [PATCH net v5 2/7] cxgb4i: fix credit check for tx_data_wr > From: Karen Xie > make sure any tx credit related checking is done before adding the wr header. > Signed-off-by: Karen Xie > --- > drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |9 + > 1 files changed, 5 insertions(+), 4 deletions(-) > diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c > b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c > index f119a67..56dbd25 100644 > --- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c > +++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c > @@ -547,15 +547,16 @@ static inline void make_tx_data_wr(struct > cxgbi_sock *csk, struct sk_buff *skb, [...] > req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) | > - FW_WR_COMPL(1) | > - FW_WR_IMMDLEN(dlen)); > +FW_WR_COMPL(1) | > +FW_WR_IMMDLEN(dlen)); > req->flowid_len16 = htonl(FW_WR_FLOWID(csk->tid) | > - FW_WR_LEN16(credits)); > + FW_WR_LEN16(credits)); The above looks like unrelated cleanup, worth putting in a separate net-next patch... WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 89531] New: mpt2sas: only every second disk working with PCIe x4 connection
https://bugzilla.kernel.org/show_bug.cgi?id=89531 Bug ID: 89531 Summary: mpt2sas: only every second disk working with PCIe x4 connection Product: SCSI Drivers Version: 2.5 Kernel Version: 3.16.5 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Other Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org Reporter: abu...@cs.tu-berlin.de Regression: No Created attachment 160351 --> https://bugzilla.kernel.org/attachment.cgi?id=160351&action=edit syslog I have an SAS controller with LSI SAS 2008 controller in a PCIe slot with only four lanes where the card can use up to eight lanes. I have the following issue. Lets assume there are four drives attached to the controller (sda...sdd). I use the following simple benchmark "cat /dev/sdX | pipebench > /dev/null". When accessing every drive individually, every thing works fine. However when I run the experiment on sda and sdb concurrently, it still works on sda but the benchmarks stalls on sdb. When I kill the benchmark after some seconds I see the error messages in the attachment. However, it gets more strange. When I run the benchmark concurrently on sda and sdc every thing works as expected. When trying to read sdb or sdd concurrently it always results in the error described above. I also tried to change the hardware setup and only used every second connection of the card. However the result stayed the same: concurrent access to every second disk fails. In the same machine I have the same SAS controller model in a PCIe x16 slot and there every thing works like a charm. I also swaped the cards and the issue stays with the PCIe x4 slot. So a defective card as the source of the problem can be ruled out. Thank you -- You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net v6 7/7] libcxgbi: free skb after debug prints
Hello. On 12/10/2014 07:25 PM, Karen Xie wrote: [PATCH net v6 7/7] libcxgbi: free skb after debug prints Please, do not duplicate the subject in the changelog -- DaveM would have to edit it out by hand. From: Karen Xie The debug print was accessing the skb after it was freed. Signed-off-by: Karen Xie WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v7 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
[PATCH net v7 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i This patch set fixes cxgb4i's tx credit calculation and adds handling of additional rx message and negative advice types. It also removes the duplicate code in cxgb4i to set the outgoing queues of a packet. Karen Xie (7): cxgb4i: fix tx immediate data credit check cxgb4i: fix credit check for tx_data_wr cxgb4/cxgb4i: set max. outgoing pdu length in the f/w cxgb4i: add more types of negative advice cxgb4i: handle non pdu-aligned rx data cxgb4i: use cxgb4's set_wr_txq() for setting outgoing queues libcxgbi: fix the debug print accessing skb after it is freed Sending to net as the fixes are mostly in the network area and it touches cxgb4's header file (t4fw_api.h). v2 corrects the "CHECK"s flagged by checkpatch.pl --strict. v3 splits the 3rd patch from v2 to two separate patches. Adds detailed commit messages and makes subject more concise. Patch 3/6 also changes the return value of is_neg_adv() from int to bool. v4 -- please ignore. v5 splits the 1st patch from v3 to two separate patches and reduces code duplication in make_tx_data_wr(). v6 removed the code style cleanup in the 2nd patch. The style update will be addressed in a separate patch. v7 updates the 7th patch with more detailed commit message. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
[PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware.
From: Karen Xie
Programs the firmware of the maximum outgoing iscsi pdu length per connection.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 69 +++-
1 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 3409756..743a350 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -529,6 +529,7 @@ enum fw_flowc_mnem {
FW_FLOWC_MNEM_RCVNXT,
FW_FLOWC_MNEM_SNDBUF,
FW_FLOWC_MNEM_MSS,
+ FW_FLOWC_MNEM_TXDATAPLEN_MAX,
};
struct fw_flowc_mnemval {
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index abee611..5f31eb7 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -75,6 +75,7 @@ typedef void (*cxgb4i_cplhandler_func)(struct cxgbi_device *,
struct sk_buff *);
static void *t4_uld_add(const struct cxgb4_lld_info *);
static int t4_uld_rx_handler(void *, const __be64 *, const struct pkt_gl *);
static int t4_uld_state_change(void *, enum cxgb4_state state);
+static inline int send_tx_flowc_wr(struct cxgbi_sock *);
static const struct cxgb4_uld_info cxgb4i_uld_info = {
.name = DRV_MODULE_NAME,
@@ -391,6 +392,12 @@ static void send_abort_req(struct cxgbi_sock *csk)
if (unlikely(csk->state == CTP_ABORTING) || !skb || !csk->cdev)
return;
+
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ send_tx_flowc_wr(csk);
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
cxgbi_sock_set_state(csk, CTP_ABORTING);
cxgbi_sock_set_flag(csk, CTPF_ABORT_RPL_PENDING);
cxgbi_sock_purge_write_queue(csk);
@@ -493,20 +500,40 @@ static inline unsigned int calc_tx_flits_ofld(const
struct sk_buff *skb)
return flits + sgl_len(cnt);
}
-static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
+#define FLOWC_WR_NPARAMS_MIN 9
+static inline int tx_flowc_wr_credits(int *nparamsp, int *flowclenp)
+{
+ int nparams, flowclen16, flowclen;
+
+ nparams = FLOWC_WR_NPARAMS_MIN;
+ flowclen = offsetof(struct fw_flowc_wr, mnemval[nparams]);
+ flowclen16 = DIV_ROUND_UP(flowclen, 16);
+ flowclen = flowclen16 * 16;
+ /*
+* Return the number of 16-byte credits used by the FlowC request.
+* Pass back the nparams and actual FlowC length if requested.
+*/
+ if (nparamsp)
+ *nparamsp = nparams;
+ if (flowclenp)
+ *flowclenp = flowclen;
+
+ return flowclen16;
+}
+
+static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
{
struct sk_buff *skb;
struct fw_flowc_wr *flowc;
- int flowclen, i;
+ int nparams, flowclen16, flowclen;
- flowclen = 80;
+ flowclen16 = tx_flowc_wr_credits(&nparams, &flowclen);
skb = alloc_wr(flowclen, 0, GFP_ATOMIC);
flowc = (struct fw_flowc_wr *)skb->head;
flowc->op_to_nparams =
- htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(8));
+ htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(nparams));
flowc->flowid_len16 =
- htonl(FW_WR_LEN16(DIV_ROUND_UP(72, 16)) |
- FW_WR_FLOWID(csk->tid));
+ htonl(FW_WR_LEN16(flowclen16) | FW_WR_FLOWID(csk->tid));
flowc->mnemval[0].mnemonic = FW_FLOWC_MNEM_PFNVFN;
flowc->mnemval[0].val = htonl(csk->cdev->pfvf);
flowc->mnemval[1].mnemonic = FW_FLOWC_MNEM_CH;
@@ -525,11 +552,9 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[7].val = htonl(csk->advmss);
flowc->mnemval[8].mnemonic = 0;
flowc->mnemval[8].val = 0;
- for (i = 0; i < 9; i++) {
- flowc->mnemval[i].r4[0] = 0;
- flowc->mnemval[i].r4[1] = 0;
- flowc->mnemval[i].r4[2] = 0;
- }
+ flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
+ flowc->mnemval[8].val = 16384;
+
set_queue(skb, CPL_PRIORITY_DATA, csk);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
@@ -539,6 +564,8 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
csk->advmss);
cxgb4_ofld_send(csk->cdev->ports[csk->port_id], skb);
+
+ return flowclen16;
}
static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -599,6 +626,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
int dlen = skb->len;
int len = skb->len;
unsigned int credits_needed;
+ int flowclen16 = 0;
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
@@ -613,6 +641,17 @@ static int push_tx_frames
[PATCH net v7 6/7] cxgb4i: use set_wr_txq() to set tx queues
[PATCH net v7 6/7] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie
use cxgb4's set_wr_txq() for setting of the tx queue for a outgoing packet.
Remove the similar function in cxgb4i.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index dff7345..6aa50fc 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -157,12 +157,6 @@ static struct scsi_transport_template *cxgb4i_stt;
#define RCV_BUFSIZ_MASK0x3FFU
#define MAX_IMM_TX_PKT_LEN 128
-static inline void set_queue(struct sk_buff *skb, unsigned int queue,
- const struct cxgbi_sock *csk)
-{
- skb->queue_mapping = queue;
-}
-
static int push_tx_frames(struct cxgbi_sock *, int);
/*
@@ -404,7 +398,7 @@ static void send_abort_req(struct cxgbi_sock *csk)
csk->cpl_abort_req = NULL;
req = (struct cpl_abort_req *)skb->head;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
req->cmd = CPL_ABORT_SEND_RST;
t4_set_arp_err_handler(skb, csk, abort_arp_failure);
INIT_TP_WR(req, csk->tid);
@@ -430,7 +424,7 @@ static void send_abort_rpl(struct cxgbi_sock *csk, int
rst_status)
csk, csk->state, csk->flags, csk->tid, rst_status);
csk->cpl_abort_rpl = NULL;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
INIT_TP_WR(rpl, csk->tid);
OPCODE_TID(rpl) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_RPL, csk->tid));
rpl->cmd = rst_status;
@@ -555,7 +549,7 @@ static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
flowc->mnemval[8].val = 16384;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
"csk 0x%p, tid 0x%x, %u,%u,%u,%u,%u,%u,%u.\n",
@@ -660,7 +654,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
break;
}
__skb_unlink(skb, &csk->write_queue);
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
@@ -1552,7 +1546,7 @@ static int ddp_ppod_write_idata(struct cxgbi_device
*cdev, unsigned int port_id,
return -ENOMEM;
}
req = (struct ulp_mem_io *)skb->head;
- set_queue(skb, CPL_PRIORITY_CONTROL, NULL);
+ set_wr_txq(skb, CPL_PRIORITY_CONTROL, 0);
ulp_mem_io_set_hdr(lldi, req, wr_len, dlen, pm_addr);
idata = (struct ulptx_idata *)(req + 1);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v7 5/7] cxgb4i: handle non-pdu-aligned rx data
[PATCH net v7 5/7] cxgb4i: handle non-pdu-aligned rx data
From: Karen Xie
Abort the connection upon receiving of cpl_rx_data, which means the pdu cannot
be recovered from the tcp stream. This generally is due to pdu header
corruption.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 2880f200..dff7345 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1034,6 +1034,27 @@ rel_skb:
__kfree_skb(skb);
}
+static void do_rx_data(struct cxgbi_device *cdev, struct sk_buff *skb)
+{
+ struct cxgbi_sock *csk;
+ struct cpl_rx_data *cpl = (struct cpl_rx_data *)skb->data;
+ unsigned int tid = GET_TID(cpl);
+ struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
+ struct tid_info *t = lldi->tids;
+
+ csk = lookup_tid(t, tid);
+ if (!csk) {
+ pr_err("can't find connection for tid %u.\n", tid);
+ } else {
+ /* not expecting this, reset the connection. */
+ pr_err("csk 0x%p, tid %u, rcv cpl_rx_data.\n", csk, tid);
+ spin_lock_bh(&csk->lock);
+ send_abort_req(csk);
+ spin_unlock_bh(&csk->lock);
+ }
+ __kfree_skb(skb);
+}
+
static void do_rx_iscsi_hdr(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -1453,6 +1474,7 @@ cxgb4i_cplhandler_func cxgb4i_cplhandlers[NUM_CPL_CMDS] =
{
[CPL_SET_TCB_RPL] = do_set_tcb_rpl,
[CPL_RX_DATA_DDP] = do_rx_data_ddp,
[CPL_RX_ISCSI_DDP] = do_rx_data_ddp,
+ [CPL_RX_DATA] = do_rx_data,
};
int cxgb4i_ofld_init(struct cxgbi_device *cdev)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v7 2/7] cxgb4i: fix credit check for tx_data_wr
[PATCH net v7 2/7] cxgb4i: fix credit check for tx_data_wr
From: Karen Xie
make sure any tx credit related checking is done before adding the wr header.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index f119a67..abee611 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -547,10 +547,11 @@ static inline void make_tx_data_wr(struct cxgbi_sock
*csk, struct sk_buff *skb,
struct fw_ofld_tx_data_wr *req;
unsigned int submode = cxgbi_skcb_ulp_mode(skb) & 3;
unsigned int wr_ulp_mode = 0;
+ bool imm = is_ofld_imm(skb);
req = (struct fw_ofld_tx_data_wr *)__skb_push(skb, sizeof(*req));
- if (is_ofld_imm(skb)) {
+ if (imm) {
req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
FW_WR_IMMDLEN(dlen));
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v7 4/7] cxgb4i: additional types of negative advice
[PATCH net v7 4/7] cxgb4i: additional types of negative advice
From: Karen Xie
Treat both CPL_ERR_KEEPALV_NEG_ADVICE and CPL_ERR_PERSIST_NEG_ADVICE as
negative advice.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 5f31eb7..2880f200 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -846,6 +846,13 @@ static void csk_act_open_retry_timer(unsigned long data)
}
+static inline bool is_neg_adv(unsigned int status)
+{
+ return status == CPL_ERR_RTX_NEG_ADVICE ||
+ status == CPL_ERR_KEEPALV_NEG_ADVICE ||
+ status == CPL_ERR_PERSIST_NEG_ADVICE;
+}
+
static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -867,7 +874,7 @@ static void do_act_open_rpl(struct cxgbi_device *cdev,
struct sk_buff *skb)
"csk 0x%p,%u,0x%lx. ", (&csk->saddr), (&csk->daddr),
atid, tid, status, csk, csk->state, csk->flags);
- if (status == CPL_ERR_RTX_NEG_ADVICE)
+ if (is_neg_adv(status))
goto rel_skb;
module_put(THIS_MODULE);
@@ -973,8 +980,7 @@ static void do_abort_req_rss(struct cxgbi_device *cdev,
struct sk_buff *skb)
(&csk->saddr), (&csk->daddr),
csk, csk->state, csk->flags, csk->tid, req->status);
- if (req->status == CPL_ERR_RTX_NEG_ADVICE ||
- req->status == CPL_ERR_PERSIST_NEG_ADVICE)
+ if (is_neg_adv(req->status))
goto rel_skb;
cxgbi_sock_get(csk);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v7 1/7] cxgb4i: fix tx immediate data credit check
[PATCH net v7 1/7] cxgb4i: fix tx immediate data credit check
From: Karen Xie
Only data skbs need the wr header added while control skbs do not. Make sure
they are treated differently.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 +++---
drivers/scsi/cxgbi/libcxgbi.h |4 ++--
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1508125..f119a67 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -171,10 +171,14 @@ static int push_tx_frames(struct cxgbi_sock *, int);
* Returns true if a packet can be sent as an offload WR with immediate
* data. We currently use the same limit as for Ethernet packets.
*/
-static inline int is_ofld_imm(const struct sk_buff *skb)
+static inline bool is_ofld_imm(const struct sk_buff *skb)
{
- return skb->len <= (MAX_IMM_TX_PKT_LEN -
- sizeof(struct fw_ofld_tx_data_wr));
+ int len = skb->len;
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ len += sizeof(struct fw_ofld_tx_data_wr);
+
+ return len <= MAX_IMM_TX_PKT_LEN;
}
static void send_act_open_req(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -597,11 +601,15 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
- credits_needed = DIV_ROUND_UP(dlen +
- sizeof(struct fw_ofld_tx_data_wr), 16);
+ credits_needed = DIV_ROUND_UP(dlen, 16);
else
- credits_needed = DIV_ROUND_UP(8*calc_tx_flits_ofld(skb)
- + sizeof(struct fw_ofld_tx_data_wr),
+ credits_needed = DIV_ROUND_UP(
+ 8 * calc_tx_flits_ofld(skb),
+ 16);
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ credits_needed += DIV_ROUND_UP(
+ sizeof(struct fw_ofld_tx_data_wr),
16);
if (csk->wr_cred < credits_needed) {
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 2c7cb1c..aba1af7 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -317,8 +317,8 @@ static inline void cxgbi_skcb_clear_flag(struct sk_buff
*skb,
__clear_bit(flag, &(cxgbi_skcb_flags(skb)));
}
-static inline int cxgbi_skcb_test_flag(struct sk_buff *skb,
- enum cxgbi_skcb_flags flag)
+static inline int cxgbi_skcb_test_flag(const struct sk_buff *skb,
+ enum cxgbi_skcb_flags flag)
{
return test_bit(flag, &(cxgbi_skcb_flags(skb)));
}
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v7 7/7] libcxgbi: fix freeing skb prematurely
[PATCH net v7 7/7] libcxgbi: fix freeing skb too early From: Karen Xie With debug turned on the debug print would access the skb after it is freed. Fix it to free the skb after the debug print. Signed-off-by: Karen Xie --- drivers/scsi/cxgbi/libcxgbi.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c index 7da59c3..eb58afc 100644 --- a/drivers/scsi/cxgbi/libcxgbi.c +++ b/drivers/scsi/cxgbi/libcxgbi.c @@ -2294,10 +2294,12 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task) return err; } - kfree_skb(skb); log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_PDU_TX, "itt 0x%x, skb 0x%p, len %u/%u, xmit err %d.\n", task->itt, skb, skb->len, skb->data_len, err); + + kfree_skb(skb); + iscsi_conn_printk(KERN_ERR, task->conn, "xmit err %d.\n", err); iscsi_conn_failure(task->conn, ISCSI_ERR_XMIT_FAILED); return err; -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net v6 7/7] libcxgbi: free skb after debug prints
Thanks, v7 has been submitted to address your comment. Please review. From: Sergei Shtylyov [sergei.shtyl...@cogentembedded.com] Sent: Wednesday, December 10, 2014 11:38 AM To: Karen Xie; linux-scsi@vger.kernel.org; net...@vger.kernel.org Cc: Hariprasad S; Anish Bhatt; h...@infradead.org; james.bottom...@hansenpartnership.com; micha...@cs.wisc.edu; da...@davemloft.net Subject: Re: [PATCH net v6 7/7] libcxgbi: free skb after debug prints Hello. On 12/10/2014 07:25 PM, Karen Xie wrote: > [PATCH net v6 7/7] libcxgbi: free skb after debug prints Please, do not duplicate the subject in the changelog -- DaveM would have to edit it out by hand. > From: Karen Xie > The debug print was accessing the skb after it was freed. > Signed-off-by: Karen Xie WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
From: Karen Xie Date: Wed, 10 Dec 2014 12:24:09 -0800 > [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware. Please listen to the feedback you have been given. Again, you should not duplicate the Subject line in your message body, that makes more work for the people integrating your patches as we have to remove all of these things by hand. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net v6 7/7] libcxgbi: free skb after debug prints
From: Karen Xie Date: Wed, 10 Dec 2014 20:26:59 + > Thanks, v7 has been submitted to address your comment. Please review. Sorry, you did not actually address his comments. He said to not duplicate your Subject lines in your message bodies, and you did not fix that. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/22] [SCSI] mpt2sas: Complete the SCSI command with DID_RESET status for log_info value 0x0x32010081
> "Sreekanth" == Sreekanth Reddy writes: Sreekanth> For any SCSI command, if the driver receives IOC status = Sreekanth> SCSI_IOC_TERMINATED and log info = 0x32010081 then that Sreekanth> command will be completed with DID_RESET host status. >> >> What does that log info value mean? Sreekanth> The meaning of this log info value is "Virtual IO has failed Sreekanth> and has to be retried". OK, I'd prefer to see that documented in the patch. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
On Wed, 2014-12-10 at 15:31 -0500, David Miller wrote: > From: Karen Xie > Date: Wed, 10 Dec 2014 12:24:09 -0800 > > > [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware. > > Please listen to the feedback you have been given. > > Again, you should not duplicate the Subject line in your message > body, that makes more work for the people integrating your patches > as we have to remove all of these things by hand. While we're on the subject of making life easier for maintainers, could I put in a plea for threading your patch set? It really does make it easier to find and apply all the patches, especially on a high traffic list where they otherwise get interspersed with other messages. If you don't use git-send-email, which threads automatically, you can thread manually by just making all the other patches a reply to your [PATCH 0/N], James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
From: James Bottomley Date: Wed, 10 Dec 2014 23:41:29 +0300 > On Wed, 2014-12-10 at 15:31 -0500, David Miller wrote: >> From: Karen Xie >> Date: Wed, 10 Dec 2014 12:24:09 -0800 >> >> > [PATCH net v7 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware. >> >> Please listen to the feedback you have been given. >> >> Again, you should not duplicate the Subject line in your message >> body, that makes more work for the people integrating your patches >> as we have to remove all of these things by hand. > > While we're on the subject of making life easier for maintainers, could > I put in a plea for threading your patch set? It really does make it > easier to find and apply all the patches, especially on a high traffic > list where they otherwise get interspersed with other messages. With patchwork I never need to even think about this issue. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/22] [SCSI] mpt2sas, mpt3sas: Added a support to set cpu affinity for each MSIX vector enabled by the HBA
> "Sreekanth" == Sreekanth Reddy writes:
Sreekanth,
@@ -1373,20 +1380,30 @@ _base_assign_reply_queues(struct MPT2SAS_ADAPTER *ioc)
cpu = cpumask_first(cpu_online_mask);
- do {
+ list_for_each_entry(reply_q, &ioc->reply_queue_list, list) {
+
Why are you reverting to iterating over the queues? A while back I fixed
this up so it wouldn't fail when nr_cpus > the number of reply queues.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/22] [SCSI] mpt2sas, mpt3sas: Removing uppper boundary restriction for the module parameter max_sgl_entries
> "Sreekanth" == Sreekanth Reddy writes:
@@ -2486,9 +2486,13 @@ _base_allocate_memory_pools(struct MPT2SAS_ADAPTER *ioc,
int sleep_flag)
/* command line tunables for max sgl entries */
if (max_sgl_entries != -1) {
- ioc->shost->sg_tablesize = (max_sgl_entries <
- MPT2SAS_SG_DEPTH) ? max_sgl_entries :
- MPT2SAS_SG_DEPTH;
+ if (max_sgl_entries > MPT2SAS_SG_DEPTH)
+ printk(MPT2SAS_WARN_FMT
+"setting max_sgl_entries(%d), overriding kernel"
+" defined SCSI_MAX_SG_SEGMENTS(%d)\n", ioc->name,
+ max_sgl_entries, MPT2SAS_SG_DEPTH);
+ ioc->shost->sg_tablesize = min_t(unsigned short,
+max_sgl_entries, SCSI_MAX_SG_CHAIN_SEGMENTS);
} else {
ioc->shost->sg_tablesize = MPT2SAS_SG_DEPTH;
}
Wouldn't it be better to print the new scatterlist limit after it has
been clamped to reflect what it's actually being set to?
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
On Wed, Dec 10, 2014 at 12:38:25AM -0800, Long Li wrote: > MSFT targets currently claim SPC-2 compliance while they implement > post SPC-2 features. With this patch we can correctly handle > WRITE_SAME_16 issues. > > This patch fixes an issue where the flag is setup too late in drive > initialization process. Li, is this a fix for the issue I keep whinging about over in https://lkml.org/lkml/2014/10/21/23 ? If is the same issue you may want to CC Martin on this... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v7 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
[PATCH net v7 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i This patch set fixes cxgb4i's tx credit calculation and adds handling of additional rx message and negative advice types. It also removes the duplicate code in cxgb4i to set the outgoing queues of a packet. Karen Xie (7): cxgb4i: fix tx immediate data credit check cxgb4i: fix credit check for tx_data_wr cxgb4/cxgb4i: set max. outgoing pdu length in the f/w cxgb4i: add more types of negative advice cxgb4i: handle non pdu-aligned rx data cxgb4i: use cxgb4's set_wr_txq() for setting outgoing queues libcxgbi: fix the debug print accessing skb after it is freed Sending to net as the fixes are mostly in the network area and it touches cxgb4's header file (t4fw_api.h). v2 corrects the "CHECK"s flagged by checkpatch.pl --strict. v3 splits the 3rd patch from v2 to two separate patches. Adds detailed commit messages and makes subject more concise. Patch 3/6 also changes the return value of is_neg_adv() from int to bool. v4 -- please ignore. v5 splits the 1st patch from v3 to two separate patches and reduces code duplication in make_tx_data_wr(). v6 removed the code style cleanup in the 2nd patch. The style update will be addressed in a separate patch. v7 updates the 7th patch with more detailed commit message. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net v6 7/7] libcxgbi: free skb after debug prints
Sorry, misread the comment, will resubmit. Thanks. -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Wednesday, December 10, 2014 12:33 PM To: Karen Xie Cc: sergei.shtyl...@cogentembedded.com; linux-scsi@vger.kernel.org; net...@vger.kernel.org; Hariprasad S; Anish Bhatt; h...@infradead.org; james.bottom...@hansenpartnership.com; micha...@cs.wisc.edu Subject: Re: [PATCH net v6 7/7] libcxgbi: free skb after debug prints From: Karen Xie Date: Wed, 10 Dec 2014 20:26:59 + > Thanks, v7 has been submitted to address your comment. Please review. Sorry, you did not actually address his comments. He said to not duplicate your Subject lines in your message bodies, and you did not fix that. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net v6 7/7] libcxgbi: free skb after debug prints
From: Karen Xie Date: Wed, 10 Dec 2014 21:02:34 + > Sorry, misread the comment, will resubmit. Thanks. Please do not top-post. Quote the relevant material, then provide your own content after the quoted material, not before. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v8 1/7] cxgb4i: fix tx immediate data credit check
From: Karen Xie
Only data skbs need the wr header added while control skbs do not. Make sure
they are treated differently.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 +++---
drivers/scsi/cxgbi/libcxgbi.h |4 ++--
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1508125..f119a67 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -171,10 +171,14 @@ static int push_tx_frames(struct cxgbi_sock *, int);
* Returns true if a packet can be sent as an offload WR with immediate
* data. We currently use the same limit as for Ethernet packets.
*/
-static inline int is_ofld_imm(const struct sk_buff *skb)
+static inline bool is_ofld_imm(const struct sk_buff *skb)
{
- return skb->len <= (MAX_IMM_TX_PKT_LEN -
- sizeof(struct fw_ofld_tx_data_wr));
+ int len = skb->len;
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ len += sizeof(struct fw_ofld_tx_data_wr);
+
+ return len <= MAX_IMM_TX_PKT_LEN;
}
static void send_act_open_req(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -597,11 +601,15 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
- credits_needed = DIV_ROUND_UP(dlen +
- sizeof(struct fw_ofld_tx_data_wr), 16);
+ credits_needed = DIV_ROUND_UP(dlen, 16);
else
- credits_needed = DIV_ROUND_UP(8*calc_tx_flits_ofld(skb)
- + sizeof(struct fw_ofld_tx_data_wr),
+ credits_needed = DIV_ROUND_UP(
+ 8 * calc_tx_flits_ofld(skb),
+ 16);
+
+ if (likely(cxgbi_skcb_test_flag(skb, SKCBF_TX_NEED_HDR)))
+ credits_needed += DIV_ROUND_UP(
+ sizeof(struct fw_ofld_tx_data_wr),
16);
if (csk->wr_cred < credits_needed) {
diff --git a/drivers/scsi/cxgbi/libcxgbi.h b/drivers/scsi/cxgbi/libcxgbi.h
index 2c7cb1c..aba1af7 100644
--- a/drivers/scsi/cxgbi/libcxgbi.h
+++ b/drivers/scsi/cxgbi/libcxgbi.h
@@ -317,8 +317,8 @@ static inline void cxgbi_skcb_clear_flag(struct sk_buff
*skb,
__clear_bit(flag, &(cxgbi_skcb_flags(skb)));
}
-static inline int cxgbi_skcb_test_flag(struct sk_buff *skb,
- enum cxgbi_skcb_flags flag)
+static inline int cxgbi_skcb_test_flag(const struct sk_buff *skb,
+ enum cxgbi_skcb_flags flag)
{
return test_bit(flag, &(cxgbi_skcb_flags(skb)));
}
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v8 4/7] cxgb4i: additional types of negative advice
From: Karen Xie
Treat both CPL_ERR_KEEPALV_NEG_ADVICE and CPL_ERR_PERSIST_NEG_ADVICE as
negative advice.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 5f31eb7..2880f200 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -846,6 +846,13 @@ static void csk_act_open_retry_timer(unsigned long data)
}
+static inline bool is_neg_adv(unsigned int status)
+{
+ return status == CPL_ERR_RTX_NEG_ADVICE ||
+ status == CPL_ERR_KEEPALV_NEG_ADVICE ||
+ status == CPL_ERR_PERSIST_NEG_ADVICE;
+}
+
static void do_act_open_rpl(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -867,7 +874,7 @@ static void do_act_open_rpl(struct cxgbi_device *cdev,
struct sk_buff *skb)
"csk 0x%p,%u,0x%lx. ", (&csk->saddr), (&csk->daddr),
atid, tid, status, csk, csk->state, csk->flags);
- if (status == CPL_ERR_RTX_NEG_ADVICE)
+ if (is_neg_adv(status))
goto rel_skb;
module_put(THIS_MODULE);
@@ -973,8 +980,7 @@ static void do_abort_req_rss(struct cxgbi_device *cdev,
struct sk_buff *skb)
(&csk->saddr), (&csk->daddr),
csk, csk->state, csk->flags, csk->tid, req->status);
- if (req->status == CPL_ERR_RTX_NEG_ADVICE ||
- req->status == CPL_ERR_PERSIST_NEG_ADVICE)
+ if (is_neg_adv(req->status))
goto rel_skb;
cxgbi_sock_get(csk);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v8 3/7] cxgb4/cxgb4i: set the max. pdu length in firmware
From: Karen Xie
Programs the firmware of the maximum outgoing iscsi pdu length per connection.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 69 +++-
1 files changed, 51 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
index 3409756..743a350 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h
@@ -529,6 +529,7 @@ enum fw_flowc_mnem {
FW_FLOWC_MNEM_RCVNXT,
FW_FLOWC_MNEM_SNDBUF,
FW_FLOWC_MNEM_MSS,
+ FW_FLOWC_MNEM_TXDATAPLEN_MAX,
};
struct fw_flowc_mnemval {
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index abee611..5f31eb7 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -75,6 +75,7 @@ typedef void (*cxgb4i_cplhandler_func)(struct cxgbi_device *,
struct sk_buff *);
static void *t4_uld_add(const struct cxgb4_lld_info *);
static int t4_uld_rx_handler(void *, const __be64 *, const struct pkt_gl *);
static int t4_uld_state_change(void *, enum cxgb4_state state);
+static inline int send_tx_flowc_wr(struct cxgbi_sock *);
static const struct cxgb4_uld_info cxgb4i_uld_info = {
.name = DRV_MODULE_NAME,
@@ -391,6 +392,12 @@ static void send_abort_req(struct cxgbi_sock *csk)
if (unlikely(csk->state == CTP_ABORTING) || !skb || !csk->cdev)
return;
+
+ if (!cxgbi_sock_flag(csk, CTPF_TX_DATA_SENT)) {
+ send_tx_flowc_wr(csk);
+ cxgbi_sock_set_flag(csk, CTPF_TX_DATA_SENT);
+ }
+
cxgbi_sock_set_state(csk, CTP_ABORTING);
cxgbi_sock_set_flag(csk, CTPF_ABORT_RPL_PENDING);
cxgbi_sock_purge_write_queue(csk);
@@ -493,20 +500,40 @@ static inline unsigned int calc_tx_flits_ofld(const
struct sk_buff *skb)
return flits + sgl_len(cnt);
}
-static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
+#define FLOWC_WR_NPARAMS_MIN 9
+static inline int tx_flowc_wr_credits(int *nparamsp, int *flowclenp)
+{
+ int nparams, flowclen16, flowclen;
+
+ nparams = FLOWC_WR_NPARAMS_MIN;
+ flowclen = offsetof(struct fw_flowc_wr, mnemval[nparams]);
+ flowclen16 = DIV_ROUND_UP(flowclen, 16);
+ flowclen = flowclen16 * 16;
+ /*
+* Return the number of 16-byte credits used by the FlowC request.
+* Pass back the nparams and actual FlowC length if requested.
+*/
+ if (nparamsp)
+ *nparamsp = nparams;
+ if (flowclenp)
+ *flowclenp = flowclen;
+
+ return flowclen16;
+}
+
+static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
{
struct sk_buff *skb;
struct fw_flowc_wr *flowc;
- int flowclen, i;
+ int nparams, flowclen16, flowclen;
- flowclen = 80;
+ flowclen16 = tx_flowc_wr_credits(&nparams, &flowclen);
skb = alloc_wr(flowclen, 0, GFP_ATOMIC);
flowc = (struct fw_flowc_wr *)skb->head;
flowc->op_to_nparams =
- htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(8));
+ htonl(FW_WR_OP(FW_FLOWC_WR) | FW_FLOWC_WR_NPARAMS(nparams));
flowc->flowid_len16 =
- htonl(FW_WR_LEN16(DIV_ROUND_UP(72, 16)) |
- FW_WR_FLOWID(csk->tid));
+ htonl(FW_WR_LEN16(flowclen16) | FW_WR_FLOWID(csk->tid));
flowc->mnemval[0].mnemonic = FW_FLOWC_MNEM_PFNVFN;
flowc->mnemval[0].val = htonl(csk->cdev->pfvf);
flowc->mnemval[1].mnemonic = FW_FLOWC_MNEM_CH;
@@ -525,11 +552,9 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[7].val = htonl(csk->advmss);
flowc->mnemval[8].mnemonic = 0;
flowc->mnemval[8].val = 0;
- for (i = 0; i < 9; i++) {
- flowc->mnemval[i].r4[0] = 0;
- flowc->mnemval[i].r4[1] = 0;
- flowc->mnemval[i].r4[2] = 0;
- }
+ flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
+ flowc->mnemval[8].val = 16384;
+
set_queue(skb, CPL_PRIORITY_DATA, csk);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
@@ -539,6 +564,8 @@ static inline void send_tx_flowc_wr(struct cxgbi_sock *csk)
csk->advmss);
cxgb4_ofld_send(csk->cdev->ports[csk->port_id], skb);
+
+ return flowclen16;
}
static inline void make_tx_data_wr(struct cxgbi_sock *csk, struct sk_buff *skb,
@@ -599,6 +626,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
int dlen = skb->len;
int len = skb->len;
unsigned int credits_needed;
+ int flowclen16 = 0;
skb_reset_transport_header(skb);
if (is_ofld_imm(skb))
@@ -613,6 +641,17 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
[PATCH net v8 0/7] cxgb4/cxgbi: misc. fixes for cxgb4i
This patch set fixes cxgb4i's tx credit calculation and adds handling of additional rx message and negative advice types. It also removes the duplicate code in cxgb4i to set the outgoing queues of a packet. Karen Xie (7): cxgb4i: fix tx immediate data credit check cxgb4i: fix credit check for tx_data_wr cxgb4/cxgb4i: set max. outgoing pdu length in the f/w cxgb4i: add more types of negative advice cxgb4i: handle non pdu-aligned rx data cxgb4i: use cxgb4's set_wr_txq() for setting outgoing queues libcxgbi: fix the debug print accessing skb after it is freed Sending to net as the fixes are mostly in the network area and it touches cxgb4's header file (t4fw_api.h). v2 corrects the "CHECK"s flagged by checkpatch.pl --strict. v3 splits the 3rd patch from v2 to two separate patches. Adds detailed commit messages and makes subject more concise. Patch 3/6 also changes the return value of is_neg_adv() from int to bool. v4 -- please ignore. v5 splits the 1st patch from v3 to two separate patches and reduces code duplication in make_tx_data_wr(). v6 removed the code style cleanup in the 2nd patch. The style update will be addressed in a separate patch. v7 updates the 7th patch with more detailed commit message. v8 removes the duplicate subject lines from the message bodies. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v8 5/7] cxgb4i: handle non-pdu-aligned rx data
From: Karen Xie
Abort the connection upon receiving of cpl_rx_data, which means the pdu cannot
be recovered from the tcp stream. This generally is due to pdu header
corruption.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 2880f200..dff7345 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -1034,6 +1034,27 @@ rel_skb:
__kfree_skb(skb);
}
+static void do_rx_data(struct cxgbi_device *cdev, struct sk_buff *skb)
+{
+ struct cxgbi_sock *csk;
+ struct cpl_rx_data *cpl = (struct cpl_rx_data *)skb->data;
+ unsigned int tid = GET_TID(cpl);
+ struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
+ struct tid_info *t = lldi->tids;
+
+ csk = lookup_tid(t, tid);
+ if (!csk) {
+ pr_err("can't find connection for tid %u.\n", tid);
+ } else {
+ /* not expecting this, reset the connection. */
+ pr_err("csk 0x%p, tid %u, rcv cpl_rx_data.\n", csk, tid);
+ spin_lock_bh(&csk->lock);
+ send_abort_req(csk);
+ spin_unlock_bh(&csk->lock);
+ }
+ __kfree_skb(skb);
+}
+
static void do_rx_iscsi_hdr(struct cxgbi_device *cdev, struct sk_buff *skb)
{
struct cxgbi_sock *csk;
@@ -1453,6 +1474,7 @@ cxgb4i_cplhandler_func cxgb4i_cplhandlers[NUM_CPL_CMDS] =
{
[CPL_SET_TCB_RPL] = do_set_tcb_rpl,
[CPL_RX_DATA_DDP] = do_rx_data_ddp,
[CPL_RX_ISCSI_DDP] = do_rx_data_ddp,
+ [CPL_RX_DATA] = do_rx_data,
};
int cxgb4i_ofld_init(struct cxgbi_device *cdev)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v8 6/7] cxgb4i: use set_wr_txq() to set tx queues
From: Karen Xie
use cxgb4's set_wr_txq() for setting of the tx queue for a outgoing packet.
Remove the similar function in cxgb4i.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index dff7345..6aa50fc 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -157,12 +157,6 @@ static struct scsi_transport_template *cxgb4i_stt;
#define RCV_BUFSIZ_MASK0x3FFU
#define MAX_IMM_TX_PKT_LEN 128
-static inline void set_queue(struct sk_buff *skb, unsigned int queue,
- const struct cxgbi_sock *csk)
-{
- skb->queue_mapping = queue;
-}
-
static int push_tx_frames(struct cxgbi_sock *, int);
/*
@@ -404,7 +398,7 @@ static void send_abort_req(struct cxgbi_sock *csk)
csk->cpl_abort_req = NULL;
req = (struct cpl_abort_req *)skb->head;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
req->cmd = CPL_ABORT_SEND_RST;
t4_set_arp_err_handler(skb, csk, abort_arp_failure);
INIT_TP_WR(req, csk->tid);
@@ -430,7 +424,7 @@ static void send_abort_rpl(struct cxgbi_sock *csk, int
rst_status)
csk, csk->state, csk->flags, csk->tid, rst_status);
csk->cpl_abort_rpl = NULL;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
INIT_TP_WR(rpl, csk->tid);
OPCODE_TID(rpl) = cpu_to_be32(MK_OPCODE_TID(CPL_ABORT_RPL, csk->tid));
rpl->cmd = rst_status;
@@ -555,7 +549,7 @@ static inline int send_tx_flowc_wr(struct cxgbi_sock *csk)
flowc->mnemval[8].mnemonic = FW_FLOWC_MNEM_TXDATAPLEN_MAX;
flowc->mnemval[8].val = 16384;
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
log_debug(1 << CXGBI_DBG_TOE | 1 << CXGBI_DBG_SOCK,
"csk 0x%p, tid 0x%x, %u,%u,%u,%u,%u,%u,%u.\n",
@@ -660,7 +654,7 @@ static int push_tx_frames(struct cxgbi_sock *csk, int
req_completion)
break;
}
__skb_unlink(skb, &csk->write_queue);
- set_queue(skb, CPL_PRIORITY_DATA, csk);
+ set_wr_txq(skb, CPL_PRIORITY_DATA, csk->port_id);
skb->csum = credits_needed + flowclen16;
csk->wr_cred -= credits_needed;
csk->wr_una_cred += credits_needed;
@@ -1552,7 +1546,7 @@ static int ddp_ppod_write_idata(struct cxgbi_device
*cdev, unsigned int port_id,
return -ENOMEM;
}
req = (struct ulp_mem_io *)skb->head;
- set_queue(skb, CPL_PRIORITY_CONTROL, NULL);
+ set_wr_txq(skb, CPL_PRIORITY_CONTROL, 0);
ulp_mem_io_set_hdr(lldi, req, wr_len, dlen, pm_addr);
idata = (struct ulptx_idata *)(req + 1);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
> "Long" == Long Li writes:
Long> MSFT targets currently claim SPC-2 compliance while they implement
Long> post SPC-2 features. With this patch we can correctly handle
Long> WRITE_SAME_16 issues.
Handle the issues or handle WRITE SAME(10/16)?
+ {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES},
Is that version field meaningful or is it safe for us to inquire about
VPD pages without problems on older versions?
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v8 2/7] cxgb4i: fix credit check for tx_data_wr
From: Karen Xie
make sure any tx credit related checking is done before adding the wr header.
Signed-off-by: Karen Xie
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index f119a67..abee611 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -547,10 +547,11 @@ static inline void make_tx_data_wr(struct cxgbi_sock
*csk, struct sk_buff *skb,
struct fw_ofld_tx_data_wr *req;
unsigned int submode = cxgbi_skcb_ulp_mode(skb) & 3;
unsigned int wr_ulp_mode = 0;
+ bool imm = is_ofld_imm(skb);
req = (struct fw_ofld_tx_data_wr *)__skb_push(skb, sizeof(*req));
- if (is_ofld_imm(skb)) {
+ if (imm) {
req->op_to_immdlen = htonl(FW_WR_OP(FW_OFLD_TX_DATA_WR) |
FW_WR_COMPL(1) |
FW_WR_IMMDLEN(dlen));
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v8 7/7] libcxgbi: fix freeing skb prematurely
From: Karen Xie With debug turned on the debug print would access the skb after it is freed. Fix it to free the skb after the debug print. Signed-off-by: Karen Xie --- drivers/scsi/cxgbi/libcxgbi.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c index 7da59c3..eb58afc 100644 --- a/drivers/scsi/cxgbi/libcxgbi.c +++ b/drivers/scsi/cxgbi/libcxgbi.c @@ -2294,10 +2294,12 @@ int cxgbi_conn_xmit_pdu(struct iscsi_task *task) return err; } - kfree_skb(skb); log_debug(1 << CXGBI_DBG_ISCSI | 1 << CXGBI_DBG_PDU_TX, "itt 0x%x, skb 0x%p, len %u/%u, xmit err %d.\n", task->itt, skb, skb->len, skb->data_len, err); + + kfree_skb(skb); + iscsi_conn_printk(KERN_ERR, task->conn, "xmit err %d.\n", err); iscsi_conn_failure(task->conn, ISCSI_ERR_XMIT_FAILED); return err; -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[v3.16][v3.17][v3.18][ Regression] scsi: handle flush errors properly
Hello James, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit 89fb4cd1f717a871ef79fa7debbe840e3225cd54 Author: James Bottomley Date: Thu Jul 3 19:17:34 2014 +0200 scsi: handle flush errors properly The regression was introduced as of v3.16 and still exits in the 3.18 kernel. It has also made it's way into the stable kernels. I was hoping to get your feedback, since you are the patch author. Do you think gathering any additional data will help diagnose this issue, or would it be best to submit a revert request? Thanks, Joe [0] http://pad.lv/1366538 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
> -Original Message- > From: Sitsofe Wheeler [mailto:sits...@gmail.com] > Sent: Wednesday, December 10, 2014 12:58 PM > To: Long Li > Cc: KY Srinivasan; Haiyang Zhang; jbottom...@parallels.com; linux- > s...@vger.kernel.org; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2 > > On Wed, Dec 10, 2014 at 12:38:25AM -0800, Long Li wrote: > > MSFT targets currently claim SPC-2 compliance while they implement > > post SPC-2 features. With this patch we can correctly handle > > WRITE_SAME_16 issues. > > > > This patch fixes an issue where the flag is setup too late in drive > > initialization process. > > Li, is this a fix for the issue I keep whinging about over in > https://lkml.org/lkml/2014/10/21/23 ? > > If is the same issue you may want to CC Martin on this... This is only for fixing WRITE_SAME_16. The rest of the thin provisioning (e.g. UNMAP) is still broken on SPC-2. > > -- > Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 2/5] kexec: Export kexec_in_progress
On 12/08/2014 03:38 PM, Eric W. Biederman wrote: > Brian King writes: > >> On 12/02/2014 12:49 PM, Brian King wrote: >>> On 12/02/2014 12:47 PM, Brian King wrote: A kexec boot for some ipr SAS adapters was seen to take ~20 seconds just doing ipr adapter initialization. This is due to the fact that a kexec invokes the driver's shutdown handler which places the adapter into a state that requires a hard reset and resulting firmware initialization to be usable again, which takes significant time. By exporting kexec_in_progress, this process can be optimized significantly in the driver by essentially placing the adapter into a state where this hardware reset and re-initialization can be bypassed, eliminating this delay in kexec boot. Cc: Eric Biederman Cc: kexec Signed-off-by: Brian King --- kernel/kexec.c |2 ++ 1 file changed, 2 insertions(+) diff -puN kernel/kexec.c~kexec_export_in_prog kernel/kexec.c --- scsi-queue/kernel/kexec.c~kexec_export_in_prog 2014-12-02 12:13:22.820325731 -0600 +++ scsi-queue-bjking1/kernel/kexec.c 2014-12-02 12:13:22.825325687 -0600 @@ -2768,3 +2768,5 @@ int kernel_kexec(void) mutex_unlock(&kexec_mutex); return error; } + +EXPORT_SYMBOL_GPL(kexec_in_progress); _ >>> >>> Eric, >>> >>> Can I get your ack on this so this can go through the scsi tree? The last >>> time I sent this >>> out you had some issues with the patch description. >> >> Eric - can I get your ack here? > > You can have my nack. > > We really shouldn't need to special case things for kexec here. Why do > you do the full shutdown that is so slow to get out of? Does it really > make reboots more reliable? If you need it for a reboot why don't you > need it for a kexec reboot? You certainly need to stop all dma in > both cases. > > If it really matters to device drivers we need to refactor and make the > callbacks make sense, be maintainable. Right now caring that it is > kexec vs reboot seems broken. > > Now maybe I am wrong here, and there are some good really good reasons > for wanting to do a much stronger shutdown on reboot but at least > skimming through the change longs of the associated patches I am not > seeing the reason for making all of these changes conditional on kexec. > > What I am seeing is driver code getting really complicated possibly > beyond the ability of anyone to sanely test. The difference between an actual reboot and a kexec reboot is that for an actual reboot, the system / platform will end up hard resetting the adapter across the reboot. Due to this impending hard reset, some drivers may want to take additional actions before a full system reboot occurs. In the case of ipr, prior to a full system reset the key thing I want to ensure happens is to tell the adapter to quiesce any outstanding I/O to the disks. I/O that can be occurring at this time is either data being destaged from the non volatile write cache, RAID rebuilds, etc. The only firmware interface available to initiate this quiesce currently places the adapter into a state where the only way back out of it to a state where the host can begin to issue I/O again is to hard reset the adapter, as it is expected to only occur prior to system shutdown or system reboot. This reset and then the firmware initialization that follows can take a bit of time. If this pending I/O is not quiesced prior to a hard reset of the adapter the subsequent boot can then take even longer and, in some cases, may require additional actions to recover from. I can look at implementing this in a driver unique way so that we don't need this kexec patch, but this seemed the most straight forward. Thanks, Brian -- Brian King Power Linux I/O IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3.16][v3.17][v3.18][ Regression] scsi: handle flush errors properly
Hey Joe, Here's some context: The SCSI flush command was being treated by a zero-byte write, which means that if an error was returned, you wouldn't catch it until a subsequent write (or flush). The way writes work is that all possible bytes are written, and if something bad happens, an error bubbles out on the next write attempt. This holds true even for a zero-byte write. This means that before this bug, to guarantee durability you had to flush twice (and verify both were error-free). I'm working on a storage appliance that relies on the fact that a single flush command guarantees a write made durably to a SCSI device. I'm sure many other storage products rely on this behavior, too. The patch James shipped fixes this bug by special-casing the flush error path. Before flush wouldn't return errors; now it does. I'm not sure why certain USB drives are failing in the flush path on unmount. Since the flush bug existed for such a long time, I suspect certain drivers coded around this behavior, and now that it is correct we are seeing new bugs exposed. Based on the simplicity and obviousness of our patch for the flush bug, it would really be ideal to diagnose this further rather than reverting. Steven Haber Qumulo, Inc. On Wed, Dec 10, 2014 at 2:08 PM, Joseph Salisbury wrote: > Hello James, > > A kernel bug report was opened against Ubuntu [0]. After a kernel > bisect, it was found that reverting the following commit resolved this bug: > > commit 89fb4cd1f717a871ef79fa7debbe840e3225cd54 > Author: James Bottomley > Date: Thu Jul 3 19:17:34 2014 +0200 > > scsi: handle flush errors properly > > The regression was introduced as of v3.16 and still exits in the 3.18 > kernel. It has also made it's way into the stable kernels. > > I was hoping to get your feedback, since you are the patch author. Do > you think gathering any additional data will help diagnose this issue, > or would it be best to submit a revert request? > > > Thanks, > > Joe > > [0] http://pad.lv/1366538 > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
> -Original Message-
> From: Long Li
> Sent: Wednesday, December 10, 2014 2:28 PM
> To: Martin K. Petersen
> Cc: KY Srinivasan; Haiyang Zhang; jbottom...@parallels.com; linux-
> s...@vger.kernel.org; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: RE: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
>
> > > "Long" == Long Li writes:
> >
> > Long> MSFT targets currently claim SPC-2 compliance while they
> > Long> implement post SPC-2 features. With this patch we can correctly
> > Long> handle
> > Long> WRITE_SAME_16 issues.
> >
> > Handle the issues or handle WRITE SAME(10/16)?
>
> With this patch, the SCSI layer will be able to correctly send WRITE_SAME_16
> to the Hyper-V host. It will not send WRITE_SAME_10: it has been disabled in
> the driver template. Do you want me to send another patch with these
> details?
>
> >
> > + {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES},
> >
> > Is that version field meaningful or is it safe for us to inquire about
> > VPD pages without problems on older versions?
>
> This version is used in all current Hyper-V hosts: Windows 2008 R2, 2012 and
> 2012 R2. However it may change in future Windows releases.
The next version of the host will be claiming conformance to SPC-3
K. Y
>
> >
> > --
> > Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
> > "Long" == Long Li writes:
>
> Long> MSFT targets currently claim SPC-2 compliance while they implement
> Long> post SPC-2 features. With this patch we can correctly handle
> Long> WRITE_SAME_16 issues.
>
> Handle the issues or handle WRITE SAME(10/16)?
With this patch, the SCSI layer will be able to correctly send WRITE_SAME_16 to
the Hyper-V host. It will not send WRITE_SAME_10: it has been disabled in the
driver template. Do you want me to send another patch with these details?
>
> + {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES},
>
> Is that version field meaningful or is it safe for us to inquire about VPD
> pages
> without problems on older versions?
This version is used in all current Hyper-V hosts: Windows 2008 R2, 2012 and
2012 R2. However it may change in future Windows releases.
>
> --
> Martin K. PetersenOracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UAS crash with Apricorn USB3 SATA bridge
On Wed, Dec 10, 2014 at 02:29:29AM -0800, Darrick J. Wong wrote:
> On Wed, Dec 10, 2014 at 02:15:14AM -0800, Darrick J. Wong wrote:
> > On Wed, Dec 10, 2014 at 01:04:58AM -0800, Darrick J. Wong wrote:
> > > On Wed, Dec 10, 2014 at 09:19:04AM +0100, Hans de Goede wrote:
> > > > Hi,
> > > >
> > > > On 09-12-14 20:31, Darrick J. Wong wrote:
> > > > >Hi,
> > > > >
> > > > >I have an Apricorn USB 3 disk dongle thing that claims to support UAS.
> > > > >However, the kernel crashes when I plug it in[1].
> > > >
> > > > Yes there are some known issues with uas error handling which are fixed
> > > > in 3.18, can you try with a 3.18 kernel please ?
> > >
> > > The crash pic was from 3.18.0, blk_mq disabled. I'll work on getting a
> > > fuller
> > > dmesg output. Looking at the code, it looks like we end up in
> > > queue_bulk_sg_tx() with a sg list that is shorter than num_sgs, so we
> > > fall off
> > > the end.
Well, there are (at least) two issues going on here. The first is that the
SCSI layer passes us zero-length READ10 commands, which is causing this crash.
Zero length means the sglist is empty, so the usb host has nothing to map, and
hence urb->num_mapped_sgs == 0 and the loop goes boom. I don't know what it
means to send a bulk URB with no buffers, so...
...then I took a tour of how SCSI LLDDs deal with zero-length read/write
commands. mpt2sas attaches a junk sg and pushes the command out. libata
detects zero-length READ/WRITE SCSI commands and completes the scsi command
without ever touching hardware. I wasn't able to get any of my parallel SCSI
disks to boot, so I could not try that.
The other problem is when I plug in a different disk (same mfg/model), READ
CAPACITY 16 intermittently returns the string "USBSUSBSUSBS", which of course
is garbage. The kernel then tries to use these values; fortunately, it rejects
a sector size of 1431519827 ("USBS") and sets the size to zero.
So, I can code up a couple of patches -- one to teach UAS how to deal with zero
length read and writes; and a second patch to set US_FL_IGNORE_UAS on Apricorn
bridges. I tried setting US_FL_NO_READ_CAPACITY_16, but for whatever reason
sd.c was still trying RC16.
--D
> > >
> > > (Alas it's now 1am here, so I'm going to bed. :/ )
> >
> > Eh, nuts to sleeping. dmesg produces this:
> >
> > [ 231.128074] usbcore: registered new interface driver usb-storage
> > [ 231.133822] usbcore: registered new interface driver uas
> > [ 252.121353] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd
> > [ 252.136927] scsi host6: uas
> > [ 252.141679] scsi 6:0:0:0: Direct-Access Apricorn
> > 0128 PQ: 0 ANSI: 6
> > [ 252.145433] sd 6:0:0:0: Attached scsi generic sg2 type 0
> > [ 252.145525] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160
> > GB/149 GiB)
> > [ 252.145527] sd 6:0:0:0: [sdc] 4096-byte physical blocks
> > [ 252.145891] sd 6:0:0:0: [sdc] Write Protect is off
> > [ 252.145973] sd 6:0:0:0: [sdc] No Caching mode page found
> > [ 252.145975] sd 6:0:0:0: [sdc] Assuming drive cache: write through
>
> Huh. 4096-byte physical blocks?? That drive is /not/ a 4k sector drive.
> Here's what the kernel said when I plugged in the other ("Plugable" brand) UAS
> bridge[1]:
>
> [ 32.466870] usb 2-4: new SuperSpeed USB device number 2 using xhci_hcd
> [ 32.498996] usbcore: registered new interface driver usb-storage
> [ 37.660963] scsi host6: uas
> [ 37.661193] usbcore: registered new interface driver uas
> [ 37.661292] queue_bulk_sg_tx: num=1 sg=880447764500 addr=45af41000
> len=0 pagelink=ea00116bd042
> [ 37.661550] queue_bulk_sg_tx: num=1 sg=8804483fb600 addr=45af41000
> len=0 pagelink=ea00116bd042
> [ 37.661744] scsi 6:0:0:0: Direct-Access Plugable USB3-SATA-UASP1 0
> PQ: 0 ANSI: 6
> [ 37.661865] queue_bulk_sg_tx: num=1 sg=8804483fba00 addr=45af41000
> len=0 pagelink=ea00116bd042
> [ 37.662053] queue_bulk_sg_tx: num=1 sg=8804483fba00 addr=45af41000
> len=0 pagelink=ea00116bd042
> [ 37.662294] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45af41000
> len=0 pagelink=ea00116bd042
> [ 37.662488] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45b6ab000
> len=0 pagelink=ea00116daac2
> [ 37.663041] sd 6:0:0:0: Attached scsi generic sg2 type 0
> [ 37.663138] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=44897c000
> len=0 pagelink=ea0011225f02
> [ 37.664420] sd 6:0:0:0: [sdc] 312581808 512-byte logical blocks: (160
> GB/149 GiB)
> [ 37.664599] queue_bulk_sg_tx: num=1 sg=880447764400 addr=45b5c
> len=0 pagelink=ea00116d7002
> [ 37.664833] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45b5c
> len=0 pagelink=ea00116d7002
> [ 37.665022] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45b5c
> len=0 pagelink=ea00116d7002
> [ 37.665255] queue_bulk_sg_tx: num=1 sg=88045b9e1200 addr=45b5c
> len=0 pagelink=ea00116d7002
> [ 37.665421] sd 6:0:0:0:
RE: [PATCH 09/22] [SCSI] mpt2sas, mpt3sas: Added a support to set cpu affinity for each MSIX vector enabled by the HBA
> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Sreekanth Reddy > Sent: Tuesday, 09 December, 2014 6:17 AM > To: martin.peter...@oracle.com; j...@kernel.org; h...@infradead.org ... > Change_set: > 1. Added affinity_hint varable of type cpumask_var_t in adapter_reply_queue >structure. And allocated a memory for this varable by calling > zalloc_cpumask_var. > 2. Call the API irq_set_affinity_hint for each MSIx vector to affiniate it >with calculated cpus at driver inilization time. > 3. While freeing the MSIX vector, call this same API to release the cpu > affinity mask >for each MSIx vector by providing the NULL value in cpumask argument. > 4. then call the free_cpumask_var API to free the memory allocated in step 2. > ... > diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c > b/drivers/scsi/mpt3sas/mpt3sas_base.c > index 1560115..f0f8ba0 100644 > --- a/drivers/scsi/mpt3sas/mpt3sas_base.c > +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c ... > @@ -1609,6 +1611,10 @@ _base_request_irq(struct MPT3SAS_ADAPTER *ioc, u8 > index, u32 vector) > reply_q->ioc = ioc; > reply_q->msix_index = index; > reply_q->vector = vector; > + > + if (!zalloc_cpumask_var(&reply_q->affinity_hint, GFP_KERNEL)) > + return -ENOMEM; I think this will create the problem Alex Thorlton just reported with lpfc on a system with a huge number (6144) of CPUs. See this thread: [BUG] kzalloc overflow in lpfc driver on 6k core system --- Rob ElliottHP Server Storage -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net v8 1/7] cxgb4i: fix tx immediate data credit check
From: Karen Xie Date: Wed, 10 Dec 2014 13:11:06 -0800 > From: Karen Xie > > Only data skbs need the wr header added while control skbs do not. Make sure > they are treated differently. > > Signed-off-by: Karen Xie Please text format your commit messages to 80 characters or less per line. People are going to read your commits using text tools, not necessarily GUI tools which will auto-format your commit message. I know this seems like we are being difficult, but you are making many fundamental mistakes in your efforts to merge in these changes. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3.16][v3.17][v3.18][ Regression] scsi: handle flush errors properly
On Wed, 2014-12-10 at 17:08 -0500, Joseph Salisbury wrote: > Hello James, > > A kernel bug report was opened against Ubuntu [0]. After a kernel > bisect, it was found that reverting the following commit resolved this bug: If I read this bug report correctly, it's saying a USB attached device produces an error when doing a "shred" but the same device PCI attached doesn't. Presumably shred sends some type of zero length command USB storage doesn't like. What is shred actually doing (what commands is it sending)? James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
T10-PI: Getting failed tag info
Hi, We are currently developing a SCSI target system with T10-PI. We are using block integrity interface and found a problem that this interface fundamentally can not pass Oracle T10-PI certification tests. Those tests require to receive on the initiator side information about which particular tag failed the target checks, but the block integrity interface does not preserve this information, hence the target can not deliver it to the initiator => certification failure. The storage provides the right sense, but then in scsi_io_completion() it is dropped and replaced by a single EILSEQ. What would be the best way to fix that? By making a patch introducing new -EXX error codes for the PI errors? Thanks, Vlad -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cxgb4/csiostor: Don't use MASTER_MUST for fw_hello call
Remove use of calls into t4_fw_hello() with MASTER_MUST, which results in
FW_HELLO_CMD_MASTERFORCE being set. The firmware doesn't support this and of
course any existing PF Drivers will totally go for a toss.
Signed-off-by: Hariprasad Shenai
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 12 ++--
drivers/scsi/csiostor/csio_hw.c |6 +-
drivers/scsi/csiostor/csio_hw.h |1 -
3 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 279873c..30deaf1 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5687,14 +5687,8 @@ static int adap_init0(struct adapter *adap)
struct fw_caps_config_cmd caps_cmd;
int reset = 1;
- /*
-* Contact FW, advertising Master capability (and potentially forcing
-* ourselves as the Master PF if our module parameter force_init is
-* set).
-*/
- ret = t4_fw_hello(adap, adap->mbox, adap->fn,
- force_init ? MASTER_MUST : MASTER_MAY,
- &state);
+ /* Contact FW, advertising Master capability */
+ ret = t4_fw_hello(adap, adap->mbox, adap->mbox, MASTER_MAY, &state);
if (ret < 0) {
dev_err(adap->pdev_dev, "could not connect to FW, error %d\n",
ret);
@@ -5702,8 +5696,6 @@ static int adap_init0(struct adapter *adap)
}
if (ret == adap->mbox)
adap->flags |= MASTER_PF;
- if (force_init && state == DEV_STATE_INIT)
- state = DEV_STATE_UNINIT;
/*
* If we're the Master PF Driver and the device is uninitialized,
diff --git a/drivers/scsi/csiostor/csio_hw.c b/drivers/scsi/csiostor/csio_hw.c
index 0eaec47..5b909c0 100644
--- a/drivers/scsi/csiostor/csio_hw.c
+++ b/drivers/scsi/csiostor/csio_hw.c
@@ -47,7 +47,6 @@
#include "csio_lnode.h"
#include "csio_rnode.h"
-int csio_force_master;
int csio_dbg_level = 0xFEFF;
unsigned int csio_port_mask = 0xf;
@@ -889,7 +888,6 @@ csio_do_hello(struct csio_hw *hw, enum csio_dev_state
*state)
{
struct csio_mb *mbp;
int rv = 0;
- enum csio_dev_master master;
enum fw_retval retval;
uint8_t mpfn;
char state_str[16];
@@ -904,11 +902,9 @@ csio_do_hello(struct csio_hw *hw, enum csio_dev_state
*state)
goto out;
}
- master = csio_force_master ? CSIO_MASTER_MUST : CSIO_MASTER_MAY;
-
retry:
csio_mb_hello(hw, mbp, CSIO_MB_DEFAULT_TMO, hw->pfn,
- hw->pfn, master, NULL);
+ hw->pfn, CSIO_MASTER_MAY, NULL);
rv = csio_mb_issue(hw, mbp);
if (rv) {
diff --git a/drivers/scsi/csiostor/csio_hw.h b/drivers/scsi/csiostor/csio_hw.h
index 5db2d85..68248da 100644
--- a/drivers/scsi/csiostor/csio_hw.h
+++ b/drivers/scsi/csiostor/csio_hw.h
@@ -110,7 +110,6 @@ struct csio_scsi_cpu_info {
};
extern int csio_dbg_level;
-extern int csio_force_master;
extern unsigned int csio_port_mask;
extern int csio_msi;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
