Yes, the behavior you described is correct. It's mainly because it's hard to know if the SCSI/ATAPI device always couldn't handle big data transfer or just for this single request.
Thanks Feng -----Original Message----- From: Mike Maslenkin [mailto:miha...@parallels.com] Sent: Wednesday, May 21, 2014 15:59 To: edk2-devel@lists.sourceforge.net Cc: Tian, Feng Subject: Re: [edk2] [PATCH 1/1] MdeModulePkg/ScsiDiskDxe: introduce a Pcd for maximum blocks transferred by Read10/Write10 commands Ops! I missed this change. BTW Do I understand correctly and ACTION_RETRY_WITH_BACKOFF_ALGO (or better returned SectorCount value) is not saved anywhere. So, every IO starts from: ScsiDiskRead10, ACTION_NO_ACTION if (not Fail) done then repeat ScsiDiskRead10, ACTION_RETRY_WITH_BACKOFF_ALGO until (SectorCount<<1 || Success) So in case of DVD drive does not support large transfer would it be performance penalty on retries? I.e. if we know that drive does not support large transfer, why are we trying to submit unsupported IO every time? On Wed, 2014-05-21 at 00:23 +0000, Tian, Feng wrote: > HI, Mike > > We (Intel) have had another solution to solve this issue. We use back-off > algorithm to dynamically calculate the transfer length in single transfer > till it succeeds or fails. > > Please use latest ScsiDisk driver to see if it solves your problem. > > Thanks > Feng ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
