Date: Mon, 20 Feb 1995 21:46:35 +0500 From: potter@bev.net (Mark Potter) To: bugs@FreeBSD.org Subject: SCSI problems (pas & sea) w/ solutions Message-ID: <199502210258.VAA20915@quackerjack.cc.vt.edu>
next in thread | raw e-mail | index | archive | help
In my system I have two possible SCSI adapters. One is just a simple 8-bit
SCSI card, the other is hanging off of my sound card. Any ways I had problems
with both of them when installing FreeBSD v2.0.
When I first tired to install FreeBSD v2.0, the new kernel just outright
panicked on boot of the new kernel. It panicked right after the pas driver
was loaded, so assuming it was associated with my sound card, I pulled the
card. I was then able to complete the installation. I then set to getting
one or both of my SCSI ports operational.
First I worked on my FD-850. I thought I reported this one before, but may be
not. Since I had the card operational before under 1.1.5 I applied the same
basic patch that I used there. The basic problem is the seaport device driver
attempts to identify what SCSI card is installed by looking for the copyright
message in the boot ROM on the card. The problem is, my card had no boot ROM.
The driver that assumes that there is no Future Domain or Seagate SCSI
controller. My solution is a bit hackish, but is operational. A correct
solution would be to find some other means of identifying the existence of FD
or Seagate card. The changes I made to the /usr/src/i386/isa/seagate.c where
to the sea_probe function as follows:
*** seagate.c Sun Feb 5 22:49:10 1995
--- original/seagate.c Sat Feb 4 21:37:53 1995
***************
*** 499,525 ****
break;
}
if(j == NUM_SIGNATURES) {
! # if SEA_ASSUME
! printf( "sea: Board type unknown at address 0x%lx, assuming %s\n",
! sea->basemaddr,
! # if SEA_ASSUME==FD
! "FD"
! # elif SEA_ASSUME==SEAGATE
! "SEAGATE"
! # else
! # error Unknown SEA_ASSUME value.
! # endif
! );
! sea->ctrl_type = SEA_ASSUME;
! # else
! # ifdef SEADEBUG
! printf("sea: Board type unknown at address 0x%lx\n",
sea->basemaddr);
! # endif
! seadata[unit]=NULL;
! free(sea, M_TEMP);
! return(0);
! # endif
}
/* Find controller and data memory addresses */
--- 499,511 ----
break;
}
if(j == NUM_SIGNATURES) {
! #ifdef SEADEBUG
! printf("sea: Board type unknown at address 0x%lx\n",
sea->basemaddr);
! #endif
! seadata[unit]=NULL;
! free(sea, M_TEMP);
! return(0);
}
/* Find controller and data memory addresses */
With this change in place, one can then add the an option line to their kernel
config file which defines SEA_ASSUME to either SEAGATE or FD depending on the
type the user has. In my case FD. The disadvantage of setting this option is
that if the named card isn't in the system, the boot will take some time as it
waits for a non-existent card, eventually timing out (I think, didn't actually
test that).
Wanting to get my sound card back into my system, and preferring to remove the
FD (one less card from a fairly loaded system), I went back to looking at the
pas problem. Booting the system with the pas driver active and my sound card
in place caused the panic again. Examining the exact message printed before
the panic ("pas0: Type 7 <"), and the code revealed that the table used for
printing card type did not have a entry for position 7. Instead it just had
a 0, which would cause a NULL de-reference fault. My card is a Pro Audio
Spectrum+. A string that read "PAS+" existed in the table at position 6.
Assuming that it was mistakenly entered, I moved this entry from 6 to 7. The
system them came up with out a problem, an I was able to access my CD-ROM
though this SCSI port. The diff report as follows:
*** pas.c Sun Feb 5 18:51:29 1995
--- original/pas.c Sun Feb 5 18:44:02 1995
***************
*** 253,259 ****
};
static char *mv_type[] = {
! 0,0,0,0,0,0,0,"PAS+",0,0,0,0,"PAS16D",0,"CDPC","PAS16"};
int
pasprobe(struct isa_device *dev)
--- 253,259 ----
};
static char *mv_type[] = {
! 0,0,0,0,0,0,"PAS+",0,0,0,0,0,"PAS16D",0,"CDPC","PAS16"};
int
pasprobe(struct isa_device *dev)
I do not have any technical specs on PAS programming, so I don't know if type 6
is also a valid device type number. A better solution would probably also
include changing the 0's the "unknown"'s or adding a test for the 0, that way
if a unknown type does show up, one won't see this panic.
After getting both these SCSI devices working, I then attempted a simple
benchmark to see which was better. I did something like "time ls -R
>/dev/null" with a fairly full CD-ROM in place. Both took about the same
amount of actual time, however the pas had its system time near equal to the
real time, where as the sea driver had only a few percent. This infers that
the pas driver is spending its time in a busy loop. Though performance of the
CD-ROM is about the same, the pas driver consumes more CPU time from other
processes. Therefore I've gone back to the sea driver. Question: is anyone
working on replacement pas driver that does support interrupts and/or DMA in
order to get the performance up, or is such even possible with this SCSI
controller?
Thank you
Potter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502210258.VAA20915>