From owner-freebsd-current Sun Jan 21 0:25:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id D785237B401; Sun, 21 Jan 2001 00:25:32 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0L8PTl07759; Sun, 21 Jan 2001 09:25:29 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: John Baldwin Cc: Mark Murray , current@FreeBSD.org, The Hermit Hacker Subject: Re: current hangs... In-Reply-To: Your message of "Sat, 20 Jan 2001 16:03:08 PST." Date: Sun, 21 Jan 2001 09:25:29 +0100 Message-ID: <7757.980065529@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , John Baldwin writes: > >On 20-Jan-01 Poul-Henning Kamp wrote: >> In message , John Baldwin writes: >>> >>>On 20-Jan-01 The Hermit Hacker wrote: >>>> On Sat, 20 Jan 2001, Mark Murray wrote: >>>> >>>>> > >>>>> > on a 2xPII/350, 256M, two scsi disks on ahc, and ccd I have three times >>>>> > now hung the machine so that only reset got any attention simply by >>>>> > make -j 128 world >>>>> >>>>> Do you have an easy way to narrow it down to CCD by doing the same >>>>> thing but without ccd involvement? >>>> >>>> I don't have CCD, and got home last night from the office and mine was >>>> hung also, on a kernel from the day before ... being in X, pretty much >>>> nothing I could do to try and debug it ... new laptop gets in this week, >>>> so will be setting up the whole serial console debugging env ... >>> >>>Is it SMP, and does it have multiple SCSI disks hanging off of the same >>>device? >> >> SMP, one scsi disk on each controller, /usr and /home ccd'ed. > >Is there any code dealing with disk I/O in the kernel that does the equivalent >of this: > >while (!io_done) > /* spin */ ; > >That assumes an interrupt will set io_done? > >Using DELAY() in places might explain this. Not that I know of. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 1:15:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from herbelot.dyndns.org (s014.dhcp212-24.cybercable.fr [212.198.24.14]) by hub.freebsd.org (Postfix) with ESMTP id 6C95B37B400 for ; Sun, 21 Jan 2001 01:15:24 -0800 (PST) Received: from free.fr (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id KAA67165 for ; Sun, 21 Jan 2001 10:15:22 +0100 (CET) (envelope-from thierry.herbelot@free.fr) Message-ID: <3A6AA8AA.AE4385C2@free.fr> Date: Sun, 21 Jan 2001 10:15:22 +0100 From: Thierry Herbelot X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: VN bug or pilot error ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I've got a recent current (cvsuped and rebuilt yesterday) on a laptop and I can't use the vn(4) pseudo-driver : I've compiled it in the kernel and I've also tried to kldload vn.ko, but I get consistently "vn0c : device not configured" when I try to use it to mount a locally stored iso image. I've switched to Stable and I can mount the exact same image. TfH PS : it seems it's possible to vn-mount a file located on an NFS server, when the man page says it is not possible (which is right ?) -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 2:29:22 2001 Delivered-To: freebsd-current@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 2E0C137B400 for ; Sun, 21 Jan 2001 02:29:05 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0LAW9M63747; Sun, 21 Jan 2001 02:32:09 -0800 (PST) (envelope-from kris) Date: Sun, 21 Jan 2001 02:32:08 -0800 From: Kris Kennaway To: David Syphers Cc: current@FreeBSD.ORG Subject: Re: XFree86 4.0.2 Message-ID: <20010121023208.A63679@citusc17.usc.edu> References: <4.3.2.7.2.20010121013438.00ba9100@nsit-popmail.uchicago.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010121013438.00ba9100@nsit-popmail.uchicago.edu>; from dbsypher@uchicago.edu on Sun, Jan 21, 2001 at 01:51:05AM -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 21, 2001 at 01:51:05AM -0600, David Syphers wrote: > the binaries from a directory labeled "FreeBSD 5.x". So I tried the port= s,=20 > and it built fine for a long time, and then after about 35300 lines of=20 > output to the screen, ran into >=20 > make: don't know how to make ../../../fonts/encodings/encodings.dir. Stop > *** Error code 2 >=20 > Stop in /usr/ports/x11/XFree86-4/work/xc/fonts/bdf. The port should be working, but since it's not for you, just add the packag= e. pkg_add -r XFree86 Kris -- NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6arqoWry0BWjoQKURAsV8AJ0ceY27pgbwXMyjcztjc3auRVBfyQCgw1y8 B80tM6pNaRBAQL1mb93RCcY= =hagB -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 2:33: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 2654337B400 for ; Sun, 21 Jan 2001 02:32:46 -0800 (PST) Received: (qmail 50424 invoked by uid 1142); 21 Jan 2001 10:32:45 -0000 Date: 21 Jan 2001 02:32:45 -0800 Date: Sun, 21 Jan 2001 02:32:38 -0800 From: Jason Evans To: current@freebsd.org Subject: HEADS UP: Strange booting lockups Message-ID: <20010121023238.S69199@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Several of us have started experiencing problems with kernels that won't boot. The symptom is hard to miss: the machine locks up at the spinner just before printing the copyright message at the beginning of the boot sequence. We don't know why this is happening, and at this point the primary suspicion is that this problem has been lurking for quite some time, and we've recently committed a combination of changes that causes the problem to exhibit itself more consistently. Jake Burkholder, Peter Wemm, and I all checked in changes that were independently tested and confirmed to work, yet the combination of the changes seems to be bad, even though none of them appear to touch code that is executed so early during boot. There is a report (that just came to my attention) of this problem existing for one person at least two weeks ago, so it isn't clear yet what conditions cause the problem to manifest itself. A number of us are searching for the problem, but it may take some time. Meanwhile, it may be a good idea to hold off committing changes to core parts of the kernel until we are able to analyze this problem. Naturally, if someone knows what is wrong, we would love to hear about it. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 2:55:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 3769737B400 for ; Sun, 21 Jan 2001 02:55:38 -0800 (PST) Received: from zippy.pacbell.net ([207.214.149.54]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G7I00M7SE8GG4@mta5.snfc21.pbi.net> for current@freebsd.org; Sun, 21 Jan 2001 02:53:05 -0800 (PST) Received: by zippy.pacbell.net (Postfix, from userid 1000) id 423B617FD; Sun, 21 Jan 2001 02:54:57 -0800 (PST) Date: Sun, 21 Jan 2001 02:54:57 -0800 From: Alex Zepeda Subject: Re: HEADS UP: Strange booting lockups In-reply-to: <20010121023238.S69199@canonware.com>; from jasone@canonware.com on Sun, Jan 21, 2001 at 02:32:38AM -0800 To: current@freebsd.org Message-id: <20010121025457.A396@zippy.pacbell.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <20010121023238.S69199@canonware.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 02:32:38AM -0800, Jason Evans wrote: > Several of us have started experiencing problems with kernels that won't > boot. The symptom is hard to miss: the machine locks up at the spinner > just before printing the copyright message at the beginning of the boot > sequence. Hmm. I've recently tried to boot a kernel off of a CDRW, and it got through the loader, printed the copyright and blinked the keyboard leds, and froze. The lsdev command causes the loader to panic when booted from the CD. Could this possibly be related? - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 2:58: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from webcom.it (unknown [212.34.222.47]) by hub.freebsd.org (Postfix) with SMTP id C8A1B37B401 for ; Sun, 21 Jan 2001 02:57:47 -0800 (PST) Received: (qmail 2298 invoked by uid 1000); 21 Jan 2001 10:51:22 -0000 Date: Sun, 21 Jan 2001 11:51:22 +0100 From: Andrea Campi To: Dag-Erling Smorgrav Cc: cjclark@alum.mit.edu, FreeBSD-gnats-submit@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: bin/24444: syslogd(8) does not update hostname Message-ID: <20010121115121.A402@webcom.it> References: <200101190330.f0J3UPa75677@rfx-216-196-73-168.users.reflexcom.com> <20010119110341.A7958@rfx-216-196-73-168.users.reflex> <20010120170155.K10761@rfx-216-196-73-168.users.reflex> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Sun, Jan 21, 2001 at 04:32:33AM +0100 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > the hostname, one being a syscall and the other being a sysctl. One > could of course have the kernel print a message to the console about > it, syslogd(8) would pick that up. Yes, I was about to propose this, but then I thought: why? If we go this way, then we should definitely also log an IP address change, maybe even our default router change MAC address... why not even hardware changes since last reboot? Working in a security job, I can understand worries about important events going unnoticed. But doing this in kernel is IMHO overkill, maybe it could be interesting for TrustetBSD, but not in the normal kernel; at least, it should be configurable at both compile time and runtime (high securelevel and/or a sysctl). The Right Way (tm) to do this is to use (or write) an host intrusion detection system. Having said this, the proposed patch looks fine to me and I think it should be committed. Bye, Andrea -- Speak softly and carry a cellular phone. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 3: 4:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail8.sc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by hub.freebsd.org (Postfix) with ESMTP id 10BD937B401 for ; Sun, 21 Jan 2001 03:04:35 -0800 (PST) Received: from sc.rr.com ([24.88.102.101]) by mail8.sc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Sun, 21 Jan 2001 06:02:31 -0500 Received: (from dmaddox@localhost) by sc.rr.com (8.11.1/8.11.1) id f0LB5KS00450; Sun, 21 Jan 2001 06:05:20 -0500 (EST) (envelope-from dmaddox) Date: Sun, 21 Jan 2001 06:05:20 -0500 From: "Donald J . Maddox" To: Alex Zepeda Cc: current@FreeBSD.ORG Subject: Re: HEADS UP: Strange booting lockups Message-ID: <20010121060520.A396@cae88-102-101.sc.rr.com> Reply-To: dmaddox@sc.rr.com Mail-Followup-To: Alex Zepeda , current@FreeBSD.ORG References: <20010121023238.S69199@canonware.com> <20010121025457.A396@zippy.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010121025457.A396@zippy.pacbell.net>; from jazepeda@pacbell.net on Sun, Jan 21, 2001 at 02:54:57AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 02:54:57AM -0800, Alex Zepeda wrote: > On Sun, Jan 21, 2001 at 02:32:38AM -0800, Jason Evans wrote: > > > Several of us have started experiencing problems with kernels that won't > > boot. The symptom is hard to miss: the machine locks up at the spinner > > just before printing the copyright message at the beginning of the boot > > sequence. > > Hmm. I've recently tried to boot a kernel off of a CDRW, and it got > through the loader, printed the copyright and blinked the keyboard leds, > and froze. > > The lsdev command causes the loader to panic when booted from the CD. > > Could this possibly be related? It may have absolutely nothing to do with either of these cases, but I found out the hard way recently that booting with no device.hints in /boot will exhibit symptoms that appear identical to this. Is it possible that something is trashing the device list, or not initializing it properly at kernel load time? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 3:14:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 23F1537B400 for ; Sun, 21 Jan 2001 03:13:56 -0800 (PST) Received: (qmail 51076 invoked by uid 1142); 21 Jan 2001 11:13:51 -0000 From: jasone@magnesium.net Date: 21 Jan 2001 03:13:51 -0800 Date: Sun, 21 Jan 2001 03:13:37 -0800 To: current@freebsd.org Subject: Fixed (was Re: HEADS UP: Strange booting lockups) Message-ID: <20010121031337.T69199@canonware.com> References: <20010121023238.S69199@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010121023238.S69199@canonware.com>; from jasone@canonware.com on Sun, Jan 21, 2001 at 02:32:38AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 02:32:38AM -0800, Jason Evans wrote: > We don't know why this is happening, and at this point the primary > suspicion is that this problem has been lurking for quite some time, and > we've recently committed a combination of changes that causes the problem > to exhibit itself more consistently. Jake Burkholder, Peter Wemm, and I > all checked in changes that were independently tested and confirmed to > work, yet the combination of the changes seems to be bad, even though none > of them appear to touch code that is executed so early during boot. It was my fault. I tested my changes, and during review, one of the review comments was a request to change the order of fields in struct mtx. I didn't change the order in a static initializer though. Yay for last minute changes without repeated testing. Thanks go to Jake for finding the problem. In my tired and frantic state, I was about to resort to backing the whole thing out. =) > There is a report (that just came to my attention) of this problem existing > for one person at least two weeks ago, so it isn't clear yet what > conditions cause the problem to manifest itself. I'm not sure what caused the problem as mentioned in the above paragraph, but Donald Maddox may have the explanation for it in another email in this thread. Wearing the pointy hat, Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 3:16: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by hub.freebsd.org (Postfix) with ESMTP id F265037B400 for ; Sun, 21 Jan 2001 03:15:49 -0800 (PST) Received: from fwd00.sul.t-online.com by mailout01.sul.t-online.com with smtp id 14KITE-0004fJ-05; Sun, 21 Jan 2001 12:15:40 +0100 Received: from neutron.cichlids.com (520050424122-0001@[62.158.39.52]) by fmrl00.sul.t-online.com with esmtp id 14KIT0-0KstIuC; Sun, 21 Jan 2001 12:15:26 +0100 Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by neutron.cichlids.com (Postfix) with ESMTP id C77E1AB0C; Sun, 21 Jan 2001 12:17:20 +0100 (CET) Received: by cichlids.cichlids.com (Postfix, from userid 1001) id 0588014A46; Sun, 21 Jan 2001 12:15:06 +0100 (CET) Date: Sun, 21 Jan 2001 12:15:06 +0100 To: Jason Evans Cc: current@freebsd.org Subject: Re: HEADS UP: Strange booting lockups Message-ID: <20010121121506.B8734@cichlids.cichlids.com> Mail-Followup-To: alex@cichlids.cichlids.com, Jason Evans , current@freebsd.org References: <20010121023238.S69199@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010121023238.S69199@canonware.com>; from jasone@canonware.com on Sun, Jan 21, 2001 at 02:32:38AM -0800 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-PGP-at: finger alex@big.endian.de X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. From: alex@big.endian.de (Alexander Langer) X-Sender: 520050424122-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thus spake Jason Evans (jasone@canonware.com): > Several of us have started experiencing problems with kernels that won't > boot. The symptom is hard to miss: the machine locks up at the spinner > just before printing the copyright message at the beginning of the boot > sequence. Yes, I have this too... > We don't know why this is happening, and at this point the primary ... if this helps: This doens't happen on a PIII nor on a K6-2. It just happens on my 486 (using the same kernel, I mean) Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 3:59:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from server.bitmcnit.bryansk.su (bitmcnit.bryansk.ru [195.239.213.9]) by hub.freebsd.org (Postfix) with ESMTP id E5A0E37B400; Sun, 21 Jan 2001 03:59:26 -0800 (PST) Received: (from uucp@localhost) by server.bitmcnit.bryansk.su (8.9.3/8.9.3) with UUCP id OAA19628; Sun, 21 Jan 2001 14:48:12 +0300 Received: (from alex@localhost) by kapran.bitmcnit.bryansk.su (8.11.1/8.11.1) id f0LBon801376; Sun, 21 Jan 2001 14:50:49 +0300 (MSK) (envelope-from alex@kapran.bitmcnit.bryansk.su) Date: Sun, 21 Jan 2001 14:50:48 +0300 From: Alex Kapranoff To: current@freebsd.org Cc: questions@freebsd.org Subject: cc1 gets segmentation faults Message-ID: <20010121145048.A644@kapran.bitmcnit.bryansk.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have -CURRENT on a UP P166 box. I've just managed to build a new kernel and world (cvsuped yesterday) and installed them both. Now I get: cc: Internal compiler error: program cc1 got fatal signal 11 *** Error code 1 Stop in /usr/home/alex/work/own. whenever I want to compile something not so trivial as `hello world'. So, am I stuck in this situation? I cannot build neither kernel nor gcc now. Are there any ways out? Unfortunately, I don't backup system binaries, libs or headers. How can I debug this? BTW, other big programs such as INN, apache + mod_php4 work like a charm. -- Alex Kapranoff, Voice: +7(0832)791845 We've lived 494 hours in the brand new millenium... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 4:13:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.org.ru (sweet.etrust.ru [194.84.67.5]) by hub.freebsd.org (Postfix) with ESMTP id 0A4C737B401 for ; Sun, 21 Jan 2001 04:13:31 -0800 (PST) Received: by freebsd.org.ru (Postfix, from userid 1000) id C503B135; Sun, 21 Jan 2001 15:13:29 +0300 (MSK) Date: Sun, 21 Jan 2001 15:13:29 +0300 From: "Sergey A. Osokin" To: freebsd-current@freebsd.org Subject: make buildworld failed... Message-ID: <20010121151329.D73590@freebsd.org.ru> Reply-To: osa@FreeBSD.org.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! After cvsuped, i try to build world under FreeBSD 5.0-CURRENT #0: Sat Jan 13 22:57:43 MSK 2001 ===> usr.bin/kdump cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/u sr/include -c /usr/src/usr.bin/kdump/kdump.c cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/u sr/include -c ioctl.c In file included from ioctl.c:99: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:81: warning: this is the location of the previous definition In file included from ioctl.c:51: /usr/obj/usr/src/i386/usr/include/machine/i4b_rbch_ioctl.h:45: `TELNO_MAX' undeclared here (not in a function) ioctl.c: In function `ioctlname': ioctl.c:693: invalid use of `restrict' ioctl.c:693: sizeof applied to an incomplete type *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Rgdz, /"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN osa@freebsd.org.ru X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 4:21:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A606C37B401; Sun, 21 Jan 2001 04:20:52 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA65173; Sun, 21 Jan 2001 13:20:46 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: current@freebsd.org Cc: jasone@freebsd.org Subject: -CURRENT won't dump core on SMP box From: Dag-Erling Smorgrav Date: 21 Jan 2001 13:20:46 +0100 Message-ID: Lines: 64 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --=-=-= My -CURRENT SMP box (Digital Prioris 5166HX running friday's -CURRENT unmodified) refuses to dump core. If I type 'panic' at the DDB prompt after a trap (I've had different types - mainly page faults in vinum and lock order violation in the SIGINFO handler in tty.c), it goes into recursive panic (i.e. something downstream from panic() calls panic()), runs out of stack, and double-faults: > [...] > Mounting root from ufs:/dev/da0a > SMP: AP CPU #1 Launched! > Enter full pathname of shell or RETURN for /bin/sh: > # lopanic: mutex_enter(sio:1, MTX_SPIN) out of order @ ../../isa/sio.c:2585 already holding sched lock:2 > cpuid = 1; lapic.id = 01000000 > Debugger("panic") > d > CPU1 stopping CPUs: 0x00000001... stopped. > Stopped at Debugger+0x45: pushl %ebx > db> panic > > Fatal double fault: > eip = 0xc015cc8c > esp = 0xd4356000 > ebp = 0xd4356024 > cpuid = 1; lapic.id = 01000000 If, on the other hand, I just break manually into the debugger (by sending a break over the serial console), I get a "trap 12 with interrupts disabled" and an instant reboot, with not even the usual 15 seconds: > [...] > Mounting root from ufs:/dev/da0a > SMP: AP CPU #1 Launched! > Enter full pathname of shell or RETURN for /bin/sh: > # > # set -E > # grep dump /etc/rc.conf > dumpdev='/dev/da3b' > # dumpon /dev/da3b > # ~# > CPU1 stopping CPUs: 0x00000001... stopped. > Stopped at siointr1+0xb1: jmp siointr1+0x1b7 > db> panic > panic: from debugger > cpuid = 1; lapic.id = 01000000 > Debugger("panic") > Stopped at siointr1+0xb1: jmp siointr1+0x1b7 > db> > kernel trap 12 with interrupts disabled I've attached the kernel config and hints and a log of a verbose boot. --=-=-= Content-Disposition: attachment; filename=RSA Content-Description: Kernel config # Kernel configuration for rsa.thinksec.com machine i386 cpu I586_CPU cpu I686_CPU ident RSA maxusers 32 hints "RSA.hints" makeoptions DEBUG=-g options DDB, BREAK_TO_DEBUGGER options INVARIANT_SUPPORT, INVARIANTS, MUTEX_DEBUG, WITNESS options SMP options APIC_IO #options AUTO_EOI1 #options AUTO_EOI2 options COMPAT_43 options FFS options FFS_ROOT options INCLUDE_CONFIG_FILE options INET options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options KTRACE options NMBCLUSTERS=8192 options SOFTUPDATES #options UCONSOLE options USERCONFIG options VISUAL_USERCONFIG options MSGBUF_SIZE=262144 config kernel device npx device eisa device isa device pci # Floppy controller device fdc # SCSI controller device bt device scbus device da device sa device cd device pass # Console device atkbdc device atkbd device psm device vga device sc device splash options SC_DFLT_FONT makeoptions SC_DFLT_FONT=iso options SC_HISTORY_SIZE=1024 # PCI Ethernet NICs. device de # Serial I/O device sio # Parallel I/O device ppc device ppbus device lpt device plip device ppi # Pseudo-devices device bpf device ether device loop device pty device random --=-=-= --=-=-= Content-Disposition: attachment; filename=RSA.hints Content-Description: Kernel hints hint.fdc.0.at="isa" hint.fdc.0.port="0x3F0" hint.fdc.0.irq="6" hint.fdc.0.drq="2" hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.fd.1.at="fdc0" hint.fd.1.drive="1" hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.atkbd.0.flags="0x1" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.npx.0.at="nexus" hint.npx.0.port="0x0F0" hint.npx.0.irq="13" hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint.sio.0.flags="0x10" hint.sio.0.irq="4" hint.sio.1.at="isa" hint.sio.1.port="0x2F8" hint.sio.1.irq="3" hint.ppc.0.at="isa" hint.ppc.0.irq="7" --=-=-= --=-=-= Content-Disposition: attachment; filename=RSA.log Content-Description: Boot log Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS drive E: is disk3 BIOS drive F: is disk4 BIOS 639kB/15360kB available memory FreeBSD/i386 bootstrap loader, Revision 1.0 (des@rsa.thinksec.com, Thu Jan 18 07:09:38 CET 2001) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x150285 data=0x21b54+0x2c124 syms=[0x4+0x22210+0x4+0x27de7] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 9 seconds... Type '?' for a list of commands, 'help' for more detailed help. ok boot -v stray irq 7 SMAP type=01 base=00000000 00000000 len=00000000 0009fc00 SMAP type=02 base=00000000 0009fc00 len=00000000 00000400 SMAP type=02 base=00000000 000ed130 len=00000000 000017a0 SMAP type=02 base=00000000 000f855c len=00000000 00007aa4 SMAP type=01 base=00000000 00100000 len=00000000 00f00000 SMAP type=01 base=00000000 00100000 len=00000000 00f00000 Overlapping or non-montonic memory region, ignoring second region SMAP type=01 base=00000000 01000000 len=00000000 1f000000 SMAP type=02 base=00000000 fec00000 len=00000000 00100000 SMAP type=02 base=00000000 fee00000 len=00000000 00100000 SMAP type=02 base=00000000 ffff855c len=00000000 00007aa4 Copyright (c) 1992-2001 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 #2: Sat Jan 20 18:14:02 CET 2001 des@des.thinksec.com:/usr/src/sys/compile/RSA Calibrating clock(s) ... TSC clock: 166666120 Hz, i8254 clock: 1193173 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium/P54C (166.67-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x3bf real memory = 536870912 (524288K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00313000 - 0x1ffbffff, 533385216 bytes (130221 pages) kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 avail memory = 519475200 (507300K bytes) Programming 16 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 SMP: CPU0 apic_initialize(): lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 bios32: Found BIOS32 Service Directory header at 0xc00fff70 bios32: Entry = 0xfda98 (c00fda98) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd120+0x9dc Other BIOS signatures found: Preloaded elf kernel "kernel" at 0xc02ea000. Intel Pentium detected, installing workaround for F00F bug null: mem: random: SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000010 SVR: 0x000001ff npx0: on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 290444379 bytes/sec bzero() bandwidth = 146049364 bytes/sec pcib0: at pcibus 0 on motherboard pci0: physical bus=0 found-> vendor=0x8086, dev=0x04a3, revid=0x11 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 found-> vendor=0x1011, dev=0x0001, revid=0x02 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 found-> vendor=0x8086, dev=0x0482, revid=0x03 bus=0, slot=2, func=0 class=00-00-00, hdrtype=0x00, mfdev=0 map[10]: type 4, range 32, base 00008080, size 2, enabled found-> vendor=0x104b, dev=0x1040, revid=0x00 bus=0, slot=6, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=10 map[10]: type 4, range 32, base 00008084, size 2, enabled found-> vendor=0x104b, dev=0x1040, revid=0x00 bus=0, slot=7, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=12 map[10]: type 4, range 32, base 00008000, size 7, enabled map[14]: type 1, range 32, base c0000000, size 7, enabled found-> vendor=0x1011, dev=0x0009, revid=0x12 bus=0, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 pci0: on pcib0 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xf00000-0xfffff pcib1: prefetched decode 0xf00000-0xfffff pci1: physical bus=1 pci1: on pcib1 eisab0: at device 2.0 on pci0 isa0: on eisab0 bt0: port 0x8080-0x8083 irq 10 at device 6.0 on pci0 bt0: BT-946C FW Rev. 4.28D Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs bt0: Using Strict Round Robin Mailbox Mode bt1: port 0x8084-0x8087 irq 12 at device 7.0 on pci0 bt1: BT-946C FW Rev. 4.28D Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs bt1: Using Strict Round Robin Mailbox Mode de0: port 0x8000-0x807f mem 0xc0000000-0xc000007f irq 11 at device 8.0 on pci0 de0: DEC DE500-XA 21140 [10-100Mb/s] pass 1.2 de0: address 00:00:f8:1e:8b:58 bpf: de0 attached 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 sc-: sc0 already exists, using sc1 instead vga-: vga0 already exists, using vga1 instead isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 05 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x41 0x51 0x41 0x41 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1: irq maps: 0x41 0x49 0x41 0x41 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc_detect_fifo: PWord not supported ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode plip0: on ppbus0 bpf: lp0 attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc1: no video adapter is found. sc1: failed to probe on isa0 vga1: failed to probe on isa0 isa_probe_children: probing PnP devices SMP: enabled INTs: 3, 4, 6, 7, 10, 11, 12, apic_imen: 0xffffe327 BIOS Geometries: 0:03ea7f20 0..1002=1003 cylinders, 0..127=128 heads, 1..32=32 sectors 1:0208fe3f 0..520=521 cylinders, 0..254=255 heads, 1..63=63 sectors 2:0208fe3f 0..520=521 cylinders, 0..254=255 heads, 1..63=63 sectors 3:03ea7f20 0..1002=1003 cylinders, 0..127=128 heads, 1..32=32 sectors 0 accounted for Device configuration finished. APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 bpf: lo0 attached Waiting 2 seconds for SCSI devices to settle bt0: Using Strict Round Robin Mailbox Mode bt1: Using Strict Round Robin Mailbox Mode bt: ccb 0xd4365380 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd4365300 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd4365280 - error 4 occured. btstat = 11, sdstat = 0 bt: ccb 0xd4365340 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd43652c0 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd4365200 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd4365300 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd43652c0 - error 4 occured. btstat = 0, sdstat = 2 (probe6:bt0:0:6:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe6:bt0:0:6:0): ILLEGAL REQUEST asc:24,0 (probe6:bt0:0:6:0): Invalid field in CDB sks:c8,1 bt: ccb 0xd4365200 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd4365240 - error 4 occured. btstat = 0, sdstat = 2 (probe5:bt0:0:5:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe5:bt0:0:5:0): ILLEGAL REQUEST asc:24,0 (probe5:bt0:0:5:0): Invalid field in CDB sks:c8,1 bt: ccb 0xd4365200 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd4369280 - error 4 occured. btstat = 11, sdstat = 0 bt: ccb 0xd4369240 - error 4 occured. btstat = 11, sdstat = 0 bt: ccb 0xd4369200 - error 4 occured. btstat = 11, sdstat = 0 bt: ccb 0xd43692c0 - error 4 occured. btstat = 11, sdstat = 0 bt: ccb 0xd4369380 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd4369300 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xd4369300 - error 4 occured. btstat = 0, sdstat = 2 de0: enabling 10baseT port Creating DISK cd0 Creating DISK da0 Creating DISK da1 Creating DISK da2 Creating DISK da3 Creating DISK da4 Creating DISK da5 Creating DISK da6 pass0 at bt0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number 04819568 bt: ccb 0xd4365240 - error 4 occured. btstat = 0, sdstat = 2 pass0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass1 at bt0 bus 0 target 1 lun 0 pass1: Fixed Direct Access SCSI-2 device pass1: Serial Number 02794200 pass1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass2 at bt0 bus 0 target 2 lun 0 pass2: Fixed Direct Access SCSI-2 device pass2: Serial Number 02751300 pass2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass3 at bt0 bus 0 target 3 lun 0 pass3: Fixed Direct Access SCSI-2 device pass3: Serial Number 04888161 pass3: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass4 at bt0 bus 0 target 5 lun 0 pass4: Removable CD-ROM SCSI-2 device pass4: 4.032MB/s transfers (4.032MHz, offset 15) pass5 at bt0 bus 0 target 6 lun 0 pass5: Removable Sequential Access SCSI-2 device pass5: 5.000MB/s transfers (5.000MHz, offset 8) pass6 at bt1 bus 0 target 0 lun 0 pass6: Fixed Direct Access SCSI-2 device pass6: Serial Number 02876358 pass6: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass7 at bt1 bus 0 target 1 lun 0 pass7: Fixed Direct Access SCSI-2 device pass7: Serial Number 02885332 pass7: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass8 at bt1 bus 0 target 2 lun 0 pass8: Fixed Direct Access SCSI-2 device pass8: Serial Number 04887964 pass8: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled sa0 at bt0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 8) da0 at bt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number 04819568 da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 2007MB (4110480 512 byte sectors: 128H 32S/T 1003C) da1 at bt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number 02794200 da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da2 at bt0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: Serial Number 02751300 da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da3 at bt0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: Serial Number 04888161 da3: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da3: 2007MB (4110480 512 byte sectors: 128H 32S/T 1003C) da4 at bt1 bus 0 target 0 lun 0 da4: Fixed Direct Access SCSI-2 device da4: Serial Number 02876358 da4: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da4: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da5 at bt1 bus 0 target 1 lun 0 da5: Fixed Direct Access SCSI-2 device da5: Serial Number 02885332 da5: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da5: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C) da6 at bt1 bus 0 target 2 lun 0 da6: Fixed Direct Access SCSI-2 device da6: Serial Number 04887964 da6: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da6: 2007MB (4110480 512 byte sectors: 128H 32S/T 1003C) Mounting root from ufs:/dev/da0a cd0 at bt0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.032MB/s transfers (4.032MHz, offset 15) cd0: cd present [329507 x 2048 byte records] da0s1: type 0xa5, start 0, end = 4110479, size 4110480 da0s1: C/H/S end 255/220/45 (2545919) != end 4110479: invalid SMP: AP CPU #1 Launched! SMP: CPU1 apic_initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff start_init: trying /sbin/init --=-=-= DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 6:30:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id B24E737B698 for ; Sun, 21 Jan 2001 06:30:00 -0800 (PST) Received: (qmail 54016 invoked by uid 1142); 21 Jan 2001 14:30:00 -0000 Date: 21 Jan 2001 06:30:00 -0800 Date: Sun, 21 Jan 2001 06:29:53 -0800 From: Jason Evans To: current@freebsd.org Subject: WITNESS may cause failed boot, patch available Message-ID: <20010121062953.V69199@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm noticed that WITNESS currently causes a kernel trap the alpha. The bug also exists on x86, but does not necessarily cause any problems. If you run into problems (probably during boot), there is a patch available that should fix the WITNESS problem: http://people.freebsd.org/~jasone/diffs/mutex_f_3.diff Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 7: 9:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from server.bitmcnit.bryansk.su (bitmcnit.bryansk.ru [195.239.213.9]) by hub.freebsd.org (Postfix) with ESMTP id 7BC8937B6A1; Sun, 21 Jan 2001 07:09:24 -0800 (PST) Received: (from uucp@localhost) by server.bitmcnit.bryansk.su (8.9.3/8.9.3) with UUCP id RAA21284; Sun, 21 Jan 2001 17:58:12 +0300 Received: (from alex@localhost) by kapran.bitmcnit.bryansk.su (8.11.1/8.11.1) id f0LCk4I19641; Sun, 21 Jan 2001 15:46:05 +0300 (MSK) (envelope-from alex@kapran.bitmcnit.bryansk.su) Date: Sun, 21 Jan 2001 15:46:02 +0300 From: Alex Kapranoff To: current@FreeBSD.ORG Cc: questions@FreeBSD.ORG Subject: Re: cc1 gets segmentation faults Message-ID: <20010121154602.A17804@kapran.bitmcnit.bryansk.su> References: <20010121145048.A644@kapran.bitmcnit.bryansk.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010121145048.A644@kapran.bitmcnit.bryansk.su>; from alex@kapran.bitmcnit.bryansk.su on Sun, Jan 21, 2001 at 02:50:48PM +0300 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Huh, I removed '-O' switch from ${CFLAGS} and managed to rebuild and reinstall gcc. This new (in fact the same) gcc now works fine both with '-O' and without it. Looks like a pilot error. Strange, anyway. Sorry to bother you all. On Sun, Jan 21, 2001 at 02:50:48PM +0300, Alex Kapranoff wrote: > I have -CURRENT on a UP P166 box. > > I've just managed to build a new kernel and world (cvsuped yesterday) > and installed them both. Now I get: > > cc: Internal compiler error: program cc1 got fatal signal 11 > *** Error code 1 > > Stop in /usr/home/alex/work/own. > > whenever I want to compile something not so trivial as `hello world'. > > So, am I stuck in this situation? I cannot build neither kernel nor > gcc now. Are there any ways out? Unfortunately, I don't backup system > binaries, libs or headers. > > How can I debug this? BTW, other big programs such as INN, apache + > mod_php4 work like a charm. -- Alex Kapranoff, Voice: +7(0832)791845 We've lived 2 weeks in the brand new millenium... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 7:34: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 42D9037B401 for ; Sun, 21 Jan 2001 07:33:43 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id CAA04656; Mon, 22 Jan 2001 02:33:37 +1100 Date: Mon, 22 Jan 2001 02:33:31 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Will Andrews Cc: current@FreeBSD.ORG Subject: Re: sys/time.h w/ timespec stuff In-Reply-To: <20010121011326.D3002@puck.firepipe.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Will Andrews wrote: > The timespec* stuff is hidden behind the _KERNEL aura on FreeBSD, but > not on OpenBSD. This is manifested in OpenBSD's make source, which uses > timespec for a few things. > > So now, maybe someone can answer my question: why is timespec _KERNEL? The timespec macros are unportable and are specialized for the kernel, so they shouldn't be turned into application interfaces. Similarly for the timeval macros, except they shouldn't have been turned into application interfaces (we have them for compatibility with NetBSD/ OpenBSD). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 8:48:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.org.ru (sweet.etrust.ru [194.84.67.5]) by hub.freebsd.org (Postfix) with ESMTP id EA85737B698 for ; Sun, 21 Jan 2001 08:48:36 -0800 (PST) Received: by freebsd.org.ru (Postfix, from userid 1000) id 0C690135; Sun, 21 Jan 2001 19:48:35 +0300 (MSK) Date: Sun, 21 Jan 2001 19:48:34 +0300 From: "Sergey A. Osokin" To: freebsd-current@FreeBSD.org Subject: buildworld in -current failed... Message-ID: <20010121194834.A75163@freebsd.org.ru> Reply-To: osa@FreeBSD.org.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello. After resup few hours ago, i try to buildworld on FreeBSD 5.0-CURRENT #0: Sat Jan 13 22:57:43 MSK 2001 gzip -cn /usr/src/lib/libc/../libc/regex/re_format.7 > re_format.7.gz make in free(): error: junk pointer, too high to make sense. Abort trap - core dumped *** Error code 134 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any idea? -- Rgdz, /"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN osa@freebsd.org.ru X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 10: 5: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from VL-MS-MR003.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 2011D37B404 for ; Sun, 21 Jan 2001 10:04:40 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR003.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G7IY7Q05.181; Sun, 21 Jan 2001 13:04:38 -0500 Message-ID: <009e01c083d4$d880d0c0$1f90c918@jehovah> From: "Bosko Milekic" To: "Jason Evans" , References: <20010121062953.V69199@canonware.com> Subject: Re: WITNESS may cause failed boot, patch available Date: Sun, 21 Jan 2001 13:06:15 -0500 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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Evans wrote: > Peter Wemm noticed that WITNESS currently causes a kernel trap the alpha. > The bug also exists on x86, but does not necessarily cause any problems. > If you run into problems (probably during boot), there is a patch available > that should fix the WITNESS problem: > > http://people.freebsd.org/~jasone/diffs/mutex_f_3.diff This looks like a variation of Peter's mutex.diff which moves a bunch of macros to kern/kern_mutex.c from sys/mutex.h - so is it final now that we will move them there? > Jason -Bosko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 11:10:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 06AE937B400 for ; Sun, 21 Jan 2001 11:09:56 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id LAA03085 for ; Sun, 21 Jan 2001 11:09:55 -0800 Date: Sun, 21 Jan 2001 11:09:56 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: current@freebsd.org Subject: loopback nfs hangs now propagated to -stable... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The loopback nfs hangs that have been with us for a month have now propagated to -stable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 11:35:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id CA50F37B401 for ; Sun, 21 Jan 2001 11:34:58 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0LJYr715345; Sun, 21 Jan 2001 11:34:53 -0800 (PST) (envelope-from dillon) Date: Sun, 21 Jan 2001 11:34:53 -0800 (PST) From: Matt Dillon Message-Id: <200101211934.f0LJYr715345@earth.backplane.com> To: freebsd-current@freebsd.org Subject: strong recommendation re: NFS Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Guys, I've noticed that some of you have been making noises about cleaning up the NFS macros in current. I strongly recommend that you not do this, at least not unless you want to take on a man month (or two!) worth of work & debugging! In fact, I would recommend that the NFS subsystem be left alone as much as possible until -current is far more stable then it is. NFS issues tend to be subtle, and unless you've been staring at the code for a year you are likely to introduce more bugs then you fix. There's a reason why I (Mr 'rewrite everything' Dillon) haven't touched them. Concentrate on making the general network stack (aka TCP) and filesystems SMP aware. Leave NFS alone for now. Please. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 11:50:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from gypsy.vrac.iastate.edu (gypsy.vrac.iastate.edu [129.186.232.122]) by hub.freebsd.org (Postfix) with ESMTP id 70FD637B400 for ; Sun, 21 Jan 2001 11:50:35 -0800 (PST) Received: from 137.org (howe-193-222.dhcp.iastate.edu [129.186.193.222]) by gypsy.vrac.iastate.edu (Postfix) with ESMTP id 1EC2BF7; Sun, 21 Jan 2001 13:50:29 -0600 (CST) Message-ID: <3A6B3D84.58831A5@137.org> Date: Sun, 21 Jan 2001 13:50:28 -0600 From: Chris X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 Cc: David Syphers , current@FreeBSD.ORG Subject: Re: XFree86 4.0.2 References: <4.3.2.7.2.20010121013438.00ba9100@nsit-popmail.uchicago.edu> <20010121023208.A63679@citusc17.usc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > > On Sun, Jan 21, 2001 at 01:51:05AM -0600, David Syphers wrote: > > > the binaries from a directory labeled "FreeBSD 5.x". So I tried the ports, > > and it built fine for a long time, and then after about 35300 lines of > > output to the screen, ran into > > > > make: don't know how to make ../../../fonts/encodings/encodings.dir. Stop > > *** Error code 2 > > > > Stop in /usr/ports/x11/XFree86-4/work/xc/fonts/bdf. > > The port should be working, but since it's not for you, just add the package. > > pkg_add -r XFree86 If you are currently running 4.0.1, I would seriously recommend skipping this minor revision. I have run into a multitude of problems with it, and am now back right where I started. One, is the lack of DRM support for the matrox cards anymore. The kernel module has a version number in it, which is less than that required by the DRM system. It won't insert the module until you update this--so it appears that no one is actually using it. Another, is that there seem to be delays in the event stream, making interactive performance terrible. One example: When I go to move a window, I start dragging it, moving the outline as I go. Then I unclick, yet the frame is still visible. I actually have to move the mouse more to get the window move to take effect. There are other cases, where it appears to lose events all together--like clicking on windows to raise them, or with menus. There were also a handful of other things, that I don't recall offhand now. These problems were observed on a 4.2-STABLE box, not too long ago. I have compiled the source from scratch (with and without matrox DRM stuff), as well as using the stock 4.0.2_5 package, both of which behave the same. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 11:54:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id E703437B400 for ; Sun, 21 Jan 2001 11:54:33 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0LJsWI15413; Sun, 21 Jan 2001 11:54:32 -0800 (PST) (envelope-from dillon) Date: Sun, 21 Jan 2001 11:54:32 -0800 (PST) From: Matt Dillon Message-Id: <200101211954.f0LJsWI15413@earth.backplane.com> To: Matthew Jacob Cc: current@FreeBSD.ORG Subject: Re: loopback nfs hangs now propagated to -stable... References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :The loopback nfs hangs that have been with us for a month have now propagated :to -stable. Can you break into DDB and get a 'ps' and a kernel core? There are a bunch of things it could be, including possibly my low-memory deadlock code (which concentrated more on UFS and not so much on NFS), though my low-memory deadlock code was committed all the way back in december (12/29). The only recent commit was to fix an O_EXCL bug, and I doubt that could cause a loopback deadlock. The cause could also be related to MFC's (not by me) related to the network stack, which are more recent. There isn't much in the cvs logs that I can see as having caused the problem to occur only recently. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 13:19:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 2D70A37B402 for ; Sun, 21 Jan 2001 13:19:38 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0LLJP901744; Sun, 21 Jan 2001 14:19:26 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101212119.f0LLJP901744@harmony.village.org> To: Jason Evans Subject: Re: HEADS UP: Strange booting lockups Cc: current@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Jan 2001 02:32:38 PST." <20010121023238.S69199@canonware.com> References: <20010121023238.S69199@canonware.com> Date: Sun, 21 Jan 2001 14:19:25 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010121023238.S69199@canonware.com> Jason Evans writes: : Several of us have started experiencing problems with kernels that won't : boot. The symptom is hard to miss: the machine locks up at the spinner : just before printing the copyright message at the beginning of the boot : sequence. I've seen this on laptops that don't clear their RAM for a long time. I suspect that it is something different, however. My bug is that the kernel goes looking for dmesg buffer, finds a bogus pointer and walks off the edge of the world. Bang, you are dead. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 13:22:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 1E6C137B401 for ; Sun, 21 Jan 2001 13:22:10 -0800 (PST) Received: (qmail 62185 invoked by uid 1142); 21 Jan 2001 21:22:09 -0000 Date: 21 Jan 2001 13:22:09 -0800 Date: Sun, 21 Jan 2001 13:22:00 -0800 From: Jason Evans To: Bosko Milekic Cc: current@FreeBSD.ORG Subject: Re: WITNESS may cause failed boot, patch available Message-ID: <20010121132200.W69199@canonware.com> References: <20010121062953.V69199@canonware.com> <009e01c083d4$d880d0c0$1f90c918@jehovah> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <009e01c083d4$d880d0c0$1f90c918@jehovah>; from bmilekic@technokratis.com on Sun, Jan 21, 2001 at 01:06:15PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 01:06:15PM -0500, Bosko Milekic wrote: > > > http://people.freebsd.org/~jasone/diffs/mutex_f_3.diff > > This looks like a variation of Peter's mutex.diff which moves a bunch of > macros to kern/kern_mutex.c from sys/mutex.h - so is it final now that we > will move them there? It was one of the things I expected to happen as part of the mutex API and inlining cleanup, but it was necessary to either move a bunch of mutex implementation details out of mutex.h, or to expose even more implementation details in order to fix the WITNESS breakage, so I did the former. By the way, Peter helped me clean this patch up, so there isn't a conflict of interest between the two patches. I just wish this could have waited until your mutex cleanups were ready. =) Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 14: 5:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from relay3.inwind.it (relay3.inwind.it [212.141.53.74]) by hub.freebsd.org (Postfix) with ESMTP id 0D1E237B401 for ; Sun, 21 Jan 2001 14:04:58 -0800 (PST) Received: from bartequi.ottodomain.org (62.98.171.186) by relay3.inwind.it (5.1.056) id 3A40BF8600668C51 for freebsd-current@FreeBSD.ORG; Sun, 21 Jan 2001 23:04:50 +0100 From: Salvo Bartolotta Date: Sun, 21 Jan 2001 22:07:18 GMT Message-ID: <20010121.22071800@bartequi.ottodomain.org> Subject: cvsup'ing repo & cvs-checkout'ing sources makes cvs complain... To: freebsd-current@FreeBSD.ORG X-Mailer: SuperCalifragilis X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG /* apologies if this is not the most appropriate list; [additional] * apologies for the long post; suggestions and pointers gladly * accepted. */ Dear FreeBSD'ers, Over the past few days, I have been cvsup'ing FreeBSD's repository and cvs-checkout'ing out my -CURRENT sources; for the record, I had been cvsup'ing my sources and making the buildkernel etc. dance flawlessly on this very test system. It seems a logical approach to switch from cvsup'ing each system separately to cvsup'ing the repo & cvs-checkout'ing the desired modules (src, ports, doc, www) for each of my systems. However, I have had a few (probably minor) problems on my -CURRENT test system, where I am playing the new "cvsup repo"/"cvs-checkout modules" dance. My (stripped) cvs-supfile:
# $FreeBSD: src/share/examples/cvsup/cvs-supfile,v 1.26.2.3 2000/09/22 06:31:21 asami Exp $ # *default host=3Dcvsup.nl.FreeBSD.org *default base=3D/myjunk *default prefix=3D/myjunk/home/ncvs *default release=3Dcvs *default delete use-rel-suffix *default compress src-all ports-all doc-all www
------------ The background (also posted to -questions) -------------- Following Warner's directions in internat.txt, I removed the crypto-related stuff, and issued the following explicit command: 201 1:54am /usr # >=3D=3D=3D=3D> cvs -d /myjunk/home/ncvs checkout -r HE= AD src # Script started on Wed Jan 17 01:54:54 2001 You have mail. 201 1:54am /usr # >=3D=3D=3D=3D> cvs -d /myjunk/home/ncvs checkout -r HE= AD src cvs checkout: Updating src RCS file: /myjunk/home/ncvs/src/Makefile,v retrieving revision 1.234 retrieving revision 1.242 Merging differences between 1.234 and 1.242 into Makefile src/Makefile already contains the differences between 1.234 and 1.242 RCS file: /myjunk/home/ncvs/src/Makefile.inc1,v retrieving revision 1.141.2.2 retrieving revision 1.180 Merging differences between 1.141.2.2 and 1.180 into Makefile.inc1 src/Makefile.inc1 already contains the differences between 1.141.2.2 and 1.180 RCS file: /myjunk/home/ncvs/src/README,v retrieving revision 1.15 retrieving revision 1.19 Merging differences between 1.15 and 1.19 into README src/README already contains the differences between 1.15 and 1.19 RCS file: /myjunk/home/ncvs/src/UPDATING,v retrieving revision 1.73.2.3 retrieving revision 1.134 Merging differences between 1.73.2.3 and 1.134 into UPDATING src/UPDATING already contains the differences between 1.73.2.3 and 1.134 /* How come...? */ ? src/contrib ? src/gnu ? src/etc ? src/games ? src/include ? src/lib ? src/libexec ? src/release ? src/bin ? src/sbin ? src/share ? src/sys ? src/usr.bin ? src/usr.sbin ? src/tools ? src/kerberosIV ? src/kerberos5 ? src/makeworld_logfiles /* ? cvs doesn't like all directories, except the removed (crypto) ones, which are correctly updated. */ cvs checkout: Updating src/crypto U src/crypto/README cvs checkout: Updating src/crypto/heimdal U src/crypto/heimdal/ChangeLog /* cvs correctly updates the files in the src/crypto directories: heimdal, kerberos, openssh, etc. */ cvs checkout: Updating src/secure U src/secure/Makefile /* cvs correctly updates the files in the src/crypto directories: heimdal, kerberos, openssh, etc.; nothing else is updated */ 202 1:59am /usr # >=3D=3D=3D=3D> exit exit Script done on Wed Jan 17 02:00:13 2001 Needless to say, I rm -rf'ed the directories marked by "?", and repeated the whole checkout operation. Apart from a few ? in front of some files of mine in the source tree, everything was fine. I am now happily running a -CURRENT built from those very sources. What am I missing in the above cvs steps ? Why were my source directories marked as "?" and not updated ? Is it really necessary to rm -rf those subtrees? Mutatis mutandis, the same occurred in my ports tree (in the same -CURRENT system): Script started on Thu Jan 18 00:28:26 2001 You have mail. 201 12:28am /usr # >=3D=3D=3D=3D> cvs -d /myjunk/home/ncvs checkout port= s cvs checkout: Updating ports U ports/.cvsignore cvs checkout: move away ports/INDEX; it is in the way C ports/INDEX cvs checkout: move away ports/LEGAL; it is in the way C ports/LEGAL U ports/Makefile U ports/README ? ports/README.html ? ports/Mk ? ports/Templates ? ports/Tools ? ports/archivers ? ports/astro ? ports/audio ? ports/benchmarks ? ports/biology ? ports/cad ? ports/chinese ? ports/comms ? ports/converters ? ports/databases ? ports/deskutils ? ports/devel ? ports/editors ? ports/emulators ? ports/ftp ? ports/games Again, removing the "?" directories (except distfiles) and cvs checkout'ing once more gave me a working ports tree. I haven't tried other modules (yet). I would first like to understand what happened. ---------------------- brand-new problems ------------------------- As I said above, I removed the "?" directories, cvs-checkout'ed my sources, and successfully updated my -CURRENT (test) system. But on the next src checkout, the following warnings were given: Script started on Fri Jan 19 01:35:40 2001 You have mail. 201 1:35am /usr # >=3D=3D=3D=3D> cvs -d /myjunk/home/ncvs/ -q checkout -= r HEAD src # >=3D=3D=3D=3D> grep warning: cvscheckout.log > cvscheckout.warn # >=3D=3D=3D=3D> cat cvscheckout.warn cvs checkout: warning: src/lib/libc/compat-43/sigblock.2 is not (any longer) pertinent cvs checkout: warning: src/lib/libc/rpc/rstat.1 is not (any longer) pertinent cvs checkout: warning: src/lib/libc/rpc/rstat_svc.8 is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/Makefile is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/anonFTP.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/cdrom.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/command.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/config.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/dev2c.sh is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/devices.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/dhcp.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/disks.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/dispatch.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/dist.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/dist.h is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/dmenu.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/doc.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/dos.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/floppy.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/ftp.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/globals.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/http.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/index.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/install.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/install.cfg is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/installUpgrade.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/keymap.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/kget.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/label.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/list.h is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/main.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/media.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/menus.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/misc.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/modules.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/mouse.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/msg.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/network.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/nfs.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/options.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/package.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/pccard.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/rtermcap.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/sysinstall.8 is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/sysinstall.h is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/system.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/tape.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/tcpip.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/termcap.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/ufs.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/usb.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/user.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/variable.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/wizard.c is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/anonftp.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/configure.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/distributions.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/drives.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/fixit.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/html.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/media.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/network_device.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/options.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/partition.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/register.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/shortcuts.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/slice.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/tcp.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/usage.hlp is not (any longer) pertinent cvs checkout: warning: src/release/sysinstall/help/usermgmt.hlp is not (any longer) pertinent cvs checkout: warning: src/sbin/mount_ifs/getmntopts.3 is not (any longer) pertinent cvs checkout: warning: src/sbin/mount_ifs/getmntopts.c is not (any longer) pertinent cvs checkout: warning: src/sbin/mount_ifs/mntopts.h is not (any longer) pertinent cvs checkout: warning: src/sbin/mount_ifs/mount.8 is not (any longer) pertinent cvs checkout: warning: src/sbin/mount_ifs/pathnames.h is not (any longer) pertinent cvs checkout: warning: src/sys/alpha/include/console.h is not (any longer) pertinent cvs checkout: warning: src/sys/alpha/include/mouse.h is not (any longer) pertinent cvs checkout: warning: src/sys/i386/include/console.h is not (any longer) pertinent cvs checkout: warning: src/sys/i386/include/mouse.h is not (any longer) pertinent cvs checkout: warning: src/sys/ia64/include/console.h is not (any longer) pertinent cvs checkout: warning: src/sys/ia64/include/mouse.h is not (any longer) pertinent Incidentally, I successfully performed a buildworld from those warning-provoking sources; however, I was cautious, and stopped the updating process there. I seem to have been playing by the book; why is cvs complaining?/what am I missing? TIA, Salvo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 14:23:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 28EB437B404 for ; Sun, 21 Jan 2001 14:23:13 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id JAA25242; Mon, 22 Jan 2001 09:23:02 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01JZ7BBMWK9C900WYP@cim.alcatel.com.au>; Mon, 22 Jan 2001 09:22:57 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f0LMMqK65446; Mon, 22 Jan 2001 09:22:52 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Mon, 22 Jan 2001 09:22:52 +1100 From: Peter Jeremy Subject: Re: VN bug or pilot error ? In-reply-to: <3A6AA8AA.AE4385C2@free.fr>; from thierry.herbelot@free.fr on Sun, Jan 21, 2001 at 10:15:22AM +0100 To: Thierry Herbelot Cc: current@FreeBSD.ORG Mail-followup-to: Thierry Herbelot , current@FreeBSD.ORG Message-id: <20010122092252.P9165@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <3A6AA8AA.AE4385C2@free.fr> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2001-Jan-21 10:15:22 +0100, Thierry Herbelot wrote: >I've got a recent current (cvsuped and rebuilt yesterday) on a laptop >and I can't use the vn(4) pseudo-driver : I've compiled it in the kernel >and I've also tried to kldload vn.ko, but I get consistently "vn0c : >device not configured" when I try to use it to mount a locally stored >iso image. Change "vn0c" to "vn0". I believe this is the result of PHK's change in mid-December which added cloning to vn. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 14:29:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.cc.u-szeged.hu (sol.cc.u-szeged.hu [160.114.8.24]) by hub.freebsd.org (Postfix) with ESMTP id A70D137B698 for ; Sun, 21 Jan 2001 14:28:52 -0800 (PST) Received: from petra.hos.u-szeged.hu by sol.cc.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id XAA00876; Sun, 21 Jan 2001 23:28:45 +0100 (MET) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 14KSyc-00060c-00 for ; Sun, 21 Jan 2001 23:28:46 +0100 Date: Sun, 21 Jan 2001 23:28:46 +0100 From: Szilveszter Adam To: freebsd-current@FreeBSD.ORG Subject: Re: cvsup'ing repo & cvs-checkout'ing sources makes cvs complain... Message-ID: <20010121232846.A19387@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , freebsd-current@FreeBSD.ORG References: <20010121.22071800@bartequi.ottodomain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010121.22071800@bartequi.ottodomain.org>; from bartequi@inwind.it on Sun, Jan 21, 2001 at 10:07:18PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Salvo, Maybe I do not know your problem exactly but I am trying to find out... I think that what you saw at first try was related to the fact that the source tree you tried to upgrade did not have CVS directories in each directory. These directories are needed for proper CVS operation. If you cd to any dir that you have rm -f-ed and checked out again, you will find a CVS subdir in each. If you like you can look at what is in those dirs, in short CVS keeps book about what files have been co-d from the repo, at what time etc so that it knows what files to update and leaves the rest alone. Also, it uses this info to decide which files have changed when you want to commit. So if you want to place a directory under CVS control, you must first rm -rf it and then check it out again. As for your second question: CVS does not normally delete files that you no longer need but only displays warnings about them. You can remove those files now. Cvsup in contrast also removes the files if you tell it so. A useful option to use when doing CVS updates is -P it will delete empty directories in the tree. But even that will not delete files. Also you can try to use -d which will create directories upon checkout if needed. Also, if you want the HEAD branch, you can just say: -A and it will do instead of -r HEAD. Good luck and I hope this was of some help. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 15:17:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from relay3.inwind.it (relay3.inwind.it [212.141.53.74]) by hub.freebsd.org (Postfix) with ESMTP id AC69D37B400 for ; Sun, 21 Jan 2001 15:16:57 -0800 (PST) Received: from bartequi.ottodomain.org (62.98.171.186) by relay3.inwind.it (5.1.056) id 3A40BF860066BF42; Mon, 22 Jan 2001 00:16:21 +0100 From: Salvo Bartolotta Date: Sun, 21 Jan 2001 23:18:58 GMT Message-ID: <20010121.23185800@bartequi.ottodomain.org> Subject: Re: cvsup'ing repo & cvs-checkout'ing sources makes cvs complain... To: Szilveszter Adam Cc: freebsd-current@FreeBSD.ORG References: <20010121.22071800@bartequi.ottodomain.org> <20010121232846.A19387@petra.hos.u-szeged.hu> X-Mailer: SuperCalifragilis X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 1/21/01, 11:28:46 PM, Szilveszter Adam wrote regarding Re: cvsup'ing repo & cvs-checkout'ing sources makes cvs complain...: > Dear Salvo, > So if you want to place a directory under CVS control, you must > first rm -rf it and then check it out again. Thanks a lot again. And still more apologies for the newbieish questions. Evidently, I was not correct in implicitly assuming that cvs would recognize/adopt a previously cvsup'ed tree. > As for your second question: CVS does not normally delete files that > you no longer need but only displays warnings about them. You can > remove those files now. Cvsup in contrast also removes the files if > you tell it so. Ok, since I logged those warnings, I'll just write a two-liner awk/perl script for that :-) Best regards, Salvo (I'll get out and grep someone... :-)) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 15:26:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 23ADE37B401 for ; Sun, 21 Jan 2001 15:26:23 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0LNTNh74689; Sun, 21 Jan 2001 15:29:23 -0800 (PST) (envelope-from kris) Date: Sun, 21 Jan 2001 15:29:22 -0800 From: Kris Kennaway To: "Donald J . Maddox" Cc: Alex Zepeda , current@FreeBSD.ORG Subject: Re: HEADS UP: Strange booting lockups Message-ID: <20010121152922.C74407@citusc17.usc.edu> References: <20010121023238.S69199@canonware.com> <20010121025457.A396@zippy.pacbell.net> <20010121060520.A396@cae88-102-101.sc.rr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010121060520.A396@cae88-102-101.sc.rr.com>; from dmaddox@sc.rr.com on Sun, Jan 21, 2001 at 06:05:20AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --+nBD6E3TurpgldQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 21, 2001 at 06:05:20AM -0500, Donald J . Maddox wrote: > It may have absolutely nothing to do with either of these cases, but > I found out the hard way recently that booting with no device.hints > in /boot will exhibit symptoms that appear identical to this. Is it > possible that something is trashing the device list, or not initializing > it properly at kernel load time? This is a different problem. If you don't have device hints available at boot (statically compiled into the kernel or loaded from /boot) then the console driver doesn't get its hints, and doesn't work in the manner you describe. Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --+nBD6E3TurpgldQp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6a3DSWry0BWjoQKURAhB0AKD7+sQf3BxQ+EWyxKrXwYP3T/L+OgCdG8p5 GFiZCSZbVtTaz3COt5bxklQ= =wR1o -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 16:10:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (SHW2-202.accesscable.net [24.71.145.202]) by hub.freebsd.org (Postfix) with ESMTP id C3E9C37B401 for ; Sun, 21 Jan 2001 16:10:10 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id f0M08H100706 for ; Sun, 21 Jan 2001 20:08:17 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Sun, 21 Jan 2001 20:08:17 -0400 (AST) From: The Hermit Hacker To: Subject: lastest kernel from cvs ( sh exists with signal 8 ) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG just tried to reboot with a latest build (from this afternoon), and upon reboot, it gives: pid 6 (sh), uid 0: exited with signal 8 when /etc/rc tries to run, and, of course, won't let me get to single user mode for same reason ... checked /usr/src/UPDATING, and nothing in there seems to apply ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 16:37:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from Mail6.sc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by hub.freebsd.org (Postfix) with ESMTP id 16E3F37B401; Sun, 21 Jan 2001 16:37:12 -0800 (PST) Received: from sc.rr.com ([24.88.102.101]) by Mail6.sc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Sun, 21 Jan 2001 19:37:11 -0500 Received: (from dmaddox@localhost) by sc.rr.com (8.11.1/8.11.1) id f0M0cAB15727; Sun, 21 Jan 2001 19:38:10 -0500 (EST) (envelope-from dmaddox) Date: Sun, 21 Jan 2001 19:38:10 -0500 From: "Donald J . Maddox" To: Kris Kennaway Cc: "Donald J . Maddox" , Alex Zepeda , current@FreeBSD.ORG Subject: Re: HEADS UP: Strange booting lockups Message-ID: <20010121193810.B15459@cae88-102-101.sc.rr.com> Reply-To: dmaddox@sc.rr.com Mail-Followup-To: Kris Kennaway , "Donald J . Maddox" , Alex Zepeda , current@FreeBSD.ORG References: <20010121023238.S69199@canonware.com> <20010121025457.A396@zippy.pacbell.net> <20010121060520.A396@cae88-102-101.sc.rr.com> <20010121152922.C74407@citusc17.usc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010121152922.C74407@citusc17.usc.edu>; from kris@FreeBSD.ORG on Sun, Jan 21, 2001 at 03:29:22PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 03:29:22PM -0800, Kris Kennaway wrote: > On Sun, Jan 21, 2001 at 06:05:20AM -0500, Donald J . Maddox wrote: > > > It may have absolutely nothing to do with either of these cases, but > > I found out the hard way recently that booting with no device.hints > > in /boot will exhibit symptoms that appear identical to this. Is it > > possible that something is trashing the device list, or not initializing > > it properly at kernel load time? > > This is a different problem. If you don't have device hints available > at boot (statically compiled into the kernel or loaded from /boot) > then the console driver doesn't get its hints, and doesn't work in the > manner you describe. Yeah, I know what my problem was... I was just suggesting that if something trashed the area of memory where these hints live at boot time, it could possibly cause the problem being described. That wasn't the problem, but hey, I was trying to help :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 20:36:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id DDB3037B400 for ; Sun, 21 Jan 2001 20:36:42 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0M4ZQk11489; Sun, 21 Jan 2001 20:35:40 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101220435.f0M4ZQk11489@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: The Hermit Hacker Cc: freebsd-current@FreeBSD.ORG Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) In-Reply-To: Date: Sun, 21 Jan 2001 20:35:26 -0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Hermit Hacker wrote: > > just tried to reboot with a latest build (from this afternoon), and upon > reboot, it gives: > > pid 6 (sh), uid 0: exited with signal 8 > > when /etc/rc tries to run, and, of course, won't let me get to single user > mode for same reason ... > > checked /usr/src/UPDATING, and nothing in there seems to apply ... We were discussing this and a couple of other related strange things that turned up. I might have broken the npx code with my last config(8) change and the corresponding #ifdefs. I have not gone back over it all again but will shortly. Given that two people have this sort of problem now, things are pointing to the npx commits somehow. You did rebuild config, right? Can you please check the opt_npx.h file in your build directory and make sure it has "#define DEV_NPX 1" in it? Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 20:39:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (SHW2-202.accesscable.net [24.71.145.202]) by hub.freebsd.org (Postfix) with ESMTP id 0E3D637B401 for ; Sun, 21 Jan 2001 20:39:36 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id f0M4bHH04160; Mon, 22 Jan 2001 00:37:17 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 22 Jan 2001 00:37:17 -0400 (AST) From: The Hermit Hacker To: Peter Wemm Cc: Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) In-Reply-To: <200101220435.f0M4ZQk11489@mobile.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG d'oh, did it backwards again ... buildkernel then buildworld ... let me go back and rebuild kernel and see if that is all it was in my case ... On Sun, 21 Jan 2001, Peter Wemm wrote: > The Hermit Hacker wrote: > > > > just tried to reboot with a latest build (from this afternoon), and upon > > reboot, it gives: > > > > pid 6 (sh), uid 0: exited with signal 8 > > > > when /etc/rc tries to run, and, of course, won't let me get to single user > > mode for same reason ... > > > > checked /usr/src/UPDATING, and nothing in there seems to apply ... > > We were discussing this and a couple of other related strange things > that turned up. I might have broken the npx code with my last config(8) > change and the corresponding #ifdefs. I have not gone back over it all > again but will shortly. Given that two people have this sort of problem > now, things are pointing to the npx commits somehow. You did rebuild config, > right? > > Can you please check the opt_npx.h file in your build directory and make sure > it has "#define DEV_NPX 1" in it? > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 21:48: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from white.imgsrc.co.jp (ns.imgsrc.co.jp [210.226.20.2]) by hub.freebsd.org (Postfix) with ESMTP id DA28F37B699; Sun, 21 Jan 2001 21:47:48 -0800 (PST) Received: from waterblue.imgsrc.co.jp (waterblue.imgsrc.co.jp [210.226.20.160]) by white.imgsrc.co.jp (8.11.2/8.11.0) with ESMTP id f0M5lkj25574; Mon, 22 Jan 2001 14:47:47 +0900 (JST) Date: Mon, 22 Jan 2001 14:47:45 +0900 Message-ID: <7mae8kt9xa.wl@waterblue.imgsrc.co.jp> From: Jun Kuriyama To: Current , freebsd-emulation@FreeBSD.org Subject: Cannot build emulators/vmware2 User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 13) (Crater Lake) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After installworld'ing today, I cannot compile emulators/vmware2. Does someone see this result? ----- cc -O -mpentiumpro -pipe -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/include -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/common -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/export/include -I/sys -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/ -DCDEV_MAJOR_=200 -DSMP -DAPIC_IO -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/include -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/common -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/expor! t/include -I/sys -I/tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/../vmnet-only/freebsd/ -I. -I@ -I@/dev -I@/../include -mpreferred-stack-boundary=2 -c /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c In file included from /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c:66: /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.h:25: field `rsel' has incomplete type /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c: In function `FreeBSD_Driver_Poll': /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c:495: warning: implicit declaration of function `selrecord' /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c: In function `FreeBSD_DriverSelectTimeout': /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only/freebsd/driver.c:519: warning: implicit declaration of function `selwakeup' *** Error code 1 Stop in /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib/vmmon-only. *** Error code 1 Stop in /tmp/work/home/ports/emulators/vmware2/work/vmware-distrib. *** Error code 1 Stop in /home/ports/emulators/vmware2. *** Error code 1 Stop in /home/ports/emulators/vmware2. *** Error code 1 Stop in /home/ports/emulators/vmware2. -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 22:22:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from herbelot.dyndns.org (s014.dhcp212-24.cybercable.fr [212.198.24.14]) by hub.freebsd.org (Postfix) with ESMTP id 4AC1837B69D for ; Sun, 21 Jan 2001 22:22:00 -0800 (PST) Received: from free.fr (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id HAA68430; Mon, 22 Jan 2001 07:21:50 +0100 (CET) (envelope-from thierry.herbelot@free.fr) Message-ID: <3A6BD17E.657F2D0@free.fr> Date: Mon, 22 Jan 2001 07:21:50 +0100 From: Thierry Herbelot X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Jeremy Cc: current@FreeBSD.ORG Subject: Re: VN bug or pilot error ? References: <3A6AA8AA.AE4385C2@free.fr> <20010122092252.P9165@gsmx07.alcatel.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG thanks a lot : that was it ! Peter Jeremy wrote: > > On 2001-Jan-21 10:15:22 +0100, Thierry Herbelot wrote: > >I've got a recent current (cvsuped and rebuilt yesterday) on a laptop > >and I can't use the vn(4) pseudo-driver : I've compiled it in the kernel > >and I've also tried to kldload vn.ko, but I get consistently "vn0c : > >device not configured" when I try to use it to mount a locally stored > >iso image. > > Change "vn0c" to "vn0". I believe this is the result of PHK's change > in mid-December which added cloning to vn. > > Peter -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 22:27:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id BE69637B400 for ; Sun, 21 Jan 2001 22:27:36 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0M6RQl13141; Mon, 22 Jan 2001 07:27:26 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Thierry Herbelot Cc: Peter Jeremy , current@FreeBSD.ORG Subject: Re: VN bug or pilot error ? In-Reply-To: Your message of "Mon, 22 Jan 2001 07:21:50 +0100." <3A6BD17E.657F2D0@free.fr> Date: Mon, 22 Jan 2001 07:27:26 +0100 Message-ID: <13139.980144846@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG But while you're at it, migrate to md(4) instead of vn(4), it does vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices Poul-Henning In message <3A6BD17E.657F2D0@free.fr>, Thierry Herbelot writes: >thanks a lot : that was it ! > >Peter Jeremy wrote: >> >> On 2001-Jan-21 10:15:22 +0100, Thierry Herbelot wrote: >> >I've got a recent current (cvsuped and rebuilt yesterday) on a laptop >> >and I can't use the vn(4) pseudo-driver : I've compiled it in the kernel >> >and I've also tried to kldload vn.ko, but I get consistently "vn0c : >> >device not configured" when I try to use it to mount a locally stored >> >iso image. >> >> Change "vn0c" to "vn0". I believe this is the result of PHK's change >> in mid-December which added cloning to vn. >> >> Peter > >-- >Thierry Herbelot > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 22:40:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 24B4637B400; Sun, 21 Jan 2001 22:40:05 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp150.geekhouse.net [192.168.1.150]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f0M6iRs79360; Sun, 21 Jan 2001 22:44:28 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <7mae8kt9xa.wl@waterblue.imgsrc.co.jp> Date: Sun, 21 Jan 2001 22:39:56 -0800 (PST) From: John Baldwin To: Jun Kuriyama Subject: RE: Cannot build emulators/vmware2 Cc: freebsd-emulation@FreeBSD.org, Current Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Jan-01 Jun Kuriyama wrote: > > After installworld'ing today, I cannot compile emulators/vmware2. > Does someone see this result? Fix it to #include instead of was just recently gutted and/or axed (can't remember which). If doesn't work on stable, just do a #ifdef __FreeBSD_version > 4 use selinfo, else use select.h. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 22:50: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 71E1037B404 for ; Sun, 21 Jan 2001 22:49:43 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0M6nUk12690; Sun, 21 Jan 2001 22:49:30 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101220649.f0M6nUk12690@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: The Hermit Hacker Cc: freebsd-current@FreeBSD.ORG Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) In-Reply-To: Date: Sun, 21 Jan 2001 22:49:30 -0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The Hermit Hacker wrote: > > d'oh, did it backwards again ... buildkernel then buildworld ... let me go > back and rebuild kernel and see if that is all it was in my case ... Argh! I wish people would stop using buildkernel! :-( It calls config(8) in such a way that buries the warning messages where people dont see. config(8) is meant to be used interactively :-( > On Sun, 21 Jan 2001, Peter Wemm wrote: > > > The Hermit Hacker wrote: > > > > > > just tried to reboot with a latest build (from this afternoon), and upon > > > reboot, it gives: > > > > > > pid 6 (sh), uid 0: exited with signal 8 > > > > > > when /etc/rc tries to run, and, of course, won't let me get to single use r > > > mode for same reason ... > > > > > > checked /usr/src/UPDATING, and nothing in there seems to apply ... > > > > We were discussing this and a couple of other related strange things > > that turned up. I might have broken the npx code with my last config(8) > > change and the corresponding #ifdefs. I have not gone back over it all > > again but will shortly. Given that two people have this sort of problem > > now, things are pointing to the npx commits somehow. You did rebuild confi g, > > right? > > > > Can you please check the opt_npx.h file in your build directory and make su re > > it has "#define DEV_NPX 1" in it? > > > > Cheers, > > -Peter > > -- > > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrapp y > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.or g > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 22:54:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail8.sc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by hub.freebsd.org (Postfix) with ESMTP id B816E37B401 for ; Sun, 21 Jan 2001 22:54:03 -0800 (PST) Received: from sc.rr.com ([24.88.102.101]) by mail8.sc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 22 Jan 2001 01:52:11 -0500 Received: (from dmaddox@localhost) by sc.rr.com (8.11.1/8.11.1) id f0M6t2118887; Mon, 22 Jan 2001 01:55:02 -0500 (EST) (envelope-from dmaddox) Date: Mon, 22 Jan 2001 01:55:02 -0500 From: "Donald J . Maddox" To: Peter Wemm Cc: The Hermit Hacker , freebsd-current@FreeBSD.ORG Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Message-ID: <20010122015502.A18847@cae88-102-101.sc.rr.com> Reply-To: dmaddox@sc.rr.com Mail-Followup-To: Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.ORG References: <200101220649.f0M6nUk12690@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101220649.f0M6nUk12690@mobile.wemm.org>; from peter@netplex.com.au on Sun, Jan 21, 2001 at 10:49:30PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: > > Argh! I wish people would stop using buildkernel! :-( It calls config(8) > in such a way that buries the warning messages where people dont see. > config(8) is meant to be used interactively :-( Is there another target that will get a kernel built with new tools in /usr/obj rather than old, previously installed binaries? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23: 3:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 4FC2537B69B for ; Sun, 21 Jan 2001 23:03:36 -0800 (PST) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.11.1/8.11.0) id f0M735x22761; Mon, 22 Jan 2001 08:03:05 +0100 (CET) (envelope-from asmodai) Date: Mon, 22 Jan 2001 08:03:05 +0100 From: Jeroen Ruigrok van der Werven To: Peter Wemm Cc: The Hermit Hacker , freebsd-current@FreeBSD.ORG Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Message-ID: <20010122080305.B22424@lucifer.bart.nl> References: <200101220649.f0M6nUk12690@mobile.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101220649.f0M6nUk12690@mobile.wemm.org>; from peter@netplex.com.au on Sun, Jan 21, 2001 at 10:49:30PM -0800 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20010122 07:55], Peter Wemm (peter@netplex.com.au) wrote: >The Hermit Hacker wrote: >> >> d'oh, did it backwards again ... buildkernel then buildworld ... let me go >> back and rebuild kernel and see if that is all it was in my case ... > >Argh! I wish people would stop using buildkernel! :-( It calls config(8) >in such a way that buries the warning messages where people dont see. >config(8) is meant to be used interactively :-( Yeah well, buildkernel was advocated as the next best thing to sliced bread. Myself, I'll stick to the ``old way''. Never failed me thus far. At least, nothing a good rm -rf compile/KERNEL cannot solve. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Killing me is not enough to make me go away... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23: 5: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 0342937B401 for ; Sun, 21 Jan 2001 23:04:44 -0800 (PST) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.11.1/8.11.0) id f0M74dk22773; Mon, 22 Jan 2001 08:04:39 +0100 (CET) (envelope-from asmodai) Date: Mon, 22 Jan 2001 08:04:39 +0100 From: Jeroen Ruigrok van der Werven To: Salvo Bartolotta Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvsup'ing repo & cvs-checkout'ing sources makes cvs complain... Message-ID: <20010122080439.C22424@lucifer.bart.nl> References: <20010121.22071800@bartequi.ottodomain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010121.22071800@bartequi.ottodomain.org>; from bartequi@inwind.it on Sun, Jan 21, 2001 at 10:07:18PM +0000 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20010121 23:10], Salvo Bartolotta (bartequi@inwind.it) wrote: >Following Warner's directions in internat.txt, I removed the >crypto-related stuff, and issued the following explicit command: One question: why? crypto is now folded into src-all -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Killing me is not enough to make me go away... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23: 9:22 2001 Delivered-To: freebsd-current@freebsd.org Received: from lucifer.ninth-circle.org (lucifer.bart.nl [194.158.168.74]) by hub.freebsd.org (Postfix) with ESMTP id 753A637B402; Sun, 21 Jan 2001 23:09:02 -0800 (PST) Received: (from asmodai@localhost) by lucifer.ninth-circle.org (8.11.1/8.11.0) id f0M78Og22856; Mon, 22 Jan 2001 08:08:24 +0100 (CET) (envelope-from asmodai) Date: Mon, 22 Jan 2001 08:08:24 +0100 From: Jeroen Ruigrok van der Werven To: Alex Kapranoff Cc: current@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: Lots of page faults Message-ID: <20010122080824.D22424@lucifer.bart.nl> References: <20010120103135.A10608@kapran.bitmcnit.bryansk.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010120103135.A10608@kapran.bitmcnit.bryansk.su>; from alex@kapran.bitmcnit.bryansk.su on Sat, Jan 20, 2001 at 10:31:37AM +0300 Organisation: VIA Net.Works The Netherlands Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20010120 08:40], Alex Kapranoff (alex@kapran.bitmcnit.bryansk.su) wrote: >Additional symptoms include very high system CPU state percentage and >a lot of page faults. A page fault is not a bad thing, it is merely an indicator from the CPU to the kernel that the page you want to refer to, the next page of executable data of the application you are running, is not in memory [yet]. The CPU causes a page fault and the kernel pages in the part(s) of the application to memory and then resumes operation, now being able to refer to the appropriate page. [snip] >Is my RAM rotting or what? Given you get coredumps on cc, as and such, it could be. But not always, I have had current give me coredumps in cc and as before but that was due to problems in the binaries themselves after some changes in the world. -- Jeroen Ruigrok van der Werven VIA Net.Works The Netherlands BSD: Technical excellence at its best Network- and systemadministrator D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 Killing me is not enough to make me go away... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:13:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id C454C37B401 for ; Sun, 21 Jan 2001 23:12:53 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp150.geekhouse.net [192.168.1.150]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f0M7HGs79420; Sun, 21 Jan 2001 23:17:16 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010122015502.A18847@cae88-102-101.sc.rr.com> Date: Sun, 21 Jan 2001 23:12:44 -0800 (PST) From: John Baldwin To: "Donald J . Maddox" Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: freebsd-current@FreeBSD.org, The Hermit Hacker , Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Jan-01 Donald J . Maddox wrote: > On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: >> >> Argh! I wish people would stop using buildkernel! :-( It calls config(8) >> in such a way that buries the warning messages where people dont see. >> config(8) is meant to be used interactively :-( > > Is there another target that will get a kernel built with new tools > in /usr/obj rather than old, previously installed binaries? Rarely if ever do you need the new tools. The only cases are for a binutils upgrade that is not backwards compatible (such as the 2.9 -> 2.10 upgrade), or if you need a newer version of config, which can be handled by installing config and then building your kernel. The config(8) changes won't happen in stable, and I don't foresee anymore drastic buildkernel changes in the future. FWIW, I _never_ use buildkernel to update my kernels on any of my boxes. I just do it the old fashioned way, and with the exception of the 2.9 -> 2.10 binutils upgrade, it always works. buildkernel overloads the KERNEL variable and thus violates POLA, so it needs fixing regardless, but I don't see a reason to encourage its use unless it is actually needed. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:17: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (SHW2-202.accesscable.net [24.71.145.202]) by hub.freebsd.org (Postfix) with ESMTP id 1FB2437B69B for ; Sun, 21 Jan 2001 23:16:43 -0800 (PST) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.11.1/8.11.1) with ESMTP id f0M7Ehw20596; Mon, 22 Jan 2001 03:14:43 -0400 (AST) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 22 Jan 2001 03:14:43 -0400 (AST) From: The Hermit Hacker To: Peter Wemm Cc: Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) In-Reply-To: <200101220649.f0M6nUk12690@mobile.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Peter Wemm wrote: > The Hermit Hacker wrote: > > > > d'oh, did it backwards again ... buildkernel then buildworld ... let me go > > back and rebuild kernel and see if that is all it was in my case ... > > Argh! I wish people would stop using buildkernel! :-( It calls config(8) > in such a way that buries the warning messages where people dont see. > config(8) is meant to be used interactively :-( well, according to /usr/src/UPDATING, that is the documented way to do things, or at least two out of 4 of them: To build a kernel ----------------- If you are updating from a prior version of FreeBSD (even one just a few days old), you should follow this procedure. With a /usr/obj tree with a fresh buildworld, make buildkernel KERNEL=YOUR_KERNEL_HERE make installkernel KERNEL=YOUR_KERNEL_HERE To just build a kernel when you know that it won't mess you up -------------------------------------------------------------- cd src/sys/{i386,alpha}/conf config KERNEL_NAME_HERE [1] cd ../../compile/KERNEL_NAME_HERE make depend make make install [1] If in doubt, -r might help here. If this fails, go to the "To build a kernel" section. To rebuild everything and install it on the current system. ----------------------------------------------------------- make world Build a new kernel, see above. To upgrade from 4.x-stable to current ------------------------------------- make buildworld make buildkernel KERNEL=YOUR_KERNEL_HERE cp src/sys/${MACHINE_ARCH}/GENERIC.hints /boot/device.hints [2] make installkernel KERNEL=YOUR_KERNEL_HERE make installworld [1] If this is wrong, can we get that updated? Even /usr/src/README references and steers ppl to buildkernel: "The ``buildkernel'' and ``installkernel'' targets build and install the kernel and the modules (see below)" I have no probs with switching back to the more 'manual way' of cd'ng into conf and using config, etc ... I just got the impression awhile back that using buildkernel/installkernel was the recommended way of doing this, so switched to it ... > > > On Sun, 21 Jan 2001, Peter Wemm wrote: > > > > > The Hermit Hacker wrote: > > > > > > > > just tried to reboot with a latest build (from this afternoon), and upon > > > > reboot, it gives: > > > > > > > > pid 6 (sh), uid 0: exited with signal 8 > > > > > > > > when /etc/rc tries to run, and, of course, won't let me get to single use > r > > > > mode for same reason ... > > > > > > > > checked /usr/src/UPDATING, and nothing in there seems to apply ... > > > > > > We were discussing this and a couple of other related strange things > > > that turned up. I might have broken the npx code with my last config(8) > > > change and the corresponding #ifdefs. I have not gone back over it all > > > again but will shortly. Given that two people have this sort of problem > > > now, things are pointing to the npx commits somehow. You did rebuild confi > g, > > > right? > > > > > > Can you please check the opt_npx.h file in your build directory and make su > re > > > it has "#define DEV_NPX 1" in it? > > > > > > Cheers, > > > -Peter > > > -- > > > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > > > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > > > > > > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrapp > y > > Systems Administrator @ hub.org > > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.or > g > > > > > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:18:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id DB22337B699; Sun, 21 Jan 2001 23:18:18 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp150.geekhouse.net [192.168.1.150]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f0M7Mjs79431; Sun, 21 Jan 2001 23:22:45 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 21 Jan 2001 23:18:13 -0800 (PST) From: John Baldwin To: John Baldwin Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.org, "Donald J . Maddox" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Jan-01 John Baldwin wrote: > > On 22-Jan-01 Donald J . Maddox wrote: >> On Sun, Jan 21, 2001 at 10:49:30PM -0800, Peter Wemm wrote: >>> >>> Argh! I wish people would stop using buildkernel! :-( It calls config(8) >>> in such a way that buries the warning messages where people dont see. >>> config(8) is meant to be used interactively :-( >> >> Is there another target that will get a kernel built with new tools >> in /usr/obj rather than old, previously installed binaries? > > Rarely if ever do you need the new tools. The only cases are for a binutils > upgrade that is not backwards compatible (such as the 2.9 -> 2.10 upgrade), > or > if you need a newer version of config, which can be handled by installing > config and then building your kernel. The config(8) changes won't happen in > stable, and I don't foresee anymore drastic buildkernel changes in the > future. That last 'buildkernel' should be 'toolchain'. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:21:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from herbelot.dyndns.org (s014.dhcp212-24.cybercable.fr [212.198.24.14]) by hub.freebsd.org (Postfix) with ESMTP id BAECD37B401 for ; Sun, 21 Jan 2001 23:21:13 -0800 (PST) Received: from free.fr (multi.herbelot.nom [192.168.1.2]) by herbelot.dyndns.org (8.9.3/8.9.3) with ESMTP id IAA68509; Mon, 22 Jan 2001 08:18:41 +0100 (CET) (envelope-from thierry.herbelot@free.fr) Message-ID: <3A6BDED1.9D437C77@free.fr> Date: Mon, 22 Jan 2001 08:18:41 +0100 From: Thierry Herbelot X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: current@FreeBSD.ORG Subject: Re: VN bug or pilot error ? References: <13139.980144846@critter> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > But while you're at it, migrate to md(4) instead of vn(4), it does > vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices If I may, two more questions : - the 4.2 man page for vn says the file must be stored locally (I have tried vn-mounting a NFS file and it worked : certainly the man page could be corrected - or I was lucky ?) - under 4.2-Release, I have trouble using a larger than 20 Megs MD partition (I have increased MDNsect to 80000, but I still can't store more the 20 Megs : a "cp" with a 35 Megs file stays blocked, and always at the same place - I will give more details) TfH > > Poul-Henning > > In message <3A6BD17E.657F2D0@free.fr>, Thierry Herbelot writes: > >thanks a lot : that was it ! > > > -- > 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. -- Thierry Herbelot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:24:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 3AD1F37B402 for ; Sun, 21 Jan 2001 23:24:03 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0M7Nxl13535; Mon, 22 Jan 2001 08:23:59 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Thierry Herbelot Cc: current@FreeBSD.ORG Subject: Re: VN bug or pilot error ? In-Reply-To: Your message of "Mon, 22 Jan 2001 08:18:41 +0100." <3A6BDED1.9D437C77@free.fr> Date: Mon, 22 Jan 2001 08:23:59 +0100 Message-ID: <13533.980148239@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3A6BDED1.9D437C77@free.fr>, Thierry Herbelot writes: >Poul-Henning Kamp wrote: >> >> But while you're at it, migrate to md(4) instead of vn(4), it does >> vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices > >If I may, two more questions : Sorry, my misundertstanding, seing that you emailed to current@ I pressumed we were talking about -current here. The new md(4)/mdconfig(8) is only in -current and will not make it into -stable any time soon if at all. Poul-Henning > >- the 4.2 man page for vn says the file must be stored locally (I have >tried vn-mounting a NFS file and it worked : certainly the man page >could be corrected - or I was lucky ?) > >- under 4.2-Release, I have trouble using a larger than 20 Megs MD >partition (I have increased MDNsect to 80000, but I still can't store >more the 20 Megs : a "cp" with a 35 Megs file stays blocked, and always >at the same place - I will give more details) > > TfH > >> >> Poul-Henning >> >> In message <3A6BD17E.657F2D0@free.fr>, Thierry Herbelot writes: >> >thanks a lot : that was it ! >> > > >> -- >> 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. > >-- >Thierry Herbelot > -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:27:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from Mail6.sc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by hub.freebsd.org (Postfix) with ESMTP id 1948F37B402; Sun, 21 Jan 2001 23:26:59 -0800 (PST) Received: from sc.rr.com ([24.88.102.101]) by Mail6.sc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 22 Jan 2001 02:26:57 -0500 Received: (from dmaddox@localhost) by sc.rr.com (8.11.1/8.11.1) id f0M7Rv119148; Mon, 22 Jan 2001 02:27:57 -0500 (EST) (envelope-from dmaddox) Date: Mon, 22 Jan 2001 02:27:57 -0500 From: "Donald J . Maddox" To: John Baldwin Cc: "Donald J . Maddox" , freebsd-current@FreeBSD.org, The Hermit Hacker , Peter Wemm Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Message-ID: <20010122022757.B18935@cae88-102-101.sc.rr.com> Reply-To: dmaddox@sc.rr.com Mail-Followup-To: John Baldwin , "Donald J . Maddox" , freebsd-current@FreeBSD.org, The Hermit Hacker , Peter Wemm References: <20010122015502.A18847@cae88-102-101.sc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Sun, Jan 21, 2001 at 11:12:44PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, fair enough. I have to confess that my usual procedure remains, as it has been for a long time, like this: 1) rm -r /usr/include; cd /usr/src; make includes This may be controversial, but it has always worked for me, and although it's not supposed to (in my understanding), the build (I think both world and kernel) does use installed headers. If you don't think so, mv /usr/include and then try to build either. 2) cd usr.sbin/config; make obj && make depend && make && make install 3) config and build kernel 4) make buildworld 5) install kernel 6) make installworld 7) update /etc if necessary 8) reboot Here lately, I have been trying to break this cycle and use the 1) make buildworld 2) make buildkernel 3) make installkernel 4) make installworld 5) reboot cycle instead, since I have been assured that this is the canonical way of doing things now. It appears that these pronouncements were premature at best. On Sun, Jan 21, 2001 at 11:12:44PM -0800, John Baldwin wrote: > > Rarely if ever do you need the new tools. The only cases are for a binutils > upgrade that is not backwards compatible (such as the 2.9 -> 2.10 upgrade), or > if you need a newer version of config, which can be handled by installing > config and then building your kernel. The config(8) changes won't happen in > stable, and I don't foresee anymore drastic buildkernel changes in the future. > > FWIW, I _never_ use buildkernel to update my kernels on any of my boxes. I > just do it the old fashioned way, and with the exception of the 2.9 -> 2.10 > binutils upgrade, it always works. buildkernel overloads the KERNEL variable > and thus violates POLA, so it needs fixing regardless, but I don't see a reason > to encourage its use unless it is actually needed. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:27:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 54CE537B404 for ; Sun, 21 Jan 2001 23:27:07 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp150.geekhouse.net [192.168.1.150]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f0M7VUs79449; Sun, 21 Jan 2001 23:31:30 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 21 Jan 2001 23:26:58 -0800 (PST) From: John Baldwin To: The Hermit Hacker Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: freebsd-current@FreeBSD.org, Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Jan-01 The Hermit Hacker wrote: > On Sun, 21 Jan 2001, Peter Wemm wrote: > >> The Hermit Hacker wrote: >> > >> > d'oh, did it backwards again ... buildkernel then buildworld ... let me go >> > back and rebuild kernel and see if that is all it was in my case ... >> >> Argh! I wish people would stop using buildkernel! :-( It calls config(8) >> in such a way that buries the warning messages where people dont see. >> config(8) is meant to be used interactively :-( > > well, according to /usr/src/UPDATING, that is the documented way to do > things, or at least two out of 4 of them: What happened is that binutils was upgraded from 2.9 to 2.10 in both -current and -stable, and the old and new binutils weren't compatible. So, you had to installworld before building your kernel (which is what I did, and always do in fact). However, this made some people uncomfortable, so a 'buildkernel' target was made to work around this one problem. Then, in order to really beat it into -stable users heads to use it for the one needed upgrade, it was declared the end-all be-all method of upgrading a kernel when updating world. Except that it really isn't. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:36:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 5EA0F37B401 for ; Sun, 21 Jan 2001 23:36:07 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp150.geekhouse.net [192.168.1.150]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f0M7eLs79468; Sun, 21 Jan 2001 23:40:21 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010122022757.B18935@cae88-102-101.sc.rr.com> Date: Sun, 21 Jan 2001 23:35:49 -0800 (PST) From: John Baldwin To: "Donald J . Maddox" Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Jan-01 Donald J . Maddox wrote: > Ok, fair enough. I have to confess that my usual procedure remains, > as it has been for a long time, like this: > > 1) rm -r /usr/include; cd /usr/src; make includes I just do 'make includes' w/o the rm of /usr/include when I do this.. I normally do this, FWIW: 1) make buildworld 2) make installworld 3) config FOO 4) compile kernel FOO 5) install kernel FOO 6) update /etc 7) reboot 1-5 are all in 2 scripts, and part of 6) is in a script. > Here lately, I have been trying to break this cycle and use the > > 1) make buildworld > > 2) make buildkernel > > 3) make installkernel > > 4) make installworld > > 5) reboot This should work, except that buildkernel has a few problems: 1) It (ab)uses the KERNEL make variable so that it now has 2 conflicting meanings. Simply using KERNCONF for the buildkernel case instead can fix this, however. 2) It hides the output from config(8). config(8) prints out all sorts of useful warnings when options are deprecated, etc., but buildkernel hides these from the user. The problem is that config(8) is by design an interactive tool, which buildkernel fails to take into account. The hack now is to have config(8) treat warnings as errors instead. :-/ -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:43:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id ADE7E37B404 for ; Sun, 21 Jan 2001 23:43:23 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id f0M7bjr98421; Mon, 22 Jan 2001 09:37:45 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200101220737.f0M7bjr98421@zibbi.icomtek.csir.co.za> Subject: Re: VN bug or pilot error ? In-Reply-To: <13139.980144846@critter> from Poul-Henning Kamp at "Jan 22, 2001 07:27:26 am" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 22 Jan 2001 09:37:45 +0200 (SAT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > But while you're at it, migrate to md(4) instead of vn(4), it does > vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices > So why not change the release process to use md instead of vn, so that we can make sure it works before vn is axed? John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:43:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3DA0A37B699; Sun, 21 Jan 2001 23:43:36 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0M7hX906143; Mon, 22 Jan 2001 00:43:33 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101220743.f0M7hX906143@harmony.village.org> To: dmaddox@sc.rr.com Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: John Baldwin , freebsd-current@FreeBSD.ORG, The Hermit Hacker , Peter Wemm In-reply-to: Your message of "Mon, 22 Jan 2001 02:27:57 EST." <20010122022757.B18935@cae88-102-101.sc.rr.com> References: <20010122022757.B18935@cae88-102-101.sc.rr.com> <20010122015502.A18847@cae88-102-101.sc.rr.com> Date: Mon, 22 Jan 2001 00:43:33 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010122022757.B18935@cae88-102-101.sc.rr.com> "Donald J . Maddox" writes: : way of doing things now. It appears that these pronouncements were : premature at best. Actually no. It isn't premature. It is the canonical way. It is how we've been telling people to build it for at least the past year or so. Some people don't like it and this is really the first I've heard of it. The reliance on buildworld is, I'll agree, a bit much. But that's going away soon. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:44: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from white.imgsrc.co.jp (ns.imgsrc.co.jp [210.226.20.2]) by hub.freebsd.org (Postfix) with ESMTP id 6734037B69B for ; Sun, 21 Jan 2001 23:43:47 -0800 (PST) Received: from waterblue.imgsrc.co.jp (waterblue.imgsrc.co.jp [210.226.20.160]) by white.imgsrc.co.jp (8.11.2/8.11.0) with ESMTP id f0M7hjj26615; Mon, 22 Jan 2001 16:43:45 +0900 (JST) Date: Mon, 22 Jan 2001 16:43:43 +0900 Message-ID: <7m66j8t4k0.wl@waterblue.imgsrc.co.jp> From: Jun Kuriyama To: Current Subject: Exit value of rtprio(1) User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 13) (Crater Lake) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Mon_Jan_22_16:43:43_2001-1" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --Multipart_Mon_Jan_22_16:43:43_2001-1 Content-Type: text/plain; charset=US-ASCII Manual page of rtprio(1) says it returns exit value 0 on success when PID is specified via argument. But current rtprio(1) returns 1 whether rtprio(2) is processed successfully or not. This patch seems to fix to return 0 on success as documented in manpage. Please let me know if it is wrong... I'll commit this in this week. -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project --Multipart_Mon_Jan_22_16:43:43_2001-1 Content-Type: application/octet-stream; type=patch Content-Disposition: attachment; filename="rtprio.diff" Content-Transfer-Encoding: 7bit Index: rtprio.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/rtprio/rtprio.c,v retrieving revision 1.8 diff -u -r1.8 rtprio.c --- rtprio.c 1999/08/28 01:19:49 1.8 +++ rtprio.c 2001/01/22 07:30:26 @@ -123,6 +123,7 @@ execvp(argv[2], &argv[2]); err(1, "%s", argv[2]); } + exit(0); } exit (1); } --Multipart_Mon_Jan_22_16:43:43_2001-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:47: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from Mail6.sc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by hub.freebsd.org (Postfix) with ESMTP id C5E9737B400; Sun, 21 Jan 2001 23:46:46 -0800 (PST) Received: from sc.rr.com ([24.88.102.101]) by Mail6.sc.rr.com with Microsoft SMTPSVC(5.5.1877.537.53); Mon, 22 Jan 2001 02:46:46 -0500 Received: (from dmaddox@localhost) by sc.rr.com (8.11.1/8.11.1) id f0M7ljG19332; Mon, 22 Jan 2001 02:47:45 -0500 (EST) (envelope-from dmaddox) Date: Mon, 22 Jan 2001 02:47:45 -0500 From: "Donald J . Maddox" To: John Baldwin Cc: Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.ORG Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Message-ID: <20010122024745.A19253@cae88-102-101.sc.rr.com> Reply-To: dmaddox@sc.rr.com Mail-Followup-To: John Baldwin , Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.ORG References: <20010122022757.B18935@cae88-102-101.sc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Sun, Jan 21, 2001 at 11:35:49PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 11:35:49PM -0800, John Baldwin wrote: > > On 22-Jan-01 Donald J . Maddox wrote: > > > > 1) rm -r /usr/include; cd /usr/src; make includes > > I just do 'make includes' w/o the rm of /usr/include when I do this.. I used to do 'make -DCLOBBER includes' to make sure no old stuff survived, but somebody decided that was just too convenient, I guess. No CLOBBER in the Makefiles anymore... > This should work, except that buildkernel has a few problems: > > 1) It (ab)uses the KERNEL make variable so that it now has 2 conflicting > meanings. Simply using KERNCONF for the buildkernel case instead can fix this, > however. > > 2) It hides the output from config(8). config(8) prints out all sorts of > useful warnings when options are deprecated, etc., but buildkernel hides these > from the user. The problem is that config(8) is by design an interactive tool, > which buildkernel fails to take into account. The hack now is to have > config(8) treat warnings as errors instead. :-/ I think this is a good policy :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:47:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 401BE37B401; Sun, 21 Jan 2001 23:46:57 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0M7ku906193; Mon, 22 Jan 2001 00:46:56 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101220746.f0M7ku906193@harmony.village.org> To: John Baldwin Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: "Donald J . Maddox" , Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Sun, 21 Jan 2001 23:35:49 PST." References: Date: Mon, 22 Jan 2001 00:46:56 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : 2) It hides the output from config(8). config(8) prints out all sorts of : useful warnings when options are deprecated, etc., but buildkernel hides these : from the user. The problem is that config(8) is by design an interactive tool, : which buildkernel fails to take into account. The hack now is to have : config(8) treat warnings as errors instead. :-/ config is not an interactive tool, any more than the compiler is an interactive tool. buildkernel hiding it from the user is a bug in buildkernel. It should be fixed. You shouldn't throw the baby out with the bath water. buildkernel is a much simplified way of telling people how to build kernels. As someone in the front lines of that game, I can tell you that the support load from that has dropped off quite a bit since we started telling people to use it. If you want to advocate all the steps that make it safe by hand, feel free, but the average user had no need to know them, nor do them by hand. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jan 21 23:50:22 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 182D837B402 for ; Sun, 21 Jan 2001 23:50:02 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0M7nZl13740; Mon, 22 Jan 2001 08:49:35 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: John Hay Cc: current@FreeBSD.ORG Subject: Re: VN bug or pilot error ? In-Reply-To: Your message of "Sat, 22 Jan 2001 09:37:45 +0200." <200101220737.f0M7bjr98421@zibbi.icomtek.csir.co.za> Date: Mon, 22 Jan 2001 08:49:35 +0100 Message-ID: <13738.980149775@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101220737.f0M7bjr98421@zibbi.icomtek.csir.co.za>, John Hay write s: >> >> But while you're at it, migrate to md(4) instead of vn(4), it does >> vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices >> > >So why not change the release process to use md instead of vn, so that >we can make sure it works before vn is axed? I will do, as soon as I have time... -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 0:33: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.cc.u-szeged.hu (sol.cc.u-szeged.hu [160.114.8.24]) by hub.freebsd.org (Postfix) with ESMTP id 369AF37B401 for ; Mon, 22 Jan 2001 00:32:51 -0800 (PST) Received: from petra.hos.u-szeged.hu by sol.cc.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id JAA23144; Mon, 22 Jan 2001 09:32:49 +0100 (MET) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 14KcPD-00008P-00 for ; Mon, 22 Jan 2001 09:32:51 +0100 Date: Mon, 22 Jan 2001 09:32:51 +0100 From: Szilveszter Adam To: freebsd-current@FreeBSD.org Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Message-ID: <20010122093251.B19387@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , freebsd-current@FreeBSD.org References: <20010122022757.B18935@cae88-102-101.sc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Sun, Jan 21, 2001 at 11:35:49PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, On Sun, Jan 21, 2001 at 11:35:49PM -0800, John Baldwin wrote: > I just do 'make includes' w/o the rm of /usr/include when I do this.. > > I normally do this, FWIW: > > 1) make buildworld > 2) make installworld > 3) config FOO > 4) compile kernel FOO > 5) install kernel FOO > 6) update /etc > 7) reboot OK, then I am not the only one left still sticking to the ole' style... which has always worked for me BTW... although this is also due to the fact that I read mailing lists, docs, and lately even cvs-all. Which is not true for many -stable users out there... > 2) It hides the output from config(8). config(8) prints out all sorts of > useful warnings when options are deprecated, etc., but buildkernel hides these > from the user. The problem is that config(8) is by design an interactive tool, > which buildkernel fails to take into account. The hack now is to have > config(8) treat warnings as errors instead. :-/ I can second this. Way back when I upgraded from 3.x to 4.x I had to use this method and boy, was I lucky to stare at the screen all while it was running... this way I cought the errors from config(8) that were quickly scrolling by, and buildkernel continued despite of the errors! I broke my personal record for hitting Ctrl-C and so ended this crazy ride, after which config file was fixed and a succesful buildkernel followed. (Yes, I know... using custom kernel config files was not supported during the upgrade... but hey, I knew what I was doing... I even managed to preserve my old config file from 3.3 days by always converting it to new syntax requirements instead of starting over:-) So buildkernel should most deifintely be fixed. But relax, guys. The FreeBSD source upgrade system is still the most robust of any OS I saw out there, including all the other BSDs. Eg you cannot normally upgrade between releases because they are not prepared for those extra steps our buildworld does wrt the toolchain. (You have to rebuild gcc by hand etc.) Keep up the good work! -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 0:35: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id 4BE9737B401 for ; Mon, 22 Jan 2001 00:34:51 -0800 (PST) Received: (qmail 947 invoked by uid 100); 22 Jan 2001 08:34:50 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14955.61610.500089.727096@guru.mired.org> Date: Mon, 22 Jan 2001 02:34:50 -0600 (CST) To: Poul-Henning Kamp Cc: Thierry Herbelot , Peter Jeremy , current@FreeBSD.ORG Subject: Re: VN bug or pilot error ? In-Reply-To: <13139.980144846@critter> References: <3A6BD17E.657F2D0@free.fr> <13139.980144846@critter> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp types: > But while you're at it, migrate to md(4) instead of vn(4), it does > vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices How close is the md rewrite to being able to replace mfs? Thanxm Poul-Henning > > > In message <3A6BD17E.657F2D0@free.fr>, Thierry Herbelot writes: > >thanks a lot : that was it ! > > > >Peter Jeremy wrote: > >> > >> On 2001-Jan-21 10:15:22 +0100, Thierry Herbelot wrote: > >> >I've got a recent current (cvsuped and rebuilt yesterday) on a laptop > >> >and I can't use the vn(4) pseudo-driver : I've compiled it in the kernel > >> >and I've also tried to kldload vn.ko, but I get consistently "vn0c : > >> >device not configured" when I try to use it to mount a locally stored > >> >iso image. > >> > >> Change "vn0c" to "vn0". I believe this is the result of PHK's change > >> in mid-December which added cloning to vn. > >> > >> Peter > > > >-- > >Thierry Herbelot > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-current" in the body of the message > > > > -- > 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. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > -- Mike Meyer http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 0:43:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id D7E1D37B401; Mon, 22 Jan 2001 00:42:52 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0M8gqk14036; Mon, 22 Jan 2001 00:42:52 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101220842.f0M8gqk14036@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: John Baldwin , "Donald J . Maddox" , freebsd-current@FreeBSD.org, The Hermit Hacker Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) In-Reply-To: <20010122022757.B18935@cae88-102-101.sc.rr.com> Date: Mon, 22 Jan 2001 00:42:52 -0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Donald J . Maddox" wrote: > Ok, fair enough. I have to confess that my usual procedure remains, > as it has been for a long time, like this: > > 1) rm -r /usr/include; cd /usr/src; make includes > > This may be controversial, but it has always worked for me, and although > it's not supposed to (in my understanding), the build (I think both world > and kernel) does use installed headers. If you don't think so, mv > /usr/include and then try to build either. > > 2) cd usr.sbin/config; make obj && make depend && make && make install > > 3) config and build kernel > > 4) make buildworld > > 5) install kernel > > 6) make installworld > > 7) update /etc if necessary > > 8) reboot > > Here lately, I have been trying to break this cycle and use the > > 1) make buildworld > > 2) make buildkernel > > 3) make installkernel > > 4) make installworld Here is where you are going wrong.. You reboot before doing an installworld because you can boot kernel.old real easy, but you cannot undo an installworld. > 5) reboot > > cycle instead, since I have been assured that this is the canonical > way of doing things now. It appears that these pronouncements were > premature at best. The optimal way always has been and still is: update config if required build kernel install, reboot. check out your kernel. Make sure it is basically functional. If so, then: make buildworld # a stress test for the kernel you just built. If and only if the buildworld lives, do an installworld. *never never never* install a world before the kernel, you cannot back out of it if the kernel is unstable. This is especially important in -current with the SMPng work going on. If your new kernel cannot build a world, then you *dont want to run it* and go back to kernel.old. There is no installworld.old to roll back to. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 0:47:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 040D537B698; Mon, 22 Jan 2001 00:47:17 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0M8l8k14115; Mon, 22 Jan 2001 00:47:08 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101220847.f0M8l8k14115@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Warner Losh Cc: John Baldwin , "Donald J . Maddox" , The Hermit Hacker , freebsd-current@FreeBSD.ORG Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) In-Reply-To: <200101220746.f0M7ku906193@harmony.village.org> Date: Mon, 22 Jan 2001 00:47:08 -0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message John Baldwin writes: > : 2) It hides the output from config(8). config(8) prints out all sorts of > : useful warnings when options are deprecated, etc., but buildkernel hides th ese > : from the user. The problem is that config(8) is by design an interactive t ool, > : which buildkernel fails to take into account. The hack now is to have > : config(8) treat warnings as errors instead. :-/ > > config is not an interactive tool, any more than the compiler is an > interactive tool. Config is *loaded* with places where it does not return an error code if something is wrong. This is a recipe for disaster by automating it so that people can do a 'make buildkernel' and switch to a different vty/window and never see that there were 30000 parse errors in their kernel config file. That is the fundamental problem. I've started converting the notices in config(8) to fatal errors that I hope buildkernel will pick up, but it is IMHO still wrong, especially for -current that is changing on a daily basis. -stable is a different story, but this is outright deadly for -current. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 0:50:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 218A537B402 for ; Mon, 22 Jan 2001 00:50:06 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0M8nql13993; Mon, 22 Jan 2001 09:49:52 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Mike Meyer Cc: Thierry Herbelot , Peter Jeremy , current@FreeBSD.ORG Subject: Re: VN bug or pilot error ? In-Reply-To: Your message of "Mon, 22 Jan 2001 02:34:50 CST." <14955.61610.500089.727096@guru.mired.org> Date: Mon, 22 Jan 2001 09:49:52 +0100 Message-ID: <13991.980153392@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14955.61610.500089.727096@guru.mired.org>, Mike Meyer writes: >Poul-Henning Kamp types: >> But while you're at it, migrate to md(4) instead of vn(4), it does >> vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices > >How close is the md rewrite to being able to replace mfs? Well, it can, but it is still not obviously better than mfs. see mdconfig(8) A real vmfs or tmpfs is more complicated. -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 2:26: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from wop21.wop.wtb.tue.nl (wop21.wop.wtb.tue.nl [131.155.56.216]) by hub.freebsd.org (Postfix) with ESMTP id F23FD37B400 for ; Mon, 22 Jan 2001 02:25:43 -0800 (PST) Received: (from karelj@localhost) by wop21.wop.wtb.tue.nl (8.11.1/8.11.1) id f0MAP4577825; Mon, 22 Jan 2001 11:25:04 +0100 (CET) (envelope-from karelj) Date: Mon, 22 Jan 2001 11:22:45 +0100 From: "Karel J. Bosschaart" To: Chris Cc: David Syphers , current@FreeBSD.ORG Subject: Re: XFree86 4.0.2 Message-ID: <20010122112245.A77620@wop21.wop.wtb.tue.nl> Reply-To: K.J.Bosschaart@wtb.tue.nl References: <4.3.2.7.2.20010121013438.00ba9100@nsit-popmail.uchicago.edu> <20010121023208.A63679@citusc17.usc.edu> <3A6B3D84.58831A5@137.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A6B3D84.58831A5@137.org>; from cc@137.org on Sun, Jan 21, 2001 at 01:50:28PM -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 21, 2001 at 01:50:28PM -0600, Chris wrote: > > If you are currently running 4.0.1, I would seriously recommend skipping > this > minor revision. I have run into a multitude of problems with it, and am now > back right where I started. > > One, is the lack of DRM support for the matrox cards anymore. The kernel > module has a version number in it, which is less than that required by the > DRM system. > At the moment I'm using XFree86-4.0.2_5 with Matrox G400 and DRM, on 4.2-STABLE. I could get the correct DRM module version compiled thanks to a bunch of patches that someone has sent me. Occasionally things lock up and I need to restart remotely (killing -9 the offending process does not help). This happens only when using drm. > It won't insert the module until you update this--so it appears > that no one is actually using it. FYI, http://wop21.wop.wtb.tue.nl/freebsd/hwaccel.html describes how to install drm/G400 with XFree86-4.0.1. I'm getting a few hits a day, so I suppose there is some interest, although the patches are getting only 20 % of the number of hits on the guidelines, which might be more indicative for the people actually trying. > Another, is that there seem to be delays in the event stream, making > interactive performance terrible. One example: When I go to move a window, > I > start dragging it, moving the outline as I go. Then I unclick, yet the > frame > is still visible. I actually have to move the mouse more to get the window > move to take effect. There are other cases, where it appears to lose events > all together--like clicking on windows to raise them, or with menus. > Hmm, I don't have such troubles. Only minor problem I have, besides above mentioned drm related things, is that VMware doesn't correctly use Full Screen mode. Karel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 4:35:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 277D937B400; Mon, 22 Jan 2001 04:35:06 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA03042; Mon, 22 Jan 2001 23:35:00 +1100 Date: Mon, 22 Jan 2001 23:34:54 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: John Baldwin Cc: "Donald J . Maddox" , Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.ORG Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, John Baldwin wrote: > On 22-Jan-01 Donald J . Maddox wrote: > > Ok, fair enough. I have to confess that my usual procedure remains, > > as it has been for a long time, like this: > > > > 1) rm -r /usr/include; cd /usr/src; make includes > > I just do 'make includes' w/o the rm of /usr/include when I do this.. I never do this. `includes' is a private target in Makefile.inc1. Running it at any time except as part of buildworld or installworld may give an inconsistent set of includes. > 1) make buildworld > 2) make installworld > 3) config FOO > 4) compile kernel FOO > 5) install kernel FOO > 6) update /etc > 7) reboot > > 1-5 are all in 2 scripts, and part of 6) is in a script. For building kernels, I normally skip steps 1-2 (update config if necessary) and 6 (even more rarely necessary), and I never use the kernel install rules since they blow away backups and set inconvenient schg flags. > 2) It hides the output from config(8). config(8) prints out all sorts of > useful warnings when options are deprecated, etc., but buildkernel hides these > from the user. The problem is that config(8) is by design an interactive tool, > which buildkernel fails to take into account. The hack now is to have > config(8) treat warnings as errors instead. :-/ Doesn't this break things? The current warnings for LINT are: WARNING: Old ISA driver compatability shims present. WARNING: COMPAT_SVR4 is broken and usage is, until fixed, not recommended Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 6: 9:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 0D6F737B401 for ; Mon, 22 Jan 2001 06:09:25 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id f0ME9GI07562 for current@freebsd.org; Mon, 22 Jan 2001 16:09:16 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200101221409.f0ME9GI07562@zibbi.icomtek.csir.co.za> Subject: vmstat compile errors To: current@freebsd.org Date: Mon, 22 Jan 2001 16:09:16 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is this maybe fallout from the vm_zone changes? ===> usr.bin/vmstat cc -O -pipe -I/usr/src/usr.bin/vmstat/../../sys -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/vmstat/vmstat.c gzip -cn /usr/src/usr.bin/vmstat/vmstat.8 > vmstat.8.gz /usr/src/usr.bin/vmstat/vmstat.c:483: warning: `pgtok' redefined /usr/obj/usr/src/i386/usr/include/machine/param.h:166: warning: this is the location of the previous definition /usr/src/usr.bin/vmstat/vmstat.c: In function `dozmem': /usr/src/usr.bin/vmstat/vmstat.c:907: structure has no member named `znext' *** Error code 1 John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 6:28:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3C87937B699 for ; Mon, 22 Jan 2001 06:28:21 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA08374 for ; Tue, 23 Jan 2001 01:28:18 +1100 Date: Tue, 23 Jan 2001 01:28:11 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: current@freebsd.org Subject: current panics in mount(2) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My nfs server now always panics when it attempts to export ufs filesystems. This is caused by my mount(8) being slightly out of date. This shouldn't be a problem, but `struct export_args' contains a `struct ucred' which contains a `struct mtx', so when `struct mtx' shrunk by 1 pointer yesterday, the out of date mount(8) started supplying garbage for all the export args following the ucred one. FreeBSD does very little checking of the export args and panics in the following malloc() in vfs_hang_addrlist(): i = sizeof(struct netcred) + argp->ex_addrlen + argp->ex_masklen; np = (struct netcred *)malloc(i, M_NETADDR, M_WAITOK | M_ZERO); ISTR a PR about lack of checking of export args. Somehow there were few problems when `struct mtx' was added to `struct ucred'. The critical args were probably usually 0. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 9:40:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4CAE537B404 for ; Mon, 22 Jan 2001 09:40:06 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA39988; Mon, 22 Jan 2001 12:40:00 -0500 (EST) (envelope-from wollman) Date: Mon, 22 Jan 2001 12:40:00 -0500 (EST) From: Garrett Wollman Message-Id: <200101221740.MAA39988@khavrinen.lcs.mit.edu> To: cjclark@alum.mit.edu Cc: current@FreeBSD.ORG Subject: Re: excessive paranoia in syslogd(8)? In-Reply-To: <20010120212039.M10761@rfx-216-196-73-168.users.reflex> References: <20010120224944.I387@bonsai.knology.net> <20010120212039.M10761@rfx-216-196-73-168.users.reflex> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > If you want to or need to use network sockets, > # syslogd -a localhost > Should provide the behavior you want. I.e., no security whatsoever. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 9:42:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 2EECA37B69B for ; Mon, 22 Jan 2001 09:41:50 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id MAA40017; Mon, 22 Jan 2001 12:41:43 -0500 (EST) (envelope-from wollman) Date: Mon, 22 Jan 2001 12:41:43 -0500 (EST) From: Garrett Wollman Message-Id: <200101221741.MAA40017@khavrinen.lcs.mit.edu> To: Will Andrews Cc: current@FreeBSD.ORG Subject: sys/time.h w/ timespec stuff In-Reply-To: <20010121011326.D3002@puck.firepipe.net> References: <20010121011326.D3002@puck.firepipe.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > So now, maybe someone can answer my question: why is timespec _KERNEL? It's not. Some of the namespace pollution associated with it is. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 10:11:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 371F237B401; Mon, 22 Jan 2001 10:11:04 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA40255; Mon, 22 Jan 2001 13:11:03 -0500 (EST) (envelope-from wollman) Date: Mon, 22 Jan 2001 13:11:03 -0500 (EST) From: Garrett Wollman Message-Id: <200101221811.NAA40255@khavrinen.lcs.mit.edu> To: John Baldwin Cc: freebsd-emulation@FreeBSD.ORG, Current Subject: RE: Cannot build emulators/vmware2 In-Reply-To: References: <7mae8kt9xa.wl@waterblue.imgsrc.co.jp> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > work on stable, just do a #ifdef __FreeBSD_version > 4 use selinfo, else use > select.h. Make that: #if __FreeBSD_version >= 500014 #include #else #include #endif -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 10:27:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 106AF37B400 for ; Mon, 22 Jan 2001 10:27:25 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA40361; Mon, 22 Jan 2001 13:27:20 -0500 (EST) (envelope-from wollman) Date: Mon, 22 Jan 2001 13:27:20 -0500 (EST) From: Garrett Wollman Message-Id: <200101221827.NAA40361@khavrinen.lcs.mit.edu> To: Bruce Evans Cc: current@FreeBSD.ORG Subject: current panics in mount(2) In-Reply-To: References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > Somehow there were few problems when `struct mtx' was added to > `struct ucred'. The critical args were probably usually 0. It's a bug that mount(2) uses a bare `struct ucred' and not a well-defined, user-exportable credential structure (like struct cmsgcred used for SCM_CREDS ancillary data). -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 10:47:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 0CE7537B402; Mon, 22 Jan 2001 10:46:20 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f0MIjEa14613; Mon, 22 Jan 2001 20:45:34 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.1/8.9.3) with ESMTP id f0MIjJQ33874; Mon, 22 Jan 2001 20:45:19 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A6C7FBF.251B4C89@FreeBSD.org> Date: Mon, 22 Jan 2001 20:45:19 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: current@FreeBSD.org, sos@FreeBSD.org, nsouch@alcove.fr Subject: [RFC] New features for libvgl Content-Type: multipart/mixed; boundary="------------3933D2980D4C5D0799F56951" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------3933D2980D4C5D0799F56951 Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Hi folks, Now I'm in process of writing a libvgl driver for SDL (almost finished - I'm testing it right now) and found that two handy features are currently missed from the libvgl: ability to query video modes supported by the video hardware and ability to install custom mouse eventhandler. So I extended libvgl attaching patches with this message. I would like that someone review/comment attached patches. Please also note that VGLListModes() part of these patches are not optimal right now (it largely duplicates VGLInit()), so please concentrate on concept rather than on implementation details. Thanks! -Maxim --------------3933D2980D4C5D0799F56951 Content-Type: text/plain; charset=x-user-defined; name="libvgl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libvgl.patch" Index: bitmap.c =================================================================== RCS file: /home/ncvs/src/lib/libvgl/bitmap.c,v retrieving revision 1.6 diff -d -u -r1.6 bitmap.c --- bitmap.c 2001/01/13 11:30:12 1.6 +++ bitmap.c 2001/01/22 18:25:23 @@ -30,6 +30,7 @@ #include #include +#include #include #include "vgl.h" Index: keyboard.c =================================================================== RCS file: /home/ncvs/src/lib/libvgl/keyboard.c,v retrieving revision 1.4 diff -d -u -r1.4 keyboard.c --- keyboard.c 2000/10/08 21:33:46 1.4 +++ keyboard.c 2001/01/22 18:25:23 @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include "vgl.h" Index: main.c =================================================================== RCS file: /home/ncvs/src/lib/libvgl/main.c,v retrieving revision 1.8 diff -d -u -r1.8 main.c --- main.c 2001/01/13 11:30:16 1.8 +++ main.c 2001/01/22 18:25:23 @@ -49,7 +49,7 @@ video_adapter_info_t VGLAdpInfo; byte *VGLBuf; -static int VGLMode; +static int VGLCurModeId; static int VGLOldMode; static size_t VGLBufSize; static byte *VGLMem = MAP_FAILED; @@ -159,6 +159,7 @@ * vi_mem_model specifies the memory model of the current video mode * in -CURRENT. */ + VGLDisplay->PixelBytes = 1; switch (VGLModeInfo.vi_mem_model) { case V_INFO_MM_PLANAR: /* we can handle EGA/VGA planner modes only */ @@ -267,7 +268,7 @@ } } - VGLMode = mode; + VGLCurModeId = mode; VGLCurWindow = 0; VGLDisplay->Xsize = VGLModeInfo.vi_width; @@ -290,9 +291,10 @@ #ifdef LIBVGL_DEBUG fprintf(stderr, "va_line_width:%d\n", VGLAdpInfo.va_line_width); - fprintf(stderr, "VGLXsize:%d, Ysize:%d, VXsize:%d, VYsize:%d\n", + fprintf(stderr, "VGLXsize:%d, Ysize:%d, VXsize:%d, VYsize:%d, Type:%d\n", VGLDisplay->Xsize, VGLDisplay->Ysize, - VGLDisplay->VXsize, VGLDisplay->VYsize); + VGLDisplay->VXsize, VGLDisplay->VYsize, + VGLDisplay->Type); #endif smode.mode = VT_PROCESS; @@ -321,7 +323,7 @@ if (VGLOnDisplay) { ioctl(0, KDENABIO, 0); ioctl(0, KDSETMODE, KD_GRAPHICS); - ioctl(0, VGLMode, 0); + ioctl(0, VGLCurModeId, 0); VGLCurWindow = 0; VGLMem = (byte*)mmap(0, VGLAdpInfo.va_window_size, PROT_READ|PROT_WRITE, MAP_FILE, 0, 0); @@ -547,4 +549,118 @@ #endif return 0; +} + +VGLMode ** +VGLListModes(int depth, int mem_model) +{ + static VGLMode **modes = NULL; + + VGLBitmap *vminfop; + VGLMode **modesp, *modescp; + video_info_t minfo; + int adptype, i, modenum; + + if (modes == NULL) { + modes = malloc(sizeof(VGLMode *) * M_VESA_MODE_MAX); + bzero(modes, sizeof(VGLMode *) * M_VESA_MODE_MAX); + } + modesp = modes; + + for (modenum = 0; modenum < M_VESA_MODE_MAX; modenum++) { + minfo.vi_mode = modenum; + if (ioctl(0, CONS_MODEINFO, &minfo) || ioctl(0, CONS_CURRENT, &adptype)) + continue; + if (minfo.vi_mode != modenum) + continue; + if ((minfo.vi_flags & V_INFO_GRAPHICS) == 0) + continue; + if ((mem_model != -1) && ((minfo.vi_mem_model & mem_model) == 0)) + continue; + if ((depth > 1) && (minfo.vi_depth != depth)) + continue; + + /* reallocf can fail */ + if ((*modesp = reallocf(*modesp, sizeof(VGLMode))) == NULL) + return NULL; + modescp = *modesp; + + vminfop = &(modescp->ModeInfo); + bzero(vminfop, sizeof(VGLBitmap)); + + vminfop->Type = NOBUF; + + vminfop->PixelBytes = 1; /* Good default value */ + switch (minfo.vi_mem_model) { + case V_INFO_MM_PLANAR: + /* we can handle EGA/VGA planar modes only */ + if (!(minfo.vi_depth != 4 || minfo.vi_planes != 4 + || (adptype != KD_EGA && adptype != KD_VGA))) + vminfop->Type = VIDBUF4; + break; + case V_INFO_MM_PACKED: + /* we can do only 256 color packed modes */ + if (minfo.vi_depth == 8) + vminfop->Type = VIDBUF8; + break; + case V_INFO_MM_VGAX: + vminfop->Type = VIDBUF8X; + break; + case V_INFO_MM_DIRECT: + vminfop->PixelBytes = minfo.vi_pixel_size; + switch (vminfop->PixelBytes) { + case 2: + vminfop->Type = VIDBUF16; + break; +#if notyet + case 3: + vminfop->Type = VIDBUF24; + break; +#endif + case 4: + vminfop->Type = VIDBUF32; + break; + default: + break; + } + default: + break; + } + if (vminfop->Type == NOBUF) + continue; + + vminfop->Xsize = minfo.vi_width; + vminfop->Ysize = minfo.vi_height; + modescp->Depth = minfo.vi_depth; + + /* XXX */ + if (minfo.vi_mode >= M_VESA_BASE) + modescp->ModeId = _IO('V', minfo.vi_mode - M_VESA_BASE); + else + modescp->ModeId = _IO('S', minfo.vi_mode); + + /* Sort list */ + for (i = 0; modes + i < modesp ; i++) { + if (modes[i]->ModeInfo.Xsize * modes[i]->ModeInfo.Ysize > + vminfop->Xsize * modes[i]->ModeInfo.Ysize) + continue; + if ((modes[i]->ModeInfo.Xsize * modes[i]->ModeInfo.Ysize == + vminfop->Xsize * vminfop->Ysize) && + (modes[i]->Depth >= modescp->Depth)) + continue; + *modesp = modes[i]; + modes[i] = modescp; + modescp = *modesp; + vminfop = &(modescp->ModeInfo); + } + + modesp++; + } + + if (*modesp != NULL) { + free(*modesp); + *modesp = NULL; + } + + return modes; } Index: mouse.c =================================================================== RCS file: /home/ncvs/src/lib/libvgl/mouse.c,v retrieving revision 1.4 diff -d -u -r1.4 mouse.c --- mouse.c 2000/10/08 21:33:46 1.4 +++ mouse.c 2001/01/22 18:25:28 @@ -89,6 +89,8 @@ static int VGLMouseYpos = 0; static int VGLMouseButtons = 0; +static mouse_handler_t VGLMouseHandler = NULL; + void VGLMousePointerShow() { @@ -161,12 +163,17 @@ { struct mouse_info mouseinfo; + mouseinfo.operation = MOUSE_GETINFO; + ioctl(0, CONS_MOUSECTL, &mouseinfo); + + if (VGLMouseHandler != NULL) { + VGLMouseHandler(mouseinfo); + } + if (VGLMouseFrozen) { VGLMouseFrozen++; return; } - mouseinfo.operation = MOUSE_GETINFO; - ioctl(0, CONS_MOUSECTL, &mouseinfo); if (VGLMouseShown == VGL_MOUSESHOW) VGLMousePointerHide(); VGLMouseXpos = mouseinfo.u.data.x; @@ -281,4 +288,10 @@ if (VGLMouseShown == VGL_MOUSESHOW && !VGLMouseVisible) VGLMousePointerShow(); } +} + +void +VGLSetMouseHandler(mouse_handler_t mousehandler) +{ + VGLMouseHandler = mousehandler; } Index: simple.c =================================================================== RCS file: /home/ncvs/src/lib/libvgl/simple.c,v retrieving revision 1.6 diff -d -u -r1.6 simple.c --- simple.c 2001/01/13 11:30:16 1.6 +++ simple.c 2001/01/22 18:25:28 @@ -29,6 +29,7 @@ */ #include +#include #include #include "vgl.h" Index: text.c =================================================================== RCS file: /home/ncvs/src/lib/libvgl/text.c,v retrieving revision 1.5 diff -d -u -r1.5 text.c --- text.c 2000/10/08 21:33:46 1.5 +++ text.c 2001/01/22 18:25:28 @@ -29,6 +29,7 @@ */ #include +#include #include #include "vgl.h" Index: vgl.h =================================================================== RCS file: /home/ncvs/src/lib/libvgl/vgl.h,v retrieving revision 1.6 diff -d -u -r1.6 vgl.h --- vgl.h 2001/01/13 11:30:17 1.6 +++ vgl.h 2001/01/22 18:25:28 @@ -79,6 +79,15 @@ int (*CallBackFunction)(); } VGLObject; +typedef struct { + int ModeId; + int Depth; + VGLBitmap ModeInfo; +} VGLMode; + +/* Type for the custom mouse handling function */ +typedef void (*mouse_handler_t)(mouse_info_t info); + #define MOUSE_IMG_SIZE 16 #define VGL_MOUSEHIDE 0 #define VGL_MOUSESHOW 1 @@ -117,6 +126,7 @@ int VGLSetVScreenSize(VGLBitmap *object, int VXsize, int VYsize); int VGLPanScreen(VGLBitmap *object, int x, int y); int VGLSetSegment(unsigned int offset); +VGLMode ** VGLListModes(int depth, int mem_model); /* mouse.c */ void VGLMousePointerShow(void); void VGLMousePointerHide(void); @@ -128,6 +138,7 @@ int VGLMouseStatus(int *x, int *y, char *buttons); int VGLMouseFreeze(int x, int y, int width, int hight, byte color); void VGLMouseUnFreeze(void); +void VGLSetMouseHandler(mouse_handler_t mousehandler); /* simple.c */ void VGLSetXY(VGLBitmap *object, int x, int y, u_long color); u_long VGLGetXY(VGLBitmap *object, int x, int y); --------------3933D2980D4C5D0799F56951-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 10:54:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 19EF337B400 for ; Mon, 22 Jan 2001 10:54:10 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0MIs4R25928; Mon, 22 Jan 2001 10:54:04 -0800 (PST) Date: Mon, 22 Jan 2001 10:54:04 -0800 From: Alfred Perlstein To: Garrett Wollman Cc: Bruce Evans , current@FreeBSD.ORG Subject: Re: current panics in mount(2) Message-ID: <20010122105404.F7240@fw.wintelcom.net> References: <200101221827.NAA40361@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101221827.NAA40361@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Mon, Jan 22, 2001 at 01:27:20PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Garrett Wollman [010122 10:27] wrote: > < said: > > > Somehow there were few problems when `struct mtx' was added to > > `struct ucred'. The critical args were probably usually 0. > > It's a bug that mount(2) uses a bare `struct ucred' and not a > well-defined, user-exportable credential structure (like struct > cmsgcred used for SCM_CREDS ancillary data). I looked at fixing this once, but got scared off because of binary compatibility issues. Would 'fixing' mount to use cmsgcred be acceptable? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 11:15: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailbox.gaccomputer.com (w050.z064001143.chi-il.dsl.cnc.net [64.1.143.50]) by hub.freebsd.org (Postfix) with ESMTP id 4779237B402 for ; Mon, 22 Jan 2001 11:14:47 -0800 (PST) Received: from gaccomputer.com ([192.168.2.51]) by mailbox.gaccomputer.com (8.9.3/8.9.3) with ESMTP id NAA25130 for ; Mon, 22 Jan 2001 13:14:40 -0600 (CST) (envelope-from dgobe@gaccomputer.com) Message-ID: <3A6C8759.D214F49@gaccomputer.com> Date: Mon, 22 Jan 2001 13:17:45 -0600 From: David Gobeille X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: Belkin Omniview switch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I recently saw a thread regarding the Belkin KVM switches that had their EEPROM's in the wrong sockets. Can someone please point me to the link that was posted earlier, could not find it in the archives. Please CC me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 11:20: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5A34637B404 for ; Mon, 22 Jan 2001 11:19:51 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0MJJU911542; Mon, 22 Jan 2001 12:19:30 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101221919.f0MJJU911542@harmony.village.org> To: Alfred Perlstein Subject: Re: current panics in mount(2) Cc: Garrett Wollman , Bruce Evans , current@FreeBSD.ORG In-reply-to: Your message of "Mon, 22 Jan 2001 10:54:04 PST." <20010122105404.F7240@fw.wintelcom.net> References: <20010122105404.F7240@fw.wintelcom.net> <200101221827.NAA40361@khavrinen.lcs.mit.edu> Date: Mon, 22 Jan 2001 12:19:30 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010122105404.F7240@fw.wintelcom.net> Alfred Perlstein writes: : I looked at fixing this once, but got scared off because of binary : compatibility issues. Would 'fixing' mount to use cmsgcred be : acceptable? I think so. Right now we have lots of killer, panic inducing binary incompatibilities. One more that doesn't suffer from the panic inducing part would be an excellent idea. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 11:34: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from citusc17.usc.edu (citusc17.usc.edu [128.125.38.177]) by hub.freebsd.org (Postfix) with ESMTP id 8BF4637B402; Mon, 22 Jan 2001 11:33:50 -0800 (PST) Received: (from kris@localhost) by citusc17.usc.edu (8.11.1/8.11.1) id f0MJaf292179; Mon, 22 Jan 2001 11:36:41 -0800 (PST) (envelope-from kris) Date: Mon, 22 Jan 2001 11:36:41 -0800 From: Kris Kennaway To: John Baldwin Cc: "Donald J . Maddox" , freebsd-current@FreeBSD.ORG, The Hermit Hacker , Peter Wemm Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Message-ID: <20010122113641.A92053@citusc17.usc.edu> References: <20010122015502.A18847@cae88-102-101.sc.rr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Sun, Jan 21, 2001 at 11:12:44PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 21, 2001 at 11:12:44PM -0800, John Baldwin wrote: > Rarely if ever do you need the new tools. The only cases are for a > binutils upgrade that is not backwards compatible (such as the 2.9 > -> 2.10 upgrade), or if you need a newer version of config, which > can be handled by installing config and then building your kernel. > The config(8) changes won't happen in stable, and I don't foresee > anymore drastic buildkernel changes in the future. I agree that developers don't need to use buildkernel because we are mostly capable of doing the manual workarounds on the rare occasions when things need to be done differently. But if you cast your mind back to the many dozens of support messages on -stable and other lists after the binutils upgrade, you will note that users are incapable of following special-case directions even when their mailbox is full of messages repeating them, and they need to have a magic wand which does it for them. That's what buildkernel is supposed to be..whether or not it's broken or can be fixed is a separate question. I never use buildkernel either because I know enough to fix things when they break, but that's not true for Joe Random, and we shouldn't advocate against it to the general user base unless we have a better magic solution. Kris --=20 NOTE: To fetch an updated copy of my GPG key which has not expired, finger kris@FreeBSD.org --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6bIvJWry0BWjoQKURAoILAKCW6ZNyJ1fv5RH8FlQ3aoi/qu/ECACdG3Hp bIGjdP/jJW2xCtHXk4eQkQA= =77g8 -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 11:43:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id A74C837B400 for ; Mon, 22 Jan 2001 11:43:18 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id OAA41036; Mon, 22 Jan 2001 14:43:10 -0500 (EST) (envelope-from wollman) Date: Mon, 22 Jan 2001 14:43:10 -0500 (EST) From: Garrett Wollman Message-Id: <200101221943.OAA41036@khavrinen.lcs.mit.edu> To: Alfred Perlstein Cc: current@FreeBSD.ORG Subject: Re: current panics in mount(2) In-Reply-To: <20010122105404.F7240@fw.wintelcom.net> References: <200101221827.NAA40361@khavrinen.lcs.mit.edu> <20010122105404.F7240@fw.wintelcom.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > I looked at fixing this once, but got scared off because of binary > compatibility issues. Would 'fixing' mount to use cmsgcred be > acceptable? No, it should use a structure appropriately named and designed for its own purpose. (By preference, it should be binary-compatible with 4.x to make upgrades easier in six months' time.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 12: 1:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 986FD37B6A0 for ; Mon, 22 Jan 2001 12:01:22 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0MKGc001040; Mon, 22 Jan 2001 12:16:38 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101222016.f0MKGc001040@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bruce Evans Cc: current@freebsd.org Subject: Re: current panics in mount(2) In-reply-to: Your message of "Tue, 23 Jan 2001 01:28:11 +1100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 12:16:38 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got quite upset about this last time, and I guess it's time to do it again. Folks, *please* stop exporting "pure" kernel structures to userland. Make a sanitisied, versioned structure and just copy your damn args back and forth. 'struct ucred' should probably never have been exported to userspace, and it *certainly* never should have been exported to userpsace with a mutex in it! I also asked the perpetrator of this error to do something about it following the last debacle it caused. In the meantime, perhaps we could ask that one of the SMPng rules of engagement mandate that no mutex structures or structure members should ever be exported as part of a userspace interface? > My nfs server now always panics when it attempts to export ufs > filesystems. This is caused by my mount(8) being slightly out of > date. This shouldn't be a problem, but `struct export_args' contains > a `struct ucred' which contains a `struct mtx', so when `struct mtx' > shrunk by 1 pointer yesterday, the out of date mount(8) started > supplying garbage for all the export args following the ucred one. > FreeBSD does very little checking of the export args and panics in > the following malloc() in vfs_hang_addrlist(): > > i = sizeof(struct netcred) + argp->ex_addrlen + argp->ex_masklen; > np = (struct netcred *)malloc(i, M_NETADDR, M_WAITOK | M_ZERO); > > ISTR a PR about lack of checking of export args. > > Somehow there were few problems when `struct mtx' was added to > `struct ucred'. The critical args were probably usually 0. > > Bruce > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 12:14:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5087537B6A6; Mon, 22 Jan 2001 12:14:10 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0MKE9911943; Mon, 22 Jan 2001 13:14:09 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101222014.f0MKE9911943@harmony.village.org> To: Kris Kennaway Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: John Baldwin , "Donald J . Maddox" , freebsd-current@FreeBSD.ORG, The Hermit Hacker , Peter Wemm In-reply-to: Your message of "Mon, 22 Jan 2001 11:36:41 PST." <20010122113641.A92053@citusc17.usc.edu> References: <20010122113641.A92053@citusc17.usc.edu> <20010122015502.A18847@cae88-102-101.sc.rr.com> Date: Mon, 22 Jan 2001 13:14:09 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010122113641.A92053@citusc17.usc.edu> Kris Kennaway writes: : I agree that developers don't need to use buildkernel because we are : mostly capable of doing the manual workarounds on the rare occasions : when things need to be done differently. But if you cast your mind : back to the many dozens of support messages on -stable and other lists : after the binutils upgrade, you will note that users are incapable of : following special-case directions even when their mailbox is full of : messages repeating them, and they need to have a magic wand which does : it for them. That's what buildkernel is supposed to be..whether or not : it's broken or can be fixed is a separate question. : : I never use buildkernel either because I know enough to fix things : when they break, but that's not true for Joe Random, and we shouldn't : advocate against it to the general user base unless we have a better : magic solution. Agreed. It *IS* the documented way of building kernels. It is in the handbook and we've been recommending it for over a year. If it is broken in some way, we should fix the way in which it is broken. Kris is right, most normal users can't follow directions more complex than make buildkernel. I've spent my time in the trenches, as have others which is why make buildkernel exists. Believe us when we tell you this. We had litterally a dozen questions each week about this before buildkernel. Now we have almost none (maybe 2-3 a month for people not using buildkernel, or whacked out cases where buildkernel was done without a buildworld immediately before it). If you don't like it, don't use it. If it is broken, fix it, or tell others how to fix it. Personally, I use it here from time to time to test things, but when I'm in a development cycle, I'm more likely to use the old way because I know enough to know what body part I'm about to shoot off... It is in the handbook, and has been for some time. I'm reviewing the recent KERNEL -> KERNCONF changes to make sure that they make it into the handbook properly (I assume there will be a MFC in a few days, since putting KERNEL in /etc/make.conf is a setup for disaster right now). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 12:46:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id B858337B6A7 for ; Mon, 22 Jan 2001 12:46:12 -0800 (PST) Received: (qmail 21927 invoked by uid 100); 22 Jan 2001 20:46:11 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14956.39955.318792.388889@guru.mired.org> Date: Mon, 22 Jan 2001 14:46:11 -0600 (CST) To: Warner Losh Cc: Kris Kennaway , John Baldwin , "Donald J . Maddox" , freebsd-current@FreeBSD.ORG, The Hermit Hacker , Peter Wemm Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) In-Reply-To: <200101222014.f0MKE9911943@harmony.village.org> References: <20010122113641.A92053@citusc17.usc.edu> <20010122015502.A18847@cae88-102-101.sc.rr.com> <200101222014.f0MKE9911943@harmony.village.org> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh types: > It is in the handbook, and has been for some time. I'm reviewing the > recent KERNEL -> KERNCONF changes to make sure that they make it into > the handbook properly (I assume there will be a MFC in a few days, > since putting KERNEL in /etc/make.conf is a setup for disaster right > now). Could you also make sure it makes it into /etc/defaults/make.conf (KERNEL isn't mentioned there at all) and make.conf(5)? Thanx, http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 12:47:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from akira.wossname.net (ct389270-a.lafayt1.in.home.com [24.19.33.26]) by hub.freebsd.org (Postfix) with ESMTP id 9E98437B402; Mon, 22 Jan 2001 12:46:51 -0800 (PST) Received: from akira.wossname.net (localhost.wossname.net [127.0.0.1]) by akira.wossname.net (Postfix) with ESMTP id A372B709C; Mon, 22 Jan 2001 15:46:51 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Robert Watson Cc: current@FreeBSD.org Subject: Re: Building -STABLE on -CURRENT In-reply-to: Your message of "Sat, 13 Jan 2001 00:00:53 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 15:46:51 -0500 From: Benjamin Lewis Message-Id: <20010122204651.A372B709C@akira.wossname.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert, You wrote: > For the last few days (not sure when it started) I've been unable to build > -STABLE on a -CURRENT machine. This has proven a problem for recent > RELENG_3 MFC's of security fixes; I've tried upgrading to the most recent > -CURRENT on the box, making sure /usr/include is updated, et al. I'm > guessing this is /usr/include pollution in the /usr/src build, but won't > speculate too much more as I'm travelling tomorrow. Attached below is the > breakage from buildworld. [...] > > cd /usr/src/share/syscons/scrnmaps; make build-tools > cc -static -O -pipe -I/usr/src/share/syscons/scrnmaps > -DFIL=\"koi8-r2cp866\" > -o koi8-r2cp866.mk /usr/src/share/syscons/scrnmaps/mkscrfil.c > In file included from /usr/src/share/syscons/scrnmaps/mkscrfil.c:28: > /usr/include/machine/console.h:3: #error "this file includes > > which is deprecated, use instead" I've seen the same thing. I hacked up the -stable source to include the correct -current include files to get past this, but that strikes me as extremely non-optimal. I tried hacking up the Makefile in /usr/src/share/syscons/scrnmaps to use a different include path, but don't have the know-how or mojo to get that working. Have you had any replies to this message or further insights? If so, I'd very much appreciate hearing them. Thank you, -Ben To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 12:50:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 969BB37B402; Mon, 22 Jan 2001 12:49:59 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0MKnv912117; Mon, 22 Jan 2001 13:49:57 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101222049.f0MKnv912117@harmony.village.org> To: Mike Meyer Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: Kris Kennaway , John Baldwin , "Donald J . Maddox" , freebsd-current@FreeBSD.ORG, The Hermit Hacker , Peter Wemm In-reply-to: Your message of "Mon, 22 Jan 2001 14:46:11 CST." <14956.39955.318792.388889@guru.mired.org> References: <14956.39955.318792.388889@guru.mired.org> <20010122113641.A92053@citusc17.usc.edu> <20010122015502.A18847@cae88-102-101.sc.rr.com> <200101222014.f0MKE9911943@harmony.village.org> Date: Mon, 22 Jan 2001 13:49:57 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14956.39955.318792.388889@guru.mired.org> Mike Meyer writes: : Warner Losh types: : > It is in the handbook, and has been for some time. I'm reviewing the : > recent KERNEL -> KERNCONF changes to make sure that they make it into : > the handbook properly (I assume there will be a MFC in a few days, : > since putting KERNEL in /etc/make.conf is a setup for disaster right : > now). : : Could you also make sure it makes it into /etc/defaults/make.conf : (KERNEL isn't mentioned there at all) and make.conf(5)? That's really Peter's job since he made the change without any lead time at all to resolve issues like this. I'll see what I can do to backstop things, but it really isn't my baby. When people change things that have impact in different parts of the whole tree, they should be the ones to make the changes to those different parts of the tree, or at least submit patches to the maintainers of those parts of the tree. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 13:35: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 6458937B69D; Mon, 22 Jan 2001 13:34:44 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0MLYfx01360; Mon, 22 Jan 2001 13:34:41 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0MLYHc10701; Mon, 22 Jan 2001 13:34:17 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200101222049.f0MKnv912117@harmony.village.org> Date: Mon, 22 Jan 2001 13:34:17 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Warner Losh Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.ORG, "Donald J . Maddox" , Kris Kennaway , Mike Meyer Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Jan-01 Warner Losh wrote: > In message <14956.39955.318792.388889@guru.mired.org> Mike Meyer writes: >: Warner Losh types: >: > It is in the handbook, and has been for some time. I'm reviewing the >: > recent KERNEL -> KERNCONF changes to make sure that they make it into >: > the handbook properly (I assume there will be a MFC in a few days, >: > since putting KERNEL in /etc/make.conf is a setup for disaster right >: > now). >: >: Could you also make sure it makes it into /etc/defaults/make.conf >: (KERNEL isn't mentioned there at all) and make.conf(5)? > > That's really Peter's job since he made the change without any lead > time at all to resolve issues like this. I'll see what I can do to > backstop things, but it really isn't my baby. When people change > things that have impact in different parts of the whole tree, they > should be the ones to make the changes to those different parts of the > tree, or at least submit patches to the maintainers of those parts of > the tree. Erm, if it wasn't documented in the first place, making a change doesn't put the burden of documenting the old behavior on the person making the change. Are there any kernel manpages for all of the oldcard and newcard API's floating around btw? (As an example.) I agree it should be documented, but just because Peter made the change doesn't mean that the onus that the people who originally did buildkernel didn't bother to document it in places like make.conf(5) should fall on Peter. > Warner -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 13:42:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id DF20437B6A0 for ; Mon, 22 Jan 2001 13:42:31 -0800 (PST) Received: (qmail 23917 invoked by uid 100); 22 Jan 2001 21:42:31 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14956.43335.171799.155466@guru.mired.org> Date: Mon, 22 Jan 2001 15:42:31 -0600 (CST) To: John Baldwin Cc: Warner Losh , Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.ORG, "Donald J . Maddox" Kris Kennaway , Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) In-Reply-To: References: <200101222049.f0MKnv912117@harmony.village.org> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin types: > > On 22-Jan-01 Warner Losh wrote: > > In message <14956.39955.318792.388889@guru.mired.org> Mike Meyer writes: > >: Warner Losh types: > >: > It is in the handbook, and has been for some time. I'm reviewing the > >: > recent KERNEL -> KERNCONF changes to make sure that they make it into > >: > the handbook properly (I assume there will be a MFC in a few days, > >: > since putting KERNEL in /etc/make.conf is a setup for disaster right > >: > now). > >: > >: Could you also make sure it makes it into /etc/defaults/make.conf > >: (KERNEL isn't mentioned there at all) and make.conf(5)? > > > > That's really Peter's job since he made the change without any lead > > time at all to resolve issues like this. I'll see what I can do to > > backstop things, but it really isn't my baby. When people change > > things that have impact in different parts of the whole tree, they > > should be the ones to make the changes to those different parts of the > > tree, or at least submit patches to the maintainers of those parts of > > the tree. > Erm, if it wasn't documented in the first place, making a change doesn't > put the burden of documenting the old behavior on the person making the change. > Are there any kernel manpages for all of the oldcard and newcard API's floating > around btw? (As an example.) I agree it should be documented, but just > because Peter made the change doesn't mean that the onus that the people who > originally did buildkernel didn't bother to document it in places like > make.conf(5) should fall on Peter. KERNEL is documented in make.conf(5), but not in /etc/defaults/make.conf. Since the only thing in the latter that's anything other than a comment is BDECFLAGS, I suggested nuking most of /etc/defaults/make.conf and putting in a pointer to make.conf(5). That way, this stuff only needs to be documented in one place. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 13:43:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailgate.trb.co.uk (mailgate.trb.co.uk [212.113.19.67]) by hub.freebsd.org (Postfix) with SMTP id CB8DD37B69F for ; Mon, 22 Jan 2001 13:43:00 -0800 (PST) Received: from mx19.newsalesjob.net (1Cust253.tnt12.det3.da.uu.net [63.27.69.253]) by mailgate.trb.co.uk; Sat, 13 Jan 2001 13:16:53 +0000 Subject: OPTIMIZE WINDOWS X-Mailer: Mozilla 4.7 [en] (Win95; U) Cc: current@home.com, current@home.com, current@home.com, current@home.com, current@home.com, current@home.com Message-Id: Date: Sat, 13 Jan 2001 08:21:11 -0500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT To: $user@home.com From: info2182407@mindsprings.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG untitled

Dear PC User,

Now you can make Windows 95 and 98 almost as dependable as
Windows NT/2000, Microsoft's professional version of Windows.

A new software product is available to very effectively improve the
reliability
of Windows. It lets Windows quickly repair itself when necessary, and is
completely safe because it operates independent of Windows.

CLICK HERE to find out more about this safe and effective new way to keep
your PC working uninterrupted.


CLICK HERE

----------------------------------
This letter is being sent to PC users who requested to be advised of new
developments in Windows software. To be taken off this mailing list, visit
the Email us page.CLICK HERE
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 14:22: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 9411E37B402 for ; Mon, 22 Jan 2001 14:21:52 -0800 (PST) Received: (qmail 95113 invoked by uid 1142); 22 Jan 2001 22:21:51 -0000 Date: 22 Jan 2001 14:21:51 -0800 Date: Mon, 22 Jan 2001 12:42:05 -0800 From: Jason Evans To: Mike Smith Cc: current@freebsd.org Subject: Re: current panics in mount(2) Message-ID: <20010122124205.D69199@canonware.com> References: <200101222016.f0MKGc001040@mass.dis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101222016.f0MKGc001040@mass.dis.org>; from msmith@freebsd.org on Mon, Jan 22, 2001 at 12:16:38PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 12:16:38PM -0800, Mike Smith wrote: > In the meantime, perhaps we could > ask that one of the SMPng rules of engagement mandate that no mutex > structures or structure members should ever be exported as part of a > userspace interface? This sounds fine in principle, but the real problem is that kernel structures are exported. In order for us to fix some of the places where structures are exported and an embedded mutex becomes necessary, we would have to go out of our way to fix an existing design flaw. Under normal circumstances, I would agree with you that broken code should be fixed as it is modified. However, the amount of work that the SMPng project is already taking on is overwhelming. Placing this additional burden on the SMPng developers would in my opinion be detrimental to the medium-term success of the project. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 14:28:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 5F80B37B401 for ; Mon, 22 Jan 2001 14:28:31 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.1/8.11.1) with ESMTP id f0MMSRk03471; Mon, 22 Jan 2001 14:28:27 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.1/8.11.0) id f0MMSQA21556; Mon, 22 Jan 2001 14:28:26 -0800 (PST) (envelope-from jdp) Date: Mon, 22 Jan 2001 14:28:26 -0800 (PST) Message-Id: <200101222228.f0MMSQA21556@vashon.polstra.com> To: current@freebsd.org From: John Polstra Cc: dgobe@gaccomputer.com Subject: Re: Belkin Omniview switch In-Reply-To: <3A6C8759.D214F49@gaccomputer.com> References: <3A6C8759.D214F49@gaccomputer.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <3A6C8759.D214F49@gaccomputer.com>, David Gobeille wrote: > I recently saw a thread regarding the Belkin KVM switches that had their > EEPROM's in the wrong sockets. > > Can someone please point me to the link that was posted earlier, > could not find it in the archives. http://www.belkin.com/support/downloads/manuals/Omnipro.pdf John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:12:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id BFF9D37B6B8; Mon, 22 Jan 2001 15:12:20 -0800 (PST) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CX5HR0CC; Mon, 22 Jan 2001 18:12:20 -0500 Reply-To: Randell Jesup To: current@FreeBSD.ORG Cc: stable@FreeBSD.ORG Subject: Re: sysinstall.8 Breaking buildworld References: <20010111220021.C79365@strontium.scientia.demon.co.uk> <20010111174332.B74480@dragon.nuxi.com> From: Randell Jesup Date: 22 Jan 2001 18:15:24 -0500 In-Reply-To: "David O'Brien"'s message of "Thu, 11 Jan 2001 17:43:32 -0800" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "David O'Brien" writes: >On Thu, Jan 11, 2001 at 02:38:55PM -0800, John Baldwin wrote: >> Erm, sysinstall can be used as a replacement for fdisk and disklabel, >> both of which are in /sbin. In fact, in 4.2 the only tool you can >> realistically use to splat a virgin disklabel onto a slice w/o weird >> hoop jumping that isn't documented _is_ sysinstall. disklabel should >> have that fixed by 4.3, however. > >But disklabel/fdisk can't even accept MB's as a unit. Until they grow >the functionality of the NetBSD and OpenBSD versions of them, sysinstall >is really the only tolerable disk label manipulation tool our users have. >This includes those with a bummed /usr that needs to install a new disk >to get it back. A full set of disklabel patches to support MB, GB, KB, %, and * (everything not spoken for elsewhere) for sizes (and * for offsets to allow disklabel to calculate them for you), etc are in Warner's hands. (I got annoyed at it one evening...) Now, if Warner would commit them.... :-) (Matt has looked at the patch also.) They also have improved error checking, etc. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:25:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 9877937B6CF; Mon, 22 Jan 2001 15:25:12 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0MNPA913286; Mon, 22 Jan 2001 16:25:10 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101222325.f0MNPA913286@harmony.village.org> To: John Baldwin Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.ORG, "Donald J . Maddox" , Kris Kennaway , Mike Meyer In-reply-to: Your message of "Mon, 22 Jan 2001 13:34:17 PST." References: Date: Mon, 22 Jan 2001 16:25:10 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : : On 22-Jan-01 Warner Losh wrote: : > In message <14956.39955.318792.388889@guru.mired.org> Mike Meyer writes: : >: Warner Losh types: : >: > It is in the handbook, and has been for some time. I'm reviewing the : >: > recent KERNEL -> KERNCONF changes to make sure that they make it into : >: > the handbook properly (I assume there will be a MFC in a few days, : >: > since putting KERNEL in /etc/make.conf is a setup for disaster right : >: > now). : >: : >: Could you also make sure it makes it into /etc/defaults/make.conf : >: (KERNEL isn't mentioned there at all) and make.conf(5)? : > : > That's really Peter's job since he made the change without any lead : > time at all to resolve issues like this. I'll see what I can do to : > backstop things, but it really isn't my baby. When people change : > things that have impact in different parts of the whole tree, they : > should be the ones to make the changes to those different parts of the : > tree, or at least submit patches to the maintainers of those parts of : > the tree. : : Erm, if it wasn't documented in the first place, making a change doesn't : put the burden of documenting the old behavior on the person making the change. It was in the handbook, explicitly documented. Nothing undocumented about it. If I were to change how ls worked in some way, I'd be exepcted to update the man page for ls. This is no different than that. This is the documented way to build kernels, see http://www.freebsd.org/handbook/kernelconfig-building.html for the current instructions. They have been in there since at least 1.29 (alex 15-Jul-00): &prompt.root; make... 1.29 (alex 15-Jul-00): &prompt.root; make... when alex added them. That's at least 6 months ago. They have been in UPDATING longer than that. : Are there any kernel manpages for all of the oldcard and newcard API's floating : around btw? (As an example.) Neither have ever been documented. Eventually newcard will be documented. However, that's fundamentally different. We have maybe 5 NEWCARD folks hacking drivers right now. We have easily 50,000 folks running current, following the previously published instructions which are now inaccurate. Fortunatley, the change is now in UPDATING. : I agree it should be documented, but just : because Peter made the change doesn't mean that the onus that the people who : originally did buildkernel didn't bother to document it in places like : make.conf(5) should fall on Peter. I disagree. Peter made a fairly major change that needs many documentation changes to document the change. Yes, it was a small change, but it is how we are telling people to build things in the handbook. Fortunately the doc changes are relatively easy to make. Warner P.S. The following should do the trick: Index: chapter.sgml =================================================================== RCS file: /home/imp/FreeBSD/CVS/doc/en_US.ISO_8859-1/books/handbook/kernelconfig/chapter.sgml,v retrieving revision 1.36 diff -u -r1.36 chapter.sgml --- chapter.sgml 2000/08/10 02:09:18 1.36 +++ chapter.sgml 2001/01/22 23:20:48 @@ -167,8 +167,8 @@ following commands: &prompt.root; cd /usr/src -&prompt.root; make buildkernel KERNEL=MYKERNEL -&prompt.root; make installkernel KERNEL=MYKERNEL +&prompt.root; make buildkernel KERNCONF=MYKERNEL +&prompt.root; make installkernel KERNCONF=MYKERNEL If you have not upgraded your source tree in any way (you have not run CVSup, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:32:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 5AB3337B404 for ; Mon, 22 Jan 2001 15:31:53 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA08514 for ; Mon, 22 Jan 2001 15:31:53 -0800 Date: Mon, 22 Jan 2001 15:31:52 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: current@freebsd.org Subject: a panic from recent changes... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Debugger("panic") Stopped at Debugger+0x44: pushl %ebx db> t Debugger(c02b8303) at Debugger+0x44 panic(c02c9040,bfc00000,581000,c02ea620,c030ab0c) at panic+0x70 kmem_malloc(c0312d20,bfc00000,8,bfbff810,c8dddd98) at kmem_malloc+0xd7 malloc(bfbff810,c02ea620,8,c0ff1e00,c8dddd98) at malloc+0x248 vfs_hang_addrlist(c0ff1e00,c0feac6c,c8dddd98,c0ff5000,c80c9f00) at vfs_hang_addrlist+0x8f vfs_export(c0ff1e00,c0feac6c,c8dddd98,4,c0ff1e00) at vfs_export+0x61 ffs_mount(c0ff1e00,809f0b0,bfbff6b8,c8ddde9c,c7add980) at ffs_mount+0x3ee mount(c7add980,c8dddf80,809f0b1,0,0) at mount+0x5e7 syscall2(2f,2f,2f,0,0) at syscall2+0x285 Xint0x80_syscall() at Xint0x80_syscall+0x23 --- syscall 0x15, eip = 0x804f51c, esp = 0xbfbff684, ebp = 0xbfbff780 --- mountd exporting stuff causes a panic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:36:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 1875A37B404 for ; Mon, 22 Jan 2001 15:35:52 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0MNZob06139; Mon, 22 Jan 2001 15:35:50 -0800 (PST) Date: Mon, 22 Jan 2001 15:35:50 -0800 From: Alfred Perlstein To: Matthew Jacob Cc: current@FreeBSD.ORG Subject: Re: a panic from recent changes... Message-ID: <20010122153549.G26076@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Mon, Jan 22, 2001 at 03:31:52PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matthew Jacob [010122 15:32] wrote: > > Debugger("panic") > Stopped at Debugger+0x44: pushl %ebx > db> t > Debugger(c02b8303) at Debugger+0x44 > panic(c02c9040,bfc00000,581000,c02ea620,c030ab0c) at panic+0x70 > kmem_malloc(c0312d20,bfc00000,8,bfbff810,c8dddd98) at kmem_malloc+0xd7 > malloc(bfbff810,c02ea620,8,c0ff1e00,c8dddd98) at malloc+0x248 > vfs_hang_addrlist(c0ff1e00,c0feac6c,c8dddd98,c0ff5000,c80c9f00) at > vfs_hang_addrlist+0x8f > vfs_export(c0ff1e00,c0feac6c,c8dddd98,4,c0ff1e00) at vfs_export+0x61 > ffs_mount(c0ff1e00,809f0b0,bfbff6b8,c8ddde9c,c7add980) at ffs_mount+0x3ee > mount(c7add980,c8dddf80,809f0b1,0,0) at mount+0x5e7 > syscall2(2f,2f,2f,0,0) at syscall2+0x285 > Xint0x80_syscall() at Xint0x80_syscall+0x23 > --- syscall 0x15, eip = 0x804f51c, esp = 0xbfbff684, ebp = 0xbfbff780 --- > > mountd exporting stuff causes a panic. This is and isn't my fault, struct ucred needs a lock for refcounts. Since mount uses ucreds in userspace and passes them to the kernel we have a issue when struct mtx changes. I'm going to take a shot at removing struct ucred from userland this weekend, but you can have a shot at it if you'd like. The other option is to at least fix mount and friends to use something other than ucred, and slowly remove it (struct ucred) from userland. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:39:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 348E837B404 for ; Mon, 22 Jan 2001 15:39:20 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA08569; Mon, 22 Jan 2001 15:39:19 -0800 Date: Mon, 22 Jan 2001 15:39:18 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Alfred Perlstein Cc: current@FreeBSD.ORG Subject: Re: a panic from recent changes... In-Reply-To: <20010122153549.G26076@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Matthew Jacob [010122 15:32] wrote: > > > > Debugger("panic") > > Stopped at Debugger+0x44: pushl %ebx > > db> t > > Debugger(c02b8303) at Debugger+0x44 > > panic(c02c9040,bfc00000,581000,c02ea620,c030ab0c) at panic+0x70 > > kmem_malloc(c0312d20,bfc00000,8,bfbff810,c8dddd98) at kmem_malloc+0xd7 > > malloc(bfbff810,c02ea620,8,c0ff1e00,c8dddd98) at malloc+0x248 > > vfs_hang_addrlist(c0ff1e00,c0feac6c,c8dddd98,c0ff5000,c80c9f00) at > > vfs_hang_addrlist+0x8f > > vfs_export(c0ff1e00,c0feac6c,c8dddd98,4,c0ff1e00) at vfs_export+0x61 > > ffs_mount(c0ff1e00,809f0b0,bfbff6b8,c8ddde9c,c7add980) at ffs_mount+0x3ee > > mount(c7add980,c8dddf80,809f0b1,0,0) at mount+0x5e7 > > syscall2(2f,2f,2f,0,0) at syscall2+0x285 > > Xint0x80_syscall() at Xint0x80_syscall+0x23 > > --- syscall 0x15, eip = 0x804f51c, esp = 0xbfbff684, ebp = 0xbfbff780 --- > > > > mountd exporting stuff causes a panic. > > This is and isn't my fault, struct ucred needs a lock for refcounts. > Since mount uses ucreds in userspace and passes them to the kernel > we have a issue when struct mtx changes. I'm going to take a shot > at removing struct ucred from userland this weekend, but you can > have a shot at it if you'd like. > > The other option is to at least fix mount and friends to use > something other than ucred, and slowly remove it (struct ucred) > from userland. Well, no, I can live w/o exporting things from a -current box until next week. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:39:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 514ED37B6A0 for ; Mon, 22 Jan 2001 15:39:34 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id PAA08574; Mon, 22 Jan 2001 15:39:33 -0800 Date: Mon, 22 Jan 2001 15:39:33 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Alfred Perlstein Cc: current@FreeBSD.ORG Subject: Re: a panic from recent changes... In-Reply-To: <20010122153549.G26076@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > mountd exporting stuff causes a panic. > > This is and isn't my fault, struct ucred needs a lock for refcounts. > Since mount uses ucreds in userspace and passes them to the kernel > we have a issue when struct mtx changes. I'm going to take a shot > at removing struct ucred from userland this weekend, but you can > have a shot at it if you'd like. > > The other option is to at least fix mount and friends to use > something other than ucred, and slowly remove it (struct ucred) > from userland. > > BTW- thanks for the quick response! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:43:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 038EF37B6A8 for ; Mon, 22 Jan 2001 15:43:21 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0MNwd001891; Mon, 22 Jan 2001 15:58:40 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101222358.f0MNwd001891@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jason Evans Cc: current@freebsd.org Subject: Re: current panics in mount(2) In-reply-to: Your message of "Mon, 22 Jan 2001 12:42:05 PST." <20010122124205.D69199@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jan 2001 15:58:39 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jan 22, 2001 at 12:16:38PM -0800, Mike Smith wrote: > > In the meantime, perhaps we could > > ask that one of the SMPng rules of engagement mandate that no mutex > > structures or structure members should ever be exported as part of a > > userspace interface? > > This sounds fine in principle, but the real problem is that kernel > structures are exported. In order for us to fix some of the places where > structures are exported and an embedded mutex becomes necessary, we would > have to go out of our way to fix an existing design flaw. This would seem to be more or less obvious, yes. > Under normal circumstances, I would agree with you that broken code should > be fixed as it is modified. However, the amount of work that the SMPng > project is already taking on is overwhelming. Placing this additional > burden on the SMPng developers would in my opinion be detrimental to the > medium-term success of the project. I think that the alternative is also fairly undesirable. However, you're in the hot seat on this one, so it's your call. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:44:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 8506C37B6A9; Mon, 22 Jan 2001 15:43:59 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0MNhp913550; Mon, 22 Jan 2001 16:43:57 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101222343.f0MNhp913550@harmony.village.org> To: Mike Meyer Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: John Baldwin , Peter Wemm , The Hermit Hacker , freebsd-current@FreeBSD.ORG, "\"Donald J . Maddox\" Kris Kennaway" In-reply-to: Your message of "Mon, 22 Jan 2001 15:42:31 CST." <14956.43335.171799.155466@guru.mired.org> References: <14956.43335.171799.155466@guru.mired.org> <200101222049.f0MKnv912117@harmony.village.org> Date: Mon, 22 Jan 2001 16:43:51 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14956.43335.171799.155466@guru.mired.org> Mike Meyer writes: : KERNEL is documented in make.conf(5), but not in : /etc/defaults/make.conf. Since the only thing in the latter that's : anything other than a comment is BDECFLAGS, I suggested nuking most of : /etc/defaults/make.conf and putting in a pointer to make.conf(5). That : way, this stuff only needs to be documented in one place. So it is. Something like the following untested change should do the trick. Warner Index: make.conf.5 =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/share/man/man5/make.conf.5,v retrieving revision 1.8 diff -u -r1.8 make.conf.5 --- make.conf.5 2001/01/18 09:42:50 1.8 +++ make.conf.5 2001/01/22 23:43:04 @@ -250,7 +250,7 @@ Optimization levels above .Oo Fl O ( O2 , No ...\& ) Oc are not supported. -.It Va KERNEL +.It Va KERNCONF .Vt ( str ) Controls which kernel configurations will be built by @@ -259,7 +259,7 @@ .Dq Li "${MAKE} installkernel" . For example, .Bd -literal -offset indent -KERNEL=MINE DEBUG GENERIC OTHERMACHINE +KERNCONF=MINE DEBUG GENERIC OTHERMACHINE .Ed .Pp will build the the kernels specified by the config files To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:45:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0A57437B69F; Mon, 22 Jan 2001 15:45:20 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0MNj6913586; Mon, 22 Jan 2001 16:45:07 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101222345.f0MNj6913586@harmony.village.org> To: Randell Jesup Subject: Re: sysinstall.8 Breaking buildworld Cc: current@FreeBSD.ORG, stable@FreeBSD.ORG In-reply-to: Your message of "22 Jan 2001 18:15:24 EST." References: <20010111220021.C79365@strontium.scientia.demon.co.uk> <20010111174332.B74480@dragon.nuxi.com> Date: Mon, 22 Jan 2001 16:45:06 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Randell Jesup writes: : A full set of disklabel patches to support MB, GB, KB, %, and * : (everything not spoken for elsewhere) for sizes (and * for offsets to allow : disklabel to calculate them for you), etc are in Warner's hands. (I got : annoyed at it one evening...) Now, if Warner would commit them.... :-) : (Matt has looked at the patch also.) I've looked at them, and I have found someone with more time than I have to review and commit them. They should be going in soon, unless there's problems that I've not encountered. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:48: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from ns.plaut.de (ns.plaut.de [194.99.75.166]) by hub.freebsd.org (Postfix) with ESMTP id 4EA5737B400 for ; Mon, 22 Jan 2001 15:47:36 -0800 (PST) Received: (from uucp@localhost) by ns.plaut.de (8.9.3/8.9.3) with UUCP id AAA16067 for current@freebsd.org; Tue, 23 Jan 2001 00:47:35 +0100 (CET) (envelope-from root@nihil.plaut.de) Received: from localhost (root@localhost) by nihil.plaut.de (8.11.1/8.8.8) with ESMTP id f0MNkYi00777 for ; Tue, 23 Jan 2001 00:46:34 +0100 (CET) (envelope-from root@nihil) Date: Tue, 23 Jan 2001 00:46:34 +0100 (CET) From: Michael Reifenberger To: FreeBSD-Current Subject: -current UP panic Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1448934333-980207194=:760" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1448934333-980207194=:760 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, attached in dbg.txt is some dbg output from a recent -current panic. Anything else of interest to inspect? Bye! ---- Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS --0-1448934333-980207194=:760 Content-Type: TEXT/plain; name="dbg.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dbg.txt" Li4uDQpJZGxlUFREIDM3MzE0NTYNCmluaXRpYWwgcGNiIGF0IDJiZDYwMA0K cGFuaWNzdHI6IGdldG5ld2J1ZjogbG9ja2VkIGJ1Zg0KcGFuaWMgbWVzc2Fn ZXM6DQotLS0NCnBhbmljOiBsb2NrbWdyOiBwaWQgNSwgbm90IGV4Y2x1c2l2 ZSBsb2NrIGhvbGRlciAzNzQ1IHVubG9ja2luZw0KIA0Kc3luY2luZyBkaXNr cy4uLiBwYW5pYzogZ2V0bmV3YnVmOiBsb2NrZWQgYnVmDQpVcHRpbWU6IDlt MzVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Ci4uLg0KKGtnZGIpIGJ0DQojMCAgZHVtcHN5cyAoKSBhdCAuLi8uLi9rZXJu L2tlcm5fc2h1dGRvd24uYzo0NzcNCiMxICAweGMwMTgxNWJjIGluIGJvb3Qg KGhvd3RvPTB4MTA0KSBhdCAuLi8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzoz MjANCiMyICAweGMwMTgxOTkxIGluIHBhbmljIChmbXQ9MHhjMDI0ODlhMSAi Z2V0bmV3YnVmOiBsb2NrZWQgYnVmIikgYXQgLi4vLi4va2Vybi9rZXJuX3No dXRkb3duLmM6NTcwICMzICAweGMwMWFjNThhIGluIGdldG5ld2J1ZiAoc2xw ZmxhZz0weDAsIHNscHRpbWVvPTB4MCwgc2l6ZT0weDQwMDAsIG1heHNpemU9 MHg0MDAwKSBhdCAuLi8uLi9rZXJuL3Zmc19iaW8uYzoxNjI0DQojNCAgMHhj MDFhZDIzNyBpbiBnZXRlYmxrIChzaXplPTB4NDAwMCkgYXQgLi4vLi4va2Vy bi92ZnNfYmlvLmM6MjI5OQ0KIzUgIDB4YzAxYWIyZjQgaW4gYndyaXRlIChi cD0weGM0YTBmNDc4KSBhdCAuLi8uLi9rZXJuL3Zmc19iaW8uYzo2NjENCiM2 ICAweGMwMWIwZDZmIGluIHZvcF9zdGRid3JpdGUgKGFwPTB4Y2E5OWVjODgp IGF0IC4uLy4uL2tlcm4vdmZzX2RlZmF1bHQuYzozMjcNCiM3ICAweGMwMWIw Yjc5IGluIHZvcF9kZWZhdWx0b3AgKGFwPTB4Y2E5OWVjODgpIGF0IC4uLy4u L2tlcm4vdmZzX2RlZmF1bHQuYzoxNTANCiM4ICAweGMwMWJlNzMxIGluIHNw ZWNfdm5vcGVyYXRlIChhcD0weGNhOTllYzg4KSBhdCAuLi8uLi9taXNjZnMv c3BlY2ZzL3NwZWNfdm5vcHMuYzoxMTcNCiM5ICAweGMwMWFiNzhhIGluIGJh d3JpdGUgKGJwPTB4YzRhMGY0NzgpIGF0IHZub2RlX2lmLmg6OTg3DQojMTAg MHhjMDFiZWJjNyBpbiBzcGVjX2ZzeW5jIChhcD0weGNhOTllY2VjKSBhdCAu Li8uLi9taXNjZnMvc3BlY2ZzL3NwZWNfdm5vcHMuYzozODUNCiMxMSAweGMw MWJlNzMxIGluIHNwZWNfdm5vcGVyYXRlIChhcD0weGNhOTllY2VjKSBhdCAu Li8uLi9taXNjZnMvc3BlY2ZzL3NwZWNfdm5vcHMuYzoxMTcNCiMxMiAweGMw MWViMzUyIGluIGZmc19zeW5jIChtcD0weGMxM2E0NDAwLCB3YWl0Zm9yPTB4 MiwgY3JlZD0weGMwYTM4NTAwLCBwPTB4YzAyZTAzYzApIGF0IHZub2RlX2lm Lmg6NDIzDQojMTMgMHhjMDFiNjMxZSBpbiBzeW5jIChwPTB4YzAyZTAzYzAs IHVhcD0weDApIGF0IC4uLy4uL2tlcm4vdmZzX3N5c2NhbGxzLmM6NTQ5DQoj MTQgMHhjMDE4MTJjOCBpbiBib290IChob3d0bz0weDEwMCkgYXQgLi4vLi4v a2Vybi9rZXJuX3NodXRkb3duLmM6MjMwDQojMTUgMHhjMDE4MTk5MSBpbiBw YW5pYyAoZm10PTB4YzAyNDQwNjAgImxvY2ttZ3I6IHBpZCAlZCwgbm90ICVz ICVkIHVubG9ja2luZyIpIGF0IC4uLy4uL2tlcm4va2Vybl9zaHV0ZG93bi5j OjU3MA0KIzE2IDB4YzAxN2FlYjggaW4gbG9ja21nciAobGtwPTB4YzQ5Zjdj MjAsIGZsYWdzPTB4NiwgaW50ZXJsa3A9MHgwLCBwPTB4YzlmOTQ4NjApIGF0 IC4uLy4uL2tlcm4va2Vybl9sb2NrLmM6NDI4DQojMTcgMHhjMDFhYmVkZSBp biBicmVsc2UgKGJwPTB4YzQ5ZjdiOWMpIGF0IC4uLy4uL2tlcm4vdmZzX2Jp by5jOjIwOA0KIzE4IDB4YzAxYWQ5NWQgaW4gYnVmZG9uZSAoYnA9MHhjNDlm N2I5YykgYXQgLi4vLi4va2Vybi92ZnNfYmlvLmM6MjY4NA0KIzE5IDB4YzAx YWQ4ZTcgaW4gYnVmZG9uZWJpbyAoYnA9MHhjNDlmN2I5YykgYXQgLi4vLi4v a2Vybi92ZnNfYmlvLmM6MjY0Nw0KIzIwIDB4YzAxZjQzNWUgaW4gc3dhcF9w YWdlcl9zdHJhdGVneSAob2JqZWN0PTB4Y2JkNDQ4NDAsIGJwPTB4YzQ5Zjdi OWMpIGF0IC4uLy4uL3N5cy9iaW8uaDoxMDMNCiMyMSAweGMwMjAwNTA1IGlu IHZtX3BhZ2VyX3N0cmF0ZWd5IChvYmplY3Q9MHhjYmQ0NDg0MCwgYnA9MHhj NDlmN2I5YykgYXQgLi4vLi4vdm0vdm1fcGFnZXIuYzoyNzANCiMyMiAweGMw MzZiODU5IGluID8/ICgpDQojMjMgMHhjMDM2YjkxZSBpbiA/PyAoKQ0KIzI0 IDB4YzAxOGVkZTEgaW4gZGlza3N0cmF0ZWd5IChicD0weGM0YThkYmQ0KSBh dCAuLi8uLi9rZXJuL3N1YnJfZGlzay5jOjMxNQ0KIzI1IDB4YzAxYmVkNmMg aW4gc3BlY19zdHJhdGVneSAoYXA9MHhjYTk5ZWVlYykgYXQgLi4vLi4vbWlz Y2ZzL3NwZWNmcy9zcGVjX3Zub3BzLmM6NDYzDQojMjYgMHhjMDFiZTczMSBp biBzcGVjX3Zub3BlcmF0ZSAoYXA9MHhjYTk5ZWVlYykgYXQgLi4vLi4vbWlz Y2ZzL3NwZWNmcy9zcGVjX3Zub3BzLmM6MTE3DQojMjcgMHhjMDFhYjQxYiBp biBid3JpdGUgKGJwPTB4YzRhNDJlODApIGF0IHZub2RlX2lmLmg6NzQ0DQoj MjggMHhjMDFiMGQ2ZiBpbiB2b3Bfc3RkYndyaXRlIChhcD0weGNhOTllZjI4 KSBhdCAuLi8uLi9rZXJuL3Zmc19kZWZhdWx0LmM6MzI3DQojMjkgMHhjMDFi MGI3OSBpbiB2b3BfZGVmYXVsdG9wIChhcD0weGNhOTllZjI4KSBhdCAuLi8u Li9rZXJuL3Zmc19kZWZhdWx0LmM6MTUwDQojMzAgMHhjMDFiZTczMSBpbiBz cGVjX3Zub3BlcmF0ZSAoYXA9MHhjYTk5ZWYyOCkgYXQgLi4vLi4vbWlzY2Zz L3NwZWNmcy9zcGVjX3Zub3BzLmM6MTE3DQojMzEgMHhjMDFhYjc4YSBpbiBi YXdyaXRlIChicD0weGM0YTQyZTgwKSBhdCB2bm9kZV9pZi5oOjk4Nw0KIzMy IDB4YzAxYmViYzcgaW4gc3BlY19mc3luYyAoYXA9MHhjYTk5ZWY3YykgYXQg Li4vLi4vbWlzY2ZzL3NwZWNmcy9zcGVjX3Zub3BzLmM6Mzg1DQojMzMgMHhj MDFiZTczMSBpbiBzcGVjX3Zub3BlcmF0ZSAoYXA9MHhjYTk5ZWY3YykgYXQg Li4vLi4vbWlzY2ZzL3NwZWNmcy9zcGVjX3Zub3BzLmM6MTE3DQojMzQgMHhj MDFiMzRmZSBpbiBzY2hlZF9zeW5jICgpIGF0IHZub2RlX2lmLmg6NDIzDQoo a2dkYikgZnJhbWUgMQ0KIzEgIDB4YzAxODE1YmMgaW4gYm9vdCAoaG93dG89 MHgxMDQpIGF0IC4uLy4uL2tlcm4va2Vybl9zaHV0ZG93bi5jOjMyMA0KMzIw ICAgICAgICAgICAgICAgICAgICAgZHVtcHN5cygpOw0KKGtnZGIpIHVwDQoj MiAgMHhjMDE4MTk5MSBpbiBwYW5pYyAoZm10PTB4YzAyNDg5YTEgImdldG5l d2J1ZjogbG9ja2VkIGJ1ZiIpIGF0IC4uLy4uL2tlcm4va2Vybl9zaHV0ZG93 bi5jOjU3MA0KNTcwICAgICAgICAgICAgIGJvb3QoYm9vdG9wdCk7DQooa2dk YikNCiMzICAweGMwMWFjNThhIGluIGdldG5ld2J1ZiAoc2xwZmxhZz0weDAs IHNscHRpbWVvPTB4MCwgc2l6ZT0weDQwMDAsIG1heHNpemU9MHg0MDAwKSBh dCAuLi8uLi9rZXJuL3Zmc19iaW8uYzoxNjI0DQoxNjI0ICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHBhbmljKCJnZXRuZXdidWY6IGxvY2tlZCBidWYi KTsNCihrZ2RiKQ0KIzQgIDB4YzAxYWQyMzcgaW4gZ2V0ZWJsayAoc2l6ZT0w eDQwMDApIGF0IC4uLy4uL2tlcm4vdmZzX2Jpby5jOjIyOTkNCjIyOTkgICAg ICAgICAgICB3aGlsZSAoKGJwID0gZ2V0bmV3YnVmKDAsIDAsIHNpemUsIG1h eHNpemUpKSA9PSAwKTsNCihrZ2RiKQ0KIzUgIDB4YzAxYWIyZjQgaW4gYndy aXRlIChicD0weGM0YTBmNDc4KSBhdCAuLi8uLi9rZXJuL3Zmc19iaW8uYzo2 NjENCjY2MSAgICAgICAgICAgICAgICAgICAgIG5ld2JwID0gZ2V0ZWJsayhi cC0+Yl9idWZzaXplKTsNCihrZ2RiKQ0KIzYgIDB4YzAxYjBkNmYgaW4gdm9w X3N0ZGJ3cml0ZSAoYXA9MHhjYTk5ZWM4OCkgYXQgLi4vLi4va2Vybi92ZnNf ZGVmYXVsdC5jOjMyNw0KMzI3ICAgICAgICAgICAgIHJldHVybiAoYndyaXRl KGFwLT5hX2JwKSk7DQooa2dkYikNCiM3ICAweGMwMWIwYjc5IGluIHZvcF9k ZWZhdWx0b3AgKGFwPTB4Y2E5OWVjODgpIGF0IC4uLy4uL2tlcm4vdmZzX2Rl ZmF1bHQuYzoxNTANCjE1MCAgICAgICAgICAgICByZXR1cm4gKFZPQ0FMTChk ZWZhdWx0X3Zub2Rlb3BfcCwgYXAtPmFfZGVzYy0+dmRlc2Nfb2Zmc2V0LCBh cCkpOw0KKGtnZGIpDQojOCAgMHhjMDFiZTczMSBpbiBzcGVjX3Zub3BlcmF0 ZSAoYXA9MHhjYTk5ZWM4OCkgYXQgLi4vLi4vbWlzY2ZzL3NwZWNmcy9zcGVj X3Zub3BzLmM6MTE3DQoxMTcgICAgICAgICAgICAgcmV0dXJuIChWT0NBTEwo c3BlY192bm9kZW9wX3AsIGFwLT5hX2Rlc2MtPnZkZXNjX29mZnNldCwgYXAp KTsNCihrZ2RiKQ0KIzkgIDB4YzAxYWI3OGEgaW4gYmF3cml0ZSAoYnA9MHhj NGEwZjQ3OCkgYXQgdm5vZGVfaWYuaDo5ODcNCjk4NyAgICAgICAgICAgICBy YyA9IFZDQUxMKHZwLCBWT0ZGU0VUKHZvcF9id3JpdGUpLCAmYSk7DQooa2dk YikNCiMxMCAweGMwMWJlYmM3IGluIHNwZWNfZnN5bmMgKGFwPTB4Y2E5OWVj ZWMpIGF0IC4uLy4uL21pc2Nmcy9zcGVjZnMvc3BlY192bm9wcy5jOjM4NQ0K Mzg1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiYXdyaXRlKGJwKTsN CihrZ2RiKSB1cA0KIzExIDB4YzAxYmU3MzEgaW4gc3BlY192bm9wZXJhdGUg KGFwPTB4Y2E5OWVjZWMpIGF0IC4uLy4uL21pc2Nmcy9zcGVjZnMvc3BlY192 bm9wcy5jOjExNw0KMTE3ICAgICAgICAgICAgIHJldHVybiAoVk9DQUxMKHNw ZWNfdm5vZGVvcF9wLCBhcC0+YV9kZXNjLT52ZGVzY19vZmZzZXQsIGFwKSk7 DQooa2dkYikgdXANCiMxMiAweGMwMWViMzUyIGluIGZmc19zeW5jIChtcD0w eGMxM2E0NDAwLCB3YWl0Zm9yPTB4MiwgY3JlZD0weGMwYTM4NTAwLCBwPTB4 YzAyZTAzYzApIGF0IHZub2RlX2lmLmg6NDIzDQo0MjMgICAgICAgICAgICAg cmMgPSBWQ0FMTCh2cCwgVk9GRlNFVCh2b3BfZnN5bmMpLCAmYSk7DQooa2dk YikgdXANCiMxMyAweGMwMWI2MzFlIGluIHN5bmMgKHA9MHhjMDJlMDNjMCwg dWFwPTB4MCkgYXQgLi4vLi4va2Vybi92ZnNfc3lzY2FsbHMuYzo1NDkNCjU0 OSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVkZTX1NZTkMobXAsIE1O VF9OT1dBSVQsDQooa2dkYikgdXANCiMxNCAweGMwMTgxMmM4IGluIGJvb3Qg KGhvd3RvPTB4MTAwKSBhdCAuLi8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzoy MzANCjIzMCAgICAgICAgICAgICAgICAgICAgIHN5bmMoJnByb2MwLCBOVUxM KTsNCihrZ2RiKSB1cA0KIzE1IDB4YzAxODE5OTEgaW4gcGFuaWMgKGZtdD0w eGMwMjQ0MDYwICJsb2NrbWdyOiBwaWQgJWQsIG5vdCAlcyAlZCB1bmxvY2tp bmciKSBhdCAuLi8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzo1NzANCjU3MCAg ICAgICAgICAgICBib290KGJvb3RvcHQpOw0KKGtnZGIpIHVwDQojMTYgMHhj MDE3YWViOCBpbiBsb2NrbWdyIChsa3A9MHhjNDlmN2MyMCwgZmxhZ3M9MHg2 LCBpbnRlcmxrcD0weDAsIHA9MHhjOWY5NDg2MCkgYXQgLi4vLi4va2Vybi9r ZXJuX2xvY2suYzo0MjgNCjQyOCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBwYW5pYygibG9ja21ncjogcGlkICVkLCBub3QgJXMgJWQg dW5sb2NraW5nIiwNCihrZ2RiKSB1cA0KIzE3IDB4YzAxYWJlZGUgaW4gYnJl bHNlIChicD0weGM0OWY3YjljKSBhdCAuLi8uLi9rZXJuL3Zmc19iaW8uYzoy MDgNCjIwOCAgICAgfQ0KKGtnZGIpIHVwDQojMTggMHhjMDFhZDk1ZCBpbiBi dWZkb25lIChicD0weGM0OWY3YjljKSBhdCAuLi8uLi9rZXJuL3Zmc19iaW8u YzoyNjg0DQoyNjg0ICAgICAgICAgICAgICAgICAgICBicmVsc2UoYnApOw0K KGtnZGIpIHVwDQojMTkgMHhjMDFhZDhlNyBpbiBidWZkb25lYmlvIChicD0w eGM0OWY3YjljKSBhdCAuLi8uLi9rZXJuL3Zmc19iaW8uYzoyNjQ3DQoyNjQ3 ICAgICAgICAgICAgYnVmZG9uZShicC0+YmlvX2NhbGxlcjIpOw0KKGtnZGIp IHVwDQojMjAgMHhjMDFmNDM1ZSBpbiBzd2FwX3BhZ2VyX3N0cmF0ZWd5IChv YmplY3Q9MHhjYmQ0NDg0MCwgYnA9MHhjNDlmN2I5YykgYXQgLi4vLi4vc3lz L2Jpby5oOjEwMw0KMTAzICAgICAgICAgICAgIGJwLT5iaW9fZG9uZShicCk7 DQooa2dkYikgdXANCiMyMSAweGMwMjAwNTA1IGluIHZtX3BhZ2VyX3N0cmF0 ZWd5IChvYmplY3Q9MHhjYmQ0NDg0MCwgYnA9MHhjNDlmN2I5YykgYXQgLi4v Li4vdm0vdm1fcGFnZXIuYzoyNzANCjI3MCAgICAgICAgICAgICAgICAgKCpw YWdlcnRhYltvYmplY3QtPnR5cGVdLT5wZ29fc3RyYXRlZ3kpKG9iamVjdCwg YnApOw0KKGtnZGIpIHVwDQojMjIgMHhjMDM2Yjg1OSBpbiA/PyAoKQ0KKGtn ZGIpIHVwDQojMjMgMHhjMDM2YjkxZSBpbiA/PyAoKQ0KKGtnZGIpIHVwDQoj MjQgMHhjMDE4ZWRlMSBpbiBkaXNrc3RyYXRlZ3kgKGJwPTB4YzRhOGRiZDQp IGF0IC4uLy4uL2tlcm4vc3Vicl9kaXNrLmM6MzE1DQozMTUgICAgICAgICAg ICAgZHAtPmRfZGV2c3ctPmRfc3RyYXRlZ3koYnApOw0KKGtnZGIpIHVwDQoj MjUgMHhjMDFiZWQ2YyBpbiBzcGVjX3N0cmF0ZWd5IChhcD0weGNhOTllZWVj KSBhdCAuLi8uLi9taXNjZnMvc3BlY2ZzL3NwZWNfdm5vcHMuYzo0NjMNCjQ2 MyAgICAgICAgICAgICBERVZfU1RSQVRFR1koYnAsIDApOw0KKGtnZGIpIHVw DQojMjYgMHhjMDFiZTczMSBpbiBzcGVjX3Zub3BlcmF0ZSAoYXA9MHhjYTk5 ZWVlYykgYXQgLi4vLi4vbWlzY2ZzL3NwZWNmcy9zcGVjX3Zub3BzLmM6MTE3 DQoxMTcgICAgICAgICAgICAgcmV0dXJuIChWT0NBTEwoc3BlY192bm9kZW9w X3AsIGFwLT5hX2Rlc2MtPnZkZXNjX29mZnNldCwgYXApKTsNCihrZ2RiKSB1 cA0KIzI3IDB4YzAxYWI0MWIgaW4gYndyaXRlIChicD0weGM0YTQyZTgwKSBh dCB2bm9kZV9pZi5oOjc0NA0KNzQ0ICAgICAgICAgICAgIHJjID0gVkNBTEwo dnAsIFZPRkZTRVQodm9wX3N0cmF0ZWd5KSwgJmEpOw0KKGtnZGIpIHVwDQoj MjggMHhjMDFiMGQ2ZiBpbiB2b3Bfc3RkYndyaXRlIChhcD0weGNhOTllZjI4 KSBhdCAuLi8uLi9rZXJuL3Zmc19kZWZhdWx0LmM6MzI3DQozMjcgICAgICAg ICAgICAgcmV0dXJuIChid3JpdGUoYXAtPmFfYnApKTsNCihrZ2RiKSB1cA0K IzI5IDB4YzAxYjBiNzkgaW4gdm9wX2RlZmF1bHRvcCAoYXA9MHhjYTk5ZWYy OCkgYXQgLi4vLi4va2Vybi92ZnNfZGVmYXVsdC5jOjE1MA0KMTUwICAgICAg ICAgICAgIHJldHVybiAoVk9DQUxMKGRlZmF1bHRfdm5vZGVvcF9wLCBhcC0+ YV9kZXNjLT52ZGVzY19vZmZzZXQsIGFwKSk7DQooa2dkYikgdXANCiMzMCAw eGMwMWJlNzMxIGluIHNwZWNfdm5vcGVyYXRlIChhcD0weGNhOTllZjI4KSBh dCAuLi8uLi9taXNjZnMvc3BlY2ZzL3NwZWNfdm5vcHMuYzoxMTcNCjExNyAg ICAgICAgICAgICByZXR1cm4gKFZPQ0FMTChzcGVjX3Zub2Rlb3BfcCwgYXAt PmFfZGVzYy0+dmRlc2Nfb2Zmc2V0LCBhcCkpOw0KKGtnZGIpIHVwDQojMzEg MHhjMDFhYjc4YSBpbiBiYXdyaXRlIChicD0weGM0YTQyZTgwKSBhdCB2bm9k ZV9pZi5oOjk4Nw0KOTg3ICAgICAgICAgICAgIHJjID0gVkNBTEwodnAsIFZP RkZTRVQodm9wX2J3cml0ZSksICZhKTsNCihrZ2RiKSB1cA0KIzMyIDB4YzAx YmViYzcgaW4gc3BlY19mc3luYyAoYXA9MHhjYTk5ZWY3YykgYXQgLi4vLi4v bWlzY2ZzL3NwZWNmcy9zcGVjX3Zub3BzLmM6Mzg1DQozODUgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGJhd3JpdGUoYnApOw0KKGtnZGIpIHVwDQoj MzMgMHhjMDFiZTczMSBpbiBzcGVjX3Zub3BlcmF0ZSAoYXA9MHhjYTk5ZWY3 YykgYXQgLi4vLi4vbWlzY2ZzL3NwZWNmcy9zcGVjX3Zub3BzLmM6MTE3DQox MTcgICAgICAgICAgICAgcmV0dXJuIChWT0NBTEwoc3BlY192bm9kZW9wX3As IGFwLT5hX2Rlc2MtPnZkZXNjX29mZnNldCwgYXApKTsNCihrZ2RiKSB1cA0K IzM0IDB4YzAxYjM0ZmUgaW4gc2NoZWRfc3luYyAoKSBhdCB2bm9kZV9pZi5o OjQyMw0KNDIzICAgICAgICAgICAgIHJjID0gVkNBTEwodnAsIFZPRkZTRVQo dm9wX2ZzeW5jKSwgJmEpOyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQo= --0-1448934333-980207194=:760 Content-Type: TEXT/plain; name="dmesg.txt" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDEgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIDUuMC1DVVJSRU5UICMwOiBNb24gSmFuIDIyIDE0 OjUwOjU1IENFVCAyMDAxDQogICAgcm9vdEBuaWhpbC5wbGF1dC5kZTovdXNy L3NyYy9zeXMvY29tcGlsZS9uaWhpbA0KVGltZWNvdW50ZXIgImk4MjU0IiAg ZnJlcXVlbmN5IDExOTMxODIgSHoNCkNQVTogUGVudGl1bSBJSS9QZW50aXVt IElJIFhlb24vQ2VsZXJvbiAoMjY2LjYyLU1IeiA2ODYtY2xhc3MgQ1BVKQ0K ICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDY1MiAgU3RlcHBp bmcgPSAyDQogIEZlYXR1cmVzPTB4MTgzZjlmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQs UFNFMzYsTU1YLEZYU1I+DQpyZWFsIG1lbW9yeSAgPSAyNjgzNjk5MjAgKDI2 MjA4MEsgYnl0ZXMpDQpjb25maWc+ICNmbGFncyB3ZGMwIDB4YTBmZmEwZmYN CkludmFsaWQgY29tbWFuZCBvciBzeW50YXguICBUeXBlIGA/JyBmb3IgaGVs cC4NCmNvbmZpZz4gI2ZsYWdzIHdkYzEgMHhhMGZmYTBmZg0KSW52YWxpZCBj b21tYW5kIG9yIHN5bnRheC4gIFR5cGUgYD8nIGZvciBoZWxwLg0KY29uZmln PiAjaW9zaXogbnB4MCAxOTY2MDgNCkludmFsaWQgY29tbWFuZCBvciBzeW50 YXguICBUeXBlIGA/JyBmb3IgaGVscC4NCmNvbmZpZz4gI2lycSBwY2ljMCAx MQ0KSW52YWxpZCBjb21tYW5kIG9yIHN5bnRheC4gIFR5cGUgYD8nIGZvciBo ZWxwLg0KY29uZmlnPiBxdWl0DQphdmFpbCBtZW1vcnkgPSAyNTc3NTcxODQg KDI1MTcxNksgYnl0ZXMpDQpQcmVsb2FkZWQgZWxmIGtlcm5lbCAia2VybmVs IiBhdCAweGMwMzcwMDAwLg0KUHJlbG9hZGVkIHVzZXJjb25maWdfc2NyaXB0 ICIvYm9vdC9rZXJuZWwuY29uZiIgYXQgMHhjMDM3MDA5Yy4NClByZWxvYWRl ZCBlbGYgbW9kdWxlICJsaW51eC5rbyIgYXQgMHhjMDM3MDBlYy4NClByZWxv YWRlZCBlbGYgbW9kdWxlICJsaW5wcm9jZnMua28iIGF0IDB4YzAzNzAxOGMu DQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAicHJvY2ZzLmtvIiBhdCAweGMwMzcw MjMwLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIm1kLmtvIiBhdCAweGMwMzcw MmQwLg0Kc2VxMC0xNTogTWlkaSBzZXF1ZW5jZXJzLg0KUGVudGl1bSBQcm8g TVRSUiBzdXBwb3J0IGVuYWJsZWQNClZFU0E6IHYyLjAsIDI0OTZrIG1lbW9y eSwgZmxhZ3M6MHgwLCBtb2RlIHRhYmxlOjB4YzAyY2ZlMDIgKDEwMDAwMjIp DQpWRVNBOiBNYWdpY0dyYXBoIDI1NiBBViA0NEsgUFJFTElNSU5BUlkNClVz aW5nICRQSVIgdGFibGUsIDYgZW50cmllcyBhdCAweGMwMGYwMWUwDQphcG0w OiA8QVBNIEJJT1M+IG9uIG1vdGhlcmJvYXJkDQphcG0wOiBmb3VuZCBBUE0g QklPUyB2MS4yLCBjb25uZWN0ZWQgYXQgdjEuMg0KbnB4MDogPG1hdGggcHJv Y2Vzc29yPiBvbiBtb3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGludGVyZmFj ZQ0KcGNpYjA6IDxJbnRlbCA4MjQ0M0JYIGhvc3QgdG8gUENJIGJyaWRnZSAo QUdQIGRpc2FibGVkKT4gYXQgcGNpYnVzIDAgb24gbW90aGVyYm9hcmQNCnBj aTA6IDxQQ0kgYnVzPiBvbiBwY2liMA0KcGNpMDogPGRpc3BsYXksIFZHQT4g YXQgNC4wIChubyBkcml2ZXIgYXR0YWNoZWQpDQppc2FiMDogPFBDSS1JU0Eg YnJpZGdlPiBhdCBkZXZpY2UgNS4wIG9uIHBjaTANCmlzYTA6IDxJU0EgYnVz PiBvbiBpc2FiMA0KYXRhcGNpMDogPEludGVsIFBJSVg0IEFUQTMzIGNvbnRy b2xsZXI+IHBvcnQgMHhmZTYwLTB4ZmU2ZiBhdCBkZXZpY2UgNS4xIG9uIHBj aTANCmF0YTA6IGF0IDB4MWYwIGlycSAxNCBvbiBhdGFwY2kwDQphdGExOiBh dCAweDE3MCBpcnEgMTUgb24gYXRhcGNpMA0KcGNpMDogPHNlcmlhbCBidXMs IFVTQj4gYXQgNS4yIChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2kwOiA8YnJp ZGdlLCBQQ0ktdW5rbm93bj4gYXQgNS4zIChubyBkcml2ZXIgYXR0YWNoZWQp DQpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCA5LjAgKG5vIGRyaXZlciBhdHRh Y2hlZCkNCnBjaWMtcGNpMDogPFRvc2hpYmEgVG9QSUM5NyBQQ0ktQ2FyZEJ1 cyBCcmlkZ2U+IGF0IGRldmljZSAxMS4wIG9uIHBjaTANCnBjaWMtcGNpMTog PFRvc2hpYmEgVG9QSUM5NyBQQ0ktQ2FyZEJ1cyBCcmlkZ2U+IGF0IGRldmlj ZSAxMS4xIG9uIHBjaTANCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVy IChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0IG9uIGlzYTANCmF0a2JkMDog PEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwDQpwc20wOiA8UFMvMiBN b3VzZT4gaXJxIDEyIG9uIGF0a2JkYzANCnBzbTA6IG1vZGVsIEdsaWRlUG9p bnQsIGRldmljZSBJRCAwDQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBw b3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2Ew DQpzYzA6IDxTeXN0ZW0gY29uc29sZT4gb24gaXNhMA0Kc2MwOiBWR0EgPDE2 IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MjAwPg0Kc2lvMCBhdCBwb3J0 IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gaXNhMA0Kc2lvMDog dHlwZSAxNjU1MEENCnNpbzE6IGNvbmZpZ3VyZWQgaXJxIDMgbm90IGluIGJp dG1hcCBvZiBwcm9iZWQgaXJxcyAwDQpwcGMwOiA8UGFyYWxsZWwgcG9ydD4g YXQgcG9ydCAweDM3OC0weDM3ZiBpcnEgNyBmbGFncyAweDQwIG9uIGlzYTAN CnBwYzA6IEdlbmVyaWMgY2hpcHNldCAoRUNQL1BTMi9OSUJCTEUpIGluIENP TVBBVElCTEUgbW9kZQ0KcHBjMDogRklGTyB3aXRoIDE2LzE2LzE2IGJ5dGVz IHRocmVzaG9sZA0KbHB0MDogPFByaW50ZXI+IG9uIHBwYnVzMA0KbHB0MDog SW50ZXJydXB0LWRyaXZlbiBwb3J0DQpwcGkwOiA8UGFyYWxsZWwgSS9PPiBv biBwcGJ1czANCnBwczA6IDxQdWxzZSBwZXIgc2Vjb25kIFRpbWluZyBJbnRl cmZhY2U+IG9uIHBwYnVzMA0KcGNpYzA6IDxJbnRlbCBpODIzNjU+IGF0IHBv cnQgMHgzZTAtMHgzZTEgb24gaXNhMA0KcGNpYzA6IFBvbGxpbmcgbW9kZQ0K cGNjYXJkMDogPFBDIENhcmQgYnVzIC0tIGtsdWRnZSB2ZXJzaW9uPiBvbiBw Y2ljMA0KcGNjYXJkMTogPFBDIENhcmQgYnVzIC0tIGtsdWRnZSB2ZXJzaW9u PiBvbiBwY2ljMA0KcG10aW1lcjAgb24gaXNhMA0KdW5rbm93bjogPFBOUDAz MDM+IGNhbid0IGFzc2lnbiByZXNvdXJjZXMNCnVua25vd246IDxQTlAwZjEz PiBjYW4ndCBhc3NpZ24gcmVzb3VyY2VzDQp1bmtub3duOiA8UE5QMDUwMT4g Y2FuJ3QgYXNzaWduIHJlc291cmNlcw0KdW5rbm93bjogPFBOUDA0MDE+IGNh bid0IGFzc2lnbiByZXNvdXJjZXMNCnVua25vd246IDxQTlAwZTAzPiBjYW4n dCBhc3NpZ24gcmVzb3VyY2VzDQpwY20wOiA8WWFtYWhhIE9QTC1TQXg+IGF0 IHBvcnQgMHgyMjAtMHgyMzMsMHg1MzAtMHg1MzcsMHgzODgtMHgzOGYsMHgz MzAtMHgzMzMsMHg1MzgtMHg1MzkgaXJxIDUgZHJxIDEsMCBvbiBpc2EwDQpJ UCBwYWNrZXQgZmlsdGVyaW5nIGluaXRpYWxpemVkLCBkaXZlcnQgZW5hYmxl ZCwgcnVsZS1iYXNlZCBmb3J3YXJkaW5nIGRpc2FibGVkLCBkZWZhdWx0IHRv IGRlbnksIGxvZ2dpbmcgbGltaXRlZCB0byAxMDAgcGFja2V0cy9lbnRyeSBi eSBkZWZhdWx0DQpsbzAgWFhYOiBkcml2ZXIgZGlkbid0IGluaXRpYWxpemUg cXVldWUgbXR4DQphZDA6IDMwNTIwTUIgPElCTS1ESlNBLTIzMj4gWzYyMDEw LzE2LzYzXSBhdCBhdGEwLW1hc3RlciBVRE1BMzMNCmFkMTogMzA1MjBNQiA8 SUJNLURKU0EtMjMyPiBbNjIwMTAvMTYvNjNdIGF0IGF0YTEtbWFzdGVyIFVE TUEzMw0KTW91bnRpbmcgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMyYQ0KcGNj YXJkOiBjYXJkIGluc2VydGVkLCBzbG90IDANCnBjY2FyZDogY2FyZCBpbnNl cnRlZCwgc2xvdCAxDQpSZWFkaW5nIGVudHJvcHkgZmlsZQ0Kcm06IA0KL2V0 Yy9lbnRyb3B5DQo6IA0KUmVhZC1vbmx5IGZpbGUgc3lzdGVtDQpzd2Fwb246 IGFkZGluZyAvZGV2L2FkMHMyYiBhcyBzd2FwIGRldmljZQ0KQXV0b21hdGlj IGJvb3QgaW4gcHJvZ3Jlc3MuLi4NCi9kZXYvYWQwczJhOiANCkZJTEVTWVNU RU0gQ0xFQU47IFNLSVBQSU5HIENIRUNLUw0KL2Rldi9hZDBzMmE6IA0KY2xl YW4sIDk1NSBmcmVlIA0KKDEyMyBmcmFncywgMTA0IGJsb2NrcywgMC4yJSBm cmFnbWVudGF0aW9uKQ0KL2Rldi9hZDBzMmQ6IA0KRklMRVNZU1RFTSBDTEVB TjsgU0tJUFBJTkcgQ0hFQ0tTDQovZGV2L2FkMHMyZDogDQpjbGVhbiwgMTMx MTY3NyBmcmVlIA0KKDE4MjUzIGZyYWdzLCAxNjE2NzggYmxvY2tzLCAwLjEl IGZyYWdtZW50YXRpb24pDQpmc2NrOiANCnByb2MgaW4gZnN0YWIgbW9yZSB0 aGFuIG9uY2UhDQoNCnZmcy52bWlvZGlyZW5hYmxlOiANCjANCiAtPiANCjEN Cg0KdmZzLndyaXRlX2JlaGluZDogDQoxDQogLT4gDQowDQoNCm5ldC5pbmV0 LnRjcC5kZWxheWVkX2FjazogDQoxDQogLT4gDQoxMA0KDQpuZXQuaW5ldC50 Y3AuZGVsYWNrdGltZTogDQoxMDANCiAtPiANCjEwDQoNCm5ldC5pbmV0LnRj cC5zZW5kc3BhY2U6IA0KMTYzODQNCiAtPiANCjEzMTA3Mg0KDQpuZXQuaW5l dC50Y3AucmVjdnNwYWNlOiANCjE2Mzg0DQogLT4gDQoxMzEwNzINCg0KDQou Li4NCg== --0-1448934333-980207194=:760-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:49: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 92B6F37B69E; Mon, 22 Jan 2001 15:48:41 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0MNlwx13734; Mon, 22 Jan 2001 15:47:58 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0MNlYs11373; Mon, 22 Jan 2001 15:47:34 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200101222325.f0MNPA913286@harmony.village.org> Date: Mon, 22 Jan 2001 15:47:34 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Warner Losh Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: Mike Meyer , Kris Kennaway , "Donald J . Maddox" , freebsd-current@FreeBSD.ORG, The Hermit Hacker , Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Jan-01 Warner Losh wrote: > In message John Baldwin writes: >: >: Erm, if it wasn't documented in the first place, making a change doesn't >: put the burden of documenting the old behavior on the person making the >: change. > > It was in the handbook, explicitly documented. Nothing undocumented > about it. If I were to change how ls worked in some way, I'd be > exepcted to update the man page for ls. This is no different than > that. This is the documented way to build kernels, see > http://www.freebsd.org/handbook/kernelconfig-building.html > for the current instructions. They have been in there since at least > 1.29 (alex 15-Jul-00): &prompt.root; make... > 1.29 (alex 15-Jul-00): &prompt.root; make... > when alex added them. That's at least 6 months ago. They have been > in UPDATING longer than that. Nm. I was referring to the original request: >: >: Could you also make sure it makes it into /etc/defaults/make.conf >: >: (KERNEL isn't mentioned there at all) and make.conf(5)? Which basically says: "this wasn't documented before, can you document it now?" But anyways, this isn't really worth the effort. My laptop still isn't booting, so I'll get back to that.... -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 15:54: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id F080137B400; Mon, 22 Jan 2001 15:53:49 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0MNrm913718; Mon, 22 Jan 2001 16:53:48 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101222353.f0MNrm913718@harmony.village.org> To: John Baldwin Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) Cc: Mike Meyer , Kris Kennaway , "Donald J . Maddox" , freebsd-current@FreeBSD.ORG, The Hermit Hacker , Peter Wemm In-reply-to: Your message of "Mon, 22 Jan 2001 15:47:34 PST." References: Date: Mon, 22 Jan 2001 16:53:48 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Baldwin writes: : Nm. I was referring to the original request: : : >: >: Could you also make sure it makes it into /etc/defaults/make.conf : >: >: (KERNEL isn't mentioned there at all) and make.conf(5)? : : Which basically says: "this wasn't documented before, can you document it now?" : But anyways, this isn't really worth the effort. My laptop still isn't : booting, so I'll get back to that.... Ah. That makes sense. Technically, it was documented, but that was a very very recent change: revision 1.7 date: 2001/01/17 11:51:43; author: ben; state: Exp; lines: +19 -1 document ${KERNEL} so I agree with your sentiment as far as that goes. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 16:56:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D072E37B400 for ; Mon, 22 Jan 2001 16:55:58 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id QAA08883; Mon, 22 Jan 2001 16:55:52 -0800 Date: Mon, 22 Jan 2001 16:55:51 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matt Dillon Cc: current@FreeBSD.ORG Subject: Re: loopback nfs hangs now propagated to -stable... In-Reply-To: <200101211954.f0LJsWI15413@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would, except that several attempts to get this to work have failed. It hangs syncing disks, I couldn't get into ddb....I'll keep trying as I can, but, you know, this is really really easy to reproduce- can't you do it? The best I can tell you at the moment is that objcopy is in sleeping on 'sbwait'. -matt > : > :The loopback nfs hangs that have been with us for a month have now propagated > :to -stable. > > Can you break into DDB and get a 'ps' and a kernel core? There are a > bunch of things it could be, including possibly my low-memory deadlock > code (which concentrated more on UFS and not so much on NFS), though > my low-memory deadlock code was committed all the way back in > december (12/29). The only recent commit was to fix an O_EXCL bug, > and I doubt that could cause a loopback deadlock. The cause could > also be related to MFC's (not by me) related to the network stack, > which are more recent. There isn't much in the cvs logs that I > can see as having caused the problem to occur only recently. > > -Matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 17: 4:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 549CF37B402 for ; Mon, 22 Jan 2001 17:03:59 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0N13rg07556; Mon, 22 Jan 2001 17:03:53 -0800 (PST) (envelope-from dillon) Date: Mon, 22 Jan 2001 17:03:53 -0800 (PST) From: Matt Dillon Message-Id: <200101230103.f0N13rg07556@earth.backplane.com> To: Matthew Jacob Cc: current@FreeBSD.ORG Subject: Re: loopback nfs hangs now propagated to -stable... References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : : :I would, except that several attempts to get this to work have failed. It :hangs syncing disks, I couldn't get into ddb....I'll keep trying as I can, :but, you know, this is really really easy to reproduce- can't you do it? : :The best I can tell you at the moment is that objcopy is in sleeping on :'sbwait'. : :-matt The last time I tested a localhost mount was around 6 months ago. If I do a localhost mount of /usr/src and /usr/obj, and buildworld, should that be sufficient enough to cause the hang? I can do that test relatively easily, but it may take me a few days because my computer room is being given a facelift at the moment and all the equipment is sitting in the living room :-) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 17: 6:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id CE8C437B402 for ; Mon, 22 Jan 2001 17:05:54 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id RAA08927; Mon, 22 Jan 2001 17:05:53 -0800 Date: Mon, 22 Jan 2001 17:05:52 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matt Dillon Cc: current@FreeBSD.ORG Subject: Re: loopback nfs hangs now propagated to -stable... In-Reply-To: <200101230103.f0N13rg07556@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 22 Jan 2001, Matt Dillon wrote: > > : > : > : > :I would, except that several attempts to get this to work have failed. It > :hangs syncing disks, I couldn't get into ddb....I'll keep trying as I can, > :but, you know, this is really really easy to reproduce- can't you do it? > : > :The best I can tell you at the moment is that objcopy is in sleeping on > :'sbwait'. > : > :-matt > > The last time I tested a localhost mount was around 6 months ago. > > If I do a localhost mount of /usr/src and /usr/obj, and buildworld, > should that be sufficient enough to cause the hang? I can do that test > relatively easily, but it may take me a few days because my computer > room is being given a facelift at the moment and all the equipment is > sitting in the living room :-) I have a /tstsys and have loopback mounted /tstsys/compile. That might be easier than the whole /usr/obj. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 18: 1:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id BAE0937B400 for ; Mon, 22 Jan 2001 18:01:36 -0800 (PST) Received: (qmail 27458 invoked by uid 1000); 23 Jan 2001 02:01:35 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Jan 2001 02:01:35 -0000 Date: Mon, 22 Jan 2001 20:01:35 -0600 (CST) From: Mike Silbersack To: Cc: Subject: Patch to enable asm cores w/openssl Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG http://www.silby.com/patches/openssl-asm.patch I've just thrown together a patch that enables the asm cores (where available) in openssl. I've tested it on a p5, k6, and p6 - all show good improvements (from 1.1x - 2.0x, depending on the core.) SHA1, blowfish, and cast aren't running as fast as they could - doing so would make the resulting lib not work on 386es. Nonetheless, there's still a marked improvement over the C versions of the code. There are two things I can't easily test, which I was hoping I could get some help on before I bug kris about committing this. 1. Operation on 386es. I don't have one of these around, but if someone has one running 4.x or 5.x and could test to make sure that the updated libcrypto works properly on it, I'd feel much safer. 2. Speed on Athlons. I don't have one of these handy, and I'm curious if the asm cores cause any regressions in speed. For those not familiar with openssl, the process of benchmarking is simple - just type "openssl speed". Any comments about how to improve my make syntax would also be helpful, if one is so inclined. Thanks, Mike "Silby" Silbersack (Please CC me on followups, I'm not on the list.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 18: 7: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from kyra.unloved.org (kyra.unloved.org [62.58.62.162]) by hub.freebsd.org (Postfix) with ESMTP id 328FD37B400; Mon, 22 Jan 2001 18:06:14 -0800 (PST) Received: by kyra.unloved.org (Postfix) id 13586F431; Tue, 23 Jan 2001 03:06:08 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix, from userid 0) id 7E839F40E; Tue, 23 Jan 2001 03:06:07 +0100 (CET) To: root@unloved.org Subject: kyra.unloved.org daily run output Message-Id: <20010123020607.7E839F40E@kyra.unloved.org> Date: Tue, 23 Jan 2001 03:06:07 +0100 (CET) From: root@unloved.org (Charlie Root) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: kyra.unloved.org passwd diffs: 68d67 < orion:(password):2004:2004::0:0:Orion Server:/home/orion:/usr/local/bin/bash 69a69 > postfix:(password):2001:3024::0:0:Postfix Mail System:/nonexistent:/nonexistent kyra.unloved.org group diffs: 93a94 > postfix:*:3024: Verifying group file syntax: Backing up mail aliases: kyra.unloved.org aliases diffs: --- /var/backups/aliases.bak Thu Sep 21 17:28:04 2000 +++ /etc/mail/aliases Mon Jan 22 11:02:55 2001 @@ -1,4 +1,4 @@ -# $FreeBSD: src/etc/mail/aliases,v 1.10.4.1 2000/08/27 17:31:38 gshapiro Exp $ +# $FreeBSD: src/etc/mail/aliases,v 1.10.4.2 2000/12/16 07:03:35 dougb Exp $ # @(#)aliases 5.3 (Berkeley) 5/24/90 # # Aliases in this file will NOT be expanded in the header from @@ -24,8 +24,10 @@ # General redirections for pseudo accounts bin: root +bind: root daemon: root games: root +kmem: root man: root news: root nobody: root @@ -33,6 +35,7 @@ pop: root system: root toor: root +tty: root usenet: news uucp: root xten: root Disk status: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad5s1a 198399 51629 130899 28% / /dev/ad5s2e 9505261 539884 8204957 6% /data /dev/ad5s1f 8473272 2924146 4871265 38% /usr /dev/ad5s1e 992239 18696 894164 2% /var procfs 4 4 0 100% /proc Last dump(s) done (Dump '>' file systems): UUCP status: Network interface status: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll xl0 1500 00:10:4b:09:ec:f0 49045770 0 84287087 4 0 xl0 1500 62.58.62.160/ kyra 49045770 0 84287087 4 0 xl0 1500 jacquie.would jacquie.would.b 49045770 0 84287087 4 0 xl0 1500 my.pussy.gets my.pussy.gets.w 49045770 0 84287087 4 0 xl0 1500 jacquie.loves jacquie.loves.a 49045770 0 84287087 4 0 xl0 1500 twilight.bast twilight.bastar 49045770 0 84287087 4 0 xl0 1500 freebsd.is.be freebsd.is.bett 49045770 0 84287087 4 0 xl0 1500 magic.kablast magic.kablasto. 49045770 0 84287087 4 0 xl0 1500 i.own.decix.n i.own.decix.net 49045770 0 84287087 4 0 xl0 1500 teefers.is.th teefers.is.thra 49045770 0 84287087 4 0 xl0 1500 i.fucked.freu i.fucked.freudi 49045770 0 84287087 4 0 xl0 1500 jacquie.swall jacquie.swallow 49045770 0 84287087 4 0 xl0 1500 unhappy.and/3 unhappy.and 49045770 0 84287087 4 0 xl0 1500 attyz.wants.t attyz.wants.to. 49045770 0 84287087 4 0 xl0 1500 jacquie.is.a. jacquie.is.a.cu 49045770 0 84287087 4 0 xl0 1500 i.am.not.real i.am.not.really 49045770 0 84287087 4 0 xl0 1500 you.need.a.go you.need.a.good 49045770 0 84287087 4 0 xl0 1500 will.never.be will.never.be 49045770 0 84287087 4 0 xl0 1500 vanitywhore.o vanitywhore.org 49045770 0 84287087 4 0 xl0 1500 is.a.masturba is.a.masturbati 49045770 0 84287087 4 0 xl0 1500 works.for.ver works.for.versa 49045770 0 84287087 4 0 xl0 1500 deeply.shallo deeply.shallow. 49045770 0 84287087 4 0 xl0 1500 62.58.48.84/3 62.58.48.84 49045770 0 84287087 4 0 lo0 16384 5114 0 5114 0 0 lo0 16384 127 localhost 5114 0 5114 0 0 Local system status: 3:01AM up 15:55, 1 user, load averages: 0.00, 0.00, 0.00 Mail in local queue: Mail queue is empty Security check: (output mailed separately) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 18: 8:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from kyra.unloved.org (kyra.unloved.org [62.58.62.162]) by hub.freebsd.org (Postfix) with ESMTP id B9C1237B402; Mon, 22 Jan 2001 18:06:15 -0800 (PST) Received: by kyra.unloved.org (Postfix) id E543DF431; Tue, 23 Jan 2001 03:06:14 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix) via BOUNCE id B6B6FF40E; Tue, 23 Jan 2001 03:06:14 +0100 (CET) Date: Tue, 23 Jan 2001 03:06:14 +0100 (CET) From: MAILER-DAEMON@unloved.org (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: root@unloved.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="13586F431.980215574/kyra.unloved.org" Message-Id: <20010123020614.B6B6FF40E@kyra.unloved.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a MIME-encapsulated message. --13586F431.980215574/kyra.unloved.org Content-Description: Notification Content-Type: text/plain This is the Postfix program at host kyra.unloved.org. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <$header_To@unloved.org>: unknown user: "$header_to" <$home/Mail/lists/freebsd-arch@unloved.org>: unknown user: "$home/mail/lists/freebsd-arch" <$home/Mail/lists/bugtraq@unloved.org>: unknown user: "$home/mail/lists/bugtraq" <$home/Mail/lists/freebsd-current@unloved.org>: unknown user: "$home/mail/lists/freebsd-current" <$home/Mail/lists/freebsd-cvs@unloved.org>: unknown user: "$home/mail/lists/freebsd-cvs" <$home/Mail/lists/freebsd-security@unloved.org>: unknown user: "$home/mail/lists/freebsd-security" <$home/Mail/lists/freeciv@unloved.org>: unknown user: "$home/mail/lists/freeciv" <^freeciv-dev@unloved.org>: unknown user: "^freeciv-dev" : unknown user: "contains" : unknown user: "endif" : unknown user: "if" : unknown user: "matches" : unknown user: "or" : unknown user: "save" : unknown user: "then" <$header_sender@unloved.org>: unknown user: "$header_sender" <$header_X-list@unloved.org>: unknown user: "$header_x-list" <$header_Cc@unloved.org>: unknown user: "$header_cc" --13586F431.980215574/kyra.unloved.org Content-Description: Delivery error report Content-Type: message/delivery-status Reporting-MTA: dns; kyra.unloved.org Arrival-Date: Tue, 23 Jan 2001 03:06:08 +0100 (CET) Final-Recipient: rfc822; $header_To@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_to" Final-Recipient: rfc822; $home/Mail/lists/freebsd-arch@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-arch" Final-Recipient: rfc822; $home/Mail/lists/bugtraq@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/bugtraq" Final-Recipient: rfc822; $home/Mail/lists/freebsd-current@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-current" Final-Recipient: rfc822; $home/Mail/lists/freebsd-cvs@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-cvs" Final-Recipient: rfc822; $home/Mail/lists/freebsd-security@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-security" Final-Recipient: rfc822; $home/Mail/lists/freeciv@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freeciv" Final-Recipient: rfc822; ^freeciv-dev@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "^freeciv-dev" Final-Recipient: rfc822; contains@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "contains" Final-Recipient: rfc822; endif@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "endif" Final-Recipient: rfc822; if@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "if" Final-Recipient: rfc822; matches@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "matches" Final-Recipient: rfc822; or@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "or" Final-Recipient: rfc822; save@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "save" Final-Recipient: rfc822; then@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "then" Final-Recipient: rfc822; $header_sender@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_sender" Final-Recipient: rfc822; $header_X-list@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_x-list" Final-Recipient: rfc822; $header_Cc@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_cc" --13586F431.980215574/kyra.unloved.org Content-Description: Undelivered Message Content-Type: message/rfc822 Received: by kyra.unloved.org (Postfix) id 13586F431; Tue, 23 Jan 2001 03:06:08 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix, from userid 0) id 7E839F40E; Tue, 23 Jan 2001 03:06:07 +0100 (CET) To: root@unloved.org Subject: kyra.unloved.org daily run output Message-Id: <20010123020607.7E839F40E@kyra.unloved.org> Date: Tue, 23 Jan 2001 03:06:07 +0100 (CET) From: root@unloved.org (Charlie Root) Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: kyra.unloved.org passwd diffs: 68d67 < orion:(password):2004:2004::0:0:Orion Server:/home/orion:/usr/local/bin/bash 69a69 > postfix:(password):2001:3024::0:0:Postfix Mail System:/nonexistent:/nonexistent kyra.unloved.org group diffs: 93a94 > postfix:*:3024: Verifying group file syntax: Backing up mail aliases: kyra.unloved.org aliases diffs: --- /var/backups/aliases.bak Thu Sep 21 17:28:04 2000 +++ /etc/mail/aliases Mon Jan 22 11:02:55 2001 @@ -1,4 +1,4 @@ -# $FreeBSD: src/etc/mail/aliases,v 1.10.4.1 2000/08/27 17:31:38 gshapiro Exp $ +# $FreeBSD: src/etc/mail/aliases,v 1.10.4.2 2000/12/16 07:03:35 dougb Exp $ # @(#)aliases 5.3 (Berkeley) 5/24/90 # # Aliases in this file will NOT be expanded in the header from @@ -24,8 +24,10 @@ # General redirections for pseudo accounts bin: root +bind: root daemon: root games: root +kmem: root man: root news: root nobody: root @@ -33,6 +35,7 @@ pop: root system: root toor: root +tty: root usenet: news uucp: root xten: root Disk status: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad5s1a 198399 51629 130899 28% / /dev/ad5s2e 9505261 539884 8204957 6% /data /dev/ad5s1f 8473272 2924146 4871265 38% /usr /dev/ad5s1e 992239 18696 894164 2% /var procfs 4 4 0 100% /proc Last dump(s) done (Dump '>' file systems): UUCP status: Network interface status: Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll xl0 1500 00:10:4b:09:ec:f0 49045770 0 84287087 4 0 xl0 1500 62.58.62.160/ kyra 49045770 0 84287087 4 0 xl0 1500 jacquie.would jacquie.would.b 49045770 0 84287087 4 0 xl0 1500 my.pussy.gets my.pussy.gets.w 49045770 0 84287087 4 0 xl0 1500 jacquie.loves jacquie.loves.a 49045770 0 84287087 4 0 xl0 1500 twilight.bast twilight.bastar 49045770 0 84287087 4 0 xl0 1500 freebsd.is.be freebsd.is.bett 49045770 0 84287087 4 0 xl0 1500 magic.kablast magic.kablasto. 49045770 0 84287087 4 0 xl0 1500 i.own.decix.n i.own.decix.net 49045770 0 84287087 4 0 xl0 1500 teefers.is.th teefers.is.thra 49045770 0 84287087 4 0 xl0 1500 i.fucked.freu i.fucked.freudi 49045770 0 84287087 4 0 xl0 1500 jacquie.swall jacquie.swallow 49045770 0 84287087 4 0 xl0 1500 unhappy.and/3 unhappy.and 49045770 0 84287087 4 0 xl0 1500 attyz.wants.t attyz.wants.to. 49045770 0 84287087 4 0 xl0 1500 jacquie.is.a. jacquie.is.a.cu 49045770 0 84287087 4 0 xl0 1500 i.am.not.real i.am.not.really 49045770 0 84287087 4 0 xl0 1500 you.need.a.go you.need.a.good 49045770 0 84287087 4 0 xl0 1500 will.never.be will.never.be 49045770 0 84287087 4 0 xl0 1500 vanitywhore.o vanitywhore.org 49045770 0 84287087 4 0 xl0 1500 is.a.masturba is.a.masturbati 49045770 0 84287087 4 0 xl0 1500 works.for.ver works.for.versa 49045770 0 84287087 4 0 xl0 1500 deeply.shallo deeply.shallow. 49045770 0 84287087 4 0 xl0 1500 62.58.48.84/3 62.58.48.84 49045770 0 84287087 4 0 lo0 16384 5114 0 5114 0 0 lo0 16384 127 localhost 5114 0 5114 0 0 Local system status: 3:01AM up 15:55, 1 user, load averages: 0.00, 0.00, 0.00 Mail in local queue: Mail queue is empty Security check: (output mailed separately) --13586F431.980215574/kyra.unloved.org-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 18: 8:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from kyra.unloved.org (kyra.unloved.org [62.58.62.162]) by hub.freebsd.org (Postfix) with ESMTP id 5D1C937B404; Mon, 22 Jan 2001 18:06:17 -0800 (PST) Received: by kyra.unloved.org (Postfix) id 71C2CF432; Tue, 23 Jan 2001 03:06:16 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix) via BOUNCE id 24DA6F40E; Tue, 23 Jan 2001 03:06:16 +0100 (CET) Date: Tue, 23 Jan 2001 03:06:16 +0100 (CET) From: MAILER-DAEMON@unloved.org (Mail Delivery System) Subject: Undelivered Mail Returned to Sender To: root@unloved.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="162E6F432.980215576/kyra.unloved.org" Message-Id: <20010123020616.24DA6F40E@kyra.unloved.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a MIME-encapsulated message. --162E6F432.980215576/kyra.unloved.org Content-Description: Notification Content-Type: text/plain This is the Postfix program at host kyra.unloved.org. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program <$header_Cc@unloved.org>: unknown user: "$header_cc" <$header_sender@unloved.org>: unknown user: "$header_sender" <$home/Mail/lists/bugtraq@unloved.org>: unknown user: "$home/mail/lists/bugtraq" <$home/Mail/lists/freebsd-arch@unloved.org>: unknown user: "$home/mail/lists/freebsd-arch" <$home/Mail/lists/freebsd-current@unloved.org>: unknown user: "$home/mail/lists/freebsd-current" <$home/Mail/lists/freebsd-security@unloved.org>: unknown user: "$home/mail/lists/freebsd-security" <$home/Mail/lists/freeciv@unloved.org>: unknown user: "$home/mail/lists/freeciv" <^freeciv-dev@unloved.org>: unknown user: "^freeciv-dev" : unknown user: "contains" : unknown user: "endif" : unknown user: "if" : unknown user: "matches" : unknown user: "or" : unknown user: "save" : unknown user: "then" <$header_To@unloved.org>: unknown user: "$header_to" <$header_X-list@unloved.org>: unknown user: "$header_x-list" <$home/Mail/lists/freebsd-cvs@unloved.org>: unknown user: "$home/mail/lists/freebsd-cvs" --162E6F432.980215576/kyra.unloved.org Content-Description: Delivery error report Content-Type: message/delivery-status Reporting-MTA: dns; kyra.unloved.org Arrival-Date: Tue, 23 Jan 2001 03:06:08 +0100 (CET) Final-Recipient: rfc822; $header_Cc@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_cc" Final-Recipient: rfc822; $header_sender@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_sender" Final-Recipient: rfc822; $home/Mail/lists/bugtraq@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/bugtraq" Final-Recipient: rfc822; $home/Mail/lists/freebsd-arch@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-arch" Final-Recipient: rfc822; $home/Mail/lists/freebsd-current@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-current" Final-Recipient: rfc822; $home/Mail/lists/freebsd-security@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-security" Final-Recipient: rfc822; $home/Mail/lists/freeciv@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freeciv" Final-Recipient: rfc822; ^freeciv-dev@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "^freeciv-dev" Final-Recipient: rfc822; contains@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "contains" Final-Recipient: rfc822; endif@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "endif" Final-Recipient: rfc822; if@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "if" Final-Recipient: rfc822; matches@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "matches" Final-Recipient: rfc822; or@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "or" Final-Recipient: rfc822; save@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "save" Final-Recipient: rfc822; then@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "then" Final-Recipient: rfc822; $header_To@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_to" Final-Recipient: rfc822; $header_X-list@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$header_x-list" Final-Recipient: rfc822; $home/Mail/lists/freebsd-cvs@unloved.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; unknown user: "$home/mail/lists/freebsd-cvs" --162E6F432.980215576/kyra.unloved.org Content-Description: Undelivered Message Content-Type: message/rfc822 Received: by kyra.unloved.org (Postfix) id 162E6F432; Tue, 23 Jan 2001 03:06:08 +0100 (CET) Delivered-To: ashp@unloved.org Received: by kyra.unloved.org (Postfix, from userid 0) id 1CCE2F40C; Tue, 23 Jan 2001 03:06:07 +0100 (CET) Subject: kyra.unloved.org security check output Message-Id: <20010123020607.1CCE2F40C@kyra.unloved.org> Date: Tue, 23 Jan 2001 03:06:07 +0100 (CET) From: root@unloved.org (Charlie Root) To: undisclosed-recipients: ; Checking setuid files and devices: kyra.unloved.org setuid diffs: 1,54c1,52 < 21616 -r-xr-sr-x 1 root operator 56964 Oct 29 23:03:40 2000 /bin/df < 21532 -r-sr-xr-x 1 root wheel 241844 Oct 29 23:03:44 2000 /bin/rcp < 35919 -r-xr-sr-x 1 root kmem 62800 Oct 29 23:06:25 2000 /sbin/ccdconfig < 35863 -r-xr-sr-x 1 root kmem 69488 Oct 29 23:06:27 2000 /sbin/dmesg < 36290 -r-xr-sr-x 2 root tty 257044 Oct 29 23:06:27 2000 /sbin/dump < 35898 -r-sr-xr-x 1 root wheel 195636 Oct 29 23:06:42 2000 /sbin/ping < 35899 -r-sr-xr-x 1 root bin 190864 Oct 29 23:06:43 2000 /sbin/ping6 < 36290 -r-xr-sr-x 2 root tty 257044 Oct 29 23:06:27 2000 /sbin/rdump < 36041 -r-xr-sr-x 2 root tty 283376 Oct 29 23:06:44 2000 /sbin/restore < 35901 -r-sr-xr-x 1 root wheel 191712 Oct 29 23:06:44 2000 /sbin/route < 36041 -r-xr-sr-x 2 root tty 283376 Oct 29 23:06:44 2000 /sbin/rrestore < 35906 -r-sr-x--- 1 root operator 164524 Oct 29 23:06:46 2000 /sbin/shutdown < 8500 -r-sr-xr-x 4 root wheel 19324 Oct 29 23:07:48 2000 /usr/bin/at < 8500 -r-sr-xr-x 4 root wheel 19324 Oct 29 23:07:48 2000 /usr/bin/atq < 8500 -r-sr-xr-x 4 root wheel 19324 Oct 29 23:07:48 2000 /usr/bin/atrm < 8500 -r-sr-xr-x 4 root wheel 19324 Oct 29 23:07:48 2000 /usr/bin/batch < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/chfn < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/chpass < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/chsh < 8235 -r-sr-xr-x 1 root wheel 23912 Oct 29 23:08:54 2000 /usr/bin/crontab < 8490 -r-sr-sr-x 1 uucp dialer 123456 Oct 29 23:04:16 2000 /usr/bin/cu < 8071 -r-xr-sr-x 1 root kmem 12900 Oct 29 23:08:00 2000 /usr/bin/fstat < 8087 -r-xr-sr-x 1 root kmem 9624 Oct 29 23:08:03 2000 /usr/bin/ipcs < 8026 -r-sr-xr-x 1 root wheel 510 Oct 29 23:08:04 2000 /usr/bin/keyinfo < 8094 -r-sr-xr-x 1 root wheel 7232 Oct 29 23:08:04 2000 /usr/bin/keyinit < 8110 -r-sr-xr-x 1 root wheel 6792 Oct 29 23:08:11 2000 /usr/bin/lock < 8113 -r-sr-xr-x 1 root wheel 19556 Oct 29 23:08:11 2000 /usr/bin/login < 8239 -r-sr-sr-x 1 root daemon 19796 Oct 29 23:09:35 2000 /usr/bin/lpq < 8240 -r-sr-sr-x 1 root daemon 22996 Oct 29 23:09:35 2000 /usr/bin/lpr < 8241 -r-sr-sr-x 1 root daemon 19132 Oct 29 23:09:36 2000 /usr/bin/lprm < 7984 -r-sr-xr-x 1 man wheel 28304 Oct 29 23:04:54 2000 /usr/bin/man < 8136 -r-xr-sr-x 1 root kmem 84736 Oct 29 23:08:16 2000 /usr/bin/netstat < 8138 -r-xr-sr-x 1 root kmem 9660 Oct 29 23:08:16 2000 /usr/bin/nfsstat < 8462 -r-sr-xr-x 2 root wheel 26356 Oct 29 23:08:18 2000 /usr/bin/passwd < 8148 -r-sr-xr-x 1 root wheel 10232 Oct 29 23:08:19 2000 /usr/bin/quota < 8152 -r-sr-xr-x 1 root wheel 9976 Oct 29 23:08:20 2000 /usr/bin/rlogin < 8156 -r-sr-xr-x 1 root wheel 7372 Oct 29 23:08:22 2000 /usr/bin/rsh < 8467 -r-sr-xr-x 2 root wheel 147872 Oct 29 23:10:00 2000 /usr/bin/slogin < 8467 -r-sr-xr-x 2 root wheel 147872 Oct 29 23:10:00 2000 /usr/bin/ssh < 8168 -r-sr-xr-x 1 root wheel 7960 Oct 29 23:08:24 2000 /usr/bin/su < 8171 -r-xr-sr-x 1 root kmem 56648 Oct 29 23:08:25 2000 /usr/bin/systat < 8179 -r-xr-sr-x 1 root kmem 32104 Oct 29 23:08:27 2000 /usr/bin/top < 8489 -r-sr-xr-x 1 uucp wheel 87984 Oct 29 23:04:18 2000 /usr/bin/uucp < 8350 -r-sr-xr-x 1 uucp wheel 37100 Oct 29 23:04:18 2000 /usr/bin/uuname < 8279 -r-sr-sr-x 1 uucp dialer 96540 Oct 29 23:04:19 2000 /usr/bin/uustat < 8274 -r-sr-xr-x 1 uucp wheel 88600 Oct 29 23:04:19 2000 /usr/bin/uux < 8200 -r-xr-sr-x 1 root kmem 16392 Oct 29 23:08:35 2000 /usr/bin/vmstat < 8201 -r-xr-sr-x 1 root tty 8860 Oct 29 23:08:35 2000 /usr/bin/wall < 8208 -r-xr-sr-x 1 root tty 7288 Oct 29 23:08:37 2000 /usr/bin/write < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/ypchfn < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/ypchpass < 8317 -r-sr-xr-x 6 root wheel 31972 Oct 29 23:07:52 2000 /usr/bin/ypchsh < 8462 -r-sr-xr-x 2 root wheel 26356 Oct 29 23:08:18 2000 /usr/bin/yppasswd < 1190465 -r-xr-sr-x 1 root games 6964 Oct 29 23:03:54 2000 /usr/games/dm --- > 21620 -r-xr-sr-x 1 root operator 56892 Jan 22 09:47:23 2001 /bin/df > 21532 -r-sr-xr-x 1 root wheel 241840 Jan 22 09:47:30 2001 /bin/rcp > 35924 -r-xr-sr-x 1 root kmem 62792 Jan 22 09:52:51 2001 /sbin/ccdconfig > 35863 -r-xr-sr-x 1 root kmem 69544 Jan 22 09:52:55 2001 /sbin/dmesg > 36344 -r-xr-sr-x 2 root tty 257100 Jan 22 09:52:56 2001 /sbin/dump > 35898 -r-sr-xr-x 1 root wheel 195660 Jan 22 09:53:19 2001 /sbin/ping > 35899 -r-sr-xr-x 1 root bin 190888 Jan 22 09:53:20 2001 /sbin/ping6 > 36344 -r-xr-sr-x 2 root tty 257100 Jan 22 09:52:56 2001 /sbin/rdump > 36159 -r-xr-sr-x 2 root tty 283372 Jan 22 09:53:22 2001 /sbin/restore > 35901 -r-sr-xr-x 1 root wheel 191736 Jan 22 09:53:23 2001 /sbin/route > 36159 -r-xr-sr-x 2 root tty 283372 Jan 22 09:53:22 2001 /sbin/rrestore > 35906 -r-sr-x--- 1 root operator 164484 Jan 22 09:53:26 2001 /sbin/shutdown > 8383 -r-sr-xr-x 4 root wheel 19540 Jan 22 09:56:32 2001 /usr/bin/at > 8383 -r-sr-xr-x 4 root wheel 19540 Jan 22 09:56:32 2001 /usr/bin/atq > 8383 -r-sr-xr-x 4 root wheel 19540 Jan 22 09:56:32 2001 /usr/bin/atrm > 8383 -r-sr-xr-x 4 root wheel 19540 Jan 22 09:56:32 2001 /usr/bin/batch > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/chfn > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/chpass > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/chsh > 8235 -r-sr-xr-x 1 root wheel 24508 Jan 22 09:58:53 2001 /usr/bin/crontab > 8334 -r-sr-sr-x 1 uucp dialer 123856 Jan 22 09:48:31 2001 /usr/bin/cu > 8071 -r-xr-sr-x 1 root kmem 13108 Jan 22 09:56:58 2001 /usr/bin/fstat > 8087 -r-xr-sr-x 1 root kmem 9832 Jan 22 09:57:07 2001 /usr/bin/ipcs > 8025 -r-sr-xr-x 1 root wheel 510 Jan 22 09:57:09 2001 /usr/bin/keyinfo > 8094 -r-sr-xr-x 1 root wheel 7444 Jan 22 09:57:09 2001 /usr/bin/keyinit > 8110 -r-sr-xr-x 1 root wheel 7004 Jan 22 09:57:21 2001 /usr/bin/lock > 8113 -r-sr-xr-x 1 root wheel 19764 Jan 22 09:57:22 2001 /usr/bin/login > 8239 -r-sr-sr-x 1 root daemon 22728 Jan 22 10:00:25 2001 /usr/bin/lpq > 8240 -r-sr-sr-x 1 root daemon 26312 Jan 22 10:00:26 2001 /usr/bin/lpr > 8241 -r-sr-sr-x 1 root daemon 21612 Jan 22 10:00:27 2001 /usr/bin/lprm > 7984 -r-sr-xr-x 1 man wheel 27872 Jan 22 09:49:48 2001 /usr/bin/man > 8136 -r-xr-sr-x 1 root kmem 85104 Jan 22 09:57:32 2001 /usr/bin/netstat > 8138 -r-xr-sr-x 1 root kmem 9936 Jan 22 09:57:33 2001 /usr/bin/nfsstat > 8439 -r-sr-xr-x 2 root wheel 26564 Jan 22 09:57:39 2001 /usr/bin/passwd > 8148 -r-sr-xr-x 1 root wheel 10440 Jan 22 09:57:42 2001 /usr/bin/quota > 8152 -r-sr-xr-x 1 root wheel 10216 Jan 22 09:57:44 2001 /usr/bin/rlogin > 8156 -r-sr-xr-x 1 root wheel 7584 Jan 22 09:57:46 2001 /usr/bin/rsh > 8168 -r-sr-xr-x 1 root wheel 8168 Jan 22 09:57:53 2001 /usr/bin/su > 8171 -r-xr-sr-x 1 root kmem 56144 Jan 22 09:57:54 2001 /usr/bin/systat > 8179 -r-xr-sr-x 1 root kmem 32344 Jan 22 09:57:58 2001 /usr/bin/top > 8337 -r-sr-xr-x 1 uucp wheel 88228 Jan 22 09:48:33 2001 /usr/bin/uucp > 8340 -r-sr-xr-x 1 uucp wheel 37312 Jan 22 09:48:34 2001 /usr/bin/uuname > 8292 -r-sr-sr-x 1 uucp dialer 96752 Jan 22 09:48:35 2001 /usr/bin/uustat > 8279 -r-sr-xr-x 1 uucp wheel 88844 Jan 22 09:48:35 2001 /usr/bin/uux > 8200 -r-xr-sr-x 1 root kmem 15952 Jan 22 09:58:16 2001 /usr/bin/vmstat > 8201 -r-xr-sr-x 1 root tty 9072 Jan 22 09:58:17 2001 /usr/bin/wall > 8208 -r-xr-sr-x 1 root tty 7500 Jan 22 09:58:21 2001 /usr/bin/write > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/ypchfn > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/ypchpass > 8384 -r-sr-xr-x 6 root wheel 32184 Jan 22 09:56:43 2001 /usr/bin/ypchsh > 8439 -r-sr-xr-x 2 root wheel 26564 Jan 22 09:57:39 2001 /usr/bin/yppasswd > 1190465 -r-xr-sr-x 1 root games 7176 Jan 22 09:47:43 2001 /usr/games/dm 57,58c55,56 < 1190520 -r-sr-sr-x 1 uucp dialer 220460 Oct 29 23:04:16 2000 /usr/libexec/uucp/uucico < 1190524 -r-sr-s--- 1 uucp uucp 99340 Oct 29 23:04:19 2000 /usr/libexec/uucp/uuxqt --- > 1190520 -r-sr-sr-x 1 uucp dialer 220672 Jan 22 09:48:32 2001 /usr/libexec/uucp/uucico > 1190524 -r-sr-s--- 1 uucp uucp 99584 Jan 22 09:48:36 2001 /usr/libexec/uucp/uuxqt 62,74d59 < 1801974 -r-xr-sr-x 1 bin mail 26080 Oct 19 21:40:14 2000 /usr/local/libexec/cucipop < 1024241 -rwxr-sr-x 1 root mailman 16329 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/admin < 1024242 -rwxr-sr-x 1 root mailman 16333 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/admindb < 1024243 -rwxr-sr-x 1 root mailman 16341 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/archives < 1024244 -rwxr-sr-x 1 root mailman 16341 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/edithtml < 1024249 -rwxr-sr-x 1 root mailman 16349 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/handle_opts < 1024246 -rwxr-sr-x 1 root mailman 16341 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/listinfo < 1024245 -rwxr-sr-x 1 root mailman 16333 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/options < 1024250 -rwxr-sr-x 1 root mailman 16333 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/private < 1024248 -rwxr-sr-x 1 root mailman 16329 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/roster < 1024247 -rwxr-sr-x 1 root mailman 16345 Jan 12 13:45:48 2001 /usr/local/mailman/cgi-bin/subscribe < 1064052 -rwxr-sr-x 1 root mailman 16867 Jan 12 13:45:48 2001 /usr/local/mailman/mail/wrapper < 1627111 -rwsr-xr-x 1 root wheel 543149 Dec 23 15:29:16 2000 /usr/local/sbin/exim 76,89c61,75 < 1214251 -r-xr-sr-x 1 root kmem 4456 Oct 29 23:08:59 2000 /usr/sbin/ifmcstat < 1214253 -r-xr-sr-x 1 root kmem 10116 Oct 29 23:08:59 2000 /usr/sbin/iostat < 1214359 -r-xr-sr-x 1 root daemon 26784 Oct 29 23:09:35 2000 /usr/sbin/lpc < 1214276 -r-sr-xr-x 1 root wheel 16136 Oct 29 23:09:04 2000 /usr/sbin/mrinfo < 1214278 -r-sr-xr-x 1 root wheel 29688 Oct 29 23:09:04 2000 /usr/sbin/mtrace < 1214402 -r-sr-xr-- 1 root network 283964 Oct 29 23:09:15 2000 /usr/sbin/ppp < 1214403 -r-sr-xr-x 1 root wheel 96080 Oct 29 23:09:16 2000 /usr/sbin/pppd < 1214629 -r-xr-sr-x 2 root kmem 14368 Oct 29 23:09:17 2000 /usr/sbin/pstat < 1214327 -r-sr-x--- 1 root network 10776 Oct 29 23:09:23 2000 /usr/sbin/sliplogin < 1214629 -r-xr-sr-x 2 root kmem 14368 Oct 29 23:09:17 2000 /usr/sbin/swapinfo < 1214336 -r-sr-xr-x 1 root wheel 14900 Oct 29 23:09:26 2000 /usr/sbin/timedc < 1214337 -r-sr-xr-x 1 root wheel 12956 Oct 29 23:09:26 2000 /usr/sbin/traceroute < 1214338 -r-sr-xr-x 1 root bin 14744 Oct 29 23:09:27 2000 /usr/sbin/traceroute6 < 1214339 -r-xr-sr-x 1 root kmem 7832 Oct 29 23:09:27 2000 /usr/sbin/trpt --- > 1627116 -r-xr-sr-x 1 root maildrop 56904 Jan 22 14:34:20 2001 /usr/local/sbin/postdrop > 1214251 -r-xr-sr-x 1 root kmem 4664 Jan 22 09:59:01 2001 /usr/sbin/ifmcstat > 1214253 -r-xr-sr-x 1 root kmem 9608 Jan 22 09:59:02 2001 /usr/sbin/iostat > 1214359 -r-xr-sr-x 1 root daemon 29204 Jan 22 10:00:24 2001 /usr/sbin/lpc > 1214276 -r-sr-xr-x 1 root wheel 16348 Jan 22 09:59:12 2001 /usr/sbin/mrinfo > 1214278 -r-sr-xr-x 1 root wheel 29896 Jan 22 09:59:13 2001 /usr/sbin/mtrace > 1214402 -r-sr-xr-- 1 root network 294100 Jan 22 09:59:41 2001 /usr/sbin/ppp > 1214403 -r-sr-xr-x 1 root wheel 95612 Jan 22 09:59:42 2001 /usr/sbin/pppd > 1214640 -r-xr-sr-x 2 root kmem 14616 Jan 22 09:59:44 2001 /usr/sbin/pstat > 1214327 -r-sr-x--- 1 root network 11112 Jan 22 09:59:56 2001 /usr/sbin/sliplogin > 1214640 -r-xr-sr-x 2 root kmem 14616 Jan 22 09:59:44 2001 /usr/sbin/swapinfo > 1214336 -r-sr-xr-x 1 root wheel 15112 Jan 22 10:00:05 2001 /usr/sbin/timedc > 1214337 -r-sr-xr-x 1 root wheel 13168 Jan 22 10:00:06 2001 /usr/sbin/traceroute > 1214338 -r-sr-xr-x 1 root bin 14952 Jan 22 10:00:06 2001 /usr/sbin/traceroute6 > 1214339 -r-xr-sr-x 1 root kmem 8040 Jan 22 10:00:06 2001 /usr/sbin/trpt Checking for uids of 0: root 0 toor 0 Checking for passwordless accounts: kyra.unloved.org kernel log messages: > Copyright (c) 1992-2001 The FreeBSD Project. > FreeBSD 4.2-STABLE #0: Sun Jan 21 19:59:44 CET 2001 > ashp@kyra.unloved.org:/usr/obj/usr/src/sys/KYRA > avail memory = 258371584 (252316K bytes) kyra.unloved.org login failures: kyra.unloved.org refused connections: --162E6F432.980215576/kyra.unloved.org-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 19:12:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from dante.naver.co.id (unknown [202.155.86.83]) by hub.freebsd.org (Postfix) with ESMTP id 0053C37B402; Mon, 22 Jan 2001 19:12:08 -0800 (PST) Received: by dante.naver.co.id (Postfix, from userid 1000) id B670F5358C; Tue, 23 Jan 2001 10:12:00 +0700 (JAVT) Date: Tue, 23 Jan 2001 10:12:00 +0700 From: John Indra To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org Subject: -CURRENT and XFree86 4.0.2 problem Message-ID: <20010123101200.B542@naver.co.id> Mail-Followup-To: freebsd-ports@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="f2QGlHpHGjS2mn6Y" Content-Disposition: inline X-Mailer: Mutt 1.2.5i on FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear all... First of all, sorry for cross-posting cause I don't know which mailing list is the most appropriate for this kind of question and I think this affects all mailing list I send this mail to. Running -CURRENT with world and kernel of: Thu Jan 18 13:04:05 JAVT 2001 Blew away all /usr/X11R6 and /usr/local to have fresh ports on my system. Then, I install XFree86-4.0.2_5. Now, whenever I enter X (using startx) and try to go to console (Ctrl+Alt+Fx) and then try to get back to X (Alt+F9), X died :( I suspect (from the error log) that this has something to do with Intel 810 chipset and -CURRENT agp module. Attached is /var/log/XFree86.0.log Thanks... /john --f2QGlHpHGjS2mn6Y Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="XFree86.0.log" XFree86 Version 4.0.2 / X Window System (protocol Version 11, revision 0, vendor release 6400) Release Date: 18 December 2000 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/FAQ) Operating System: FreeBSD 5.0-CURRENT i386 [ELF] Module Loader present (==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan 23 09:27:23 2001 (==) Using config file: "/etc/X11/XF86Config" Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (??) unknown. (==) ServerLayout "Simple Layout" (**) |-->Screen "Screen 1" (0) (**) | |-->Monitor "My Monitor" (**) | |-->Device "My VGA Card" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard1" (**) Option "AutoRepeat" "500 30" (WW) Option "XkbCompat" requires an string value (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc104" (**) XKB: model: "pc104" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (**) FontPath set to "unix/:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (II) xf86ReadBIOS(f8000, e80, Buf, 2)-> b4 09 2c fb... (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.3 XFree86 XInput driver : 0.1 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.2 (II) Loader running on freebsd (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.0.2, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.2 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.0.2, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.3 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1130 card 1043,8027 rev 02 class 06,00,00 hdr 00 (II) PCI: 00:02:0: chip 8086,1132 card 1043,8027 rev 02 class 03,00,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card 0000,0000 rev 01 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card 0000,0000 rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card 1043,8027 rev 01 class 01,01,80 hdr 00 (II) PCI: 00:1f:3: chip 8086,2443 card 1043,8027 rev 01 class 0c,05,00 hdr 00 (II) PCI: 01:0a:0: chip 10b7,9200 card 10b7,1000 rev 6c class 02,00,00 hdr 00 (II) PCI: 01:0b:0: chip 1274,5880 card 1274,2000 rev 02 class 04,01,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: "scanpci" (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor="The XFree86 Project" compiled for 4.0.2, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.3 (II) UnloadModule: "scanpci" (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x00 (VGA_EN is cleared) (II) Bus 0 I/O range: [0] -1 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0x00000000 - 0xffffffff (0x0) MX[B] (II) Bus 1: bridge is at (0:30:0), (0,1,1), BCTRL: 0x06 (VGA_EN is cleared) (II) Bus 1 I/O range: [0] -1 0x0000d000 - 0x0000d0ff (0x100) IX[B] [1] -1 0x0000d400 - 0x0000d4ff (0x100) IX[B] [2] -1 0x0000d800 - 0x0000d8ff (0x100) IX[B] [3] -1 0x0000dc00 - 0x0000dcff (0x100) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0xf6800000 - 0xf6ffffff (0x800000) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0xf7f00000 - 0xf7ffffff (0x100000) MX[B] (II) Bus -1: bridge is at (0:31:0), (0,-1,0), BCTRL: 0x00 (VGA_EN is cleared) (II) Bus -1 I/O range: (II) Bus -1 non-prefetchable memory range: (II) Bus -1 prefetchable memory range: (--) PCI:*(0:2:0) Intel i815 rev 2, Mem @ 0xf8000000/26, 0xf7000000/19 (II) Addressable bus resource ranges are [0] -1 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0x00000000 - 0x000001ff (0x200) IX[B]E (II) Active PCI resource ranges: [0] -1 0xf6800000 - 0xf6ffffff (0x800000) MX[B]E [1] -1 0xf7000000 - 0xf707ffff (0x80000) MX[B](B) [2] -1 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [3] -1 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [4] -1 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [5] -1 0x0000e800 - 0x0000e8ff (0x100) IX[B]E [6] -1 0x0000b800 - 0x0000b8ff (0x100) IX[B]E (II) Active PCI resource ranges after removing overlaps: [0] -1 0xf6800000 - 0xf6ffffff (0x800000) MX[B]E [1] -1 0xf7000000 - 0xf707ffff (0x80000) MX[B](B) [2] -1 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [3] -1 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [4] -1 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [5] -1 0x0000e800 - 0x0000e8ff (0x100) IX[B]E [6] -1 0x0000b800 - 0x0000b8ff (0x100) IX[B]E (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0x00000000 - 0x000001ff (0x200) IX[B]E (II) All system resource ranges: [0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0xf6800000 - 0xf6ffffff (0x800000) MX[B]E [6] -1 0xf7000000 - 0xf707ffff (0x80000) MX[B](B) [7] -1 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [8] -1 0x00000000 - 0x000001ff (0x200) IX[B]E [9] -1 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [10] -1 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [11] -1 0x0000e800 - 0x0000e8ff (0x100) IX[B]E [12] -1 0x0000b800 - 0x0000b8ff (0x100) IX[B]E (II) LoadModule: "dbe" (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor="The XFree86 Project" compiled for 4.0.2, module version = 1.0.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.1 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a (II) Module extmod: vendor="The XFree86 Project" compiled for 4.0.2, module version = 1.0.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.1 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension DPMS (II) Loading extension FontCache (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) LoadModule: "type1" (II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a (II) Module type1: vendor="The XFree86 Project" compiled for 4.0.2, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.2 (II) Loading font Type1 (II) Loading font CID (II) LoadModule: "freetype" (II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.a (II) Module freetype: vendor="The XFree86 Project" compiled for 4.0.2, module version = 1.1.8 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.2 (II) Loading font FreeType (II) LoadModule: "i810" (II) Loading /usr/X11R6/lib/modules/drivers/i810_drv.o (II) Module i810: vendor="The XFree86 Project" compiled for 4.0.2, module version = 1.0.0 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.3 (II) LoadModule: "mouse" (II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o (II) Module mouse: vendor="The XFree86 Project" compiled for 4.0.2, module version = 1.0.0 Module class: XFree86 XInput Driver ABI class: XFree86 XInput driver, version 0.1 (II) I810: Driver for Intel i810 chipset: i810, i810-dc100, i810e, i815 (II) Primary Device is: PCI 00:02:0 (--) Assigning device section with no busID to primary device (--) Chipset i815 found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0xf6800000 - 0xf6ffffff (0x800000) MX[B]E [6] -1 0xf7000000 - 0xf707ffff (0x80000) MX[B](B) [7] -1 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [8] -1 0x00000000 - 0x000001ff (0x200) IX[B]E [9] -1 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [10] -1 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [11] -1 0x0000e800 - 0x0000e8ff (0x100) IX[B]E [12] -1 0x0000b800 - 0x0000b8ff (0x100) IX[B]E (II) resource ranges after probing: [0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0xf6800000 - 0xf6ffffff (0x800000) MX[B]E [6] -1 0xf7000000 - 0xf707ffff (0x80000) MX[B](B) [7] -1 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [8] 0 0x000a0000 - 0x000affff (0x10000) MS[B] [9] 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [10] 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [11] -1 0x00000000 - 0x000001ff (0x200) IX[B]E [12] -1 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [13] -1 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [14] -1 0x0000e800 - 0x0000e8ff (0x100) IX[B]E [15] -1 0x0000b800 - 0x0000b8ff (0x100) IX[B]E [16] 0 0x000003b0 - 0x000003bb (0xc) IS[B] [17] 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor="The XFree86 Project" compiled for 4.0.2, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.3 (**) I810(0): Depth 24, (--) framebuffer bpp 24 (==) I810(0): RGB weight 888 (==) I810(0): Default visual is TrueColor (--) I810(0): Chipset: "i815" (--) I810(0): Linear framebuffer at 0xF8000000 (--) I810(0): IO registers at addr 0xF7000000 (II) I810(0): I810CheckAvailableMemory: 98304k available (**) I810(0): Will alloc AGP framebuffer: 8192 kByte (==) I810(0): Using gamma correction (1.0, 1.0, 1.0) (II) I810(0): My Monitor: Using hsync range of 30.00-70.00 kHz (II) I810(0): My Monitor: Using vrefresh range of 50.00-160.00 Hz (II) I810(0): Clock range: 12.00 to 136.00 MHz (WW) I810(0): Default mode "1280x960" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1280x1024" deleted (hsync out of range) (WW) I810(0): Default mode "1280x1024" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1600x1200" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1600x1200" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1600x1200" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1600x1200" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1600x1200" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1792x1344" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1792x1344" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1856x1392" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1856x1392" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1920x1440" deleted (bad mode clock/interlace/doublescan) (WW) I810(0): Default mode "1920x1440" deleted (bad mode clock/interlace/doublescan) (--) I810(0): Virtual size is 1024x768 (pitch 1024) (**) I810(0): Mode "1024x768": 85.0 MHz, 63.4 kHz, 79.4 Hz (==) I810(0): DPI set to (75, 75) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/X11R6/lib/modules/libfb.a (II) Module fb: vendor="The XFree86 Project" compiled for 4.0.2, module version = 1.0.0 ABI class: XFree86 ANSI C Emulation, version 0.1 (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/X11R6/lib/modules/libxaa.a (II) Module xaa: vendor="The XFree86 Project" compiled for 4.0.2, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.3 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Loading /usr/X11R6/lib/modules/libramdac.a (II) Module ramdac: vendor="The XFree86 Project" compiled for 4.0.2, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.3 Symbol VBEInit from module /usr/X11R6/lib/modules/drivers/i810_drv.o is unresolved! Symbol vbeDoEDID from module /usr/X11R6/lib/modules/drivers/i810_drv.o is unresolved! (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] 0 0xf7000000 - 0xf707ffff (0x80000) MS[B] [1] 0 0xf8000000 - 0xfbffffff (0x4000000) MS[B] [2] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [3] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [4] -1 0x000f0000 - 0x000fffff (0x10000) MX[B] [5] -1 0x000c0000 - 0x000effff (0x30000) MX[B] [6] -1 0x00000000 - 0x0009ffff (0xa0000) MX[B] [7] -1 0xf6800000 - 0xf6ffffff (0x800000) MX[B]E [8] -1 0xf7000000 - 0xf707ffff (0x80000) MX[B](B) [9] -1 0xf8000000 - 0xfbffffff (0x4000000) MX[B](B) [10] 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [11] 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [12] 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [13] -1 0x00000000 - 0x000001ff (0x200) IX[B]E [14] -1 0x0000d400 - 0x0000d4ff (0x100) IX[B]E [15] -1 0x0000d800 - 0x0000d8ff (0x100) IX[B]E [16] -1 0x0000e800 - 0x0000e8ff (0x100) IX[B]E [17] -1 0x0000b800 - 0x0000b8ff (0x100) IX[B]E [18] 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [19] 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (==) I810(0): Write-combining range (0xf7000000,0x80000) was already clear (==) I810(0): Write-combining range (0xf8000000,0x2000000) was already set (==) I810(0): Write-combining range (0xa0000,0x10000) was already clear (II) I810(0): Setting dot clock to 84.9 MHz [ 0x2c 0xb 0x20 ] [ 46 13 2 ] (II) I810(0): chose watermark 0x22218000: (tab.freq 94.5) (WW) I810(0): xf86AllocateGARTMemory: allocation of 1024 pages failed (Cannot allocate memory) (II) I810(0): No physical memory available for 4194304 bytes of DCACHE (II) I810(0): Adding 512 scanlines for pixmap caching (II) I810(0): Allocated Scratch Memory (II) I810(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Horizontal and Vertical Lines Offscreen Pixmaps (==) I810(0): Backing store disabled (==) I810(0): Silken mouse enabled (II) I810(0): direct rendering: Disabled (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension LBX (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (**) Option "Protocol" "MouseSystems" (**) Mouse0: Protocol: "MouseSystems" (**) Option "CorePointer" (**) Mouse0: Core Pointer (**) Option "Device" "/dev/sysmouse" (**) Option "BaudRate" "1200" (**) Option "StopBits" "2" (**) Option "DataBits" "8" (**) Option "Parity" "None" (**) Option "Vmin" "1" (**) Option "Vtime" "0" (**) Option "FlowControl" "None" (==) Mouse0: Buttons: 3 (**) Option "ZAxisMapping" "4 5" (**) Mouse0: ZAxisMapping: buttons 4 and 5 (**) Mouse0: BaudRate: 1200 (II) Keyboard "Keyboard1" handled by legacy driver (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (**) Option "BaudRate" "1200" GetModeLine - scrn: 0 clock: 85000 GetModeLine - hdsp: 1024 hbeg: 1088 hend: 1196 httl: 1340 vdsp: 768 vbeg: 772 vend: 775 vttl: 799 flags: 0 (WW) I810(0): xf86BindGARTMemory: binding of gart memory with key 3 at offset 0x0 failed (No such file or directory) Fatal server error: EnterVT failed for screen 0 When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.0.log". Please report problems to xfree86@xfree86.org. pgetbl_ctl: 0x599001 pgetbl_err: 0x19 ipeir: 0 iphdr: 0 LP ring tail: 8 head: 0 len: 0 start 0 eir: 0 esr: 10 emr: 3d instdone: ff7b instpm: 0 memmode: 24 instps: 0 hwstam: 9ac7 ier: 0 imr: 9ac7 iir: 0 space: 65520 wanted 65528 FatalError re-entered, aborting lockup --f2QGlHpHGjS2mn6Y-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 21:39: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailhost01.reflexnet.net (mailhost01.reflexnet.net [64.6.192.82]) by hub.freebsd.org (Postfix) with ESMTP id 5D4EE37B404 for ; Mon, 22 Jan 2001 21:38:50 -0800 (PST) Received: from rfx-216-196-73-168.users.reflexcom.com ([216.196.73.168]) by mailhost01.reflexnet.net with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 22 Jan 2001 21:36:57 -0800 Received: (from cjc@localhost) by rfx-216-196-73-168.users.reflexcom.com (8.11.1/8.11.0) id f0N5ci536646; Mon, 22 Jan 2001 21:38:44 -0800 (PST) (envelope-from cjc) Date: Mon, 22 Jan 2001 21:38:42 -0800 From: "Crist J. Clark" To: Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: excessive paranoia in syslogd(8)? Message-ID: <20010122213842.O10761@rfx-216-196-73-168.users.reflex> Reply-To: cjclark@alum.mit.edu References: <20010120224944.I387@bonsai.knology.net> <20010120212039.M10761@rfx-216-196-73-168.users.reflex> <200101221740.MAA39988@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200101221740.MAA39988@khavrinen.lcs.mit.edu>; from wollman@khavrinen.lcs.mit.edu on Mon, Jan 22, 2001 at 12:40:00PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 12:40:00PM -0500, Garrett Wollman wrote: > < said: > > > If you want to or need to use network sockets, > > > # syslogd -a localhost > > > Should provide the behavior you want. > > I.e., no security whatsoever. Well, yeah, it's syslogd(8) and as the manpage says, BUGS The ability to log messages received in UDP packets is equivalent to an unauthenticated remote disk-filling service... However, doing 'syslogd -a localhost' should really not be much worse than 'syslogd -s' or '-ss'. In all three cases, a local user can nail you. The only risk I see is 127.0.0.1 being forced in from the LAN, and even then, I can't recall if FreeBSD will ever accept loopback numbers coming in a non-loopback interface. And that still is only local net, 127/8 packets aren't going to be routed. -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 23:13:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by hub.freebsd.org (Postfix) with ESMTP id 1A93D37B400; Mon, 22 Jan 2001 23:13:21 -0800 (PST) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.11.1/8.11.1) id f0N7CkJ03219; Tue, 23 Jan 2001 08:12:46 +0100 (CET) (envelope-from stijn) Date: Tue, 23 Jan 2001 08:12:46 +0100 From: Stijn Hoop To: John Indra Cc: freebsd-ports@freebsd.org, freebsd-current@freebsd.org Subject: Re: -CURRENT and XFree86 4.0.2 problem Message-ID: <20010123081246.A3129@pcwin002.win.tue.nl> References: <20010123101200.B542@naver.co.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010123101200.B542@naver.co.id>; from john@naver.co.id on Tue, Jan 23, 2001 at 10:12:00AM +0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 23, 2001 at 10:12:00AM +0700, John Indra wrote: > Running -CURRENT with world and kernel of: Thu Jan 18 13:04:05 JAVT 2001 > Blew away all /usr/X11R6 and /usr/local to have fresh ports on my system. > Then, I install XFree86-4.0.2_5. > > Now, whenever I enter X (using startx) and try to go to console > (Ctrl+Alt+Fx) and then try to get back to X (Alt+F9), X died :( > > I suspect (from the error log) that this has something to do with Intel 810 > chipset and -CURRENT agp module. FWIW, I have the same problem with a -STABLE from jan. 20th. So the bug is probably also in the -STABLE agp module, or else it is XFree86-4.0.2_5 (I also blew away /usr/local and /usr/X11R6 before installing it). --Stijn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jan 22 23:30:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 5B16237B400; Mon, 22 Jan 2001 23:30:22 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id f0N7UED32260; Tue, 23 Jan 2001 09:30:14 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200101230730.f0N7UED32260@zibbi.icomtek.csir.co.za> Subject: ahc messages To: gibbs@freebsd.org Date: Tue, 23 Jan 2001 09:30:14 +0200 (SAT) Cc: current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On a current SMP box running a kernel from this morning I see messages from the ahc driver I haven't seen before. The machine keeps on running though. Should I worry about them or back down to kernel of yesterday? ahc0: port 0xd000-0xd0ff mem 0xe1000000-0xe1000fff irq 19 at device 6.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: WARNING no command for scb 118 (cmdcmplt) QOUTPOS = 172 (da0:ahc0:0:0:0): SCB 0x33 - timed out while idle, SEQADDR == 0x5 STACK == 0x3, 0x190, 0x160, 0x0 SXFRCTL0 == 0x80 ahc0: Dumping Card State at SEQADDR 0x5 SCB count = 120 Kernel NEXTQSCB = 58 Card NEXTQSCB = 58 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: 10:45 QOUTFIFO entries: Sequencer Free SCB List: 5 4 12 11 8 13 6 0 3 1 15 14 2 7 9 Pending list: 45 51 Kernel Free SCB list: 21 8 44 118 18 7 37 4 3 61 54 22 35 57 25 27 29 20 15 2 50 65 56 46 49 1 10 6 59 39 48 36 11 5 33 67 34 64 28 17 69 66 60 26 30 42 62 13 53 9 23 68 40 96 43 52 31 0 116 47 16 12 24 19 117 119 100 101 102 103 104 105 106 107 108 109 90 91 92 93 94 95 14 38 79 78 77 76 75 74 73 72 71 70 89 88 87 86 85 84 83 82 81 80 99 98 97 55 32 41 63 115 114 113 112 111 110 sg[0] - Addr 0x405c000 : Length 2048 (da0:ahc0:0:0:0): Queuing a BDR SCB (da0:ahc0:0:0:0): Bus Device Reset Message Sent (da0:ahc0:0:0:0): no longer in timeout, status = 34b ahc0: Bus Device Reset on A:0. 1 SCBs aborted John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 1:14:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id E3A0337B401; Tue, 23 Jan 2001 01:13:54 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0N9Dse00521; Tue, 23 Jan 2001 01:13:54 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101230913.f0N9Dse00521@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: msmith@freebsd.org, current@freebsd.org Subject: ACPI glitch Date: Tue, 23 Jan 2001 01:13:54 -0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just a FYI: #2 0xc01f0231 in panic (fmt=0xc031c8c0 "malloc(M_WAITOK) in interrupt context") at ../../kern/kern_shutdown.c:570 #3 0xc01ea192 in malloc (size=28, type=0xc03465c0, flags=0) at ../../kern/kern_malloc.c:151 #4 0xc016a4ce in AcpiOsQueueForExecution (Priority=2, Function=0xc0166e98 , Context=0xc1096e40) at ../../dev/acpica/Osd/OsdSchedule.c:68 #5 0xc0167025 in EcGpeHandler (Context=0xc1096e40) at ../../dev/acpica/acpi_ec.c:471 #6 0xc01446a4 in AcpiEvGpeDispatch (GpeNumber=9) at ../../contrib/dev/acpica/Subsystem/Events/evevent.c:913 #7 0xc01444fe in AcpiEvGpeDetect () at ../../contrib/dev/acpica/Subsystem/Events/evevent.c:779 #8 0xc0145a7d in AcpiEvSciHandler (Context=0x0) at ../../contrib/dev/acpica/Subsystem/Events/evsci.c:185 #9 0xc02d3fee in ithd_loop (dummy=0x0) at ../../i386/isa/ithread.c:188 Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 1:23:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from gate.consol.de (gate.consol.de [194.221.87.10]) by hub.freebsd.org (Postfix) with ESMTP id 4D1CF37B400 for ; Tue, 23 Jan 2001 01:23:21 -0800 (PST) X-Envelope-Sender-Is: Thorsten.Greiner@consol.de (at relayer gate.consol.de) Received: from msgsrv.bb.consol.de (msgsrv.bb.consol.de [10.250.0.100]) by gate.consol.de (8.11.1/8.9.3) with ESMTP id f0N9NKj24006 for ; Tue, 23 Jan 2001 10:23:20 +0100 (CET) (envelope-from Thorsten.Greiner@consol.de) Received: from vscanner.bb.consol.de (root@vscanner.bb.consol.de [10.250.0.120]) by msgsrv.bb.consol.de (8.8.8/8.8.8) with ESMTP id KAA07913 for ; Tue, 23 Jan 2001 10:23:20 +0100 Received: from bonn.rtg.consol.de (bonn.rtg.consol.de [10.2.204.3]) by vscanner.bb.consol.de (8.9.3/8.9.3) with ESMTP id KAA24963 for ; Tue, 23 Jan 2001 10:22:46 +0100 Received: from hilden by bonn.rtg.consol.de (8.8.8+Sun/SMI-SVR4) id LAA13268; Tue, 23 Jan 2001 11:23:41 +0100 (MET) Message-Id: <200101231023.LAA13268@bonn.rtg.consol.de> X-Amavis-approved: Yes Date: Tue, 23 Jan 2001 10:22:45 +0100 (MET) From: Thorsten Greiner Reply-To: Thorsten Greiner Subject: USB problems To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: qZeuVOV/RjjSo1IjpA+9tA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I cannot get the USB interface to work on my ASUS L7300G Laptop with -CURRENT. I have attached an excerpt of the message file and the section of the config file dealing with USB. Any hints? messages: Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci0: port 0x1c00-0x1c1f irq 11 at device 7.2 on pci0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_run: setting run=0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_run: done cmd=0x0 sts=0x20 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_run: setting run=1 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_run: done cmd=0x81 sts=0x0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: usb0: on uhci0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: usb0: USB revision 1.0 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub0: 2 ports with 2 removable, self powered Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_waitintr: timeout Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_transfer_cb: short transfer 0<8 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_waitintr: timeout Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_transfer_cb: short transfer 0<8 Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhci_waitintr: timeout Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_transfer_cb: short transfer 0<8 Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_new_device: addr=2, getting first desc failed Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub_explore: usb_new_device failed, error=SHORT_XFER Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub0: device problem, disabling port 1 config: # USB support device uhci # UHCI PCI->USB interface device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ums # Mouse options UHCI_DEBUG options USB_DEBUG options UGEN_DEBUG options UHID_DEBUG options UHUB_DEBUG options UMS_DEBUG Thanks -Thorsten To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 2:14:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id CB02E37B6A8; Tue, 23 Jan 2001 02:14:20 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0NAEI400958; Tue, 23 Jan 2001 02:14:18 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101231014.f0NAEI400958@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Thorsten Greiner Cc: freebsd-current@FreeBSD.ORG, n_hibma@FreeBSD.ORG Subject: Re: USB problems In-Reply-To: <200101231023.LAA13268@bonn.rtg.consol.de> Date: Tue, 23 Jan 2001 02:14:18 -0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thorsten Greiner wrote: > Hi, > > I cannot get the USB interface to work on my ASUS L7300G Laptop with > -CURRENT. I have attached an excerpt of the message file and the section of > the config file dealing with USB. Any hints? > > messages: > Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_transfer_cb: short > transfer 0<8 > Jan 23 10:01:22 tybalt /boot/kernel/kernel: usbd_new_device: addr=2, > getting first desc failed > Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub_explore: usb_new_device > failed, error=SHORT_XFER > Jan 23 10:01:22 tybalt /boot/kernel/kernel: uhub0: device problem, > disabling port 1 Yes, I have the same problem. Apparently there is some problem with reading the header information that requires a reset to be issued between the two reads. Windows does the reset, and the USB maintainer was wondering why.. Now we know. :-] No, there is no known fix or workaround yet. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 4:19:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from pis.toba-cmt.ac.jp (pis.toba-cmt.ac.jp [202.26.248.77]) by hub.freebsd.org (Postfix) with ESMTP id 6E0CD37B400 for ; Tue, 23 Jan 2001 04:19:07 -0800 (PST) Received: from kiri.pis (localhost [127.0.0.1]) by pis.toba-cmt.ac.jp (8.11.1/8.11.1) with ESMTP id f0NCHQ412158 for ; Tue, 23 Jan 2001 21:17:27 +0900 (JST) (envelope-from kiri@pis.toba-cmt.ac.jp) Message-Id: <200101231217.f0NCHQ412158@pis.toba-cmt.ac.jp> Date: Tue, 23 Jan 2001 21:17:26 +0900 From: kiri@pis.toba-cmt.ac.jp To: freebsd-current@FreeBSD.ORG Subject: Error: you don't have the right version of perl in /usr/bin? User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 13) (Crater Lake) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all. I have make install in devel/automake port, but can't compile with put error messages: ===> Extracting for rpm-3.0.6_4 >> Checksum OK for rpm-3.0.6.tar.gz. ===> rpm-3.0.6_4 depends on executable: gmake - found ===> rpm-3.0.6_4 depends on executable: automake - not found ===> Verifying install for automake in /usr/ports/devel/automake Error: you don't have the right version of perl in /usr/bin. *** Error code 1 Stop in /usr/ports/devel/automake. *** Error code 1 Same port in stable has been compiled ok. Is there any reason that? # Both stable and current are make world yesterday and both were # well reconfigured to chroot environment. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 6:23:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id A84D937B6A4; Tue, 23 Jan 2001 06:23:11 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f0NEN6U01974; Tue, 23 Jan 2001 16:23:08 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.1/8.9.3) with ESMTP id f0NE07Q37210; Tue, 23 Jan 2001 16:00:07 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A6D8E67.8ED56EE5@FreeBSD.org> Date: Tue, 23 Jan 2001 16:00:09 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: yokota@FreeBSD.org, sos@FreeBSD.org Cc: current@FreeBSD.org, audit@FreeBSD.org Subject: [RFC] Configurable text geometry in VESA_800x600 raster text mode Content-Type: multipart/mixed; boundary="------------53C3D4175924CB963590EC2D" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------53C3D4175924CB963590EC2D Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi, With this message I'm attaching a patch for vidcontrol(1) and vgl(3) to allow a user select his own text geometry (i.e. number of rows and number of columns) in a raster text modes (currently only VESA_800x600 is supported). This should make VESA_800x600 more usable, as the 80x25, which is currently default geometry for this mode, covers only 50% (80 * 16 * 25 * 8 / (800 * 600)) of the usable screen area in this mode. Furthermore, there also should be a possibility to use with raster modes configurable font sizes other than default 16, but unfortunately existing set of console ioctl's doesn't allow to get font size being used currently, so there is no way to restore text console properly after it was switched into a graphics mode. Therefore this feature may be provided later after console ioctl's set has been properly adjusted. -Maxim --------------53C3D4175924CB963590EC2D Content-Type: text/plain; charset=koi8-r; name="vidcontrol.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vidcontrol.diff" Index: libvgl/main.c =================================================================== RCS file: /home/ncvs/src/lib/libvgl/main.c,v retrieving revision 1.8 diff -d -u -r1.8 main.c --- libvgl/main.c 2001/01/13 11:30:16 1.8 +++ libvgl/main.c 2001/01/23 13:09:41 @@ -57,6 +57,7 @@ static int VGLOnDisplay; static unsigned int VGLCurWindow; static int VGLInitDone = 0; +static struct winsize VGLOldWSize; void VGLEnd() @@ -79,8 +80,8 @@ ioctl(0, _IO('V', VGLOldMode - M_VESA_BASE), 0); if (VGLOldMode == M_VESA_800x600) { int size[3]; - size[0] = 80; - size[1] = 25; + size[0] = VGLOldWSize.ws_col; + size[1] = VGLOldWSize.ws_row; size[2] = 16; ioctl(0, KDRASTER, size); } @@ -143,6 +144,11 @@ VGLModeInfo.vi_mode = mode & 0x0ff; if (ioctl(0, CONS_MODEINFO, &VGLModeInfo)) /* FBIO_MODEINFO */ return -1; + + /* If current mode is VESA_800x600 then save its geometry to restore later */ + if ((VGLOldMode >= M_VESA_BASE) && (VGLOldMode == M_VESA_800x600)) + if (ioctl(0, TIOCGWINSZ, &VGLOldWSize)) + return -1; VGLDisplay = (VGLBitmap *)malloc(sizeof(VGLBitmap)); if (VGLDisplay == NULL) Index: vidcontrol/vidcontrol.1 =================================================================== RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.1,v retrieving revision 1.27 diff -d -u -r1.27 vidcontrol.1 --- vidcontrol/vidcontrol.1 2000/11/17 11:44:16 1.27 +++ vidcontrol/vidcontrol.1 2001/01/23 13:09:41 @@ -25,6 +25,7 @@ .Op Fl c Ar appearance .Op Fl d .Op Fl f Ar size Ar file +.Op Fl g Ar geometry .Op Fl i Cm adapter | mode .Op Fl l Ar screen_map .Op Fl L @@ -159,6 +160,18 @@ .Sx EXAMPLES below and the man page for .Xr syscons 4 . +.It Fl g Ar geometry +Set the +.Ar geometry +of the text mode for the modes with selectable +geometry. Currently only raster modes, such as +.Ar VESA_800x600 , +support this option. +See also +.Sx Video Mode Support +and +.Sx EXAMPLES +below. .It Fl s Ar number Set the current vty to .Ar number . @@ -283,6 +296,11 @@ .Pp The above command will load .Pa /usr/share/syscons/scrnmaps/iso-8859-1_to_cp437.scm . +.Pp +The following command will set-up a 100x37 raster text mode (useful for +some LCD models): +.Pp +.Dl vidcontrol -g 100x37 VESA_800x600 .Sh SEE ALSO .Xr kbdcontrol 1 , .Xr vidfont 1 , Index: vidcontrol/vidcontrol.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/vidcontrol/vidcontrol.c,v retrieving revision 1.33 diff -d -u -r1.33 vidcontrol.c --- vidcontrol/vidcontrol.c 2000/10/08 21:34:00 1.33 +++ vidcontrol/vidcontrol.c 2001/01/23 13:09:42 @@ -44,6 +44,10 @@ #include "path.h" #include "decode.h" +#define _VESA_800x600_DFL_COLS 80 +#define _VESA_800x600_DFL_ROWS 25 +#define _VESA_800x600_DFL_FNSZ 16 + char legal_colors[16][16] = { "black", "blue", "green", "cyan", "red", "magenta", "brown", "white", @@ -52,6 +56,8 @@ }; int hex = 0; int number; +int vesa_cols = _VESA_800x600_DFL_COLS; +int vesa_rows = _VESA_800x600_DFL_ROWS; char letter; struct vid_info info; @@ -62,8 +68,8 @@ fprintf(stderr, "%s\n%s\n%s\n%s\n", "usage: vidcontrol [-r fg bg] [-b color] [-c appearance] [-d] [-l scrmap]", " [-i adapter | mode] [-L] [-M char] [-m on|off]", -" [-f size file] [-s number] [-t N|off] [-x] [mode]", -" [fgcol [bgcol]] [show]"); +" [-f size file] [-s number] [-t N|off] [-x] [-g geometry]", +" [mode] [fgcol [bgcol]] [show]"); exit(1); } @@ -318,9 +324,25 @@ if (ioctl(0, mode, NULL) < 0) warn("cannot set videomode"); if (mode == SW_VESA_800x600) { - size[0] = 80; /* columns */ - size[1] = 25; /* rows */ - size[2] = 16; /* font size */ + /* columns */ + if ((vesa_cols * 8 > 800) || (vesa_cols <= 0)) { + warnx("incorrect number of columns: %d", + vesa_cols); + size[0] = _VESA_800x600_DFL_COLS; + } else { + size[0] = vesa_cols; + } + /* rows */ + if ((vesa_rows * _VESA_800x600_DFL_FNSZ > 600) || + (vesa_rows <=0)) { + warnx("incorrect number of rows: %d", + vesa_rows); + size[1] = _VESA_800x600_DFL_ROWS; + } else { + size[1] = vesa_rows; + } + /* font size */ + size[2] = _VESA_800x600_DFL_FNSZ; if (ioctl(0, KDRASTER, size)) { ioerr = errno; if (cur_mode >= M_VESA_BASE) @@ -574,7 +596,7 @@ info.size = sizeof(info); if (ioctl(0, CONS_GETINFO, &info) < 0) err(1, "must be on a virtual console"); - while((opt = getopt(argc, argv, "b:c:df:i:l:LM:m:r:s:t:x")) != -1) + while((opt = getopt(argc, argv, "b:c:df:g:i:l:LM:m:r:s:t:x")) != -1) switch(opt) { case 'b': set_border_color(optarg); @@ -588,6 +610,13 @@ case 'f': load_font(optarg, nextarg(argc, argv, &optind, 'f')); + break; + case 'g': + if (sscanf(optarg, "%dx%d", &vesa_cols, + &vesa_rows) != 2) { + warnx("incorrect geometry: %s", optarg); + usage(); + } break; case 'i': show_info(optarg); --------------53C3D4175924CB963590EC2D-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 8:36: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id CECF337B400 for ; Tue, 23 Jan 2001 08:35:21 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0NGZOl23622 for ; Tue, 23 Jan 2001 17:35:24 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: make -j 128 world hang.... From: Poul-Henning Kamp Date: Tue, 23 Jan 2001 17:35:23 +0100 Message-ID: <23620.980267723@critter> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I can still stall my 2xPII/350 machine with a make -j 128 world, but it is slightly different now I think: I can break into ddb. This machine is a ahc/scsi machine, so I don't know if this is really SMP or Justins recent changes... Poul-Henning db> trace siointr1(c10d1400,c02dc520,1,c0291103,723) at siointr1+0xb1 siointr(c10d1400) at siointr+0x23 Xfastintr4(0) at Xfastintr4+0x2f fork_trampoline() at fork_trampoline+0x3c db> ps pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 55841 ce3ab840 ce3b1000 0 55818 16280 004006 3 vmwait c02e1e38 cpp0 55840 cde5b200 cdfa6000 0 55823 16280 004006 3 vmwait c02e1e38 as 55839 ce01b620 ce025000 0 55823 16280 004006 3 vmwait c02e1e38 cc1 55838 cdd5e400 cdd76000 0 55809 16280 004006 3 vmwait c02e1e38 as 55837 ce30b660 ce394000 0 55722 16280 000016 3 vmwait c02e1e38 cc 55836 ce30cdc0 ce360000 0 55823 16280 004006 3 vmwait c02e1e38 cpp0 55835 ce30c980 ce368000 0 55722 16280 004006 3 vmwait c02e1e38 cc1 55834 ce276660 ce55d000 0 55809 16280 004006 3 vmwait c02e1e38 cc1 55833 ce989860 ce9ce000 0 55693 16280 004006 3 vmwait c02e1e38 as 55832 cdd5db80 cdd86000 0 55785 16280 004006 3 vmwait c02e1e38 as 55831 cdd5dfc0 cdd81000 0 55722 16280 004006 3 vmwait c02e1e38 cpp0 55830 cdcd80e0 cdd15000 0 55779 16280 004006 3 vmwait c02e1e38 as 55829 cdc19220 cdcce000 0 55693 16280 004006 3 vmwait c02e1e38 cc1 55828 ce27a400 ce28d000 0 55809 16280 004006 3 vmwait c02e1e38 cpp0 55827 ce6addc0 ce705000 0 55779 16280 004006 3 vmwait c02e1e38 cc1 55826 cdcd8da0 cdcfd000 0 55785 16280 004006 3 vmwait c02e1e38 cc1 55825 ce4d6da0 ce4f6000 0 55778 16280 004086 3 piperd ce328c00 as 55824 cdcd91e0 cdcf6000 0 55693 16280 004006 3 vmwait c02e1e38 cpp0 55823 cdc1b640 cdc77000 0 55630 16280 004086 3 wait cdc1b640 cc 55822 cdcd8520 cdd10000 0 55807 16280 004006 3 vmwait c02e1e38 as 55821 cdcd7ca0 cdd1c000 0 55806 16280 004006 3 vmwait c02e1e38 as 55820 cdd5c200 cddf6000 0 55806 16280 004086 3 piperd cdda07a0 cc1 55819 ce3a9420 ce403000 0 55807 16280 004086 3 piperd cdbe74e0 cc1 55818 cdc1ba80 cdc6c000 0 55775 16280 004006 3 allproc c02e08a0 cc 55817 ce425b80 ce44d000 0 55807 16280 004006 3 vmwait c02e1e38 cpp0 55816 ce4d4100 ce545000 0 55750 16280 004086 3 piperd ce4018a0 as 55815 cdcd5ee0 cdd6a000 0 55750 16280 004086 3 piperd ce325280 cc1 55814 ce30d860 ce34e000 0 55750 16280 004006 3 vmwait c02e1e38 cpp0 55813 ce571320 ce00a000 0 55803 16280 004006 3 vmwait c02e1e38 as 55812 ce609220 ce6a2000 0 55806 16280 004006 3 vmwait c02e1e38 cpp0 55811 ce571ba0 ce5ca000 0 55803 16280 004086 3 piperd cdd9fda0 cc1 55810 ce3a7cc0 ce409000 0 55803 16280 004006 3 vmwait c02e1e38 cpp0 55809 ce609cc0 ce68e000 0 55801 16280 004086 3 wait ce609cc0 cc 55808 ce573300 ce59e000 0 55749 16280 004086 3 piperd ce328840 as 55807 cdd5e1e0 cdd7a000 0 55782 16280 004082 3 wait cdd5e1e0 cc 55806 ce7f3660 ce976000 0 55791 16280 004082 3 wait ce7f3660 cc 55804 ce571540 ce001000 0 55749 16280 004086 3 piperd ce039b60 cc1 55803 ce60a980 ce673000 0 55764 16280 004082 3 wait ce60a980 cc 55801 cdcd5000 cddc9000 0 55317 16280 004082 3 wait cdcd5000 sh 55799 cde59440 ce00d000 0 55746 16280 004086 3 piperd cdbe6860 as 55798 ce989200 ce9d7000 0 55749 16280 004006 3 vmwait c02e1e38 cpp0 55797 ce423100 ce4aa000 0 55792 16280 004086 3 piperd ce4023e0 as 55796 ce98bc80 ce98d000 0 55792 16280 004086 3 piperd ce4002c0 cc1 55795 ce01a0e0 ce0bd000 0 55792 16280 004006 3 vmwait c02e1e38 cpp0 55794 ce4d5640 ce521000 0 55786 16280 004086 3 piperd ce325f00 as 55793 ce30fc80 ce310000 0 55786 16280 004086 3 piperd ce542d60 cc1 55792 cde5d400 cde6f000 0 55787 16280 004082 3 wait cde5d400 cc 55791 ce7f3000 ce980000 0 55317 16280 004082 3 wait ce7f3000 sh 55790 cdc1b200 cdc86000 0 55786 16280 004006 3 vmwait c02e1e38 cpp0 55789 cdcd6dc0 cdd33000 0 55779 16280 004006 3 vmwait c02e1e38 cpp0 55788 cdcd7a80 cdd20000 0 55785 16280 004006 3 vmwait c02e1e38 cpp0 55787 cdcd5220 cddc5000 0 55317 16280 004082 3 wait cdcd5220 sh 55786 ce988760 cea08000 0 55784 16280 004082 3 wait ce988760 cc 55785 cde5a760 cdfbe000 0 55780 16280 004086 3 wait cde5a760 cc 55784 cdd5c420 cddbe000 0 55317 16280 004082 3 wait cdd5c420 sh 55783 ce017220 ce303000 0 55778 16280 004006 3 vmwait c02e1e38 cc1 55782 ce3a8fe0 ce1dc000 0 55317 16280 004082 3 wait ce3a8fe0 sh 55781 cdd5a880 cde44000 0 55778 16280 004006 3 vmwait c02e1e38 cpp0 55780 ce571dc0 ce5c6000 0 55317 16280 004082 3 wait ce571dc0 sh 55779 ce425740 ce455000 0 55777 16280 004086 3 wait ce425740 cc 55778 ce30e0e0 ce341000 0 55776 16280 004082 3 wait ce30e0e0 cc 55777 ce01bc80 ce01c000 0 55317 16280 004082 3 wait ce01bc80 sh 55776 ce6af520 ce6dd000 0 55317 16280 004082 3 wait ce6af520 sh 55775 ce609aa0 ce690000 0 55317 16280 004082 3 wait ce609aa0 sh 55774 ce7f5420 ce8ed000 0 55770 16280 004086 3 piperd ce542ae0 as 55773 ce01a300 ce0ba000 0 55734 16280 004086 3 piperd ce038940 as 55772 ce424a80 ce468000 0 55770 16280 004086 3 piperd ce325a00 cc1 55771 ce7f3880 ce96e000 0 55770 16280 004006 3 vmwait c02e1e38 cpp0 55770 ce30dca0 ce346000 0 55707 16280 004082 3 wait ce30dca0 cc 55769 cea9c740 ceb78000 0 55747 16280 004086 3 piperd ce8b7300 as 55768 ce30f840 ce317000 0 55747 16280 004086 3 piperd cdbe6d60 cc1 55767 ce6ad320 ce714000 0 55747 16280 004006 3 vmwait c02e1e38 cpp0 55766 cde5afe0 cdfa9000 0 55746 16280 004086 3 piperd ce8b7ee0 cc1 55765 ce7f5640 ce8e6000 0 55734 16280 004006 3 vmwait c02e1e38 cc1 55764 ce4d3440 ce562000 0 55317 16280 004082 3 wait ce4d3440 sh 55763 ce570440 ce270000 0 55746 16280 004006 3 vmwait c02e1e38 cpp0 55762 ce60c960 ce638000 0 55734 16280 004006 3 vmwait c02e1e38 cpp0 55761 cde5a320 ce0ee000 0 55739 16280 004086 3 piperd ce543e40 as 55760 ce30dec0 ce344000 0 55740 16280 004086 3 piperd ce3ff000 as 55759 ce277320 ce43e000 0 55740 16280 004086 3 piperd cdbe8ac0 cc1 55758 ce30e740 ce337000 0 55740 16280 004006 3 vmwait c02e1e38 cpp0 55757 cdcd8b80 cdd00000 0 55739 16280 004086 3 piperd ce542a40 cc1 55756 ce276440 ce600000 0 55737 16280 004086 3 piperd ce0390c0 as 55755 ce01ba60 ce01f000 0 55737 16280 004086 3 piperd ce402e80 cc1 55754 ce27a620 ce28a000 0 55725 16280 004086 3 piperd cdbe88e0 as 55753 ce7f6da0 ce8bf000 0 55737 16280 004006 3 vmwait c02e1e38 cpp0 55752 ce30fa60 ce314000 0 55739 16280 004006 3 vmwait c02e1e38 cpp0 55751 cdd5e840 cdd70000 0 55725 16280 004086 3 piperd cdd9e0e0 cc1 55750 ce4250e0 ce45d000 0 55748 16280 004082 3 wait ce4250e0 cc 55749 ce3a8ba0 ce1e4000 0 55732 16280 004082 3 wait ce3a8ba0 cc 55748 cea9d840 ceaa4000 0 55317 16280 004082 3 wait cea9d840 sh 55747 ce7f3cc0 ce949000 0 55738 16280 004082 3 wait ce7f3cc0 cc 55746 cde5d1e0 cde72000 0 55745 16280 004082 3 wait cde5d1e0 cc 55745 ce609660 ce698000 0 55317 16280 004082 3 wait ce609660 sh 55744 ce4d3aa0 ce556000 0 55741 16280 004086 3 piperd ce5413c0 as 55743 cea9d620 ceb30000 0 55741 16280 004086 3 piperd cdd9e360 cc1 55742 ce018320 ce2df000 0 55741 16280 004006 3 vmwait c02e1e38 cpp0 55741 ce6b0400 ce6bf000 0 55606 16280 004082 3 wait ce6b0400 cc 55740 ce60bec0 ce64d000 0 55731 16280 004082 3 wait ce60bec0 cc 55739 ce30b000 ce3a0000 0 55727 16280 004082 3 wait ce30b000 cc 55738 ce425300 ce45b000 0 55317 16280 004082 3 wait ce425300 sh 55737 ce60da60 ce617000 0 55729 16280 004082 3 wait ce60da60 cc 55736 cdd5a440 cde4a000 0 55726 16280 004086 3 piperd ce3282a0 as 55735 ce6af0e0 ce6e5000 0 55726 16280 004086 3 piperd cdd9ed60 cc1 55734 ce574c80 ce575000 0 55730 16280 004082 3 wait ce574c80 cc 55733 cdd5bdc0 cddfa000 0 55726 16280 004006 3 vmwait c02e1e38 cpp0 55732 ce30f1e0 ce323000 0 55317 16280 004082 3 wait ce30f1e0 sh 55731 cdd5bba0 cddfd000 0 55317 16280 004082 3 wait cdd5bba0 sh 55730 ce3aa960 ce3c8000 0 55317 16280 004082 3 wait ce3aa960 sh 55729 ce30cba0 ce363000 0 55317 16280 004082 3 wait ce30cba0 sh 55728 cdc1a980 cdc96000 0 55725 16280 004006 3 vmwait c02e1e38 cpp0 55727 ce6af740 ce6d9000 0 55317 16280 004082 3 wait ce6af740 sh 55726 cea9dc80 cea9e000 0 55724 16280 004082 3 wait cea9dc80 cc 55725 ce4d3000 ce568000 0 55723 16280 004082 3 wait ce4d3000 cc 55724 ce30f620 ce31a000 0 55317 16280 004082 3 wait ce30f620 sh 55723 ce01a520 ce0b7000 0 55317 16280 004082 3 wait ce01a520 sh 55722 ce276ee0 ce0a2000 0 55692 16280 004006 3 ppwait ce276ee0 cc 55721 cdcd5660 cdd99000 0 55715 16280 004086 3 piperd ce325320 as 55720 ce018760 ce0f9000 0 55715 16280 004086 3 piperd ce4022a0 cc1 55719 ce60d620 ce61d000 0 55715 16280 004006 3 vmwait c02e1e38 cpp0 55718 ce30e960 ce334000 0 55711 16280 004086 3 piperd ce0372c0 as 55717 ce7f3220 ce97e000 0 55711 16280 004086 3 piperd ce542e00 cc1 55716 ce425da0 ce44a000 0 55711 16280 004006 3 vmwait c02e1e38 cpp0 55715 ce98a520 ce9ba000 0 55705 16280 004082 3 wait ce98a520 cc 55714 ce6ad100 ce71c000 0 55703 16280 004086 3 piperd ce4019e0 as 55713 ce3a8760 ce1e8000 0 55703 16280 004086 3 piperd cdbe79e0 cc1 55712 ce7f5ca0 ce8db000 0 55703 16280 004006 3 vmwait c02e1e38 cpp0 55711 ce988320 cea0d000 0 55706 16280 004082 3 wait ce988320 cc 55710 ce30da80 ce34b000 0 55704 16280 004086 3 piperd ce543260 as 55709 ce426840 ce42e000 0 55704 16280 004086 3 piperd cdd9fe40 cc1 55708 ce425960 ce453000 0 55704 16280 004006 3 vmwait c02e1e38 cpp0 55707 ce422440 ce4c1000 0 55317 16280 004082 3 wait ce422440 sh 55706 ce4d7a60 ce4df000 0 55317 16280 004082 3 wait ce4d7a60 sh 55705 cea9d400 ceb33000 0 55317 16280 004082 3 wait cea9d400 sh 55704 ce6accc0 ce091000 0 55702 16280 004082 3 wait ce6accc0 cc 55703 cdd5dda0 cdd84000 0 55701 16280 004082 3 wait cdd5dda0 cc 55702 ce422660 ce4be000 0 55317 16280 004082 3 wait ce422660 sh 55701 ce571100 ce06f000 0 55317 16280 004082 3 wait ce571100 sh 55700 ce01afc0 ce031000 0 55684 16280 004086 3 piperd cdbe8200 as 55699 ce7f4320 ce937000 0 55695 16280 004086 3 piperd cdd9ddc0 as 55698 ce30efc0 ce32a000 0 55695 16280 004086 3 piperd ce542360 cc1 55697 ce572860 ce5b7000 0 55695 16280 004006 3 vmwait c02e1e38 cpp0 55696 ce3a7ee0 ce406000 0 55684 16280 004086 3 piperd ce039ca0 cc1 55695 cdcd5440 cddc2000 0 55566 16280 004082 3 wait cdcd5440 cc 55694 ce3ab620 ce3b4000 0 55684 16280 004006 3 vmwait c02e1e38 cpp0 55693 cdc1c300 cdc55000 0 55678 16280 004086 3 wait cdc1c300 cc 55692 ce6ad980 ce70b000 0 55317 16280 004082 3 wait ce6ad980 sh 55691 ce98afc0 ce9a7000 0 55681 16280 004086 3 piperd cdd9f760 as 55690 ce01a960 ce03e000 0 55681 16280 004086 3 piperd ce8b6a40 cc1 55689 cde5cfc0 cde77000 0 55672 16280 004086 3 piperd ce402ca0 as 55688 cdc1bca0 cdc69000 0 55665 16280 004086 3 piperd ce5433a0 as 55687 ce279740 ce372000 0 55681 16280 004006 3 vmwait c02e1e38 cpp0 55686 ce7f6520 ce8d1000 0 55665 16280 004086 3 piperd ce402d40 cc1 55685 cdd5ea60 cdd6c000 0 55665 16280 004006 3 vmwait c02e1e38 cpp0 55684 ce7f6960 ce8c6000 0 55671 16280 004082 3 wait ce7f6960 cc 55683 ce60dc80 ce60e000 0 55668 16280 004086 3 piperd cdbe7760 as 55682 ce4d4dc0 ce52f000 0 55646 16280 004086 3 piperd ce5445c0 as 55681 ce6b0840 ce6b8000 0 55669 16280 004082 3 wait ce6b0840 cc 55680 ce60c740 ce63b000 0 55668 16280 004086 3 piperd ce039e80 cc1 55679 ce7f6b80 ce8c2000 0 55672 16280 004086 3 piperd ce400180 cc1 55678 cde5d620 cde6c000 0 55317 16280 004082 3 wait cde5d620 sh 55677 ce4d4fe0 ce52b000 0 55672 16280 004006 3 vmwait c02e1e38 cpp0 55676 ce423980 ce496000 0 55646 16280 004086 3 piperd ce4009a0 cc1 55675 ce60b200 ce663000 0 55668 16280 004006 3 vmwait c02e1e38 cpp0 55674 cdd5bfe0 cddf8000 0 55646 16280 004006 3 vmwait c02e1e38 cpp0 55673 ce6afda0 ce6cb000 0 55654 16280 004086 3 piperd ce544de0 as 55672 ce4d6fc0 ce4ee000 0 55670 16280 004082 3 wait ce4d6fc0 cc 55671 ce3a7000 ce41c000 0 55317 16280 004082 3 wait ce3a7000 sh 55670 ce98b620 ce99e000 0 55317 16280 004082 3 wait ce98b620 sh 55669 ce277540 ce43a000 0 55317 16280 004082 3 wait ce277540 sh 55668 ce60cb80 ce634000 0 55651 16280 004082 3 wait ce60cb80 cc 55667 cde59ee0 ce137000 0 55654 16280 004086 3 piperd ce8b69a0 cc1 55666 ce572640 ce5ba000 0 55656 16280 004086 3 piperd ce8b6c20 as 55665 ce7f5ec0 ce8d8000 0 55658 16280 004082 3 wait ce7f5ec0 cc 55664 ce6b0620 ce6bb000 0 55654 16280 004006 3 vmwait c02e1e38 cpp0 55663 cdc1b420 cdc83000 0 55634 16280 004086 3 piperd cdda00c0 as 55662 ce278420 ce3e1000 0 55656 16280 004086 3 piperd ce8b5500 cc1 55661 ce98ba60 ce994000 0 55652 16280 004086 3 piperd ce3ff960 as 55660 ce2790e0 ce380000 0 55652 16280 004006 3 vmwait c02e1e38 cc1 55659 ce572ec0 ce5a4000 0 55656 16280 004006 3 vmwait c02e1e38 cpp0 55658 ce989640 ce9d1000 0 55317 16280 004082 3 wait ce989640 sh 55657 ce7f4540 ce930000 0 55652 16280 004086 3 pipdwt ce544e80 cpp0 55656 ce6aeec0 ce6e8000 0 55649 16280 004082 3 wait ce6aeec0 cc 55655 cea9cb80 ceb3f000 0 55640 16280 004086 3 piperd ce3ffd20 as 55654 ce019ca0 ce0c6000 0 55650 16280 004082 3 wait ce019ca0 cc 55653 ce4d4540 ce53a000 0 55634 16280 004086 3 piperd ce036000 cc1 55652 ce988540 cea0b000 0 55613 16280 004082 3 wait ce988540 cc 55651 ce4d60e0 ce50d000 0 55317 16280 004082 3 wait ce4d60e0 sh 55650 ce573960 ce594000 0 55317 16280 004082 3 wait ce573960 sh 55649 ce6ac220 ce7ee000 0 55317 16280 004082 3 wait ce6ac220 sh 55648 ce4d5420 ce524000 0 55639 16280 004086 3 piperd cdd9e400 as 55647 cde5cb80 cde7d000 0 55639 16280 004086 3 piperd cdd9f080 cc1 55646 ce3abc80 ce3ac000 0 55641 16280 004082 3 wait ce3abc80 cc 55645 ce60a760 ce678000 0 55634 16280 004006 3 vmwait c02e1e38 cpp0 55644 ce019860 ce0cc000 0 55640 16280 004086 3 piperd ce541000 cc1 55643 ce570ee0 ce0a4000 0 55640 16280 004006 3 vmwait c02e1e38 cpp0 55642 ce018540 ce0fe000 0 55639 16280 004006 3 vmwait c02e1e38 cpp0 55641 cdcd8740 cdd07000 0 55317 16280 004082 3 wait cdcd8740 sh 55640 ce6ae200 ce6fe000 0 55635 16280 004082 3 wait ce6ae200 cc 55639 ce7f4ba0 ce928000 0 55632 16280 004082 3 wait ce7f4ba0 cc 55638 ce3aba60 ce3af000 0 55631 16280 004086 3 piperd ce038c60 as 55637 ce7f4980 ce92a000 0 55631 16280 004086 3 piperd ce036820 cc1 55636 cea9d1e0 ceb36000 0 55631 16280 004006 3 vmwait c02e1e38 cpp0 55635 ce5730e0 ce5a1000 0 55317 16280 004082 3 wait ce5730e0 sh 55634 ce987cc0 cea16000 0 55633 16280 004082 3 wait ce987cc0 cc 55633 ce6af300 ce6df000 0 55317 16280 004082 3 wait ce6af300 sh 55632 ce4d6520 ce509000 0 55317 16280 004082 3 wait ce4d6520 sh 55631 cdc19000 cdcd2000 0 55629 16280 004082 3 wait cdc19000 cc 55630 ce988ba0 ce9e0000 0 55317 16280 004082 3 wait ce988ba0 sh 55629 ce4d7620 ce4e5000 0 55317 16280 004082 3 wait ce4d7620 sh 55628 cde5aba0 cdfb8000 0 55582 16280 004086 3 piperd ce401760 as 55627 ce01b400 ce028000 0 55582 16280 004006 3 vmwait c02e1e38 cc1 55626 cde5b420 cdfa3000 0 55582 16280 004086 3 pipdwt ce541be0 cpp0 55625 ce30e520 ce33b000 0 55622 16280 004086 3 piperd ce3ff820 as 55624 ce987440 cea6a000 0 55622 16280 004086 3 piperd ce039de0 cc1 55623 ce4d4ba0 ce532000 0 55622 16280 004006 3 vmwait c02e1e38 cpp0 55622 cde5c960 cdec6000 0 55545 16280 004082 3 wait cde5c960 cc 55621 cde5bca0 cdf94000 0 55592 16280 004086 3 piperd ce542180 as 55620 ce279fc0 ce2d9000 0 55592 16280 004086 3 piperd ce039520 cc1 55619 cde5adc0 cdfb5000 0 55612 16280 004086 3 piperd ce039840 as 55618 cdc19440 cdccb000 0 55612 16280 004086 3 piperd ce543b20 cc1 55617 cde5b640 cdfa0000 0 55609 16280 004086 3 piperd cdbe87a0 as 55616 ce4d5860 ce51f000 0 55612 16280 004006 3 vmwait c02e1e38 cpp0 55615 ce7f60e0 ce8d6000 0 55609 16280 004086 3 piperd cdd9f800 cc1 55614 ce7f7a60 ce87f000 0 55609 16280 004006 3 vmwait c02e1e38 cpp0 55613 ce423fe0 ce482000 0 55317 16280 004082 3 wait ce423fe0 sh 55612 ce4d4980 ce534000 0 55611 16280 004082 3 wait ce4d4980 cc 55611 ce423dc0 ce4a6000 0 55317 16280 004082 3 wait ce423dc0 sh 55610 ce6ae420 ce6fb000 0 55598 16280 004086 3 piperd ce038b20 as 55609 cdc19ee0 cdcb2000 0 55599 16280 004082 3 wait cdc19ee0 cc 55608 ce30f400 ce31c000 0 55598 16280 004086 3 piperd ce038800 cc1 55607 ce019ec0 ce0c3000 0 55598 16280 004006 3 vmwait c02e1e38 cpp0 55606 ce7f5200 ce8f4000 0 55317 16280 004082 3 wait ce7f5200 sh 55605 ce30cfe0 ce35b000 0 55594 16280 004086 3 piperd ce3265e0 as 55604 ce3aab80 ce3c5000 0 55594 16280 004086 3 piperd ce0377c0 cc1 55603 ce98ab80 ce9b1000 0 55594 16280 004006 3 vmwait c02e1e38 cpp0 55602 ce30eda0 ce32d000 0 55593 16280 004086 3 piperd ce8b7620 as 55601 ce30bee0 ce386000 0 55593 16280 004086 3 piperd ce8b55a0 cc1 55600 cdd5c640 cddbc000 0 55593 16280 004006 3 vmwait c02e1e38 cpp0 55599 cde59aa0 ce13e000 0 55317 16280 004082 3 wait cde59aa0 sh 55598 ce571fe0 ce5c3000 0 55596 16280 004082 3 wait ce571fe0 cc 55597 ce571980 ce610000 0 55592 16280 004006 3 vmwait c02e1e38 cpp0 55596 ce3a9ca0 ce3ea000 0 55317 16280 004082 3 wait ce3a9ca0 sh 55595 cdd5d0e0 cddab000 0 55561 16280 004086 3 piperd ce544700 as 55594 ce4d6960 ce500000 0 55560 16280 004082 3 wait ce4d6960 cc 55593 ce3a8100 ce1f3000 0 55584 16280 004082 3 wait ce3a8100 cc 55592 ce988100 cea10000 0 55590 16280 004082 3 wait ce988100 cc 55591 cdcd8960 cdd04000 0 55583 16280 004086 3 piperd ce036aa0 as 55590 ce424ca0 ce465000 0 55317 16280 004082 3 wait ce424ca0 sh 55589 cde5ba80 cdf98000 0 55583 16280 004006 3 vmwait c02e1e38 cc1 55588 ce572420 ce5bd000 0 55583 16280 004086 3 pipdwt ce8b6720 cpp0 55587 cdd5d300 cdda8000 0 55579 16280 004086 3 piperd cdd9e900 as 55586 ce7f6740 ce8cd000 0 55579 16280 004086 3 piperd ce8b8b60 cc1 55585 ce6acaa0 ce093000 0 55579 16280 004006 3 vmwait c02e1e38 cpp0 55584 ce609440 ce69b000 0 55317 16280 004082 3 wait ce609440 sh 55583 ce60b860 ce659000 0 55580 16280 004082 3 wait ce60b860 cc 55582 ce988fe0 ce9da000 0 55581 16280 004082 3 wait ce988fe0 cc 55581 ce3aafc0 ce3be000 0 55317 16280 004082 3 wait ce3aafc0 sh 55580 ce60c300 ce641000 0 55317 16280 004082 3 wait ce60c300 sh 55579 ce017000 ce309000 0 55578 16280 004082 3 wait ce017000 cc 55578 ce426a60 ce42b000 0 55317 16280 004082 3 wait ce426a60 sh 55577 ce422880 ce4bc000 0 55562 16280 004086 3 piperd ce327080 as 55576 ce4d4760 ce537000 0 55562 16280 004086 3 piperd ce038080 cc1 55575 cde5d840 cde6a000 0 55522 16280 004086 3 piperd cdd9d320 as 55574 cdd5cca0 cddb1000 0 55522 16280 004086 3 piperd ce8b8d40 cc1 55573 ce573b80 ce590000 0 55522 16280 004006 3 vmwait c02e1e38 cpp0 55572 ce30b440 ce398000 0 55561 16280 004086 3 piperd ce400d60 cc1 55571 ce277100 ce476000 0 55562 16280 004006 3 vmwait c02e1e38 cpp0 55570 ce425520 ce458000 0 55559 16280 004086 3 piperd ce326900 as 55569 ce424420 ce473000 0 55559 16280 004006 3 vmwait c02e1e38 cc1 55568 ce017440 ce301000 0 55559 16280 004086 3 pipdwt ce038a80 cpp0 55567 ce019a80 ce0c9000 0 55561 16280 004006 3 vmwait c02e1e38 cpp0 55566 ce60d1e0 ce628000 0 55317 16280 004082 3 wait ce60d1e0 sh 55565 ce30bcc0 ce388000 0 55552 16280 004086 3 piperd ce038f80 as 55564 ce422220 ce4c8000 0 55552 16280 004086 3 piperd ce0366e0 cc1 55563 ce60d400 ce625000 0 55552 16280 004006 3 vmwait c02e1e38 cpp0 55562 ce4d6740 ce505000 0 55547 16280 004082 3 wait ce4d6740 cc 55561 cdd5d740 cdda1000 0 55551 16280 004082 3 wait cdd5d740 cc 55560 ce30baa0 ce38f000 0 55317 16280 004082 3 wait ce30baa0 sh 55559 cea9cda0 ceb3c000 0 55550 16280 004082 3 wait cea9cda0 cc 55558 ce570660 ce26e000 0 55542 16280 004086 3 piperd ce3274e0 as 55557 ce277fe0 ce3ed000 0 55544 16280 004086 3 piperd cdbe6540 as 55556 cdd5d520 cdda3000 0 55542 16280 004086 3 piperd ce036320 cc1 55555 cdcd7ec0 cdd18000 0 55542 16280 004006 3 vmwait c02e1e38 cpp0 55554 ce30c100 ce37e000 0 55544 16280 004006 3 vmwait c02e1e38 cc1 55553 ce276880 ce55b000 0 55544 16280 004086 3 pipdwt ce037220 cpp0 55552 ce018dc0 ce0e7000 0 55538 16280 004082 3 wait ce018dc0 cc 55551 ce018980 ce0f7000 0 55317 16280 004082 3 wait ce018980 sh 55550 ce278200 ce3e3000 0 55317 16280 004082 3 wait ce278200 sh 55549 ce423ba0 ce4a8000 0 55534 16280 004086 3 piperd ce038620 as 55548 ce423760 ce499000 0 55534 16280 004006 3 vmwait c02e1e38 cc1 55547 ce98b840 ce996000 0 55317 16280 004082 3 wait ce98b840 sh 55546 ce60ba80 ce657000 0 55534 16280 004086 3 pipdwt ce400540 cpp0 55545 ce7f7840 ce888000 0 55317 16280 004082 3 wait ce7f7840 sh 55544 ce570aa0 ce134000 0 55536 16280 004082 3 wait ce570aa0 cc 55543 ce4261e0 ce445000 0 55531 16280 004086 3 piperd ce3ff0a0 as 55542 ce277dc0 ce3fb000 0 55535 16280 004082 3 wait ce277dc0 cc 55541 cde5b860 cdf9d000 0 55531 16280 004006 3 vmwait c02e1e38 cc1 55540 ce7f71e0 ce8b9000 0 55531 16280 004086 3 pipdwt cdd9d280 cpp0 55539 ce4d4320 ce53f000 0 55513 16280 004086 3 piperd ce325aa0 as 55538 cdd5a660 cde48000 0 55317 16280 004082 3 wait cdd5a660 sh 55537 ce7f5860 ce8e3000 0 55513 16280 004006 3 vmwait c02e1e38 cc1 55536 ce6affc0 ce6c4000 0 55317 16280 004082 3 wait ce6affc0 sh 55535 ce278a80 ce3a4000 0 55317 16280 004082 3 wait ce278a80 sh 55534 cdcd7860 cdd23000 0 55532 16280 004082 3 wait cdcd7860 cc 55533 ce7f6300 ce8d3000 0 55501 16280 004086 3 piperd ce543a80 as 55532 ce30e300 ce33e000 0 55317 16280 004082 3 wait ce30e300 sh 55531 ce277980 ce431000 0 55529 16280 004082 3 wait ce277980 cc 55530 ce426400 ce442000 0 55501 16280 004086 3 piperd ce328020 cc1 55529 ce570220 ce272000 0 55317 16280 004082 3 wait ce570220 sh 55528 ce422cc0 ce4b4000 0 55504 16280 004086 3 piperd ce327300 as 55527 ce3a9a80 ce3f2000 0 55524 16280 004086 3 piperd ce328700 as 55526 ce4d3660 ce55f000 0 55524 16280 004006 3 vmwait c02e1e38 cc1 55525 ce422aa0 ce4b7000 0 55524 16280 004086 3 pipdwt cdd9f300 cpp0 55524 cdd5c860 cddb8000 0 55482 16280 004082 3 wait cdd5c860 cc 55523 ce4d3cc0 ce54c000 0 55501 16280 004006 3 vmwait c02e1e38 cpp0 55522 cdd5ec80 cdd5f000 0 55515 16280 004082 3 wait cdd5ec80 cc 55521 ce609ee0 ce68c000 0 55504 16280 004006 3 vmwait c02e1e38 cc1 55520 ce426c80 ce427000 0 55516 16280 004086 3 piperd ce8b5fa0 as 55519 ce988980 cea05000 0 55516 16280 004086 3 piperd ce544b60 cc1 55518 ce3a7660 ce411000 0 55516 16280 004006 3 vmwait c02e1e38 cpp0 55517 ce98b400 ce9a1000 0 55513 16280 004086 3 pipdwt cdbe7ee0 cpp0 55516 ce6adfe0 ce703000 0 55514 16280 004082 3 wait ce6adfe0 cc 55515 cdd5b540 cde06000 0 55317 16280 004082 3 wait cdd5b540 sh 55514 ce570880 ce1d3000 0 55317 16280 004082 3 wait ce570880 sh 55513 ce574840 ce57c000 0 55508 16280 004082 3 wait ce574840 cc 55512 cdc19aa0 cdcbd000 0 55504 16280 004086 3 pipdwt cdbe7260 cpp0 55511 ce277760 ce433000 0 55493 16280 004086 3 piperd cdbe7120 as 55510 cea9da60 ceaa1000 0 55493 16280 004006 3 vmwait c02e1e38 cc1 55509 ce30b880 ce391000 0 55502 16280 004086 3 piperd ce402840 as 55508 cde5a980 cdfbb000 0 55317 16280 004082 3 wait cde5a980 sh 55507 ce987660 cea67000 0 55502 16280 004006 3 vmwait c02e1e38 cc1 55506 ce017ee0 ce2e9000 0 55502 16280 004086 3 pipdwt ce3258c0 cpp0 55505 cdcd9a60 cdce3000 0 55493 16280 004086 3 pipdwt ce327c60 cpp0 55504 cde5a100 ce0f1000 0 55503 16280 004082 3 wait cde5a100 cc 55503 ce6ac660 ce098000 0 55317 16280 004082 3 wait ce6ac660 sh 55502 ce3aa520 ce3d8000 0 55492 16280 004082 3 wait ce3aa520 cc 55501 ce4d3880 ce558000 0 55499 16280 004082 3 wait ce4d3880 cc 55500 ce27aa60 ce281000 0 55490 16280 004086 3 piperd ce038260 as 55499 ce30d640 ce352000 0 55317 16280 004082 3 wait ce30d640 sh 55498 cde59880 cdfe6000 0 55488 16280 004086 3 piperd cdd9da00 as 55497 ce3ab1e0 ce3bc000 0 55490 16280 004006 3 vmwait c02e1e38 cc1 55496 ce98a300 ce9bd000 0 55488 16280 004006 3 vmwait c02e1e38 cc1 55495 cdcd8fc0 cdcfb000 0 55490 16280 004086 3 pipdwt ce3285c0 cpp0 55494 cdd5b980 cde00000 0 55488 16280 004086 3 pipdwt ce8b6040 cpp0 55493 ce30d200 ce358000 0 55491 16280 004082 3 wait ce30d200 cc 55492 cdcd9c80 cdcdb000 0 55317 16280 004082 3 wait cdcd9c80 sh 55491 cde5c0e0 cdf4f000 0 55317 16280 004082 3 wait cde5c0e0 sh 55490 ce30d420 ce355000 0 55489 16280 004082 3 wait ce30d420 cc 55489 ce987880 cea64000 0 55317 16280 004082 3 wait ce987880 sh 55488 ce6acee0 ce720000 0 55487 16280 004082 3 wait ce6acee0 cc 55487 ce279b80 ce2ee000 0 55317 16280 004082 3 wait ce279b80 sh 55486 ce7f4760 ce92c000 0 55483 16280 004086 3 piperd ce541a00 as 55485 cdd5b100 cde11000 0 55483 16280 004006 3 vmwait c02e1e38 cc1 55484 cdd5a000 cde56000 0 55483 16280 004086 3 pipdwt ce326720 cpp0 55483 ce019200 ce0d3000 0 55475 16280 004082 3 wait ce019200 cc 55482 cdcd7420 cdd28000 0 55317 16280 004082 3 wait cdcd7420 sh 55481 ce7f7620 ce88f000 0 55466 16280 004086 3 piperd cdd9d780 as 55480 ce60a540 ce67a000 0 55476 16280 004086 3 piperd cdda0020 as 55479 cdc19660 cdcc9000 0 55466 16280 004006 3 vmwait c02e1e38 cc1 55478 ce279960 ce2f0000 0 55476 16280 004006 3 vmwait c02e1e38 cc1 55477 ce574400 ce582000 0 55476 16280 004086 3 pipdwt ce0379a0 cpp0 55476 cdd5acc0 cde1b000 0 55448 16280 004082 3 wait cdd5acc0 cc 55475 ce3a7440 ce414000 0 55317 16280 004082 3 wait ce3a7440 sh 55474 ce3ab400 ce3b9000 0 55471 16280 004086 3 piperd ce544d40 as 55473 cdcd6ba0 cdd36000 0 55471 16280 004006 3 vmwait c02e1e38 cc1 55472 cdcd6100 cdd68000 0 55471 16280 004086 3 pipdwt ce326cc0 cpp0 55471 ce3a7aa0 ce40c000 0 55455 16280 004082 3 wait ce3a7aa0 cc 55466 ce6b0c80 ce6b1000 0 55465 16280 004082 3 wait ce6b0c80 cc 55465 ce4d6b80 ce4f9000 0 55317 16280 004082 3 wait ce4d6b80 sh 55463 ce60bca0 ce64f000 0 55317 16280 084082 2 sh 55462 ce4d7400 ce4e8000 0 55453 16280 004086 3 piperd ce8b7760 as 55461 cdd5aee0 cde15000 0 55453 16280 004006 3 vmwait c02e1e38 cc1 55460 ce570000 ce274000 0 55453 16280 004086 3 pipdwt ce325820 cpp0 55459 ce6ae860 ce6f5000 0 55445 16280 004086 3 piperd ce8b7e40 as 55458 cdcd7200 cdd2c000 0 55445 16280 004086 3 piperd cdda0e80 cc1 55457 cde5c520 cdf1f000 0 55445 16280 004006 3 vmwait c02e1e38 cpp0 55456 ce573da0 ce58d000 0 55442 16280 004086 3 piperd cdbe8520 as 55455 ce30b220 ce39d000 0 55317 16280 004082 3 wait ce30b220 sh 55454 ce27ac80 ce27b000 0 55442 16280 004086 3 piperd ce5439e0 cc1 55453 ce7f4100 ce93e000 0 55444 16280 004082 3 wait ce7f4100 cc 55452 cdc1adc0 cdc91000 0 55439 16280 004086 3 piperd ce8b8020 as 55451 ce7f7400 ce8b2000 0 55439 16280 004006 3 vmwait c02e1e38 cc1 55450 ce278ec0 ce38b000 0 55442 16280 004006 3 vmwait c02e1e38 cpp0 55449 ce4d3ee0 ce549000 0 55439 16280 004086 3 pipdwt ce400860 cpp0 55448 ce988dc0 ce9dd000 0 55317 16280 004082 3 wait ce988dc0 sh 55447 ce278860 ce3cd000 0 55441 16280 004086 3 piperd ce038760 as 55446 cdcd7640 cdd25000 0 55441 16280 004006 3 vmwait c02e1e38 cc1 55445 ce573740 ce598000 0 55440 16280 004082 3 wait ce573740 cc 55444 ce5741e0 ce585000 0 55317 16280 004082 3 wait ce5741e0 sh 55443 cde59660 cdfe9000 0 55441 16280 004086 3 pipdwt ce328480 cpp0 55442 ce4d7840 ce4e2000 0 55438 16280 004082 3 wait ce4d7840 cc 55441 ce60d840 ce61a000 0 55434 16280 004082 3 wait ce60d840 cc 55440 ce60b420 ce660000 0 55317 16280 004082 3 wait ce60b420 sh 55439 cdcd6320 cdd65000 0 55429 16280 004082 3 wait cdcd6320 cc 55438 cdd5cec0 cddad000 0 55317 16280 004082 3 wait cdd5cec0 sh 55437 ce98ada0 ce9aa000 0 55433 16280 004086 3 piperd ce8b8ca0 as 55436 ce7f4fe0 ce91d000 0 55433 16280 004006 3 vmwait c02e1e38 cc1 55435 ce6b01e0 ce6c1000 0 55433 16280 004086 3 pipdwt ce328160 cpp0 55434 ce4d6300 ce50b000 0 55317 16280 004082 3 wait ce4d6300 sh 55433 ce3a8980 ce1e6000 0 55422 16280 004082 3 wait ce3a8980 cc 55432 ce425fc0 ce447000 0 55421 16280 004086 3 piperd ce3279e0 as 55431 cdcd9840 cdce5000 0 55421 16280 004006 3 vmwait c02e1e38 cc1 55430 ce574a60 ce578000 0 55421 16280 004086 3 pipdwt ce8b8c00 cpp0 55429 ce276aa0 ce517000 0 55317 16280 004082 3 wait ce276aa0 sh 55428 ce98a740 ce9b6000 0 55411 16280 004086 3 piperd ce543120 as 55427 cdc1a540 cdca9000 0 55411 16280 004006 3 vmwait c02e1e38 cc1 55426 ce572200 ce5c0000 0 55411 16280 004086 3 pipdwt cdda05c0 cpp0 55425 cdd5b320 cde0f000 0 55418 16280 004086 3 piperd ce8b71c0 as 55424 ce3aada0 ce3c1000 0 55418 16280 004006 3 vmwait c02e1e38 cc1 55423 ce7f5a80 ce8de000 0 55418 16280 004086 3 pipdwt ce8b5f00 cpp0 55422 ce3a8320 ce1f1000 0 55317 16280 004082 3 wait ce3a8320 sh 55421 ce3aa0e0 ce3df000 0 55419 16280 004082 3 wait ce3aa0e0 cc 55420 cde59cc0 ce13a000 0 55410 16280 004086 3 piperd cdd9f940 as 55419 ce3a7880 ce40e000 0 55317 16280 004082 3 wait ce3a7880 sh 55418 ce018100 ce2e2000 0 55415 16280 004082 3 wait ce018100 cc 55417 cdc1a320 cdcae000 0 55410 16280 004006 3 vmwait c02e1e38 cc1 55416 ce60b640 ce65c000 0 55410 16280 004086 3 pipdwt cdd9f620 cpp0 55415 ce4d5200 ce528000 0 55317 16280 004082 3 wait ce4d5200 sh 55414 ce989ec0 ce9c4000 0 55409 16280 004086 3 piperd ce8b83e0 as 55413 ce4d5ec0 ce511000 0 55409 16280 004006 3 vmwait c02e1e38 cc1 55412 ce27a1e0 ce2d1000 0 55409 16280 004086 3 pipdwt ce326b80 cpp0 55411 ce7f3aa0 ce94b000 0 55408 16280 004082 3 wait ce7f3aa0 cc 55410 cdc19cc0 cdcb6000 0 55404 16280 004082 3 wait cdc19cc0 cc 55409 cde59000 ce012000 0 55397 16280 004082 3 wait cde59000 cc 55408 ce017660 ce2ff000 0 55317 16280 004082 3 wait ce017660 sh 55407 ce424860 ce46e000 0 55396 16280 004086 3 piperd cdd9e860 as 55406 ce3a9640 ce3f6000 0 55396 16280 004006 3 vmwait c02e1e38 cc1 55405 cdcd6760 cdd3d000 0 55396 16280 004086 3 pipdwt ce036dc0 cpp0 55404 ce3a8540 ce1ee000 0 55317 16280 004082 3 wait ce3a8540 sh 55403 ce6af960 ce6d2000 0 55395 16280 004086 3 piperd ce401120 as 55402 cea9cfc0 ceb39000 0 55395 16280 004006 3 vmwait c02e1e38 cc1 55400 cde5a540 ce0eb000 0 55386 16280 004086 3 piperd cdd9e720 as 55399 ce60afe0 ce666000 0 55386 16280 004006 3 vmwait c02e1e38 cc1 55397 ce573520 ce59b000 0 55317 16280 004082 3 wait ce573520 sh 55396 ce98a960 ce9b3000 0 55389 16280 004082 3 wait ce98a960 cc 55395 ce017aa0 ce2f8000 0 55394 16280 004082 3 wait ce017aa0 cc 55394 ce3aa300 ce3db000 0 55317 16280 004082 3 wait ce3aa300 sh 55393 ce426620 ce436000 0 55377 16280 004086 3 piperd ce0389e0 as 55392 cdcd5880 cdd95000 0 55378 16280 004086 3 piperd ce5415a0 as 55391 ce6aeca0 ce6f0000 0 55378 16280 004006 3 vmwait c02e1e38 cc1 55390 ce424640 ce470000 0 55378 16280 004086 3 pipdwt ce328200 cpp0 55389 ce7f4dc0 ce921000 0 55317 16280 004082 3 wait ce7f4dc0 sh 55388 ce571760 ce613000 0 55377 16280 004006 3 vmwait c02e1e38 cc1 55387 cdc1b860 cdc6e000 0 55377 16280 004086 3 pipdwt ce3ffc80 cpp0 55386 ce30eb80 ce330000 0 55385 16280 004082 3 wait ce30eb80 cc 55385 cdcd8300 cdd13000 0 55317 16280 004082 3 wait cdcd8300 sh 55384 cde5cda0 cde7a000 0 55374 16280 004086 3 piperd cdbe6cc0 as 55383 ce574620 ce57f000 0 55375 16280 004086 3 piperd ce8b6e00 as 55382 ce60c0e0 ce645000 0 55374 16280 004006 3 vmwait c02e1e38 cc1 55381 ce98a0e0 ce9c1000 0 55375 16280 004006 3 vmwait c02e1e38 cc1 55380 ce019640 ce0cf000 0 55375 16280 004086 3 pipdwt ce037540 cpp0 55379 cde5dc80 cde5e000 0 55374 16280 004086 3 pipdwt ce544340 cpp0 55378 cdc19880 cdcc0000 0 55376 16280 004082 3 wait cdc19880 cc 55377 ce30c320 ce377000 0 55373 16280 004082 3 wait ce30c320 cc 55376 ce6ac880 ce095000 0 55317 16280 004082 3 wait ce6ac880 sh 55375 cdc1afe0 cdc88000 0 55364 16280 004082 3 wait cdc1afe0 cc 55374 ce987aa0 cea61000 0 55372 16280 004082 3 wait ce987aa0 cc 55373 ce60cfc0 ce630000 0 55317 16280 004082 3 wait ce60cfc0 sh 55372 ce6adba0 ce708000 0 55317 16280 004082 3 wait ce6adba0 sh 55371 cdcd9400 cdceb000 0 55361 16280 004086 3 piperd ce544f20 as 55370 ce60a100 ce684000 0 55361 16280 004086 3 piperd ce036f00 cc1 55369 ce7f3ee0 ce942000 0 55360 16280 004086 3 piperd ce037d60 as 55368 ce7f3440 ce979000 0 55360 16280 004006 3 vmwait c02e1e38 cc1 55367 cde5da60 cde61000 0 55361 16280 004006 3 vmwait c02e1e38 cpp0 55366 ce609880 ce695000 0 55360 16280 004086 3 pipdwt cdd9f1c0 cpp0 55365 ce4d5a80 ce51d000 0 55352 16280 004086 3 piperd ce8b6180 as 55364 ce60aba0 ce66c000 0 55317 16280 004082 3 wait ce60aba0 sh 55363 ce60a320 ce681000 0 55352 16280 004006 3 vmwait c02e1e38 cc1 55362 ce573fc0 ce58a000 0 55352 16280 004086 3 pipdwt cdda0a20 cpp0 55361 ce276000 ce604000 0 55359 16280 004082 3 wait ce276000 cc 55360 ce017cc0 ce2ec000 0 55351 16280 004082 3 wait ce017cc0 cc 55359 ce987220 cea8e000 0 55317 16280 004082 3 wait ce987220 sh 55358 ce989ca0 ce9c7000 0 55349 16280 004086 3 piperd ce328340 as 55357 ce572a80 ce5b0000 0 55349 16280 004006 3 vmwait c02e1e38 cc1 55356 cdcd6fe0 cdd30000 0 55347 16280 004086 3 piperd cdbe7bc0 as 55354 cdc1bec0 cdc60000 0 55347 16280 004006 3 vmwait c02e1e38 cc1 55353 ce7f6fc0 ce8bc000 0 55347 16280 004086 3 pipdwt cdd9d1e0 cpp0 55352 cdcd5cc0 cdd8f000 0 55350 16280 004082 3 wait cdcd5cc0 cc 55351 ce98b1e0 ce9a4000 0 55317 16280 004082 3 wait ce98b1e0 sh 55350 ce4d71e0 ce4eb000 0 55317 16280 004082 3 wait ce4d71e0 sh 55349 ce4d7c80 ce4d8000 0 55338 16280 004082 3 wait ce4d7c80 cc 55348 cdcd5aa0 cdd92000 0 55337 16280 004086 3 piperd cdd9f4e0 as 55347 ce6aea80 ce6f3000 0 55336 16280 004082 3 wait ce6aea80 cc 55346 ce987000 cea97000 0 55337 16280 004006 3 vmwait c02e1e38 cc1 55345 ce30c540 ce36f000 0 55332 16280 004086 3 piperd ce8b58c0 as 55344 ce422000 ce4cf000 0 55337 16280 004086 3 pipdwt ce8b5be0 cpp0 55343 ce989a80 ce9ca000 0 55327 16280 004086 3 piperd ce400f40 as 55342 ce987ee0 cea13000 0 55327 16280 004006 3 vmwait c02e1e38 cc1 55341 ce3a9ec0 ce3e7000 0 55332 16280 004006 3 vmwait c02e1e38 cc1 55340 ce01ada0 ce033000 0 55332 16280 004086 3 pipdwt ce5447a0 cpp0 55339 cdc1aba0 cdc93000 0 55327 16280 004086 3 pipdwt cdd9dbe0 cpp0 55338 ce6ac440 ce7cb000 0 55317 16280 004082 3 wait ce6ac440 sh 55337 ce3a9860 ce3f4000 0 55331 16280 004082 3 wait ce3a9860 cc 55336 cdcd9620 cdce8000 0 55317 16280 004082 3 wait cdcd9620 sh 55335 ce4d5ca0 ce514000 0 55325 16280 004086 3 piperd ce327260 as 55334 ce60adc0 ce669000 0 55325 16280 004006 3 vmwait c02e1e38 cc1 55333 ce6ae640 ce6f8000 0 55325 16280 004086 3 pipdwt ce3ff280 cpp0 55332 ce423320 ce49f000 0 55326 16280 004082 3 wait ce423320 cc 55331 ce424ec0 ce462000 0 55317 16280 004082 3 wait ce424ec0 sh 55327 ce018ba0 ce0e9000 0 55324 16280 004082 3 wait ce018ba0 cc 55326 cde5c740 cdf18000 0 55317 16280 004082 3 wait cde5c740 sh 55325 cdd5d960 cdd89000 0 55323 16280 004082 3 wait cdd5d960 cc 55324 ce3a8dc0 ce1e0000 0 55317 16280 004082 3 wait ce3a8dc0 sh 55323 ce278ca0 ce38d000 0 55317 16280 004082 3 wait ce278ca0 sh 55322 ce4d3220 ce565000 0 55321 16280 004006 3 vmwait c02e1e38 cc 55321 cdd5ca80 cddb5000 0 55317 16280 004082 3 wait cdd5ca80 sh 55317 ce019420 ce071000 0 47279 16280 004086 3 select c02e0e14 make 47279 ce423540 ce49c000 0 47278 16280 004082 3 wait ce423540 sh 47278 cdd5b760 cde02000 0 44596 16280 004086 3 select c02e0e14 make 44596 cdc1c0e0 cdc59000 0 44592 16280 004082 3 wait cdc1c0e0 sh 44592 cdc1c520 cdc4f000 0 16292 16280 004086 3 select c02e0e14 make 16702 ce276cc0 ce1d1000 0 16700 16702 004106 3 sysctl c02ca000 systat 16700 ce609000 ce6aa000 0 16699 16700 2004082 3 pause ce6aa108 csh 16699 ce017880 ce2fb000 0 190 16699 004084 3 select c02e0e14 rlogind 16494 cde59220 ce00f000 0 16460 16494 004106 3 vmwait c02e1e38 top 16460 cde5c300 cdf38000 0 16441 16460 2004082 3 pause cdf38108 csh 16441 cdd5aaa0 cde1e000 0 190 16441 004080 3 select c02e0e14 rlogind 16292 cdc1c740 cdc4a000 0 16288 16280 004082 3 wait cdc1c740 sh 16288 cdc1c960 cdc44000 0 16287 16280 004086 3 select c02e0e14 make 16287 cdc1cb80 cdc40000 0 16280 16280 004082 3 wait cdc1cb80 sh 16280 cdc1cda0 cdc39000 0 250 16280 004086 3 select c02e0e14 make 250 cdc1cfc0 cdc34000 0 249 250 2004082 3 pause cdc34108 csh 249 cdc1d1e0 cdc32000 0 190 249 004080 3 select c02e0e14 rlogind 239 cdc1d400 cdc2b000 0 1 239 004082 3 ttyin c11e0c10 getty 238 cdc1d620 cdc28000 0 1 238 004082 3 ttyin c11f8210 getty 237 cdc1d840 cdc25000 0 1 237 004082 3 ttyin c124f510 getty 236 cdc1da60 cdc22000 0 1 236 004082 3 ttyin c124f710 getty 235 cbc70100 cdc14000 0 1 235 004082 3 ttyin c124f910 getty 234 cbc70ba0 cdbec000 0 1 234 004082 3 ttyin c124fb10 getty 233 cdc1dc80 cdc1f000 0 1 233 004082 3 ttyin c124fd10 getty 232 cbc6fee0 cdc17000 0 1 232 004082 3 ttyin c124ff10 getty 231 cbc71200 cdbe0000 0 1 231 004082 3 ttyin c10dff10 getty 200 cbc70320 cdc0f000 0 1 200 000080 3 select c02e0e14 usbd 195 cbc70540 cdc0c000 0 1 195 000184 3 select c02e0e14 sendmail 192 cbc70760 cdbf4000 0 1 192 000080 3 nanslp c02ca104 cron 190 cbc70fe0 cdbe3000 0 1 190 000080 3 select c02e0e14 inetd 168 cbc70dc0 cdbe9000 0 1 168 000084 3 select c02e0e14 syslogd 145 cbc70980 cdbef000 0 1 145 000080 3 select c02e0e14 dhclient 5 cbc71420 cc868000 0 0 0 000204 3 syncer c02e0d28 syncer 4 cbc71640 cc866000 0 0 0 100204 3 psleep c02ca368 bufdaemon 3 cbc71860 cc864000 0 0 0 000204 3 allproc c02e08a0 vmdaemon 2 cbc71a80 cc862000 0 0 0 100204 3 psleep c02ace78 pagedaemon 24 cbc71ca0 cc4e4000 0 0 0 000204 6 swi0: tty:sio 23 cbc71ec0 cc4e2000 0 0 0 000204 6 irq7: ppc0 22 cbc720e0 cc4e0000 0 0 0 000204 6 irq6: fdc0 21 cbc72300 cc4de000 0 0 0 000204 6 irq1: atkbd0 20 cbc72520 cc4d6000 0 0 0 000204 6 irq17: ahc0 ahc1 19 cbc72740 cc4ce000 0 0 0 000204 6 irq19: fxp0+ 18 cbc72960 cc4cb000 0 0 0 000204 6 swi3: cambio 17 cbc72b80 cc4c9000 0 0 0 000204 6 swi2: camnet 16 cbc72da0 cc4c7000 0 0 0 000204 6 swi5: task queue 15 cbc72fc0 cc4c5000 0 0 0 000204 3 rndslp c02b8dcc random 14 cbc731e0 cc4c3000 0 0 0 000204 6 swi4: vm 13 cbc73400 cc4c1000 0 0 0 00020c 3 allproc c02e08a0 swi6: clock 12 cbc73620 cc4bf000 0 0 0 000204 3 allproc c02e08a0 swi1: net 11 cbc73840 cbc7c000 0 0 0 00020c 2 idle: cpu0 10 cbc73a60 cbc7a000 0 0 0 00020c 2 idle: cpu1 1 cbc73c80 cbc78000 0 0 1 004284 3 wait cbc73c80 init 0 c02dfe60 c0364000 0 0 0 000204 3 vmwait c02e1e38 swapper 55464 ce989420 ce9d4000 0 55463 16280 006006 5 cc 55464 ce989420 ce9d4000 0 55463 16280 006006 5 cc -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 9:20: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id DB8AB37B401 for ; Tue, 23 Jan 2001 09:19:43 -0800 (PST) Received: (qmail 3423 invoked by uid 100); 23 Jan 2001 17:19:43 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14957.48431.166493.714278@guru.mired.org> Date: Tue, 23 Jan 2001 11:19:43 -0600 (CST) To: current@freebsd.org Subject: Why would my IRQs suddenly move? X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After installing a fresh cvsup last Sunday, I find that my usb printer quit working. Some investigation shows that this is because the uhci and fxp are now on the same IRQ. This hasn't been a problem previously. I haven't made any hardware changes in quite a while, and haven't mucked around with the BIOS either. Anyone got a clue as to why the IRQ would change? Is there anything in FreeBSD that could change it? Thanx, http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 9:25: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 44E2737B404 for ; Tue, 23 Jan 2001 09:24:47 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f0NHOft24125 for ; Tue, 23 Jan 2001 09:24:42 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: current@freebsd.org Subject: world build broken in -current as of yesterday Date: Tue, 23 Jan 2001 09:24:41 -0800 Message-ID: <24121.980270681@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ===> usr.bin/vmstat cc -O -pipe -I/usr/src/usr.bin/vmstat/../../sys -I/usr/obj/usr/src/i386/usr/in clude -c /usr/src/usr.bin/vmstat/vmstat.c /usr/src/usr.bin/vmstat/vmstat.c:483: warning: `pgtok' redefined /usr/obj/usr/src/i386/usr/include/machine/param.h:166: warning: this is the loca tion of the previous definition /usr/src/usr.bin/vmstat/vmstat.c: In function `dozmem': /usr/src/usr.bin/vmstat/vmstat.c:907: structure has no member named `znext' *** Error code 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 9:34:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 275F337B402 for ; Tue, 23 Jan 2001 09:34:09 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0NHXrs82881; Tue, 23 Jan 2001 10:33:58 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101231733.f0NHXrs82881@aslan.scsiguy.com> To: John Hay Cc: current@freebsd.org Subject: Re: ahc messages In-Reply-To: Your message of "Sat, 23 Jan 2001 09:30:14 +0200." <200101230730.f0N7UED32260@zibbi.icomtek.csir.co.za> Date: Tue, 23 Jan 2001 10:33:53 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On a current SMP box running a kernel from this morning I see messages >from the ahc driver I haven't seen before. The machine keeps on running >though. Should I worry about them or back down to kernel of yesterday? Hmmm. Can you add a call to "ahc_dump_card_state(ahc);" after the "WARNING" printf in aic7xxx.c? I'm trying to reproduce this here as well. I don't know what I've changed that could cause the qoutfifo to become confused. How many drives do you have on the controller? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 10:22:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 16C0437B404; Tue, 23 Jan 2001 10:22:21 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0NIMGx48186; Tue, 23 Jan 2001 10:22:16 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0NILqp25993; Tue, 23 Jan 2001 10:21:52 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <23620.980267723@critter> Date: Tue, 23 Jan 2001 10:21:52 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Poul-Henning Kamp Subject: RE: make -j 128 world hang.... Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Jan-01 Poul-Henning Kamp wrote: > > I can still stall my 2xPII/350 machine with a make -j 128 world, > but it is slightly different now I think: I can break into ddb. > > This machine is a ahc/scsi machine, so I don't know if this is > really SMP or Justins recent changes... > > Poul-Henning Ok, the problem children here are the 'allproc' waiters, which are waiting on the allproc lock. I have had this lockup occur once so far. It appears to be a deadlock in the lockmgr (surprise, suprise). When I had this, the allproc lockmgr lock has 1 pending exclusive lock and 4 pending exclusive locks, and 1 existing shared lock. However, the actual lockmgr struct itself thought it had 1 existing shared lock and 5 pending shared locks. *sigh* I tried to dig around and determined that my smp_hlt.patch had made it worse because cpu0 had basically HLT'd and never been woken up, and cpu1 was spinning forever in lockmgr in the atkbd0 ithread. I got no farther than that, however: > 55818 cdc1ba80 cdc6c000 0 55775 16280 004006 3 allproc c02e08a0 cc Exclusive lock for wait4() or exit1(). I think exit1(). > 13 cbc73400 cc4c1000 0 0 0 00020c 3 allproc c02e08a0 swi6: > clock > 12 cbc73620 cc4bf000 0 0 0 000204 3 allproc c02e08a0 swi1: > net These are both shared lock waiters. The fact that softclock() is blocked is why the machine "locks up". It is blocked in schedcpu(), and no timeouts are being called. I have a vmcore and kernel.debug and have futzed around in gdb with them for a while but don't know why it is locked up. IIRC, the atkbd thread was stuck here: /* * This is the waitloop optimization, and note for this to work * simple_lock and simple_unlock should be subroutines to avoid * optimization troubles. */ static int apause(struct lock *lkp, int flags) { #ifdef SMP int i, lock_wait; #endif if ((lkp->lk_flags & flags) == 0) return 0; #ifdef SMP for (lock_wait = LOCK_WAIT_TIME; lock_wait > 0; lock_wait--) { mtx_exit(lkp->lk_interlock, MTX_DEF); for (i = LOCK_SAMPLE_WAIT; i > 0; i--) if ((lkp->lk_flags & flags) == 0) break; mtx_enter(lkp->lk_interlock, MTX_DEF); if ((lkp->lk_flags & flags) == 0) return 0; } #endif return 1; } If you want some fun, stick KTR and KTR_EXTEND in your kernel. Then, before you start your world, do: sysctl -w debug.ktr.mask=0x1008 To log process switches (0x1000) and mutex ops (8). When you break into ddb, you can use 'tbuf' to display the first entry in the log buffer, and 'tnext' to display the next entry. Then tnext again, etc. If you can get a core dump (it worked for me on my dual 200 at least), then I have gdb macros that allow you to dump the KTR logs in gdb easily. As for a fix, Jason Evans has implemented and tested and will hopefully soon commit some simpler and lighter weith shared/exclusive locks that allproc and proctree will switch to using. However, lockmgr is used in lots of places, so it is still in our best interest to get it fixed. Also, for the preemptive kernel, (which is very close to running stably on UP and SMP x86 and UP alpha last I heard, just some problems with FPU state) all these #ifdef SMP's will have to go away and we will use mutexes in UP as well. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 10:26: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 1450E37B699 for ; Tue, 23 Jan 2001 10:25:42 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0NIf6S01012; Tue, 23 Jan 2001 10:41:06 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101231841.f0NIf6S01012@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Mike Meyer Cc: current@freebsd.org Subject: Re: Why would my IRQs suddenly move? In-reply-to: Your message of "Tue, 23 Jan 2001 11:19:43 CST." <14957.48431.166493.714278@guru.mired.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jan 2001 10:41:06 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > After installing a fresh cvsup last Sunday, I find that my usb printer > quit working. Some investigation shows that this is because the uhci > and fxp are now on the same IRQ. Why would this cause your printer to stop working? Have you determined that this is actually the case, or did you only just notice that they're on the same IRQ? > Anyone got a clue as to why the IRQ would change? Is there anything in > FreeBSD that could change it? Has it actually changed? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 10:34:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 3D6F837B404 for ; Tue, 23 Jan 2001 10:34:18 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id f0NIY5G47608; Tue, 23 Jan 2001 20:34:05 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200101231834.f0NIY5G47608@zibbi.icomtek.csir.co.za> Subject: Re: ahc messages In-Reply-To: <200101231733.f0NHXrs82881@aslan.scsiguy.com> from "Justin T. Gibbs" at "Jan 23, 2001 10:33:53 am" To: gibbs@scsiguy.com (Justin T. Gibbs) Date: Tue, 23 Jan 2001 20:34:05 +0200 (SAT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >On a current SMP box running a kernel from this morning I see messages > >from the ahc driver I haven't seen before. The machine keeps on running > >though. Should I worry about them or back down to kernel of yesterday? > > Hmmm. Can you add a call to "ahc_dump_card_state(ahc);" after the > "WARNING" printf in aic7xxx.c? I'm trying to reproduce this here as > well. I don't know what I've changed that could cause the qoutfifo > to become confused. How many drives do you have on the controller? There are 3 drives on the controller. Almost everything is on da0 except /usr/obj that is on da2. Releases are also built on da2. da1 is mostly idle. I have only seen it once. The first time after a reboot with the new kernel. I have now rebooted again with the same kernel and built a whole release with a squeek from ahc. Is it possible that it could have been some interaction or leftover from the previous sequencer code or something like that? I'll put ahc_dump_card_state(ahc) in. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 12: 1:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id 6214237B402 for ; Tue, 23 Jan 2001 12:01:32 -0800 (PST) Received: (qmail 833 invoked by uid 100); 23 Jan 2001 20:01:27 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14957.58135.667966.116745@guru.mired.org> Date: Tue, 23 Jan 2001 14:01:27 -0600 (CST) To: Mike Smith Cc: current@freebsd.org Subject: Re: Why would my IRQs suddenly move? In-Reply-To: <200101231841.f0NIf6S01012@mass.dis.org> References: <14957.48431.166493.714278@guru.mired.org> <200101231841.f0NIf6S01012@mass.dis.org> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith types: > > After installing a fresh cvsup last Sunday, I find that my usb printer > > quit working. Some investigation shows that this is because the uhci > > and fxp are now on the same IRQ. > Why would this cause your printer to stop working? Have you determined > that this is actually the case, or did you only just notice that they're > on the same IRQ? I don't know why it would cause the printer to stop working. I didn't just notice that the IRQs were the same - I checked for it specifically. What I noticed was that the printer wasn't working, and lpq showed it as possibly offline. When I first installed the USB printer, I had the exact same problem - until I changed changed the hardware config so that the fxp and uhci weren't using the same IRQ. That's why I checked for this case. > > Anyone got a clue as to why the IRQ would change? Is there anything in > > FreeBSD that could change it? > Has it actually changed? I'm still trying to figure that one out. I haven't been able to get a config with the fxp and uhci on different IRQs. I've got a doctor's appointment, after which I'm going to pull the fxp and see how that goes. Thanx, http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 12:35:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 10A1F37B402 for ; Tue, 23 Jan 2001 12:35:15 -0800 (PST) Received: from kampala-54.budapest.interware.hu ([195.70.52.246] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LA9o-0007Vj-00 for ; Tue, 23 Jan 2001 21:35:13 +0100 Message-ID: <3A6DA32E.D92AB30C@elischer.org> Date: Tue, 23 Jan 2001 07:28:46 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Subject: mountd changed? Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Suddenly the following error messages occur: Jan 23 07:21:02 jules mountd[435]: can't export /unused Jan 23 07:21:02 jules mountd[435]: bad exports list line /unused -maproot Jan 23 07:21:02 jules mountd[435]: could not remount /usr: Bad address Jan 23 07:21:02 jules mountd[435]: bad exports list line /usr -alldirs -maproot The file is: /unused -maproot=root vjules /usr -alldirs -maproot=root vjules vjules is just fine as an address: julian@jules:ping vjules PING vjules (192.168.254.2): 56 data bytes ..... CVS shows no changes to mountd recently. this /etc/exports file was working fine a couple of weeks ago. Is this related to the 'ucred' thing people have been talking about? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 12:41:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id A533B37B404 for ; Tue, 23 Jan 2001 12:40:53 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0NKenx58454; Tue, 23 Jan 2001 12:40:49 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0NKeO827829; Tue, 23 Jan 2001 12:40:24 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3A6DA32E.D92AB30C@elischer.org> Date: Tue, 23 Jan 2001 12:40:24 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: Julian Elischer Subject: RE: mountd changed? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 23-Jan-01 Julian Elischer wrote: > Suddenly the following error messages occur: > Jan 23 07:21:02 jules mountd[435]: can't export /unused > Jan 23 07:21:02 jules mountd[435]: bad exports list line /unused > -maproot > Jan 23 07:21:02 jules mountd[435]: could not remount /usr: Bad > address > Jan 23 07:21:02 jules mountd[435]: bad exports list line /usr > -alldirs > -maproot > > The file is: > /unused -maproot=root vjules > /usr -alldirs -maproot=root vjules > > vjules is just fine as an address: > julian@jules:ping vjules > PING vjules (192.168.254.2): 56 data bytes > ..... > > CVS shows no changes to mountd recently. > > this /etc/exports file was working fine a couple of weeks ago. > Is this related to the 'ucred' thing people have been talking about? Possibly, are your kernel and world out of sync? You should've gotten evil console messages about trying to malloc some obscene amount of memory like 128MB though. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 12:52:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id DC25637B69C; Tue, 23 Jan 2001 12:52:31 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0NKqVw09628; Tue, 23 Jan 2001 12:52:31 -0800 (PST) Date: Tue, 23 Jan 2001 12:52:31 -0800 From: Alfred Perlstein To: John Baldwin Cc: Julian Elischer , current@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: mountd changed? Message-ID: <20010123125231.D26076@fw.wintelcom.net> References: <3A6DA32E.D92AB30C@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Tue, Jan 23, 2001 at 12:40:24PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Baldwin [010123 12:41] wrote: > > On 23-Jan-01 Julian Elischer wrote: > > Suddenly the following error messages occur: > > Jan 23 07:21:02 jules mountd[435]: can't export /unused > > Jan 23 07:21:02 jules mountd[435]: bad exports list line /unused > > -maproot > > Jan 23 07:21:02 jules mountd[435]: could not remount /usr: Bad > > address > > Jan 23 07:21:02 jules mountd[435]: bad exports list line /usr > > -alldirs > > -maproot > > > > The file is: > > /unused -maproot=root vjules > > /usr -alldirs -maproot=root vjules > > > > vjules is just fine as an address: > > julian@jules:ping vjules > > PING vjules (192.168.254.2): 56 data bytes > > ..... > > > > CVS shows no changes to mountd recently. > > > > this /etc/exports file was working fine a couple of weeks ago. > > Is this related to the 'ucred' thing people have been talking about? > > Possibly, are your kernel and world out of sync? You should've gotten > evil console messages about trying to malloc some obscene amount of > memory like 128MB though. No, he would have panic'd before seeing that. Something else is broken I think. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 13:30:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id D10A637B69E for ; Tue, 23 Jan 2001 13:30:23 -0800 (PST) Received: (from uucp@localhost) by ns.internet.dk (8.11.1/8.11.1) with UUCP id f0NLUMe52021 for freebsd-current@FreeBSD.ORG; Tue, 23 Jan 2001 22:30:22 +0100 (CET) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.11.1/8.11.0) with SMTP id f0NLTwx11397 for ; Tue, 23 Jan 2001 22:30:09 +0100 (CET) (envelope-from leifn@neland.dk) Message-ID: <013a01c08583$addfa8e0$0e00a8c0@neland.dk> Reply-To: "Leif Neland" From: "Leif Neland" To: Subject: uucico dies with floating point errors Date: Tue, 23 Jan 2001 22:30:05 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I pick up my mail with uucico, because I don't want to put all the mail for my domain (read: my family) in one mailbox, and I don't have a fixed ip, so etrn won't work (easily). Anyway during the last month or so, around a third of the times it runs, it appearently dies, and I get a message saying uucico died because of a floating point error. It seems I get the mail on the next call. The box is running current of 6. jan, but I¨m pretty sure it started before that. It's using user-isdn and uucp over tcp. How would I start debugging this? There is no core files, or other error messages. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 13:52:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E1E5637B6A2 for ; Tue, 23 Jan 2001 13:51:51 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA12776; Tue, 23 Jan 2001 13:51:49 -0800 Date: Tue, 23 Jan 2001 13:51:49 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jordan Hubbard Cc: current@FreeBSD.ORG Subject: Re: world build broken in -current as of yesterday In-Reply-To: <24121.980270681@winston.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nope, been fixed. I fixed it quickly and was yelled at by DES who fixed it better. > ===> usr.bin/vmstat > cc -O -pipe -I/usr/src/usr.bin/vmstat/../../sys -I/usr/obj/usr/src/i386/usr/in > clude -c /usr/src/usr.bin/vmstat/vmstat.c > /usr/src/usr.bin/vmstat/vmstat.c:483: warning: `pgtok' redefined > /usr/obj/usr/src/i386/usr/include/machine/param.h:166: warning: this is the loca > tion of the previous definition > /usr/src/usr.bin/vmstat/vmstat.c: In function `dozmem': > /usr/src/usr.bin/vmstat/vmstat.c:907: structure has no member named `znext' > *** Error code 1 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 14:21:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 8C39537B400 for ; Tue, 23 Jan 2001 14:20:55 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f0NMJ3s89808; Tue, 23 Jan 2001 15:20:37 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101232220.f0NMJ3s89808@aslan.scsiguy.com> To: John Hay Cc: current@FreeBSD.ORG Subject: Re: ahc messages In-Reply-To: Your message of "Sat, 23 Jan 2001 20:34:05 +0200." <200101231834.f0NIY5G47608@zibbi.icomtek.csir.co.za> Date: Tue, 23 Jan 2001 15:19:03 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> >On a current SMP box running a kernel from this morning I see messages >> >from the ahc driver I haven't seen before. The machine keeps on running >> >though. Should I worry about them or back down to kernel of yesterday? I know you are having difficulties reproducing this, but I believe that my latest checkin corrects the problem. Please let me know if you experience any additional difficulties. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 15:22:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.netcom.com (freebsd.netcom.com [198.211.79.3]) by hub.freebsd.org (Postfix) with ESMTP id 2C56637B400 for ; Tue, 23 Jan 2001 15:21:53 -0800 (PST) Received: (from bugs@localhost) by freebsd.netcom.com (8.8.8+Sun/8.8.8) id RAA27120; Tue, 23 Jan 2001 17:21:39 -0600 (CST) From: Mark Hittinger Message-Id: <200101232321.RAA27120@freebsd.netcom.com> Subject: Re: uucico dies with floating point errors To: leif@neland.dk Date: Tue, 23 Jan 2001 17:21:39 -0600 (CST) Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <013a01c08583$addfa8e0$0e00a8c0@neland.dk> from "Leif Neland" at Jan 23, 2001 10:30:05 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Anyway during the last month or so, around a third of the times it runs, it > appearently dies, and I get a message saying uucico died because of a > floating point error. The most frequent floating point error is a divide by zero error. I'd speculate that some statistic that uucico is calculating (say bytes/second) is causing a divide by zero floating point exception. That is - unless I didn't just look at the source and not find any floats. Maybe there is an integer divide by zero in there someplace. Are you sure it isn't generating a core in the /var/spool/uucp area someplace? Are you using the taylor uucp built from the -current source tree or an older uucico (maybe a.out format?). Floating point exceptions in a program that doesn't use fp generally implies some sort of buffer overflow and code jumping into garbage that happens to look like fp code. You can rebuild taylor with debug on and try to figure out what is happening that way. You may discover that the other side is sending a field that is too long - like a system that has larger usernames than yours does etc. Good luck! Mark Hittinger Earthlink bugs@freebsd.netcom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 16:20:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.org.ru (sweet.etrust.ru [194.84.67.5]) by hub.freebsd.org (Postfix) with ESMTP id 4F24237B698 for ; Tue, 23 Jan 2001 16:19:52 -0800 (PST) Received: by freebsd.org.ru (Postfix, from userid 1000) id 1B364130; Wed, 24 Jan 2001 03:19:50 +0300 (MSK) Date: Wed, 24 Jan 2001 03:19:50 +0300 From: "Sergey A. Osokin" To: freebsd-current@freebsd.org Subject: buildworld failed... Message-ID: <20010124031949.A95290@freebsd.org.ru> Reply-To: osa@FreeBSD.org.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! After CVSup i try to buildworld under my FreeBSD 5.0-CURRENT #0: Sat Jan 13 22:57:43 MSK 2001 box and it failed: ===> usr.bin/kdump cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/kdump.c cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c ioctl.c In file included from ioctl.c:99: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:81: warning: this is the location of the previous definition In file included from ioctl.c:51: /usr/obj/usr/src/i386/usr/include/machine/i4b_rbch_ioctl.h:45: `TELNO_MAX' undeclared here (not in a function) ioctl.c: In function `ioctlname': ioctl.c:693: invalid use of `restrict' ioctl.c:693: sizeof applied to an incomplete type *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 Any idea? -- Rgdz, /"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN osa@freebsd.org.ru X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 17:52: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.clones.com (unknown [216.70.178.182]) by hub.freebsd.org (Postfix) with ESMTP id EA94037B401; Tue, 23 Jan 2001 17:51:49 -0800 (PST) Received: from localhost (gross@localhost) by mail.clones.com (8.9.3/8.9.3) with ESMTP id RAA20390; Tue, 23 Jan 2001 17:52:23 -0800 Date: Tue, 23 Jan 2001 17:52:23 -0800 (PST) From: Glendon Gross To: Mike Meyer Cc: Mike Smith , current@freebsd.org Subject: Re: Why would my IRQs suddenly move? In-Reply-To: <14957.58135.667966.116745@guru.mired.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This sounds like a necessary consequence of the "PCI crapshoot." On Tue, 23 Jan 2001, Mike Meyer wrote: > Mike Smith types: > > > After installing a fresh cvsup last Sunday, I find that my usb printer > > > quit working. Some investigation shows that this is because the uhci > > > and fxp are now on the same IRQ. > > Why would this cause your printer to stop working? Have you determined > > that this is actually the case, or did you only just notice that they're > > on the same IRQ? > > I don't know why it would cause the printer to stop working. I didn't > just notice that the IRQs were the same - I checked for it > specifically. What I noticed was that the printer wasn't working, and > lpq showed it as possibly offline. When I first installed the USB > printer, I had the exact same problem - until I changed changed the > hardware config so that the fxp and uhci weren't using the same > IRQ. That's why I checked for this case. > > > > Anyone got a clue as to why the IRQ would change? Is there anything in > > > FreeBSD that could change it? > > Has it actually changed? > > I'm still trying to figure that one out. I haven't been able to get a > config with the fxp and uhci on different IRQs. I've got a doctor's > appointment, after which I'm going to pull the fxp and see how that > goes. > > Thanx, > -- > Mike Meyer http://www.mired.org/home/mwm/ > Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 19:51:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id 98F2837B401 for ; Tue, 23 Jan 2001 19:51:21 -0800 (PST) Received: (qmail 1445 invoked by uid 100); 24 Jan 2001 03:51:20 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14958.20792.511300.829700@guru.mired.org> Date: Tue, 23 Jan 2001 21:51:20 -0600 (CST) To: Mike Smith , current@freebsd.org Subject: Re: Why would my IRQs suddenly move? In-Reply-To: <14957.58135.667966.116745@guru.mired.org> References: <14957.48431.166493.714278@guru.mired.org> <200101231841.f0NIf6S01012@mass.dis.org> <14957.58135.667966.116745@guru.mired.org> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Meyer types: > Mike Smith types: > > > After installing a fresh cvsup last Sunday, I find that my usb printer > > > quit working. Some investigation shows that this is because the uhci > > > and fxp are now on the same IRQ. > > Why would this cause your printer to stop working? Have you determined > > that this is actually the case, or did you only just notice that they're > > on the same IRQ? > I don't know why it would cause the printer to stop working. I didn't > just notice that the IRQs were the same - I checked for it > specifically. What I noticed was that the printer wasn't working, and > lpq showed it as possibly offline. When I first installed the USB > printer, I had the exact same problem - until I changed changed the > hardware config so that the fxp and uhci weren't using the same > IRQ. That's why I checked for this case. FWIW, juggling the hardware so that the fxp and uhci controller aren't on the same IRQ, and the printer works. However, the fxp is now sharing IRQs with an an aic7890, and the uhci is sharing an irq with a 2940. Strange stuff. > > > Anyone got a clue as to why the IRQ would change? Is there anything in > > > FreeBSD that could change it? > > Has it actually changed? > I'm still trying to figure that one out. I haven't been able to get a > config with the fxp and uhci on different IRQs. I've got a doctor's > appointment, after which I'm going to pull the fxp and see how that > goes. And it looks like FreeBSD had nothing to do with it, other than not working sharing the fxp & uhci controllers. Thanx, http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 23:41:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from srcso.globis.ru (globis.ru [212.248.80.7]) by hub.freebsd.org (Postfix) with ESMTP id 2F5A537B401 for ; Tue, 23 Jan 2001 23:40:59 -0800 (PST) Received: from raduga.dyndns.org (raduga.sochi.net [212.248.82.76]) by srcso.globis.ru (8.9.3/8.9.3) with ESMTP id LAA69914 for ; Wed, 24 Jan 2001 11:12:18 +0300 (MSK) (envelope-from igor@raduga.dyndns.org) Received: (from igor@localhost) by raduga.dyndns.org (8.10.1/8.10.1) id f0O7Yag08094 for freebsd-current@freebsd.org; Wed, 24 Jan 2001 10:34:36 +0300 Date: Wed, 24 Jan 2001 10:34:30 +0300 From: Igor Robul To: freebsd-current@freebsd.org Subject: buildkernel trouble ? Message-ID: <20010124103430.A8027@linux.rainbow> Reply-To: igorr@crosswinds.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I'm tracking -CURRENT on my workstation around 3 months. Recently I have found that "make buildkernel" fails. Even with GENERIC. Ok, I have removed /usr/src/* and cvsupped again. Now, if I do make buildkernel KERNEL=MORDOR GENERIC kernel will be built, so I don't know how to build kernel now :-( Last cvsup was on 2000.01.23 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jan 23 23:49:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id A1AC737B400 for ; Tue, 23 Jan 2001 23:49:39 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0O7nZ956060; Wed, 24 Jan 2001 00:49:35 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101240749.f0O7nZ956060@harmony.village.org> To: igorr@crosswinds.net Subject: Re: buildkernel trouble ? Cc: freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Wed, 24 Jan 2001 10:34:30 +0300." <20010124103430.A8027@linux.rainbow> References: <20010124103430.A8027@linux.rainbow> Date: Wed, 24 Jan 2001 00:49:35 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010124103430.A8027@linux.rainbow> Igor Robul writes: : Hello, : I'm tracking -CURRENT on my workstation around 3 months. Recently I : have found that "make buildkernel" fails. Even with GENERIC. : Ok, I have removed : /usr/src/* and cvsupped again. Now, if I do : make buildkernel KERNEL=MORDOR : GENERIC kernel will be built, so I don't know how to build kernel now : :-( Read UPDATING: 20010122: ****************************** WARNING ****************************** buildkernel has been changed slightly ****************************** WARNING ****************************** KERNCONF replaces the variable KERNEL for buildkernel. You should update your scripts and make.conf accordingly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 1:33:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 2C1C637B400 for ; Wed, 24 Jan 2001 01:33:17 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0O9XAx99372 for ; Wed, 24 Jan 2001 01:33:10 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0O9Wjb73550 for current@FreeBSD.org; Wed, 24 Jan 2001 01:32:45 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 24 Jan 2001 01:32:45 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: current@FreeBSD.org Subject: HEADS UP: current broken for a while Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm committing another big wad of code that all depends on each other, so -current kernels are going to be broken for a while. I'll send another mail when it is back to working again. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 1:43:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by hub.freebsd.org (Postfix) with ESMTP id 2E76C37B400 for ; Wed, 24 Jan 2001 01:42:53 -0800 (PST) Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) id 14LMS4-0005pj-00; Wed, 24 Jan 2001 10:42:52 +0100 Received: from sure.surfnet.nl (sure.surfnet.nl [192.87.109.131]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.8) with ESMTP id KAA16962; Wed, 24 Jan 2001 10:42:51 +0100 (MET) Date: Wed, 24 Jan 2001 10:42:51 +0100 (CET) From: Ronald van der Pol To: Matt Dillon Cc: freebsd-current@freebsd.org Subject: Re: strong recommendation re: NFS In-Reply-To: <200101211934.f0LJYr715345@earth.backplane.com> Message-ID: X-NCC-RegID: nl.surfnet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 21 Jan 2001, Matt Dillon wrote: > Concentrate on making the general network stack (aka TCP) and > filesystems SMP aware. Leave NFS alone for now. Please. If I understand correctly another item on the wishlist is TI-RPC (so that NFS can be made IPv6 aware). What is the latest on that? rvdp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 5:26: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CC04437B402; Wed, 24 Jan 2001 05:25:40 -0800 (PST) Received: from vigrid.com (pm3-pt20.pcnet.net [206.105.29.94]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id IAA26284; Wed, 24 Jan 2001 08:25:12 -0500 (EST) Message-ID: <3A6ED750.CAB29ECC@vigrid.com> Date: Wed, 24 Jan 2001 08:23:28 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: current@FreeBSD.org Cc: ports@FreeBSD.org Subject: HEADS UP: libc/libc_r changes require rebuild of threaded apps Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As discussed a few days ago, I've just committed the changes to libc and libc_r to allow them to be linked together via -lc_r. If you're running -current and have any threaded apps built using libc_r.so.5, you'll need to rebuild them without the -pthread option using -lc_r. For porters, the __FreeBSD_version has been bumped to 500016 to reflect the above change. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 5:38: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id EFDD837B6A0; Wed, 24 Jan 2001 05:37:38 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f0ODbWT28870; Wed, 24 Jan 2001 15:37:33 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.1/8.9.3) with ESMTP id f0ODbY601497; Wed, 24 Jan 2001 15:37:34 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A6EDA94.F26C6BA6@FreeBSD.org> Date: Wed, 24 Jan 2001 15:37:24 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: "Daniel M. Eischen" Cc: current@FreeBSD.org, ports@FreeBSD.org Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps References: <3A6ED750.CAB29ECC@vigrid.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel M. Eischen" wrote: > As discussed a few days ago, I've just committed the changes to libc > and libc_r to allow them to be linked together via -lc_r. If you're > running -current and have any threaded apps built using libc_r.so.5, > you'll need to rebuild them without the -pthread option using -lc_r. > > For porters, the __FreeBSD_version has been bumped to 500016 to > reflect the above change. Could you please bump version number of libc/libc_r shared libraries, so the programs linked with older version will still work correctly? -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 5:41:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 455E737B404 for ; Wed, 24 Jan 2001 05:41:31 -0800 (PST) Received: (qmail 59704 invoked by uid 1142); 24 Jan 2001 13:41:30 -0000 Date: 24 Jan 2001 05:41:30 -0800 Date: Wed, 24 Jan 2001 05:41:19 -0800 From: Jason Evans To: Maxim Sobolev Cc: "Daniel M. Eischen" , current@FreeBSD.org, ports@FreeBSD.org Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps Message-ID: <20010124054119.M69199@canonware.com> References: <3A6ED750.CAB29ECC@vigrid.com> <3A6EDA94.F26C6BA6@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6EDA94.F26C6BA6@FreeBSD.org>; from sobomax@FreeBSD.org on Wed, Jan 24, 2001 at 03:37:24PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 03:37:24PM +0200, Maxim Sobolev wrote: > "Daniel M. Eischen" wrote: > > > For porters, the __FreeBSD_version has been bumped to 500016 to > > reflect the above change. > > Could you please bump version number of libc/libc_r shared libraries, so the > programs linked with older version will still work correctly? AFAIK, we don't bump library version numbers for -current. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 5:43:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3F9FD37B400; Wed, 24 Jan 2001 05:43:02 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id IAA28709; Wed, 24 Jan 2001 08:42:39 -0500 (EST) Date: Wed, 24 Jan 2001 08:42:39 -0500 (EST) From: Daniel Eischen To: Maxim Sobolev Cc: "Daniel M. Eischen" , current@FreeBSD.org, ports@FreeBSD.org Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps In-Reply-To: <3A6EDA94.F26C6BA6@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Maxim Sobolev wrote: > "Daniel M. Eischen" wrote: > > > As discussed a few days ago, I've just committed the changes to libc > > and libc_r to allow them to be linked together via -lc_r. If you're > > running -current and have any threaded apps built using libc_r.so.5, > > you'll need to rebuild them without the -pthread option using -lc_r. > > > > For porters, the __FreeBSD_version has been bumped to 500016 to > > reflect the above change. > > Could you please bump version number of libc/libc_r shared libraries, so the > programs linked with older version will still work correctly? It's already been bumped in -current so that we _can_ do stuff like this. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 5:44: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.net022.co.yu (mail.net022.co.yu [212.200.44.4]) by hub.freebsd.org (Postfix) with ESMTP id 94E8B37B401 for ; Wed, 24 Jan 2001 05:43:32 -0800 (PST) Received: from Athlon (dial-in11.net022.co.yu [212.200.44.20]) by mail.net022.co.yu (8.8.7/8.8.7) with SMTP id PAA06060 for ; Wed, 24 Jan 2001 15:30:49 +0100 From: Rasa Karapandza Date: Wed, 24 Jan 2001 14:06:11 +0100 X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="iso-8859-1" To: current@freebsd.org Subject: help! MIME-Version: 1.0 Message-Id: <01012414061100.55885@Athlon> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just downloaded src-cur.4700xEmpty.gz src-cur.4701 src-cur.4702 removed my old source tree installed them using CTM when trying to make world I get an error lib/libc_r/../libc/stdtime/localtime.c -o localtime.o In file included from /usr/src/lib/libc_r/../libc/stdtime/localtime.c:29: /usr/src/lib/libc_r/../../include/pthread.h:199: syntax error before ``' *** Error code 1 Stop in /usr/src/lib/libc_r. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Rasa please ansver to my personal mail account to To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 5:46:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 75A1537B400; Wed, 24 Jan 2001 05:46:28 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f0ODkOT29051; Wed, 24 Jan 2001 15:46:25 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.1/8.9.3) with ESMTP id f0ODkP601618; Wed, 24 Jan 2001 15:46:25 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A6EDCA8.8E009900@FreeBSD.org> Date: Wed, 24 Jan 2001 15:46:16 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Daniel Eischen Cc: current@FreeBSD.org, ports@FreeBSD.org Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen wrote: > On Wed, 24 Jan 2001, Maxim Sobolev wrote: > > "Daniel M. Eischen" wrote: > > > > > As discussed a few days ago, I've just committed the changes to libc > > > and libc_r to allow them to be linked together via -lc_r. If you're > > > running -current and have any threaded apps built using libc_r.so.5, > > > you'll need to rebuild them without the -pthread option using -lc_r. > > > > > > For porters, the __FreeBSD_version has been bumped to 500016 to > > > reflect the above change. > > > > Could you please bump version number of libc/libc_r shared libraries, so the > > programs linked with older version will still work correctly? > > It's already been bumped in -current so that we _can_ do stuff like this. Ah, ok. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 6:48:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from pike.osd.bsdi.com (unknown [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id CE23937B698 for ; Wed, 24 Jan 2001 06:47:53 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0OElkx15612 for ; Wed, 24 Jan 2001 06:47:46 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f0OElLG78574 for current@FreeBSD.ORG; Wed, 24 Jan 2001 06:47:21 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 24 Jan 2001 06:47:21 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: current@FreeBSD.ORG Subject: RE: HEADS UP: current broken for a while Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24-Jan-01 John Baldwin wrote: > I'm committing another big wad of code that all depends on each > other, so -current kernels are going to be broken for a while. > I'll send another mail when it is back to working again. Ok, it should be back to normal now. Sorry this took so long. Now I need to go take a long nap..... -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 7: 3:33 2001 Delivered-To: freebsd-current@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 8836637B404; Wed, 24 Jan 2001 07:03:16 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0OF3G481822; Wed, 24 Jan 2001 07:03:16 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101241503.f0OF3G481822@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: John Baldwin Cc: current@FreeBSD.ORG Subject: Re: HEADS UP: current broken for a while In-Reply-To: Date: Wed, 24 Jan 2001 07:03:16 -0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 24-Jan-01 John Baldwin wrote: > > I'm committing another big wad of code that all depends on each > > other, so -current kernels are going to be broken for a while. > > I'll send another mail when it is back to working again. > > Ok, it should be back to normal now. Sorry this took so long. Now I > need to go take a long nap..... Normal - as in "It compiles". I would *strongly* caution anybody (even more so than usual) about using -current where a crash would be bad. A lot of new stuff went in and INVARIANTS and WITNESS are still finding some edge cases. The proc locking stuff is not yet finished, this part of the commit has the files with dependencies on changes in other files. There is more to come. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 8:37:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 5EC4837B698; Wed, 24 Jan 2001 08:37:09 -0800 (PST) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.1/8.11.0) with ESMTP id f0OGb8s15794; Wed, 24 Jan 2001 09:37:08 -0700 (MST) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.1/8.8.3) with ESMTP id f0OGZMs07562; Wed, 24 Jan 2001 09:35:24 -0700 (MST) Message-Id: <200101241635.f0OGZMs07562@billy-club.village.org> To: Peter Wemm Subject: Re: HEADS UP: current broken for a while Cc: John Baldwin , current@FreeBSD.ORG In-reply-to: Your message of "Wed, 24 Jan 2001 07:03:16 PST." <200101241503.f0OF3G481822@mobile.wemm.org> References: <200101241503.f0OF3G481822@mobile.wemm.org> Date: Wed, 24 Jan 2001 09:35:22 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101241503.f0OF3G481822@mobile.wemm.org> Peter Wemm writes: : Normal - as in "It compiles". I would *strongly* caution anybody (even : more so than usual) about using -current where a crash would be bad. A lot : of new stuff went in and INVARIANTS and WITNESS are still finding some edge : cases. The proc locking stuff is not yet finished, this part of the commit : has the files with dependencies on changes in other files. There is more : to come. Will this new instability last long enough to warrant a note in UPDATING? Or is it a day or two sort of instability. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 8:41:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 0494737B698; Wed, 24 Jan 2001 08:41:01 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0OGexK11180; Wed, 24 Jan 2001 08:40:59 -0800 (PST) Date: Wed, 24 Jan 2001 08:40:58 -0800 From: Alfred Perlstein To: "Daniel M. Eischen" Cc: current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps Message-ID: <20010124084058.S26076@fw.wintelcom.net> References: <3A6ED750.CAB29ECC@vigrid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A6ED750.CAB29ECC@vigrid.com>; from eischen@vigrid.com on Wed, Jan 24, 2001 at 08:23:28AM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Daniel M. Eischen [010124 05:26] wrote: > As discussed a few days ago, I've just committed the changes to libc > and libc_r to allow them to be linked together via -lc_r. If you're > running -current and have any threaded apps built using libc_r.so.5, > you'll need to rebuild them without the -pthread option using -lc_r. > > For porters, the __FreeBSD_version has been bumped to 500016 to > reflect the above change. This is ambiguous, can you provide old/new examples of how to compile/link a single C source file? thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 9:22:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.netcom.com (freebsd.netcom.com [198.211.79.3]) by hub.freebsd.org (Postfix) with ESMTP id 287F637B402 for ; Wed, 24 Jan 2001 09:22:16 -0800 (PST) Received: (from bugs@localhost) by freebsd.netcom.com (8.8.8+Sun/8.8.8) id LAA00274 for current@freebsd.org; Wed, 24 Jan 2001 11:22:14 -0600 (CST) From: Mark Hittinger Message-Id: <200101241722.LAA00274@freebsd.netcom.com> Subject: beware libc change sigprocmask sigaction abort.c To: current@freebsd.org Date: Wed, 24 Jan 2001 11:22:14 -0600 (CST) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey watch out - one of those little changes that can blow your system up if you cheat on how you build it. abort.c references undefined symbols for sigprocmask and sigaction. Later Mark Hittinger Earthlink bugs@freebsd.netcom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 9:37: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6419C37B698; Wed, 24 Jan 2001 09:36:46 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id MAA07481; Wed, 24 Jan 2001 12:36:17 -0500 (EST) Date: Wed, 24 Jan 2001 12:36:17 -0500 (EST) From: Daniel Eischen To: Alfred Perlstein Cc: "Daniel M. Eischen" , current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps In-Reply-To: <20010124084058.S26076@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Alfred Perlstein wrote: > * Daniel M. Eischen [010124 05:26] wrote: > > As discussed a few days ago, I've just committed the changes to libc > > and libc_r to allow them to be linked together via -lc_r. If you're > > running -current and have any threaded apps built using libc_r.so.5, > > you'll need to rebuild them without the -pthread option using -lc_r. > > > > For porters, the __FreeBSD_version has been bumped to 500016 to > > reflect the above change. > > This is ambiguous, can you provide old/new examples of how to > compile/link a single C source file? What's not clear ;-) Use -lc_r instead of -pthread. gcc -Wall -o foo foo.c -lc_r The old way was: gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread Obviously -Wall isn't necessary, but it should be mandatory :-) -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 9:50:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp.alcove.fr (smtp.alcove.fr [212.155.209.139]) by hub.freebsd.org (Postfix) with ESMTP id B31F137B400; Wed, 24 Jan 2001 09:50:15 -0800 (PST) Received: from nsouch by smtp.alcove.fr with local (Exim 3.12 #1 (Debian)) id 14LU3h-0004Nc-00; Wed, 24 Jan 2001 18:50:13 +0100 Date: Wed, 24 Jan 2001 18:50:13 +0100 From: Nicolas Souchu To: Maxim Sobolev Cc: current@FreeBSD.org, sos@FreeBSD.org Subject: Re: [RFC] New features for libvgl Message-ID: <20010124185013.G12375@ontario.alcove-int> References: <3A6C7FBF.251B4C89@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.4i In-Reply-To: <3A6C7FBF.251B4C89@FreeBSD.org>; from sobomax@FreeBSD.org on Mon, Jan 22, 2001 at 08:45:19PM +0200 Organization: =?iso-8859-1?Q?Alc=F4ve=2C_http:=2F=2Fwww=2Ealcove=2Efr?= Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 08:45:19PM +0200, Maxim Sobolev wrote: > Hi folks, > > Now I'm in process of writing a libvgl driver for SDL (almost finished - I'm > testing it right now) and found that two handy features are currently missed > from the libvgl: ability to query video modes supported by the video hardware > and ability to install custom mouse eventhandler. So I extended libvgl > attaching patches with this message. I would like that someone review/comment > attached patches. Please also note that VGLListModes() part of these patches > are not optimal right now (it largely duplicates VGLInit()), so please > concentrate on concept rather than on implementation details. Isn't your list of modes redundant with the internal data structures of the VGA/VESA driver? Why do you list modes if it's not to query a specific one? This is how I query the console (note that I planned to add it to VGL): memset(&modeinfo, 0, sizeof(modeinfo)); switch(gt) { case GT_1BIT : modeinfo.vi_depth = 1; break; case GT_4BIT : modeinfo.vi_depth = 4; break; case GT_8BIT : modeinfo.vi_depth = 8; break; case GT_16BIT: modeinfo.vi_depth = 16; break; case GT_32BIT: modeinfo.vi_depth = 32; break; /* Unsupported mode depths */ case GT_15BIT: case GT_24BIT: default: return -1; } modeinfo.vi_width = tm->visible.x; modeinfo.vi_height = tm->visible.y; /* XXX should be added to libvgl */ if (ioctl(0, FBIO_FINDMODE, &modeinfo)) return -1; GGIDPRINT("Setting VGLlib mode %d (0x%x)\n", modeinfo.vi_mode, modeinfo.vi_mode); /* Terminate any current mode before initialising another */ if (priv->vgl_init_done) { priv->vgl_init_done = 0; VGLEnd(); } /* XXX should be in VGL */ if ((modeinfo.vi_mode >= M_B40x25) && (modeinfo.vi_mode <= M_VGA_M90x60) ) modenum = _IO('S', modeinfo.vi_mode); if ((modeinfo.vi_mode >= M_TEXT_80x25) && (modeinfo.vi_mode <= M_TEXT_13 2x60)) modenum = _IO('S', modeinfo.vi_mode); if ((modeinfo.vi_mode >= M_VESA_CG640x400) && (modeinfo.vi_mode <= M_VESA_FULL_1280)) modenum = _IO('V', modeinfo.vi_mode - M_VESA_BASE); if ((err = VGLInit(modenum)) != 0) { GGIDPRINT("display-vgl: setting mode 0x%x failed with error %d\n ", modeinfo.vi_mode, err); return GGI_EFATAL; } ++++++++++++++++++++++++ About the mouse stuff, what is the exact usage of MousePointerShow? It's not documented in the manpage. Nicholas -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 9:57:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 312A637B400; Wed, 24 Jan 2001 09:57:14 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f0OHv1t76723; Wed, 24 Jan 2001 09:57:01 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Daniel Eischen Cc: Alfred Perlstein , current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps In-Reply-To: Message from Daniel Eischen of "Wed, 24 Jan 2001 12:36:17 EST." Date: Wed, 24 Jan 2001 09:57:01 -0800 Message-ID: <76719.980359021@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What's not clear ;-) Use -lc_r instead of -pthread. > > gcc -Wall -o foo foo.c -lc_r > > The old way was: > > gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread Hmmmm. And does the -pthread argument do anything anymore? If not, why not have it default to simply linking in libc_r for POLA's sake and ease of transition? If it does do something different now, perhaps you could explain what that is for all of us who are also confused. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 10: 0:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from hera.drwilco.net (10dyn101.dh.casema.net [212.64.31.101]) by hub.freebsd.org (Postfix) with ESMTP id E02DB37B400 for ; Wed, 24 Jan 2001 09:59:49 -0800 (PST) Received: from ceres.drwilco.net (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0OILmd18095 for ; Wed, 24 Jan 2001 19:21:51 +0100 (CET) (envelope-from drwilco@drwilco.net) Message-Id: <4.3.2.7.0.20010124185058.00ac5100@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Jan 2001 19:01:27 +0100 To: freebsd-current@freebsd.org From: "Rogier R. Mulhuijzen" Subject: status of bridge code Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is anyone working on the bridge code? I've got a couple of things I'd like to fix in it, but I wouldn't want to be doing anything someone else already did. My wishlist: 1) Better interaction with various drivers (like if_tap). For some reason I need to do a wack (undocumented) sysctl to make the bridge code refresh the iface list 2) Spontanious kablooies. After being in operation for a while it refuses to send anything through and doesn't spew any messages.... 3) Improve documentation. 3) iface clustering/routing 4) spanning tree implementation There's talk of a userland daemon for the last item. Is there such a thing, and if so, where. If there's no such daemon (not even halfway done), what would be the best way for a daemon like that to interact with the kernel source? A device or sysctl's? Is there any bridging part of BSDi maybe that could be merged into our networking code. Being used a lot in key networking positions FreeBSD should really have good bridging. I've heard a few people who tried it complain about the 2nd item on my list. Being an allround good networking OS this is unacceptable IMHO. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 10: 4:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 9A7BB37B400 for ; Wed, 24 Jan 2001 10:04:14 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.1/8.11.1) with ESMTP id f0OI4Da18391 for ; Wed, 24 Jan 2001 10:04:14 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.3.p0.FreeBSD:010124100413:25635=_" Date: Wed, 24 Jan 2001 10:04:13 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: current@freebsd.org Subject: Please test this patch to restore "cc -pthread" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:010124100413:25635=_ Content-Type: text/plain; charset=us-ascii Here is a patch which should make "cc -pthread" work properly with Dan Eischen's recent libc & libc_r changes. I'd appreciate it if some people running up-to-date -current would test it. I especially need testers who can use it to build some threaded applications. Recommended test procedure: - apply the patch to src/contrib/gcc.295/config/freebsd.h - rebuild and install world - rebuild some threaded apps and see if they still work Thanks, John --_=XFMail.1.3.p0.FreeBSD:010124100413:25635=_ Content-Disposition: attachment; filename="freebsd.h.patch" Content-Description: freebsd.h.patch Content-Type: text/plain; charset=us-ascii; name=freebsd.h.patch; SizeOnDisk=893 Content-Transfer-Encoding: 7bit Index: freebsd.h =================================================================== RCS file: /home/ncvs/src/contrib/gcc.295/config/freebsd.h,v retrieving revision 1.30 diff -u -r1.30 freebsd.h --- freebsd.h 2000/11/07 21:49:08 1.30 +++ freebsd.h 2001/01/24 17:05:35 @@ -71,17 +71,14 @@ #define CPP_SPEC FBSD_CPP_SPEC /* Provide a LIB_SPEC appropriate for FreeBSD. Just select the appropriate - libc, depending on whether we're doing profiling. + libc, depending on whether we're doing profiling. Add the appropriate + libc_r if supporting threads. (like the default, except no -lg, and no -p). */ #undef LIB_SPEC #define LIB_SPEC "\ %{!shared: \ - %{!pg: \ - %{!pthread:-lc} \ - %{pthread:-lc_r}} \ - %{pg: \ - %{!pthread:-lc_p} \ - %{pthread:-lc_r_p}} \ + %{!pg: %{pthread:-lc_r} -lc} \ + %{pg: %{pthread:-lc_r_p} -lc_p} \ }" --_=XFMail.1.3.p0.FreeBSD:010124100413:25635=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 10:14:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id A279837B401; Wed, 24 Jan 2001 10:14:34 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f0OIEHT02398; Wed, 24 Jan 2001 20:14:21 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.1/8.9.3) with ESMTP id f0OIEI603115; Wed, 24 Jan 2001 20:14:18 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A6F1B68.9AA53C0B@FreeBSD.org> Date: Wed, 24 Jan 2001 20:14:01 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Nicolas Souchu Cc: current@FreeBSD.org, sos@FreeBSD.org Subject: Re: [RFC] New features for libvgl References: <3A6C7FBF.251B4C89@FreeBSD.org> <20010124185013.G12375@ontario.alcove-int> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nicolas Souchu wrote: > On Mon, Jan 22, 2001 at 08:45:19PM +0200, Maxim Sobolev wrote: > > Hi folks, > > > > Now I'm in process of writing a libvgl driver for SDL (almost finished - I'm > > testing it right now) and found that two handy features are currently missed > > from the libvgl: ability to query video modes supported by the video hardware > > and ability to install custom mouse eventhandler. So I extended libvgl > > attaching patches with this message. I would like that someone review/comment > > attached patches. Please also note that VGLListModes() part of these patches > > are not optimal right now (it largely duplicates VGLInit()), so please > > concentrate on concept rather than on implementation details. > > Isn't your list of modes redundant with the internal data structures of the > VGA/VESA driver? Why do you list modes if it's not to query a specific one? I believe that there should be possibility to do both these things, i.e. (1) query list of available modes using some filter, so the aplication/toolkit will be able to select one that matches its needs, and (2) let the video driver select the best one given certain constrains. For example SDL provides a possibility to at least emulate mode if is not directly available from video hardware, so it need to know what the alternatives are. I'm not very adamant about using internal data structures of video driver, because they are too generic and include too much irrelevant details. Probably we should extent VGLBitmap to include missing bits (depth, masks, etc). > [skip] > > ++++++++++++++++++++++++ Well, it's nice, but I'm not sure how it would work in the case of more high level toolkit (like SDL). As I said earlier, application can request an arbitrary mode, i.e. 349x246x19, so we have to do some adjustments before passing these parameters to the video driver- to do this we should know what the alternatives are. > About the mouse stuff, what is the exact usage of MousePointerShow? It's > not documented in the manpage. It's internal VGL function used to draw a mouse pointer at the screen. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 10:23:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 249A037B400; Wed, 24 Jan 2001 10:23:11 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA15593; Wed, 24 Jan 2001 13:22:44 -0500 (EST) Date: Wed, 24 Jan 2001 13:22:43 -0500 (EST) From: Daniel Eischen To: Jordan Hubbard Cc: Alfred Perlstein , current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps In-Reply-To: <76719.980359021@winston.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Jordan Hubbard wrote: > > What's not clear ;-) Use -lc_r instead of -pthread. > > > > gcc -Wall -o foo foo.c -lc_r > > > > The old way was: > > > > gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread > > Hmmmm. And does the -pthread argument do anything anymore? If not, > why not have it default to simply linking in libc_r for POLA's sake > and ease of transition? If it does do something different now, > perhaps you could explain what that is for all of us who are also > confused. :) OK, from the original email I sent to -arch and -current in the "Request For Review:...": For those not familiar with our current libc_r, it is currently built to include a thread-safe libc as well as the POSIX threads routines. On the other hand, libc is built to be non-thread safe. This differs from other OSs and from what POSIX mandates and means that we require non-standard hacks like the linker option -pthread (which links to libc_r and prevents linking to libc). Using -pthread will prevent linking to libc and only link to libc_r. After the change I just committed, you need to link to both libc_r and libc (in that order), just like you would for a threaded application on just about any other OS (only ours is called libc_r instead of libpthread). John Polstra has a simple patch that will change the semantics of -pthread. This is obriens territory and I've steered clear of touching anything in there. I sent him an email a few days ago about this, but he's away for a couple of weeks and won't be able to do anything about it until he gets back. I'll test Johns patch, which should work just fine, and we'll let _him_ commit it ;-) -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 10:32:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 026A337B402; Wed, 24 Jan 2001 10:32:08 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f0OIVn528052; Wed, 24 Jan 2001 12:31:49 -0600 (CST) (envelope-from dan) Date: Wed, 24 Jan 2001 12:31:48 -0600 From: Dan Nelson To: Daniel Eischen Cc: Alfred Perlstein , current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps Message-ID: <20010124123147.A2215@dan.emsphone.com> References: <20010124084058.S26076@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: ; from "Daniel Eischen" on Wed Jan 24 12:36:17 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jan 24), Daniel Eischen said: > On Wed, 24 Jan 2001, Alfred Perlstein wrote: > > * Daniel M. Eischen [010124 05:26] wrote: > > > As discussed a few days ago, I've just committed the changes to libc > > > and libc_r to allow them to be linked together via -lc_r. If you're > > > running -current and have any threaded apps built using libc_r.so.5, > > > you'll need to rebuild them without the -pthread option using -lc_r. > > > > > > For porters, the __FreeBSD_version has been bumped to 500016 to > > > reflect the above change. > > > > This is ambiguous, can you provide old/new examples of how to > > compile/link a single C source file? > > What's not clear ;-) Use -lc_r instead of -pthread. > > gcc -Wall -o foo foo.c -lc_r > > The old way was: > > gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread I thought the old way was just -pthread, and it would handle everything. I did a quick scan of the devel/ and net/ branches of our ports tree, and of 43 thread-using ports, 36 of the ports simply add -pthread. Only 7 also add -D_THREAD_SAFE. The only usage of _THREAD_SAFE in /usr/include is redefinition of feof, ferror, clearerr, and fileno to *_unlocked. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 10:35:33 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C721237B400; Wed, 24 Jan 2001 10:35:11 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0OIZ6f14723; Wed, 24 Jan 2001 10:35:06 -0800 (PST) Date: Wed, 24 Jan 2001 10:35:06 -0800 From: Alfred Perlstein To: Dan Nelson Cc: Daniel Eischen , current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps Message-ID: <20010124103505.C26076@fw.wintelcom.net> References: <20010124084058.S26076@fw.wintelcom.net> <20010124123147.A2215@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010124123147.A2215@dan.emsphone.com>; from dnelson@emsphone.com on Wed, Jan 24, 2001 at 12:31:48PM -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Dan Nelson [010124 10:32] wrote: > In the last episode (Jan 24), Daniel Eischen said: > > On Wed, 24 Jan 2001, Alfred Perlstein wrote: > > > * Daniel M. Eischen [010124 05:26] wrote: > > > > As discussed a few days ago, I've just committed the changes to libc > > > > and libc_r to allow them to be linked together via -lc_r. If you're > > > > running -current and have any threaded apps built using libc_r.so.5, > > > > you'll need to rebuild them without the -pthread option using -lc_r. > > > > > > > > For porters, the __FreeBSD_version has been bumped to 500016 to > > > > reflect the above change. > > > > > > This is ambiguous, can you provide old/new examples of how to > > > compile/link a single C source file? > > > > What's not clear ;-) Use -lc_r instead of -pthread. > > > > gcc -Wall -o foo foo.c -lc_r > > > > The old way was: > > > > gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread > > I thought the old way was just -pthread, and it would handle > everything. I did a quick scan of the devel/ and net/ branches of our > ports tree, and of 43 thread-using ports, 36 of the ports simply add > -pthread. Only 7 also add -D_THREAD_SAFE. > > The only usage of _THREAD_SAFE in /usr/include is redefinition of > feof, ferror, clearerr, and fileno to *_unlocked. -D_THREAD_SAFE used to (or still does) make various foo_r function prototypes available. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 10:39: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 7F51F37B400; Wed, 24 Jan 2001 10:38:16 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f0OIbmT02809; Wed, 24 Jan 2001 20:37:51 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.1/8.9.3) with ESMTP id f0OIbp603173; Wed, 24 Jan 2001 20:37:51 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A6F20EE.15B78584@FreeBSD.org> Date: Wed, 24 Jan 2001 20:37:34 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Dan Nelson Cc: Daniel Eischen , Alfred Perlstein , current@FreeBSD.org, ports@FreeBSD.org Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps References: <20010124084058.S26076@fw.wintelcom.net> <20010124123147.A2215@dan.emsphone.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Nelson wrote: > In the last episode (Jan 24), Daniel Eischen said: > > On Wed, 24 Jan 2001, Alfred Perlstein wrote: > > > * Daniel M. Eischen [010124 05:26] wrote: > > > > As discussed a few days ago, I've just committed the changes to libc > > > > and libc_r to allow them to be linked together via -lc_r. If you're > > > > running -current and have any threaded apps built using libc_r.so.5, > > > > you'll need to rebuild them without the -pthread option using -lc_r. > > > > > > > > For porters, the __FreeBSD_version has been bumped to 500016 to > > > > reflect the above change. > > > > > > This is ambiguous, can you provide old/new examples of how to > > > compile/link a single C source file? > > > > What's not clear ;-) Use -lc_r instead of -pthread. > > > > gcc -Wall -o foo foo.c -lc_r > > > > The old way was: > > > > gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread > > I thought the old way was just -pthread, and it would handle > everything. I did a quick scan of the devel/ and net/ branches of our > ports tree, and of 43 thread-using ports, 36 of the ports simply add > -pthread. Only 7 also add -D_THREAD_SAFE. It's not a very accurate estimate, as the magic can be in the distfile itself, i.e. properly written configure script or makefile may know that FreeBSD need a -pthread and -D_THREAD_SAFE. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 10:44: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0300F37B699; Wed, 24 Jan 2001 10:43:46 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA19006; Wed, 24 Jan 2001 13:43:19 -0500 (EST) Date: Wed, 24 Jan 2001 13:43:18 -0500 (EST) From: Daniel Eischen To: Dan Nelson Cc: Alfred Perlstein , current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps In-Reply-To: <20010124123147.A2215@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Dan Nelson wrote: > In the last episode (Jan 24), Daniel Eischen said: > > On Wed, 24 Jan 2001, Alfred Perlstein wrote: > > > * Daniel M. Eischen [010124 05:26] wrote: > > > > As discussed a few days ago, I've just committed the changes to libc > > > > and libc_r to allow them to be linked together via -lc_r. If you're > > > > running -current and have any threaded apps built using libc_r.so.5, > > > > you'll need to rebuild them without the -pthread option using -lc_r. > > > > > > > > For porters, the __FreeBSD_version has been bumped to 500016 to > > > > reflect the above change. > > > > > > This is ambiguous, can you provide old/new examples of how to > > > compile/link a single C source file? > > > > What's not clear ;-) Use -lc_r instead of -pthread. > > > > gcc -Wall -o foo foo.c -lc_r > > > > The old way was: > > > > gcc -Wall -D_THREAD_SAFE -o foo foo.c -pthread > > I thought the old way was just -pthread, and it would handle > everything. I did a quick scan of the devel/ and net/ branches of our > ports tree, and of 43 thread-using ports, 36 of the ports simply add > -pthread. Only 7 also add -D_THREAD_SAFE. > > The only usage of _THREAD_SAFE in /usr/include is redefinition of > feof, ferror, clearerr, and fileno to *_unlocked. That's if _THREAD_SAFE isn't defined, otherwise the MT-safe versions of those functions are used. The same for getc(), putc(), getchar(), putchar(). If the application isn't using those functions, nor calling anything in libc that uses them, then there shouldn't be a problem in not defining _THREAD_SAFE. But to be correct, and if you see gcc(1), -D_THREAD_SAFE is recommended. This is not the case in -current; -D_THREAD_SAFE is not needed (but will not be harmful if it is used). -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 10:52:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 14F9537B402 for ; Wed, 24 Jan 2001 10:52:01 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id f0OIpSk69419; Wed, 24 Jan 2001 10:51:28 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Jan 2001 10:51:28 -0800 (PST) From: Matt Dillon Message-Id: <200101241851.f0OIpSk69419@earth.backplane.com> To: Ronald van der Pol Cc: freebsd-current@freebsd.org Subject: Re: strong recommendation re: NFS References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Sun, 21 Jan 2001, Matt Dillon wrote: : :> Concentrate on making the general network stack (aka TCP) and :> filesystems SMP aware. Leave NFS alone for now. Please. : :If I understand correctly another item on the wishlist is TI-RPC :(so that NFS can be made IPv6 aware). What is the latest on that? : : rvdp I don't think anyone is working on IPV6 issues at the moment. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 11: 3: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id F403F37B404; Wed, 24 Jan 2001 11:02:36 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f0OJ2Xn05308; Wed, 24 Jan 2001 13:02:33 -0600 (CST) (envelope-from dan) Date: Wed, 24 Jan 2001 13:02:33 -0600 From: Dan Nelson To: Maxim Sobolev Cc: Daniel Eischen , Alfred Perlstein , current@FreeBSD.org, ports@FreeBSD.org Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps Message-ID: <20010124130233.B2215@dan.emsphone.com> References: <20010124084058.S26076@fw.wintelcom.net> <20010124123147.A2215@dan.emsphone.com> <3A6F20EE.15B78584@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: <3A6F20EE.15B78584@FreeBSD.org>; from "Maxim Sobolev" on Wed Jan 24 20:37:34 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jan 24), Maxim Sobolev said: > Dan Nelson wrote: > > I thought the old way was just -pthread, and it would handle > > everything. I did a quick scan of the devel/ and net/ branches of our > > ports tree, and of 43 thread-using ports, 36 of the ports simply add > > -pthread. Only 7 also add -D_THREAD_SAFE. > > It's not a very accurate estimate, as the magic can be in the > distfile itself, i.e. properly written configure script or makefile > may know that FreeBSD need a -pthread and -D_THREAD_SAFE. Right; I only scanned for ports that had been patched to support our pthreads. I checked a couple of other ports that I know have native threads support (gnut, db3, mysql) and only db3 adds -D_THREAD_SAFE. The pthread(3) manpage doesn't mention -D_THREAD_SAFE at all. Would it be a good idea to edit the specs file in -STABLE to add that define when the user compiles with -pthread? -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 11: 9:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from blizzard.sabbo.net (ns.sabbo.net [193.193.218.18]) by hub.freebsd.org (Postfix) with ESMTP id 7642637B400; Wed, 24 Jan 2001 11:09:08 -0800 (PST) Received: from vic.sabbo.net (root@vic.sabbo.net [193.193.218.112]) by blizzard.sabbo.net (8.10.1/8.10.1) with ESMTP id f0OJ8PT03460; Wed, 24 Jan 2001 21:08:29 +0200 Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vic.sabbo.net (8.11.1/8.9.3) with ESMTP id f0OJ8S603299; Wed, 24 Jan 2001 21:08:28 +0200 (EET) (envelope-from sobomax@FreeBSD.org) Message-ID: <3A6F281A.858B78AC@FreeBSD.org> Date: Wed, 24 Jan 2001 21:08:10 +0200 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Dan Nelson Cc: Daniel Eischen , Alfred Perlstein , current@FreeBSD.org, ports@FreeBSD.org Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps References: <20010124084058.S26076@fw.wintelcom.net> <20010124123147.A2215@dan.emsphone.com> <3A6F20EE.15B78584@FreeBSD.org> <20010124130233.B2215@dan.emsphone.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Nelson wrote: > In the last episode (Jan 24), Maxim Sobolev said: > > Dan Nelson wrote: > > > I thought the old way was just -pthread, and it would handle > > > everything. I did a quick scan of the devel/ and net/ branches of our > > > ports tree, and of 43 thread-using ports, 36 of the ports simply add > > > -pthread. Only 7 also add -D_THREAD_SAFE. > > > > It's not a very accurate estimate, as the magic can be in the > > distfile itself, i.e. properly written configure script or makefile > > may know that FreeBSD need a -pthread and -D_THREAD_SAFE. > > Right; I only scanned for ports that had been patched to support our > pthreads. I checked a couple of other ports that I know have native > threads support (gnut, db3, mysql) and only db3 adds -D_THREAD_SAFE. > > The pthread(3) manpage doesn't mention -D_THREAD_SAFE at all. Would it > be a good idea to edit the specs file in -STABLE to add that define > when the user compiles with -pthread? No, I think it would violate POLA. AFAIK, the most that you can to do is to mention it somehow in pthread manpage. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 12:21:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 8684737B698 for ; Wed, 24 Jan 2001 12:21:06 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0OKL6l33285 for ; Wed, 24 Jan 2001 21:21:06 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: cy.c doesn't compile in LINT From: Poul-Henning Kamp Date: Wed, 24 Jan 2001 21:21:06 +0100 Message-ID: <33283.980367666@critter> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -include opt_global.h -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue ../../i386/isa/cy.c ../../i386/isa/cy.c: In function `cy_units': ../../i386/isa/cy.c:447: warning: `firmware_version' might be used uninitialized in this function ../../i386/isa/cy.c: In function `cyopen': ../../i386/isa/cy.c:783: warning: implicit declaration of function `mtx_enter' ../../i386/isa/cy.c:783: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c:783: (Each undeclared identifier is reported only once ../../i386/isa/cy.c:783: for each function it appears in.) ../../i386/isa/cy.c:789: warning: implicit declaration of function `mtx_exit' ../../i386/isa/cy.c: In function `cyhardclose': ../../i386/isa/cy.c:889: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cyinput': ../../i386/isa/cy.c:1035: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cyintr': ../../i386/isa/cy.c:1117: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cypoll': ../../i386/isa/cy.c:1783: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cyparam': ../../i386/isa/cy.c:2029: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cysetwater': ../../i386/isa/cy.c:2284: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cystart': ../../i386/isa/cy.c:2332: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cystop': ../../i386/isa/cy.c:2477: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cymctl': ../../i386/isa/cy.c:2557: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cywakeup': ../../i386/isa/cy.c:2669: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cd_etc': ../../i386/isa/cy.c:2840: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cd_getreg': ../../i386/isa/cy.c:2884: `MTX_SPIN' undeclared (first use in this function) ../../i386/isa/cy.c: In function `cd_setreg': ../../i386/isa/cy.c:2913: `MTX_SPIN' undeclared (first use in this function) *** Error code 1 Stop in /syv/src/sys/compile/LINT. syv# -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 12:36:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 3FFF137B400 for ; Wed, 24 Jan 2001 12:36:21 -0800 (PST) Received: from portonovo-07.budapest.interware.hu ([195.70.60.71] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LWeQ-0002k9-00; Wed, 24 Jan 2001 21:36:19 +0100 Message-ID: <3A6F3CBF.5329127@elischer.org> Date: Wed, 24 Jan 2001 12:36:15 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Rogier R. Mulhuijzen" Cc: freebsd-current@freebsd.org Subject: Re: status of bridge code References: <4.3.2.7.0.20010124185058.00ac5100@mail.drwilco.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Rogier R. Mulhuijzen" wrote: > > Is anyone working on the bridge code? > > I've got a couple of things I'd like to fix in it, but I wouldn't want to > be doing anything someone else already did. > > My wishlist: > 1) Better interaction with various drivers (like if_tap). For some reason I > need to do a wack (undocumented) sysctl to make the bridge code refresh the > iface list > 2) Spontanious kablooies. After being in operation for a while it refuses > to send anything through and doesn't spew any messages.... > 3) Improve documentation. > 3) iface clustering/routing > 4) spanning tree implementation personally I use the netgraph bridging code and I think (though I'm biased) that you should look at using htat rather than the hardwired bridging code that it was derived from. > > There's talk of a userland daemon for the last item. Is there such a thing, > and if so, where. > > If there's no such daemon (not even halfway done), what would be the best > way for a daemon like that to interact with the kernel source? A device or > sysctl's? via netgraph. > item on my list. Being an allround good networking OS this is unacceptable > IMHO. Have a look at what you can do with netgraph first. Most people don't know what it is but it allows almost arbitrarily complicated network topologies to be set up from the command line. > > DocWilco > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 12:49:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 8200737B401 for ; Wed, 24 Jan 2001 12:49:17 -0800 (PST) Received: (qmail 75183 invoked by uid 1142); 24 Jan 2001 20:49:17 -0000 Date: 24 Jan 2001 12:49:16 -0800 Date: Wed, 24 Jan 2001 12:49:04 -0800 From: Jason Evans To: Poul-Henning Kamp Cc: current@freebsd.org Subject: Re: cy.c doesn't compile in LINT Message-ID: <20010124124904.A87569@canonware.com> References: <33283.980367666@critter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <33283.980367666@critter>; from phk@freebsd.org on Wed, Jan 24, 2001 at 09:21:06PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 09:21:06PM +0100, Poul-Henning Kamp wrote: > > cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -DGPROF -DGPROF4 -DGUPROF -D_KERNEL -include opt_global.h -elf -malign-functions=4 -fno-builtin -mpreferred-stack-boundary=2 -pg -mprofiler-epilogue ../../i386/isa/cy.c > ../../i386/isa/cy.c: In function `cy_units': > ../../i386/isa/cy.c:447: warning: `firmware_version' might be used uninitialized in this function > ../../i386/isa/cy.c: In function `cyopen': > ../../i386/isa/cy.c:783: warning: implicit declaration of function `mtx_enter' > ../../i386/isa/cy.c:783: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c:783: (Each undeclared identifier is reported only once > ../../i386/isa/cy.c:783: for each function it appears in.) > ../../i386/isa/cy.c:789: warning: implicit declaration of function `mtx_exit' > ../../i386/isa/cy.c: In function `cyhardclose': > ../../i386/isa/cy.c:889: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cyinput': > ../../i386/isa/cy.c:1035: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cyintr': > ../../i386/isa/cy.c:1117: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cypoll': > ../../i386/isa/cy.c:1783: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cyparam': > ../../i386/isa/cy.c:2029: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cysetwater': > ../../i386/isa/cy.c:2284: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cystart': > ../../i386/isa/cy.c:2332: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cystop': > ../../i386/isa/cy.c:2477: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cymctl': > ../../i386/isa/cy.c:2557: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cywakeup': > ../../i386/isa/cy.c:2669: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cd_etc': > ../../i386/isa/cy.c:2840: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cd_getreg': > ../../i386/isa/cy.c:2884: `MTX_SPIN' undeclared (first use in this function) > ../../i386/isa/cy.c: In function `cd_setreg': > ../../i386/isa/cy.c:2913: `MTX_SPIN' undeclared (first use in this function) > *** Error code 1 > > Stop in /syv/src/sys/compile/LINT. > syv# This looks to be due to the simplelock changes. I'm a bit confused as to why LINT compiled fine for me... I'll take a look at it as soon as I get a chance. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 12:50: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from veldy.net (w028.z064001117.msp-mn.dsl.cnc.net [64.1.117.28]) by hub.freebsd.org (Postfix) with ESMTP id 9FCBE37B698 for ; Wed, 24 Jan 2001 12:49:46 -0800 (PST) Received: from HP2500B (veldy.net [64.1.117.28]) by veldy.net (Postfix) with SMTP id 2A82A8C2C; Wed, 24 Jan 2001 14:49:15 -0600 (CST) Message-ID: <036c01c08646$d287c600$3028680a@tgt.com> From: "Thomas T. Veldhouse" To: "Julian Elischer" , "Rogier R. Mulhuijzen" Cc: References: <4.3.2.7.0.20010124185058.00ac5100@mail.drwilco.net> <3A6F3CBF.5329127@elischer.org> Subject: Re: status of bridge code Date: Wed, 24 Jan 2001 14:47:06 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Have a look at what you can do with netgraph first. > > Most people don't know what it is but it allows almost arbitrarily > complicated network topologies to be set up from the command line. > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? I am currently using the standard bridging code and IPFIREWALL (ipfw) with my dc cards. No problems so far - as long as I don't use DUMMYNET with it. I really wish I could use DUMMYNET as I need to put bandwidth limits on a few of the computers on my network. Tom Veldhouse veldy@veldy.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 13: 5:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id B3DD737B404; Wed, 24 Jan 2001 13:05:30 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f0OL58961216; Wed, 24 Jan 2001 14:05:08 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200101242105.f0OL58961216@harmony.village.org> To: Alfred Perlstein Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps Cc: Dan Nelson , Daniel Eischen , current@FreeBSD.ORG, ports@FreeBSD.ORG In-reply-to: Your message of "Wed, 24 Jan 2001 10:35:06 PST." <20010124103505.C26076@fw.wintelcom.net> References: <20010124103505.C26076@fw.wintelcom.net> <20010124084058.S26076@fw.wintelcom.net> <20010124123147.A2215@dan.emsphone.com> Date: Wed, 24 Jan 2001 14:05:08 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010124103505.C26076@fw.wintelcom.net> Alfred Perlstein writes: : -D_THREAD_SAFE used to (or still does) make various foo_r function : prototypes available. Currently it does not do this. The foo_r prototypes are always available. Well, when we aren't compiling _ANSI_SOURCE or _POSIX_SOURCE. Dan was right that the only places that _THREAD_SAFE was used was in stdio.h for the unlocked versions of stdio routines. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 14: 4:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id CDF7737B400 for ; Wed, 24 Jan 2001 14:03:52 -0800 (PST) Received: from portonovo-07.budapest.interware.hu ([195.70.60.71] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LY12-000434-00; Wed, 24 Jan 2001 23:03:45 +0100 Message-ID: <3A6F513C.376C173E@elischer.org> Date: Wed, 24 Jan 2001 14:03:40 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Thomas T. Veldhouse" Cc: "Rogier R. Mulhuijzen" , freebsd-current@freebsd.org, vitaly@riss-telecom.ru Subject: Re: status of bridge code References: <4.3.2.7.0.20010124185058.00ac5100@mail.drwilco.net> <3A6F3CBF.5329127@elischer.org> <036c01c08646$d287c600$3028680a@tgt.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Thomas T. Veldhouse" wrote: > > > Have a look at what you can do with netgraph first. > > > > Most people don't know what it is but it allows almost arbitrarily > > complicated network topologies to be set up from the command line. > > > > > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? > I am currently using the standard bridging code and IPFIREWALL (ipfw) with > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > few of the computers on my network. /usr/share/examples/netgraph man 4 netgraph man 4 ng_bridge (etc.) also a daemon-news article on how it works. Rate limitting is one thing that isn't there yet. If we pulled our fingers out, I guess we would have ripped the dummynet rate limmiter out of where it is and placed it into a netgraph node where it would be generally useful instead of being hardcoded into one (sometimes useful) localtion in the netoworking stacks. there is a rate limitter based on netgraph available from: http://www.riss-telecom.ru/~vitaly/ but I have not tried it. I need to look at it again as I believe it has improved and may be generally useful. When I looked at it last it was a bit alpha. It probably needs rewriting for the new netgraph API in -current. > > Tom Veldhouse > veldy@veldy.net -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 14:39:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 19D1F37B400; Wed, 24 Jan 2001 14:39:38 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id A280C75C; Wed, 24 Jan 2001 14:39:36 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id OAA22513; Wed, 24 Jan 2001 14:39:28 -0800 (PST) Message-ID: <3A6F59A0.6293710B@cup.hp.com> Date: Wed, 24 Jan 2001 14:39:28 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: The Hermit Hacker , freebsd-current@FreeBSD.ORG, Peter Wemm Subject: Re: lastest kernel from cvs ( sh exists with signal 8 ) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > What happened is that binutils was upgraded from 2.9 to 2.10 in both -current > and -stable, and the old and new binutils weren't compatible. So, you had to > installworld before building your kernel (which is what I did, and always do in > fact). However, this made some people uncomfortable, so a 'buildkernel' target > was made to work around this one problem. No. The buildkernel target was created to support a source upgrade path and cross-building. It's been there since 4.0-RELEASE. The use of buildkernel has been advocated as the supported way of building a kernels, because it handles the difficult upgrade cases (such as the binutils upgrade) and thus works best for the uninitiated. The buildkernel target was, however, not designed for use as the preferred way to build any and all kernels, and it's this discrepancy that's making people unhappy in all sorts of ways and is the result of all kinds of misperceptions and bogus conclusions. -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 15: 7:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.eastlink.ca (syd.eastlink.ca [24.222.47.133]) by hub.freebsd.org (Postfix) with ESMTP id 88DE137B401; Wed, 24 Jan 2001 15:07:13 -0800 (PST) Received: from u56n134.syd.eastlink.ca (dest@u56n134.syd.eastlink.ca [24.222.56.134]) by mail.eastlink.ca (8.9.3/8.9.3) with ESMTP id TAA05610; Wed, 24 Jan 2001 19:06:24 -0400 Date: Wed, 24 Jan 2001 19:07:20 -0400 (AST) From: Craig Hawco X-X-Sender: To: Daniel Eischen Cc: Jordan Hubbard , Alfred Perlstein , , Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Daniel Eischen wrote: > > Using -pthread will prevent linking to libc and only link to > libc_r. After the change I just committed, you need to link > to both libc_r and libc (in that order), just like you would > for a threaded application on just about any other OS (only > ours is called libc_r instead of libpthread). Why not just call it libpthread for the sake of consistancy with other OSes? I understand why it was called libc_r, but it no longer contains the libc functionality. I know we like being nonconformist, but sometimes consistancy is a Good Thing. --Craig To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 15:16:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from isris.pair.com (isris.pair.com [209.68.2.39]) by hub.freebsd.org (Postfix) with SMTP id A05C437B404 for ; Wed, 24 Jan 2001 15:16:35 -0800 (PST) Received: (qmail 27211 invoked by uid 3130); 24 Jan 2001 23:16:30 -0000 Date: Wed, 24 Jan 2001 18:16:30 -0500 From: Garrett Rooney To: Craig Hawco Cc: Daniel Eischen , Jordan Hubbard , Alfred Perlstein , current@FreeBSD.ORG, ports@FreeBSD.ORG Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps Message-ID: <20010124181630.C97550@electricjellyfish.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dest@syd.eastlink.ca on Wed, Jan 24, 2001 at 07:07:20PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jan 24, 2001 at 07:07:20PM -0400, Craig Hawco wrote: > > > On Wed, 24 Jan 2001, Daniel Eischen wrote: > > > > > Using -pthread will prevent linking to libc and only link to > > libc_r. After the change I just committed, you need to link > > to both libc_r and libc (in that order), just like you would > > for a threaded application on just about any other OS (only > > ours is called libc_r instead of libpthread). > > Why not just call it libpthread for the sake of consistancy with other > OSes? I understand why it was called libc_r, but it no longer contains the > libc functionality. I know we like being nonconformist, but sometimes > consistancy is a Good Thing. Because libpthread will be written as part of the KSE project, and this way we have two different names for the different libraries, as opposed to "the new libpthread" and "the old libpthread". -- garrett rooney my pid is inigo montoya. rooneg@electricjellyfish.net you kill -9 my parent process. http://electricjellyfish.net/ prepare to vi. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 15:22:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.eastlink.ca (syd.eastlink.ca [24.222.47.133]) by hub.freebsd.org (Postfix) with ESMTP id E882437B400; Wed, 24 Jan 2001 15:22:26 -0800 (PST) Received: from u56n134.syd.eastlink.ca (dest@u56n134.syd.eastlink.ca [24.222.56.134]) by mail.eastlink.ca (8.9.3/8.9.3) with ESMTP id TAA06590; Wed, 24 Jan 2001 19:20:53 -0400 Date: Wed, 24 Jan 2001 19:21:44 -0400 (AST) From: Craig Hawco X-X-Sender: To: Garrett Rooney Cc: Daniel Eischen , Jordan Hubbard , Alfred Perlstein , , Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps In-Reply-To: <20010124181630.C97550@electricjellyfish.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Garrett Rooney wrote: > On Wed, Jan 24, 2001 at 07:07:20PM -0400, Craig Hawco wrote: > > > > > > On Wed, 24 Jan 2001, Daniel Eischen wrote: > > > > > > > > Using -pthread will prevent linking to libc and only link to > > > libc_r. After the change I just committed, you need to link > > > to both libc_r and libc (in that order), just like you would > > > for a threaded application on just about any other OS (only > > > ours is called libc_r instead of libpthread). > > > > Why not just call it libpthread for the sake of consistancy with other > > OSes? I understand why it was called libc_r, but it no longer contains the > > libc functionality. I know we like being nonconformist, but sometimes > > consistancy is a Good Thing. > > Because libpthread will be written as part of the KSE project, and this > way we have two different names for the different libraries, as opposed > to "the new libpthread" and "the old libpthread". I see, very well then. =) Happy coding. --Craig > > -- > garrett rooney my pid is inigo montoya. > rooneg@electricjellyfish.net you kill -9 my parent process. > http://electricjellyfish.net/ prepare to vi. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ports" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 16:18:46 2001 Delivered-To: freebsd-current@freebsd.org Received: from hera.drwilco.net (10dyn236.dh.casema.net [212.64.31.236]) by hub.freebsd.org (Postfix) with ESMTP id 47A3437B400 for ; Wed, 24 Jan 2001 16:18:24 -0800 (PST) Received: from ceres.drwilco.net (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0P0eBG00775 for ; Thu, 25 Jan 2001 01:40:24 +0100 (CET) (envelope-from drwilco@drwilco.net) Message-Id: <4.3.2.7.0.20010125011302.00beb520@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 01:19:45 +0100 To: freebsd-current@freebsd.org From: "Rogier R. Mulhuijzen" Subject: panic in netgraph (caught by WITNESS) in custom UP kernel Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_492334963==_" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --=====================_492334963==_ Content-Type: text/plain; charset="us-ascii"; format=flowed FYI: Full source CVSupped on the 18th or 19th Panic came about when I did a 'ls' in ngctl(8). Kernel config attached, gdb of core follows below: This GDB was configured as "i386-unknown-freebsd"... IdlePTD 5300224 initial pcb at 31c4e0 panicstr: from debugger panic messages: --- panic: mutex_enter: MTX_SPIN on MTX_DEF mutex netgraph node mutex @ ../../netgraph/ng_base.c:2205 panic: from debugger Uptime: 1d4h5m24s dumping to dev ad0s2b, offset 262144 dump ata0: resetting devices .. done 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 dumpsys () at ../../kern/kern_shutdown.c:477 477 if (dumping++) { (kgdb) trace trace command requires an argument (kgdb) where #0 dumpsys () at ../../kern/kern_shutdown.c:477 #1 0xc0187342 in boot (howto=260) at ../../kern/kern_shutdown.c:320 #2 0xc0187711 in panic (fmt=0xc02a1794 "from debugger") at ../../kern/kern_shutdown.c:570 #3 0xc0142b51 in db_panic (addr=-1071151608, have_addr=0, count=-1, modif=0xc7f70bac "") at ../../ddb/db_command.c:433 #4 0xc0142af1 in db_command (last_cmdp=0xc02e20f4, cmd_table=0xc02e1f54, aux_cmd_tablep=0xc0305e7c) at ../../ddb/db_command.c:333 #5 0xc0142bb6 in db_command_loop () at ../../ddb/db_command.c:455 #6 0xc0144d83 in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71 #7 0xc027839a in kdb_trap (type=3, code=0, regs=0xc7f70cb0) at ../../i386/i386/db_interface.c:164 #8 0xc028376c in trap (frame={tf_fs = -1070530536, tf_es = 16, tf_ds = -940113904, tf_edi = -1056367804, tf_esi = 256, tf_ebp = -940110596, tf_isp = -940110628, tf_ebx = 2, tf_edx = -1072984320, tf_ecx = 32, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1071151608, tf_cs = 8, tf_eflags = 70, tf_esp = -1070788385, tf_ss = -1070936125}) at ../../i386/i386/trap.c:596 #9 0xc0278608 in Debugger (msg=0xc02acfc3 "panic") at machine/cpufunc.h:60 #10 0xc0187708 in panic ( fmt=0xc02ac060 "mutex_enter: MTX_SPIN on MTX_DEF mutex %s @ %s:%d") at ../../kern/kern_shutdown.c:568 #11 0xc01813aa in witness_enter (m=0xc1091b48, flags=1, file=0xc02b5c91 "../../netgraph/ng_base.c", line=2205) ---Type to continue, or q to quit--- at ../../kern/kern_mutex.c:842 #12 0xc01e25e6 in ng_snd_item (item=0xc132e740, queue=1) at ../../sys/mutex.h:528 #13 0xc01e4640 in ng_generic_msg (here=0xc1091b00, item=0xc132e740, lasthook=0x0) at ../../netgraph/ng_base.c:2855 #14 0xc01e2f14 in ng_apply_item (node=0xc1091b00, item=0xc132e740) at ../../netgraph/ng_base.c:2386 #15 0xc01e2ab0 in ng_snd_item (item=0xc132e740, queue=0) at ../../netgraph/ng_base.c:2249 #16 0xc139890f in ?? () #17 0xc01ae707 in sosend (so=0xc81e2c00, addr=0xc0f5fb30, uio=0xc7f70edc, top=0xc0b3fa00, control=0x0, flags=0, p=0xc8d83ca0) at ../../kern/uipc_socket.c:620 #18 0xc01b3668 in sendit (p=0xc8d83ca0, s=3, mp=0xc7f70f1c, flags=0) at ../../kern/uipc_syscalls.c:577 #19 0xc01b371e in sendto (p=0xc8d83ca0, uap=0xc7f70f80) at ../../kern/uipc_syscalls.c:630 #20 0xc0284551 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077967404, tf_esi = -1077967406, tf_ebp = -1077966892, tf_isp = -940109868, tf_ebx = 671528168, tf_edx = -1077967408, tf_ecx = -1077967408, tf_eax = 133, tf_trapno = 12, tf_err = 2, tf_eip = 671772124, tf_cs = 31, tf_eflags = 518, tf_esp = -1077967496, tf_ss = 47}) at ../../i386/i386/trap.c:1153 #21 0xc0278d03 in Xint0x80_syscall () ---Type to continue, or q to quit--- #22 0x28069995 in ?? () #23 0x8049dc7 in ?? () #24 0x8049119 in ?? () #25 0x80490ca in ?? () #26 0x804904b in ?? () #27 0x8048d1f in ?? () #28 0x8048acd in ?? () (kgdb) --=====================_492334963==_ Content-Type: application/octet-stream; name="VENUS" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VENUS" bWFjaGluZQkJaTM4NgppZGVudAkJVkVOVVMKbWF4dXNlcnMJMzIKI21ha2VvcHRpb25zCUNPTkZf Q0ZMQUdTPSItZm5vLWJ1aWx0aW4gLW1jcHU9cGVudGl1bXBybyAtbWFyY2g9cGVudGl1bXBybyIK bWFrZW9wdGlvbnMJQ09ORl9DRkxBR1M9Ii1PIC1waXBlIgpvcHRpb25zIAlCTEtERVZfSU9TSVpF PTgxOTIKb3B0aW9ucyAJUFFfTk9PUFQKb3B0aW9ucyAJSU5DTFVERV9DT05GSUdfRklMRSAgICAg CmNwdQkJSTY4Nl9DUFUJCQpvcHRpb25zIAlOT19GMDBGX0hBQ0sJCQpvcHRpb25zIAlDT01QQVRf NDMKb3B0aW9ucyAJVVNFUl9MRFQJCQpvcHRpb25zIAlTWVNWU0hNCm9wdGlvbnMgCVNZU1ZTRU0K b3B0aW9ucyAJU1lTVk1TRwpvcHRpb25zIAlVQ09OU09MRQpvcHRpb25zIAlVU0VSQ09ORklHCQkK b3B0aW9ucyAJVklTVUFMX1VTRVJDT05GSUcJCm9wdGlvbnMgCUlORVQJCQkKb3B0aW9ucyAJSU5F VDYJCQkKb3B0aW9ucyAJSVBTRUMJCQkKb3B0aW9ucyAJSVBTRUNfRVNQCQkKb3B0aW9ucwkJTkVU R1JBUEgKZGV2aWNlCQlldGhlcgkJCQpkZXZpY2UJCXZsYW4JCQkKZGV2aWNlCQlsb29wCTEJCQpk ZXZpY2UJCWJwZgkJCQojZGV2aWNlCQl0YXAJCQkKI2RldmljZQkJdHVuCQkJCmRldmljZQkJZ2lm CQkJCmRldmljZQkJZmFpdGgJCQkKZGV2aWNlCQlzdGYJCQkKb3B0aW9ucyAJSVBGSVJFV0FMTAkJ Cm9wdGlvbnMgCUlQRklSRVdBTExfVkVSQk9TRQkKb3B0aW9ucyAJSVBGSVJFV0FMTF9GT1JXQVJE CQpvcHRpb25zIAlJUFY2RklSRVdBTEwJCQpvcHRpb25zIAlJUFY2RklSRVdBTExfVkVSQk9TRQpv cHRpb25zIAlJUERJVkVSVAkJCm9wdGlvbnMgCUlQU1RFQUxUSAkJCm9wdGlvbnMgCVRDUF9EUk9Q X1NZTkZJTgkJCm9wdGlvbnMgCVRDUF9SRVNUUklDVF9SU1QJCm9wdGlvbnMgCURVTU1ZTkVUCm9w dGlvbnMgCUJSSURHRQpvcHRpb25zIAlGRlMJCQkKb3B0aW9ucyAJTlRGUwpvcHRpb25zCQlERVZG UwpvcHRpb25zIAlGRlNfUk9PVAkJCm9wdGlvbnMJRkZTX0VYVEFUVFIKb3B0aW9ucyAJRU5BQkxF X1ZGU19JT09QVApkZXZpY2UJCXJhbmRvbQpvcHRpb25zIAlQMTAwM18xQgpvcHRpb25zIAlfS1BP U0lYX1BSSU9SSVRZX1NDSEVEVUxJTkcKb3B0aW9ucyAJX0tQT1NJWF9WRVJTSU9OPTE5OTMwOUwK b3B0aW9ucyAJSFo9MTAwCmRldmljZQkJcHR5CQkKI2RldmljZQkJdm4JCQpvcHRpb25zIAlNU0dC VUZfU0laRT00MDk2MApkZXZpY2UJCWlzYQojb3B0aW9ucyAJQ09NUEFUX09MRElTQQkKb3B0aW9u cyAJQVVUT19FT0lfMQpvcHRpb25zIAlNQVhNRU09IigxMjgqMTAyNCkiCiNvcHRpb25zIAlOVElN RUNPVU5URVI9MjAKZGV2aWNlCQlwY2kKI29wdGlvbnMgCUNPTVBBVF9PTERQQ0kJCmRldmljZQkJ YXRrYmRjCTEKZGV2aWNlCQlhdGtiZApkZXZpY2UJCXBzbQpvcHRpb25zIAlQU01fSE9PS1JFU1VN RQkJCm9wdGlvbnMgCVBTTV9SRVNFVEFGVEVSU1VTUEVORAkKZGV2aWNlCQl2Z2EKb3B0aW9ucyAJ VkdBX0FMVF9TRVFBQ0NFU1MKb3B0aW9ucyAJVkdBX1NMT1dfSU9BQ0NFU1MJCmRldmljZQkJc3Bs YXNoCmRldmljZQkJc2MJMQpvcHRpb25zIAlNQVhDT05TPTEyCQkKZGV2aWNlCQlucHgKZGV2aWNl CQlhdGEKZGV2aWNlCQlhdGFkaXNrCQkKZGV2aWNlCQlhdGFwaWNkCQkKb3B0aW9ucwkJU09GVFVQ REFURVMKb3B0aW9ucyAJQVRBX1NUQVRJQ19JRApvcHRpb25zIAlBVEFfRU5BQkxFX0FUQVBJX0RN QQpvcHRpb25zIAlBVEFfRU5BQkxFX1RBR1MKZGV2aWNlCQlmZGMKZGV2aWNlCQlzaW8KZGV2aWNl CQl4ZQojZGV2aWNlCQlwY20KZGV2aWNlCQltaWRpCiNkZXZpY2UJCXNlcQojZGV2aWNlCQlzYmMK ZGV2aWNlCQlhcG0KZGV2aWNlCQlwbXRpbWVyCQkJCiNib3RoIE5FV0NBUkQgYW5kIE9MRENBUkQK ZGV2aWNlCQlwY2ljCiNqdXN0IE9MRENBUkQKZGV2aWNlCQljYXJkCiNqdXN0IE5FV0NBUkQKI2Rl dmljZQkJcGNjYXJkCiNkZXZpY2UJCWNhcmRidXMKI2RldmljZQkJcGNjYmIKI3Jlc3VtZSBub3Jt YWwgc2NodHVmZgpvcHRpb25zIAlQQ0lDX1JFU1VNRV9SRVNFVAkKb3B0aW9ucyAJUE9XRVJGQUlM X05NSQkKI2RldmljZQkJc21idXMJCQojZGV2aWNlCQlpbnRwbQojZGV2aWNlCQlpY2hzbWIKI2Rl dmljZQkJc21iCiNkZXZpY2UJCWlpY2J1cwkJCiNkZXZpY2UJCWlpY2JiCiNkZXZpY2UJCWljCiNk ZXZpY2UJCWlpYwojZGV2aWNlCQlpaWNzbWIJCQojZGV2aWNlCQlwY2YKb3B0aW9ucwkJUFBDX1BS T0JFX0NISVBTRVQgCm9wdGlvbnMgCURPTlRQUk9CRV8xMjg0CQpkZXZpY2UJCXBwYwpkZXZpY2UJ CXBwYnVzCmRldmljZQkJbHB0CiNkZXZpY2UJCXVoY2kKI2RldmljZQkJdXNiCiNkZXZpY2UJCXVk YnAKI2RldmljZQkJdWdlbgojZGV2aWNlCQl1aGlkCiNkZXZpY2UJCXVrYmQKI2RldmljZQkJdWxw dAojZGV2aWNlCQl1bWFzcwojZGV2aWNlCQl1bW9kZW0KI2RldmljZQkJdW1zCiNkZXZpY2UJCXVy aW8KI2RldmljZQkJYXVlCiNkZXZpY2UJCWN1ZQojZGV2aWNlCQlrdWUKZGV2aWNlICAgICAgICAg IGFjcGljYQojb3B0aW9ucyAgICAgICAgIEFDUElfREVCVUcKb3B0aW9ucwkJRElBR05PU1RJQwpv cHRpb25zICAgICAgICAgTVVURVhfREVCVUcKb3B0aW9ucyAgICAgICAgIFdJVE5FU1MKb3B0aW9u cyAgICAgICAgIFdJVE5FU1NfRERCCiNvcHRpb25zICAgICAgICAgV0lUTkVTU19TS0lQU1BJTgpv cHRpb25zICAgICAgICAgRERCICAgCgo= --=====================_492334963==_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 20: 3:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from c1030098-a.wtrlo1.ia.home.com (c1030098-a.wtrlo1.ia.home.com [24.11.39.39]) by hub.freebsd.org (Postfix) with ESMTP id 725AE37B402 for ; Wed, 24 Jan 2001 20:03:23 -0800 (PST) Received: by c1030098-a.wtrlo1.ia.home.com (Postfix, from userid 1001) id 286F314A63; Wed, 24 Jan 2001 22:03:23 -0600 (CST) To: freebsd-current@FreeBSD.ORG Subject: world dies in perl Keywords: usr,perl,libperl,undefined,reference,src,obj,gnu,bin,lib,i386,libc From: Michael Harnois Date: 24 Jan 2001 22:03:22 -0600 In-Reply-To: <200101241722.LAA00274@freebsd.netcom.com> (Mark Hittinger's message of "Wed, 24 Jan 2001 11:22:14 -0600 (CST)") Message-ID: <863de8gtx1.fsf@mharnois.workgroup.net> Lines: 323 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Poseidon) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ===> gnu/usr.bin/perl/perl cc -O -pipe -march=i686 -I/usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5 -I/usr/obj/usr/src/gnu/usr.bin/perl/perl -DPERL_CORE -pthread -I/usr/obj/usr/src/i386/usr/include -Wl,-E -L/usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl -o perl perlmain.o lib/auto/DynaLoader/DynaLoader.a -lperl -lm -lcrypt -lmd lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `dl_generic_private_init': DynaLoader.o(.text+0x184): undefined reference to `getenv' DynaLoader.o(.text+0x19e): undefined reference to `atoi' lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `SaveError': DynaLoader.o(.text+0x280): undefined reference to `strncpy' lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `XS_DynaLoader_dl_load_file': DynaLoader.o(.text+0x4e8): undefined reference to `dlopen' DynaLoader.o(.text+0x526): undefined reference to `dlerror' lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `XS_DynaLoader_dl_unload_file': DynaLoader.o(.text+0x6de): undefined reference to `dlclose' DynaLoader.o(.text+0x6fc): undefined reference to `dlerror' lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `XS_DynaLoader_dl_find_symbol': DynaLoader.o(.text+0x996): undefined reference to `dlsym' DynaLoader.o(.text+0x9d4): undefined reference to `dlerror' lib/auto/DynaLoader/DynaLoader.a(DynaLoader.o): In function `boot_DynaLoader': DynaLoader.o(.text+0x1180): undefined reference to `strcmp' /usr/obj/usr/src/i386/usr/lib/crt1.o: In function `_start': /usr/obj/usr/src/i386/usr/lib/crt1.o(.text+0x56): undefined reference to `atexit' /usr/obj/usr/src/i386/usr/lib/crt1.o(.text+0x66): undefined reference to `atexit' /usr/obj/usr/src/i386/usr/lib/crt1.o(.text+0x7f): undefined reference to `exit' perlmain.o: In function `main': perlmain.o(.text+0x2e): undefined reference to `exit' perlmain.o(.text+0xac): undefined reference to `exit' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `clock_gettime' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setgrent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `chroot' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `strcpy' /usr/obj/usr/src/i386/usr/lib/libm.so: undefined reference to `__sysctl' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `sigsetjmp' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__longjmp' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `tmpfile' /usr/lib/libutil.so.3: undefined reference to `getrlimit' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getservent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getgid' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_fcntl' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `printf' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `vsprintf' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `utime' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `getdtablesize' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `sethostent' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_fchmod' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setservent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getlogin' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_wait4' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `ungetc' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `sigemptyset' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__tcdrain' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `shmctl' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `strerror' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_aio_suspend' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `___toupper' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `geteuid' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__siglongjmp' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `memmove' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `endnetent' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `snprintf' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `syscall' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_sigprocmask' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `atol' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_recvmsg' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getgrgid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `times' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getprotobynumber' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `errno' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getegid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setlinebuf' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setpriority' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getpriority' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_dup2' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getprotobyname' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `semget' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getpid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `qsort' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `truncate' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_open' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `_getlogin' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getnetent' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `___longjmp' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_fchflags' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getc' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `msgrcv' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `shmat' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `memcpy' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `setitimer' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `__infinity' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `execl' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `seekdir' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_fstat' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `readlink' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getuid' /usr/lib/libutil.so.3: undefined reference to `rtprio' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `rewinddir' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `semctl' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `feof' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_socketpair' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `malloc' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `isatty' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `endpwent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setruid' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_sendmsg' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `strtoul' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_sendfile' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `gethostbyaddr' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `rmdir' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_msync' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_sigaltstack' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_read' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `readdir' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys__exit' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setgroups' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fflush' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `ftruncate' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_fork' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `lseek' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `sigaddset' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__wait' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `chown' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `mmap' /usr/lib/libutil.so.3: undefined reference to `strncasecmp' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_recvfrom' /usr/lib/libutil.so.3: undefined reference to `bzero' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setpgid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `send' /usr/lib/libutil.so.3: undefined reference to `freeaddrinfo' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `abort' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `endprotoent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `chmod' /usr/lib/libutil.so.3: undefined reference to `getnameinfo' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `alarm' /usr/lib/libutil.so.3: undefined reference to `strtoq' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `strtol' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__pause' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getnetbyaddr' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `_DefaultRuneLocale' /usr/lib/libutil.so.3: undefined reference to `cgetstr' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `rename' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `strrchr' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_socket' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `h_errno' /usr/lib/libutil.so.3: undefined reference to `setrlimit' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setrgid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setprotoent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `atof' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_getsockopt' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `sysctl' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fprintf' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `kill' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setpwent' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_sendto' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `strcat' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_flock' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getprotoent' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_writev' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `chdir' /usr/lib/libutil.so.3: undefined reference to `initgroups' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fseeko' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setregid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `shmdt' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `modf' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `endgrent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `shmget' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setproctitle' /usr/lib/libutil.so.3: undefined reference to `memchr' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `umask' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_poll' /usr/lib/libutil.so.3: undefined reference to `mktime' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_bind' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `lstat' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `ferror' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `ftello' /usr/lib/libutil.so.3: undefined reference to `setgid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `___runetype' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `strncmp' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `unlink' /usr/lib/libutil.so.3: undefined reference to `setenv' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__creat' /usr/lib/libutil.so.3: undefined reference to `strcasecmp' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `revoke' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `realloc' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_dup' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `_CurrentRuneLocale' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_sigreturn' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `sigfillset' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_connect' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fdopen' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `__sF' /usr/lib/libutil.so.3: undefined reference to `__inet_ntoa' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `execv' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getgrent' /usr/obj/usr/src/i386/usr/lib/libcrypt.so: undefined reference to `strncat' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setresuid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `msgsnd' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `srand48' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `killpg' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fread' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_pipe' /usr/obj/usr/src/i386/usr/lib/libcrypt.so: undefined reference to `strdup' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `endhostent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `symlink' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `gettimeofday' /usr/lib/libutil.so.3: undefined reference to `ttyslot' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__isthreaded' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fopen' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_write' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setreuid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `localtime' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `memset' /usr/lib/libutil.so.3: undefined reference to `fnmatch' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `strxfrm' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `clearerr' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fclose' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getppid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getservbyport' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `time' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `opendir' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getgroups' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `msgctl' /usr/obj/usr/src/i386/usr/lib/libcrypt.so: undefined reference to `syslog' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `seteuid' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_fstatfs' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getpwuid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `gethostbyname' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getpwnam' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_fpathconf' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getservbyname' /usr/lib/libutil.so.3: undefined reference to `gethostname' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_close' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `sprintf' /usr/lib/libutil.so.3: undefined reference to `strcspn' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_getpeername' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setlocale' /usr/lib/libutil.so.3: undefined reference to `getttynam' /usr/lib/libutil.so.3: undefined reference to `cgetcap' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sleep' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__waitpid' /usr/obj/usr/src/i386/usr/lib/libm.so: undefined reference to `isnan' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `sigismember' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_setsockopt' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fputc' /usr/lib/libutil.so.3: undefined reference to `fgetln' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_getdirentries' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_getsockname' /usr/lib/libutil.so.3: undefined reference to `getaddrinfo' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_readv' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setresgid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `localeconv' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `stat' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_execve' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_fchown' /usr/lib/libutil.so.3: undefined reference to `cgetclose' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fwrite' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `access' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_listen' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `drand48' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_sigaction' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `gethostent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getnetbyname' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `link' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `semop' /usr/lib/libutil.so.3: undefined reference to `cgetent' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `sigdelset' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getgrnam' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__system' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_kevent' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_fsync' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fileno' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `_setjmp' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `endservent' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_accept' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getpwent' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `gmtime' /usr/lib/libutil.so.3: undefined reference to `strspn' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_shutdown' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `strchr' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `fputs' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `execvp' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `setsid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setegid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `closedir' /usr/obj/usr/src/i386/usr/lib/libcrypt.so: undefined reference to `warn' /usr/lib/libutil.so.3: undefined reference to `cgetnum' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `setnetent' /usr/lib/libutil.so.3: undefined reference to `setuid' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `getpgid' /usr/lib/libutil.so.3: undefined reference to `tcsetattr' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `mkdir' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `msgget' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `frexp' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `setlogin' /usr/obj/usr/src/i386/usr/lib/libc_r.so: undefined reference to `__sys_ioctl' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `telldir' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `vfprintf' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `___tolower' /usr/obj/usr/src/gnu/usr.bin/perl/perl/../libperl/libperl.so: undefined reference to `free' *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois@home.com aa0bt@aa0bt.ampr.org Sed quis custodiet ipsos custodes? -- Juvenal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 21: 9:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 998BC37B402 for ; Wed, 24 Jan 2001 21:09:00 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id VAA55851; Wed, 24 Jan 2001 21:08:52 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id VAA04564; Wed, 24 Jan 2001 21:08:52 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101250508.VAA04564@curve.dellroad.org> Subject: Re: status of bridge code In-Reply-To: <3A6F513C.376C173E@elischer.org> "from Julian Elischer at Jan 24, 2001 02:03:40 pm" To: Julian Elischer Date: Wed, 24 Jan 2001 21:08:51 -0800 (PST) Cc: "Thomas T. Veldhouse" , "Rogier R. Mulhuijzen" , freebsd-current@FreeBSD.ORG, vitaly@riss-telecom.ru X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer writes: > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? > > I am currently using the standard bridging code and IPFIREWALL (ipfw) with > > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > > few of the computers on my network. > > /usr/share/examples/netgraph > man 4 netgraph > man 4 ng_bridge > (etc.) > also a daemon-news article on how it works. http://www.daemonnews.org/200003/netgraph.html -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jan 24 22:58:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.122.47]) by hub.freebsd.org (Postfix) with ESMTP id 1664B37B402 for ; Wed, 24 Jan 2001 22:57:54 -0800 (PST) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.10.1/8.10.1) with ESMTP id f0P6vaY27603; Wed, 24 Jan 2001 22:57:37 -0800 (PST) Date: Wed, 24 Jan 2001 22:57:36 -0800 (PST) From: Doug White To: Archie Cobbs Cc: Julian Elischer , "Thomas T. Veldhouse" , "Rogier R. Mulhuijzen" , freebsd-current@FreeBSD.ORG, vitaly@riss-telecom.ru Subject: Re: status of bridge code In-Reply-To: <200101250508.VAA04564@curve.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Archie Cobbs wrote: > Julian Elischer writes: > > > Is there any reasonable documentation or a HOWTO on the usage of netgraph? > > > I am currently using the standard bridging code and IPFIREWALL (ipfw) with > > > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > > > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > > > few of the computers on my network. > > > > /usr/share/examples/netgraph > > man 4 netgraph > > man 4 ng_bridge > > (etc.) > > also a daemon-news article on how it works. > > http://www.daemonnews.org/200003/netgraph.html A small addendum to the Netgraph canon: Netgraph starts with a _clean_slate_. If this is your first time, make sure you define some endpoint first, then build on that. You don't have interfaces, sockets, nothin' to start with. Like a box of Legos and an empty table. :-) Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 0:16: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from hera.drwilco.net (10dyn244.dh.casema.net [212.64.31.244]) by hub.freebsd.org (Postfix) with ESMTP id 8A73F37B402 for ; Thu, 25 Jan 2001 00:15:38 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0P8apG02424; Thu, 25 Jan 2001 09:37:06 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 00:16:16 +0100 To: Julian Elischer , Archie Cobbs From: "Rogier R. Mulhuijzen" Subject: Re: status of bridge code Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <3A6F3CBF.5329127@elischer.org> References: <4.3.2.7.0.20010124185058.00ac5100@mail.drwilco.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >personally I use the netgraph bridging code and I think (though I'm biased) >that you should look at using htat rather than the hardwired bridging >code that it was derived from. Now that I've read up on it I can tell you you and and Archie have every right to be biased =) I've had a netgraph bridge in place for a while now and it works very well. (On 4.X-STABLE, on 5.X-CURRENT it went kablooie. See panic trace) > > item on my list. Being an allround good networking OS this is unacceptable > > IMHO. > >Have a look at what you can do with netgraph first. > >Most people don't know what it is but it allows almost arbitrarily >complicated network topologies to be set up from the command line. What you might want to tell people is that it allows networking structures to be setup in a simple manner, but is so powerful it can also be used for immensely complex structures. A friend and fellow BSD user of mine's first response was "I like to keep things simple". After I rephrased into the above he was much more interested. But from my list of wishes I'd say the first 3 are gone. All that's left is spanning tree. I'm probably going to need this pretty soon, so once more I'm asking if anyone is working on it. If not I'll start on it. Also, a quick question for you netgraph guys. Why is it that ng_one2many send a packet only out of one hook? I can see use for an algorithm that sends packets from the 'one' hook to all the 'many' hooks (that are up) and keep the normal behaviour for many to one. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 4:28:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 02C3837B400 for ; Thu, 25 Jan 2001 04:28:19 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.0/8.11.0) id f0PCP4Y15787; Thu, 25 Jan 2001 14:25:04 +0200 (EET) (envelope-from ru) Date: Thu, 25 Jan 2001 14:25:04 +0200 From: Ruslan Ermilov To: Marcel Moolenaar , rene@xs4all.nl Cc: current@FreeBSD.org Subject: Re: Bootstrapping issues with groff(1) Message-ID: <20010125142504.A15489@sunbay.com> Mail-Followup-To: Marcel Moolenaar , rene@xs4all.nl, current@FreeBSD.org References: <20001216171526.A28853@sunbay.com> <20010124182729.A22713@xs4all.nl> <20001208181908.A12716@sunbay.com> <3A319751.D2C9E5AB@cup.hp.com> <20001209154347.A78374@sunbay.com> <3A329641.CC6D8447@cup.hp.com> <20001211094815.D96665@sunbay.com> <3A3509E9.F1D19305@cup.hp.com> <20001212102344.B92312@sunbay.com> <3A3663DB.2DA71F0E@cup.hp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A3663DB.2DA71F0E@cup.hp.com>; from marcel@cup.hp.com on Tue, Dec 12, 2000 at 09:43:55AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! Attached is the patch for RELENG_4. It works but I don't like how it pollutes the Makefile.inc1. Anyone with a better idea? On Tue, Dec 12, 2000 at 09:43:55AM -0800, Marcel Moolenaar wrote: > Ruslan Ermilov wrote: > > > > > Let me rephrase the question: Did you modify the manpages to get it to > > > work with the new groff(1) or is the new groff(1) backward compatible > > > with the old groff(1)? > > > > > The new groff(1) is not always backwards compatible. > > Ok, thanks. That's all I wanted to hear. > > > OK, I will augment the USRDIRS then, add the groff to bootstrap-tools, > > and leave the better (if one exists) implementation to someone else. > > Works for me. > > thanks, > > -- > Marcel Moolenaar > mail: marcel@cup.hp.com / marcel@FreeBSD.org > tel: (408) 447-4222 On Wed, Jan 24, 2001 at 06:27:29PM +0100, rene@xs4all.nl wrote: > Hi. did you get any chance to fix the problem discussed earlier yet? > > I'm currently trying to buildworld on sources gootten with CVSup, using > this supfile: > > # Defaults that apply to all the collections > *default host=cvsup.FreeBSD.org > *default base=/usr > *default prefix=/usr > *default release=cvs tag=RELENG_4 > *default delete use-rel-suffix > *default compress > > ## The international secure collections. > src-all > > buildworld fails as follows; > > ===> share/doc/usd/12.vi/summary > touch _stamp.extraobjs > (cd > /usr/src/share/doc/usd/12.vi/summary/../../../../../contrib/nvi/docs/USD.doc/vitut; > groff -mtty-char -Tascii -t -ms -o1- > /usr/src/share/doc/usd/12.vi/summary/../../../../../contrib/nvi/docs/USD.doc/vitut/vi.summary) > | gzip -cn > summary.ascii.gz > ===> share/doc/usd/13.viref > (cd > /usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref; > sed -e\ 's:\(\.so[\ \ ][\ \ > ]*\)\(vi.ref\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:' > -e\ 's:\(\.so[\ \ ][\ \ > ]*\)\(ex.cmd.roff\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:' > -e\ 's:\(\.so[\ \ ][\ \ > ]*\)\(ref.so\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:' > -e\ 's:\(\.so[\ \ ][\ \ > ]*\)\(set.opt.roff\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:' > -e\ 's:\(\.so[\ \ ][\ \ > ]*\)\(vi.cmd.roff\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:' > -e 's:^\.so index.so$::' vi.ref) | groff -mtty-char -Tascii -t -s -me -U > -o1- > /dev/null > groff: illegal option -- U > usage: groff [-abehilpstvzCENRSVXZ] [-Fdir] [-mname] [-Tdev] [-ffam] > [-wname] > [-Wname] [ -Mdir] [-dcs] [-rcn] [-nnum] [-olist] [-Parg] [-Larg] > [files...] > groff -h gives more help > *** Error code 1 > > Stop. > > Can you please help me out here? > > > On Sat, Dec 16, 2000 at 05:15:26PM +0200, Ruslan Ermilov wrote: > > On Sat, Dec 16, 2000 at 01:28:16PM +0100, rene@xs4all.nl wrote: > > > Hi. > > > > > > I'm having a hell of a time upgrading my 3.4-STABLE box to 4.2-STABLE. > > > My latest blues concern groff, for which I saw you posting a patch on > > > the freeBSD questions mailing list on the 9th of December. > > > > > > I hope this patch solved the problem, I did not see any messages on that. > > > > > > Unfortunately, you do not post instructions to apply the patch. I'm hoping > > > to get them out of you via this email ;-) > > > > > I am planning to commit the fix to 5.0-CURRENT and 4.2-STABLE shortly. > > I will send you a notice after I do this. > > > > -- > > Ruslan Ermilov Oracle Developer/DBA, > > ru@sunbay.com Sunbay Software AG, > > ru@FreeBSD.org FreeBSD committer, > > +380.652.512.251 Simferopol, Ukraine > > > > http://www.FreeBSD.org The Power To Serve > > http://www.oracle.com Enabling The Information Age -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.141.2.19 diff -u -p -r1.141.2.19 Makefile.inc1 --- Makefile.inc1 2001/01/22 23:26:15 1.141.2.19 +++ Makefile.inc1 2001/01/25 12:16:07 @@ -168,6 +168,8 @@ CROSSENV= MAKEOBJDIRPREFIX=${OBJTREE} \ COMPILER_PATH=${WORLDTMP}/usr/libexec:${WORLDTMP}/usr/bin \ LIBRARY_PATH=${WORLDTMP}${SHLIBDIR}:${WORLDTMP}/usr/lib \ OBJFORMAT_PATH=${WORLDTMP}/usr/libexec \ + GROFF_FONT_PATH=${WORLDTMP}/usr/share/groff_font \ + GROFF_TMAC_PATH=${WORLDTMP}/usr/share/tmac \ PERL5LIB=${WORLDTMP}/usr/libdata/perl/5.00503 # bootstrap-tool stage @@ -199,7 +201,24 @@ IMAKEENV= ${CROSSENV} \ IMAKE= ${IMAKEENV} ${MAKE} -f Makefile.inc1 USRDIRS= usr/bin usr/lib/compat/aout usr/games usr/libdata/ldscripts \ - usr/libexec/${OBJFORMAT} usr/sbin usr/share/misc + usr/libexec/${OBJFORMAT} usr/sbin usr/share/misc \ + usr/share/tmac/locale usr/share/tmac/mdoc/locale \ + usr/share/tmac/mm \ + usr/share/groff_font/devX100 \ + usr/share/groff_font/devX100-12 \ + usr/share/groff_font/devX75 \ + usr/share/groff_font/devX75-12 \ + usr/share/groff_font/devascii \ + usr/share/groff_font/devcp1047 \ + usr/share/groff_font/devdvi \ + usr/share/groff_font/devhtml \ + usr/share/groff_font/devkoi8-r \ + usr/share/groff_font/devlatin1 \ + usr/share/groff_font/devlbp \ + usr/share/groff_font/devlj4 \ + usr/share/groff_font/devps \ + usr/share/groff_font/devutf8 \ + usr/share/dict .if ${MACHINE_ARCH} == "i386" && ${MACHINE} == "pc98" USRDIRS+= usr/libexec/aout @@ -222,7 +241,7 @@ buildworld: .if !defined(NOCLEAN) rm -rf ${WORLDTMP} .else - for dir in bin games include lib sbin; do \ + for dir in bin games include lib sbin share; do \ rm -rf ${WORLDTMP}/usr/$$dir; \ done rm -f ${WORLDTMP}/sys @@ -512,7 +531,7 @@ _strfile= games/fortune/strfile bootstrap-tools: .for _tool in ${_strfile} usr.bin/yacc usr.bin/colldef usr.sbin/config \ - gnu/usr.bin/gperf gnu/usr.bin/texinfo + gnu/usr.bin/gperf gnu/usr.bin/groff gnu/usr.bin/texinfo cd ${.CURDIR}/${_tool}; \ ${MAKE} obj; \ ${MAKE} depend; \ --liOOAslEiF7prFVr-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 5:40:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by hub.freebsd.org (Postfix) with ESMTP id 0B27437B400 for ; Thu, 25 Jan 2001 05:40:25 -0800 (PST) Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) id 14LmdT-00022s-00; Thu, 25 Jan 2001 14:40:23 +0100 Received: from sure.surfnet.nl (sure.surfnet.nl [192.87.109.131]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.8) with ESMTP id OAA05294; Thu, 25 Jan 2001 14:40:22 +0100 (MET) Date: Thu, 25 Jan 2001 14:40:22 +0100 (CET) From: Ronald van der Pol To: Matt Dillon Cc: freebsd-current@freebsd.org, snap-users@kame.net Subject: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) In-Reply-To: <200101241851.f0OIpSk69419@earth.backplane.com> Message-ID: X-NCC-RegID: nl.surfnet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Matt Dillon wrote: > :On Sun, 21 Jan 2001, Matt Dillon wrote: > : > :> Concentrate on making the general network stack (aka TCP) and > :> filesystems SMP aware. Leave NFS alone for now. Please. > : > :If I understand correctly another item on the wishlist is TI-RPC > :(so that NFS can be made IPv6 aware). What is the latest on that? > : > : rvdp > > I don't think anyone is working on IPV6 issues at the moment. (I have cc-ed snap-users@kame.net) This came up about half a year ago in the KAME snap mailing list. I think the conclusion was: a migration from "old" RPC to TI-RPC is a pre-requisite for making NFS IPv6 aware. So, I was wondering whether a switch to TI-RPC is planned. I know it is a major task. rvdp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 6: 0:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from h2o.riss-telecom.ru (Relay1-ET0.riss-telecom.ru [195.239.105.2]) by hub.freebsd.org (Postfix) with SMTP id 0D62637B400 for ; Thu, 25 Jan 2001 06:00:05 -0800 (PST) Received: (qmail 98389 invoked by uid 1000); 25 Jan 2001 14:00:01 -0000 Date: Thu, 25 Jan 2001 20:00:00 +0600 (NOVT) From: "Vitaly V. Belekhov" To: Julian Elischer Cc: "Thomas T. Veldhouse" , "Rogier R. Mulhuijzen" , freebsd-current@freebsd.org Subject: Re: status of bridge code In-Reply-To: <3A6F513C.376C173E@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Julian Elischer wrote: ... > > my dc cards. No problems so far - as long as I don't use DUMMYNET with it. > > I really wish I could use DUMMYNET as I need to put bandwidth limits on a > > few of the computers on my network. ... > Rate limitting is one thing that isn't there yet. If we pulled our fingers out, > I guess we would have ripped the dummynet rate limmiter out of where it is > and placed it into a netgraph node where it would be generally useful > instead of being hardcoded into one (sometimes useful) localtion in the > netoworking stacks. > > there is a rate limitter based on netgraph available from: > http://www.riss-telecom.ru/~vitaly/ > > but I have not tried it. > > I need to look at it again as I believe it has improved and > may be generally useful. > When I looked at it last it was a bit alpha. > It probably needs rewriting for the new netgraph API in -current. Current state of this project: Grade: production, working on more than 40 hosts from June 2000, city-wide ISP network OS version: 3-STABLE from 8 January 2000 - this version currently used in our production routers/hosts Capabilities: guaranteed low bandwidth, maximum bandwidth, priority can be set for queue, traffic classification and bandwidth management realized by separate netgraph nodes. Since I currently have high workload, I dont have time to port it to 4.x or 5-CURRENT... Conclusion: volunteer required for this work... and I can consult him/her. -- Vitaly Belekhov System architect, AB-Telecom, Novosibirsk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 6: 4:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from dillema.net (server.pasta.cs.UiT.No [129.242.16.119]) by hub.freebsd.org (Postfix) with ESMTP id DDAFA37B400 for ; Thu, 25 Jan 2001 06:04:39 -0800 (PST) Received: (from dillema@localhost) by dillema.net (8.11.2/8.8.8) id f0PE4Fr13065; Thu, 25 Jan 2001 15:04:15 +0100 (CET) Date: Thu, 25 Jan 2001 15:04:14 +0100 From: Feico Dillema To: snap-users@kame.net Cc: Matt Dillon , freebsd-current@freebsd.org Subject: Re: (KAME-snap 3972) TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) Message-ID: <20010125150414.B13004@pasta.cs.uit.no> Mail-Followup-To: snap-users@kame.net, Matt Dillon , freebsd-current@freebsd.org References: <200101241851.f0OIpSk69419@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Ronald.vanderPol@surfnet.nl on Thu, Jan 25, 2001 at 02:40:22PM +0100 X-Operating-System: NetBSD drifter.dillema.net 1.5Q NetBSD 1.5Q (DRIFTER-CB) X-URL: http://www.dillema.net/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 25, 2001 at 02:40:22PM +0100, Ronald van der Pol wrote: > On Wed, 24 Jan 2001, Matt Dillon wrote: > > (I have cc-ed snap-users@kame.net) > > This came up about half a year ago in the KAME snap mailing list. > I think the conclusion was: a migration from "old" RPC to TI-RPC > is a pre-requisite for making NFS IPv6 aware. > > So, I was wondering whether a switch to TI-RPC is planned. I know > it is a major task. I don't think this is within the KAME-project scope. On NetBSD, the NetBSD crowd has done this almost a year ago (I believe) and NFS over IPv6 works just great on NetBSD. I'd guess FreeBSD could borrow a lot from the NetBSD work, reducing the major-ness of the task? Feico. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 6: 8: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from gate.cpmet.ufpel.tche.br (gate.cpmet.ufpel.tche.br [200.248.148.33]) by hub.freebsd.org (Postfix) with ESMTP id C881E37B404; Thu, 25 Jan 2001 06:07:41 -0800 (PST) Received: from localhost (casantos@localhost) by gate.cpmet.ufpel.tche.br (8.11.1/8.11.1) with ESMTP id f0PE7JT01509; Thu, 25 Jan 2001 14:07:20 GMT (envelope-from casantos@cpmet.ufpel.tche.br) Date: Thu, 25 Jan 2001 14:07:19 +0000 (GMT) From: "Carlos A. M. dos Santos" To: current@FreeBSD.ORG Cc: ports@FreeBSD.ORG Subject: Re: HEADS UP: libc/libc_r changes require rebuild of threaded apps In-Reply-To: <3A6F20EE.15B78584@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 24 Jan 2001, Maxim Sobolev wrote: > > It's not a very accurate estimate, as the magic can be in the distfile > itself, i.e. properly written configure script or makefile may know > that FreeBSD need a -pthread and -D_THREAD_SAFE. > For some unknown reason, math.h needs _REENTRANT in FreeBSD to declare gamma_r, lgamma_r, gammaf_r and lgammaf_r. Perhaps this could be changed too. I don't know what the POSIX standard says about this. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767 FAX: +55 53 277-6722 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 6:22: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (Postfix) with ESMTP id 2486D37B401 for ; Thu, 25 Jan 2001 06:21:49 -0800 (PST) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97] ident=root) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 14LnHY-000GDk-00 for freebsd-current@freebsd.org; Thu, 25 Jan 2001 14:21:48 +0000 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.11.1/8.11.1) id f0PELlu58987 for freebsd-current@freebsd.org; Thu, 25 Jan 2001 14:21:47 GMT (envelope-from jcm) Date: Thu, 25 Jan 2001 14:21:46 +0000 From: j mckitrick To: freebsd-current@freebsd.org Subject: parallel port zip+ fix Message-ID: <20010125142123.A53100@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I have been working with Nicholas Souchu to fix a few issues with the parallel port zip, especially the zip+ (250 meg version). I know this is deprecated hardware, but I would like to know if it helps. The driver should now work correctly in PS2 transfer mode, which in theory should be twice as fast as NIBBLE mode. Set the flags for ppc to 0x00, so the driver will detect all available modes and choose the best one. Probing and mode selection has been much improved, thanks to Nicholas' work. If you want to force PS2 mode, that should work as well. Please let me know if you have any problems. jcm -- o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o | ~~~~~~~~~~~~ Jonathon McKitrick ~~~~~~~~~~~~~ | | "I prefer the term 'Artificial Person' myself." | o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 6:23:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 8AE8137B401 for ; Thu, 25 Jan 2001 06:23:07 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA27119; Thu, 25 Jan 2001 23:22:51 +0900 (JST) To: Feico Dillema Cc: snap-users@kame.net, Matt Dillon , freebsd-current@freebsd.org In-reply-to: feico's message of Thu, 25 Jan 2001 15:04:14 +0100. <20010125150414.B13004@pasta.cs.uit.no> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (KAME-snap 3972) TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) From: itojun@iijlab.net Date: Thu, 25 Jan 2001 23:22:51 +0900 Message-ID: <27117.980432571@coconut.itojun.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I don't think this is within the KAME-project scope. On NetBSD, the >NetBSD crowd has done this almost a year ago (I believe) and NFS over >IPv6 works just great on NetBSD. I'd guess FreeBSD could borrow a lot >from the NetBSD work, reducing the major-ness of the task? The above is correct. NetBSD NFS-over-IPv6 (actually RPC over IPv6) is TI-RPC based, and it was done by NetBSD guys not KAME guys. It is not impossible to support IPv6 NFS without switching to TI-RPC, INRIA IPv6 has the code (IIRC). However, if you try this, there will be a lot of of non-intuitive typecast against library arguments. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 7:51:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by hub.freebsd.org (Postfix) with ESMTP id 2181937B6A4 for ; Thu, 25 Jan 2001 07:51:01 -0800 (PST) Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) id 14Lofq-00032R-00; Thu, 25 Jan 2001 16:50:58 +0100 Received: from sure.surfnet.nl (sure.surfnet.nl [192.87.109.131]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.8) with ESMTP id QAA04311; Thu, 25 Jan 2001 16:50:57 +0100 (MET) Date: Thu, 25 Jan 2001 16:50:57 +0100 (CET) From: Ronald van der Pol To: snap-users@kame.net Cc: Feico Dillema , Matt Dillon , freebsd-current@freebsd.org Subject: Re: (KAME-snap 3974) Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) In-Reply-To: <27117.980432571@coconut.itojun.org> Message-ID: X-NCC-RegID: nl.surfnet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Jan 2001 itojun@iijlab.net wrote: > >I don't think this is within the KAME-project scope. On NetBSD, the > >NetBSD crowd has done this almost a year ago (I believe) and NFS over > >IPv6 works just great on NetBSD. I'd guess FreeBSD could borrow a lot > >from the NetBSD work, reducing the major-ness of the task? > > The above is correct. NetBSD NFS-over-IPv6 (actually RPC over IPv6) > is TI-RPC based, and it was done by NetBSD guys not KAME guys. Sorry, I was not clear. The question about moving towards TI-RPC was directed to freebsd-current. Just out of interest. No critisism intended. rvdp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 7:51:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by hub.freebsd.org (Postfix) with ESMTP id F158837B6A7 for ; Thu, 25 Jan 2001 07:51:05 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f0PFnPk01745; Thu, 25 Jan 2001 16:49:26 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA01801; Thu, 25 Jan 2001 16:49:24 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f0PFnAO32616; Thu, 25 Jan 2001 16:49:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200101251549.f0PFnAO32616@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: snap-users@kame.net Cc: Feico Dillema , Matt Dillon , freebsd-current@freebsd.org Subject: Re: (KAME-snap 3974) Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) In-reply-to: Your message of Thu, 25 Jan 2001 23:22:51 +0900. <27117.980432571@coconut.itojun.org> Date: Thu, 25 Jan 2001 16:49:10 +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In your previous mail you wrote: It is not impossible to support IPv6 NFS without switching to TI-RPC, INRIA IPv6 has the code (IIRC). => this code was ported to FreeBSD 4.2. I'll give more details as soon as I am back to my office (ie. next week). However, if you try this, there will be a lot of of non-intuitive typecast against library arguments. => this is a matter of taste. TI-RPC is not perfect tooo (:-). Thanks Francis.Dupont@enst-bretagne.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 7:58: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 3F50437B401 for ; Thu, 25 Jan 2001 07:57:36 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id AAA28876; Fri, 26 Jan 2001 00:57:18 +0900 (JST) To: snap-users@kame.net Cc: Feico Dillema , Matt Dillon , freebsd-current@freebsd.org In-reply-to: Ronald.vanderPol's message of Thu, 25 Jan 2001 16:50:57 +0100. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (KAME-snap 3976) Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) From: itojun@iijlab.net Date: Fri, 26 Jan 2001 00:57:18 +0900 Message-ID: <28874.980438238@coconut.itojun.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> The above is correct. NetBSD NFS-over-IPv6 (actually RPC over IPv6) >> is TI-RPC based, and it was done by NetBSD guys not KAME guys. >Sorry, I was not clear. The question about moving towards TI-RPC was >directed to freebsd-current. Just out of interest. No critisism intended. no, i did not took it as criticism. i (and feico) just tried to clarify. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 8:29:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from hera.drwilco.net (10dyn244.dh.casema.net [212.64.31.244]) by hub.freebsd.org (Postfix) with ESMTP id 63D9C37B6A7 for ; Thu, 25 Jan 2001 08:29:34 -0800 (PST) Received: from ceres.drwilco.net (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0PGotG03297; Thu, 25 Jan 2001 17:51:01 +0100 (CET) (envelope-from drwilco@drwilco.net) Message-Id: <4.3.2.7.0.20010125082405.00c906c0@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 08:30:17 +0100 To: "Vitaly V. Belekhov" , Julian Elischer From: "Rogier R. Mulhuijzen" Subject: Re: bw limit in netgraph (Was: status of bridge code) Cc: "Thomas T. Veldhouse" , freebsd-current@freebsd.org, Archie Cobbs In-Reply-To: References: <3A6F513C.376C173E@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Since I currently have high workload, I dont have time to port it to 4.x or > 5-CURRENT... > Conclusion: volunteer required for this work... and I can consult him/her. Shouldn't be too hard. I'll gladly volunteer for this project. Quick question for the netgraph guru's. I haven't looked yet, but is there an explanation of the NG_ macros I see used in the netgraph nodes' code? DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 8:45:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id CA9C937B401 for ; Thu, 25 Jan 2001 08:45:09 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA21553 for ; Thu, 25 Jan 2001 08:45:09 -0800 Date: Thu, 25 Jan 2001 08:45:10 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: current@freebsd.org Subject: > 4GB with NFS? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I came across an embarrassing comparison last night- FreeBSD NFS clients (well, i386) stop writing files at 4GB. Solaris, with O_LARGEFILE options in the open arguments, does not. Does anyone here know what FreeBSD ought to be doing about this? Or have I missed something? There is no O_LARGEFILE in fcntl.h (it is present for Solaris, ConvexOS and some other platforms, I believe). I thought the *BSDs had > 32 bit file support? Or is it only for local filesystems? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 9: 5: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 2753D37B404 for ; Thu, 25 Jan 2001 09:04:48 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f0PH4dK21538; Thu, 25 Jan 2001 11:04:39 -0600 (CST) (envelope-from dan) Date: Thu, 25 Jan 2001 11:04:38 -0600 From: Dan Nelson To: Matthew Jacob Cc: current@FreeBSD.ORG Subject: Re: > 4GB with NFS? Message-ID: <20010125110438.A23179@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: ; from "Matthew Jacob" on Thu Jan 25 08:45:10 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jan 25), Matthew Jacob said: > I came across an embarrassing comparison last night- > > FreeBSD NFS clients (well, i386) stop writing files at 4GB. > > Solaris, with O_LARGEFILE options in the open arguments, does not. > > Does anyone here know what FreeBSD ought to be doing about this? Or > have I missed something? There is no O_LARGEFILE in fcntl.h (it is > present for Solaris, ConvexOS and some other platforms, I believe). I > thought the *BSDs had > 32 bit file support? Or is it only for local > filesystems? FreeBSD has 64-bit file offsets by default, which make -DLARGEFILE hackery unnecessary. Make sure you're using NFSv3 mounts (should be the default, but if not, add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, Tru64, and Solaris boxes via NFS and can access large files on all combinations of client and server. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 9:10:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 854B837B400 for ; Thu, 25 Jan 2001 09:10:13 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA21757; Thu, 25 Jan 2001 09:10:02 -0800 Date: Thu, 25 Jan 2001 09:10:03 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Dan Nelson Cc: current@FreeBSD.ORG Subject: Re: > 4GB with NFS? In-Reply-To: <20010125110438.A23179@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Jan 2001, Dan Nelson wrote: > In the last episode (Jan 25), Matthew Jacob said: > > I came across an embarrassing comparison last night- > > > > FreeBSD NFS clients (well, i386) stop writing files at 4GB. > > > > Solaris, with O_LARGEFILE options in the open arguments, does not. > > > > Does anyone here know what FreeBSD ought to be doing about this? Or > > have I missed something? There is no O_LARGEFILE in fcntl.h (it is > > present for Solaris, ConvexOS and some other platforms, I believe). I > > thought the *BSDs had > 32 bit file support? Or is it only for local > > filesystems? > > FreeBSD has 64-bit file offsets by default, which make -DLARGEFILE > hackery unnecessary. So I thought! > > Make sure you're using NFSv3 mounts (should be the default, but if not, > add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, > Tru64, and Solaris boxes via NFS and can access large files on all > combinations of client and server. Huh. Interesting. The default showed up as a nfsv3 mount: 1/25 2:12 mountd/v3: granted 192.67.166.79 to /bob ro=0 uid0=60001 The solaris mount showed up as: 1/25 2:06 mountd/v3: granted 192.67.166.155 to /bob ro=0 uid0=60001 1/25 2:06 nfs/tcp accepted 192.67.166.155,1023 I'll try an explicit v3 mount/tcp and see if it's better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 9:13:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id DC95D37B400 for ; Thu, 25 Jan 2001 09:13:25 -0800 (PST) Received: (from dan@localhost) by dan.emsphone.com (8.11.1/8.11.1) id f0PHDMD02053; Thu, 25 Jan 2001 11:13:22 -0600 (CST) (envelope-from dan) Date: Thu, 25 Jan 2001 11:13:22 -0600 From: Dan Nelson To: Matthew Jacob Cc: current@FreeBSD.ORG Subject: Re: > 4GB with NFS? Message-ID: <20010125111322.B23179@dan.emsphone.com> References: <20010125110438.A23179@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13i In-Reply-To: ; from "Matthew Jacob" on Thu Jan 25 09:10:03 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jan 25), Matthew Jacob said: > On Thu, 25 Jan 2001, Dan Nelson wrote: > > Make sure you're using NFSv3 mounts (should be the default, but if not, > > add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, > > Tru64, and Solaris boxes via NFS and can access large files on all > > combinations of client and server. > > Huh. Interesting. The default showed up as a nfsv3 mount: > > 1/25 2:12 mountd/v3: granted 192.67.166.79 to /bob ro=0 uid0=60001 > > The solaris mount showed up as: > > 1/25 2:06 mountd/v3: granted 192.67.166.155 to /bob ro=0 uid0=60001 > 1/25 2:06 nfs/tcp accepted 192.67.166.155,1023 > > I'll try an explicit v3 mount/tcp and see if it's better. I use UDP mounts as it's easier to debug traces. The next step is to start looking as packet dumps... When you say that the FreeBSD clients "stop writing", what error do they get? Also, what version of FreeBSD are you using? -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 9:14: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AF90937B404 for ; Thu, 25 Jan 2001 09:13:43 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA21787; Thu, 25 Jan 2001 09:13:40 -0800 Date: Thu, 25 Jan 2001 09:13:41 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Dan Nelson Cc: current@FreeBSD.ORG, current-users@netbsd.org Subject: Re: > 4GB with NFS? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To be fair, I should say that the server is a 'specical' box. But an lmdd writing to a file in 250GB partition that I started from Solaris last night is still going. The NetBSD && FreeBSD writes both stopped at 4GB. I suppose it still could be the server, but, well, it's hard to sell against something that "just works"... .:-) On Thu, 25 Jan 2001, Matthew Jacob wrote: > > On Thu, 25 Jan 2001, Dan Nelson wrote: > > > In the last episode (Jan 25), Matthew Jacob said: > > > I came across an embarrassing comparison last night- > > > > > > FreeBSD NFS clients (well, i386) stop writing files at 4GB. > > > > > > Solaris, with O_LARGEFILE options in the open arguments, does not. > > > > > > Does anyone here know what FreeBSD ought to be doing about this? Or > > > have I missed something? There is no O_LARGEFILE in fcntl.h (it is > > > present for Solaris, ConvexOS and some other platforms, I believe). I > > > thought the *BSDs had > 32 bit file support? Or is it only for local > > > filesystems? > > > > FreeBSD has 64-bit file offsets by default, which make -DLARGEFILE > > hackery unnecessary. > > So I thought! > > > > > Make sure you're using NFSv3 mounts (should be the default, but if not, > > add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, > > Tru64, and Solaris boxes via NFS and can access large files on all > > combinations of client and server. > > Huh. Interesting. The default showed up as a nfsv3 mount: > > 1/25 2:12 mountd/v3: granted 192.67.166.79 to /bob ro=0 uid0=60001 > > The solaris mount showed up as: > > 1/25 2:06 mountd/v3: granted 192.67.166.155 to /bob ro=0 uid0=60001 > 1/25 2:06 nfs/tcp accepted 192.67.166.155,1023 > > I'll try an explicit v3 mount/tcp and see if it's better. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 9:18:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C1E8937B402 for ; Thu, 25 Jan 2001 09:18:00 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA21829; Thu, 25 Jan 2001 09:17:56 -0800 Date: Thu, 25 Jan 2001 09:17:57 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Dan Nelson Cc: current@FreeBSD.ORG Subject: Re: > 4GB with NFS? In-Reply-To: <20010125111322.B23179@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Jan 2001, Dan Nelson wrote: > In the last episode (Jan 25), Matthew Jacob said: > > On Thu, 25 Jan 2001, Dan Nelson wrote: > > > Make sure you're using NFSv3 mounts (should be the default, but if not, > > > add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, > > > Tru64, and Solaris boxes via NFS and can access large files on all > > > combinations of client and server. > > > > Huh. Interesting. The default showed up as a nfsv3 mount: > > > > 1/25 2:12 mountd/v3: granted 192.67.166.79 to /bob ro=0 uid0=60001 > > > > The solaris mount showed up as: > > > > 1/25 2:06 mountd/v3: granted 192.67.166.155 to /bob ro=0 uid0=60001 > > 1/25 2:06 nfs/tcp accepted 192.67.166.155,1023 > > > > I'll try an explicit v3 mount/tcp and see if it's better. > > I use UDP mounts as it's easier to debug traces. > > The next step is to start looking as packet dumps... When you say that > the FreeBSD clients "stop writing", what error do they get? None. As in EOF. > Also, what > version of FreeBSD are you using? 4.2 in this case. 1.5.1 for NetBSD. Okay- I think from what you've said and what Thor said for NetBSD is that this is "supposed to work!" (which accords with what *I* thought too). I'll do some more debugging as I can (I'm in a project deadline for 3 projects this week). But I won't let it go! I was hoping to replace my Solaris box with either FreeBSD or NetBSD as my main home directory server. FreeBSD 4.2 panics part way through the first LADDIS runs I was using to test it with and I can't get NetBSD to start as a LADDIS client (I hadn't got the auth sorted out yet), so I've been trying to scrutinize a lot of things very closely in this area. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 9:31:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id C357737B699 for ; Thu, 25 Jan 2001 09:31:07 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0PHV4i22215; Thu, 25 Jan 2001 09:31:04 -0800 (PST) Date: Thu, 25 Jan 2001 09:31:04 -0800 From: Alfred Perlstein To: Matthew Jacob Cc: Dan Nelson , current@FreeBSD.ORG Subject: Re: > 4GB with NFS? Message-ID: <20010125093104.L26076@fw.wintelcom.net> References: <20010125111322.B23179@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Thu, Jan 25, 2001 at 09:17:57AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Matthew Jacob [010125 09:18] wrote: > > > On Thu, 25 Jan 2001, Dan Nelson wrote: > > > In the last episode (Jan 25), Matthew Jacob said: > > > On Thu, 25 Jan 2001, Dan Nelson wrote: > > > > Make sure you're using NFSv3 mounts (should be the default, but if not, > > > > add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, > > > > Tru64, and Solaris boxes via NFS and can access large files on all > > > > combinations of client and server. > > > > > > Huh. Interesting. The default showed up as a nfsv3 mount: > > > > > > 1/25 2:12 mountd/v3: granted 192.67.166.79 to /bob ro=0 uid0=60001 > > > > > > The solaris mount showed up as: > > > > > > 1/25 2:06 mountd/v3: granted 192.67.166.155 to /bob ro=0 uid0=60001 > > > 1/25 2:06 nfs/tcp accepted 192.67.166.155,1023 > > > > > > I'll try an explicit v3 mount/tcp and see if it's better. > > > > I use UDP mounts as it's easier to debug traces. > > > > The next step is to start looking as packet dumps... When you say that > > the FreeBSD clients "stop writing", what error do they get? > > None. As in EOF. > > > Also, what > > version of FreeBSD are you using? > > 4.2 in this case. 1.5.1 for NetBSD. > > > Okay- I think from what you've said and what Thor said for NetBSD is that this > is "supposed to work!" (which accords with what *I* thought too). I'll do some > more debugging as I can (I'm in a project deadline for 3 projects this week). > > But I won't let it go! I was hoping to replace my Solaris box with either > FreeBSD or NetBSD as my main home directory server. FreeBSD 4.2 panics part > way through the first LADDIS runs I was using to test it with and I can't get > NetBSD to start as a LADDIS client (I hadn't got the auth sorted out yet), so > I've been trying to scrutinize a lot of things very closely in this area. This is an old problem that I think was never addressed. It has to do with the vm system (on i386). It may be fixed now, so keep playing a bit, if not open a problem report and someone ought to get to it. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 9:40:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id BB5CE37B401 for ; Thu, 25 Jan 2001 09:40:19 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id JAA59531; Thu, 25 Jan 2001 09:38:48 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id JAA06204; Thu, 25 Jan 2001 09:37:33 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101251737.JAA06204@curve.dellroad.org> Subject: Re: status of bridge code In-Reply-To: <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> "from Rogier R. Mulhuijzen at Jan 25, 2001 00:16:16 am" To: "Rogier R. Mulhuijzen" Date: Thu, 25 Jan 2001 09:37:32 -0800 (PST) Cc: Julian Elischer , freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Rogier R. Mulhuijzen writes: > But from my list of wishes I'd say the first 3 are gone. All that's left is > spanning tree. I'm probably going to need this pretty soon, so once more > I'm asking if anyone is working on it. If not I'll start on it. Do you have references for how to do this? As I understand it, there are special Ethernet addresses that are "for bridges only -- do not forward" that are used to construct the spanning tree, etc. What is the "standard" algorithm used by bridges, etc.? > Also, a quick question for you netgraph guys. Why is it that ng_one2many > send a packet only out of one hook? I can see use for an algorithm that > sends packets from the 'one' hook to all the 'many' hooks (that are up) and > keep the normal behaviour for many to one. Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 9:41:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id B130737B401 for ; Thu, 25 Jan 2001 09:41:32 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id JAA59544; Thu, 25 Jan 2001 09:40:16 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id JAA06220; Thu, 25 Jan 2001 09:40:01 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101251740.JAA06220@curve.dellroad.org> Subject: Re: bw limit in netgraph (Was: status of bridge code) In-Reply-To: <4.3.2.7.0.20010125082405.00c906c0@mail.drwilco.net> "from Rogier R. Mulhuijzen at Jan 25, 2001 08:30:17 am" To: "Rogier R. Mulhuijzen" Date: Thu, 25 Jan 2001 09:40:00 -0800 (PST) Cc: "Vitaly V. Belekhov" , Julian Elischer , "Thomas T. Veldhouse" , freebsd-current@freebsd.org, Archie Cobbs X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Rogier R. Mulhuijzen writes: > Quick question for the netgraph guru's. I haven't looked yet, but is there > an explanation of the NG_ macros I see used in the netgraph nodes' code? Yes, but it's not documented :) Actually the daemonnews article does document these somewhat. The main ones are NG_MKMESSAGE() for creating a new control message and NG_MKRESPONSE() for creating a response to a control message; and NG_SEND_DATA() to send a data/meta pair, NG_FREE_DATA() to free one. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 9:46:49 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3A09737B69F for ; Thu, 25 Jan 2001 09:46:30 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA21963; Thu, 25 Jan 2001 09:46:16 -0800 Date: Thu, 25 Jan 2001 09:46:16 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Alfred Perlstein Cc: Dan Nelson , current@FreeBSD.ORG Subject: Re: > 4GB with NFS? In-Reply-To: <20010125093104.L26076@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > But I won't let it go! I was hoping to replace my Solaris box with either > > FreeBSD or NetBSD as my main home directory server. FreeBSD 4.2 panics part > > way through the first LADDIS runs I was using to test it with and I can't get > > NetBSD to start as a LADDIS client (I hadn't got the auth sorted out yet), so > > I've been trying to scrutinize a lot of things very closely in this area. > > This is an old problem that I think was never addressed. It has to > do with the vm system (on i386). It may be fixed now, so keep playing > a bit, if not open a problem report and someone ought to get to it. Yah, I was gonna do that once -current stabilized a bit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 10:37:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 33B0637B6A7 for ; Thu, 25 Jan 2001 10:37:00 -0800 (PST) Received: from victoria-221.budapest.interware.hu ([195.70.63.221] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LrGT-0004gK-00; Thu, 25 Jan 2001 19:36:58 +0100 Message-ID: <3A70723D.1C2959E0@elischer.org> Date: Thu, 25 Jan 2001 10:36:45 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Rogier R. Mulhuijzen" Cc: freebsd-current@freebsd.org Subject: Re: panic in netgraph (caught by WITNESS) in custom UP kernel References: <4.3.2.7.0.20010125011302.00beb520@mail.drwilco.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Rogier R. Mulhuijzen" wrote: > > FYI: > > Full source CVSupped on the 18th or 19th > > Panic came about when I did a 'ls' in ngctl(8). > > Kernel config attached, gdb of core follows below: > > This GDB was configured as "i386-unknown-freebsd"... > IdlePTD 5300224 > initial pcb at 31c4e0 > panicstr: from debugger > panic messages: > --- > panic: mutex_enter: MTX_SPIN on MTX_DEF mutex netgraph node mutex @ > ../../netgraph/ng_base.c:2205 > panic: from debugger > Uptime: 1d4h5m24s I think I fixed this yesterday by adding MTX_SPIN to the mtx_init() call. let me know if that isn't the case (check you have the last patch to ng_base.c) -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 10:37:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id 2DD8737B69E for ; Thu, 25 Jan 2001 10:37:10 -0800 (PST) Received: (qmail 19482 invoked from network); 25 Jan 2001 18:37:09 -0000 Received: from cognac.local.mindstep.com (HELO cognac) (192.168.10.9) by jacuzzi.local.mindstep.com with SMTP; 25 Jan 2001 18:37:09 -0000 From: "Patrick Bihan-Faou" To: Subject: Re: status of bridge code Date: Thu, 25 Jan 2001 13:38:28 -0500 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.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > > But from my list of wishes I'd say the first 3 are gone. All that's left is > > spanning tree. I'm probably going to need this pretty soon, so once more > > I'm asking if anyone is working on it. If not I'll start on it. > > Do you have references for how to do this? As I understand it, there > are special Ethernet addresses that are "for bridges only -- do not > forward" that are used to construct the spanning tree, etc. What is > the "standard" algorithm used by bridges, etc.? After a quick search on google for "spanning tree" and "BPDU", here are some usefull links: http://www.ece.wpi.edu/courses/ee535/hwk96/hwk3cd96/sef/sef.html http://www.synapse.de/ban/HTML/P_LAYER2/Eng/P_lay119.html http://www.ethereal.com/lists/ethereal-dev/199910/msg00070.html http://www.support.baynetworks.com/library/tpubs/html/router/soft1000/bridge /2950A-16.html Apparently there is an implementation in linux (look for the file net/bridge/br_stp_bpdu.c) and the "BRIDGE-STP-HOWTO" (http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/BRIDG E-STP-HOWTO.html) http://www.linuxhq.com/kernel/v2.3/patch/patch-2.3.47/linux_net_bridge_br_st p.c.html Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 10:44:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id D8CD837B69E for ; Thu, 25 Jan 2001 10:44:05 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id NAA13541; Thu, 25 Jan 2001 13:44:05 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f0PIi5j20522; Thu, 25 Jan 2001 13:44:05 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Jan 2001 13:44:05 -0500 (EST) To: mjacob@feral.com Cc: current@freebsd.org Subject: Re: > 4GB with NFS? In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14960.28209.622301.752510@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob writes: > > I came across an embarrassing comparison last night- > > FreeBSD NFS clients (well, i386) stop writing files at 4GB. > > Solaris, with O_LARGEFILE options in the open arguments, does not. > > Does anyone here know what FreeBSD ought to be doing about this? > Or have I missed something? There is no O_LARGEFILE in fcntl.h (it is present > for Solaris, ConvexOS and some other platforms, I believe). I thought the > *BSDs had > 32 bit file support? Or is it only for local filesystems? > > -matt Normal /bin/dd works fine between on 4.2-RELEASE i386s here. This is writing to a raid0 fs on a FreeBSD/i386 server using an nfsv3 mount, udp, 8k read/write size: % dd if=/dev/zero of=bigfile bs=1024k count=5000 5000+0 records in 5000+0 records out 5242880000 bytes transferred in 471.673794 secs (11115479 bytes/sec) This is writing to a software raid5 fs on a Solaris/x86 (2.8) server using an nfsv3 mount, udp, 8k read/write size: % dd if=/dev/zero of=bigfile bs=1024k count=5000 5000+0 records in 5000+0 records out 5242880000 bytes transferred in 1165.859965 secs (4497007 bytes/sec) Maybe you should look at "lmdd" ? Maybe it is either buggy, or it was compiled a long, long time ago? (btw, this is a virgin 4.2 install, with none of my nfs opts in it). Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 10:47:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id DB09B37B6A7 for ; Thu, 25 Jan 2001 10:47:12 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA22395; Thu, 25 Jan 2001 10:47:09 -0800 Date: Thu, 25 Jan 2001 10:47:08 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Andrew Gallatin Cc: current@freebsd.org Subject: Re: > 4GB with NFS? In-Reply-To: <14960.28209.622301.752510@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 25 Jan 2001, Andrew Gallatin wrote: > > Matthew Jacob writes: > > > > I came across an embarrassing comparison last night- > > > > FreeBSD NFS clients (well, i386) stop writing files at 4GB. > > > > Solaris, with O_LARGEFILE options in the open arguments, does not. > > > > Does anyone here know what FreeBSD ought to be doing about this? > > Or have I missed something? There is no O_LARGEFILE in fcntl.h (it is present > > for Solaris, ConvexOS and some other platforms, I believe). I thought the > > *BSDs had > 32 bit file support? Or is it only for local filesystems? > > > > -matt > > Normal /bin/dd works fine between on 4.2-RELEASE i386s here. > > This is writing to a raid0 fs on a FreeBSD/i386 server using an nfsv3 > mount, udp, 8k read/write size: > > % dd if=/dev/zero of=bigfile bs=1024k count=5000 > 5000+0 records in > 5000+0 records out > 5242880000 bytes transferred in 471.673794 secs (11115479 bytes/sec) > > This is writing to a software raid5 fs on a Solaris/x86 (2.8) server > using an nfsv3 mount, udp, 8k read/write size: > > % dd if=/dev/zero of=bigfile bs=1024k count=5000 > 5000+0 records in > 5000+0 records out > 5242880000 bytes transferred in 1165.859965 secs (4497007 bytes/sec) > > Maybe you should look at "lmdd" ? Maybe it is either buggy, or it was > compiled a long, long time ago? Same code compiled on Solaris is happy. > (btw, this is a virgin 4.2 install, with none of my nfs opts in it). Hmm. Well, everyone sez this oughta work so I'll go and figure out why it ain't for me... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 10:50: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 567B337B6AD for ; Thu, 25 Jan 2001 10:49:48 -0800 (PST) Received: from victoria-221.budapest.interware.hu ([195.70.63.221] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LrSq-0005uf-00; Thu, 25 Jan 2001 19:49:44 +0100 Message-ID: <3A707539.60091940@elischer.org> Date: Thu, 25 Jan 2001 10:49:29 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Rogier R. Mulhuijzen" Cc: Archie Cobbs , freebsd-current@FreeBSD.ORG Subject: Re: status of bridge code References: <4.3.2.7.0.20010124185058.00ac5100@mail.drwilco.net> <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Rogier R. Mulhuijzen" wrote: > > >personally I use the netgraph bridging code and I think (though I'm biased) > >that you should look at using htat rather than the hardwired bridging > >code that it was derived from. > > Now that I've read up on it I can tell you you and and Archie have every > right to be biased =) > > I've had a netgraph bridge in place for a while now and it works very well. > (On 4.X-STABLE, on 5.X-CURRENT it went kablooie. See panic trace) where is it? (have you tried it REALLY recently?) > > > > item on my list. Being an allround good networking OS this is unacceptable > > > IMHO. > > > >Have a look at what you can do with netgraph first. > > > >Most people don't know what it is but it allows almost arbitrarily > >complicated network topologies to be set up from the command line. > > What you might want to tell people is that it allows networking structures > to be setup in a simple manner, but is so powerful it can also be used for > immensely complex structures. A friend and fellow BSD user of mine's first > response was "I like to keep things simple". After I rephrased into the > above he was much more interested. > > But from my list of wishes I'd say the first 3 are gone. All that's left is > spanning tree. I'm probably going to need this pretty soon, so once more > I'm asking if anyone is working on it. If not I'll start on it. > > Also, a quick question for you netgraph guys. Why is it that ng_one2many > send a packet only out of one hook? I can see use for an algorithm that > sends packets from the 'one' hook to all the 'many' hooks (that are up) and > keep the normal behaviour for many to one. > > DocWilco -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 10:56:22 2001 Delivered-To: freebsd-current@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 7DBE937B6AD for ; Thu, 25 Jan 2001 10:56:02 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id NAA13875; Thu, 25 Jan 2001 13:56:02 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.1/8.9.1) id f0PIu1i20552; Thu, 25 Jan 2001 13:56:01 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 25 Jan 2001 13:56:01 -0500 (EST) To: mjacob@feral.com Cc: current@freebsd.org Subject: Re: > 4GB with NFS? In-Reply-To: References: <14960.28209.622301.752510@grasshopper.cs.duke.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14960.30292.831422.916017@grasshopper.cs.duke.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob writes: > > Same code compiled on Solaris is happy. Perhaps there's some braindamage in it. I'm afraid of something like: #ifdef Solaris typedef filefoo u_int64_t; #else typedef filefoo u_int32_t; #endif ;) Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 10:58:33 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C233A37B6AF for ; Thu, 25 Jan 2001 10:58:13 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA22531; Thu, 25 Jan 2001 10:57:54 -0800 Date: Thu, 25 Jan 2001 10:57:53 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Andrew Gallatin Cc: current@freebsd.org Subject: Re: > 4GB with NFS? In-Reply-To: <14960.30292.831422.916017@grasshopper.cs.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Matthew Jacob writes: > > > > Same code compiled on Solaris is happy. > > Perhaps there's some braindamage in it. I'm afraid of something like: > > #ifdef Solaris > typedef filefoo u_int64_t; > #else > typedef filefoo u_int32_t; > #endif > I'll try with dd then,... let y'all know... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 11: 7:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 1953D37B6B0; Thu, 25 Jan 2001 11:07:11 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.1/8.11.1) with ESMTP id f0PJ73o44918; Thu, 25 Jan 2001 20:07:03 +0100 (CET) (envelope-from Martin.Blapp@imp.ch) Date: Thu, 25 Jan 2001 20:13:21 +0100 (CET) From: Martin Blapp To: Ronald van der Pol Cc: freebsd-current@freebsd.org, snap-users@kame.net, alfred@freebsd.org Subject: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Alfred Perlstein and I have ported TI-RPC to FreeBSD Current. You can find the latest snapshot here: http://www.attic.ch/rpc.diff_01114001.tgz Patches and bugfixes are welcome. Martin Martin Blapp, mb@imp.ch ------------------------------------------------ Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 ------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 11:13:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id C175237B6AD; Thu, 25 Jan 2001 11:12:56 -0800 (PST) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by palrel3.hp.com (Postfix) with ESMTP id ED0DEAE3; Thu, 25 Jan 2001 11:12:55 -0800 (PST) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id LAA27469; Thu, 25 Jan 2001 11:12:55 -0800 (PST) Message-ID: <3A707AB7.53C0BB11@cup.hp.com> Date: Thu, 25 Jan 2001 11:12:55 -0800 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Ruslan Ermilov Cc: rene@xs4all.nl, stable@FreeBSD.org Subject: Re: Bootstrapping issues with groff(1) References: <20001216171526.A28853@sunbay.com> <20010124182729.A22713@xs4all.nl> <20001208181908.A12716@sunbay.com> <3A319751.D2C9E5AB@cup.hp.com> <20001209154347.A78374@sunbay.com> <3A329641.CC6D8447@cup.hp.com> <20001211094815.D96665@sunbay.com> <3A3509E9.F1D19305@cup.hp.com> <20001212102344.B92312@sunbay.com> <3A3663DB.2DA71F0E@cup.hp.com> <20010125142504.A15489@sunbay.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [I don't know why -current is CC'd this is clearly about -stable] Ruslan Ermilov wrote: > > Attached is the patch for RELENG_4. It works but I don't like > how it pollutes the Makefile.inc1. Anyone with a better idea? Allow me to sidetrack for a moment: I just ugraded a machine from 4.1 to 4.2-stable without any problems. I'm a bit confused. Rene picks up RELENG_4 and sees his build fail. Why did it work for me? -- Marcel Moolenaar mail: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 11:21:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id A576E37B6A2 for ; Thu, 25 Jan 2001 11:21:34 -0800 (PST) Received: from victoria-221.budapest.interware.hu ([195.70.63.221] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14Lrxc-0000wS-00; Thu, 25 Jan 2001 20:21:33 +0100 Message-ID: <3A707CB1.A6C72EAC@elischer.org> Date: Thu, 25 Jan 2001 11:21:21 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Archie Cobbs Cc: "Rogier R. Mulhuijzen" , freebsd-current@FreeBSD.ORG Subject: Re: status of bridge code References: <200101251737.JAA06204@curve.dellroad.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Archie Cobbs wrote: > > Rogier R. Mulhuijzen writes: > > > Also, a quick question for you netgraph guys. Why is it that ng_one2many > > send a packet only out of one hook? I can see use for an algorithm that > > sends packets from the 'one' hook to all the 'many' hooks (that are up) and > > keep the normal behaviour for many to one. this would be a REALLY easy node to write...maybe your first? (see how 'ng_tee' works and ng_one2many, and write one that does something in between. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 11:50:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 668F037B69F for ; Thu, 25 Jan 2001 11:49:54 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0PJnm226767; Thu, 25 Jan 2001 11:49:48 -0800 (PST) Date: Thu, 25 Jan 2001 11:49:48 -0800 From: Alfred Perlstein To: Martin Blapp Cc: Ronald van der Pol , freebsd-current@freebsd.org, snap-users@kame.net Subject: Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) Message-ID: <20010125114948.S26076@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mb@imp.ch on Thu, Jan 25, 2001 at 08:13:21PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Martin Blapp [010125 11:07] wrote: > > Hi, > > Alfred Perlstein and I have ported TI-RPC to FreeBSD Current. You can find > the latest snapshot here: > > http://www.attic.ch/rpc.diff_01114001.tgz > > Patches and bugfixes are welcome. Can you post a summary of how you've done it and what you've done to it since we last worked on this? Nothing big, just a few points on what it gives us and what you've done (or not done) about the TLI junk that it's encumbered with. thanks, -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 12: 9: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 5FC9437B698 for ; Thu, 25 Jan 2001 12:08:48 -0800 (PST) Received: from victoria-166.budapest.interware.hu ([195.70.63.166] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LshK-0005iL-00 for ; Thu, 25 Jan 2001 21:08:46 +0100 Message-ID: <3A7087C2.36A126AB@elischer.org> Date: Thu, 25 Jan 2001 12:08:34 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Subject: [loader?] secret to setting root elsewhere?. Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok so I have tried the settings in teh loader conf.. I have: #autoboot_delay="10" # Delay in seconds before autobooting #console="vidconsole" # Set the current console currdev="disk1s1a" # Set the current device module_path="/boot/kernel;/boot/modules" # Set the module search path #prompt="\\${interpret}" # Set the command prompt root_disk_unit="1" # Force the root disk unit number rootdev="disk1s1a" # Set the root filesystem but it still loads disk0 as root.. what am I doing wrong? (this is the conf file on the 2nd disk..) I hit F5 (2nd disk) then F1 (FreeBSD) and then it loads the loader. I examined the settings and they appear right in the loader. (It uses the 2nd disk while loading the kernel so Iassume that it is correct) but is still mounts ad0s4a as root.... what am I doing wrong..? -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 12:19:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from hera.drwilco.net (10dyn244.dh.casema.net [212.64.31.244]) by hub.freebsd.org (Postfix) with ESMTP id 260D437B69B for ; Thu, 25 Jan 2001 12:19:29 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0PKfPG03729; Thu, 25 Jan 2001 21:41:25 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010125122010.00c83820@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 12:20:46 +0100 To: Julian Elischer , Archie Cobbs From: "Rogier R. Mulhuijzen" Subject: Re: status of bridge code Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <3A707CB1.A6C72EAC@elischer.org> References: <200101251737.JAA06204@curve.dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >this would be a REALLY easy node to write...maybe your first? >(see how 'ng_tee' works and ng_one2many, and >write one that does something in between. I was thinking adding an algorithm to one2many..... DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 12:19:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from hera.drwilco.net (10dyn244.dh.casema.net [212.64.31.244]) by hub.freebsd.org (Postfix) with ESMTP id F2C0C37B69E for ; Thu, 25 Jan 2001 12:19:32 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0PKdtG03716; Thu, 25 Jan 2001 21:39:55 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 12:19:16 +0100 To: Archie Cobbs From: "Rogier R. Mulhuijzen" Subject: Re: status of bridge code Cc: Julian Elischer , freebsd-current@FreeBSD.ORG In-Reply-To: <200101251737.JAA06204@curve.dellroad.org> References: <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 09:37 25-1-01 -0800, Archie Cobbs wrote: >Rogier R. Mulhuijzen writes: > > But from my list of wishes I'd say the first 3 are gone. All that's > left is > > spanning tree. I'm probably going to need this pretty soon, so once more > > I'm asking if anyone is working on it. If not I'll start on it. > >Do you have references for how to do this? As I understand it, there >are special Ethernet addresses that are "for bridges only -- do not >forward" that are used to construct the spanning tree, etc. What is >the "standard" algorithm used by bridges, etc.? There's a Spanning Tree Protocol (STP) defined by IEEE 802.1D. I'd prefer to have that, but I don't have the 1K US$ to shell out for that. Does BSDi have IEEE subscriptions for FreeBSD developers to use? Anyway, even without the IEEE standard I have been able to piece together how the protocol works. First of all bridges might have their own MACs that fall into a certain range, but STP does not depend on that. The "do not forward" is deducted from the protocol type. There is an ethernet protocol called BPDU (Bridge Protocol Data Unit) that each bridge sends and receives, but is not forwarded by any of them. These BDPUs are used to elect root bridge and determine root ports and designated ports. This results in the blocking of redundant ports so that loops are eliminated. See http://www.knowcisco.com/content/1578700949/pt02ch06.shtml for a good overview that's pretty in depth. About those blocked ports though I have a question. I've been reading ng_bridge.c and blocking a link in there (a tad more finegrained than right now) should not be a problem. But it seems to me that with the bridge.ether example there might be a problem. I'm using my own situation at home as an example to sketch this out. Please correct me if I'm wrong. 1 real NIC connected to LAN with ed0 as interface 1 tap device ran by vtun with tap0 as interface 1 tun device connected to cablemodem with tun0 as interface I have a netgraph bridge node that has ed0 and tap0 as interfaces, and ed0 as local interface (as per the example script) This means that packets from kernel to LAN go through the bridge node (thanks to the link from ed0.upper to the bridge) but packets from the kernel to the tap0 interface don't go through it (no link from tap0.upper to bridge). This means the bridge node has no idea where the MAC of the tap0 device is located (not stored in the MAC table of the bridge). So when packets directed at my tap0 interface enter the bridge (through the link from tap0.lower to the bridge) the bridge doesn't have a clue where to send it, and will thus forward to all links. Thus it will go through ed0.upper and end up in the kernel, no harm done. BUT it will also go out ed0.lower and end up in my LAN where it doesn't belong. Right now I don't mind because the traffic my cablemodem can handle is 8KB/s max. But it is not desired behaviour of a bridge. What I want to know is can I just link tap0.upper to a new bridge hook? It seems to me that is the case. If that's true the example script should be altered because right now it doesn't support more than one interface. Just say the word and I'll take care of it. =) > > Also, a quick question for you netgraph guys. Why is it that ng_one2many > > send a packet only out of one hook? I can see use for an algorithm that > > sends packets from the 'one' hook to all the 'many' hooks (that are up) > and > > keep the normal behaviour for many to one. > >Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes.. I don't see how though. Lets say I link only to left, right and left2right. Now when data enters left it will go to both right and left2right. When data enters right it goes to left. But when data enters left2right it goes to right, not left, where I want it. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 12:33:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (unknown [169.237.8.131]) by hub.freebsd.org (Postfix) with ESMTP id 3009937B69D for ; Thu, 25 Jan 2001 12:33:03 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0PKmZ801414; Thu, 25 Jan 2001 12:48:35 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101252048.f0PKmZ801414@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: current@freebsd.org Subject: Re: [loader?] secret to setting root elsewhere?. In-reply-to: Your message of "Thu, 25 Jan 2001 12:08:34 PST." <3A7087C2.36A126AB@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jan 2001 12:48:35 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ok so I have tried the settings in > teh loader conf.. > I have: > > #autoboot_delay="10" # Delay in seconds before autobooting > #console="vidconsole" # Set the current console > currdev="disk1s1a" # Set the current device > module_path="/boot/kernel;/boot/modules" # Set the module search path > #prompt="\\${interpret}" # Set the command prompt > root_disk_unit="1" # Force the root disk unit number > rootdev="disk1s1a" # Set the root filesystem > > > but it still loads disk0 as root.. > > what am I doing wrong? You don't "load a disk as root". If you mean "it loads the kernel from the wrong place", that's one thing. If you mean "it mounts / from the wrong filesystem", then you should be aware that the loader reads /etc/fstab, and the kernel will mount whatever you've put in there. root_disk_unit is also deprecated. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 13:15: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from web10405.mail.yahoo.com (web10405.mail.yahoo.com [216.136.130.97]) by hub.freebsd.org (Postfix) with SMTP id 06E8637B699 for ; Thu, 25 Jan 2001 13:14:47 -0800 (PST) Message-ID: <20010125211443.22025.qmail@web10405.mail.yahoo.com> Received: from [144.48.18.200] by web10405.mail.yahoo.com; Thu, 25 Jan 2001 13:14:43 PST Date: Thu, 25 Jan 2001 13:14:43 -0800 (PST) From: Nathan Parrish Subject: Re: > 4GB with NFS? To: mjacob@feral.com, Dan Nelson Cc: current@FreeBSD.ORG, current-users@netbsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG knowing NFS in general far better than *BSD in specific, I would guess the best thing to do (if you suspect server/client communication anomaly) is to grab a snoop/tcpdump of the failure. I'm trying to think of a clever way to cause the failure immediately, so you're not tracing 4GB of writes... mebbe dd's seek/skip? or just append to the existing 4GB file. also, what command are you using on the bsd's to write the 4GB file? I've definitely seen issues with VLF-capable OS's failing to write past 2/4GB due to VLF-incapable utilities. (on a related note, is there a need for vlfread()/vlfwrite() in the BSD's, or is VLF support native in the read/write calls? nathan --- Matthew Jacob wrote: > > To be fair, I should say that the server is a 'specical' box. > > But an lmdd writing to a file in 250GB partition that I started from Solaris > last night is still going. The NetBSD && FreeBSD writes both stopped at 4GB. > I > suppose it still could be the server, but, well, it's hard to sell against > something that "just works"... .:-) > > > On Thu, 25 Jan 2001, Matthew Jacob wrote: > > > > > On Thu, 25 Jan 2001, Dan Nelson wrote: > > > > > In the last episode (Jan 25), Matthew Jacob said: > > > > I came across an embarrassing comparison last night- > > > > > > > > FreeBSD NFS clients (well, i386) stop writing files at 4GB. > > > > > > > > Solaris, with O_LARGEFILE options in the open arguments, does not. > > > > > > > > Does anyone here know what FreeBSD ought to be doing about this? Or > > > > have I missed something? There is no O_LARGEFILE in fcntl.h (it is > > > > present for Solaris, ConvexOS and some other platforms, I believe). I > > > > thought the *BSDs had > 32 bit file support? Or is it only for local > > > > filesystems? > > > > > > FreeBSD has 64-bit file offsets by default, which make -DLARGEFILE > > > hackery unnecessary. > > > > So I thought! > > > > > > > > Make sure you're using NFSv3 mounts (should be the default, but if not, > > > add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, > > > Tru64, and Solaris boxes via NFS and can access large files on all > > > combinations of client and server. > > > > Huh. Interesting. The default showed up as a nfsv3 mount: > > > > 1/25 2:12 mountd/v3: granted 192.67.166.79 to /bob ro=0 uid0=60001 > > > > The solaris mount showed up as: > > > > 1/25 2:06 mountd/v3: granted 192.67.166.155 to /bob ro=0 uid0=60001 > > 1/25 2:06 nfs/tcp accepted 192.67.166.155,1023 > > > > I'll try an explicit v3 mount/tcp and see if it's better. > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 13:27:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id E753A37B69D for ; Thu, 25 Jan 2001 13:27:16 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0PLR8400296; Thu, 25 Jan 2001 13:27:08 -0800 (PST) Date: Thu, 25 Jan 2001 13:27:08 -0800 From: Alfred Perlstein To: Nathan Parrish Cc: mjacob@feral.com, Dan Nelson , current@FreeBSD.ORG, current-users@netbsd.org Subject: Re: > 4GB with NFS? Message-ID: <20010125132708.X26076@fw.wintelcom.net> References: <20010125211443.22025.qmail@web10405.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010125211443.22025.qmail@web10405.mail.yahoo.com>; from ndparrish@yahoo.com on Thu, Jan 25, 2001 at 01:14:43PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Nathan Parrish [010125 13:19] wrote: > knowing NFS in general far better than *BSD in specific, I would guess the best > thing to do (if you suspect server/client communication anomaly) is to grab a > snoop/tcpdump of the failure. I'm trying to think of a clever way to cause the > failure immediately, so you're not tracing 4GB of writes... mebbe dd's > seek/skip? or just append to the existing 4GB file. > > also, what command are you using on the bsd's to write the 4GB file? I've > definitely seen issues with VLF-capable OS's failing to write past 2/4GB due to > VLF-incapable utilities. (on a related note, is there a need for > vlfread()/vlfwrite() in the BSD's, or is VLF support native in the read/write > calls? It has to do with the vm system casting values into 32bit variables, it's been a long time since I looked at this, if I can find it again I might be able to do something about it. To answer your question about VLF (which I had to guess at) assuming you mean Very Large Files: 1) yes some tools break on them, I don't have a list handy. 2) BSD has had native VLF support since 4.4-BSD. (off_t is 64bit) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 13:42:46 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26]) by hub.freebsd.org (Postfix) with ESMTP id 86F4637B6A4 for ; Thu, 25 Jan 2001 13:42:26 -0800 (PST) Received: from curve.dellroad.org (curve.dellroad.org [10.1.1.30]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id NAA61106; Thu, 25 Jan 2001 13:42:24 -0800 (PST) Received: (from archie@localhost) by curve.dellroad.org (8.9.3/8.9.3) id NAA07189; Thu, 25 Jan 2001 13:42:23 -0800 (PST) (envelope-from archie) From: Archie Cobbs Message-Id: <200101252142.NAA07189@curve.dellroad.org> Subject: Re: status of bridge code In-Reply-To: <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> "from Rogier R. Mulhuijzen at Jan 25, 2001 12:19:16 pm" To: "Rogier R. Mulhuijzen" Date: Thu, 25 Jan 2001 13:42:23 -0800 (PST) Cc: Archie Cobbs , Julian Elischer , freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Rogier R. Mulhuijzen writes: > >Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes.. > > I don't see how though. Lets say I link only to left, right and left2right. > Now when data enters left it will go to both right and left2right. When > data enters right it goes to left. But when data enters left2right it goes > to right, not left, where I want it. Think of each tee node as a 2x packet doubler, then hook them up like this: --- o ------------------- \ o------------------ \ o---------------- \ o-------------- \ o------------ \ o---------- \ o-------- I.e., only use "left", "right", and "left2right". -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 14: 9:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 0C36937B400 for ; Thu, 25 Jan 2001 14:09:09 -0800 (PST) Received: from timbuktu-01.budapest.interware.hu ([195.70.51.193] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LuZh-00037P-00; Thu, 25 Jan 2001 23:09:02 +0100 Message-ID: <3A70A3F0.A23A2707@elischer.org> Date: Thu, 25 Jan 2001 14:08:48 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Rogier R. Mulhuijzen" Cc: Archie Cobbs , freebsd-current@FreeBSD.ORG Subject: Re: status of bridge code References: <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Rogier R. Mulhuijzen" wrote: > > At 09:37 25-1-01 -0800, Archie Cobbs wrote: > >Rogier R. Mulhuijzen writes: > > > But from my list of wishes I'd say the first 3 are gone. All that's > > left is > > > spanning tree. I'm probably going to need this pretty soon, so once more > > > I'm asking if anyone is working on it. If not I'll start on it. > > > >Do you have references for how to do this? As I understand it, there > >are special Ethernet addresses that are "for bridges only -- do not > >forward" that are used to construct the spanning tree, etc. What is > >the "standard" algorithm used by bridges, etc.? > > There's a Spanning Tree Protocol (STP) defined by IEEE 802.1D. I'd prefer > to have that, but I don't have the 1K US$ to shell out for that. > Does BSDi have IEEE subscriptions for FreeBSD developers to use? > > Anyway, even without the IEEE standard I have been able to piece together > how the protocol works. > > First of all bridges might have their own MACs that fall into a certain > range, but STP does not depend on that. The "do not forward" is deducted > from the protocol type. There is an ethernet protocol called BPDU (Bridge > Protocol Data Unit) that each bridge sends and receives, but is not > forwarded by any of them. These BDPUs are used to elect root bridge and > determine root ports and designated ports. > > This results in the blocking of redundant ports so that loops are > eliminated. See http://www.knowcisco.com/content/1578700949/pt02ch06.shtml > for a good overview that's pretty in depth. > > About those blocked ports though I have a question. I've been reading > ng_bridge.c and blocking a link in there (a tad more finegrained than right > now) should not be a problem. But it seems to me that with the bridge.ether > example there might be a problem. I'm using my own situation at home as an > example to sketch this out. Please correct me if I'm wrong. > > 1 real NIC connected to LAN with ed0 as interface > 1 tap device ran by vtun with tap0 as interface > 1 tun device connected to cablemodem with tun0 as interface > > I have a netgraph bridge node that has ed0 and tap0 as interfaces, and ed0 > as local interface (as per the example script) > > This means that packets from kernel to LAN go through the bridge node > (thanks to the link from ed0.upper to the bridge) but packets from the > kernel to the tap0 interface don't go through it (no link from tap0.upper > to bridge). This means the bridge node has no idea where the MAC of the > tap0 device is located (not stored in the MAC table of the bridge). So when > packets directed at my tap0 interface enter the bridge (through the link > from tap0.lower to the bridge) the bridge doesn't have a clue where to send > it, and will thus forward to all links. Thus it will go through ed0.upper > and end up in the kernel, no harm done. BUT it will also go out ed0.lower > and end up in my LAN where it doesn't belong. > > Right now I don't mind because the traffic my cablemodem can handle is > 8KB/s max. But it is not desired behaviour of a bridge. > > What I want to know is can I just link tap0.upper to a new bridge hook? It > seems to me that is the case. yes I believe so.. you can hook as many interfaces as you want to the bridge node. (but you probably don't want to BRIDGE to your cable modem, but to ROUTE to it.... ) > > If that's true the example script should be altered because right now it > doesn't support more than one interface. Just say the word and I'll take > care of it. =) > > > > Also, a quick question for you netgraph guys. Why is it that ng_one2many > > > send a packet only out of one hook? I can see use for an algorithm that > > > sends packets from the 'one' hook to all the 'many' hooks (that are up) > > and > > > keep the normal behaviour for many to one. > > > >Hmm.. you could also get that affect using log2(n) ng_tee(4) nodes.. > > I don't see how though. Lets say I link only to left, right and left2right. > Now when data enters left it will go to both right and left2right. When > data enters right it goes to left. But when data enters left2right it goes > to right, not left, where I want it. no, data entering left2right goes to left. (errrr. At least it did when I wrote it.. if not let me know ) > > DocWilco -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 14:18:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0E86F37B402 for ; Thu, 25 Jan 2001 14:18:09 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA23441; Thu, 25 Jan 2001 14:18:02 -0800 Date: Thu, 25 Jan 2001 14:18:01 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Nathan Parrish Cc: Dan Nelson , current@FreeBSD.ORG, current-users@netbsd.org Subject: Re: > 4GB with NFS? In-Reply-To: <20010125211443.22025.qmail@web10405.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > knowing NFS in general far better than *BSD in specific, I would guess the best > thing to do (if you suspect server/client communication anomaly) is to grab a > snoop/tcpdump of the failure. I'm trying to think of a clever way to cause the > failure immediately, so you're not tracing 4GB of writes... mebbe dd's > seek/skip? or just append to the existing 4GB file. > > also, what command are you using on the bsd's to write the 4GB file? I've lmdd or dd... > definitely seen issues with VLF-capable OS's failing to write past 2/4GB due to > VLF-incapable utilities. (on a related note, is there a need for > vlfread()/vlfwrite() in the BSD's, or is VLF support native in the read/write > calls? An update on this.... If the server is Solaris, neither NetBSD nor FreeBSD (i386 or alpha) have a problem (as clients). The problem is therefore in some interaction between this server (see http://www.traakan.com- sorta like a NetApp) and *BSD. Hmm!!! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 14:46:46 2001 Delivered-To: freebsd-current@freebsd.org Received: from hera.drwilco.net (10dyn244.dh.casema.net [212.64.31.244]) by hub.freebsd.org (Postfix) with ESMTP id DCA4B37B401 for ; Thu, 25 Jan 2001 14:46:26 -0800 (PST) Received: from ceres.drwilco.nl (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0PN87G04049; Fri, 26 Jan 2001 00:08:07 +0100 (CET) (envelope-from drwilco@drwilco.nl) Message-Id: <4.3.2.7.0.20010125144426.00c908e0@mail.bsdchicks.com> X-Sender: lists@mail.bsdchicks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Jan 2001 14:47:23 +0100 To: Julian Elischer From: "Rogier R. Mulhuijzen" Subject: Re: status of bridge code Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <3A70A3F0.A23A2707@elischer.org> References: <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > What I want to know is can I just link tap0.upper to a new bridge hook? It > > seems to me that is the case. > >yes I believe so.. >you can hook as many interfaces as you want to the bridge node. >(but you probably don't want to BRIDGE to your cable modem, but to ROUTE >to it.... ) Don't worry =) I do want to bridge to the tunnel that goes over my cable modem though. Make a real VPN there. (And yeah encrypted links) > > I don't see how though. Lets say I link only to left, right and left2right. > > Now when data enters left it will go to both right and left2right. When > > data enters right it goes to left. But when data enters left2right it goes > > to right, not left, where I want it. > >no, data entering left2right goes to left. >(errrr. At least it did when I wrote it.. if not let me know ) From ng_tee(4) Packets may also be received on right2left and left2right; if so, they are forwarded unchanged out hooks left and right, respectively. packets on left2right are delivered on right.... And to be sure I checked ng_tee.c: } else if (hinfo == &sc->left2right) { dup = NULL; dest = &sc->right; } I'll just add the algorithm to ng_tee... DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 14:56:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 2C1E037B404; Thu, 25 Jan 2001 14:56:20 -0800 (PST) Received: from timbuktu-01.budapest.interware.hu ([195.70.51.193] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LvJL-0007My-00; Thu, 25 Jan 2001 23:56:11 +0100 Message-ID: <3A70AEFF.E743986D@elischer.org> Date: Thu, 25 Jan 2001 14:55:59 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: "Rogier R. Mulhuijzen" Cc: freebsd-current@FreeBSD.ORG, Archie@freebsd.org Subject: Re: status of bridge code References: <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> <4.3.2.7.0.20010125144426.00c908e0@mail.bsdchicks.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Rogier R. Mulhuijzen" wrote: > > > > What I want to know is can I just link tap0.upper to a new bridge hook? It > > > seems to me that is the case. > > > >yes I believe so.. > >you can hook as many interfaces as you want to the bridge node. > >(but you probably don't want to BRIDGE to your cable modem, but to ROUTE > >to it.... ) > > Don't worry =) > > I do want to bridge to the tunnel that goes over my cable modem though. > Make a real VPN there. (And yeah encrypted links) > > > > I don't see how though. Lets say I link only to left, right and left2right. > > > Now when data enters left it will go to both right and left2right. When > > > data enters right it goes to left. But when data enters left2right it goes > > > to right, not left, where I want it. > > > >no, data entering left2right goes to left. > >(errrr. At least it did when I wrote it.. if not let me know ) > > From ng_tee(4) > > Packets may also be received on right2left and left2right; if so, they > are forwarded unchanged out hooks left and right, respectively. > > packets on left2right are delivered on right.... > > And to be sure I checked ng_tee.c: > > } else if (hinfo == &sc->left2right) { > dup = NULL; > dest = &sc->right; > } > > I'll just add the algorithm to ng_tee... then I screwed it.. packets from left should go to left2right and packates from left2right should go backk to left.. But we haven't ever used that so it may be in error. > > DocWilco -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 15: 2:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.interware.hu (mail.interware.hu [195.70.32.130]) by hub.freebsd.org (Postfix) with ESMTP id 424A937B699; Thu, 25 Jan 2001 15:01:50 -0800 (PST) Received: from timbuktu-01.budapest.interware.hu ([195.70.51.193] helo=elischer.org) by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian)) id 14LvOZ-0007zv-00; Fri, 26 Jan 2001 00:01:36 +0100 Message-ID: <3A70B045.C4226CE1@elischer.org> Date: Thu, 25 Jan 2001 15:01:25 -0800 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Mike Smith Cc: current@freebsd.org Subject: Re: [loader?] secret to setting root elsewhere?. References: <200101252048.f0PKmZ801414@mass.dis.org> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > Ok so I have tried the settings in > > teh loader conf.. > > I have: > > > > #autoboot_delay="10" # Delay in seconds before autobooting > > #console="vidconsole" # Set the current console > > currdev="disk1s1a" # Set the current device > > module_path="/boot/kernel;/boot/modules" # Set the module search path > > #prompt="\\${interpret}" # Set the command prompt > > root_disk_unit="1" # Force the root disk unit number > > rootdev="disk1s1a" # Set the root filesystem > > > > > > but it still loads disk0 as root.. > > > > what am I doing wrong? > > You don't "load a disk as root". > > If you mean "it loads the kernel from the wrong place", that's one thing. > If you mean "it mounts / from the wrong filesystem", then you should be > aware that the loader reads /etc/fstab, and the kernel will mount > whatever you've put in there. YUUUKKKKKKKK!!!!!!!! I'm specifying a different place because the place where fstab is is SCREWED!!!! but it will let me do what I want. > > root_disk_unit is also deprecated. > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ from Perth, presently in: Budapest v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 15:20:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id D834E37B6DC; Thu, 25 Jan 2001 15:19:49 -0800 (PST) Received: (from uucp@localhost) by ns.internet.dk (8.11.1/8.11.1) with UUCP id f0PNJhg02911; Fri, 26 Jan 2001 00:19:43 +0100 (CET) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.11.1/8.11.0) with SMTP id f0PNJPx22417; Fri, 26 Jan 2001 00:19:27 +0100 (CET) (envelope-from leifn@neland.dk) Message-ID: <010a01c08725$41cf0580$0e00a8c0@neland.dk> Reply-To: "Leif Neland" From: "Leif Neland" To: "Mike Smith" Cc: References: <200101252048.f0PKmZ801414@mass.dis.org> Subject: Re: [loader?] secret to setting root elsewhere?. Date: Fri, 26 Jan 2001 00:19:22 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If you mean "it loads the kernel from the wrong place", that's one thing. > If you mean "it mounts / from the wrong filesystem", then you should be > aware that the loader reads /etc/fstab, and the kernel will mount > whatever you've put in there. > Just curious, but isn't there a checken-and-egg problem here? If there is two complete systems, on each disk. If the root on disc 0 contains an /etc/fstab showing root to be mounted from disk 0, and the root on disk 1 contains an /etc/fstab showing root to be mounted from disk 1? How is it then possible to mount the root on disk 1? Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 15:26:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.org.ru (sweet.etrust.ru [194.84.67.5]) by hub.freebsd.org (Postfix) with ESMTP id D4CDB37B6A6 for ; Thu, 25 Jan 2001 15:26:26 -0800 (PST) Received: by freebsd.org.ru (Postfix, from userid 1000) id 21D47130; Fri, 26 Jan 2001 02:26:24 +0300 (MSK) Date: Fri, 26 Jan 2001 02:26:24 +0300 From: "Sergey A. Osokin" To: freebsd-current@FreeBSD.org Subject: buildworld failed and PERL_THREADED=true dead... Message-ID: <20010126022623.A12403@freebsd.org.ru> Reply-To: osa@FreeBSD.org.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello. I tried make buildworld after cvsuped my source and it failed in perl area. I remove PERL_THREADED=true and tried again and it failed. ===> usr.bin/kdump cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/kdump.c cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/../ktrace/subr.c gzip -cn /usr/src/usr.bin/kdump/kdump.1 > kdump.1.gz cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c ioctl.c In file included from ioctl.c:99: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:81: warning: this is the location of the previous definition In file included from ioctl.c:51: /usr/obj/usr/src/i386/usr/include/machine/i4b_rbch_ioctl.h:45: `TELNO_MAX' undeclared here (not in a function) ioctl.c: In function `ioctlname': ioctl.c:693: invalid use of `restrict' ioctl.c:693: sizeof applied to an incomplete type *** Error code 1 1 error *** Error code 2 FreeBSD 5.0-CURRENT #0: Sat Jan 13 22:57:43 MSK 2001 Any idea? -- Rgdz, /"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN osa@freebsd.org.ru X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 15:36:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from white.imgsrc.co.jp (ns.imgsrc.co.jp [210.226.20.2]) by hub.freebsd.org (Postfix) with ESMTP id 9C47337B404 for ; Thu, 25 Jan 2001 15:36:01 -0800 (PST) Received: from waterblue.imgsrc.co.jp (waterblue.imgsrc.co.jp [210.226.20.160]) by white.imgsrc.co.jp (8.11.2/8.11.0) with ESMTP id f0PNZrj79026; Fri, 26 Jan 2001 08:35:55 +0900 (JST) Date: Fri, 26 Jan 2001 08:35:52 +0900 Message-ID: <7mitn3p5lz.wl@waterblue.imgsrc.co.jp> From: Jun Kuriyama To: Martin Blapp Cc: freebsd-current@FreeBSD.ORG, snap-users@kame.net Subject: Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) In-Reply-To: References: User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 13) (Crater Lake) (i386--freebsd) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 25 Jan 2001 19:08:14 GMT, Martin Blapp wrote: > http://www.attic.ch/rpc.diff_01114001.tgz I cannot fetch it. Gone into attic? :-) -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 15:38: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by hub.freebsd.org (Postfix) with ESMTP id 7377237B404 for ; Thu, 25 Jan 2001 15:37:45 -0800 (PST) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by mail.imp.ch (8.11.1/8.11.1) with ESMTP id f0PNbao56092; Fri, 26 Jan 2001 00:37:36 +0100 (CET) (envelope-from Martin.Blapp@imp.ch) Date: Fri, 26 Jan 2001 00:43:55 +0100 (CET) From: Martin Blapp To: Jun Kuriyama Cc: freebsd-current@FreeBSD.ORG, snap-users@kame.net Subject: Re: TI-RPC, IPv6 and NFS (was: Re: strong recommendation re: NFS) In-Reply-To: <7mitn3p5lz.wl@waterblue.imgsrc.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'll place a new version tomorrow on the server. be patient untill then. Martin Martin Blapp, mb@imp.ch ------------------------------------------------ Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 ------------------------------------------------ On Fri, 26 Jan 2001, Jun Kuriyama wrote: > At 25 Jan 2001 19:08:14 GMT, > Martin Blapp wrote: > > http://www.attic.ch/rpc.diff_01114001.tgz > > I cannot fetch it. Gone into attic? :-) > > > -- > Jun Kuriyama // IMG SRC, Inc. > // FreeBSD Project > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 15:50:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 40DD637B400 for ; Thu, 25 Jan 2001 15:50:09 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0Q05j100604; Thu, 25 Jan 2001 16:05:45 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101260005.f0Q05j100604@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Nathan Parrish Cc: mjacob@feral.com, Dan Nelson , current@FreeBSD.ORG, current-users@netbsd.org Subject: Re: > 4GB with NFS? In-reply-to: Your message of "Thu, 25 Jan 2001 13:14:43 PST." <20010125211443.22025.qmail@web10405.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jan 2001 16:05:45 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > VLF-incapable utilities. (on a related note, is there a need for > vlfread()/vlfwrite() in the BSD's, or is VLF support native in the read/write > calls? The standard off_t is 64 bits in all of the BSDs. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 15:56: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 2F28237B712 for ; Thu, 25 Jan 2001 15:55:39 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0Q0BO100646; Thu, 25 Jan 2001 16:11:24 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101260011.f0Q0BO100646@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Julian Elischer Cc: current@freebsd.org Subject: Re: [loader?] secret to setting root elsewhere?. In-reply-to: Your message of "Thu, 25 Jan 2001 15:01:25 PST." <3A70B045.C4226CE1@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jan 2001 16:11:24 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > #autoboot_delay="10" # Delay in seconds before autobooting > > > #console="vidconsole" # Set the current console > > > currdev="disk1s1a" # Set the current device > > > module_path="/boot/kernel;/boot/modules" # Set the module search path > > > #prompt="\\${interpret}" # Set the command prompt > > > root_disk_unit="1" # Force the root disk unit number > > > rootdev="disk1s1a" # Set the root filesystem > > > > > > > > > but it still loads disk0 as root.. > > > > > > what am I doing wrong? > > > > You don't "load a disk as root". > > > > If you mean "it loads the kernel from the wrong place", that's one thing. > > If you mean "it mounts / from the wrong filesystem", then you should be > > aware that the loader reads /etc/fstab, and the kernel will mount > > whatever you've put in there. > > YUUUKKKKKKKK!!!!!!!! > > I'm specifying a different place because the place where fstab is is SCREWED!!!! Ah, shut yer trap. It reads /etc/fstab from wherever the kernel is loaded from, and if /etc/fstab is hosed/can't be parsed, it'll fall back to trying to guess using the old algorithms. The new behaviour is a functional superset of the old. > but it will let me do what I want. Of course, you don't actually bother to mention what your problem is, so I still can't actually *help* you. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 15:57:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 0D30437B402 for ; Thu, 25 Jan 2001 15:57:05 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0Q0Cl100673; Thu, 25 Jan 2001 16:12:48 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101260012.f0Q0Cl100673@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Leif Neland" Cc: current@FreeBSD.ORG Subject: Re: [loader?] secret to setting root elsewhere?. In-reply-to: Your message of "Fri, 26 Jan 2001 00:19:22 +0100." <010a01c08725$41cf0580$0e00a8c0@neland.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jan 2001 16:12:47 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > If you mean "it loads the kernel from the wrong place", that's one thing. > > If you mean "it mounts / from the wrong filesystem", then you should be > > aware that the loader reads /etc/fstab, and the kernel will mount > > whatever you've put in there. > > > Just curious, but isn't there a checken-and-egg problem here? > > If there is two complete systems, on each disk. If the root on disc 0 > contains an /etc/fstab showing root to be mounted from disk 0, and the root > on disk 1 contains an /etc/fstab showing root to be mounted from disk 1? > > How is it then possible to mount the root on disk 1? By loading a kernel from disk 1, or subsequent to loading the kernel, change $rootdev to point somewhere else. Please don't assume I'm *entirely* stupid. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 18:33: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail-ob.kamp.net (mail-ob.kamp.net [195.62.97.26]) by hub.freebsd.org (Postfix) with ESMTP id BB15A37B400 for ; Thu, 25 Jan 2001 18:32:49 -0800 (PST) Received: from bsdevil.meta.net.ob.kamp.net (port-10.d.kamp.de [195.62.120.202]) by mail-ob.kamp.net (8.10.1/8.10.1) with ESMTP id f0Q2WOD03328 for ; Fri, 26 Jan 2001 03:32:42 +0100 Date: Fri, 26 Jan 2001 03:32:26 +0100 Message-Id: <200101260232.f0Q2WOD03328@mail-ob.kamp.net> From: Farid Hajji To: freebsd-current@freebsd.org Subject: buildworld failed with sysinstall X-Mailer: Emacs-20.6.1/FreeBSD-5.0-CURRENT Reply-To: farid.hajji@ob.kamp.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, 'make buildworld' failed while trying to comple sysinstall: cc -O -pipe -Wall -I/usr/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/sysinstall/keymap.c In file included from /usr/src/usr.sbin/sysinstall/keymap.c:40: keymap.h:3239: `keymap_us_pc_ctrl' undeclared here (not in a function) keymap.h:3239: initializer element is not constant keymap.h:3239: (near initialization for `keymapInfos[23].map') *** Error code 1 Stop in /usr/src/usr.sbin/sysinstall. *** Error code 1 cvsupped -CURRENT, 2001-01-25:1811 trying to update an old -CURRENT-20000506 source tree. Any ideas? -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji@ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 21: 3: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from RedDust.bluesky.net.au (CPE-61-9-140-158.vic.bigpond.net.au [61.9.140.158]) by hub.freebsd.org (Postfix) with ESMTP id 2815637B400 for ; Thu, 25 Jan 2001 21:02:47 -0800 (PST) Received: from localhost (receiver@localhost) by RedDust.bluesky.net.au (8.11.1/8.11.0) with ESMTP id f0Q4xkH05127 for ; Fri, 26 Jan 2001 14:59:47 +1000 (EST) (envelope-from receiver@blueskybbs.yi.org) Date: Fri, 26 Jan 2001 14:59:45 +1000 (EST) From: Idea Receiver To: freebsd-current@FreeBSD.ORG Subject: about ppp.. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One of my current machines here are running PPPoE.. for some reason, it will some times become extramly lag of its PPPoE connection. (for example, from 25ns ping time become 2500ns ping time). And will back to normal in few mins.. However, i do not see the same problem on my 4.2 stable system. is this a known problem or just me? plz help! thx.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 22:12:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from gratis.grondar.za (grouter.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 363D837B69B for ; Thu, 25 Jan 2001 22:12:33 -0800 (PST) Received: from grondar.za (root@gratis.grondar.za [196.7.18.133]) by gratis.grondar.za (8.11.1/8.11.1) with ESMTP id f0Q6CAW05083; Fri, 26 Jan 2001 08:12:16 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <200101260612.f0Q6CAW05083@gratis.grondar.za> To: osa@freebsd.org.ru Cc: freebsd-current@FreeBSD.ORG Subject: Re: buildworld failed and PERL_THREADED=true dead... References: <20010126022623.A12403@freebsd.org.ru> In-Reply-To: <20010126022623.A12403@freebsd.org.ru> ; from "Sergey A. Osokin" "Fri, 26 Jan 2001 02:26:24 +0300." Date: Fri, 26 Jan 2001 08:12:22 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi I see no perl failure below... M > Hello. > I tried make buildworld after cvsuped my source and it failed in perl > area. > I remove PERL_THREADED=true and tried again and it failed. > > ===> usr.bin/kdump > cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/kdump.c > cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/../ktrace/subr.c > gzip -cn /usr/src/usr.bin/kdump/kdump.1 > kdump.1.gz > cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c ioctl.c > In file included from ioctl.c:99: > /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined > /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:81: warning: this is the location of the previous definition > In file included from ioctl.c:51: > /usr/obj/usr/src/i386/usr/include/machine/i4b_rbch_ioctl.h:45: `TELNO_MAX' undeclared here (not in a function) > ioctl.c: In function `ioctlname': > ioctl.c:693: invalid use of `restrict' > ioctl.c:693: sizeof applied to an incomplete type > *** Error code 1 > 1 error > *** Error code 2 > > FreeBSD 5.0-CURRENT #0: Sat Jan 13 22:57:43 MSK 2001 > > Any idea? > -- > > Rgdz, /"\ > Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN > osa@freebsd.org.ru X AGAINST HTML MAIL > http://freebsd.org.ru/~osa/ / \ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jan 25 23:24: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D93A737B400 for ; Thu, 25 Jan 2001 23:23:49 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0Q7HZ323663; Thu, 25 Jan 2001 23:17:35 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <13738.980149775@critter> Date: Thu, 25 Jan 2001 23:21:38 -0800 (PST) From: John Baldwin To: Poul-Henning Kamp Subject: Re: VN bug or pilot error ? Cc: current@FreeBSD.org, John Hay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Jan-01 Poul-Henning Kamp wrote: > In message <200101220737.f0M7bjr98421@zibbi.icomtek.csir.co.za>, John Hay > write > s: >>> >>> But while you're at it, migrate to md(4) instead of vn(4), it does >>> vn(4) will be deprecated RSN. mdconfig(8) configures the md(4) devices >>> >> >>So why not change the release process to use md instead of vn, so that >>we can make sure it works before vn is axed? > > I will do, as soon as I have time... If you work up a patch, I can test it in about 4-6 hours time.. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 0:33:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from inferno.risc.fr (unknown [193.106.194.131]) by hub.freebsd.org (Postfix) with ESMTP id 0EA4637B400 for ; Fri, 26 Jan 2001 00:32:59 -0800 (PST) Received: from tornado.risc.fr (tornado.risc.fr) by inferno.risc.fr (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Fri, 26 Jan 2001 09:33:26 +0100 Received: from callisto.risc.fr ([192.168.1.55]) by tornado.risc.fr (Netscape Messaging Server 4.1) with ESMTP id G7RJIJ00.91V for ; Fri, 26 Jan 2001 09:25:31 +0000 Received: (from joseph@localhost) by callisto.risc.fr (8.11.2/8.9.3) id f0Q8X5A43956; Fri, 26 Jan 2001 09:33:05 +0100 (CET) (envelope-from joseph) From: Joseph Fernando MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14961.13888.574599.152573@callisto.risc.fr> Date: Fri, 26 Jan 2001 09:33:04 +0100 To: current@FreeBSD.org Subject: Suscribe X-Mailer: VM 6.76 under 21.2 (beta35) "Nike" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG suscribe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 1:28:46 2001 Delivered-To: freebsd-current@freebsd.org Received: from webcom.it (brian.inet.it [213.92.4.195]) by hub.freebsd.org (Postfix) with SMTP id 7FAF737B402 for ; Fri, 26 Jan 2001 01:28:24 -0800 (PST) Received: (qmail 2903 invoked by uid 1000); 26 Jan 2001 09:21:56 -0000 Date: Fri, 26 Jan 2001 10:21:56 +0100 From: Andrea Campi To: "Rogier R. Mulhuijzen" Cc: Archie Cobbs , Julian Elischer , freebsd-current@FreeBSD.ORG Subject: Re: status of bridge code Message-ID: <20010126102156.A572@webcom.it> References: <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> <200101251737.JAA06204@curve.dellroad.org> <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com>; from drwilco@drwilco.nl on Thu, Jan 25, 2001 at 12:19:16PM +0100 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 25, 2001 at 12:19:16PM +0100, Rogier R. Mulhuijzen wrote: > At 09:37 25-1-01 -0800, Archie Cobbs wrote: > >Rogier R. Mulhuijzen writes: > > > But from my list of wishes I'd say the first 3 are gone. All that's > > left is > > > spanning tree. I'm probably going to need this pretty soon, so once more > > > I'm asking if anyone is working on it. If not I'll start on it. > > > >Do you have references for how to do this? As I understand it, there > >are special Ethernet addresses that are "for bridges only -- do not > >forward" that are used to construct the spanning tree, etc. What is > >the "standard" algorithm used by bridges, etc.? > > There's a Spanning Tree Protocol (STP) defined by IEEE 802.1D. I'd prefer > to have that, but I don't have the 1K US$ to shell out for that. > Does BSDi have IEEE subscriptions for FreeBSD developers to use? Please also consider implementing 802.1G, which is for bridging over PPP (BCP I think?). I think a lot of us remember the times when remote bridging was more common than routing ;-) > First of all bridges might have their own MACs that fall into a certain > range, but STP does not depend on that. The "do not forward" is deducted > from the protocol type. There is an ethernet protocol called BPDU (Bridge > Protocol Data Unit) that each bridge sends and receives, but is not > forwarded by any of them. These BDPUs are used to elect root bridge and > determine root ports and designated ports. > > This results in the blocking of redundant ports so that loops are > eliminated. See http://www.knowcisco.com/content/1578700949/pt02ch06.shtml > for a good overview that's pretty in depth. Any Cisco documentation will go into depth explaining the tradeoffs in deciding the timing for the various state (STP is, in the end, a state automaton) depending on the exact topology. You should be careful when deciding defaults, and you should implement a way to adjust them. Also, FreeBSD has support for 802.1q VLAN tagging. Having 802.1q trunks in your network means you (usually) have more than 1 instance of STP. Furthermore, this means that even if you don't care about 802.1q, you should be prepared to receive BPDU-like backets which are NOT part of the 802.1d exchange (unless my mind is playing tricks on me, that is). Of course you can choose not to handle all of this but then the implementation would be less useful in the real world. Having said that, while I am not able to help in writing code (no time to learn netgraph, sorry), I will be more than happy to test it, having a home network comprising a -current box with 4 ethernet ports and 3 or 4 differents brands / models of hubs/switches. Bye, Andrea -- There's no place like ~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 2:13:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from rfi.fmrp.usp.br (unknown [143.107.198.161]) by hub.freebsd.org (Postfix) with ESMTP id A5B9237B400 for ; Fri, 26 Jan 2001 02:13:31 -0800 (PST) Received: from rfi.fmrp.usp.br (elfis.fmrp.usp.br [143.107.198.145]) by rfi.fmrp.usp.br (8.11.1/8.11.1) with ESMTP id f0QA8V114039 for ; Fri, 26 Jan 2001 08:08:33 -0200 (EDT) (envelope-from cloferra@rfi.fmrp.usp.br) Message-ID: <3A714E1D.E7F7CD11@rfi.fmrp.usp.br> Date: Fri, 26 Jan 2001 08:14:53 -0200 From: "C.F" X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG subscrive cloferra@rfi.fmrp.usp.br To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 3:22:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from hera.drwilco.net (10dyn244.dh.casema.net [212.64.31.244]) by hub.freebsd.org (Postfix) with ESMTP id 4AE0D37B402 for ; Fri, 26 Jan 2001 03:22:12 -0800 (PST) Received: from ceres.drwilco.net (ceres.drwilco.net [10.1.1.19]) by hera.drwilco.net (8.11.1/8.11.1) with ESMTP id f0QBd1G20060; Fri, 26 Jan 2001 12:39:02 +0100 (CET) (envelope-from drwilco@drwilco.net) Message-Id: <4.3.2.7.0.20010126120515.00affc80@mail.drwilco.net> X-Sender: drwilco@mail.drwilco.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Jan 2001 12:18:09 +0100 To: Andrea Campi From: "Rogier R. Mulhuijzen" Subject: Re: status of bridge code Cc: freebsd-current@FreeBSD.ORG In-Reply-To: <20010126102156.A572@webcom.it> References: <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> <200101251737.JAA06204@curve.dellroad.org> <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > There's a Spanning Tree Protocol (STP) defined by IEEE 802.1D. I'd prefer > > to have that, but I don't have the 1K US$ to shell out for that. > > Does BSDi have IEEE subscriptions for FreeBSD developers to use? > >Please also consider implementing 802.1G, which is for bridging over PPP >(BCP I think?). I think a lot of us remember the times when remote bridging >was more common than routing ;-) I'd be happy to (I like a challenge) but I still require access to the standards for that. So my question still stands, does BSDi have IEEE subscriptions for FreeBSD developers to use, or are there any other ways for me to aquire (legally of course) the standards I need without having to shell out the 1K US$ myself. > > This results in the blocking of redundant ports so that loops are > > eliminated. See http://www.knowcisco.com/content/1578700949/pt02ch06.shtml > > for a good overview that's pretty in depth. > >Any Cisco documentation will go into depth explaining the tradeoffs in >deciding the timing for the various state (STP is, in the end, a state >automaton) depending on the exact topology. You should be careful when >deciding defaults, and you should implement a way to adjust them. I'd probably go for the Cisco defaults. And there are lots of netgraph nodes with settings you can change. So I'd consider being able to change the values pretty much a given. =) >Also, FreeBSD has support for 802.1q VLAN tagging. Having 802.1q trunks in >your network means you (usually) have more than 1 instance of STP. >Furthermore, >this means that even if you don't care about 802.1q, you should be prepared to >receive BPDU-like backets which are NOT part of the 802.1d exchange (unless my >mind is playing tricks on me, that is). Of course you can choose not to handle >all of this but then the implementation would be less useful in the real >world. Duly noted. I recall reading that 802.1Q extends the 802.1D standardble to understand VLANs, but that most implementations still use a single STP instance. Cisco of course uses multiple instances (did I read this on a Cisco related site? noooo =) ). >Having said that, while I am not able to help in writing code (no time to >learn netgraph, sorry), I will be more than happy to test it, having a >home network comprising a -current box with 4 ethernet ports and 3 or 4 >differents brands / models of hubs/switches. I'll drop you a line when the time comes. DocWilco To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 4: 7:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from webcom.it (brian.inet.it [213.92.4.195]) by hub.freebsd.org (Postfix) with SMTP id D798D37B698 for ; Fri, 26 Jan 2001 04:07:07 -0800 (PST) Received: (qmail 5030 invoked by uid 1000); 26 Jan 2001 12:00:51 -0000 Date: Fri, 26 Jan 2001 13:00:50 +0100 From: Andrea Campi To: "Rogier R. Mulhuijzen" Cc: freebsd-current@FreeBSD.ORG Subject: Re: status of bridge code Message-ID: <20010126130049.C572@webcom.it> References: <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> <4.3.2.7.0.20010125000221.00b07d60@mail.bsdchicks.com> <200101251737.JAA06204@curve.dellroad.org> <4.3.2.7.0.20010125101911.00c84220@mail.bsdchicks.com> <20010126102156.A572@webcom.it> <4.3.2.7.0.20010126120515.00affc80@mail.drwilco.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.0.20010126120515.00affc80@mail.drwilco.net>; from drwilco@drwilco.net on Fri, Jan 26, 2001 at 12:18:09PM +0100 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'd be happy to (I like a challenge) but I still require access to the > standards for that. So my question still stands, does BSDi have IEEE > subscriptions for FreeBSD developers to use, or are there any other ways > for me to aquire (legally of course) the standards I need without having to > shell out the 1K US$ myself. You can probably find good sources of informations around on the net. Cisco comes immediately to my mind, 3Com and redbooks.com are also very likely to have. I'd also check ethereal sources, where packet-bpdu.c includes most of what you need to start interpreting packets you receive, and send new ones (well, you also need llcsaps.h and oui.h). Speaking of 802.1G (BCP) you should look at RFC2878... wait, checking on that again, I just found out that this is THE document for bridging, so start from that ;-) Also, RFC 1638 documents the old STP protocol. Even though I could find nothing more in RFCs, a quick tcpdump confirmed that most STP involves broadcasts to 01-80-c2-00-00-00. > I'd probably go for the Cisco defaults. And there are lots of netgraph > nodes with settings you can change. So I'd consider being able to change > the values pretty much a given. =) Ok. As I said, I know quite well bridging from my Cisco certifications days, but no experience with netgraph ;-) > > Duly noted. I recall reading that 802.1Q extends the 802.1D standardble to > understand VLANs, but that most implementations still use a single STP > instance. Cisco of course uses multiple instances (did I read this on a > Cisco related site? noooo =) ). Yes, implementation dependant. > > >Having said that, while I am not able to help in writing code (no time to > >learn netgraph, sorry), I will be more than happy to test it, having a > >home network comprising a -current box with 4 ethernet ports and 3 or 4 > >differents brands / models of hubs/switches. > > I'll drop you a line when the time comes. Ok. Please keep me updated. Bye, Andrea -- 0 and 1. Now what could be so hard about that? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 7:42:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from quack.kfu.com (quack.kfu.com [205.178.90.194]) by hub.freebsd.org (Postfix) with ESMTP id D392037B400 for ; Fri, 26 Jan 2001 07:42:22 -0800 (PST) Received: from medusa.kfu.com (medusa.kfu.com [205.178.90.222]) by quack.kfu.com (8.11.1/8.11.1) with ESMTP id f0QFgM702818 for ; Fri, 26 Jan 2001 07:42:22 -0800 (PST) (envelope-from nsayer@medusa.kfu.com) Received: from icarus.kfu.com (ssmail@localhost) by medusa.kfu.com (8.11.1/8.11.0) with ESMTP id f0QFgMJ39506 for ; Fri, 26 Jan 2001 07:42:22 -0800 (PST) (envelope-from nsayer@medusa.kfu.com) From: Nick Sayer Received: by icarus.kfu.com (8.11.1//ident-1.0) id f0QFgLd57401; Fri, 26 Jan 2001 07:42:21 -0800 (PST) Date: Fri, 26 Jan 2001 07:42:21 -0800 (PST) Message-Id: <200101261542.f0QFgLd57401@icarus.kfu.com> To: freebsd-current@freebsd.org Subject: buildworld fails Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -------------------------------------------------------------- >>> stage 4: populating /usr/obj/usr/src/i386/usr/include -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks includes cd /usr/src/include; make -B all install creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh; echo "$COPYRIGHT" > osreldate.h; echo \#'undef __FreeBSD_version' >> osreldate.h; echo \#'define __FreeBSD_version' $RELDATE >> osreldate.h ===> rpcsvc rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h rpcgen: cannot find any C preprocessor (cpp) *** Error code 1 Stop in /usr/src/include/rpcsvc. *** Error code 1 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 7:46:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from gypsy.vrac.iastate.edu (gypsy.vrac.iastate.edu [129.186.232.122]) by hub.freebsd.org (Postfix) with ESMTP id 4EC2737B400 for ; Fri, 26 Jan 2001 07:46:42 -0800 (PST) Received: from tomservo.vrac.iastate.edu (tomservo.vrac.iastate.edu [129.186.232.121]) by gypsy.vrac.iastate.edu (Postfix) with ESMTP id A3BB719; Fri, 26 Jan 2001 09:46:42 -0600 (CST) Received: from tomservo.vrac.iastate.edu (localhost [127.0.0.1]) by tomservo.vrac.iastate.edu (Postfix) with ESMTP id BB87A5D34; Fri, 26 Jan 2001 09:46:40 -0600 (CST) To: Nick Sayer Cc: freebsd-current@freebsd.org Subject: Re: buildworld fails In-reply-to: "Fri, 26 Jan 2001 07:42:21 PST." <200101261542.f0QFgLd57401@icarus.kfu.com> Date: Fri, 26 Jan 2001 09:46:40 -0600 From: Patrick Hartling Message-Id: <20010126154640.BB87A5D34@tomservo.vrac.iastate.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Sayer wrote: } -------------------------------------------------------------- } >>> stage 4: populating /usr/obj/usr/src/i386/usr/include } -------------------------------------------------------------- [snip] } ===> rpcsvc } rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h } rpcgen: cannot find any C preprocessor (cpp) I have seen exactly this and reported it a week ago. No one seemed to have noticed though. :\ -Patrick Patrick L. Hartling | Research Assistant, VRAC patrick@137.org | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 7:51:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from veldy.net (w028.z064001117.msp-mn.dsl.cnc.net [64.1.117.28]) by hub.freebsd.org (Postfix) with ESMTP id 0936F37B400 for ; Fri, 26 Jan 2001 07:51:12 -0800 (PST) Received: from HP2500B (veldy.net [64.1.117.28]) by veldy.net (Postfix) with SMTP id CC8738C66; Fri, 26 Jan 2001 09:50:31 -0600 (CST) Message-ID: <010901c087af$6c1f21a0$3028680a@tgt.com> From: "Thomas T. Veldhouse" To: "Nick Sayer" , "FreeBSD-Current, " References: <200101261542.f0QFgLd57401@icarus.kfu.com> Subject: Re: buildworld fails Date: Fri, 26 Jan 2001 09:48:17 -0600 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This has been happening for sometime. It seems to happen when you upgrade a recent 5.0-SNAPSHOT (not a 4-STABLE install). I believe that David O'Brien is aware of this. He was working on it - I wonder if it slipped away :) Tom Veldhouse veldy@veldy.net ----- Original Message ----- From: "Nick Sayer" To: Sent: Friday, January 26, 2001 9:42 AM Subject: buildworld fails > -------------------------------------------------------------- > >>> stage 4: populating /usr/obj/usr/src/i386/usr/include > -------------------------------------------------------------- > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bi n LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/u sr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks includes > cd /usr/src/include; make -B all install > creating osreldate.h from newvers.sh > setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh; echo "$COPYRIGHT" > osreldate.h; echo \#'undef __FreeBSD_version' >> osreldate.h; echo \#'define __FreeBSD_version' $RELDATE >> osreldate.h > ===> rpcsvc > rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > rpcgen: cannot find any C preprocessor (cpp) > *** Error code 1 > > Stop in /usr/src/include/rpcsvc. > *** Error code 1 > > Stop in /usr/src/include. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 8:11:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 11BFA37B400 for ; Fri, 26 Jan 2001 08:10:55 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id f0QG9Jr46359; Fri, 26 Jan 2001 18:09:19 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200101261609.f0QG9Jr46359@zibbi.icomtek.csir.co.za> Subject: Re: buildworld fails In-Reply-To: <20010126154640.BB87A5D34@tomservo.vrac.iastate.edu> from Patrick Hartling at "Jan 26, 2001 09:46:40 am" To: patrick@137.org (Patrick Hartling) Date: Fri, 26 Jan 2001 18:09:19 +0200 (SAT) Cc: nsayer@quack.kfu.com (Nick Sayer), freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > } -------------------------------------------------------------- > } >>> stage 4: populating /usr/obj/usr/src/i386/usr/include > } -------------------------------------------------------------- > > [snip] > > } ===> rpcsvc > } rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > } rpcgen: cannot find any C preprocessor (cpp) > > I have seen exactly this and reported it a week ago. No one seemed to have > noticed though. :\ > If you have current source, just recompile rpcgen and try again. Something like: cd /usr/src/usr.bin/rpcgen make all install clean should do it. Then you can return to your regular make world. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 11:31: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17]) by hub.freebsd.org (Postfix) with ESMTP id 3627837B402 for ; Fri, 26 Jan 2001 11:30:43 -0800 (PST) Received: from beast.talarian.com (beast.talarian.com [10.4.10.6] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with ESMTP id LAA03336; Fri, 26 Jan 2001 11:30:47 -0800 (PST) Received: from quack.kfu.com (localhost [127.0.0.1]) by beast.talarian.com (8.11.1/8.11.1) with ESMTP id f0QJUKR43296; Fri, 26 Jan 2001 11:30:28 -0800 (PST) (envelope-from nsayer@quack.kfu.com) Message-ID: <3A71D04C.7080706@quack.kfu.com> Date: Fri, 26 Jan 2001 11:30:20 -0800 From: Nick Sayer User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.2-RELEASE i386; en-US; 0.7) Gecko/20010123 X-Accept-Language: en MIME-Version: 1.0 To: John Hay Cc: Patrick Hartling , freebsd-current@FreeBSD.ORG Subject: Re: buildworld fails References: <200101261609.f0QG9Jr46359@zibbi.icomtek.csir.co.za> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Hay wrote: > > If you have current source, just recompile rpcgen and try again. Something > like: > > cd /usr/src/usr.bin/rpcgen > make all install clean > > should do it. Then you can return to your regular make world. > > John That did end up working. Thanks. I just wanted to mention it publicly, since I didn't see a mention of it in the list archives. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 12:50:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id ACA9137B401; Fri, 26 Jan 2001 12:50:37 -0800 (PST) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f0QKobq31173; Fri, 26 Jan 2001 12:50:37 -0800 Date: Fri, 26 Jan 2001 12:50:37 -0800 From: Brooks Davis To: freebsd-current@freebsd.org Cc: msmith@freebsd.org Subject: PCI changes break HP Docking Station Message-ID: <20010126125037.B28316@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I plugged my HP Omnibook 4150 into my dock for the first time in a couple months only to discover that I couldn't attach any of the PCI devices in it. I'm running -current as of sometime in the last week or so. I traced the problem to the new PCI code comitted six weeks ago. Specificaly: - Make the PCI-PCI bridge code a little more paranoid about valid I/O and memory decodes. It looks like the new code is too paranoid. The following patch lets me attach devices in the dock though it's obviously bogus. You can find a kernel config, verbose dmesg output, pciconf -l -v output, and acpidump output at: http://www.one-eyed-alien.net/~brooks/FreeBSD/dock/ Please let me know if you need anything more from me to help debug this. Thanks, Brooks -- Any statement of the form "X is the one, true Y" is FALSE. Index: pci_pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v retrieving revision 1.3 diff -u -r1.3 pci_pci.c --- pci_pci.c 2000/12/13 01:25:11 1.3 +++ pci_pci.c 2001/01/26 19:56:40 @@ -283,10 +283,10 @@ case SYS_RES_IOPORT: if ((start < sc->iobase) || (end > sc->iolimit)) { device_printf(dev, "device %s%d requested unsupported I/O range 0x%lx-0x%lx" - " (decoding 0x%x-0x%x)\n", + " (decoding 0x%x-0x%x) IGNORED\n", device_get_name(child), device_get_unit(child), start, end, sc->iobase, sc->iolimit); - return(NULL); + /* return(NULL); */ } if (bootverbose) device_printf(sc->dev, "device %s%d requested decoded I/O range 0x%lx-0x%lx\n", @@ -303,10 +303,10 @@ if (((start < sc->membase) || (end > sc->memlimit)) && ((start < sc->pmembase) || (end > sc->pmemlimit))) { device_printf(dev, "device %s%d requested unsupported memory range 0x%lx-0x%lx" - " (decoding 0x%x-0x%x, 0x%x-0x%x)\n", + " (decoding 0x%x-0x%x, 0x%x-0x%x) IGNORED\n", device_get_name(child), device_get_unit(child), start, end, sc->membase, sc->memlimit, sc->pmembase, sc->pmemlimit); - return(NULL); + /* return(NULL); */ } if (bootverbose) device_printf(sc->dev, "device %s%d requested decoded memory range 0x%lx-0x%lx\n", To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 13: 9:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp.wanadoo.nl (smtp.wanadoo.nl [194.134.193.6]) by hub.freebsd.org (Postfix) with ESMTP id E35A737B401 for ; Fri, 26 Jan 2001 13:08:52 -0800 (PST) Received: from ams-gw.sohara.org (p610.vcu.wanadoo.nl [194.134.201.138]) by smtp.wanadoo.nl (8.9.3/8.9.3) with SMTP id WAA13846 for ; Fri, 26 Jan 2001 22:08:37 +0100 (MET) Date: Fri, 26 Jan 2001 22:08:20 +0100 From: "Steve O'Hara-Smith" To: current@freebsd.org Subject: patch for test: /etc/shells -> /usr/local/etc/shells Message-Id: <20010126220820.2fa3265a.steveo@eircom.net> X-Mailer: Sylpheed version 0.4.9 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Following some recent comments on the evil ways of ports have of writing in /etc on install - The patch below (against 4-stable but it will probably apply easily to -current) moves /etc/shells to /usr/local/etc/shells. It should include the removal of /usr/src/etc/shells but "cvs diff -N -u ..." did not do what I exepected :( After installworld you will have to move /etc/shells to /usr/local/etc by hand or only the default shells will be known. To follow (if this is not flamed to death), bsd.ports.mk patch to automate maintenance of /usr/local/etc/shells during port install, and (of course) documentation patches (I have a grep). I am running on this and it works as expected with and without /usr/local/etc/shells installed and with /etc/shells removed. It needs more hammering than I can give it to be sure it is safe in all conditions hence this mail. Index: include/paths.h =================================================================== RCS file: /home/ncvs/src/include/paths.h,v retrieving revision 1.9.6.1 diff -u -r1.9.6.1 paths.h --- include/paths.h 2000/12/11 01:03:16 1.9.6.1 +++ include/paths.h 2001/01/26 07:00:24 @@ -60,7 +60,7 @@ #define _PATH_MEM "/dev/mem" #define _PATH_NOLOGIN "/var/run/nologin" #define _PATH_SENDMAIL "/usr/sbin/sendmail" -#define _PATH_SHELLS "/etc/shells" +#define _PATH_SHELLS "/usr/local/etc/shells" #define _PATH_TTY "/dev/tty" #define _PATH_UNIX "don't use _PATH_UNIX" #define _PATH_VI "/usr/bin/vi" Index: etc/Makefile =================================================================== RCS file: /home/ncvs/src/etc/Makefile,v retrieving revision 1.219.2.9 diff -u -r1.219.2.9 Makefile --- etc/Makefile 2000/11/01 07:21:45 1.219.2.9 +++ etc/Makefile 2001/01/26 07:04:28 @@ -13,7 +13,7 @@ printcap profile protocols \ rc rc.atm rc.devfs rc.diskless1 rc.diskless2 rc.firewall rc.firewall6 \ rc.isdn rc.network rc.network6 rc.pccard rc.serial rc.shutdown \ - rc.sysctl remote rpc security services shells syslog.conf usbd.conf \ + rc.sysctl remote rpc security services syslog.conf usbd.conf \ etc.${MACHINE_ARCH}/disktab \ etc.${MACHINE_ARCH}/rc.${MACHINE_ARCH} \ etc.${MACHINE_ARCH}/ttys \ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 13:21:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id F1CCB37B698 for ; Fri, 26 Jan 2001 13:21:12 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id QAA02884; Fri, 26 Jan 2001 16:21:01 -0500 (EST) (envelope-from wollman) Date: Fri, 26 Jan 2001 16:21:01 -0500 (EST) From: Garrett Wollman Message-Id: <200101262121.QAA02884@khavrinen.lcs.mit.edu> To: "Steve O'Hara-Smith" Cc: current@FreeBSD.ORG Subject: patch for test: /etc/shells -> /usr/local/etc/shells In-Reply-To: <20010126220820.2fa3265a.steveo@eircom.net> References: <20010126220820.2fa3265a.steveo@eircom.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > The patch below (against 4-stable but it will probably apply easily > to -current) moves /etc/shells to /usr/local/etc/shells. Bad idea. No base component (never mind libc!) should hard-code a pathname in /usr/local. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 13:34:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp.wanadoo.nl (smtp.wanadoo.nl [194.134.193.6]) by hub.freebsd.org (Postfix) with ESMTP id 44E4237B401 for ; Fri, 26 Jan 2001 13:34:22 -0800 (PST) Received: from ams-gw.sohara.org (p240.vcu.wanadoo.nl [194.134.200.168]) by smtp.wanadoo.nl (8.9.3/8.9.3) with SMTP id WAA18199; Fri, 26 Jan 2001 22:34:15 +0100 (MET) Date: Fri, 26 Jan 2001 22:34:12 +0100 From: "Steve O'Hara-Smith" To: Garrett Wollman Cc: current@FreeBSD.ORG Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells Message-Id: <20010126223412.7eba6913.steveo@eircom.net> In-Reply-To: <200101262121.QAA02884@khavrinen.lcs.mit.edu> References: <20010126220820.2fa3265a.steveo@eircom.net> <200101262121.QAA02884@khavrinen.lcs.mit.edu> X-Mailer: Sylpheed version 0.4.9 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 26 Jan 2001 16:21:01 -0500 (EST) Garrett Wollman wrote: GW> < said: GW> GW> > The patch below (against 4-stable but it will probably apply easily GW> > to -current) moves /etc/shells to /usr/local/etc/shells. GW> GW> Bad idea. No base component (never mind libc!) should hard-code a GW> pathname in /usr/local. I'll consider it flamed to death then :) It was intended to prevent port installs having to write in /etc without having to change libc/gen, roken and sendmail which I rather suspect is also a bad thing to do. Perhaps /etc/shells is the least of all evils here. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 13:43:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id E27DE37B400 for ; Fri, 26 Jan 2001 13:42:54 -0800 (PST) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.1/8.11.0) with ESMTP id f0QLgaO69945; Fri, 26 Jan 2001 16:42:36 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200101262142.f0QLgaO69945@whizzo.transsys.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Steve O'Hara-Smith" Cc: Garrett Wollman , current@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells References: <20010126220820.2fa3265a.steveo@eircom.net> <200101262121.QAA02884@khavrinen.lcs.mit.edu> <20010126223412.7eba6913.steveo@eircom.net> In-reply-to: Your message of "Fri, 26 Jan 2001 22:34:12 +0100." <20010126223412.7eba6913.steveo@eircom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Jan 2001 16:42:36 -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Perhaps /etc/shells is the least of all evils here. I think there's way too much paranoia about software systems putting stuff into /etc. It intended to contain host-specific configuration data I think there's value in having this configuration data in one or very few places so you're not chasing stuff all over the file system. I think that /etc/X11 which came along with the XFree86 4 port is a step in the right direction, too. Frankly, I'd rather have an /etc/local than /usr/local/etc for that sort configuration data so that it's in one place, and backed up along with the rest of the hosts's configuration. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 13:49:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id B4AE437B400 for ; Fri, 26 Jan 2001 13:49:09 -0800 (PST) Received: (qmail 59824 invoked by uid 100); 26 Jan 2001 21:49:08 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14961.61652.841205.31224@guru.mired.org> Date: Fri, 26 Jan 2001 15:49:08 -0600 (CST) To: "Louis A. Mamakos" Cc: "Steve O'Hara-Smith" , Garrett Wollman , current@FreeBSD.ORG Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells In-Reply-To: <200101262142.f0QLgaO69945@whizzo.transsys.com> References: <20010126220820.2fa3265a.steveo@eircom.net> <200101262121.QAA02884@khavrinen.lcs.mit.edu> <20010126223412.7eba6913.steveo@eircom.net> <200101262142.f0QLgaO69945@whizzo.transsys.com> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Louis A. Mamakos types: > I think that /etc/X11 which came along with the XFree86 4 port is a > step in the right direction, too. Frankly, I'd rather have an /etc/local > than /usr/local/etc for that sort configuration data so that it's in > one place, and backed up along with the rest of the hosts's configuration. Other things seem to be moving in the direction of putting default values (that are updated with the system) in /etc/defaults, and local changes in /etc. That would suggest /etc/defaults/shells for the shells installed as part of the base system, and /etc/shells for shells added later, whether from ports or elsewhere. And I want the shed crimson with cream trim. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 13:54:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from antioche.lip6.fr (antioche.lip6.fr [132.227.74.11]) by hub.freebsd.org (Postfix) with ESMTP id 58C6937B400 for ; Fri, 26 Jan 2001 13:54:16 -0800 (PST) Received: from rochebonne.antioche.eu.org (rochebonne.lip6.fr [132.227.74.12]) by antioche.lip6.fr (8.11.0/8.10.1) with ESMTP id f0QLs9t03183; Fri, 26 Jan 2001 22:54:09 +0100 (MET) Received: (from bouyer@localhost) by rochebonne.antioche.eu.org (8.11.2/8.9.3) id f0QKKrk00313; Fri, 26 Jan 2001 21:20:53 +0100 (MET) Date: Fri, 26 Jan 2001 21:20:53 +0100 From: Manuel Bouyer To: Matthew Jacob Cc: Nathan Parrish , Dan Nelson , current@FreeBSD.ORG, current-users@netbsd.org Subject: Re: > 4GB with NFS? Message-ID: <20010126212053.B296@antioche.eu.org> References: <20010125211443.22025.qmail@web10405.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: ; from mjacob@feral.com on Thu, Jan 25, 2001 at 02:18:01PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jan 25, 2001 at 02:18:01PM -0800, Matthew Jacob wrote: > An update on this.... > > If the server is Solaris, neither NetBSD nor FreeBSD (i386 or alpha) have a > problem (as clients). > > The problem is therefore in some interaction between this server (see > http://www.traakan.com- sorta like a NetApp) and *BSD. Hmm!!! Did you check *BSD uses NFSv3 with this server ? -- Manuel Bouyer -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 14:11:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 2D23337B400 for ; Fri, 26 Jan 2001 14:11:22 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA28198; Fri, 26 Jan 2001 14:11:03 -0800 Date: Fri, 26 Jan 2001 14:11:02 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Manuel Bouyer Cc: Nathan Parrish , Dan Nelson , current@FreeBSD.ORG, current-users@netbsd.org Subject: Re: > 4GB with NFS? In-Reply-To: <20010126212053.B296@antioche.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, Jan 25, 2001 at 02:18:01PM -0800, Matthew Jacob wrote: > > An update on this.... > > > > If the server is Solaris, neither NetBSD nor FreeBSD (i386 or alpha) have a > > problem (as clients). > > > > The problem is therefore in some interaction between this server (see > > http://www.traakan.com- sorta like a NetApp) and *BSD. Hmm!!! > > > Did you check *BSD uses NFSv3 with this server ? Other than believing what it says on the server and and doing it manually, no. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jan 26 14:14: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id A19E637B400 for ; Fri, 26 Jan 2001 14:13:50 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0QM9T345774; Fri, 26 Jan 2001 14:09:29 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010126220820.2fa3265a.steveo@eircom.net> Date: Fri, 26 Jan 2001 14:13:42 -0800 (PST) From: John Baldwin To: "Steve O'Hara-Smith" Subject: RE: patch for test: /etc/shells -> /usr/local/etc/shells Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 26-Jan-01 Steve O'Hara-Smith wrote: > Hi, > > Following some recent comments on the evil ways of ports have of > writing in /etc on install - This assumes that everyone uses /usr/local for ${LOCALBASE}, which is not a good assumption to make. If you want to do this right, then ports should modify ${LOCALBASE}/etc/shells, and a couple of things should happen: 1) All parsing of /etc/shells should move off into libutil under a suitable API. 2) The implementation of this API should allow for multiple files that it checks. One way might be to add a '.include' keyword or something so that /etc/shells could have '.include /usr/local/etc/shells' that the admin could adjust should he/she choose to change ${LOCALBASE} to something other than /usr/local. This is more work than your patch, but this patch doesn't really solve the problem, it merely moves it. It also breaks for ${LOCALBASE} != /usr/local, so I don't think it should go in. My $.02. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 0:18:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp.wanadoo.nl (smtp.wanadoo.nl [194.134.193.6]) by hub.freebsd.org (Postfix) with ESMTP id 0852D37B69C; Sat, 27 Jan 2001 00:18:21 -0800 (PST) Received: from ams-gw.sohara.org (p1231.vcu.wanadoo.nl [194.134.203.212]) by smtp.wanadoo.nl (8.9.3/8.9.3) with SMTP id JAA14935; Sat, 27 Jan 2001 09:18:19 +0100 (MET) Date: Sat, 27 Jan 2001 09:18:14 +0100 From: "Steve O'Hara-Smith" To: John Baldwin Cc: current@FreeBSD.org Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells Message-Id: <20010127091814.567fda08.steveo@eircom.net> In-Reply-To: References: <20010126220820.2fa3265a.steveo@eircom.net> X-Mailer: Sylpheed version 0.4.9 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 26 Jan 2001 14:13:42 -0800 (PST) John Baldwin wrote: JB> 1) All parsing of /etc/shells should move off into libutil under a JB> suitable API. There is one in libc/gen that would do fine. The catch is that it is not used everywhere and some of the code that fails to use it is in contrib and I am not too sure of the wisdom of changing it. JB> 2) The implementation of this API should allow for multiple files that it JB> checks. One way might be to add a '.include' keyword or something so JB> that /etc/shells could have '.include /usr/local/etc/shells' that the JB> admin could adjust should he/she choose to change ${LOCALBASE} to JB> something other than /usr/local. I did consider an include mechanism and making _PATH_SHELLS a path list. I was leaning in the direction of an include mechanism when the (bad) idea of changing _PATH_SHELLS to point to /usr/local which removed any need to patch roken, adduser.pl and sendmail. JB> This is more work than your patch, but this patch doesn't really solve JB> the problem, it merely moves it. It also breaks for ${LOCALBASE} JB> != /usr/local, so I don't think it should go in. Good points, agreed. Thoughts please on the wisdom of patching the above areas to handle an include syntax, my worry is maintenance since most of it is contib. I don't know if I would be introducing the first changes to them (in which cas I will not) or just one of many (in which case I'll start coding). ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 0:27:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 921C637B6A0 for ; Sat, 27 Jan 2001 00:27:22 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp151.geekhouse.net [192.168.1.151]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f0R8WHs92335; Sat, 27 Jan 2001 00:32:18 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20010127091814.567fda08.steveo@eircom.net> Date: Sat, 27 Jan 2001 00:27:13 -0800 (PST) From: John Baldwin To: "Steve O'Hara-Smith" Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Jan-01 Steve O'Hara-Smith wrote: > On Fri, 26 Jan 2001 14:13:42 -0800 (PST) > John Baldwin wrote: > > > JB> 1) All parsing of /etc/shells should move off into libutil under a > JB> suitable API. > > There is one in libc/gen that would do fine. The catch is that it > is not used everywhere and some of the code that fails to use it is in > contrib > and I am not too sure of the wisdom of changing it. Hmmm.. How many places use it? sendmail is probably one. If you get a workable API implemented, we might be able to convince contrib'd apps to use it, which would be one way of fixing this problem. If you can do that, then you might be able to work with the maintainer(s) to commit the changes before the next release of the vendor code comes out on the vendor branch. > JB> 2) The implementation of this API should allow for multiple files that it > JB> checks. One way might be to add a '.include' keyword or something so > JB> that /etc/shells could have '.include /usr/local/etc/shells' that the > JB> admin could adjust should he/she choose to change ${LOCALBASE} to > JB> something other than /usr/local. > > I did consider an include mechanism and making _PATH_SHELLS a path list. > I was leaning in the direction of an include mechanism when the (bad) idea of > changing _PATH_SHELLS to point to /usr/local which removed any need to patch > roken, adduser.pl and sendmail. You don't want to statically code a path into _PATH_SHELLS, cause then an admin has to recompile everything if they change LOCALBASE, which would suck. :) > JB> This is more work than your patch, but this patch doesn't really solve > JB> the problem, it merely moves it. It also breaks for ${LOCALBASE} > JB> != /usr/local, so I don't think it should go in. > > Good points, agreed. > > Thoughts please on the wisdom of patching the above areas to handle > an include syntax, my worry is maintenance since most of it is contib. I > don't > know if I would be introducing the first changes to them (in which cas I will > not) or just one of many (in which case I'll start coding). ? How many contrib'd apps need to look at /etc/shells? The biggest one I think is sendmail, and Greg Shapiro is a very reasonable fellow, and can probably assist in getting sendmail at least to use the API as long as it isn't too inconvenient. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 0:40:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 53ECA37B6A0 for ; Sat, 27 Jan 2001 00:40:05 -0800 (PST) Received: (from julian@localhost) by InterJet.elischer.org (8.9.1a/8.9.1) id AAA75738 for current@freebsd.org; Sat, 27 Jan 2001 00:33:23 -0800 (PST) Date: Sat, 27 Jan 2001 00:33:23 -0800 (PST) From: Root Dude Message-Id: <200101270833.AAA75738@InterJet.elischer.org> To: current@freebsd.org Subject: kernel threading: the first steps [patch] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's a first step. I've broken the proc structure into 4 structures. At this moment the proc structure includes the other three, so there is no problem with allocation, and there is always a 1:1 correlation between them at this time so this is safe. SOme of the fields are probably in the wrong structs but it doesn't matter for his patch. The aim of this patch is to make people think about which fields go to which structures and what new fields are needed. Remarkably the kernel compiles and runs! The purposes of the structs in this setting are: 1/ The kse struct is known to the scheduler, associated with a CPU and scheduled whenever there as a context to run. 2/The ksec is a stored context that is associated with a kse, but for some reason cannot be running now. 3/The KSEG has a priority, nice value, etc. KSECs tha complete may be reported back to the userland scheduler on he next KSE within the same KSEG. Timers are in KSEG scope. Signals are in KSEG scope too? 4/Al resorces and permissions are owned by the original proc sruct. these definitions are open for discussion but they give some grounds to work on regarding which fields go where After deciding what the semantics are and assigning fields to structures, (and how they are linked), we can then work out which functions in the kernel take which structure as arguments, and them work towards divorcing them so that the 1:1 relationship is broken. At that stage we have threads. thoughts?. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000-2001 ---> X_.---._/ v Index: kern/kern_fork.c =================================================================== RCS file: /unused/cvs/freebsd/src/sys/kern/kern_fork.c,v retrieving revision 1.94 diff -u -r1.94 kern_fork.c --- kern/kern_fork.c 2001/01/24 10:47:14 1.94 +++ kern/kern_fork.c 2001/01/27 03:53:12 @@ -371,6 +371,24 @@ bcopy(&p1->p_startcopy, &p2->p_startcopy, (unsigned) ((caddr_t)&p2->p_endcopy - (caddr_t)&p2->p_startcopy)); + bzero(&p2->kse0.kse_startzero, + (unsigned) ((caddr_t)&p2->kse0.kse_endzero + - (caddr_t)&p2->kse0.kse_startzero)); + bcopy(&p1->kse0.kse_startcopy, &p2->kse0.kse_startcopy, + (unsigned) ((caddr_t)&p2->kse0.kse_endcopy + - (caddr_t)&p2->kse0.kse_startcopy)); + + bzero(&p2->ksec0.ksec_startzero, + (unsigned) ((caddr_t)&p2->ksec0.ksec_endzero + - (caddr_t)&p2->ksec0.ksec_startzero)); + bcopy(&p1->ksec0.ksec_startcopy, &p2->ksec0.ksec_startcopy, + (unsigned) ((caddr_t)&p2->ksec0.ksec_endcopy + - (caddr_t)&p2->ksec0.ksec_startcopy)); + + bcopy(&p1->kseg0.kseg_startcopy, &p2->kseg0.kseg_startcopy, + (unsigned) ((caddr_t)&p2->kseg0.kseg_endcopy + - (caddr_t)&p2->kseg0.kseg_startcopy)); + mtx_init(&p2->p_mtx, "process lock", MTX_DEF); p2->p_aioinfo = NULL; Index: sys/proc.h =================================================================== RCS file: /unused/cvs/freebsd/src/sys/sys/proc.h,v retrieving revision 1.141 diff -u -r1.141 proc.h --- sys/proc.h 2001/01/24 09:41:03 1.141 +++ sys/proc.h 2001/01/27 03:52:53 @@ -141,18 +141,157 @@ * m - Giant * n - not locked, lazy */ +struct proc; /* forward decl. */ + +/* + * The schedulable entity that can be given a context to run. + * A process may have several of these. Probably one per processor + * but posibly a few more. In this universe they are grouped + * with a KSEG that contains the priority and niceness + * for the group. + */ +struct kse { + /***** individualy set up */ + struct pstats *kse_stats; /* (bk) Accounting/statistics (CPU). */ +#define kse_startzero kse_estcpu + /***** start zero */ + u_int kse_estcpu; /* (jk) Time averaged value of kse_cpticks. */ + int kse_cpticks; /* (jk) Ticks of cpu time. */ + fixpt_t kse_pctcpu; /* (jk) %cpu during p_swtime. */ + u_int64_t kse_uu; /* (jk) Previous user time in microsec. */ + u_int64_t kse_su; /* (jk) Previous system time in microsec. */ + u_int64_t kse_iu; /* (jk) Previous interrupt time in microsec. */ + u_int64_t kse_uticks; /* (jk) Statclock hits in user mode. */ + u_int64_t kse_sticks; /* (jk) Statclock hits in system mode. */ + u_int64_t kse_iticks; /* (jk) Statclock hits processing intr. */ + u_int kse_slptime; /* (jk) Time since last blocked. */ + u_char kse_oncpu; /* (jk) Which cpu we are on. */ + char kse_rqindex; /* (jk) Run queue index. */ + register_t kse_retval[2]; /* (kk) Syscall aux returns. */ + /***** end zero */ +#define kse_endzero kse_priority +#define kse_startcopy kse_priority + /***** start copy */ + u_char kse_priority; /* (jk) Process priority. */ + u_char kse_usrpri; /* (jk) User priority based on p_cpu and p_nice. */ +#define kse_endcopy kse_ithd + /***** end copy */ + struct ithd *kse_ithd; /* (bk) For interrupt threads only. */ + struct kseg *kse_ourkseg; + struct proc *kse_ourproc; +}; +/* + * Compatibility defines for while we are using a + * single one in the proc struct during development. + */ +#define p_stats kse0.kse_stats +#define p_estcpu kse0.kse_estcpu +#define p_cpticks kse0.kse_cpticks +#define p_pctcpu kse0.kse_pctcpu +#define p_uu kse0.kse_uu +#define p_su kse0.kse_su +#define p_iu kse0.kse_iu +#define p_uticks kse0.kse_uticks +#define p_sticks kse0.kse_sticks +#define p_iticks kse0.kse_iticks +#define p_slptime kse0.kse_slptime +#define p_oncpu kse0.kse_oncpu +#define p_rqindex kse0.kse_rqindex +#define p_retval kse0.kse_retval +#define p_priority kse0.kse_priority +#define p_usrpri kse0.kse_usrpri +#define p_ithd kse0.kse_ithd + +/* + * Kernel runnable context. This is what is put to sleep and reactivated. + * (Kernel Schedulable Entity Context) + * The first KSE available in the correct group will run this context. + * If several are available, use the one on the same CPU as last time. + */ +struct ksec { + /***** individualy set up */ + TAILQ_ENTRY(proc) ksec_procq; /* (jc) Run/mutex queue. */ + TAILQ_ENTRY(proc) ksec_slpq; /* (jc) Sleep queue. */ + int ksec_intr_nesting_level; /* (nc?) Interrupt recursion. */ +#define ksec_startzero ksec_dupfd + /***** start zero */ + int ksec_dupfd; /* (cc) Sideways ret value from fdopen. XXX */ + void *ksec_wchan; /* (jc) Sleep address. */ + const char *ksec_wmesg; /* (jc) Reason for sleep. */ + u_char ksec_lastcpu; /* (jc) Last cpu we were on. */ + short ksec_locks; /* (*c) DEBUG: lockmgr count of held locks */ + short ksec_simple_locks; /* (*c) DEBUG: count of held simple locks */ + u_int ksec_stops; /* (cc?) Procfs event bitmask. */ + u_int ksec_stype; /* (cc?) Procfs stop event type. */ + char ksec_step; /* (cc?) Procfs stop *once* flag. */ + u_char ksec_pfsflags; /* (cc?) Procfs flags. */ + struct mtx *ksec_blocked; /* (jc) Mutex process is blocked on. */ + const char *ksec_mtxname; /* (jc) Name of mutex blocked on. */ + LIST_HEAD(, mtx) ksec_contested;/* (jc) Contested locks. */ + /***** end zero */ +#define ksec_endzero ksec_slpcallout +#define ksec_startcopy ksec_slpcallout + /***** start copy */ + struct callout ksec_slpcallout;/* (hc) Callout for sleep. */ + struct mdproc ksec_md; /* (kc) Any machine-dependent fields. */ + /***** end copy */ +#define ksec_endcopy ksec_ourkse + struct kse *ksec_ourkse; +}; +/* + * Compatibility defines for while we are using a + * single one in the proc struct during development. + */ +#define p_procq ksec0.ksec_procq +#define p_slpq ksec0.ksec_slpq +#define p_intr_nesting_level ksec0.ksec_intr_nesting_level +#define p_dupfd ksec0.ksec_dupfd +#define p_wchan ksec0.ksec_wchan +#define p_wmesg ksec0.ksec_wmesg +#define p_lastcpu ksec0.ksec_lastcpu +#define p_locks ksec0.ksec_locks +#define p_simple_locks ksec0.ksec_simple_locks +#define p_stops ksec0.ksec_stops +#define p_stype ksec0.ksec_stype +#define p_step ksec0.ksec_step +#define p_pfsflags ksec0.ksec_pfsflags +#define p_blocked ksec0.ksec_blocked +#define p_mtxname ksec0.ksec_mtxname +#define p_contested ksec0.ksec_contested +#define p_slpcallout ksec0.ksec_slpcallout +#define p_md ksec0.ksec_md + +/* + * store KSE group common information such as priority + */ +struct kseg { /* all copied */ +#define kseg_startcopy kseg_itcallout + struct callout kseg_itcallout; /* (hg) Interval timer callout. */ + char kseg_nice; /* (j?/k?g) Process "nice" value. */ + struct rtprio kseg_rtprio; /* (jg) Realtime priority. */ +#define kseg_endcopy kseg_ourproc + struct proc *kseg_ourproc; +}; +/* + * Compatibility defines for while we are using a + * single one in the proc struct during development. + */ +#define p_itcallout kseg0.kseg_itcallout +#define p_nice kseg0.kseg_nice +#define p_rtprio kseg0.kseg_rtprio + struct proc { - TAILQ_ENTRY(proc) p_procq; /* (j) Run/mutex queue. */ - TAILQ_ENTRY(proc) p_slpq; /* (j) Sleep queue. */ - LIST_ENTRY(proc) p_list; /* (d) List of all processes. */ + LIST_ENTRY(proc) p_list; /* (dp) List of all processes. */ + struct kse kse0; + struct kseg kseg0; + struct ksec ksec0; /* substructures: */ - struct pcred *p_cred; /* (c) Process owner's identity. */ - struct filedesc *p_fd; /* (b) Ptr to open files structure. */ - struct pstats *p_stats; /* (b) Accounting/statistics (CPU). */ - struct plimit *p_limit; /* (m) Process limits. */ - struct vm_object *p_upages_obj;/* (c) Upages object. */ - struct procsig *p_procsig; /* (c) Signal actions, state (CPU). */ + struct pcred *p_cred; /* (cp) Process owner's identity. */ + struct filedesc *p_fd; /* (bp) Ptr to open files structure. */ + struct plimit *p_limit; /* (mp) Process limits. */ + struct vm_object *p_upages_obj;/* (cp) Upages object. */ + struct procsig *p_procsig; /* (cp) Signal actions, state (CPU). */ #define p_sigacts p_procsig->ps_sigacts #define p_sigignore p_procsig->ps_sigignore #define p_sigcatch p_procsig->ps_sigcatch @@ -160,77 +299,47 @@ #define p_ucred p_cred->pc_ucred #define p_rlimit p_limit->pl_rlimit - int p_flag; /* (c) P_* flags. */ - int p_sflag; /* (j) PS_* flags. */ - int p_intr_nesting_level; /* (n) Interrupt recursion. */ - char p_stat; /* (j) S* process status. */ + int p_flag; /* (cp) P_* flags. */ + int p_sflag; /* (jp) PS_* flags. */ + char p_stat; /* (jp) S* process status. */ char p_pad1[3]; - pid_t p_pid; /* (b) Process identifier. */ - LIST_ENTRY(proc) p_hash; /* (d) Hash chain. */ - LIST_ENTRY(proc) p_pglist; /* (c) List of processes in pgrp. */ - struct proc *p_pptr; /* (e) Pointer to parent process. */ - LIST_ENTRY(proc) p_sibling; /* (e) List of sibling processes. */ - LIST_HEAD(, proc) p_children; /* (e) Pointer to list of children. */ + pid_t p_pid; /* (bp) Process identifier. */ + LIST_ENTRY(proc) p_hash; /* (dp) Hash chain. */ + LIST_ENTRY(proc) p_pglist; /* (cp) List of processes in pgrp. */ + struct proc *p_pptr; /* (ep) Pointer to parent process. */ + LIST_ENTRY(proc) p_sibling; /* (ep) List of sibling processes. */ + LIST_HEAD(, proc) p_children; /* (ep) Pointer to list of children. */ /* The following fields are all zeroed upon creation in fork. */ #define p_startzero p_oppid - pid_t p_oppid; /* (c) Save parent pid during ptrace. XXX */ - int p_dupfd; /* (c) Sideways ret value from fdopen. XXX */ - struct vmspace *p_vmspace; /* (b) Address space. */ + pid_t p_oppid; /* (cp) Save parent pid during ptrace. XXX */ + struct vmspace *p_vmspace; /* (bp) Address space. */ /* scheduling */ - u_int p_estcpu; /* (j) Time averaged value of p_cpticks. */ - int p_cpticks; /* (j) Ticks of cpu time. */ - fixpt_t p_pctcpu; /* (j) %cpu during p_swtime. */ - struct callout p_slpcallout; /* (h) Callout for sleep. */ - void *p_wchan; /* (j) Sleep address. */ - const char *p_wmesg; /* (j) Reason for sleep. */ - u_int p_swtime; /* (j) Time swapped in or out. */ - u_int p_slptime; /* (j) Time since last blocked. */ + u_int p_swtime; /* (jp) Time swapped in or out. */ - struct callout p_itcallout; /* (h) Interval timer callout. */ struct itimerval p_realtimer; /* (h?/k?) Alarm timer. */ - u_int64_t p_runtime; /* (j) Real time in microsec. */ - u_int64_t p_uu; /* (j) Previous user time in microsec. */ - u_int64_t p_su; /* (j) Previous system time in microsec. */ - u_int64_t p_iu; /* (j) Previous interrupt time in microsec. */ - u_int64_t p_uticks; /* (j) Statclock hits in user mode. */ - u_int64_t p_sticks; /* (j) Statclock hits in system mode. */ - u_int64_t p_iticks; /* (j) Statclock hits processing intr. */ - - int p_traceflag; /* (j?) Kernel trace points. */ - struct vnode *p_tracep; /* (j?) Trace to vnode. */ - - sigset_t p_siglist; /* (c) Signals arrived but not delivered. */ - - struct vnode *p_textvp; /* (b) Vnode of executable. */ - - char p_lock; /* (c) Process lock (prevent swap) count. */ - struct mtx p_mtx; /* (k) Lock for this struct. */ - u_char p_oncpu; /* (j) Which cpu we are on. */ - u_char p_lastcpu; /* (j) Last cpu we were on. */ - char p_rqindex; /* (j) Run queue index. */ - - short p_locks; /* (*) DEBUG: lockmgr count of held locks */ - short p_simple_locks; /* (*) DEBUG: count of held simple locks */ - u_int p_stops; /* (c) Procfs event bitmask. */ - u_int p_stype; /* (c) Procfs stop event type. */ - char p_step; /* (c) Procfs stop *once* flag. */ - u_char p_pfsflags; /* (c) Procfs flags. */ + u_int64_t p_runtime; /* (jp) Real time in microsec. */ + + int p_traceflag; /* (j?p) Kernel trace points. */ + struct vnode *p_tracep; /* (j?p) Trace to vnode. */ + + sigset_t p_siglist; /* (cp) Signals arrived but not delivered. */ + + struct vnode *p_textvp; /* (bp) Vnode of executable. */ + + char p_lock; /* (cp) Process lock (prevent swap) count. */ + struct mtx p_mtx; /* (kp) Lock for this struct. */ char p_pad3[2]; /* Alignment. */ - register_t p_retval[2]; /* (k) Syscall aux returns. */ - struct sigiolst p_sigiolst; /* (c) List of sigio sources. */ - int p_sigparent; /* (c) Signal to parent on exit. */ - sigset_t p_oldsigmask; /* (c) Saved mask from before sigpause. */ - int p_sig; /* (n) For core dump/debugger XXX. */ - u_long p_code; /* (n) For core dump/debugger XXX. */ - struct klist p_klist; /* (c) Knotes attached to this process. */ - LIST_HEAD(, mtx) p_heldmtx; /* (j) For debugging code. */ - struct mtx *p_blocked; /* (j) Mutex process is blocked on. */ - const char *p_mtxname; /* (j) Name of mutex blocked on. */ - LIST_HEAD(, mtx) p_contested; /* (j) Contested locks. */ + struct sigiolst p_sigiolst; /* (cp) List of sigio sources. */ + int p_sigparent; /* (cp) Signal to parent on exit. */ + sigset_t p_oldsigmask; /* (cp) Saved mask from before sigpause. */ + int p_sig; /* (np) For core dump/debugger XXX. */ + u_long p_code; /* (np) For core dump/debugger XXX. */ + struct klist p_klist; /* (cp) Knotes attached to this process. */ + LIST_HEAD(, mtx) p_heldmtx; /* (jp) For debugging code. */ /* End area that is zeroed on creation. */ #define p_endzero p_startcopy @@ -238,38 +347,32 @@ /* The following fields are all copied upon creation in fork. */ #define p_startcopy p_sigmask - sigset_t p_sigmask; /* (c) Current signal mask. */ - stack_t p_sigstk; /* (c) Stack pointer and on-stack flag. */ + sigset_t p_sigmask; /* (cp) Current signal mask. */ + stack_t p_sigstk; /* (cp) Stack pointer and on-stack flag. */ - int p_magic; /* (b) Magic number. */ - u_char p_priority; /* (j) Process priority. */ - u_char p_usrpri; /* (j) User priority based on p_cpu and p_nice. */ - u_char p_nativepri; /* (j) Priority before propagation. */ - char p_nice; /* (j?/k?) Process "nice" value. */ - char p_comm[MAXCOMLEN + 1]; /* (b) Process name. */ - - struct pgrp *p_pgrp; /* (e?/c?) Pointer to process group. */ - struct sysentvec *p_sysent; /* (b) System call dispatch information. */ - struct rtprio p_rtprio; /* (j) Realtime priority. */ - struct prison *p_prison; /* (b?) jail(4). */ - struct pargs *p_args; /* (b?) Process arguments. */ + int p_magic; /* (bp) Magic number. */ + u_char p_nativepri; /* (jp) Priority before propagation. */ + char p_comm[MAXCOMLEN + 1]; /* (bp) Process name. */ + + struct pgrp *p_pgrp; /* (e?/c?p) Pointer to process group. */ + struct sysentvec *p_sysent; /* (pb) System call dispatch information. */ + struct prison *p_prison; /* (b?p) jail(4). */ + struct pargs *p_args; /* (b?p) Process arguments. */ /* End area that is copied on creation. */ #define p_endcopy p_addr - struct user *p_addr; /* (k) Kernel virtual addr of u-area (CPU). */ - struct mdproc p_md; /* (k) Any machine-dependent fields. */ + struct user *p_addr; /* (kp) Kernel virtual addr of u-area (CPU). */ - u_short p_xstat; /* (c) Exit status for wait; also stop sig. */ - u_short p_acflag; /* (c) Accounting flags. */ - struct rusage *p_ru; /* (a) Exit information. XXX */ - - void *p_aioinfo; /* (c) ASYNC I/O info. */ - struct proc *p_peers; /* (c) */ - struct proc *p_leader; /* (c) */ - struct pasleep p_asleep; /* (k) Used by asleep()/await(). */ - void *p_emuldata; /* (c) Emulator state data. */ - struct ithd *p_ithd; /* (b) For interrupt threads only. */ + u_short p_xstat; /* (cp) Exit status for wait; also stop sig. */ + u_short p_acflag; /* (cp) Accounting flags. */ + struct rusage *p_ru; /* (ap) Exit information. XXX */ + + void *p_aioinfo; /* (cp) ASYNC I/O info. */ + struct proc *p_peers; /* (cp) */ + struct proc *p_leader; /* (cp) */ + struct pasleep p_asleep; /* (kc) Used by asleep()/await(). */ + void *p_emuldata; /* (cp) Emulator state data. */ }; #define p_session p_pgrp->pg_session To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 1:15:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (flutter.freebsd.dk [212.242.40.147]) by hub.freebsd.org (Postfix) with ESMTP id 711D337B698 for ; Sat, 27 Jan 2001 01:14:54 -0800 (PST) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.1/8.11.1) with ESMTP id f0R9ErK09333; Sat, 27 Jan 2001 10:14:53 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Root Dude Cc: current@FreeBSD.ORG Subject: Re: kernel threading: the first steps [patch] In-Reply-To: Your message of "Sat, 27 Jan 2001 00:33:23 PST." <200101270833.AAA75738@InterJet.elischer.org> Date: Sat, 27 Jan 2001 10:14:53 +0100 Message-ID: <9331.980586893@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200101270833.AAA75738@InterJet.elischer.org>, Root Dude writes: > >Here's a first step. > >I've broken the proc structure into 4 structures. [...] Uhm Julian, You are aware that other people are working on this stuff too ? -- 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 1:29:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from obsecurity.org (adsl-64-165-226-71.dsl.lsan03.pacbell.net [64.165.226.71]) by hub.freebsd.org (Postfix) with ESMTP id 03BDC37B402 for ; Sat, 27 Jan 2001 01:29:24 -0800 (PST) Received: by obsecurity.org (Postfix, from userid 1000) id 23070BA6C2; Sat, 27 Jan 2001 01:29:52 -0800 (PST) Date: Sat, 27 Jan 2001 01:29:51 -0800 From: Kris Kennaway To: current@FreeBSD.org Subject: OpenSSL 0.9.6-STABLE snapshot Message-ID: <20010127012951.A62741@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please test the code at http://www.freebsd.org/~kris/openssl-0.9.6-stable.tgz - it's the latest snapshot of the OpenSSL 0.9.6-STABLE branch, containing lots of bugfixes against 0.9.6 etc. Just blat it over the top of your existing files from /usr/src. I especially want people to test it for binary compatability with ports etc - when I imported 0.9.6 no-one bothered to tell me about the broken binary compat, until AFTER I merged it into 4.x. Kris --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE6cpUPWry0BWjoQKURAlPOAJ4uwediuce68seQG3uCvyLzej+wNgCcC8s2 nDrOpkZejRkKxy1R32nom7Y= =DfOS -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 3:53:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp.wanadoo.nl (smtp.wanadoo.nl [194.134.193.6]) by hub.freebsd.org (Postfix) with ESMTP id 8D13137B400; Sat, 27 Jan 2001 03:53:09 -0800 (PST) Received: from ams-gw.sohara.org (p0984.vcu.wanadoo.nl [194.134.202.221]) by smtp.wanadoo.nl (8.9.3/8.9.3) with SMTP id MAA09784; Sat, 27 Jan 2001 12:53:07 +0100 (MET) Date: Sat, 27 Jan 2001 12:53:03 +0100 From: "Steve O'Hara-Smith" To: John Baldwin Cc: current@FreeBSD.org Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells Message-Id: <20010127125303.647601ef.steveo@eircom.net> In-Reply-To: References: <20010127091814.567fda08.steveo@eircom.net> X-Mailer: Sylpheed version 0.4.9 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 27 Jan 2001 00:27:13 -0800 (PST) John Baldwin wrote: JB> How many contrib'd apps need to look at /etc/shells? The biggest one I think JB> is sendmail, and Greg Shapiro is a very reasonable fellow, and can probably JB> assist in getting sendmail at least to use the API as long as it isn't too JB> inconvenient. I feel encouraged. The other are it turns up is in the crypto section crypto/heimdal/lib/roken/getusershell.c and /crypto/kerberosIV/lib/roken/getusershell.c I think these are the same. The getusershell seems to be the API to use. It will probably have to be redone in perl for adduser.perl but that's no great problem. Now for the bikeshed question .include or #include ? BTW: I did consider cpp or m4 *briefly*. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 4:18:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 0D72337B400 for ; Sat, 27 Jan 2001 04:18:03 -0800 (PST) Received: (qmail 14714 invoked by uid 1142); 27 Jan 2001 12:18:01 -0000 Date: 27 Jan 2001 04:18:01 -0800 Date: Sat, 27 Jan 2001 04:17:53 -0800 From: Jason Evans To: Root Dude Cc: current@freebsd.org Subject: Re: kernel threading: the first steps [patch] Message-ID: <20010127041753.K87569@canonware.com> References: <200101270833.AAA75738@InterJet.elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101270833.AAA75738@InterJet.elischer.org>; from julian@elischer.org on Sat, Jan 27, 2001 at 12:33:23AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 12:33:23AM -0800, Root Dude wrote: > > Here's a first step. This is very disappointing, Julian. You've duplicated work that I've already done, and if you've been paying attention at all, you know that it was already done. Even if you haven't been paying attention, I find it particularly telling that you never even sent me email about this. This is the single most flagrant lack of cooperation I have experienced while working with the FreeBSD Project. I'm truly dumbfounded. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 4:58: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp.wanadoo.nl (smtp.wanadoo.nl [194.134.193.6]) by hub.freebsd.org (Postfix) with ESMTP id 31DF637B400; Sat, 27 Jan 2001 04:57:47 -0800 (PST) Received: from ams-gw.sohara.org (p0984.vcu.wanadoo.nl [194.134.202.221]) by smtp.wanadoo.nl (8.9.3/8.9.3) with SMTP id NAA18628; Sat, 27 Jan 2001 13:57:45 +0100 (MET) Date: Sat, 27 Jan 2001 13:57:40 +0100 From: "Steve O'Hara-Smith" To: John Baldwin Cc: current@FreeBSD.org Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells Message-Id: <20010127135740.7183f71f.steveo@eircom.net> In-Reply-To: References: <20010127091814.567fda08.steveo@eircom.net> X-Mailer: Sylpheed version 0.4.9 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 27 Jan 2001 00:27:13 -0800 (PST) John Baldwin wrote: JB> How many contrib'd apps need to look at /etc/shells? The biggest one I think JB> is sendmail, and Greg Shapiro is a very reasonable fellow, and can probably JB> assist in getting sendmail at least to use the API as long as it isn't too JB> inconvenient. Life is better than I thought the crypto stuff just has it as a fallback conditional on HAVE_GETUSERSHELL so that uses the one from libc. Which leaves only sendmail which is similar but for some reason does not have HASGETUSERSHELL set for FreeBSD (I think - the conf is convoluted). Meanwhile I am building with a getusershell(3) that knows how to follow a #include (it was already looking for # which pushed the bikeshed marginally that way). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 7: 5:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from titanic.medinet.si (titanic.medinet.si [212.18.32.66]) by hub.freebsd.org (Postfix) with ESMTP id 8635637B401 for ; Sat, 27 Jan 2001 07:05:27 -0800 (PST) Received: by titanic.medinet.si (Postfix, from userid 1000) id 6129026C05; Sat, 27 Jan 2001 16:05:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by titanic.medinet.si (Postfix) with ESMTP id 504931170A for ; Sat, 27 Jan 2001 16:05:26 +0100 (CET) Date: Sat, 27 Jan 2001 16:05:26 +0100 (CET) From: Blaz Zupan To: Subject: XXX driver didn't initialize queue mtx Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG # dmesg ... xl0 XXX: driver didn't initialize queue mtx lo0 XXX: driver didn't initialize queue mtx isp0 XXX: driver didn't initialize queue mtx isp1 XXX: driver didn't initialize queue mtx isp2 XXX: driver didn't initialize queue mtx isp3 XXX: driver didn't initialize queue mtx ... Anything to worry about? 5.0-CURRENT as of today. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: blaz@amis.net, Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 7:34:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D903437B400 for ; Sat, 27 Jan 2001 07:33:56 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id QAA01502; Sat, 27 Jan 2001 16:33:53 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Blaz Zupan Cc: Subject: Re: XXX driver didn't initialize queue mtx References: From: Dag-Erling Smorgrav Date: 27 Jan 2001 16:33:53 +0100 In-Reply-To: Blaz Zupan's message of "Sat, 27 Jan 2001 16:05:26 +0100 (CET)" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Blaz Zupan writes: > xl0 XXX: driver didn't initialize queue mtx > [...] Nothing to worry about, it's just a reminder for us kernel jocks. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 9:36:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 61A2E37B401 for ; Sat, 27 Jan 2001 09:36:39 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA30851; Sat, 27 Jan 2001 09:36:32 -0800 Date: Sat, 27 Jan 2001 09:36:33 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Dag-Erling Smorgrav Cc: Blaz Zupan , freebsd-current@FreeBSD.ORG Subject: Re: XXX driver didn't initialize queue mtx In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh, yeah- can someone say *which* queue mtx it's referring to? On 27 Jan 2001, Dag-Erling Smorgrav wrote: > Blaz Zupan writes: > > xl0 XXX: driver didn't initialize queue mtx > > [...] > > Nothing to worry about, it's just a reminder for us kernel jocks. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 10:36:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 43B1337B401 for ; Sat, 27 Jan 2001 10:35:53 -0800 (PST) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.9.2/8.8.7) with UUCP id SAA09185 for current@freebsd.org; Sat, 27 Jan 2001 18:35:46 GMT (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id SAA17326 for ; Sat, 27 Jan 2001 18:08:17 GMT (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Jan 2001 18:08:17 +0000 To: current@freebsd.org From: Bob Bishop Subject: panic on last night's kernel Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, cvsup at Sat Jan 27 04:04:26 GMT 2001 While booting, just after the message: faith0 XXX: driver didn't initialize queue mtx panic: malloc(M_WAITOK) in interrupt context DDB gives: panic() malloc() exit1() kthread_suspend() ithd_loop() fork_exit() fork_trampoline() -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 10:47:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from gypsy.vrac.iastate.edu (gypsy.vrac.iastate.edu [129.186.232.122]) by hub.freebsd.org (Postfix) with ESMTP id F194F37B402 for ; Sat, 27 Jan 2001 10:46:55 -0800 (PST) Received: from tomservo.vrac.iastate.edu (tomservo.vrac.iastate.edu [129.186.232.121]) by gypsy.vrac.iastate.edu (Postfix) with ESMTP id B597C93 for ; Sat, 27 Jan 2001 12:46:55 -0600 (CST) Received: from tomservo.vrac.iastate.edu (localhost [127.0.0.1]) by tomservo.vrac.iastate.edu (Postfix) with ESMTP id C42CD5E32 for ; Sat, 27 Jan 2001 12:46:54 -0600 (CST) To: freebsd-current@freebsd.org Subject: LyX 1.1.5.2 dumping core Date: Sat, 27 Jan 2001 12:46:54 -0600 From: Patrick Hartling Message-Id: <20010127184654.C42CD5E32@tomservo.vrac.iastate.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just rebuilt my -current system yesterday, and now LyX is throwing up all over itself. It starts up fine, but if I try to load a document or create a new one, it immediately dumps core. The problem seems to be occuring the the xforms library. I have a fresh copy of the compat3x distribution from 4.2-RELEASE installed, but LyX is still unhappy. Does anyone have any suggestions on how I might fix this? I'm not opposed to reverting back to a version of -current from earlier this month. The previous version I was running was from approximately January 5. -Patrick Patrick L. Hartling | Research Assistant, VRAC patrick@137.org | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 11: 4:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4ABFB37B400 for ; Sat, 27 Jan 2001 11:04:09 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id UAA02140; Sat, 27 Jan 2001 20:04:04 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: mjacob@feral.com Cc: Blaz Zupan , freebsd-current@FreeBSD.ORG Subject: Re: XXX driver didn't initialize queue mtx References: From: Dag-Erling Smorgrav Date: 27 Jan 2001 20:04:03 +0100 In-Reply-To: Matthew Jacob's message of "Sat, 27 Jan 2001 09:36:33 -0800 (PST)" Message-ID: Lines: 17 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Jacob writes: > Oh, yeah- can someone say *which* queue mtx it's referring to? des@des ~% current "driver didn.t initialize" src/sys/net/if.c: printf("%s%d XXX: driver didn't initialize queue mtx\n", des@des ~% grep -C "driver didn.t initialize" /sys/net/if.c /* XXX This is an access violation of the mutex internals. */ if (ifp->if_snd.ifq_mtx.mtx_flags == 0) { printf("%s%d XXX: driver didn't initialize queue mtx\n", ifp->if_name, ifp->if_unit); mtx_init(&ifp->if_snd.ifq_mtx, "unknown", MTX_DEF); That wasn't so hard, was it? DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 11:17:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id A829C37B400; Sat, 27 Jan 2001 11:17:23 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id B5ABF193F0; Sat, 27 Jan 2001 13:17:22 -0600 (CST) Date: Sat, 27 Jan 2001 13:17:22 -0600 From: "Jacques A. Vidrine" To: Steve O'Hara-Smith Cc: John Baldwin , current@FreeBSD.org Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells Message-ID: <20010127131722.A17867@spawn.nectar.com> References: <20010127091814.567fda08.steveo@eircom.net> <20010127135740.7183f71f.steveo@eircom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010127135740.7183f71f.steveo@eircom.net>; from steveo@eircom.net on Sat, Jan 27, 2001 at 01:57:40PM +0100 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 01:57:40PM +0100, Steve O'Hara-Smith wrote: > Life is better than I thought the crypto stuff just has it as a fallback > conditional on HAVE_GETUSERSHELL so that uses the one from libc. Which leaves > only sendmail which is similar but for some reason does not have HASGETUSERSHELL > set for FreeBSD (I think - the conf is convoluted). > > Meanwhile I am building with a getusershell(3) that knows how to follow > a #include (it was already looking for # which pushed the bikeshed marginally > that way). You could just use the nsdispatch() API that is in -CURRENT, and that getusershell() uses. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 11:49:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp.wanadoo.nl (smtp.wanadoo.nl [194.134.193.6]) by hub.freebsd.org (Postfix) with ESMTP id 6B2D737B401; Sat, 27 Jan 2001 11:49:13 -0800 (PST) Received: from ams-gw.sohara.org (p1082.vcu.wanadoo.nl [194.134.203.63]) by smtp.wanadoo.nl (8.9.3/8.9.3) with SMTP id UAA16902; Sat, 27 Jan 2001 20:49:04 +0100 (MET) Date: Sat, 27 Jan 2001 20:48:59 +0100 From: "Steve O'Hara-Smith" To: "Jacques A. Vidrine" Cc: jhb@FreeBSD.org, current@FreeBSD.org Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells Message-Id: <20010127204859.552fc9a9.steveo@eircom.net> In-Reply-To: <20010127131722.A17867@spawn.nectar.com> References: <20010127091814.567fda08.steveo@eircom.net> <20010127135740.7183f71f.steveo@eircom.net> <20010127131722.A17867@spawn.nectar.com> X-Mailer: Sylpheed version 0.4.9 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 27 Jan 2001 13:17:22 -0600 "Jacques A. Vidrine" wrote: JV> You could just use the nsdispatch() API that is in -CURRENT, and that JV> getusershell() uses. I'm not sure what for, the changes I've made fit just as smoothly into _local_initshells as they do into initshells. Is there an include chain follower in there that I've missed ? That's what I've added. It's working in the test harness and awaiting buildworld. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 12:37: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3A22337B400 for ; Sat, 27 Jan 2001 12:36:48 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA31327; Sat, 27 Jan 2001 12:36:43 -0800 Date: Sat, 27 Jan 2001 12:36:41 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Dag-Erling Smorgrav Cc: Blaz Zupan , freebsd-current@FreeBSD.ORG Subject: Re: XXX driver didn't initialize queue mtx In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh, I suppose, I did find that... well, mainly I wanted the person who made the change to actually broadcast to NIC maintainers what the expectations were... > Matthew Jacob writes: > > Oh, yeah- can someone say *which* queue mtx it's referring to? > > des@des ~% current "driver didn.t initialize" > src/sys/net/if.c: printf("%s%d XXX: driver didn't initialize queue mtx\n", > des@des ~% grep -C "driver didn.t initialize" /sys/net/if.c > /* XXX This is an access violation of the mutex internals. */ > if (ifp->if_snd.ifq_mtx.mtx_flags == 0) { > printf("%s%d XXX: driver didn't initialize queue mtx\n", > ifp->if_name, ifp->if_unit); > mtx_init(&ifp->if_snd.ifq_mtx, "unknown", MTX_DEF); > > That wasn't so hard, was it? > > DES > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 12:42:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 4BD8337B400 for ; Sat, 27 Jan 2001 12:42:00 -0800 (PST) Received: (qmail 87506 invoked by uid 1142); 27 Jan 2001 20:41:55 -0000 Date: 27 Jan 2001 12:41:55 -0800 Date: Sat, 27 Jan 2001 12:41:49 -0800 From: Jason Evans To: Matthew Jacob Cc: Dag-Erling Smorgrav , freebsd-current@FreeBSD.ORG Subject: Re: XXX driver didn't initialize queue mtx Message-ID: <20010127124149.O87569@canonware.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Sat, Jan 27, 2001 at 12:36:41PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: > > Oh, I suppose, I did find that... well, mainly I wanted the person who made > the change to actually broadcast to NIC maintainers what the expectations > were... The code that prints these warnings out has existed for a while. However, whoever added it made a bad assumption about the internals of the mutex implementation, so the code never got executed. I "fixed" it last week, so the warnings get printed now. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 12:48:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8AF5637B400 for ; Sat, 27 Jan 2001 12:48:41 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id MAA31397; Sat, 27 Jan 2001 12:48:37 -0800 Date: Sat, 27 Jan 2001 12:48:36 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jason Evans Cc: Dag-Erling Smorgrav , freebsd-current@FreeBSD.ORG Subject: Re: XXX driver didn't initialize queue mtx In-Reply-To: <20010127124149.O87569@canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Shouldn't ether_ifattach initialize the mutex? Or do expect all drivers to initialize these prior to calling ether_ifattach? Look- I just want to know what the people who put the check in *want*..... > On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: > > > > Oh, I suppose, I did find that... well, mainly I wanted the person who made > > the change to actually broadcast to NIC maintainers what the expectations > > were... > > The code that prints these warnings out has existed for a while. However, > whoever added it made a bad assumption about the internals of the mutex > implementation, so the code never got executed. I "fixed" it last week, so > the warnings get printed now. > > Jason > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 13: 4:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (c228380-a.sfmissn1.sfba.home.com [24.20.90.44]) by hub.freebsd.org (Postfix) with ESMTP id 7ABCF37B400 for ; Sat, 27 Jan 2001 13:04:33 -0800 (PST) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.1/8.11.1) with ESMTP id f0RL4Vx01386; Sat, 27 Jan 2001 13:04:35 -0800 (PST) (envelope-from msmith@mass.dis.org) Message-Id: <200101272104.f0RL4Vx01386@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brooks Davis Cc: freebsd-current@freebsd.org Subject: Re: PCI changes break HP Docking Station In-reply-to: Your message of "Fri, 26 Jan 2001 12:50:37 PST." <20010126125037.B28316@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Jan 2001 13:04:31 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is weird; the bridge appears to be clearly misconfigured, and unless there's something funky in the datasheet (looking for it now) I'm not quite sure what the "right" thing to do is here. 8( > Please let me know if you need anything more from me to help debug this. This is enough for now; if I'm really lucky I might have some suggested changes for you... -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 13: 6:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 1829C37B401 for ; Sat, 27 Jan 2001 13:06:06 -0800 (PST) Received: (qmail 93304 invoked by uid 1142); 27 Jan 2001 21:06:04 -0000 Date: 27 Jan 2001 13:06:04 -0800 Date: Sat, 27 Jan 2001 13:05:58 -0800 From: Jason Evans To: Matthew Jacob Cc: jlemon@freebsd.org, freebsd-current@FreeBSD.ORG Subject: Re: XXX driver didn't initialize queue mtx Message-ID: <20010127130558.P87569@canonware.com> References: <20010127124149.O87569@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Sat, Jan 27, 2001 at 12:48:36PM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 12:48:36PM -0800, Matthew Jacob wrote: > Somewhere in between, Jason Evans wrote: > > On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: > > > > > > Oh, I suppose, I did find that... well, mainly I wanted the person who made > > > the change to actually broadcast to NIC maintainers what the expectations > > > were... > > > > The code that prints these warnings out has existed for a while. However, > > whoever added it made a bad assumption about the internals of the mutex > > implementation, so the code never got executed. I "fixed" it last week, so > > the warnings get printed now. > > Shouldn't ether_ifattach initialize the mutex? Or do expect all drivers to > initialize these prior to calling ether_ifattach? > > Look- I just want to know what the people who put the check in *want*..... cvs annotate is your friend. The code was added in revision 1.95 of src/sys/net/if.c by Jonathan Lemon. Please talk to him about what should be done to fix the drivers. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 13: 7:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E8F8137B401; Sat, 27 Jan 2001 13:07:17 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id NAA31517; Sat, 27 Jan 2001 13:07:17 -0800 Date: Sat, 27 Jan 2001 13:07:16 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jason Evans Cc: jlemon@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: XXX driver didn't initialize queue mtx In-Reply-To: <20010127130558.P87569@canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > cvs annotate is your friend. The code was added in revision 1.95 of > src/sys/net/if.c by Jonathan Lemon. Please talk to him about what should > be done to fix the drivers. Yes, and I shall... but this came up in a public forum. I'm making a point here (that apparently you and others don't get). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 13:11:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id C00BC37B400 for ; Sat, 27 Jan 2001 13:10:59 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f0RLADe74076; Sat, 27 Jan 2001 15:10:13 -0600 (CST) (envelope-from jlemon) Date: Sat, 27 Jan 2001 15:10:13 -0600 (CST) From: Jonathan Lemon Message-Id: <200101272110.f0RLADe74076@prism.flugsvamp.com> To: jasone@canonware.com, current@freebsd.org Subject: Re: XXX driver didn't initialize queue mtx X-Newsgroups: local.mail.freebsd-current In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: >> >> Oh, I suppose, I did find that... well, mainly I wanted the person who made >> the change to actually broadcast to NIC maintainers what the expectations >> were... > >The code that prints these warnings out has existed for a while. However, >whoever added it made a bad assumption about the internals of the mutex >implementation, so the code never got executed. I "fixed" it last week, so >the warnings get printed now. Actually, I think it was correct at the time I added it. Anything that calls if_attach (or ether_ifattach) will automatically have the mutex correctly initialized, so the driver doesn't have to do anything extra. e.g.: ifp->if_name = "lo"; ifp->if_unit = i++; ifp->if_snd.ifq_maxlen = ifqmaxlen; if_attach(ifp); if_attach(ifp) { .... mtx_init(&ifp->if_snd.ifq_mtx, ifp->if_name, MTX_DEF); ... } I'm not up-to-date with -current at the moment, so I'm not sure why things aren't working any more. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 13:20:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 3BC1E37B400; Sat, 27 Jan 2001 13:19:52 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f0RLJ4M74398; Sat, 27 Jan 2001 15:19:04 -0600 (CST) (envelope-from jlemon) Date: Sat, 27 Jan 2001 15:19:04 -0600 From: Jonathan Lemon To: Jason Evans Cc: Matthew Jacob , jlemon@freebsd.org, freebsd-current@freebsd.org Subject: Re: XXX driver didn't initialize queue mtx Message-ID: <20010127151904.V29115@prism.flugsvamp.com> References: <20010127124149.O87569@canonware.com> <20010127130558.P87569@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20010127130558.P87569@canonware.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 01:05:58PM -0800, Jason Evans wrote: > On Sat, Jan 27, 2001 at 12:48:36PM -0800, Matthew Jacob wrote: > > Somewhere in between, Jason Evans wrote: > > > On Sat, Jan 27, 2001 at 12:36:41PM -0800, Matthew Jacob wrote: > > > > > > > > Oh, I suppose, I did find that... well, mainly I wanted the person who made > > > > the change to actually broadcast to NIC maintainers what the expectations > > > > were... > > > > > > The code that prints these warnings out has existed for a while. However, > > > whoever added it made a bad assumption about the internals of the mutex > > > implementation, so the code never got executed. I "fixed" it last week, so > > > the warnings get printed now. > > > > Shouldn't ether_ifattach initialize the mutex? Or do expect all drivers to > > initialize these prior to calling ether_ifattach? > > > > Look- I just want to know what the people who put the check in *want*..... > > cvs annotate is your friend. The code was added in revision 1.95 of > src/sys/net/if.c by Jonathan Lemon. Please talk to him about what should > be done to fix the drivers. Actually, the new check appears to be incorrect, as seen by the code fragments below: #define MTX_DEF 0x0 /* Default (spin/sleep) */ mtx_init(&ifp->if_snd.ifq_mtx, ifp->if_name, MTX_DEF); mtx_init(... , flag) { ... m->mtx_flags = flag; ... } if (ifp->if_snd.ifq_mtx.mtx_flags == 0) { So the warning will always be printed out even though the mutex is correctly initialized. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 13:25:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from gypsy.vrac.iastate.edu (gypsy.vrac.iastate.edu [129.186.232.122]) by hub.freebsd.org (Postfix) with ESMTP id D34A037B401 for ; Sat, 27 Jan 2001 13:25:15 -0800 (PST) Received: from tomservo.vrac.iastate.edu (tomservo.vrac.iastate.edu [129.186.232.121]) by gypsy.vrac.iastate.edu (Postfix) with ESMTP id 2463893 for ; Sat, 27 Jan 2001 15:25:16 -0600 (CST) Received: from tomservo.vrac.iastate.edu (localhost [127.0.0.1]) by tomservo.vrac.iastate.edu (Postfix) with ESMTP id AF1425E2C for ; Sat, 27 Jan 2001 15:25:14 -0600 (CST) To: freebsd-current@freebsd.org Subject: Fixed: LyX 1.1.5.2 dumping core In-reply-to: "Sat, 27 Jan 2001 12:46:54 CST." <20010127184654.C42CD5E32@tomservo.vrac.iastate.edu> Date: Sat, 27 Jan 2001 15:25:14 -0600 From: Patrick Hartling Message-Id: <20010127212514.AF1425E2C@tomservo.vrac.iastate.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Patrick Hartling wrote: } I just rebuilt my -current system yesterday, and now LyX is throwing up } all over itself. It starts up fine, but if I try to load a document or } create a new one, it immediately dumps core. The problem seems to be } occuring the the xforms library. I have a fresh copy of the compat3x } distribution from 4.2-RELEASE installed, but LyX is still unhappy. Does } anyone have any suggestions on how I might fix this? I'm not opposed to } reverting back to a version of -current from earlier this month. The } previous version I was running was from approximately January 5. Making a symlink from /usr/lib/libc.so.5 to /usr/lib/libc.so.3 seems to have fixed my LyX problems. I'm guessing libc.so.5 and libc.so.3 were causing conflicts, especially with the recent changes to libc, but I'm no expert. Whatever the case, I can get back to work on my thesis now. :) -Patrick Patrick L. Hartling | Research Assistant, VRAC patrick@137.org | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 14: 7: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail-ob.kamp.net (mail-ob.kamp.net [195.62.97.26]) by hub.freebsd.org (Postfix) with ESMTP id 433BA37B400 for ; Sat, 27 Jan 2001 14:06:43 -0800 (PST) Received: from bsdevil.meta.net.ob.kamp.net (port-46.d.kamp.de [195.62.120.238]) by mail-ob.kamp.net (8.10.1/8.10.1) with ESMTP id f0RM6cC17189 for ; Sat, 27 Jan 2001 23:06:39 +0100 Date: Sat, 27 Jan 2001 23:06:38 +0100 Message-Id: <200101272206.f0RM6cC17189@mail-ob.kamp.net> From: Farid Hajji To: freebsd-current@freebsd.org Subject: kernel hangs initializing Soundblaster AWE 64 midi driver X-Mailer: Emacs-20.7.1/FreeBSD-5.0-CURRENT Reply-To: farid.hajji@ob.kamp.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm tracking -CURRENT and build a kernel yesterday with the following options (edited): device sbc # Soundblaster Bridge-Code to pcm device pcm # PnP/PCI Sound Cards #device midi # Midi interfaces #device seq # Sequencer The corresponding hints are: Without midi device, this is the relevant dmesg part: [...] vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b \ irq 5 drq 1,5 on isa0 pcm1: on sbc0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources ed0 XXX: driver didn't initialize queue mtx lp0 XXX: driver didn't initialize queue mtx lo0 XXX: driver didn't initialize queue mtx ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable [...] and the kernel happily boots. Sound is usable as before. Now, adding midi (either alone or together with seq) produces the following messages: sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b \ irq 5 drq 1,5 on isa0 pcm1: on sbc0 midi0: on sbc0 midi1: on sbc0 midi2: at port 0x620-0x623 on isa0 exactly here, the system hangs completely. What I'm I missing? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji@ob.kamp.net - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 15: 0: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id A8D9837B400; Sat, 27 Jan 2001 14:59:43 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 4B429193F0; Sat, 27 Jan 2001 16:59:41 -0600 (CST) Date: Sat, 27 Jan 2001 16:59:41 -0600 From: "Jacques A. Vidrine" To: Steve O'Hara-Smith Cc: jhb@FreeBSD.org, current@FreeBSD.org Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells Message-ID: <20010127165941.A18749@spawn.nectar.com> References: <20010127091814.567fda08.steveo@eircom.net> <20010127135740.7183f71f.steveo@eircom.net> <20010127131722.A17867@spawn.nectar.com> <20010127204859.552fc9a9.steveo@eircom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010127204859.552fc9a9.steveo@eircom.net>; from steveo@eircom.net on Sat, Jan 27, 2001 at 08:48:59PM +0100 X-Url: http://www.nectar.com/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 08:48:59PM +0100, Steve O'Hara-Smith wrote: > On Sat, 27 Jan 2001 13:17:22 -0600 > "Jacques A. Vidrine" wrote: > JV> You could just use the nsdispatch() API that is in -CURRENT, and that > JV> getusershell() uses. > > I'm not sure what for, the changes I've made fit just as smoothly > into _local_initshells as they do into initshells. Is there an include > chain follower in there that I've missed ? That's what I've added. It's > working in the test harness and awaiting buildworld. I thought you might add it as a different source, so that it need not be the default. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 16:48: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id 30ABE37B698 for ; Sat, 27 Jan 2001 16:47:52 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp150.geekhouse.net [192.168.1.150]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f0S0llc00289; Sat, 27 Jan 2001 16:47:48 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 27 Jan 2001 16:47:41 -0800 (PST) From: John Baldwin To: Matthew Jacob Subject: Re: XXX driver didn't initialize queue mtx Cc: freebsd-current@FreeBSD.org, Blaz Zupan , Dag-Erling Smorgrav Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Jan-01 Matthew Jacob wrote: > > Oh, yeah- can someone say *which* queue mtx it's referring to? The if queues. Ones with the IFQ_ENQUEUE() etc. macros. > On 27 Jan 2001, Dag-Erling Smorgrav wrote: > >> Blaz Zupan writes: >> > xl0 XXX: driver didn't initialize queue mtx >> > [...] >> >> Nothing to worry about, it's just a reminder for us kernel jocks. >> >> DES >> -- >> Dag-Erling Smorgrav - des@ofug.org >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-current" in the body of the message >> > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 17:55:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from tkc.att.ne.jp (tkc.att.ne.jp [165.76.16.7]) by hub.freebsd.org (Postfix) with ESMTP id 28E9137B402; Sat, 27 Jan 2001 17:55:16 -0800 (PST) Received: from work.mzaki.nom (111.pool6.ipctokyo.att.ne.jp [165.76.44.111]) by tkc.att.ne.jp (8.8.8+Spin/3.6W-CONS(10/06/00)) id KAA19637; Sun, 28 Jan 2001 10:55:13 +0900 (JST) Date: Sun, 28 Jan 2001 10:55:13 +0900 Message-ID: <864rykphj2.wl@tkc.att.ne.jp> From: Motomichi Matsuzaki To: current@freebsd.org Cc: sos@freebsd.org Subject: CD Extra disks on atapi-cd X-Mailer: Wanderlust/1.1.1 (Purple Rain) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi. I've found that -current kernel couldn't mount CD-Extra disks on ATAPI CD drives. For example: Starting track = 1, ending track = 14, TOC size = 122 bytes track start duration block length type ------------------------------------------------- 1 0:02.00 0:11.52 0 727 audio 2 0:11.52 3:58.55 727 17755 audio 3 4:08.32 2:15.55 18482 10030 audio 4 6:22.12 3:10.50 28512 14150 audio 5 9:30.62 3:02.13 42662 13513 audio 6 12:31.00 2:54.00 56175 12900 audio 7 15:23.00 3:50.40 69075 17140 audio 8 19:11.40 2:59.12 86215 13287 audio 9 22:08.52 3:04.30 99502 13680 audio 10 25:11.07 2:06.05 113182 9305 audio 11 27:15.12 2:54.35 122487 12935 audio 12 30:07.47 3:17.13 135422 14638 audio 13 33:22.60 12:53.27 150060 57852 audio 14 46:14.12 20:50.58 207912 93658 data 170 67:02.70 - 301570 - - Tracks 1-13 are normal CD-DA in the first session, and track 14 is the ISO9660 filesystem which consists of XA Mode 2 Form 1 sectors (2048bytes/sector) in the second session. This disk can be mounted on my SCSI CD drive, but not on my ATAPI CD drive (with EINVAL). I applied the following patch, and then I can successfully mount the disk. Is this a right treatment? --- sys/dev/ata/atapi-cd.c Fri Jan 19 06:01:25 2001 +++ sys/dev/ata/atapi-cd.c.new Sun Jan 28 08:15:37 2001 @@ -1227,7 +1227,7 @@ static void acd_read_toc(struct acd_softc *cdp) { - int ntracks, len; + int ntracks, len, t; int8_t ccb[16]; bzero(&cdp->toc, sizeof(cdp->toc)); @@ -1275,7 +1275,14 @@ cdp->info.volsize = ntohl(cdp->info.volsize); cdp->info.blksize = ntohl(cdp->info.blksize); - cdp->block_size = (cdp->toc.tab[0].control & 4) ? 2048 : 2352; + + cdp->block_size = 2352; + for (t = 0; t < cdp->toc.hdr.ending_track; t++) { + if (cdp->toc.tab[t].control & 4) { + cdp->block_size = 2048; + break; + } + } bzero(&cdp->disklabel, sizeof(struct disklabel)); strncpy(cdp->disklabel.d_typename, " ", -- Motomichi Matsuzaki Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 18:12: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from edgemaster.zombie.org (edgemaster.creighton.edu [147.134.107.69]) by hub.freebsd.org (Postfix) with ESMTP id 3B7E737B400; Sat, 27 Jan 2001 18:11:52 -0800 (PST) Received: by edgemaster.zombie.org (Postfix, from userid 1001) id AA9D998F9; Sat, 27 Jan 2001 20:11:50 -0600 (CST) Date: Sat, 27 Jan 2001 20:11:49 -0600 From: Sean Kelly To: Benjamin Lewis Cc: Robert Watson , current@FreeBSD.org Subject: Re: Building -STABLE on -CURRENT Message-ID: <20010127201149.A53057@edgemaster.zombie.org> References: <20010122204651.A372B709C@akira.wossname.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010122204651.A372B709C@akira.wossname.net>; from bhlewis@wossname.net on Mon, Jan 22, 2001 at 03:46:51PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jan 22, 2001 at 03:46:51PM -0500, Benjamin Lewis wrote: > Robert, > > You wrote: > > > For the last few days (not sure when it started) I've been unable to build > > -STABLE on a -CURRENT machine. This has proven a problem for recent > > RELENG_3 MFC's of security fixes; I've tried upgrading to the most recent > > -CURRENT on the box, making sure /usr/include is updated, et al. I'm > > guessing this is /usr/include pollution in the /usr/src build, but won't > > speculate too much more as I'm travelling tomorrow. Attached below is the > > breakage from buildworld. > > [...] > > > > cd /usr/src/share/syscons/scrnmaps; make build-tools > > cc -static -O -pipe -I/usr/src/share/syscons/scrnmaps > > -DFIL=\"koi8-r2cp866\" > > -o koi8-r2cp866.mk /usr/src/share/syscons/scrnmaps/mkscrfil.c > > In file included from /usr/src/share/syscons/scrnmaps/mkscrfil.c:28: > > /usr/include/machine/console.h:3: #error "this file includes > > > > which is deprecated, use instead" > > I've seen the same thing. I hacked up the -stable source to include the > correct -current include files to get past this, but that strikes me as > extremely non-optimal. I tried hacking up the Makefile in > /usr/src/share/syscons/scrnmaps to use a different include path, but don't > have the know-how or mojo to get that working. I've just hit the same problem... Has anybody got a real fix for this? -- Sean Kelly | PGP KeyID: 77042C7B smkelly@zombie.org | http://www.zombie.org For PGP key, send e-mail with subject "send pgp key" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 22: 6:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from moby.geekhouse.net (moby.geekhouse.net [64.81.6.36]) by hub.freebsd.org (Postfix) with ESMTP id DF53037B400 for ; Sat, 27 Jan 2001 22:06:06 -0800 (PST) Received: from laptop.baldwin.cx (john@dhcp150.geekhouse.net [192.168.1.150]) by moby.geekhouse.net (8.11.0/8.9.3) with ESMTP id f0S667c00849 for ; Sat, 27 Jan 2001 22:06:07 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 27 Jan 2001 22:05:59 -0800 (PST) From: John Baldwin To: current@FreeBSD.org Subject: HEADSUP: WITNESS adn modules == bad juju Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Boris reminded me of someething I had forgotten to mention: currently unloading a module that uses mutexes with WITNESS enabled in the kernel will panic the kernel, cause witness tries to look at the string of the mutex name which is usually a constant in the module later on. This leads to a kernel page fault basically, so until I get this fixed, you really can't unload modules with WITNESS right now. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 22:19: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id 070F637B402 for ; Sat, 27 Jan 2001 22:18:48 -0800 (PST) Received: (qmail 35030 invoked by uid 1142); 28 Jan 2001 06:18:47 -0000 Date: 27 Jan 2001 22:18:47 -0800 Date: Sat, 27 Jan 2001 17:14:54 -0800 From: Jason Evans To: Jonathan Lemon Cc: Matthew Jacob , freebsd-current@freebsd.org Subject: Re: XXX driver didn't initialize queue mtx Message-ID: <20010127171454.Q87569@canonware.com> References: <20010127124149.O87569@canonware.com> <20010127130558.P87569@canonware.com> <20010127151904.V29115@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010127151904.V29115@prism.flugsvamp.com>; from jlemon@flugsvamp.com on Sat, Jan 27, 2001 at 03:19:04PM -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jan 27, 2001 at 03:19:04PM -0600, Jonathan Lemon wrote: > Actually, the new check appears to be incorrect, as seen by the code > fragments below: Whoops. I obviously looked at the wrong #define when making the change. Thanks for pointing out the mistake. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 23:21: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp.wanadoo.nl (smtp.wanadoo.nl [194.134.193.6]) by hub.freebsd.org (Postfix) with ESMTP id 6245D37B402; Sat, 27 Jan 2001 23:20:46 -0800 (PST) Received: from ams-gw.sohara.org (p1522.vcu.wanadoo.nl [194.134.170.247]) by smtp.wanadoo.nl (8.9.3/8.9.3) with SMTP id IAA20625; Sun, 28 Jan 2001 08:20:30 +0100 (MET) Date: Sun, 28 Jan 2001 08:20:26 +0100 From: "Steve O'Hara-Smith" To: "Jacques A. Vidrine" Cc: jhb@FreeBSD.org, current@FreeBSD.org Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells Message-Id: <20010128082026.360a41ab.steveo@eircom.net> In-Reply-To: <20010127165941.A18749@spawn.nectar.com> References: <20010127091814.567fda08.steveo@eircom.net> <20010127135740.7183f71f.steveo@eircom.net> <20010127131722.A17867@spawn.nectar.com> <20010127204859.552fc9a9.steveo@eircom.net> <20010127165941.A18749@spawn.nectar.com> X-Mailer: Sylpheed version 0.4.9 (GTK+ 1.2.8; FreeBSD 4.2-STABLE; i386) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 27 Jan 2001 16:59:41 -0600 "Jacques A. Vidrine" wrote: JV> I thought you might add it as a different source, so that it need not be JV> the default. As I read it that is still a complementary possibility. The nsdispatch stuff could move the start point from /etc/shells to some other path. The include chain mechanism allows the config to be spread. Have I correctly understood what the nsdispatch stuff can do ? Is it expected to MFC or wait for 5.0 ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jan 27 23:32:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id 5663337B400 for ; Sat, 27 Jan 2001 23:32:29 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14Mc6g-0000Cv-00; Sat, 27 Jan 2001 13:37:59 -0700 Message-ID: <3A7331A6.BE5B27C7@softweyr.com> Date: Sat, 27 Jan 2001 13:37:58 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Steve O'Hara-Smith Cc: Garrett Wollman , current@FreeBSD.ORG Subject: Re: patch for test: /etc/shells -> /usr/local/etc/shells References: <20010126220820.2fa3265a.steveo@eircom.net> <200101262121.QAA02884@khavrinen.lcs.mit.edu> <20010126223412.7eba6913.steveo@eircom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Steve O'Hara-Smith wrote: > > On Fri, 26 Jan 2001 16:21:01 -0500 (EST) > Garrett Wollman wrote: > > GW> < said: > GW> > GW> > The patch below (against 4-stable but it will probably apply easily > GW> > to -current) moves /etc/shells to /usr/local/etc/shells. > GW> > GW> Bad idea. No base component (never mind libc!) should hard-code a > GW> pathname in /usr/local. > > I'll consider it flamed to death then :) > > It was intended to prevent port installs having to write in /etc > without having to change libc/gen, roken and sendmail which I rather suspect > is also a bad thing to do. > > Perhaps /etc/shells is the least of all evils here. There is a difference between a port creating a config file in /etc, and a port adding to a standard config file in etc. The former is a bad idea, the latter necessary. The other solution would be to allow a PATH of shells files, but that seems rather messy for something this simple. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message