From owner-freebsd-current Fri Sep 18 18:41:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA24095 for freebsd-current-outgoing; Fri, 18 Sep 1998 18:41:48 -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 SAA24010 for ; Fri, 18 Sep 1998 18:41:17 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id TAA13870; Fri, 18 Sep 1998 19:40:34 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199809190140.TAA13870@panzer.plutotech.com> Subject: Re: panic: newdirrem inum 48733 should be 48732 (SMP+SOFTUPDATES) In-Reply-To: <199809182347.QAA29701@usr06.primenet.com> from Terry Lambert at "Sep 18, 98 11:47:25 pm" To: tlambert@primenet.com (Terry Lambert) Date: Fri, 18 Sep 1998 19:40:34 -0600 (MDT) Cc: andreas@klemm.gtn.com, current@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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote... > > Had no problems with panics for a long long time although I run > > current, SMP and softupdates. When other people reported problems > > I wondered, why my system didn't panic ... > > > > But now I have been bitten by softupdates and SMP myself. > > > > Kernel config file below and the trace from DDB > > _Debugger > > _panic > > _newdirrem > > _softdep_setup_directory_change > > _ufs_dirrewrite > > _ufs_rename > > _ufs_vnoperate > > _rename > > _syscall > > _Xint0x80_syscall > > > What if you turn off CAM? Umm, you can't "turn off" CAM. The old SCSI code is no longer in -current, so you'd have to go back to before the CAM integration to "turn off" CAM. Besides, the SCSI_CAM option that everyone gets so confused about was taken out of the tree last night. It was only for the QLogic ISP driver, but Matt Jacob has re-arranged things somewhat and it is no longer necessary. > > options SCSI_CAM #We're using CAM in this kernel > > People seem to be having problems with soft updates because of CAM. I doubt the problems are *because* of CAM. It's more likely that the problems are tickled/exacerbated/demonstrated by CAM. The pattern of I/O that CAM does is different than the old SCSI layer; CAM handles a far greater number of outstanding transactions. (as many as your combination of drives and controllers can handle) > It looks like there is a commit guarantees in the old code that CAM > is failing to honor correctly... Well, if you can point out the problem... It's entirely possible that there is some problem with the interaction between the two, but I wouldn't be so sure. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message