A.P. Lawrence

Best of the Newsgroups: OSR5 sconf scsi probe

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

More info on how sconf works

From: Bela Lubkin <belal@sco.com>
Subject: Re: sconf on 5.0.7
Date: Sat, 9 Aug 2003 00:51:14 GMT References: <bgta4s$iph$1@ngspool-d02.news.aol.com> <20030807215415.GL24551@sco.com> <IoRYa.18792$Vx2.9621447@newssvr28.news.prodigy.com>

Bob Bailin wrote:

> > > While following the thread for "SCO 5.0.7 and Tape Drive", I tried
> > > using the sconf -v command on my own system.
> > >
> > > The results showed only my Sdsk and Srom devices, but not
> > > the Stp device.
> > >
> > > Sdsk is a raid on dpti ha#0, bus=0, id=0, lun=0
> > > Srom is on wd ha#0, bus=0 (pri), id=0 (master)
> > > Stp is on dpti ha#0, bus=1, id=2, lun=0
> > >
> > > All of the above devices work perfectly, I was just
> > > surprised that the Stp doesn't show. It is listed in mscsi
> > > as it should be. Does it have something to do with the
> > > device being on bus 1?
> > >
> > > I tried sconf -i to add it manually to the table, and there
> > > were no complaints executing the command, but a
> > > subsequent sconf -v didn't change.

> # sconf -v
> Srom    wd      0       0       0       0
> Sdsk    dpti    0       0       0       0
> 
> # cat /etc/conf/cf.d/mscsi
> *ha     attach  number  ID      lun     bus
> *
> dpti    Sdsk    0       0       0       0
> wd      Srom    0       0       0       0
> dpti    Stp     0       3       0       1
> 
> # hwconfig -h
> device      address    vec dma comment
> ======== ============= === === ================================================
> adapter  0xc000-0xc0ff 10   -  type=dpti ha=0 id=7, PCI, v1.12
> tape           -        -   -  type=S ha=0 id=3 lun=0 bus=1 ht=dpti unit=0
> Stp-0          -        -   -  Vnd=SONY Prd=SDT-11000 Rev=0200
> disk           -        -   -  type=S ha=0 id=0 lun=0 bus=0 ht=dpti unit=0
> Sdsk           -        -   -  cyls=2231 hds=255 secs=63 unit=0
> Sdsk-0         -        -   -  Vnd=ADAPTEC Prd=RAID-1 Rev=370F

[culled and reorganized]

Ok, it looks like it's exactly as you said -- but now I understand what
you said a lot more clearly.

Lone-Tar Backup and Disaster Recovery
for Linux and Unix

Suppose you run this, what do you get?

  lines=`sconf -r`
  line=1
  while [ $line -le $lines ]; do
    sconf -g $line
    line=`expr $line + 1`
  done

That should dump out the contents of the in-kernel SCSI configuration.
(`sconf` really ought to have a flag to do so automatically.)

`sconf -v` is something else entirely -- it is an order to actually go
out and probe the SCSI buses, while what I've just done is to dump the
tables already in the kernel.

It's possible that the `sconf -v` probe doesn't scan buses >0; or maybe
it miscommunicates with "dpti" as to how many buses your adapter has.

Indeed.  I have a copy of "dpti" BTLD 1.12 and I can see that it does
not support the xx_entry() subfunction SCSI_GET_LIMITS.  Without that
support, the kernel believes it's a 1-bus, 8-ID adapter.

So, it boils down to a bug in the "dpti" driver.

Fortunately, the missing subfunction is used _only_ by `sconf`, so the
entire loss of functionality is (1) `sconf -v` doesn't find your tape
drive, and (2) during ISL, you will not be offered to install onto or
partition any devices on buses >0 or IDs >7.

>Bela<