SPTI firewire problem

[Guest]

Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in fact,
this is just usual internal DVD-writer hosted in the firewire enclosure.
Commercial Audio CD is used as media in the tray - I tried several Audio CDs
with the same result]. So, drive's behaviour to this command is very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB status, then ,
in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as reported
by BusHound] and indeed driver is disconnected from the system at this point
and unusable. Device Manager reports that it unable to start this device
(Code 10) . Of course, I am sending the sequence of different commands to
the drive but this "disconnection" always happens on READ CAPACITY. The same
very DVD-drive on the same computer works fine while being connected to IDE
port and "READ CAPACITY" works fine, so it should be FireWire-related
"software" problem of some kind. Windows Media Player 9 works fine at the
very same computer with this firewire drive and issues "READ CAPACITY"
command [among others] without any problems.[ Does WMP uses SPTI, btw?]
Anyway, what could be reason and whould you recommend me to check first? I
am really stuck up to my head in this, so ANY help will be GREATLY
appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"

 

[Maxim S. Shatskih]

"software" problem of some kind. Windows Media Player 9 works fine at the
very same computer with this firewire drive and issues "READ CAPACITY"
command [among others] without any problems.[ Does WMP uses SPTI, btw?]

No. But PowerDVD do use SPTI.

I had a buggy SPTI filter once. The bug was minor (though BSOD) and fixed in 30
minutes, but WMP never hit this bug while playing a movie, and PowerDVD hit it
each time.

 

[igor]

Thank you!

Probably you have a bad 1394 <-> IDE bridge hardware.

Probably... How to determine that? In fact, I tried few firewire cards on my
PC and also tried 2 different enclosures from different manufacturers - but
the problem remains. Overall, it looks like the problem is on OS/software,
not hardware side...

Try Nero. Will it burn via such a hardware?

Yes, Nero works no problem, but this fact is of little help: Nero does not
use SPTI at all - it uses partially ASPI [for IDE] , partially its own
proprietory "access layer" [for Firewire, USB] - oh well, to the best of my
knowledge...
I am pretty sure about that my problem lies somewhere on "access" [SPTI?]
level, because my CDBs are fine [as BusHound reports] and everthing works
perfect when I connect the same DVD-drive via IDE

No. But PowerDVD do use SPTI.

Thanks for the hint, I'll try PowerDVD

I had a buggy SPTI filter once.

Oh, I have a feeling that I am missing something very important here - what
is *SPTI filter* ?
How exactly did you fix it?

Many many thanks!
I really appreciate your help!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"

"software" problem of some kind. Windows Media Player 9 works fine at the
very same computer with this firewire drive and issues "READ CAPACITY"
command [among others] without any problems.[ Does WMP uses SPTI, btw?]

No. But PowerDVD do use SPTI.

I had a buggy SPTI filter once. The bug was minor (though BSOD) and fixed
in 30
minutes, but WMP never hit this bug while playing a movie, and PowerDVD
hit it
each time.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
(e-mail address removed)
http://www.storagecraft.com

 

[Maxim S. Shatskih]

Yes, Nero works no problem, but this fact is of little help: Nero does not

use SPTI at all - it uses partially ASPI [for IDE] , partially its own

Absolutely not so. Nero relies on IOCTL_SCSI_PASS_THROUGH_DIRECT, at least on
SCSI, USB and 1394. I saw this in the SCSI monitor.

Well, you know, ASPI is a wrapper around SPTI anyway

proprietory "access layer" [for Firewire, USB] - oh well, to the best of my
knowledge...

I cannot understand how IOCTL_SCSI_PASS_THROUGH_DIRECT can depend on connection
bus.

Oh, I have a feeling that I am missing something very important here - what
is *SPTI filter* ?

Filter below CdRom and above the storage port which filtered all SCSI and SPTI
requests.

 

[igor]

Thank you very much, Maxim, you are very helpful indeed!

Absolutely not so. Nero relies on IOCTL_SCSI_PASS_THROUGH_DIRECT, at least
on
SCSI, USB and 1394. I saw this in the SCSI monitor.

Thanks for info! Sorry for a bit naive question but what is the *SCSI
monitor* you are using, the one which allows you to trace down
SPTI/DeviceIoControl calls?

Well, you know, ASPI is a wrapper around SPTI anyway

Oh, really? You mean Adaptec's ASPI implementation or what? I thought ASPI
[from Adaptec at least] was much more than that, not just another funny API
around, I mean, but something comprising "fat" kernel-level stuff and
working sort of parallel to SPTI delivery mechanism... and , btw, if ASPI is
simply a wrapper over the SPTI, why FireWire and USB devices are not visible
via ASPI? Frankly, this ASPI stuff is of pure theoretical interest to me, I
am not going to use ASPI anyway, just curious... so you may just ignore
these comments

I cannot understand how IOCTL_SCSI_PASS_THROUGH_DIRECT can depend on
connection bus.

You still speaking about ASPI here, right? Well, neither do I ... and what
do you mean by "connection bus" btw? Physical bus like IDE or Firewire? Or
something else?

Filter below CdRom and above the storage port which filtered all SCSI and
SPTI
requests.

Very interesting! You told you were having trouble with it once and you
fixed it. Can you reveal the partucular info how did you do that? And, sorry
for pushing you, speaking of the particular problem I have [i.e.
SPTI-FireWire-disconnect], what would be your primary culprit for that? What
would you recommend to check/investigate/look into? Frankly, I am still
looking for any hint regarding how to approach my problem...
Sorry for being so bothering, I really am!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"

Yes, Nero works no problem, but this fact is of little help: Nero does
not
use SPTI at all - it uses partially ASPI [for IDE] , partially its own

