Tejun Heo <tj <at> kernel.org> writes: > > Hello, > > On Sat, Jul 21, 2012 at 02:15:56PM +0200, Matthias Prager wrote: > > Now I'm not sure this isn't taping over another bug. Which leads me to > > my question: What is the correct behavior? > > > > #1 Issuing a separate spin-up command (START UNIT?) prior to sending i/o > > by setting allow_restart=1 for sata disks on sas controllers > > > > or > > > > #2 Teaching the sas drivers they do not need spin-up commands and can > > simply start issuing i/o to sata disks > > I haven't consulted SAT but it seems like a bug in SAS driver or > firmware. If it's a driver bug, we better fix it there. If a > firmware bug, working around those is one of major roles of drivers, > so I think setting allow_restart is fine. > > Thanks. > If this is a driver or firmware bug, then why would commit 85ef06d1d252f6a2e73b678591ab71caad4667bb cause this to happen? What is the interaction between this issue and this commit which just flushes events?
Also this issue does not happen with mvsas, only with mpt2sas. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
