headers
Tejun Heo | 1 Nov 2007 01:40
Picon

Re: "Fix ATAPI transfer lengths" causes CD writing regression

Hello, Jeff.

Jeff Garzik wrote:
> That's easy for the PIO case.  But CD writing is normally DMA, which
> means you will get a DMA engine exception if the device wants to give
> you more data than the scatter/gather entries permit.

For sense data and mode pages, the standard-sanctioned way to know the
transfer size is to issue command with short buffer size just enough to
contain the fixed size header part, determine actual transfer size from
it and issue the command again with the correct buffer size.  This
doesn't happen for READ/WRITE commands.  Transfer sizes are
pre-determined for those commands and WRITE's to optical devices often
can't be retried w/o side effect.

I've just went through the ATA spec and this basically means we can't
use DMA for these variable-transfer-length commands.  Some DMA engines
have "throw away what's left over bit" in its command structure or SG
entry but not all do and none of drivers we currently has such feature
enabled.

Hmmm.... reading ide-cd.c::cdrom_pc_intr().  OIC, ide-cd is dealing with
this problem by draining PIO after BMDMA engine is done.  This is
possible for BMDMA engines as they simply step out when the SG entries
are exhausted; then, the interrupt handler kicks in and drains the
left-over using PIO.  This just isn't possible with more modern DMA engines.

This really makes me think libata should do these commands via PIO
unless we're gonna enable leftover draining for each DMA engine
implementation or blacklist the ones which can't drain individually.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tejun Heo | 1 Nov 2007 01:48
Picon

Re: ATAPI devices in AHCI mode not working

Hello,

Gaston, Jason D wrote:
> Attached are the hdparm -I /dev/cdrom results for the three other drives
> I am using.  These do not include the original drive that had the major
> issues on, TSSTcorpCD/DVDW SH-S183L.
> 
> Applying the patch to the 2.6.24-rc kernel did not cause the same
> behavior, which I am seeing with older kernels.  Instead, everything
> seemed to be fine until I tried to automount the drive, which said that
> there was no media.  I was however, able to manually mount the drive.

Thanks.  Yeah, libata in SLE10SP1 can be considered ancient considering
the speed libata code has been evolving.  Please file a bug report in
bugzilla.novell.com and assign it to teheo <at> novell.com.  Eeeek... /me
hates vendor kernels.  :-)

Thanks.

--

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Shaohua Li | 1 Nov 2007 03:50
Picon
Favicon

Re: [PATCH]libata-acpi: add ACPI _PSx method

On Wed, 2007-10-31 at 14:26 +0100, Rafael J. Wysocki wrote:
> On Wednesday, 31 October 2007 03:27, Len Brown wrote:
> > It would be interseting if any of the folks having power consumption
> > problems when suspended see an improvement with this patch.
> > 
> > Are there plans to refresh this patch and get it upstream?
> > 
> > Acked-by: Len Brown <len.brown <at> intel.com>
> 
> There was a discussion regarding this patch, IIRC, and it was argued that
> _PSx are only applicable to IDE/PATA devices.
> 
> I wonder if this has been addressed.
Sure, there is a check for PATA. I refreshed the patch to against latest
git tree.

ACPI spec (ver 3.0a, p289) requires IDE power on/off executes ACPI _PSx
methods. As recently most PATA drivers use libata, this patch adds _PSx
method support in libata. ACPI spec doesn't mention if SATA requires the
same _PSx method.

Signed-off-by: Shaohua Li <shaohua.li <at> intel.com>
Acked-by: Len Brown <len.brown <at> intel.com>
---
 drivers/ata/libata-acpi.c |   33 +++++++++++++++++++++++++++++++++
 drivers/ata/libata-eh.c   |    3 +++
 drivers/ata/libata.h      |    2 ++
 3 files changed, 38 insertions(+)

Index: linux/drivers/ata/libata-acpi.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tejun Heo | 1 Nov 2007 08:24
Picon

Re: "Fix ATAPI transfer lengths" causes CD writing regression