Absolutely not so. Nero relies on IOCTL_SCSI_PASS_THROUGH_DIRECT, at least
on
SCSI, USB and 1394. I saw this in the SCSI monitor.

Well, you know, ASPI is a wrapper around SPTI anyway

proprietory "access layer" [for Firewire, USB] - oh well, to the best of
my
knowledge...

I cannot understand how IOCTL_SCSI_PASS_THROUGH_DIRECT can depend on
connection
bus.

Oh, I have a feeling that I am missing something very important here -
what
is *SPTI filter* ?

Filter below CdRom and above the storage port which filtered all SCSI and
SPTI
requests.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
(e-mail address removed)
http://www.storagecraft.com

 

[Maxim S. Shatskih]

Thanks for info! Sorry for a bit naive question but what is the *SCSI

monitor* you are using, the one which allows you to trace down
SPTI/DeviceIoControl calls?

My own code. My own SCSI monitor.

simply a wrapper over the SPTI, why FireWire and USB devices are not visible
via ASPI?

Because ASPI is stupid legacy idiocy inherited from MS-DOS. Forget ASPI.

Very interesting! You told you were having trouble with it once and you
fixed it. Can you reveal the partucular info how did you do that?

The trouble was some minor, but it revealed the fact that WMP does not send any
SPTI commands, while PowerDVD does.

for pushing you, speaking of the particular problem I have [i.e.
SPTI-FireWire-disconnect], what would be your primary culprit for that? What

I cannot understand why READ CAPACITY does not work. The CDFS filesystem relies
on this call to mount.

 

[cristalink]

Your READ CAPACITY is probably malformed.

 

[cristalink]

It is easy to make a mistake in a SPTI request, eg, specify OUT instead of
IN or set invalid lengths. You may want to try firestreamer-dvd to see if
your drive disconnects. Firestreamer issues READ CAPACITY for DVD-ROMs only,
not for rewritable disks.

If your READ CAPACITY is flushed, then the problem is most likely with the
*previous* command, not with READ CAPACITY.

--
http://www.firestreamer.com - NTBackup to DVD and DV

Thank you for you reply!

Your READ CAPACITY is probably malformed.

I do not think so ... for it is not so easy to malform such trivial
command as "READ CAPACITY" - although certainly possible Seriously, as
far as I can see, the command is perfectly fine, only the drive behaviour
is weird [ in the firewire enclosure only, the same drive works fine while
connected via IDE]. Here is the excerpt from the SCSI logs I collected:
firewire and ide (see attachments) - just to make sure ...
Many thanks!
Igor.

Your READ CAPACITY is probably malformed.

--
http://www.firestreamer.com - NTBackup to DVD and DV

Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in fact,
this is just usual internal DVD-writer hosted in the firewire enclosure.
Commercial Audio CD is used as media in the tray - I tried several Audio
CDs with the same result]. So, drive's behaviour to this command is very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB status,
then
, in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as
reported by BusHound] and indeed driver is disconnected from the system
at
this point and unusable. Device Manager reports that it unable to start
this device (Code 10) . Of course, I am sending the sequence of
different
commands to the drive but this "disconnection" always happens on READ
CAPACITY. The same very DVD-drive on the same computer works fine while
being connected to IDE port and "READ CAPACITY" works fine, so it should
be FireWire-related "software" problem of some kind. Windows Media
Player
9 works fine at the very same computer with this firewire drive and
issues
"READ CAPACITY" command [among others] without any problems.[ Does WMP
uses SPTI, btw?] Anyway, what could be reason and whould you recommend
me
to check first? I am really stuck up to my head in this, so ANY help
will
be GREATLY appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail
address from this message with the following literal "iholodov"

 

[igor]

Firestreamer issues READ CAPACITY for DVD-ROMs only, not for rewritable
disks.

In a way, so do I, only for CDs - I am using READ FORMAT CAPACITIES for
writable CD media, but, as I said, there was commercial Audio CD in the
tray, so READ CAPACITY was used. And, thanks for advice, I would give a try
to Firestreamer, although I do not quite see how it will help me to approach
my problem... but thanks anyway!

If your READ CAPACITY is flushed, then the problem is most likely with the
*previous* command, not with READ CAPACITY.

Right. As you can see from the SCSI log, it is GET EVENT STATUS was flashed
and the previous command was exactly "READ CAPACITY".

It is easy to make a mistake in a SPTI request, eg, specify OUT instead of
IN or set invalid lengths.

Agree. But you can see from the SCSI log that both direction and size are
Ok.
Also, let me put it this way: unless I am terribly mistaken, malformed CDB
is malformed CDB, no more, no less. You can send it via Firewire or you can
send it via IDE - it still remains malformed CDB, right? If you are sending
malformed CDB to the device, it won't work no matter what do you send it
through: IDE or FireWire, right? Correct me if I am wrong. Also, while
sending malformed CDB, you have a good chance to get back appropriate SCSI
sense code [e.g. "5 26 00 INVALID FIELD IN PARAMETER LIST"] none of which
are present here. What IS present, though, is weird behaviour which is
peculiar to FireWire only. Overall, it looks more like sort of timing-like
issue to me, could it be that way? If yes, is there any control over it? Or
perhaps there are some mandatory Firewire windows updates/patches which I am
not aware about... Btw, are you aware of any? The nature of the problem
makes me to suspect that the solution to my problem lies more likely in this
area, rather than in CDB tweaking - although, I can be mistaken on this, of
course.... What do you think?
Many thanks!
I really appreciate your help!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"

It is easy to make a mistake in a SPTI request, eg, specify OUT instead of
IN or set invalid lengths. You may want to try firestreamer-dvd to see if
your drive disconnects. Firestreamer issues READ CAPACITY for DVD-ROMs
only, not for rewritable disks.

If your READ CAPACITY is flushed, then the problem is most likely with the
*previous* command, not with READ CAPACITY.

--
http://www.firestreamer.com - NTBackup to DVD and DV

Thank you for you reply!

Your READ CAPACITY is probably malformed.

I do not think so ... for it is not so easy to malform such trivial
command as "READ CAPACITY" - although certainly possible Seriously, as
far as I can see, the command is perfectly fine, only the drive behaviour
is weird [ in the firewire enclosure only, the same drive works fine
while connected via IDE]. Here is the excerpt from the SCSI logs I
collected: firewire and ide (see attachments) - just to make sure ...
Many thanks!
Igor.

Your READ CAPACITY is probably malformed.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in
fact,
this is just usual internal DVD-writer hosted in the firewire
enclosure.
Commercial Audio CD is used as media in the tray - I tried several
Audio
CDs with the same result]. So, drive's behaviour to this command is
very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB status,
then
, in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as
reported by BusHound] and indeed driver is disconnected from the system
at
this point and unusable. Device Manager reports that it unable to start
this device (Code 10) . Of course, I am sending the sequence of
different
commands to the drive but this "disconnection" always happens on READ
CAPACITY. The same very DVD-drive on the same computer works fine while
being connected to IDE port and "READ CAPACITY" works fine, so it
should
be FireWire-related "software" problem of some kind. Windows Media
Player
9 works fine at the very same computer with this firewire drive and
issues
"READ CAPACITY" command [among others] without any problems.[ Does WMP
uses SPTI, btw?] Anyway, what could be reason and whould you recommend
me
to check first? I am really stuck up to my head in this, so ANY help
will
be GREATLY appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail
address from this message with the following literal "iholodov"

 

[cristalink]

In a way, so do I, only for CDs - I am using READ FORMAT CAPACITIES for
writable CD media, but, as I said, there was commercial Audio CD in the
tray, so READ CAPACITY was used. And, thanks for advice, I would give a
try to Firestreamer, although I do not quite see how it will help me to
approach my problem... but thanks anyway!

I've got a better idea. Send one of the following from the user mode. These
are translated into READ CAPACITY. If your drive is still alive after you
sent IOCTL, then the problem is in your code. See CDROM class sources.

IOCTL_DISK_GET_LENGTH_INFO:
IOCTL_DISK_GET_DRIVE_GEOMETRY_EX:
IOCTL_DISK_GET_DRIVE_GEOMETRY:
IOCTL_CDROM_GET_DRIVE_GEOMETRY_EX:
IOCTL_CDROM_GET_DRIVE_GEOMETRY: {

Right. As you can see from the SCSI log, it is GET EVENT STATUS was
flashed and the previous command was exactly "READ CAPACITY".

I wouldn't use GET EVENT STATUS unless absolute necessary. As far as I can
see from your log, GET STATUS fails after INQUIRY and TEST UNIT READY, too.

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths.

Agree. But you can see from the SCSI log that both direction and size are
Ok.
Also, let me put it this way: unless I am terribly mistaken, malformed CDB
is malformed CDB, no more, no less. You can send it via Firewire or you
can send it via IDE - it still remains malformed CDB, right? If you are
sending malformed CDB to the device, it won't work no matter what do you
send it through: IDE or FireWire, right? Correct me if I am wrong. Also,
while sending malformed CDB, you have a good chance to get back
appropriate SCSI sense code [e.g. "5 26 00 INVALID FIELD IN PARAMETER
LIST"] none of which are present here.

If it only was so easy! I've seen disconnects, too. READ CAPACITY should
work though.

What IS present, though, is weird behaviour which is peculiar to FireWire
only. Overall, it looks more like sort of timing-like issue to me, could
it be that way? If yes, is there any control over it? Or perhaps there are
some mandatory Firewire windows updates/patches which I am not aware
about... Btw, are you aware of any? The nature of the problem makes me to
suspect that the solution to my problem lies more likely in this area,
rather than in CDB tweaking - although, I can be mistaken on this, of
course.... What do you think?

Try IOCTL from user mode first

Many thanks!
I really appreciate your help!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths. You may want to try firestreamer-dvd to see
if your drive disconnects. Firestreamer issues READ CAPACITY for DVD-ROMs
only, not for rewritable disks.

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.

--
http://www.firestreamer.com - NTBackup to DVD and DV

Thank you for you reply!

Your READ CAPACITY is probably malformed.
I do not think so ... for it is not so easy to malform such trivial
command as "READ CAPACITY" - although certainly possible Seriously,
as far as I can see, the command is perfectly fine, only the drive
behaviour is weird [ in the firewire enclosure only, the same drive
works fine while connected via IDE]. Here is the excerpt from the SCSI
logs I collected: firewire and ide (see attachments) - just to make sure
...
Many thanks!
Igor.


Your READ CAPACITY is probably malformed.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in
fact,
this is just usual internal DVD-writer hosted in the firewire
enclosure.
Commercial Audio CD is used as media in the tray - I tried several
Audio
CDs with the same result]. So, drive's behaviour to this command is
very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB status,
then
, in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as
reported by BusHound] and indeed driver is disconnected from the
system at
this point and unusable. Device Manager reports that it unable to
start
this device (Code 10) . Of course, I am sending the sequence of
different
commands to the drive but this "disconnection" always happens on READ
CAPACITY. The same very DVD-drive on the same computer works fine
while
being connected to IDE port and "READ CAPACITY" works fine, so it
should
be FireWire-related "software" problem of some kind. Windows Media
Player
9 works fine at the very same computer with this firewire drive and
issues
"READ CAPACITY" command [among others] without any problems.[ Does WMP
uses SPTI, btw?] Anyway, what could be reason and whould you recommend
me
to check first? I am really stuck up to my head in this, so ANY help
will
be GREATLY appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail
address from this message with the following literal "iholodov"

 

[cristalink]

Besides, *as far as I remember*, GET EVENT STATUS clears the status in the
device. If you send this command from your app, this interferes with
CLASSPNP. Say, a user pressed the Eject button on a locked drive, your app
reads the status, but the class cannot see it since the status is cleared.
So nobody except of you knows that the user wants the disk out. On the other
hand, the status can be cleared by the class driver before you can see it.
So GET EVENT STATUS is useless and harmful if used by anyone but CLASSPNP.

--
http://www.firestreamer.com - NTBackup to DVD and DV

Firestreamer issues READ CAPACITY for DVD-ROMs only, not for rewritable
disks.

In a way, so do I, only for CDs - I am using READ FORMAT CAPACITIES for
writable CD media, but, as I said, there was commercial Audio CD in the
tray, so READ CAPACITY was used. And, thanks for advice, I would give a
try to Firestreamer, although I do not quite see how it will help me to
approach my problem... but thanks anyway!

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.

Right. As you can see from the SCSI log, it is GET EVENT STATUS was
flashed and the previous command was exactly "READ CAPACITY".

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths.

Agree. But you can see from the SCSI log that both direction and size are
Ok.
Also, let me put it this way: unless I am terribly mistaken, malformed CDB
is malformed CDB, no more, no less. You can send it via Firewire or you
can send it via IDE - it still remains malformed CDB, right? If you are
sending malformed CDB to the device, it won't work no matter what do you
send it through: IDE or FireWire, right? Correct me if I am wrong. Also,
while sending malformed CDB, you have a good chance to get back
appropriate SCSI sense code [e.g. "5 26 00 INVALID FIELD IN PARAMETER
LIST"] none of which are present here. What IS present, though, is weird
behaviour which is peculiar to FireWire only. Overall, it looks more like
sort of timing-like issue to me, could it be that way? If yes, is there
any control over it? Or perhaps there are some mandatory Firewire windows
updates/patches which I am not aware about... Btw, are you aware of any?
The nature of the problem makes me to suspect that the solution to my
problem lies more likely in this area, rather than in CDB tweaking -
although, I can be mistaken on this, of course.... What do you think?
Many thanks!
I really appreciate your help!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths. You may want to try firestreamer-dvd to see
if your drive disconnects. Firestreamer issues READ CAPACITY for DVD-ROMs
only, not for rewritable disks.

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.

--
http://www.firestreamer.com - NTBackup to DVD and DV

Thank you for you reply!

Your READ CAPACITY is probably malformed.
I do not think so ... for it is not so easy to malform such trivial
command as "READ CAPACITY" - although certainly possible Seriously,
as far as I can see, the command is perfectly fine, only the drive
behaviour is weird [ in the firewire enclosure only, the same drive
works fine while connected via IDE]. Here is the excerpt from the SCSI
logs I collected: firewire and ide (see attachments) - just to make sure
...
Many thanks!
Igor.


Your READ CAPACITY is probably malformed.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in
fact,
this is just usual internal DVD-writer hosted in the firewire
enclosure.
Commercial Audio CD is used as media in the tray - I tried several
Audio
CDs with the same result]. So, drive's behaviour to this command is
very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB status,
then
, in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as
reported by BusHound] and indeed driver is disconnected from the
system at
this point and unusable. Device Manager reports that it unable to
start
this device (Code 10) . Of course, I am sending the sequence of
different
commands to the drive but this "disconnection" always happens on READ
CAPACITY. The same very DVD-drive on the same computer works fine
while
being connected to IDE port and "READ CAPACITY" works fine, so it
should
be FireWire-related "software" problem of some kind. Windows Media
Player
9 works fine at the very same computer with this firewire drive and
issues
"READ CAPACITY" command [among others] without any problems.[ Does WMP
uses SPTI, btw?] Anyway, what could be reason and whould you recommend
me
to check first? I am really stuck up to my head in this, so ANY help
will
be GREATLY appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail
address from this message with the following literal "iholodov"

 

[Maxim S. Shatskih]

your drive disconnects. Firestreamer issues READ CAPACITY for DVD-ROMs only,

not for rewritable disks.

READ CAPACITY is a reader command, and must not be used for writing, there is
READ WRITE CAPACITY.

 

[igor]

Thank you very much for info!
In fact, I am NOT sending this command to the drive explicitely. Where is it
from - I do not know exactly, my understanding was that some kind of
"middleware" [between my DeviceIoControl call and the drive itself ] is
sending it. I am observing this command on regular base in many places while
doing my SCSI logs and so far it was absolutely harmless, so I kindda got
an impression that it is inevitable part of working with SPTI
Is there any way to figure out what component [besides my program] may send
it?
Igor.

Besides, *as far as I remember*, GET EVENT STATUS clears the status in the
device. If you send this command from your app, this interferes with
CLASSPNP. Say, a user pressed the Eject button on a locked drive, your app
reads the status, but the class cannot see it since the status is cleared.
So nobody except of you knows that the user wants the disk out. On the
other hand, the status can be cleared by the class driver before you can
see it. So GET EVENT STATUS is useless and harmful if used by anyone but
CLASSPNP.

--
http://www.firestreamer.com - NTBackup to DVD and DV

Firestreamer issues READ CAPACITY for DVD-ROMs only, not for rewritable
disks.

In a way, so do I, only for CDs - I am using READ FORMAT CAPACITIES for
writable CD media, but, as I said, there was commercial Audio CD in the
tray, so READ CAPACITY was used. And, thanks for advice, I would give a
try to Firestreamer, although I do not quite see how it will help me to
approach my problem... but thanks anyway!

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.

Right. As you can see from the SCSI log, it is GET EVENT STATUS was
flashed and the previous command was exactly "READ CAPACITY".

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths.

Agree. But you can see from the SCSI log that both direction and size are
Ok.
Also, let me put it this way: unless I am terribly mistaken, malformed
CDB is malformed CDB, no more, no less. You can send it via Firewire or
you can send it via IDE - it still remains malformed CDB, right? If you
are sending malformed CDB to the device, it won't work no matter what do
you send it through: IDE or FireWire, right? Correct me if I am wrong.
Also, while sending malformed CDB, you have a good chance to get back
appropriate SCSI sense code [e.g. "5 26 00 INVALID FIELD IN PARAMETER
LIST"] none of which are present here. What IS present, though, is weird
behaviour which is peculiar to FireWire only. Overall, it looks more like
sort of timing-like issue to me, could it be that way? If yes, is there
any control over it? Or perhaps there are some mandatory Firewire windows
updates/patches which I am not aware about... Btw, are you aware of any?
The nature of the problem makes me to suspect that the solution to my
problem lies more likely in this area, rather than in CDB tweaking -
although, I can be mistaken on this, of course.... What do you think?
Many thanks!
I really appreciate your help!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths. You may want to try firestreamer-dvd to
see if your drive disconnects. Firestreamer issues READ CAPACITY for
DVD-ROMs only, not for rewritable disks.

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Thank you for you reply!

Your READ CAPACITY is probably malformed.
I do not think so ... for it is not so easy to malform such trivial
command as "READ CAPACITY" - although certainly possible Seriously,
as far as I can see, the command is perfectly fine, only the drive
behaviour is weird [ in the firewire enclosure only, the same drive
works fine while connected via IDE]. Here is the excerpt from the SCSI
logs I collected: firewire and ide (see attachments) - just to make
sure ...
Many thanks!
Igor.


Your READ CAPACITY is probably malformed.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in
fact,
this is just usual internal DVD-writer hosted in the firewire
enclosure.
Commercial Audio CD is used as media in the tray - I tried several
Audio
CDs with the same result]. So, drive's behaviour to this command is
very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB status,
then
, in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as
reported by BusHound] and indeed driver is disconnected from the
system at
this point and unusable. Device Manager reports that it unable to
start
this device (Code 10) . Of course, I am sending the sequence of
different
commands to the drive but this "disconnection" always happens on READ
CAPACITY. The same very DVD-drive on the same computer works fine
while
being connected to IDE port and "READ CAPACITY" works fine, so it
should
be FireWire-related "software" problem of some kind. Windows Media
Player
9 works fine at the very same computer with this firewire drive and
issues
"READ CAPACITY" command [among others] without any problems.[ Does
WMP
uses SPTI, btw?] Anyway, what could be reason and whould you
recommend me
to check first? I am really stuck up to my head in this, so ANY help
will
be GREATLY appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail
address from this message with the following literal "iholodov"

 

[igor]

thank you for the idea - I'll try that !
Many thanks again!
Igor.

In a way, so do I, only for CDs - I am using READ FORMAT CAPACITIES for
writable CD media, but, as I said, there was commercial Audio CD in the
tray, so READ CAPACITY was used. And, thanks for advice, I would give a
try to Firestreamer, although I do not quite see how it will help me to
approach my problem... but thanks anyway!

I've got a better idea. Send one of the following from the user mode.
These are translated into READ CAPACITY. If your drive is still alive
after you sent IOCTL, then the problem is in your code. See CDROM class
sources.

IOCTL_DISK_GET_LENGTH_INFO:
IOCTL_DISK_GET_DRIVE_GEOMETRY_EX:
IOCTL_DISK_GET_DRIVE_GEOMETRY:
IOCTL_CDROM_GET_DRIVE_GEOMETRY_EX:
IOCTL_CDROM_GET_DRIVE_GEOMETRY: {

Right. As you can see from the SCSI log, it is GET EVENT STATUS was
flashed and the previous command was exactly "READ CAPACITY".

I wouldn't use GET EVENT STATUS unless absolute necessary. As far as I can
see from your log, GET STATUS fails after INQUIRY and TEST UNIT READY,
too.

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths.

Agree. But you can see from the SCSI log that both direction and size are
Ok.
Also, let me put it this way: unless I am terribly mistaken, malformed
CDB is malformed CDB, no more, no less. You can send it via Firewire or
you can send it via IDE - it still remains malformed CDB, right? If you
are sending malformed CDB to the device, it won't work no matter what do
you send it through: IDE or FireWire, right? Correct me if I am wrong.
Also, while sending malformed CDB, you have a good chance to get back
appropriate SCSI sense code [e.g. "5 26 00 INVALID FIELD IN PARAMETER
LIST"] none of which are present here.

If it only was so easy! I've seen disconnects, too. READ CAPACITY should
work though.

What IS present, though, is weird behaviour which is peculiar to FireWire
only. Overall, it looks more like sort of timing-like issue to me, could
it be that way? If yes, is there any control over it? Or perhaps there
are some mandatory Firewire windows updates/patches which I am not aware
about... Btw, are you aware of any? The nature of the problem makes me to
suspect that the solution to my problem lies more likely in this area,
rather than in CDB tweaking - although, I can be mistaken on this, of
course.... What do you think?

Try IOCTL from user mode first

Many thanks!
I really appreciate your help!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths. You may want to try firestreamer-dvd to
see if your drive disconnects. Firestreamer issues READ CAPACITY for
DVD-ROMs only, not for rewritable disks.

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Thank you for you reply!

Your READ CAPACITY is probably malformed.
I do not think so ... for it is not so easy to malform such trivial
command as "READ CAPACITY" - although certainly possible Seriously,
as far as I can see, the command is perfectly fine, only the drive
behaviour is weird [ in the firewire enclosure only, the same drive
works fine while connected via IDE]. Here is the excerpt from the SCSI
logs I collected: firewire and ide (see attachments) - just to make
sure ...
Many thanks!
Igor.


Your READ CAPACITY is probably malformed.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in
fact,
this is just usual internal DVD-writer hosted in the firewire
enclosure.
Commercial Audio CD is used as media in the tray - I tried several
Audio
CDs with the same result]. So, drive's behaviour to this command is
very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB status,
then
, in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as
reported by BusHound] and indeed driver is disconnected from the
system at
this point and unusable. Device Manager reports that it unable to
start
this device (Code 10) . Of course, I am sending the sequence of
different
commands to the drive but this "disconnection" always happens on READ
CAPACITY. The same very DVD-drive on the same computer works fine
while
being connected to IDE port and "READ CAPACITY" works fine, so it
should
be FireWire-related "software" problem of some kind. Windows Media
Player
9 works fine at the very same computer with this firewire drive and
issues
"READ CAPACITY" command [among others] without any problems.[ Does
WMP
uses SPTI, btw?] Anyway, what could be reason and whould you
recommend me
to check first? I am really stuck up to my head in this, so ANY help
will
be GREATLY appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail
address from this message with the following literal "iholodov"

 

[Alexander Grigoriev]

For aspi.sys, there is no need to use SPTI. It can use IRP_MJ_SCSI. SPTI is
always synchronous, and this doesn't playwell with ASPI model.

Yes, Nero works no problem, but this fact is of little help: Nero does
not
use SPTI at all - it uses partially ASPI [for IDE] , partially its own

Absolutely not so. Nero relies on IOCTL_SCSI_PASS_THROUGH_DIRECT, at least
on
SCSI, USB and 1394. I saw this in the SCSI monitor.

Well, you know, ASPI is a wrapper around SPTI anyway

proprietory "access layer" [for Firewire, USB] - oh well, to the best of
my
knowledge...

I cannot understand how IOCTL_SCSI_PASS_THROUGH_DIRECT can depend on
connection
bus.

Oh, I have a feeling that I am missing something very important here -
what
is *SPTI filter* ?

Filter below CdRom and above the storage port which filtered all SCSI and
SPTI
requests.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
(e-mail address removed)
http://www.storagecraft.com

 

[cristalink]

CLASSPNP.SYS

--
http://www.firestreamer.com - NTBackup to DVD and DV

Thank you very much for info!
In fact, I am NOT sending this command to the drive explicitely. Where is it
from - I do not know exactly, my understanding was that some kind of
"middleware" [between my DeviceIoControl call and the drive itself ] is
sending it. I am observing this command on regular base in many places while
doing my SCSI logs and so far it was absolutely harmless, so I kindda got
an impression that it is inevitable part of working with SPTI
Is there any way to figure out what component [besides my program] may send
it?
Igor.

Besides, *as far as I remember*, GET EVENT STATUS clears the status in the
device. If you send this command from your app, this interferes with
CLASSPNP. Say, a user pressed the Eject button on a locked drive, your app
reads the status, but the class cannot see it since the status is cleared.
So nobody except of you knows that the user wants the disk out. On the
other hand, the status can be cleared by the class driver before you can
see it. So GET EVENT STATUS is useless and harmful if used by anyone but
CLASSPNP.

--
http://www.firestreamer.com - NTBackup to DVD and DV

Firestreamer issues READ CAPACITY for DVD-ROMs only, not for rewritable
disks.
In a way, so do I, only for CDs - I am using READ FORMAT CAPACITIES for
writable CD media, but, as I said, there was commercial Audio CD in the
tray, so READ CAPACITY was used. And, thanks for advice, I would give a
try to Firestreamer, although I do not quite see how it will help me to
approach my problem... but thanks anyway!

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.
Right. As you can see from the SCSI log, it is GET EVENT STATUS was
flashed and the previous command was exactly "READ CAPACITY".

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths.
Agree. But you can see from the SCSI log that both direction and size are
Ok.
Also, let me put it this way: unless I am terribly mistaken, malformed
CDB is malformed CDB, no more, no less. You can send it via Firewire or
you can send it via IDE - it still remains malformed CDB, right? If you
are sending malformed CDB to the device, it won't work no matter what do
you send it through: IDE or FireWire, right? Correct me if I am wrong.
Also, while sending malformed CDB, you have a good chance to get back
appropriate SCSI sense code [e.g. "5 26 00 INVALID FIELD IN PARAMETER
LIST"] none of which are present here. What IS present, though, is weird
behaviour which is peculiar to FireWire only. Overall, it looks more like
sort of timing-like issue to me, could it be that way? If yes, is there
any control over it? Or perhaps there are some mandatory Firewire windows
updates/patches which I am not aware about... Btw, are you aware of any?
The nature of the problem makes me to suspect that the solution to my
problem lies more likely in this area, rather than in CDB tweaking -
although, I can be mistaken on this, of course.... What do you think?
Many thanks!
I really appreciate your help!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"


It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths. You may want to try firestreamer-dvd to
see if your drive disconnects. Firestreamer issues READ CAPACITY for
DVD-ROMs only, not for rewritable disks.

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Thank you for you reply!

Your READ CAPACITY is probably malformed.
I do not think so ... for it is not so easy to malform such trivial
command as "READ CAPACITY" - although certainly possible Seriously,
as far as I can see, the command is perfectly fine, only the drive
behaviour is weird [ in the firewire enclosure only, the same drive
works fine while connected via IDE]. Here is the excerpt from the SCSI
logs I collected: firewire and ide (see attachments) - just to make
sure ...
Many thanks!
Igor.


Your READ CAPACITY is probably malformed.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in
fact,
this is just usual internal DVD-writer hosted in the firewire
enclosure.
Commercial Audio CD is used as media in the tray - I tried several
Audio
CDs with the same result]. So, drive's behaviour to this command is
very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB status,
then
, in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as
reported by BusHound] and indeed driver is disconnected from the
system at
this point and unusable. Device Manager reports that it unable to
start
this device (Code 10) . Of course, I am sending the sequence of
different
commands to the drive but this "disconnection" always happens on READ
CAPACITY. The same very DVD-drive on the same computer works fine
while
being connected to IDE port and "READ CAPACITY" works fine, so it
should
be FireWire-related "software" problem of some kind. Windows Media
Player
9 works fine at the very same computer with this firewire drive and
issues
"READ CAPACITY" command [among others] without any problems.[ Does
WMP
uses SPTI, btw?] Anyway, what could be reason and whould you
recommend me
to check first? I am really stuck up to my head in this, so ANY help
will
be GREATLY appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail
address from this message with the following literal "iholodov"

 

