Hi, Robert Hancock wrote: > On Thu, Dec 15, 2011 at 10:26 PM, Mark Lord <kernel@xxxxxxxxxxxx> wrote: > > On 11-12-15 01:38 PM, Robert Hancock wrote: > >> On Thu, Dec 15, 2011 at 5:01 AM, Juergen Beisert <jbe@xxxxxxxxxxxxxx> > >> wrote: > > > > .. > > > >>> As far as I understand the problem of this kind of errors is for the > >>> multi sector write case. The framework does not know what sectors > >>> fails, so the question is: does it repeat the whole multi sector > >>> sequence or what else it does? > >> > >> The entire request should get retried. > > > > I'm not so sure that is correct. > > > > The Linux IDE stack will not retry the completed sectors > > (those which were successfully transfered in multiple-sector blocks). > > > > Not sure what libata does here. > > I don't know of any logic in libata that tries to do selective > retries. In many cases we wouldn't know where in the request it failed > in any case. There's no real reason to do this anyway as redoing a bit > of I/O after a device error shouldn't be a big deal. Some info about the real behaviour. I added some code for fault injection into the libata to simulate the error report the CF card does when it is in trouble with its internal flash memory. And at least for the PIO mode case the whole transfer gets repeated in the case of this error: [...] ata_sff_tf_load: feat 0x0 nsect 0x0 lba 0x84 0x8A 0x1 <-- this is the transfer ata_sff_hsm_move HSM_ST_FIRST <-- state machine starts FAULT_INJECTION: forcing a failure <-- fault injection happens ata_sff_hsm_move HSM_ST_ERR <-- state machine enters ERROR detection ata_sff_tf_read: 'ABORT' flag reported <-- simulated error type ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 ata1.00: failed command: WRITE SECTOR(S) ata1.00: cmd 30/00:00:84:8a:01/00:00:00:00:00/e0 tag 0 pio 131072 out res 58/04:b6:ce:8a:01/00:00:00:00:00/e0 Emask 0x3 (HSM violation) ata1.00: status: { DRDY DRQ } ata1.00: error: { ABRT } ata1: soft resetting link ata1.00: configured for PIO1 ata1: EH complete ata_sff_tf_load: feat 0x0 nsect 0x0 lba 0x84 0x8A 0x1 <-- the same transfer again \o/ [...] Now I'm going to check the DMA case. Currently it looks a bit different to me. Regards, Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html