Re: SPTI firewire problem

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: cristalink (cristalink_at_nospam.nospam)
Date: 02/04/05 

Date: Fri, 4 Feb 2005 13:51:32 +1300

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
"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!
>
>> 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"
>
>
> "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"
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

Relevant Pages

  • Re: SPTI firewire problem
    ... "igor" wrote in message ... I am NOT sending this command to the drive explicitely. ... so READ CAPACITY was used. ... >>> you can send it via IDE - it still remains malformed CDB, ...
    (microsoft.public.development.device.drivers)
  • Re: SPTI firewire problem
    ... "igor" wrote in message ... I am NOT sending this command to the drive explicitely. ... so READ CAPACITY was used. ... >>> you can send it via IDE - it still remains malformed CDB, ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: SPTI firewire problem
    ... so READ CAPACITY was used. ... >> the *previous* command, not with READ CAPACITY. ... > Also, let me put it this way: unless I am terribly mistaken, malformed CDB ... > send it through: IDE or FireWire, ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: SPTI firewire problem
    ... I am NOT sending this command to the drive explicitely. ... But you can see from the SCSI log that both direction and size are ... >> CDB is malformed CDB, no more, no less. ... >> behaviour which is peculiar to FireWire only. ...
    (microsoft.public.development.device.drivers)
  • Re: SPTI firewire problem
    ... I am NOT sending this command to the drive explicitely. ... But you can see from the SCSI log that both direction and size are ... >> CDB is malformed CDB, no more, no less. ... >> behaviour which is peculiar to FireWire only. ...
    (microsoft.public.windowsxp.device_driver.dev)