sconf on 5.0.7
Bob Bailin
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
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
"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
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
> > > 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
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