public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	linux-ide@vger.kernel.org, Jeff Garzik <jgarzik@redhat.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: todays git: WARNING: at drivers/ata/libata-sff.c:1017 ata_sff_hsm_move+0x45e/0x750()
Date: Sat, 10 Jan 2009 18:29:18 +0300	[thread overview]
Message-ID: <4968BECE.8070304@ru.mvista.com> (raw)
In-Reply-To: <20090110151248.063199d2@lxorguk.ukuu.org.uk>

Alan Cox wrote:

> O> Your problem is that the *device* is wanting to transfer a set of bytes

>>not divisible by four.  If you want to use word based PIO, you'll have
>>to fall back to collecting bytes for the last two.  Alternatively, you

> Nope.. you can't do that with ATA block transfers - it isn't the same as
> SCSI

   ATA block transfers are always mutliple of 512 bytes (except read/write 
long), so this shouldn't be an issue... unless the code is trying to split a 
sector between 2 pages on an arbitrary boundary -- in this case, even if the 
both resulting byte counts divide by 2, you may be busted because of prefetch 
that (as the Intel docs say), should have the initial (start of sector) and 
all subsequent reads of the same size (either 16- or 32-bit). I don't know if 
this situation is actually possible with libata -- but beware...

>>could just do byte PIO for all reply lengths like this ... they occur
>>all over the SCSI standard, but not usually in critical paths.

> The problem we have is that the sg list the drivers were given had a
> segment which was not divisible in length by four and was *NOT* the last
> segment in the sg list

> The logic in the ATA PIO code is basically

> 	for each sg entry

> 		compute the number of bytes to transfer staying within
> the page
> 		transfer that many bytes (but may be more)
> 
> 		if and only if the transfer is NOT the last segment but is
> 			more than the bytes requested - WARN

    The ATAPI logic is more complex since it has to take into account the 
arbitrary byte count that a device want to transfer on each INTRQ (read from 
the byte count low/high regs).

> Alan

MBR, Sergei

  parent reply	other threads:[~2009-01-10 15:28 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-09 12:34 todays git: WARNING: at drivers/ata/libata-sff.c:1017 ata_sff_hsm_move+0x45e/0x750() Christian Borntraeger
2009-01-09 12:44 ` Alan Cox
2009-01-09 13:09   ` Christian Borntraeger
2009-01-10  9:09   ` Christian Borntraeger
2009-01-10 10:41     ` Alan Cox
2009-01-10 11:42       ` Christian Borntraeger
2009-01-10 11:49         ` Sergei Shtylyov
2009-01-10 12:21           ` Alan Cox
2009-01-10 13:01             ` Sergei Shtylyov
2009-01-10 13:55               ` Alan Cox
2009-01-10 13:04             ` Christian Borntraeger
2009-01-10 13:14               ` Jeff Garzik
2009-01-10 13:27                 ` Christian Borntraeger
2009-01-10 13:51                 ` Alan Cox
2009-01-10 21:21                   ` Arjan van de Ven
2009-01-10 13:07             ` Ingo Molnar
2009-01-10 13:12               ` Jeff Garzik
2009-01-10 13:24                 ` Ingo Molnar
2009-01-10 13:36                   ` [bisected] " Ingo Molnar
2009-01-10 13:57                     ` Alan Cox
2009-01-10 15:10                       ` Sergei Shtylyov
2009-01-10 15:28                         ` Alan Cox
2009-01-10 15:59                           ` Sergei Shtylyov
2009-01-10 20:06                             ` Sergei Shtylyov
2009-01-10 20:31                               ` Jeff Garzik
2009-01-10 20:50                                 ` Sergei Shtylyov
2009-01-11  0:10                               ` Alan Cox
2009-01-11  9:18                                 ` Sergei Shtylyov
2009-01-11 11:24                                   ` Alan Cox
2009-01-13  9:38                           ` [PATCH] ata: fix wrong WARN_ON_ONCE Christian Borntraeger
2009-01-10 13:57                     ` [bisected] Re: todays git: WARNING: at drivers/ata/libata-sff.c:1017 ata_sff_hsm_move+0x45e/0x750() Christian Borntraeger
2009-01-10 13:53               ` Alan Cox
2009-01-10 14:36             ` James Bottomley
2009-01-10 15:03               ` Jeff Garzik
2009-01-10 15:12               ` Alan Cox
2009-01-10 15:22                 ` James Bottomley
2009-01-10 15:29                   ` Alan Cox
2009-01-10 15:34                   ` Sergei Shtylyov
2009-01-10 15:29                 ` Sergei Shtylyov [this message]
2009-01-10 15:32                   ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4968BECE.8070304@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=borntraeger@de.ibm.com \
    --cc=jgarzik@redhat.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox