Re: [RFC][PATCH] libata: enable SATA disk fua detection on default

[Jeff Garzik]

On 09/09/2012 04:34 PM, Arvydas Sidorenko wrote:

Meanwhile there already has a number of SATA disks that have supported
this feature.  So I think maybe we can enable it.

Regards,
Zheng


Blindly enabling FUA by default in my opinion is not a good idea at all.
I believe the focus should be on detecting FUA support on the device
instead, which the kernel at this point cannot reliably do (is it possible?).


Premature assumptions.  It is entirely possible that FUA is detected 
accurately, but the software is missing a flush somewhere that FUA 
requires, if disks are to be used in FUA mode.


The filesystem and the block layer must properly generate and order 
their I/Os based on the FUA enablement bits that appear in the block 
layer after libata discovers the SATA FUA feature.


Jeff




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] libata: enable SATA disk fua detection on default

[Arvydas Sidorenko]

> Meanwhile there already has a number of SATA disks that have supported
> this feature.  So I think maybe we can enable it.
>
> Regards,
> Zheng

Blindly enabling FUA by default in my opinion is not a good idea at all.
I believe the focus should be on detecting FUA support on the device
instead, which the kernel at this point cannot reliably do (is it possible?).

This patch introduced regression: https://lkml.org/lkml/2012/8/27/66

Arvydas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] libata: enable SATA disk fua detection on default

[Arvydas Sidorenko]

 Meanwhile there already has a number of SATA disks that have supported
 this feature.  So I think maybe we can enable it.

 Regards,
 Zheng

Blindly enabling FUA by default in my opinion is not a good idea at all.
I believe the focus should be on detecting FUA support on the device
instead, which the kernel at this point cannot reliably do (is it possible?).

This patch introduced regression: https://lkml.org/lkml/2012/8/27/66

Arvydas
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] libata: enable SATA disk fua detection on default

[Jeff Garzik]

On 09/09/2012 04:34 PM, Arvydas Sidorenko wrote:

Meanwhile there already has a number of SATA disks that have supported
this feature.  So I think maybe we can enable it.

Regards,
Zheng


Blindly enabling FUA by default in my opinion is not a good idea at all.
I believe the focus should be on detecting FUA support on the device
instead, which the kernel at this point cannot reliably do (is it possible?).


Premature assumptions.  It is entirely possible that FUA is detected 
accurately, but the software is missing a flush somewhere that FUA 
requires, if disks are to be used in FUA mode.


The filesystem and the block layer must properly generate and order 
their I/Os based on the FUA enablement bits that appear in the block 
layer after libata discovers the SATA FUA feature.


Jeff




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Enabling FUA for SATA drives (was Re: [RFC][PATCH] libata: enable SATA disk fua detection on default)

[Jeff Garzik]

On 05/07/2012 11:24 PM, Zheng Liu wrote:

From: Zheng Liu 

Currently, SATA disk fua detection is disabled on default because most of
devices don't support this feature at that time.  With the development of
technology, more and more SATA disks support this feature.  So now we can enable
this detection on default.

Although fua detection is defined as a kernel module parameter, it is too hard
to set its value because it must be loaded and set before system starts up.
That needs to modify initrd file.  So it is inconvenient for administrator who
needs to manage a huge number of servers.

CC: Jeff Garzik 
Signed-off-by: Zheng Liu 
---
  drivers/ata/libata-core.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 23763a1..3627251 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -133,9 +133,9 @@ int atapi_passthru16 = 1;
  module_param(atapi_passthru16, int, 0444);
  MODULE_PARM_DESC(atapi_passthru16, "Enable ATA_16 passthru for ATAPI devices 
(0=off, 1=on [default])");

-int libata_fua = 0;
+int libata_fua = 1;
  module_param_named(fua, libata_fua, int, 0444);
-MODULE_PARM_DESC(fua, "FUA support (0=off [default], 1=on)");
+MODULE_PARM_DESC(fua, "FUA support (0=off, 1=on [default])");


Applied.  Let's see how far down the rabbit hole we go ;-)

The FUA decision, as previously indicated, was based on early SATA 
drives, and perhaps better ones are available now.  Only testing will 
tell, at this point.


The larger questions, raised by Christoph and others remain unaddressed 
(though perhaps we can start addressing them now, with this patch):


* what is smart flushing policy for ATA devices with FUA?

* ATA NCQ's flush is not queued

* ATA NCQ always had the FUA bit...

* ...but mixing ATA NCQ FUA and !FUA in a queue is not fully supported 
by the existing code


and probably a few other details I forgot :)

Jeff







--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Enabling FUA for SATA drives (was Re: [RFC][PATCH] libata: enable SATA disk fua detection on default)

[Jeff Garzik]

On 05/07/2012 11:24 PM, Zheng Liu wrote:

From: Zheng Liu wenqing...@taobao.com

Currently, SATA disk fua detection is disabled on default because most of
devices don't support this feature at that time.  With the development of
technology, more and more SATA disks support this feature.  So now we can enable
this detection on default.

Although fua detection is defined as a kernel module parameter, it is too hard
to set its value because it must be loaded and set before system starts up.
That needs to modify initrd file.  So it is inconvenient for administrator who
needs to manage a huge number of servers.

CC: Jeff Garzik j...@garzik.org
Signed-off-by: Zheng Liu wenqing...@taobao.com
---
  drivers/ata/libata-core.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 23763a1..3627251 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -133,9 +133,9 @@ int atapi_passthru16 = 1;
  module_param(atapi_passthru16, int, 0444);
  MODULE_PARM_DESC(atapi_passthru16, Enable ATA_16 passthru for ATAPI devices 
(0=off, 1=on [default]));

-int libata_fua = 0;
+int libata_fua = 1;
  module_param_named(fua, libata_fua, int, 0444);
-MODULE_PARM_DESC(fua, FUA support (0=off [default], 1=on));
+MODULE_PARM_DESC(fua, FUA support (0=off, 1=on [default]));


Applied.  Let's see how far down the rabbit hole we go ;-)

The FUA decision, as previously indicated, was based on early SATA 
drives, and perhaps better ones are available now.  Only testing will 
tell, at this point.


The larger questions, raised by Christoph and others remain unaddressed 
(though perhaps we can start addressing them now, with this patch):


* what is smart flushing policy for ATA devices with FUA?

* ATA NCQ's flush is not queued

* ATA NCQ always had the FUA bit...

* ...but mixing ATA NCQ FUA and !FUA in a queue is not fully supported 
by the existing code


and probably a few other details I forgot :)

Jeff







--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[Bartlomiej Zolnierkiewicz]

On Sunday 06 January 2008, FD Cami wrote:
> On Sun, 6 Jan 2008 17:27:38 +0100
> Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> 
> > On Sunday 06 January 2008, FD Cami wrote:
> > > On Sun, 6 Jan 2008 13:36:09 +
> > > Alan Cox <[EMAIL PROTECTED]> wrote:
> > > 
> > > > On Sun, 6 Jan 2008 08:03:31 +0300
> > > > > > For now you can boot with libata.dma=1 to select DMA on disks
> > > > > > but not CD
> > > > > 
> > > > > Great, but why isn't this in the documentation?
> > > > 
> > > > Send patches
> > > 
> > > patch attached.
> > > 
> > > Description : Add libata.dma= to Documentation/kernel-parameters.txt
> > > 
> > > Found documentation in :
> > > http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html
> > > http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html
> > > 
> > > Signed-off-by: François Cami <[EMAIL PROTECTED]>
> > 
> > diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt 
> > linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
> > ---
> > linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06
> > 15:58:54.0 +0100 +++
> > linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06
> > 16:11:20.0 +0100 @@ -883,4 +883,11 @@ C2 power state. 
> > +   libata.dma= [LIBATA] DMA control
> > +   libata.dma=0  Disable all PATA DMA like
> > old IDE
> > 
> > this doesn't seem entirely correct:
> > 
> > * IDE has "hdx=nodma" so you can disable DMA on per-device basis
> 
> I think that libata.dma=1 is designed to behave like 
> CONFIG_IDEDMA_ONLYDISK used to. "hdx=nodma" is more fine-grained than
> this.

Seems so but CONFIG_IDEDMA_ONLYDISK was removed on the same day
that "hdx=nodma" was introduced (Oct 16 2007)...

> > * is this really limited to PATA?
> 
> Alan's original patch took care of PATA. SATA support was added
> later by Jeff Garzik. Corrected documentation patch attached.
> 
> > +   libata.dma=1  Disk DMA only
> > +   libata.dma=2  ATAPI DMA only
> > +   libata.dma=3  CF DMA only 
> 
> This is also wrong, it should be "libata.dma=4  CF DMA only"
> Thanks to Zoltan Boszormenyi <[EMAIL PROTECTED]> for catching this
> mistake.
> 
> Revised patch attached.

Thanks, looks good to me.

Bart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[FD Cami]

On Sun, 6 Jan 2008 17:27:38 +0100
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:

> On Sunday 06 January 2008, FD Cami wrote:
> > On Sun, 6 Jan 2008 13:36:09 +
> > Alan Cox <[EMAIL PROTECTED]> wrote:
> > 
> > > On Sun, 6 Jan 2008 08:03:31 +0300
> > > > > For now you can boot with libata.dma=1 to select DMA on disks
> > > > > but not CD
> > > > 
> > > > Great, but why isn't this in the documentation?
> > > 
> > > Send patches
> > 
> > patch attached.
> > 
> > Description : Add libata.dma= to Documentation/kernel-parameters.txt
> > 
> > Found documentation in :
> > http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html
> > http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html
> > 
> > Signed-off-by: François Cami <[EMAIL PROTECTED]>
> 
> diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt 
> linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
> ---
> linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06
> 15:58:54.0 +0100 +++
> linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06
> 16:11:20.0 +0100 @@ -883,4 +883,11 @@ C2 power state. 
> +   libata.dma= [LIBATA] DMA control
> +   libata.dma=0  Disable all PATA DMA like
> old IDE
> 
> this doesn't seem entirely correct:
> 
> * IDE has "hdx=nodma" so you can disable DMA on per-device basis

I think that libata.dma=1 is designed to behave like 
CONFIG_IDEDMA_ONLYDISK used to. "hdx=nodma" is more fine-grained than
this.

> * is this really limited to PATA?

Alan's original patch took care of PATA. SATA support was added
later by Jeff Garzik. Corrected documentation patch attached.

> +   libata.dma=1  Disk DMA only
> +   libata.dma=2  ATAPI DMA only
> +   libata.dma=3  CF DMA only 

This is also wrong, it should be "libata.dma=4  CF DMA only"
Thanks to Zoltan Boszormenyi <[EMAIL PROTECTED]> for catching this
mistake.

Revised patch attached.

Best,

François
diff -rU4 linux-2.6.24-rc6/Documentation/kernel-parameters.txt 
linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
--- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 
15:58:54.0 +0100
+++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06 
18:46:49.0 +0100
@@ -881,8 +881,16 @@
 
lapic_timer_c2_ok   [X86-32,x86-64,APIC] trust the local apic timer 
in
C2 power state.
 
+   libata.dma= [LIBATA] DMA control
+   libata.dma=0  Disable all PATA and SATA DMA
+   libata.dma=1  PATA and SATA Disk DMA only
+   libata.dma=2  ATAPI (CDROM) DMA only
+   libata.dma=4  Compact Flash DMA only 
+   Combinations also work, so libata.dma=3 enables DMA
+   for disks and CDROMs, but not CFs.
+
libata.noacpi   [LIBATA] Disables use of ACPI in libata suspend/resume
when set.
Format: 
 

[PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY

[Zoltan Boszormenyi]

Hi,

Once upon a time FD Cami wrote:

On Sun, 6 Jan 2008 13:36:09 +
Alan Cox <[EMAIL PROTECTED]> wrote:

> On Sun, 6 Jan 2008 08:03:31 +0300
> > > For now you can boot with libata.dma=1 to select DMA on disks but
> > > not CD
> > 
> > Great, but why isn't this in the documentation?
> 
> Send patches


patch attached.

Description : Add libata.dma= to Documentation/kernel-parameters.txt

Found documentation in :
http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html
http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html

Signed-off-by: François Cami <[EMAIL PROTECTED]>

*["libata-doc-patch.txt" (text/plain)]* 


diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt \
linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
--- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 \
15:58:54.0 +0100
+++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06 \
16:11:20.0 +0100 @@ -883,4 +883,11 @@
C2 power state.
 
+	libata.dma=	[LIBATA] DMA control

+   libata.dma=0  Disable all PATA DMA like old IDE
+   libata.dma=1  Disk DMA only
+   libata.dma=2  ATAPI DMA only
+			libata.dma=3	  CF DMA only 
+			libata.dma=0,1,3  Combinations also work.

+
  


The code patch you are looking at has little different semantics.
(1 << 2) is 4 not 3... Values for different devices are:

1  - ATA
2 - ATAPI
4 - CF

The parameter is a bitmask of 1, 2, 4. Default is 7.
2.6.24-rc3 also has this in libata-core.c which confirms
the acceptance of a bitmask :

static int libata_dma_mask = 
ATA_DMA_MASK_ATA|ATA_DMA_MASK_ATAPI|ATA_DMA_MASK_CFA;

module_param_named(dma, libata_dma_mask, int, 0444);
MODULE_PARM_DESC(dma, "DMA enable/disable (0x1==ATA, 0x2==ATAPI, 0x4==CF)");

Best regards,
Zoltán Böszörményi


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[FD Cami]

On Sun, 6 Jan 2008 13:36:09 +
Alan Cox <[EMAIL PROTECTED]> wrote:

> On Sun, 6 Jan 2008 08:03:31 +0300
> > > For now you can boot with libata.dma=1 to select DMA on disks but
> > > not CD
> > 
> > Great, but why isn't this in the documentation?
> 
> Send patches

patch attached.

Description : Add libata.dma= to Documentation/kernel-parameters.txt

Found documentation in :
http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html
http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html

Signed-off-by: François Cami <[EMAIL PROTECTED]>
diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt 
linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
--- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 
15:58:54.0 +0100
+++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06 
16:11:20.0 +0100
@@ -883,4 +883,11 @@
C2 power state.
 
+   libata.dma= [LIBATA] DMA control
+   libata.dma=0  Disable all PATA DMA like old IDE
+   libata.dma=1  Disk DMA only
+   libata.dma=2  ATAPI DMA only
+   libata.dma=3  CF DMA only 
+   libata.dma=0,1,3  Combinations also work.
+
libata.noacpi   [LIBATA] Disables use of ACPI in libata suspend/resume
when set.

Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[Alan Cox]

On Sun, 6 Jan 2008 08:03:31 +0300
> > For now you can boot with libata.dma=1 to select DMA on disks but not CD
> 
> Great, but why isn't this in the documentation?

Send patches
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[Alan Cox]

On Sun, 6 Jan 2008 08:03:31 +0300
  For now you can boot with libata.dma=1 to select DMA on disks but not CD
 
 Great, but why isn't this in the documentation?

Send patches
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[FD Cami]

On Sun, 6 Jan 2008 13:36:09 +
Alan Cox [EMAIL PROTECTED] wrote:

 On Sun, 6 Jan 2008 08:03:31 +0300
   For now you can boot with libata.dma=1 to select DMA on disks but
   not CD
  
  Great, but why isn't this in the documentation?
 
 Send patches

patch attached.

Description : Add libata.dma= to Documentation/kernel-parameters.txt

Found documentation in :
http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html
http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html

Signed-off-by: François Cami [EMAIL PROTECTED]
diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt 
linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
--- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 
15:58:54.0 +0100
+++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06 
16:11:20.0 +0100
@@ -883,4 +883,11 @@
C2 power state.
 
+   libata.dma= [LIBATA] DMA control
+   libata.dma=0  Disable all PATA DMA like old IDE
+   libata.dma=1  Disk DMA only
+   libata.dma=2  ATAPI DMA only
+   libata.dma=3  CF DMA only 
+   libata.dma=0,1,3  Combinations also work.
+
libata.noacpi   [LIBATA] Disables use of ACPI in libata suspend/resume
when set.

[PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY

[Zoltan Boszormenyi]

Hi,

Once upon a time FD Cami wrote:

On Sun, 6 Jan 2008 13:36:09 +
Alan Cox [EMAIL PROTECTED] wrote:

 On Sun, 6 Jan 2008 08:03:31 +0300
   For now you can boot with libata.dma=1 to select DMA on disks but
   not CD
  
  Great, but why isn't this in the documentation?
 
 Send patches


patch attached.

Description : Add libata.dma= to Documentation/kernel-parameters.txt

Found documentation in :
http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html
http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html

Signed-off-by: François Cami [EMAIL PROTECTED]

*[libata-doc-patch.txt (text/plain)]* 
http://marc.info/?l=linux-kernelm=119963307018562q=p3

diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt \
linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
--- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 \
15:58:54.0 +0100
+++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06 \
16:11:20.0 +0100 @@ -883,4 +883,11 @@
C2 power state.
 
+	libata.dma=	[LIBATA] DMA control

+   libata.dma=0  Disable all PATA DMA like old IDE
+   libata.dma=1  Disk DMA only
+   libata.dma=2  ATAPI DMA only
+			libata.dma=3	  CF DMA only 
+			libata.dma=0,1,3  Combinations also work.

+
  


The code patch you are looking at has little different semantics.
(1  2) is 4 not 3... Values for different devices are:

1  - ATA
2 - ATAPI
4 - CF

The parameter is a bitmask of 1, 2, 4. Default is 7.
2.6.24-rc3 also has this in libata-core.c which confirms
the acceptance of a bitmask :

static int libata_dma_mask = 
ATA_DMA_MASK_ATA|ATA_DMA_MASK_ATAPI|ATA_DMA_MASK_CFA;

module_param_named(dma, libata_dma_mask, int, 0444);
MODULE_PARM_DESC(dma, DMA enable/disable (0x1==ATA, 0x2==ATAPI, 0x4==CF));

Best regards,
Zoltán Böszörményi


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[FD Cami]

On Sun, 6 Jan 2008 17:27:38 +0100
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:

 On Sunday 06 January 2008, FD Cami wrote:
  On Sun, 6 Jan 2008 13:36:09 +
  Alan Cox [EMAIL PROTECTED] wrote:
  
   On Sun, 6 Jan 2008 08:03:31 +0300
 For now you can boot with libata.dma=1 to select DMA on disks
 but not CD

Great, but why isn't this in the documentation?
   
   Send patches
  
  patch attached.
  
  Description : Add libata.dma= to Documentation/kernel-parameters.txt
  
  Found documentation in :
  http://www.mail-archive.com/linux-ide%40vger.kernel.org/msg09849.html
  http://www.redhat.com/archives/fedora-extras-commits/2007-October/msg04568.html
  
  Signed-off-by: François Cami [EMAIL PROTECTED]
 
 diff -rU2 linux-2.6.24-rc6/Documentation/kernel-parameters.txt 
 linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
 ---
 linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06
 15:58:54.0 +0100 +++
 linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06
 16:11:20.0 +0100 @@ -883,4 +883,11 @@ C2 power state. 
 +   libata.dma= [LIBATA] DMA control
 +   libata.dma=0  Disable all PATA DMA like
 old IDE
 
 this doesn't seem entirely correct:
 
 * IDE has hdx=nodma so you can disable DMA on per-device basis

I think that libata.dma=1 is designed to behave like 
CONFIG_IDEDMA_ONLYDISK used to. hdx=nodma is more fine-grained than
this.

 * is this really limited to PATA?

Alan's original patch took care of PATA. SATA support was added
later by Jeff Garzik. Corrected documentation patch attached.

 +   libata.dma=1  Disk DMA only
 +   libata.dma=2  ATAPI DMA only
 +   libata.dma=3  CF DMA only 

This is also wrong, it should be libata.dma=4  CF DMA only
Thanks to Zoltan Boszormenyi [EMAIL PROTECTED] for catching this
mistake.

Revised patch attached.

Best,

François
diff -rU4 linux-2.6.24-rc6/Documentation/kernel-parameters.txt 
linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt
--- linux-2.6.24-rc6/Documentation/kernel-parameters.txt2008-01-06 
15:58:54.0 +0100
+++ linux-2.6.24-rc6-mine/Documentation/kernel-parameters.txt   2008-01-06 
18:46:49.0 +0100
@@ -881,8 +881,16 @@
 
lapic_timer_c2_ok   [X86-32,x86-64,APIC] trust the local apic timer 
in
C2 power state.
 
+   libata.dma= [LIBATA] DMA control
+   libata.dma=0  Disable all PATA and SATA DMA
+   libata.dma=1  PATA and SATA Disk DMA only
+   libata.dma=2  ATAPI (CDROM) DMA only
+   libata.dma=4  Compact Flash DMA only 
+   Combinations also work, so libata.dma=3 enables DMA
+   for disks and CDROMs, but not CFs.
+
libata.noacpi   [LIBATA] Disables use of ACPI in libata suspend/resume
when set.
Format: int
 

Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[Al Boldi]

Alan Cox wrote:
> Al Boldi <[EMAIL PROTECTED]> wrote:
> > What's hindering the ability to force a mode in libata, as is possible
> > with the normal ide-driver?
>
> We want it to be correct and race free. That means we have to synchronize
> all the devices on the controller, quiesce them and recompute the speeds
> for each device then turn them all back on and resume command processing.
>
> It is quite hairy although Tejun's EH work has provided the framework for
> all of this.
>
> For now you can boot with libata.dma=1 to select DMA on disks but not CD

Great, but why isn't this in the documentation?


Thanks!

--
Al

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[Alan Cox]

On Sat, 5 Jan 2008 16:41:03 +0300
Al Boldi <[EMAIL PROTECTED]> wrote:

> What's hindering the ability to force a mode in libata, as is possible with 
> the normal ide-driver?

We want it to be correct and race free. That means we have to synchronize
all the devices on the controller, quiesce them and recompute the speeds
for each device then turn them all back on and resume command processing.

It is quite hairy although Tejun's EH work has provided the framework for
all of this.

For now you can boot with libata.dma=1 to select DMA on disks but not CD
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Forcing modes in libata (was: SATA buffered read VERY slow)

[Al Boldi]

Alan Cox wrote:
> hdparm supports identify to read modes on drives with libata. The one
> thing you cannot do is force modes right now.

I have some AOpen 52x/32x CD-RWriter, that advertises itself as DMA capable, 
but has a hard time sustaining such access.  The only way to make access to 
this drive safe is by reducing it to PIO-3 even on XP,  which makes libata 
somewhat unusable on this drive, especially for writing.

What's hindering the ability to force a mode in libata, as is possible with 
the normal ide-driver?


Thanks!

--
Al

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Forcing modes in libata (was: SATA buffered read VERY slow)

[Al Boldi]

Alan Cox wrote:
 hdparm supports identify to read modes on drives with libata. The one
 thing you cannot do is force modes right now.

I have some AOpen 52x/32x CD-RWriter, that advertises itself as DMA capable, 
but has a hard time sustaining such access.  The only way to make access to 
this drive safe is by reducing it to PIO-3 even on XP,  which makes libata 
somewhat unusable on this drive, especially for writing.

What's hindering the ability to force a mode in libata, as is possible with 
the normal ide-driver?


Thanks!

--
Al

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Forcing modes in libata (was: SATA buffered read VERY slow)

[Alan Cox]

On Sat, 5 Jan 2008 16:41:03 +0300
Al Boldi [EMAIL PROTECTED] wrote:

 What's hindering the ability to force a mode in libata, as is possible with 
 the normal ide-driver?

We want it to be correct and race free. That means we have to synchronize
all the devices on the controller, quiesce them and recompute the speeds
for each device then turn them all back on and resume command processing.

It is quite hairy although Tejun's EH work has provided the framework for
all of this.

For now you can boot with libata.dma=1 to select DMA on disks but not CD
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Alan]

> IMO creating a new check_atapi_dma function for first-gen chips would be 
> the preferred way to add this check.

A mode filter would be even better, that will mean the list of modes on
the device is correct and ATAPI devices are shown as PIO on such a
controller.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Mikael Pettersson]

On Sun, 07 Jan 2007 20:47:35 -0500, Jeff Garzik wrote:
> Mikael Pettersson wrote:
> > @@ -789,8 +789,14 @@ static void pdc_exec_command_mmio(struct
> >  static int pdc_check_atapi_dma(struct ata_queued_cmd *qc)
> >  {
> > u8 *scsicmd = qc->scsicmd->cmnd;
> > +   struct ata_port *ap = qc->ap;
> > +   struct pdc_host_priv *hp = ap->host->private_data;
> > int pio = 1; /* atapi dma off by default */
> >  
> > +   /* First generation chips cannot use ATAPI DMA on SATA ports */
> > +   if (!(hp->flags & PDC_FLAG_GEN_II) && sata_scr_valid(ap))
> > +   return 1;
> > +
> > /* Whitelist commands that may use DMA. */
> > switch (scsicmd[0]) {
> > case WRITE_12:
> 
> 
> IMO creating a new check_atapi_dma function for first-gen chips would be 
> the preferred way to add this check.

Agreed. Will do.

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: unbreak 20619

[Mikael Pettersson]

On Sun, 07 Jan 2007 20:46:13 -0500, Jeff Garzik wrote:
> Given that I agree with your RFC, this means I can drop all these 
> #promise-sata-pata patches, and kill the #promise-sata-pata branch soon, 
> right?

Yes

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: unbreak 20619

[Mikael Pettersson]

On Sun, 07 Jan 2007 20:46:13 -0500, Jeff Garzik wrote:
 Given that I agree with your RFC, this means I can drop all these 
 #promise-sata-pata patches, and kill the #promise-sata-pata branch soon, 
 right?

Yes

/Mikael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Mikael Pettersson]

On Sun, 07 Jan 2007 20:47:35 -0500, Jeff Garzik wrote:
 Mikael Pettersson wrote:
  @@ -789,8 +789,14 @@ static void pdc_exec_command_mmio(struct
   static int pdc_check_atapi_dma(struct ata_queued_cmd *qc)
   {
  u8 *scsicmd = qc-scsicmd-cmnd;
  +   struct ata_port *ap = qc-ap;
  +   struct pdc_host_priv *hp = ap-host-private_data;
  int pio = 1; /* atapi dma off by default */
   
  +   /* First generation chips cannot use ATAPI DMA on SATA ports */
  +   if (!(hp-flags  PDC_FLAG_GEN_II)  sata_scr_valid(ap))
  +   return 1;
  +
  /* Whitelist commands that may use DMA. */
  switch (scsicmd[0]) {
  case WRITE_12:
 
 
 IMO creating a new check_atapi_dma function for first-gen chips would be 
 the preferred way to add this check.

Agreed. Will do.

/Mikael
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Alan]

 IMO creating a new check_atapi_dma function for first-gen chips would be 
 the preferred way to add this check.

A mode filter would be even better, that will mean the list of modes on
the device is correct and ATAPI devices are shown as PIO on such a
controller.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Jeff Garzik]

Mikael Pettersson wrote:

@@ -789,8 +789,14 @@ static void pdc_exec_command_mmio(struct
 static int pdc_check_atapi_dma(struct ata_queued_cmd *qc)
 {
u8 *scsicmd = qc->scsicmd->cmnd;
+   struct ata_port *ap = qc->ap;
+   struct pdc_host_priv *hp = ap->host->private_data;
int pio = 1; /* atapi dma off by default */
 
+	/* First generation chips cannot use ATAPI DMA on SATA ports */

+   if (!(hp->flags & PDC_FLAG_GEN_II) && sata_scr_valid(ap))
+   return 1;
+
/* Whitelist commands that may use DMA. */
switch (scsicmd[0]) {
case WRITE_12:



IMO creating a new check_atapi_dma function for first-gen chips would be 
the preferred way to add this check.


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: unbreak 20619

[Jeff Garzik]

Mikael Pettersson wrote:

The PATA support patch for sata_promise appears, from
code inspection, to break the PATA-only 20619 chip.

The patch removes the SATA flag from the TX2plus SATA+PATA
boards' common flags, with the intention of adding it back
via the _port_flags[] entries for those boards' SATA ports.

However, it unconditionally marks ports 0 and 1 as SATA
for all boards. This causes the 20619 (TX4000) to announce
its first two PATA ports as SATA | ATA_FLAG_SLAVE_POSS.

I don't have a TX4000 so I don't know what the actual
consequences of this bug are, but surely this isn't Ok.

Fixed by moving the port 0 and 1 settings as SATA into
the TX4 and TX2plus specific initialisation code.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>


Given that I agree with your RFC, this means I can drop all these 
#promise-sata-pata patches, and kill the #promise-sata-pata branch soon, 
right?


Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Mikael Pettersson]

On Sat, 6 Jan 2007 21:32:03 +0100 (MET), Mikael Pettersson wrote:
>This patch adds ATAPI support for the PATA port on Promise 2037x chips.
>It depends on the common sata_promise ATAPI support patch.
>
>First-generation chips don't support ATAPI on their SATA ports, so
>the patch removes ATA_FLAG_NO_ATAPI from the 2037x common host flags,
>and adds it back via the _port_flags[] entries for the SATA ports.

Update: SATAPI works on first-generation chips, but only in PIO mode.

To verify that DMA doesn't work I also tried Promise's pdc-ultra
driver for their first-generation chips. It doesn't want to support
ATAPI without an explicit option. Enabling that option makes it
recognise ATAPI devices, but even a simple "eject" command triggers
command timeouts and eventually a kernel oops due to the NMI watchdog.
So I'm fairly sure that DMA simply doesn't work.

This patch enables ATAPI on 20319 and 2037x chips, but forces SATA
ports to always use PIO. As a side-effect, ATAPI support is now free
of any dependencies on the #promise-sata-pata branch.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

--- linux-2.6.20-rc4/drivers/ata/sata_promise.c.~1~ 2007-01-07 
22:58:01.0 +0100
+++ linux-2.6.20-rc4/drivers/ata/sata_promise.c 2007-01-07 23:06:22.0 
+0100
@@ -197,7 +197,7 @@ static const struct ata_port_info pdc_po
/* board_20319 */
{
.sht= _ata_sht,
-   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_NO_ATAPI | 
ATA_FLAG_SATA,
+   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_SATA,
.pio_mask   = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
@@ -789,8 +789,14 @@ static void pdc_exec_command_mmio(struct
 static int pdc_check_atapi_dma(struct ata_queued_cmd *qc)
 {
u8 *scsicmd = qc->scsicmd->cmnd;
+   struct ata_port *ap = qc->ap;
+   struct pdc_host_priv *hp = ap->host->private_data;
int pio = 1; /* atapi dma off by default */
 
+   /* First generation chips cannot use ATAPI DMA on SATA ports */
+   if (!(hp->flags & PDC_FLAG_GEN_II) && sata_scr_valid(ap))
+   return 1;
+
/* Whitelist commands that may use DMA. */
switch (scsicmd[0]) {
case WRITE_12:
@@ -996,10 +1002,6 @@ static int pdc_ata_init_one (struct pci_
probe_ent->n_ports = 2;
probe_ent->_port_flags[0] = ATA_FLAG_SATA;
probe_ent->_port_flags[1] = ATA_FLAG_SATA;
-   if (board_idx == board_2037x) {
-   probe_ent->_port_flags[0] |= ATA_FLAG_NO_ATAPI;
-   probe_ent->_port_flags[1] |= ATA_FLAG_NO_ATAPI;
-   }
break;
case board_20619:
probe_ent->n_ports = 4;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Mikael Pettersson]

On Sat, 6 Jan 2007 21:32:03 +0100 (MET), Mikael Pettersson wrote:
This patch adds ATAPI support for the PATA port on Promise 2037x chips.
It depends on the common sata_promise ATAPI support patch.

First-generation chips don't support ATAPI on their SATA ports, so
the patch removes ATA_FLAG_NO_ATAPI from the 2037x common host flags,
and adds it back via the _port_flags[] entries for the SATA ports.

Update: SATAPI works on first-generation chips, but only in PIO mode.

To verify that DMA doesn't work I also tried Promise's pdc-ultra
driver for their first-generation chips. It doesn't want to support
ATAPI without an explicit option. Enabling that option makes it
recognise ATAPI devices, but even a simple eject command triggers
command timeouts and eventually a kernel oops due to the NMI watchdog.
So I'm fairly sure that DMA simply doesn't work.

This patch enables ATAPI on 20319 and 2037x chips, but forces SATA
ports to always use PIO. As a side-effect, ATAPI support is now free
of any dependencies on the #promise-sata-pata branch.

Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]

--- linux-2.6.20-rc4/drivers/ata/sata_promise.c.~1~ 2007-01-07 
22:58:01.0 +0100
+++ linux-2.6.20-rc4/drivers/ata/sata_promise.c 2007-01-07 23:06:22.0 
+0100
@@ -197,7 +197,7 @@ static const struct ata_port_info pdc_po
/* board_20319 */
{
.sht= pdc_ata_sht,
-   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_NO_ATAPI | 
ATA_FLAG_SATA,
+   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_SATA,
.pio_mask   = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
@@ -789,8 +789,14 @@ static void pdc_exec_command_mmio(struct
 static int pdc_check_atapi_dma(struct ata_queued_cmd *qc)
 {
u8 *scsicmd = qc-scsicmd-cmnd;
+   struct ata_port *ap = qc-ap;
+   struct pdc_host_priv *hp = ap-host-private_data;
int pio = 1; /* atapi dma off by default */
 
+   /* First generation chips cannot use ATAPI DMA on SATA ports */
+   if (!(hp-flags  PDC_FLAG_GEN_II)  sata_scr_valid(ap))
+   return 1;
+
/* Whitelist commands that may use DMA. */
switch (scsicmd[0]) {
case WRITE_12:
@@ -996,10 +1002,6 @@ static int pdc_ata_init_one (struct pci_
probe_ent-n_ports = 2;
probe_ent-_port_flags[0] = ATA_FLAG_SATA;
probe_ent-_port_flags[1] = ATA_FLAG_SATA;
-   if (board_idx == board_2037x) {
-   probe_ent-_port_flags[0] |= ATA_FLAG_NO_ATAPI;
-   probe_ent-_port_flags[1] |= ATA_FLAG_NO_ATAPI;
-   }
break;
case board_20619:
probe_ent-n_ports = 4;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: unbreak 20619

[Jeff Garzik]

Mikael Pettersson wrote:

The PATA support patch for sata_promise appears, from
code inspection, to break the PATA-only 20619 chip.

The patch removes the SATA flag from the TX2plus SATA+PATA
boards' common flags, with the intention of adding it back
via the _port_flags[] entries for those boards' SATA ports.

However, it unconditionally marks ports 0 and 1 as SATA
for all boards. This causes the 20619 (TX4000) to announce
its first two PATA ports as SATA | ATA_FLAG_SLAVE_POSS.

I don't have a TX4000 so I don't know what the actual
consequences of this bug are, but surely this isn't Ok.

Fixed by moving the port 0 and 1 settings as SATA into
the TX4 and TX2plus specific initialisation code.

Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]


Given that I agree with your RFC, this means I can drop all these 
#promise-sata-pata patches, and kill the #promise-sata-pata branch soon, 
right?


Jeff



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Jeff Garzik]

Mikael Pettersson wrote:

@@ -789,8 +789,14 @@ static void pdc_exec_command_mmio(struct
 static int pdc_check_atapi_dma(struct ata_queued_cmd *qc)
 {
u8 *scsicmd = qc-scsicmd-cmnd;
+   struct ata_port *ap = qc-ap;
+   struct pdc_host_priv *hp = ap-host-private_data;
int pio = 1; /* atapi dma off by default */
 
+	/* First generation chips cannot use ATAPI DMA on SATA ports */

+   if (!(hp-flags  PDC_FLAG_GEN_II)  sata_scr_valid(ap))
+   return 1;
+
/* Whitelist commands that may use DMA. */
switch (scsicmd[0]) {
case WRITE_12:



IMO creating a new check_atapi_dma function for first-gen chips would be 
the preferred way to add this check.


Jeff


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Mikael Pettersson]

This patch adds ATAPI support for the PATA port on Promise 2037x chips.
It depends on the common sata_promise ATAPI support patch.

First-generation chips don't support ATAPI on their SATA ports, so
the patch removes ATA_FLAG_NO_ATAPI from the 2037x common host flags,
and adds it back via the _port_flags[] entries for the SATA ports.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

--- linux-2.6.20-rc3/drivers/ata/sata_promise.c.~1~ 2007-01-06 
17:10:56.0 +0100
+++ linux-2.6.20-rc3/drivers/ata/sata_promise.c 2007-01-06 17:14:23.0 
+0100
@@ -187,7 +187,7 @@ static const struct ata_port_info pdc_po
/* board_2037x */
{
.sht= _ata_sht,
-   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_NO_ATAPI /* | 
ATA_FLAG_SATA */,
+   .flags  = PDC_COMMON_FLAGS /* | ATA_FLAG_NO_ATAPI | 
ATA_FLAG_SATA */,
.pio_mask   = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
@@ -996,6 +996,10 @@ static int pdc_ata_init_one (struct pci_
probe_ent->n_ports = 2;
probe_ent->_port_flags[0] = ATA_FLAG_SATA;
probe_ent->_port_flags[1] = ATA_FLAG_SATA;
+   if (board_idx == board_2037x) {
+   probe_ent->_port_flags[0] |= ATA_FLAG_NO_ATAPI;
+   probe_ent->_port_flags[1] |= ATA_FLAG_NO_ATAPI;
+   }
break;
case board_20619:
probe_ent->n_ports = 4;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH libata #promise-sata-pata] sata_promise: unbreak 20619

[Mikael Pettersson]

The PATA support patch for sata_promise appears, from
code inspection, to break the PATA-only 20619 chip.

The patch removes the SATA flag from the TX2plus SATA+PATA
boards' common flags, with the intention of adding it back
via the _port_flags[] entries for those boards' SATA ports.

However, it unconditionally marks ports 0 and 1 as SATA
for all boards. This causes the 20619 (TX4000) to announce
its first two PATA ports as SATA | ATA_FLAG_SLAVE_POSS.

I don't have a TX4000 so I don't know what the actual
consequences of this bug are, but surely this isn't Ok.

Fixed by moving the port 0 and 1 settings as SATA into
the TX4 and TX2plus specific initialisation code.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>

--- linux-2.6.20-rc3/drivers/ata/sata_promise.c.~1~ 2007-01-06 
17:05:29.0 +0100
+++ linux-2.6.20-rc3/drivers/ata/sata_promise.c 2007-01-06 17:10:56.0 
+0100
@@ -957,9 +957,6 @@ static int pdc_ata_init_one (struct pci_
probe_ent->port[0].scr_addr = base + 0x400;
probe_ent->port[1].scr_addr = base + 0x500;
 
-   probe_ent->_port_flags[0] = ATA_FLAG_SATA;
-   probe_ent->_port_flags[1] = ATA_FLAG_SATA;
-   
/* notice 4-port boards */
switch (board_idx) {
case board_40518:
@@ -974,6 +971,8 @@ static int pdc_ata_init_one (struct pci_
probe_ent->port[2].scr_addr = base + 0x600;
probe_ent->port[3].scr_addr = base + 0x700;

+   probe_ent->_port_flags[0] = ATA_FLAG_SATA;
+   probe_ent->_port_flags[1] = ATA_FLAG_SATA;
probe_ent->_port_flags[2] = ATA_FLAG_SATA;
probe_ent->_port_flags[3] = ATA_FLAG_SATA;
break;
@@ -995,6 +994,8 @@ static int pdc_ata_init_one (struct pci_
}
else
probe_ent->n_ports = 2;
+   probe_ent->_port_flags[0] = ATA_FLAG_SATA;
+   probe_ent->_port_flags[1] = ATA_FLAG_SATA;
break;
case board_20619:
probe_ent->n_ports = 4;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH libata #promise-sata-pata] sata_promise: unbreak 20619

[Mikael Pettersson]

The PATA support patch for sata_promise appears, from
code inspection, to break the PATA-only 20619 chip.

The patch removes the SATA flag from the TX2plus SATA+PATA
boards' common flags, with the intention of adding it back
via the _port_flags[] entries for those boards' SATA ports.

However, it unconditionally marks ports 0 and 1 as SATA
for all boards. This causes the 20619 (TX4000) to announce
its first two PATA ports as SATA | ATA_FLAG_SLAVE_POSS.

I don't have a TX4000 so I don't know what the actual
consequences of this bug are, but surely this isn't Ok.

Fixed by moving the port 0 and 1 settings as SATA into
the TX4 and TX2plus specific initialisation code.

Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]

--- linux-2.6.20-rc3/drivers/ata/sata_promise.c.~1~ 2007-01-06 
17:05:29.0 +0100
+++ linux-2.6.20-rc3/drivers/ata/sata_promise.c 2007-01-06 17:10:56.0 
+0100
@@ -957,9 +957,6 @@ static int pdc_ata_init_one (struct pci_
probe_ent-port[0].scr_addr = base + 0x400;
probe_ent-port[1].scr_addr = base + 0x500;
 
-   probe_ent-_port_flags[0] = ATA_FLAG_SATA;
-   probe_ent-_port_flags[1] = ATA_FLAG_SATA;
-   
/* notice 4-port boards */
switch (board_idx) {
case board_40518:
@@ -974,6 +971,8 @@ static int pdc_ata_init_one (struct pci_
probe_ent-port[2].scr_addr = base + 0x600;
probe_ent-port[3].scr_addr = base + 0x700;

+   probe_ent-_port_flags[0] = ATA_FLAG_SATA;
+   probe_ent-_port_flags[1] = ATA_FLAG_SATA;
probe_ent-_port_flags[2] = ATA_FLAG_SATA;
probe_ent-_port_flags[3] = ATA_FLAG_SATA;
break;
@@ -995,6 +994,8 @@ static int pdc_ata_init_one (struct pci_
}
else
probe_ent-n_ports = 2;
+   probe_ent-_port_flags[0] = ATA_FLAG_SATA;
+   probe_ent-_port_flags[1] = ATA_FLAG_SATA;
break;
case board_20619:
probe_ent-n_ports = 4;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH libata #promise-sata-pata] sata_promise: 2037x PATAPI support

[Mikael Pettersson]

This patch adds ATAPI support for the PATA port on Promise 2037x chips.
It depends on the common sata_promise ATAPI support patch.

First-generation chips don't support ATAPI on their SATA ports, so
the patch removes ATA_FLAG_NO_ATAPI from the 2037x common host flags,
and adds it back via the _port_flags[] entries for the SATA ports.

Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]

--- linux-2.6.20-rc3/drivers/ata/sata_promise.c.~1~ 2007-01-06 
17:10:56.0 +0100
+++ linux-2.6.20-rc3/drivers/ata/sata_promise.c 2007-01-06 17:14:23.0 
+0100
@@ -187,7 +187,7 @@ static const struct ata_port_info pdc_po
/* board_2037x */
{
.sht= pdc_ata_sht,
-   .flags  = PDC_COMMON_FLAGS | ATA_FLAG_NO_ATAPI /* | 
ATA_FLAG_SATA */,
+   .flags  = PDC_COMMON_FLAGS /* | ATA_FLAG_NO_ATAPI | 
ATA_FLAG_SATA */,
.pio_mask   = 0x1f, /* pio0-4 */
.mwdma_mask = 0x07, /* mwdma0-2 */
.udma_mask  = 0x7f, /* udma0-6 ; FIXME */
@@ -996,6 +996,10 @@ static int pdc_ata_init_one (struct pci_
probe_ent-n_ports = 2;
probe_ent-_port_flags[0] = ATA_FLAG_SATA;
probe_ent-_port_flags[1] = ATA_FLAG_SATA;
+   if (board_idx == board_2037x) {
+   probe_ent-_port_flags[0] |= ATA_FLAG_NO_ATAPI;
+   probe_ent-_port_flags[1] |= ATA_FLAG_NO_ATAPI;
+   }
break;
case board_20619:
probe_ent-n_ports = 4;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: libata and sata?

[John Richard Moser]

Alan wrote:
>> I no longer have two kernels to test through; I can't tell if the speed
>> is back or not.  Nothing in dmesg tells me if SATA is using DMA or
>> 32-bit IO support though, so I don't know... lack of knowledge over here
>> is killing me for troubleshooting this on my own.
> 
> The dmesg message shows the mode selected. It should be the highest speed
> but in one or two cases it selects UDMA33 only. I've fixed one of those
> caused by us relying on a bit not defined in older controllers. We've
> still got a case in the newer chips where BIOS setup doesn't set the
> flags properly. Old IDE has a hackish workaround for that and I'll
> probably end up porting it over.
> 
> 

It seems the highest speed here is UDMA/133.  That should be right...

I've let this go for now; except someone just brought up that copying
from one SATA drive to another slows Ubuntu to a crawl (which is what
I'm using, hence my dmesg should be relevant).  On my end I'm not
noticing; VLC used to hang the system horribly while trying to read like
20M videos (hard disk light on the whole time), now it behaves.


[   25.411977] sata_via :00:0f.0: version 2.0
[   25.411992] ACPI: PCI Interrupt :00:0f.0[B] -> Link [ALKA] -> GSI
20 (level, low) -> IRQ 18
[   25.412004] sata_via :00:0f.0: routed to hard irq line 11
[   25.412057] ata3: SATA max UDMA/133 cmd 0x9400 ctl 0x9802 bmdma
0xA400 irq 18
[   25.412363] ata4: SATA max UDMA/133 cmd 0x9C00 ctl 0xA002 bmdma
0xA408 irq 18
[   25.412380] scsi2 : sata_via
[   25.415286] 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[   25.598514] ieee1394: Host added: ID:BUS[0-00:1023]
GUID[]
[   25.613389] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   25.738290] usb 2-1: device not accepting address 2, error -71
[   25.764951] ata3.00: ATA-7, max UDMA/133, 240121728 sectors: LBA
[   25.764954] ata3.00: ata3: dev 0 multi count 16
[   25.765730] ata3.00: configured for UDMA/133
[   25.765741] scsi3 : sata_via
[   25.967113] ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 300)
[   25.977712] ATA: abnormal status 0x7F on port 0x9C07
[   25.977852] scsi 2:0:0:0: Direct-Access ATA  Maxtor 6Y120M0
 YAR5 PQ: 0 ANSI: 5

-- 
We will enslave their women, eat their children and rape their
cattle!
  -- Bosc, Evil alien overlord from the fifth dimension
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: libata and sata?

[John Richard Moser]

Alan wrote:
 I no longer have two kernels to test through; I can't tell if the speed
 is back or not.  Nothing in dmesg tells me if SATA is using DMA or
 32-bit IO support though, so I don't know... lack of knowledge over here
 is killing me for troubleshooting this on my own.
 
 The dmesg message shows the mode selected. It should be the highest speed
 but in one or two cases it selects UDMA33 only. I've fixed one of those
 caused by us relying on a bit not defined in older controllers. We've
 still got a case in the newer chips where BIOS setup doesn't set the
 flags properly. Old IDE has a hackish workaround for that and I'll
 probably end up porting it over.
 
 

It seems the highest speed here is UDMA/133.  That should be right...

I've let this go for now; except someone just brought up that copying
from one SATA drive to another slows Ubuntu to a crawl (which is what
I'm using, hence my dmesg should be relevant).  On my end I'm not
noticing; VLC used to hang the system horribly while trying to read like
20M videos (hard disk light on the whole time), now it behaves.


[   25.411977] sata_via :00:0f.0: version 2.0
[   25.411992] ACPI: PCI Interrupt :00:0f.0[B] - Link [ALKA] - GSI
20 (level, low) - IRQ 18
[   25.412004] sata_via :00:0f.0: routed to hard irq line 11
[   25.412057] ata3: SATA max UDMA/133 cmd 0x9400 ctl 0x9802 bmdma
0xA400 irq 18
[   25.412363] ata4: SATA max UDMA/133 cmd 0x9C00 ctl 0xA002 bmdma
0xA408 irq 18
[   25.412380] scsi2 : sata_via
[   25.415286] 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[   25.598514] ieee1394: Host added: ID:BUS[0-00:1023]
GUID[]
[   25.613389] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   25.738290] usb 2-1: device not accepting address 2, error -71
[   25.764951] ata3.00: ATA-7, max UDMA/133, 240121728 sectors: LBA
[   25.764954] ata3.00: ata3: dev 0 multi count 16
[   25.765730] ata3.00: configured for UDMA/133
[   25.765741] scsi3 : sata_via
[   25.967113] ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 300)
[   25.977712] ATA: abnormal status 0x7F on port 0x9C07
[   25.977852] scsi 2:0:0:0: Direct-Access ATA  Maxtor 6Y120M0
 YAR5 PQ: 0 ANSI: 5

-- 
We will enslave their women, eat their children and rape their
cattle!
  -- Bosc, Evil alien overlord from the fifth dimension
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: libata and sata?

[Stephen Clark]

John Richard Moser wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A while back my distro moved to libata for sata_via.  I was since
confused; my disk seemed a lot slower, and it looked like DMA was off.
I'm not sure how SATA works; is it even possible to enable/disable
32-bit IO and DMA?  Or are those just on?

sata_via   11524  4
libata112660  3 ata_generic,pata_via,sata_via

~$ sudo hdparm -d1 -c1 -u1 /dev/sda

/dev/sda:
setting 32-bit IO_support flag to 1
HDIO_SET_32BIT failed: Invalid argument
setting unmaskirq to 1 (on)
HDIO_SET_UNMASKINTR failed: Inappropriate ioctl for device
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for device
IO_support   =  0 (default 16-bit)

I no longer have two kernels to test through; I can't tell if the speed
is back or not.  Nothing in dmesg tells me if SATA is using DMA or
32-bit IO support though, so I don't know... lack of knowledge over here
is killing me for troubleshooting this on my own.

 




Hi John,

This happened to me with my ICH7 intel chipset which supports sata and ata - my 
drive was an ide and the performance was like 1.2mb/sec. Someone said boot with 
combined_mode=libata and it fixed the problem.
Now I get 44mb/sec.

HTH,
Steve
--

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)


"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: libata and sata?

[Alan]

> I no longer have two kernels to test through; I can't tell if the speed
> is back or not.  Nothing in dmesg tells me if SATA is using DMA or
> 32-bit IO support though, so I don't know... lack of knowledge over here
> is killing me for troubleshooting this on my own.

The dmesg message shows the mode selected. It should be the highest speed
but in one or two cases it selects UDMA33 only. I've fixed one of those
caused by us relying on a bit not defined in older controllers. We've
still got a case in the newer chips where BIOS setup doesn't set the
flags properly. Old IDE has a hackish workaround for that and I'll
probably end up porting it over.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

libata and sata?

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A while back my distro moved to libata for sata_via.  I was since
confused; my disk seemed a lot slower, and it looked like DMA was off.
I'm not sure how SATA works; is it even possible to enable/disable
32-bit IO and DMA?  Or are those just on?

sata_via   11524  4
libata112660  3 ata_generic,pata_via,sata_via

~$ sudo hdparm -d1 -c1 -u1 /dev/sda

/dev/sda:
 setting 32-bit IO_support flag to 1
 HDIO_SET_32BIT failed: Invalid argument
 setting unmaskirq to 1 (on)
 HDIO_SET_UNMASKINTR failed: Inappropriate ioctl for device
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Inappropriate ioctl for device
 IO_support   =  0 (default 16-bit)

I no longer have two kernels to test through; I can't tell if the speed
is back or not.  Nothing in dmesg tells me if SATA is using DMA or
32-bit IO support though, so I don't know... lack of knowledge over here
is killing me for troubleshooting this on my own.

- --
We will enslave their women, eat their children and rape their
cattle!
  -- Bosc, Evil alien overlord from the fifth dimension
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRX7YeAs1xW0HCTEFAQIZ5w/9GCEP1LMCqTAa366wSg6WcwomBL1fsSik
xrZJ2ZGAzKyAkKA6DLDKjJ12fG1Pueri5qj7Cx8iRgPOFTnXg3+zNdC26uWJ2cSR
hlXI/GkjMAaB2yXidPHkfpsh1fROQoiWPy+wQ8ppXVfW/xwgFUPFst5OWoU/HSbn
8Y72tUDgsj5QjWtn6XendpND8kq59Aqw4A+WG8ThW5FyRNXa5zyd8IW6bSmLGKAa
+/PCp937aK6us8LAqlkjqHaqN+JavS+lTxFXb0ZhStKteoGo0z79IvuwnRbNtJR5
XwDBzWhic1IDTV5NOyxDQ0fBoVTllIKeY55v84lzbRrYJOIiKaze1dyDPPT/nAlo
2nS1rXP+X+3RxqUrD5kXorGSHdTqVQoBINfnntrKTkNqAKUNQ4YxlBmwzsoYsIHO
/h0hCEFoIp1wFokKEP6/Dz6TM63G3m+tadPLpSbQ2u4yEg8N8vSZeix61EieNoAU
nR8YZW52BK6rGc0/IrJRE2fVd90gxSjvN2T3o3Du+cjPHdYQhlvV3GFcIsFVIp3Y
GkXO9T29HwgZO/KuA02vhjqgP2WvC5qeV4ansbukGBBi8jaanm6qf7PcsN0/1bNr
bWqYCfzvIuIg/FPiK7XzkmVJ6cipBbCHEGqBQiQn6D0lpA715Me+T8uTH3HPUX4l
oclOnqemO+w=
=TU0m
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

libata and sata?

[John Richard Moser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A while back my distro moved to libata for sata_via.  I was since
confused; my disk seemed a lot slower, and it looked like DMA was off.
I'm not sure how SATA works; is it even possible to enable/disable
32-bit IO and DMA?  Or are those just on?

sata_via   11524  4
libata112660  3 ata_generic,pata_via,sata_via

~$ sudo hdparm -d1 -c1 -u1 /dev/sda

/dev/sda:
 setting 32-bit IO_support flag to 1
 HDIO_SET_32BIT failed: Invalid argument
 setting unmaskirq to 1 (on)
 HDIO_SET_UNMASKINTR failed: Inappropriate ioctl for device
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Inappropriate ioctl for device
 IO_support   =  0 (default 16-bit)

I no longer have two kernels to test through; I can't tell if the speed
is back or not.  Nothing in dmesg tells me if SATA is using DMA or
32-bit IO support though, so I don't know... lack of knowledge over here
is killing me for troubleshooting this on my own.

- --
We will enslave their women, eat their children and rape their
cattle!
  -- Bosc, Evil alien overlord from the fifth dimension
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRX7YeAs1xW0HCTEFAQIZ5w/9GCEP1LMCqTAa366wSg6WcwomBL1fsSik
xrZJ2ZGAzKyAkKA6DLDKjJ12fG1Pueri5qj7Cx8iRgPOFTnXg3+zNdC26uWJ2cSR
hlXI/GkjMAaB2yXidPHkfpsh1fROQoiWPy+wQ8ppXVfW/xwgFUPFst5OWoU/HSbn
8Y72tUDgsj5QjWtn6XendpND8kq59Aqw4A+WG8ThW5FyRNXa5zyd8IW6bSmLGKAa
+/PCp937aK6us8LAqlkjqHaqN+JavS+lTxFXb0ZhStKteoGo0z79IvuwnRbNtJR5
XwDBzWhic1IDTV5NOyxDQ0fBoVTllIKeY55v84lzbRrYJOIiKaze1dyDPPT/nAlo
2nS1rXP+X+3RxqUrD5kXorGSHdTqVQoBINfnntrKTkNqAKUNQ4YxlBmwzsoYsIHO
/h0hCEFoIp1wFokKEP6/Dz6TM63G3m+tadPLpSbQ2u4yEg8N8vSZeix61EieNoAU
nR8YZW52BK6rGc0/IrJRE2fVd90gxSjvN2T3o3Du+cjPHdYQhlvV3GFcIsFVIp3Y
GkXO9T29HwgZO/KuA02vhjqgP2WvC5qeV4ansbukGBBi8jaanm6qf7PcsN0/1bNr
bWqYCfzvIuIg/FPiK7XzkmVJ6cipBbCHEGqBQiQn6D0lpA715Me+T8uTH3HPUX4l
oclOnqemO+w=
=TU0m
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: libata and sata?

[Alan]

 I no longer have two kernels to test through; I can't tell if the speed
 is back or not.  Nothing in dmesg tells me if SATA is using DMA or
 32-bit IO support though, so I don't know... lack of knowledge over here
 is killing me for troubleshooting this on my own.

The dmesg message shows the mode selected. It should be the highest speed
but in one or two cases it selects UDMA33 only. I've fixed one of those
caused by us relying on a bit not defined in older controllers. We've
still got a case in the newer chips where BIOS setup doesn't set the
flags properly. Old IDE has a hackish workaround for that and I'll
probably end up porting it over.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: libata and sata?

[Stephen Clark]

John Richard Moser wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A while back my distro moved to libata for sata_via.  I was since
confused; my disk seemed a lot slower, and it looked like DMA was off.
I'm not sure how SATA works; is it even possible to enable/disable
32-bit IO and DMA?  Or are those just on?

sata_via   11524  4
libata112660  3 ata_generic,pata_via,sata_via

~$ sudo hdparm -d1 -c1 -u1 /dev/sda

/dev/sda:
setting 32-bit IO_support flag to 1
HDIO_SET_32BIT failed: Invalid argument
setting unmaskirq to 1 (on)
HDIO_SET_UNMASKINTR failed: Inappropriate ioctl for device
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for device
IO_support   =  0 (default 16-bit)

I no longer have two kernels to test through; I can't tell if the speed
is back or not.  Nothing in dmesg tells me if SATA is using DMA or
32-bit IO support though, so I don't know... lack of knowledge over here
is killing me for troubleshooting this on my own.

 


snip

Hi John,

This happened to me with my ICH7 intel chipset which supports sata and ata - my 
drive was an ide and the performance was like 1.2mb/sec. Someone said boot with 
combined_mode=libata and it fixed the problem.
Now I get 44mb/sec.

HTH,
Steve
--

They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety.  (Ben Franklin)


The course of history shows that as a government grows, liberty 
decreases.  (Thomas Jefferson)




-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Bogdan Costescu]

On Wed, 7 Sep 2005, Brett Russ wrote:

> The one I fixed concerned the 5xxx chips not supporting the master
> reset functionality.

Please note that in my case the failure to do master reset is followed
by the module still being loaded and oops-ing at rmmod, which means
that the error path in the probe routine is wrong and some resources
remain allocated.

>   IRQ routing conflict for :02:08.0, have irq 9, want irq 5

In the mean time, I have discovered that booting the SMP kernel (the
mainboard is UP, but both it and the CPU support HyperThreading) takes
care of this: the controller gets some high numbered IRQ, like 209 or
so, not shared. This is not exactly related to this driver, but might
help others that want to use the on-board controller on this MB.

> The chip does take an "error" interrupt upon drive connection but
> that's not fatal.

In my situation this happened with the drive already connected, so is
it possible that such interrupt is (also) generated when probing for
drives ?

Here is some more output, this time with debugging on (cut-and-pasted 
from serial console, maybe with some extra newlines):

- without any drive connected, I also get problems now:

mv_init_one: ENTER for PCI Bus:Slot.Func=2:8.0
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x0018/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_host_init: HC0: HC config=0x11dcf013 HC IRQ cause=0x
mv_host_init: HC MAIN IRQ cause/mask=0x0001/0x0007 PCI int 
cause/mask=0x/6mv_init_one: PCI config space:
mv_init_one: 504111ab 02b7 0103 2008
mv_init_one: f504   
mv_init_one:    81241043
mv_init_one:  0040  0109
mv_host_intr: ENTER, hc0 relevant=0x0001 HC IRQ cause=0x
mv_phy_reset: ENTER, port 0, mmio 0xf8a22000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_err_intr: port 0 error; EDMA err cause: 0x0018 SERR: 0x
mv_phy_reset: ENTER, port 0, mmio 0xf8a22000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
Badness in __sata_phy_reset at drivers/scsi/libata-core.c:1413
 [] __sata_phy_reset+0x75/0x12e [libata]
 [] mv_phy_reset+0xe8/0x175 [sata_mv]
 [] mv_host_intr+0xf1/0x187 [sata_mv]
 [] mv_interrupt+0x7f/0xa7 [sata_mv]
 [] handle_IRQ_event+0x25/0x4f
 [] do_IRQ+0x11c/0x1ae
 ===
 [] common_interrupt+0x18/0x20
bad: scheduling while atomic!
 [] schedule+0x2d/0x87a
 [] scheduler_tick+0x3ce/0x3e5
 [] profile_hook+0x1b/0x26
 [] __mod_timer+0x101/0x10b
 [] schedule_timeout+0xd3/0xee
 [] process_timeout+0x0/0x5
 [] mv_scr_read+0xf/0x54 [sata_mv]
 [] msleep+0x4f/0x55
 [] __sata_phy_reset+0xa8/0x12e [libata]
 [] mv_phy_reset+0xe8/0x175 [sata_mv]
 [] mv_host_intr+0xf1/0x187 [sata_mv]
 [] mv_interrupt+0x7f/0xa7 [sata_mv]
 [] handle_IRQ_event+0x25/0x4f
 [] do_IRQ+0x11c/0x1ae
 ===
 [] common_interrupt+0x18/0x20

which kills the network, the system is still responsive to keyboard -
but doesn't want to reboot, needs the button push. This however seems 
to be random, as I can also get a successful start:

mv_init_one: ENTER for PCI Bus:Slot.Func=2:8.0
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_host_init: HC0: HC config=0x11dcf013 HC IRQ cause=0x
mv_host_init: HC MAIN IRQ cause/mask=0x/0x0007 PCI int 
cause/mask=0x/6mv_init_one: PCI config space:
mv_init_one: 504111ab 02b7 0103 2008
mv_init_one: f504   
mv_init_one:    81241043
mv_init_one:  0040  0109
mv_phy_reset: ENTER, port 0, mmio 0xf8a22000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_phy_reset: Port disabled pre-sig.  Exiting.
mv_phy_reset: ENTER, port 1, mmio 0xf8a24000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_phy_reset: Port disabled pre-sig.  Exiting.
mv_phy_reset: ENTER, port 2, mmio 0xf8a26000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_phy_reset: Port disabled pre-sig.  Exiting.
mv_phy_reset: ENTER, port 3, mmio 0xf8a28000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_phy_reset: Port disabled pre-sig.  Exiting.



- with a drive connected to what on the MB is labeled as the first
channel for this controller (which IIRC is also recognized as the
first channel by the mv_sata driver):

mv_init_one: ENTER for PCI Bus:Slot.Func=2:8.0
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ 

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

Jeff Garzik wrote:

applied



There are some issues with this.  One of which I fixed and the other is 
a bit confusing.  The one I fixed concerned the 5xxx chips not 
supporting the master reset functionality.  The other problem has been 
reported by 2 people so far.  I have a stack trace from each of them:


Stack 1: (from http://article.gmane.org/gmane.linux.ide/5280)


 PCI: Found IRQ 5 for device :02:08.0
 PCI: Sharing IRQ 5 with :00:1d.0
 IRQ routing conflict for :02:08.0, have irq 9, want irq 5
 ata1: SATA max PIO4 cmd 0x0 ctl 0xF8A22120 bmdma 0x0 irq 9
 ata2: SATA max PIO4 cmd 0x0 ctl 0xF8A24120 bmdma 0x0 irq 9
 ata3: SATA max PIO4 cmd 0x0 ctl 0xF8A26120 bmdma 0x0 irq 9
 ata4: SATA max PIO4 cmd 0x0 ctl 0xF8A28120 bmdma 0x0 irq 9
 Badness in __sata_phy_reset at drivers/scsi/libata-core.c:1413
  [] __sata_phy_reset+0x75/0x12e [libata]
  [] mv_phy_reset+0xbf/0x11e [sata_mv]
  [] end_that_request_last+0x6c/0x7e
  [] mv_host_intr+0xd6/0x142 [sata_mv]
  [] mv_interrupt+0xd5/0x145 [sata_mv]
  [] handle_IRQ_event+0x25/0x4f
  [] do_IRQ+0x18a/0x2bf
  ===
  [] common_interrupt+0x18/0x20
  [] mv_phy_reset+0xa8/0x11e [sata_mv]
  [] setup_irq+0x179/0x181
  [] mv_interrupt+0x0/0x145 [sata_mv]
  [] ata_bus_probe+0xe/0x7b [libata]
  [] ata_device_add+0x186/0x202 [libata]
  [] mv_init_one+0x197/0x1d5 [sata_mv]
  [] pci_device_probe_static+0x2a/0x3d
  [] __pci_device_probe+0x1b/0x2c
  [] pci_device_probe+0x1b/0x2d
  [] bus_match+0x27/0x45
  [] driver_attach+0x37/0x66
  [] bus_add_driver+0x77/0x97
  [] driver_register+0x51/0x58
  [] pci_register_driver+0x85/0xa1
  [] mv_init+0xa/0x15 [sata_mv]
  [] sys_init_module+0x1f1/0x2d9
  [] syscall_call+0x7/0xb
 bad: scheduling while atomic!
  [] schedule+0x2d/0x552
  [] handle_IRQ_event+0x25/0x4f
  [] schedule_timeout+0xf1/0x10c
  [] process_timeout+0x0/0x5
  [] mv_scr_read+0xf/0x54 [sata_mv]
  [] msleep+0x4e/0x54
  [] __sata_phy_reset+0xa8/0x12e [libata]
  [] mv_phy_reset+0xbf/0x11e [sata_mv]
  [] end_that_request_last+0x6c/0x7e
  [] mv_host_intr+0xd6/0x142 [sata_mv]
  [] mv_interrupt+0xd5/0x145 [sata_mv]
  [] handle_IRQ_event+0x25/0x4f
  [] do_IRQ+0x18a/0x2bf
  ===
  [] common_interrupt+0x18/0x20
  [] mv_phy_reset+0xa8/0x11e [sata_mv]
  [] setup_irq+0x179/0x181
  [] mv_interrupt+0x0/0x145 [sata_mv]
  [] ata_bus_probe+0xe/0x7b [libata]
  [] ata_device_add+0x186/0x202 [libata]
  [] mv_init_one+0x197/0x1d5 [sata_mv]
  [] pci_device_probe_static+0x2a/0x3d
  [] __pci_device_probe+0x1b/0x2c
  [] pci_device_probe+0x1b/0x2d
  [] bus_match+0x27/0x45
  [] driver_attach+0x37/0x66
  [] bus_add_driver+0x77/0x97
  [] driver_register+0x51/0x58
  [] pci_register_driver+0x85/0xa1
  [] mv_init+0xa/0x15 [sata_mv]
  [] sys_init_module+0x1f1/0x2d9
  [] syscall_call+0x7/0xb



Stack 2: (from off list email)


scheduling while atomic: klogd/0x0001/1572
 [] schedule+0xab4/0xbf0
 [] scheduler_tick+0x15f/0x380
 [] lock_timer_base+0x20/0x50
 [] __mod_timer+0xa8/0xd0
 [] schedule_timeout+0x4e/0xc0
 [] process_timeout+0x0/0x10
 [] msleep+0x30/0x40
 [] __sata_phy_reset+0x4a/0x120 [libata]
 [] delay_pmtmr+0x12/0x20
 [] mv_phy_reset+0x7a/0x140 [sata_mv]
 [] ide_end_request+0x92/0xb0
 [] mv_host_intr+0xce/0x120 [sata_mv]
 [] mv_interrupt+0xa7/0xf0 [sata_mv]
 [] handle_IRQ_event+0x33/0x70
 [] __do_IRQ+0xd9/0x150
 [] do_IRQ+0x57/0xa0
 ===
 [] common_interrupt+0x1a/0x20
 [] __group_send_sig_info+0x2b/0xd0
 [] do_syslog+0xe8/0x3e0
 [] apic_timer_interrupt+0x1c/0x24
 [] autoremove_wake_function+0x0/0x50
 [] autoremove_wake_function+0x0/0x50
 [] kmsg_read+0x0/0x50
 [] vfs_read+0xb8/0x170
 [] sys_read+0x41/0x70
 [] sysenter_past_esp+0x54/0x75



So it looks like mv_phy_reset() is getting called from interrupt level, 
and it calls __sata_phy_reset() which sleeps.


I only call mv_phy_reset() as part of fatal error interrupt cleanup. 
The chip does take an "error" interrupt upon drive connection but that's 
not fatal.  Either way, mv_phy_reset() is called from mv_err_intr() 
which doesn't appear in either of the stack dumps above.


Possible solutions:
-change __sata_phy_reset() to do a mdelay rather than msleep?
-do the phy_reset part of error recovery after returning from interrupt 
handler?


Thoughts?
BR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

Jeff Garzik wrote:

applied



There are some issues with this.  One of which I fixed and the other is 
a bit confusing.  The one I fixed concerned the 5xxx chips not 
supporting the master reset functionality.  The other problem has been 
reported by 2 people so far.  I have a stack trace from each of them:


Stack 1: (from http://article.gmane.org/gmane.linux.ide/5280)


 PCI: Found IRQ 5 for device :02:08.0
 PCI: Sharing IRQ 5 with :00:1d.0
 IRQ routing conflict for :02:08.0, have irq 9, want irq 5
 ata1: SATA max PIO4 cmd 0x0 ctl 0xF8A22120 bmdma 0x0 irq 9
 ata2: SATA max PIO4 cmd 0x0 ctl 0xF8A24120 bmdma 0x0 irq 9
 ata3: SATA max PIO4 cmd 0x0 ctl 0xF8A26120 bmdma 0x0 irq 9
 ata4: SATA max PIO4 cmd 0x0 ctl 0xF8A28120 bmdma 0x0 irq 9
 Badness in __sata_phy_reset at drivers/scsi/libata-core.c:1413
  [f88e8f0c] __sata_phy_reset+0x75/0x12e [libata]
  [f883f62f] mv_phy_reset+0xbf/0x11e [sata_mv]
  [c0250f16] end_that_request_last+0x6c/0x7e
  [f883f3bf] mv_host_intr+0xd6/0x142 [sata_mv]
  [f883f500] mv_interrupt+0xd5/0x145 [sata_mv]
  [c0107e2b] handle_IRQ_event+0x25/0x4f
  [c01087d3] do_IRQ+0x18a/0x2bf
  ===
  [c030fb7c] common_interrupt+0x18/0x20
  [f883f618] mv_phy_reset+0xa8/0x11e [sata_mv]
  [c01091d8] setup_irq+0x179/0x181
  [f883f42b] mv_interrupt+0x0/0x145 [sata_mv]
  [f88e8e25] ata_bus_probe+0xe/0x7b [libata]
  [f88eb34d] ata_device_add+0x186/0x202 [libata]
  [f883f97a] mv_init_one+0x197/0x1d5 [sata_mv]
  [c01ec15d] pci_device_probe_static+0x2a/0x3d
  [c01ec18b] __pci_device_probe+0x1b/0x2c
  [c01ec1b7] pci_device_probe+0x1b/0x2d
  [c024a33b] bus_match+0x27/0x45
  [c024a404] driver_attach+0x37/0x66
  [c024a7b9] bus_add_driver+0x77/0x97
  [c024abd4] driver_register+0x51/0x58
  [c01ec375] pci_register_driver+0x85/0xa1
  [f881a00a] mv_init+0xa/0x15 [sata_mv]
  [c013d5a3] sys_init_module+0x1f1/0x2d9
  [c030fa37] syscall_call+0x7/0xb
 bad: scheduling while atomic!
  [c030d515] schedule+0x2d/0x552
  [c0107e2b] handle_IRQ_event+0x25/0x4f
  [c030e40e] schedule_timeout+0xf1/0x10c
  [c012ad7e] process_timeout+0x0/0x5
  [f883f082] mv_scr_read+0xf/0x54 [sata_mv]
  [c012b498] msleep+0x4e/0x54
  [f88e8f3f] __sata_phy_reset+0xa8/0x12e [libata]
  [f883f62f] mv_phy_reset+0xbf/0x11e [sata_mv]
  [c0250f16] end_that_request_last+0x6c/0x7e
  [f883f3bf] mv_host_intr+0xd6/0x142 [sata_mv]
  [f883f500] mv_interrupt+0xd5/0x145 [sata_mv]
  [c0107e2b] handle_IRQ_event+0x25/0x4f
  [c01087d3] do_IRQ+0x18a/0x2bf
  ===
  [c030fb7c] common_interrupt+0x18/0x20
  [f883f618] mv_phy_reset+0xa8/0x11e [sata_mv]
  [c01091d8] setup_irq+0x179/0x181
  [f883f42b] mv_interrupt+0x0/0x145 [sata_mv]
  [f88e8e25] ata_bus_probe+0xe/0x7b [libata]
  [f88eb34d] ata_device_add+0x186/0x202 [libata]
  [f883f97a] mv_init_one+0x197/0x1d5 [sata_mv]
  [c01ec15d] pci_device_probe_static+0x2a/0x3d
  [c01ec18b] __pci_device_probe+0x1b/0x2c
  [c01ec1b7] pci_device_probe+0x1b/0x2d
  [c024a33b] bus_match+0x27/0x45
  [c024a404] driver_attach+0x37/0x66
  [c024a7b9] bus_add_driver+0x77/0x97
  [c024abd4] driver_register+0x51/0x58
  [c01ec375] pci_register_driver+0x85/0xa1
  [f881a00a] mv_init+0xa/0x15 [sata_mv]
  [c013d5a3] sys_init_module+0x1f1/0x2d9
  [c030fa37] syscall_call+0x7/0xb



Stack 2: (from off list email)


scheduling while atomic: klogd/0x0001/1572
 [c0343524] schedule+0xab4/0xbf0
 [c01200bf] scheduler_tick+0x15f/0x380
 [c012dbe0] lock_timer_base+0x20/0x50
 [c012dcb8] __mod_timer+0xa8/0xd0
 [c0343eee] schedule_timeout+0x4e/0xc0
 [c012e790] process_timeout+0x0/0x10
 [c012ebb0] msleep+0x30/0x40
 [f89d914a] __sata_phy_reset+0x4a/0x120 [libata]
 [c0114b72] delay_pmtmr+0x12/0x20
 [f899051a] mv_phy_reset+0x7a/0x140 [sata_mv]
 [c02857f2] ide_end_request+0x92/0xb0
 [f899035e] mv_host_intr+0xce/0x120 [sata_mv]
 [f8990457] mv_interrupt+0xa7/0xf0 [sata_mv]
 [c0149fe3] handle_IRQ_event+0x33/0x70
 [c014a0f9] __do_IRQ+0xd9/0x150
 [c0106847] do_IRQ+0x57/0xa0
 ===
 [c0104c4a] common_interrupt+0x1a/0x20
 [c013007b] __group_send_sig_info+0x2b/0xd0
 [c01247f8] do_syslog+0xe8/0x3e0
 [c0104cd8] apic_timer_interrupt+0x1c/0x24
 [c013a0c0] autoremove_wake_function+0x0/0x50
 [c013a0c0] autoremove_wake_function+0x0/0x50
 [c01a8090] kmsg_read+0x0/0x50
 [c016c368] vfs_read+0xb8/0x170
 [c016c701] sys_read+0x41/0x70
 [c01041bb] sysenter_past_esp+0x54/0x75



So it looks like mv_phy_reset() is getting called from interrupt level, 
and it calls __sata_phy_reset() which sleeps.


I only call mv_phy_reset() as part of fatal error interrupt cleanup. 
The chip does take an error interrupt upon drive connection but that's 
not fatal.  Either way, mv_phy_reset() is called from mv_err_intr() 
which doesn't appear in either of the stack dumps above.


Possible solutions:
-change __sata_phy_reset() to do a mdelay rather than msleep?
-do the phy_reset part of error recovery after returning from interrupt 
handler?


Thoughts?
BR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a 

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Bogdan Costescu]

On Wed, 7 Sep 2005, Brett Russ wrote:

 The one I fixed concerned the 5xxx chips not supporting the master
 reset functionality.

Please note that in my case the failure to do master reset is followed
by the module still being loaded and oops-ing at rmmod, which means
that the error path in the probe routine is wrong and some resources
remain allocated.

   IRQ routing conflict for :02:08.0, have irq 9, want irq 5

In the mean time, I have discovered that booting the SMP kernel (the
mainboard is UP, but both it and the CPU support HyperThreading) takes
care of this: the controller gets some high numbered IRQ, like 209 or
so, not shared. This is not exactly related to this driver, but might
help others that want to use the on-board controller on this MB.

 The chip does take an error interrupt upon drive connection but
 that's not fatal.

In my situation this happened with the drive already connected, so is
it possible that such interrupt is (also) generated when probing for
drives ?

Here is some more output, this time with debugging on (cut-and-pasted 
from serial console, maybe with some extra newlines):

- without any drive connected, I also get problems now:

mv_init_one: ENTER for PCI Bus:Slot.Func=2:8.0
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x0018/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_host_init: HC0: HC config=0x11dcf013 HC IRQ cause=0x
mv_host_init: HC MAIN IRQ cause/mask=0x0001/0x0007 PCI int 
cause/mask=0x/6mv_init_one: PCI config space:
mv_init_one: 504111ab 02b7 0103 2008
mv_init_one: f504   
mv_init_one:    81241043
mv_init_one:  0040  0109
mv_host_intr: ENTER, hc0 relevant=0x0001 HC IRQ cause=0x
mv_phy_reset: ENTER, port 0, mmio 0xf8a22000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_err_intr: port 0 error; EDMA err cause: 0x0018 SERR: 0x
mv_phy_reset: ENTER, port 0, mmio 0xf8a22000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
Badness in __sata_phy_reset at drivers/scsi/libata-core.c:1413
 [f8961dc8] __sata_phy_reset+0x75/0x12e [libata]
 [f887566e] mv_phy_reset+0xe8/0x175 [sata_mv]
 [f8875449] mv_host_intr+0xf1/0x187 [sata_mv]
 [f887555e] mv_interrupt+0x7f/0xa7 [sata_mv]
 [c010745e] handle_IRQ_event+0x25/0x4f
 [c01079be] do_IRQ+0x11c/0x1ae
 ===
 [c02d1c88] common_interrupt+0x18/0x20
bad: scheduling while atomic!
 [c02ced41] schedule+0x2d/0x87a
 [c011e53e] scheduler_tick+0x3ce/0x3e5
 [c0122bba] profile_hook+0x1b/0x26
 [c0129741] __mod_timer+0x101/0x10b
 [c02cfa90] schedule_timeout+0xd3/0xee
 [c0129feb] process_timeout+0x0/0x5
 [f8875082] mv_scr_read+0xf/0x54 [sata_mv]
 [c012a562] msleep+0x4f/0x55
 [f8961dfb] __sata_phy_reset+0xa8/0x12e [libata]
 [f887566e] mv_phy_reset+0xe8/0x175 [sata_mv]
 [f8875449] mv_host_intr+0xf1/0x187 [sata_mv]
 [f887555e] mv_interrupt+0x7f/0xa7 [sata_mv]
 [c010745e] handle_IRQ_event+0x25/0x4f
 [c01079be] do_IRQ+0x11c/0x1ae
 ===
 [c02d1c88] common_interrupt+0x18/0x20

which kills the network, the system is still responsive to keyboard -
but doesn't want to reboot, needs the button push. This however seems 
to be random, as I can also get a successful start:

mv_init_one: ENTER for PCI Bus:Slot.Func=2:8.0
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_port_init: EDMA cfg=0x011f EDMA IRQ err 
cause/mask=0x/0x1f7f
mv_host_init: HC0: HC config=0x11dcf013 HC IRQ cause=0x
mv_host_init: HC MAIN IRQ cause/mask=0x/0x0007 PCI int 
cause/mask=0x/6mv_init_one: PCI config space:
mv_init_one: 504111ab 02b7 0103 2008
mv_init_one: f504   
mv_init_one:    81241043
mv_init_one:  0040  0109
mv_phy_reset: ENTER, port 0, mmio 0xf8a22000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_phy_reset: Port disabled pre-sig.  Exiting.
mv_phy_reset: ENTER, port 1, mmio 0xf8a24000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_phy_reset: Port disabled pre-sig.  Exiting.
mv_phy_reset: ENTER, port 2, mmio 0xf8a26000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_phy_reset: Port disabled pre-sig.  Exiting.
mv_phy_reset: ENTER, port 3, mmio 0xf8a28000
mv_phy_reset: Done.  Now calling __sata_phy_reset()
mv_phy_reset: Port disabled pre-sig.  Exiting.



- with a drive connected to what on the MB is labeled as the first
channel for this controller (which IIRC is also recognized as the
first channel by the mv_sata driver):

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

applied

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

applied

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Tyler wrote:

Brett Russ wrote:


Some (non-functional) cleanup modifications since the version 0.10
driver I sent out 2005-08-30.  Also adding signed-off-by for Jeff's
upstream push.  This is my libata compatible low level driver for
the Marvell SATA family.  Currently it successfully runs in PIO mode
on a 6081 chip.  EDMA support is in the works and should be done
shortly.  Review, testing (especially on other flavors of Marvell),
comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ <[EMAIL PROTECTED]>

 


[snip..]

Please find attached patches that add the Adaptec 1420SA controller to 
the PCI ID list in the driver, and a small note in the kernel config 
option to state so.  This is untested as of currently, if anyone has a 
1420SA to try, that would be great..  The one I had access to is now 
gone to a remote location out of reach for testing.  I read in one post 
I found with google, that the 1420SA uses a 6541 chip instead of a 6041, 
but I am not able to verify this, and also don't know if it may still 
work as a 6041.  The card is still a Sata2, PCI-X card, with 4 ports, 
the same as the 6041 based cards.  This patch may or may not be 
useful..  The card comes with a manufacturer ID of 9005 according to a 
linux PCI-ID list, which is a secondary id of Adaptec's known as 
ADAPTEC2, and an actual PCI Id of 0241.


I would prefer to have it tested, before accepting this patch...

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Tyler]

Brett Russ wrote:


Some (non-functional) cleanup modifications since the version 0.10
driver I sent out 2005-08-30.  Also adding signed-off-by for Jeff's
upstream push.  This is my libata compatible low level driver for
the Marvell SATA family.  Currently it successfully runs in PIO mode
on a 6081 chip.  EDMA support is in the works and should be done
shortly.  Review, testing (especially on other flavors of Marvell),
comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ <[EMAIL PROTECTED]>

 


[snip..]

Please find attached patches that add the Adaptec 1420SA controller to 
the PCI ID list in the driver, and a small note in the kernel config 
option to state so.  This is untested as of currently, if anyone has a 
1420SA to try, that would be great..  The one I had access to is now 
gone to a remote location out of reach for testing.  I read in one post 
I found with google, that the 1420SA uses a 6541 chip instead of a 6041, 
but I am not able to verify this, and also don't know if it may still 
work as a 6041.  The card is still a Sata2, PCI-X card, with 4 ports, 
the same as the 6041 based cards.  This patch may or may not be 
useful..  The card comes with a manufacturer ID of 9005 according to a 
linux PCI-ID list, which is a secondary id of Adaptec's known as 
ADAPTEC2, and an actual PCI Id of 0241.


Signed-off-by: Tyler Guthrie <[EMAIL PROTECTED]>


--- linux-2.6.13.orig/drivers/scsi/Kconfig  2005-09-03 
06:42:20.0 -0700

+++ linux-2.6.13drivers/scsi/Kconfig2005-09-03 06:44:29.0 -0700
@@ -466,6 +466,8 @@
 This option enables support for the Marvell Serial ATA family.
 Currently supports 88SX[56]0[48][01] chips.

+ Also Including Adaptec 1420SA Card (using marvell chip pci-id 
0x0241).

+
 If unsure, say N.

config SCSI_SATA_NV

--- linux-2.6.13.orig/drivers/scsi/sata_mv.c2005-09-03 
06:40:07.0 -0700
+++ linux-2.6.13/drivers/scsi/sata_mv.c 2005-09-03 
06:39:47.0 -0700

@@ -286,6 +286,7 @@
   {PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6041), 0, 0, chip_604x},
   {PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6080), 0, 0, chip_608x},
   {PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6081), 0, 0, chip_608x},
+   {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x0241), 0, 0, chip_604x},
   {}  /* terminate list */
};



Tyler.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Tyler]

Brett Russ wrote:


Some (non-functional) cleanup modifications since the version 0.10
driver I sent out 2005-08-30.  Also adding signed-off-by for Jeff's
upstream push.  This is my libata compatible low level driver for
the Marvell SATA family.  Currently it successfully runs in PIO mode
on a 6081 chip.  EDMA support is in the works and should be done
shortly.  Review, testing (especially on other flavors of Marvell),
comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ [EMAIL PROTECTED]

 


[snip..]

Please find attached patches that add the Adaptec 1420SA controller to 
the PCI ID list in the driver, and a small note in the kernel config 
option to state so.  This is untested as of currently, if anyone has a 
1420SA to try, that would be great..  The one I had access to is now 
gone to a remote location out of reach for testing.  I read in one post 
I found with google, that the 1420SA uses a 6541 chip instead of a 6041, 
but I am not able to verify this, and also don't know if it may still 
work as a 6041.  The card is still a Sata2, PCI-X card, with 4 ports, 
the same as the 6041 based cards.  This patch may or may not be 
useful..  The card comes with a manufacturer ID of 9005 according to a 
linux PCI-ID list, which is a secondary id of Adaptec's known as 
ADAPTEC2, and an actual PCI Id of 0241.


Signed-off-by: Tyler Guthrie [EMAIL PROTECTED]


--- linux-2.6.13.orig/drivers/scsi/Kconfig  2005-09-03 
06:42:20.0 -0700

+++ linux-2.6.13drivers/scsi/Kconfig2005-09-03 06:44:29.0 -0700
@@ -466,6 +466,8 @@
 This option enables support for the Marvell Serial ATA family.
 Currently supports 88SX[56]0[48][01] chips.

+ Also Including Adaptec 1420SA Card (using marvell chip pci-id 
0x0241).

+
 If unsure, say N.

config SCSI_SATA_NV

--- linux-2.6.13.orig/drivers/scsi/sata_mv.c2005-09-03 
06:40:07.0 -0700
+++ linux-2.6.13/drivers/scsi/sata_mv.c 2005-09-03 
06:39:47.0 -0700

@@ -286,6 +286,7 @@
   {PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6041), 0, 0, chip_604x},
   {PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6080), 0, 0, chip_608x},
   {PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x6081), 0, 0, chip_608x},
+   {PCI_DEVICE(PCI_VENDOR_ID_ADAPTEC2, 0x0241), 0, 0, chip_604x},
   {}  /* terminate list */
};



Tyler.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Tyler wrote:

Brett Russ wrote:


Some (non-functional) cleanup modifications since the version 0.10
driver I sent out 2005-08-30.  Also adding signed-off-by for Jeff's
upstream push.  This is my libata compatible low level driver for
the Marvell SATA family.  Currently it successfully runs in PIO mode
on a 6081 chip.  EDMA support is in the works and should be done
shortly.  Review, testing (especially on other flavors of Marvell),
comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ [EMAIL PROTECTED]

 


[snip..]

Please find attached patches that add the Adaptec 1420SA controller to 
the PCI ID list in the driver, and a small note in the kernel config 
option to state so.  This is untested as of currently, if anyone has a 
1420SA to try, that would be great..  The one I had access to is now 
gone to a remote location out of reach for testing.  I read in one post 
I found with google, that the 1420SA uses a 6541 chip instead of a 6041, 
but I am not able to verify this, and also don't know if it may still 
work as a 6041.  The card is still a Sata2, PCI-X card, with 4 ports, 
the same as the 6041 based cards.  This patch may or may not be 
useful..  The card comes with a manufacturer ID of 9005 according to a 
linux PCI-ID list, which is a secondary id of Adaptec's known as 
ADAPTEC2, and an actual PCI Id of 0241.


I would prefer to have it tested, before accepting this patch...

Jeff



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Ray Lee]

On 9/1/05, Brett Russ <[EMAIL PROTECTED]> wrote:
> More (non-functional) style modifications since the version 0.11
> driver I sent out earlier today.  Removed most parens around return
> value, 

return is not a function call; you can safely remove them all.

> +   return ((void __iomem *)((unsigned long)port_mmio &
> +(unsigned long)SATAHC_MASK));
> +   return (base + MV_SATAHC0_REG_BASE + (hc * MV_SATAHC_REG_SZ));
> +   return (mv_hc_base(base, port >> MV_PORT_HC_SHIFT) +
> +   MV_SATAHC_ARBTR_REG_SZ +
> +   ((port & MV_PORT_MASK) * MV_PORT_REG_SZ));
> +   return ((flags & MV_FLAG_DUAL_HC) ? 2 : 1);
> +   return (EDMA_EN & readl(port_mmio + EDMA_CMD_OFS));
> +   return (ap->flags & MV_FLAG_BDMA);

Ray
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Bogdan Costescu]

On Thu, 1 Sep 2005, Brett Russ wrote:

> This is my libata compatible low level driver for the Marvell SATA
> family.

First of all, thanks! I've been waiting for such a driver to appear.

I somehow did not manage to get a working 2.6.13 kernel to boot and,
as I didn't have too much time to see why, I compiled this driver
against the RHEL 4 Update 2 beta kernel (2.6.9-16, but which is itself
compiled by me from source RPM, so Jeff won't be able to match
addresses with the real RHEL binary RPM), which has libata v1.11, as
opposed to v1.12 in kernel 2.6.13 - I had to add the pci_intx function
(from ahci.c in kernel 2.6.13) and to remove the last line
(.ordered_flush = 1) from mv_sht initialization. All tests are with
the UP kernel.

The hardware is an Asus PSCHSR-A board with Adaptec AIC8110, but which 
appears on the PCI bus (supposedly a PCI-X one) as:

02:08.0 SCSI storage controller: Marvell Technology Group Ltd. MV88SX5041 
4-port SATA I PCI-X Controller (rev 03)

The driver starts with:

ACPI: PCI interrupt :02:08.0[A] -> GSI 9 (level, low) -> IRQ 9
sata_mvPCI master won't flush

which means init failed, but the driver is still loaded at this point.  
Afterwards, when I try to run rmmod, I get:

 Unable to handle kernel NULL pointer dereference at virtual address 0024
  printing eip:
 f89738b9
 *pde = 
 Oops:  [#1]
 Modules linked in: sata_mv(U) sd_mod libata scsi_mod nfsd exportfs lockd 
sunrpc dm_mod button battery ac uhci_hcd ehci_hcd e1000 ext3 jbd
 CPU:0
 EIP:0060:[]Not tainted VLI
 EFLAGS: 00010246   (2.6.9-16.EL) 
 EIP is at ata_pci_remove_one+0x12/0xb3 [libata]
 eax: f7f6ac44   ebx:    ecx: f8855488   edx: f89738a7
 esi: f8855424   edi:    ebp: f7f6ac00   esp: f6f96f14
 ds: 007b   es: 007b   ss: 0068
 Process rmmod (pid: 2628, threadinfo=f6f96000 task=f733f770)
 Stack: f7f6ac44 f7f6ac00 f8855424 f8855424 f6f96000 c01ec1df f7f6ac44 c024a46f 
f8855424 f8855488 c024a491 c0368c40 c0368c8c c024a821 f885542c f8855424 
 c024abe7 f8855400 c035e5c0 c01ec39c f8855500 c013b6f5  
 Call Trace:
  [] pci_device_remove+0x16/0x28
  [] device_release_driver+0x3c/0x46
  [] driver_detach+0x18/0x1f
  [] bus_remove_driver+0x48/0x75
  [] driver_unregister+0xc/0x31
  [] pci_unregister_driver+0xb/0x13
  [] sys_delete_module+0x132/0x179
  [] unmap_vma_list+0xe/0x17
  [] do_munmap+0x1c8/0x1d2
  [] do_page_fault+0x0/0x4dc
  [] syscall_call+0x7/0xb
 Code: 87 c7 83 3c 24 00 74 07 89 e8 e8 59 72 87 c7 89 f0 83 c4 54 5b 5e 5f 5d 
c3 55 89 c5 8d 40 44 57 31 ff 56 53 52 89 04 24 8b 58 74 <3b> 7b 24 73 0e 8b 74 
bb 30 47 8b 06 e8 55 ef fa ff eb ed 8b 43 
  <0>Fatal exception: panic in 5 seconds

This init error seems to be connected to the PCI BusMaster state:  
after booting, but before loading the driver, 'lspci -vv' shows
BusMaster+, but after loading the driver which complains, the state is
BusMaster-. This is with the latest BIOS (1007A) available for this
board, so "update BIOS" is not an option...

If I comment out the call to mv_master_reset(), the driver seems to 
initialize fine (no disks attached at this point):

sata_mv version 0.10
ACPI: PCI interrupt :02:08.0[A] -> GSI 9 (level, low) -> IRQ 9
ata1: SATA max PIO4 cmd 0x0 ctl 0xF8A22120 bmdma 0x0 irq 9
ata2: SATA max PIO4 cmd 0x0 ctl 0xF8A24120 bmdma 0x0 irq 9
ata3: SATA max PIO4 cmd 0x0 ctl 0xF8A26120 bmdma 0x0 irq 9
ata4: SATA max PIO4 cmd 0x0 ctl 0xF8A28120 bmdma 0x0 irq 9
ata1: no device found (phy stat )
scsi0 : sata_mv
ata2: no device found (phy stat )
scsi1 : sata_mv
ata3: no device found (phy stat )
scsi2 : sata_mv
ata4: no device found (phy stat )
scsi3 : sata_mv
blk_queue_max_hw_segments: set to minimum 1

(the last line is actually repeated several times). Afterwards, rmmod 
doesn't produce any oops.

If I connect a disk in this state (driver unloaded) = device hotplug,
I get immediately:

irq 9: nobody cared! (screaming interrupt?)
irq 9: Please try booting with acpi=off and report a bug
 [] __report_bad_irq+0x3a/0x77
 [] note_interrupt+0x191/0x1b7
 [] do_IRQ+0x209/0x2bf
 [] common_interrupt+0x18/0x20
 [] skb_copy_and_csum_bits+0x25d/0x281
 [] __do_softirq+0x2c/0x79
 [] do_softirq+0x46/0x4d
 ===
 [] do_IRQ+0x2b3/0x2bf
 [] common_interrupt+0x18/0x20
 [] default_idle+0x23/0x26
 [] cpu_idle+0x1f/0x34
 [] start_kernel+0x214/0x216
handlers:
[] (acpi_irq+0x0/0x14)
Disabling IRQ #9

so I guess that the controller generates some interrupt whenever a
device is connected and the kernel doesn't know what to do with this
interrupt - so the interrupt generation by the controller probably has
to be disabled on rmmod.

Booting with apci=off and loading the same driver (without the
mv_master_reset() call) with one disk connected, I get:

 PCI: Found IRQ 5 for device :02:08.0
 PCI: Sharing IRQ 5 with :00:1d.0
 IRQ routing conflict for :02:08.0, have irq 9, want irq 5
 ata1: SATA max PIO4 cmd 0x0 ctl 0xF8A22120 bmdma 0x0 irq 9

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Bogdan Costescu]

On Thu, 1 Sep 2005, Brett Russ wrote:

 This is my libata compatible low level driver for the Marvell SATA
 family.

First of all, thanks! I've been waiting for such a driver to appear.

I somehow did not manage to get a working 2.6.13 kernel to boot and,
as I didn't have too much time to see why, I compiled this driver
against the RHEL 4 Update 2 beta kernel (2.6.9-16, but which is itself
compiled by me from source RPM, so Jeff won't be able to match
addresses with the real RHEL binary RPM), which has libata v1.11, as
opposed to v1.12 in kernel 2.6.13 - I had to add the pci_intx function
(from ahci.c in kernel 2.6.13) and to remove the last line
(.ordered_flush = 1) from mv_sht initialization. All tests are with
the UP kernel.

The hardware is an Asus PSCHSR-A board with Adaptec AIC8110, but which 
appears on the PCI bus (supposedly a PCI-X one) as:

02:08.0 SCSI storage controller: Marvell Technology Group Ltd. MV88SX5041 
4-port SATA I PCI-X Controller (rev 03)

The driver starts with:

ACPI: PCI interrupt :02:08.0[A] - GSI 9 (level, low) - IRQ 9
sata_mvPCI master won't flush

which means init failed, but the driver is still loaded at this point.  
Afterwards, when I try to run rmmod, I get:

 Unable to handle kernel NULL pointer dereference at virtual address 0024
  printing eip:
 f89738b9
 *pde = 
 Oops:  [#1]
 Modules linked in: sata_mv(U) sd_mod libata scsi_mod nfsd exportfs lockd 
sunrpc dm_mod button battery ac uhci_hcd ehci_hcd e1000 ext3 jbd
 CPU:0
 EIP:0060:[f89738b9]Not tainted VLI
 EFLAGS: 00010246   (2.6.9-16.EL) 
 EIP is at ata_pci_remove_one+0x12/0xb3 [libata]
 eax: f7f6ac44   ebx:    ecx: f8855488   edx: f89738a7
 esi: f8855424   edi:    ebp: f7f6ac00   esp: f6f96f14
 ds: 007b   es: 007b   ss: 0068
 Process rmmod (pid: 2628, threadinfo=f6f96000 task=f733f770)
 Stack: f7f6ac44 f7f6ac00 f8855424 f8855424 f6f96000 c01ec1df f7f6ac44 c024a46f 
f8855424 f8855488 c024a491 c0368c40 c0368c8c c024a821 f885542c f8855424 
 c024abe7 f8855400 c035e5c0 c01ec39c f8855500 c013b6f5  
 Call Trace:
  [c01ec1df] pci_device_remove+0x16/0x28
  [c024a46f] device_release_driver+0x3c/0x46
  [c024a491] driver_detach+0x18/0x1f
  [c024a821] bus_remove_driver+0x48/0x75
  [c024abe7] driver_unregister+0xc/0x31
  [c01ec39c] pci_unregister_driver+0xb/0x13
  [c013b6f5] sys_delete_module+0x132/0x179
  [c015a699] unmap_vma_list+0xe/0x17
  [c015aa48] do_munmap+0x1c8/0x1d2
  [c011a779] do_page_fault+0x0/0x4dc
  [c030fa37] syscall_call+0x7/0xb
 Code: 87 c7 83 3c 24 00 74 07 89 e8 e8 59 72 87 c7 89 f0 83 c4 54 5b 5e 5f 5d 
c3 55 89 c5 8d 40 44 57 31 ff 56 53 52 89 04 24 8b 58 74 3b 7b 24 73 0e 8b 74 
bb 30 47 8b 06 e8 55 ef fa ff eb ed 8b 43 
  0Fatal exception: panic in 5 seconds

This init error seems to be connected to the PCI BusMaster state:  
after booting, but before loading the driver, 'lspci -vv' shows
BusMaster+, but after loading the driver which complains, the state is
BusMaster-. This is with the latest BIOS (1007A) available for this
board, so update BIOS is not an option...

If I comment out the call to mv_master_reset(), the driver seems to 
initialize fine (no disks attached at this point):

sata_mv version 0.10
ACPI: PCI interrupt :02:08.0[A] - GSI 9 (level, low) - IRQ 9
ata1: SATA max PIO4 cmd 0x0 ctl 0xF8A22120 bmdma 0x0 irq 9
ata2: SATA max PIO4 cmd 0x0 ctl 0xF8A24120 bmdma 0x0 irq 9
ata3: SATA max PIO4 cmd 0x0 ctl 0xF8A26120 bmdma 0x0 irq 9
ata4: SATA max PIO4 cmd 0x0 ctl 0xF8A28120 bmdma 0x0 irq 9
ata1: no device found (phy stat )
scsi0 : sata_mv
ata2: no device found (phy stat )
scsi1 : sata_mv
ata3: no device found (phy stat )
scsi2 : sata_mv
ata4: no device found (phy stat )
scsi3 : sata_mv
blk_queue_max_hw_segments: set to minimum 1

(the last line is actually repeated several times). Afterwards, rmmod 
doesn't produce any oops.

If I connect a disk in this state (driver unloaded) = device hotplug,
I get immediately:

irq 9: nobody cared! (screaming interrupt?)
irq 9: Please try booting with acpi=off and report a bug
 [c0107e8f] __report_bad_irq+0x3a/0x77
 [c010834d] note_interrupt+0x191/0x1b7
 [c0108852] do_IRQ+0x209/0x2bf
 [c030fb7c] common_interrupt+0x18/0x20
 [c02b007b] skb_copy_and_csum_bits+0x25d/0x281
 [c0126774] __do_softirq+0x2c/0x79
 [c0109338] do_softirq+0x46/0x4d
 ===
 [c01088fc] do_IRQ+0x2b3/0x2bf
 [c030fb7c] common_interrupt+0x18/0x20
 [c010403b] default_idle+0x23/0x26
 [c010408c] cpu_idle+0x1f/0x34
 [c03b86b9] start_kernel+0x214/0x216
handlers:
[c01fc0c3] (acpi_irq+0x0/0x14)
Disabling IRQ #9

so I guess that the controller generates some interrupt whenever a
device is connected and the kernel doesn't know what to do with this
interrupt - so the interrupt generation by the controller probably has
to be disabled on rmmod.

Booting with apci=off and loading the same driver (without the
mv_master_reset() call) with one disk connected, I get:

 PCI: Found 

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Ray Lee]

On 9/1/05, Brett Russ [EMAIL PROTECTED] wrote:
 More (non-functional) style modifications since the version 0.11
 driver I sent out earlier today.  Removed most parens around return
 value, 

return is not a function call; you can safely remove them all.

 +   return ((void __iomem *)((unsigned long)port_mmio 
 +(unsigned long)SATAHC_MASK));
 +   return (base + MV_SATAHC0_REG_BASE + (hc * MV_SATAHC_REG_SZ));
 +   return (mv_hc_base(base, port  MV_PORT_HC_SHIFT) +
 +   MV_SATAHC_ARBTR_REG_SZ +
 +   ((port  MV_PORT_MASK) * MV_PORT_REG_SZ));
 +   return ((flags  MV_FLAG_DUAL_HC) ? 2 : 1);
 +   return (EDMA_EN  readl(port_mmio + EDMA_CMD_OFS));
 +   return (ap-flags  MV_FLAG_BDMA);

Ray
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

Brett Russ wrote:

This is my libata compatible low level driver for the Marvell SATA
family.  Currently it successfully runs in PIO mode on a 6081 chip.
EDMA support is in the works and should be done shortly.  Review,
testing (especially on other flavors of Marvell), comments welcome.


Note that this patch depends on the PCI INTx patch I submitted earlier:

http://lkml.org/lkml/2005/8/15/165

Sorry for the delayed notice,
BR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

More (non-functional) style modifications since the version 0.11
driver I sent out earlier today.  Removed most parens around return
value, corrected indentation of labels, improved comment for flush,
removed naked return, and cleanup ata_qc_from_tag() call block.

This is my libata compatible low level driver for the Marvell SATA
family.  Currently it successfully runs in PIO mode on a 6081 chip.
EDMA support is in the works and should be done shortly.  Review,
testing (especially on other flavors of Marvell), comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ <[EMAIL PROTECTED]>


Index: linux-2.6.13/drivers/scsi/sata_mv.c
===
--- /dev/null
+++ linux-2.6.13/drivers/scsi/sata_mv.c
@@ -0,0 +1,827 @@
+/*
+ * sata_mv.c - Marvell SATA support
+ *
+ * Copyright 2005: EMC Corporation, all rights reserved. 
+ *
+ * Please ALWAYS copy linux-ide@vger.kernel.org on emails.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "scsi.h"
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "sata_mv"
+#define DRV_VERSION"0.12"
+
+enum {
+   /* BAR's are enumerated in terms of pci_resource_start() terms */
+   MV_PRIMARY_BAR  = 0,/* offset 0x10: memory space */
+   MV_IO_BAR   = 2,/* offset 0x18: IO space */
+   MV_MISC_BAR = 3,/* offset 0x1c: FLASH, NVRAM, SRAM */
+
+   MV_MAJOR_REG_AREA_SZ= 0x1,  /* 64KB */
+   MV_MINOR_REG_AREA_SZ= 0x2000,   /* 8KB */
+
+   MV_PCI_REG_BASE = 0,
+   MV_IRQ_COAL_REG_BASE= 0x18000,  /* 6xxx part only */
+   MV_SATAHC0_REG_BASE = 0x2,
+
+   MV_PCI_REG_SZ   = MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_REG_SZ= MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_ARBTR_REG_SZ  = MV_MINOR_REG_AREA_SZ, /* arbiter */
+   MV_PORT_REG_SZ  = MV_MINOR_REG_AREA_SZ,
+
+   MV_Q_CT = 32,
+   MV_CRQB_SZ  = 32,
+   MV_CRPB_SZ  = 8,
+
+   MV_DMA_BOUNDARY = 0xU,
+   SATAHC_MASK = (~(MV_SATAHC_REG_SZ - 1)),
+
+   MV_PORTS_PER_HC = 4,
+   /* == (port / MV_PORTS_PER_HC) to determine HC from 0-7 port */
+   MV_PORT_HC_SHIFT= 2,
+   /* == (port % MV_PORTS_PER_HC) to determine port from 0-7 port */
+   MV_PORT_MASK= 3,
+
+   /* Host Flags */
+   MV_FLAG_DUAL_HC = (1 << 30),  /* two SATA Host Controllers */
+   MV_FLAG_IRQ_COALESCE= (1 << 29),  /* IRQ coalescing capability */
+   MV_FLAG_BDMA= (1 << 28),  /* Basic DMA */
+
+   chip_504x   = 0,
+   chip_508x   = 1,
+   chip_604x   = 2,
+   chip_608x   = 3,
+
+   /* PCI interface registers */
+
+   PCI_MAIN_CMD_STS_OFS= 0xd30,
+   STOP_PCI_MASTER = (1 << 2),
+   PCI_MASTER_EMPTY= (1 << 3),
+   GLOB_SFT_RST= (1 << 4),
+
+   PCI_IRQ_CAUSE_OFS   = 0x1d58,
+   PCI_IRQ_MASK_OFS= 0x1d5c,
+   PCI_UNMASK_ALL_IRQS = 0x7f, /* bits 22-0 */
+
+   HC_MAIN_IRQ_CAUSE_OFS   = 0x1d60,
+   HC_MAIN_IRQ_MASK_OFS= 0x1d64,
+   PORT0_ERR   = (1 << 0), /* shift by port # */
+   PORT0_DONE  = (1 << 1), /* shift by port # */
+   HC0_IRQ_PEND= 0x1ff,/* bits 0-8 = HC0's ports */
+   HC_SHIFT= 9,/* bits 9-17 = HC1's ports */
+   PCI_ERR = (1 << 18),
+   TRAN_LO_DONE= (1 << 19),/* 6xxx: IRQ coalescing */
+   TRAN_HI_DONE= (1 << 20),/* 6xxx: IRQ coalescing */
+   PORTS_0_7_COAL_DONE = (1 << 21),/* 6xxx: IRQ coalescing */
+   GPIO_INT= (1 << 22),
+   SELF_INT= (1 << 23),
+   TWSI_INT= (1 << 24),
+   HC_MAIN_RSVD= (0x7f << 25), /* bits 31-25 */
+   HC_MAIN_MASKED_IRQS = (TRAN_LO_DONE | TRAN_HI_DONE | 
+  PORTS_0_7_COAL_DONE | GPIO_INT | TWSI_INT |
+  HC_MAIN_RSVD),
+
+   /* SATAHC registers 

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Christoph Hellwig]

On Thu, Sep 01, 2005 at 04:03:27PM -0400, Jeff Garzik wrote:
> Christoph Hellwig wrote:
> >On Thu, Sep 01, 2005 at 03:48:51PM -0400, Jeff Garzik wrote:
> >
> >>Christoph Hellwig wrote:
> >>
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "scsi.h"
> >>>
> >>>
> >>>pleaese don't include "scsi.h" in new drivers.  It will go away soon.
> >>>Use the  headers and get rid of usage of obsolete constucts
> >>>in your driver.
> >>
> >>
> >>It stays until the rest of the libata drivers lose the include.
> >>
> >>After ATAPI support is done, I can stop 2.4.x support, and this and 
> >>several other compat-isms will go away.
> >
> >
> >NACK.  Jeff, I accept that you don't want to convert old drivers yet,
> >but this is not acceptable for new drivers.  We don't allow it for any
> >new scsi LLDDs, and that includes libata drivers.
> 
> Sorry, you don't get to NAK that change, since it affects 2.4.x 
> maintenance of this new driver.

Stop that crap now please.  Adding "scsi.h" includes is _not_ allowed
for new drivers, period.  There's no exceptions, not even for
Jeff "I'm part of the calal" Garzik.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Jeff Garzik wrote:

As I said, the include does away simultaneously for all libata drivers.


s/does/goes/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Christoph Hellwig wrote:

Stop that crap now please.  Adding "scsi.h" includes is _not_ allowed
for new drivers, period.  There's no exceptions, not even for
Jeff "I'm part of the calal" Garzik.


There are solid technical reasons (a) why libata drivers include scsi.h, 
and (b) why all libata drivers look similar.  It -impedes- maintenance 
to have one libata driver different from all the others, and this is 
what you are suggesting.


Your suggestion causes nothing but additional work, for zero gain:  as I 
have explained, all the scsi.h includes will go away at the same time. 
Such as sweep would catch all libata drivers, including sata_mv.


Until you're willing to step up and help with 2.4.x maintenance, you're 
just being an impediment for non-technical reasons.  If you want to do 
that, join politics and become a politician.  I have real work to do.


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Christoph Hellwig wrote:

+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "scsi.h"



pleaese don't include "scsi.h" in new drivers.  It will go away soon.
Use the  headers and get rid of usage of obsolete constucts
in your driver.



It stays until the rest of the libata drivers lose the include.

After ATAPI support is done, I can stop 2.4.x support, and this and 
several other compat-isms will go away.


Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Christoph Hellwig]

On Thu, Sep 01, 2005 at 03:48:51PM -0400, Jeff Garzik wrote:
> Christoph Hellwig wrote:
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include "scsi.h"
> >
> >
> >pleaese don't include "scsi.h" in new drivers.  It will go away soon.
> >Use the  headers and get rid of usage of obsolete constucts
> >in your driver.
> 
> 
> It stays until the rest of the libata drivers lose the include.
> 
> After ATAPI support is done, I can stop 2.4.x support, and this and 
> several other compat-isms will go away.

NACK.  Jeff, I accept that you don't want to convert old drivers yet,
but this is not acceptable for new drivers.  We don't allow it for any
new scsi LLDDs, and that includes libata drivers.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Christoph Hellwig wrote:

On Thu, Sep 01, 2005 at 03:48:51PM -0400, Jeff Garzik wrote:


Christoph Hellwig wrote:


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "scsi.h"



pleaese don't include "scsi.h" in new drivers.  It will go away soon.
Use the  headers and get rid of usage of obsolete constucts
in your driver.



It stays until the rest of the libata drivers lose the include.

After ATAPI support is done, I can stop 2.4.x support, and this and 
several other compat-isms will go away.



NACK.  Jeff, I accept that you don't want to convert old drivers yet,
but this is not acceptable for new drivers.  We don't allow it for any
new scsi LLDDs, and that includes libata drivers.


Sorry, you don't get to NAK that change, since it affects 2.4.x 
maintenance of this new driver.


As I said, the include does away simultaneously for all libata drivers.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Christoph Hellwig]

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "scsi.h"

pleaese don't include "scsi.h" in new drivers.  It will go away soon.
Use the  headers and get rid of usage of obsolete constucts
in your driver.

> +static inline void writelfl(unsigned long data, void __iomem *addr)
> +{
> + writel(data, addr);
> + (void) readl(addr); /* flush */

no need for the (void) case.

> +static void mv_irq_clear(struct ata_port *ap)
> +{
> + return;
> +}

no need for the return

> + return (ofs);

please remove the braces around the return value

> + if (ap && 
> + (NULL != (qc = ata_qc_from_tag(ap, ap->active_tag {
> + VPRINTK("port %u IRQ found for qc, ata_status 0x%x\n",
> + port,ata_status);
> + BUG_ON(0xffU == ata_status);
> + /* mark qc status appropriately */
> + ata_qc_complete(qc, ata_status);
> + }

the formatting looks rather odd.  What about;

if (ap) {
qc = ata_qc_from_tag(ap, ap->active_tag);
if (qc) {
VPRINTK("port %u IRQ found for qc, "
"ata_status 0x%x\n",
port, ata_status);
BUG_ON(0xffU == ata_status);
/* mark qc status appropriately */
ata_qc_complete(qc, ata_status);
}
}

> +  err_out_hpriv:

rather odd placement of the goto labels.  If you look at kernel code it's
always either not indented at all, or indented a single space.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

Some (non-functional) cleanup modifications since the version 0.10
driver I sent out 2005-08-30.  Also adding signed-off-by for Jeff's
upstream push.  This is my libata compatible low level driver for
the Marvell SATA family.  Currently it successfully runs in PIO mode
on a 6081 chip.  EDMA support is in the works and should be done
shortly.  Review, testing (especially on other flavors of Marvell),
comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ <[EMAIL PROTECTED]>


Index: linux-2.6.13/drivers/scsi/sata_mv.c
===
--- /dev/null
+++ linux-2.6.13/drivers/scsi/sata_mv.c
@@ -0,0 +1,826 @@
+/*
+ * sata_mv.c - Marvell SATA support
+ *
+ * Copyright 2005: EMC Corporation, all rights reserved. 
+ *
+ * Please ALWAYS copy linux-ide@vger.kernel.org on emails.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "scsi.h"
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "sata_mv"
+#define DRV_VERSION"0.11"
+
+enum {
+   /* BAR's are enumerated in terms of pci_resource_start() terms */
+   MV_PRIMARY_BAR  = 0,/* offset 0x10: memory space */
+   MV_IO_BAR   = 2,/* offset 0x18: IO space */
+   MV_MISC_BAR = 3,/* offset 0x1c: FLASH, NVRAM, SRAM */
+
+   MV_MAJOR_REG_AREA_SZ= 0x1,  /* 64KB */
+   MV_MINOR_REG_AREA_SZ= 0x2000,   /* 8KB */
+
+   MV_PCI_REG_BASE = 0,
+   MV_IRQ_COAL_REG_BASE= 0x18000,  /* 6xxx part only */
+   MV_SATAHC0_REG_BASE = 0x2,
+
+   MV_PCI_REG_SZ   = MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_REG_SZ= MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_ARBTR_REG_SZ  = MV_MINOR_REG_AREA_SZ, /* arbiter */
+   MV_PORT_REG_SZ  = MV_MINOR_REG_AREA_SZ,
+
+   MV_Q_CT = 32,
+   MV_CRQB_SZ  = 32,
+   MV_CRPB_SZ  = 8,
+
+   MV_DMA_BOUNDARY = 0xU,
+   SATAHC_MASK = (~(MV_SATAHC_REG_SZ - 1)),
+
+   MV_PORTS_PER_HC = 4,
+   /* == (port / MV_PORTS_PER_HC) to determine HC from 0-7 port */
+   MV_PORT_HC_SHIFT= 2,
+   /* == (port % MV_PORTS_PER_HC) to determine port from 0-7 port */
+   MV_PORT_MASK= 3,
+
+   /* Host Flags */
+   MV_FLAG_DUAL_HC = (1 << 30),  /* two SATA Host Controllers */
+   MV_FLAG_IRQ_COALESCE= (1 << 29),  /* IRQ coalescing capability */
+   MV_FLAG_BDMA= (1 << 28),  /* Basic DMA */
+
+   chip_504x   = 0,
+   chip_508x   = 1,
+   chip_604x   = 2,
+   chip_608x   = 3,
+
+   /* PCI interface registers */
+
+   PCI_MAIN_CMD_STS_OFS= 0xd30,
+   STOP_PCI_MASTER = (1 << 2),
+   PCI_MASTER_EMPTY= (1 << 3),
+   GLOB_SFT_RST= (1 << 4),
+
+   PCI_IRQ_CAUSE_OFS   = 0x1d58,
+   PCI_IRQ_MASK_OFS= 0x1d5c,
+   PCI_UNMASK_ALL_IRQS = 0x7f, /* bits 22-0 */
+
+   HC_MAIN_IRQ_CAUSE_OFS   = 0x1d60,
+   HC_MAIN_IRQ_MASK_OFS= 0x1d64,
+   PORT0_ERR   = (1 << 0), /* shift by port # */
+   PORT0_DONE  = (1 << 1), /* shift by port # */
+   HC0_IRQ_PEND= 0x1ff,/* bits 0-8 = HC0's ports */
+   HC_SHIFT= 9,/* bits 9-17 = HC1's ports */
+   PCI_ERR = (1 << 18),
+   TRAN_LO_DONE= (1 << 19),/* 6xxx: IRQ coalescing */
+   TRAN_HI_DONE= (1 << 20),/* 6xxx: IRQ coalescing */
+   PORTS_0_7_COAL_DONE = (1 << 21),/* 6xxx: IRQ coalescing */
+   GPIO_INT= (1 << 22),
+   SELF_INT= (1 << 23),
+   TWSI_INT= (1 << 24),
+   HC_MAIN_RSVD= (0x7f << 25), /* bits 31-25 */
+   HC_MAIN_MASKED_IRQS = (TRAN_LO_DONE | TRAN_HI_DONE | 
+  PORTS_0_7_COAL_DONE | GPIO_INT | TWSI_INT |
+  HC_MAIN_RSVD),
+
+   /* SATAHC registers */
+   HC_CFG_OFS  = 0,
+
+   HC_IRQ_CAUSE_OFS= 0x14,
+   CRBP_DMA_DONE   

[PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

Some (non-functional) cleanup modifications since the version 0.10
driver I sent out 2005-08-30.  Also adding signed-off-by for Jeff's
upstream push.  This is my libata compatible low level driver for
the Marvell SATA family.  Currently it successfully runs in PIO mode
on a 6081 chip.  EDMA support is in the works and should be done
shortly.  Review, testing (especially on other flavors of Marvell),
comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ [EMAIL PROTECTED]


Index: linux-2.6.13/drivers/scsi/sata_mv.c
===
--- /dev/null
+++ linux-2.6.13/drivers/scsi/sata_mv.c
@@ -0,0 +1,826 @@
+/*
+ * sata_mv.c - Marvell SATA support
+ *
+ * Copyright 2005: EMC Corporation, all rights reserved. 
+ *
+ * Please ALWAYS copy linux-ide@vger.kernel.org on emails.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/init.h
+#include linux/blkdev.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include linux/dma-mapping.h
+#include scsi.h
+#include scsi/scsi_host.h
+#include linux/libata.h
+#include asm/io.h
+
+#define DRV_NAME   sata_mv
+#define DRV_VERSION0.11
+
+enum {
+   /* BAR's are enumerated in terms of pci_resource_start() terms */
+   MV_PRIMARY_BAR  = 0,/* offset 0x10: memory space */
+   MV_IO_BAR   = 2,/* offset 0x18: IO space */
+   MV_MISC_BAR = 3,/* offset 0x1c: FLASH, NVRAM, SRAM */
+
+   MV_MAJOR_REG_AREA_SZ= 0x1,  /* 64KB */
+   MV_MINOR_REG_AREA_SZ= 0x2000,   /* 8KB */
+
+   MV_PCI_REG_BASE = 0,
+   MV_IRQ_COAL_REG_BASE= 0x18000,  /* 6xxx part only */
+   MV_SATAHC0_REG_BASE = 0x2,
+
+   MV_PCI_REG_SZ   = MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_REG_SZ= MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_ARBTR_REG_SZ  = MV_MINOR_REG_AREA_SZ, /* arbiter */
+   MV_PORT_REG_SZ  = MV_MINOR_REG_AREA_SZ,
+
+   MV_Q_CT = 32,
+   MV_CRQB_SZ  = 32,
+   MV_CRPB_SZ  = 8,
+
+   MV_DMA_BOUNDARY = 0xU,
+   SATAHC_MASK = (~(MV_SATAHC_REG_SZ - 1)),
+
+   MV_PORTS_PER_HC = 4,
+   /* == (port / MV_PORTS_PER_HC) to determine HC from 0-7 port */
+   MV_PORT_HC_SHIFT= 2,
+   /* == (port % MV_PORTS_PER_HC) to determine port from 0-7 port */
+   MV_PORT_MASK= 3,
+
+   /* Host Flags */
+   MV_FLAG_DUAL_HC = (1  30),  /* two SATA Host Controllers */
+   MV_FLAG_IRQ_COALESCE= (1  29),  /* IRQ coalescing capability */
+   MV_FLAG_BDMA= (1  28),  /* Basic DMA */
+
+   chip_504x   = 0,
+   chip_508x   = 1,
+   chip_604x   = 2,
+   chip_608x   = 3,
+
+   /* PCI interface registers */
+
+   PCI_MAIN_CMD_STS_OFS= 0xd30,
+   STOP_PCI_MASTER = (1  2),
+   PCI_MASTER_EMPTY= (1  3),
+   GLOB_SFT_RST= (1  4),
+
+   PCI_IRQ_CAUSE_OFS   = 0x1d58,
+   PCI_IRQ_MASK_OFS= 0x1d5c,
+   PCI_UNMASK_ALL_IRQS = 0x7f, /* bits 22-0 */
+
+   HC_MAIN_IRQ_CAUSE_OFS   = 0x1d60,
+   HC_MAIN_IRQ_MASK_OFS= 0x1d64,
+   PORT0_ERR   = (1  0), /* shift by port # */
+   PORT0_DONE  = (1  1), /* shift by port # */
+   HC0_IRQ_PEND= 0x1ff,/* bits 0-8 = HC0's ports */
+   HC_SHIFT= 9,/* bits 9-17 = HC1's ports */
+   PCI_ERR = (1  18),
+   TRAN_LO_DONE= (1  19),/* 6xxx: IRQ coalescing */
+   TRAN_HI_DONE= (1  20),/* 6xxx: IRQ coalescing */
+   PORTS_0_7_COAL_DONE = (1  21),/* 6xxx: IRQ coalescing */
+   GPIO_INT= (1  22),
+   SELF_INT= (1  23),
+   TWSI_INT= (1  24),
+   HC_MAIN_RSVD= (0x7f  25), /* bits 31-25 */
+   HC_MAIN_MASKED_IRQS = (TRAN_LO_DONE | TRAN_HI_DONE | 
+  PORTS_0_7_COAL_DONE | GPIO_INT | TWSI_INT |
+  HC_MAIN_RSVD),
+
+   /* 

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Christoph Hellwig]

 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/pci.h
 +#include linux/init.h
 +#include linux/blkdev.h
 +#include linux/delay.h
 +#include linux/interrupt.h
 +#include linux/sched.h
 +#include linux/dma-mapping.h
 +#include scsi.h

pleaese don't include scsi.h in new drivers.  It will go away soon.
Use the scsi/*.h headers and get rid of usage of obsolete constucts
in your driver.

 +static inline void writelfl(unsigned long data, void __iomem *addr)
 +{
 + writel(data, addr);
 + (void) readl(addr); /* flush */

no need for the (void) case.

 +static void mv_irq_clear(struct ata_port *ap)
 +{
 + return;
 +}

no need for the return

 + return (ofs);

please remove the braces around the return value

 + if (ap  
 + (NULL != (qc = ata_qc_from_tag(ap, ap-active_tag {
 + VPRINTK(port %u IRQ found for qc, ata_status 0x%x\n,
 + port,ata_status);
 + BUG_ON(0xffU == ata_status);
 + /* mark qc status appropriately */
 + ata_qc_complete(qc, ata_status);
 + }

the formatting looks rather odd.  What about;

if (ap) {
qc = ata_qc_from_tag(ap, ap-active_tag);
if (qc) {
VPRINTK(port %u IRQ found for qc, 
ata_status 0x%x\n,
port, ata_status);
BUG_ON(0xffU == ata_status);
/* mark qc status appropriately */
ata_qc_complete(qc, ata_status);
}
}

 +  err_out_hpriv:

rather odd placement of the goto labels.  If you look at kernel code it's
always either not indented at all, or indented a single space.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Christoph Hellwig wrote:

+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/init.h
+#include linux/blkdev.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include linux/dma-mapping.h
+#include scsi.h



pleaese don't include scsi.h in new drivers.  It will go away soon.
Use the scsi/*.h headers and get rid of usage of obsolete constucts
in your driver.



It stays until the rest of the libata drivers lose the include.

After ATAPI support is done, I can stop 2.4.x support, and this and 
several other compat-isms will go away.


Jeff


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Jeff Garzik wrote:

As I said, the include does away simultaneously for all libata drivers.


s/does/goes/

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Christoph Hellwig wrote:

Stop that crap now please.  Adding scsi.h includes is _not_ allowed
for new drivers, period.  There's no exceptions, not even for
Jeff I'm part of the calal Garzik.


There are solid technical reasons (a) why libata drivers include scsi.h, 
and (b) why all libata drivers look similar.  It -impedes- maintenance 
to have one libata driver different from all the others, and this is 
what you are suggesting.


Your suggestion causes nothing but additional work, for zero gain:  as I 
have explained, all the scsi.h includes will go away at the same time. 
Such as sweep would catch all libata drivers, including sata_mv.


Until you're willing to step up and help with 2.4.x maintenance, you're 
just being an impediment for non-technical reasons.  If you want to do 
that, join politics and become a politician.  I have real work to do.


Jeff


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Christoph Hellwig]

On Thu, Sep 01, 2005 at 03:48:51PM -0400, Jeff Garzik wrote:
 Christoph Hellwig wrote:
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/pci.h
 +#include linux/init.h
 +#include linux/blkdev.h
 +#include linux/delay.h
 +#include linux/interrupt.h
 +#include linux/sched.h
 +#include linux/dma-mapping.h
 +#include scsi.h
 
 
 pleaese don't include scsi.h in new drivers.  It will go away soon.
 Use the scsi/*.h headers and get rid of usage of obsolete constucts
 in your driver.
 
 
 It stays until the rest of the libata drivers lose the include.
 
 After ATAPI support is done, I can stop 2.4.x support, and this and 
 several other compat-isms will go away.

NACK.  Jeff, I accept that you don't want to convert old drivers yet,
but this is not acceptable for new drivers.  We don't allow it for any
new scsi LLDDs, and that includes libata drivers.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Jeff Garzik]

Christoph Hellwig wrote:

On Thu, Sep 01, 2005 at 03:48:51PM -0400, Jeff Garzik wrote:


Christoph Hellwig wrote:


+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/init.h
+#include linux/blkdev.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include linux/dma-mapping.h
+#include scsi.h



pleaese don't include scsi.h in new drivers.  It will go away soon.
Use the scsi/*.h headers and get rid of usage of obsolete constucts
in your driver.



It stays until the rest of the libata drivers lose the include.

After ATAPI support is done, I can stop 2.4.x support, and this and 
several other compat-isms will go away.



NACK.  Jeff, I accept that you don't want to convert old drivers yet,
but this is not acceptable for new drivers.  We don't allow it for any
new scsi LLDDs, and that includes libata drivers.


Sorry, you don't get to NAK that change, since it affects 2.4.x 
maintenance of this new driver.


As I said, the include does away simultaneously for all libata drivers.

Jeff



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Christoph Hellwig]

On Thu, Sep 01, 2005 at 04:03:27PM -0400, Jeff Garzik wrote:
 Christoph Hellwig wrote:
 On Thu, Sep 01, 2005 at 03:48:51PM -0400, Jeff Garzik wrote:
 
 Christoph Hellwig wrote:
 
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/pci.h
 +#include linux/init.h
 +#include linux/blkdev.h
 +#include linux/delay.h
 +#include linux/interrupt.h
 +#include linux/sched.h
 +#include linux/dma-mapping.h
 +#include scsi.h
 
 
 pleaese don't include scsi.h in new drivers.  It will go away soon.
 Use the scsi/*.h headers and get rid of usage of obsolete constucts
 in your driver.
 
 
 It stays until the rest of the libata drivers lose the include.
 
 After ATAPI support is done, I can stop 2.4.x support, and this and 
 several other compat-isms will go away.
 
 
 NACK.  Jeff, I accept that you don't want to convert old drivers yet,
 but this is not acceptable for new drivers.  We don't allow it for any
 new scsi LLDDs, and that includes libata drivers.
 
 Sorry, you don't get to NAK that change, since it affects 2.4.x 
 maintenance of this new driver.

Stop that crap now please.  Adding scsi.h includes is _not_ allowed
for new drivers, period.  There's no exceptions, not even for
Jeff I'm part of the calal Garzik.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

More (non-functional) style modifications since the version 0.11
driver I sent out earlier today.  Removed most parens around return
value, corrected indentation of labels, improved comment for flush,
removed naked return, and cleanup ata_qc_from_tag() call block.

This is my libata compatible low level driver for the Marvell SATA
family.  Currently it successfully runs in PIO mode on a 6081 chip.
EDMA support is in the works and should be done shortly.  Review,
testing (especially on other flavors of Marvell), comments welcome.

Thank you,
BR

Signed-off-by: Brett Russ [EMAIL PROTECTED]


Index: linux-2.6.13/drivers/scsi/sata_mv.c
===
--- /dev/null
+++ linux-2.6.13/drivers/scsi/sata_mv.c
@@ -0,0 +1,827 @@
+/*
+ * sata_mv.c - Marvell SATA support
+ *
+ * Copyright 2005: EMC Corporation, all rights reserved. 
+ *
+ * Please ALWAYS copy linux-ide@vger.kernel.org on emails.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/init.h
+#include linux/blkdev.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include linux/dma-mapping.h
+#include scsi.h
+#include scsi/scsi_host.h
+#include linux/libata.h
+#include asm/io.h
+
+#define DRV_NAME   sata_mv
+#define DRV_VERSION0.12
+
+enum {
+   /* BAR's are enumerated in terms of pci_resource_start() terms */
+   MV_PRIMARY_BAR  = 0,/* offset 0x10: memory space */
+   MV_IO_BAR   = 2,/* offset 0x18: IO space */
+   MV_MISC_BAR = 3,/* offset 0x1c: FLASH, NVRAM, SRAM */
+
+   MV_MAJOR_REG_AREA_SZ= 0x1,  /* 64KB */
+   MV_MINOR_REG_AREA_SZ= 0x2000,   /* 8KB */
+
+   MV_PCI_REG_BASE = 0,
+   MV_IRQ_COAL_REG_BASE= 0x18000,  /* 6xxx part only */
+   MV_SATAHC0_REG_BASE = 0x2,
+
+   MV_PCI_REG_SZ   = MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_REG_SZ= MV_MAJOR_REG_AREA_SZ,
+   MV_SATAHC_ARBTR_REG_SZ  = MV_MINOR_REG_AREA_SZ, /* arbiter */
+   MV_PORT_REG_SZ  = MV_MINOR_REG_AREA_SZ,
+
+   MV_Q_CT = 32,
+   MV_CRQB_SZ  = 32,
+   MV_CRPB_SZ  = 8,
+
+   MV_DMA_BOUNDARY = 0xU,
+   SATAHC_MASK = (~(MV_SATAHC_REG_SZ - 1)),
+
+   MV_PORTS_PER_HC = 4,
+   /* == (port / MV_PORTS_PER_HC) to determine HC from 0-7 port */
+   MV_PORT_HC_SHIFT= 2,
+   /* == (port % MV_PORTS_PER_HC) to determine port from 0-7 port */
+   MV_PORT_MASK= 3,
+
+   /* Host Flags */
+   MV_FLAG_DUAL_HC = (1  30),  /* two SATA Host Controllers */
+   MV_FLAG_IRQ_COALESCE= (1  29),  /* IRQ coalescing capability */
+   MV_FLAG_BDMA= (1  28),  /* Basic DMA */
+
+   chip_504x   = 0,
+   chip_508x   = 1,
+   chip_604x   = 2,
+   chip_608x   = 3,
+
+   /* PCI interface registers */
+
+   PCI_MAIN_CMD_STS_OFS= 0xd30,
+   STOP_PCI_MASTER = (1  2),
+   PCI_MASTER_EMPTY= (1  3),
+   GLOB_SFT_RST= (1  4),
+
+   PCI_IRQ_CAUSE_OFS   = 0x1d58,
+   PCI_IRQ_MASK_OFS= 0x1d5c,
+   PCI_UNMASK_ALL_IRQS = 0x7f, /* bits 22-0 */
+
+   HC_MAIN_IRQ_CAUSE_OFS   = 0x1d60,
+   HC_MAIN_IRQ_MASK_OFS= 0x1d64,
+   PORT0_ERR   = (1  0), /* shift by port # */
+   PORT0_DONE  = (1  1), /* shift by port # */
+   HC0_IRQ_PEND= 0x1ff,/* bits 0-8 = HC0's ports */
+   HC_SHIFT= 9,/* bits 9-17 = HC1's ports */
+   PCI_ERR = (1  18),
+   TRAN_LO_DONE= (1  19),/* 6xxx: IRQ coalescing */
+   TRAN_HI_DONE= (1  20),/* 6xxx: IRQ coalescing */
+   PORTS_0_7_COAL_DONE = (1  21),/* 6xxx: IRQ coalescing */
+   GPIO_INT= (1  22),
+   SELF_INT= (1  23),
+   TWSI_INT= (1  24),
+   HC_MAIN_RSVD= (0x7f  25), /* bits 31-25 */
+   HC_MAIN_MASKED_IRQS = (TRAN_LO_DONE | TRAN_HI_DONE | 
+ 

Re: [PATCH 2.6.13] libata: Marvell SATA support (PIO mode)

[Brett Russ]

Brett Russ wrote:

This is my libata compatible low level driver for the Marvell SATA
family.  Currently it successfully runs in PIO mode on a 6081 chip.
EDMA support is in the works and should be done shortly.  Review,
testing (especially on other flavors of Marvell), comments welcome.


Note that this patch depends on the PCI INTx patch I submitted earlier:

http://lkml.org/lkml/2005/8/15/165

Sorry for the delayed notice,
BR
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/