From owner-freebsd-current@FreeBSD.ORG Tue Jun 3 20:29:33 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FD3E37B401 for ; Tue, 3 Jun 2003 20:29:33 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 741D643F93 for ; Tue, 3 Jun 2003 20:29:32 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9/8.12.9) with ESMTP id h543SMOn031100; Tue, 3 Jun 2003 23:28:22 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h543SMAO031049; Tue, 3 Jun 2003 23:28:22 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 3 Jun 2003 23:28:22 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bryan Liesner In-Reply-To: <20030603115912.Q648@gravy.homeunix.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Jeff Roberson cc: current@freebsd.org Subject: Re: umtx/libthr SMP fixes. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 03:29:33 -0000 On Tue, 3 Jun 2003, Bryan Liesner wrote: > Actually, no it doesn't. I was able to use kern_umtx v 1.3 only if I > removed atapicam from my kernel config. These patches (now committed?) > panic the system whether I use atapicam or not. With kern_umtx v1.2 > there is no panic at all, with or without atapicam. > > Actually, I think it's cam in general that's causing the panic with > these changes. Bizarre. Sounds like an errant pointer in some other code, and it's just a matter of the memory layout as to what gets stepped on. Alternatively, it might be affected by the insertion of the MTX sysinit event. Perhaps that revision rearranges memory a bit. Anyhow, here are some things you might consider, since this whole thing is so odd. Try merging the addition of the struct mtx declaration from 1.3 into 1.2 and see if you get the same panic. If you don't, try merging the MTX_SYSINIT line and see if that triggers the panic. The other changes probably wouldn't cause disruptive memory rearrangement, so see what happens. If the panics appear with the addition of the variable, it probably is a memory stepping thing and a bug in some other piece of code (unfortunately, probably hard to track down). If it's the addition of the initializer, it's a different class of problem. I have to admit that I'm also fairly baffled: my current reading of the change suggests there won't be a specific bug in umtx, rather, the triggering of symptoms from another bug, but I guess we can only find out with a bit of experimentation. You might also find the problem "disappears" if you remove INVARIANTS, although given that you can reproduce this nicely, I'm reluctant to have you do that for fear the bug will get away and not get fixed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories