From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <262d7c11a5d30050cdf45a4a30eab66b@gmx.de>
Date: Sun, 19 May 2013 17:55:48 +0200
From: cinap_lenrek@gmx.de
To: 9fans@9fans.net
In-Reply-To: <13095494dd62b57b68b36d52632bcfb6@kw.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] atagenioretry: nondma
Topicbox-Message-UUID: 59fbaa56-ead8-11e9-9d60-3106f5b1d025

9front uses a (older) variant of the 9atom ide driver.

from arisawas's output, it seems that the write command times out
in atagenio():

		iowait(drive, 30*1000, 0);
		if(!ctlr->done){
			/*
			 * What should the above timeout be? In
			 * standby and sleep modes it could take as
			 * long as 30 seconds for a drive to respond.
			 * Very hard to get out of this cleanly.
			 */
			atadumpstate(drive, r, lba, count);
			ataabort(drive, 1);
			qunlock(ctlr);
			return atagenioretry(drive, r, lba, count);
		}

atagenioretry() will just cause the command to be retried in pio mode
when it previously was failing in dma mode. think this what erik means
with "assumes dma doesnt work". dma is already off so we fail the
request.

i doubt this is missed interrupts. iowait() calls the interrupt handler
itself before giving up. you can even check, as the driver keeps statistics
about missed interrupts in the ctl file.

the drive seems to not complete the command within the timeout.

what i would try is to check if reading the offending sectors produce
i/o errors as well with dd.

where these sectors ever written before? i dd /dev/zero over the whole
drive before initializing filesystems on it. was something similar done
here as well?

could this be a prblem with the drive going into standby mode and then
the next command taking too long to complete because drive is slow to
spin up?

--
cinap