NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Subject: Re: kern/52126



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

From: =?UTF-8?B?SmFyb23DrXIgRG9sZcSNZWs=?= <jaromir.dolecek%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost, Michael van Elst <mlelstv%serpens.de@localhost>
Cc: Jaromir Dolecek <jdolecek%netbsd.org@localhost>, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
	Patrick Welche <prlw1%cam.ac.uk@localhost>
Subject: Re: Subject: Re: kern/52126
Date: Sat, 19 Aug 2017 21:31:26 +0200

 --001a1148f876afc9050557204acf
 Content-Type: text/plain; charset="UTF-8"
 
 I've changed the sleep/delay code on jdolecek-ncq branch so that the sleep
 is always at least 1 tick. You might give it a try - if that is really the
 only issue, this might help. Increasing the timeouts however did not fix
 the issue for me on 60xx, at least not with the brief testing I did so far.
 
 I've experienced the EDMA timeout on 6048 just while booting or some light
 use, while it almost never happened on 70xxx. It usually happened when the
 chip was wedged for other reasons, like unrecovered NCQ error or some such.
 So I think that there might be something else we do wrong for 60xx, and the
 EDMA disable problem is just consequence.
 
 60xx was however not really focus of the NCQ branch, and I won't do
 anything further for it on the branch. My focus is now on completing my
 branch and merge, and some RL stuff. Then I may start looking on the 60xx
 issue, but that won't be before late September.
 
 Jaromir
 
 2017-08-19 10:45 GMT+02:00 Michael van Elst <mlelstv%serpens.de@localhost>:
 
 > The following reply was made to PR kern/52126; it has been noted by GNATS.
 >
 > From: mlelstv%serpens.de@localhost (Michael van Elst)
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: Subject: Re: kern/52126
 > Date: Sat, 19 Aug 2017 08:41:28 -0000 (UTC)
 >
 >  matt%mattbrocklehurst.co.uk@localhost (Matt Brocklehurst) writes:
 >
 >  > I've tried a mixture of different drives, they all give the "unable to
 > stop
 >  > EDMA" error on boot.
 >
 >  The corresponding code in Linux does almost the same. Differences are:
 >
 >  - it not only waits for the IDLE flag, but also for the CACHEEMPTY flag
 >    before disabling DMA.
 >  - it waits up to 15ms (instead of 10ms) before disabling DMA
 >  - it disables DMA even when the idle timeout is reached.
 >  - it waits up to 100ms (instead of the remainder of 10ms) after disabling
 > DMA
 >    before giving up.
 >
 >  On the other hand, our timeouts are very imprecise as the driver tries to
 >  sleep for 1 millisecond, which is impossible with HZ=100. A sleep for
 >  mstohz(1) will sleep 0 ticks, i.e. it will only yield the CPU to other
 >  LWPs. It is likely that the required delays are not met.
 >
 >
 >  --
 >  --
 >                                  Michael van Elst
 >  Internet: mlelstv%serpens.de@localhost
 >                                  "A potential Snark may lurk in every
 > tree."
 >
 >
 
 --001a1148f876afc9050557204acf
 Content-Type: text/html; charset="UTF-8"
 Content-Transfer-Encoding: quoted-printable
 
 <div dir=3D"ltr">I&#39;ve changed the sleep/delay code on jdolecek-ncq bran=
 ch so that the sleep is always at least 1 tick. You might give it a try - i=
 f that is really the only issue, this might help. Increasing the timeouts h=
 owever did not fix the issue for me on 60xx, at least not with the brief te=
 sting I did so far.<div><br></div><div>I&#39;ve experienced the EDMA timeou=
 t on 6048 just while booting or some light use, while it almost never happe=
 ned on 70xxx. It usually happened when the chip was wedged for other reason=
 s, like unrecovered NCQ error or some such. So I think that there might be =
 something else we do wrong for 60xx, and the EDMA disable problem is just c=
 onsequence.=C2=A0<br></div><div><br></div><div>60xx was however not really =
 focus of the NCQ branch, and I won&#39;t do anything further for it on the =
 branch. My focus is now on completing my branch and merge, and some RL stuf=
 f. Then I may start looking on the 60xx issue, but that won&#39;t be before=
  late September.</div><div><br></div><div>Jaromir<br></div></div><div class=
 =3D"gmail_extra"><br><div class=3D"gmail_quote">2017-08-19 10:45 GMT+02:00 =
 Michael van Elst <span dir=3D"ltr">&lt;<a href=3D"mailto:mlelstv%serpens.de@localhost=
 " target=3D"_blank">mlelstv%serpens.de@localhost</a>&gt;</span>:<br><blockquote class=
 =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
 ing-left:1ex"><span class=3D"">The following reply was made to PR kern/5212=
 6; it has been noted by GNATS.<br>
 <br>
 </span>From: <a href=3D"mailto:mlelstv%serpens.de@localhost";>mlelstv%serpens.de@localhost</a> (=
 Michael van Elst)<br>
 To: <a href=3D"mailto:gnats-bugs%netbsd.org@localhost";>gnats-bugs%netbsd.org@localhost</a><br>
 Cc:<br>
 Subject: Re: Subject: Re: kern/52126<br>
 Date: Sat, 19 Aug 2017 08:41:28 -0000 (UTC)<br>
 <span class=3D""><br>
 =C2=A0<a href=3D"mailto:matt%mattbrocklehurst.co.uk@localhost";>matt@mattbrocklehurst.=
 co.uk</a> (Matt Brocklehurst) writes:<br>
 <br>
 =C2=A0&gt; I&#39;ve tried a mixture of different drives, they all give the =
 &quot;unable to stop<br>
 =C2=A0&gt; EDMA&quot; error on boot.<br>
 <br>
 </span>=C2=A0The corresponding code in Linux does almost the same. Differen=
 ces are:<br>
 <br>
 =C2=A0- it not only waits for the IDLE flag, but also for the CACHEEMPTY fl=
 ag<br>
 =C2=A0 =C2=A0before disabling DMA.<br>
 =C2=A0- it waits up to 15ms (instead of 10ms) before disabling DMA<br>
 =C2=A0- it disables DMA even when the idle timeout is reached.<br>
 =C2=A0- it waits up to 100ms (instead of the remainder of 10ms) after disab=
 ling DMA<br>
 =C2=A0 =C2=A0before giving up.<br>
 <br>
 =C2=A0On the other hand, our timeouts are very imprecise as the driver trie=
 s to<br>
 =C2=A0sleep for 1 millisecond, which is impossible with HZ=3D100. A sleep f=
 or<br>
 =C2=A0mstohz(1) will sleep 0 ticks, i.e. it will only yield the CPU to othe=
 r<br>
 =C2=A0LWPs. It is likely that the required delays are not met.<br>
 <br>
 <br>
 =C2=A0--<br>
 =C2=A0--<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
 =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Michael van Elst<br>
 =C2=A0Internet: <a href=3D"mailto:mlelstv%serpens.de@localhost";>mlelstv%serpens.de@localhost</a=
 ><br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
 =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;A potential Snark may lu=
 rk in every tree.&quot;<br>
 <br>
 </blockquote></div><br></div>
 
 --001a1148f876afc9050557204acf--
 


Home | Main Index | Thread Index | Old Index