From owner-freebsd-scsi  Sat Aug  9 02:43:48 1997
Return-Path: <owner-freebsd-scsi>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id CAA16531
          for freebsd-scsi-outgoing; Sat, 9 Aug 1997 02:43:48 -0700 (PDT)
Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA16512
          for <scsi@freebsd.org>; Sat, 9 Aug 1997 02:43:40 -0700 (PDT)
Received: (qmail 17350 invoked by uid 1000); 9 Aug 1997 09:43:52 -0000
Message-ID: <XFMail.970809024351.Shimon@i-Connect.Net>
X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD
Content-Type: text/plain; charset=iso-8859-8
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <19970808215105.63789@ican.net>
Date: Sat, 09 Aug 1997 02:43:51 -0700 (PDT)
Organization: Atlas Telecom
From: Simon Shapiro <Shimon@i-Connect.Net>
To: Josh Tiefenbach <josh@ican.net>
Subject: RE: `problem' with dpt driver v1.2.0
Cc: scsi@freebsd.org
Sender: owner-freebsd-scsi@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


Hi Josh Tiefenbach;  On 09-Aug-97 you wrote: 
> Shimon,

Simon will do just as well :-)

> We've been noticing some disturbing behavior with both v1.1.10 and v1.2.0
> of
> the dpt driver. In a nutshell, we cant have unattended reboots. I think
> the
> best way of describing the problem, is with dmesg outputs.

Version 1.2 is not published.  See the copyright message.  Actually,
version 1.2 does not exist yet.

> [shutdown box]
> 
> syncing disks... 2 done
> dpt0: Shutting down (mode 0) HBA.     Please wait...dpt0: Controller was
> warned of shutdown and is now disabled
> Rebooting...
> 
> [snip]
> 
> DPT:  RAID Manager driver, Version 1.0.0
> Probing for devices on PCI bus 0:
> chip0 <Intel 82440FX (Natoma) PCI and memory controller> rev 2 on pci0:0
> DPT:  PCI SCSI HBA Driver, version 1.2.0
> dpt0 <DPT Caching SCSI RAID Controller> rev 2 int a irq 11 on pci0:13
> dpt0: DPT type 3, model PM3334UW firmware 07L0, Protocol 0 
>       on port 1090 with 458753MB Write-Back cache
> dpt0: Enabled Options:
>       Use Software Interrupts
>       Precisely Track State Transitions
>       Collect Metrics
> dpt0 waiting for scsi devices to settle
> dpt0 ERROR: Command "Test Unit Ready [7.24]" recieved for b0t0u0
>               but controller is shutdown.     Aborting...
> dpt0 ERROR: Command "Inquiry [7.5]" recieved for b0t0u0
>               but controller is shutdown.     Aborting...
> dpt0 ERROR: Command "Test Unit Ready [7.24]" recieved for b0t1u0
>               but controller is shutdown.     Aborting...
> 
> [repeated *many* times, followed by eventually]
> 
> panic: cannot mount root
> 
> 
> This is, of course, a problem :) The only way I've been able to
> ameliorate the
> situation is to boot the machine with an older version of the dpt driver
> (from
> floppy no less), wait for it to come up. and reboot with the new driver.
> 
> Any suggestions?

Yes.  Tell Simon to: a) take a Programming in C introductory class and to
stop working until 0300 four times a week :-)

A bit more to the point;  When we shutdown the controller, we set a bit
in a state variable in a structure which controls the DPT behaviour
(dpt_softc_t *dpt....).  Amazingly enough, on your system (we never saw
this problem here on any machine, honest), when it reboots on the same 
kernel configuration, your system's DRAM survives the reset, malloc
allocates the same virtual address, the vm assigns the same physical
address, etc. and you see the bit still set.

Please go to sys/pci/dpt_pci.c and in the function dpt_pci_attach, after
the long comment, BEFORE the four TAILQ_INIT calls, add:

bzero(dpt, sizeof(dpt_softc_t);

If that does not fix the problem, let me know.
When I release 1.2, the problem will be fixed.

Simon