| Author |
Message |
Ehud
Guest
|
 Posted:
Mon Dec 06, 2004 11:52 pm Post subject:
ASPI: MODE SENSE locks computer up on a *specific* device |
|
|
Hello.
I'm using ASPI (Adaptec's 4.60) on Win98SE to send MODE SENSE 10 (SCSI
command 0x5A) requests to devices on the system. It works as expected
on two drives (an IDE CD-ROM and a Virtual drive), but on the 3rd, a
Sony IDE CD-RW drive, it locks the computer up.
This is very odd; I'd first expect an ASPI/SCSI error, then a program
crash, then a Windows crash, but not a complete lockup.
The same drive respondes fine to other things, such as INQUIRY or
REQUEST SENSE. Also, tracing the ASPI activity of another program, I
see it sends MODE SENSE 10 requests to that drive (among other things),
without any problems.
Any idea what's that all about?
NOTE: Programming questions seem common in comp.periphs.scsi, but if
anyone knows a more fitting group, let me know. :)
Thanks,
Ehud Shapira. |
|
| Back to top |
|
 |
Rob Turk
Guest
|
| Posted:
Tue Dec 07, 2004 3:10 am Post subject:
Re: MODE SENSE locks computer up on a *specific* device |
|
|
"Ehud" <ehudshapira@hotmail.com> wrote in message
news:1102359135.767197.55630@c13g2000cwb.googlegroups.com...
| Quote: | Hello.
I'm using ASPI (Adaptec's 4.60) on Win98SE to send MODE SENSE 10 (SCSI
command 0x5A) requests to devices on the system. It works as expected
on two drives (an IDE CD-ROM and a Virtual drive), but on the 3rd, a
Sony IDE CD-RW drive, it locks the computer up.
This is very odd; I'd first expect an ASPI/SCSI error, then a program
crash, then a Windows crash, but not a complete lockup.
|
Can you post the full CDB? Did you allocate enough buffer space to allow for
the returned data to be stored?
Rob |
|
| Back to top |
|
|
Ehud
Guest
|
| Posted:
Tue Dec 07, 2004 3:40 am Post subject:
Re: MODE SENSE locks computer up on a *specific* device |
|
|
| Quote: | Can you post the full CDB?
|
srb.CDBByte[0] = SCSI_MODE_SEN10;
srb.CDBByte[2] = 0x20; // page code
srb.CDBByte[8] = LEN_P20;
| Quote: | Did you allocate enough buffer space to allow for the returned data
to be stored? |
Yes, the same value specified in the SRB and CDB.
But even if this was a bad CDB or buffer overflow, it shouldn't lock
the computer, but complain/crash... which is why I see no way of
figuring this out.
And it works with the other devices.
Ehud. |
|
| Back to top |
|
|
Rob Turk
Guest
|
| Posted:
Tue Dec 07, 2004 12:26 pm Post subject:
Re: MODE SENSE locks computer up on a *specific* device |
|
|
"Ehud" <ehudshapira@hotmail.com> wrote in message
news:1102372836.365074.286520@z14g2000cwz.googlegroups.com...
| Quote: | Can you post the full CDB?
srb.CDBByte[0] = SCSI_MODE_SEN10;
srb.CDBByte[2] = 0x20; // page code
srb.CDBByte[8] = LEN_P20;
Did you allocate enough buffer space to allow for the returned data
to be stored?
Yes, the same value specified in the SRB and CDB.
But even if this was a bad CDB or buffer overflow, it shouldn't lock
the computer, but complain/crash... which is why I see no way of
figuring this out.
And it works with the other devices.
Ehud.
|
Do you have a SCSI bus analyzer to check if the CDB you send is also the CDB
you think you're sending? Do you explicitely clear the rest of the CDB
bytes?
Since you only set the LSB of the allocation length, can you try a 6-byte
Mode Sense? Can you make sure that LEN_P20 is an even number? Not all
devices like odd byte transfers. Last but not least, page 0x20 is vendor
unique, does your device properly support this page? There could be a
firmware bug which makes the device return more data than requested. That
can cause all sorts of problems.
Rob |
|
| Back to top |
|
|
Ehud
Guest
|
| Posted:
Wed Dec 08, 2004 1:15 am Post subject:
Re: MODE SENSE locks computer up on a *specific* device |
|
|
| Quote: | Do you have a SCSI bus analyzer to check if the CDB you send
is also the CDB you think you're sending? Do you explicitely
clear the rest of the CDB bytes?
Yes, I zero everything before setting the needed fields. I can look at |
the sent CDB using an ASPI wrapper that logs to file, but I can do just
the same from my program.
BTW: Speaking of SCSI analyzers, do you know any (hopefully free)? I
was using the AspiSpy source (from cdrlabs.com) with some modifications
and additions, but it's still not ideal (and why recreate something
that already exists?).
| Quote: | Since you only set the LSB of the allocation length, can you
try a 6-byte Mode Sense?
Tried that too, gets stuck too. |
| Quote: | Can you make sure that LEN_P20 is an even number?
It is. |
| Quote: | page 0x20 is vendor unique, does your device properly
support this page?
It doesn't. I'm sending this to all devices as part of the detection |
phase, and also, a user may override the detection, either way it
shouldn't be harmful, just useless.
| Quote: | There could be a firmware bug which makes the device
return more data than requested.
Possibly, but unless it's doing something REALLY wrong, it should only |
crash and not lock everything up, no?
Here's something else I found out; the device responds fine to standard
MODE SENSE pages, such as the CD/A control page (0x0E), and only causes
a lockup on vendor specifics. I may have a solution -- request all
pages (0x3F), see if the ones I'm after are available, and only then
query for them specifically.
But this mystery still bothers me, especially since there are no
lockups when the very same device gets these vendor-specific requests
from another program. I really hate unexplained and inconsistent
things when it comes to computers (and in general, actually... :).
..
~Ehud. |
|
| Back to top |
|
|
Rob Turk
Guest
|
| Posted:
Wed Dec 08, 2004 1:21 pm Post subject:
Re: MODE SENSE locks computer up on a *specific* device |
|
|
"Ehud" <ehudshapira@hotmail.com> wrote in message
news:1102450524.049145.265430@z14g2000cwz.googlegroups.com...
| Quote: |
BTW: Speaking of SCSI analyzers, do you know any (hopefully free)? I
was using the AspiSpy source (from cdrlabs.com) with some modifications
and additions, but it's still not ideal (and why recreate something
that already exists?).
|
On 32-bit Windows I use BusTrace (www.bustrace.com) which is an excellent
SCSI debugger, but not free. If you are professionally involved with SCSI
it's well worth it's money. I have not found anything terribly intelligent
for 16-bit platforms. I use a Verisys (now part of LeCroy) hardware analyzer
for that, or an old Ancot if it's an 8-bit narrow SCSI dinosaur..
| Quote: |
Since you only set the LSB of the allocation length, can you
try a 6-byte Mode Sense?
Tried that too, gets stuck too.
Can you make sure that LEN_P20 is an even number?
It is.
page 0x20 is vendor unique, does your device properly
support this page?
It doesn't. I'm sending this to all devices as part of the detection
phase, and also, a user may override the detection, either way it
shouldn't be harmful, just useless.
There could be a firmware bug which makes the device
return more data than requested.
Possibly, but unless it's doing something REALLY wrong, it should only
crash and not lock everything up, no?
|
Since page 0x20 is vendor unique the device may ignore the allocation length
you passed to it and return a large amount of data. It may for instance
return a diagnostics trace buffer of a fixed length, ignoring the allocation
length in your CDB. It wouldn't be pretty, but if Sony decides to implement
that page as an undocumented feature then there's little you can do about
it.
A SCSI target is always in control of the SCSI bus phases. If the drive
decides it wants to return a megabyte of data, it can. The host adapter can
try to stop it by raising ATN and trying to pass an Abort message to the
device, but if it decides to ignore that attempt, it can merrily go on
sending data bytes. Most 16-bit ASPI implementations will then keep on
receiving and storing that data, and overwrite anything in memory. That's a
pretty solid way to lock up a 16-bit environment, and even 32-bit
environments are not too well protected against such mishaps.
| Quote: | Here's something else I found out; the device responds fine to standard
MODE SENSE pages, such as the CD/A control page (0x0E), and only causes
a lockup on vendor specifics. I may have a solution -- request all
pages (0x3F), see if the ones I'm after are available, and only then
query for them specifically.
|
That would be the right thing to do. Get all pages, then find out how much
the drive returned and walk the list of pages.
| Quote: | But this mystery still bothers me, especially since there are no
lockups when the very same device gets these vendor-specific requests
from another program.
|
Get a SCSI analyzer to verify that the returned amount of data is consistent
with your allocated request. You could also try to allocate a huge buffer so
an overrun would still fit in that buffer and not overwrite your main
memory.
| Quote: | I really hate unexplained and inconsistent
things when it comes to computers (and in general, actually... :).
|
That's why we get paid the big bucks ;-) Oh wait...
Rob (looking for a job..) |
|
| Back to top |
|
|
Ehud Shapira
Guest
|
| Posted:
Tue Dec 14, 2004 12:27 am Post subject:
Re: MODE SENSE locks computer up on a *specific* device |
|
|
| Quote: | BusTrace... which is an excellent SCSI debugger, but not free. If you
are professionally involved with SCSI it's well worth it's money. |
No, nothing professional, just may want to peek at some ASPI/SPTI
activity at times.
| Quote: | I have not found anything terribly intelligent for 16-bit platforms.
That's definitely not for me. 16-bit?! I never really liked Windows |
3-. Did you? :)
| Quote: | even 32-bit environments are not too well protected against such
mishaps... |
It is supposed to be protected mode -- it should only crash the
relevant process.
| Quote: | You could also try to allocate a huge buffer
A 4MB buffer doesn't help. This never looked like a buffer problem. |
| Quote: | That's why we get paid the big bucks ;-)
You mostly get that for making programs, not trying to figure out why |
other programs act strange. Hmm... or do you?
| Quote: | Rob (looking for a job..)
What kind of job would that be? :) (something that involves hardware |
SCSI analyzers, I bet ;)
Anyway, the get all pages approach works (I got into some trouble at
first, but it was my and ASPI's fault). Besides that I'll try to get a
response from Sony (and possibly ask LiteOn too, maybe the firmware is
theirs). I'm still curious to know why the command works for the other
software, but now that I have an alternative I won't dwell on that too
much.
Thanks for the help, and if you can think of something else, tell me.
:)
~Ehud. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in