From owner-freebsd-current  Tue Oct 13 10:26:15 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id KAA20248
          for freebsd-current-outgoing; Tue, 13 Oct 1998 10:26:15 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20239
          for <freebsd-current@FreeBSD.ORG>; Tue, 13 Oct 1998 10:26:11 -0700 (PDT)
          (envelope-from ken@panzer.plutotech.com)
Received: (from ken@localhost)
          by panzer.plutotech.com (8.9.1/8.8.5) id LAA03687;
          Tue, 13 Oct 1998 11:25:50 -0600 (MDT)
From: "Kenneth D. Merry" <ken@plutotech.com>
Message-Id: <199810131725.LAA03687@panzer.plutotech.com>
Subject: Re: 3.0-19981009-BETA + 2840 AHA + camcontrol stop/start = panic
In-Reply-To: <19981013193051.46229@deepo.prosa.dk> from Philippe Regnauld at "Oct 13, 98 07:30:51 pm"
To: regnauld@deepo.prosa.dk (Philippe Regnauld)
Date: Tue, 13 Oct 1998 11:25:50 -0600 (MDT)
Cc: freebsd-current@FreeBSD.ORG, gibbs@pluto.plutotech.com
X-Mailer: ELM [version 2.4ME+ PL28s (25)]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=ELM908299550-3628-0_
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


--ELM908299550-3628-0_
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Philippe Regnauld wrote...
> Kenneth D. Merry writes:
> > 
> > BTW, in your first message you exposed a bug in camcontrol.  It's fixed
> > now.  The reason your drive started was because the error recovery code
> > kicked in and started it when you typed 'camcontrol'.  (the kernel tried to
> > access the disk, which wasn't spun up, so it sent a start unit command to
> > it.)
> 
> 	That's what I thought.  So in fact the subsequent invocation
> 	of camcontrol start did nothing, right ?  (it just responded
> 	that start should take an argument)

Right.  camcontrol itself did nothing, but by calling it, you caused a disk
access which caused us to try to spin the disk up.

I've attached a preliminary patch that fixes one of the panics you saw.  (the
one in xpt_done())  It may cause other problems, though, so I need to check
it out a little more.  In my initial tests it works fine, though.

The "biodone: buffer not busy" panic seems to only happen on a mounted
filesystem.  This patch doesn't fix that problem.

Ken
-- 
Kenneth Merry
ken@plutotech.com

--ELM908299550-3628-0_
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: attachment; filename=cam_xpt.inq_changed.diffs.101398
Content-Description: cam_xpt.inq_changed.diffs.101398
Content-Transfer-Encoding: 7bit

==== //depot/cam/sys/cam/cam_xpt.c#167 - /usr/home/ken/perforce/cam/sys/cam/cam_xpt.c ====
*** /tmp/tmp.26937.0	Tue Oct 13 11:16:20 1998
--- /usr/home/ken/perforce/cam/sys/cam/cam_xpt.c	Tue Oct 13 11:11:41 1998
***************
*** 3941,3947 ****
  			if ((async_code == AC_SENT_BDR)
  			 || (async_code == AC_BUS_RESET)
  			 || (async_code == AC_INQ_CHANGED))
! 				status = xpt_compile_path(&newpath, NULL,
  							  bus->path_id,
  							  target->target_id,
  							  device->lun_id);
--- 3941,3948 ----
  			if ((async_code == AC_SENT_BDR)
  			 || (async_code == AC_BUS_RESET)
  			 || (async_code == AC_INQ_CHANGED))
! 				status = xpt_compile_path(&newpath,
! 							  path->periph,
  							  bus->path_id,
  							  target->target_id,
  							  device->lun_id);

--ELM908299550-3628-0_--

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message