plextor and forced unit access

[inphobia]

Heya,
I'm trying to get forced unit access (fua) to work with my plextor drive, but thus far it only seems to work with sptd uninstalled. Without fua my plextor drive tends to cache audio, which makes ripping with exact audio copy (eac) pretty slow. To circumvent this eac added the -usefua commandline switch, for the plextor specific fua command. But, this doesn't work with sptd installed.

To ease testing a bit I used a tool called cache explorer, which is discussed here:
http://club.cdfreaks.com/showthread.php?t=184487

Anyway, it came up with these results:

sptd not installed:
F:\temp\cachex\cachex.exe -i -p g:

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on G is PLEXTOR DVDR PX-760A 1.06

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)
[+] Plextor flush command: accepted
[+] Plextor flush tests: 5/5


sptd 1.43 installed:
F:\temp\cachex\cachex.exe -i -p g:

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on G is PLEXTOR DVDR PX-760A 1.06

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh D8h
[+] Plextor flush command: accepted
[+] Plextor flush tests: 4/5


sptd 1.45 installed:
F:\temp\cachex\cachex.exe -i -p g:

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on G is PLEXTOR DVDR PX-760A 1.06

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh D8h
[+] Plextor flush command: accepted
[+] Plextor flush tests: 4/5


I've got a plextor 760SA (sata version) with firmware 1.06, although I also did the tests with firmware 1.04 as well. I'm running windows xp pro sp2 with all the latest patches. All this on a MSI 945gt speedster a4r mobo with an ICH7R southbridge and achi drivers installed instead of IDE mode.

I also did some brief testing on an asrock 939dual-sata2, which seemed to behave the same. Regretfully that unit is offline for the moment.

Thanks for taking a look.

[Digger]

We checked this tool - its behavior seems depending on driver for controller where CD/DVD-ROM is attached. On standard MS drivers (eg. atapi.sys) it behaves same way as well, even if no SPTD is installed. But on other system with nVidia drivers it behaved indeed as you described (FUA found etc). So seems it is because your controller uses vendor drivers.
If SPTD is installed then all devices respond in a "Microsoft" manner - this is cause of your behaviour with SPTD present.

To make it short: this tool uses SPTI interface in "unreliable" manner: it sends
IOCTL_SCSI_PASS_THROUGH_DIRECT requests without specifying sense info buffer and uses REQUEST SENSE command in case of error. It is not a good way to work with SPTI - it may be ok only if you know device returns no error.
For proper operation on all Windows platforms IOCTL_SCSI_PASS_THROUGH_DIRECT must specify non-zero SenseInfoOffset and SenseInfoLength in SCSI_PASS_THROUGH_DIRECT structure.
Then it should work with all Microsoft and vendor drivers.

In your case (when SPTD is not installed) this tool works in fact incorrectly - device reports error on some commands but it ignores them due to sense buffer missing and vendor driver still reports success - this is bug in vendor driver. For example, Plextor-760 does not support 0xD4 command at all and what this tool reports to you is mere bullshit.

With SPTD present it simply works how it should:

a) without sense buffer standard Microsoft driver (same as SPTD) will always report error and does not return any info if device command failed. Application then uses REQUEST SENSE to get more detailed error (which is bad anyway because device status may be already reset by other command arriving "inbetween").

b) with sense buffer (which is CORRECT way to use SPTI) driver will fill it immediately with error data and return success to application which then must analyze ScsiStatus and SenseInfoLength fields of SCSI_PASS_THROUGH_DIRECT structure.

This is how SPTI interface was designed.

If you want this fixed mail its author with reference to this thread. He may mail us if he needs more detailed explanation.

[inphobia]

Thank you for your prompt update. I'll see if I can contact the author of the program and present him with these findings.

Regretfully that still leaves me to find a way to get eac to report my drive as not caching audio data. Perhaps their detection routines are bogus as well, perhaps there's just nothing I can do about it. It seems I have a lot more testing to do.

And for the record. I do indeed use intel's ahci drivers, since windows xp doesn't support it out of the box. They were installed during system installation, not afterwards.

Thanks again.