From owner-freebsd-questions@FreeBSD.ORG Tue Dec 9 12:23:35 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D45A16A4CF; Tue, 9 Dec 2003 12:23:35 -0800 (PST) Received: from stats.net (legolas.counted.com [66.230.158.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7C4243D30; Tue, 9 Dec 2003 12:23:32 -0800 (PST) (envelope-from fthylmann@stats.net) Received: from notefabi ([172.176.95.126]) by stats.net ; Tue, 09 Dec 2003 15:23:08 -0500 Message-ID: <000d01c3be92$4fe92d10$2102a8c0@NoteFabi> From: "Fabian Thylmann" To: "Robert Watson" References: Date: Tue, 9 Dec 2003 21:23:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on legolas.counted.com X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 cc: freebsd-questions@freebsd.org Subject: Re: inode state X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2003 20:23:35 -0000 > Hmm. Kqueue should be thread-safe in that it's a system call, but I can't > speak to the safety of various arguments/parameters. I don't know if > linuxthreads tries to provide locking around file descriptors and might > have reference problems if kqueue were held over a call to close(), but it > could be kqueue will "just work" with linuxthreads. Do calls like > select()/poll() require thread-safe versions in linuxthreads? Yeah, select/poll is not needed, but the thing is that my app, which I just changed from pthreads to linuxthreads, did all ok, launched threads and all, but it crashed when running kevent() and all the referrences it gave to kevent() were fine. > Do you have an outstanding PR on the LSI problem, and/or a stack trace for > the trap? In the past, our LSI drivers have been fairly well maintained > on the LSI side. I can certainly try shaking some branches and see if > anything falls down, if there's a detailed bug report I can point at. I have no PR nor do I have a stack trace for the trap right now. How would I exactly get a stack trace of the trap? It happends when booting from the 5.2-beta cd-rom. Let me know when you need from me and I'll get all that. The box is at a hosting provider so I'll have to get the info from them. > I know some work has been done relating to this problem at Yahoo, > especially relating to disk fragmentation resulting from allocation using > mmap on sparse files. You might want to try posting about this problem on > freebsd-fs or freebsd-current and see if you manage to hook someone who's > been looking at this. Thanks, I'll give that a try. Fabian