|
|
|
|
| Author |
Message |
peacekeeper
Guest
|
 Posted: Tue Feb 27, 2007 1:27 am Post subject: SCSI regocnized but not approachable |
 |
|
I'be got a DawiControl SCSI adapter (with bios) installed and upon
booting it finds the attached HDD's and assigns SCSI ID's (0 upto 7
where 7 is the PCI card itself) but as soon as an OS is being loaded
the drives are not found.
Strange enough I can access the drives when I boot with a SeaGate
bootdisk using FreeDos. and even more weird is the fact I can format
the drives from within DOS 6.22 (test environment) with a tool that
came with the card's driver software,
Sofar I've tried W2K, W2003 server, WIN98 and Ubuntu Linux and DOS
6.22 and nothing seems to be working.
What's wrong? |
|
| Back to top |
|
 |
Fix your Windows Problems - FAST.
FREE Safe Scan Registry Check. Locate & Fix Errors in Minutes!
|
|
Bruce Morgen
Guest
|
| Posted: Tue Feb 27, 2007 1:30 am Post subject: Re: SCSI regocnized but not approachable |
|
|
"peacekeeper" <paost712@gmail.com> wrote:
| Quote: | I'be got a DawiControl SCSI adapter (with bios) installed and upon
booting it finds the attached HDD's and assigns SCSI ID's (0 upto 7
where 7 is the PCI card itself) but as soon as an OS is being loaded
the drives are not found.
Strange enough I can access the drives when I boot with a SeaGate
bootdisk using FreeDos. and even more weird is the fact I can format
the drives from within DOS 6.22 (test environment) with a tool that
came with the card's driver software,
Sofar I've tried W2K, W2003 server, WIN98 and Ubuntu Linux and DOS
6.22 and nothing seems to be working.
What's wrong?
|
Got drivers for the card?
Odds are they're not
included with the OSs you
tried and, if so, that's
your problem. FreedDos
and MS-DOS access the
drives via the card's
SCSI BIOS and don't
require drivers, but the
others you mentioned do. |
|
| Back to top |
|
|
Michael Baeuerle
Guest
|
| Posted: Fri Mar 02, 2007 6:05 pm Post subject: Re: SCSI regocnized but not approachable |
|
|
Folkert Rienstra wrote:
| Quote: |
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, ASPI is just an API.
| Quote: | 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.
| Quote: | When starting DOS all seems to go right untill the drives drivers are
being loaded, the message "no drives found" comes up.
^^^^^^^^^^^^^^^
I don't know the Dawicontrol drivers but this message may simply mean
that no "DOS drives" (C:, D:, etc) are found because there is no
partition table and no filesystem on the disks.
Not with ASPI.
|
??? IMHO the API is not relevant for this question. 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. It is
the disk driver that may print such a message (regardless whether it
uses ASPI or another API).
| Quote: | 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
You simply have to add the hostadapter driver, the SCSI support itself
and the device class drivers are generic and integrated in Linux. For
DOS you have to install a complete SCSI subsystem because DOS have
nothing helpful integrated.
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.
They can be configured to be very verbose (and human readable) and are
vendor independent.
3) ASPI is not really vendor independent
This may or may not an ASPI design flaw but along to my experience ASPI
is not ASPI. You cannot combine an ASPI hostadapter driver with an
arbitrary ASPI device class driver from a different vendor - sometimes
such combinations don't work as expected. It is a good idea to always
use the device class drivers shipped with the hostadapter. With Linux
the abstraction and re-usage of known working code is much more
advanced.
4) Tools
On Linux there are many general purpose SCSI tools available out of the
box, for DOS you have to get them from the hostadapter vendor or second
sources. MS don't have useful things on the OS media for this purpose.
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.
The only advantage for DOS that I can see in this comparison is that DOS
is smaller and may boot a bit faster. Because most people use WindowsNT
with GUI today, there is no longer an advantage for DOS in the way "It
is always there" or "I already know how it works".
Micha
--
http://micha.freeshell.org |
|
| Back to top |
|
|
Folkert Rienstra
Guest
|
| Posted: Fri Mar 02, 2007 8:35 pm Post subject: Re: SCSI regocnized but not approachable |
|
|
"Michael Baeuerle" <michael.baeuerle@gmx.net> wrote in message news:bjglb4-k71.ln1@micha.freeshell.org
| Quote: | 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.
| Quote: | ASPI is just an API.
|
So? Same goes for drivers. It's the apps that matter.
| Quote: |
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.
If the BIOS routines fail so will very likely the driver's.
| Quote: |
When starting DOS all seems to go right untill the drives drivers are
being loaded, the message "no drives found" comes up.
^^^^^^^^^^^^^^^
I don't know the Dawicontrol drivers but this message may simply mean
that no "DOS drives" (C:, D:, etc) are found because there is no
partition table and no filesystem on the disks.
Not with ASPI.
??? IMHO the API is not relevant for this question.
|
Yes, it is.
| Quote: | 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.
| Quote: | 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.
| Quote: |
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.
| Quote: | You simply have to add the hostadapter driver, the SCSI support itself
and the device class drivers are generic and integrated in Linux.
|
For DOS you have to do nothing if you have a BIOS
| Quote: | 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.
| Quote: |
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.
| Quote: | They can be configured to be very verbose (and human readable) and are
vendor independent.
3) ASPI is not really vendor independent
|
Not in DOS, no.
In Windows the device dependent parts are covered by the device driver.
| Quote: | This may or may not an ASPI design flaw but along to my experience ASPI
is not ASPI.
You cannot combine an ASPI hostadapter driver with an
arbitrary ASPI device class driver from a different vendor
|
And why would you.
| Quote: | - sometimes such combinations don't work as expected.
|
Shrug.
| Quote: | It is a good idea to always use the device class drivers shipped with the
hostadapter. With Linux the abstraction and re-usage of known working
code is much more advanced.
4) Tools
On Linux there are many general purpose SCSI tools available out of the
box, for DOS you have to get them from the hostadapter vendor or second
sources. MS don't have useful things on the OS media for this purpose.
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.
| Quote: |
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.
One very good one, Bart's SCSITool, is for DOS.
It too has human readable error codes.
| Quote: | Because most people use WindowsNT
with GUI today, there is no longer an advantage for DOS in the way
"It is always there" or "I already know how it works".
Micha |
|
|
| Back to top |
|
|
peacekeeper
Guest
|
| Posted: Sat Mar 03, 2007 1:08 am Post subject: Re: SCSI regocnized but not approachable |
|
|
@ all
Thanks to the discussion here I found out what went wrong...
It was my misunderstanding that the SCSI drive(s) would be accesible
right after correct attachment to the (IDE mainboard) machine
I've low leveled the drives and created DOS partitions. et voila!
Guess the low level was a little overdone ;-)
SCSI disks are asking for another approach when IDE disks are present.
Anyhow thanks for for your efforts
B. |
|
| Back to top |
|
|
Fix your Windows Problems - FAST.
FREE Safe Scan Registry Check. Locate & Fix Errors in Minutes!
|
|
Folkert Rienstra
Guest
|
| Posted: Sat Mar 03, 2007 4:07 pm Post subject: Re: SCSI regocnized but not approachable |
|
|
"peacekeeper" <paost712@gmail.com> wrote in message news:1172862502.638566.178820@v33g2000cwv.googlegroups.com
| Quote: | @ all
Thanks to the discussion here I found out what went wrong...
It was my misunderstanding that the SCSI drive(s) would be accesible
right after correct attachment to the (IDE mainboard) machine
I've low leveled the drives and created DOS partitions. et voila!
Guess the low level was a little overdone ;-)
|
Yes.
| Quote: |
SCSI disks are asking for another approach when IDE disks are present.
|
No they don't.
The same goes for 'additional' IDE "when IDE disks are present".
| Quote: |
Anyhow thanks for for your efforts
B. |
|
|
| Back to top |
|
|
Michael Baeuerle
Guest
|
| Posted: Sat Mar 03, 2007 7:30 pm Post subject: Re: SCSI regocnized but not approachable |
|
|
Folkert Rienstra wrote:
| Quote: |
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? Seems that you can interpret
anything as "nonsense" that is not written in exactly the words you
would use.
| Quote: | [...]
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. The BIOS routines simply don't support
formatting of SCSI disks, so tools like the mentioned FMTSCSI cannot
work with them.
| Quote: | 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.
| Quote: | [...]
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>
| Quote: | 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 ...
| Quote: | 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.
|
I don't agree. For BIOS access you require help from the hostadapters
BIOS, for ASPI you require third party device class drivers. In both
cases 0% of the SCSI code is shipped from MS with DOS.
| Quote: | You simply have to add the hostadapter driver, the SCSI support itself
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?
| Quote: | 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,
or if you have more than 2 (sometimes 4) "direct access" devices,
or if your disk drive have removable media,
or ...
| Quote: | 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 ...
| Quote: | [...]
3) ASPI is not really vendor independent
Not in DOS, no.
[...]
This may or may not an ASPI design flaw but along to my experience ASPI
is not ASPI.
You cannot combine an ASPI hostadapter driver with an
arbitrary ASPI device class driver from a different vendor
And why would you.
|
To use known working components. 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.
| Quote: | [...]
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.
| Quote: | [...]
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.
| Quote: | 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".
Micha |
|
| Back to top |
|
|
wolfgang schneider
Guest
|
| Posted: Sun Mar 04, 2007 7:55 pm Post subject: Re: SCSI regocnized but not approachable |
|
|
In article <6u9ob4-tb1.ln1@micha.freeshell.org>,
michael.baeuerle@gmx.net says...
| Quote: | ......................
Nonsense. That's what FMTSCSI is for.
And running FMTSCSI does exactly what? Seems that you can interpret
anything as "nonsense" that is not written in exactly the words you
would use.
yes , michael . this is how our vollkiff likes to blow - must have had a |
hardened childhood . it is a pitty the two real experts in this group
fight that way , instead of trying to work together for best support .
sorry for poor english .....
--
gravity is still active
-<--@
gruss , wolfgang |
|
| Back to top |
|
|
Folkert Rienstra
Guest
|
| Posted: Thu Mar 08, 2007 5:52 am Post subject: Re: SCSI regocnized but not approachable |
|
|
"Michael Baeuerle" <michael.baeuerle@gmx.net> wrote in message news:6u9ob4-tb1.ln1@micha.freeshell.org
| Quote: | 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.
| Quote: | 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.
| Quote: |
[...]
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.
| Quote: | The BIOS routines simply don't support formatting of SCSI disks,
|
Which 99.9% of all users will never use.
| Quote: | so tools like the mentioned FMTSCSI cannot work with them.
|
So they don't work with them, so they work with ASPI.
| Quote: |
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.
| Quote: |
[...]
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.
| Quote: |
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>
| Quote: | I don't agree. For BIOS access you require help from the hostadap-
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.
/pedantic |
Does the term 'Linux zealot' ring a bell?
| Quote: |
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.
| Quote: |
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.
| Quote: | or if you have more than 2 (sometimes 4) "direct access" devices,
|
Yes, toy SCSI controllers do exist.
| Quote: | or if your disk drive have removable media,
|
Not a problem with most bios'ed SCSI controllers.
| Quote: | 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.
| Quote: |
[...]
3) ASPI is not really vendor independent
Not in DOS, no.
[...]
|
Trying to make a point by using a convenient snip?
| Quote: |
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.
| Quote: |
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.
| Quote: |
And why would you.
To use known working components.
|
Usually that is what you expect from a BIOS.
| Quote: | 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".
| Quote: |
[...]
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.
| Quote: |
[...]
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.
| Quote: |
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.
|
|
| Back to top |
|
|
|
|
| |
Watched Topics
Search
Register
Log in to check your private messages
Profile
Log in
Memberlist
Usergroups