[Keywords: IDE Buslogic ffs_valloc crash burn]
[Keywords: more than one bt BusLogic controller]
[Keywords: pine can't access terminal]

This is a long winded post.  I have 3 questions, #2
should be simplest to answer.

3) Pine.  Wanted to use this as the mailer on tandem.
Works fine on my box I do compiles on, yet the 
binary on tandem dies with the can't access err.
I'm confused....perhaps someone on this list knows an answer.

$ env
USER=marc
HOME=/home/marc
TERm=
LOGNAME=marc
TERM=vt100
PATH=/usr/bin:/bin:/sbin:/usr/sbin:/usr/local/bin
SHELL=/bin/sh
$ pine
Can't access terminal or input is not a terminal. Redirection of
standard input is not allowed. For example "pine < file" doesn't work. 

myname# env
USER=marc
HOME=/root
LOGNAME=marc
TERM=vt100
PATH=/sbin:/usr/sbin:/bin:/usr/bin
SHELL=/bin/csh
PWD=/usr/marc/net/pine3.91/bin
BLOCKSIZE=1k                                   

As you can see, the terminals are the same....got me stumped. :-(
(Oh yea, using the same terminal emulator when I try this.)
 

2) Is it possible to have more than one bustek (err buslogic) controller in
a NetBSD machine at one time?  If so, how?
Goal (eventual): 2 fast wide PCI SCSI controllers in the same 
box. 

Onto the main reason for this post.....

[Find this in netbsd-help.0010]
>From: James Lever <James.Lever@mailbox.uq.oz.au>
>Subject: adaptec 1542C/CF probs
>Just wondering if there is some major problems with the adaptec 1542C/CF
>and netbsd-1.0     ...
.......
>seem to get lots of kernel panics for no reason... etc I start an ftp and
>^Z and bg and kernel panic...  either ffs_valloc or some other ffs error
>and sometimes it has cored while starting system logger....
                                  
James hasn't responded to my e-mail.  He seems to have a problem 
similar to mine.                       

Details:
2 IDE hard drives

Jan 23 21:48:41 tandem /netbsd: wdc0 at isa0 port 0x1f0-0x1f7 irq 14
Jan 23 21:48:41 tandem /netbsd: wd0 at wdc0 drive 0: 610MB, 1240 cyl, 16 head, 6
3 sec, 512 bytes/sec <WDC AC2635F>
Jan 23 21:48:41 tandem /netbsd: wd0: using 16-sector 16-bit pio transfers, lba a
ddressing
Jan 23 21:48:41 tandem /netbsd: wd1 at wdc0 drive 1: 201MB, 1272 cyl, 9 head, 36
 sec, 512 bytes/sec <94354-230>
Jan 23 21:48:41 tandem /netbsd: wd1: using 16-sector 16-bit pio transfers, chs a
ddressing

2 or 3 Seagate drives  (3rd drive not hooked up)

Jan 23 21:48:41 tandem /netbsd: bt0 at isa0 port 0x330-0x333 irq 11 drq 5: versi
on 3.3, async, parity, 32 mbxs
Jan 23 21:48:41 tandem /netbsd: scsibus0 at bt0
Jan 23 21:48:41 tandem /netbsd: bt0 targ 0 lun 0: <SEAGATE, ST15230N, 0298> SCSI
2 0/direct fixed
Jan 23 21:48:41 tandem /netbsd: sd0 at scsibus0: 4095MB, 3992 cyl, 19 head, 110
sec, 512 bytes/sec
Jan 23 21:48:41 tandem /netbsd: bt0 targ 1 lun 0: <SEAGATE, ST15230N, 0298> SCSI
2 0/direct fixed
Jan 23 21:48:41 tandem /netbsd: sd1 at scsibus0: 4095MB, 3992 cyl, 19 head, 110
sec, 512 bytes/sec

IF the SCSI drives are formatted and not 'touched' (aka written to 
to any LARGE volume) they will keep there little magnetic minds from
reboot to reboot.  If you write a volume (seems greater than 5% full)
then the drives go out to lunch upon hard or soft reboot.


First I did an fsck to capture the 'disk problems'.
(normally it lists things like lost root inode)
The box crashed and burned.

Jan 23 21:47:32 tandem /netbsd: sd1: mode sense (4) returned nonsense; using fic
titious geometry    

After the crash.......

# fsck /dev/sd1a
** /dev/rsd1a
BAD SUPER BLOCK: MAGIC NUMBER WRONG

LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y

SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE
-b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE
SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8).


Relevant disktab entries....


seagate4gig: \
        :ty=winchester:ns#110:nt#19:nc#3992:\
        :dt=SCSI:\
        :pa#8343280:oa#0:ba#8192:fa#1024:ta=4.2BSD:\
        :pc#8343280:oc#0:bc#8192:fc#1024:

st1296:\
        :ty=winchester:ns#36:nt#9:nc#1272:\
        :dt=ST506:\
        :pa#412128:oa#0:ba#8192:fa#1024:ta=4.2BSD:\
        :pc#412128:oc#0:bc#8192:fc#1024:

seagate1gig:\
        :ty=winchester:ns#103:nt#5:nc#3992:\
        :dt=SCSI:\
        :pa#2055880:oa#0:ba#8192:fa#1024:ta=4.2BSD:\
        :pc#2055880:oc#0:bc#8192:fc#1024:

(and I believe I got the disktab thing right...as the st1296 is
new, like the SCSI disks.  The st1296 on the IDE controller isn't
crashing and burning like the SCSI.)

The disks were generated with:
diskpart
disklabel
newfs
in that order.

I don't believe it's a hardware problem anymore.  Why?  News will
run for 2-4 days on these drives, expire, etc la.  If it was hardware,
it should die in 2-4 days of constant pounding.

  
[Now to general comments, these are just observations....]

TekRam DC-820B Users Manual
(a SCSI cards) sez
(paraphrasing) You must put the ide drives before SCSI
drives in a hunt sequence if you want them found.

An assoicate of mine who hacks Linux made this
proclamation:
Yea, if I didn't have the IDE drives found first, then
I got all kindsa wierd problems.

Finally, the UnixWare that WAS running on this same
hardware did 'find' the IDE first, then the SCSI.