Yes, I know we shouldn't do this, but at the current
time, this seems to fix DMA READ/WRITE timeout
problems. This also may fix the sata_nv driver as
well, but this seems indicate that there is a lowlevel
problem with the SATA subsystem.
Signed-off-by: Shawn Starr <[email protected]>
--- sata_sil.c.old 2005-05-24 12:19:20.312197269
-0400
+++ sata_sil.c 2005-05-11 14:05:26.000000000 -0400
@@ -93,6 +93,7 @@ struct sil_drivelist {
{ "ST380011ASL", SIL_QUIRK_MOD15WRITE
},
{ "ST3120022ASL", SIL_QUIRK_MOD15WRITE
},
{ "ST3160021ASL", SIL_QUIRK_MOD15WRITE
},
+ { "Maxtor 6Y080M0", SIL_QUIRK_MOD15WRITE
},
{ "Maxtor 4D060H3", SIL_QUIRK_UDMA5MAX },
{ }
};
I don't believe that drive is vulnerable to the traditionally
described SI issue, as it's based on Marvell bridge IP. If that
drive was vulnerable, so would be the drives of more than one other
large vendor. I would bet something else is actually the root cause,
and by using smaller transfers or something you're just hiding the
race condition, not fixing a root cause.
(obviously i'd love to see a bus trace of the hang in action, but not
everyone can swap their cars for bus analyzers...)
--eric
On 5/24/05, Shawn Starr <[email protected]> wrote:
> Yes, I know we shouldn't do this, but at the current
> time, this seems to fix DMA READ/WRITE timeout
> problems. This also may fix the sata_nv driver as
> well, but this seems indicate that there is a lowlevel
> problem with the SATA subsystem.
>
> Signed-off-by: Shawn Starr <[email protected]>
>
> --- sata_sil.c.old 2005-05-24 12:19:20.312197269
> -0400
> +++ sata_sil.c 2005-05-11 14:05:26.000000000 -0400
> @@ -93,6 +93,7 @@ struct sil_drivelist {
> { "ST380011ASL", SIL_QUIRK_MOD15WRITE
> },
> { "ST3120022ASL", SIL_QUIRK_MOD15WRITE
> },
> { "ST3160021ASL", SIL_QUIRK_MOD15WRITE
> },
> + { "Maxtor 6Y080M0", SIL_QUIRK_MOD15WRITE
> },
> { "Maxtor 4D060H3", SIL_QUIRK_UDMA5MAX },
> { }
> };
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Any way i can get you the bus trace? the box Im using is
'disposable' (reinstallable)
On May 27, 2005 00:01, Eric D. Mudama wrote:
> I don't believe that drive is vulnerable to the traditionally
> described SI issue, as it's based on Marvell bridge IP. If that
> drive was vulnerable, so would be the drives of more than one other
> large vendor. I would bet something else is actually the root cause,
> and by using smaller transfers or something you're just hiding the
> race condition, not fixing a root cause.
>
> (obviously i'd love to see a bus trace of the hang in action, but not
> everyone can swap their cars for bus analyzers...)
>
> --eric
>
> On 5/24/05, Shawn Starr <[email protected]> wrote:
> > Yes, I know we shouldn't do this, but at the current
> > time, this seems to fix DMA READ/WRITE timeout
> > problems. This also may fix the sata_nv driver as
> > well, but this seems indicate that there is a lowlevel
> > problem with the SATA subsystem.
> >
> > Signed-off-by: Shawn Starr <[email protected]>
> >
> > --- sata_sil.c.old 2005-05-24 12:19:20.312197269
> > -0400
> > +++ sata_sil.c 2005-05-11 14:05:26.000000000 -0400
> > @@ -93,6 +93,7 @@ struct sil_drivelist {
> > { "ST380011ASL", SIL_QUIRK_MOD15WRITE
> > },
> > { "ST3120022ASL", SIL_QUIRK_MOD15WRITE
> > },
> > { "ST3160021ASL", SIL_QUIRK_MOD15WRITE
> > },
> > + { "Maxtor 6Y080M0", SIL_QUIRK_MOD15WRITE
> > },
> > { "Maxtor 4D060H3", SIL_QUIRK_UDMA5MAX },
> > { }
> > };
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html