Hello, I haven't followed the trace but, > > __ata_port_freeze: ata4 port frozen > > ata_port_schedule_eh: port EH scheduled > > ata_eh_thaw_port: ata4 port thawed > > ata_std_postreset: ENTER > > ata4: SATA link down (SStatus 0 SControl 310) > > ata_std_postreset: EXIT > > ata_eh_revalidate_and_attach: ENTER > > ata_eh_revalidate_and_attach: EXIT rc=-5 > > ata4.00: disabled > > ata_eh_revalidate_and_attach: ENTER > > ata_eh_recover: EXIT, rc=0 > > ata4: EH complete > > ata_scsi_error: EXIT > > ata_scsi_hotplug: ENTER > > ata4.00: detaching (SCSI 3:0:0:0) > > ata_scsi_hotplug: EXIT > > Okay, so the ata_eh_thaw_port has raced (and won) against whatever was in the > process of masking off the irq (the __ata_port_freeze?), which then completes > leaving libata/sata_mv thinking the port is thawed while no further irqs get > generated. > > Could ata_port_freeze or __ata_port_freeze (which don't claim the ap's lock) > have been invoked and then slept while ata_eh_thaw_port runs? ata4 is reporting link down and the device is detached and port disabled afterwards. Doesn't seem to have much to do with freezing/thawing? -- tejun -- 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
