From owner-freebsd-current@FreeBSD.ORG Sun May 11 00:08:30 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 E2CBB37B401 for ; Sun, 11 May 2003 00:08:30 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F29643FBF for ; Sun, 11 May 2003 00:08:29 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id RAA25434 for ; Sun, 11 May 2003 17:08:24 +1000 Date: Sun, 11 May 2003 17:08:23 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: freebsd-current@freebsd.org In-Reply-To: <20030510141840.Q2955@gamplex.bde.org> Message-ID: <20030511170706.F74671@gamplex.bde.org> References: <20030508.124929.74756191.haro@kgt.co.jp> <20030508.102242.72244093.imp@bsdimp.com> <20030508.111836.130233489.imp@bsdimp.com> <20030510141840.Q2955@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: LOR with -current 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: Sun, 11 May 2003 07:08:31 -0000 [Resending with trimmed Cc: after second bounce] On Thu, 8 May 2003, M. Warner Losh wrote: > In message: <16058.36990.299231.566625@grasshopper.cs.duke.edu> > Andrew Gallatin writes: > : > : M. Warner Losh writes: > : > That reminds me, would anybody object if I were to hack traceback so > : > that it would actually put the traceback in the dmesg buffer when not > : > called from ddb? Yes. No hacks please. See old mail about how to implement this not very hackishly (basically s/db_printf/printf/g, and change printf to act like the old db_printf iff db_active is set; this would also fix the bug of forgetting to use db_printf in ddb commands and reduce the bugs for abusing non-ddb commands as ddb commands). > : FWIW, I think that tracebacks generated from DDB_TRACE should also > : go into the dmesg buffer. It would save quite a few initial exchanges > : with users.. I think that DDB_TRACE shouldn't have been committed until it did this. > Does anybdoy know why the ddb output doesn't go into the dmesg buffer > in general? It sure would save me a lot of grief as well if it did. Yes. 1. The message buffer (and some other aspects of printf() as opposed to db_printf()) is highly non-reentrant and lock-deficient. This is broken in general. printf() can panic when it is called in certain not very unusual contexts, and ddb is often needed in these contexts. Also, using ddb in the relatively unusual context of debugging the message buffer itself would cause unbounded recursion if ddb output always went to the message buffer. 2. ddb output tends to be large and not very useful. It can push normal kernel messages (not to mention ddb messages) out of the message buffer before they can be seen by syslog. Just thought of another problem: the traceback can trap if it gets confused about the stack frame and/or the number of args. In ddb context, these traps are handled properly using setjmp() (except trap() barfs about them unsafely and unusefully using ordinary printf before it reenters ddb). This safety harness is missing if the traceback is done outside of ddb. You really don't want debugging messages about a problem compounding the problem. Bruce From owner-freebsd-current@FreeBSD.ORG Sun May 11 00:09:06 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 1582037B401; Sun, 11 May 2003 00:09:06 -0700 (PDT) Received: from critter.freebsd.dk (port757.uc1-esp.isdn-lan.cybercity.dk [212.242.98.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id A74A743FBD; Sun, 11 May 2003 00:09:02 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h4B78x56085745; Sun, 11 May 2003 09:09:00 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: obrien@freebsd.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 10 May 2003 20:51:04 PDT." <20030511035104.GA17878@dragon.nuxi.com> Date: Sun, 11 May 2003 09:08:59 +0200 Message-ID: <85744.1052636939@critter.freebsd.dk> cc: freebsd-current@freebsd.org Subject: Re: GEOM loose end? 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: Sun, 11 May 2003 07:09:06 -0000 In message <20030511035104.GA17878@dragon.nuxi.com>, "David O'Brien" writes: >On Fri, May 09, 2003 at 10:14:52PM +0200, Poul-Henning Kamp wrote: >> We _really_ need to revist the area of disk management programs, >> there is a bid out there called "libwhisk" which as far as I can >> tell would make a good foundation. > >Do you have a pointer to "libwhisk"? The only documented site for it >(http://www.gjvc.com/projects/libwhisk/) gives a 404 responce. Here is a copy of the copy I have: http://phk.freebsd.dk/misc/libwhisk.tar.gz -- 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-current@FreeBSD.ORG Sun May 11 00:40:35 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 66EAC37B401 for ; Sun, 11 May 2003 00:40:35 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00D9343FD7 for ; Sun, 11 May 2003 00:40:34 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id RAA27637; Sun, 11 May 2003 17:40:15 +1000 Date: Sun, 11 May 2003 17:40:14 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Poul-Henning Kamp In-Reply-To: <40211.1052584093@critter.freebsd.dk> Message-ID: <20030511170900.P74675@gamplex.bde.org> References: <40211.1052584093@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: Mark Murray Subject: Re: buildworld b?rkedinlibpam 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: Sun, 11 May 2003 07:40:35 -0000 On Sat, 10 May 2003, Poul-Henning Kamp wrote: > In message <200305101515.h4AFFU8c039592@grimreaper.grondar.org>, Mark Murray wr > ites: > >"Poul-Henning Kamp" writes: > >> >> http://phk.freebsd.dk/misc/_.ia64.buildworld > >> > > >> >AHA! > >> > > >> >Please try this patch (you may need to do it manually because of c&p > >> >fubaring): [Context with patch lost] > >> Started, report to follow... > > > >Thanks! :-) > > > >I'm very confident about this. If it works for all archs, I'd like to get > >it into 5.1. > > Well, it didn't. It failed for both ia64 and i386 so far :-( The patch seems to fix one aspect of the problem. It restores creation of ${WORLDTMP}/usr/include/openssl/ in the loop that creates ${WORLDTMP}/usr/include/. This cannot be a complete fix, since there are many other subdirs of ${WORLDTMP}/usr/include/ that need to be created before they are used. The main problem seems to be that the _includes target needs to build at least its second subdir (src/include) before the others, but it does the opposite of this -- it uses par-includes to run "make includes" in the subdirs concurrently. Untested quick fix: %%% Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.356 diff -u -0 -r1.356 Makefile.inc1 --- Makefile.inc1 5 May 2003 12:54:26 -0000 1.356 +++ Makefile.inc1 11 May 2003 07:21:11 -0000 @@ -330 +404,1 @@ - cd ${.CURDIR}; ${WMAKE} SHARED=symlinks par-includes + cd ${.CURDIR}; ${WMAKE} SHARED=symlinks includes %%% Bruce From owner-freebsd-current@FreeBSD.ORG Sun May 11 00:58:53 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 45C0F37B401; Sun, 11 May 2003 00:58:53 -0700 (PDT) Received: from mail.unixguru.nl (mosibi.demon.nl [212.238.240.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DA9743FDD; Sun, 11 May 2003 00:58:51 -0700 (PDT) (envelope-from richard@unixguru.nl) Received: from mail (mail [192.168.10.4]) by mail.unixguru.nl (8.12.9/8.12.9) with ESMTP id h4B7wZUw073155 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 11 May 2003 09:58:38 +0200 (CEST) (envelope-from richard@unixguru.nl) Date: Sun, 11 May 2003 09:58:35 +0200 (CEST) From: Richard Arends To: Johan Karlsson In-Reply-To: <20030509180233.GA600@numeri.campus.luth.se> Message-ID: <20030511095512.Y55105@mail.unixguru.nl> References: <20030509180233.GA600@numeri.campus.luth.se> X-message-flag: Get yourself a real mail client! http://www.washington.edu/pine/ X-Accepted-File-Formats: ASCII .rtf .ps - *NO* MS Office files please. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) cc: current@freebsd.org Subject: Re: ACPI temperature monitor for current 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: Sun, 11 May 2003 07:58:53 -0000 On Fri, 9 May 2003, Johan Karlsson wrote: Johan, > can anyone recomend some program to monitor temperature > and fan speed? I have had some problems with my fan > and the computer hang due to the heat and now I would > like to have some program that will tell me the current > temperature and fan speed. I'm running a fairly current > -current and will upgrade to the latest ACPI import > if necesary. Begin Februari I made a port for gkrellmgas. A Gkrellm2 plugin that monitors the system temp. It is not committed yet to the ports collection, but you can get it from: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/47856 Regards, Richard. ---- Paul Vixie in an interview with Sendmail.net: Now that the Internet has the full spectrum of humanity as users, the technology is showing its weakness: it was designed to be used by friendly, smart people. Spammers, as an example of a class, are neither friendly nor smart. From owner-freebsd-current@FreeBSD.ORG Sun May 11 01:49:22 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 59EF837B401 for ; Sun, 11 May 2003 01:49:22 -0700 (PDT) Received: from ferengi.borderworlds.dk (borderworlds.dk [62.79.110.124]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65B7C43FCB for ; Sun, 11 May 2003 01:49:21 -0700 (PDT) (envelope-from xi@borderworlds.dk) Received: from borg.borderworlds.dk (localhost [127.0.0.1]) by ferengi.borderworlds.dk (Postfix) with ESMTP id 0D6245C78 for ; Sun, 11 May 2003 10:49:19 +0200 (CEST) Received: by borg.borderworlds.dk (Postfix, from userid 500) id D49493B8008; Sun, 11 May 2003 10:49:17 +0200 (CEST) Sender: xi@borderworlds.dk To: freebsd-current@freebsd.org References: From: Christian Laursen Date: 11 May 2003 10:49:17 +0200 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Docs for filesystem snapshots on FreeBSD 5.0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2003 08:49:22 -0000 Per von Zweigbergk writes: > The new filesystem snapshot functionality in FreeBSD 5.0 seems very > interesting to make it possible to consistently back up > filesystems. However, I have found very little information about this > when googling for this information. > > Any pointers? It's in the handbook. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/snapshots.html -- Best regards Christian Laursen From owner-freebsd-current@FreeBSD.ORG Sun May 11 02:43:34 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 B2B7A37B401 for ; Sun, 11 May 2003 02:43:34 -0700 (PDT) Received: from castle.jp.FreeBSD.org (castle.jp.FreeBSD.org [210.226.20.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D87743FE0 for ; Sun, 11 May 2003 02:43:33 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [::1])h4B9hVY86797 for ; Sun, 11 May 2003 18:43:31 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) In-Reply-To: <3EBD16E4.1060903@jocose.org> References: <20030509115517.GF6082@pcwin002.win.tue.nl> <20030509222224L.matusita@jp.FreeBSD.org> <3EBD16E4.1060903@jocose.org> X-User-Agent: Mew/1.94.2 Emacs/21.3 X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20030322(IM144) Lines: 14 From: Makoto Matsushita To: current@freebsd.org Date: Sun, 11 May 2003 18:43:29 +0900 Message-Id: <20030511184329Y.matusita@jp.FreeBSD.org> Subject: Re: The sysinstall's safe_realloc() failure 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: Sun, 11 May 2003 09:43:35 -0000 peter> This works for me. Some problem with the lukemftpd I guess. Hmm, maybe. However, you know, lukemftpd is *old*; I'm just installing tnftpd 2.0 beta3 to the host (ya ya, it is easy to make ports/ftp/tnftpd from ports/ftp/lukemftpd. If it goes well, I'll put it to ports repository later). Anybody interests in this issue, please try ftp-install 5-current (actually 5.1-BETA) from snapshots.jp.FreeBSD.org, and email me your experiences. -- - Makoto `MAR' Matsushita From owner-freebsd-current@FreeBSD.ORG Sun May 11 02:49:04 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 1B86F37B401 for ; Sun, 11 May 2003 02:49:04 -0700 (PDT) Received: from mail.g.bonet.se (mail.g.bonet.se [212.181.52.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E20DF43FAF for ; Sun, 11 May 2003 02:49:02 -0700 (PDT) (envelope-from pvz@linux.se) Received: from linux.se (as14-6-3.o.s.bonet.se [217.215.216.100]) by mail.g.bonet.se (8.12.9/8.12.9) with ESMTP id h4B9mMHp074989 for ; Sun, 11 May 2003 11:48:23 +0200 (CEST) (envelope-from pvz@linux.se) Date: Sun, 11 May 2003 11:49:07 +0200 Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Per von Zweigbergk To: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Subject: Re: Docs for filesystem snapshots on FreeBSD 5.0? 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: Sun, 11 May 2003 09:49:04 -0000 s=F6ndagen den 11 maj 2003 kl 10.49 skrev Christian Laursen: > Per von Zweigbergk writes: > >> The new filesystem snapshot functionality in FreeBSD 5.0 seems very >> interesting to make it possible to consistently back up >> filesystems. However, I have found very little information about this >> when googling for this information. >> >> Any pointers? > > It's in the handbook. > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/=20 > snapshots.html Thank you. I should have searched for "file system" as well as =20 "filesystem". I'm going to go stand in a corner for a few minutes now. =20= :-) --=20 Per von Zweigbergk From owner-freebsd-current@FreeBSD.ORG Sun May 11 03:17:49 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 A2DD937B401; Sun, 11 May 2003 03:17:45 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80F8643FA3; Sun, 11 May 2003 03:17:43 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id UAA07438; Sun, 11 May 2003 20:17:39 +1000 Date: Sun, 11 May 2003 20:17:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Maxime Henrion In-Reply-To: <20030510221612.GT21011@elvis.mu.org> Message-ID: <20030511195402.C75054@gamplex.bde.org> References: <20030509163718.GA22231@rot13.obsecurity.org> <20030510221612.GT21011@elvis.mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kris Kennaway cc: alpha@freebsd.org cc: Andrew Gallatin cc: current@freebsd.org Subject: Re: Unaligned access fault in fxp on alpha 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: Sun, 11 May 2003 10:17:49 -0000 On Sun, 11 May 2003, Maxime Henrion wrote: > I removed them because they were just looking bogus. I wanted to ask > people to test a patch adding a __packed in the struct definition to see > if it fixed things. If it works with a __packed keyword, I'd like > it better than going back to having an array of four u_int8_t. > Otherwise I'll put the u_int8_t back. __packed looks very bogus to me. It is a syntax error for non-gcc compilers. The code was apparently originally carefully written to not depend on gccisms. I think __packed is also a pessimization here on some arches. The struct also has some u_int16_t's which are aligned, but __packed says that everything may be misaligned (unless you also use __aligned(mumble)). On some arches, the compiler will have to access everything as bytes and reassemble, or more complicated things if byte accesses are impossible. Since the accesses are for machine registers, the accesses with unusual widths and/or alignments for this may even be bugs. I just noticed that gcc now has some warnings -Wpacked and -Wpadded to help detect gratuitous use of __packed and errors in explicit packing/ padding. Bruce From owner-freebsd-current@FreeBSD.ORG Sun May 11 04:02:44 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 ED2E237B401 for ; Sun, 11 May 2003 04:02:43 -0700 (PDT) Received: from moya.lambermont.dyndns.org (e165253.upc-e.chello.nl [213.93.165.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A90643FE3 for ; Sun, 11 May 2003 04:02:43 -0700 (PDT) (envelope-from hans@lambermont.dyndns.org) Received: from localhost (localhost [127.0.0.1]) by moya.lambermont.dyndns.org (Postfix) with ESMTP id 6B5B936599; Sun, 11 May 2003 13:02:41 +0200 (CEST) Received: by moya.lambermont.dyndns.org (Postfix, from userid 1001) id 0E2B436403; Sun, 11 May 2003 13:02:39 +0200 (CEST) Date: Sun, 11 May 2003 13:02:39 +0200 To: Kenneth Culver Message-ID: <20030511110238.GA80065@moya.lambermont.dyndns.org> References: <20030510173400.P1131@gravy.homeunix.net> <20030510173620.E76533-100000@alpha.yumyumyum.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030510173620.E76533-100000@alpha.yumyumyum.org> User-Agent: Mutt/1.4i From: hans@lambermont.dyndns.org (Hans Lambermont) X-Virus-Scanned: by AMaViS perl-11 cc: freebsd-current@freebsd.org Subject: Re: atapicam 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: Sun, 11 May 2003 11:02:49 -0000 Kenneth Culver wrote: > I fixed my problem, I did a make includes in /usr/src, then rebuilt > libcam, and rebuilt cdrtools, everything works now. Doesn't work for me :-/ gagh# camcontrol devlist camcontrol: error sending CAMIOCOMMAND ioctl: Inappropriate ioctl for device I also booted a fresh kernel. Maybe 'make includes in /usr/src', 'make libcam in /usr/src/lib', 'make install in /usr/src/lib/libcam' is not enough for this camcontrol update ? Hints are welcome :-) Hans -- http://lambermont.webhop.org/ () ascii ribbon campaign - against HTML mail, /\ vCards and proprietary formats From owner-freebsd-current@FreeBSD.ORG Sun May 11 04:21:19 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 42D4637B401 for ; Sun, 11 May 2003 04:21:19 -0700 (PDT) Received: from mail.rdslink.ro (mail.rdslink.ro [193.231.236.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5F2FD43FE9 for ; Sun, 11 May 2003 04:21:17 -0700 (PDT) (envelope-from enache@rdslink.ro) Received: (qmail 7134 invoked from network); 11 May 2003 11:24:28 -0000 Received: from unknown (HELO ratsnest.hole) (10.100.0.30) by mail.rdslink.ro with SMTP; 11 May 2003 11:24:28 -0000 Date: Sun, 11 May 2003 14:22:47 +0300 From: Enache Adrian To: current@freebsd.org Message-ID: <20030511112247.GA794@ratsnest.hole> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i cc: deischen@freebsd.org Subject: bin/51535, bin/49087 - please do something about libc_r bugs 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: Sun, 11 May 2003 11:21:19 -0000 There are two PRs I submitted about blatant bugs in libc_r: bin/49087 bin/51535 the first is something one can live with it; the second is far more serious and already caused a lot of naughty breakage; both affect programs linked against libc_r, even if they don't use a single bit of the pthread_* stuff. The second seems to have propagated to the -STABLE branch too (or the other way around ?) and to NetBSD and OpenBSD. I guess libc_r will still be the default for a period of time - so please take a look at those bugs and do something about them before 5.1. Regards, Adi From owner-freebsd-current@FreeBSD.ORG Sun May 11 04:54:16 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 F3D4437B401 for ; Sun, 11 May 2003 04:54:15 -0700 (PDT) Received: from mx.j10n.org (203.141.155.228.user.ca.il24.net [203.141.155.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 715A343F93 for ; Sun, 11 May 2003 04:54:14 -0700 (PDT) (envelope-from shinra@j10n.org) Received: from e-note.j10n.org (e-note.j10n.org [IPv6:2002:cb8d:9be4:1::1]) by mx.j10n.org (8.12.8p1/8.12.8) with ESMTP id h4BBsCwm071620 for ; Sun, 11 May 2003 20:54:12 +0900 (JST) (envelope-from shinra@j10n.org) Received: from e-note.j10n.org (localhost [IPv6:::1]) by e-note.j10n.org (8.12.9/8.12.9) with ESMTP id h4BBsBlc002016 for ; Sun, 11 May 2003 20:54:12 +0900 (JST) (envelope-from shinra@j10n.org) Date: Sun, 11 May 2003 20:54:11 +0900 Message-ID: <86bry9snq4.wl@j10n.org> From: AIDA Shinra To: freebsd-current@freebsd.org User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.4 MULE XEmacs/21.4 (patch 10) (Military Intelligence) (i386-unknown-freebsd4.7) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Subject: LOR: vm_object.c and vm_kern.c 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: Sun, 11 May 2003 11:54:16 -0000 I got following LOR message today. Vm_object.c was rev 1.287. lock order reversal 1st 0xc203c688 vm object (vm object) @ /usr/freebsd/src/sys/vm/vm_object.c:512 2nd 0xc082f110 system map (system map) @ /usr/freebsd/src/sys/vm/vm_kern.c:325 Stack backtrace: backtrace(c038cad0,c082f110,c039c77a,c039c77a,c039c609) at backtrace+0x17 witness_lock(c082f110,8,c039c609,145,0) at witness_lock+0x697 _mtx_lock_flags(c082f110,0,c039c609,145,3) at _mtx_lock_flags+0xb1 _vm_map_lock(c082f0b0,c039c609,145,ccea6a18,c01f4be4) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,ccea6a84,c030b500) at kmem_malloc+0x66 page_alloc(c083a240,1000,ccea6a77,101,c03c570c) at page_alloc+0x27 slab_zalloc(c083a240,101,c039e03e,66f,c18684a4) at slab_zalloc+0x150 uma_zone_slab(c083a240,101,c039e03e,66f,0) at uma_zone_slab+0xd8 uma_zalloc_internal(c083a240,0,101,6ef,0) at uma_zalloc_internal+0x55 uma_zfree_arg(c1868480,cc9a69b4,0,1,0) at uma_zfree_arg+0x2cb swp_pager_meta_free_all(c203c688,c039bfee,c039bf7a,1af) at swp_pager_meta_free_a ll+0x1b0 swap_pager_dealloc(c203c688,1,c039df29,10b,0) at swap_pager_dealloc+0x113 vm_pager_deallocate(c203c688,0,c039d0cf,25e,c03fb888) at vm_pager_deallocate+0x3 d vm_object_terminate(c203c688,0,c039d0cf,200,c22e30f0) at vm_object_terminate+0x1 f4 vm_object_deallocate(c203c688,c22e30f0,c203c688,c22e30f0,ccea6c24) at vm_object_ deallocate+0x217 vm_map_entry_delete(c1c66000,c22e30f0,c039c7e8,86e,0) at vm_map_entry_delete+0x3 b vm_map_delete(c1c66000,0,bfc00000,c1c66000,c1847c00) at vm_map_delete+0x453 vm_map_remove(c1c66000,0,bfc00000,111,c0389ff3) at vm_map_remove+0x58 exit1(c1c3be40,f,c0389ff3,8bb,81) at exit1+0x626 sigexit(c1c3be40,f,c0389ff3,844,0) at sigexit+0x1a7 postsig(f,0,c038c55c,f7,20800) at postsig+0x11b ast(ccea6d48) at ast+0x448 doreti_ast() at doreti_ast+0x17 From owner-freebsd-current@FreeBSD.ORG Sun May 11 05: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 5DFC637B401 for ; Sun, 11 May 2003 05:29:33 -0700 (PDT) Received: from pl122.evertek.net (pl122.evertek.net [216.51.178.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6055043F75 for ; Sun, 11 May 2003 05:29:32 -0700 (PDT) (envelope-from klaatu@evertek.net) Received: from pl122.evertek.net (localhost [127.0.0.1]) by pl122.evertek.net (8.12.9/8.12.9) with ESMTP id h4BCRaX3026214 for ; Sun, 11 May 2003 07:27:36 -0500 (CDT) (envelope-from klaatu@evertek.net) Received: (from klaatu@localhost) by pl122.evertek.net (8.12.9/8.12.9/Submit) id h4BCRQb0026101 for current@freebsd.org; Sun, 11 May 2003 07:27:26 -0500 (CDT) X-Authentication-Warning: aristotle.pl122.evertek.net: klaatu set sender to klaatu@evertek.net using -f Date: Sun, 11 May 2003 07:27:26 -0500 From: Mike Dean To: current@freebsd.org Message-ID: <20030511122726.GA16355@evertek.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Organization: Engedi Technology X-Preferred-Format: text/plain X-Operating-System: FreeBSD 5.0-CURRENT X-Mail-System: fetchmail, procmail, mutt, vim, abook Subject: buildworld freeze in share/doc/papers/beyond4.3 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: Sun, 11 May 2003 12:29:33 -0000 The last couple CVSup's I've done (one a couple days ago, one last night), make buildworld has hung when building in share/doc/papers/beyond4.3, when running groff. Groff runs with near-full processor consumption indefinately (I started the buildworld at 11:30 last night, and groff was still running at 7:25 this morning - a buildworld usually takes me about 1 1/2 - 2 hrs). -Michael From owner-freebsd-current@FreeBSD.ORG Sun May 11 05:45:14 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 0457537B401 for ; Sun, 11 May 2003 05:45:14 -0700 (PDT) Received: from sv02.webonaut.com (kirk.webonaut.com [212.41.243.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14E4943FB1 for ; Sun, 11 May 2003 05:45:13 -0700 (PDT) (envelope-from klammer@webonaut.com) Received: from localhost (localhost [127.0.0.1]) by sv02.webonaut.com (Postfix) with ESMTP id E46717644D; Sun, 11 May 2003 14:45:10 +0200 (CEST) Received: from sv02.webonaut.com ([127.0.0.1]) by localhost (sv02.webonaut.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48497-04; Sun, 11 May 2003 14:45:08 +0200 (CEST) Received: from mail.webonaut.com (localhost [127.0.0.1]) by sv02.webonaut.com (Postfix) with SMTP id B9D407644B; Sun, 11 May 2003 14:45:07 +0200 (CEST) Received: from sisko.webonaut.com ([212.41.243.28]) (SquirrelMail authenticated user klammer) by mail.webonaut.com with HTTP; Sun, 11 May 2003 14:45:07 +0200 (CEST) Message-ID: <49368.212.41.243.28.1052657107.squirrel@mail.webonaut.com> In-Reply-To: <20030511122726.GA16355@evertek.net> References: <20030511122726.GA16355@evertek.net> Date: Sun, 11 May 2003 14:45:07 +0200 (CEST) From: "Franz Klammer" To: "Mike Dean" User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: buildworld freeze in share/doc/papers/beyond4.3 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: Sun, 11 May 2003 12:45:14 -0000 Mike Dean sagte: > The last couple CVSup's I've done (one a couple days ago, one last > night), make buildworld has hung when building in > share/doc/papers/beyond4.3, when running groff. Groff runs with > near-full processor consumption indefinately (I started the buildworld > at 11:30 last night, and groff was still running at 7:25 this morning - > a buildworld usually takes me about 1 1/2 - 2 hrs). > please read /usr/src/UPDATING. there is a workaround for this. franz. > -Michael -- http://webonaut.com/ mailto:klammer@webonaut.com From owner-freebsd-current@FreeBSD.ORG Sun May 11 06:00:17 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 2B18737B401; Sun, 11 May 2003 06:00:17 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B023143FEC; Sun, 11 May 2003 06:00:15 -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 h4BD0DOn077938; Sun, 11 May 2003 09:00:13 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: (from robert@localhost) by fledge.watson.org (8.12.9/8.12.9/Submit) id h4BD0CrT077936; Sun, 11 May 2003 09:00:12 -0400 (EDT) (envelope-from robert) Date: Sun, 11 May 2003 09:00:12 -0400 (EDT) Message-Id: <200305111300.h4BD0CrT077936@fledge.watson.org> From: Robert Watson To: current@FreeBSD.org Subject: 5.1-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: re@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2003 13:00:17 -0000 This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail re@FreeBSD.org. Must Resolve Issues for 5.1-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-----------------+-------------+-------------+--------------------------| | | | | Kris Kennaway reports | | | | | that he has seen several | | | | | unique panics on the | | | | | alpha machines, but | | Spurious alpha | -- | -- | since gdb -k doesn't | | panics | | | work on alpha I haven't | | | | | been able to get more | | | | | than a DDB traceback. | | | | | No-one has looked into | | | | | them. | |-----------------+-------------+-------------+--------------------------| | gdb -k doesn't | -- | Mark Peek | gdb -k doesn't work on | | work on alpha | | | alpha | |-----------------+-------------+-------------+--------------------------| | | | | There are reports of | | ipfw/ipfw2 | | | alignment problems with | | alignment | In progress | Luigi Rizzo | ipfw and/or ipfw2 on | | issues on | | | 64-bit platforms | | alpha/sparc64 | | | (specifically alpha and | | | | | sparc64). | |-----------------+-------------+-------------+--------------------------| | | | | Kris Kennaway reports | | | | | high instability of | | | | | 5.0-CURRENT on ia64 | | | | | machines, such as the | | ia64 stability | -- | -- | pluto* machines. These | | | | | problems need to be | | | | | fixed in order to get a | | | | | successful package | | | | | build. | |-----------------+-------------+-------------+--------------------------| | | | | Kris Kennaway reports | | | | | that there is a gcc bug | | | | | on sparc64 that prevents | | gcc sparc64 | -- | -- | the build of | | problems | | | XFree86-4-libraries. | | | | | Alexander Kabaev is | | | | | working on a gcc 3.3 | | | | | patchset for test. | |-----------------+-------------+-------------+--------------------------| | | | | ia64 serial console | | | | | support is not currently | | ia64 sio | | Marcel | functional, and requires | | support | In progress | Moolenaar, | a reworking of the sio | | | | Warner Losh | support to improve | | | | | platform independence | | | | | and bus handling. | |-----------------+-------------+-------------+--------------------------| | | | | Brian Feldman has | | | | | submitted patches to | | | | | improve the consistency | | MAC Framework | | | of the pathnames passed | | devfs path | In progress | Robert | into the MAC Framework | | fixes | | Watson | devfs labeling entry | | | | | points. These patches | | | | | need to be thoroughly | | | | | reviewed and tested, | | | | | then merged. | |-----------------+-------------+-------------+--------------------------| | Panic on | | | If a network device | | load/unload a | | | driver, possibly any | | kernel module | | | driver, is linked into | | for a driver | Patch | Maxime | the kernel and then | | already | submitted | Henrion | loaded and unloaded as a | | statically | | | module, the kernel will | | linked into the | | | panic. This has been | | kernel. | | | observed with both if_dc | | | | | and if_fxp. | |-----------------+-------------+-------------+--------------------------| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for the | | | | | i386 platform, limiting | | | | | use of KSE to the i386 | | | | | platform. It is highly | | KSE support for | | Jake | desirable to make KSE | | sparc64, alpha, | -- | Burkholder, | available on non-i386 | | ia64 | | --, -- | platforms for | | | | | 5.1-RELEASE so that KSE | | | | | can see more broad | | | | | exposure, and the | | | | | performance benefits of | | | | | KSE can be visible to | | | | | users of the 64-bit | | | | | FreeBSD architectures. | |-----------------+-------------+-------------+--------------------------| | | | | Update the run-time link | | rtld-elf | -- | Alexander | editor (rtld) | | thread-safety | | Kabaev | thread-safe with | | | | | libpthread. | +------------------------------------------------------------------------+ Desired Features for 5.1-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |----------------+-----------+----------------+--------------------------| | | | | A.out support in the | | a.out | | | base system was reduced; | | toolchain port | -- | -- | the removed build chain | | | | | components should be | | | | | made into a port. | |----------------+-----------+----------------+--------------------------| | | | | Truss appears to contain | | | | | a race condition during | | | | | the start-up of | | | | | debugging, which can | | | | | result in truss failing | | | | | to attach to the process | | | | | before it exits. The | | | | | symptom is that truss | | | | | reports that it cannot | | | | | open the procfs node | | | | | supporting the process | | | | | being debugged. A bug | | Race | Errata | | also appears to exist | | conditions in | candidate | Robert Drehmel | where in truss will hang | | truss | | | if execve() returns | | | | | ENOENT. A further race | | | | | appears to exist in | | | | | which truss will return | | | | | "PIOCWAIT: Input/output | | | | | error" occasionally on | | | | | startup. The fix for | | | | | this sufficiently | | | | | changes process | | | | | execution handling that | | | | | we will defer the fix to | | | | | post-5.0 and consider | | | | | this errata. | |----------------+-----------+----------------+--------------------------| | | | | Kris Kennaway reports | | | | | deadlocks involving the | | | | | use of nullfs in the | | | | | bento environment: | | | | | buildworld -j4 with src | | | | | and obj mounted via | | nullfs | -- | -- | nullfs; the gcc | | deadlocks | | | processes eventually | | | | | deadlocked in the ufs | | | | | state. DDB traceback | | | | | showed two different | | | | | codepaths. I've just | | | | | repeated this, so the | | | | | bug still exists. | +------------------------------------------------------------------------+ Documentation items that must be resolved for 5.1 +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-----------------+-------------+--------------+-------------------------| | | | | We now use OPIE instead | | Documentation | | Christian | of S/Key. The handbook | | rottage: S/Key | In progress | Brueffer | doesn't cover OPIE as | | | | | well as it covers | | | | | S/Key. | |-----------------+-------------+--------------+-------------------------| | | | | The hardware notes for | | | | | ia64 needs some large | | ia64 Hardware | -- | -- | infusions of text. They | | Notes | | | probably haven't been | | | | | synched with reality | | | | | for awhile. | |-----------------+-------------+--------------+-------------------------| | | | | As BUSDMA is now the | | | | | required driver API for | | | | | DMA access in hardware | | | | | device drivers as of | | | | | 5.1-RELEASE, we need to | | busdma man page | In progress | Hiten Pandya | make sure it's properly | | | | | documented. A man page | | | | | is in progress and | | | | | needs to be | | | | | appropriately reviewed | | | | | and committed prior to | | | | | the release. | +------------------------------------------------------------------------+ Areas requiring immediate testing +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-----------------+-----------+-----------------+------------------------| | | | | The 20030228 vendor | | Fresh ACPI-CA | | | sources have been | | import | -- | -- | imported. Further | | | | | testing is | | | | | appreciated. | |-----------------+-----------+-----------------+------------------------| | | | | During the install, | | | | | the iir controller | | | | | appears to correctly | | | | | probe, but finds no | | | | | disk devices. The card | | | | | in question is an | | | | | Intel srcu32 RAID | | iir driver | | | controller with 32Mb | | fails to probe | -- | -- | RAM, Firmware revision | | disks | | | 2.33.01. Intel | | | | | developers have | | | | | released an update | | | | | driver, which has | | | | | recently been adapted | | | | | and imported into | | | | | 5-CURRENT, and must be | | | | | tested. | |-----------------+-----------+-----------------+------------------------| | | | | PAE support allows the | | | | | use of up to 64GB of | | PAE support for | | | RAM on Pentium Pro and | | i386 | -- | -- | above systems. Virtual | | | | | addresses are still | | | | | constrained to | | | | | 32-bits. | |-----------------+-----------+-----------------+------------------------| | | | | The recently upgraded | | | | | if_wi driver is more | | | | | tuned to Prism | | | | | hardware than to | | if_wi problems | | | Lucent hardware, | | on Lucent | -- | -- | resulting in system | | hardware | | | lockups and poor | | | | | performance when using | | | | | Lucent hardware. These | | | | | problems are believed | | | | | to be fixed but more | | | | | testing is welcome. | |-----------------+-----------+-----------------+------------------------| | | | | There are reports that | | | | | kernels build with | | No console | | | smbus, viapm, and smb | | (term) if smbus | -- | -- | devices may not | | is enable in | | | properly probe and | | the kernel | | | support the system | | | | | console following | | | | | boot. | |-----------------+-----------+-----------------+------------------------| | | | | For 5.1-RELEASE, the | | | | | default file system | | | | | type for newly created | | | | | file systems is UFS2 | | | | | rather than UFS1. | | UFS2 as | | | newfs(8) and | | installation, | -- | Robert Watson | sysinstall(8) have | | newfs default | | | been updated to use | | | | | this new default. | | | | | Testing to make sure | | | | | all goes well after | | | | | the change (committed | | | | | on April 20, 2003) is | | | | | vital. | |-----------------+-----------+-----------------+------------------------| | | | | Kris Kennaway reports | | | | | mutex panics in wait4 | | | | | in the bento | | | | | environment: | | wait4 | | | "Impossible" mutex | | "impossible" | -- | Tim J. Robbins | panic in wait4() | | mutex panic | | | (reported to -current | | | | | a while ago). Believed | | | | | to be related to (and | | | | | fixed along with) | | | | | uidinfo "impossible" | | | | | panic below. | |-----------------+-----------+-----------------+------------------------| | | | | Kris Kennaway reports | | | | | that there appears to | | | | | be a resource leak of | | | | | uidinfo reference | | uidinfo | | | counts that is causing | | "impossible" | -- | Tim J. Robbins | the gohan machines to | | panic | | | panic after about 18 | | | | | days of load. | | | | | Tim J. Robbins has | | | | | committed a fix that | | | | | is believed to solve | | | | | the problem. | |-----------------+-----------+-----------------+------------------------| | | | | Support for pluggable | | | | | directory services | | | | | using NSS, including | | | | | adaptations of current | | | | | directory services | | NSSwitch | | | (local databases, | | support | -- | Jacques Vidrine | NIS), and support for | | | | | new services (LDAP, | | | | | Active Directory, | | | | | etc). This change has | | | | | been committed, and | | | | | requires broader | | | | | testing. | |-----------------+-----------+-----------------+------------------------| | | | | Starting in late | | | | | April, reports of a | | | | | new UFS panic, "panic: | | | | | ffs_blkfree: freeing | | | | | free frag" began to | | | | | pop up with a high | | | | | frequency in some | | | | | environments. This | | | | | problem appears to | | | | | have been associated | | | | | with a bug introduced | | | | | in the VM system that | | | | | has now been resolved. | | panic: | Patch | Alan L. Cox | Users who updated to a | | ffs_blkfree | committed | | kernel between | | | | | approximately May 1 | | | | | and May 4 will want to | | | | | run a full foreground | | | | | fsck on all file | | | | | systems to make sure | | | | | that no remaining free | | | | | space accounting | | | | | errors exist. However, | | | | | we should be on the | | | | | lookout for any | | | | | recurrence of this | | | | | problem due to its | | | | | serious nature. | |-----------------+-----------+-----------------+------------------------| | | | | Due to TCP state | | | | | efficiency | | | | | improvements in the | | | | | TIMEWAIT state, it is | | | | | now possible for the | | | | | PCB socket pointer to | | | | | be NULL in situations | | TIMEWAIT panic | | | it previously wasn't. | | for network | Patch | | As a result, TCP | | labeled MAC | committed | Robert Watson | responses generated in | | policy modules | | | the TIMEWAIT state | | | | | lacked properly | | | | | initialized MAC | | | | | labels, resulting in | | | | | panics for network | | | | | labeled MAC policies. | | | | | A fix has been | | | | | committed, and needs | | | | | more broad testing. | +------------------------------------------------------------------------+ ---------------------------------------------------------------------- freebsd-qa@FreeBSD.ORG Copyright (c) 1995-2003 The FreeBSD Project. All rights reserved. Last modified: 2003/05/09 20:08:07 From owner-freebsd-current@FreeBSD.ORG Sun May 11 06:34:27 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 5442937B401 for ; Sun, 11 May 2003 06:34:27 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E59043F85 for ; Sun, 11 May 2003 06:34:26 -0700 (PDT) (envelope-from ticso@cicely9.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h4BDY7rN095177 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sun, 11 May 2003 15:34:22 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h4BDY1iP000766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 11 May 2003 15:34:01 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.9/8.12.9) with ESMTP id h4BDXwRw003836 for ; Sun, 11 May 2003 15:34:00 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.9/8.12.9/Submit) id h4BDXv7p003835 for current@freebsd.org; Sun, 11 May 2003 15:33:57 +0200 (CEST) (envelope-from ticso) Date: Sun, 11 May 2003 15:33:56 +0200 From: Bernd Walter To: current@freebsd.org Message-ID: <20030511133355.GA3789@cicely9.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.3i Subject: NFS troubles on recent -current. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2003 13:34:27 -0000 I have a -current (10th may) NFS server which serves for a diskless NFS client (11th May). The client has / on a CF media and /usr as well as /var/spool on the server. Also swap is on the server (/usr/swapfile) via md. When I run installworld on the client the server hangs with "lockmgr draning against myself". I got no DDB prompt so no stacktrace or crashdump :( On the client I have a different problem. Normaly the client should just wait for the server without any problem, but I get kernel messages of the following kind: swap_pager: indefinite wait buffer: device: md0, blkno: 872, size:8192 -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Sun May 11 06:43:07 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 CD3E837B401; Sun, 11 May 2003 06:43:07 -0700 (PDT) Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D9EC43FE1; Sun, 11 May 2003 06:43:03 -0700 (PDT) (envelope-from netch@iv.nn.kiev.ua) Received: (from uucp@localhost) by segfault.kiev.ua (8) with UUCP id h5BDh0NJ003312; Sun, 11 May 2003 16:43:00 +0300 (EEST) (envelope-from netch@iv.nn.kiev.ua) Received: (from netch@localhost) by iv.nn.kiev.ua (8.12.8p1/8.12.8) id h4BDfN0l000338; Sun, 11 May 2003 16:41:23 +0300 (EEST) (envelope-from netch) Date: Sun, 11 May 2003 16:41:23 +0300 From: Valentin Nechayev To: current@freebsd.org Message-ID: <20030511134123.GA307@iv.nn.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-42: On Organization: Dark side of coredump Subject: ATA: falling to PIO4 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: Sun, 11 May 2003 13:43:08 -0000 Hi, this host works with ATA correct on 4.8-RELEASE and 5.0-RELEASE, but on 5.0-CURRENT of 2003-May-03 fails to work via UDMA with HDD on first ATA channel. Dmesg shows it tries to set UDMA66, even without compliant cable (cable for ata0 is of old type), and gets a bunch of UDMA ICRC errors. Setting UDMA33 via atacontrol (`atacontrol mode 0 udma33 -') works for a few seconds, then accidentally ICRC errors happen again and driver downgrades mode to PIO4 again. With 4.8, UDMA33 works stably. Dmesgs and configs are attached. If any additional info or debug print hooks are needed, please name it. 4.8 has ==={{{ hw.ata.tags=1 hw.ata.wc=0 hw.ata.atapi_dma=1 ===}}} in loader.conf. 5.0 doesn't have it. === cut: dmesg.boot 5.0 (verbose) === Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Sat May 3 17:01:15 EEST 2003 root@iv5.nn.kiev.ua:/var/obj/var/HEAD/src/sys/nn15 Preloaded elf kernel "/boot/kernel/kernel" at 0xc043a000. Calibrating clock(s) ... i8254 clock: 1193010 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 799436830 Hz Timecounter "TSC" frequency 799436830 Hz CPU: Intel Celeron (799.44-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 268369920 (255 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000461000 - 0x000000000fb31fff, 258805760 bytes (63185 pages) avail memory = 255795200 (243 MB) bios32: Found BIOS32 Service Directory header at 0xc00fad00 bios32: Entry = 0xfb190 (c00fb190) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb1c0 pnpbios: Found PnP BIOS data at 0xc00fbbb0 pnpbios: Entry = f0000:bbe0 Rev = 1.0 Other BIOS signatures found: null: random: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 00 01 80 00 05 02 07 01 00 01 1a 01 00 01 23 01 00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 0a 01 0b 01 0c 01 0e 01 0f 01 VESA: 33 mode(s) found VESA: v3.0, 8192k memory, flags:0x1, mode table:0xc03b6e62 (1000022) VESA: NVidia VESA: NVidia Corporation Riva TNT Chip Rev B1 npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fded0 PCI-Only Interrupts: 5 9 11 Location Bus Device Pin Link IRQs slot 1 0 2 A 0x60 3 4 5 7 9 10 11 14 15 slot 1 0 2 B 0x61 3 4 5 7 9 10 11 14 15 slot 1 0 2 C 0x62 3 4 5 7 9 10 11 14 15 slot 1 0 2 D 0x63 3 4 5 7 9 10 11 14 15 slot 2 2 8 A 0x68 3 4 5 7 9 10 11 14 15 slot 2 2 8 B 0x69 3 4 5 7 9 10 11 14 15 slot 2 2 8 C 0x6a 3 4 5 7 9 10 11 14 15 slot 2 2 8 D 0x6b 3 4 5 7 9 10 11 14 15 slot 3 2 0 A 0x60 3 4 5 7 9 10 11 14 15 slot 3 2 0 B 0x61 3 4 5 7 9 10 11 14 15 slot 3 2 0 C 0x62 3 4 5 7 9 10 11 14 15 slot 3 2 0 D 0x63 3 4 5 7 9 10 11 14 15 slot 4 2 1 A 0x61 3 4 5 7 9 10 11 14 15 slot 4 2 1 B 0x62 3 4 5 7 9 10 11 14 15 slot 4 2 1 C 0x63 3 4 5 7 9 10 11 14 15 slot 4 2 1 D 0x60 3 4 5 7 9 10 11 14 15 slot 5 2 6 A 0x62 3 4 5 7 9 10 11 14 15 slot 5 2 6 B 0x63 3 4 5 7 9 10 11 14 15 slot 5 2 6 C 0x60 3 4 5 7 9 10 11 14 15 slot 5 2 6 D 0x61 3 4 5 7 9 10 11 14 15 slot 6 2 7 A 0x63 3 4 5 7 9 10 11 14 15 slot 6 2 7 B 0x60 3 4 5 7 9 10 11 14 15 slot 6 2 7 C 0x61 3 4 5 7 9 10 11 14 15 slot 6 2 7 D 0x62 3 4 5 7 9 10 11 14 15 slot 7 2 9 A 0x61 3 4 5 7 9 10 11 14 15 slot 7 2 9 B 0x62 3 4 5 7 9 10 11 14 15 slot 7 2 9 C 0x63 3 4 5 7 9 10 11 14 15 slot 7 2 9 D 0x60 3 4 5 7 9 10 11 14 15 slot 8 2 10 A 0x62 3 4 5 7 9 10 11 14 15 slot 8 2 10 B 0x63 3 4 5 7 9 10 11 14 15 slot 8 2 10 C 0x60 3 4 5 7 9 10 11 14 15 slot 8 2 10 D 0x61 3 4 5 7 9 10 11 14 15 embedded 0 31 A 0x60 3 4 5 7 9 10 11 14 15 embedded 0 31 B 0x61 3 4 5 7 9 10 11 14 15 embedded 0 31 C 0x6b 3 4 5 7 9 10 11 14 15 embedded 0 31 D 0x63 3 4 5 7 9 10 11 14 15 embedded 0 1 A 0x60 3 4 5 7 9 10 11 14 15 embedded 0 1 B 0x61 3 4 5 7 9 10 11 14 15 embedded 0 1 C 0x62 3 4 5 7 9 10 11 14 15 embedded 0 1 D 0x63 3 4 5 7 9 10 11 14 15 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e4000000, size 26, enabled found-> vendor=0x8086, dev=0x1130, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1131, revid=0x02 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x244e, revid=0x02 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2440, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x8086, dev=0x244b, revid=0x02 bus=0, slot=31, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 4, range 32, base 0000dc00, size 6, enabled found-> vendor=0x8086, dev=0x2445, revid=0x02 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 agp0: mem 0xe4000000-0xe7ffffff at device 0.0 on pci0 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xec000000-0xedffffff pcib1: prefetched decode 0xea000000-0xebffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base ec000000, size 24, enabled map[14]: type 3, range 32, base ea000000, size 25, enabled found-> vendor=0x10de, dev=0x002c, revid=0x15 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xfff00000-0xfffff pcib2: prefetched decode 0xfff00000-0xfffff pci2: on pcib2 pci2: physical bus=2 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 31.1 on pci0 ata0: pre reset mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI 00 00 ata0-slave: ATAPI 14 eb ata0: after reset mask=03 stat0=50 stat1=00 ata0-master: ATA 01 a5 ata0: devices=09 ata0: at 0x1f0 irq 14 on atapci0 ata1: pre reset mask=03 ostat0=50 ostat2=00 ata1-master: ATAPI 00 00 ata1-slave: ATAPI 00 00 ata1: after reset mask=03 stat0=50 stat1=00 ata1-master: ATA 01 a5 ata1: devices=01 ata1: at 0x170 irq 15 on atapci0 pcm0: port 0xdc00-0xdc3f,0xd800-0xd8ff irq 5 at device 31.5 on pci0 pcm0: pcm0: Codec features 5 bit master volume, Realtek 3D Stereo Enhancement pcm0: Primary codec extended features AMAP pcm0: sndbuf_setmap 595000, 4000; 0xd1d8a000 -> 595000 pcm0: sndbuf_setmap 5b9000, 4000; 0xd1d8e000 -> 5b9000 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 pnpbios: 17 devices, largest 156 bytes PNP0000: adding irq mask 0x4 PNP0000: adding io range 0x20-0x21, size=0x2, align=0 PNP0000: adding io range 0xa0-0xa1, size=0x2, align=0 pnpbios: handle 0 device ID PNP0000 (0000d041) PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x81-0x83, size=0x3, align=0 PNP0200: adding io range 0x87-0x87, size=0x1, align=0 PNP0200: adding io range 0x89-0x8b, size=0x3, align=0 PNP0200: adding io range 0x8f-0x91, size=0x3, align=0 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 pnpbios: handle 1 device ID PNP0200 (0002d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 pnpbios: handle 4 device ID PNP0303 (0303d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0 pnpbios: handle 5 device ID PNP0800 (0008d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 pnpbios: handle 6 device ID PNP0c04 (040cd041) INT0800: adding fixed memory32 range 0xffb80000-0xffbfffff, size=0x80000 pnpbios: handle 7 device ID INT0800 (0008d425) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0xffb00000-0xffb7ffff, size=0x80000 PNP0c01: adding fixed memory32 range 0xfff00000-0xffffffff, size=0x100000 PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0x100000-0xfffffff, size=0xff00000 pnpbios: handle 8 device ID PNP0c01 (010cd041) PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf8000-0xfbfff, size=0x4000 PNP0c02: adding fixed memory32 range 0xfc000-0xfffff, size=0x4000 pnpbios: handle 9 device ID PNP0c02 (020cd041) PNP0a03: adding io range 0x294-0x297, size=0x4, align=0 PNP0a03: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 PNP0a03: adding io range 0x480-0x48f, size=0x10, align=0 PNP0a03: adding io range 0x4000-0x40f7, size=0xf8, align=0 pnpbios: handle 10 device ID PNP0a03 (030ad041) PNP0f13: adding irq mask 0x1000 pnpbios: handle 11 device ID PNP0f13 (130fd041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 pnpbios: handle 12 device ID PNP0501 (0105d041) PNP0400: adding irq mask 0x80 PNP0400: adding io range 0x378-0x37f, size=0x8, align=0 PNP0400: adding io range 0x778-0x77b, size=0x4, align=0 PNP0400: adding io range 0xb78-0xb7b, size=0x4, align=0 PNP0400: adding io range 0xf78-0xf7b, size=0x4, align=0 pnpbios: handle 14 device ID PNP0400 (0004d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0 pnpbios: handle 16 device ID PNP0501 (0105d041) PNPb006: adding irq mask 0x400 PNPb006: adding io range 0x330-0x331, size=0x2, align=0 pnpbios: handle 17 device ID PNPb006 (06b0d041) PNPb02f: adding io range 0x201-0x207, size=0x7, align=0 PNPb02f: adding io range 0x200-0x200, size=0x1, align=0 pnpbios: handle 18 device ID PNPb02f (2fb0d041) sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: