Wanting to probe SCSI bus to discover devices
Stuart J. Browne
I have a server on the other side of the country, which is having problems
with the tape drive. I just want to confirm that the ID that the device is
listed under is the one that it is actually configured at.
I was wondering if there are any SCO utilities to query a SCSI adapter to
get it to report that devices are currently conected to it via a console
interface.
I had a quick look through 'hw', and although listing the controller devices
happily, it doesn't list the devices connected.
I had a quick look at 'sconf', and the -p looks favourable, but given the
man page's "Don't run this!" type of message, I figured I'd ask if anybody
knew of a 'better' way (apart from rebooting with someone infront of the
machine).
It's an alad type controller (AHA-2940)..
anyway :) thanks.
bkx
Stuart J. Browne
news:9gov2o$iq2$1...@perki.connect.com.au...
*kicks self*
SCO:Unix::5.0.5Eb rs505a.Unix505.1.0a oss497c.Unix505.1.0a
oss600a.Unix505
Jean-Pierre Radley
| I was wondering if there are any SCO utilities to query a SCSI adapter to
| get it to report that devices are currently conected to it via a console
| interface.
You'd think there would be a simple utility provided by SCO, but if so,
I don't know its name.
Get cdrecord, which compiles very straightforwardly on OpenServer 5.
(You can get not-the-latest binary from Skunkware.) Besides actually
burning CDs, it also answers your question:
# cdrecord -scanbus
Cdrecord 1.10 (i386-pc-sco3.2v5.0.6) Copyright (C) 1995-2001 Jvrg Schilling
Using libscg version 'schily-0.5'
scsibus0:
0,0,0 0) 'QUANTUM ' 'ATLAS10K2-TY184L' 'DDD6' Disk
0,1,0 1) *
0,2,0 2) 'HP ' 'C1537A ' 'L005' Removable Tape
0,3,0 3) *
0,4,0 4) *
0,5,0 5) 'MATSHITA' 'CD-R CW-7503 ' '1.08' Removable CD-ROM
0,6,0 6) *
0,7,0 7) *
Clearly this is not just the kernel's notion of what's ought to be at
SCSI IDs 1, 2 and 5, 'cause the kernel doesn't know from Quantum, HP, or
Matshita. The program has actually read those bytes from those devices.
(One peculiarity: the tape drive is reported whether or not there's a
cartridge inserted, but the CD drive isn't reported unless there's a
disk inserted.)
--
JP
Stuart J. Browne
news:2001061922...@jpradley.jpr.com...
> Stuart J. Browne propounded (on Wed, Jun 20, 2001 at 11:41:56AM +1000):
> | I was wondering if there are any SCO utilities to query a SCSI adapter
to
> | get it to report that devices are currently conected to it via a console
> | interface.
>
> You'd think there would be a simple utility provided by SCO, but if so,
> I don't know its name.
>
> Get cdrecord, which compiles very straightforwardly on OpenServer 5.
> (You can get not-the-latest binary from Skunkware.) Besides actually
> burning CDs, it also answers your question:
<SNIP>
> (One peculiarity: the tape drive is reported whether or not there's a
> cartridge inserted, but the CD drive isn't reported unless there's a
> disk inserted.)
It's always something simple isn't it? :) Use CDRecord under Linux, and
have an old version on the SCO box, just never thought of using it.
It appears as if the 1.8a19 I've got on the SCO bo xis a pain, will grab a
newer one.
Thanks JP.
Stuart J. Browne
for the record:
313# /usr/local/bin/cdrecord -scanbus
Cdrecord 1.9 (i586-pc-sco3.2v5.0.5) Copyright (C) 1995-2000 Jörg Schilling
Using libscg version 'schily-0.1'
scsibus0:
0,0,0 0) *
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
scsibus1:
1,0,0 100) *
1,1,0 101) *
1,2,0 102) 'SONY ' 'SDT-9000 ' '0400' Removable Tape
1,3,0 103) *
1,4,0 104) *
1,5,0 105) *
1,6,0 106) *
1,7,0 107) *
thanks again JP.
John Gray
sconf -v
Be aware that some HBA drivers have problems with this. The end result
is a panic. If your system is okay, then sconf -v will be just fine.
Unfortunately there is only one way to find out. The sconf util is
used during install to query the scsi bus and reconfigure the inkernel
scsi addresses of the devices attached. It can add/delete/reconfigure
the scsi subsystem on the fly.
good luck
-john
Jean-Pierre Radley
| "Stuart J. Browne" wrote:
| >
| > I have a server on the other side of the country, which is having problems
| > with the tape drive. I just want to confirm that the ID that the device is
| > listed under is the one that it is actually configured at.
|
My impression is that 'sconf -v' simply reports what the kernel expects to
find at various SCSI ID numbers on each bus and does not actually probe
any devices at those locations to see if they're present and what their
ROM chip reports by way of further identication; whereas the 'cdrecord
-scanbus' command that I suggested yesterday does in fact get bytes from
the hardware.
--
JP
John DuBois
In article <9gov2o$iq2$1...@perki.connect.com.au>,
Stuart J. Browne <stu...@promed.com.au> wrote:
+I had a quick look at 'sconf', and the -p looks favourable, but given the
+man page's "Don't run this!" type of message, I figured I'd ask if anybody
+knew of a 'better' way (apart from rebooting with someone infront of the
+machine).
I think that the warnings apply mainly to trying to change the scsi
configuration with sconf. I really, really doubt that sconf -v/-p do anything
less benign than cdrecord does. I've never had a problem using it.
John
--
John DuBois jo...@sco.com KC6QKZ/AE
I wish to God these calculations had been executed by steam. - Charles Babbage
John DuBois
In article <2001062013...@jpradley.jpr.com>,
Jean-Pierre Radley <j...@jpr.com> wrote:
+My impression is that 'sconf -v' simply reports what the kernel expects to
+find at various SCSI ID numbers on each bus and does not actually probe
+any devices at those locations to see if they're present and what their
+ROM chip reports by way of further identication; whereas the 'cdrecord
+-scanbus' command that I suggested yesterday does in fact get bytes from
+the hardware.
Nope - it looks that way, but only because 'sconf -v' prints its output in
mscsi format. 'sconf -v' really does generate its output from a scan.
Ronald J Marchand
news:9gqo3t$i6t$1...@hobbes.sco.com...
>
> In article <2001062013...@jpradley.jpr.com>,
> Jean-Pierre Radley <j...@jpr.com> wrote:
> +My impression is that 'sconf -v' simply reports what the kernel expects
to
> +find at various SCSI ID numbers on each bus and does not actually probe
> +any devices at those locations to see if they're present and what their
> +ROM chip reports by way of further identication; whereas the 'cdrecord
> +-scanbus' command that I suggested yesterday does in fact get bytes from
> +the hardware.
>
> Nope - it looks that way, but only because 'sconf -v' prints its output in
> mscsi format. 'sconf -v' really does generate its output from a scan.
I have a machine configured with an external removable fixed disk @ Sdsk 0 0
4 0. I turn the unit's power off and 'sconf -v' continues to report the
device.
Jean-Pierre Radley
Same behavior if you detach the SCSI cable?
--
JP
Ronald J Marchand
To my surprise .. Yes. I would have expected the bus to freak out, but it
didn't. I left alad out of the above information. This is 5.0.6 also.
I also booted the machine with the unit off and it was not reported. I
turned it on and it still was not reported. So I guess that it does not
poll the bus.
Ron
Jean-Pierre Radley
| Jean-Pierre Radley <j...@jpr.com> wrote in message
| news:2001062016...@jpradley.jpr.com...
| > Ronald J Marchand propounded (on Wed, Jun 20, 2001 at 07:06:12PM +0000):
| > | John DuBois <jo...@sco.COM> wrote in message
| > | news:9gqo3t$i6t$1...@hobbes.sco.com...
| > |
| > | > In article <2001062013...@jpradley.jpr.com>, Jean-Pierre
| > | > Radley <j...@jpr.com> wrote: +My impression is that 'sconf -v'
| > | > ID numbers on each bus and does not actually probe any devices
| > | > at those locations to see if they're present and what their
| > | > fact get bytes from the hardware.
| > | >
| > | > Nope - it looks that way, but only because 'sconf -v' prints
| > | > its output in mscsi format. 'sconf -v' really does generate its
| > | > output from a scan.
| > |
| > | I have a machine configured with an external removable fixed
| > | disk @ Sdsk 0 0 4 0. I turn the unit's power off and 'sconf -v'
| > | continues to report the device.
| >
| > Same behavior if you detach the SCSI cable?
|
| To my surprise .. Yes. I would have expected the bus to freak out,
| but it didn't. I left alad out of the above information. This is
| 5.0.6 also.
|
| I also booted the machine with the unit off and it was not reported.
| I turned it on and it still was not reported. So I guess that it does
| not poll the bus.
Roland: Your message was practially unreadable -- please use 'par' to
reformat before sending out stuff with so many nested quotes.
John: what say you?
--
JP
----- End forwarded message -----
--
JP
John Gray
It does indeed poll the BUS *but* during the first poll it build an
internal
table. From that point on it uses the table entries for output and
won't do
further scans. I don't remember if there was an option to flush the
table.
-john
Bill Vermillion
Ronald J Marchand <rjm...@home.com> wrote:
>Jean-Pierre Radley <j...@jpr.com> wrote in message
>news:2001062016...@jpradley.jpr.com...
>> Ronald J Marchand propounded (on Wed, Jun 20, 2001 at 07:06:12PM +0000):
>> | John DuBois <jo...@sco.COM> wrote in message
>> | news:9gqo3t$i6t$1...@hobbes.sco.com...
>> | > In article <2001062013...@jpradley.jpr.com>,
>> | > Jean-Pierre Radley <j...@jpr.com> wrote: +My impression is
>> | > that 'sconf -v' simply reports what the kernel expects +to
>> | > +find at various SCSI ID numbers on each bus and does not
>> | > actually probe +any devices at those locations to see if
>> | > they're present and what their +ROM chip reports by way
>> | > of further identication; whereas the 'cdrecord +-scanbus'
>> | > command that I suggested yesterday does in fact get bytes
>> | > from +the hardware.
>> | > Nope - it looks that way, but only because 'sconf -v' prints
>> | > its output in mscsi format. 'sconf -v' really does generate
>> | > its output from a scan.
>> |
>> | I have a machine configured with an external removable fixed
>> | disk @ Sdsk 0 0 4 0. I turn the unit's power off and 'sconf -v'
>> | continues to report the device.
>> Same behavior if you detach the SCSI cable?
>To my surprise .. Yes. I would have expected the bus to freak out,
>but it didn't. I left alad out of the above information. This is
>5.0.6 also.
>I also booted the machine with the unit off and it was not
>reported. I turned it on and it still was not reported. So I guess
>that it does not poll the bus.
That is typically behaviour in most Unix system. The bus is
scanned when it boots and reports the devices.
They are many OSes [UW 2 and 7, and SGI's IRIX are the ones I've
used that do this] do dynamic assignment of ID's on boot.
Thus you can remove a device, change it's ID, and reattach, and
when it the system reboots the new ID will point to the correct
device. No more adding devices with ID's into the kernel.
Unless you have a utility to force a rescan of the bus [the
programs which do this as a side-effect were reported here] then
reboots are away of life.
Some of Unix variants extent today have utilities which permit
rescan, resets, issue SCSI cmds to the device, manipulate code
pages, etc.
My feeling is that the extreme utilites should almost be left as
add-on packages, or as in the fx in SGI require you to read and
undersdtand the man pages just to be able to get the program into
a mode that could, if used wrong, make your drive totally unuseable
until it goes back to the factrory. A simple and obvious rescan
utility would be desirable however.
--
Bill Vermillion - bv @ wjv . com
John DuBois
In article <2001062111...@jpradley.jpr.com>,
Jean-Pierre Radley <j...@jpr.com> wrote:
+Ronald J Marchand propounded (on Thu, Jun 21, 2001 at 05:47:02AM +0000):
+| Jean-Pierre Radley <j...@jpr.com> wrote in message
+| news:2001062016...@jpradley.jpr.com...
+| > Ronald J Marchand propounded (on Wed, Jun 20, 2001 at 07:06:12PM +0000):
+| > | John DuBois <jo...@sco.COM> wrote in message
+| > | news:9gqo3t$i6t$1...@hobbes.sco.com...
+| > |
+| > | > In article <2001062013...@jpradley.jpr.com>, Jean-Pierre
+| > | > Radley <j...@jpr.com> wrote: +My impression is that 'sconf -v'
+| > | > simply reports what the kernel expects to find at various SCSI
+| > | > ID numbers on each bus and does not actually probe any devices
+| > | > at those locations to see if they're present and what their
+| > | > ROM chip reports by way of further identication; whereas the
+| > | > 'cdrecord -scanbus' command that I suggested yesterday does in
+| > | > fact get bytes from the hardware.
+| > | >
+| > | > Nope - it looks that way, but only because 'sconf -v' prints
+| > | > its output in mscsi format. 'sconf -v' really does generate its
+| > | > output from a scan.
+| > |
+| > | I have a machine configured with an external removable fixed
+| > | disk @ Sdsk 0 0 4 0. I turn the unit's power off and 'sconf -v'
+| > | continues to report the device.
+| >
+| > Same behavior if you detach the SCSI cable?
+|
+| To my surprise .. Yes. I would have expected the bus to freak out,
+| but it didn't. I left alad out of the above information. This is
+| 5.0.6 also.
+|
+| I also booted the machine with the unit off and it was not reported.
+| I turned it on and it still was not reported. So I guess that it does
+| not poll the bus.
+
+Roland: Your message was practially unreadable -- please use 'par' to
+reformat before sending out stuff with so many nested quotes.
+
+John: what say you?
sconf -v returns information from a kernel table that is indeed produced by a
bus scan.
Matt Schalit
>They are many OSes [UW 2 and 7, and SGI's IRIX are the ones I've
>used that do this] do dynamic assignment of ID's on boot.
>
>Thus you can remove a device, change it's ID, and reattach, and
>when it the system reboots the new ID will point to the correct
>device. No more adding devices with ID's into the kernel.
>--
>Bill Vermillion - bv @ wjv . com
Uw7 also gives itself a little crutch finding the
devices that were switched around, with a subsystem
called sdighost. Most of you probably know how it
works, but here's some info if you're interested.
(Don't put something at the old device address too soon)
(Moving devices isn't as painless as the marketing hype
because there's also tape backup/restore ramifications
that the man page doesn't list)
I had pasted in the first three paragraphs from the
man(1M) sdighost page, but here's a link instead, if
anyone wants to read about it.
http://uw7doc.sco.com/cgi-bin/man/man?sdighost
I like sdighost (now that I know about it :)
Matt
------------------------------------------------------------
Matt Schalit
>It does indeed poll the BUS *but* during the first poll it build an
>internal
>table. From that point on it uses the table entries for output and
>won't do
>further scans. I don't remember if there was an option to flush the
>table.
>-john
For UnixWare 7 running Veritas, you can use vxdiskadm to
rescan the scsi bus for drives that have been moved, but
it's specialized. You may be refering to a more general
approach.
If someone searches http://uw7doc.sco.com/ for
"Menu Interface Operations"
they can read up on it.
Matthew
Bill Vermillion
Matt Schalit <msch...@pacbell.net> wrote:
>On Thu, 21 Jun 2001 16:27:52 GMT, bi...@wjv.com (Bill Vermillion) wrote:
>>They are many OSes [UW 2 and 7, and SGI's IRIX are the ones I've
>>used that do this] do dynamic assignment of ID's on boot.
>>Thus you can remove a device, change it's ID, and reattach, and
>>when it the system reboots the new ID will point to the correct
>>device. No more adding devices with ID's into the kernel.
>Uw7 also gives itself a little crutch finding the
>devices that were switched around, with a subsystem
>called sdighost. Most of you probably know how it
>works, but here's some info if you're interested.
The first iNTEL based Unix I used that automatically discoverd
the changed ID's came in a big red box labeled Novell. It was
called Unixware 1.3 :-)
I also had a probem when I put UW 2 on a system on which there was
an ubooted 1.3 drive. 2 'discovered' the first drive and the OS
incompatilbilites and it's attempt to fix what it thought was
broken really did break. Automagic discovery can be good, but it
can also kill you if you have a system that doesn't fit the model
those who built the scripts had in mind. We really do need more
"I" in the supposed AI of the install systems.
>(Don't put something at the old device address too soon)
>(Moving devices isn't as painless as the marketing hype
>because there's also tape backup/restore ramifications
>that the man page doesn't list)
The IRIX systems handled that flawlessly. But if you hardcode
to a device, instead of the linked generic name expect all sorts of
fun/problems.