From owner-freebsd-scsi Sat Oct 3 10:12:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26569 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 10:12:04 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.kersur.net (mail.kersur.net [199.79.199.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA26540 for ; Sat, 3 Oct 1998 10:11:58 -0700 (PDT) (envelope-from dswartz@druber.com) Received: from manticore (manticore.druber.com [207.180.95.108]) by mail.kersur.net (8.8.8/8.8.8) with SMTP id NAA09336; Sat, 3 Oct 1998 13:12:38 -0400 (EDT) Message-Id: <3.0.5.32.19981003131135.0094fab0@mail.kersur.net> X-Sender: druber@mail.kersur.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 03 Oct 1998 13:11:35 -0400 To: "Kenneth D. Merry" From: Dan Swartzendruber Subject: Re: dumping with CAM kernel? Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810031656.KAA13245@panzer.plutotech.com> References: <3.0.5.32.19981003103509.0094e6f0@mail.kersur.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:56 AM 10/3/98 -0600, Kenneth D. Merry wrote: >Dan Swartzendruber wrote... > >Dumps were broken for a while in CAM because (I think) of the order some >of the shutdown hooks were called. Basically, the shutdown hook that >Justin uses to reset the Adaptec board to a "known" state was getting >called before the dump routine in the da driver gets called. So when we >tried to run the dump routine, everything just blew up. (no sequencer >running on the card, all the registers are set wrong, etc. etc.) > >Justin finally figured out and fixed the problem around the time we put >CAM into -current. We haven't released another -stable snapshot yet. >That'll probably happen after 3.0 goes out. Thanks, I finally got a dump on a non-CAM system here at home, but it's nice to know I wasn't hallucinating. >I'm not sure what kind of environment you've got it in, but if you can, you >might want to put a serial console on it and enable DDB. Then you can capture >a stack trace of the problem at least. If that's not possible, I guess >you'll probably have to wait until we get another -stable snapshot out. Actually, I'm in the process of setting of a remote monitoring system for a bunch of the servers. Each one will have serial0 connected to a terminal server port. Each server's /boot.config will say '-P' to probe for the (nonexistent) keyboard. I'm finishing up (RSN) the daemon that runs on a workstation and monitors all of the console ports. The idea is to let an admin telnet to a specific port on the workstation and pull up a console session for that server (complete with the last N lines of console output, etc...) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message