Re: kern/58767: VT6421 is not working

["Andrius V via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/58767; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: bogdan%kde.org@localhost
Subject: Re: kern/58767: VT6421 is not working
Date: Fri, 14 Mar 2025 09:32:47 +0200

 Hi again,
 
 I believe I have rushed with the conclusion this time.
 Aforementioned Linux problem might still exist, but I don't believe
 anymore it was the case here, the explanation of the fix mentions two
 HDDs as a typical setup for it to happen.
 
 You may try the patch below nevertheless:
 https://www.netbsd.org/~andvar/vt6421_poc_pr58767.diff
 
 I thought I have reproduced the issue myself (and I had two drives
 attached, one of which was SATA 3 SSD), but last two days system works
 completely stable, so I again tend to believe hardware factors were at
 play.
 
 It was also a commit made to restore the support for ATA DMA mode
 downgrade a while ago which also may have helped your case. Please try
 the latest kernel from https://nycdn.netbsd.org/.
 
 But I would really recommend to re-check that cables (maybe even try
 another one) and the card itself, power supply are properly attached.
 Like for me, this issue might be intermittent and related to hardware
 problems.
 
 Thank you.
 
 Regards,
 Andrius V
 
 On Wed, Mar 12, 2025 at 4:10=E2=80=AFPM Andrius V via gnats
 <gnats-admin%netbsd.org@localhost> wrote:
 >
 > The following reply was made to PR kern/58767; it has been noted by GNATS=
 .
 >
 > From: Andrius V <vezhlys%gmail.com@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: kern/58767: VT6421 is not working
 > Date: Wed, 12 Mar 2025 16:07:19 +0200
 >
 >  On Tue, Mar 11, 2025 at 6:18=3DE2=3D80=3DAFPM Andrius V <vezhlys@gmail.c=
 om> wrote=3D
 >  :
 >  >
 >  > On Mon, Oct 21, 2024 at 1:46=3DE2=3D80=3DAFPM <bogdan%kde.org@localhost> wrote:
 >  > >
 >  > > [  1924.584579] wd0: autoconfiguration error: excessive DMA errors -=
  4 =3D
 >  in last 30 transfers
 >  > > [  1924.606353] wd0c: error reading fsbn 68 of 68-71 (wd0 bn 68; cn =
 0 t=3D
 >  n 1 sn 5), xfer 40, retry 0
 >  > > [  1924.606353] wd0: (aborted command, interface CRC error)
 >  > > [  1925.754578] wd0: soft error (corrected) xfer 40
 >  > > [  1926.084581] wd0c: error reading fsbn 336 of 336-339 (wd0 bn 336;=
  cn=3D
 >   0 tn 5 sn 21), xfer 40, retry 0
 >  > > [  1926.084581] wd0: (aborted command, interface CRC error)
 >  > > [  1926.614578] wd0: soft error (corrected) xfer 40
 >  > > [...]
 >  > > lots of wd0 errors.
 >  > >
 >  > > >How-To-Repeat:
 >  >
 >  > Hi,
 >  >
 >  > It can be SPARC or SSD specific issue, I am using it relatively
 >  > successfully on the x86/amd64 system.
 >  >
 >  > However, this controller is quite fickle from my experience. I've seen
 >  > quite similar errors because of "bad" SATA cables or maybe power
 >  > connectors.
 >  >
 >  > Of course, if Linux consistently works correctly with the same device,
 >  > likely the problem is elsewhere.
 >
 >
 >  It seems to be specific to the attached device (not arch) and I can
 >  actually reproduce this after prolonged usage or writes with the SSD
 >  drive.
 >
 >  Linux apparently had the same problem, some "magic" fix was applied,
 >  which slows down the disk speed but makes it work stable for those
 >  "incompatible" disks (commits below all related to it):
 >  https://github.com/torvalds/linux/commit/8b27ff4cf6d15964aa2987aeb58db4d=
 fb1=3D
 >  f87a19
 >  https://github.com/torvalds/linux/commit/b475a3b83a7709e16a734ef2b8ead4d=
 50f=3D
 >  885427
 >  https://github.com/torvalds/linux/commit/b1353e4f40f6179ab26a3bb1b2e1fe2=
 9ff=3D
 >  e534f5
 >  https://github.com/torvalds/linux/commit/44a9b494f20b37dc9c9f94577ff98c8=
 56f=3D
 >  594b96
 >
 >  I will try to analyze these commits (or maybe somebody else can?) and
 >  see if it is actually relevant to us and if it can be applied in
 >  NetBSD.
 >
 >  It seems they apply this to VT6420 (meaning likely to VT8237R
 >  integrated controller since it shares pci id afaik). I was using it
 >  for years, but likely with "compatible" drive.
 >  Would need to test same SSD and see if issue reoccurs there too.
 >
 >  Regards,
 >  Andrius V
 >