Archived from groups: microsoft.public.development.device.drivers,microsoft.public.windowsxp.device_driver.dev (
More info?)
I think you did something wrong.
--
http://www.firestreamer.com - NTBackup to DVD and DV
"igor" <no-spam@hotmail.com> wrote in message
news:uRxQeQXDFHA.1084@tk2msftngp13.phx.gbl...
>> 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.
>
>
> "cristalink" <cristalink@nospam.nospam> wrote in message
> news:%23B1g7YkCFHA.4004@tk2msftngp13.phx.gbl...
>> "igor" <no-spam@hotmail.com> wrote in message
>> news:O7AbwEkCFHA.3728@TK2MSFTNGP14.phx.gbl...
>>>
>>>> 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"
>>>
>>>
>>> "cristalink" <cristalink@nospam.nospam> wrote in message
>>> news:O83F7UjCFHA.444@TK2MSFTNGP09.phx.gbl...
>>>> 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
>>>>
>>>>
>>>> "igor" <no-spam@hotmail.com> wrote in message
>>>> news:OI9WA9iCFHA.2876@TK2MSFTNGP12.phx.gbl...
>>>>> 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.
>>>>>
>>>>>
>>>>> "cristalink" <cristalink@nospam.nospam> wrote in message
>>>>> news:O2uBPfiCFHA.4072@TK2MSFTNGP10.phx.gbl...
>>>>>> Your READ CAPACITY is probably malformed.
>>>>>>
>>>>>> --
>>>>>>
http://www.firestreamer.com - NTBackup to DVD and DV
>>>>>>
>>>>>>
>>>>>> <no-spam@hotmail.com> wrote in message
>>>>>> news:%238JBqhYCFHA.1936@TK2MSFTNGP14.phx.gbl...
>>>>>>> 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"
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Facebook
Twitter
Instagram