sconf on 5.0.7

282 views
Skip to first unread message

Bob Bailin

unread,
Aug 7, 2003, 6:36:36 AM8/7/03
to
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.

Bob


Bela Lubkin

unread,
Aug 7, 2003, 5:54:15 PM8/7/03
to sco...@xenitec.ca
Bob Bailin wrote:

How about the following actual data:

# sconf -v
# cat /etc/conf/cf.d/mscsi
# hwconfig -h

-- then we'll have a chance of understanding the situation...

>Bela<

Bob Bailin

unread,
Aug 8, 2003, 1:49:28 PM8/8/03
to

"Bela Lubkin" <be...@sco.com> wrote in message
news:20030807215...@sco.com...

Sorry about that, here it is:

# 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
======== ============= === ===
================================================
kernel - - - rel=3.2v5.0.7 kid=2003-02-18
cpu - - - unit=1 family=6 type=Pentium III (model B)
cpuid - - - unit=1 vend=GenuineIntel tfms=0:6:11:1(4)
fpu - 13 - unit=1 type=80387-compatible
pci 0xcf8-0xcff - - am=1 sc=0 buses=3
PnP - - - nodes=0
clock - - - type=TSC/1.262291527Ghz
serial 0x3f8-0x3ff 4 - unit=0 type=Standard nports=1 base=0
16550A/16
serial 0x2f8-0x2ff 3 - unit=1 type=Standard nports=1 base=8
16550A/16
console - - - unit=vga type=0 num=12 scoansi=0 scroll=50
apm - - - PM v1.2
floppy 0x3f2-0x3f7 6 2 unit=0 type=135ds18
floppy - - - unit=1 type=96ds15
kbmouse 0x60-0x64 12 - type=Keyboard|PS/2 mouse (wheel) id=0x03
parallel 0xc000-0xc002 5 - unit=3
parallel 0x378-0x37a 7 - unit=0
udi - - - UDI environment
adapter - - - ha=0 type=usb_msto UDI SCSI HBA
adapter 0x1f0-0x1f7 14 - type=IDE ctlr=primary dvr=wd
adapter 0xc000-0xc0ff 10 - type=dpti ha=0 id=7, PCI, v1.12
eeE0 0xc400-0xc41f 5 - type=EE PRO/100+ 00:02:b3:a4:2d:5f
cd-rom - - - type=IDE unit=0 ctlr=pri cfg=mst dvr=Srom->wd
tape - - - type=S ha=0 id=3 lun=0 bus=1 ht=dpti unit=0
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
usb_uhci - 9 - PCI bus=0 dev=7 func=2
usb_uhci - 9 - PCI bus=0 dev=7 func=3
cpu - 255 - unit=2 family=6 type=Pentium III (model B)
cpuid - - - unit=2 vend=GenuineIntel tfms=0:6:11:1(4)
fpu - - - unit=2 type=80387-compatible
Stp-0 - - - Vnd=SONY Prd=SDT-11000 Rev=0200
Srom-0 - - - Vnd=TOSHIBA Prd=CD-ROM XM-6402B Rev=1008
#

Bob


Yves Leclerc

unread,
Aug 8, 2003, 4:07:32 PM8/8/03
to
The tape drive does not automatically appear in the list of active devices,
unless you access it first with a tape command (tar, cpio, tape etc....)
Then, it should appear correctly.

Yves


"Bob Bailin" <72027...@compuserve.com> wrote in message
news:bgta4s$iph$1...@ngspool-d02.news.aol.com...

Bela Lubkin

unread,
Aug 8, 2003, 8:51:14 PM8/8/03
to sco...@xenitec.ca
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.

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<

Bob Bailin

unread,
Aug 11, 2003, 4:11:22 PM8/11/03
to

"Bela Lubkin" <be...@sco.com> wrote in message
news:20030809005...@sco.com...

Stp dpti 0 1 3 0


Srom wd 0 0 0 0
Sdsk dpti 0 0 0 0

>


> 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<

I suppose I can live with this glaring omission. I'll pass this along
to Adaptec just in case they ever plan to update this driver.
Thanks again, Bela!

Bob


Reply all
Reply to author
Forward
0 new messages