On Tue, 2007-10-23 at 17:08 +0900, Tejun Heo wrote:
> Jeff Garzik wrote:
> > Alan Cox wrote:
> >>> 2) Once we identified, over time, the set of drives affected by this
> >>> 3112 quirk (aka drives that didn't fully comply to SATA spec), the
> >>> debugging of corruption cases largely shifted to the
Hello Tejun,
On Tuesday 23 October 2007 10:08:01 Tejun Heo wrote:
> Jeff Garzik wrote:
> > Alan Cox wrote:
> >>> 2) Once we identified, over time, the set of drives affected by this
> >>> 3112 quirk (aka drives that didn't fully comply to SATA spec), the
> >>> debugging of corruption cases largely
Jeff Garzik wrote:
> Alan Cox wrote:
>>> 2) Once we identified, over time, the set of drives affected by this
>>> 3112 quirk (aka drives that didn't fully comply to SATA spec), the
>>> debugging of corruption cases largely shifted to the standard
>>> routine: update the BIOS, replace the
>>> cables
On Friday 12 October 2007 23:08:21 Jeff Garzik wrote:
> Bernd Schubert wrote:
> > a) 2.6.23 + sil-patch I posted, this is on a customer system (though my
> > former group), I wouldn't like to use -mm there.
> >
> > b) .config is attached
> >
> > c) attached
> >
> > d) attached (don't get irritaded
Bernd Schubert wrote:
a) 2.6.23 + sil-patch I posted, this is on a customer system (though my former
group), I wouldn't like to use -mm there.
b) .config is attached
c) attached
d) attached (don't get irritaded by those machine check events, thats "GART
TLB errorr", harmless warnings, just n
On Thursday 11 October 2007 17:04:45 Jeff Garzik wrote:
> Bernd Schubert wrote:
> > On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote:
> >> 1) Just about the only valid optimization is to ensure that only the
> >> write path must be limited to small chunks, not both read- and
> >> write-paths.
Bernd Schubert wrote:
On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote:
1) Just about the only valid optimization is to ensure that only the
write path must be limited to small chunks, not both read- and
write-paths. Tejun had a patch to do this a long time ago, but it's an
open question
Alan Cox wrote:
The problem is that the 3112 generates Data FIS's of a size other than a
multiple of 512 bytes. Spec-legal, but exposed firmware bugs in many
early SATA drives. Early Seagate hard drives choked when the formula
(sector%15)==1 was satisfied (or something along those lines).
A
> The problem is that the 3112 generates Data FIS's of a size other than a
> multiple of 512 bytes. Spec-legal, but exposed firmware bugs in many
> early SATA drives. Early Seagate hard drives choked when the formula
> (sector%15)==1 was satisfied (or something along those lines).
And the 311
On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote:
> 1) Just about the only valid optimization is to ensure that only the
> write path must be limited to small chunks, not both read- and
> write-paths. Tejun had a patch to do this a long time ago, but it's an
> open question whether the large
Alan Cox wrote:
-static void ata_fill_sg(struct ata_queued_cmd *qc)
+void ata_fill_sg(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
struct scatterlist *sg;
@@ -4217,10 +4217,15 @@ int ata_check_atapi_dma(struct ata_queue
*/
void ata_qc_prep(struct ata_queued_cmd *
> -static void ata_fill_sg(struct ata_queued_cmd *qc)
> +void ata_fill_sg(struct ata_queued_cmd *qc)
> {
> struct ata_port *ap = qc->ap;
> struct scatterlist *sg;
> @@ -4217,10 +4217,15 @@ int ata_check_atapi_dma(struct ata_queue
> */
> void ata_qc_prep(struct ata_queued_cmd *qc)
>
This is based on a patch from Jeff from 2004, but backported to 2.6.23 and
furthermore, it will use the 7.5kiB/512B splitoff for blacklisted drives
only.
Jeff, why did you replace ATA_SHT_USE_CLUSTERING and ATA_DMA_BOUNDARY?
drivers/ata/libata-core.c |9 -
drivers/ata/sata_sil.c|
13 matches
Mail list logo