Tejun Heo wrote:
> Hello, Jeff.
> 
> Jeff Garzik wrote:
>> That's easy for the PIO case.  But CD writing is normally DMA, which
>> means you will get a DMA engine exception if the device wants to give
>> you more data than the scatter/gather entries permit.
> 
> For sense data and mode pages, the standard-sanctioned way to know the
> transfer size is to issue command with short buffer size just enough to
> contain the fixed size header part, determine actual transfer size from
> it and issue the command again with the correct buffer size.  This
> doesn't happen for READ/WRITE commands.  Transfer sizes are
> pre-determined for those commands and WRITE's to optical devices often
> can't be retried w/o side effect.
> 
> I've just went through the ATA spec and this basically means we can't
> use DMA for these variable-transfer-length commands.  Some DMA engines
> have "throw away what's left over bit" in its command structure or SG
> entry but not all do and none of drivers we currently has such feature
> enabled.
> 
> Hmmm.... reading ide-cd.c::cdrom_pc_intr().  OIC, ide-cd is dealing with
> this problem by draining PIO after BMDMA engine is done.  This is
> possible for BMDMA engines as they simply step out when the SG entries
> are exhausted; then, the interrupt handler kicks in and drains the
> left-over using PIO.  This just isn't possible with more modern DMA engines.
> 
> This really makes me think libata should do these commands via PIO
> unless we're gonna enable leftover draining for each DMA engine
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jens Axboe | 1 Nov 2007 09:41
Picon
Favicon

Re: Suspend to ram regression (2.6.24-rc1-git)

On Wed, Oct 31 2007, Jens Axboe wrote:
> Hi,
> 
> My x60 stopped suspending about two days ago. It just freezes after
> printing
> 
> Suspending console(s)
> 
> where it would normally turn everything off and the 'moon' light would
> go on. Posting this message in case somebody else knows what is up, if
> not I'll do a bisect on it tomorrow.

Did the bisect, it points to this commit:

1556594f913fa81d008cecfe46d7211c919a853 is first bad commit
commit 31556594f913fa81d008cecfe46d7211c919a853
Author: Kristen Carlson Accardi <kristen.c.accardi <at> intel.com>
Date:   Thu Oct 25 01:33:26 2007 -0400

    [libata] AHCI: add hw link power management support

Booting any kernel after this commit fails suspending to ram, it just
sits there forever.

--

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 26 comments |
headers
jameshsu | 1 Nov 2007 09:47

Re: Should be Acard ATP8620 2SATA / 1 IDE driver

Hi Jeff,

".....Is your hardware documentation public?  I can help provide a sample
driver for your hardware, or help guide your engineers in this
effort........"
 =>>>>>  Product spec is under preparation, will be provided soon.
Right after doc public, please help us to provide a sample driver in your
eralier conveniance??
This way to ensure SATA driver of this hardware will be compliance with
Linux kernel requirement.
Thanks!

James Hsu
----- Original Message -----
From: Jeff Garzik
To: jameshsu
Cc: linux-scsi <at> vger.kernel.org ; 'David Miller' ; James Bottomley ; Matti
Aarnio ; tytso <at> us.ibm.com ; IDE/ATA development list ; Andrew Morton
Sent: Tuesday, October 30, 2007 6:24 PM
Subject: Re: Should be Acard ATP8620 2SATA / 1 IDE driver

jameshsu wrote:
> Should be in TEXT/PLAIN mode. --- resend
>
> ************************
> Hello,
>
> This driver has nothing changed since last time submit.
> However recently we download 2.6.23.1 kernel and found Acard ATP8620 SATA
> driver is still not there.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 1 Nov 2007 10:07
Favicon

[PATCH] libata ATAPI transfer size cleanups


This is purely for comment and testing, not for merging (yet?).

A common recipe in several vendor drivers (either GPL'd, or I have NDA'd
access to use them as a documentation-like reference) for ATAPI was
slightly different from ours.  This recipe can be found in
atapi_tf_xfer_size(), and it's slightly different from Alan's.

This patch also adds some byte count checks, consolidated
ata_pio_use_silly() use, and adds a dmadir-related FIXME.

The 'xfer-size' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git xfer-size

