From owner-freebsd-arch@FreeBSD.ORG Sun Oct 10 19:50:12 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EE9E16A4CE for ; Sun, 10 Oct 2004 19:50:12 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 1685043D1F for ; Sun, 10 Oct 2004 19:50:10 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 31697 invoked by uid 89); 10 Oct 2004 19:50:09 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 10 Oct 2004 19:50:09 -0000 Received: (qmail 31685 invoked by uid 89); 10 Oct 2004 19:50:09 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 10 Oct 2004 19:50:09 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i9AJo8mt080405; Sun, 10 Oct 2004 15:50:08 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Peter Holm In-Reply-To: <20041005130308.GA2586@peter.osted.lan> References: <1095468747.31297.241.camel@palm.tree.com> <1096496057.3733.2163.camel@palm.tree.com> <1096603981.21577.195.camel@palm.tree.com> <200410041131.35387.jhb@FreeBSD.org> <1096911278.44307.17.camel@palm.tree.com> <41619D29.1000704@elischer.org><4161A7BD.3040706@elischer.org> <20041005130308.GA2586@peter.osted.lan> Content-Type: text/plain Message-Id: <1097437808.80398.4.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 10 Oct 2004 15:50:08 -0400 Content-Transfer-Encoding: 7bit cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 19:50:12 -0000 On Tue, 2004-10-05 at 09:03, Peter Holm wrote: > On Mon, Oct 04, 2004 at 12:42:53PM -0700, Julian Elischer wrote: > > OK, I got a crash dump now, after a few modifications to kern_shutdown.c > > There are however a few strange things worth noticing: > > 1) The are no panic string: > > Mounted root from ufs:/dev/ad0s1a. > pid 1146: corrected slot count (2->1) > [thread 100796] > Stopped at sched_add+0x13: movl 0x14c(%esi),%ebx > > 2) The gdb stack trace gets a bit weird at: > > #8 0xc07812da in calltrap () at ../../../i386/i386/exception.s:140 > #9 0xc05f0018 in flock (td=0x0, uap=0x0) at ../../../kern/kern_descrip.c:2138 > #10 0xc0619fd1 in setrunqueue (td=0xc2319180, flags=0x0) at kern_switch.c:521 > #11 0xc061921f in sched_wakeup (td=0xc2319180) at ../../../kern/sched_4bsd.c:859 > > Where did flock() come from? > > The full console output is at http://www.holm.cc/stress/log/cons82.html > > - Peter I am still puzzled. My newest pet theory is that the sorting of the kg_runq is corrupted before setrunqueue is called. Directly changing td_priority while the thread is on the run queue would be an explanation. However the only instance that I found is what I think is a rare condition where sleepq_resume_thread may be called while the thread is on a runqueue. (John - what did I miss this time ...) Peter could you try this patch? Index: subr_sleepqueue.c =================================================================== RCS file: /cvsroot/src/sys/kern/subr_sleepqueue.c,v retrieving revision 1.11 diff -u -r1.11 subr_sleepqueue.c --- subr_sleepqueue.c 19 Aug 2004 11:31:41 -0000 1.11 +++ subr_sleepqueue.c 10 Oct 2004 18:18:55 -0000 @@ -642,7 +642,7 @@ /* Adjust priority if requested. */ MPASS(pri == -1 || (pri >= PRI_MIN && pri <= PRI_MAX)); if (pri != -1 && td->td_priority > pri) - td->td_priority = pri; + sched_prio(td, pri); setrunnable(td); mtx_unlock_spin(&sched_lock); } Should it crash again could you walk the kg_runq to verify the sorting? Thanks Stephan From owner-freebsd-arch@FreeBSD.ORG Sun Oct 10 19:58:02 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA8E416A4D1 for ; Sun, 10 Oct 2004 19:58:01 +0000 (GMT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 39AEB43D5D for ; Sun, 10 Oct 2004 19:58:01 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 46314 invoked from network); 10 Oct 2004 19:57:59 -0000 Received: from 0x50a43fc7.hknxx1.adsl-dhcp.tele.dk (HELO peter.osted.lan) (80.164.63.199) by relay.pair.com with SMTP; 10 Oct 2004 19:57:59 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.12.10/8.12.10) with ESMTP id i9AJvwXc052163; Sun, 10 Oct 2004 21:57:58 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.12.10/8.12.10/Submit) id i9AJvwmW052162; Sun, 10 Oct 2004 21:57:58 +0200 (CEST) (envelope-from pho) Date: Sun, 10 Oct 2004 21:57:58 +0200 From: Peter Holm To: Stephan Uphoff Message-ID: <20041010195758.GA52129@peter.osted.lan> References: <1096496057.3733.2163.camel@palm.tree.com> <1096603981.21577.195.camel@palm.tree.com> <200410041131.35387.jhb@FreeBSD.org> <1096911278.44307.17.camel@palm.tree.com> <20041004184939.GA8178@peter.osted.lan> <41619D29.1000704@elischer.org> <20041004191410.GA8423@peter.osted.lan> <4161A7BD.3040706@elischer.org> <20041005130308.GA2586@peter.osted.lan> <1097437808.80398.4.camel@palm.tree.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1097437808.80398.4.camel@palm.tree.com> User-Agent: Mutt/1.4.1i cc: Peter Holm cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 19:58:02 -0000 On Sun, Oct 10, 2004 at 03:50:08PM -0400, Stephan Uphoff wrote: > On Tue, 2004-10-05 at 09:03, Peter Holm wrote: > > On Mon, Oct 04, 2004 at 12:42:53PM -0700, Julian Elischer wrote: > > > > OK, I got a crash dump now, after a few modifications to kern_shutdown.c > > > > There are however a few strange things worth noticing: > > > > 1) The are no panic string: > > > > Mounted root from ufs:/dev/ad0s1a. > > pid 1146: corrected slot count (2->1) > > [thread 100796] > > Stopped at sched_add+0x13: movl 0x14c(%esi),%ebx > > > > 2) The gdb stack trace gets a bit weird at: > > > > #8 0xc07812da in calltrap () at ../../../i386/i386/exception.s:140 > > #9 0xc05f0018 in flock (td=0x0, uap=0x0) at ../../../kern/kern_descrip.c:2138 > > #10 0xc0619fd1 in setrunqueue (td=0xc2319180, flags=0x0) at kern_switch.c:521 > > #11 0xc061921f in sched_wakeup (td=0xc2319180) at ../../../kern/sched_4bsd.c:859 > > > > Where did flock() come from? > > > > The full console output is at http://www.holm.cc/stress/log/cons82.html > > > > - Peter > > I am still puzzled. > My newest pet theory is that the sorting of the kg_runq is corrupted > before setrunqueue is called. > Directly changing td_priority while the thread is on the run queue would > be an explanation. > However the only instance that I found is what I think is a rare > condition where sleepq_resume_thread may be called while the thread is > on a runqueue. (John - what did I miss this time ...) > > Peter could you try this patch? > Sure, no problem. This patch + your previous changes applied to HEAD, right? - Peter > Index: subr_sleepqueue.c > =================================================================== > RCS file: /cvsroot/src/sys/kern/subr_sleepqueue.c,v > retrieving revision 1.11 > diff -u -r1.11 subr_sleepqueue.c > --- subr_sleepqueue.c 19 Aug 2004 11:31:41 -0000 1.11 > +++ subr_sleepqueue.c 10 Oct 2004 18:18:55 -0000 > @@ -642,7 +642,7 @@ > /* Adjust priority if requested. */ > MPASS(pri == -1 || (pri >= PRI_MIN && pri <= PRI_MAX)); > if (pri != -1 && td->td_priority > pri) > - td->td_priority = pri; > + sched_prio(td, pri); > setrunnable(td); > mtx_unlock_spin(&sched_lock); > } > > Should it crash again could you walk the kg_runq to verify the sorting? > > Thanks > Stephan > > > > -- Peter Holm From owner-freebsd-arch@FreeBSD.ORG Sun Oct 10 20:07:57 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFD2016A4CE for ; Sun, 10 Oct 2004 20:07:56 +0000 (GMT) Received: from duchess.speedfactory.net (duchess.speedfactory.net [66.23.201.84]) by mx1.FreeBSD.org (Postfix) with SMTP id 82DB943D31 for ; Sun, 10 Oct 2004 20:07:56 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 26075 invoked by uid 89); 10 Oct 2004 20:07:55 -0000 Received: from duchess.speedfactory.net (66.23.201.84) by duchess.speedfactory.net with SMTP; 10 Oct 2004 20:07:55 -0000 Received: (qmail 26063 invoked by uid 89); 10 Oct 2004 20:07:55 -0000 Received: from unknown (HELO palm.tree.com) (66.23.216.49) by duchess.speedfactory.net with SMTP; 10 Oct 2004 20:07:55 -0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id i9AK7tmt080478; Sun, 10 Oct 2004 16:07:55 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Peter Holm In-Reply-To: <20041010195758.GA52129@peter.osted.lan> References: <1096496057.3733.2163.camel@palm.tree.com> <1096603981.21577.195.camel@palm.tree.com> <200410041131.35387.jhb@FreeBSD.org> <1096911278.44307.17.camel@palm.tree.com> <41619D29.1000704@elischer.org><4161A7BD.3040706@elischer.org> <20041005130308.GA2586@peter.osted.lan> <1097437808.80398.4.camel@palm.tree.com> <20041010195758.GA52129@peter.osted.lan> Content-Type: text/plain Message-Id: <1097438874.80398.12.camel@palm.tree.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 10 Oct 2004 16:07:55 -0400 Content-Transfer-Encoding: 7bit cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Oct 2004 20:07:57 -0000 On Sun, 2004-10-10 at 15:57, Peter Holm wrote: > On Sun, Oct 10, 2004 at 03:50:08PM -0400, Stephan Uphoff wrote: > > On Tue, 2004-10-05 at 09:03, Peter Holm wrote: > > > On Mon, Oct 04, 2004 at 12:42:53PM -0700, Julian Elischer wrote: > > > > > > OK, I got a crash dump now, after a few modifications to kern_shutdown.c > > > > > > There are however a few strange things worth noticing: > > > > > > 1) The are no panic string: > > > > > > Mounted root from ufs:/dev/ad0s1a. > > > pid 1146: corrected slot count (2->1) > > > [thread 100796] > > > Stopped at sched_add+0x13: movl 0x14c(%esi),%ebx > > > > > > 2) The gdb stack trace gets a bit weird at: > > > > > > #8 0xc07812da in calltrap () at ../../../i386/i386/exception.s:140 > > > #9 0xc05f0018 in flock (td=0x0, uap=0x0) at ../../../kern/kern_descrip.c:2138 > > > #10 0xc0619fd1 in setrunqueue (td=0xc2319180, flags=0x0) at kern_switch.c:521 > > > #11 0xc061921f in sched_wakeup (td=0xc2319180) at ../../../kern/sched_4bsd.c:859 > > > > > > Where did flock() come from? > > > > > > The full console output is at http://www.holm.cc/stress/log/cons82.html > > > > > > - Peter > > > > I am still puzzled. > > My newest pet theory is that the sorting of the kg_runq is corrupted > > before setrunqueue is called. > > Directly changing td_priority while the thread is on the run queue would > > be an explanation. > > However the only instance that I found is what I think is a rare > > condition where sleepq_resume_thread may be called while the thread is > > on a runqueue. (John - what did I miss this time ...) > > > > Peter could you try this patch? > > > > Sure, no problem. > > This patch + your previous changes applied to HEAD, right? > > - Peter Yes. I will try to clean up the old patches tonight to get them reviewed. Stephan > > > Index: subr_sleepqueue.c > > =================================================================== > > RCS file: /cvsroot/src/sys/kern/subr_sleepqueue.c,v > > retrieving revision 1.11 > > diff -u -r1.11 subr_sleepqueue.c > > --- subr_sleepqueue.c 19 Aug 2004 11:31:41 -0000 1.11 > > +++ subr_sleepqueue.c 10 Oct 2004 18:18:55 -0000 > > @@ -642,7 +642,7 @@ > > /* Adjust priority if requested. */ > > MPASS(pri == -1 || (pri >= PRI_MIN && pri <= PRI_MAX)); > > if (pri != -1 && td->td_priority > pri) > > - td->td_priority = pri; > > + sched_prio(td, pri); > > setrunnable(td); > > mtx_unlock_spin(&sched_lock); > > } > > > > Should it crash again could you walk the kg_runq to verify the sorting? > > > > Thanks > > Stephan > > > > > > > > From owner-freebsd-arch@FreeBSD.ORG Mon Oct 11 03:57:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67CB916A4CE for ; Mon, 11 Oct 2004 03:57:08 +0000 (GMT) Received: from server1.astraldream.net (astraldream.net [69.20.5.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id F061743D48 for ; Mon, 11 Oct 2004 03:57:07 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.20] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated (0 bits)) by server1.astraldream.net (8.11.6/8.11.6) with ESMTP id i9B3v1X19628 verified NO) for ; Sun, 10 Oct 2004 23:57:06 -0400 From: Suleiman Souhlal To: freebsd-arch@FreeBSD.org Content-Type: text/plain Message-Id: <1097467017.5258.34.camel@zZzZ.segfaulted.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 10 Oct 2004 23:56:57 -0400 Content-Transfer-Encoding: 7bit Subject: [RFC] sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 03:57:08 -0000 Hello, In the past few days, I have managed to remove Giant from sysctl. The patch is at http://people.freebsd.org/~ssouhlal/testing/sysctl-locking.diff This is the first time I ever do something like this, so I wouldn't be surprised if I am doing something wrong. Any suggestions/comments? green@ also pointed out that I might need to use memory barriers, or some other synchronization primitive, when setting oid_owner to NULL in sysctl_oid_disown, but I am unsure on how to do that.. Thanks in advance for your help. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Mon Oct 11 19:30:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82EEF16A4CE; Mon, 11 Oct 2004 19:30:32 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24BEB43D2F; Mon, 11 Oct 2004 19:30:32 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9BJUODI068849; Mon, 11 Oct 2004 12:30:28 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410111930.i9BJUODI068849@gw.catspoiler.org> Date: Mon, 11 Oct 2004 12:30:24 -0700 (PDT) From: Don Lewis To: ssouhlal@FreeBSD.org In-Reply-To: <1097467017.5258.34.camel@zZzZ.segfaulted.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 19:30:32 -0000 On 10 Oct, Suleiman Souhlal wrote: > Hello, > > In the past few days, I have managed to remove Giant from sysctl. The > patch is at > http://people.freebsd.org/~ssouhlal/testing/sysctl-locking.diff > This is the first time I ever do something like this, so I wouldn't be > surprised if I am doing something wrong. > Any suggestions/comments? > > green@ also pointed out that I might need to use memory barriers, or > some other synchronization primitive, when setting oid_owner to NULL in > sysctl_oid_disown, but I am unsure on how to do that.. > > Thanks in advance for your help. There seems to be a lot of locking/unlocking overhead in the oid lookup and oid tree manipulation code. Doing the traversals at each level of the tree without holding a lock for the entire time makes me nervous, though I can't point to any specific problem. It might be better to just hold a single lock across then entire lookup, insertion, or deletion operation. What happens if: thread A owns an oid thread B, which wants to delete the oid, goes to sleep to wait for the oid thread C wants the oid and goes to sleep thread A releases the oid and wakes up thread B thread B deletes the oid thread C does ??? I don't think that you can arbitrarily remove mtx_assert(&Giant, MA_OWNED) from the handlers. Some of the handlers probably need Giant for correct operation. It's probably possible to change these into mtx_lock()/mtx_unlock() pairs. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 11 19:36:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 394C316A4CE; Mon, 11 Oct 2004 19:36:32 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3CB743D4C; Mon, 11 Oct 2004 19:36:31 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9BKYwfa025715; Mon, 11 Oct 2004 15:34:58 -0500 Date: Mon, 11 Oct 2004 15:34:58 -0500 (EST) From: Sam X-X-Sender: sah@athena To: Andre Oppermann In-Reply-To: <4165ADC2.70D2F0C1@freebsd.org> Message-ID: References: <4165ADC2.70D2F0C1@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: sys/net/netisr.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 19:36:32 -0000 > Sam wrote: >> >> Hello - >> >> I think I've found a bug in -- and have a question about >> the overall stability of -- sys/net/netisr.c (5.2.1 branch). > > This particular bug has already been fixed in 5.3 and 6.0-current. This bug is not fixed in 5.3-beta7 or -current. Unloading a module that unregisters a netisr leaves the queue pointer for that netisr structure page fault ready. > You should do your development on either RELENG_5 or MAIN. The > 5.2.1 branch was only a technology demo and the areas you are > concerned with have changed significantly (read: really a lot). > > RELENG_5 (5.3) will be the next stable branch which features > future binary compatibility within further > 5.x releases. > > -- > Andre > > >> My AoE module calls netisr_register on load, netisr_unregister >> on unload. Netisr_unregister fails to clear the ni->ni_queue >> pointer and the next received frame gets queued up to a page >> fault. Pretty easy to fix: >> >> --- src/sys/net/netisr.c Sat Nov 8 17:28:39 2003 >> +++ src2/sys/net/netisr.c Thu Oct 7 15:03:39 2004 >> @@ -103,6 +103,7 @@ >> ni->ni_handler = NULL; >> if (ni->ni_queue != NULL) >> IF_DRAIN(ni->ni_queue); >> + ni->ni_queue = NULL; >> } >> >> struct isrstat { >> >> Looking at the code, though, I don't see why I can't >> cause something just as ugly to happen anyway. Suppose >> the following: cpu0 starts processing an inbound frame >> while cpu1 unloads module (calling netisr_unregister). >> It *seems* possible for cpu0 to get a pointer to the >> queue, then cpu1 unload the module completely, causing >> cpu0 to page fault on the queue address. >> >> I don't claim to understand the context in which >> netisr_dispatch is called, so perhaps I'm off base, >> but shouldn't there be a mutex protecting against this? >> >> Please prove me wrong. >> >> Sam >> From owner-freebsd-arch@FreeBSD.ORG Mon Oct 11 20:02:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5805816A4D1 for ; Mon, 11 Oct 2004 20:02:35 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B1B543D2D for ; Mon, 11 Oct 2004 20:02:34 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 26111 invoked from network); 11 Oct 2004 19:53:08 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Oct 2004 19:53:08 -0000 Message-ID: <416AE70B.3030900@freebsd.org> Date: Mon, 11 Oct 2004 22:03:23 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: <4165ADC2.70D2F0C1@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: sys/net/netisr.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 20:02:35 -0000 Sam wrote: >> Sam wrote: >> >>> >>> Hello - >>> >>> I think I've found a bug in -- and have a question about >>> the overall stability of -- sys/net/netisr.c (5.2.1 branch). >> >> >> This particular bug has already been fixed in 5.3 and 6.0-current. > > This bug is not fixed in 5.3-beta7 or -current. Unloading a > module that unregisters a netisr leaves the queue pointer for that > netisr structure page fault ready. You are right indeed. Sorry for the confusion. There have been other bugs fixed but not this one. I've commited your fix in rev. 1.15 of net/netisr.c. Thanks for submitting the bug report and proving me wrong ;-) -- Andre >> You should do your development on either RELENG_5 or MAIN. The >> 5.2.1 branch was only a technology demo and the areas you are >> concerned with have changed significantly (read: really a lot). >> >> RELENG_5 (5.3) will be the next stable branch which features >> future binary compatibility within further > 5.x releases. >> >> -- >> Andre >> >> >>> My AoE module calls netisr_register on load, netisr_unregister >>> on unload. Netisr_unregister fails to clear the ni->ni_queue >>> pointer and the next received frame gets queued up to a page >>> fault. Pretty easy to fix: >>> >>> --- src/sys/net/netisr.c Sat Nov 8 17:28:39 2003 >>> +++ src2/sys/net/netisr.c Thu Oct 7 15:03:39 2004 >>> @@ -103,6 +103,7 @@ >>> ni->ni_handler = NULL; >>> if (ni->ni_queue != NULL) >>> IF_DRAIN(ni->ni_queue); >>> + ni->ni_queue = NULL; >>> } >>> >>> struct isrstat { >>> >>> Looking at the code, though, I don't see why I can't >>> cause something just as ugly to happen anyway. Suppose >>> the following: cpu0 starts processing an inbound frame >>> while cpu1 unloads module (calling netisr_unregister). >>> It *seems* possible for cpu0 to get a pointer to the >>> queue, then cpu1 unload the module completely, causing >>> cpu0 to page fault on the queue address. >>> >>> I don't claim to understand the context in which >>> netisr_dispatch is called, so perhaps I'm off base, >>> but shouldn't there be a mutex protecting against this? >>> >>> Please prove me wrong. >>> >>> Sam >>> > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Mon Oct 11 21:27:51 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C721D16A4CE for ; Mon, 11 Oct 2004 21:27:51 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CD5F43D4C for ; Mon, 11 Oct 2004 21:27:51 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 32560 invoked from network); 11 Oct 2004 21:27:51 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Oct 2004 21:27:50 -0000 Received: from [10.50.40.210] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i9BLRH6W042482; Mon, 11 Oct 2004 17:27:47 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Stephan Uphoff Date: Mon, 11 Oct 2004 16:54:14 -0400 User-Agent: KMail/1.6.2 References: <1095468747.31297.241.camel@palm.tree.com> <20041005130308.GA2586@peter.osted.lan> <1097437808.80398.4.camel@palm.tree.com> In-Reply-To: <1097437808.80398.4.camel@palm.tree.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410111654.14502.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Peter Holm cc: Julian Elischer cc: "freebsd-arch@freebsd.org" Subject: Re: scheduler (sched_4bsd) questions X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2004 21:27:51 -0000 On Sunday 10 October 2004 03:50 pm, Stephan Uphoff wrote: > On Tue, 2004-10-05 at 09:03, Peter Holm wrote: > > On Mon, Oct 04, 2004 at 12:42:53PM -0700, Julian Elischer wrote: > > > > OK, I got a crash dump now, after a few modifications to kern_shutdown.c > > > > There are however a few strange things worth noticing: > > > > 1) The are no panic string: > > > > Mounted root from ufs:/dev/ad0s1a. > > pid 1146: corrected slot count (2->1) > > [thread 100796] > > Stopped at sched_add+0x13: movl 0x14c(%esi),%ebx > > > > 2) The gdb stack trace gets a bit weird at: > > > > #8 0xc07812da in calltrap () at ../../../i386/i386/exception.s:140 > > #9 0xc05f0018 in flock (td=0x0, uap=0x0) at > > ../../../kern/kern_descrip.c:2138 #10 0xc0619fd1 in setrunqueue > > (td=0xc2319180, flags=0x0) at kern_switch.c:521 #11 0xc061921f in > > sched_wakeup (td=0xc2319180) at ../../../kern/sched_4bsd.c:859 > > > > Where did flock() come from? > > > > The full console output is at http://www.holm.cc/stress/log/cons82.html > > > > - Peter > > I am still puzzled. > My newest pet theory is that the sorting of the kg_runq is corrupted > before setrunqueue is called. > Directly changing td_priority while the thread is on the run queue would > be an explanation. > However the only instance that I found is what I think is a rare > condition where sleepq_resume_thread may be called while the thread is > on a runqueue. (John - what did I miss this time ...) This is a good find! > Peter could you try this patch? > > Index: subr_sleepqueue.c > =================================================================== > RCS file: /cvsroot/src/sys/kern/subr_sleepqueue.c,v > retrieving revision 1.11 > diff -u -r1.11 subr_sleepqueue.c > --- subr_sleepqueue.c 19 Aug 2004 11:31:41 -0000 1.11 > +++ subr_sleepqueue.c 10 Oct 2004 18:18:55 -0000 > @@ -642,7 +642,7 @@ > /* Adjust priority if requested. */ > MPASS(pri == -1 || (pri >= PRI_MIN && pri <= PRI_MAX)); > if (pri != -1 && td->td_priority > pri) > - td->td_priority = pri; > + sched_prio(td, pri); > setrunnable(td); > mtx_unlock_spin(&sched_lock); > } > > Should it crash again could you walk the kg_runq to verify the sorting? > > Thanks > Stephan -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Oct 12 14:34:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 44F9416A4CE for ; Tue, 12 Oct 2004 14:34:49 +0000 (GMT) Received: from somic.vox-mundi.net (somic.vox-mundi.net [80.253.170.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98D1E43D4C for ; Tue, 12 Oct 2004 14:34:47 +0000 (GMT) (envelope-from gordan@vox-mundi.net) Received: from VMPresario ([80.253.170.106]) by somic.vox-mundi.net (8.11.6/8.11.6) with SMTP id i9CEYhr26179 for ; Tue, 12 Oct 2004 16:34:43 +0200 From: "Gordan Remus (Vox Mundi)" To: Date: Tue, 12 Oct 2004 16:32:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: FreeBSD 4.X and Intel E7520 chipset problems X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 14:34:49 -0000 Recently we have purchased a Supermicro X6DHR-IG2 motherboard based on Intel E7520 chipset with 2x3.0GHz Xeons and are unable to install FreeBSD 4.X on it. It seems that FreeBSD 4.X is not recognizing the chipset and therefore it's unable to recognize Mylex AcceleRAID 160 controller. Everything is working fine on FreeBSD 5.X, but unfortunately the application we need to run on top of that is made specifically for FreeBSD 4.X. Is there any chance that Intel E7520 chipset will be supported on some future 4.X releases or is there some kind of patch/workaround ? Best Regards, Gordan Remus Technical Department Vox Mundi From owner-freebsd-arch@FreeBSD.ORG Tue Oct 12 15:25:39 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 742C916A4CE; Tue, 12 Oct 2004 15:25:39 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CDA843D3F; Tue, 12 Oct 2004 15:25:39 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9CGO3r6031585; Tue, 12 Oct 2004 11:24:03 -0500 Date: Tue, 12 Oct 2004 11:24:03 -0500 (EST) From: Sam X-X-Sender: sah@athena To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: mbuf w/o pkthdr? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 15:25:39 -0000 Hello - src/sys/i386/i386/busdma_machdep.c:/^bus_dmamap_load_mbuf/ prohibits loading an mbuf that does not contain a packet header. Some drivers use this (xl), some don't (fxp). Are all packets supposed to have the M_PKTHDR flag? Why? Cheers, Sam From owner-freebsd-arch@FreeBSD.ORG Tue Oct 12 15:36:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5953016A4CE; Tue, 12 Oct 2004 15:36:22 +0000 (GMT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id B96F843D39; Tue, 12 Oct 2004 15:36:21 +0000 (GMT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 6DD285312; Tue, 12 Oct 2004 17:36:20 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id BD98E530A; Tue, 12 Oct 2004 17:36:13 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 6DFF2B861; Tue, 12 Oct 2004 17:36:13 +0200 (CEST) To: Sam References: From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 12 Oct 2004 17:36:13 +0200 In-Reply-To: (sah@softcardsystems.com's message of "Tue, 12 Oct 2004 11:24:03 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.64 cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: mbuf w/o pkthdr? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 15:36:22 -0000 Sam writes: > Are all packets supposed to have the M_PKTHDR flag? Why? IIRC, M_PKTHDR indicates the first mbuf in a chain when a packet is split across multiple mbufs. This usually only happens for outgoing packets, where protocol headers are constructed in separate mbufs which are prepended to the chain as the packet moves down the stack. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Oct 12 15:44:10 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3B9716A4CE; Tue, 12 Oct 2004 15:44:10 +0000 (GMT) Received: from athena.softcardsystems.com (mail.softcardsystems.com [12.34.136.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4993C43D41; Tue, 12 Oct 2004 15:44:10 +0000 (GMT) (envelope-from sah@softcardsystems.com) Received: from athena (athena [12.34.136.114])i9CGgWlq031724; Tue, 12 Oct 2004 11:42:32 -0500 Date: Tue, 12 Oct 2004 11:42:32 -0500 (EST) From: Sam X-X-Sender: sah@athena To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: mbuf w/o pkthdr? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 15:44:10 -0000 >> Are all packets supposed to have the M_PKTHDR flag? Why? > > IIRC, M_PKTHDR indicates the first mbuf in a chain when a packet is > split across multiple mbufs. This usually only happens for outgoing > packets, where protocol headers are constructed in separate mbufs > which are prepended to the chain as the packet moves down the stack. That's kind of my understanding (with some PACKET_TAG* stuff going on). I don't have split headers, though. Neither would an arp frame, but he too gets a packet header and fills it out. I don't mind following suit, I'm just wondering what the convention is for. Perhaps we use mbufs without packet headers for something special? Sam From owner-freebsd-arch@FreeBSD.ORG Tue Oct 12 15:50:21 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C05616A4CE; Tue, 12 Oct 2004 15:50:21 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14F5E43D1D; Tue, 12 Oct 2004 15:50:21 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.93] ([66.127.85.93]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i9CFoJWi097239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Oct 2004 08:50:20 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <416BFD51.2080805@errno.com> Date: Tue, 12 Oct 2004 08:50:41 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 0.8 (Macintosh/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: mbuf w/o pkthdr? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 15:50:21 -0000 Sam wrote: > Hello - > > src/sys/i386/i386/busdma_machdep.c:/^bus_dmamap_load_mbuf/ > prohibits loading an mbuf that does not contain a packet > header. Some drivers use this (xl), some don't (fxp). > > Are all packets supposed to have the M_PKTHDR flag? Why? M_PKTHDR indicates an m_pkthdr structure is present in the mbuf. bus_dmamap_load_mbuf requires this as it gets the packet length from it (instead of walking the mbuf chain or taking it as an argument). Most packets typically have this information (can't think of any interesting cases where it is not be there). Sam From owner-freebsd-arch@FreeBSD.ORG Tue Oct 12 15:57:46 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DAE216A4CE; Tue, 12 Oct 2004 15:57:46 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8706543D2D; Tue, 12 Oct 2004 15:57:45 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (host5.bedc.ondsl.gr [62.103.39.229])i9CFvf0l001258; Tue, 12 Oct 2004 18:57:41 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i9CFveeT001936; Tue, 12 Oct 2004 18:57:40 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)i9CFve8k001935; Tue, 12 Oct 2004 18:57:40 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Tue, 12 Oct 2004 18:57:40 +0300 From: Giorgos Keramidas To: Dag-Erling Sm?rgrav Message-ID: <20041012155740.GA1648@orion.daedalusnetworks.priv> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: Sam cc: freebsd-current@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: mbuf w/o pkthdr? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 15:57:46 -0000 On 2004-10-12 17:36, Dag-Erling Sm?rgrav wrote: > Sam writes: > > Are all packets supposed to have the M_PKTHDR flag? Why? > > IIRC, M_PKTHDR indicates the first mbuf in a chain when a packet is > split across multiple mbufs. This usually only happens for outgoing > packets, where protocol headers are constructed in separate mbufs > which are prepended to the chain as the packet moves down the stack. AFAIK, all the packets have an M_PKTHDR in the first mbuf of their chain. The presence of an M_PKTHDR flag only means that the beginning of the mbuf contains a (struct pkthdr) before the packet payload. This is not related to the splitting of packets to multiple mbufs or not, though. A small packet might have an M_PKTHDR but still fit in a single mbuf if its payload packet (including protocol headers and data) is less than MHLEN bytes. From owner-freebsd-arch@FreeBSD.ORG Tue Oct 12 16:49:08 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC96716A4CE for ; Tue, 12 Oct 2004 16:49:08 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A938543D41 for ; Tue, 12 Oct 2004 16:49:08 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 9BEA872DD4; Tue, 12 Oct 2004 09:49:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 99EEB72DCB; Tue, 12 Oct 2004 09:49:08 -0700 (PDT) Date: Tue, 12 Oct 2004 09:49:08 -0700 (PDT) From: Doug White To: "Gordan Remus (Vox Mundi)" In-Reply-To: Message-ID: <20041012094659.F41628@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: FreeBSD 4.X and Intel E7520 chipset problems X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2004 16:49:08 -0000 On Tue, 12 Oct 2004, Gordan Remus (Vox Mundi) wrote: > Recently we have purchased a Supermicro X6DHR-IG2 motherboard > based on Intel E7520 chipset with 2x3.0GHz Xeons and are unable > to install FreeBSD 4.X on it. > It seems that FreeBSD 4.X is not recognizing the chipset > and therefore it's unable to recognize Mylex AcceleRAID 160 controller. Its not usually required to specifically support the chipset to enumerate the buses. Can you get a dmesg from it? > Everything is working fine on FreeBSD 5.X, but unfortunately > the application we need to run on top of that is made specifically > for FreeBSD 4.X. > > Is there any chance that Intel E7520 chipset will be supported > on some future 4.X releases or is there some kind of patch/workaround ? > > Best Regards, > Gordan Remus > Technical Department > Vox Mundi > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Oct 13 21:02:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75AAC16A4CE; Wed, 13 Oct 2004 21:02:01 +0000 (GMT) Received: from server1.astraldream.net (astraldream.net [69.20.5.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFC4343D2D; Wed, 13 Oct 2004 21:02:00 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated (0 bits)) by server1.astraldream.net (8.11.6/8.11.6) with ESMTP id i9DL1rX13719 (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits) verified NO); Wed, 13 Oct 2004 17:01:59 -0400 In-Reply-To: <200410111930.i9BJUODI068849@gw.catspoiler.org> References: <200410111930.i9BJUODI068849@gw.catspoiler.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1C45EA64-1D5B-11D9-A525-000A95C4D7BC@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Wed, 13 Oct 2004 17:01:53 -0400 To: Don Lewis X-Mailer: Apple Mail (2.619) cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 21:02:01 -0000 Hi, On Oct 11, 2004, at 3:30 PM, Don Lewis wrote: > There seems to be a lot of locking/unlocking overhead in the oid lookup > and oid tree manipulation code. Doing the traversals at each level of > the tree without holding a lock for the entire time makes me nervous, > though I can't point to any specific problem. It might be better to > just hold a single lock across then entire lookup, insertion, or > deletion operation. Thanks for your reply! I think you are right. It would also make the locking much simpler. However, there is the problem that sysctl handlers can sleep, so we shouldn't be holding a mutex when calling them.. > What happens if: > thread A owns an oid > > thread B, which wants to delete the oid, goes to sleep to wait > for the oid > > thread C wants the oid and goes to sleep > > thread A releases the oid and wakes up thread B > > thread B deletes the oid > > thread C does ??? I didn't think of this possibility. I guess I'll have to rethink the whole thing, whenever I find some time. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Oct 13 21:17:22 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2CF316A4CE; Wed, 13 Oct 2004 21:17:22 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0864C43D39; Wed, 13 Oct 2004 21:17:22 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9DLHEKS076320; Wed, 13 Oct 2004 14:17:18 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410132117.i9DLHEKS076320@gw.catspoiler.org> Date: Wed, 13 Oct 2004 14:17:14 -0700 (PDT) From: Don Lewis To: ssouhlal@FreeBSD.org In-Reply-To: <1C45EA64-1D5B-11D9-A525-000A95C4D7BC@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2004 21:17:22 -0000 On 13 Oct, Suleiman Souhlal wrote: > Hi, > > On Oct 11, 2004, at 3:30 PM, Don Lewis wrote: >> There seems to be a lot of locking/unlocking overhead in the oid lookup >> and oid tree manipulation code. Doing the traversals at each level of >> the tree without holding a lock for the entire time makes me nervous, >> though I can't point to any specific problem. It might be better to >> just hold a single lock across then entire lookup, insertion, or >> deletion operation. > > Thanks for your reply! I think you are right. It would also make the > locking much simpler. However, there is the problem that sysctl > handlers can sleep, so we shouldn't be holding a mutex when calling > them.. Unlock the mutex after doing the lookup and getting ownership of the oid, and before calling the handler. From owner-freebsd-arch@FreeBSD.ORG Thu Oct 14 18:53:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 962EC16A4CE for ; Thu, 14 Oct 2004 18:53:26 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id D030943D31 for ; Thu, 14 Oct 2004 18:53:25 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i9EIrOgR070820 for ; Thu, 14 Oct 2004 20:53:24 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org From: Poul-Henning Kamp Date: Thu, 14 Oct 2004 20:53:24 +0200 Message-ID: <70819.1097780004@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: tty code, status and future... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2004 18:53:26 -0000 I'm done hashing tty code for now and I'll take a break away from it for some time. Apart from the 3000 lines less copy&paste code we are now able to safely remove a serial port which is being used (not all drivers support this yet though). A number of drivers still need some minor polishing mostly related to how tty structures are allocated and managed. The next logical step is to sort out the tty <-> linedisc stuff and decide where snoop(4) fits into the bigger picture. When that is sorted out, we can try to remove Giant. But as I said: I'm taking a break for now, I'll be hacking bufcache instead. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Fri Oct 15 06:14:43 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1561116A4CE; Fri, 15 Oct 2004 06:14:43 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F10243D55; Fri, 15 Oct 2004 06:14:42 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id i9F6EYwQ080109; Thu, 14 Oct 2004 23:14:39 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200410150614.i9F6EYwQ080109@gw.catspoiler.org> Date: Thu, 14 Oct 2004 23:14:34 -0700 (PDT) From: Don Lewis To: ssouhlal@FreeBSD.org In-Reply-To: <1C45EA64-1D5B-11D9-A525-000A95C4D7BC@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-arch@FreeBSD.org Subject: Re: [RFC] sysctl locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2004 06:14:43 -0000 On 13 Oct, Suleiman Souhlal wrote: >> What happens if: >> thread A owns an oid >> >> thread B, which wants to delete the oid, goes to sleep to wait >> for the oid >> >> thread C wants the oid and goes to sleep >> >> thread A releases the oid and wakes up thread B >> >> thread B deletes the oid >> >> thread C does ??? > > I didn't think of this possibility. I guess I'll have to rethink the > whole thing, whenever I find some time. Have thread B mark the oid as deleted and disconnect it from the tree. When any subsequent waiting threads gain ownership, have them return ENOENT if they see the deleted flag instead of calling the handler. Free the oid when the last waiting thread gives up ownership. From owner-freebsd-arch@FreeBSD.ORG Sat Oct 16 17:44:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E58E316A4CE for ; Sat, 16 Oct 2004 17:44:20 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9592B43D4C for ; Sat, 16 Oct 2004 17:44:20 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id i9GHiJ4I096803 for ; Sat, 16 Oct 2004 10:44:19 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i9GHiJu2096802 for freebsd-arch@freebsd.org; Sat, 16 Oct 2004 10:44:19 -0700 (PDT) (envelope-from obrien) Date: Sat, 16 Oct 2004 10:44:19 -0700 From: "David O'Brien" To: freebsd-arch@freebsd.org Message-ID: <20041016174419.GA96297@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Subject: Proposal to restore traditional BSD behavior in . X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 17:44:21 -0000 I'd like to restore the traditional BSD behavior that includes the content of in addition to the BSD bcmp, et. al. We changed our between 4.x and 5.x and now that we're at 5-STABLE I'm finding software that built fine on 4.x has an issue on 5.x. Index: strings.h =================================================================== RCS file: /home/ncvs/src/include/strings.h,v retrieving revision 1.6 diff -u -r1.6 strings.h --- strings.h 23 Jul 2004 07:13:35 -0000 1.6 +++ strings.h 16 Oct 2004 17:09:40 -0000 @@ -31,6 +31,7 @@ #include #include +#include #ifndef _SIZE_T_DECLARED typedef __size_t size_t; -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Sat Oct 16 17:57:33 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D4C916A4CE; Sat, 16 Oct 2004 17:57:33 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BCA443D1F; Sat, 16 Oct 2004 17:57:32 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (sccrmhc12) with ESMTP id <2004101617572901200fs69re>; Sat, 16 Oct 2004 17:57:29 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost [127.0.0.1]) i9GHvbdW079641; Sat, 16 Oct 2004 13:57:38 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)i9GHvb1M079640; Sat, 16 Oct 2004 13:57:37 -0400 (EDT) (envelope-from rodrigc) Date: Sat, 16 Oct 2004 13:57:37 -0400 From: Craig Rodrigues To: "David O'Brien" Message-ID: <20041016175737.GA79623@crodrigues.org> References: <20041016174419.GA96297@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041016174419.GA96297@dragon.nuxi.com> User-Agent: Mutt/1.4.1i cc: freebsd-standards@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: Proposal to restore traditional BSD behavior in . X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 17:57:33 -0000 On Sat, Oct 16, 2004 at 10:44:19AM -0700, David O'Brien wrote: > I'd like to restore the traditional BSD behavior that > includes the content of in addition to the BSD bcmp, et. al. > We changed our between 4.x and 5.x and now that we're at > 5-STABLE I'm finding software that built fine on 4.x has an issue on 5.x. What do the standards@ people have to say about this? I don't see anything in the Single Unix Specification which would prohibit this: http://www.opengroup.org/onlinepubs/000095399/basedefs/strings.h.html but I am not good at interpreting standards. -- Craig Rodrigues http://crodrigues.org rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Sat Oct 16 18:32:03 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46AC816A4CE; Sat, 16 Oct 2004 18:32:03 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id E962C43D54; Sat, 16 Oct 2004 18:32:02 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i9GIW2pe077051; Sat, 16 Oct 2004 14:32:02 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i9GIW296077050; Sat, 16 Oct 2004 14:32:02 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Sat, 16 Oct 2004 14:32:02 -0400 From: David Schultz To: "David O'Brien" Message-ID: <20041016183202.GA76917@VARK.MIT.EDU> Mail-Followup-To: David O'Brien , freebsd-arch@FreeBSD.ORG References: <20041016174419.GA96297@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041016174419.GA96297@dragon.nuxi.com> cc: freebsd-arch@FreeBSD.ORG Subject: Re: Proposal to restore traditional BSD behavior in . X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 18:32:03 -0000 On Sat, Oct 16, 2004, David O'Brien wrote: > I'd like to restore the traditional BSD behavior that > includes the content of in addition to the BSD bcmp, et. al. > We changed our between 4.x and 5.x and now that we're at > 5-STABLE I'm finding software that built fine on 4.x has an issue on 5.x. It has been this way for 2.5 years, and nobody has complained until now AFAIK. Therefore, it seems unlikely that there's enough affected unportable software out there to justify undoing the efforts at reducing namespace pollution now. Moreover, there's a *lot* of pollution in string.h, where as strings.h has very little. Polluting strings.h again increases the chances that portable applications that use strings.h will break due to naming conflicts. > Index: strings.h > =================================================================== > RCS file: /home/ncvs/src/include/strings.h,v > retrieving revision 1.6 > diff -u -r1.6 strings.h > --- strings.h 23 Jul 2004 07:13:35 -0000 1.6 > +++ strings.h 16 Oct 2004 17:09:40 -0000 > @@ -31,6 +31,7 @@ > > #include > #include > +#include You'd want to wrap this in #if __BSD_VISIBLE as well... From owner-freebsd-arch@FreeBSD.ORG Sat Oct 16 23:58:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03DE616A4CE; Sat, 16 Oct 2004 23:58:11 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9067943D1D; Sat, 16 Oct 2004 23:58:10 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i9GNw7IS009691; Sat, 16 Oct 2004 19:58:09 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20041016174419.GA96297@dragon.nuxi.com> References: <20041016174419.GA96297@dragon.nuxi.com> Date: Sat, 16 Oct 2004 19:58:07 -0400 To: obrien@freebsd.org, freebsd-arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Proposal to restore traditional BSD behavior in . X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2004 23:58:11 -0000 At 10:44 AM -0700 10/16/04, David O'Brien wrote: >I'd like to restore the traditional BSD behavior that >includes the content of in addition to the BSD bcmp, >et. al. We changed our between 4.x and 5.x and now >that we're at 5-STABLE I'm finding software that built fine on >4.x has an issue on 5.x. I think it is definitely too late to do this for 5.3-RELEASE, because we have no idea what software might be compiling fine right now, but may break due to namespace conflicts if starts pulling in . It looks like 5.x has gone 2 and a half years with not including , and if we also ship 5.3-release in that state then I suspect there isn't much point in switching back after 5.3-release. I have no particular objection to the *idea*, but I think we are past the point were we could make such a change. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu