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? 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? I'm still troubleshooting the command timeout issue on my test hardware, I will repeat the same test on i386 hardware. In the mean time, I would appreciate any suggestions or known information to isolate the issue. Thanks, Fajun On 3/13/07, Fajun Chen <fajunchen@xxxxxxxxx> wrote:
On 3/13/07, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > above 1.5. Two timers are used to track command timeout in our test > > software. The one in the user space is set to 6 seconds using alarm() > > call while the one in the kernel (scsi timer) is set to 5 seconds. > > These timeout values are probably too low to be realistic, but the > > issue here is not about the timeout itself but to understand why it is > > A lot of drive commands seem to be set up on a seven second worst case > > > always user space timer expired before kernel timer. Since kernel > > timer uses jiffies to track time, does this imply a kernel bug where > > the time interrupts were lost or delay somehow? Do you know any know > > problems related to command timeout in PATA Sil680? > > Alarm() is also handled by the same jiffies logic, so I suspect a bug in > your test environment ? > > I enabled ata_irq_trap and did the same test again. The kernel timer caught the timeout (10 seconds) this time along with the irq trap traces below. What's the cause of these idle irqs? [42949560.150000] SCSI device sdb: drive cache: write back [ 85.570000] ata1: irq trap [ 85.820000] ata2: irq trap [ 92.120000] abnormal status 0xD0 [ 92.120000] ata1: irq trap [ 92.920000] ata2: irq trap [ 98.750000] ata1: irq trap [ 100.260000] abnormal status 0xD0 [ 100.260000] ata2: irq trap [ 105.540000] ata1: irq trap [ 108.050000] ata1: irq trap [ 110.620000] ata1: irq trap [ 113.130000] ata1: irq trap [ 115.530000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen [ 115.530000] ata1.00: (BMDMA stat 0x0) [ 115.530000] ata1.00: tag 0 cmd 0xc8 Emask 0x4 stat 0x40 err 0x0 (timeout) [ 115.530000] ata1: soft resetting port [ 115.570000] ata1.00: configured for UDMA/100 [ 115.570000] sg_cmd_done: sg0, pack_id=2706, res=0x8000002, dur=10040 ms [ 115.570000] ata1: EH complete [ 115.580000] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) [ 115.580000] sda: Write Protect is off [ 115.580000] sda: Mode Sense: 00 3a 00 00 [ 115.580000] SCSI device sda: drive cache: write back ... 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