to receive the following updates:

 drivers/ata/libata-core.c |   53 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/ata/libata-eh.c   |   11 +--------
 drivers/ata/libata-scsi.c |   48 +++++++++-------------------------------
 drivers/ata/libata.h      |    7 ++++++
 4 files changed, 72 insertions(+), 47 deletions(-)

Jeff Garzik (1):
      [libata] Standardize ATAPI byte count [limit] handling

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 63035d7..5c616a8 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
 <at>  <at>  -5258,6 +5258,55  <at>  <at>  next_sg:
(Continue reading)

Permalink | Reply | 28 comments |
headers
Jens Axboe | 1 Nov 2007 10:21
Picon
Favicon

Re: Suspend to ram regression (2.6.24-rc1-git)

On Thu, Nov 01 2007, Jens Axboe wrote:
> On Wed, Oct 31 2007, Jens Axboe wrote:
> > Hi,
> > 
> > My x60 stopped suspending about two days ago. It just freezes after
> > printing
> > 
> > Suspending console(s)
> > 
> > where it would normally turn everything off and the 'moon' light would
> > go on. Posting this message in case somebody else knows what is up, if
> > not I'll do a bisect on it tomorrow.
> 
> Did the bisect, it points to this commit:
> 
> 1556594f913fa81d008cecfe46d7211c919a853 is first bad commit
> commit 31556594f913fa81d008cecfe46d7211c919a853
> Author: Kristen Carlson Accardi <kristen.c.accardi <at> intel.com>
> Date:   Thu Oct 25 01:33:26 2007 -0400
> 
>     [libata] AHCI: add hw link power management support
> 
> Booting any kernel after this commit fails suspending to ram, it just
> sits there forever.

Reverting just the default AHCI flags makes it work again. IOW, with the
below patch I can suspend properly with current -git.

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index ed9b407..77f7631 100644
(Continue reading)

Permalink | Reply | 12 comments |
headers
Jens Axboe | 1 Nov 2007 10:25
Picon
Favicon

Re: Suspend to ram regression (2.6.24-rc1-git)

On Thu, Nov 01 2007, Jens Axboe wrote:
> On Thu, Nov 01 2007, Jens Axboe wrote:
> > On Wed, Oct 31 2007, Jens Axboe wrote:
> > > Hi,
> > > 
> > > My x60 stopped suspending about two days ago. It just freezes after
> > > printing
> > > 
> > > Suspending console(s)
> > > 
> > > where it would normally turn everything off and the 'moon' light would
> > > go on. Posting this message in case somebody else knows what is up, if
> > > not I'll do a bisect on it tomorrow.
> > 
> > Did the bisect, it points to this commit:
> > 
> > 1556594f913fa81d008cecfe46d7211c919a853 is first bad commit
> > commit 31556594f913fa81d008cecfe46d7211c919a853
> > Author: Kristen Carlson Accardi <kristen.c.accardi <at> intel.com>
> > Date:   Thu Oct 25 01:33:26 2007 -0400
> > 
> >     [libata] AHCI: add hw link power management support
> > 
> > Booting any kernel after this commit fails suspending to ram, it just
> > sits there forever.
> 
> Reverting just the default AHCI flags makes it work again. IOW, with the
> below patch I can suspend properly with current -git.
> 
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Cox | 1 Nov 2007 10:43
Picon

Re: [PATCH] libata ATAPI transfer size cleanups

On Thu, 1 Nov 2007 05:07:33 -0400
Jeff Garzik <jeff <at> garzik.org> wrote:

> 
> This is purely for comment and testing, not for merging (yet?).
> 
> A common recipe in several vendor drivers (either GPL'd, or I have NDA'd
> access to use them as a documentation-like reference) for ATAPI was
> slightly different from ours.  This recipe can be found in
> atapi_tf_xfer_size(), and it's slightly different from Alan's.

Looks mostly good. Might cause breakage on one or two controllers by
setting lbam/lbah to 0 for DMA but we can test that and find out.

Note however - the scheme in use now has been tested for over ten years
in drivers/ide. The scheme below has not...

Having an ata_tf_xfer_size method is definitely a good idea whatever
methods we eventually decide on.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |

Gmane