[igor]

I've got a better idea...
FYI: I tried to issue IOCTL_DISK_GET_DRIVE_GEOMETRY_EX instead of "READ
CAPACITY" via SPTI and it worked with my firewire drive just fine. So, at
least, I have a functional workaround, thank you very much for the idea!!!
I still do not quite understand why READ CAPACITY through SPTI does not work
[or worse, why it partially(!) does not work: works for IDE but not for
firewire] - it would be easier in a way if it wouldn't work at all <g>...
anyway ... thank you very much for your help again!
Igor.

In a way, so do I, only for CDs - I am using READ FORMAT CAPACITIES for
writable CD media, but, as I said, there was commercial Audio CD in the
tray, so READ CAPACITY was used. And, thanks for advice, I would give a
try to Firestreamer, although I do not quite see how it will help me to
approach my problem... but thanks anyway!

I've got a better idea. Send one of the following from the user mode.
These are translated into READ CAPACITY. If your drive is still alive
after you sent IOCTL, then the problem is in your code. See CDROM class
sources.

IOCTL_DISK_GET_LENGTH_INFO:
IOCTL_DISK_GET_DRIVE_GEOMETRY_EX:
IOCTL_DISK_GET_DRIVE_GEOMETRY:
IOCTL_CDROM_GET_DRIVE_GEOMETRY_EX:
IOCTL_CDROM_GET_DRIVE_GEOMETRY: {

Right. As you can see from the SCSI log, it is GET EVENT STATUS was
flashed and the previous command was exactly "READ CAPACITY".

I wouldn't use GET EVENT STATUS unless absolute necessary. As far as I can
see from your log, GET STATUS fails after INQUIRY and TEST UNIT READY,
too.

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths.

Agree. But you can see from the SCSI log that both direction and size are
Ok.
Also, let me put it this way: unless I am terribly mistaken, malformed
CDB is malformed CDB, no more, no less. You can send it via Firewire or
you can send it via IDE - it still remains malformed CDB, right? If you
are sending malformed CDB to the device, it won't work no matter what do
you send it through: IDE or FireWire, right? Correct me if I am wrong.
Also, while sending malformed CDB, you have a good chance to get back
appropriate SCSI sense code [e.g. "5 26 00 INVALID FIELD IN PARAMETER
LIST"] none of which are present here.

If it only was so easy! I've seen disconnects, too. READ CAPACITY should
work though.

What IS present, though, is weird behaviour which is peculiar to FireWire
only. Overall, it looks more like sort of timing-like issue to me, could
it be that way? If yes, is there any control over it? Or perhaps there
are some mandatory Firewire windows updates/patches which I am not aware
about... Btw, are you aware of any? The nature of the problem makes me to
suspect that the solution to my problem lies more likely in this area,
rather than in CDB tweaking - although, I can be mistaken on this, of
course.... What do you think?

Try IOCTL from user mode first

Many thanks!
I really appreciate your help!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the e-mail
address from this message with the following literal "iholodov"

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths. You may want to try firestreamer-dvd to
see if your drive disconnects. Firestreamer issues READ CAPACITY for
DVD-ROMs only, not for rewritable disks.

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Thank you for you reply!

Your READ CAPACITY is probably malformed.
I do not think so ... for it is not so easy to malform such trivial
command as "READ CAPACITY" - although certainly possible Seriously,
as far as I can see, the command is perfectly fine, only the drive
behaviour is weird [ in the firewire enclosure only, the same drive
works fine while connected via IDE]. Here is the excerpt from the SCSI
logs I collected: firewire and ide (see attachments) - just to make
sure ...
Many thanks!
Igor.


Your READ CAPACITY is probably malformed.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in
fact,
this is just usual internal DVD-writer hosted in the firewire
enclosure.
Commercial Audio CD is used as media in the tray - I tried several
Audio
CDs with the same result]. So, drive's behaviour to this command is
very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB status,
then
, in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as
reported by BusHound] and indeed driver is disconnected from the
system at
this point and unusable. Device Manager reports that it unable to
start
this device (Code 10) . Of course, I am sending the sequence of
different
commands to the drive but this "disconnection" always happens on READ
CAPACITY. The same very DVD-drive on the same computer works fine
while
being connected to IDE port and "READ CAPACITY" works fine, so it
should
be FireWire-related "software" problem of some kind. Windows Media
Player
9 works fine at the very same computer with this firewire drive and
issues
"READ CAPACITY" command [among others] without any problems.[ Does
WMP
uses SPTI, btw?] Anyway, what could be reason and whould you
recommend me
to check first? I am really stuck up to my head in this, so ANY help
will
be GREATLY appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail
address from this message with the following literal "iholodov"

 

