Fajun Chen wrote: > On 3/14/07, Jeff Garzik <jeff@xxxxxxxxxx> wrote: > >> Fajun Chen wrote: >> > Since primary channel and secondary channel share the same IRQ, the >> > ISR could be called to service one or both channels. So I would think >> > it's normal to see "irq trap" traces when both channels are in IO >> > operation, correct? >> >> The irq trap code only occurs after a certain number of unhandled >> interrupts. >> > > If an interrupt fires for IDE1 while IDE0 is busy handling commands, > the irq trap code will count one unhandled interrupts on IDE0 but the > interrupt was not targeted for IDE0 to start with. So this irq trap > code if enabled could generate false alarms even in a perfert working > system and ata_irq_ack() function should not be called based on false > alarm. Please correct me if I misunderstand the intention of the > code. > >> >> > I have another question in regard to ata_host_intr() function in >> > libata-core.c. For PIO read/write, the status of interrupt pin was not >> > checked before moving the host state machine. Sil680 spec. recommend >> > checking IDE channel interupt (bit 11 in the IDEx Task File Timing and >> > Config + Status register) though. Could someone explain why interrupt >> > status does not need to be checked for PIO? >> >> Reading the Status register (as opposed to AltStatus) should clear the >> interrupt condition, on standard hardware. >> > > Could this piece of code handle the sequence below well? > 1. A interrupt fires for IDE1 to indicate command finish > 2. At the same time, IDE0 just started PIO read and its status > register has not been updated to busy. > 3. As part of the interrupt handling, ata_host_intr() will be called > for IDE0 as well. Since this code doesn't check interrupt validity on > IDE0 and count on status register to make decision, it will be misled > to read data register which has not been populated by the target > device yet. The host->lock is acquired when a command is being issued to the device. After writing the command register, libata reads Alt Status and waits for a short period of time (ndelay(400)) to ensure that the device is BSY before releasing the host lock. (Please see ata_exec_command().) So, the above scenario won't happen, unless the device is faulty and doesn't set BSY after 400+ ns. Even under such situation, libata won't read the data register blindly as worried. It will be detected as HSM violation and EH will be activated to handle such situation. -- albert - 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
