Dear people,
I have one small question regarding the libata drivers and the
interaction with hdparm.
I am presently using PATA/IDE devices only, but some distributions
provide kernels with libata by default (and some defconfigs also use
libata even for IDE devices).
Using the usual IDE drivers, I can use/query various parameters with
hdparm, like, for instance, the -m option, the -c option or even
disabling DMA. With the libata drivers, this is all that I get:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
lutz:~# hdparm /dev/sda
/dev/sda:
IO_support = 0 (default)
readonly = 0 (off)
readahead = 256 (on)
geometry = 48641/255/63, sectors = 781420655, start = 0
lutz:~# hdparm -c 1 /dev/sda
/dev/sda:
setting 32-bit IO_support flag to 1
HDIO_SET_32BIT failed: Invalid argument
IO_support = 0 (default)
lutz:~# hdparm -m 16 /dev/sda
/dev/sda:
setting multcount to 16
HDIO_SET_MULTCOUNT failed: Inappropriate ioctl for device
HDIO_GET_MULTCOUNT failed: Inappropriate ioctl for device
lutz:~#
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Am I doing something incorrectly? I would like at least to understand
what is happening and, if possible, to fine-tune some settings.
If necessary, please let me know and I will provide any further
information that may be needed.
Thanks in advance, Rog?rio Brito.
Rog?rio Brito wrote:
> Dear people,
>
> I have one small question regarding the libata drivers and the
> interaction with hdparm.
>
> I am presently using PATA/IDE devices only, but some distributions
> provide kernels with libata by default (and some defconfigs also use
> libata even for IDE devices).
>
> Using the usual IDE drivers, I can use/query various parameters with
> hdparm, like, for instance, the -m option, the -c option or even
> disabling DMA. With the libata drivers, this is all that I get:
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> lutz:~# hdparm /dev/sda
>
> /dev/sda:
> IO_support = 0 (default)
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 48641/255/63, sectors = 781420655, start = 0
> lutz:~# hdparm -c 1 /dev/sda
>
> /dev/sda:
> setting 32-bit IO_support flag to 1
> HDIO_SET_32BIT failed: Invalid argument
> IO_support = 0 (default)
> lutz:~# hdparm -m 16 /dev/sda
>
> /dev/sda:
> setting multcount to 16
> HDIO_SET_MULTCOUNT failed: Inappropriate ioctl for device
> HDIO_GET_MULTCOUNT failed: Inappropriate ioctl for device
> lutz:~#
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Am I doing something incorrectly? I would like at least to understand
> what is happening and, if possible, to fine-tune some settings.
>
> If necessary, please let me know and I will provide any further
> information that may be needed.
libata doesn't support many of the ioctls used by hdparm to control
these options. The idea is that the user shouldn't have to mess with
them. They were more necessary with old IDE in some cases as it could
sometimes end up with brain-dead settings..
The set 32-bit IO support only recently got added in 2.6.30-rc kernels.
However, it already defaults to enabled on all controllers where it's
supported currently.
Rogério Brito wrote:
> Dear people,
>
> I have one small question regarding the libata drivers and the
> interaction with hdparm.
>
> I am presently using PATA/IDE devices only, but some distributions
> provide kernels with libata by default (and some defconfigs also use
> libata even for IDE devices).
>
> Using the usual IDE drivers, I can use/query various parameters with
> hdparm, like, for instance, the -m option, the -c option or even
> disabling DMA. With the libata drivers, this is all that I get:
..
> Am I doing something incorrectly? I would like at least to understand
> what is happening and, if possible, to fine-tune some settings.
..
Nearly all of the hdparm flags work fine with libata and SATA/PATA drives.
Among the *very few* that do not, are the -m and -d flags. -c will be working
in the newest kernels, but not yet in most distro kernels.
The -d flag is not permitted by libata, as the kernel prefers to completely
dictate DMA / PIO, and it does do a rather good job of it.
The -m flag could be done, and I even have code in hdparm to do it,
but libata is very buggy with multi-sector I/O, so -m is currently is disallowed.
Cheers
Mark Lord wrote:
[]
> Nearly all of the hdparm flags work fine with libata and SATA/PATA drives.
> Among the *very few* that do not, are the -m and -d flags. -c will be
> working
> in the newest kernels, but not yet in most distro kernels.
>
> The -d flag is not permitted by libata, as the kernel prefers to completely
> dictate DMA / PIO, and it does do a rather good job of it.
Well, the kernel does a good job here in *almost* all cases.
The problematic case is when a device has some bad/unreadable
blocks/sectors. When such a place occurs on read, libata
(or whatever it is) performs several retries, each time
using "less aggressive" settings - like reducing UDMA and
PIO mode till the lowest possible PIO/33. And the device
stays in that mode until reboot, even if the problematic
sector has been relocated. So it'd be nice to be able to
reset the mode back in such cases.
/mjt
Michael Tokarev wrote:
> Mark Lord wrote:
> []
>> Nearly all of the hdparm flags work fine with libata and SATA/PATA
>> drives.
>> Among the *very few* that do not, are the -m and -d flags. -c will be
>> working
>> in the newest kernels, but not yet in most distro kernels.
>>
>> The -d flag is not permitted by libata, as the kernel prefers to
>> completely
>> dictate DMA / PIO, and it does do a rather good job of it.
>
> Well, the kernel does a good job here in *almost* all cases.
> The problematic case is when a device has some bad/unreadable
> blocks/sectors. When such a place occurs on read, libata
> (or whatever it is) performs several retries, each time
> using "less aggressive" settings - like reducing UDMA and
> PIO mode till the lowest possible PIO/33. And the device
> stays in that mode until reboot, even if the problematic
> sector has been relocated. So it'd be nice to be able to
> reset the mode back in such cases.
Do you have a log?
libata worries about speed changes for CRC errors and the like, not for
media errors that involve sector relocation.
Jeff
Jeff Garzik wrote:
> Michael Tokarev wrote:
>> Mark Lord wrote:
>> []
>>> Nearly all of the hdparm flags work fine with libata and SATA/PATA
>>> drives.
>>> Among the *very few* that do not, are the -m and -d flags. -c will
>>> be working
>>> in the newest kernels, but not yet in most distro kernels.
>>>
>>> The -d flag is not permitted by libata, as the kernel prefers to
>>> completely
>>> dictate DMA / PIO, and it does do a rather good job of it.
>>
>> Well, the kernel does a good job here in *almost* all cases.
>> The problematic case is when a device has some bad/unreadable
>> blocks/sectors. When such a place occurs on read, libata
>> (or whatever it is) performs several retries, each time
>> using "less aggressive" settings - like reducing UDMA and
>> PIO mode till the lowest possible PIO/33. And the device
>> stays in that mode until reboot, even if the problematic
>> sector has been relocated. So it'd be nice to be able to
>> reset the mode back in such cases.
>
> Do you have a log?
Hmm. Just a week ago I were reading several bad disks - one
dying drive from a laptop with many bad blocks on it and several
scsi drives that were in a server room where an airconditioner
failed and ambient temp were as high as 78C. Ran that off an
rescue cd, without any permanent storage to save logs. It was
quite time-consuming process - I had to use ddrescue to recover
data, and I had to reboot several times to get the (sata) disk
to work in UDMA6 mode again (ddrescue saves state and resumes
from place it were stopped before). So no - I don't have logs
right now even if I saw it very recently.
> libata worries about speed changes for CRC errors and the like, not for
> media errors that involve sector relocation.
Maybe I were not clear enough. The relocation event were triggered
especially *after* failure to read the bad block(s). I tried to
read the bad blocks with ddrescue, during which drive returned
"media error" (in case of scsi drives) and - probably, but i'm
not sure - crc errors in case of sata, and libata (in case of
sata) reduced the mode the drive is working at and retried.
Later on I just wrote something to the problematic place to
trigger relocation and continued, but the drive (now reading
good portions) stays in PIO/33 mode anyway, which is slow and
I had to reboot to speed it up again.
So it seems there's no disagreement - the drive actually returned
something similar to CRC errors, and it has nothing to do with
sector relocation.
What I mean by mentioning relocated sectors is that the drive
stays in "lower" mode after - even if the problematic sector
is fixed already.
But this is not something you encounter 20 times a day, hopefully :)
/mjt
On Apr 19 2009, Mark Lord wrote:
> Rogério Brito wrote:
>> Using the usual IDE drivers, I can use/query various parameters with
>> hdparm, like, for instance, the -m option, the -c option or even
>> disabling DMA. With the libata drivers, this is all that I get:
(...)
>
> Nearly all of the hdparm flags work fine with libata and SATA/PATA
> drives. Among the *very few* that do not, are the -m and -d flags.
Hummm, the -m switch would be very important in the case of a slow ppc
based NAS that I have here.
> -c will be working in the newest kernels, but not yet in most distro
> kernels.
As another person replied, you meant in the 30-rc kernels? I can test
that, but the .29 kernels stopped working with the MTD devices on the
NAS cited above.
With .28 kernels, I can access all the partitions of the MTD devices,
which I can't with kernels .29 (that is, the .29 kernels lost
functionality).
I guess that I will reopen the bugzilla bug-report that I wrote before
and try the newer .30-rc kernels, then. Squeezing performance out of
this little machine is quite important in my case.
> The -d flag is not permitted by libata, as the kernel prefers to
> completely dictate DMA / PIO, and it does do a rather good job of it.
And what about corner cases like the ones that happen sometimes?
> The -m flag could be done, and I even have code in hdparm to do it,
> but libata is very buggy with multi-sector I/O, so -m is currently is
> disallowed.
I would be interested in putting in a new drive in the NAS and testing
your patch to debug things, if that would help with multi-sector I/O
getting fixed with libata.
Thanks,
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
Hi, Jeff.
On Apr 19 2009, Jeff Garzik wrote:
> Michael Tokarev wrote:
>> Well, the kernel does a good job here in *almost* all cases.
>> The problematic case is when a device has some bad/unreadable
>> blocks/sectors. When such a place occurs on read, libata
>> (or whatever it is) performs several retries, each time
>> using "less aggressive" settings - like reducing UDMA and
>> PIO mode till the lowest possible PIO/33. And the device
>> stays in that mode until reboot, even if the problematic
>> sector has been relocated. So it'd be nice to be able to
>> reset the mode back in such cases.
>
> Do you have a log?
I have a log here of libata reducing UDMA speed. I don't know if this is
any hardware problem or not (I think not), but I do see libata
complaining and reducing the speed of the drive.
Would you like it?
Thanks,
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
Rogério Brito wrote:
> Hi, Jeff.
>
> On Apr 19 2009, Jeff Garzik wrote:
>> Michael Tokarev wrote:
>>> Well, the kernel does a good job here in *almost* all cases.
>>> The problematic case is when a device has some bad/unreadable
>>> blocks/sectors. When such a place occurs on read, libata
>>> (or whatever it is) performs several retries, each time
>>> using "less aggressive" settings - like reducing UDMA and
>>> PIO mode till the lowest possible PIO/33. And the device
>>> stays in that mode until reboot, even if the problematic
>>> sector has been relocated. So it'd be nice to be able to
>>> reset the mode back in such cases.
>> Do you have a log?
>
> I have a log here of libata reducing UDMA speed. I don't know if this is
> any hardware problem or not (I think not), but I do see libata
> complaining and reducing the speed of the drive.
Well, it's supposed to reduce speed in several circumstances... just not
Michael's. :)
Jeff
Rogério Brito wrote:
> On Apr 19 2009, Mark Lord wrote:
..
>> The -m flag could be done, and I even have code in hdparm to do it,
>> but libata is very buggy with multi-sector I/O, so -m is currently is
>> disallowed.
>
> I would be interested in putting in a new drive in the NAS and testing
> your patch to debug things, if that would help with multi-sector I/O
> getting fixed with libata.
..
It just needs someone to patch libata to sniff out "SET MULTIPLE" commands
from SG_IO, and perform drive revalidation afterwards. Very similar to
how it currently sniffs "SET FEATURES XFERMODE" commands.
If libata did that, then "hdparm -m" would become safe to use with it.
Cheers
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.
I can post any information that is desired about this machine (but the
dmesg talks a lot about it, of course).
(Yes, this dmesg is from Ubuntu, and, yes, I can use a vanilla kernel
from kernel.org--just let me know if it is necessary to change anything
and I will do just that).
Thanks, Rogério.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
> 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.
Its logging a couple of transmission errors. The CRC is computed by
hardware each end and compared (by hardware).
> 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.
It's tuned down to UDMA33 which looks correct.
If I saw a lot of these I'd suspect something like a controller timing
setup error, but you seem to just have occasional ones in the log which
really does look like genuine CRC errors from electrical noise or similar.
You don't happen to have any amateur radio transmitters or telsa coils in
the room with it ;) ?
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 <[email protected]>
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 <[email protected]>
---
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 <[email protected]>
- * (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);
Hi, Alan. Thanks for your mail.
On Apr 20 2009, Alan Cox wrote:
> > 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.
>
> Its logging a couple of transmission errors. The CRC is computed by
> hardware each end and compared (by hardware).
Right. I don't remember the kernel logging out errors when I was using a
custom kernel and pure Debian userland with the promise IDE controller
on this ASUS K7V motherboard (which has a VIA KT-133 chipset, not a
KT-133A).
I can try to test that again, but now I have installed Ubuntu for my
girlfriend. I have two spare IDE HDs here that I can use for testing
purposes and trash everything. If more testing is desired, please let me
know.
> > 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.
>
> It's tuned down to UDMA33 which looks correct.
Yes, that looks fine, as I only have the 40 ribbon cable.
> If I saw a lot of these I'd suspect something like a controller timing
> setup error, but you seem to just have occasional ones in the log which
> really does look like genuine CRC errors from electrical noise or
> similar.
Hummm, now that you mention it, I will see if the loudspeakers installed
may have any impact on it.
> You don't happen to have any amateur radio transmitters or telsa coils in
> the room with it ;) ?
No, I don't. :-) But I do have an open embedded computer (with its own
IDE HD) at less than 10cm of this desktop and said speakers. I will try
to find any other source of electromagnetic noise.
I can try many things here to try to fix that. I want libata to not have
that experimental warning for IDE devices.
Thanks, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
On Apr 20 2009, Bartlomiej Zolnierkiewicz wrote:
> DISCLAIMER: I'm not handling this bugreport, this is best
> done by pata_pdc202xx_old Maintainer or libata Maintainer.
Right.
> Rogério, if the issue is reproducible you can give this patch a try...
100% reproducible at each and every boot.
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> 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. ]
Untarring the kernel right now. Will report back in a few minutes.
Thanks, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
> Right. I don't remember the kernel logging out errors when I was using a
> custom kernel and pure Debian userland with the promise IDE controller
> on this ASUS K7V motherboard (which has a VIA KT-133 chipset, not a
> KT-133A).
That strongly suggests its a software bug, probably misprogramming the
timing in UDMA33 mode.
> Hummm, now that you mention it, I will see if the loudspeakers installed
> may have any impact on it.
Would take a bit more than that I think
Alan
> DISCLAIMER: I'm not handling this bugreport, this is best
> done by pata_pdc202xx_old Maintainer or libata Maintainer.
Be that as it may thanks - thats well spotted and definitely a bug.
On Apr 20 2009, Alan Cox wrote:
> > DISCLAIMER: I'm not handling this bugreport, this is best
> > done by pata_pdc202xx_old Maintainer or libata Maintainer.
>
> Be that as it may thanks - thats well spotted and definitely a bug.
Ok, I patched the 30-rc2 tarball. It is taking a looong time to compile
(even with very few components selected).
But I will report how things go "in a few moments" (for some values of
"few moments"). :-)
Thanks for all the attention. You guys rock.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
Hi Alan, Bart and Co.
On Apr 20 2009, Alan Cox wrote:
> > DISCLAIMER: I'm not handling this bugreport, this is best
> > done by pata_pdc202xx_old Maintainer or libata Maintainer.
>
> Be that as it may thanks - thats well spotted and definitely a bug.
Well, I just compiled the kernel both with libata and with the usual IDE
drivers.
Unfortunately, it seems that Bart's patch isn't enough. OTOH, when I use
the older IDE drive, it seems to work OK, as the attached dmesgs show
(BTW, you may notice that there's something fishy with X, but that's
another story).
Oh, just one observation: I tried to compile a 2.6.30-rc2 kernel, but I
only got errors during the compilation. This is why I used a 2.6.29
kernel.
Actually, I also had a compilation problem with the 2.6.30-rc2 kernel on
another box running x86_64. I can post them separately if needed.
Thanks for your valuable help so far, Rogério Brito.
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
On Tuesday 21 April 2009 07:32:58 Rog?rio Brito wrote:
> Hi Alan, Bart and Co.
>
> On Apr 20 2009, Alan Cox wrote:
> > > DISCLAIMER: I'm not handling this bugreport, this is best
> > > done by pata_pdc202xx_old Maintainer or libata Maintainer.
> >
> > Be that as it may thanks - thats well spotted and definitely a bug.
>
> Well, I just compiled the kernel both with libata and with the usual IDE
> drivers.
>
> Unfortunately, it seems that Bart's patch isn't enough. OTOH, when I use
> the older IDE drive, it seems to work OK, as the attached dmesgs show
> (BTW, you may notice that there's something fishy with X, but that's
> another story).
Incremental patch (a certain theory to verify).
---
drivers/ata/pata_pdc202xx_old.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: b/drivers/ata/pata_pdc202xx_old.c
===================================================================
--- a/drivers/ata/pata_pdc202xx_old.c
+++ b/drivers/ata/pata_pdc202xx_old.c
@@ -163,9 +163,11 @@ static void pdc2026x_bmdma_start(struct
else
iowrite8(ioread8(clock) & ~sel66, clock);
+ /* FIXME: this thrashes internal UDMA timings previously set by
+ controller on SET FEATURES - XFER MODE command "snooping" */
/* The DMA clocks may have been trashed by a reset. FIXME: make conditional
and move to qc_issue ? */
- pdc202xx_set_dmamode(ap, qc->dev);
+ /* pdc202xx_set_dmamode(ap, qc->dev); */
/* Cases the state machine will not complete correctly without help */
if ((tf->flags & ATA_TFLAG_LBA48) || tf->protocol == ATAPI_PROT_DMA) {
Hi, Bart, Alan.
On Apr 21 2009, Bartlomiej Zolnierkiewicz wrote:
> Incremental patch (a certain theory to verify).
(...)
> + /* FIXME: this thrashes internal UDMA timings previously set by
> + controller on SET FEATURES - XFER MODE command "snooping" */
> /* The DMA clocks may have been trashed by a reset. FIXME: make conditional
> and move to qc_issue ? */
> - pdc202xx_set_dmamode(ap, qc->dev);
> + /* pdc202xx_set_dmamode(ap, qc->dev); */
This didn't work. I still get those same messages. If you want, I can try
compiling the 2.6.30-rc3 kernel that was released now (as I mentioned
before, I was using 2.6.29).
I can test whatever you want me to.
Thanks,
--
Rog?rio Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
On Thursday 23 April 2009 07:56:19 Rog?rio Brito wrote:
> Hi, Bart, Alan.
>
> On Apr 21 2009, Bartlomiej Zolnierkiewicz wrote:
> > Incremental patch (a certain theory to verify).
> (...)
> > + /* FIXME: this thrashes internal UDMA timings previously set by
> > + controller on SET FEATURES - XFER MODE command "snooping" */
> > /* The DMA clocks may have been trashed by a reset. FIXME: make conditional
> > and move to qc_issue ? */
> > - pdc202xx_set_dmamode(ap, qc->dev);
> > + /* pdc202xx_set_dmamode(ap, qc->dev); */
>
> This didn't work. I still get those same messages. If you want, I can try
> compiling the 2.6.30-rc3 kernel that was released now (as I mentioned
> before, I was using 2.6.29).
I think that testing -rc3 won't hurt but don't get your hopes too high. ;)
> I can test whatever you want me to.
You can try booting with "libata.force=1.00:mwdma2" kernel paramater to
force use of "regular" MWDMA2 transfer mode instead of UDMA ones so we are
sure that the issue is specific to pata_pdc202xx_old + UDMA.
Other than that I'm out of ideas, though the hint that the original driver
works just fine should help driver's maintainer in fixing this regression.
Thanks,
Bart
Hi, Bart, Alan & Co.
On 4/23/09, Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> You can try booting with "libata.force=1.00:mwdma2" kernel paramater to
> force use of "regular" MWDMA2 transfer mode instead of UDMA ones so we are
> sure that the issue is specific to pata_pdc202xx_old + UDMA.
This *did* work. I see no other error messages, while using multword
dma. So I think that this serves for us to rule out some unknown
variables.
> Other than that I'm out of ideas, though the hint that the original driver
> works just fine should help driver's maintainer in fixing this regression.
Well, it worked now. I'm attaching what I see now.
Thanks, Rog?rio Brito.
P.S.: This is still with kernel 2.6.29, since compiling a new kernel
in this computer takes a lot of time.
--
Rog?rio Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org