Date: Sat, 09 Aug 1997 02:43:51 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: Josh Tiefenbach <josh@ican.net> Cc: scsi@freebsd.org Subject: RE: `problem' with dpt driver v1.2.0 Message-ID: <XFMail.970809024351.Shimon@i-Connect.Net> In-Reply-To: <19970808215105.63789@ican.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970809024351.Shimon>