linux-kernel - Re: Quick question about libata and hdparm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200904202231.25670.bzolnier@gmail.com>
Date:	Mon, 20 Apr 2009 22:31:25 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Rogério Brito <rbrito@....usp.br>
Cc:	Jeff Garzik <jeff@...zik.org>, Michael Tokarev <mjt@....msk.ru>,
	Mark Lord <lkml@....ca>, linux-kernel@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: Quick question about libata and hdparm

On Monday 20 April 2009 19:35:27 Rogério Brito wrote:
> Hi, Jeff.
> 
> On Apr 19 2009, Jeff Garzik wrote:
> > Well, it's supposed to reduce speed in several circumstances... just
> > not Michael's.  :)
> 
> Well, I'll take that as a yes. :-)
> 
> Can you comment on the dmesg log attached? I'd like to, at least,
> understand what is happening, since I'm starting to consider using
> libata with all my computers.
> 
> This computer, in particular, uses an IDE drive with a 40 ribbon cable
> (and, thus, no UDMA/66). The cable is well put (checked two times
> already) and I believe that everything is OK with this cable, since I
> substituted it was already substituting one that gave me the same
> results.

DISCLAIMER: I'm not handling this bugreport, this is best
done by pata_pdc202xx_old Maintainer or libata Maintainer.

Rogério, if the issue is reproducible you can give this patch a try...

From: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Subject: [PATCH] pata_pdc202xx_old: fix UDMA33 handling

The original driver doesn't use 66 MHz clock for UDMA33.

[ The alternative solution would be to adjust UDMA33 timings
  for 66 MHz clock but I think that it is safer to stick with
  old & tested behavior for now. ]

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
---
 drivers/ata/pata_pdc202xx_old.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: b/drivers/ata/pata_pdc202xx_old.c
===================================================================
--- a/drivers/ata/pata_pdc202xx_old.c
+++ b/drivers/ata/pata_pdc202xx_old.c
@@ -2,7 +2,7 @@
  * pata_pdc202xx_old.c 	- Promise PDC202xx PATA for new ATA layer
  *			  (C) 2005 Red Hat Inc
  *			  Alan Cox <alan@...rguk.ukuu.org.uk>
- *			  (C) 2007 Bartlomiej Zolnierkiewicz
+ *			  (C) 2007,2009 Bartlomiej Zolnierkiewicz
  *
  * Based in part on linux/drivers/ide/pci/pdc202xx_old.c
  *
@@ -158,7 +158,7 @@ static void pdc2026x_bmdma_start(struct 
 	u32 len;
 
 	/* Check we keep host level locking here */
-	if (adev->dma_mode >= XFER_UDMA_2)
+	if (adev->dma_mode > XFER_UDMA_2)
 		iowrite8(ioread8(clock) | sel66, clock);
 	else
 		iowrite8(ioread8(clock) & ~sel66, clock);
@@ -212,7 +212,7 @@ static void pdc2026x_bmdma_stop(struct a
 		iowrite8(ioread8(clock) & ~sel66, clock);
 	}
 	/* Flip back to 33Mhz for PIO */
-	if (adev->dma_mode >= XFER_UDMA_2)
+	if (adev->dma_mode > XFER_UDMA_2)
 		iowrite8(ioread8(clock) & ~sel66, clock);
 	ata_bmdma_stop(qc);
 	pdc202xx_set_piomode(ap, adev);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/