Mikael Pettersson wrote:
Unfortunately the name pdc_qc_prep() is already taken
[it switches on qc-tf.protocol], so that leaves either pdc_fill_sg()
[slightly imprecise as you noted], or uglies like __pdc_qc_prep(),
pdc_qc_prep2(), or pdc_qc_prep_and_fill_sg() as names for the new
procedure. I
Jeff Garzik wrote:
Mikael Pettersson wrote:
@@ -530,7 +608,7 @@ static void pdc_qc_prep(struct ata_queue
switch (qc-tf.protocol) {
case ATA_PROT_DMA:
-ata_qc_prep(qc);
+pdc_fill_sg(qc);
/* fall through */
case ATA_PROT_NODATA:
@@ -546,11 +624,11
Jeff Garzik wrote:
BTW, looking at the Promise code I see
cam_con.h:
/* for ASIC bug, limit the last element of SG byteCount must 32
Dword */
#define SG_COUNT_ASIC_BUG 32
//#define SG_COUNT_ASIC_BUG 128
and in the code itself
/* check PRD table, last element = (32
Hello.
There appears to be a hardware bug in that it chokes on scatterlist
if the last item is larger than 164 bytes.
The patch that follows fixes my problem on 2.6.22.
I can't think of a way to avoid second pass over scatterlist without
duplicating code (ata_qc_prep() and ata_fill_sg() from
Alexander Sabourenkov wrote:
Hello.
There appears to be a hardware bug in that it chokes on scatterlist
if the last item is larger than 164 bytes.
The patch that follows fixes my problem on 2.6.22.
I can't think of a way to avoid second pass over scatterlist without
duplicating code
MisterE wrote:
Can you confirm that this only will happen when running at 300Gb mode?
I confirm that without this patch errors happen on both 150 and 300
modes, on both jumpered and unjumpered drives. It seems that errors are
highly hardware/configuration dependent.
I'm willing to try your
Hello.
Once again,
There appears to be a hardware bug in that it chokes on scatterlist
if the last item is larger than 164 bytes. This was discovered by
reading the code of vendor-supplied driver.
The patch that follows fixes my problem on 2.6.22.
I can't think of a way to avoid second pass
Hello.
Interesting, but can you please give more background information?
I.e., how did you determine the existence of this bug?
I was experiencing read/write errors, with data corruption.
Dmesgs and lspcis are at http://lxnt.info/linux/
I downloaded driver from the promise.com, put up 2.6.11
Alan Cox wrote:
I can't think of a way to avoid second pass over scatterlist without
duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
This appears to be incomplete:
[...]
What guarantees you have enough PRD entries to do this without changing
the limit in the
Alexander Sabourenkov wrote:
Alan Cox wrote:
I can't think of a way to avoid second pass over scatterlist without
duplicating code (ata_qc_prep() and ata_fill_sg() from libata-core.c).
This appears to be incomplete:
[...]
What guarantees you have enough PRD entries to do this without
Hello.
Tejun Heo wrote:
Does the attached patch help?
It does somehow force 1.5GB/s mode, and it does change the pattern of
'configured for UDMAxxx' messages that come along with errors, and it
causes the following error:
ata3: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t4
ata3:
Hello.
So, my bet for your second report is your hardware went through
something similar as above.
Thanks for the insight. Let's dismiss it then.
Back to the TX4, I tried libata-dev.git cloned at about 20:00 UTC 19.10,
no perceived difference - parallel read from two drives causes a lot
Hello.
I have done some quick tests with 2.6.23/amd64 and unfortunately, the
very same problem persists.
By the way, 8 in (port_status 0x2008) stands for
PDC_OVERRUN_ERR = (1 19), /* S/G byte count larger
than HD requires */
Does by any chance 'S/G' here somehow relate to
MisterE wrote:
Hello,
Alexander, does these problems with the Promise SATA300 TX4 happen to
everyone?
Most probably not, as I think it would have been fixed much faster then.
I was waiting for a) release of 2.6.23, and b) me completing the move to
another flat
to retest all the latest
Mikael Pettersson wrote:
I'm thinking of replacing both 3512 controllers with a Promise SATA300
TX4. Do you know if there are problems with this device?
(please don't top-post)
There are no known data-corruption issues with Promise SATA cards.
However, some of them, especially the 2nd
Clemens Koller wrote:
Okay, I have no idea about any bugs there.
You have several options: Find a 100% working vanilla kernel for your
problem (minimal configuration, skip i.e. the sound stuff, ...).
And then git bisect with a known bad kernel.
I'm afraid there is no 100% working kernel.
Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10
320G, jumper-limited to SATA150.
Kernel : 2.6.22.9 amd64
Problem:
Heavy load causes errors and triggers oops.
History:
Problems were first encountered on kernel 2.6.19, both i686 (old
system) and amd64 (gentoo installation
Clemens Koller wrote:
Alexander Sabourenkov schrieb:
Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10
320G, jumper-limited to SATA150.
Kernel : 2.6.22.9 amd64
Problem:
Heavy load causes errors and triggers oops.
Have you checked your memory already (memtest86
Have you checked your memory already (memtest86)?
[...]
Again... sounds like bad memory to me.
Nightly memtest86 run : 11 hours, 23 passes, 0 errors.
--
./lxnt
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
19 matches
Mail list logo