[cristalink]

I think you did something wrong.

--
http://www.firestreamer.com - NTBackup to DVD and DV

I've got a better idea...

FYI: I tried to issue IOCTL_DISK_GET_DRIVE_GEOMETRY_EX instead of "READ
CAPACITY" via SPTI and it worked with my firewire drive just fine. So, at
least, I have a functional workaround, thank you very much for the idea!!!
I still do not quite understand why READ CAPACITY through SPTI does not
work [or worse, why it partially(!) does not work: works for IDE but not
for firewire] - it would be easier in a way if it wouldn't work at all
<g>... anyway ... thank you very much for your help again!
Igor.

Firestreamer issues READ CAPACITY for DVD-ROMs only, not for
rewritable disks.
In a way, so do I, only for CDs - I am using READ FORMAT CAPACITIES for
writable CD media, but, as I said, there was commercial Audio CD in the
tray, so READ CAPACITY was used. And, thanks for advice, I would give a
try to Firestreamer, although I do not quite see how it will help me to
approach my problem... but thanks anyway!

I've got a better idea. Send one of the following from the user mode.
These are translated into READ CAPACITY. If your drive is still alive
after you sent IOCTL, then the problem is in your code. See CDROM class
sources.

IOCTL_DISK_GET_LENGTH_INFO:
IOCTL_DISK_GET_DRIVE_GEOMETRY_EX:
IOCTL_DISK_GET_DRIVE_GEOMETRY:
IOCTL_CDROM_GET_DRIVE_GEOMETRY_EX:
IOCTL_CDROM_GET_DRIVE_GEOMETRY: {

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.
Right. As you can see from the SCSI log, it is GET EVENT STATUS was
flashed and the previous command was exactly "READ CAPACITY".

I wouldn't use GET EVENT STATUS unless absolute necessary. As far as I
can see from your log, GET STATUS fails after INQUIRY and TEST UNIT
READY, too.

It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths.
Agree. But you can see from the SCSI log that both direction and size
are Ok.
Also, let me put it this way: unless I am terribly mistaken, malformed
CDB is malformed CDB, no more, no less. You can send it via Firewire or
you can send it via IDE - it still remains malformed CDB, right? If you
are sending malformed CDB to the device, it won't work no matter what do
you send it through: IDE or FireWire, right? Correct me if I am wrong.
Also, while sending malformed CDB, you have a good chance to get back
appropriate SCSI sense code [e.g. "5 26 00 INVALID FIELD IN PARAMETER
LIST"] none of which are present here.

If it only was so easy! I've seen disconnects, too. READ CAPACITY should
work though.

What IS present, though, is weird behaviour which is peculiar to
FireWire only. Overall, it looks more like sort of timing-like issue to
me, could it be that way? If yes, is there any control over it? Or
perhaps there are some mandatory Firewire windows updates/patches which
I am not aware about... Btw, are you aware of any? The nature of the
problem makes me to suspect that the solution to my problem lies more
likely in this area, rather than in CDB tweaking - although, I can be
mistaken on this, of course.... What do you think?

Try IOCTL from user mode first

Many thanks!
I really appreciate your help!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail address from this message with the following literal "iholodov"


It is easy to make a mistake in a SPTI request, eg, specify OUT instead
of IN or set invalid lengths. You may want to try firestreamer-dvd to
see if your drive disconnects. Firestreamer issues READ CAPACITY for
DVD-ROMs only, not for rewritable disks.

If your READ CAPACITY is flushed, then the problem is most likely with
the *previous* command, not with READ CAPACITY.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Thank you for you reply!

Your READ CAPACITY is probably malformed.
I do not think so ... for it is not so easy to malform such trivial
command as "READ CAPACITY" - although certainly possible Seriously,
as far as I can see, the command is perfectly fine, only the drive
behaviour is weird [ in the firewire enclosure only, the same drive
works fine while connected via IDE]. Here is the excerpt from the SCSI
logs I collected: firewire and ide (see attachments) - just to make
sure ...
Many thanks!
Igor.


Your READ CAPACITY is probably malformed.

--
http://www.firestreamer.com - NTBackup to DVD and DV


Can anybody help me with the following problem?
I am using SPTI's IOCTL_SCSI_PASS_THROUGH call to send MMC "READ
CAPACITY"(25h) command from my XP PC to the FireWire DVD-drive [in
fact,
this is just usual internal DVD-writer hosted in the firewire
enclosure.
Commercial Audio CD is used as media in the tray - I tried several
Audio
CDs with the same result]. So, drive's behaviour to this command is
very
strange: driver reports SRB_STATUS_REQUEST_FLUSHED (0x16) SRB
status, then
, in a short time, it reports SRB_STATUS_NO_DEVICE (0x08) status [as
reported by BusHound] and indeed driver is disconnected from the
system at
this point and unusable. Device Manager reports that it unable to
start
this device (Code 10) . Of course, I am sending the sequence of
different
commands to the drive but this "disconnection" always happens on
READ
CAPACITY. The same very DVD-drive on the same computer works fine
while
being connected to IDE port and "READ CAPACITY" works fine, so it
should
be FireWire-related "software" problem of some kind. Windows Media
Player
9 works fine at the very same computer with this firewire drive and
issues
"READ CAPACITY" command [among others] without any problems.[ Does
WMP
uses SPTI, btw?] Anyway, what could be reason and whould you
recommend me
to check first? I am really stuck up to my head in this, so ANY help
will
be GREATLY appreciated!
Many thanks!
Igor.
P.S.
if you want to contact me by e-mail, replace "no-spam" part in the
e-mail
address from this message with the following literal "iholodov"