--GakPwvZJvklGIlSn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Sorry about this last minute response, This is for Manuel Bouyer,

Ahh, I've tried three power supplies :)=20

I'm aware of some of the interesting things that happen when power supplies
don't play fair, and I've had some fascinating power supply outages over
the last year, so, believe me, power supply and memory are the first thing
I check.

All my memory I usually check with a memory tester, even though this isn't
entirely accurate when it comes to finding memory problems, the memory in
this machine actually had another installation on it, I updated a system
from 3.0 to 3.1 on this motherboard aswell earlier during the year. I'm
pretty sure it works.

Also, I've tried other memory, other boards, and other power supplies...=20

But, just putting those two lines specified in my other e-mail into the wd.=
c=20
file stops problems from occuring, but, I keep getting error messages=20
anyway, I can live with that though, long as it works.

But, if I can somehow discover a problem in the kernel code, I'd like to do=
 that,
otherwise somebody else may be turned away from NetBSD because their seagate
drives don't work when it is something minor. =20

On Sun, Mar 25, 2007 at 08:04:28PM +0200, William Fletcher wrote:
> Hi guys, I'm on the list and I read it all the time so no cc required.
>=20
> Well, it is working, I rebuilt the parity a few times, and I the=20
> reconstructed RAID twice...=20
>=20
> The error messages still appear, but, everything is working, I'm happy
> with that, as long as my data is safely copying from one disk to the
> other.
>=20
> Should I be concerned about this?
>=20
>=20
> I included this in sys/dev/ata/wd.c with other similar entries.
>=20
>         { "ST3160211A*",
>           WD_QUIRK_FORCE_LBA48 },
>=20
> Could it be the other quirk? The WD_QUIRK_SPLIT_MOD15_WRITE thingums?
> Let me know if I must try this.
>=20
> Thanks in advance.
>=20
> On Sun, Mar 25, 2007 at 04:38:51PM +0200, Manuel Bouyer wrote:
> > On Sun, Mar 25, 2007 at 09:31:32AM -0400, Greg Troxel wrote:
> > >=20
> > > I was reacting to William's error message:
> > >=20
> > >   wd2a: device timeout reading fsbn 268435392 of 268435392-268435519 =
(wd2 bn 268435455; cn 266305 tn 0 sn 15), retrying
> > >   pdcsata0:0:0: lost interrupt type: ata tc_bcount: 65536 tc_skip: 0
> > >=20
> > > That transfer is FFFFFC0 to 1000003F, so it looks like it crosses the
> > > boundary.  Does the code switch to LBA48 for the whole transfer?  Does
> > > it need to be split into a non-LBA48 and a LB48 part?  Perhaps the
> > > drive can't handle such crossings.  I could be off by some power of
> > > two, though.
> >=20
> > Yes, this one cross the LBA48 barrier. But in previous messages he incl=
ued
> > errors with other block numbers ...
> >=20
> > --=20
> > Manuel Bouyer <bouyer@antioche.eu.org>
> >      NetBSD: 26 ans d'experience feront toujours la difference
> > --
>=20
> --=20
> Omina Solutions  | http://omina.co.za | (012) Ph. 664-2480 F. 664-2474=20
>=20



--=20
Omina Solutions  | http://omina.co.za | (012) Ph. 664-2480 F. 664-2474=20


--GakPwvZJvklGIlSn
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (NetBSD)

iD8DBQFGBr0C0o1hk/SHCkoRAl3BAJ9OaWzxa5peD5F27tPM1Vyq3boXtwCeM/rS
Dc7hLBiKZap2T2dldBXjgno=
=2YCE
-----END PGP SIGNATURE-----

--GakPwvZJvklGIlSn--