From owner-freebsd-bugs Mon Feb 20 18:54:13 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id SAA29743 for bugs-outgoing; Mon, 20 Feb 1995 18:54:13 -0800 Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id SAA29735 for ; Mon, 20 Feb 1995 18:54:11 -0800 Received: from vtucs.cc.vt.edu (vtucs.cc.vt.edu [128.173.4.72]) by quackerjack.cc.vt.edu (8.6.9/8.6.9) with ESMTP id VAA20915 for ; Mon, 20 Feb 1995 21:58:20 -0500 Message-Id: <199502210258.VAA20915@quackerjack.cc.vt.edu> Received: from potter.bevb.blacksburg.va.us by vtucs.cc.vt.edu with SMTP (8.6.9/16.2) id VAA24353; Mon, 20 Feb 1995 21:53:46 -0500 X-Sender: potter@mail.vt.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Feb 1995 21:46:35 +0500 To: bugs@FreeBSD.org From: potter@bev.net (Mark Potter) Subject: SCSI problems (pas & sea) w/ solutions X-Mailer: Sender: bugs-owner@FreeBSD.org Precedence: bulk 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