NetBSD-Bugs archive

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

Re: Subject: Re: kern/52126



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."




Home | Main Index | Thread Index | Old Index