> > On Tue, Dec 27, 2011 at 1:21 AM, Jack Wang <jack_wang@xxxxxxxxx> wrote: > >> > >> In the direct-attached case this routine returns the phy on which this > >> device was first discovered. Which is broken if we want to support > >> wide-targets, as this phy reference can become stale even though the > >> port is still active. > >> > >> In the expander-attached case this routine tries to lookup the phy by > >> scanning the attached sas addresses of the parent expander, and BUG_ONs > >> if it can't find it. However since eh and the libsas workqueue run > >> independently we can still be attempting device recovery via eh after > >> libsas has recorded the device as detached. This is even easier to hit > >> now that eh is blocked while device domain rediscovery takes place, and > >> that libata is fed more timed out commands increasing the chances that > >> it will try to recover the ata device. > >> > >> Arrange for dev->phy to always point to a last known good phy, it may be > >> stale after the port is torn down, but it will catch up for wide port > >> reconfigurations, and never be NULL. > >> > >> Q: How is pm8001_I_T_nexus_reset getting away with not performing reset > >> on direct attached sata devices? > >> > > [Jack Wang] > > We found reset may lead to some SATA disks can not be found sometime, in > > fact no only for direct attached sata devices. > > > > I wonder why we always reset the sata device when probe, for pm8001 direct > > attached sata firmware will report Initial SATA FIS when phy ready. > > > > We need to get the drive to a known state. Do these problems still > happen in your tests with the "wait for ready" checking? That's > supposed to allow enough time for the signature fis to be transmitted. > > I'll take a closer look at your libsas fix, because I believe we are > still seeing failures to rediscover all attached devices even with > these patches. > > -- > Dan [Jack Wang] I only test sata behind expander, will add lldd_ata_check_ready to have a test later. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
