Re: SCSI regocnized but not approachable
- From: "Folkert Rienstra" <see_reply-to@xxxxxxxx>
- Date: Thu, 8 Mar 2007 00:52:42 +0100
"Michael Baeuerle" <michael.baeuerle@xxxxxxx> wrote in message news:6u9ob4-tb1.ln1@xxxxxxxxxxxxxxxxxxx
Folkert Rienstra wrote:
Michael Baeuerle wrote:
Folkert Rienstra wrote:
Michael Baeuerle wrote:
[...]
To format a SCSI disk you have to send a FORMAT UNIT command to the disk
No you don't (have to).
(the disk itself will then do the job alone). A normal PC BIOS do not
support such things because it was not designed for SCSI.
That's why you have ASPI.
You nevertheless have to send the command yourself,
Nonsense. That's what FMTSCSI is for.
And running FMTSCSI does exactly what?
Send the FORMAT UNIT command, maybe? Just a wild guess.
Seems that you can interpret anything as "nonsense" that is not written in
exactly the words you would use.
It's nonsense when it is nonsense, basta. Feel free not to write nonsense.
[...]
Try this tool again without loading the drivers and it will fail.
So what.
At least the hostadapter drivers are loaded and the access have not used
the BIOS routines.
There is nothing wrong with using the BIOS routines.
Yes, there is nothing wrong.
Good.
The BIOS routines simply don't support formatting of SCSI disks,
Which 99.9% of all users will never use.
so tools like the mentioned FMTSCSI cannot work with them.
So they don't work with them, so they work with ASPI.
If the BIOS routines fail so will very likely the driver's.
No, because APIs like ASPI support SCSI formatting, the BIOS
routines do not.
Which is not a problem for the normal operations of what harddrives
are used for, storing data.
[...]
Even with CAM or any
other API you have a hostadapter driver for hardware abstraction.
On top of this you have device class drivers, a disk driver in this case.
Correct. It looks for drives and it depends on ASPI to see them.
<pedantic>
It depends on the API that the device
class driver is designed for to see them.
</pedantic>
It is the disk driver that may print such a message (regardless whether it
uses ASPI or another API).
I don't think it concerns itself with partitioning. That's for DOS.
I am not a DOS expert but I have seen DOS ASPI disk drivers that print
the drive letters for every disk - maybe or not for cosmetic purposes only ...
As do PC bioses for IDE.
You formerly wrote:^^^^^
Sofar I've tried W2K, W2003 server, WIN98 and Ubuntu Linux and DOS[...]
IMHO you should use Linux for testing (it is much better suited for this
task as DOS).
No it isn't.
OK, you asked for it ;-) Here are 5 reasons:
1) SCSI is supported by Linux
By DOS too, through BIOS and/or through ASPI.
<pedantic>
I don't agree. For BIOS access you require help from the hostadap-</pedantic>
ters BIOS, for ASPI you require third party device class drivers.
In both cases 0% of the SCSI code is shipped from MS with DOS.
Does the term 'Linux zealot' ring a bell?
You simply have to add the hostadapter driver, the SCSI support it-
self and the device class drivers are generic and integrated in Linux.
For DOS you have to do nothing if you have a BIOS
We are talking about SCSI in general, how do you debug a problem with a
CDROM or tape drive using the BIOS?
By running SCSITool.
For DOS you have to install a complete SCSI subsystem because DOS
have nothing helpful integrated.
It simply uses BIOS.
Only if you have a biosless controller do you need ASPI and ASPI drivers.
Or if your drive is not a "direct access" device,
If it doesn't work it's probably broken.
or if you have more than 2 (sometimes 4) "direct access" devices,
Yes, toy SCSI controllers do exist.
or if your disk drive have removable media,
Not a problem with most bios'ed SCSI controllers.
or ...
2) Linux has an additional abstraction layer.
There are hostadapter drivers for hardware abstraction and there are
device class drivers (up to this point similar to the DOS/ASPI scheme).
The difference is the additional SCSI midlayer driver. It contains
routines that are neither hardware nor device class dependent. One thing
that this additional driver can do for you is logging of error messages.
You can just run the mfgr diagnostics for that.
It's new to me that mfgr is a part of DOS ...
So what else is new.
[...]
3) ASPI is not really vendor independent
Not in DOS, no.
[...]
Trying to make a point by using a convenient snip?
This may or may not be an ASPI design flaw but along to my
experience ASPI is not ASPI.
It should be from the program side.
Just as with BIOS, drivers etc.
Every body makes mistakes.
You cannot combine an ASPI hostadapter driver with an
arbitrary ASPI device class driver from a different vendor.
Well, if you can't then maybe it is not arbitrary, meaning the
vendor did not want you to use it because you likely didn't pay
for it, because you are not using the product that it came with.
Arbitrary is not necessarily the same as generic.
And why would you.
To use known working components.
Usually that is what you expect from a BIOS.
If I search for a nontrivial problem I normally exclude
one possible error source after the other until I know
exactly where the problem is located.
The device class driver is one possible error sources.
Well, there goes your "known working components".
[...]
5) Selfmade options
Most people won't do but if you have the skills you can write your own
tools. The whole framework and documentation is right there, you have
to pay no cent. If all fails you can look at the source code of the Linux
drivers to see what they are doing (again it is right there, you don't
have to ask MS or the hostadapter vendor). With closed source software
like DOS and proprietary vendor drivers such things are much harder.
Maybe that's so because there is a lack of real SCSI diagnostic programs.
This is true - because you don't need them here.
Isn't it nice when you can reinvent the wheel over and over again.
Keeps you off the street for years.
[...]
The only advantage for DOS that I can see in this comparison
is that DOS is smaller and may boot a bit faster.
Most diagnostic programs are for DOS.
With Linux you don't need a "diagnostic program", the OS will
tell you about errors. The tools are mainly for configuration.
The OS is not a diagnostic, it only shows the symptoms.
One very good one, Bart's SCSITool, is for DOS.
It too has human readable error codes.
I translate this to "Bart's SCSITool is better suited for this task
as the Linux tools" - maybe, but this does not disprove my statement
"Linux it is much better suited for this task as DOS".
Only if Linux tops Bart's SCSITool. Bet it doesn't.
Oh, and there 's a conclusion in that sentence, if you missed it.
.
Micha
- References:
- Re: SCSI regocnized but not approachable
- From: Folkert Rienstra
- Re: SCSI regocnized but not approachable
- From: Michael Baeuerle
- Re: SCSI regocnized but not approachable
- From: Folkert Rienstra
- Re: SCSI regocnized but not approachable
- From: Michael Baeuerle
- Re: SCSI regocnized but not approachable
- Prev by Date: Re: Seagate ST32430N upgrade
- Next by Date: Re: Seagate ST32430N upgrade
- Previous by thread: Re: SCSI regocnized but not approachable
- Next by thread: Re: SCSI regocnized but not approachable
- Index(es):
Relevant Pages
|
Loading
