Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1295644 > unrolled thread
| Started by | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| First post | 2015-12-20 19:00 +0100 |
| Last post | 2015-12-22 00:00 +0100 |
| Articles | 4 on this page of 44 — 9 participants |
Back to article view | Back to linux.kernel
IO errors after "block: remove bio_get_nr_vecs()" Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-20 19:00 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Christoph Hellwig <hch@lst.de> - 2015-12-20 19:20 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-20 19:50 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 00:50 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-20 19:50 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 00:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Dan Aloni <dan@kernelim.com> - 2015-12-21 12:30 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 00:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-21 00:50 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 01:00 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 00:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Ming Lei <tom.leiming@gmail.com> - 2015-12-21 02:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 03:00 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Ming Lei <tom.leiming@gmail.com> - 2015-12-21 03:20 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 03:30 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-21 03:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Ming Lei <tom.leiming@gmail.com> - 2015-12-21 04:30 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 04:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-21 05:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 05:50 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-21 05:50 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-21 06:30 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-21 08:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-22 05:10 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Tejun Heo <tj@kernel.org> - 2015-12-21 05:30 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-21 06:20 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Tejun Heo <tj@kernel.org> - 2015-12-21 08:00 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Tejun Heo <tj@kernel.org> - 2015-12-21 20:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Tejun Heo <tj@kernel.org> - 2015-12-21 21:10 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Tejun Heo <tj@kernel.org> - 2015-12-21 22:10 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-22 04:50 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-22 05:10 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Junichi Nomura <j-nomura@ce.jp.nec.com> - 2015-12-22 06:30 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-22 06:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-22 07:00 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-22 07:00 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-22 07:00 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-22 07:10 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-22 06:40 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Jens Axboe <axboe@fb.com> - 2015-12-22 18:30 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Kent Overstreet <kent.overstreet@gmail.com> - 2015-12-22 05:50 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-22 06:20 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" "Artem S. Tashkinov" <t.artem@lycos.com> - 2015-12-22 06:30 +0100
Re: IO errors after "block: remove bio_get_nr_vecs()" Ming Lei <tom.leiming@gmail.com> - 2015-12-22 00:00 +0100
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Kent Overstreet <kent.overstreet@gmail.com> |
|---|---|
| Date | 2015-12-22 05:50 +0100 |
| Message-ID | <qIn3z-7FD-17@gated-at.bofh.it> |
| In reply to | #1296208 |
So what I _really_ want to know is - how the fuck is the actual ATA command itself malformed? You told me at one point that the error code indicated the controller was claiming it overran the end of the sglist - well, if that's the case we ought to be able to prove it with an assertion (I already tried; qc->nbytes does match the sglist, checking from ata_sg_setup()). Ignore bvec merging, PAE, all that crap - the controller doesn't know about any of that. _WHAT_ are we feeding it that it doesn't like? There shouldn't even be that much stuff to check, since in theory the only possible thing that could be at fault is the sglist. Maybe they're too big, too small, misaligned, too many of them, god knows what, but somehow the sglist we're feeding the device has to be at fault, right? But the sglists in Artem's debugging output look pretty uninteresting (one of them has _no_ merged segments - it's just 18 4k pages - how could THAT be an issue?) Gonna apply your debugging patch and start throwing stuff at the wall next, I guess... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Artem S. Tashkinov" <t.artem@lycos.com> |
|---|---|
| Date | 2015-12-22 06:20 +0100 |
| Message-ID | <qInwB-84N-1@gated-at.bofh.it> |
| In reply to | #1296186 |
On 2015-12-22 01:07, Tejun Heo wrote:
> Hello, Artem.
>
> Can you please apply the following patch on top and see whether
> anything changes? If it does make the issue go away, can you please
> revert the ".can_queue" part and test again?
>
> Thanks.
>
> ---
> drivers/ata/ahci.h | 2 +-
> drivers/ata/libahci.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --- a/drivers/ata/ahci.h
> +++ b/drivers/ata/ahci.h
> @@ -365,7 +365,7 @@ extern struct device_attribute *ahci_sde
> */
> #define AHCI_SHT(drv_name) \
> ATA_NCQ_SHT(drv_name), \
> - .can_queue = AHCI_MAX_CMDS - 1, \
> + .can_queue = 1/*AHCI_MAX_CMDS - 1*/, \
> .sg_tablesize = AHCI_MAX_SG, \
> .dma_boundary = AHCI_DMA_BOUNDARY, \
> .shost_attrs = ahci_shost_attrs, \
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -420,7 +420,7 @@ void ahci_save_initial_config(struct dev
> hpriv->saved_cap2 = cap2 = 0;
>
> /* some chips have errata preventing 64bit use */
> - if ((cap & HOST_CAP_64) && (hpriv->flags & AHCI_HFLAG_32BIT_ONLY)) {
> + if ((cap & HOST_CAP_64)/* && (hpriv->flags &
> AHCI_HFLAG_32BIT_ONLY)*/) {
> dev_info(dev, "controller can't do 64bit DMA, forcing 32bit\n");
> cap &= ~HOST_CAP_64;
> }
This patch fixes the issue for me. Now rechecking without .can_queue
part.
BTW, since I left debugging on, here's the part you wanted:
[ 0.613851] XXX port 0 dma_sz=91392 mem=c0020000 mem_dma=00020000
cmd_slot=0 rx_fis=1024 cmd_tbl=1280
[ 0.613865] XXX port 1 dma_sz=91392 mem=eea00000 mem_dma=2ea00000
cmd_slot=0 rx_fis=1024 cmd_tbl=1280
[ 0.620464] XXX port 2 dma_sz=91392 mem=eea20000 mem_dma=2ea20000
cmd_slot=0 rx_fis=1024 cmd_tbl=1280
[ 0.627121] XXX port 3 dma_sz=91392 mem=eea40000 mem_dma=2ea40000
cmd_slot=0 rx_fis=1024 cmd_tbl=1280
[ 0.633791] XXX port 4 dma_sz=91392 mem=eea60000 mem_dma=2ea60000
cmd_slot=0 rx_fis=1024 cmd_tbl=1280
[ 0.640445] XXX port 5 dma_sz=91392 mem=eea80000 mem_dma=2ea80000
cmd_slot=0 rx_fis=1024 cmd_tbl=1280
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Artem S. Tashkinov" <t.artem@lycos.com> |
|---|---|
| Date | 2015-12-22 06:30 +0100 |
| Message-ID | <qInGh-8ai-5@gated-at.bofh.it> |
| In reply to | #1296186 |
[Multipart message — attachments visible in raw view] — view raw
On 2015-12-22 01:07, Tejun Heo wrote:
> Hello, Artem.
>
> Can you please apply the following patch on top and see whether
> anything changes? If it does make the issue go away, can you please
> revert the ".can_queue" part and test again?
>
> Thanks.
>
> ---
> drivers/ata/ahci.h | 2 +-
> drivers/ata/libahci.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> --- a/drivers/ata/ahci.h
> +++ b/drivers/ata/ahci.h
> @@ -365,7 +365,7 @@ extern struct device_attribute *ahci_sde
> */
> #define AHCI_SHT(drv_name) \
> ATA_NCQ_SHT(drv_name), \
> - .can_queue = AHCI_MAX_CMDS - 1, \
> + .can_queue = 1/*AHCI_MAX_CMDS - 1*/, \
> .sg_tablesize = AHCI_MAX_SG, \
> .dma_boundary = AHCI_DMA_BOUNDARY, \
> .shost_attrs = ahci_shost_attrs, \
> --- a/drivers/ata/libahci.c
> +++ b/drivers/ata/libahci.c
> @@ -420,7 +420,7 @@ void ahci_save_initial_config(struct dev
> hpriv->saved_cap2 = cap2 = 0;
>
> /* some chips have errata preventing 64bit use */
> - if ((cap & HOST_CAP_64) && (hpriv->flags & AHCI_HFLAG_32BIT_ONLY)) {
> + if ((cap & HOST_CAP_64)/* && (hpriv->flags &
> AHCI_HFLAG_32BIT_ONLY)*/) {
> dev_info(dev, "controller can't do 64bit DMA, forcing 32bit\n");
> cap &= ~HOST_CAP_64;
> }
With the ".can_queue" part left intact the bug resurfaced. Full dmesg
output is attached.
[toc] | [prev] | [next] | [standalone]
| From | Ming Lei <tom.leiming@gmail.com> |
|---|---|
| Date | 2015-12-22 00:00 +0100 |
| Message-ID | <qIhAR-46k-5@gated-at.bofh.it> |
| In reply to | #1296171 |
On Tue, Dec 22, 2015 at 3:35 AM, Tejun Heo <tj@kernel.org> wrote:
>
>> [ 74.367632] XXX cmd=ee9e0260 cmd_tbl=ee9ed600 ahci_sg=ee9ed680
>> [ 74.367634] XXX opts=140005 st=0 addr=2e9ed600 addr_hi=0 rsvd=0:0:0:0
>> [ 74.367637] XXX fis=00608027:40218900:07000004:08000098 00000000:00000000:00000000:00001fff
>> [ 74.367639] XXX qc->n_elem=20 fis_len=5 prdtl=20
>> [ 74.367641] XXX sg[0] = 29007000 0 8fff (36864)
>> [ 74.367643] XXX sg[1] = 29218000 0 7fff (32768)
>> [ 74.367645] XXX sg[2] = 29298000 0 7fff (32768)
>> [ 74.367646] XXX sg[3] = 29ad8000 0 7fff (32768)
>> [ 74.367648] XXX sg[4] = 29338000 0 7fff (32768)
>> [ 74.367650] XXX sg[5] = 29370000 0 2fff (12288)
>> [ 74.367652] XXX sg[6] = 219000 0 2fff (12288)
>> [ 74.367653] XXX sg[7] = 230000 0 3fff (16384)
>> [ 74.367655] XXX sg[8] = 29373000 0 4fff (20480)
>> [ 74.367657] XXX sg[9] = 29130000 0 ffff (65536)
>> [ 74.367659] XXX sg[10] = 29170000 0 ffff (65536)
>> [ 74.367660] XXX sg[11] = 29280000 0 ffff (65536)
>> [ 74.367662] XXX sg[12] = 29200000 0 ffff (65536)
>> [ 74.367664] XXX sg[13] = 29320000 0 ffff (65536)
>> [ 74.367666] XXX sg[14] = 29360000 0 ffff (65536)
>> [ 74.367667] XXX sg[15] = 29340000 0 ffff (65536)
>> [ 74.367669] XXX sg[16] = 29350000 0 ffff (65536)
>> [ 74.367671] XXX sg[17] = 29300000 0 ffff (65536)
>> [ 74.367672] XXX sg[18] = 29310000 0 ffff (65536)
>> [ 74.367674] XXX sg[19] = 29020000 0 7fff (32768)
>
> And everything checks out. Data lenghts are consistent and all the
> addresses look kosher - at least nothing should upset the data
> transfer itself.
Maybe we can check more, such as if the sg element is correctly
merged from bvec, and the following code should be useful to check
that:
+static void ahci_dump_req(struct ata_queued_cmd *qc)
+{
+ struct scsi_cmnd *cmd = qc->scsicmd;
+ struct request *req = cmd->request;
+ struct req_iterator iter;
+ struct bio_vec bv;
+ int i = 0;
+ phys_addr_t paddr;
+
+ printk("%s: \n", __func__);
+ rq_for_each_segment(bv, req, iter) {
+ paddr = page_to_phys(bv.bv_page);
+ printk("\t %3d: %x-%x %x %u\n", i++,
+ (unsigned)paddr & 0xffffffff,
+ (unsigned)(paddr >> 32),
+ bv.bv_offset,
+ bv.bv_len);
+ }
+}
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web