On 2/28/08, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > PIO read/writes with wrong direction is not the only failure mode, > > PATA sil680 also failed with disabling IRQ with some unsupported > > commands such as Trusted Send (0x5E) even with perfect TF data. Given > > that some ATA commands are optional, we may have a chance to hit the > > trap even with well programmed code. > > > That sounds very strange - I regularly test PATA controlles with > unsupported commands and see the correct 0x04 abort patterns. > > > > What would take to harden the PATA ISR code such that it fails more gracefully? > > > First thing would be to work out why your system is behaving differently > to the others. What is the trigger here. > For most of unsupported commands, it will be aborted by drive. However, for some unsupported commands, it may not. I suspect these bad commands are the new ones in ATA8 issued to some drives with old firmware. For instance, can you try command 0x5E (Trusted Send PIO data out) with sector count set to 1 and see what happens? The blame is probably on drives which should have aborted these commands. But the reality is that libata will handle variety of drives including the ones with old firmware. So the question here is whether libata PATA code can be more fault tolerate. It seems the weakest link is on PATA PIO since I have not been able to reproduce the IRQ disabling problem on DMA operations. Just my 2 cents. Thanks, Fajun -- 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
