From owner-freebsd-scsi Mon Apr 20 09:33:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA01717 for freebsd-scsi-outgoing; Mon, 20 Apr 1998 09:33:02 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA01540 for ; Mon, 20 Apr 1998 16:32:06 GMT (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id KAA17559; Mon, 20 Apr 1998 10:31:49 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199804201631.KAA17559@panzer.plutotech.com> Subject: Re: Help ! Scsi buss going down ! In-Reply-To: from Raul Zighelboim at "Apr 20, 98 10:23:46 am" To: rzig@verio.net (Raul Zighelboim) Date: Mon, 20 Apr 1998 10:31:49 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Raul Zighelboim wrote... > > This system seems to have suffer from a massive stroke! > > With lots of testing, we got to the same conclusion yesterday revision E > has problems over load (run iozone and see the system freeze). I am > running 3 revision D cards, but maybe one of them is defective. We will > keep replacing cards. Have you considered running CAM? There are many bugs that have been fixed in the CAM version of the Adaptec driver. At the very least, the error recovery code in CAM is generally better than the old code, so that might help stabilize your system somewhat. To see what is involved, see: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/README or ftp://ftp.kdm.org/pub/FreeBSD/cam/README You'll have to run -current, which may or may not work in your case. If not, you'll have to wait until Justin gets time to port CAM to 2.2-stable. > Unrelated , every time we reboot the server, we get an error message at > reboot. It does not matter how clean the shutdown was: (sync; sync; > sync; /sbin/umount -a; /sbin/shutdown -h now)... > > fsck complains at reboot: > Cannot alloc 3317710 bytes for blockmap > Cannot check file system > .... > running fsck manually will show a clean fs. > > Any idea on how I can fix this >? You need to adjust the amount of memory that the 'daemon' class is allowed to use in /etc/login.conf. Problems like that typically show up when you try to fsck a large filesystem, or run savecore on a RAM image from a system with a lot of memory. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message