--- malahal@xxxxxxxxxx wrote: > I see a PORTE_BYTES_DMAED event, followed by a PHYE_LOSS_OF_SIGNAL event > and then followed by a PORTE_BYTES_DMAED event on the same phy. The code > seems to just drop the last event because of the not yet processed first > event. So, it just processes the first two events in that order. In > other words, the link doesn't get used at all! Hi Malahal, This is of course wrong and the original SAS Stack as written by me doesn't process this in the way you outlined above, and doesn't lose *any* events. In the above example, the device is _properly discovered_. You should hold Bottomley and LTC directly responsible for this. Not "someone" or "the community". Here are their patches directy responsible for this: Bottomley: http://marc.theaimsgroup.com/?l=linux-scsi&m=114218113500117&w=2 Bruemmer: http://marc.theaimsgroup.com/?l=linux-scsi&m=114235935625301&w=2 Bruemmer: http://marc.theaimsgroup.com/?l=linux-scsi&m=114721079722569&w=2 > Of course, I get timeouts because of Vitesse/AIC94xx combination while > doing discovery. :-( Don't blame the hardware. Software should be robust enough to handle the worst cases, in fact any case. > Maybe, this is what Luben is talking about when he said, > "Priority Queue Without Duplication Implementation"? Yes. Good luck Malahal! Luben - 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
