Precise point of bomb...

[Robert G. Brown]

Dear Doug et. al.

Adding still more debug printk's to scsi.c, I believe that I have
narrowed down the precise point of failure still further.  Apparently
(comparing the trace from a "good" system to a "bad" system) the
initial return from the device probe is OK -- at least, I get 00000000
as result codes either way.  The returns from the 7860 are the same as
well, so the 26/28 device codes are ok for that controller/device
combo.

In the following code fragment (which executes the INQUIRY command):

  /*
   * Build an INQUIRY command block.
   */
  scsi_cmd[0] = INQUIRY;
  scsi_cmd[1] = (lun << 5) & 0xe0;
  scsi_cmd[2] = 0;
  scsi_cmd[3] = 0;
  scsi_cmd[4] = 255;
  scsi_cmd[5] = 0;
  SCpnt->cmd_len = 0;
  {
    struct semaphore sem = MUTEX_LOCKED;
    SCpnt->request.sem = &sem;
    SCpnt->request.rq_status = RQ_SCSI_BUSY;
#if defined (DEBUG)
  printk ("rgb: About to run INQUIRY command with MUTEX_LOCKED...\n");
#endif
    scsi_do_cmd (SCpnt, (void *) scsi_cmd,
                 (void *) scsi_result,
                 256, scan_scsis_done, SCSI_TIMEOUT, 3);

#if defined (DEBUG)
  printk ("rgb: About to run down(&sem)...\n");
#endif
    down (&sem);
#if defined (DEBUG)
  printk ("rgb: down(&sem) completed...\n");
#endif
  }

the last printk is not run but the preceding one is.  The bomb occurs
in down(&sem).  Presumably this is because the semaphore passed to it
is munged somehow by the scsi_do_cmd function for INQUIRY.  In a
minute I'll look into what, if anything, is done to/with the semaphore
in scsi_do_cmd, but things are looking more and more like a memory
mapping error.

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu




To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message