Alan Cox wrote: > Ar Gwe, 2006-06-30 am 15:09 +0800, ysgrifennodd Albert Lee: > >>If it is the problem of the specific ATAPI device, all controllers >>should be affected, not only VIA. So, strange not seeing the problem on >>Promise. > > > That may be because of the way the chips handle buffering of interrupt > delivery and readahead/writebehind. I have two traces on the ALi > chipsets that look like the delayed response problem. > > > Understood. Thanks for the explanation. Checked Matthieu's log, and yes it does look like early interrupt. Matthieu's Sil680 has no such problem. Also the problem is not reproducible with the same CD-RW drive on my Promise 20275 chip. So, the explanation makes sense. BTW, even for VIA, the early irq problem occur on 'set features - xfer mode' but IDENTIFY works ok. Just curious, does the ALi chip have the same symptom? i.e. Besides the 'set features' command, are there any other commands affected by the early irq problem? Say, any other PIO non-data commands? -- albert (The relevant part from Matthieu's log.) ata_dev_set_xfermode: set features - xfer mode ata4: ata_dev_select: ENTER, ata4: device 1, wait 1 ata_tf_load_pio: feat 0x3 nsect 0x42 lba 0x0 0x0 0x0 ata_tf_load_pio: device 0xB0 ata_exec_command_pio: ata4: cmd 0xEF ata_host_intr: ata4: protocol 1 task_state 3 <=== early irq ata_port_flush_task: ENTER ata_port_flush_task: flush #1 ata4: ata_port_flush_task: flush #2 ata4: ata_port_flush_task: EXIT __ata_port_freeze: ata4 port frozen ata4.01: qc timeout (cmd 0xef) ata_dev_set_xfermode: EXIT, err_mask=4 ata4.01: failed to set xfermode (err_mask=0x4) ata4.01: limiting speed to UDMA/25 ata4: failed to recover some devices, retrying in 5 secs __ata_port_freeze: ata4 port frozen - : 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