Hello, Mikael. Mikael Pettersson wrote: > Tejun, what's the functional difference between the original > sata reset method and the one you changed it to? It means that the controller is having trouble updating the TF registers from the first D2H Reg FIS after hardreset and thus requires a follow-up SRST to get the device signature and initial DRDY status right. This is actually quite common among SATA controllers. Some ahci's and sata_sil24 can't do it either. sata_sil is one of the best behaving ones in this regard. It looks like sata_promise needs follow-up SRST after all. I'll put the header and send this patch to Jeff. > > [ 649.991712] ata1: hard resetting link > > [ 650.500230] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > > [ 650.641824] ata1.00: configured for UDMA/133 > > [ 650.642194] ata1: limiting SATA link speed to 1.5 Gbps > > [ 650.642200] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xf t4 > > [ 650.642202] ata1: hotplug_status 0x80 > > [ 650.642252] ata1: hard resetting link > > [ 651.550344] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) > > [ 651.700416] ata1.00: configured for UDMA/133 > > [ 651.700678] ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9 t3 > > [ 651.700681] ata1: hotplug_status 0x80 > > These hotplug_status things worry me. Hard resets trigger > hotplug events, but all recent kernels should disable them > in ->freeze. This used to be the case. > > Either libata isn't freezing the port before the reset, > or ->freeze isn't marking the port properly causing the > interrupt handler to interpret (silent) hotplug status bits > when it shouldn't, or (horrors) ->freeze isn't working any more. libata definitely is calling ->freeze but some controllers seem to ignore IRQ masking during hardreset. Maybe promise falls in this category too? For those controllers, irq handler should be ready for spurious interrupts during reset. If anything needs to be done differently, it can use ATA_PFLAG_RESETTING to tell whether reset is in progress (see ahci.c for example). > Stray hotplug events prolong EH handling sequences and can even > cause port disabling due to EH failures. libata EH should be smart enough to handle this if the PHY event happens during reset and scheduled reset. EH will clear those actions on successful completion of reset but before verifying the connected devices (spurious events are ignored w/o losing actual device presence). Thanks. -- 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
