From owner-freebsd-current Sun Jan 11 01:06:53 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA04704 for current-outgoing; Sun, 11 Jan 1998 01:06:53 -0800 (PST) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA04679 for ; Sun, 11 Jan 1998 01:05:45 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id UAA27003; Sun, 11 Jan 1998 20:01:36 +1100 Date: Sun, 11 Jan 1998 20:01:36 +1100 From: Bruce Evans Message-Id: <199801110901.UAA27003@godzilla.zeta.org.au> To: dstenn@fanfic.org, jb@freebsd1.cimlogic.com.au Subject: Re: make world - A new error Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Well.. Here's the latest in the saga.. This isn't really a 'make world' >> error but a 'make most' The previous error seem to happen when I try to >> compile the libs so I decided to exclude them. > ^^^^^^^ >If you exclude them, then they are not there to link against! It should link to the standard libraries. This may not be right, but it is what you asked for. `make most' is more like plain `make' than it is like `make world'. >> >> ===> ac >> cc -O -c /usr/src/usr.sbin/ac/ac.c >> make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libc.so.3.0. > ^^^^^^^^^^^^^^^^^^^^ > >This is the temporary build tree which is supposed to contain things >you have build before, not things which have previously been installed. It may contain pointers (in .depend files) to the temporary obj tree when the main obj tree isn't clean enough. The main tree is normally cleaned by `make world', but it is likely to be unclean at the point of failure if `make world' fails. Summary: pilot error. Bruce From owner-freebsd-current Sun Jan 11 01:53:45 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA06905 for current-outgoing; Sun, 11 Jan 1998 01:53:45 -0800 (PST) (envelope-from owner-freebsd-current) Received: from rah.star-gate.com ([209.133.7.178]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA06897 for ; Sun, 11 Jan 1998 01:53:40 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id BAA00477; Sun, 11 Jan 1998 01:53:38 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199801110953.BAA00477@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: brian@worldcontrol.com cc: freebsd-current@FreeBSD.ORG Subject: Re: rvplayer kills my -current system In-reply-to: Your message of "Sat, 10 Jan 1998 19:54:28 PST." <19980110195428.17158@top.worldcontrol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jan 1998 01:53:38 -0800 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > rvplayer (linux 5.0 elf version) running under a -current from > Sat 10 Jan 19:50:29 PST 1998 using linuxlib-2.4 kills my system. > > It basically locks up shortly after the command is issued and then > 15 seconds or so later it reboots. There are no messages. > > I'm running XFree86 with depth:16 > > -- > Brian Litzinger Care to post on multimedia and include the output of dmesg? Tnks, Amancio From owner-freebsd-current Sun Jan 11 01:58:58 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA07083 for current-outgoing; Sun, 11 Jan 1998 01:58:58 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org ([206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA07074 for ; Sun, 11 Jan 1998 01:58:44 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 20073 invoked by uid 1000); 11 Jan 1998 09:59:30 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <11733.884504253@time.cdrom.com> Date: Sun, 11 Jan 1998 01:59:30 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: "Jordan K. Hubbard" Subject: Re: Making world today Cc: asami@cs.berkeley.edu, aryder@bestweb.net, current@FreeBSD.ORG, kong@kkk.ml.org, Alex Nash Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 11-Jan-98 Jordan K. Hubbard wrote: >> Seems that way. Maybe we should start thinking about how to eliminate >> these slips. We are gaining a reputation lately. > > It is the nature of -current to break occasionally and I would be no > means wish to get so anal about this that the whole intention of > -current was lost, namely to be a place to work out new stuff and, > yes, occasionally break things in the process. That is why -current > has always been a strictly no-warranty proposition with warning > stickers stuck all over it. The complains we've been getting lately > stem, I think, more from the fact that a lot of the wrong people are > now running -current rather than any major instability there. Hell, I > remember when running -current was a good way to lose *filesystems* > and things have definitely come a hell of a long way from there. ;-) > > Jordan As you no doubtedly noticed, I did say that FreeBSD is one of the best. We all understand rather well the experimental nature of -current. As there is absolutely no warranty on ANY version of FreeBSD, it is quite clear that -current is less waranted than no warranty. None of these should act as a license for careless checkin (which happens by all admissions, from time to time). Neither should it impede the quest for a better, more reliable environment and methodology. As far as being ``far and long way from loosing filesystems'', I've got news for you :-) Not that far: a. My /usr/ports/distfiles is belived, by FSCK to have corrupt superblocks where the forst copy does not match the second copy. This is a) nonsense - they actually match, and b) a result of a -current crash. b. I took this long to reply and still am up at this time, despite needing to wake up at 0600, because of a -current crash that neatly and cleanly removed ALL the files from /, kernels and all, and corrupted two filesystems beyond repair. These facts are NOT a bitch/complaint/moan. I am fully aware of the consequences of using in-progress code. Just a light-hearted tease :-)) ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-current Sun Jan 11 02:30:25 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA08691 for current-outgoing; Sun, 11 Jan 1998 02:30:25 -0800 (PST) (envelope-from owner-freebsd-current) Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA08676 for ; Sun, 11 Jan 1998 02:30:13 -0800 (PST) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.8.8/8.6.9) with ESMTP id LAA26754; Sun, 11 Jan 1998 11:19:55 +0100 (CET) Message-Id: <199801111019.LAA26754@peedub.muc.de> X-Mailer: exmh version 2.0.1 12/23/97 To: Andreas Klemm cc: current@FreeBSD.ORG Subject: Re: strange errors with -current, compile problems ... Reply-To: Gary Jennejohn In-reply-to: Your message of "Sun, 11 Jan 1998 00:53:57 +0100." <19980111005357.35018@klemm.gtn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jan 1998 11:19:54 +0100 From: Gary Jennejohn Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andreas Klemm writes: >I didn't get xmail compiled, imake terminated with signal 10 or >12. I could fix this only by doing a make world from -current >sources of last Monday. > >Now everything works fine again. > I had the same problem (imake core dumping). I had to switch to a kernel from before John Dyson's latest commits. I can't swear that John's changes are the cause because I didn't pursue it any further. I failed to "make world" after updating the kernel; this may be the cause of my problems. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com From owner-freebsd-current Sun Jan 11 04:12:23 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA18720 for current-outgoing; Sun, 11 Jan 1998 04:12:23 -0800 (PST) (envelope-from owner-freebsd-current) Received: from kong.dorms.spbu.ru (kong@kong.dorms.spbu.ru [195.19.252.147]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA18689 for ; Sun, 11 Jan 1998 04:11:59 -0800 (PST) (envelope-from kong@kkk.ml.org) Received: from localhost (kong@localhost) by kong.dorms.spbu.ru (8.8.8/kong/0.00) with SMTP id PAA00270 for ; Sun, 11 Jan 1998 15:11:39 +0300 (MSK) (envelope-from kong@kkk.ml.org) Date: Sun, 11 Jan 1998 15:11:39 +0300 (MSK) From: Hostas Red X-Sender: kong@kong.dorms.spbu.ru To: current@freebsd.org Subject: iOmega zip/ide problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! I have a problem: -current recognizes internal zip/ide(atapi) drive as wcd0 device (and now i have my cdrom as wcd1 :) and doesn't wants to mount with '-t msdos'. Is there any support for zip/ide at all? Adios, /KONG From owner-freebsd-current Sun Jan 11 06:19:16 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA27315 for current-outgoing; Sun, 11 Jan 1998 06:19:16 -0800 (PST) (envelope-from owner-freebsd-current) Received: from mail.tds.net (mail.tds.net [204.246.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA27308 for ; Sun, 11 Jan 1998 06:19:11 -0800 (PST) (envelope-from heraldiw@mail.tds.net) From: heraldiw@mail.tds.net Received: from user900.meznet5.net (brga1-a03.blrg.tds.net [207.49.210.196]) by mail.tds.net (8.8.5/8.8.8) with SMTP id IAA17916; Sun, 11 Jan 1998 08:17:03 -0600 (CST) Message-Id: <199801111417.IAA17916@mail.tds.net> To: ctransue@mkl.com Subject: Want to try something new? *! Reply-To: heraldiw@mail.tds.net Date: Fri, 8 Sep 97 14:24:52 EST Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk X-Info:Filtered Via The Remove List At http://www.antispam.org X-Info:Sent using Zen Bulk Emailer (FREE) X-Info:See End Of Email For Free Copy And Download Address If I could show how you can get a stream of instant lottery tickets FREE, would you be interested? If not, delete and I will never contact you again. But if FREE lottery tickests interests you, just go see for yourself how easy it is. No hype, just facts. Click on the following web URL address or cut and paste it to your web browser and press Enter. http://www.sunridge.net/index.phtml?id=73543 *** Get The Zen Bulk Emailer FREE - Where To Get it *** *** FAX/CALL +1 212 2082904 (US) or FAX +44 (01772) 492507 (UK) *** *** No Question, No Hard Sell, It's Freeware ! *** From owner-freebsd-current Sun Jan 11 07:22:56 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA00952 for current-outgoing; Sun, 11 Jan 1998 07:22:56 -0800 (PST) (envelope-from owner-freebsd-current) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA00946 for ; Sun, 11 Jan 1998 07:22:48 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id QAA21133 for freebsd-current@freebsd.org; Sun, 11 Jan 1998 16:22:46 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id QAA28341; Sun, 11 Jan 1998 16:20:15 +0100 (MET) Date: Sun, 11 Jan 1998 16:20:15 +0100 (MET) Message-Id: <199801111520.QAA28341@uriah.heep.sax.de> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Organization: Private BSD site, Dresden X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E References: <19980105091229.49254@uriah.heep.sax.de> In-Reply-To: From: j@uriah.heep.sax.de (J Wunsch) Subject: Re: New patch: one thing to think about X-Original-Newsgroups: local.freebsd.current To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= wrote: > I think Posix insist here on pure functionality separation as Unix > principle, i.e. making patch *is* main function of the "patch", but > producing backup *is not*. Well, but it's nevertheless silly of Posix. In order to really separate the functionality, you had to write another program besides patch that would walk through the diff, derive the pathnames to be patched the same way patch(1) would do, then make backup copies of all files. Obviously, those Posix people never had to use patch(1), or they wouldn't have come up with that nonsense. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Jan 11 10:07:27 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA19804 for current-outgoing; Sun, 11 Jan 1998 10:07:27 -0800 (PST) (envelope-from owner-freebsd-current) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA19582 for ; Sun, 11 Jan 1998 10:06:20 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id KAA14643 for ; Sun, 11 Jan 1998 10:06:19 -0800 (PST) (envelope-from jdp) Message-Id: <199801111806.KAA14643@austin.polstra.com> To: current@freebsd.org Subject: CVSup users: please upgrade to version 15.2 Date: Sun, 11 Jan 1998 10:06:19 -0800 From: John Polstra Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk CVSup users, please make sure you are using version 15.2 or later of CVSup. Version 15.2 is the current released version. It was released around the end of September, 1997. The wheels are being set in motion to convert the $Id$ strings in our repository files to $FreeBSD$. If you have an old version of CVSup, you are going to experience problems when this change occurs. The most likely symptom will be a whole slew of checksum mismatches on your updated files. To determine the version of CVSup that you are running, type "cvsup -v". The output should look like this: CVSup client Software version: REL_15_2 Protocol version: 15.4 If the software version doesn't say "REL_15_2" then you need to upgrade as soon as possible. You can do so with either the "cvsup" port/package or the "cvsup-bin" port/package, both of which are in the "net" category. Also, please check to make sure you don't have an old version of cvsup lying around in "/usr/local/sbin". The program belongs in "/usr/local/bin", but the earliest versions of it were installed in "/usr/local/sbin" due to a bad decision on my part. This has bitten a few people who thought they were up to date, but whose cron jobs were actually running the obsolete version. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Sun Jan 11 10:21:04 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA21671 for current-outgoing; Sun, 11 Jan 1998 10:21:04 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA21590 for ; Sun, 11 Jan 1998 10:20:25 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id NAA01653; Sun, 11 Jan 1998 13:19:38 -0500 (EST) (envelope-from toor) Message-Id: <199801111819.NAA01653@dyson.iquest.net> Subject: Re: strange errors with -current, compile problems ... In-Reply-To: <199801111019.LAA26754@peedub.muc.de> from Gary Jennejohn at "Jan 11, 98 11:19:54 am" To: garyj@muc.de Date: Sun, 11 Jan 1998 13:19:38 -0500 (EST) Cc: andreas@klemm.gtn.com, current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Gary Jennejohn said: > Andreas Klemm writes: > >I didn't get xmail compiled, imake terminated with signal 10 or > >12. I could fix this only by doing a make world from -current > >sources of last Monday. > > > >Now everything works fine again. > > > > I had the same problem (imake core dumping). I had to switch to a > kernel from before John Dyson's latest commits. I can't swear that > John's changes are the cause because I didn't pursue it any further. > > I failed to "make world" after updating the kernel; this may be the > cause of my problems. > For a *fun time*, try my patches against -current below :-). Let me know if things are any better (if you can)... I'll be committing a large part of them today/tonight. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. Index: i386/i386/pmap.c =================================================================== RCS file: /local/home/ncvs/src/sys/i386/i386/pmap.c,v retrieving revision 1.176 diff -C2 -r1.176 pmap.c *** pmap.c 1997/12/22 10:06:09 1.176 --- pmap.c 1998/01/11 09:06:50 *************** *** 414,418 **** /* 2 = local apic */ /* 16-31 = io apics */ ! SMP_prvpt[2] = (pt_entry_t)(PG_V | PG_RW | pgeflag | ((u_long)cpu_apic_address & PG_FRAME)); for (i = 0; i < mp_napics; i++) { --- 414,418 ---- /* 2 = local apic */ /* 16-31 = io apics */ ! SMP_prvpt[2] = (pt_entry_t)(PG_V | PG_RW | PG_G | ((u_long)cpu_apic_address & PG_FRAME)); for (i = 0; i < mp_napics; i++) { *************** *** 426,430 **** /* use this slot if available */ if (((u_long)SMP_prvpt[j + 16] & PG_FRAME) == 0) { ! SMP_prvpt[j + 16] = (pt_entry_t)(PG_V | PG_RW | pgeflag | ((u_long)io_apic_address[i] & PG_FRAME)); ioapic[i] = (ioapic_t *)&SMP_ioapic[j * PAGE_SIZE]; --- 426,430 ---- /* use this slot if available */ if (((u_long)SMP_prvpt[j + 16] & PG_FRAME) == 0) { ! SMP_prvpt[j + 16] = (pt_entry_t)(PG_V | PG_RW | PG_G | ((u_long)io_apic_address[i] & PG_FRAME)); ioapic[i] = (ioapic_t *)&SMP_ioapic[j * PAGE_SIZE]; *************** *** 929,939 **** --- 929,943 ---- panic("pmap_dispose_proc: upage already missing???"); *(ptek + i) = 0; + #if !defined(SMP) if (cpu_class >= CPUCLASS_586) invlpg((vm_offset_t) p->p_addr + i * PAGE_SIZE); + #endif vm_page_unwire(m); vm_page_free(m); } + #if defined(SMP) if (cpu_class < CPUCLASS_586) + #endif invltlb(); *************** *** 996,1005 **** m->flags |= PG_BUSY; } - vm_page_wire(m); splx(s); - pmap_kenter(((vm_offset_t) p->p_addr) + i * PAGE_SIZE, - VM_PAGE_TO_PHYS(m)); - if (m->valid != VM_PAGE_BITS_ALL) { int rv; --- 1000,1005 ---- *************** *** 1009,1015 **** --- 1009,1025 ---- m->valid = VM_PAGE_BITS_ALL; } + + vm_page_wire(m); + + pmap_kenter(((vm_offset_t) p->p_addr) + i * PAGE_SIZE, + VM_PAGE_TO_PHYS(m)); + if (cpu_class >= CPUCLASS_586) + invlpg((vm_offset_t) p->p_addr + i * PAGE_SIZE); + PAGE_WAKEUP(m); m->flags |= PG_MAPPED|PG_WRITEABLE; } + if (cpu_class < CPUCLASS_586) + invltlb(); } *************** *** 1932,1936 **** } if (!update_needed && ! ((!curproc || (&curproc->p_vmspace->vm_pmap == pv->pv_pmap)) || (pv->pv_pmap == kernel_pmap))) { update_needed = 1; --- 1942,1947 ---- } if (!update_needed && ! (((((unsigned)pv->pv_pmap->pm_pdir[PTDPTDI]) & PG_FRAME) == ! (((unsigned) PTDpde) & PG_FRAME)) || (pv->pv_pmap == kernel_pmap))) { update_needed = 1; *************** *** 1945,1951 **** ppv->pv_vm_page->flags &= ~(PG_MAPPED|PG_WRITEABLE); - if (update_needed) invltlb(); splx(s); return; --- 1956,1962 ---- ppv->pv_vm_page->flags &= ~(PG_MAPPED|PG_WRITEABLE); if (update_needed) invltlb(); + splx(s); return; Index: i386/isa/wd.c =================================================================== RCS file: /local/home/ncvs/src/sys/i386/isa/wd.c,v retrieving revision 1.146 diff -C2 -r1.146 wd.c *** wd.c 1997/12/06 14:27:20 1.146 --- wd.c 1998/01/11 07:09:00 *************** *** 206,210 **** --- 206,212 ---- int b_errcnt; int b_active; + int b_flags; /* flags for blocking concurrent opens */ } wdtab[NWDC]; + #define WDC_OPENING 0x1 struct wddma wddma[NWDC]; *************** *** 411,414 **** --- 413,418 ---- return (0); + bzero(&wdtab[dvp->id_unit], sizeof wdtab[dvp->id_unit]); + #ifdef CMD640 if (eide_quirks & Q_CMD640B) { *************** *** 431,434 **** --- 435,440 ---- continue; + bzero(&wdutab[lunit], sizeof wdutab[lunit]); + unit = wdup->id_physid; *************** *** 1066,1069 **** --- 1072,1076 ---- du = wddrives[dkunit(bp->b_dev)]; + dmastat = 0; /* finish off DMA */ if (du->dk_flags & (DKFL_DMA|DKFL_USEDMA)) { *************** *** 1279,1283 **** register unsigned int lunit; register struct disk *du; ! int error; lunit = dkunit(dev); --- 1286,1290 ---- register unsigned int lunit; register struct disk *du; ! int s, error, ctrlr; lunit = dkunit(dev); *************** *** 1288,1299 **** return (ENXIO); - /* Finish flushing IRQs left over from wdattach(). */ #ifdef CMD640 ! if (wdtab[du->dk_ctrlr_cmd640].b_active == 2) ! wdtab[du->dk_ctrlr_cmd640].b_active = 0; #else ! if (wdtab[du->dk_ctrlr].b_active == 2) ! wdtab[du->dk_ctrlr].b_active = 0; #endif du->dk_flags &= ~DKFL_BADSCAN; --- 1295,1313 ---- return (ENXIO); #ifdef CMD640 ! ctrlr = du->dk_ctrlr_cmd640; #else ! ctrlr = du->dk_ctrlr; #endif + s = splbio(); + while (wdtab[ctrlr].b_flags & WDC_OPENING) { + tsleep(&wdtab[ctrlr].b_flags, PRIBIO, "wdcopn", 10); + } + wdtab[ctrlr].b_flags |= WDC_OPENING; + splx(s); + + /* Finish flushing IRQs left over from wdattach(). */ + if (wdtab[ctrlr].b_active == 2) + wdtab[ctrlr].b_active = 0; du->dk_flags &= ~DKFL_BADSCAN; *************** *** 1321,1324 **** --- 1335,1341 ---- du->dk_flags &= ~DKFL_LABELLING; wdsleep(du->dk_ctrlr, "wdopn2"); + + wdtab[ctrlr].b_flags &= ~WDC_OPENING; + wakeup(&wdtab[ctrlr].b_flags); return (error); #else *************** *** 1340,1343 **** --- 1357,1362 ---- if (error != 0) { du->dk_flags &= ~DKFL_LABELLING; + wdtab[ctrlr].b_flags &= ~WDC_OPENING; + wakeup(&wdtab[ctrlr].b_flags); return (error); } *************** *** 1346,1349 **** --- 1365,1370 ---- if (dkslice(dev) == WHOLE_DISK_SLICE) { dsopen(dev, fmt, du->dk_slices); + wdtab[ctrlr].b_flags &= ~WDC_OPENING; + wakeup(&wdtab[ctrlr].b_flags); return (0); } *************** *** 1376,1381 **** log(LOG_WARNING, "wd%d: cannot find label (%s)\n", lunit, msg); ! if (part != RAW_PART) return (EINVAL); /* XXX needs translation */ /* * Soon return. This is how slices without labels --- 1397,1405 ---- log(LOG_WARNING, "wd%d: cannot find label (%s)\n", lunit, msg); ! if (part != RAW_PART) { ! wdtab[ctrlr].b_flags &= ~WDC_OPENING; ! wakeup(&wdtab[ctrlr].b_flags); return (EINVAL); /* XXX needs translation */ + } /* * Soon return. This is how slices without labels *************** *** 1439,1447 **** } } ! if (part >= du->dk_dd.d_npartitions && part != RAW_PART) return (ENXIO); dsopen(dev, fmt, du->dk_slices); return (0); #endif --- 1463,1476 ---- } } ! if (part >= du->dk_dd.d_npartitions && part != RAW_PART) { ! wdtab[ctrlr].b_flags &= ~WDC_OPENING; ! wakeup(&wdtab[ctrlr].b_flags); return (ENXIO); + } dsopen(dev, fmt, du->dk_slices); + wdtab[ctrlr].b_flags &= ~WDC_OPENING; + wakeup(&wdtab[ctrlr].b_flags); return (0); #endif Index: kern/imgact_aout.c =================================================================== RCS file: /local/home/ncvs/src/sys/kern/imgact_aout.c,v retrieving revision 1.37 diff -C2 -r1.37 imgact_aout.c *** imgact_aout.c 1998/01/06 05:15:25 1.37 --- imgact_aout.c 1998/01/07 07:45:43 *************** *** 37,40 **** --- 37,41 ---- #include #include + #include #include *************** *** 44,47 **** --- 45,49 ---- #include #include + #include #include *************** *** 54,58 **** const struct exec *a_out = (const struct exec *) imgp->image_header; struct vmspace *vmspace; ! vm_offset_t vmaddr; unsigned long virtual_offset; unsigned long file_offset; --- 56,62 ---- const struct exec *a_out = (const struct exec *) imgp->image_header; struct vmspace *vmspace; ! struct vnode *vp; ! vm_object_t object; ! vm_offset_t text_end, data_end; unsigned long virtual_offset; unsigned long file_offset; *************** *** 146,187 **** vmspace = imgp->proc->p_vmspace; ! /* ! * Map text/data read/execute ! */ ! vmaddr = virtual_offset; ! error = ! vm_mmap(&vmspace->vm_map, /* map */ ! &vmaddr, /* address */ ! a_out->a_text + a_out->a_data, /* size */ ! VM_PROT_READ | VM_PROT_EXECUTE, /* protection */ ! VM_PROT_ALL, /* max protection */ ! MAP_PRIVATE | MAP_FIXED, /* flags */ ! (caddr_t)imgp->vp, /* vnode */ ! file_offset); /* offset */ if (error) return (error); ! /* ! * allow writing of data ! */ ! vm_map_protect(&vmspace->vm_map, ! vmaddr + a_out->a_text, ! vmaddr + a_out->a_text + a_out->a_data, ! VM_PROT_ALL, ! FALSE); ! ! if (bss_size != 0) { ! /* ! * Allocate demand-zeroed area for uninitialized data ! * "bss" = 'block started by symbol' - named after the IBM 7090 ! * instruction of the same name. ! */ ! vmaddr = virtual_offset + a_out->a_text + a_out->a_data; ! error = vm_map_find(&vmspace->vm_map, NULL, 0, ! &vmaddr, bss_size, FALSE, VM_PROT_ALL, VM_PROT_ALL, 0); if (error) return (error); } /* Fill in process VM information */ vmspace->vm_tsize = a_out->a_text >> PAGE_SHIFT; --- 150,190 ---- vmspace = imgp->proc->p_vmspace; ! vp = imgp->vp; ! object = vp->v_object; ! vm_object_reference(object); ! ! text_end = virtual_offset + a_out->a_text; ! error = vm_map_insert(&vmspace->vm_map, object, ! file_offset, ! virtual_offset, text_end, ! VM_PROT_READ | VM_PROT_EXECUTE, VM_PROT_ALL, ! MAP_COPY_NEEDED | MAP_COPY_ON_WRITE); if (error) return (error); ! data_end = text_end + a_out->a_data; ! if (a_out->a_data) { ! vm_object_reference(object); ! error = vm_map_insert(&vmspace->vm_map, object, ! file_offset + a_out->a_text, ! text_end, data_end, ! VM_PROT_ALL, VM_PROT_ALL, ! MAP_COPY_NEEDED | MAP_COPY_ON_WRITE); if (error) return (error); } + pmap_object_init_pt(&vmspace->vm_pmap, virtual_offset, + object, (vm_pindex_t) OFF_TO_IDX(file_offset), + a_out->a_text + a_out->a_data, 0); + + if (bss_size) { + error = vm_map_insert(&vmspace->vm_map, NULL, 0, + data_end, data_end + bss_size, + VM_PROT_ALL, VM_PROT_ALL, 0); + if (error) + return (error); + } + /* Fill in process VM information */ vmspace->vm_tsize = a_out->a_text >> PAGE_SHIFT; Index: kern/kern_exec.c =================================================================== RCS file: /local/home/ncvs/src/sys/kern/kern_exec.c,v retrieving revision 1.73 diff -C2 -r1.73 kern_exec.c *** kern_exec.c 1998/01/06 05:15:34 1.73 --- kern_exec.c 1998/01/07 07:41:25 *************** *** 55,58 **** --- 55,59 ---- #include #include + #include #include #include *************** *** 60,63 **** --- 61,66 ---- #include #include + #include + #include #include *************** *** 65,69 **** static int *exec_copyout_strings __P((struct image_params *)); ! static int exec_check_permissions(struct image_params *); /* --- 68,74 ---- static int *exec_copyout_strings __P((struct image_params *)); ! static int exec_check_permissions __P((struct image_params *)); ! static int exec_map_first_page __P((struct image_params *)); ! static void exec_unmap_first_page __P((struct image_params *)); /* *************** *** 115,119 **** imgp->uap = uap; imgp->attr = &attr; - imgp->image_header = NULL; imgp->argc = imgp->envc = 0; imgp->argv0 = NULL; --- 120,123 ---- *************** *** 123,126 **** --- 127,132 ---- imgp->interpreter_name[0] = '\0'; imgp->auxargs = NULL; + imgp->vp = NULL; + imgp->firstpage = NULL; /* *************** *** 128,132 **** * environment strings */ ! imgp->stringbase = (char *)kmem_alloc_wait(exec_map, ARG_MAX); if (imgp->stringbase == NULL) { error = ENOMEM; --- 134,138 ---- * environment strings */ ! imgp->stringbase = (char *)kmem_alloc_wait(exec_map, ARG_MAX + PAGE_SIZE); if (imgp->stringbase == NULL) { error = ENOMEM; *************** *** 135,138 **** --- 141,145 ---- imgp->stringp = imgp->stringbase; imgp->stringspace = ARG_MAX; + imgp->image_header = imgp->stringbase + ARG_MAX; /* *************** *** 148,152 **** error = namei(ndp); if (error) { ! kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase, ARG_MAX); goto exec_fail; } --- 155,160 ---- error = namei(ndp); if (error) { ! kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase, ! ARG_MAX + PAGE_SIZE); goto exec_fail; } *************** *** 163,198 **** } ! /* ! * Get the image header, which we define here as meaning the first ! * page of the executable. ! */ ! if (imgp->vp->v_object && imgp->vp->v_mount && ! imgp->vp->v_mount->mnt_stat.f_iosize >= PAGE_SIZE && ! imgp->vp->v_object->un_pager.vnp.vnp_size >= ! imgp->vp->v_mount->mnt_stat.f_iosize) { ! /* ! * Get a buffer with (at least) the first page. ! */ ! error = bread(imgp->vp, 0, imgp->vp->v_mount->mnt_stat.f_iosize, ! p->p_ucred, &bp); ! imgp->image_header = bp->b_data; ! } else { ! int resid; ! ! /* ! * The filesystem block size is too small, so do this the hard ! * way. Malloc some space and read PAGE_SIZE worth of the image ! * header into it. ! */ ! imgp->image_header = malloc(PAGE_SIZE, M_TEMP, M_WAITOK); ! error = vn_rdwr(UIO_READ, imgp->vp, ! (void *)imgp->image_header, PAGE_SIZE, 0, ! UIO_SYSSPACE, IO_NODELOCKED, p->p_ucred, &resid, p); ! /* ! * Clear out any remaining junk. ! */ ! if (!error && resid) ! bzero((char *)imgp->image_header + PAGE_SIZE - resid, resid); ! } VOP_UNLOCK(imgp->vp, 0, p); if (error) --- 171,175 ---- } ! error = exec_map_first_page(imgp); VOP_UNLOCK(imgp->vp, 0, p); if (error) *************** *** 217,227 **** goto exec_fail_dealloc; if (imgp->interpreted) { ! /* free old bp/image_header */ ! if (bp != NULL) { ! brelse(bp); ! bp = NULL; ! } else ! free((void *)imgp->image_header, M_TEMP); ! imgp->image_header = NULL; /* free old vnode and name buffer */ vrele(ndp->ni_vp); --- 194,198 ---- goto exec_fail_dealloc; if (imgp->interpreted) { ! exec_unmap_first_page(imgp); /* free old vnode and name buffer */ vrele(ndp->ni_vp); *************** *** 352,375 **** setregs(p, imgp->entry_addr, (u_long)stack_base); /* * free various allocated resources */ ! kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase, ARG_MAX); ! if (bp != NULL) ! brelse(bp); ! else if (imgp->image_header != NULL) ! free((void *)imgp->image_header, M_TEMP); ! vrele(ndp->ni_vp); ! zfree(namei_zone, ndp->ni_cnd.cn_pnbuf); - return (0); - - exec_fail_dealloc: if (imgp->stringbase != NULL) ! kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase, ARG_MAX); ! if (bp != NULL) ! brelse(bp); ! else if (imgp->image_header != NULL) ! free((void *)imgp->image_header, M_TEMP); if (ndp->ni_vp) { vrele(ndp->ni_vp); --- 323,338 ---- setregs(p, imgp->entry_addr, (u_long)stack_base); + exec_fail_dealloc: + /* * free various allocated resources */ ! if (imgp->firstpage) ! exec_unmap_first_page(imgp); if (imgp->stringbase != NULL) ! kmem_free_wakeup(exec_map, (vm_offset_t)imgp->stringbase, ! ARG_MAX + PAGE_SIZE); ! if (ndp->ni_vp) { vrele(ndp->ni_vp); *************** *** 377,380 **** --- 340,346 ---- } + if (error == 0) + return (0); + exec_fail: if (imgp->vmspace_destroyed) { *************** *** 388,391 **** --- 354,422 ---- } + int + exec_map_first_page(imgp) + struct image_params *imgp; + { + int s; + vm_page_t m; + vm_object_t object; + + + if (imgp->firstpage) { + exec_unmap_first_page(imgp); + } + + object = imgp->vp->v_object; + s = splvm(); + + retry: + m = vm_page_lookup(object, 0); + if (m == NULL) { + m = vm_page_alloc(object, 0, VM_ALLOC_NORMAL); + if (m == NULL) { + VM_WAIT; + goto retry; + } + } else if ((m->flags & PG_BUSY) || m->busy) { + m->flags |= PG_WANTED; + tsleep(m, PVM, "execpw", 0); + goto retry; + } + + m->flags |= PG_BUSY; + + if ((m->valid & VM_PAGE_BITS_ALL) != VM_PAGE_BITS_ALL) { + int rv; + rv = vm_pager_get_pages(object, &m, 1, 0); + if (rv != VM_PAGER_OK) { + vm_page_protect(m, VM_PROT_NONE); + vm_page_deactivate(m); + PAGE_WAKEUP(m); + splx(s); + return EIO; + } + } + + vm_page_wire(m); + PAGE_WAKEUP(m); + splx(s); + + pmap_kenter((vm_offset_t) imgp->image_header, VM_PAGE_TO_PHYS(m)); + imgp->firstpage = m; + + return 0; + } + + void + exec_unmap_first_page(imgp) + struct image_params *imgp; + { + if (imgp->firstpage) { + pmap_kremove((vm_offset_t) imgp->image_header); + vm_page_unwire(imgp->firstpage); + imgp->firstpage = NULL; + } + } + /* * Destroy old address space, and allocate a new stack *************** *** 421,428 **** /* Allocate a new stack */ ! error = vm_map_find(map, NULL, 0, (vm_offset_t *)&stack_addr, ! SGROWSIZ, FALSE, VM_PROT_ALL, VM_PROT_ALL, 0); if (error) ! return(error); vmspace->vm_ssize = SGROWSIZ >> PAGE_SHIFT; --- 452,460 ---- /* Allocate a new stack */ ! error = vm_map_insert(&vmspace->vm_map, NULL, 0, ! (vm_offset_t) stack_addr, (vm_offset_t) USRSTACK, ! VM_PROT_ALL, VM_PROT_ALL, 0); if (error) ! return (error); vmspace->vm_ssize = SGROWSIZ >> PAGE_SHIFT; Index: kern/vfs_subr.c =================================================================== RCS file: /local/home/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.121 diff -C2 -r1.121 vfs_subr.c *** vfs_subr.c 1998/01/07 09:26:29 1.121 --- vfs_subr.c 1998/01/11 04:48:53 *************** *** 108,112 **** SYSCTL_INT(_debug, OID_AUTO, freevnodes, CTLFLAG_RD, &freevnodes, 0, ""); ! int vfs_ioopt = 0; SYSCTL_INT(_vfs, OID_AUTO, ioopt, CTLFLAG_RW, &vfs_ioopt, 0, ""); --- 108,112 ---- SYSCTL_INT(_debug, OID_AUTO, freevnodes, CTLFLAG_RD, &freevnodes, 0, ""); ! int vfs_ioopt = 2; SYSCTL_INT(_vfs, OID_AUTO, ioopt, CTLFLAG_RW, &vfs_ioopt, 0, ""); *************** *** 351,356 **** struct vnode **vpp; { struct proc *p = curproc; /* XXX */ ! struct vnode *vp, *tvp; vm_object_t object; TAILQ_HEAD(freelst, vnode) vnode_tmp_list; --- 351,357 ---- struct vnode **vpp; { + int s; struct proc *p = curproc; /* XXX */ ! struct vnode *vp, *tvp, *nvp; vm_object_t object; TAILQ_HEAD(freelst, vnode) vnode_tmp_list; *************** *** 363,366 **** --- 364,368 ---- */ + s = splbio(); simple_lock(&vnode_free_list_slock); TAILQ_INIT(&vnode_tmp_list); *************** *** 374,378 **** vp = NULL; } else { ! TAILQ_FOREACH(vp, &vnode_free_list, v_freelist) { if (!simple_lock_try(&vp->v_interlock)) continue; --- 376,383 ---- vp = NULL; } else { ! for (vp = TAILQ_FIRST(&vnode_free_list); vp; vp = nvp) { ! ! nvp = TAILQ_NEXT(vp, v_freelist); ! if (!simple_lock_try(&vp->v_interlock)) continue; *************** *** 396,400 **** } ! TAILQ_FOREACH(tvp, &vnode_tmp_list, v_freelist) { TAILQ_REMOVE(&vnode_tmp_list, tvp, v_freelist); TAILQ_INSERT_TAIL(&vnode_free_list, tvp, v_freelist); --- 401,406 ---- } ! for (tvp = TAILQ_FIRST(&vnode_tmp_list); tvp; tvp = nvp) { ! nvp = TAILQ_NEXT(tvp, v_freelist); TAILQ_REMOVE(&vnode_tmp_list, tvp, v_freelist); TAILQ_INSERT_TAIL(&vnode_free_list, tvp, v_freelist); *************** *** 455,458 **** --- 461,465 ---- vp->v_usecount = 1; vp->v_data = 0; + splx(s); return (0); } *************** *** 1417,1421 **** if (vp->v_usecount == 0 && !(vp->v_flag & VDOOMED)) { simple_lock(&vnode_free_list_slock); ! TAILQ_REMOVE(&vnode_free_list, vp, v_freelist); TAILQ_INSERT_HEAD(&vnode_free_list, vp, v_freelist); simple_unlock(&vnode_free_list_slock); --- 1424,1430 ---- if (vp->v_usecount == 0 && !(vp->v_flag & VDOOMED)) { simple_lock(&vnode_free_list_slock); ! if (vp->v_flag & VFREE) { ! TAILQ_REMOVE(&vnode_free_list, vp, v_freelist); ! } TAILQ_INSERT_HEAD(&vnode_free_list, vp, v_freelist); simple_unlock(&vnode_free_list_slock); Index: kern/vfs_vnops.c =================================================================== RCS file: /local/home/ncvs/src/sys/kern/vfs_vnops.c,v retrieving revision 1.46 diff -C2 -r1.46 vfs_vnops.c *** vfs_vnops.c 1998/01/06 05:16:32 1.46 --- vfs_vnops.c 1998/01/11 06:26:07 *************** *** 512,518 **** vp->v_flag |= VXWANT; simple_unlock(&vp->v_interlock); ! if (tsleep((caddr_t)vp, PINOD, "vn_lock", 120*hz)) { ! vprint("vn_lock: timeout:", vp); ! } error = ENOENT; } else { --- 512,516 ---- vp->v_flag |= VXWANT; simple_unlock(&vp->v_interlock); ! tsleep((caddr_t)vp, PINOD, "vn_lock", 0); error = ENOENT; } else { Index: sys/imgact.h =================================================================== RCS file: /local/home/ncvs/src/sys/sys/imgact.h,v retrieving revision 1.15 diff -C2 -r1.15 imgact.h *** imgact.h 1997/04/23 22:02:37 1.15 --- imgact.h 1998/01/07 07:41:39 *************** *** 53,56 **** --- 53,57 ---- char interpreter_name[64]; /* name of the interpreter */ void *auxargs; /* ELF Auxinfo structure pointer */ + struct vm_page *firstpage; /* first page that we mapped */ }; Index: sys/vnode.h =================================================================== RCS file: /local/home/ncvs/src/sys/sys/vnode.h,v retrieving revision 1.63 diff -C2 -r1.63 vnode.h *** vnode.h 1998/01/06 05:23:04 1.63 --- vnode.h 1998/01/07 05:55:19 *************** *** 274,285 **** extern void (*lease_updatetime) __P((int deltat)); #define VSHOULDFREE(vp) \ (!((vp)->v_flag & (VFREE|VDOOMED)) && \ !(vp)->v_holdcnt && !(vp)->v_usecount) #define VSHOULDBUSY(vp) \ (((vp)->v_flag & VFREE) && \ ((vp)->v_holdcnt || (vp)->v_usecount)) - #endif /* KERNEL */ --- 274,292 ---- extern void (*lease_updatetime) __P((int deltat)); + #if 1 + #define VSHOULDFREE(vp) \ + (!((vp)->v_flag & (VFREE|VDOOMED)) && \ + !(vp)->v_holdcnt && !(vp)->v_usecount && \ + (!(vp)->v_object || \ + !((vp)->v_object->ref_count || (vp)->v_object->resident_page_count))) + #else #define VSHOULDFREE(vp) \ (!((vp)->v_flag & (VFREE|VDOOMED)) && \ !(vp)->v_holdcnt && !(vp)->v_usecount) + #endif #define VSHOULDBUSY(vp) \ (((vp)->v_flag & VFREE) && \ ((vp)->v_holdcnt || (vp)->v_usecount)) #endif /* KERNEL */ Index: vm/vm_fault.c =================================================================== RCS file: /local/home/ncvs/src/sys/vm/vm_fault.c,v retrieving revision 1.73 diff -C2 -r1.73 vm_fault.c *** vm_fault.c 1998/01/06 05:25:54 1.73 --- vm_fault.c 1998/01/06 08:05:58 *************** *** 524,529 **** --- 524,531 ---- } + #if defined(DIAGNOSTIC) if ((m->flags & PG_BUSY) == 0) panic("vm_fault: not busy after main loop"); + #endif /* Index: vm/vm_map.c =================================================================== RCS file: /local/home/ncvs/src/sys/vm/vm_map.c,v retrieving revision 1.104 diff -C2 -r1.104 vm_map.c *** vm_map.c 1998/01/06 05:25:58 1.104 --- vm_map.c 1998/01/11 04:43:10 *************** *** 2406,2410 **** } ! if (entry->object.vm_object != NULL) default_pager_convert_to_swapq(entry->object.vm_object); /* --- 2406,2410 ---- } ! if (entry->object.vm_object->type == OBJT_DEFAULT) default_pager_convert_to_swapq(entry->object.vm_object); /* *************** *** 2480,2493 **** vm_pindex_t first_pindex, osize, oindex; off_t ooffset; if (npages) *npages = 0; while (cnt > 0) { map = mapa; uaddr = uaddra; if ((vm_map_lookup(&map, uaddr, ! VM_PROT_READ|VM_PROT_WRITE, &first_entry, &first_object, &first_pindex, &prot, &wired, &su)) != KERN_SUCCESS) { return EFAULT; --- 2480,2497 ---- vm_pindex_t first_pindex, osize, oindex; off_t ooffset; + int skipinit, allremoved; if (npages) *npages = 0; + allremoved = 0; + while (cnt > 0) { map = mapa; uaddr = uaddra; + skipinit = 0; if ((vm_map_lookup(&map, uaddr, ! VM_PROT_READ, &first_entry, &first_object, &first_pindex, &prot, &wired, &su)) != KERN_SUCCESS) { return EFAULT; *************** *** 2507,2521 **** osize = atop(tcnt); if (npages) { ! vm_pindex_t src_index, idx; ! src_index = OFF_TO_IDX(cp); for (idx = 0; idx < osize; idx++) { vm_page_t m; ! if ((m = vm_page_lookup(srcobject, src_index + idx)) == NULL) { vm_map_lookup_done(map, first_entry); return 0; } ! if ((m->flags & PG_BUSY) || m->busy || ! m->hold_count || m->wire_count || ((m->valid & VM_PAGE_BITS_ALL) != VM_PAGE_BITS_ALL)) { vm_map_lookup_done(map, first_entry); --- 2511,2524 ---- osize = atop(tcnt); + oindex = OFF_TO_IDX(cp); if (npages) { ! vm_pindex_t idx; for (idx = 0; idx < osize; idx++) { vm_page_t m; ! if ((m = vm_page_lookup(srcobject, oindex + idx)) == NULL) { vm_map_lookup_done(map, first_entry); return 0; } ! if ((m->flags & PG_BUSY) || ((m->valid & VM_PAGE_BITS_ALL) != VM_PAGE_BITS_ALL)) { vm_map_lookup_done(map, first_entry); *************** *** 2525,2554 **** } - oindex = OFF_TO_IDX(first_entry->offset); - /* * If we are changing an existing map entry, just redirect * the object, and change mappings. */ ! if ((first_object->ref_count == 1) && ! (first_object->backing_object == srcobject) && (first_object->size == osize) && (first_object->resident_page_count == 0)) { ! /* ! * Remove old window into the file ! */ ! pmap_remove (map->pmap, start, end); ! ! /* ! * Force copy on write for mmaped regions ! */ ! vm_object_pmap_copy_1 (first_object, ! oindex, oindex + osize); ! /* ! * Point the object appropriately ! */ ! first_object->backing_object_offset = cp; /* * Otherwise, we have to do a logical mmap. --- 2528,2625 ---- } /* * If we are changing an existing map entry, just redirect * the object, and change mappings. */ ! if (first_object->type == OBJT_VNODE) { ! ! if (first_object != srcobject) { ! ! vm_object_deallocate(first_object); ! srcobject->flags |= OBJ_OPT; ! vm_object_reference(srcobject); ! ! first_entry->object.vm_object = srcobject; ! first_entry->offset = cp; ! ! } else if (first_entry->offset != cp) { ! ! first_entry->offset = cp; ! ! } else { ! ! skipinit = 1; ! ! } ! ! if (skipinit == 0) { ! /* ! * Remove old window into the file ! */ ! if (!allremoved) { ! pmap_remove (map->pmap, uaddra, uaddra + cnt); ! allremoved = 1; ! } ! ! /* ! * Force copy on write for mmaped regions ! */ ! vm_object_pmap_copy_1 (srcobject, ! oindex, oindex + osize); ! } ! ! } else if ((first_object->ref_count == 1) && (first_object->size == osize) && (first_object->resident_page_count == 0)) { + vm_object_t oldobject; ! oldobject = first_object->backing_object; ! ! if ((first_object->backing_object_offset != cp) || ! (oldobject != srcobject)) { ! /* ! * Remove old window into the file ! */ ! if (!allremoved) { ! pmap_remove (map->pmap, uaddra, uaddra + cnt); ! allremoved = 1; ! } ! ! /* ! * Force copy on write for mmaped regions ! */ ! vm_object_pmap_copy_1 (srcobject, ! oindex, oindex + osize); ! ! /* ! * Point the object appropriately ! */ ! if (oldobject != srcobject) { ! /* ! * Set the object optimization hint flag ! */ ! srcobject->flags |= OBJ_OPT; ! vm_object_reference(srcobject); ! ! if (oldobject) { ! TAILQ_REMOVE(&oldobject->shadow_head, ! first_object, shadow_list); ! oldobject->shadow_count--; ! if (oldobject->shadow_count == 0) ! oldobject->flags &= ~OBJ_OPT; ! vm_object_deallocate(oldobject); ! } ! ! TAILQ_INSERT_TAIL(&srcobject->shadow_head, ! first_object, shadow_list); ! srcobject->shadow_count++; ! ! first_object->backing_object = srcobject; ! } ! first_object->backing_object_offset = cp; ! } else { ! skipinit = 1; ! } /* * Otherwise, we have to do a logical mmap. *************** *** 2556,2568 **** } else { ! object = srcobject; ! object->flags |= OBJ_OPT; ! vm_object_reference(object); ! ooffset = cp; ! ! vm_object_shadow(&object, &ooffset, osize); ! pmap_remove (map->pmap, start, end); ! vm_object_pmap_copy_1 (first_object, oindex, oindex + osize); vm_map_lookup_done(map, first_entry); --- 2627,2638 ---- } else { ! srcobject->flags |= OBJ_OPT; ! vm_object_reference(srcobject); ! if (!allremoved) { ! pmap_remove (map->pmap, uaddra, uaddra + cnt); ! allremoved = 1; ! } ! vm_object_pmap_copy_1 (srcobject, oindex, oindex + osize); vm_map_lookup_done(map, first_entry); *************** *** 2579,2584 **** vm_map_entry_delete(map, first_entry); ! rv = vm_map_insert(map, object, 0, start, end, ! VM_PROT_ALL, VM_PROT_ALL, MAP_COPY_ON_WRITE); if (rv != KERN_SUCCESS) --- 2649,2654 ---- vm_map_entry_delete(map, first_entry); ! rv = vm_map_insert(map, srcobject, cp, start, end, ! VM_PROT_ALL, VM_PROT_ALL, MAP_COPY_ON_WRITE | MAP_COPY_NEEDED); if (rv != KERN_SUCCESS) *************** *** 2589,2594 **** * Map the window directly, if it is already in memory */ ! pmap_object_init_pt(map->pmap, start, ! srcobject, (vm_pindex_t) OFF_TO_IDX(cp), end - start, 1); vm_map_unlock(map); --- 2659,2665 ---- * Map the window directly, if it is already in memory */ ! if (!skipinit) ! pmap_object_init_pt(map->pmap, start, ! srcobject, (vm_pindex_t) OFF_TO_IDX(cp), end - start, 0); vm_map_unlock(map); *************** *** 2664,2671 **** --- 2735,2746 ---- vm_object_reference(robject); + + s = splvm(); while (robject->paging_in_progress) { robject->flags |= OBJ_PIPWNT; tsleep(robject, PVM, "objfrz", 0); } + splx(s); + if (robject->ref_count == 1) { vm_object_deallocate(robject); *************** *** 2691,2695 **** if( m_in->flags & PG_BUSY) { ! s = splhigh(); while (m_in && (m_in->flags & PG_BUSY)) { m_in->flags |= PG_WANTED; --- 2766,2770 ---- if( m_in->flags & PG_BUSY) { ! s = splvm(); while (m_in && (m_in->flags & PG_BUSY)) { m_in->flags |= PG_WANTED; *************** *** 2706,2710 **** m_out = vm_page_lookup(robject, dstpindex); if( m_out && (m_out->flags & PG_BUSY)) { ! s = splhigh(); while (m_out && (m_out->flags & PG_BUSY)) { m_out->flags |= PG_WANTED; --- 2781,2785 ---- m_out = vm_page_lookup(robject, dstpindex); if( m_out && (m_out->flags & PG_BUSY)) { ! s = splvm(); while (m_out && (m_out->flags & PG_BUSY)) { m_out->flags |= PG_WANTED; *************** *** 2734,2737 **** --- 2809,2813 ---- if (((from - bo_pindex) == 0) && ((to - bo_pindex) == robject->size)) { + object->shadow_count--; Index: vm/vm_object.c =================================================================== RCS file: /local/home/ncvs/src/sys/vm/vm_object.c,v retrieving revision 1.105 diff -C2 -r1.105 vm_object.c *** vm_object.c 1998/01/07 03:12:19 1.105 --- vm_object.c 1998/01/11 07:56:56 *************** *** 333,336 **** --- 333,337 ---- robject->flags |= OBJ_PIPWNT; tsleep(robject, PVM, "objde1", 0); + splx(s); goto retry; } *************** *** 339,342 **** --- 340,344 ---- object->flags |= OBJ_PIPWNT; tsleep(object, PVM, "objde2", 0); + splx(s); goto retry; } Index: vm/vm_page.c =================================================================== RCS file: /local/home/ncvs/src/sys/vm/vm_page.c,v retrieving revision 1.84 diff -C2 -r1.84 vm_page.c *** vm_page.c 1997/12/29 00:24:58 1.84 --- vm_page.c 1998/01/11 07:59:09 *************** *** 754,757 **** --- 754,758 ---- register vm_page_t m; struct vpgqueues *pq; + vm_object_t oldobject; int queue, qtype; int s; *************** *** 862,868 **** --- 863,871 ---- --(*pq->cnt); --(*pq->lcnt); + oldobject = NULL; if (qtype == PQ_ZERO) { m->flags = PG_ZERO|PG_BUSY; } else if (qtype == PQ_CACHE) { + oldobject = m->object; vm_page_remove(m); m->flags = PG_BUSY; *************** *** 892,895 **** --- 895,911 ---- pagedaemon_wakeup(); + if (((page_req == VM_ALLOC_NORMAL) || (page_req == VM_ALLOC_ZERO)) && + oldobject && + ((oldobject->type == OBJT_VNODE) && + (oldobject->ref_count == 0) && + (oldobject->resident_page_count == 0))) { + struct vnode *vp; + vp = (struct vnode *) oldobject->handle; + if (VSHOULDFREE(vp)) { + vm_object_reference(oldobject); + vm_object_vndeallocate(oldobject); + } + } + return (m); } *************** *** 955,958 **** --- 971,975 ---- vm_page_t m; { + #if !defined(MAX_PERF) if (m->busy || (m->flags & PG_BUSY) || *************** *** 967,970 **** --- 984,988 ---- panic("vm_page_free: freeing busy page"); } + #endif vm_page_remove(m); Index: vm/vm_pageout.c =================================================================== RCS file: /local/home/ncvs/src/sys/vm/vm_pageout.c,v retrieving revision 1.106 diff -C2 -r1.106 vm_pageout.c *** vm_pageout.c 1998/01/06 05:26:11 1.106 --- vm_pageout.c 1998/01/07 02:36:12 *************** *** 593,596 **** --- 593,614 ---- #endif + void + vm_pageout_page_free(vm_page_t m) { + vm_object_t objref = NULL; + + m->flags |= PG_BUSY; + if (m->object->type == OBJT_VNODE) { + objref = m->object; + vm_object_reference(objref); + } + vm_page_protect(m, VM_PROT_NONE); + PAGE_WAKEUP(m); + vm_page_free(m); + cnt.v_dfree++; + if (objref) { + vm_object_vndeallocate(objref); + } + } + /* * vm_pageout_scan does the dirty work for the pageout daemon. *************** *** 717,723 **** */ if (m->valid == 0) { ! vm_page_protect(m, VM_PROT_NONE); ! vm_page_free(m); ! cnt.v_dfree++; ++pages_freed; --- 735,739 ---- */ if (m->valid == 0) { ! vm_pageout_page_free(m); ++pages_freed; *************** *** 954,959 **** break; cache_rover = (cache_rover + PQ_PRIME2) & PQ_L2_MASK; ! vm_page_free(m); ! cnt.v_dfree++; } splx(s); --- 970,974 ---- break; cache_rover = (cache_rover + PQ_PRIME2) & PQ_L2_MASK; ! vm_pageout_page_free(m); } splx(s); Index: vm/vm_pageout.h =================================================================== RCS file: /local/home/ncvs/src/sys/vm/vm_pageout.h,v retrieving revision 1.21 diff -C2 -r1.21 vm_pageout.h *** vm_pageout.h 1997/12/06 02:23:36 1.21 --- vm_pageout.h 1998/01/06 20:46:59 *************** *** 106,109 **** --- 106,110 ---- void vm_pageout_cluster __P((vm_page_t, vm_object_t)); int vm_pageout_flush __P((vm_page_t *, int, int)); + void vm_pageout_page_free __P((vm_page_t)); #endif From owner-freebsd-current Sun Jan 11 11:30:02 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA27932 for current-outgoing; Sun, 11 Jan 1998 11:30:02 -0800 (PST) (envelope-from owner-freebsd-current) Received: from kong.dorms.spbu.ru (root@kong.dorms.spbu.ru [195.19.252.147]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA27868 for ; Sun, 11 Jan 1998 11:29:53 -0800 (PST) (envelope-from kong@kkk.ml.org) Received: from localhost (kong@localhost) by kong.dorms.spbu.ru (8.8.8/kong/0.00) with SMTP id WAA02252 for ; Sun, 11 Jan 1998 22:10:03 +0300 (MSK) (envelope-from kong@kkk.ml.org) Date: Sun, 11 Jan 1998 22:10:02 +0300 (MSK) From: Hostas Red X-Sender: kong@kong.dorms.spbu.ru To: current@freebsd.org Subject: cvs broken? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! What can that be? It doesn't work anymore. ========= ... ========= Edit src/usr.sbin/ppp/vjcomp.h Add delta 1.5 98.01.11.17.50.49 brian Updater failed: Protocol error: Short counted file attribute ========= 8< ========== Next time: ========= ... ========= Running Updating collection src-all/cvs Updater failed: Protocol error: Short counted file attribute ========= 8< ========== This is from cvsup.freebsd.org. Adios, /KONG From owner-freebsd-current Sun Jan 11 12:18:04 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02370 for current-outgoing; Sun, 11 Jan 1998 12:18:04 -0800 (PST) (envelope-from owner-freebsd-current) Received: from bubble.didi.com (sjx-ca124-37.ix.netcom.com [207.223.162.165]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA02238 for ; Sun, 11 Jan 1998 12:16:54 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by bubble.didi.com (8.8.7/8.8.8) id MAA00716; Sun, 11 Jan 1998 12:04:53 -0800 (PST) (envelope-from asami) Date: Sun, 11 Jan 1998 12:04:53 -0800 (PST) Message-Id: <199801112004.MAA00716@bubble.didi.com> To: current@FreeBSD.ORG In-reply-to: (message from Simon Shapiro on Sat, 10 Jan 1998 20:07:39 -0800 (PST)) Subject: Re: Firewall in kernel? - Found it! From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Listen guys, we've been over this over and over before. Check the mailing list archives for all the wonderful arguments we had in the past. Really, it's quite simple. If you change a header file, do a complete buildworld. Otherwise, just recompile that program. The tree might still have a minor breakage from time to time, but we're talking -current hee. Satoshi From owner-freebsd-current Sun Jan 11 12:18:07 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02377 for current-outgoing; Sun, 11 Jan 1998 12:18:07 -0800 (PST) (envelope-from owner-freebsd-current) Received: from bubble.didi.com (sjx-ca124-37.ix.netcom.com [207.223.162.165]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA02286; Sun, 11 Jan 1998 12:17:28 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by bubble.didi.com (8.8.7/8.8.8) id KAA00607; Sun, 11 Jan 1998 10:57:03 -0800 (PST) (envelope-from asami) Date: Sun, 11 Jan 1998 10:57:03 -0800 (PST) Message-Id: <199801111857.KAA00607@bubble.didi.com> To: ache@nagual.pp.ru, mike@smith.net.au, current@FreeBSD.ORG, peter@FreeBSD.ORG In-reply-to: <19980110195007.31038@uriah.heep.sax.de> (message from J Wunsch on Sat, 10 Jan 1998 19:50:07 +0100) Subject: Re: CVS DIFF fix for review (-L added) From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk * From: J Wunsch * Also, i'm not sure, but IMHO the Index: lines should be dropped then. * They are obsolete at best, and confusing at worst. Please keep them if they are correct. They make it easy to get a list of changed files. Satoshi From owner-freebsd-current Sun Jan 11 12:36:43 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04003 for current-outgoing; Sun, 11 Jan 1998 12:36:43 -0800 (PST) (envelope-from owner-freebsd-current) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA03989 for ; Sun, 11 Jan 1998 12:36:34 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id XAA17338; Sun, 11 Jan 1998 23:35:41 +0300 (MSK) (envelope-from ache) Date: Sun, 11 Jan 1998 23:35:40 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Peter Wemm cc: FreeBSD-current , Joerg Wunsch Subject: Re: CVS DIFF fix for review (-L added) In-Reply-To: <199801111457.WAA06475@spinner.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 11 Jan 1998, Peter Wemm wrote: > > BTW, do you still against applying the fix into -current and -stable > > cvs (which 'cvs diff' remains broken)? > > If you can convince the info-cvs folks to make the changes, then I'll go > along. Otherwise, IMHO the new patch and/or "standard" is busted. It > wouldn't be the first time that POSIX have screwed something up. CVS and > patch have been doing it like this since as far back as 1993. Please, note that it _not_ POSIX invention, POSIX just document _existent_practice_ for years! GNU "patch" (_any_ version!) _never_ have Index: precedence, so CVS code in question _never_ works with GNU "patch" and was broken at the first moment as designed. BTW, I have no reply at this moment from CVS folks (I not subscribed to info-cvs), did you? What we plan to do if no reply comes? Leave it broken? -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Sun Jan 11 13:55:29 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA10473 for current-outgoing; Sun, 11 Jan 1998 13:55:29 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alushta.NL.net (alushta.NL.net [193.78.240.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA10392 for ; Sun, 11 Jan 1998 13:54:11 -0800 (PST) (envelope-from benst@terminus.stuyts.nl) Received: from stuyts by alushta.NL.net with UUCP id <3772-10704>; Sun, 11 Jan 1998 22:54:02 +0100 Received: from daneel.stuyts.nl (daneel.stuyts.nl [193.78.231.7]) by terminus.stuyts.nl (8.8.8/8.8.8) with ESMTP id WAA00541 for ; Sun, 11 Jan 1998 22:44:05 +0100 (MET) (envelope-from benst) Received: (from benst@localhost) by daneel.stuyts.nl (8.8.5/8.8.5) id WAA11069 for current@FreeBSD.ORG; Sun, 11 Jan 1998 22:43:37 +0100 (MET) Message-Id: <199801112143.WAA11069@daneel.stuyts.nl> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) X-Nextstep-Mailer: Mail 3.3 (Enhance 1.2) Received: by NeXT.Mailer (1.118.2) From: Ben Stuyts Date: Sun, 11 Jan 98 22:43:35 +0100 To: current@FreeBSD.ORG Subject: Performance problems/hangs with today's build Reply-To: ben@stuyts.nl Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I finally managed to make world and a new kernel today, but there is something seriously wrong. First my system: It is a Gigabyte 586DX dual P166 MMX with 64 MB ram. (I tried a non-SMP kernel: same problems.) A couple of the problems: 1. Various 'tail -f xxxx' that I have running in xterms, fail to update after some time. Killing and restarting them works for a while, but then the same thing happens. 2. I run afterstep as wm, and the clock in wharf stops after some time. 3. Same thing with top. No more updates, though 'q'uit works. 4. Reading news with trn to a local nntp, sometimes takes a long time to fetch an article. 5. nfs from a NeXT box to the FreeBSD machine sometimes takes ages. 6. If I start the rc5 crack program, the whole system becomes sluggish. The mouse (on psm0, logitech 3-button) moves extremely jerky, like only twice a second. 7. Building a kernel with AHC_TAGENABLE, AHC_SCBPAGING_ENABLE and AHC_ALLOW_MEMIO will hang the system. Sometimes a see SCB paging messages in the console, sometimes the system completely hangs; ctl-alt-delete doesn't work. Unfortunately nothing in /var/messages. The motherboard has a 7880 on-board, and the drives are: sd0 at scbus0 target 1 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 4134MB (8467200 512 byte sectors) sd0: with 8205 cyls, 6 heads, and an average 171 sectors/track sd1 at scbus0 target 3 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access 810MB (1660299 512 byte sectors) sd1: with 3653 cyls, 4 heads, and an average 113 sectors/track cd0 at scbus0 target 4 lun 0 cd0: type 5 removable SCSI 2 cd0: CD-ROM can't get the size worm0 at scbus0 target 5 lun 0 worm0: type 5 removable SCSI 2 worm0: Write-Once I booted with an old kernel (18-nov-97) and that runs fine. (Top can't run because of proc size mismatches etc, but at least that can be explained.) I updated/checked my /etc for any problems, but I think I'm all right there. I've ran current quite successful over the last months, is it just a bad time to build today, or have I missed something? I looked over the past few days of messages in this list but couldn't find anybody else with such severe problems. Thanks, Ben From owner-freebsd-current Sun Jan 11 14:28:17 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA12996 for current-outgoing; Sun, 11 Jan 1998 14:28:17 -0800 (PST) (envelope-from owner-freebsd-current) Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA12810 for ; Sun, 11 Jan 1998 14:26:54 -0800 (PST) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.8.8/8.6.9) with ESMTP id XAA00399 for ; Sun, 11 Jan 1998 23:26:13 +0100 (CET) Message-Id: <199801112226.XAA00399@peedub.muc.de> X-Mailer: exmh version 2.0.1 12/23/97 To: freebsd-current@freebsd.org Subject: Re: strange errors with -current, compile problems ... Reply-To: Gary Jennejohn In-reply-to: Your message of "Sun, 11 Jan 1998 19:19:38 +0100." <199801111819.NAA01653@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jan 1998 23:26:13 +0100 From: Gary Jennejohn Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "John S. Dyson" writes: >Gary Jennejohn said: >> Andreas Klemm writes: >> >I didn't get xmail compiled, imake terminated with signal 10 or >> >12. I could fix this only by doing a make world from -current >> >sources of last Monday. >> > >> >Now everything works fine again. >> > >> >> I had the same problem (imake core dumping). I had to switch to a >> kernel from before John Dyson's latest commits. I can't swear that >> John's changes are the cause because I didn't pursue it any further. >> >> I failed to "make world" after updating the kernel; this may be the >> cause of my problems. >> >For a *fun time*, try my patches against -current below :-). Let me >know if things are any better (if you can)... I'll be committing >a large part of them today/tonight. > [patches deleted] well, they applied cleanly :) But they didn't help. imake dies with a SIGBUS. Seems to me that it was dying with a SIGSEGV before I applied the patches. I still haven't made world, what with the current (no pun intended) breakage in the tree. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com From owner-freebsd-current Sun Jan 11 15:14:51 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA16633 for current-outgoing; Sun, 11 Jan 1998 15:14:51 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA16525 for ; Sun, 11 Jan 1998 15:13:37 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id SAA02628; Sun, 11 Jan 1998 18:13:29 -0500 (EST) (envelope-from toor) Message-Id: <199801112313.SAA02628@dyson.iquest.net> Subject: Re: Performance problems/hangs with today's build In-Reply-To: <199801112143.WAA11069@daneel.stuyts.nl> from Ben Stuyts at "Jan 11, 98 10:43:35 pm" To: ben@stuyts.nl Date: Sun, 11 Jan 1998 18:13:29 -0500 (EST) Cc: current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ben Stuyts said: > > I've ran current quite successful over the last months, is it just a bad time > to build today, or have I missed something? I looked over the past few days > of messages in this list but couldn't find anybody else with such severe > problems. > More than just a few times, I have made statements about the instability of -current. It is a really good idea to follow the current mailing list carefully. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Sun Jan 11 15:34:52 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA18788 for current-outgoing; Sun, 11 Jan 1998 15:34:52 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alushta.NL.net (alushta.NL.net [193.78.240.22]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA18747; Sun, 11 Jan 1998 15:34:32 -0800 (PST) (envelope-from benst@terminus.stuyts.nl) Received: from stuyts by alushta.NL.net with UUCP id <9757-26708>; Mon, 12 Jan 1998 00:34:05 +0100 Received: from daneel.stuyts.nl (daneel.stuyts.nl [193.78.231.7]) by terminus.stuyts.nl (8.8.8/8.8.8) with ESMTP id AAA02777; Mon, 12 Jan 1998 00:31:07 +0100 (MET) (envelope-from benst) Received: (from benst@localhost) by daneel.stuyts.nl (8.8.5/8.8.5) id AAA11185; Mon, 12 Jan 1998 00:30:40 +0100 (MET) Message-Id: <199801112330.AAA11185@daneel.stuyts.nl> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: <199801112313.SAA02628@dyson.iquest.net> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.2) Received: by NeXT.Mailer (1.118.2) From: Ben Stuyts Date: Mon, 12 Jan 98 00:30:38 +0100 To: dyson@FreeBSD.ORG Subject: Re: Performance problems/hangs with today's build cc: current@FreeBSD.ORG Reply-To: ben@stuyts.nl References: <199801112313.SAA02628@dyson.iquest.net> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 11 Jan 1998, "John S. Dyson" wrote: > Ben Stuyts said: > > > > I've ran current quite successful over the last months, is it just a bad > > time to build today, or have I missed something? I looked over the past few > > days of messages in this list but couldn't find anybody else with such > > severe problems. > > > More than just a few times, I have made statements about the instability > of -current. It is a really good idea to follow the current mailing list > carefully. John, I'm aware of the risks of running current, but I'm only trying to help by describing the problems I encountered. I didn't mean to put down all the good work you people put into it. On the contrary, it is very much appreciated. I'm on the digest list of -current, so maybe that's part of the problem. Sometimes the digest doesn't appear for days. Maybe something can be configured so that it is sent out at least once a day. Or I should just subscribe to the non-digest list. I just scan the digest headers for things to watch out for. (Heads up, xxx broken, etc). FYI, I have a few other machines that need to be up 24/7, and they run -stable, and stable they are. Only my home toy runs -current, because I'm interested in SMP and the direction you guys are taking for FreeBSD. Best regards, Ben From owner-freebsd-current Sun Jan 11 15:45:17 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA19682 for current-outgoing; Sun, 11 Jan 1998 15:45:17 -0800 (PST) (envelope-from owner-freebsd-current) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA19648 for ; Sun, 11 Jan 1998 15:44:55 -0800 (PST) (envelope-from grog@lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id KAA14219 for ; Mon, 12 Jan 1998 10:14:49 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id KAA05136; Mon, 12 Jan 1998 10:14:48 +1030 (CST) (envelope-from grog) Message-ID: <19980112101448.06484@lemis.com> Date: Mon, 12 Jan 1998 10:14:48 +1030 From: Greg Lehey To: FreeBSD current users Subject: VM breakage in yesterday's -current? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I built a new kernel on one of my machines (razzia) yesterday, and since then I've been getting hanging processes. This is quite specific: one process (xtset, which sets an xterm title bar) hangs waiting at vmpfw. It's NFS mounted, so possibly there's an NFS problem in there, but it's hard to be sure. Any ideas? I know there's some VM problems at the moment. I'll keep the kernel and try to find more details if anybody wants me to. Greg From owner-freebsd-current Sun Jan 11 16:20:55 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA23131 for current-outgoing; Sun, 11 Jan 1998 16:20:55 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA23117; Sun, 11 Jan 1998 16:20:38 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id TAA00352; Sun, 11 Jan 1998 19:20:14 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801120020.TAA00352@dyson.iquest.net> Subject: Re: Performance problems/hangs with today's build In-Reply-To: <199801112330.AAA11185@daneel.stuyts.nl> from Ben Stuyts at "Jan 12, 98 00:30:38 am" To: ben@stuyts.nl Date: Sun, 11 Jan 1998 19:20:14 -0500 (EST) Cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ben Stuyts said: > > I'm aware of the risks of running current, but I'm only trying to help by > describing the problems I encountered. I didn't mean to put down all the good > work you people put into it. On the contrary, it is very much appreciated. > There should be some fixes going in tonight. I have been getting frustrated (probably because I take this so seriously) about the me too bug reports. Truly I have been working long long hours, over the entire holiday to fix the bugs that I had admittedly created. I am very tired, and intensely trying to fix the problem. Sorry if I came across as "cross", but -current is something to be very gentle with until I get the (my) problems fixed. > > I'm on the digest list of -current, so maybe that's part of the problem. > Sometimes the digest doesn't appear for days. Maybe something can be > configured so that it is sent out at least once a day. Or I should just > subscribe to the non-digest list. I just scan the digest headers for things to > watch out for. (Heads up, xxx broken, etc). > I find that any delay in information about -current can "hose" me also. So, unless you are not running -current actively, I suggest subscribing to the regular mailing list, and using procmail to split it off for review so you can get the info immediately when you are ready to try an up-to-date -current. (That is how I manage the 600+ messages/day that I have to wade through.) > > FYI, I have a few other machines that need to be up 24/7, and they run > -stable, and stable they are. Only my home toy runs -current, because I'm > interested in SMP and the direction you guys are taking for FreeBSD. > You are wise avoiding use of -current in production, but some people have to use it and that is one reason that I am frank about breakage when I know about it. It is best for me to be straightforward about it, rather than hide it, and have users even more angry :-). (I'd rather cause people to be frustrated with me, rather than them being angry at the entire project, because we might appear that we (or I) don't care about the users or the codebase.) -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Sun Jan 11 16:30:34 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA24083 for current-outgoing; Sun, 11 Jan 1998 16:30:34 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA24064 for ; Sun, 11 Jan 1998 16:30:21 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id TAA00418; Sun, 11 Jan 1998 19:30:04 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801120030.TAA00418@dyson.iquest.net> Subject: Re: VM breakage in yesterday's -current? In-Reply-To: <19980112101448.06484@lemis.com> from Greg Lehey at "Jan 12, 98 10:14:48 am" To: grog@lemis.com (Greg Lehey) Date: Sun, 11 Jan 1998 19:30:04 -0500 (EST) Cc: FreeBSD-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greg Lehey said: > I built a new kernel on one of my machines (razzia) yesterday, and > since then I've been getting hanging processes. This is quite > specific: one process (xtset, which sets an xterm title bar) hangs > waiting at vmpfw. It's NFS mounted, so possibly there's an NFS > problem in there, but it's hard to be sure. > > Any ideas? I know there's some VM problems at the moment. I'll keep > the kernel and try to find more details if anybody wants me to. > If you can, please try the new code that I am about to commit. I'll be able to make better use of any bug info given that code. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Sun Jan 11 16:34:29 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA24497 for current-outgoing; Sun, 11 Jan 1998 16:34:29 -0800 (PST) (envelope-from owner-freebsd-current) Received: from silverback.gorilla.net (silverback.gorilla.net [208.128.8.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA24488 for ; Sun, 11 Jan 1998 16:34:21 -0800 (PST) (envelope-from tom@gorilla.net) Received: from ygordial056.gorilla.net (ygordial056.gorilla.net [208.143.84.56]) by silverback.gorilla.net (NTMail 3.03.0014/18.aaac) with ESMTP id oa029706 for ; Sun, 11 Jan 1998 18:33:38 -0600 Received: (from tom@localhost) by gorilla.net (8.8.8/8.8.8) id SAA01561; Sun, 11 Jan 1998 18:33:47 -0600 (CST) (envelope-from tom) Message-ID: <19980111183307.21448@TOJ.org> Date: Sun, 11 Jan 1998 18:33:07 -0600 From: Tom Jackson To: FreeBSD Current Subject: pcvt keyboard buffer overflows Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Only on the source cvsup'd from the tenth do I get a keyboard lockup with both the standard and slice kernel. Looked in /var/log/messages and saw plenty of these. Can't really see anything lately that should cause this. Kernel of the ninth works fine. Anyone seen this? Tom From owner-freebsd-current Sun Jan 11 17:41:04 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA03033 for current-outgoing; Sun, 11 Jan 1998 17:41:04 -0800 (PST) (envelope-from owner-freebsd-current) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA02641; Sun, 11 Jan 1998 17:38:49 -0800 (PST) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199801120138.RAA02641@hub.freebsd.org> Subject: Re: Making world today To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sun, 11 Jan 1998 17:38:49 -0800 (PST) Cc: shimon@simon-shapiro.org, nash@mcs.net, kong@kkk.ml.org, current@freebsd.org, aryder@bestweb.net, asami@cs.berkeley.edu In-Reply-To: <11733.884504253@time.cdrom.com> from "Jordan K. Hubbard" at Jan 10, 98 11:37:33 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk amen brother! current is the bleeding edge. stable is for those that dont want to or cant afford to bleed. stable is also known as RELENG_2_2 in the cvs tree at this time. jmb Jordan K. Hubbard wrote: > > > Seems that way. Maybe we should start thinking about how to eliminate > > these slips. We are gaining a reputation lately. > > It is the nature of -current to break occasionally and I would be no > means wish to get so anal about this that the whole intention of > -current was lost, namely to be a place to work out new stuff and, > yes, occasionally break things in the process. That is why -current > has always been a strictly no-warranty proposition with warning > stickers stuck all over it. The complains we've been getting lately > stem, I think, more from the fact that a lot of the wrong people are > now running -current rather than any major instability there. Hell, I > remember when running -current was a good way to lose *filesystems* > and things have definitely come a hell of a long way from there. ;-) > > Jordan > From owner-freebsd-current Sun Jan 11 17:53:11 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA04752 for current-outgoing; Sun, 11 Jan 1998 17:53:11 -0800 (PST) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA04483 for ; Sun, 11 Jan 1998 17:50:55 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA00554; Mon, 12 Jan 1998 12:11:34 +1030 (CST) Message-Id: <199801120141.MAA00554@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Alex Nash , kong@kkk.ml.org, Studded@dal.net, current@FreeBSD.ORG, thyerm@camtech.net.au Subject: Re: Firewall in kernel? - Found it! In-reply-to: Your message of "Sat, 10 Jan 1998 14:24:54 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 1998 12:11:34 +1030 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It does seem that we have, as of late, a situation where submitted patches > do not even compile. This particular one is not the first, but maybe for > some of us, one too many. > > There can, logically, be only two explanations for this trend: You are making the fallacious assumption that this is a "trend" or something somehow new. It's not. In fact, even this thread is nothing new. There is a period of reasonable stability and quiet in -current, then a few wrinkles and all the people that were getting complacent start screaming. Your proposal's not new either. Your offer to help run it is, but realistically do you feel that you have the time and stamina to do nothing but vet endless permutations of changes to the system? We already *have* a lazy vetting system, with many hundreds if not thousands of participants, and a reasonably adequate feedback mechanism. Trying to improve substantially on this would require a lot of work. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-current Sun Jan 11 18:04:21 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA06418 for current-outgoing; Sun, 11 Jan 1998 18:04:21 -0800 (PST) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA06011 for ; Sun, 11 Jan 1998 18:00:56 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA00677; Mon, 12 Jan 1998 12:23:20 +1030 (CST) Message-Id: <199801120153.MAA00677@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Hostas Red cc: current@FreeBSD.ORG Subject: Re: iOmega zip/ide problems In-reply-to: Your message of "Sun, 11 Jan 1998 15:11:39 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 1998 12:23:19 +1030 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I have a problem: -current recognizes internal zip/ide(atapi) drive as > wcd0 device (and now i have my cdrom as wcd1 :) and doesn't wants to mount > with '-t msdos'. Is there any support for zip/ide at all? It *shouldn't* show up on 'wcd0', but it will be listed being probed off 'wdc0' (one line where the controller finds it, not two). The LS-120 driver should adapt reasonably easily to handle these drives, and I am very keen to get a few hours to look at this. I had hoped to do so this weekend, but: - My going-away party - Moving house - Selling my car and all my other stuff - Counselling a frind that was just bashed by their partner all got in first, sorry. I'll try ASAP, or happily liaise with anyone else that has one of these and isn't afraid of getting a little blood on their hands. Satoh has done all the hard work, this is just some dinking and a little testing. If you're interested, please let me know. Failing that, keep your eyes peeled and I'll make noise as soon as something is happening. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-current Sun Jan 11 18:55:18 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA12121 for current-outgoing; Sun, 11 Jan 1998 18:55:18 -0800 (PST) (envelope-from owner-freebsd-current) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA11889 for ; Sun, 11 Jan 1998 18:53:55 -0800 (PST) (envelope-from jdp@austin.polstra.com) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.8/8.8.8) with ESMTP id SAA17796; Sun, 11 Jan 1998 18:52:59 -0800 (PST) (envelope-from jdp) Message-Id: <199801120252.SAA17796@austin.polstra.com> To: kong@kkk.ml.org Subject: Re: cvs broken? In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Date: Sun, 11 Jan 1998 18:52:59 -0800 From: John Polstra Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , Hostas Red wrote: > > What can that be? It doesn't work anymore. > > ========= ... ========= > Edit src/usr.sbin/ppp/vjcomp.h > Add delta 1.5 98.01.11.17.50.49 brian > Updater failed: Protocol error: Short counted file attribute > ========= 8< ========== This is its way of saying "premature EOF from the network connection." :-) I think it's probably caused by the widespread network problems that are going on this weekend. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth From owner-freebsd-current Sun Jan 11 19:05:51 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA13760 for current-outgoing; Sun, 11 Jan 1998 19:05:51 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA13696 for ; Sun, 11 Jan 1998 19:05:05 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id WAA00180 for current@freebsd.org; Sun, 11 Jan 1998 22:04:53 -0500 (EST) (envelope-from toor) Message-Id: <199801120304.WAA00180@dyson.iquest.net> Subject: Still not fixed, but closer To: current@freebsd.org Date: Sun, 11 Jan 1998 22:04:52 -0500 (EST) From: "John S. Dyson" Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The vnode problems are not fixed yet as of 12-JAN 03:00 GMT. It is close, and I'll announce on -current when it is fixed. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Sun Jan 11 19:17:43 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA15648 for current-outgoing; Sun, 11 Jan 1998 19:17:43 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA15622 for ; Sun, 11 Jan 1998 19:17:26 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id WAA03994 for current@freebsd.org.; Sun, 11 Jan 1998 22:17:21 -0500 (EST) (envelope-from toor) Message-Id: <199801120317.WAA03994@dyson.iquest.net> Subject: Okay, I think things are okay To: current@freebsd.org Date: Sun, 11 Jan 1998 22:17:21 -0500 (EST) From: "John S. Dyson" Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It looks like the code works correctly now. In order to keep things in sync, I want to know about bugs when using -current with version 1.123 of /sys/kern/vfs_subr.c. Anything before that is definitely going to give you trouble. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Sun Jan 11 21:10:34 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA26800 for current-outgoing; Sun, 11 Jan 1998 21:10:34 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA26766; Sun, 11 Jan 1998 21:10:14 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id VAA15184; Sun, 11 Jan 1998 21:02:37 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd015182; Sun Jan 11 21:02:37 1998 Date: Sun, 11 Jan 1998 20:59:30 -0800 (PST) From: Julian Elischer To: "John S. Dyson" cc: current@freebsd.org Subject: Re: Still not fixed, but closer In-Reply-To: <199801120304.WAA00180@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ok so vfs_subr.c 1.123 is still buggy? it's hard to know what version you're talking about.. thanks by the way for doing all this work and taking it seriously enough to be so concerned about keeping us posted. julian On Sun, 11 Jan 1998, John S. Dyson wrote: > The vnode problems are not fixed yet as of 12-JAN 03:00 GMT. It is close, > and I'll announce on -current when it is fixed. > > -- > John | Never try to teach a pig to sing, > dyson@freebsd.org | it just makes you look stupid, > jdyson@nc.com | and it irritates the pig. > From owner-freebsd-current Sun Jan 11 21:15:58 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA27265 for current-outgoing; Sun, 11 Jan 1998 21:15:58 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA27188; Sun, 11 Jan 1998 21:14:38 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id AAA00234; Mon, 12 Jan 1998 00:14:23 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801120514.AAA00234@dyson.iquest.net> Subject: Re: Still not fixed, but closer In-Reply-To: from Julian Elischer at "Jan 11, 98 08:59:30 pm" To: julian@whistle.com (Julian Elischer) Date: Mon, 12 Jan 1998 00:14:22 -0500 (EST) Cc: dyson@freebsd.org, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Elischer said: > ok so vfs_subr.c 1.123 is still buggy? > it's hard to know what version you're talking about.. > > thanks by the way for doing all this work and taking it seriously enough > to be so concerned about keeping us posted. > vfs_subr.c 1.123 should be the first version that I think might be okay. Feedback regarding a kernel with this version of vfs_subr would be very much appreciated. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Sun Jan 11 21:29:57 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA28913 for current-outgoing; Sun, 11 Jan 1998 21:29:57 -0800 (PST) (envelope-from owner-freebsd-current) Received: from fanfic.org (fanfic.org [205.150.35.145]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA28899 for ; Sun, 11 Jan 1998 21:29:45 -0800 (PST) (envelope-from dstenn@fanfic.org) Received: from localhost (dstenn@localhost) by fanfic.org (8.8.8/8.8.8) with SMTP id AAA00396 for ; Mon, 12 Jan 1998 00:04:33 -0500 (EST) (envelope-from dstenn@fanfic.org) Date: Mon, 12 Jan 1998 00:04:32 -0500 (EST) From: Dennis Tenn To: FreeBSD-current Subject: make world - Update (was Re: make world - A new error) In-Reply-To: <199801110901.UAA27003@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 11 Jan 1998, Bruce Evans wrote: Thanks everyone that responded. | >> Well.. Here's the latest in the saga.. This isn't really a 'make world' | >> error but a 'make most' The previous error seem to happen when I try to | >> compile the libs so I decided to exclude them. | > ^^^^^^^ | >If you exclude them, then they are not there to link against! | | It should link to the standard libraries. This may not be right, but it | is what you asked for. `make most' is more like plain `make' than it is | like `make world'. | | >> ===> ac | >> cc -O -c /usr/src/usr.sbin/ac/ac.c | >> make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libc.so.3.0. | > ^^^^^^^^^^^^^^^^^^^^ | > | >This is the temporary build tree which is supposed to contain things | >you have build before, not things which have previously been installed. | | It may contain pointers (in .depend files) to the temporary obj tree | when the main obj tree isn't clean enough. The main tree is normally | cleaned by `make world', but it is likely to be unclean at the point of | failure if `make world' fails. | | Summary: pilot error. I retrieved the latest cvs of 3.0 and ran 'make world' and this time it compiled perfectly. No hardware changes to my system. I was pleasantly surprised when it only took 4hrs and 40mins to 'make world'. I also compiled a new kernel and installed an additional 64Mb ram. Now I have 128Mb. FreeBSD had no trouble recognizing all my ram. I'm so happy now! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dennis Tenn * There will always come a time dstenn@fanfic.org * When your love will be tested * Stand tall and rise to the occasion * For only then will you grow strong. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From owner-freebsd-current Sun Jan 11 22:22:02 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA04247 for current-outgoing; Sun, 11 Jan 1998 22:22:02 -0800 (PST) (envelope-from owner-freebsd-current) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA04183 for ; Sun, 11 Jan 1998 22:21:48 -0800 (PST) (envelope-from julian@FreeBSD.org) From: Julian Elischer Received: (from julian@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id WAA07305 for current; Sun, 11 Jan 1998 22:21:06 -0800 (PST) Date: Sun, 11 Jan 1998 22:21:06 -0800 (PST) Message-Id: <199801120621.WAA07305@freefall.freebsd.org> To: current@FreeBSD.ORG Subject: YADR (yet another DEVFS release (12)) Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk the usual place: ftp://hub.freebsd.org/pub/scsi read the README :) julian From owner-freebsd-current Sun Jan 11 23:22:58 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA09933 for current-outgoing; Sun, 11 Jan 1998 23:22:58 -0800 (PST) (envelope-from owner-freebsd-current) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA09917 for ; Sun, 11 Jan 1998 23:22:50 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA02388; Mon, 12 Jan 1998 08:22:29 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id IAA05468; Mon, 12 Jan 1998 08:20:22 +0100 (MET) Message-ID: <19980112082022.30571@uriah.heep.sax.de> Date: Mon, 12 Jan 1998 08:20:22 +0100 From: J Wunsch To: =?iso-8859-1?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= Cc: Peter Wemm , FreeBSD-current , info-cvs@gnu.ai.mit.edu Subject: Re: CVS DIFF fix for review (-L added) Reply-To: Joerg Wunsch References: <199801111457.WAA06475@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88 In-Reply-To: =?iso-8859-1?Q?=3CPine=2EBSF=2E3=2E96=2E980111232840=2E17312A-100000=40l?= =?iso-8859-1?Q?sd=2Erelcom=2Eeu=2Enet=3E=3B_from_=E1=CE=C4=D2=C5=CA_=FE?= =?iso-8859-1?Q?=C5=D2=CE=CF=D7_on_Sun=2C_Jan_11=2C_1998_at_11=3A35=3A40P?= =?iso-8859-1?Q?M_+0300?= X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Андрей Чернов wrote: > > If you can convince the info-cvs folks to make the changes, then I'll go > > along. Otherwise, IMHO the new patch and/or "standard" is busted. It > > wouldn't be the first time that POSIX have screwed something up. CVS and > > patch have been doing it like this since as far back as 1993. > > Please, note that it _not_ POSIX invention, POSIX just document > _existent_practice_ for years! Well, Peter, indeed. This only incidentally worked as intended as long as the -L option to diff/rcsdiff didn't exist, so at least one of the pathnames in the context diff header was invalid by the time patch has been called. Now, with -L and the basename of the file in both lines of the context diff header, it's very likely that this file exists in the current directory (like `Makefile', for a popular example), and patch will try patching the wrong file. The idea of Index: was great, but there has never been a patch utility supporting it the way CVS did expect. :-O Again, all the pre-existant ``support'' for Index: lines taking precedence over context-diff headers was _incidentally_. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current Sun Jan 11 23:41:34 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA11389 for current-outgoing; Sun, 11 Jan 1998 23:41:34 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA11384 for ; Sun, 11 Jan 1998 23:41:28 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 16538 invoked by uid 1000); 13 Jan 1998 07:42:06 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801120141.MAA00554@word.smith.net.au> Date: Mon, 12 Jan 1998 23:42:06 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: Firewall in kernel? - Found it! Cc: thyerm@camtech.net.au, current@FreeBSD.ORG, Studded@dal.net, kong@kkk.ml.org, Alex Nash Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 12-Jan-98 Mike Smith wrote: >> >> It does seem that we have, as of late, a situation where submitted >> patches >> do not even compile. This particular one is not the first, but maybe >> for >> some of us, one too many. >> >> There can, logically, be only two explanations for this trend: > > You are making the fallacious assumption that this is a "trend" or > something somehow new. You are assuming I make an assumption, which I am not. > > It's not. > > In fact, even this thread is nothing new. There is a period of > reasonable stability and quiet in -current, then a few wrinkles and all > the people that were getting complacent start screaming. I was not screaming and I do not consider myself complacent either. I belive every process which shows failure can be improved, and any human process that does not show failures is so broken that failures do not even show up. > Your proposal's not new either. Your offer to help run it is, but > realistically do you feel that you have the time and stamina to do > nothing but vet endless permutations of changes to the system? Done manually, yes, it will take a lot of time. Automated, it will not. Besides, I am already doing that. All I was proposing is to have a go/fail mechanism that serializes all requests and simply rejects those that fail to ``make buildworld''. This instead of today's mechnism, where sources that do not make sense even to GCC and /bin/sh are becoming part of the official tree, only to be retracted/modified. Think about it as an ATM deposit into your checking account; It is not there officially until the transaction is verified, but you can deposit and forget. If you made no mistakes, the transaction becomes official. If not, you are told there is a problem. For ``correct'' CVS transactions this represents a delay of few hours. For bad transactions, it acts as an early warning system and reduces noise in this very list. > We already *have* a lazy vetting system, with many hundreds if not > thousands of participants, and a reasonably adequate feedback > mechanism. Trying to improve substantially on this would require a lot > of work. 8) If the concensus is that the current system is oh so very well, and needs no further improvement, then I humbly apologize and withraw my offer. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-current Mon Jan 12 00:21:43 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA15567 for current-outgoing; Mon, 12 Jan 1998 00:21:43 -0800 (PST) (envelope-from owner-freebsd-current) Received: from rah.star-gate.com ([209.133.7.178]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA15550 for ; Mon, 12 Jan 1998 00:21:35 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id AAA04349; Mon, 12 Jan 1998 00:21:07 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199801120821.AAA04349@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: shimon@simon-shapiro.org cc: Mike Smith , thyerm@camtech.net.au, current@freebsd.org, Studded@dal.net, kong@kkk.ml.org, Alex Nash Subject: Re: Firewall in kernel? - Found it! In-reply-to: Your message of "Mon, 12 Jan 1998 23:42:06 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 1998 00:21:07 -0800 From: Amancio Hasty Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > If the concensus is that the current system is oh so very well, and needs > no further improvement, then I humbly apologize and withraw my offer. Well, if it can improve or increase our current build process then I would say it is worth it go for it. There is more to that little tiny statement -- I can say that one major company in the valley honorable checking process almost spun out of control and it took several million dollars to get themselves out of the mess they created it. So if an automatic check-in and verify process can be placed it can improve our productivity. Also, it will be way cool to have a world-wide network for check-in, verify and build 8) Cheers, Amancio From owner-freebsd-current Mon Jan 12 00:40:25 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA17615 for current-outgoing; Mon, 12 Jan 1998 00:40:25 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA17601 for ; Mon, 12 Jan 1998 00:40:19 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id AAA20218; Mon, 12 Jan 1998 00:39:22 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd020216; Mon Jan 12 00:39:16 1998 Date: Mon, 12 Jan 1998 00:36:09 -0800 (PST) From: Julian Elischer To: Simon Shapiro cc: current@freebsd.org Subject: Re: Firewall in kernel? - Found it! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 12 Jan 1998, Simon Shapiro wrote: > > Done manually, yes, it will take a lot of time. Automated, it will not. > Besides, I am already doing that. All I was proposing is to have a go/fail > mechanism that serializes all requests and simply rejects those that fail > to ``make buildworld''. This instead of today's mechnism, where sources > that do not make sense even to GCC and /bin/sh are becoming part of the > official tree, only to be retracted/modified. The problem is that I the users committing should have done test builds directly defore/after committing. at least testing all related areas. I think it's one of those things where the cost of living with the confusion is more than the cost of stopping it. (see later) > > Think about it as an ATM deposit into your checking account; It is not > there officially until the transaction is verified, but you can deposit and > forget. If you made no mistakes, the transaction becomes official. If > not, you are told there is a problem. For ``correct'' CVS transactions > this represents a delay of few hours. For bad transactions, it acts as an > early warning system and reduces noise in this very list. Yes but it would slow down my own verification of the correctness of my patches.. My method is: edit/build/test/edit/build/test make world (not always fora a smaller commit) cvs diff apply diff to my commit tree commit (remotly) cvsup to local cvs tree <-------XXX checkout entire sources make kernel(s) make world this way I catch any stuffups You are suggesting inserting a 3 hour gap at XXX this will slow down my attempts at checking my commit. (that will really slow down my work rate, as I can't really get on with other things till I see my own commits return. (I don't multitask well) > > We already *have* a lazy vetting system, with many hundreds if not > > thousands of participants, and a reasonably adequate feedback > > mechanism. Trying to improve substantially on this would require a lot > > of work. 8) > > If the concensus is that the current system is oh so very well, and needs > no further improvement, then I humbly apologize and withraw my offer. It aint purfect, but it's remarkable how effective it is. this last week has been an aberation rather than the norm. I'm usually pretty happy with the state of the tree really. julian (ps. new devfs code out..) From owner-freebsd-current Mon Jan 12 04:59:16 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA06515 for current-outgoing; Mon, 12 Jan 1998 04:59:16 -0800 (PST) (envelope-from owner-freebsd-current) Received: from db2server.voga.com.br (db2server.voga.com.br [200.239.39.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA06505 for ; Mon, 12 Jan 1998 04:59:01 -0800 (PST) (envelope-from daniel_sobral@voga.com.br) From: daniel_sobral@voga.com.br Received: from papagaio.voga.com.br (papagaio.voga.com.br [200.239.39.2]) by db2server.voga.com.br (8.8.3+2.6Wbeta9/8.8.7) with SMTP id KAA13948 for ; Mon, 12 Jan 1998 10:59:45 -0200 Received: by papagaio.voga.com.br(Lotus SMTP MTA v1.06 (346.7 3-18-1997)) id 0325658A.004CDFDA ; Mon, 12 Jan 1998 10:59:40 -0300 X-Lotus-FromDomain: VOGA To: current@freebsd.org Message-ID: <8325658A.004CBE54.00@papagaio.voga.com.br> Date: Mon, 12 Jan 1998 10:59:35 -0300 Subject: Current/Stable drivers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quick question before you go back to your latest world problems (pun intended), is there any device driver on current that can be compiled without changes on both stable and current? -- Daniel C. Sobral (8-DCS) Daniel_Sobral@voga.com.br From owner-freebsd-current Mon Jan 12 05:41:29 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA09603 for current-outgoing; Mon, 12 Jan 1998 05:41:29 -0800 (PST) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (ppp3.portal.net.au [202.12.71.103]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA09597 for ; Mon, 12 Jan 1998 05:41:17 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id AAA00363; Tue, 13 Jan 1998 00:04:23 +1030 (CST) Message-Id: <199801121334.AAA00363@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , thyerm@camtech.net.au, current@freebsd.org, Studded@dal.net, kong@kkk.ml.org, Alex Nash Subject: Commit Approval (was Re: Firewall in kernel? - Found it! ) In-reply-to: Your message of "Mon, 12 Jan 1998 23:42:06 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jan 1998 00:04:23 +1030 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > On 12-Jan-98 Mike Smith wrote: > >> > >> It does seem that we have, as of late, a situation where submitted > >> patches > >> do not even compile. This particular one is not the first, but maybe > >> for > >> some of us, one too many. > >> > >> There can, logically, be only two explanations for this trend: > > > > You are making the fallacious assumption that this is a "trend" or > > something somehow new. > > You are assuming I make an assumption, which I am not. I can't imagine what else you might be doing. It's certainly not an observation, as it has no basis in any observable fact or history, and I was being too polite to suggest you were delusional... 8) > I belive every process which shows failure can be improved, and any human > process that does not show failures is so broken that failures do not even > show up. No argument there. > > Your proposal's not new either. Your offer to help run it is, but > > realistically do you feel that you have the time and stamina to do > > nothing but vet endless permutations of changes to the system? > > Done manually, yes, it will take a lot of time. Automated, it will not. Ah yes, the wonderful concept of "automated software testing". 8( > Besides, I am already doing that. All I was proposing is to have a go/fail > mechanism that serializes all requests and simply rejects those that fail > to ``make buildworld''. Given a buildable state A, and desired target state C, how do I transit between the two when it is necessary for me to make more than a single commit? After the first commit I have an unbuildable but temporary state B, which your system will reject. > This instead of today's mechnism, where sources > that do not make sense even to GCC and /bin/sh are becoming part of the > official tree, only to be retracted/modified. And an automated buildability checker will help here? One with 'buildworld' latency? Why not educate the developer population instead? Rather than frustration and rejected commits, you get increased productivity and happier hackers. Why is it that prohibition is so much easier to advocate than commonsense? > Think about it as an ATM deposit into your checking account; It is not > there officially until the transaction is verified, but you can deposit and > forget. If you made no mistakes, the transaction becomes official. If > not, you are told there is a problem. For ``correct'' CVS transactions > this represents a delay of few hours. For bad transactions, it acts as an > early warning system and reduces noise in this very list. That's an awfully big handwave there; counting a few notes is just ever so *slightly* easier than verifying the real buildability of a commit, let alone its correctness. As for noise on the list, that's not going to go away, or even reduce much, just by removing the (really pretty rare) "-current build fails with xxxxx" messages. Sheesh, you should go back a little while and look for the times when people would post saying that -current *built*. > > We already *have* a lazy vetting system, with many hundreds if not > > thousands of participants, and a reasonably adequate feedback > > mechanism. Trying to improve substantially on this would require a lot > > of work. 8) > > If the concensus is that the current system is oh so very well, and needs > no further improvement, then I humbly apologize and withraw my offer. To be completely blunt about it, and bearing in mind that this is just *my* opinion, there are many things that would benefit more from the sort of effort and attention that would be expended on such a scheme. The current mechanism works amazingly well, and has shown a strong improving trend over the last couple of years. Nuking it would be a real Dilbert manouvre IMHO. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-current Mon Jan 12 08:02:14 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA21444 for current-outgoing; Mon, 12 Jan 1998 08:02:14 -0800 (PST) (envelope-from owner-freebsd-current) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA21335; Mon, 12 Jan 1998 08:01:40 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id QAA00367; Mon, 12 Jan 1998 16:58:11 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: dyson@freebsd.org Cc: current@freebsd.org Subject: random (?) SIGBUS in -current From: Poul-Henning Kamp Date: Mon, 12 Jan 1998 16:58:11 +0100 Message-ID: <365.884620691@critter.freebsd.dk> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I see random SIGBUS in programs now on current up to and including: > dyson 1998/01/11 21:16:06 PST > > Modified files: > sys/i386/i386 machdep.c > Log: > Adjust upwards the size of exec map in order to take into account the > additional PAGE_SIZE needed for exec operatino. > > Revision Changes Path > 1.281 +2 -2 src/sys/i386/i386/machdep.c I belive it is related to caching somehow. It never seems to happen on the first invocation of a program, but rather if I run a program do something else, run the program again, then bang. The ucode in trap() is T_PAGEFLT if that helps any. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-current Mon Jan 12 08:14:51 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA22756 for current-outgoing; Mon, 12 Jan 1998 08:14:51 -0800 (PST) (envelope-from owner-freebsd-current) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA22741; Mon, 12 Jan 1998 08:14:36 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0xrmVF-0005KW-00; Mon, 12 Jan 1998 09:14:17 -0700 Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.8.8/8.8.3) with ESMTP id JAA08570; Mon, 12 Jan 1998 09:14:21 -0700 (MST) Message-Id: <199801121614.JAA08570@harmony.village.org> To: dyson@freebsd.org Subject: Re: Performance problems/hangs with today's build Cc: ben@stuyts.nl, current@freebsd.org In-reply-to: Your message of "Sun, 11 Jan 1998 18:13:29 EST." <199801112313.SAA02628@dyson.iquest.net> References: <199801112313.SAA02628@dyson.iquest.net> Date: Mon, 12 Jan 1998 09:14:20 -0700 From: Warner Losh Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199801112313.SAA02628@dyson.iquest.net> "John S. Dyson" writes: : More than just a few times, I have made statements about the instability : of -current. It is a really good idea to follow the current mailing list : carefully. Speaking of which, is it safe to go back in the -current yet? I've been holding off building a new kernel/world for a little while now due to the scariness of the bugs reported in the current/hackers mailing lists. Warner From owner-freebsd-current Mon Jan 12 09:11:06 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA28734 for current-outgoing; Mon, 12 Jan 1998 09:11:06 -0800 (PST) (envelope-from owner-freebsd-current) Received: from mailgate32 (mailgate32-hme0.a001.sprintmail.com [205.137.196.58]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA28721 for ; Mon, 12 Jan 1998 09:10:56 -0800 (PST) (envelope-from andreleclaire@sprintmail.com) Received: by mailgate32 (SMI-8.6/SMI-SVR4) id JAA09099; Mon, 12 Jan 1998 09:10:20 -0800 Received: from sdn-ts-001txfwo8p06.dialsprint.net(206.133.157.25) by mailfep1-hme1 via smap (KC5.24) id Q_10.1.1.4/Q_19168_1_34ba4e70; Mon Jan 12 09:10:08 1998 Date: Mon, 12 Jan 1998 12:10:05 -0500 (EST) From: Andre LeClaire X-Sender: andreleclaire@chinquapin.lostfork.net Reply-To: Andre LeClaire To: freebsd-current@FreeBSD.ORG Subject: wdc1 not found Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi all, I just upgraded from 2.2.5-STABLE to 3.0-CURRENT, and now my ATAPI cdrom (which always worked great with -STABLE) is not recognized. In fact, the 2nd IDE controller, to which it's attached, is not found! The machine is a 486DX4-100 on a VIP motherboard (I/O and disk controllers onboard), with 16MB RAM. Output of dmesg and kernel config file follow; any help would be greatly appreciated. Andre ________________________________________________________________________ CPU: i486 DX4 (486-class CPU) Origin = "GenuineIntel" Id = 0x483 Stepping=3 Features=0xb real memory = 16777216 (16384K bytes) avail memory = 14635008 (14292K bytes) Probing for devices on PCI bus 0: chip0: rev 0x04 on pci0.16.0 chip1: rev 0x0e on pci0.18.0 ide_pci0: rev 0x10 on pci0.18.1 ide_pci: controller is simplex, no DMA on secondary channel Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x280-0x29f irq 10 on isa ed0: address 00:c0:a8:45:19:c9, type NE2000 (16 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 696MB (1427328 sectors), 1416 cyls, 16 heads, 63 S/T, 512 B/S wdc1 not found at 0x170 npx0 on motherboard npx0: INT 16 interface ___________________________________________________________________________ machine "i386" cpu "I486_CPU" ident CHINQUAPIN maxusers 10 options INET # InterNETworking options FFS # Berkeley Fast Filesystem options NFS # Network Filesystem options PROCFS # Process Filesystem options MSDOSFS # MSDOS Filesystem options "CD9660" # ISO 9660 Filesystem options "COMPAT_43" # Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE # Allow users to grab the console config kernel root on wd0 controller isa0 controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device wcd0 #IDE CD-ROM device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr options XSERVER # include code for XFree86 device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device ed0 at isa? port 0x280 net irq 10 vector edintr pseudo-device loop # Loopback pseudo-device ether # Ethernet pseudo-device bpfilter 1 # Berkeley packet filter pseudo-device ppp 1 # Kernel PPP pseudo-device pty 16 # virtual terminals pseudo-device gzip # Exec gzipped a.out's options SYSVSHM # \ options SYSVSEM # > For Netscape options SYSVMSG # / From owner-freebsd-current Mon Jan 12 09:45:07 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA02743 for current-outgoing; Mon, 12 Jan 1998 09:45:07 -0800 (PST) (envelope-from owner-freebsd-current) Received: from watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA02706 for ; Mon, 12 Jan 1998 09:44:51 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: by watermarkgroup.com (4.1/SMI-4.1) id AA19905; Mon, 12 Jan 98 12:44:13 EST Date: Mon, 12 Jan 98 12:44:13 EST From: luoqi@watermarkgroup.com (Luoqi Chen) Message-Id: <9801121744.AA19905@watermarkgroup.com> To: current@freebsd.org Subject: gdb addressing off by 0x20 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone else noticed this? When I debug a program with gdb, I have to specify x+0x20 if I want to get data at address x. For example, % gdb /bin/sh GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) info target Symbols from "/bin/sh". Local exec file: `/bin/sh', file type a.out-i386-freebsd. Entry point: 0x1020 0x00001020 - 0x0004a020 is .text 0x0004b000 - 0x0004e000 is .data 0x0004e000 - 0x000565d0 is .bss (gdb) x/10i 0x1020 <-- entry point, should show valid 0x1020: int3 <-- op codes, but garbage instead 0x1021: addb %al,0x4900000(%esi) 0x1027: addb %al,(%eax) 0x1029: xorb %al,(%eax) 0x102b: addb %dl,%al 0x102d: testl %eax,(%eax) 0x102f: addb %al,(%eax) 0x1031: addb %al,(%eax) 0x1033: addb %ah,(%eax) 0x1035: adcb %al,(%eax) (gdb) x/10i 0x1040 0x1040: pushl %ebp 0x1041: movl %esp,%ebp 0x1043: pushl %esi 0x1044: pushl %ebx 0x1045: leal 0x4(%ebp),%ebx 0x1048: leal 0x4(%ebx),%ecx 0x104b: leal 0x8(%ebx),%edx 0x104e: cmpl $0x0,0x4(%ebx) 0x1052: je 0x105d 0x1054: movl (%edx),%eax I am running UP kernel cvsupped Sat(1/10) morning. -lq From owner-freebsd-current Mon Jan 12 09:50:15 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA03622 for current-outgoing; Mon, 12 Jan 1998 09:50:15 -0800 (PST) (envelope-from owner-freebsd-current) Received: from watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA03449 for ; Mon, 12 Jan 1998 09:49:54 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: by watermarkgroup.com (4.1/SMI-4.1) id AA19967; Mon, 12 Jan 98 12:49:23 EST Date: Mon, 12 Jan 98 12:49:23 EST From: luoqi@watermarkgroup.com (Luoqi Chen) Message-Id: <9801121749.AA19967@watermarkgroup.com> To: current@freebsd.org Subject: gdb addressing off by 0x20 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Did anyone else notice this? When I debug a program with gdb, I have to specify x+0x20 if I want to get data at address x. For example % gdb /bin/sh GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) info target Symbols from "/bin/sh". Local exec file: `/bin/sh', file type a.out-i386-freebsd. Entry point: 0x1020 0x00001020 - 0x0004a020 is .text 0x0004b000 - 0x0004e000 is .data 0x0004e000 - 0x000565d0 is .bss Did anyone else notice this? When I debug a program with gdb, I have to specify x+0x20 if I want to get data at address x. For example, % gdb /bin/sh GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) info target Symbols from "/bin/sh". Local exec file: `/bin/sh', file type a.out-i386-freebsd. Entry point: 0x1020 0x00001020 - 0x0004a020 is .text 0x0004b000 - 0x0004e000 is .data Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) info target Symbols from "/bin/sh". Local exec file: `/bin/sh', file type a.out-i386-freebsd. Entry point: 0x1020 0x1029: xorb %al,(%eax) 0x102b: addb %dl,%al 0x102d: testl %eax,(%eax) 0x102f: addb %al,(%eax) 0x1031: addb %al,(%eax) 0x1033: addb %ah,(%eax) 0x1035: adcb %al,(%eax) (gdb) x/10i 0x1040 0x1040: pushl %ebp 0x1041: movl %esp,%ebp 0x1043: pushl %esi 0x1044: pushl %ebx 0x1045: leal 0x4(%ebp),%ebx 0x1048: leal 0x4(%ebx),%ecx 0x104b: leal 0x8(%ebx),%edx 0x104e: cmpl $0x0,0x4(%ebx) 0x1052: je 0x105d 0x1054: movl (%edx),%eax I am running world cvsupped on Sat(1/10) morning. Actually, I noticed the problem earlier, I suspected it might be caused by inconsistent header files. So I did a clean make world, but the problem didn't go away. -lq From owner-freebsd-current Mon Jan 12 10:46:23 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA10386 for current-outgoing; Mon, 12 Jan 1998 10:46:23 -0800 (PST) (envelope-from owner-freebsd-current) Received: from barracuda.bestweb.net (aryder@sendmail.exploit.org [209.94.111.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA10375 for ; Mon, 12 Jan 1998 10:46:17 -0800 (PST) (envelope-from aryder@bestweb.net) Received: from localhost (aryder@localhost) by barracuda.bestweb.net (8.8.8/8.8.8) with SMTP id NAA07148 for ; Mon, 12 Jan 1998 13:46:10 -0500 (EST) (envelope-from aryder@bestweb.net) X-Authentication-Warning: barracuda.bestweb.net: aryder owned process doing -bs Date: Mon, 12 Jan 1998 13:46:10 -0500 (EST) From: Andrew Ryder To: freebsd-current@freebsd.org Subject: wierd happening Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a 3.0-CURRENT machine last cvsup'd on the 9th and have had some wierd error with AccelX in it. After running it for 2 days, fine no problems when I would press ctrl-alt-f1-f5 it wouldnt go back into the consoles. Ive had this problem once before on a -stable where it did this and when you exited the xserver basically your machine was hung in the console. It wouldnt bring back anything nor let you type. While this is going on, it seems everything works fine in AccelX with AfterStep as my wm, opening rxvt's etc. Ive never seen this error on anything but FreeBSD since I asked a few Linux users of the 4.1 version to do the same, which was keep the Xserver open with different wm's and they didnt see it. Is this a problem with FreeBSD? or should I contact Xinside? From owner-freebsd-current Mon Jan 12 10:53:36 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA11572 for current-outgoing; Mon, 12 Jan 1998 10:53:36 -0800 (PST) (envelope-from owner-freebsd-current) Received: from taliesin.cs.ucla.edu (Taliesin.CS.UCLA.EDU [131.179.96.166]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA11516 for ; Mon, 12 Jan 1998 10:53:01 -0800 (PST) (envelope-from scottm@mordred.cs.ucla.edu) Received: (qmail 5511 invoked from network); 12 Jan 1998 18:52:16 -0000 Received: from mordred.cs.ucla.edu (131.179.48.34) by taliesin.cs.ucla.edu with SMTP; 12 Jan 1998 18:52:16 -0000 Received: from mordred (localhost [127.0.0.1]) by mordred.cs.ucla.edu (8.8.8/8.8.8) with ESMTP id KAA07318; Mon, 12 Jan 1998 10:52:27 -0800 (PST) (envelope-from scottm@mordred.cs.ucla.edu) Message-Id: <199801121852.KAA07318@mordred.cs.ucla.edu> X-Mailer: exmh version 2.0.1 12/23/97 To: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org Subject: NEC 273 CD-ROM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 1998 10:52:26 -0800 From: Scott Michel Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is an ATAPI critter, but for some reason at bootstrap, there's an out of phase error. Suggestions on how to debug it? (This should mean: I'm willing to debug it, I'm willing to fix and patch the driver, but how to I go about debugging?) -scooter -- Scott Michel | In life, there are sheep and there are UCLA Computer Science | wolves. PhD Graduate Student | I don't bleat. From owner-freebsd-current Mon Jan 12 10:57:19 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA12159 for current-outgoing; Mon, 12 Jan 1998 10:57:19 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA11872; Mon, 12 Jan 1998 10:55:25 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA07949; Mon, 12 Jan 1998 10:34:13 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd007945; Mon Jan 12 10:34:08 1998 Date: Mon, 12 Jan 1998 10:31:00 -0800 (PST) From: Julian Elischer To: Poul-Henning Kamp cc: dyson@freebsd.org, current@freebsd.org Subject: Re: random (?) SIGBUS in -current In-Reply-To: <365.884620691@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk kernel from late last night system got 85% through 'make world' before a process hung in 'D' state. The rest of the system seemed ok. no sign of SIGBUS though. julian (p.s. make-world completed correctly after hacking makefile (to not rebuild tools etc again) and restarting) On Mon, 12 Jan 1998, Poul-Henning Kamp wrote: > > I see random SIGBUS in programs now on current up to and including: > > > dyson 1998/01/11 21:16:06 PST > > > > Modified files: > > sys/i386/i386 machdep.c > > Log: > > Adjust upwards the size of exec map in order to take into account the > > additional PAGE_SIZE needed for exec operatino. > > > > Revision Changes Path > > 1.281 +2 -2 src/sys/i386/i386/machdep.c > > I belive it is related to caching somehow. It never seems to happen > on the first invocation of a program, but rather if I run a program > do something else, run the program again, then bang. > > The ucode in trap() is T_PAGEFLT if that helps any. > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > From owner-freebsd-current Mon Jan 12 11:24:11 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15754 for current-outgoing; Mon, 12 Jan 1998 11:24:11 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA15584; Mon, 12 Jan 1998 11:23:35 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id OAA00277; Mon, 12 Jan 1998 14:23:25 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801121923.OAA00277@dyson.iquest.net> Subject: Re: random (?) SIGBUS in -current In-Reply-To: from Julian Elischer at "Jan 12, 98 10:31:00 am" To: julian@whistle.com (Julian Elischer) Date: Mon, 12 Jan 1998 14:23:25 -0500 (EST) Cc: phk@freebsd.org, dyson@freebsd.org, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Julian Elischer said: > > kernel from late last night > system got 85% through 'make world' before a process hung in 'D' state. > The rest of the system seemed ok. > > no sign of SIGBUS though. > I cannot reproduce the problem, with testing and compiles on 8MB, 16MB, and 112MB systems. PHK, could you tell me more about your system? Are you running anything special, that I can reproduce the problem? Note that the new code follows the "rules" fairly precisely regarding the vnode free list. Some parts of the system might not be able to deal with it yet (maybe.) -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Mon Jan 12 11:30:31 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA16752 for current-outgoing; Mon, 12 Jan 1998 11:30:31 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA16698; Mon, 12 Jan 1998 11:30:08 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id OAA00321; Mon, 12 Jan 1998 14:29:45 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801121929.OAA00321@dyson.iquest.net> Subject: Re: random (?) SIGBUS in -current In-Reply-To: <365.884620691@critter.freebsd.dk> from Poul-Henning Kamp at "Jan 12, 98 04:58:11 pm" To: phk@freebsd.org (Poul-Henning Kamp) Date: Mon, 12 Jan 1998 14:29:45 -0500 (EST) Cc: dyson@freebsd.org, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk So far, I cannot reproduce the problem that PHK can see. I would appreciate input on the -current sources as of today. Thanks!!! Poul-Henning Kamp said: > > I see random SIGBUS in programs now on current up to and including: > > > dyson 1998/01/11 21:16:06 PST > > > > Modified files: > > sys/i386/i386 machdep.c > > Log: > > Adjust upwards the size of exec map in order to take into account the > > additional PAGE_SIZE needed for exec operatino. > > > > Revision Changes Path > > 1.281 +2 -2 src/sys/i386/i386/machdep.c > > I belive it is related to caching somehow. It never seems to happen > on the first invocation of a program, but rather if I run a program > do something else, run the program again, then bang. > > The ucode in trap() is T_PAGEFLT if that helps any. > -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Mon Jan 12 11:48:48 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA19938 for current-outgoing; Mon, 12 Jan 1998 11:48:48 -0800 (PST) (envelope-from owner-freebsd-current) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA19855; Mon, 12 Jan 1998 11:48:26 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id UAA00950; Mon, 12 Jan 1998 20:25:56 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "John S. Dyson" cc: julian@whistle.com (Julian Elischer), dyson@freebsd.org, current@freebsd.org Subject: Re: random (?) SIGBUS in -current In-reply-to: Your message of "Mon, 12 Jan 1998 14:23:25 EST." <199801121923.OAA00277@dyson.iquest.net> Date: Mon, 12 Jan 1998 20:25:52 +0100 Message-ID: <948.884633152@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199801121923.OAA00277@dyson.iquest.net>, "John S. Dyson" writes: >Julian Elischer said: >> >> kernel from late last night >> system got 85% through 'make world' before a process hung in 'D' state. >> The rest of the system seemed ok. >> >> no sign of SIGBUS though. >> >I cannot reproduce the problem, with testing and compiles on 8MB, 16MB, and >112MB systems. PHK, could you tell me more about your system? Are you >running anything special, that I can reproduce the problem? HP800 laptop. 48M Ram. Pretty much vanilla -current. For instance, I use mh to read email. the "inc" program will often sigbus when I have been running something else and rerun it to see if there is new email. It looks like some page gets stolen, and the object isn't updated accordingly... >Note that the new code follows the "rules" fairly precisely regarding the >vnode free list. Some parts of the system might not be able to deal with >it yet (maybe.) But this would be related to pages, they die with a pagefault... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" From owner-freebsd-current Mon Jan 12 12:01:41 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA21966 for current-outgoing; Mon, 12 Jan 1998 12:01:41 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA21924 for ; Mon, 12 Jan 1998 12:01:09 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 5033 invoked by uid 1000); 13 Jan 1998 20:01:24 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801120821.AAA04349@rah.star-gate.com> Date: Tue, 13 Jan 1998 12:01:24 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Amancio Hasty Subject: Re: Firewall in kernel? - Found it! Cc: Alex Nash , kong@kkk.ml.org, Studded@dal.net, current@freebsd.org, thyerm@camtech.net.au, Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 12-Jan-98 Amancio Hasty wrote: >> If the concensus is that the current system is oh so very well, and >> needs >> no further improvement, then I humbly apologize and withraw my offer. > > Well, if it can improve or increase our current build process then I > would > say it is worth it go for it. > > There is more to that little tiny statement -- I can say that one > major company in the valley honorable checking process almost > spun out of control and it took several million dollars to get > themselves out of the mess they created it. So if an automatic > check-in and verify process can be placed it can improve our > productivity. > > Also, it will be way cool to have a world-wide network > for check-in, verify and build 8) Once I am out of this current crunch here, I will start working on it. Promise. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-current Mon Jan 12 12:10:09 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA23169 for current-outgoing; Mon, 12 Jan 1998 12:10:09 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA23032 for ; Mon, 12 Jan 1998 12:09:52 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 5322 invoked by uid 1000); 13 Jan 1998 20:10:13 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] 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: Tue, 13 Jan 1998 12:10:13 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Julian Elischer Subject: Re: Firewall in kernel? - Found it! Cc: current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 12-Jan-98 Julian Elischer wrote: ... > Yes but it would slow down my own verification of the correctness of my > patches.. My method is: > edit/build/test/edit/build/test > make world (not always fora a smaller commit) > cvs diff > apply diff to my commit tree > commit (remotly) > cvsup to local cvs tree <-------XXX > checkout entire sources > make kernel(s) > make world > this way I catch any stuffups As usual, replacing accountability with procedure is costly. The cycle you describe is accountability. If everyone will always do that, there will be no need for procedure. You use the term ``not always'', which implies deviation. Small changes may cause big headaches. It is a compromise, and I hear the concensus is that it is a good one. I will agree that the technology and procedure we use are the best I have seen. Maybe improvement in procedure are of diminishing return. PErsonally, this last incident was an easy one to overcome, as the bugs were obvious. I also did not hear anyone moaning too loudly. Just specifying ``did that happened to you too?'' I need to think about this one some more. Maybe the process IS good enough. > It aint purfect, but it's remarkable how effective it is. > this last week has been an aberation rather than the norm. I tend to agree. > (ps. new devfs code out..) Great! ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-current Mon Jan 12 12:16:41 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA23877 for current-outgoing; Mon, 12 Jan 1998 12:16:41 -0800 (PST) (envelope-from owner-freebsd-current) Received: from gaia.coppe.ufrj.br (cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA23856 for ; Mon, 12 Jan 1998 12:16:29 -0800 (PST) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.8/8.8.8) id SAA17293; Mon, 12 Jan 1998 18:15:59 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199801122015.SAA17293@gaia.coppe.ufrj.br> Subject: Re: Architecture dependent source In-Reply-To: <199801082332.QAA10804@mt.sri.com> from Nate Williams at "Jan 8, 98 04:32:15 pm" To: nate@mt.sri.com (Nate Williams) Date: Mon, 12 Jan 1998 18:15:59 -0200 (EDT) Cc: jb@freebsd1.cimlogic.com.au, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk #define quoting(Nate Williams) // > Has the directory structure for architecture dependent source been // > decided? // > // > For instance, does src/sys/i386 become src/sys/arch/i386 (like NetBSD) // > or do we just start adding src/sys/alpha because i386 sets the precedent? // // Personally, I don't see that '/sys/arch' buys us anything other than // 'Yet Another directory'. Especially when there is no goal of having // every architecture under the sun working. It has the advantage of isolating architectures from other stuff. A ls in the arch dir shows all architectures, and nothing else. I'm not sure, but think it's mostly cosmetic though. Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67 From owner-freebsd-current Mon Jan 12 12:26:25 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24762 for current-outgoing; Mon, 12 Jan 1998 12:26:25 -0800 (PST) (envelope-from owner-freebsd-current) Received: from sphinx.lovett.com (root@sphinx.lovett.com [38.155.241.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA24667 for ; Mon, 12 Jan 1998 12:25:44 -0800 (PST) (envelope-from ade@demon.net) Received: from gorgon.lovett.com [38.155.241.3] (ade) by sphinx.lovett.com with esmtp (Exim 1.82 #1) id 0xrqQZ-0005s0-00; Mon, 12 Jan 1998 14:25:43 -0600 To: current@freebsd.org Subject: 980112 current and imake SIGBUS Organization: Demon Internet Date: Mon, 12 Jan 1998 14:25:42 -0600 From: Ade Lovett Message-Id: Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk With today's -current kernel: FreeBSD gorgon.lovett.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Mon Jan 12 10:59:20 CST 1998 root@gorgon.lovett.com:/usr/src/sys/compile/GORGON i386 I noticed that /usr/X11R6/bin/imake started dumping core (I initially built X11R6 from /usr/ports after installing the machine when it was running current-980106. Next stage was to do a complete make world, rather than just the kernel, which I've now done. Same results. gorgon 47# make World Building Release 6.3 of the X Window System. ... cc -o imake -O -I../../include -I../../imports/x11/include/X11 imake.o rm -f ./config/makedepend/Makefile.proto ./config/imake/imake -I./config/cf -s ./config/makedepend/Makefile.proto -f ./config/makedepend/Imakefile -DTOPDIR=../.. -DCURDIR=./config/makedepend Bus error *** Error code 138 ... kdump output shows: 14848 imake RET read 259/0x103 14848 imake CALL lseek(0x3,0,0,0,0) 14848 imake RET lseek 0 14848 imake CALL ftruncate(0x3,0,0,0) 14848 imake RET ftruncate 0 14848 imake PSIG SIGBUS SIG_DFL 14848 imake NAMI "imake.core" System is a 200MHz AMD K6, 64Mb EDO, various EIDE and SCSI drives. Any ideas? -aDe -- Ade Lovett, Demon Internet, Austin, Texas. From owner-freebsd-current Mon Jan 12 12:28:34 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA24969 for current-outgoing; Mon, 12 Jan 1998 12:28:34 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA24947 for ; Mon, 12 Jan 1998 12:28:20 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 5861 invoked by uid 1000); 13 Jan 1998 20:28:39 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801121334.AAA00363@word.smith.net.au> Date: Tue, 13 Jan 1998 12:28:39 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: RE: Commit Approval (was Re: Firewall in kernel? - Found it! ) Cc: Alex Nash , kong@kkk.ml.org, Studded@dal.net, current@freebsd.org, thyerm@camtech.net.au Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 12-Jan-98 Mike Smith wrote: ... >> > Your proposal's not new either. Your offer to help run it is, but >> > realistically do you feel that you have the time and stamina to do >> > nothing but vet endless permutations of changes to the system? >> >> Done manually, yes, it will take a lot of time. Automated, it will not. > > Ah yes, the wonderful concept of "automated software testing". 8( Yuck. This is not what I had in mind at all. I was wondering aloud on the need for automating some of these procedures. I have done it before, and though maybe we need it here too. >> Besides, I am already doing that. All I was proposing is to have a >> go/fail >> mechanism that serializes all requests and simply rejects those that >> fail >> to ``make buildworld''. > > Given a buildable state A, and desired target state C, how do I transit > between the two when it is necessary for me to make more than a single > commit? After the first commit I have an unbuildable but temporary > state B, which your system will reject. Why is it necessary to make more than a single commit to transition from given to desired? Just curious. I am looking at this whole thing as a dtatabase transaction, whith a clear BEGIN, checkpoints, and COMMIT. Maybe your point B is a checkpoint, meaning ``I want the change to `take' even if the transaction is to fail''. > And an automated buildability checker will help here? One with > 'buildworld' latency? Why not educate the developer population instead? > Rather than frustration and rejected commits, you get increased > productivity and happier hackers. You are raising two interesting points, which Julian already did. 1. We are willing to risk occasional breakage in the name of speed. 2. You prefer accuntability to procedure. I must admit that I accpt point 1 and agree with point 2. > Why is it that prohibition is so much easier to advocate than > commonsense? Because prohibition is procedural, ``fair'', anonymous and non-personal, thus, once agreed to, much easier in our society. >> Think about it as an ATM deposit into your checking account; It is not >> there officially until the transaction is verified, but you can deposit >> and >> forget. If you made no mistakes, the transaction becomes official. If >> not, you are told there is a problem. For ``correct'' CVS transactions >> this represents a delay of few hours. For bad transactions, it acts as >> an >> early warning system and reduces noise in this very list. > > That's an awfully big handwave there; counting a few notes is just ever > so *slightly* easier than verifying the real buildability of a commit, > let alone its correctness. Agree. I was not proposing an implementation. Just probing for acceptability of a concept. Seems to me I was proposing a solution to a non-problem. > As for noise on the list, that's not going to go away, or even reduce > much, just by removing the (really pretty rare) "-current build fails > with xxxxx" messages. Again, I must agree this is a ``noisy'' list. Probably its main attraction to many :-) > The current mechanism works amazingly well, and has shown a strong > improving trend over the last couple of years. Nuking it would be a > real Dilbert manouvre IMHO. Seems to me that we, by all accounts, have a great system wich does not require improvement at this time. No sarcasm here, really. So, my ``proposal'' was unnecessary and is thus dropped. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-current Mon Jan 12 12:48:48 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28039 for current-outgoing; Mon, 12 Jan 1998 12:48:48 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA28013; Mon, 12 Jan 1998 12:48:12 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id PAA00534; Mon, 12 Jan 1998 15:47:26 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801122047.PAA00534@dyson.iquest.net> Subject: Re: random (?) SIGBUS in -current In-Reply-To: <948.884633152@critter.freebsd.dk> from Poul-Henning Kamp at "Jan 12, 98 08:25:52 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 12 Jan 1998 15:47:26 -0500 (EST) Cc: toor@dyson.iquest.net, julian@whistle.com, dyson@freebsd.org, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp said: > > It looks like some page gets stolen, and the object isn't updated > accordingly... > > >Note that the new code follows the "rules" fairly precisely regarding the > >vnode free list. Some parts of the system might not be able to deal with > >it yet (maybe.) > > But this would be related to pages, they die with a pagefault... > Vnodes, objects and pages are all intimately related to each other. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Mon Jan 12 12:51:29 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28363 for current-outgoing; Mon, 12 Jan 1998 12:51:29 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA28343; Mon, 12 Jan 1998 12:51:13 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA14211; Mon, 12 Jan 1998 12:40:24 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd014208; Mon Jan 12 12:40:14 1998 Message-ID: <34BA7EF3.167EB0E7@whistle.com> Date: Mon, 12 Jan 1998 12:37:07 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Poul-Henning Kamp CC: "John S. Dyson" , dyson@freebsd.org, current@freebsd.org Subject: Re: random (?) SIGBUS in -current References: <948.884633152@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > > In message <199801121923.OAA00277@dyson.iquest.net>, "John S. Dyson" writes: > >Julian Elischer said: > >> > >> kernel from late last night > >> system got 85% through 'make world' before a process hung in 'D' state. > >> The rest of the system seemed ok. > >> > >> no sign of SIGBUS though. > >> > >I cannot reproduce the problem, with testing and compiles on 8MB, 16MB, and > >112MB systems. PHK, could you tell me more about your system? Are you > >running anything special, that I can reproduce the problem? > > HP800 laptop. 48M Ram. Pretty much vanilla -current. > > For instance, I use mh to read email. the "inc" program will often > sigbus when I have been running something else and rerun it to > see if there is new email. > > It looks like some page gets stolen, and the object isn't updated > accordingly... ahhhhh this looks very much like the problem I showed you when you were here last time john.. a page seems to be unmapped from a running process we see sig-11s from things such as cron, sendmail, perl not enough to stop the world, or make our product unreliable, but annnoying.. (our system is basically a batch system if the user clicks on a button and nothing happens they just assume it's windows and click onit again :) but this is on 2.2.5+x.. maybe the bug is older and is only being shown up by the new code. (you may be looking at the wrong place :) > > >Note that the new code follows the "rules" fairly precisely regarding the > >vnode free list. Some parts of the system might not be able to deal with > >it yet (maybe.) > > But this would be related to pages, they die with a pagefault... > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > "Drink MONO-tonic, it goes down but it will NEVER come back up!" From owner-freebsd-current Mon Jan 12 12:59:29 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA29491 for current-outgoing; Mon, 12 Jan 1998 12:59:29 -0800 (PST) (envelope-from owner-freebsd-current) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA29462; Mon, 12 Jan 1998 12:58:55 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA01162; Mon, 12 Jan 1998 21:54:23 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "John S. Dyson" cc: julian@whistle.com, dyson@freebsd.org, current@freebsd.org Subject: Re: random (?) SIGBUS in -current In-reply-to: Your message of "Mon, 12 Jan 1998 15:47:26 EST." <199801122047.PAA00534@dyson.iquest.net> Date: Mon, 12 Jan 1998 21:54:23 +0100 Message-ID: <1160.884638463@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199801122047.PAA00534@dyson.iquest.net>, "John S. Dyson" writes: >Poul-Henning Kamp said: >> >> It looks like some page gets stolen, and the object isn't updated >> accordingly... >> >> >Note that the new code follows the "rules" fairly precisely regarding the >> >vnode free list. Some parts of the system might not be able to deal with >> >it yet (maybe.) >> >> But this would be related to pages, they die with a pagefault... >> >Vnodes, objects and pages are all intimately related to each other. Yes, but the program runs part of the way before it dies, so we're not talking an entire vnode, object, but only a page or two... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" From owner-freebsd-current Mon Jan 12 13:07:21 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA00491 for current-outgoing; Mon, 12 Jan 1998 13:07:21 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA00396; Mon, 12 Jan 1998 13:06:32 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id QAA01060; Mon, 12 Jan 1998 16:05:11 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801122105.QAA01060@dyson.iquest.net> Subject: Re: random (?) SIGBUS in -current In-Reply-To: <1160.884638463@critter.freebsd.dk> from Poul-Henning Kamp at "Jan 12, 98 09:54:23 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 12 Jan 1998 16:05:11 -0500 (EST) Cc: toor@dyson.iquest.net, julian@whistle.com, dyson@freebsd.org, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp said: > In message <199801122047.PAA00534@dyson.iquest.net>, "John S. Dyson" writes: > >Poul-Henning Kamp said: > >> > >> It looks like some page gets stolen, and the object isn't updated > >> accordingly... > >> > >> >Note that the new code follows the "rules" fairly precisely regarding the > >> >vnode free list. Some parts of the system might not be able to deal with > >> >it yet (maybe.) > >> > >> But this would be related to pages, they die with a pagefault... > >> > >Vnodes, objects and pages are all intimately related to each other. > > Yes, but the program runs part of the way before it dies, so we're > not talking an entire vnode, object, but only a page or two... > When the vnodes are on the wrong list, exactly the same kind of problem can occur. Pages are and always have been protected off before freeing. If that is working correctly (which it should be), a new fault should bring a missing page back. If the pointers to the object or vnode are messed up, then a page will likely be demand zeroed, the wrong file will be referenced, or an error will be detected. It most likely isn't a problem with pages, but a problem with dangling references due to the new mechanism for vnode mangement. I already have seen a potential problem with the vnode management, and am trying to get it working before my flight to the Bay area. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Mon Jan 12 13:42:23 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA05151 for current-outgoing; Mon, 12 Jan 1998 13:42:23 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA04956 for ; Mon, 12 Jan 1998 13:40:48 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id QAA00220; Mon, 12 Jan 1998 16:40:36 -0500 (EST) (envelope-from toor) Message-Id: <199801122140.QAA00220@dyson.iquest.net> Subject: Re: wierd happening In-Reply-To: from Andrew Ryder at "Jan 12, 98 01:46:10 pm" To: aryder@bestweb.net (Andrew Ryder) Date: Mon, 12 Jan 1998 16:40:36 -0500 (EST) Cc: freebsd-current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Andrew Ryder said: > > I have a 3.0-CURRENT machine last cvsup'd on the 9th and have had some > wierd error with AccelX in it. > There are bugs in syscons and in the vfs/vm system. The vfs/vm system problems are still problematical, but not as bad as they were. Please back up to a -current as of 18-19 Dec if you need a stable system. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Mon Jan 12 14:24:20 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA10803 for current-outgoing; Mon, 12 Jan 1998 14:24:20 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA10635 for ; Mon, 12 Jan 1998 14:23:33 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id RAA00344 for current@freebsd.org; Mon, 12 Jan 1998 17:22:55 -0500 (EST) (envelope-from toor) Message-Id: <199801122222.RAA00344@dyson.iquest.net> Subject: Sorry, but -current still has problems To: current@freebsd.org Date: Mon, 12 Jan 1998 17:22:54 -0500 (EST) From: "John S. Dyson" Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am going to be at the Bay area for a few more days this week. Unfortunately, I don't have any resources there to work on things unless I am at work. So, it is unlikely that I'll be able to work on the problems until Friday. It looks like I have made some improvements in the object/vnode mgmt in my local tree, but it is still not good enough to commit. The problem is that the vnode/objects have to be put on the free list when they are in the right state. Unfortunately, the state transistions at unpleasant to handle times. There may also be some locking problems, but I am still researching it. I hope to be able to get a good week of work in soon, so these problems can be more easily resolved. All in all, the new code should work alot better when it is done. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Mon Jan 12 15:13:04 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA16448 for current-outgoing; Mon, 12 Jan 1998 15:13:04 -0800 (PST) (envelope-from owner-freebsd-current) Received: from didda.est.is (didda.est.is [194.144.208.205]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA16415 for ; Mon, 12 Jan 1998 15:12:14 -0800 (PST) (envelope-from totii@est.is) Received: from est.is (didda.est.is [192.168.255.1]) by didda.est.is (8.8.7/8.8.7) with ESMTP id XAA00691 for ; Mon, 12 Jan 1998 23:12:00 GMT (envelope-from totii@est.is) Message-ID: <34BAA33F.91584616@est.is> Date: Mon, 12 Jan 1998 23:11:59 +0000 From: Thordur Ivarsson X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: "current@FreeBSD.ORG" Subject: Error in 'files.i386' Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk When I config kernel I get this error: files.i386: i386/isa/npx.c must be optional or standard editing files.i386 fixes the problem but it remains after cvsup! I am running 2.2.5-stable as primary system but current as secondary. -- чСrПur мvarsson Thordur Ivarsson Rafeindavirki Electronic technician NorПurgЖtu 30 Nordurgotu 30 Box 309 Box 309 602 Akureyri 602 Akureyri мsland Iceland --------------------------------------------- FreeBSD has good features, Some others are full of unwanted features! --------------------------------------------- From owner-freebsd-current Mon Jan 12 15:17:27 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA16927 for current-outgoing; Mon, 12 Jan 1998 15:17:27 -0800 (PST) (envelope-from owner-freebsd-current) Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA16912 for ; Mon, 12 Jan 1998 15:17:18 -0800 (PST) (envelope-from tom@uniserve.com) Received: from shell.uniserve.com [204.244.186.218] by pop.uniserve.com with smtp (Exim 1.73 #1) id 0xrt5Y-00013g-00; Mon, 12 Jan 1998 15:16:12 -0800 Date: Mon, 12 Jan 1998 15:16:10 -0800 (PST) From: Tom To: Mike Smith cc: shimon@simon-shapiro.org, thyerm@camtech.net.au, current@freebsd.org, Studded@dal.net, kong@kkk.ml.org, Alex Nash Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) In-Reply-To: <199801121334.AAA00363@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 13 Jan 1998, Mike Smith wrote: ... > I can't imagine what else you might be doing. It's certainly not an > observation, as it has no basis in any observable fact or history, and > I was being too polite to suggest you were delusional... 8) I don't know about that. Current has been broken quite a bit lately. A good proof of this is NFS. When is the last time NFS worked properly? NFS seems to have fallen from grace from the 1.1.5.1 days, when people were ditching linux and others because of the rock-solid NFS in FreeBSD. Lots of this stuff in the archive. But now, NFS isn't that dependable. See archives again. ... > And an automated buildability checker will help here? One with > 'buildworld' latency? Why not educate the developer population instead? > Rather than frustration and rejected commits, you get increased > productivity and happier hackers. > > Why is it that prohibition is so much easier to advocate than > commonsense? Commonsense? Prohibition? Who knows... I don't understand why some developers are forced to make changes on branches, while others check stuff into the mainline branch? Perhaps branches should be used more often? This might prevent FreeBSD from getting stuck with unfinished chunks of code in the mainline branch. Tom From owner-freebsd-current Mon Jan 12 15:36:46 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA20087 for current-outgoing; Mon, 12 Jan 1998 15:36:46 -0800 (PST) (envelope-from owner-freebsd-current) Received: from helios.dnttm.ru (root@dnttm.wave.ras.ru [194.85.104.197]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA19984; Mon, 12 Jan 1998 15:35:57 -0800 (PST) (envelope-from dima@tejblum.dnttm.rssi.ru) Received: (from uucp@localhost) by helios.dnttm.ru (8.8.5/8.8.5/IP-3) with UUCP id CAA29769; Tue, 13 Jan 1998 02:16:42 +0300 Received: from tejblum.dnttm.rssi.ru (localhost [127.0.0.1]) by tejblum.dnttm.rssi.ru (8.8.8/8.8.7) with ESMTP id CAA01371; Tue, 13 Jan 1998 02:19:21 +0300 (MSK) (envelope-from dima@tejblum.dnttm.rssi.ru) Message-Id: <199801122319.CAA01371@tejblum.dnttm.rssi.ru> X-Mailer: exmh version 2.0gamma 1/27/96 To: Poul-Henning Kamp cc: dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: random (?) SIGBUS in -current In-reply-to: Your message of "Mon, 12 Jan 1998 16:58:11 +0100." <365.884620691@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jan 1998 02:19:21 +0300 From: Dmitrij Tejblum Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > > I see random SIGBUS in programs now on current up to and including: > > > dyson 1998/01/11 21:16:06 PST > > I believe I seen random SIGBUS and SIGSEGV with a december kernel. Dima From owner-freebsd-current Mon Jan 12 15:52:32 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22102 for current-outgoing; Mon, 12 Jan 1998 15:52:32 -0800 (PST) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA21977 for ; Mon, 12 Jan 1998 15:51:40 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id KAA00315; Tue, 13 Jan 1998 10:14:20 +1030 (CST) Message-Id: <199801122344.KAA00315@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: current@freebsd.org Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) In-reply-to: Your message of "Tue, 13 Jan 1998 12:28:39 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jan 1998 10:14:20 +1030 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >> > Your proposal's not new either. Your offer to help run it is, but > >> > realistically do you feel that you have the time and stamina to do > >> > nothing but vet endless permutations of changes to the system? > >> > >> Done manually, yes, it will take a lot of time. Automated, it will not. > > > > Ah yes, the wonderful concept of "automated software testing". 8( > > Yuck. This is not what I had in mind at all. I was wondering aloud on the > need for automating some of these procedures. I have done it before, and > though maybe we need it here too. I don't know whether "we need automated procedures". I agree wholeheartedly that there is still plenty of room for improvement; don't get me wrong on that one. My objections to your proposals have more to do with what seems practical in the context of the current development procedure. > > Given a buildable state A, and desired target state C, how do I transit > > between the two when it is necessary for me to make more than a single > > commit? After the first commit I have an unbuildable but temporary > > state B, which your system will reject. > > Why is it necessary to make more than a single commit to transition from > given to desired? Just curious. I am looking at this whole thing as a > dtatabase transaction, whith a clear BEGIN, checkpoints, and COMMIT. Maybe > your point B is a checkpoint, meaning ``I want the change to `take' even if > the transaction is to fail''. I was considering this point as well; being able to cluster a group of commits would be essential. Often you want to commit several sets of interrelated changes to widely separated components in the tree; eg. consider changing a header implementing a kernel interface (evil, yes, but let's consider it). You want to change the header, and the code in the tools that consume it. You don't want to have to check out large slices of the tree, make your changes and then commit the whole lot in one fell swoop. Instead, you commit the changes to each tool separately. This is both a convenience feature and also leads to more compact and relevant commit messages. In another case, imagine you have just made a minor commit to fix something, and you make a typo. Normal procedure is to immediately fix the fix. There's another situation where you have two developers; #1 commits code that is a prerequisite for #2's work. They may be on the phone to each other, or whatever. A 3-hour wait for vetting would really slow that sort of collaborative work down. One more practical problem; count the number of commits in a day. Multiply by 3 hours. If you want to serialise everything, that becomes a real issue. > > And an automated buildability checker will help here? One with > > 'buildworld' latency? Why not educate the developer population instead? > > Rather than frustration and rejected commits, you get increased > > productivity and happier hackers. > > You are raising two interesting points, which Julian already did. > > 1. We are willing to risk occasional breakage in the name of speed. > > 2. You prefer accuntability to procedure. > > I must admit that I accpt point 1 and agree with point 2. I'd agree with point #2 in this case simply because I feel that accountability is more effective. If I could see how procedure could be more effective I'd swap sides in an instant. > > Why is it that prohibition is so much easier to advocate than > > commonsense? > > Because prohibition is procedural, ``fair'', anonymous and non-personal, > thus, once agreed to, much easier in our society. "path of least resistance" I guess. > Agree. I was not proposing an implementation. Just probing for > acceptability of a concept. > > Seems to me I was proposing a solution to a non-problem. No, at least not to me. I felt you were proposing a non-solution to a problem.a > Seems to me that we, by all accounts, have a great system wich does not > require improvement at this time. No sarcasm here, really. We seem to have a system which is working reasonably well. There is historical precedent for resistance to any sort of change under the circumstances. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-current Mon Jan 12 15:58:54 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22726 for current-outgoing; Mon, 12 Jan 1998 15:58:54 -0800 (PST) (envelope-from owner-freebsd-current) Received: from most.weird.com (most.weird.com [204.92.254.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA22647 for ; Mon, 12 Jan 1998 15:58:02 -0800 (PST) (envelope-from woods@mail.weird.com) Received: from localhost (3668 bytes) by most.weird.com via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident using unix) id for ; Mon, 12 Jan 1998 18:56:20 -0500 (EST) (Smail-3.2.0.102-Pre 1997-Dec-17 #5 built 1998-Jan-8) Message-Id: Date: Mon, 12 Jan 1998 18:56:20 -0500 (EST) From: woods@most.weird.com (Greg A. Woods) To: Joerg Wunsch Cc: =?iso-8859-1?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= , Peter Wemm , FreeBSD-current , info-cvs@gnu.org Subject: Re: CVS DIFF fix for review (-L added) In-Reply-To: J. Wunsch's message of "Mon, January 12, 1998 08:20:22 +0100" regarding "Re: CVS DIFF fix for review (-L added)" id <19980112082022.30571@uriah.heep.sax.de> References: <199801111457.WAA06475@spinner.netplex.com.au> <19980112082022.30571@uriah.heep.sax.de> Reply-To: woods@weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.96 (beta) with GNU Emacs 19.34.1 (m68k.68881-sun-sunos4.1.1, X toolkit) of Thu Sep 12 1996 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [ On Mon, January 12, 1998 at 08:20:22 (+0100), J. Wunsch wrote: ] > Subject: Re: CVS DIFF fix for review (-L added) > > The idea of Index: was great, but there has never been a patch utility > supporting it the way CVS did expect. :-O Again, all the pre-existant > ``support'' for Index: lines taking precedence over context-diff > headers was _incidentally_. Oh, I beg to differ! It was upon my request that "Index:" was originally added to the `cvs diff' output, specifically to support patch. I think even the last release of patch by Larry Wall contained support for "Index:". However versions of GNU Patch since 2.3.7 have only supported the "Index:" tag when requested by setting the environment variable POSIXLY_CORRECT (or completely omitting filenames in the context header) [see note rule 2]. This from 2.4's manual: If no original file origfile is specified on the command line, patch tries to figure out from the leading garbage what the name of the file to edit is, using the following rules. + If the header is that of a context diff, patch takes the old and new file names in the header. Any /dev/null names are ignored. + If there is an Index: line in the leading garbage and if either the old and new names are both absent or the POSIXLY_CORRECT environment variable is set, patch takes the name in the Index: line. + For the purpose of the following rules, the names are considered to be in the order (old, new, index), regard- less of the order that they appear in the header. + If some of the named files exist, patch uses the first name if the POSIXLY_CORRECT environment variable is set, and the best name otherwise. + If patch is not ignoring RCS and SCCS (see the -g num or --get=num option), and no named files exist but an RCS or SCCS master is found, patch uses the first named file with an RCS or SCCS master. + If no named files exist, no RCS or SCCS master was found, some names are given, POSIXLY_CORRECT is not set, and the patch appears to create a file, patch uses the best name requiring the creation of the fewest directories. Unfortunately POSIX has made life difficult yet again (rule three seems to make the "Index:" header have the least precedence even when it would be more logical to have it the most precedence).... At least now it's all documented and "standard". -- Greg A. Woods +1 416 443-1734 VE3TCP Planix, Inc. ; Secrets of the Weird From owner-freebsd-current Mon Jan 12 16:35:09 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27571 for current-outgoing; Mon, 12 Jan 1998 16:35:09 -0800 (PST) (envelope-from owner-freebsd-current) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27156 for ; Mon, 12 Jan 1998 16:32:09 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id DAA27441; Tue, 13 Jan 1998 03:31:35 +0300 (MSK) (envelope-from ache) Date: Tue, 13 Jan 1998 03:31:32 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: "Greg A. Woods" cc: Joerg Wunsch , Peter Wemm , FreeBSD-current , info-cvs@gnu.org Subject: Re: CVS DIFF fix for review (-L added) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 12 Jan 1998, Greg A. Woods wrote: > Oh, I beg to differ! It was upon my request that "Index:" was > originally added to the `cvs diff' output, specifically to support > patch. I think even the last release of patch by Larry Wall contained > support for "Index:". However versions of GNU Patch since 2.3.7 have > only supported the "Index:" tag when requested by setting the > environment variable POSIXLY_CORRECT (or completely omitting filenames > in the context header) [see note rule 2]. This from 2.4's manual: Even POSIX isn't means simple Index: precedence taken, it is treated differently for existent and non-existent files, here is following comment from GNU patch 2.5 (latest) source: /* To intuit `inname', the name of the file to patch, use the algorithm specified by POSIX 1003.2b/D11 section 5.22.7.2 (with some modifications if posixly_correct is zero): - Take the old and new names from the context header if present, and take the index name from the `Index:' line if present and if either the old and new names are both absent or posixly_correct is nonzero. Consider the file names to be in the order (old, new, index). - If some named files exist, use the first one if posixly_correct is nonzero, the best one otherwise. ^^^^^^^^^^^^^^^^^^^^^^ old (first one) taken if posixly_correct !=0 ^^^^^^ - If patch_get is nonzero, and no named files exist, but an RCS or SCCS master file exists, use the first named file with an RCS or SCCS master. - If no named files exist, no RCS or SCCS master was found, some names are given, posixly_correct is zero, and the patch appears to create a file, then use the best name requiring the creation of the fewest directories. - Otherwise, report failure by setting `inname' to 0; this causes our invoker to ask the user for a file name. */ In any case CVS must not relay on such complex things just because any mistake here (or different environment) easily cause the same file patched many times or file from upper level patched instead of lower one; some of such errors are hard to detect. The method which works in any case with any patch and in any environment is adding -L option for diff to make consistent ***/--- (old,new) names. Index: line is good only for ed-style diffs (with absent file names). -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Mon Jan 12 16:40:47 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28122 for current-outgoing; Mon, 12 Jan 1998 16:40:47 -0800 (PST) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA27905; Mon, 12 Jan 1998 16:38:36 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id LAA03740; Tue, 13 Jan 1998 11:01:17 +1030 (CST) Message-Id: <199801130031.LAA03740@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Scott Michel cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org Subject: Re: NEC 273 CD-ROM In-reply-to: Your message of "Mon, 12 Jan 1998 10:52:26 -0800." <199801121852.KAA07318@mordred.cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jan 1998 11:01:15 +1030 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This is an ATAPI critter, but for some reason at bootstrap, there's > an out of phase error. Suggestions on how to debug it? (This should > mean: I'm willing to debug it, I'm willing to fix and patch the > driver, but how to I go about debugging?) Grab the ATAPI CDROM documentation (SFF-8020, available from fission.dt.wdc.com IIRC), and apply yourself to sys/i386/isa/wdc.c. You can build it as an LKM, which will make your life debugging somehat easier (as you can load/unload it without rebooting). One question; does the drive work despite the error? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-current Mon Jan 12 16:59:49 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA00246 for current-outgoing; Mon, 12 Jan 1998 16:59:49 -0800 (PST) (envelope-from owner-freebsd-current) Received: from watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA00106; Mon, 12 Jan 1998 16:58:58 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: by watermarkgroup.com (4.1/SMI-4.1) id AA24177; Mon, 12 Jan 98 19:58:20 EST Date: Mon, 12 Jan 98 19:58:20 EST From: luoqi@watermarkgroup.com (Luoqi Chen) Message-Id: <9801130058.AA24177@watermarkgroup.com> To: freebsd-current@FreeBSD.ORG, freebsd-multimedia@FreeBSD.ORG, scottm@cs.ucla.edu Subject: Re: NEC 273 CD-ROM Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Scott Michel wrote: > This is an ATAPI critter, but for some reason at bootstrap, there's > an out of phase error. Suggestions on how to debug it? (This should > mean: I'm willing to debug it, I'm willing to fix and patch the > driver, but how to I go about debugging?) I have the same drive and the same problem. The problem is that during bootstrap, interrupt is not used, instead, interrupt reason & status registers are polled to determine the phase. Because two registers are involved, chances are you may be reading when value of one reg. has changed and the other has not, and the driver reports an unknown phase error. I tried to fix it with unsatifactory results. Eventually I gave up, it wouldn't affect anything after the system is up. If you want to give it a try, look at function atapi_request_immediate(). You need to figure out when both ireason & status registers are stablized and would give a correct phase reading. > > > -scooter > -- > Scott Michel | In life, there are sheep and there are > UCLA Computer Science | wolves. > PhD Graduate Student | I don't bleat. > -lq From owner-freebsd-current Mon Jan 12 17:00:14 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00409 for current-outgoing; Mon, 12 Jan 1998 17:00:14 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA00210 for ; Mon, 12 Jan 1998 16:59:40 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 13520 invoked by uid 1000); 13 Jan 1998 01:00:19 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.3.p0.FreeBSD:980112170019:16207=_" In-Reply-To: <199801072203.OAA16705@implode.root.com> Date: Mon, 12 Jan 1998 17:00:19 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: David Greenman Subject: Re: Panic: kmem_malloc: kmem_map too small Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:980112170019:16207=_ Content-Type: text/plain; charset=us-ascii [ This one refuses to go away... ] On 07-Jan-98 David Greenman wrote: >>I receive that mainly under SMP, but looking at vm/vm_kern.c I do not see > > Sounds like you need to increase the kmem_map size - you're running > out > of malloc space. This can be done by changing VM_KMEM_SIZE in > /sys/i386/include/vmparam.h. The problem might indicate that you have a > very large system, a mistuned system, or perhaps could even indicate a > kernel memory leak. I suggest that you carefully analyze the output of > "vmstat -m" to determine where it's all going. I bumped the value from 32MB to 64MB and am still getting this panic. I am attaching the output of vmstat -m. I am looking at it but it does not tell me much. I observed it over a period of time, but nothing seems to systematically grow without shrinking. Thanx for any help... ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 --_=XFMail.1.3.p0.FreeBSD:980112170019:16207=_ Content-Disposition: attachment; filename="vmstat-m.out" Content-Transfer-Encoding: none Content-Description: Without any NFS activity Content-Type: application/octet-stream; name=vmstat-m.out; SizeOnDisk=5200 Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 16 91 165 1779 1280 0 32 55147 21 158349 640 0 64 89484 52 3995076 320 0 128 1084 68 20624 160 0 256 180561 15 527406 80 0 512 281 383 3022 40 167 1K 117 303 11242 20 2140 2K 328 18 1036 10 157 4K 17 1 90 5 0 8K 6 0 6 5 0 16K 15 0 15 5 0 32K 3 0 3 5 0 64K 3 0 3 5 0 128K 9 0 9 5 0 512K 4 0 4 5 0 Memory usage type by bucket size Size Type(s) 16 sysctl, mrt, soname, ether_multi, routetbl, pcb, IpFw/IpAcct, vnodes, proc, devbuf, temp 32 sysctl, soname, in_multi, ether_multi, pgrp, subproc, routetbl, pcb, vnodes, ifaddr, devbuf, temp, kld 64 NFS req, lockf, file, session, routetbl, pcb, namecache, ifaddr, devbuf, temp 128 ip_moptions, zombie, file desc, routetbl, pcb, IpFw/IpAcct, namecache, ZONE, cred, ttys, ifaddr, devbuf, temp 256 socket, VM map, file desc, subproc, FFS node, routetbl, pcb, NFS daemon, NFS srvsock, NFS node, vnodes, proc, devbuf, temp 512 NFSV3 diroff, NFS mount, ioctlops, file desc, UFS mount, BIO buffer, mount, pcb, proc, devbuf, temp 1K file desc, BIO buffer, NQNFS Lease, proc, devbuf, temp 2K file desc, UFS mount, BIO buffer, ttys, devbuf, mbuf 4K UFS mount, devbuf, temp 8K UFS mount, devbuf 16K UFS mount, devbuf 32K MSDOSFS mount, devbuf 64K NFS node, ISOFS mount, UFS ihash 128K namecache, devbuf 512K devbuf Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) NFSV3 diroff 71 36K 36K 39322K 82 0 0 512 NFS req 0 0K 1K 39322K 3232940 0 0 64 NFS mount 27 14K 14K 39322K 27 0 0 512 sysctl 0 0K 1K 39322K 3 0 0 16,32 lockf 3 1K 1K 39322K 173 0 0 64 mrt 2 1K 1K 39322K 2 0 0 16 ip_moptions 2 1K 1K 39322K 3 0 0 128 soname 29 1K 1K 39322K 1650 0 0 16,32 in_multi 5 1K 1K 39322K 5 0 0 32 ether_multi 16 1K 1K 39322K 16 0 0 16,32 socket 79 20K 21K 39322K 472 0 0 256 ioctlops 0 0K 1K 39322K 30 0 0 512 zombie 0 0K 1K 39322K 1362 0 0 128 file 129 9K 9K 39322K 305879 0 0 64 session 26 2K 2K 39322K 211 0 0 64 pgrp 29 1K 2K 39322K 383 0 0 32 VM map 51 13K 15K 39322K 1413 0 0 256 file desc 60 23K 28K 39322K 1788 0 0 128,256,512,1K,2K subproc 66 6K 8K 39322K 2790 0 0 32,256 FFS node 35103 8776K 8790K 39322K 278619 0 0 256 UFS mount 90 157K 157K 39322K 90 0 0 512,2K,4K,8K,16K BIO buffer 115 117K 419K 39322K 12527 0 0 512,1K,2K mount 58 29K 29K 39322K 58 0 0 512 routetbl 32 4K 5K 39322K 99 0 0 16,32,64,128,256 pcb 101 14K 16K 39322K 543 0 0 16,32,64,128,256, 512 IpFw/IpAcct 8 1K 1K 39322K 8 0 0 16,128 NQNFS Lease 1 1K 1K 39322K 1 0 0 1K NFS daemon 1 1K 1K 39322K 1 0 0 256 NFS srvsock 2 1K 1K 39322K 2 0 0 256 NFS node 54943 13800K 13802K 39322K 155058 0 0 256,64K MSDOSFS mount 1 32K 32K 39322K 1 0 0 32K ISOFS mount 1 64K 64K 39322K 1 0 0 64K UFS ihash 1 64K 64K 39322K 1 0 0 64K vnodes145070 24237K 24237K 39322K 246196 0 0 16,32,256 namecache 89403 5724K 5724K 39322K 456759 0 0 64,128,128K ZONE 7 1K 1K 39322K 7 0 0 128 cred 16 2K 3K 39322K 14471 0 0 128 proc 59 28K 32K 39322K 1478 0 0 16,256,512,1K ttys 638 86K 86K 39322K 1730 0 0 128,2K ifaddr 26 3K 3K 39322K 27 0 0 32,64,128 devbuf 677 4683K 4683K 39322K 820 0 0 16,32,64,128,256, 512,1K,2K,4K,8K,16K,32K,128K,512K mbuf 1 2K 2K 39322K 1 0 0 2K temp 200 29K 33K 39322K 936 0 0 16,32,64,128,256, 512,1K,4K kld 1 1K 1K 39322K 1 0 0 32 Memory Totals: In Use Free Requests 57971K 554K 4718664 --_=XFMail.1.3.p0.FreeBSD:980112170019:16207=_-- End of MIME message From owner-freebsd-current Mon Jan 12 17:02:44 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00707 for current-outgoing; Mon, 12 Jan 1998 17:02:44 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA00544; Mon, 12 Jan 1998 17:01:14 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA23101; Mon, 12 Jan 1998 16:55:04 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd023088; Mon Jan 12 16:55:01 1998 Message-ID: <34BABAA8.7DE14518@whistle.com> Date: Mon, 12 Jan 1998 16:51:52 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: Poul-Henning Kamp CC: "John S. Dyson" , dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: random (?) SIGBUS in -current References: <948.884633152@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > > >running anything special, that I can reproduce the problem? > > HP800 laptop. 48M Ram. Pretty much vanilla -current. is it a 486 or a 586? > From owner-freebsd-current Mon Jan 12 17:18:13 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA02460 for current-outgoing; Mon, 12 Jan 1998 17:18:13 -0800 (PST) (envelope-from owner-freebsd-current) Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA02300 for ; Mon, 12 Jan 1998 17:17:27 -0800 (PST) (envelope-from tom@uniserve.com) Received: from shell.uniserve.com [204.244.186.218] by pop.uniserve.com with smtp (Exim 1.73 #1) id 0xruyY-0004Bx-00; Mon, 12 Jan 1998 17:17:06 -0800 Date: Mon, 12 Jan 1998 17:17:03 -0800 (PST) From: Tom To: Mike Smith cc: shimon@simon-shapiro.org, thyerm@camtech.net.au, current@freebsd.org, Studded@dal.net, kong@kkk.ml.org, Alex Nash Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) In-Reply-To: <199801122350.KAA00344@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 13 Jan 1998, Mike Smith wrote: > > Commonsense? Prohibition? Who knows... I don't understand why some > > developers are forced to make changes on branches, while others check > > stuff into the mainline branch? > > Politics. Personal motivation. Percieved scope. The first. > If these issues really bother you, try (politely) asking one of the > core members. Whilst their deliberations are on a private list, I've > found they consider themselves quite accountable for their decisions. > > > Perhaps branches should be used more> often? This might prevent > > FreeBSD from getting stuck with unfinished chunks of code in the > > mainline branch. > > This opens more cans of worms with CVS, unfortunately. Some people are using branches for this now, simply because it was the only option available (see first paragraph). If it can be used by some projects, it should be possible to be used more widely. There are always going to be CVS issues, and integrating a branch into the mainline is always hard if the mainline has changed. > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ > > > > Tom From owner-freebsd-current Mon Jan 12 17:21:12 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA02771 for current-outgoing; Mon, 12 Jan 1998 17:21:12 -0800 (PST) (envelope-from owner-freebsd-current) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA02760 for ; Mon, 12 Jan 1998 17:20:27 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 13902 invoked by uid 1000); 13 Jan 1998 01:21:11 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801122344.KAA00315@word.smith.net.au> Date: Mon, 12 Jan 1998 17:21:11 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) Cc: current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 12-Jan-98 Mike Smith wrote: ... > I agree wholeheartedly that there is still plenty of room for > improvement; don't get me wrong on that one. My objections to your > proposals have more to do with what seems practical in the context of > the current development procedure. Agree. I was thinking about it in a different context. > I was considering this point as well; being able to cluster a group of > commits would be essential. > > Often you want to commit several sets of interrelated changes to widely > separated components in the tree; eg. consider changing a header > implementing a kernel interface (evil, yes, but let's consider it). > > You want to change the header, and the code in the tools that consume > it. You don't want to have to check out large slices of the tree, make > your changes and then commit the whole lot in one fell swoop. Instead, > you commit the changes to each tool separately. This is both a > convenience feature and also leads to more compact and relevant commit > messages. But, in between these commits, the tree is, by definition, broken. > In another case, imagine you have just made a minor commit to fix > something, and you make a typo. Normal procedure is to immediately > fix the fix. If you follow Julian's procedure, this would never happen. > There's another situation where you have two developers; #1 commits > code that is a prerequisite for #2's work. They may be on the phone to > each other, or whatever. A 3-hour wait for vetting would really slow > that sort of collaborative work down. In this case, developer #1 is the key holder, and #2 submits his/her changes to #1, which is now responsible for the whole transaction. Any other way, #2 may get there before #1 and break the tree. Can also ``work'' the other way around. > One more practical problem; count the number of commits in a day. > Multiply by 3 hours. If you want to serialise everything, that becomes > a real issue. This is where my superficial proposal really breaks. Using the compiler (and make) as a syntax checker is really bad. They are thorough but very slow and fragile. Something better and faster is needed. Sort of super-xref. ... >> 2. You prefer accuntability to procedure. >> >> I must admit that I accpt point 1 and agree with point 2. > > I'd agree with point #2 in this case simply because I feel that > accountability is more effective. If I could see how procedure could > be more effective I'd swap sides in an instant. Nah, procedure always gets implemented where accountability fails. By its nature, procedure fails too. ... > We seem to have a system which is working reasonably well. There is > historical precedent for resistance to any sort of change under the > circumstances. 8) Which is, in a way, a good thing. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-current Mon Jan 12 17:24:22 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA03174 for current-outgoing; Mon, 12 Jan 1998 17:24:22 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA03027 for ; Mon, 12 Jan 1998 17:23:57 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id SAA29263; Mon, 12 Jan 1998 18:23:46 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd029214; Mon Jan 12 18:23:37 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA11924; Mon, 12 Jan 1998 18:23:31 -0700 (MST) From: Terry Lambert Message-Id: <199801130123.SAA11924@usr01.primenet.com> Subject: Re: Architecture dependent source To: nate@mt.sri.com (Nate Williams) Date: Tue, 13 Jan 1998 01:23:31 +0000 (GMT) Cc: jb@freebsd1.cimlogic.com.au, current@FreeBSD.ORG In-Reply-To: <199801082332.QAA10804@mt.sri.com> from "Nate Williams" at Jan 8, 98 04:32:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Has the directory structure for architecture dependent source been > > decided? > > > > For instance, does src/sys/i386 become src/sys/arch/i386 (like NetBSD) > > or do we just start adding src/sys/alpha because i386 sets the precedent? > > Personally, I don't see that '/sys/arch' buys us anything other than > 'Yet Another directory'. Especially when there is no goal of having > every architecture under the sun working. > > But, I have no say in the matter, that would be David's choice to make. I would personally *love* to see /sys/kern/vfs* move to /sys/vfs/vfs* and the FS code itself to /sys/vfs/fs_name/... If there is going to be a big shuffle... well... "Never to a vast thing in a half-vast way"... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Jan 12 17:43:48 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA05898 for current-outgoing; Mon, 12 Jan 1998 17:43:48 -0800 (PST) (envelope-from owner-freebsd-current) Received: from taliesin.cs.ucla.edu (Taliesin.CS.UCLA.EDU [131.179.96.166]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA05819 for ; Mon, 12 Jan 1998 17:43:15 -0800 (PST) (envelope-from scottm@mordred.cs.ucla.edu) Received: (qmail 6237 invoked from network); 13 Jan 1998 01:42:57 -0000 Received: from mordred.cs.ucla.edu (131.179.48.34) by taliesin.cs.ucla.edu with SMTP; 13 Jan 1998 01:42:57 -0000 Received: from mordred (localhost [127.0.0.1]) by mordred.cs.ucla.edu (8.8.8/8.8.8) with ESMTP id RAA00309; Mon, 12 Jan 1998 17:43:08 -0800 (PST) (envelope-from scottm@mordred.cs.ucla.edu) Message-Id: <199801130143.RAA00309@mordred.cs.ucla.edu> X-Mailer: exmh version 2.0.1 12/23/97 To: "John S. Dyson" cc: phk@freebsd.org (Poul-Henning Kamp), dyson@freebsd.org, current@freebsd.org Subject: Re: random (?) SIGBUS in -current In-reply-to: Your message of "Mon, 12 Jan 1998 14:29:45 EST." <199801121929.OAA00321@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jan 1998 17:43:07 -0800 From: Scott Michel Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just got one, with a complete machine hose included. Problem was that I was in X at the time, and couldn't get over to a syscon. Sorry. Will see what I can do to get better information for you. But yes, there are a lot of spurious crashes, signal 11's from processes that couldn't/shouldn't (like xterm!!) -scooter -- Scott Michel | In life, there are sheep and there are UCLA Computer Science | wolves. PhD Graduate Student | I don't bleat. From owner-freebsd-current Mon Jan 12 17:44:48 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA06180 for current-outgoing; Mon, 12 Jan 1998 17:44:48 -0800 (PST) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA05761 for ; Mon, 12 Jan 1998 17:42:50 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id MAA04371; Tue, 13 Jan 1998 12:05:42 +1030 (CST) Message-Id: <199801130135.MAA04371@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , current@freebsd.org Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) In-reply-to: Your message of "Mon, 12 Jan 1998 17:21:11 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jan 1998 12:05:42 +1030 From: Mike Smith Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > You want to change the header, and the code in the tools that consume > > it. You don't want to have to check out large slices of the tree, make > > your changes and then commit the whole lot in one fell swoop. Instead, > > you commit the changes to each tool separately. This is both a > > convenience feature and also leads to more compact and relevant commit > > messages. > > But, in between these commits, the tree is, by definition, broken. That's correct. In most cases, such breakage works in the current system, assuming: - the breakage is fixed quickly (next commit(s) come soon), leaving the window in which someone else will be hurt as narrow as possible. - consumers are prepared to retry before complaining. I agree that we get by on probability rather than certainty. The more I talk about it, the shakier it sounds. 8) > > In another case, imagine you have just made a minor commit to fix > > something, and you make a typo. Normal procedure is to immediately > > fix the fix. > > If you follow Julian's procedure, this would never happen. True. However often enough a one-line fix is easier to type than to ship a diff around for, or it works in the context in which you have tested it but fails in a larger one. The "test it here first" process is definitely what all responsible developers should use. Always. *blush* > > There's another situation where you have two developers; #1 commits > > code that is a prerequisite for #2's work. They may be on the phone to > > each other, or whatever. A 3-hour wait for vetting would really slow > > that sort of collaborative work down. > > In this case, developer #1 is the key holder, and #2 submits his/her > changes to #1, which is now responsible for the whole transaction. > Any other way, #2 may get there before #1 and break the tree. Can also > ``work'' the other way around. That works, to a degree, too. It breaks down in terms of accountability though, in that #1's name is on #2's changes. There are lag and synchronisation issues too, not to mention the extra overhead for #2 to transfer all the brain state involved in their changes to #1. > This is where my superficial proposal really breaks. Using the compiler > (and make) as a syntax checker is really bad. They are thorough but very > slow and fragile. Something better and faster is needed. Sort of > super-xref. *grins* I'll take three, please. > > I'd agree with point #2 in this case simply because I feel that > > accountability is more effective. If I could see how procedure could > > be more effective I'd swap sides in an instant. > > Nah, procedure always gets implemented where accountability fails. > By its nature, procedure fails too. Ouch. For someone a few messages ago so hot on procedure your cynicism is scalding. 8) > > We seem to have a system which is working reasonably well. There is > > historical precedent for resistance to any sort of change under the > > circumstances. 8) > > Which is, in a way, a good thing. Perhaps. I am often concerned that we have a little too much inertia, but such a thing is very difficult to judge. Where does caution become conservatism, and conservatism become NIH or worse? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-current Mon Jan 12 17:57:54 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA08325 for current-outgoing; Mon, 12 Jan 1998 17:57:54 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA08317 for ; Mon, 12 Jan 1998 17:57:36 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id SAA16066; Mon, 12 Jan 1998 18:56:48 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd016012; Mon Jan 12 18:56:42 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id SAA14174; Mon, 12 Jan 1998 18:56:36 -0700 (MST) From: Terry Lambert Message-Id: <199801130156.SAA14174@usr01.primenet.com> Subject: Re: Firewall in kernel? - Found it! To: nash@mcs.net (Alex Nash) Date: Tue, 13 Jan 1998 01:56:36 +0000 (GMT) Cc: shimon@simon-shapiro.org, nash@mcs.net, kong@kkk.ml.org, Studded@dal.net, current@FreeBSD.ORG, thyerm@camtech.net.au In-Reply-To: <199801110242.UAA10815@nash.pr.mcs.net> from "Alex Nash" at Jan 10, 98 08:42:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > While these steps are highly recommendable (I try to check commits > against up-to-the-minute sources in a similar way), they can't prevent > problems such as the one involved in this thread (i.e. the exit codes > for ipfw causing breakage for the non-firewall kernels). No. That particular problem resulted from checking for the nonexistance of a specific error condition to signal success, instead of looking for the (single) specific success condition. In other words, it was just a bad test. Probably the best place to address that would be a "style" for the files involved (comments at the top, maybe?). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Jan 12 18:00:22 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA08860 for current-outgoing; Mon, 12 Jan 1998 18:00:22 -0800 (PST) (envelope-from owner-freebsd-current) Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA08666 for ; Mon, 12 Jan 1998 17:59:57 -0800 (PST) (envelope-from tom@uniserve.com) Received: from shell.uniserve.com [204.244.186.218] by pop.uniserve.com with smtp (Exim 1.73 #1) id 0xrvdl-00005h-00; Mon, 12 Jan 1998 17:59:41 -0800 Date: Mon, 12 Jan 1998 17:59:38 -0800 (PST) From: Tom To: Mike Smith cc: shimon@simon-shapiro.org, thyerm@camtech.net.au, current@freebsd.org, Studded@dal.net, kong@kkk.ml.org, Alex Nash Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) In-Reply-To: <199801130139.MAA04391@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 13 Jan 1998, Mike Smith wrote: > > > > Commonsense? Prohibition? Who knows... I don't understand why some > > > > developers are forced to make changes on branches, while others check > > > > stuff into the mainline branch? > > > > > > Politics. Personal motivation. Percieved scope. > > > > The first. > > All three, at various times, actually. Please be very careful judging > situations based on less than the complete set of facts, and remember > to take into account the entire situation. 8) I take into account only what I read. I've been chastised for doing this before, but it is the only information I have. Perhaps if "core" meeting minutes, or any other kind of "core" publication was made available, people could see more clearly where things are heading. You gave me three choices. As the developer in question said something about the "powers that be" made the decision, I doubt that the last two choices fit, leaving only the first. Doesn't preclude a fourth possibility though. I should clarified my original comment, because "politics" doesn't seem accurate to me either, but I assumed that you were refering to the same unnamed project that I was. ... > In addition to this, the administrative overhead would be not > inconsiderable. The burden on developers that need to deal with build problems in other parts of the tree is also considerable. I believe this is what prompted Simon's to start this thread. Simon is working a kernel based distribued lock manager. I don't think anyone here fails to see the value of this project. But when current is having so many problems it tends to stymie all other projects, other than the one that happens to be destablizing current. > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ > > > > Tom From owner-freebsd-current Mon Jan 12 18:07:54 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA09905 for current-outgoing; Mon, 12 Jan 1998 18:07:54 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA09880; Mon, 12 Jan 1998 18:07:34 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA13405; Mon, 12 Jan 1998 19:07:29 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpd013383; Mon Jan 12 19:07:26 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA15022; Mon, 12 Jan 1998 19:07:25 -0700 (MST) From: Terry Lambert Message-Id: <199801130207.TAA15022@usr01.primenet.com> Subject: Between Current and Stable... To: jmb@FreeBSD.ORG (Jonathan M. Bresler) Date: Tue, 13 Jan 1998 02:07:25 +0000 (GMT) Cc: current@FreeBSD.ORG In-Reply-To: <199801120138.RAA02641@hub.freebsd.org> from "Jonathan M. Bresler" at Jan 11, 98 05:38:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > amen brother! > > current is the bleeding edge. > stable is for those that dont want to or cant afford to bleed. > stable is also known as RELENG_2_2 in the cvs tree at this time. I would like to see something between -current and -stable. Not much. Perhaps no more than a -current that always compiles. Actually, I can't see how a -current that always compiles would not be in the best interests of all developers. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Jan 12 18:13:45 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA10759 for current-outgoing; Mon, 12 Jan 1998 18:13:45 -0800 (PST) (envelope-from owner-freebsd-current) Received: (from jmb@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA10704; Mon, 12 Jan 1998 18:13:23 -0800 (PST) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199801130213.SAA10704@hub.freebsd.org> Subject: Re: Between Current and Stable... To: tlambert@primenet.com (Terry Lambert) Date: Mon, 12 Jan 1998 18:13:22 -0800 (PST) Cc: jmb@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199801130207.TAA15022@usr01.primenet.com> from "Terry Lambert" at Jan 13, 98 02:07:25 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > amen brother! > > > > current is the bleeding edge. > > stable is for those that dont want to or cant afford to bleed. > > stable is also known as RELENG_2_2 in the cvs tree at this time. > > I would like to see something between -current and -stable. > > Not much. Perhaps no more than a -current that always compiles. > > Actually, I can't see how a -current that always compiles would not > be in the best interests of all developers. > hmm....like a snapshot of current at an aspicious moment in time? oh, yeah, that's right, we do make SNAPSHOTS. doh! ;) jmb From owner-freebsd-current Mon Jan 12 18:48:59 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16390 for current-outgoing; Mon, 12 Jan 1998 18:48:59 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16360 for ; Mon, 12 Jan 1998 18:48:38 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA23155; Mon, 12 Jan 1998 19:48:33 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd023126; Mon Jan 12 19:48:25 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA17582; Mon, 12 Jan 1998 19:48:23 -0700 (MST) From: Terry Lambert Message-Id: <199801130248.TAA17582@usr01.primenet.com> Subject: Re: Firewall in kernel? - Found it! To: mike@smith.net.au (Mike Smith) Date: Tue, 13 Jan 1998 02:48:23 +0000 (GMT) Cc: current@freebsd.org In-Reply-To: <199801120141.MAA00554@word.smith.net.au> from "Mike Smith" at Jan 12, 98 12:11:34 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Your proposal's not new either. Your offer to help run it is, but > realistically do you feel that you have the time and stamina to do > nothing but vet endless permutations of changes to the system? Don't vet. Just guarantee compiles. I. Add three new commands: cvs lock read Assert a read lock on the CVS tree cvs lock write Assert a write lock on the CVS tree cvs unlock Deassert a read or write lock on the CVS tree. If deasserting a write lock, you are prompted for a comment describing the one or more files written while the lock was asserted. II. Change the source tree to be world readable, but only group writeable; the cvs lock write adds the group to your current process and starts a subshell. You *must* write lock. You *should* provide a comment when you unlock. Unlocking a write lock creates a change tag associated with the lock. We can now see who broke the tree, and we can back out *only* the breakage. After each cvs command, the lock status is printed to remind people to unlock. The following is the lock truth-table: Current state is None R W W+PR R+PW W+PW Request R G G B B B(1) B(1) Request W G B B B(1) B(1) B Key G Lock is granted B Lock is blocked Notes 1 Write requests have higher priority than read requests. All blocked requests are queued and remain queued unless aborted. Write requests are served preferentially. III. Allow reads with override (attempt to update/checkout without a read lock will say "no read lock -- continue?". You may override this with -q or -Q, or by explicity typing "y"/"Y". Default is "n"/"N". This lets people who think write-locking will slow them down from reading choose to take the risk. IV. Locks over a certain age can be "forced". Age is determined by "time of last CVS operation". Force is allowed to members of specified group ("wheel"/"committers"/"core"/whatever). Alternately, other methods of "stale lock" detection can be used (idle tim, whether the user with the lock is logged in or not, etc. -- this is a policy decision for core). V. All CVS tree mirrors must obtain a read lock to mirror; this is implemented in the CVSup server process.. CVSsup is no longer permitted on the main repository machine, except by mirrors, to reduce the amount of time a read lock may be held on the main repository. This *guarantees* a tree snapshot will be internally consistent across a change. It does *not* guarantee that a tree will not be corrupted by a writer (that guarantee requires policy enforcement. VI. A policy is established whereby all commits must use the following procedure:" 1) cvs lock write 2) cvs update copy of tree 3) resolve conflicts, if any 4) apply patches, if any 5) verify compilation. If dependencies worked, this would be a "make" succeeding... i) Subtask: fix the damn make dependencies 6) If compilation fails, go to (3) 7) cvs unlock 8) Enter comment describing overall changes This will pretty much answer all complaints, except those of people too lazy to type "cvs lock write"/"cvs unlock", and/or too lazy to describe the changes they made, in vague terms. Do you really want those people committing code to your tree anyway? If the controls are in place, and policy is followed, the tree is *guaranteed* to always build. > We already *have* a lazy vetting system, with many hundreds if not > thousands of participants, and a reasonably adequate feedback > mechanism. Trying to improve substantially on this would require a lot > of work. 8) To those who say this will be cumbersome, I say "What drugs are you on!?! yYou are always telling me how this level of synchronization is unnecessary because there are only one or two people in at a time". To those who say "this solves a non-problem", I say "you are currently reading about the problem; see the list archives for other occurrances". This is *trivial* to implement. Worst case, you can write a front end program, call it "cvs" and run "realcvs" after validating the command arguments for read/write. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Jan 12 18:57:11 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17164 for current-outgoing; Mon, 12 Jan 1998 18:57:11 -0800 (PST) (envelope-from owner-freebsd-current) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17116; Mon, 12 Jan 1998 18:56:52 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.8/8.8.8) id DAA13663; Tue, 13 Jan 1998 03:53:15 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199801130253.DAA13663@ocean.campus.luth.se> Subject: Re: NEC 273 CD-ROM In-Reply-To: <199801130031.LAA03740@word.smith.net.au> from Mike Smith at "Jan 13, 98 11:01:15 am" To: mike@smith.net.au (Mike Smith) Date: Tue, 13 Jan 1998 03:53:15 +0100 (CET) Cc: scottm@cs.ucla.edu, freebsd-multimedia@FreeBSD.ORG, freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Mike Smith: > > This is an ATAPI critter, but for some reason at bootstrap, there's > > an out of phase error. Suggestions on how to debug it? (This should > > mean: I'm willing to debug it, I'm willing to fix and patch the > > driver, but how to I go about debugging?) > > Grab the ATAPI CDROM documentation (SFF-8020, available from > fission.dt.wdc.com IIRC), and apply yourself to sys/i386/isa/wdc.c. > > You can build it as an LKM, which will make your life debugging somehat > easier (as you can load/unload it without rebooting). > > One question; does the drive work despite the error? Just a note to say i've seen this error message too (I assume he means the "atapi1.0: unknown phase" one). My CD (Goldstar x4) gets that, but works just fine even so, it seems. /Mikael From owner-freebsd-current Mon Jan 12 18:57:58 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17287 for current-outgoing; Mon, 12 Jan 1998 18:57:58 -0800 (PST) (envelope-from owner-freebsd-current) Received: from mail.scsn.net (scsn.net [206.25.246.12]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17219; Mon, 12 Jan 1998 18:57:26 -0800 (PST) (envelope-from dmaddox@scsn.net) Received: from rhiannon.scsn.net ([208.133.153.80]) by mail.scsn.net (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-41950U6000L1100S0) with ESMTP id AAA66; Mon, 12 Jan 1998 21:55:08 -0500 Received: (from root@localhost) by rhiannon.scsn.net (8.8.8/8.8.7) id VAA26095; Mon, 12 Jan 1998 21:55:55 -0500 (EST) (envelope-from root) Message-ID: <19980112215555.06726@scsn.net> Date: Mon, 12 Jan 1998 21:55:55 -0500 From: dmaddox@scsn.net (Donald J. Maddox) To: Dmitrij Tejblum Cc: Poul-Henning Kamp , dyson@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: random (?) SIGBUS in -current Reply-To: dmaddox@scsn.net References: <365.884620691@critter.freebsd.dk> <199801122319.CAA01371@tejblum.dnttm.rssi.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199801122319.CAA01371@tejblum.dnttm.rssi.ru>; from Dmitrij Tejblum on Tue, Jan 13, 1998 at 02:19:21AM +0300 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Jan 13, 1998 at 02:19:21AM +0300, Dmitrij Tejblum wrote: > Poul-Henning Kamp wrote: > > > > I see random SIGBUS in programs now on current up to and including: > > > > > dyson 1998/01/11 21:16:06 PST > > > > > I believe I seen random SIGBUS and SIGSEGV with a december kernel. After today's CVSup update, make world, and kernel rebuild, I am getting a lot of bus errors. Imake _consistently_ exits with a bus error. My last rebuild prior to this one was about 1 1/2 weeks ago, and that build was fairly stable (i.e. no bus errors). From owner-freebsd-current Mon Jan 12 18:58:51 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA17386 for current-outgoing; Mon, 12 Jan 1998 18:58:51 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA17376 for ; Mon, 12 Jan 1998 18:58:41 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id TAA25510; Mon, 12 Jan 1998 19:58:32 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd025491; Mon Jan 12 19:58:26 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA18098; Mon, 12 Jan 1998 19:58:22 -0700 (MST) From: Terry Lambert Message-Id: <199801130258.TAA18098@usr01.primenet.com> Subject: Re: Architecture dependent source To: jonny@coppe.ufrj.br (Joao Carlos Mendes Luis) Date: Tue, 13 Jan 1998 02:58:22 +0000 (GMT) Cc: nate@mt.sri.com, jb@freebsd1.cimlogic.com.au, current@FreeBSD.ORG In-Reply-To: <199801122015.SAA17293@gaia.coppe.ufrj.br> from "Joao Carlos Mendes Luis" at Jan 12, 98 06:15:59 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > // Personally, I don't see that '/sys/arch' buys us anything other than > // 'Yet Another directory'. Especially when there is no goal of having > // every architecture under the sun working. > > It has the advantage of isolating architectures from other stuff. > A ls in the arch dir shows all architectures, and nothing else. > > I'm not sure, but think it's mostly cosmetic though. Hypothetically, what happens when you: cd /usr/src/include make install Specifically, /usr/include/sys, /usr/include/machine, /usr/include/ufs. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Jan 12 19:02:14 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA18031 for current-outgoing; Mon, 12 Jan 1998 19:02:14 -0800 (PST) (envelope-from owner-freebsd-current) Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA17252 for ; Mon, 12 Jan 1998 18:57:38 -0800 (PST) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg by adelphi.physics.adelaide.edu.au (5.65/AndrewR-930902) id AA23082; Tue, 13 Jan 1998 13:26:57 +1030 Received: by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA28613; Tue, 13 Jan 1998 13:27:47 +1030 Date: Tue, 13 Jan 1998 13:27:46 +1030 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Ade Lovett Cc: current@FreeBSD.ORG Subject: Re: 980112 current and imake SIGBUS In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 12 Jan 1998, Ade Lovett wrote: > > With today's -current kernel: > > FreeBSD gorgon.lovett.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: > Mon Jan 12 10:59:20 CST 1998 > root@gorgon.lovett.com:/usr/src/sys/compile/GORGON i386 > > I noticed that /usr/X11R6/bin/imake started dumping core (I initially > built X11R6 from /usr/ports after installing the machine when it was > running current-980106. Exactly the same problem with imake after a kernel compile last night. I can provide more information re my system if required, once I get home from work. Kris WOWBO /\ . Through the darkness of future past, /\ . BWOWB OBWOW /##\/#\ The Magician longs to see. /##\/#\ BOBWO WBOBW / \ One chance out between two worlds, / \ OWBOB WOWBO / \ Fire, Walk with me! / \ BWOWB From owner-freebsd-current Mon Jan 12 19:02:39 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA18138 for current-outgoing; Mon, 12 Jan 1998 19:02:39 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA18081 for ; Mon, 12 Jan 1998 19:02:24 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id UAA26138; Mon, 12 Jan 1998 20:01:02 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd026066; Mon Jan 12 20:00:58 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id UAA18374; Mon, 12 Jan 1998 20:00:50 -0700 (MST) From: Terry Lambert Message-Id: <199801130300.UAA18374@usr01.primenet.com> Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) To: tom@uniserve.com (Tom) Date: Tue, 13 Jan 1998 03:00:49 +0000 (GMT) Cc: mike@smith.net.au, shimon@simon-shapiro.org, thyerm@camtech.net.au, current@freebsd.org, Studded@dal.net, kong@kkk.ml.org, nash@Mcs.Net In-Reply-To: from "Tom" at Jan 12, 98 03:16:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I don't know about that. Current has been broken quite a bit > lately. A good proof of this is NFS. When is the last time NFS worked > properly? NFS seems to have fallen from grace from the 1.1.5.1 days, when > people were ditching linux and others because of the rock-solid NFS in > FreeBSD. Lots of this stuff in the archive. But now, NFS isn't that > dependable. See archives again. NFS is one of the things I'd like to be able to work on. Only I'm not willing to do it by starting over with a stock -current FS subsystem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Jan 12 19:04:14 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA18410 for current-outgoing; Mon, 12 Jan 1998 19:04:14 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA18334 for ; Mon, 12 Jan 1998 19:03:46 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA00303; Mon, 12 Jan 1998 19:54:08 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp04.primenet.com, id smtpd000241; Mon Jan 12 19:53:58 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id TAA17781; Mon, 12 Jan 1998 19:53:52 -0700 (MST) From: Terry Lambert Message-Id: <199801130253.TAA17781@usr01.primenet.com> Subject: Re: Commit Approval (was Re: Firewall in kernel? - Found it! ) To: mike@smith.net.au (Mike Smith) Date: Tue, 13 Jan 1998 02:53:51 +0000 (GMT) Cc: shimon@simon-shapiro.org, mike@smith.net.au, thyerm@camtech.net.au, current@FreeBSD.ORG, Studded@dal.net, kong@kkk.ml.org, nash@Mcs.Net In-Reply-To: <199801121334.AAA00363@word.smith.net.au> from "Mike Smith" at Jan 13, 98 00:04:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Why is it that prohibition is so much easier to advocate than > commonsense? Because you can automatically enforce the former, but not the latter. Is this a trick question? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Mon Jan 12 19:30:44 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA21703 for current-outgoing; Mon, 12 Jan 1998 19:30:44 -0800 (PST) (envelope-from owner-freebsd-current) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA21678 for ; Mon, 12 Jan 1998 19:30:27 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id TAA18904; Mon, 12 Jan 1998 19:28:57 -0800 (PST) Message-Id: <199801130328.TAA18904@implode.root.com> To: shimon@simon-shapiro.org cc: freebsd-current@FreeBSD.ORG Subject: Re: Panic: kmem_malloc: kmem_map too small In-reply-to: Your message of "Mon, 12 Jan 1998 17:00:19 PST." From: David Greenman Reply-To: dg@root.com Date: Mon, 12 Jan 1998 19:28:57 -0800 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > vnodes145070 24237K 24237K 39322K 246196 0 0 16,32,256 Huh - 145070 vnodes? How much physical memory is in this machine? I have a gigabyte of RAM in wcarchive and it peaks at about 87,000. This looks like a vnode leak to me. Which version of FreeBSD is this? >Memory Totals: In Use Free Requests > 57971K 554K 4718664 ...no surprise that the machine is panicing. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Mon Jan 12 19:58:57 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25375 for current-outgoing; Mon, 12 Jan 1998 19:58:57 -0800 (PST) (envelope-from owner-freebsd-current) Received: from miro.bestweb.net (miro.bestweb.net [209.94.100.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA25225; Mon, 12 Jan 1998 19:58:09 -0800 (PST) (envelope-from aryder@bestweb.net) Received: from okeefe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by miro.bestweb.net (8.8.8/8.8.8) with ESMTP id XAA05183; Mon, 12 Jan 1998 23:02:43 -0500 (EST) Received: from monet.bestweb.net (aryder@monet.bestweb.net [209.94.100.120]) by okeefe.bestweb.net (8.8.7/8.8.8) with SMTP id WAA17678; Mon, 12 Jan 1998 22:58:02 -0500 (EST) Date: Mon, 12 Jan 1998 22:58:02 -0500 (EST) From: Andrew Ryder To: "John S. Dyson" cc: freebsd-current@FreeBSD.ORG Subject: Re: wierd happening In-Reply-To: <199801122140.QAA00220@dyson.iquest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 12 Jan 1998, John S. Dyson wrote: > Andrew Ryder said: > > > > I have a 3.0-CURRENT machine last cvsup'd on the 9th and have had some > > wierd error with AccelX in it. > > > > There are bugs in syscons and in the vfs/vm system. The vfs/vm system > problems are still problematical, but not as bad as they were. Please > back up to a -current as of 18-19 Dec if you need a stable system. ahh.. do you know the exact problem or program which causes this? or is it something you cant really say? From owner-freebsd-current Wed Jan 14 08:27:49 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16695 for current-outgoing; Wed, 14 Jan 1998 08:27:49 -0800 (PST) (envelope-from owner-freebsd-current) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16291 for freebsd-current@freebsd.org; Wed, 14 Jan 1998 08:24:29 -0800 (PST) (envelope-from jmb) Date: Wed, 14 Jan 1998 08:24:29 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199801141624.IAA16291@hub.freebsd.org> To: freebsd-current@freebsd.org Subject: lists shoudl be back soon Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk working on them now jmb From owner-freebsd-current Wed Jan 14 08:28:49 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16923 for current-outgoing; Wed, 14 Jan 1998 08:28:49 -0800 (PST) (envelope-from owner-freebsd-current) Received: (from root@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA16885 for freebsd-current@freebsd.org; Wed, 14 Jan 1998 08:28:29 -0800 (PST) (envelope-from jmb) Date: Wed, 14 Jan 1998 08:28:29 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199801141628.IAA16885@hub.freebsd.org> To: freebsd-current@freebsd.org Subject: lists should be back soon Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk wokring on then now. jmb From owner-freebsd-current Wed Jan 14 11:55:08 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA16097 for current-outgoing; Wed, 14 Jan 1998 11:55:08 -0800 (PST) (envelope-from owner-freebsd-current) Received: from super-g.inch.com ([207.240.140.161]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA16080 for ; Wed, 14 Jan 1998 11:54:52 -0800 (PST) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id OAA08270; Wed, 14 Jan 1998 14:54:37 -0500 (EST) Date: Wed, 14 Jan 1998 14:54:37 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: "David M. Holloway" cc: freebsd-current@freebsd.org Subject: Re: LAND attack In-Reply-To: <199801090138.RAA29799@soda.CSUA.Berkeley.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, This is interesting. We have a machine that is "patched", but seems to still be getting hit by land. It has lots of virtual interfaces. Have you received any feedback on this question? Thanks, Charles Sprickman spork@super-g.com ---- "I'm not a prophet or a stone-age man Just a mortal with potential of a superman I'm living on" -DB On Thu, 8 Jan 1998, David M. Holloway wrote: > Regarding this little addition in tcp_input.c > This doesnt appear to guard against attacks > where the sender and receiver are different > ip address but happen to be the same machine(multi-homed) > > Any comments? > > /* > * Reject attempted self-connects. XXX This actually masks > * a bug elsewhere, since self-connect should work. > * However, a urrently-active DoS attack in the Internet > * sends a phony self-connect request which causes an infinite > * loop. > */ > if (ti->ti_src.s_addr == ti->ti_dst.s_addr > && ti->ti_sport == ti->ti_dport) { > tcpstat.tcps_badsyn++; > goto drop; > } > > /* > From owner-freebsd-current Wed Jan 14 14:53:52 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA09481 for current-outgoing; Wed, 14 Jan 1998 14:53:52 -0800 (PST) (envelope-from owner-freebsd-current) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA09388 for ; Wed, 14 Jan 1998 14:53:30 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 755 invoked by uid 1000); 14 Jan 1998 20:27:34 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-010198 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199801130328.TAA18904@implode.root.com> Date: Wed, 14 Jan 1998 12:27:34 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: David Greenman Subject: Re: Panic: kmem_malloc: kmem_map too small Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 13-Jan-98 David Greenman wrote: >> vnodes145070 24237K 24237K 39322K 246196 0 0 16,32,256 > > Huh - 145070 vnodes? How much physical memory is in this machine? I > have > a gigabyte of RAM in wcarchive and it peaks at about 87,000. This looks > like > a vnode leak to me. Which version of FreeBSD is this? 384MB or RAM. 3.0-current as of 12-Jan. What do I do about the vnode leak? The way to trigger it is to cd into one LARGE directory and do ``find . | cpio -dmpv /Destination'' >>Memory Totals: In Use Free Requests >> 57971K 554K 4718664 I have seen the FREE go down to 38K or so. > ...no surprise that the machine is panicing. Dumb Question: Which is the alert and why? ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-current Wed Jan 14 15:27:26 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14375 for current-outgoing; Wed, 14 Jan 1998 15:27:26 -0800 (PST) (envelope-from owner-freebsd-current) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA13616 for ; Wed, 14 Jan 1998 15:20:07 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id PAA08559; Wed, 14 Jan 1998 15:23:38 -0800 (PST) Message-Id: <199801142323.PAA08559@implode.root.com> To: shimon@simon-shapiro.org cc: freebsd-current@FreeBSD.ORG Subject: Re: Panic: kmem_malloc: kmem_map too small In-reply-to: Your message of "Wed, 14 Jan 1998 12:27:34 PST." From: David Greenman Reply-To: dg@root.com Date: Wed, 14 Jan 1998 15:23:38 -0800 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >On 13-Jan-98 David Greenman wrote: >>> vnodes145070 24237K 24237K 39322K 246196 0 0 16,32,256 >> >> Huh - 145070 vnodes? How much physical memory is in this machine? I >> have >> a gigabyte of RAM in wcarchive and it peaks at about 87,000. This looks >> like >> a vnode leak to me. Which version of FreeBSD is this? > >384MB or RAM. 3.0-current as of 12-Jan. > >What do I do about the vnode leak? I guess you wait until John has fixed the leak - I'm pretty sure this is one of the recent bugs that he's been working on resolving. >The way to trigger it is to cd into one LARGE directory and do >``find . | cpio -dmpv /Destination'' > > >>>Memory Totals: In Use Free Requests >>> 57971K 554K 4718664 > >I have seen the FREE go down to 38K or so. "Free" doesn't matter; ignore that. >> ...no surprise that the machine is panicing. > >Dumb Question: Which is the alert and why? "In Use" is in outer space. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-current Wed Jan 14 20:56:23 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA20159 for current-outgoing; Wed, 14 Jan 1998 20:56:23 -0800 (PST) (envelope-from owner-freebsd-current) Received: from tor-adm1.nbc.netcom.ca (taob@tor-adm1.nbc.netcom.ca [207.181.89.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA19971 for ; Wed, 14 Jan 1998 20:55:07 -0800 (PST) (envelope-from taob@tor-adm1.nbc.netcom.ca) Received: (from taob@localhost) by tor-adm1.nbc.netcom.ca (8.8.5/8.8.5) id XAA08481; Wed, 14 Jan 1998 23:55:06 -0500 (EST) Date: Wed, 14 Jan 1998 23:55:06 -0500 (EST) From: Brian Tao X-Sender: taob@tor-adm1 To: FREEBSD-CURRENT Subject: gcc 2.8.0 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -rw-r--r-- 1 14910 23059 8477747 Jan 14 01:52 gcc-2.8.0.tar.gz -rw-r--r-- 1 14910 23059 2282644 Jan 14 05:31 libg++-2.8.0.tar.gz -rw-r--r-- 1 14910 23059 811260 Jan 14 01:53 libstdc++-2.8.0.tar.gz Anyone try 'em out yet? -- Brian Tao (BT300, taob@netcom.ca) "Though this be madness, yet there is method in't" From owner-freebsd-current Wed Jan 14 21:52:56 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA27886 for current-outgoing; Wed, 14 Jan 1998 21:52:56 -0800 (PST) (envelope-from owner-freebsd-current) Received: from internet1.mel.cybec.com.au (internet1.mel.cybec.com.au [203.103.154.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA27714 for ; Wed, 14 Jan 1998 21:51:10 -0800 (PST) (envelope-from TLiddelow@cybec.com.au) Received: from cybec.com.au (tech34.mel.cybec.com.au [203.103.154.37]) by internet1.mel.cybec.com.au (post.office MTA v2.0 0813 ID# 0-14031) with ESMTP id AAA333; Thu, 15 Jan 1998 16:52:55 +1100 Message-ID: <34BDA399.2F3F8E92@cybec.com.au> Date: Thu, 15 Jan 1998 16:50:17 +1100 From: TLiddelow@cybec.com.au (Tim Liddelow) Organization: Cybec Pty Ltd X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Brian Tao CC: FREEBSD-CURRENT Subject: Re: gcc 2.8.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brian Tao wrote: > > -rw-r--r-- 1 14910 23059 8477747 Jan 14 01:52 gcc-2.8.0.tar.gz > -rw-r--r-- 1 14910 23059 2282644 Jan 14 05:31 libg++-2.8.0.tar.gz > -rw-r--r-- 1 14910 23059 811260 Jan 14 01:53 libstdc++-2.8.0.tar.gz > > Anyone try 'em out yet? Nope, but I did try out egcs-1.0.1 and it didn't install seamlessly; I haven't quite determined whether egcs isn't right or FreeBSD has a problem. I am interested in the new pentium optimisations and also the much improved template support for C++. As the back end optimiser has been improved, C will benefit as well. Cheers Tim. -- ==================================================================== Tim Liddelow * Internet Consulting Internet Project Manager * * Cybec Pty Ltd * Anti Virus/Firewalls/Security Phone: +61 3 9825 5645 C++/UNIX/WIN32/OOP/OOD/WWW mailto:TLiddelow@cybec.com.au * http://www.vet.com.au/ ===================================================================== From owner-freebsd-current Wed Jan 14 23:03:59 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA05734 for current-outgoing; Wed, 14 Jan 1998 23:03:59 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dan.emsphone.com (dan@dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA05709 for ; Wed, 14 Jan 1998 23:03:42 -0800 (PST) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.8.6/8.8.6) id BAA11681; Thu, 15 Jan 1998 01:03:37 -0600 (CST) Message-ID: <19980115010336.51647@emsphone.com> Date: Thu, 15 Jan 1998 01:03:36 -0600 From: Dan Nelson To: Tim Liddelow Cc: Brian Tao , FREEBSD-CURRENT Subject: Re: gcc 2.8.0 References: <34BDA399.2F3F8E92@cybec.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.13 In-Reply-To: <34BDA399.2F3F8E92@cybec.com.au>; from "Tim Liddelow" on Thu Jan 15 16:50:17 GMT 1998 X-OS: FreeBSD 2.2-970701-RELENG Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In the last episode (Jan 15), Tim Liddelow said: > Brian Tao wrote: > > Anyone try 'em out yet? > > Nope, but I did try out egcs-1.0.1 and it didn't install seamlessly; > I haven't quite determined whether egcs isn't right or FreeBSD has a > problem. I am interested in the new pentium optimisations and also > the much improved template support for C++. As the back end > optimiser has been improved, C will benefit as well. Hm. I installed egcs + pgcc patches with no errors at all: -rw-rw-r-- 1 dan devel 243986 Jan 5 08:43 egcs-1.0.1-pgcc-1.0.1.diff.gz -rw-rw-r-- 1 dan devel 6700735 Jan 3 17:19 egcs-core-1.0.1.tar.gz -rw-rw-r-- 1 dan devel 1318704 Jan 3 17:19 egcs-g++-1.0.1.tar.gz extracted them, applied the patch, cd'd into the gcc directory (i.e. I did _not_ build the other subdirs), ran ./configure --with-gnu-as --with-gnu-ld --with-exec-prefix=p Then did a make bootstrap LANGUAGES="c c++", then a make install. I haven't tried pgc++ yet, but plain pgcc seems to work. Haven't done any timing tests either, but the few programs I've recompiled don't really feel any faster. $ pgcc -v Reading specs from /usr/local/lib/gcc-lib/i386-unknown-freebsd2.2/pgcc-2.90.23/specs gcc version pgcc-2.90.23 980102 (egcs-1.0.1 release) -Dan Nelson dnelson@emsphone.con From owner-freebsd-current Wed Jan 14 23:43:34 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA10141 for current-outgoing; Wed, 14 Jan 1998 23:43:34 -0800 (PST) (envelope-from owner-freebsd-current) Received: from internet1.mel.cybec.com.au (internet1.mel.cybec.com.au [203.103.154.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA10130 for ; Wed, 14 Jan 1998 23:43:28 -0800 (PST) (envelope-from TLiddelow@cybec.com.au) Received: from cybec.com.au (tech34.mel.cybec.com.au [203.103.154.37]) by internet1.mel.cybec.com.au (post.office MTA v2.0 0813 ID# 0-14031) with ESMTP id AAA334; Thu, 15 Jan 1998 18:45:27 +1100 Message-ID: <34BDBDFD.6529690@cybec.com.au> Date: Thu, 15 Jan 1998 18:42:53 +1100 From: TLiddelow@cybec.com.au (Tim Liddelow) Organization: Cybec Pty Ltd X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Dan Nelson CC: Brian Tao , FREEBSD-CURRENT Subject: Re: gcc 2.8.0 References: <34BDA399.2F3F8E92@cybec.com.au> <19980115010336.51647@emsphone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > -rw-rw-r-- 1 dan devel 243986 Jan 5 08:43 egcs-1.0.1-pgcc-1.0.1.diff.gz > -rw-rw-r-- 1 dan devel 6700735 Jan 3 17:19 egcs-core-1.0.1.tar.gz > -rw-rw-r-- 1 dan devel 1318704 Jan 3 17:19 egcs-g++-1.0.1.tar.gz > > extracted them, applied the patch, cd'd into the gcc directory (i.e. I > did _not_ build the other subdirs), ran > > ./configure --with-gnu-as --with-gnu-ld --with-exec-prefix=p > > Then did a make bootstrap LANGUAGES="c c++", then a make install. I > haven't tried pgc++ yet, but plain pgcc seems to work. Haven't done > any timing tests either, but the few programs I've recompiled don't > really feel any faster. Oh well...I didn't do a configure with gnu as or gnu ld. That wasn't the problem; the problem is that I didn't specify the LANGUAGES line and as a result it built the f77 stuff which died while comparing files from a couple of stages. I didn't care about the fortran stuff, so the way I got it installed was to do exactly what you did. Should I reconfigure using gnu as and gnu ld ? System is 2.2-STABLE, by the way. Cheers Tim. -- ==================================================================== Tim Liddelow * Internet Consulting Internet Project Manager * * Cybec Pty Ltd * Anti Virus/Firewalls/Security Phone: +61 3 9825 5645 C++/UNIX/WIN32/OOP/OOD/WWW mailto:TLiddelow@cybec.com.au * http://www.vet.com.au/ ===================================================================== From owner-freebsd-current Thu Jan 15 02:42:44 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA01388 for current-outgoing; Thu, 15 Jan 1998 02:42:44 -0800 (PST) (envelope-from owner-freebsd-current) Received: from penrose.isocor.ie (penrose.isocor.ie [194.106.155.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA01320 for ; Thu, 15 Jan 1998 02:42:00 -0800 (PST) (envelope-from peter.edwards@isocor.ie) Received: from isocor.ie (194.106.155.26) by penrose.isocor.ie; 15 Jan 1998 10:40:46 +0000 Message-ID: <34BDE762.214739B9@isocor.ie> Date: Thu, 15 Jan 1998 10:39:30 +0000 From: Peter Edwards Organization: ISOCOR X-Mailer: Mozilla 4.04 [en] (WinNT; I) 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 X-Loop: FreeBSD.org Precedence: bulk subscribe freebsd-current subscribe cvs-all From owner-freebsd-current Thu Jan 15 04:42:04 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA14460 for current-outgoing; Thu, 15 Jan 1998 04:42:04 -0800 (PST) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA14351 for ; Thu, 15 Jan 1998 04:40:47 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id XAA25568; Thu, 15 Jan 1998 23:40:18 +1100 Date: Thu, 15 Jan 1998 23:40:18 +1100 From: Bruce Evans Message-Id: <199801151240.XAA25568@godzilla.zeta.org.au> To: current@FreeBSD.ORG, luoqi@watermarkgroup.com Subject: Re: gdb addressing off by 0x20 Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [This may have been lost when hub.freebsd.org was down.] >> >Has anyone else noticed this? When I debug a program with gdb, I have to >> >specify x+0x20 if I want to get data at address x. For example, >> ^^^^ text >> >> Oops. Try this fix. >Thanks, it works. But there seems to be some problem on dependency generation. >The first time, I did a simple make, only one file was recompiled and the >problem didn't go away. Only after I have done a make clean, then followed by >make, it worked correctly. Here only one file was recompiled and the problem did go away :-). Dependencies on libraries (libbfd.a in this case) aren't generated right if the library is described by `-Lfoo -lbar' and doesn't already exist. `ld -f' can't find the library, and it does nothing because emitting a wrong library name breaks the dependencies even more. DPADD gives the dependencies in cases where it is set properly (including for gdb), but isn't used since automatic generation of library dependencies is supposed to work. This problem is made worse by bsd.dep.mk's smartness about not rebuilding .depend. foo/bar.a instead of -Lfoo -lbar works right. -lbar is only better for libraries that might be shared. The makefiles have to know all about where nonstandard libraries are to issue -Lfoo's. Bruce From owner-freebsd-current Thu Jan 15 04:47:18 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA14907 for current-outgoing; Thu, 15 Jan 1998 04:47:18 -0800 (PST) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA14794; Thu, 15 Jan 1998 04:46:06 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id XAA25673; Thu, 15 Jan 1998 23:42:48 +1100 Date: Thu, 15 Jan 1998 23:42:48 +1100 From: Bruce Evans Message-Id: <199801151242.XAA25673@godzilla.zeta.org.au> To: dyson@freebsd.org Subject: panic: vm_object_deallocate: deallocated too many times Cc: current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [This may have been lost when hub.freebsd.org was down.] The following command usually causes a panic when /usr is nfs-mounted: umount -Af -t nfs The panic usually occurs when syslogd exits. Bruce GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... IdlePTD 390000 current pcb at 2302b8 panicstr: vm_object_deallocate: object deallocated too many times panic messages: --- panic: vm_object_deallocate: object deallocated too many times syncing disks... done dumping to dev 401, offset 65536 dump 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 boot (howto=256) at ./@/kern/kern_shutdown.c:285 285 dumppcb.pcb_cr3 = rcr3(); (kgdb) where #0 boot (howto=256) at ./@/kern/kern_shutdown.c:285 #1 0xf0120557 in panic ( fmt=0xf01d7f3b "vm_object_deallocate: object deallocated too many times") at ./@/kern/kern_shutdown.c:425 #2 0xf01d7fbc in vm_object_deallocate (object=0xf035344c) at ./@/vm/vm_object.c:295 #3 0xf01d5a00 in vm_map_entry_delete (map=0xf06a4500, entry=0xf476c828) at ./@/vm/vm_map.c:1784 #4 0xf01d5b7c in vm_map_delete (map=0xf06a4500, start=0, end=4022329344) at ./@/vm/vm_map.c:1877 #5 0xf01d5c04 in vm_map_remove (map=0xf06a4500, start=0, end=4022329344) at ./@/vm/vm_map.c:1911 #6 0xf01195f8 in exit1 (p=0xf06b9400, rv=11) at ./@/kern/kern_exit.c:213 #7 0xf01217e6 in sigexit (p=0xf06b9400, signum=11) at ./@/kern/kern_sig.c:1222 #8 0xf01215e3 in postsig (signum=11) at ./@/kern/kern_sig.c:1130 #9 0xf01ef7d8 in trap (frame={tf_es = 39, tf_ds = 39, tf_edi = -272646808, tf_esi = 32, tf_ebp = -272638376, tf_isp = -196325404, tf_ebx = 537455056, tf_edx = -1, tf_ecx = 3, tf_eax = 1, tf_trapno = 12, tf_err = 1, tf_eip = 7798, tf_cs = 31, tf_eflags = 66118, tf_esp = -272646880, tf_ss = 39}) at ./@/i386/i386/trap.c:166 #10 0x1e76 in ?? () Cannot access memory at address 0xefbfde5c. (kgdb) up 2 #2 0xf01d7fbc in vm_object_deallocate (object=0xf035344c) at ./@/vm/vm_object.c:295 295 return; (kgdb) p *object $1 = {object_list = {tqe_next = 0xf0352aec, tqe_prev = 0xf47939d8}, shadow_head = {tqh_first = 0x0, tqh_last = 0xf0353814}, shadow_list = { tqe_next = 0x0, tqe_prev = 0xf03539fc}, memq = {tqh_first = 0x0, tqh_last = 0xf0353824}, type = OBJT_DEFAULT, size = 13, ref_count = 0, shadow_count = -1, pg_color = 5, flags = 392, paging_in_progress = 0, behavior = 0, resident_page_count = 0, paging_offset = 0x0000000000000000, backing_object = 0x0, backing_object_offset = 0x0000000000000000, last_read = 0, page_hint = 0x0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, handle = 0x0, un_pager = {vnp = { vnp_size = 0x0000000000007000}, devp = {devp_pglist = { tqh_first = 0x7000, tqh_last = 0x0}}, swp = {swp_nblocks = 28672, swp_allocsize = 0, swp_blocks = 0x0, swp_poip = 0}}} (kgdb) p *curproc $2 = {p_procq = {tqe_next = 0xf034459c, tqe_prev = 0x0}, p_list = { le_next = 0xf06a2000, le_prev = 0xf06b5408}, p_cred = 0xf04df960, p_fd = 0xf06c0e00, p_stats = 0xf44c3220, p_limit = 0xf06a6400, p_upages_obj = 0xf0353884, p_sigacts = 0xf44c30f0, p_flag = 8196, p_stat = 2 '\002', p_pad1 = "\000\000", p_pid = 95, p_hash = { le_next = 0xf06a2000, le_prev = 0xf0689cfc}, p_pglist = {le_next = 0x0, le_prev = 0xf04df368}, p_pptr = 0xf06a2e00, p_sibling = { le_next = 0xf06a2000, le_prev = 0xf06b5448}, p_children = { lh_first = 0x0}, p_ithandle = {callout = 0xf2683e4c}, p_oppid = 0, p_dupfd = 0, p_vmspace = 0xf06a4500, p_estcpu = 14, p_cpticks = 14, p_pctcpu = 0, p_wchan = 0x0, p_wmesg = 0xf0127d99 "select", p_swtime = 241, p_slptime = 0, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 884704028, tv_usec = 512775}}, p_rtime = {tv_sec = 0, tv_usec = 109914}, p_uticks = 5, p_sticks = 22, p_iticks = 0, p_sleepend = 0x0, p_traceflag = 0, p_tracep = 0x0, p_siglist = 0, p_textvp = 0xf06a4a00, p_lock = 0 '\000', p_oncpu = 0 '\000', p_lastcpu = 0 '\000', p_pad2 = 0 '\000', p_locks = 0, p_simple_locks = 0, p_stops = 0, p_stype = 0, p_step = 0 '\000', p_pfsflags = 0 '\000', p_pad3 = "\000", p_retval = {1, -1}, p_sigmask = 0, p_sigignore = 4294967295, p_sigcatch = 548865, p_priority = 53 '5', p_usrpri = 53 '5', p_nice = 0 '\000', p_comm = "syslogd\000\000\000\000\000\000\000\000\000", p_pgrp = 0xf04df360, p_sysent = 0xf021fdd0, p_rtprio = {type = 1, prio = 0}, p_addr = 0xf44c3000, p_md = {md_regs = 0xf44c4fbc}, p_xstat = 0, p_acflag = 19, p_ru = 0xf0715f80, p_nthreads = 0, p_aioinfo = 0x0, p_wakeup = 0, p_peers = 0x0, p_leader = 0xf06b9400} (kgdb) q From owner-freebsd-current Thu Jan 15 05:36:12 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA19805 for current-outgoing; Thu, 15 Jan 1998 05:36:12 -0800 (PST) (envelope-from owner-freebsd-current) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA19771 for ; Thu, 15 Jan 1998 05:35:52 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from cyrus.watson.org (cyrus.pr.watson.org [192.0.2.4]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id IAA18040 for ; Thu, 15 Jan 1998 08:35:41 -0500 (EST) Date: Thu, 15 Jan 1998 08:36:50 -0500 (EST) From: Robert Watson Reply-To: Robert Watson To: freebsd-current@freebsd.org Subject: kth krb in 3.0-980107-SNAP (minor kadmin bug) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This may have been lost due to downtime somewhere or another. Apologies if you get this twice. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ ---------- Forwarded message ---------- Date: Tue, 13 Jan 1998 18:38:41 -0500 (EST) From: Robert Watson Reply-To: Robert Watson To: freebsd-current@freebsd.org Subject: kth krb in 3.0-980107-SNAP (minor kadmin bug) I'm a few days behind on current, but with kth kerberos got this error on a plain-vanilla install on a machine that had previously run kadmin happily under 2.2-STABLE. It looks like crypt was not linked in on compile? I can reproduce this on other machines with the same vintage snapshot. % uname -a FreeBSD trojanhorse.watson.org 3.0-980107-SNAP FreeBSD 3.0-980107-SNAP #0: Wed Jan 7 10:26:59 GMT 1998 root@make.ican.net:/usr/src/sys/compile/GENERIC i386 % kadmin Welcome to the Kerberos Administration Program, version 2 Type "help" if you need it. kadmin: get rcmd.trojan /usr/libexec/ld.so: Undefined symbol "_crypt" called from kadmin:/usr/lib/libkrb.so.3.0 at 0x200352f8 % Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ From owner-freebsd-current Thu Jan 15 06:18:14 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA23416 for current-outgoing; Thu, 15 Jan 1998 06:18:14 -0800 (PST) (envelope-from owner-freebsd-current) Received: from home.dragondata.com (toasty@home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA23402 for ; Thu, 15 Jan 1998 06:18:03 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.5/8.8.5) id IAA19842 for current@freebsd.org; Thu, 15 Jan 1998 08:18:05 -0600 (CST) From: Kevin Day Message-Id: <199801151418.IAA19842@home.dragondata.com> Subject: No buffer space available To: current@freebsd.org Date: Thu, 15 Jan 1998 08:18:05 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A while back someone (bruce?) had asked me to post sysctl and vmstat listings while I was getting 'no buffer space available' messages. Well, since the machine uses yp and nfs a lot, when it ran out of buffer space, I'm essentially dead... This is after the machine recovered on it's own, about 15 mins later.. (sometimes it comes back, sometimes it locks up, or nicely suggests more swap before locking up, I've got 150MB now, with 128MB ram) The first sign of something going wrong is users getting their botchk cron jobs mailing them with yp_client complaining about no buffer space, but still working. If anyone would like any more information, let me know. Kevin kern.ostype: FreeBSD kern.osrelease: 3.0-CURRENT kern.osrevision: 199506 kern.version: FreeBSD 3.0-CURRENT #0: Wed Jan 7 19:50:42 CST 1998 root@shell.dragondata.com:/usr/src/sys/compile/SHELL kern.maxvnodes: 13153 kern.maxproc: 8212 kern.maxfiles: 16424 kern.argmax: 65536 kern.securelevel: -1 kern.hostname: shell.dragondata.com kern.hostid: 0 kern.clockrate: { hz = 100, tick = 10000, tickadj = 5, profhz = 1024, stathz = 128 } kern.posix1version: 199009 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 884807567, usec = 142017 } Wed Jan 14 13:52:47 1998 kern.domainname: dragondata.com kern.update: 30 kern.osreldate: 300001 kern.bootfile: /kernel kern.maxfilesperproc: 16424 kern.maxprocperuid: 8211 kern.dumpdev: { major = 255, minor = -65281 } kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 40 kern.ipc.max_hdr: 56 kern.ipc.max_datalen: 44 kern.dummy: 0 kern.ps_strings: -272637968 kern.usrstack: -272637952 kern.shutdown_timeout: 120 kern.acct_suspend: 2 kern.acct_resume: 4 kern.acct_chkfreq: 15 kern.fast_vfork: 0 kern.quantum: 10 kern.zone: ITEM SIZE LIMIT USED FREE REQUESTS PIPE: 160, 0, 21, 183, 23536 AIOLIO: 704, 0, 0, 0, 0 AIOL: 64, 0, 0, 0, 0 AIOCB: 128, 0, 0, 0, 0 AIOP: 32, 0, 0, 0, 0 AIO: 96, 0, 0, 0, 0 NAMEI: 1024, 0, 0, 32, 63406196 PV ENTRY: 28, 1683354, 12162, 8461, 4619617 MAP ENTRY: 36, 0, 1334, 602, 703393 KMAP ENTRY: 36, 5069, 130, 224, 12829 MAP: 108, 0, 9, 1, 9 VM OBJECT: 120, 0, 2388, 1030, 323422 kern.consmute: 0 vm.loadavg: { 0.21 0.40 0.74 } vm.v_free_min: 228 vm.v_free_target: 815 vm.v_free_reserved: 131 vm.v_inactive_target: 4700 vm.v_cache_min: 2254 vm.v_cache_max: 9016 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.swap_idle_threshold1: 2 vm.swap_idle_threshold2: 10 vm.pageout_stats_max: 815 vm.pageout_full_stats_interval: 16 vm.pageout_stats_interval: 4 vm.pageout_stats_free_max: 25 vm.swap_idle_enabled: 0 vm.defer_swapspace_pageouts: 0 vm.disable_swapspace_pageouts: 0 vm.max_page_launder: 32 vfs.nfs.nfs_privport: 0 vfs.nfs.async: 0 vfs.nfs.gatherdelay: 10000 vfs.nfs.gatherdelay_v3: 0 vfs.nfs.defect: 0 vfs.nfs.diskless_valid: 0 vfs.nfs.diskless_rootpath: vfs.nfs.diskless_swappath: vfs.cache.numneg: 175 vfs.cache.numcache: 12463 vfs.cache.numcalls: 252839623 vfs.cache.dothits: 5278 vfs.cache.dotdothits: 19270 vfs.cache.numchecks: 297389113 vfs.cache.nummiss: 139536 vfs.cache.nummisszap: 1476 vfs.cache.numposzaps: 2139 vfs.cache.numposhits: 252651882 vfs.cache.numnegzaps: 74 vfs.cache.numneghits: 19968 vfs.cache.numcwdcalls: 5764 vfs.cache.numcwdfail1: 18 vfs.cache.numcwdfail2: 25 vfs.cache.numcwdfail3: 0 vfs.cache.numcwdfail4: 0 vfs.cache.numcwdfound: 5721 vfs.numdirtybuffers: 1 vfs.lodirtybuffers: 139 vfs.hidirtybuffers: 279 vfs.numfreebuffers: 2435 vfs.lofreebuffers: 120 vfs.hifreebuffers: 240 vfs.maxbufspace: 8544256 vfs.bufspace: 8544256 vfs.maxvmiobufspace: 5696170 vfs.vmiospace: 5967872 vfs.maxmallocbufspace: 427212 vfs.bufmallocspace: 327680 vfs.kvafreespace: 86016 vfs.ioopt: 0 vfs.usermount: 0 vfs.aio.max_aio_per_proc: 32 vfs.aio.max_aio_queue_per_proc: 256 vfs.aio.max_aio_procs: 32 vfs.aio.num_aio_procs: 0 vfs.aio.num_queue_count: 0 vfs.aio.max_aio_queue: 1024 vfs.aio.target_aio_procs: 0 vfs.aio.max_buf_aio: 16 vfs.aio.num_buf_aio: 0 vfs.aio.aiod_lifetime: 3000 vfs.aio.aiod_timeout: 1000 net.local.stream.sendspace: 8192 net.local.stream.recvspace: 8192 net.local.dgram.maxdgram: 2048 net.local.dgram.recvspace: 4096 net.local.inflight: 0 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 1024 net.inet.ip.portrange.last: 5000 net.inet.ip.portrange.hifirst: 40000 net.inet.ip.portrange.hilast: 44999 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.subnets_are_local: 0 net.inet.icmp.maskrepl: 0 net.inet.icmp.bmcastecho: 1 net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.rttdflt: 3 net.inet.tcp.keepidle: 14400 net.inet.tcp.keepintvl: 150 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 150 net.inet.tcp.log_in_vain: 0 net.inet.tcp.always_keepalive: 0 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 41600 net.inet.udp.log_in_vain: 0 net.inet.raw.maxdgram: 8192 net.inet.raw.recvspace: 8192 net.link.generic.system.ifcount: 5 net.link.ether.inet.prune_intvl: 300 net.link.ether.inet.max_age: 1200 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.maxtries: 5 net.link.ether.inet.useloopback: 1 net.link.ether.inet.proxyall: 0 debug.elf_trace: 0 debug.fdexpand: 116 debug.ttydebug: 0 debug.nchash: 16383 debug.ncnegfactor: 16 debug.numneg: 175 debug.numcache: 12463 debug.vfscache: 1 debug.vnsize: 144 debug.ncsize: 36 debug.numvnodes: 13250 debug.wantfreevnodes: 25 debug.freevnodes: 11382 debug.disablecwd: 0 debug.if_tun_debug: 0 hw.machine: i386 hw.model: Pentium hw.ncpu: 2 hw.byteorder: 1234 hw.physmem: 82288640 hw.usermem: 59846656 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: ibm-pc machdep.consdev: { major = 0, minor = 0 } machdep.adjkerntz: 21600 machdep.disable_rtc_set: 0 machdep.wall_cmos_clock: 0 machdep.do_dump: 1 machdep.smp_active: 1 machdep.smp_cpus: 2 machdep.invltlb_ok: 1 machdep.do_page_zero_idle: 0 machdep.i8254_freq: 1193182 machdep.conspeed: 9600 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 16 69 699 64485383 1280 0 32 1693 867 30307 640 10 64 12905 791 189919562 320 201 128 712 152 63117075 160 0 256 26824 216 126269449 80 364331 512 108 44 21249 40 434 1K 319 121 10107 20 144 2K 23 17 84 10 17 4K 8 1 91 5 0 8K 2 1 11 5 0 16K 8 0 8 5 0 32K 3 0 4 5 0 64K 1 0 1 5 0 Memory usage type by bucket size Size Type(s) 16 sysctl, NFSV3 srvdesc, soname, ether_multi, routetbl, pcb, vnodes, proc, devbuf, temp 32 Gzip trees, sysctl, NFS req, in_multi, ether_multi, pgrp, subproc, routetbl, pcb, vnodes, devbuf, temp, kld 64 Gzip trees, lockf, NFS req, file, session, routetbl, pcb, NFS daemon, namecache, ifaddr, devbuf 128 Gzip trees, zombie, file desc, routetbl, pcb, namecache, ZONE, cred, ifaddr, ttys, temp 256 Gzip trees, NFSV3 srvdesc, Export Host, socket, VM map, file desc, subproc, FFS node, routetbl, pcb, NFS daemon, NFS srvsock, NFS node, vnodes, namecache, devbuf, temp 512 Gzip trees, NFS mount, ioctlops, file desc, UFS mount, BIO buffer, mount, pcb, NFS daemon, proc, devbuf, temp 1K Gzip trees, BIO buffer, NQNFS Lease, devbuf, temp 2K Gzip trees, UFS mount, BIO buffer, proc, ttys, devbuf 4K devbuf, temp 8K Gzip trees, proc 16K MSDOSFS mount, devbuf, mbuf 32K Gzip trees, UFS quota, UFS ihash, NFS node 64K namecache Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) Gzip trees 0 0K 44K 19661K 412 0 0 32,64,128,256,512,1K,2K,8K,32K sysctl 0 0K 1K 19661K 8 0 0 16,32 NFSV3 srvdesc 0 0K 1K 19661K 46 0 0 16,256 Export Host 1 1K 1K 19661K 5 0 0 256 lockf 7 1K 2K 19661K 22317 0 0 64 NFS req 15 1K 3K 19661K 488441 0 0 32,64 NFS mount 3 2K 2K 19661K 4 0 0 512 soname 4 1K 1K 19661K 1444124 0 0 16 in_multi 2 1K 1K 19661K 2 0 0 32 ether_multi 7 1K 1K 19661K 7 0 0 16,32 socket 139 35K 46K 19661K126106686 0 0 256 ioctlops 0 0K 1K 19661K 1 0 0 512 zombie 1 1K 2K 19661K 20602 0 0 128 file 335 21K 32K 19661K 63210409 0 0 64 session 51 4K 5K 19661K 3446 0 0 64 pgrp 54 2K 3K 19661K 4134 0 0 32 VM map 71 18K 29K 19661K 20672 0 0 256 file desc 73 10K 18K 19661K 21249 0 0 128,256,512 subproc 110 12K 19K 19661K 41313 0 0 32,256 FFS node 11776 2944K 3157K 19661K 95725 0 0 256 UFS mount 3 5K 5K 19661K 3 0 0 512,2K BIO buffer 310 327K 419K 19661K 4393 0 0 512,1K,2K mount 5 3K 3K 19661K 6 0 0 512 routetbl 142 20K 24K 19661K 648 0 0 16,32,64,128,256 pcb 239 43K 49K 19661K126114411 0 0 16,32,64,128,256,512 UFS quota 1 32K 32K 19661K 1 0 0 32K UFS ihash 1 32K 32K 19661K 1 0 0 32K NQNFS Lease 1 1K 1K 19661K 1 0 0 1K NFS daemon 28 4K 4K 19661K 28 0 0 64,256,512 NFS srvsock 2 1K 1K 19661K 2 0 0 256 NFS node 1344 368K 577K 19661K 4292 0 0 256,32K MSDOSFS mount 1 16K 16K 19661K 1 0 0 16K vnodes 14632 3359K 3359K 19661K 63058667 0 0 16,32,256 namecache 12473 844K 888K 19661K 114719 0 0 64,128,256,64K ZONE 7 1K 1K 19661K 7 0 0 128 cred 75 10K 13K 19661K 63044977 0 0 128 proc 101 54K 76K 19661K 20785 0 0 16,512,2K,8K ifaddr 8 1K 1K 19661K 8 0 0 64,128 ttys 403 55K 74K 19661K 4264 0 0 128,2K devbuf 50 137K 137K 19661K 63 0 0 16,32,64,256,512,1K,2K,4K,16K mbuf 1 16K 16K 19661K 1 0 0 16K temp 198 42K 43K 19661K 6449 0 0 16,32,128,256,512,1K,4K kld 1 1K 1K 19661K 1 0 0 32 Memory Totals: In Use Free Requests 8411K 350K 443853331 From owner-freebsd-current Thu Jan 15 07:10:33 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29275 for current-outgoing; Thu, 15 Jan 1998 07:10:33 -0800 (PST) (envelope-from owner-freebsd-current) Received: from www.giovannelli.it (www.giovannelli.it [194.184.65.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29163 for ; Thu, 15 Jan 1998 07:10:04 -0800 (PST) (envelope-from gmarco@giovannelli.it) Received: from giovannelli.it (modem00.masternet.it [194.184.65.254]) by www.giovannelli.it (8.8.8/8.8.5) with ESMTP id QAA00713 for ; Thu, 15 Jan 1998 16:11:48 +0100 (MET) Message-ID: <34BE2701.AD6D59AE@giovannelli.it> Date: Thu, 15 Jan 1998 16:10:57 +0100 From: Gianmarco Giovannelli Reply-To: gmarco@giovannelli.it X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: current@freebsd.org Subject: imake --> BUS error ! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After cvsupped yesterday , made world and a new kernel. I am not able to use imake anymore. It exits with BUS Error . With the kernel.GENERIC of SNAPSHOT 6 October it works greatly... Also a friend of mine has the same problem... What is changed ? I have reinstalled the system too, but the problem is still here... -- Regards... Gianmarco "Unix expert since yesterday" http://www2.masternet.it From owner-freebsd-current Thu Jan 15 13:01:44 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10493 for current-outgoing; Thu, 15 Jan 1998 13:01:44 -0800 (PST) (envelope-from owner-freebsd-current) Received: from opus.cts.cwu.edu (skynyrd@opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10465 for ; Thu, 15 Jan 1998 13:01:31 -0800 (PST) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.8.8/8.8.7) with SMTP id NAA21105; Thu, 15 Jan 1998 13:01:16 -0800 (PST) (envelope-from skynyrd@opus.cts.cwu.edu) Date: Thu, 15 Jan 1998 13:01:16 -0800 (PST) From: Chris Timmons Reply-To: Chris Timmons To: Gianmarco Giovannelli cc: current@FreeBSD.ORG Subject: Re: imake --> BUS error ! In-Reply-To: <34BE2701.AD6D59AE@giovannelli.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Be sure to follow this list carefully :) It has been discussed that there are a number of problems in -current right now which are presently being diagnosed and repaired. If you need to stabilize your machine for the time being: see cvsup(1) for a description of how to specify an absolute date and back up your sources to *default date=97.12.23.00.00.00 I've been using that -current to burn-in test an SMP machine (which happily rebuilt the world and xemacs20 concurrently for days on end.) [Kudos to Steve Passe and all of the SMP contributors by the way - I was very impressed with SMP. The only glitch is the PCI bridge hack to use an AHA-3940.] -Chris On Thu, 15 Jan 1998, Gianmarco Giovannelli wrote: > After cvsupped yesterday , made world and a new kernel. > I am not able to use imake anymore. > > It exits with BUS Error . With the kernel.GENERIC of SNAPSHOT 6 October > it works greatly... > > Also a friend of mine has the same problem... > > What is changed ? I have reinstalled the system too, but the problem is > still here... > > > -- > > Regards... > > Gianmarco > "Unix expert since yesterday" > > http://www2.masternet.it > From owner-freebsd-current Mon Jan 19 10:21:12 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA00942 for current-outgoing; Mon, 19 Jan 1998 10:21:12 -0800 (PST) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA00902; Mon, 19 Jan 1998 10:20:41 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id FAA22505; Tue, 20 Jan 1998 05:10:37 +1100 Date: Tue, 20 Jan 1998 05:10:37 +1100 From: Bruce Evans Message-Id: <199801191810.FAA22505@godzilla.zeta.org.au> To: current@freebsd.org Subject: gdb breakpoints broken Cc: dyson@freebsd.org Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Recent vm changes seem to have broken breakpoints: --- Script started on Tue Jan 20 05:06:21 1998 ttyv0:bde@alphplex:/tmp> gdb /bin/cat GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... (gdb) b *0x1020 Breakpoint 1 at 0x1020 (gdb) r Starting program: /bin/cat Cannot insert breakpoint 1: Error accessing memory address 0x1020: Bad address. (gdb) q The program is running. Quit anyway (and kill it)? (y or n) y ttyv0:bde@alphplex:/tmp> exit Script done on Tue Jan 20 05:06:37 1998 --- PT_WRITE_{D,I} fails. PT_READ_I works. Bruce From owner-freebsd-current Mon Jan 19 11:31:37 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA08783 for current-outgoing; Mon, 19 Jan 1998 11:31:37 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA08768 for ; Mon, 19 Jan 1998 11:31:24 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52774(3)>; Mon, 19 Jan 1998 11:31:09 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Mon, 19 Jan 1998 11:31:00 -0800 To: spork cc: "David M. Holloway" , freebsd-current@freebsd.org Subject: Re: LAND attack In-reply-to: Your message of "Wed, 14 Jan 98 11:54:37 PST." Date: Mon, 19 Jan 1998 11:30:54 PST From: Bill Fenner Message-Id: <98Jan19.113100pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk spork wrote: >This is interesting. We have a machine that is "patched", but seems to >still be getting hit by land. It has lots of virtual interfaces. I haven't yet been able to get a multi-homed machine to "land" using multiple interfaces, but it's theoretically possible, and I'm the first to admit that crackers have much more time on their hands than I do. Can you try the patch at the end of PR #kern/5103 (see http://www.freebsd.org/cgi/query-pr.cgi?pr=5103) and see if it helps? I'm about to commit a slightly modified version of it. Thanks, Bill From owner-freebsd-current Mon Jan 19 12:03:33 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA11960 for current-outgoing; Mon, 19 Jan 1998 12:03:33 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA11901; Mon, 19 Jan 1998 12:03:09 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id OAA01696; Mon, 19 Jan 1998 14:58:14 -0500 (EST) (envelope-from toor) From: Bourne-again Superuser Message-Id: <199801191958.OAA01696@dyson.iquest.net> Subject: Re: gdb breakpoints broken In-Reply-To: <199801191810.FAA22505@godzilla.zeta.org.au> from Bruce Evans at "Jan 20, 98 05:10:37 am" To: bde@zeta.org.au (Bruce Evans) Date: Mon, 19 Jan 1998 14:58:14 -0500 (EST) Cc: current@FreeBSD.ORG, dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans said: > > Recent vm changes seem to have broken breakpoints: > I'll fix it. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Mon Jan 19 13:03:32 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17677 for current-outgoing; Mon, 19 Jan 1998 13:03:32 -0800 (PST) (envelope-from owner-freebsd-current) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17639 for ; Mon, 19 Jan 1998 13:03:00 -0800 (PST) (envelope-from archer@grape.carrier.kiev.ua) Received: from sivka.carrier.kiev.ua (root@sivka.carrier.kiev.ua [193.193.193.101]) by burka.carrier.kiev.ua (8.8.8/8.Who.Cares) with ESMTP id WAA25208 for ; Mon, 19 Jan 1998 22:28:19 +0200 (EET) Received: from kozlik.carrier.kiev.ua (kozlik.carrier.kiev.ua [193.193.193.111]) by sivka.carrier.kiev.ua (8.8.7/8.8.7) with ESMTP id WAA16773 for ; Mon, 19 Jan 1998 22:29:20 +0200 (EET) Received: (from uucp@localhost) by kozlik.carrier.kiev.ua (8.8.8/8.8.8/8.Who.Cares) with UUCP id WAA13504 for current@freebsd.org; Mon, 19 Jan 1998 22:20:25 +0200 (EET) Received: (from archer@localhost) by grape.carrier.kiev.ua (8.8.8/8.8.8) id VAA04568; Mon, 19 Jan 1998 21:59:17 +0200 (EET) (envelope-from archer) Date: Mon, 19 Jan 1998 21:59:17 +0200 (EET) From: Alexander Litvin Message-Id: <199801191959.VAA04568@grape.carrier.kiev.ua> To: current@FreeBSD.ORG Subject: Re: panic: vm_object_deallocate: deallocated too many times In-Reply-To: <199801151242.XAA25673@godzilla.zeta.org.au> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just the same kind of panic happened to me with the kernel of Saturday. Have a crashdump (though no debugging simbols in kernel). Almost the same backtrace. It was not related with 'umount', the only task the machine was doing was makeworld. -- Litvin Alexander In article <199801151242.XAA25673@godzilla.zeta.org.au> you wrote: > [This may have been lost when hub.freebsd.org was down.] > The following command usually causes a panic when /usr is nfs-mounted: > umount -Af -t nfs > The panic usually occurs when syslogd exits. > Bruce > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.16 (i386-unknown-freebsd), > Copyright 1996 Free Software Foundation, Inc... > IdlePTD 390000 > current pcb at 2302b8 > panicstr: vm_object_deallocate: object deallocated too many times > panic messages: > --- > panic: vm_object_deallocate: object deallocated too many times > syncing disks... done > dumping to dev 401, offset 65536 > dump 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 boot (howto=256) at ./@/kern/kern_shutdown.c:285 > 285 dumppcb.pcb_cr3 = rcr3(); > (kgdb) where > #0 boot (howto=256) at ./@/kern/kern_shutdown.c:285 > #1 0xf0120557 in panic ( > fmt=0xf01d7f3b "vm_object_deallocate: object deallocated too many times") > at ./@/kern/kern_shutdown.c:425 > #2 0xf01d7fbc in vm_object_deallocate (object=0xf035344c) > at ./@/vm/vm_object.c:295 > #3 0xf01d5a00 in vm_map_entry_delete (map=0xf06a4500, entry=0xf476c828) > at ./@/vm/vm_map.c:1784 > #4 0xf01d5b7c in vm_map_delete (map=0xf06a4500, start=0, end=4022329344) > at ./@/vm/vm_map.c:1877 > #5 0xf01d5c04 in vm_map_remove (map=0xf06a4500, start=0, end=4022329344) > at ./@/vm/vm_map.c:1911 > #6 0xf01195f8 in exit1 (p=0xf06b9400, rv=11) at ./@/kern/kern_exit.c:213 > #7 0xf01217e6 in sigexit (p=0xf06b9400, signum=11) at ./@/kern/kern_sig.c:1222 > #8 0xf01215e3 in postsig (signum=11) at ./@/kern/kern_sig.c:1130 > #9 0xf01ef7d8 in trap (frame={tf_es = 39, tf_ds = 39, tf_edi = -272646808, > tf_esi = 32, tf_ebp = -272638376, tf_isp = -196325404, > tf_ebx = 537455056, tf_edx = -1, tf_ecx = 3, tf_eax = 1, tf_trapno = 12, > tf_err = 1, tf_eip = 7798, tf_cs = 31, tf_eflags = 66118, > tf_esp = -272646880, tf_ss = 39}) at ./@/i386/i386/trap.c:166 > #10 0x1e76 in ?? () > Cannot access memory at address 0xefbfde5c. > (kgdb) up 2 > #2 0xf01d7fbc in vm_object_deallocate (object=0xf035344c) > at ./@/vm/vm_object.c:295 > 295 return; > (kgdb) p *object > $1 = {object_list = {tqe_next = 0xf0352aec, tqe_prev = 0xf47939d8}, > shadow_head = {tqh_first = 0x0, tqh_last = 0xf0353814}, shadow_list = { > tqe_next = 0x0, tqe_prev = 0xf03539fc}, memq = {tqh_first = 0x0, > tqh_last = 0xf0353824}, type = OBJT_DEFAULT, size = 13, ref_count = 0, > shadow_count = -1, pg_color = 5, flags = 392, paging_in_progress = 0, > behavior = 0, resident_page_count = 0, paging_offset = 0x0000000000000000, > backing_object = 0x0, backing_object_offset = 0x0000000000000000, > last_read = 0, page_hint = 0x0, pager_object_list = {tqe_next = 0x0, > tqe_prev = 0x0}, handle = 0x0, un_pager = {vnp = { > vnp_size = 0x0000000000007000}, devp = {devp_pglist = { > tqh_first = 0x7000, tqh_last = 0x0}}, swp = {swp_nblocks = 28672, > swp_allocsize = 0, swp_blocks = 0x0, swp_poip = 0}}} > (kgdb) p *curproc > $2 = {p_procq = {tqe_next = 0xf034459c, tqe_prev = 0x0}, p_list = { > le_next = 0xf06a2000, le_prev = 0xf06b5408}, p_cred = 0xf04df960, > p_fd = 0xf06c0e00, p_stats = 0xf44c3220, p_limit = 0xf06a6400, > p_upages_obj = 0xf0353884, p_sigacts = 0xf44c30f0, p_flag = 8196, > p_stat = 2 '\002', p_pad1 = "\000\000", p_pid = 95, p_hash = { > le_next = 0xf06a2000, le_prev = 0xf0689cfc}, p_pglist = {le_next = 0x0, > le_prev = 0xf04df368}, p_pptr = 0xf06a2e00, p_sibling = { > le_next = 0xf06a2000, le_prev = 0xf06b5448}, p_children = { > lh_first = 0x0}, p_ithandle = {callout = 0xf2683e4c}, p_oppid = 0, > p_dupfd = 0, p_vmspace = 0xf06a4500, p_estcpu = 14, p_cpticks = 14, > p_pctcpu = 0, p_wchan = 0x0, p_wmesg = 0xf0127d99 "select", p_swtime = 241, > p_slptime = 0, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0}, > it_value = {tv_sec = 884704028, tv_usec = 512775}}, p_rtime = {tv_sec = 0, > tv_usec = 109914}, p_uticks = 5, p_sticks = 22, p_iticks = 0, > p_sleepend = 0x0, p_traceflag = 0, p_tracep = 0x0, p_siglist = 0, > p_textvp = 0xf06a4a00, p_lock = 0 '\000', p_oncpu = 0 '\000', > p_lastcpu = 0 '\000', p_pad2 = 0 '\000', p_locks = 0, p_simple_locks = 0, > p_stops = 0, p_stype = 0, p_step = 0 '\000', p_pfsflags = 0 '\000', > p_pad3 = "\000", p_retval = {1, -1}, p_sigmask = 0, > p_sigignore = 4294967295, p_sigcatch = 548865, p_priority = 53 '5', > p_usrpri = 53 '5', p_nice = 0 '\000', > p_comm = "syslogd\000\000\000\000\000\000\000\000\000", p_pgrp = 0xf04df360, > p_sysent = 0xf021fdd0, p_rtprio = {type = 1, prio = 0}, p_addr = 0xf44c3000, > p_md = {md_regs = 0xf44c4fbc}, p_xstat = 0, p_acflag = 19, > p_ru = 0xf0715f80, p_nthreads = 0, p_aioinfo = 0x0, p_wakeup = 0, > p_peers = 0x0, p_leader = 0xf06b9400} > (kgdb) q From owner-freebsd-current Mon Jan 19 14:30:34 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA27950 for current-outgoing; Mon, 19 Jan 1998 14:30:34 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA27782 for ; Mon, 19 Jan 1998 14:29:01 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id RAA00564; Mon, 19 Jan 1998 17:28:52 -0500 (EST) (envelope-from toor) Message-Id: <199801192228.RAA00564@dyson.iquest.net> Subject: Re: 980112 current and imake SIGBUS In-Reply-To: from Ade Lovett at "Jan 12, 98 02:25:42 pm" To: ade@demon.net (Ade Lovett) Date: Mon, 19 Jan 1998 17:28:52 -0500 (EST) Cc: current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ade Lovett said: > > With today's -current kernel: > > FreeBSD gorgon.lovett.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: > Mon Jan 12 10:59:20 CST 1998 > root@gorgon.lovett.com:/usr/src/sys/compile/GORGON i386 > > I noticed that /usr/X11R6/bin/imake started dumping core (I initially > built X11R6 from /usr/ports after installing the machine when it was > running current-980106. > > Next stage was to do a complete make world, rather than just the kernel, > which I've now done. Same results. > Luckily, I can reproduce the problem... Thanks!!! At bootup, try 'sysctl -w vfs.ioopt=0'. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Mon Jan 19 16:01:09 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA05996 for current-outgoing; Mon, 19 Jan 1998 16:01:09 -0800 (PST) (envelope-from owner-freebsd-current) Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA05882; Mon, 19 Jan 1998 16:00:32 -0800 (PST) (envelope-from quik@terkel.mit.edu) Received: from TERKEL.MIT.EDU by MIT.EDU with SMTP id AA12152; Mon, 19 Jan 98 19:00:31 EST Received: from localhost by terkel.mit.edu (8.8.7/4.7) id AAA05021; Tue, 20 Jan 1998 00:00:27 GMT Date: Mon, 19 Jan 1998 19:00:25 -0500 (EST) From: quiksilver To: freebsd-questions@freebsd.org, current@freebsd.org Subject: zip drive Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk atapi zip drive isn't mounting correctly probably a problem on my part uart# mount /dev/wfd0 /zip /dev/wfd0 on /zip: Incorrect super block. uart# mount /dev/wfd0 /zip msdos: /dev/wfd0: Invalid argument I'm using 3.0-CURRENT From owner-freebsd-current Mon Jan 19 18:39:58 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA18224 for current-outgoing; Mon, 19 Jan 1998 18:39:58 -0800 (PST) (envelope-from owner-freebsd-current) Received: from sphinx.lovett.com (root@sphinx.lovett.com [38.155.241.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA18188; Mon, 19 Jan 1998 18:39:33 -0800 (PST) (envelope-from ade@demon.net) Received: from gorgon.lovett.com [38.155.241.3] (ade) by sphinx.lovett.com with esmtp (Exim 1.82 #1) id 0xuTb0-00007o-00; Mon, 19 Jan 1998 20:39:22 -0600 To: dyson@freebsd.org cc: current@freebsd.org Subject: Re: 980112 current and imake SIGBUS Organization: Demon Internet Reply-To: ade@demon.net In-reply-to: Your message of "Mon, 19 Jan 1998 17:28:52 EST." <199801192228.RAA00564@dyson.iquest.net> Date: Mon, 19 Jan 1998 20:39:21 -0600 From: Ade Lovett Message-Id: Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "John S. Dyson" writes: > >Luckily, I can reproduce the problem... Thanks!!! At bootup, >try 'sysctl -w vfs.ioopt=0'. Just tried this.. seems to be working -- I'll let this machine rebuild X and a few other things overnight to see if I get any more spurious SIGBUS's. -aDe -- Ade Lovett, Demon Internet, Austin, Texas. From owner-freebsd-current Mon Jan 19 20:03:36 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA27723 for current-outgoing; Mon, 19 Jan 1998 20:03:36 -0800 (PST) (envelope-from owner-freebsd-current) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA27705; Mon, 19 Jan 1998 20:03:12 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id OAA01167; Tue, 20 Jan 1998 14:25:58 +1030 (CST) Message-Id: <199801200355.OAA01167@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: quiksilver cc: freebsd-questions@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: zip drive In-reply-to: Your message of "Mon, 19 Jan 1998 19:00:25 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jan 1998 14:25:57 +1030 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > atapi zip drive isn't mounting correctly > probably a problem on my part > > uart# mount /dev/wfd0 /zip > /dev/wfd0 on /zip: Incorrect super block. > > uart# mount /dev/wfd0 /zip > msdos: /dev/wfd0: Invalid argument > > I'm using 3.0-CURRENT Hmm, no guarantees that the ATAPI Zip will work as-is, as the probe is all wrong. However, you should bear in mind that Zip drives are partitioned like hard disks, and normally with the MSDOS partition in the third slice. Try: mount -t msdos /dev/wdf0s4 /zip or nuke the disk and put a BSD filesystem on it: disklabel -rwD wfd0 auto newfs /dev/wfd0c mount /dev/wfd0c /zip There are also outstanding reports that large transfers to/from the drive cause system lockups; I haven't been in a position to test that yet. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ From owner-freebsd-current Mon Jan 19 20:17:51 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28998 for current-outgoing; Mon, 19 Jan 1998 20:17:51 -0800 (PST) (envelope-from owner-freebsd-current) Received: from iconmail.bellatlantic.net (iconmail.bellatlantic.net [199.173.162.30]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA28927; Mon, 19 Jan 1998 20:17:03 -0800 (PST) (envelope-from dmm125@bellatlantic.net) Received: from myname.my.domain (client201-122-45.bellatlantic.net [151.201.122.45]) by iconmail.bellatlantic.net (IConNet Sendmail) with SMTP id XAA22445; Mon, 19 Jan 1998 23:17:02 -0500 (EST) Date: Mon, 19 Jan 1998 23:16:37 +0000 (GMT) From: Donn Miller X-Sender: dmm125@myname.my.domain To: freebsd-current@freebsd.org, bugs@freebsd.org Subject: stuff missing from includes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In FreeBSD 3.0-980101-SNAP: /usr/include/sys/ipc.h & /usr/include/sys/sem.h use the types ushort and u_short, and they are not found in these headers. I think maybe these two files should each #include . Donn From owner-freebsd-current Mon Jan 19 23:55:15 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13220 for current-outgoing; Mon, 19 Jan 1998 23:55:15 -0800 (PST) (envelope-from owner-freebsd-current) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA13212; Mon, 19 Jan 1998 23:55:09 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.2/nospam) with UUCP id IAA11698; Tue, 20 Jan 1998 08:55:07 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.8/keltia-2.13/nospam) id IAA15762; Tue, 20 Jan 1998 08:40:27 +0100 (CET) (envelope-from roberto) Message-ID: <19980120084026.52563@keltia.freenix.fr> Date: Tue, 20 Jan 1998 08:40:26 +0100 From: Ollivier Robert To: freebsd-current@FreeBSD.ORG, bugs@FreeBSD.ORG Subject: Re: stuff missing from includes Mail-Followup-To: bugs@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.14i In-Reply-To: ; from Donn Miller on Mon, Jan 19, 1998 at 11:16:37PM +0000 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3994 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Donn Miller: > /usr/include/sys/sem.h use the types ushort and u_short, and they are not > found in these headers. I think maybe these two files should each > #include . Nope, you must instead #include before them yourself. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #4: Sun Jan 18 15:50:16 CET 1998 From owner-freebsd-current Tue Jan 20 10:23:24 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22373 for current-outgoing; Tue, 20 Jan 1998 10:23:24 -0800 (PST) (envelope-from owner-freebsd-current) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA22312; Tue, 20 Jan 1998 10:22:07 -0800 (PST) (envelope-from Anthony.Kimball@East.Sun.COM) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA06746; Tue, 20 Jan 1998 10:21:35 -0800 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id NAA10910; Tue, 20 Jan 1998 13:21:31 -0500 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id NAA13387; Tue, 20 Jan 1998 13:19:33 -0500 Received: (from alk@localhost) by compound.east.sun.com (8.8.8/8.7.3) id MAA24372; Tue, 20 Jan 1998 12:16:26 -0600 (CST) Date: Tue, 20 Jan 1998 12:16:26 -0600 (CST) Message-Id: <199801201816.MAA24372@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Reply-To: alk@pobox.com To: hardware@freebsd.org Subject: ie0 and EE16 X-Mailer: VM 6.33 under 19.14 XEmacs Lucid Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just FYI, the ie driver consistently fails for me after several days of use, with an EE16 card. The mode: network activity stops (by the hub light); no messages are logged; ping returns "sendto: no buffer space available"; 'ifconfig ie0 down; ifconfig ie0 up' causes ping to stop reporting errors, but no network activity occurs until reboot. Strangely, I've never seen this effect with NFS traffic, only with X, and specific applications seem to trigger it: Acroread, or netscape, for example, but not ghostview. From owner-freebsd-current Tue Jan 20 11:33:29 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27756 for current-outgoing; Tue, 20 Jan 1998 11:33:29 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA27749 for ; Tue, 20 Jan 1998 11:33:25 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id MAA29181 for ; Tue, 20 Jan 1998 12:33:24 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd029161; Tue Jan 20 12:33:18 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id MAA27126 for current@freebsd.org; Tue, 20 Jan 1998 12:33:18 -0700 (MST) From: Terry Lambert Message-Id: <199801201933.MAA27126@usr04.primenet.com> Subject: Nasty GCC bug? To: current@freebsd.org Date: Tue, 20 Jan 1998 19:33:18 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have discovered what I think is a nasty bug, having to do with passing signed smaller-than-int values to varradic functions. #include /* * demonstrate bug with signed smaller-than-int arguments to * varradic functions... */ main() { short ss = 0xebeb; unsigned short us = 0xebeb; char sc = 0xeb; unsigned char uc = 0xeb; printf( "Expecting 0x%04x, but getting 0x%04x\n", us, ss); printf( "Expecting 0x%02x, but getting 0x%02x\n", uc, sc); } What is happening is that the value is being sign-extended to int when it is pushed on the stack. I don't know how you would make "%d" and "%x" work at the same time, without a type descriptor on the stack before the argument. Maybe there needs to be a character type specifier for "%x"? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Jan 20 11:47:33 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29116 for current-outgoing; Tue, 20 Jan 1998 11:47:33 -0800 (PST) (envelope-from owner-freebsd-current) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29105 for ; Tue, 20 Jan 1998 11:47:24 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id WAA28013; Tue, 20 Jan 1998 22:47:06 +0300 (MSK) (envelope-from ache) Date: Tue, 20 Jan 1998 22:47:03 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: Terry Lambert cc: current@FreeBSD.ORG Subject: Re: Nasty GCC bug? In-Reply-To: <199801201933.MAA27126@usr04.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 20 Jan 1998, Terry Lambert wrote: > What is happening is that the value is being sign-extended to int > when it is pushed on the stack. It is absolutely no bug here, it is THE RULE. All types smaller than int promotes to int in any expression, and signed types promotes _with_ sign extension. Function argument is an expression. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Tue Jan 20 11:58:34 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29972 for current-outgoing; Tue, 20 Jan 1998 11:58:34 -0800 (PST) (envelope-from owner-freebsd-current) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29959 for ; Tue, 20 Jan 1998 11:58:25 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.5) id OAA14543; Tue, 20 Jan 1998 14:57:51 -0500 (EST) Date: Tue, 20 Jan 1998 14:57:51 -0500 (EST) From: Garrett Wollman Message-Id: <199801201957.OAA14543@khavrinen.lcs.mit.edu> To: Terry Lambert Cc: current@FreeBSD.ORG Subject: Nasty GCC bug? In-Reply-To: <199801201933.MAA27126@usr04.primenet.com> References: <199801201933.MAA27126@usr04.primenet.com> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > /* > * demonstrate bug with signed smaller-than-int arguments to > * varradic functions... > */ It's no bug, Terry... just ISO 9899:1990 in action. > What is happening is that the value is being sign-extended to int > when it is pushed on the stack. Which is precisely what is supposed to happen, since in the absence of an explicit type for that argument, the default promotions prevail, and the default promotion of `signed short' is to `signed int'. Of course, the correct type to pass for the `%x' format descriptor is `unsigned int', so you should have cast the argument explicitly. You might call it a bug in gcc that `-Wformat' does not diagnose this condition. -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 From owner-freebsd-current Tue Jan 20 12:54:09 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04384 for current-outgoing; Tue, 20 Jan 1998 12:54:09 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04318 for ; Tue, 20 Jan 1998 12:53:58 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id NAA19479; Tue, 20 Jan 1998 13:53:51 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd019460; Tue Jan 20 13:53:48 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id NAA25835; Tue, 20 Jan 1998 13:53:41 -0700 (MST) From: Terry Lambert Message-Id: <199801202053.NAA25835@usr06.primenet.com> Subject: Re: Nasty GCC bug? To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Date: Tue, 20 Jan 1998 20:53:41 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Jan 20, 98 10:47:03 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Tue, 20 Jan 1998, Terry Lambert wrote: > > > What is happening is that the value is being sign-extended to int > > when it is pushed on the stack. > > It is absolutely no bug here, it is THE RULE. > > All types smaller than int promotes to int in any expression, and signed > types promotes _with_ sign extension. Function argument is an expression. I typed the wrong subject. My complaint was about how %02x worked with sign extended character values. As I pointed out, not doing the extension would break %d, and it's the fact that printf didn't know it was a character value that had been sign extended instead of an int value that was the bug. %x expects and int, %lx expects a long. There is not one that expects a short or a char. Also, my field width limits are being ignored. I kind of expected it to print out a field limit's worth of hex characters, starting at the lsb. The problem initially showed in a program that sscanf'ed into an int of %2x, assigned a character array valued to the int, and then tried to printf the char value to get back out what it scanned in. The resulting output not matching the input was unexpected, since it's sort of normal to expect that printf/scanf are inverse functions. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Jan 20 13:18:16 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06291 for current-outgoing; Tue, 20 Jan 1998 13:18:16 -0800 (PST) (envelope-from owner-freebsd-current) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06282 for ; Tue, 20 Jan 1998 13:18:10 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.5) id QAA14891; Tue, 20 Jan 1998 16:18:03 -0500 (EST) Date: Tue, 20 Jan 1998 16:18:03 -0500 (EST) From: Garrett Wollman Message-Id: <199801202118.QAA14891@khavrinen.lcs.mit.edu> To: Terry Lambert Cc: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=), current@FreeBSD.ORG Subject: Re: Nasty GCC bug? In-Reply-To: <199801202053.NAA25835@usr06.primenet.com> References: <199801202053.NAA25835@usr06.primenet.com> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk < said: > Also, my field width limits are being ignored. I kind of expected > it to print out a field limit's worth of hex characters, starting at > the lsb. No. >From printf(3): o An optional decimal digit string specifying a minimum field width. If the converted value has fewer characters than the field width, it will be padded with spaces on the left (or right, if the left-adjust- ment flag has been given) to fill out the field width. What you wanted is not available in the standard printf(3) model, since the precision means something else: o An optional precision, in the form of a period `.' followed by an op- tional digit string. If the digit string is omitted, the precision is taken as zero. This gives the minimum number of digits to appear for d, i, o, u, x, and X conversions, the number of digits to appear after the decimal-point for e, E, and f conversions, the maximum num- ber of significant digits for g and G conversions, or the maximum number of characters to be printed from a string for s conversions. One might wish that the precision for %d meant the same thing as for %s, which is what you want, but it doesn't. -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 From owner-freebsd-current Tue Jan 20 13:23:53 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06795 for current-outgoing; Tue, 20 Jan 1998 13:23:53 -0800 (PST) (envelope-from owner-freebsd-current) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06766 for ; Tue, 20 Jan 1998 13:23:37 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.7) id NAA15093; Tue, 20 Jan 1998 13:23:31 -0800 (PST) (envelope-from sef) Date: Tue, 20 Jan 1998 13:23:31 -0800 (PST) From: Sean Eric Fagan Message-Id: <199801202123.NAA15093@kithrup.com> To: current@freebsd.org Subject: Re: Nasty GCC bug? In-Reply-To: <199801202053.NAA25835.kithrup.freebsd.current@usr06.primenet.com> References: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Jan 20, 98 10:47:03 pm Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199801202053.NAA25835.kithrup.freebsd.current@usr06.primenet.com> you write: I don't normally do this, but: Terry you don't know what you're talking about. As I've explained in my two messages today. >%x expects and int, %lx expects a long. There is not one that expects >a short or a char. %x expects an unsigned int, and takes the normal modifiers. 'l', 'q', and 'h' specify sizes -- long, quad, and short, respectively. The 'h' size modifier has only been around for about 20 years now, so maybe I shouldn't expect you to know about it. >Also, my field width limits are being ignored. I kind of expected >it to print out a field limit's worth of hex characters, starting at >the lsb. What his this "lsb" you keep talking about? printf doesn't know anything about bytes; all it knows abotu are values, and characters. Your field width limits were not being ignored, as, if you read the man page (which I quoted you in my previous message), you'd see that it's the *minimum field width*, not the maximum. >The problem initially showed in a program that sscanf'ed into an >int of %2x, assigned a character array valued to the int, and then >tried to printf the char value to get back out what it scanned in. It's not my fault the program in question was buggy -- it has always been the case that you had to mask out signed char values for printf statements, since printf has never had a size modifier to treat a char-sized value as an integer. From owner-freebsd-current Tue Jan 20 13:28:10 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA07246 for current-outgoing; Tue, 20 Jan 1998 13:28:10 -0800 (PST) (envelope-from owner-freebsd-current) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA07178 for ; Tue, 20 Jan 1998 13:27:57 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.8/8.8.8) id WAA22867; Tue, 20 Jan 1998 22:25:17 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199801202125.WAA22867@ocean.campus.luth.se> Subject: Re: Nasty GCC bug? In-Reply-To: <199801202053.NAA25835@usr06.primenet.com> from Terry Lambert at "Jan 20, 98 08:53:41 pm" To: tlambert@primenet.com (Terry Lambert) Date: Tue, 20 Jan 1998 22:25:16 +0100 (CET) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Terry Lambert: > %x expects and int, %lx expects a long. There is not one that expects > a short or a char. Er... Terry? Tried "man sprintf"? :-) none for int, l for long, h for short. Thus %hx. /Mikael From owner-freebsd-current Tue Jan 20 13:43:30 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08670 for current-outgoing; Tue, 20 Jan 1998 13:43:30 -0800 (PST) (envelope-from owner-freebsd-current) Received: from hydrogen.nike.efn.org (d182-89.uoregon.edu [128.223.182.89]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA08662 for ; Tue, 20 Jan 1998 13:43:23 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id NAA14213; Tue, 20 Jan 1998 13:31:54 -0800 (PST) Message-ID: <19980120133154.34281@hydrogen.nike.efn.org> Date: Tue, 20 Jan 1998 13:31:54 -0800 From: John-Mark Gurney To: Terry Lambert Cc: ????????????? , current@FreeBSD.ORG Subject: Re: Nasty GCC bug? References: <199801202053.NAA25835@usr06.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199801202053.NAA25835@usr06.primenet.com>; from Terry Lambert on Tue, Jan 20, 1998 at 08:53:41PM +0000 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert scribbled this message on Jan 20: > > On Tue, 20 Jan 1998, Terry Lambert wrote: > > > > > What is happening is that the value is being sign-extended to int > > > when it is pushed on the stack. > > > > It is absolutely no bug here, it is THE RULE. > > > > All types smaller than int promotes to int in any expression, and signed > > types promotes _with_ sign extension. Function argument is an expression. > > I typed the wrong subject. My complaint was about how %02x worked > with sign extended character values. As I pointed out, not doing the > extension would break %d, and it's the fact that printf didn't know > it was a character value that had been sign extended instead of an > int value that was the bug. > > %x expects and int, %lx expects a long. There is not one that expects > a short or a char. actually... there is one for the short... didn't you read the man page? :) o The optional character h, specifying that a following d, i, o, u, x, or X conversion corresponds to a short int or unsigned short int ar- gument, or that a following n conversion corresponds to a pointer to a short int argument. but the char one is missing... > Also, my field width limits are being ignored. I kind of expected > it to print out a field limit's worth of hex characters, starting at > the lsb. yes... you specified minium field width.. therer is no way to limit the number of characters outputed from x... > The problem initially showed in a program that sscanf'ed into an > int of %2x, assigned a character array valued to the int, and then > tried to printf the char value to get back out what it scanned in. > > The resulting output not matching the input was unexpected, since > it's sort of normal to expect that printf/scanf are inverse functions. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-current Tue Jan 20 13:46:25 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08878 for current-outgoing; Tue, 20 Jan 1998 13:46:25 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA08869 for ; Tue, 20 Jan 1998 13:46:18 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA29024; Tue, 20 Jan 1998 14:46:13 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd028974; Tue Jan 20 14:46:05 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA29266; Tue, 20 Jan 1998 14:46:03 -0700 (MST) From: Terry Lambert Message-Id: <199801202146.OAA29266@usr06.primenet.com> Subject: Re: Nasty GCC bug? To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Tue, 20 Jan 1998 21:46:02 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: <199801202125.WAA22867@ocean.campus.luth.se> from "Mikael Karpberg" at Jan 20, 98 10:25:16 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > %x expects and int, %lx expects a long. There is not one that expects > > a short or a char. > > Er... Terry? Tried "man sprintf"? :-) Naw, I was doing "man printf", which was getting me the shell printf. 8-). > none for int, l for long, h for short. Thus %hx. That works for a 'short'; what about my 'char'? VMS used to have a ":", I think, for something like "%02:2x" to truncate values larger than the field. Unfortunately, if the value was larger, it would put out asterisks instead of digits, to indicate that you had overflowed the thing. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Jan 20 13:50:38 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09309 for current-outgoing; Tue, 20 Jan 1998 13:50:38 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA09291 for ; Tue, 20 Jan 1998 13:50:16 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id OAA00269; Tue, 20 Jan 1998 14:50:13 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd000220; Tue Jan 20 14:50:04 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id OAA29572; Tue, 20 Jan 1998 14:50:01 -0700 (MST) From: Terry Lambert Message-Id: <199801202150.OAA29572@usr06.primenet.com> Subject: Re: Nasty GCC bug? To: gurney_j@resnet.uoregon.edu Date: Tue, 20 Jan 1998 21:50:01 +0000 (GMT) Cc: tlambert@primenet.com, ache@nagual.pp.ru, current@FreeBSD.ORG In-Reply-To: <19980120133154.34281@hydrogen.nike.efn.org> from "John-Mark Gurney" at Jan 20, 98 01:31:54 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > actually... there is one for the short... didn't you read the man page? :) > o The optional character h, specifying that a following d, i, o, u, x, > or X conversion corresponds to a short int or unsigned short int ar- > gument, or that a following n conversion corresponds to a pointer to > a short int argument. > > but the char one is missing... I nominate "%bx"; it's be helpful for scanf(), as well, to indicate the pointer value points to a "byte" so you can give the address of a character variable. > > Also, my field width limits are being ignored. I kind of expected > > it to print out a field limit's worth of hex characters, starting at > > the lsb. > > yes... you specified minium field width.. therer is no way to limit > the number of characters outputed from x... You forgot the part about it sucking. ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Jan 20 14:02:24 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10244 for current-outgoing; Tue, 20 Jan 1998 14:02:24 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA10239 for ; Tue, 20 Jan 1998 14:02:16 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA10136; Tue, 20 Jan 1998 15:02:10 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd010121; Tue Jan 20 15:02:08 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA00510; Tue, 20 Jan 1998 15:02:07 -0700 (MST) From: Terry Lambert Message-Id: <199801202202.PAA00510@usr06.primenet.com> Subject: Re: Nasty GCC bug? To: sef@kithrup.com (Sean Eric Fagan) Date: Tue, 20 Jan 1998 22:02:07 +0000 (GMT) Cc: current@FreeBSD.ORG In-Reply-To: <199801202123.NAA15093@kithrup.com> from "Sean Eric Fagan" at Jan 20, 98 01:23:31 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I don't normally do this, but: Terry you don't know what you're talking > about. As I've explained in my two messages today. [ ... ] > It's not my fault the program in question was buggy -- it has always been the > case that you had to mask out signed char values for printf statements, since > printf has never had a size modifier to treat a char-sized value as an > integer. Is is an artifact of the calling convention, which is implementation defined. It has *NOT* "always been the case"; on systems which do not use an integer stack based calling convention, the value can be treated as its type by the varradic function, instead of being treated as an int. It is the promotion caused by the calling convention that is the source of the breakage. VMS is one such system; it makes calls by descriptor rather than by integers on a stack. The descriptor contains the type information, and it does the unsurprising, and outputs via printf that which was input via scanf in such a way as to allow the program to run against the data that was output. It is probably more corrrect to say "the program depended on implementation defined behavior". Nevertheless, I was surprised when my data got garbled. 8-|. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Jan 20 14:06:39 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA10586 for current-outgoing; Tue, 20 Jan 1998 14:06:39 -0800 (PST) (envelope-from owner-freebsd-current) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA10549 for ; Tue, 20 Jan 1998 14:06:21 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.7) id OAA18817 for current@freebsd.org; Tue, 20 Jan 1998 14:06:21 -0800 (PST) (envelope-from sef) Date: Tue, 20 Jan 1998 14:06:21 -0800 (PST) From: Sean Eric Fagan Message-Id: <199801202206.OAA18817@kithrup.com> To: current@freebsd.org Subject: Re: Nasty GCC bug? Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Is is an artifact of the calling convention, which is implementation >defined. No, it is not. Variardic functions ARE REQUIRED TO USE OLD-STYLE PROMOTION RULES. REQUIRED. As in MANDAATORY. Further, printf then treats the argument as int; this is also required by the standard. >It has *NOT* "always been the case"; on systems which do not use an >integer stack based calling convention, the value can be treated as >its type by the varradic function, instead of being treated as an int. >It is the promotion caused by the calling convention that is the >source of the breakage. It *has* always been the case; not doing it this way is a bug. yes, there have been buggy implementations, and some of those are even superior ot the correct, required implementation. If I still had my copy of ANSI C, I could tell you the exact paragraph numbers that require this behaviour. As it is, I quoted man pages at you, and other peopl ehave quoted man pages at you. Terry, you are *WRONG*. Admit it. From owner-freebsd-current Tue Jan 20 14:51:59 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14526 for current-outgoing; Tue, 20 Jan 1998 14:51:59 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14458 for ; Tue, 20 Jan 1998 14:51:07 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA23700; Tue, 20 Jan 1998 15:50:59 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd023671; Tue Jan 20 15:50:56 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA04005; Tue, 20 Jan 1998 15:50:55 -0700 (MST) From: Terry Lambert Message-Id: <199801202250.PAA04005@usr06.primenet.com> Subject: Re: Nasty GCC bug? To: sef@kithrup.com (Sean Eric Fagan) Date: Tue, 20 Jan 1998 22:50:54 +0000 (GMT) Cc: current@FreeBSD.ORG In-Reply-To: <199801202206.OAA18817@kithrup.com> from "Sean Eric Fagan" at Jan 20, 98 02:06:21 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Is is an artifact of the calling convention, which is implementation > >defined. > > No, it is not. > > Variardic functions ARE REQUIRED TO USE OLD-STYLE PROMOTION RULES. > > REQUIRED. > > As in MANDAATORY. > > Further, printf then treats the argument as int; this is also required by the > standard. > > >It has *NOT* "always been the case"; on systems which do not use an > >integer stack based calling convention, the value can be treated as > >its type by the varradic function, instead of being treated as an int. > >It is the promotion caused by the calling convention that is the > >source of the breakage. > > It *has* always been the case; not doing it this way is a bug. yes, there > have been buggy implementations, and some of those are even superior ot the > correct, required implementation. > > If I still had my copy of ANSI C, I could tell you the exact paragraph numbers > that require this behaviour. As it is, I quoted man pages at you, and other > peopl ehave quoted man pages at you. > > Terry, you are *WRONG*. Admit it. Wrong about what? The subject line? The body of my message made it clear that I used the wrong subject line. Being surprised when a program that worked on one system failed on another? How can I be wrong about being surprised? Wrong about the type promotion resulting in what I was seeing? Wrong about VMS not promoting the type in the VAX Calling Standard? Wrong about "there should be a "%bx""? Wrong for setting my mail up to filter lists into seperate mailboxes so I couldn't read your previous responses before you lost patience and posted to the thread? Wrong about mandatory promotion in the face of a different calling convention? Wrong about the existance of the "h" conversion specifier's existance? Well, you got me on the subject, which I typed before I wrote my little test program and wrote the body of the message; and if I were trying to play "ANSI C lawyer" (which I wouldn't; I'd lose -- you definitely know the standard better than me), you got me on the mandatory promption rules -- though I don't know if it'd cause the same results, if the VCS "demoted" the thing back to a signed char after it was "promoted" once it was in the function. You also got me on the "h" conversion specifier, though I blame the printf(1) man page for that one... Other than that, I've stated facts that aren't relevent to your argument one way or the other (the ones which led me to my conclusion that the type promotion was what was biting me), and I've stated an opinion about "doing something to the formatting code to let me do what I want". I don't really see anything to fly into a fury over... PS: if anyone is still interested, I can send you the fixed program, which is supposed to: * Scan a file for an arbitrary number of bytes matching entered * as hex values. Print out the offsets where the pattern occurs * as hex values. ...useful for finding filesystems when you destroy your disklabel by running against the device and specifying FS_MAGIC (011954) as the pattern. It doesn't use scanf() any more. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Tue Jan 20 17:14:29 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA25441 for current-outgoing; Tue, 20 Jan 1998 17:14:29 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA25419 for ; Tue, 20 Jan 1998 17:14:15 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52179(1)>; Tue, 20 Jan 1998 17:14:13 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Tue, 20 Jan 1998 17:14:09 -0800 To: Sean Eric Fagan cc: current@freebsd.org Subject: Re: Nasty GCC bug? In-reply-to: Your message of "Tue, 20 Jan 98 14:06:21 PST." <199801202206.OAA18817@kithrup.com> Date: Tue, 20 Jan 1998 17:14:03 PST From: Bill Fenner Message-Id: <98Jan20.171409pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sean Eric Fagan wrote: >Terry said: >>... on systems which do not use an >>integer stack based calling convention, the value can be treated as >>its type by the varradic function, instead of being treated as an int. >>It is the promotion caused by the calling convention that is the >>source of the breakage. > >It *has* always been the case; not doing it this way is a bug. Not quite. If you don't do it this way, the behavior is undefined -- section 7.8.2.1: ...or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined. So it's not *wrong* to allow chars to be passed into varargs functions as chars, but the ANSI C specification doesn't require it. Terry wants to define some of this undefined behavior. Bill From owner-freebsd-current Tue Jan 20 18:11:29 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA00245 for current-outgoing; Tue, 20 Jan 1998 18:11:29 -0800 (PST) (envelope-from owner-freebsd-current) Received: from wcc.wcc.net (wcc.wcc.net [208.6.232.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA00239 for ; Tue, 20 Jan 1998 18:11:15 -0800 (PST) (envelope-from piquan@wcc.wcc.net) Received: from detlev.UUCP (newip60.wcc.net [206.104.247.60]) by wcc.wcc.net (8.8.7/8.8.7) with ESMTP id UAA23208; Tue, 20 Jan 1998 20:07:34 -0600 (CST) Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.7) id UAA01144; Tue, 20 Jan 1998 20:09:35 -0600 (CST) (envelope-from joelh) Date: Tue, 20 Jan 1998 20:09:35 -0600 (CST) Message-Id: <199801210209.UAA01144@detlev.UUCP> To: fenner@parc.xerox.com CC: sef@kithrup.com, current@FreeBSD.ORG In-reply-to: <98Jan20.171409pst.177476@crevenia.parc.xerox.com> (message from Bill Fenner on Tue, 20 Jan 1998 17:14:03 PST) Subject: Re: Nasty GCC bug? From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <98Jan20.171409pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>> ... on systems which do not use an integer stack based calling >>> convention, the value can be treated as its type by the varradic >>> function, instead of being treated as an int. It is the promotion >>> caused by the calling convention that is the source of the >>> breakage. >> It *has* always been the case; not doing it this way is a bug. > Not quite. If you don't do it this way, the behavior is undefined -- > section 7.8.2.1: > ...or if type is not compatible with the type of the actual > next argument (as promoted according to the default argument > promotions), the behavior is undefined. > So it's not *wrong* to allow chars to be passed into varargs functions > as chars, but the ANSI C specification doesn't require it. Terry wants > to define some of this undefined behavior. I read this to mean that the promotions are required, it's just that if you mismatch types (eg, printf("%s",15);) then the results are undefined. Best, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped From owner-freebsd-current Tue Jan 20 18:24:24 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01171 for current-outgoing; Tue, 20 Jan 1998 18:24:24 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpha.xerox.com (firewall-user@alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA01103 for ; Tue, 20 Jan 1998 18:23:52 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52684(4)>; Tue, 20 Jan 1998 18:23:49 PST Received: by crevenia.parc.xerox.com id <177476>; Tue, 20 Jan 1998 18:23:45 -0800 From: Bill Fenner To: fenner@parc.xerox.com, joelh@gnu.org Subject: Re: Nasty GCC bug? Cc: current@freebsd.org, sef@kithrup.com Message-Id: <98Jan20.182345pst.177476@crevenia.parc.xerox.com> Date: Tue, 20 Jan 1998 18:23:34 PST Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It's easy to read it to say that promotions are required. However, all it really says is that ANSI only guarantees that things work if you match types with the promoted type. However, if you have some way to intuit what type was passed in (e.g. Terry's description of an argument passing scheme which passes types along with values and delays promotion until required), you might see a loop like: switch (va_type(ap)) { /* non-ANSI function */ case VA_CHAR: c = va_arg(ap, char); /* ANSI says this is undefined */ break; ... } Now, that usage of va_arg(), according to ANSI, is undefined. That just means that ANSI doesn't tell us what it's supposed to do, not that ANSI requires that it doesn't do something useful. I was just trying to refute sef's assertion that a compiler/library that implemented printf() in this way was buggy or wrong. It's not. It's defining a certain behavior that ANSI chose not to define. Terry is asserting that FreeBSD should have this behavior, which is a fine thing to have an argument about, but it shouldn't be based upon an assertion that it's an incorrect thing to do. Bill From owner-freebsd-current Tue Jan 20 19:00:59 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04002 for current-outgoing; Tue, 20 Jan 1998 19:00:59 -0800 (PST) (envelope-from owner-freebsd-current) Received: from wcc.wcc.net (wcc.wcc.net [208.6.232.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA03989 for ; Tue, 20 Jan 1998 19:00:42 -0800 (PST) (envelope-from piquan@wcc.wcc.net) Received: from detlev.UUCP (newip54.wcc.net [206.104.247.54]) by wcc.wcc.net (8.8.7/8.8.7) with ESMTP id UAA27919; Tue, 20 Jan 1998 20:57:21 -0600 (CST) Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.7) id UAA00312; Tue, 20 Jan 1998 20:56:49 -0600 (CST) (envelope-from joelh) Date: Tue, 20 Jan 1998 20:56:49 -0600 (CST) Message-Id: <199801210256.UAA00312@detlev.UUCP> To: fenner@parc.xerox.com CC: fenner@parc.xerox.com, current@freebsd.org, sef@kithrup.com In-reply-to: <98Jan20.182345pst.177476@crevenia.parc.xerox.com> (message from Bill Fenner on Tue, 20 Jan 1998 18:23:34 PST) Subject: Re: Nasty GCC bug? From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <98Jan20.182345pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > It's easy to read it to say that promotions are required. However, > all it really says is that ANSI only guarantees that things work if > you match types with the promoted type. This is correct. After rereading the standard, it actually does say that the types have to match after promotion, not that it has to be passed that way. I personally wouldn't want to build a compiler and library that does it differently, though. > However, if you have some way to > intuit what type was passed in (e.g. Terry's description of an argument > passing scheme which passes types along with values and delays > promotion until required), you might see a loop like: > switch (va_type(ap)) { /* non-ANSI function */ > case VA_CHAR: > c = va_arg(ap, char); /* ANSI says this is undefined */ > break; > > ... > } > Now, that usage of va_arg(), according to ANSI, is undefined. That > just means that ANSI doesn't tell us what it's supposed to do, not that > ANSI requires that it doesn't do something useful. I see no way to do this without breaking both unprototyped code and NetBSD binary compatibility. (Actually, I see one other way if the only functions to use this will only be called by functions compiled knowing that this would be used, but it is not reentrant.) If we could do it sans breakage, it wouldn't be a bad thing. But I suspect that if you try to work out a proof, it would show that it must break something. > I was just trying to refute sef's assertion that a compiler/library > that implemented printf() in this way was buggy or wrong. It's not. > It's defining a certain behavior that ANSI chose not to define. Terry > is asserting that FreeBSD should have this behavior, which is a fine > thing to have an argument about, but it shouldn't be based upon an > assertion that it's an incorrect thing to do. I do agree with that. Best, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped From owner-freebsd-current Tue Jan 20 21:06:18 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA12040 for current-outgoing; Tue, 20 Jan 1998 21:06:18 -0800 (PST) (envelope-from owner-freebsd-current) Received: from inet03.citec.qld.gov.au (firewall-user@inet03.citec.qld.gov.au [203.5.10.10]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA12034 for ; Tue, 20 Jan 1998 21:06:11 -0800 (PST) (envelope-from sysseh@manila.workcover.qld.gov.au) Received: by inet03.citec.qld.gov.au; id PAA08487; Wed, 21 Jan 1998 15:06:09 +1000 Received: from CCII.workcover.qld.gov.au(h084202.workcover.qld.gov.au 131.242.84.202) by inet03 via smap (V2.0) id xma007733; Wed, 21 Jan 98 15:05:16 +1000 Received: from bne16unx215.workcover.qld.gov.au (CCI.workcover.qld.gov.au [131.242.84.201]) by CCII.workcover.qld.gov.au (8.8.5/8.8.5) with ESMTP id PAA25075 for ; Wed, 21 Jan 1998 15:03:05 +1000 (EST) Received: from localhost (sysseh@localhost) by bne16unx215.workcover.qld.gov.au (8.8.5/8.8.5) with SMTP id FAA19826 for ; Wed, 21 Jan 1998 05:09:14 GMT Message-Id: <199801210509.FAA19826@bne16unx215.workcover.qld.gov.au> X-Authentication-Warning: bne16unx215.workcover.qld.gov.au: sysseh@localhost didn't use HELO protocol X-Mailer: exmh version 2.0zeta 7/24/97 To: current@freebsd.org Subject: Stupid patch & impacts upon Xfree86. X-Face: 3}heU+2?b->-GSF-G4T4>jEB9~FR(V9lo&o>kAy=Pj&;oVOc<|pr%I/VSG"ZD32J>5gGC0N 7gj]^GI@M:LlqNd]|(2OxOxy@$6@/!,";-!OlucF^=jq8s57$%qXd/ieC8DhWmIy@J1AcnvSGV\|*! >Bvu7+0h4zCY^]{AxXKsDTlgA2m]fX$W@'8ev-Qi+-;%L'CcZ'NBL!@n?}q!M&Em3*eW7,093nOeV8 M)(u+6D;%B7j\XA/9j4!Gj~&jYzflG[#)E9sI&Xe9~y~Gn%fA7>F:YKr"Wx4cZU*6{^2ocZ!YyR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jan 1998 15:09:13 +1000 From: Stephen Hocking Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been following the Xfree86 alpha tree, with the patches as they as they come out. patch is now refusing to work with them. *mumble* Stephen -- The views expressed above are not those of WorkCover Queensland, Australia. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California From owner-freebsd-current Tue Jan 20 21:23:05 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA13299 for current-outgoing; Tue, 20 Jan 1998 21:23:05 -0800 (PST) (envelope-from owner-freebsd-current) Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA13175 for ; Tue, 20 Jan 1998 21:21:50 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.5/8.8.5) id XAA17193 for current@freebsd.org; Tue, 20 Jan 1998 23:21:50 -0600 (CST) From: Kevin Day Message-Id: <199801210521.XAA17193@home.dragondata.com> Subject: panic: removing a buffer when not on a queue To: current@freebsd.org Date: Tue, 20 Jan 1998 23:21:50 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Received this today, from a kernel cvsup'ed on the 17th. panic: removing a buffer when not on a queue The trace showed: panic bremfree vfs_bio_awrite vinvalbuf nfs_vinvalbuf nfs_open vn_open open SMP kernel, running as an nfs client and server. Any questions? Kevin From owner-freebsd-current Tue Jan 20 21:59:05 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA15529 for current-outgoing; Tue, 20 Jan 1998 21:59:05 -0800 (PST) (envelope-from owner-freebsd-current) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA15513; Tue, 20 Jan 1998 21:58:41 -0800 (PST) (envelope-from grog@lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id QAA09669; Wed, 21 Jan 1998 16:28:29 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id QAA08184; Wed, 21 Jan 1998 16:28:28 +1030 (CST) (envelope-from grog) Message-ID: <19980121162827.41222@lemis.com> Date: Wed, 21 Jan 1998 16:28:27 +1030 From: Greg Lehey To: George Vagner Cc: questions@freebsd.org, FreeBSD current users Subject: Re: kernel make^H^H^H^Hbreak References: <199801210509.XAA10551@epcot.spdc.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199801210509.XAA10551@epcot.spdc.ti.com>; from George Vagner on Tue, Jan 20, 1998 at 11:09:09PM -0600 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, Jan 20, 1998 at 11:09:09PM -0600, George Vagner wrote: > > Greg that fixed the previous problem with doing the config! thanks You're welcome. > I tried to do a make on the last cvsupped files and i get this now. > now I am really stuck, does anyone know why this stopped compiling? > do i need to do a make clean or something after cvsupping? cause i > didnt. > cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I. > ./.. -I../../../include -DFAILSAFE -DNFS -DFFS -DKERNEL -include opt_global.h . > ./../pci/bt9xx.c Although it's normally correct and polite to wrap long lines, this kind of output is an exception. It's easier to read when it looks exactly like it would on the screen--one long line. > cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I. > ./.. -I../../../include -DFAILSAFE -DNFS -DFFS -DKERNEL -include opt_global.h . > ./../pci/if_de.c > ../../pci/if_de.c: In function `tulip_addr_filter': > ../../pci/if_de.c:3038: storage size of `step' isn't known > ../../pci/if_de.c:3096: warning: implicit declaration of function `ETHER_FIRST_M > ULTI' > ../../pci/if_de.c:3098: dereferencing pointer to incomplete type > ../../pci/if_de.c:3098: dereferencing pointer to incomplete type > ../../pci/if_de.c:3099: dereferencing pointer to incomplete type > ../../pci/if_de.c:3106: warning: implicit declaration of function `ETHER_NEXT_MU > LTI' > ../../pci/if_de.c:3147: dereferencing pointer to incomplete type > ../../pci/if_de.c:3147: dereferencing pointer to incomplete type > ../../pci/if_de.c:3148: dereferencing pointer to incomplete type > ../../pci/if_de.c:3149: dereferencing pointer to incomplete type > ../../pci/if_de.c:3150: dereferencing pointer to incomplete type > ../../pci/if_de.c: In function `tulip_ifioctl': > ../../pci/if_de.c:4475: warning: implicit declaration of function `ether_addmult > i' > ../../pci/if_de.c:4477: warning: implicit declaration of function `ether_delmult > i' > ../../pci/if_de.c: In function `tulip_pci_attach': > ../../pci/if_de.c:5239: request for member `cfg1' in something not a structure o > r union > ../../pci/if_de.c:5239: request for member `cfg1' in something not a structure o > r union > *** Error code 1 > > Stop. 1. You've omitted a lot of information here. What are you making? Just the kernel? In that case, config will remove the entire build directory, which is a pretty radical 'make clean'. 2. Which version of FreeBSD are you making? In my last message I assumed -CURRENT. If that's the case you should, in principle, send messages to FreeBSD-current@FreeBSD.org. However, this problem doesn't really warrant a message yet. Running -CURRENT means you're pretty much on your own. See Mike Smith's document on this subject (ftp://ftp.lemis.com/pub/staying-current). 3. This particular one looks suspiciously like a broken source file in -CURRENT, since somebody else asked about checking out an earlier version of exactly this file today. See my reply to him, check out the previous version, and try again. Greg From owner-freebsd-current Tue Jan 20 22:13:28 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA17135 for current-outgoing; Tue, 20 Jan 1998 22:13:28 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA17128 for ; Tue, 20 Jan 1998 22:13:18 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id BAA00623; Wed, 21 Jan 1998 01:09:03 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801210609.BAA00623@dyson.iquest.net> Subject: Re: panic: removing a buffer when not on a queue In-Reply-To: <199801210521.XAA17193@home.dragondata.com> from Kevin Day at "Jan 20, 98 11:21:50 pm" To: toasty@home.dragondata.com (Kevin Day) Date: Wed, 21 Jan 1998 01:09:03 -0500 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Kevin Day said: > > Received this today, from a kernel cvsup'ed on the 17th. > > > panic: removing a buffer when not on a queue > > The trace showed: > > panic > bremfree > vfs_bio_awrite > vinvalbuf > nfs_vinvalbuf > nfs_open > vn_open > open > > SMP kernel, running as an nfs client and server. > > Any questions? > There are still some loose ends in -current. If I don't get everything done that I want to get done in the next day or so, I'll commit the minimal fixes only. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Tue Jan 20 22:41:53 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA19597 for current-outgoing; Tue, 20 Jan 1998 22:41:53 -0800 (PST) (envelope-from owner-freebsd-current) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA19592 for ; Tue, 20 Jan 1998 22:41:47 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id WAA15953; Tue, 20 Jan 1998 22:38:27 -0800 (PST) To: Stephen Hocking cc: current@FreeBSD.ORG Subject: Re: Stupid patch & impacts upon Xfree86. In-reply-to: Your message of "Wed, 21 Jan 1998 15:09:13 +1000." <199801210509.FAA19826@bne16unx215.workcover.qld.gov.au> Date: Tue, 20 Jan 1998 22:38:27 -0800 Message-ID: <15950.885364707@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk These are XFree86 patches blowing up now? Hmmm! Perhaps it is time to revert Andrey's patch changes. They seem to have created an unholy mess for very little gain that I can see. > > I've been following the Xfree86 alpha tree, with the patches as they > as they come out. patch is now refusing to work with them. *mumble* > > > Stephen > -- > The views expressed above are not those of WorkCover Queensland, Australia. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California > > From owner-freebsd-current Tue Jan 20 23:50:33 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA00367 for current-outgoing; Tue, 20 Jan 1998 23:50:33 -0800 (PST) (envelope-from owner-freebsd-current) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA00321; Tue, 20 Jan 1998 23:50:06 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id KAA02830; Wed, 21 Jan 1998 10:36:28 +0300 (MSK) (envelope-from ache) Date: Wed, 21 Jan 1998 10:36:27 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: peter@freebsd.org cc: FreeBSD-current Subject: Patch from Attic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter, I don't remember exactly at this moment, I fix -current patch before replacing it with patch 2.5 or not. Please just restore what we have in the Attic and I handle rest. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Wed Jan 21 00:57:35 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA05800 for current-outgoing; Wed, 21 Jan 1998 00:57:35 -0800 (PST) (envelope-from owner-freebsd-current) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA05793 for ; Wed, 21 Jan 1998 00:57:30 -0800 (PST) (envelope-from sos@sos.freebsd.dk) Received: (from sos@localhost) by sos.freebsd.dk (8.8.8/8.8.8) id JAA09899; Wed, 21 Jan 1998 09:34:01 +0100 (MET) (envelope-from sos) Message-Id: <199801210834.JAA09899@sos.freebsd.dk> Subject: Re: Stupid patch & impacts upon Xfree86. In-Reply-To: <15950.885364707@time.cdrom.com> from "Jordan K. Hubbard" at "Jan 20, 98 10:38:27 pm" To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Wed, 21 Jan 1998 09:32:35 +0100 (MET) Cc: sysseh@workcover.qld.gov.au, current@freebsd.org From: SЬren Schmidt Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In reply to Jordan K. Hubbard who wrote: > These are XFree86 patches blowing up now? Hmmm! > > Perhaps it is time to revert Andrey's patch changes. They seem to have > created an unholy mess for very little gain that I can see. BTW whats wrong with the patch that (open|net)BSD has ?? (its not GPL infected) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- SЬren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-current Wed Jan 21 01:39:31 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA08641 for current-outgoing; Wed, 21 Jan 1998 01:39:31 -0800 (PST) (envelope-from owner-freebsd-current) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA08636 for ; Wed, 21 Jan 1998 01:39:28 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.8/8.8.8) id KAA26275 for current@FreeBSD.ORG; Wed, 21 Jan 1998 10:36:54 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199801210936.KAA26275@ocean.campus.luth.se> Subject: What's the status of -current? To: current@FreeBSD.ORG Date: Wed, 21 Jan 1998 10:36:54 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk With all the mail loss and stuff that's been happening, it's hard to know what you have missed. Dyson, are the changes to the VM fully operational yet? Anything else that one should look of for that's been changed the last month? /Mikael From owner-freebsd-current Wed Jan 21 03:15:56 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA14594 for current-outgoing; Wed, 21 Jan 1998 03:15:56 -0800 (PST) (envelope-from owner-freebsd-current) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.124.148]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA14585 for ; Wed, 21 Jan 1998 03:15:51 -0800 (PST) (envelope-from kato@migmatite.eps.nagoya-u.ac.jp) Received: from localhost (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.8/3.6Wbeta7) with ESMTP id UAA04818 for ; Wed, 21 Jan 1998 20:15:44 +0900 (JST) To: current@freebsd.org Subject: Panic while clustered I/O From: KATO Takenori X-Mailer: Mew version 1.92.4 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980121201543Z.kato@gneiss.eps.nagoya-u.ac.jp> Date: Wed, 21 Jan 1998 20:15:43 +0900 X-Dispatcher: imput version 971024 Lines: 342 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Please help me. How to repeat: mount_union foo /usr/obj make world Workarround: disabling clustered I/O in ufs_readwrite.c :-(. # gdb -k GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc. (kgdb) symbol-file kernel.debug Reading symbols from kernel.debug...done. (kgdb) exec-file /var/crash/kernel.0 (kgdb) core-file /var/crash/vmcore.0 IdlePTD 227000 current pcb at 1d7e10 panicstr: vm_bounce_alloc: Unmapped page panic messages: --- panic: vm_bounce_alloc: Unmapped page syncing disks... 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 giving up dumping to dev 401, offset 93952 dump 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 boot (howto=256) at ../../kern/kern_shutdown.c:285 285 dumppcb.pcb_cr3 = rcr3(); (kgdb) where #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 #1 0xf011511f in panic (fmt=0xf01a7389 "vm_bounce_alloc: Unmapped page") at ../../kern/kern_shutdown.c:425 #2 0xf01a74a9 in vm_bounce_alloc (bp=0xf25028bc) at ../../i386/i386/vm_machdep.c:356 #3 0xf017a9dd in sd_strategy (bp=0xf25028bc, sc_link=0xf050af00) at ../../scsi/sd.c:477 #4 0xf017788c in scsi_strategy (bp=0xf25028bc, device=0xf01cf8a8) at ../../scsi/scsi_driver.c:220 #5 0xf017a3dc in sdstrategy (bp=0xf25028bc) at ../../scsi/sd.c:127 #6 0xf014025e in spec_strategy (ap=0xf43f1e10) at ../../miscfs/specfs/spec_vnops.c:557 #7 0xf013f939 in spec_vnoperate (ap=0xf43f1e10) at ../../miscfs/specfs/spec_vnops.c:127 #8 0xf0187e29 in ufs_vnoperatespec (ap=0xf43f1e10) at ../../ufs/ufs/ufs_vnops.c:2242 #9 0xf018784a in ufs_strategy (ap=0xf43f1e10) at ../../ufs/ufs/ufs_vnops.c:1721 #10 0xf0187df9 in ufs_vnoperate (ap=0xf43f1e10) at ../../ufs/ufs/ufs_vnops.c:2224 #11 0xf012cb76 in bwrite (bp=0xf25028bc) at vnode_if.h:1064 #12 0xf013124a in vop_stdbwrite (ap=0xf43f1e48) at ../../kern/vfs_default.c:283 #13 0xf0131091 in vop_defaultop (ap=0xf43f1e48) at ../../kern/vfs_default.c:130 #14 0xf0187df9 in ufs_vnoperate (ap=0xf43f1e48) at ../../ufs/ufs/ufs_vnops.c:2224 #15 0xf012cd30 in bawrite (bp=0xf25028bc) at vnode_if.h:1081 #16 0xf0130ed3 in cluster_wbuild (vp=0xf05ab400, size=8192, start_lbn=1, len=2) at ../../kern/vfs_cluster.c:750 #17 0xf012d59f in vfs_bio_awrite (bp=0xf2525c7c) at ../../kern/vfs_bio.c:886 #18 0xf01823c7 in ffs_fsync (ap=0xf43f1f3c) at ../../ufs/ffs/ffs_vnops.c:181 #19 0xf0180bae in ffs_sync (mp=0xf0542800, waitfor=2, cred=0xf050ad00, p=0xf0526800) at vnode_if.h:499 #20 0xf0134fc7 in sync (p=0xf0526800, uap=0x0) at ../../kern/vfs_syscalls.c:493 #21 0xf012ec21 in vfs_update () at ../../kern/vfs_bio.c:1974 #22 0xf0108b4e in kproc_start (udata=0xf01cca78) at ../../kern/init_main.c:264 #23 0xf019d573 in fork_trampoline () Cannot access memory at address 0x29ff000. (kgdb) up #1 0xf011511f in panic (fmt=0xf01a7389 "vm_bounce_alloc: Unmapped page") at ../../kern/kern_shutdown.c:425 425 boot(bootopt); (kgdb) up #2 0xf01a74a9 in vm_bounce_alloc (bp=0xf25028bc) at ../../i386/i386/vm_machdep.c:356 356 panic("vm_bounce_alloc: Unmapped page"); (kgdb) list 351 for (i = 0; i < countvmpg; i++) { 352 pa = pmap_kextract(va); 353 if (pa >= SIXTEENMEG) 354 ++dobounceflag; 355 if( pa == 0) 356 panic("vm_bounce_alloc: Unmapped page"); 357 va += PAGE_SIZE; 358 } 359 if (dobounceflag == 0) 360 return; (kgdb) print *bp $1 = {b_hash = {le_next = 0x0, le_prev = 0x0}, b_vnbufs = { le_next = 0x87654321, le_prev = 0x0}, b_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, b_act = {tqe_next = 0x0, tqe_prev = 0x0}, b_proc = 0x0, b_flags = 1090519124, b_qindex = 0, b_usecount = 0 '\000', b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0, b_dev = 197637, b_data = 0xf3aaa000
, b_kvabase = 0xf3aaa000
, b_kvasize = 8192, b_lblkno = 0, b_blkno = 341728, b_iodone = 0xf0130904 , b_iodone_chain = 0x0, b_vp = 0xf05ab400, b_dirtyoff = 0, b_dirtyend = 8192, b_rcred = 0x0, b_wcred = 0x0, b_validoff = 0, b_validend = 0, b_pblkno = 2698976, b_saveaddr = 0x0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = { tqh_first = 0xf2525c7c, tqh_last = 0xf2525d0c}, cluster_entry = { tqe_next = 0xf2525c7c, tqe_prev = 0xf2525d0c}}, b_pages = { 0x0 }, b_npages = 0} (kgdb) print bp $2 = (struct buf *) 0xf25028bc (kgdb) up #3 0xf017a9dd in sd_strategy (bp=0xf25028bc, sc_link=0xf050af00) at ../../scsi/sd.c:477 477 vm_bounce_alloc(bp); (kgdb) list 472 /* 473 * Use a bounce buffer if necessary 474 */ 475 #ifdef BOUNCE_BUFFERS 476 if (sc_link->flags & SDEV_BOUNCE) 477 vm_bounce_alloc(bp); 478 #endif 479 480 /* 481 * Place it in the queue of disk activities for this disk (kgdb) up #4 0xf017788c in scsi_strategy (bp=0xf25028bc, device=0xf01cf8a8) at ../../scsi/scsi_driver.c:220 220 (*device->dev_strategy)(bp, sc_link); (kgdb) up #5 0xf017a3dc in sdstrategy (bp=0xf25028bc) at ../../scsi/sd.c:127 127 SCSI_DEVICE_ENTRIES(sd) (kgdb) up #6 0xf014025e in spec_strategy (ap=0xf43f1e10) at ../../miscfs/specfs/spec_vnops.c:557 557 (*bdevsw[major(ap->a_bp->b_dev)]->d_strategy)(ap->a_bp); (kgdb) up #7 0xf013f939 in spec_vnoperate (ap=0xf43f1e10) at ../../miscfs/specfs/spec_vnops.c:127 127 return (VOCALL(spec_vnodeop_p, ap->a_desc->vdesc_offset, ap)); (kgdb) up #8 0xf0187e29 in ufs_vnoperatespec (ap=0xf43f1e10) at ../../ufs/ufs/ufs_vnops.c:2242 2242 return (VOCALL(ufs_specop_p, ap->a_desc->vdesc_offset, ap)); (kgdb) list 2237 ufs_vnoperatespec(ap) 2238 struct vop_generic_args /* { 2239 struct vnodeop_desc *a_desc; 2240 } */ *ap; 2241 { 2242 return (VOCALL(ufs_specop_p, ap->a_desc->vdesc_offset, ap)); 2243 } 2244 2245 (kgdb) up #9 0xf018784a in ufs_strategy (ap=0xf43f1e10) at ../../ufs/ufs/ufs_vnops.c:1721 1721 VOCALL (vp->v_op, VOFFSET(vop_strategy), ap); (kgdb) print ap $3 = (struct vop_strategy_args *) 0xf43f1e10 (kgdb) print *ap $4 = {a_desc = 0xf01ca784, a_bp = 0xf25028bc} (kgdb) print *ap->a_bp $5 = {b_hash = {le_next = 0x0, le_prev = 0x0}, b_vnbufs = { le_next = 0x87654321, le_prev = 0x0}, b_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, b_act = {tqe_next = 0x0, tqe_prev = 0x0}, b_proc = 0x0, b_flags = 1090519124, b_qindex = 0, b_usecount = 0 '\000', b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0, b_dev = 197637, b_data = 0xf3aaa000
, b_kvabase = 0xf3aaa000
, b_kvasize = 8192, b_lblkno = 0, b_blkno = 341728, b_iodone = 0xf0130904 , b_iodone_chain = 0x0, b_vp = 0xf05ab400, b_dirtyoff = 0, b_dirtyend = 8192, b_rcred = 0x0, b_wcred = 0x0, b_validoff = 0, b_validend = 0, b_pblkno = 2698976, b_saveaddr = 0x0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = { tqh_first = 0xf2525c7c, tqh_last = 0xf2525d0c}, cluster_entry = { tqe_next = 0xf2525c7c, tqe_prev = 0xf2525d0c}}, b_pages = { 0x0 }, b_npages = 0} (kgdb) up #10 0xf0187df9 in ufs_vnoperate (ap=0xf43f1e10) at ../../ufs/ufs/ufs_vnops.c:2224 2224 return (VOCALL(ufs_vnodeop_p, ap->a_desc->vdesc_offset, ap)); (kgdb) up #11 0xf012cb76 in bwrite (bp=0xf25028bc) at vnode_if.h:1064 1064 return (VCALL((bp)->b_vp, VOFFSET(vop_strategy), &a)); (kgdb) list 1059 { 1060 struct vop_strategy_args a; 1061 1062 a.a_desc = VDESC(vop_strategy); 1063 a.a_bp = bp; 1064 return (VCALL((bp)->b_vp, VOFFSET(vop_strategy), &a)); 1065 } 1066 1067 struct vop_bwrite_args { 1068 struct vnodeop_desc *a_desc; (kgdb) print *bp $6 = {b_hash = {le_next = 0x0, le_prev = 0x0}, b_vnbufs = { le_next = 0x87654321, le_prev = 0x0}, b_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, b_act = {tqe_next = 0x0, tqe_prev = 0x0}, b_proc = 0x0, b_flags = 1090519124, b_qindex = 0, b_usecount = 0 '\000', b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0, b_dev = 197637, b_data = 0xf3aaa000
, b_kvabase = 0xf3aaa000
, b_kvasize = 8192, b_lblkno = 0, b_blkno = 341728, b_iodone = 0xf0130904 , b_iodone_chain = 0x0, b_vp = 0xf05ab400, b_dirtyoff = 0, b_dirtyend = 8192, b_rcred = 0x0, b_wcred = 0x0, b_validoff = 0, b_validend = 0, b_pblkno = 2698976, b_saveaddr = 0x0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = { tqh_first = 0xf2525c7c, tqh_last = 0xf2525d0c}, cluster_entry = { tqe_next = 0xf2525c7c, tqe_prev = 0xf2525d0c}}, b_pages = { 0x0 }, b_npages = 0} (kgdb) up #12 0xf013124a in vop_stdbwrite (ap=0xf43f1e48) at ../../kern/vfs_default.c:283 283 return (bwrite(ap->a_bp)); (kgdb) print $7 = {b_hash = {le_next = 0x0, le_prev = 0x0}, b_vnbufs = { le_next = 0x87654321, le_prev = 0x0}, b_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, b_act = {tqe_next = 0x0, tqe_prev = 0x0}, b_proc = 0x0, b_flags = 1090519124, b_qindex = 0, b_usecount = 0 '\000', b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0, b_dev = 197637, b_data = 0xf3aaa000
, b_kvabase = 0xf3aaa000
, b_kvasize = 8192, b_lblkno = 0, b_blkno = 341728, b_iodone = 0xf0130904 , b_iodone_chain = 0x0, b_vp = 0xf05ab400, b_dirtyoff = 0, b_dirtyend = 8192, b_rcred = 0x0, b_wcred = 0x0, b_validoff = 0, b_validend = 0, b_pblkno = 2698976, b_saveaddr = 0x0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = { tqh_first = 0xf2525c7c, tqh_last = 0xf2525d0c}, cluster_entry = { tqe_next = 0xf2525c7c, tqe_prev = 0xf2525d0c}}, b_pages = { 0x0 }, b_npages = 0} (kgdb) up #13 0xf0131091 in vop_defaultop (ap=0xf43f1e48) at ../../kern/vfs_default.c:130 130 return (VOCALL(default_vnodeop_p, ap->a_desc->vdesc_offset, ap)); (kgdb) up #14 0xf0187df9 in ufs_vnoperate (ap=0xf43f1e48) at ../../ufs/ufs/ufs_vnops.c:2224 2224 return (VOCALL(ufs_vnodeop_p, ap->a_desc->vdesc_offset, ap)); (kgdb) up #15 0xf012cd30 in bawrite (bp=0xf25028bc) at vnode_if.h:1081 1081 return (VCALL((bp)->b_vp, VOFFSET(vop_bwrite), &a)); (kgdb) print *bp Cannot access memory at address 0x0. (kgdb) pritn bp Undefined command: "pritn". Try "help". (kgdb) print bp $8 = (struct buf *) 0x0 (kgdb) print *(struct buf *)(struct buf *)0xf225028bc Numeric constant too large. (kgdb) print *(struct buf *)0xf225028bc $9 = {b_hash = {le_next = 0x0, le_prev = 0x0}, b_vnbufs = { le_next = 0x87654321, le_prev = 0x0}, b_freelist = {tqe_next = 0x0, tqe_prev = 0x0}, b_act = {tqe_next = 0x0, tqe_prev = 0x0}, b_proc = 0x0, b_flags = 1090519124, b_qindex = 0, b_usecount = 0 '\000', b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0, b_dev = 197637, b_data = 0xf3aaa000
, b_kvabase = 0xf3aaa000
, b_kvasize = 8192, b_lblkno = 0, b_blkno = 341728, b_iodone = 0xf0130904 , b_iodone_chain = 0x0, b_vp = 0xf05ab400, b_dirtyoff = 0, b_dirtyend = 8192, b_rcred = 0x0, b_wcred = 0x0, b_validoff = 0, b_validend = 0, b_pblkno = 2698976, b_saveaddr = 0x0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = { tqh_first = 0xf2525c7c, tqh_last = 0xf2525d0c}, cluster_entry = { tqe_next = 0xf2525c7c, tqe_prev = 0xf2525d0c}}, b_pages = { 0x0 }, b_npages = 0} (kgdb) up #16 0xf0130ed3 in cluster_wbuild (vp=0xf05ab400, size=8192, start_lbn=1, len=2) at ../../kern/vfs_cluster.c:750 750 bawrite(bp); (kgdb) print *vp $10 = {v_flag = 8192, v_usecount = 2, v_writecount = 0, v_holdcnt = 3, v_lastr = 0, v_id = 2731, v_mount = 0xf0542800, v_op = 0xf0517c00, v_freelist = {tqe_next = 0xf05b1e00, tqe_prev = 0xf01e077c}, v_mntvnodes = { le_next = 0xf05ac200, le_prev = 0xf0542814}, v_cleanblkhd = { lh_first = 0xf2525c7c}, v_dirtyblkhd = {lh_first = 0xf252a588}, v_numoutput = 2, v_type = VREG, v_un = {vu_mountedhere = 0x0, vu_socket = 0x0, vu_specinfo = 0x0, vu_fifoinfo = 0x0}, v_lease = 0x0, v_lastw = 1, v_cstart = 0, v_lasta = 341744, v_clen = 7, v_object = 0xf46d4000, v_interlock = {lock_data = 0}, v_vnlock = 0x0, v_tag = VT_UFS, v_data = 0xf05b1100, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xf05a23c0, tqh_last = 0xf05a23d0}, v_dd = 0xf05ab400, v_ddid = 0, v_pollinfo = {vpi_lock = {lock_data = 0}, vpi_selinfo = {si_pid = 0, si_flags = 0}, vpi_events = 0, vpi_revents = 0}} (kgdb) print tbp $11 = (struct buf *) 0xf252a588 (kgdb) print *tbp $12 = {b_hash = {le_next = 0x0, le_prev = 0xf252b94c}, b_vnbufs = { le_next = 0xf252c7e8, le_prev = 0xf05ab434}, b_freelist = { tqe_next = 0xf252c7e8, tqe_prev = 0xf2507020}, b_act = {tqe_next = 0x0, tqe_prev = 0x0}, b_proc = 0x0, b_flags = 537002656, b_qindex = 2, b_usecount = 15 '\017', b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0, b_dev = 4294967295, b_data = 0xf2db9000 "ype.h /usr/include/runetype.h /usr/include/stdlib.h \\\n /usr/include/unistd.h /usr/src/usr.bin/make/sprite.h \\\n /usr/src/usr.bin/make/lst.h /usr/include/sys/param.h \\\n /usr/include/sys/syslimits.h /usr"..., b_kvabase = 0xf2db9000 "ype.h /usr/include/runetype.h /usr/include/stdlib.h \\\n /usr/include/unistd.h /usr/src/usr.bin/make/sprite.h \\\n /usr/src/usr.bin/make/lst.h /usr/include/sys/param.h \\\n /usr/include/sys/syslimits.h /usr"..., b_kvasize = 8192, b_lblkno = 1, b_blkno = 341744, b_iodone = 0, b_iodone_chain = 0x0, b_vp = 0xf05ab400, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_validoff = 0, b_validend = 0, b_pblkno = 0, b_saveaddr = 0x0, b_savekva = 0x0, b_driver1 = 0x0, b_driver2 = 0x0, b_spc = 0x0, b_cluster = {cluster_head = {tqh_first = 0x0, tqh_last = 0x0}, cluster_entry = {tqe_next = 0x0, tqe_prev = 0x0}}, b_pages = {0xf02af100, 0xf02a2134, 0x0 }, b_npages = 2} (kgdb) up #17 0xf012d59f in vfs_bio_awrite (bp=0xf2525c7c) at ../../kern/vfs_bio.c:886 886 nwritten = cluster_wbuild(vp, size, lblkno, ncl); (kgdb) up #18 0xf01823c7 in ffs_fsync (ap=0xf43f1f3c) at ../../ufs/ffs/ffs_vnops.c:181 181 vfs_bio_awrite(bp); (kgdb) up #19 0xf0180bae in ffs_sync (mp=0xf0542800, waitfor=2, cred=0xf050ad00, p=0xf0526800) at vnode_if.h:499 499 return (VCALL(vp, VOFFSET(vop_fsync), &a)); (kgdb) print *vp $13 = {v_flag = 8192, v_usecount = 2, v_writecount = 0, v_holdcnt = 3, v_lastr = 0, v_id = 2731, v_mount = 0xf0542800, v_op = 0xf0517c00, v_freelist = {tqe_next = 0xf05b1e00, tqe_prev = 0xf01e077c}, v_mntvnodes = { le_next = 0xf05ac200, le_prev = 0xf0542814}, v_cleanblkhd = { lh_first = 0xf2525c7c}, v_dirtyblkhd = {lh_first = 0xf252a588}, v_numoutput = 2, v_type = VREG, v_un = {vu_mountedhere = 0x0, vu_socket = 0x0, vu_specinfo = 0x0, vu_fifoinfo = 0x0}, v_lease = 0x0, v_lastw = 1, v_cstart = 0, v_lasta = 341744, v_clen = 7, v_object = 0xf46d4000, v_interlock = {lock_data = 0}, v_vnlock = 0x0, v_tag = VT_UFS, v_data = 0xf05b1100, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xf05a23c0, tqh_last = 0xf05a23d0}, v_dd = 0xf05ab400, v_ddid = 0, v_pollinfo = {vpi_lock = {lock_data = 0}, vpi_selinfo = {si_pid = 0, si_flags = 0}, vpi_events = 0, vpi_revents = 0}} (kgdb) up #20 0xf0134fc7 in sync (p=0xf0526800, uap=0x0) at ../../kern/vfs_syscalls.c:493 493 VFS_SYNC(mp, MNT_NOWAIT, p != NULL ? p->p_ucred : NOCRED, p); (kgdb) up #21 0xf012ec21 in vfs_update () at ../../kern/vfs_bio.c:1974 1974 sync(curproc, NULL); (kgdb) up #22 0xf0108b4e in kproc_start (udata=0xf01cca78) at ../../kern/init_main.c:264 264 (*kp->func)(); (kgdb) up #23 0xf019d573 in fork_trampoline () (kgdb) up Cannot access memory at address 0x29ff000. (kgdb) quit ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-current Wed Jan 21 03:42:11 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA16648 for current-outgoing; Wed, 21 Jan 1998 03:42:11 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpha.netvision.net.il (alpha.NetVision.net.il [194.90.1.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA16587 for ; Wed, 21 Jan 1998 03:41:58 -0800 (PST) (envelope-from gena@NetVision.net.il) Received: from Burka.NetVision.net.il (burka.NetVision.net.il [194.90.1.23]) by alpha.netvision.net.il (8.8.6/8.8.6) with ESMTP id NAA26653; Wed, 21 Jan 1998 13:41:50 +0200 (IST) Message-ID: X-Mailer: XFMail 1.3-alpha-011998 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 X-XFMail-Comment: Experimental version - for developers only Date: Wed, 21 Jan 1998 13:41:49 +0200 (IST) X-Face: #v>4HN>#D_"[olq9y`HqTYkLVB89Xy|3')Vs9v58JQ*u-xEJVKY`xa.}E?z0RkLI/P&;BJmi0#u=W0).-Y'J4(dw{"54NhSG|YYZG@[)(`e! >jN#L!~qI5fE-JHS+< Organization: NetVision Ltd. From: Gennady Sorokopud To: current@freebsd.org Subject: gdb problems Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id DAA16631 Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! gdb does not seem to work on the latest freebsd-current: 13:37 root-ttyp2 Burka:/tmp#gcc -g a.c 13:37 root-ttyp2 Burka:/tmp#gdb a.out GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... (gdb) r Starting program: /usr/tmp/a.out Error accessing memory address 0x1087: Bad address. (gdb) The program is running. Quit anyway (and kill it)? (y or n) y 13:38 root-ttyp2 Burka:/tmp#cat a.c void main(){} This is on todays current, with todays kernel and gdb , after a make world. The same gdb appears to work fine with kernel from about a month ago. Any ideas? Best regards. -------- Gennady B. Sorokopud - System programmer at NetVision Israel. E-Mail: Gennady Sorokopud PGP public key is available by fingering gena@netvision.net.il This message was sent at 21-Jan-98 13:41:49 by XFMail From owner-freebsd-current Wed Jan 21 04:01:47 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA17929 for current-outgoing; Wed, 21 Jan 1998 04:01:47 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA17924 for ; Wed, 21 Jan 1998 04:01:42 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id HAA00803; Wed, 21 Jan 1998 07:01:17 -0500 (EST) (envelope-from toor) Message-Id: <199801211201.HAA00803@dyson.iquest.net> Subject: Re: Panic while clustered I/O In-Reply-To: <19980121201543Z.kato@gneiss.eps.nagoya-u.ac.jp> from KATO Takenori at "Jan 21, 98 08:15:43 pm" To: kato@migmatite.eps.nagoya-u.ac.jp (KATO Takenori) Date: Wed, 21 Jan 1998 07:01:17 -0500 (EST) Cc: current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk KATO Takenori said: > Please help me. > > How to repeat: > mount_union foo /usr/obj > make world > > Workarround: disabling clustered I/O in ufs_readwrite.c :-(. > The VFS layering is being worked on aggressively right now. Hopefully, it will be more possible to fix the problem, after I get done with my part of the layering issues. PHK has started working on it, and I am working on the VFS/VM interface. Once we all get done with it, I think that it will be much easier to debug these problems. Note that the specific problem that you are seeing is likely partially due to the problems with (lack of) resource reservation. It appears that you are running out of bounce-buffers (obvious.) Even if you get rid of the use of bounces, there will still likely eventually be problems. Note that it appears that clustering is putting to much pressure on the bounce buffer code. You *might* try increasing the size of the bounce space, and see if things work better. Also, Justin is working on the new FreeBSD bus mgmt code. That also might be a component of a "real" fix. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Wed Jan 21 04:03:40 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA18066 for current-outgoing; Wed, 21 Jan 1998 04:03:40 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA18061 for ; Wed, 21 Jan 1998 04:03:35 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id HAA00823; Wed, 21 Jan 1998 07:03:25 -0500 (EST) (envelope-from toor) Message-Id: <199801211203.HAA00823@dyson.iquest.net> Subject: Re: gdb problems In-Reply-To: from Gennady Sorokopud at "Jan 21, 98 01:41:49 pm" To: gena@NetVision.net.il (Gennady Sorokopud) Date: Wed, 21 Jan 1998 07:03:25 -0500 (EST) Cc: current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Gennady Sorokopud said: > Hi! > > gdb does not seem to work on the latest freebsd-current: > > 13:37 root-ttyp2 Burka:/tmp#gcc -g a.c > 13:37 root-ttyp2 Burka:/tmp#gdb a.out > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.16 (i386-unknown-freebsd), > Copyright 1996 Free Software Foundation, Inc... > (gdb) r > Starting program: /usr/tmp/a.out > Error accessing memory address 0x1087: Bad address. > (gdb) The program is running. Quit anyway (and kill it)? (y or n) y > 13:38 root-ttyp2 Burka:/tmp#cat a.c > void main(){} > > This is on todays current, with todays kernel and gdb , after a make world. > The same gdb appears to work fine with kernel from about a month ago. > > Any ideas? > Yes, there is a bug in vm_map. My private version of vm_map is too different to send you diffs. I'll commit a minimal fix today, if I cannot commit the entire set of fixes that I need to apply. BDE told me about this a week or so ago, and maybe I need to "just apply" the fix asap? -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Wed Jan 21 04:06:22 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA18314 for current-outgoing; Wed, 21 Jan 1998 04:06:22 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA18305 for ; Wed, 21 Jan 1998 04:06:17 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id HAA00829; Wed, 21 Jan 1998 07:06:05 -0500 (EST) (envelope-from toor) Message-Id: <199801211206.HAA00829@dyson.iquest.net> Subject: Re: What's the status of -current? In-Reply-To: <199801210936.KAA26275@ocean.campus.luth.se> from Mikael Karpberg at "Jan 21, 98 10:36:54 am" To: karpen@ocean.campus.luth.se (Mikael Karpberg) Date: Wed, 21 Jan 1998 07:06:05 -0500 (EST) Cc: current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg said: > > With all the mail loss and stuff that's been happening, it's hard to know > what you have missed. > > Dyson, are the changes to the VM fully operational yet? > Anything else that one should look of for that's been changed the last month? > It is still in rough shape. I am working at 100% trying to clean things up. There are some fixes that I can apply with minimal disturbances, and I am getting convinced that it is time to bring -current to a more stable state again. (It is sometimes tricky to decide whether or not to apply complete fixes, or fixes to make the problems go away enough that other people can use -current. I think that the problems have gone on long enough, and the fixes that I have been working on are taking alot longer than I had hoped.) -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Wed Jan 21 04:20:07 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA19012 for current-outgoing; Wed, 21 Jan 1998 04:20:07 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA19005 for ; Wed, 21 Jan 1998 04:20:02 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id HAA00223 for current@freebsd.org; Wed, 21 Jan 1998 07:20:00 -0500 (EST) (envelope-from toor) Message-Id: <199801211220.HAA00223@dyson.iquest.net> Subject: For GDB to work, use -r1.107 for vm_map.c To: current@freebsd.org Date: Wed, 21 Jan 1998 07:19:59 -0500 (EST) From: "John S. Dyson" Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have applied a fix for GDB to work now. You'll need -r1.107 of vm_map.c. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Wed Jan 21 05:20:16 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA23139 for current-outgoing; Wed, 21 Jan 1998 05:20:16 -0800 (PST) (envelope-from owner-freebsd-current) Received: from korin.warman.org.pl (korin.nask.waw.pl [148.81.160.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA23131; Wed, 21 Jan 1998 05:20:07 -0800 (PST) (envelope-from abial@korin.warman.org.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.8.8/8.8.5) with SMTP id OAA11726; Wed, 21 Jan 1998 14:22:31 +0100 (CET) Date: Wed, 21 Jan 1998 14:22:30 +0100 (CET) From: Andrzej Bialecki To: freebsd-current@freebsd.org cc: jkh@freebsd.org Subject: Setting root device Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! Is there some generic way to set the root device from bootblock? Presently, if I'm correct, we have two choices: * ask for root device (btw., how strange that this code is tied to swapgeneric.c and "swap on" config clause, not the "root on"...) * set default (compiled in) (I'm not talking about _startup_ device, but about where do I look for root to mount it). What I'd like to see is to have an option to explicitly set the rootdev, and not have it interpreted by bootblock. The problem I have is with the new Intel mb, Dakota. I have an ATAPI CD-ROM on channel 0 (no other IDE disks whatsoever), set as non-bootable in BIOS, and only one SCSI disk on channel 0 of 7895. BUT... I can never automatically mount root because the bootblock thinks I'm booting off of the wd(0,a), and of course the kernel doesn't find it's root after that (because in fact it was booted from sd(0,a)). Why is it so? Anyway, I'd like to be able to set something like "rootdev=da0a" in boot prompt, and to have it interpreted by kernel (which knows better what to do with this string, as by this time it has already found a da0 disk). Any ideas? And the second thing: I attach the patch which IMHO can help with using "-a" option from bootblock. And the third one: why '-a' does not have precedence over booting from compiled-in MFS? I noticed that if I have an MFS in kernel (and the kernel has support for swapgeneric) '-a' is silently ignored... Andrzej Bialecki ---------------------+--------------------------------------------------------- abial@warman.org.pl | if(halt_per_mth > 0) { fetch("http://www.freebsd.org") } Research & Academic | "Be open-minded, but don't let your brains to fall out." Network in Poland | All of the above (and more) is just my personal opinion. ---------------------+--------------------------------------------------------- From owner-freebsd-current Wed Jan 21 08:06:44 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07093 for current-outgoing; Wed, 21 Jan 1998 08:06:44 -0800 (PST) (envelope-from owner-freebsd-current) Received: from lsd.relcom.eu.net (root@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA06950; Wed, 21 Jan 1998 08:05:07 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id SAA05269; Wed, 21 Jan 1998 18:31:07 +0300 (MSK) (envelope-from ache) Date: Wed, 21 Jan 1998 18:31:02 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: FreeBSD-current cc: committers@freebsd.org Subject: Patch & CVS diff summary for -current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 1) There is no more new patch 2.5 in -current, patch 2.1 restored 2) Patch 2.1 handle Index: lines as unmodified GNU patch 2.1 now 3) To get FreeBSD hacked patch behaviour just add -I option to patch call 4) CVS fix backed out in favour of patch -I usage In comparison with old -current we have changed patch behaviour only, i.e. old variant available with -I option while GNU one available by default. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Wed Jan 21 10:55:10 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20486 for current-outgoing; Wed, 21 Jan 1998 10:55:10 -0800 (PST) (envelope-from owner-freebsd-current) Received: from veda.is (adam@veda.is [193.4.230.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20388 for ; Wed, 21 Jan 1998 10:54:04 -0800 (PST) (envelope-from adam@veda.is) Received: (from adam@localhost) by veda.is (8.8.8/8.8.8) id SAA05003 for freebsd-current@freebsd.org; Wed, 21 Jan 1998 18:54:02 GMT (envelope-from adam) From: Adam David Message-Id: <199801211854.SAA05003@veda.is> Subject: if.h / in_var.h breakage? To: freebsd-current@freebsd.org Date: Wed, 21 Jan 1998 18:54:02 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Attempting to run 'make buildworld' under -current on a RELENG_2_2 source tree, I get the following errors. Where should this be fixed and how? Adam David cc -O2 -m486 -pipe -I/sys -c /usr1/2.2-stable/src/usr.bin/netstat/if.c In file included from /usr1/2.2-stable/src/usr.bin/netstat/if.c:42: /sys/net/if.h:69: field `ifi_lastchange' has incomplete type In file included from /usr1/2.2-stable/src/usr.bin/netstat/if.c:46: /sys/netinet/in_var.h:49: field `ia_ifa' has incomplete type In file included from /usr1/2.2-stable/src/usr.bin/netstat/if.c:48: /sys/netinet/if_ether.h:90: field `ac_if' has incomplete type /sys/netinet/if_ether.h:118: warning: `struct rtentry' declared inside parameter list /sys/netinet/if_ether.h:118: warning: its scope is only this definition or declaration, /sys/netinet/if_ether.h:118: warning: which is probably not what you want. In file included from /usr1/2.2-stable/src/usr.bin/netstat/if.c:51: /sys/netipx/ipx_if.h:50: field `ia_ifa' has incomplete type /usr1/2.2-stable/src/usr.bin/netstat/if.c: In function `intpr': /usr1/2.2-stable/src/usr.bin/netstat/if.c:83: storage size of `ifnet' isn't known /usr1/2.2-stable/src/usr.bin/netstat/if.c:85: field `ifa' has incomplete type /usr1/2.2-stable/src/usr.bin/netstat/if.c:269: structure has no member named `ia_multiaddrs' /usr1/2.2-stable/src/usr.bin/netstat/if.c:273: structure has no member named `inm_entry' /usr1/2.2-stable/src/usr.bin/netstat/if.c:286: storage size of `enm' isn't known /usr1/2.2-stable/src/usr.bin/netstat/if.c:289: structure has no member named `ac_multiaddrs' /usr1/2.2-stable/src/usr.bin/netstat/if.c: In function `sidewaysintpr': /usr1/2.2-stable/src/usr.bin/netstat/if.c:340: storage size of `ifnet' isn't known From owner-freebsd-current Wed Jan 21 11:13:57 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA22169 for current-outgoing; Wed, 21 Jan 1998 11:13:57 -0800 (PST) (envelope-from owner-freebsd-current) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA22112; Wed, 21 Jan 1998 11:13:08 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id WAA06311; Wed, 21 Jan 1998 22:12:57 +0300 (MSK) (envelope-from ache) Date: Wed, 21 Jan 1998 22:12:52 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: FreeBSD-current cc: committers@freebsd.org Subject: Patch guidelines Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk After series of back outs, now use "patch -I" for CVS diffs to obtain full compatibility with FreeBSD hacked "patch" and just "patch" for compatibility with GNU "patch". -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Wed Jan 21 11:22:39 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA22793 for current-outgoing; Wed, 21 Jan 1998 11:22:39 -0800 (PST) (envelope-from owner-freebsd-current) Received: from rah.star-gate.com ([209.133.7.178]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA22772; Wed, 21 Jan 1998 11:22:20 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id LAA06118; Wed, 21 Jan 1998 11:22:08 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199801211922.LAA06118@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: dyson@FreeBSD.ORG cc: gena@NetVision.net.il (Gennady Sorokopud), current@FreeBSD.ORG Subject: Re: gdb problems In-reply-to: Your message of "Wed, 21 Jan 1998 07:03:25 EST." <199801211203.HAA00823@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jan 1998 11:22:08 -0800 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Yes, there is a bug in vm_map. My private version of vm_map is too different > to send you diffs. I'll commit a minimal fix today, if I cannot commit the > entire set of fixes that I need to apply. BDE told me about this a week > or so ago, and maybe I need to "just apply" the fix asap? I don't see why you have to apply the fixes asap given that it has been stated on the list over and over that we are having problems with -current and we know that you are working on the problem. What I am trying to say is if it is possible take your time to fix the current crop of vm problems with the hope of not de-stabilizing the system further by way of rushing out fixes. Cheers, Amancio From owner-freebsd-current Wed Jan 21 14:57:59 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05726 for current-outgoing; Wed, 21 Jan 1998 14:57:59 -0800 (PST) (envelope-from owner-freebsd-current) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05704 for ; Wed, 21 Jan 1998 14:57:46 -0800 (PST) (envelope-from mestery@mail.winternet.com) Received: (from adm@localhost) by icicle.winternet.com (8.8.8/8.8.8) id QAA18521 for ; Wed, 21 Jan 1998 16:57:41 -0600 (CST) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma018387; Wed, 21 Jan 98 16:56:54 -0600 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.7/8.8.4) with SMTP id QAA05030 for ; Wed, 21 Jan 1998 16:56:54 -0600 (CST) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Wed, 21 Jan 1998 16:56:53 -0600 (CST) From: Kyle Mestery To: freebsd-current@freebsd.org Subject: ACE and current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone been running the ACE libraries on current? I am runing a kernel from Dec. 11, and I can get them to compile and run fine without thread support, but when I try and compile them with thread support, every single test core dumps. I will trace through one tonite, but just wanted to see if anyone else is using them with current. Thanks! Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Minneapolis, MN 55428 mesteka@anubis.network.com, mestery@winternet.com FreeBSD hope.winternet.com 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Thu Dec 11 21:35:02 CST 1997 mestery@hope.winternet.com:/usr/src/sys/compile/HOPE i386 From owner-freebsd-current Wed Jan 21 15:06:44 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06879 for current-outgoing; Wed, 21 Jan 1998 15:06:44 -0800 (PST) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06827; Wed, 21 Jan 1998 15:06:21 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id SAA29073; Wed, 21 Jan 1998 18:06:11 -0500 (EST) (envelope-from toor) From: "John S. Dyson" Message-Id: <199801212306.SAA29073@dyson.iquest.net> Subject: Re: gdb problems In-Reply-To: <199801211922.LAA06118@rah.star-gate.com> from Amancio Hasty at "Jan 21, 98 11:22:08 am" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Wed, 21 Jan 1998 18:06:11 -0500 (EST) Cc: dyson@FreeBSD.ORG, gena@NetVision.net.il, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty said: > > Yes, there is a bug in vm_map. My private version of vm_map is too different > > to send you diffs. I'll commit a minimal fix today, if I cannot commit the > > entire set of fixes that I need to apply. BDE told me about this a week > > or so ago, and maybe I need to "just apply" the fix asap? > > I don't see why you have to apply the fixes asap given that it has been > stated on the list over and over that we are having problems > with -current and we know that you are working on the problem. > What I am trying to say is if it is possible take your time to fix > the current crop of vm problems with the hope of not de-stabilizing > the system further by way of rushing out fixes. > The complete GDB fix was so simple, that I went ahead and committed it. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Wed Jan 21 15:07:22 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA06966 for current-outgoing; Wed, 21 Jan 1998 15:07:22 -0800 (PST) (envelope-from owner-freebsd-current) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA06951; Wed, 21 Jan 1998 15:07:13 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id QAA09048; Wed, 21 Jan 1998 16:04:44 -0700 (MST) Date: Wed, 21 Jan 1998 16:04:44 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199801212304.QAA09048@narnia.plutotech.com> To: dyson@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: Panic while clustered I/O Newsgroups: pluto.freebsd.current In-Reply-To: <199801211201.HAA00803@dyson.iquest.net> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Also, Justin is working on the new FreeBSD bus mgmt code. That also might > be a component of a "real" fix. It requires some large changes to each bus mastering ISA device driver, so I don't know how realistic it is to use bus dma to fix these kinds of problems in the short term. I don't mind adding bus dma support to drivers I need to re-write/modify heavily anyway (i.e. for it to work in a CAM environment), but I'm loath to do the work twice and modify the current SCSI drivers. > -- > John | Never try to teach a pig to sing, > dyson@freebsd.org | it just makes you look stupid, > jdyson@nc.com | and it irritates the pig. -- Justin From owner-freebsd-current Wed Jan 21 16:33:26 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA17174 for current-outgoing; Wed, 21 Jan 1998 16:33:26 -0800 (PST) (envelope-from owner-freebsd-current) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA17158; Wed, 21 Jan 1998 16:33:16 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id RAA02467; Wed, 21 Jan 1998 17:18:06 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd002357; Wed Jan 21 17:17:59 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA14275; Wed, 21 Jan 1998 17:16:52 -0700 (MST) From: Terry Lambert Message-Id: <199801220016.RAA14275@usr09.primenet.com> Subject: Re: Panic while clustered I/O To: dyson@freebsd.org Date: Thu, 22 Jan 1998 00:16:37 +0000 (GMT) Cc: kato@migmatite.eps.nagoya-u.ac.jp, current@freebsd.org In-Reply-To: <199801211201.HAA00803@dyson.iquest.net> from "John S. Dyson" at Jan 21, 98 07:01:17 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The VFS layering is being worked on aggressively right now. Hopefully, > it will be more possible to fix the problem, after I get done with my > part of the layering issues. PHK has started working on it, and I am > working on the VFS/VM interface. Once we all get done with it, I think > that it will be much easier to debug these problems. What exactly are you doing to the VFS layering? Is there anything I can help with? I would *dearly* love to get the following changes in: 1. Enforced use of VOP_GETPAGE/VOP_PUTPAGE in all cases so that there are no buffer list aliases in an FS stack. This will allow nullfs to truly be nullfs. The synchronization failures have been from stacked dirty pages. 2. Hang the advisory lock list off the vnode where the pages live instead of off the in-core inode. 3. Make the advisory locking code veto-based instead of call-down based. This would move much duplicate code out of each FS instance, as well as reducing the number of kernel interfaces each FS depends upon. This is also necessary to support NFS client locking. 4. Do the same for VOP_LOCK. Right now, there is a heck of a lot of imperfectly duplicated functionality in the per-FS VOP_LOCK code. This is a primary source of strange errors. 5. Have the code that allocated the path name buffer free it, so that each FS in a stack does not have to be aware of the internals of the path name buffer. I think this is necessary for Unicode and dual namespace support (NTFS/VFAT/VFAT32/HFS/HPFS). 6. Get rid of the VFS_MOUNTROOT/VFS_MOUNT dichotomy. There is no good reason for an fs mount to know if it's a root mount or not. The root mount and the non-rooot mount vnode overlay code should go to common code, both of which call a single VOP_MOUNT. Right now there are FS types that can not be mounted as your root FS because of this dichotomy. 7. Fix path lookup to actually recurse instead of rewriting the path buffer. This will remove the MAXPATHLEN restriction from a list of relative symlinks. 8. Add a VOP_VALLOC/VOP_VRELE to allow FS's to own their own vnode structures if they want, instead of using a vnode from the global vnode pool. 9. Seperate the VOP_READDIR code into two functions to allow us to get rid of "cookies" and the NFS directory read restart problems for some FS types. 10. Order the contents of the vnodeop_desc array. We can't add new ops not in vfs_op_descs[] in vnode_if.c at runtime, and ordering the array will allow us to directly reference the functions out with the VOP_XXX macro instead packing the argument list into an argument structure on the stack and VCALL using the VOCALL descriptor dereference (saves one function call and much argument munging per VOP_XXX). On a related note: 1. Seperate lock assertion from coelescing in the advisory locking. This is also necessary for NFS client locking so that the lock can be asserted locally, asserted remotely, and deasserted locally if the remote assertion fails. 2. Seperate quotas out into a stacking layer so they will work with all FS's. Is it now the time for this stuff??? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-current Wed Jan 21 20:12:39 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA07932 for current-outgoing; Wed, 21 Jan 1998 20:12:39 -0800 (PST) (envelope-from owner-freebsd-current) Received: from mhub3.tc.umn.edu (0@mhub3.tc.umn.edu [128.101.131.53]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA07912 for ; Wed, 21 Jan 1998 20:12:28 -0800 (PST) (envelope-from adkin003@tc.umn.edu) Received: from mhub1.tc.umn.edu by mhub3.tc.umn.edu; Wed, 21 Jan 98 22:12:23 -0600 Received: from gold.tc.umn.edu by mhub1.tc.umn.edu; Wed, 21 Jan 98 22:12:22 -0600 Received: from pub-20-c-177.dialup.umn.edu by gold.tc.umn.edu; Wed, 21 Jan 98 22:12:22 -0600 Date: Wed, 21 Jan 1998 22:10:17 -0600 (CST) From: dave adkins X-Sender: adkin003@samthedog To: current@FreeBSD.ORG Subject: ppp and proxy arp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk hi, v1.22 and v1.23 of arp.c don't seem to publish the the ethernet address of the server correctly with proxy arp. The entry, always reads as incomplete. Going back to v1.21 of arp.c makes the problem go away. Running arp.c as arp-test and looking at the hardware address shows that the ethernet address returned by (get_ether_addr) is 0:0:0:0:0:0. dave adkins From owner-freebsd-current Thu Jan 22 00:28:24 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA25147 for current-outgoing; Thu, 22 Jan 1998 00:28:24 -0800 (PST) (envelope-from owner-freebsd-current) Received: from lsd.relcom.eu.net (ache@lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA25126; Thu, 22 Jan 1998 00:28:16 -0800 (PST) (envelope-from ache@lsd.relcom.eu.net) Received: (from ache@localhost) by lsd.relcom.eu.net (8.8.8/8.8.8) id LAA09785; Thu, 22 Jan 1998 11:28:07 +0300 (MSK) (envelope-from ache) Date: Thu, 22 Jan 1998 11:28:05 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net To: FreeBSD-current cc: committers@FreeBSD.ORG Subject: Re: Patch guidelines In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 21 Jan 1998, Андрей Чернов wrote: > After series of back outs, now use "patch -I" for CVS diffs to obtain full > compatibility with FreeBSD hacked "patch" and just "patch" for > compatibility with GNU "patch". There is new env. variable PATCH_INDEX_FIRST just added which do the same as -I option. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-current Thu Jan 22 05:00:25 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA10315 for current-outgoing; Thu, 22 Jan 1998 05:00:25 -0800 (PST) (envelope-from owner-freebsd-current) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA10310 for ; Thu, 22 Jan 1998 05:00:19 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id XAA10618; Thu, 22 Jan 1998 23:59:34 +1100 Date: Thu, 22 Jan 1998 23:59:34 +1100 From: Bruce Evans Message-Id: <199801221259.XAA10618@godzilla.zeta.org.au> To: adam@veda.is, freebsd-current@FreeBSD.ORG Subject: Re: if.h / in_var.h breakage? Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Attempting to run 'make buildworld' under -current on a RELENG_2_2 source tree, >I get the following errors. Where should this be fixed and how? > >Adam David > >cc -O2 -m486 -pipe -I/sys -c /usr1/2.2-stable/src/usr.bin/netstat/if.c >In file included from /usr1/2.2-stable/src/usr.bin/netstat/if.c:42: >/sys/net/if.h:69: field `ifi_lastchange' has incomplete type Removing the bogus -I option would be a good start. Bruce From owner-freebsd-current Thu Jan 22 06:27:45 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA16029 for current-outgoing; Thu, 22 Jan 1998 06:27:45 -0800 (PST) (envelope-from owner-freebsd-current) Received: from mhub3.tc.umn.edu (0@mhub3.tc.umn.edu [128.101.131.53]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA16021 for ; Thu, 22 Jan 1998 06:27:43 -0800 (PST) (envelope-from adkin003@tc.umn.edu) Received: from gold.tc.umn.edu by mhub3.tc.umn.edu; Thu, 22 Jan 98 08:27:41 -0600 Received: from pub-24-a-135.dialup.umn.edu by gold.tc.umn.edu; Thu, 22 Jan 98 08:27:41 -0600 Date: Thu, 22 Jan 1998 08:25:35 -0600 (CST) From: dave adkins X-Sender: adkin003@samthedog To: freebsd-current@FreeBSD.ORG Subject: ppp and proxy arp (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk hi, v1.22 and v1.23 of arp.c don't seem to publish the the ethernet address of the server correctly with proxy arp. The entry, always reads as incomplete. Going back to v1.21 of arp.c makes the problem go away. Running arp.c as arp-test and looking at the hardware address shows that the ethernet address returned by (get_ether_addr) is 0:0:0:0:0:0. dave adkins From owner-freebsd-current Thu Jan 22 10:03:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA06009 for current-outgoing; Thu, 22 Jan 1998 10:03:14 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA06002; Thu, 22 Jan 1998 10:02:52 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.8.8/8.8.5) id NAA21506; Thu, 22 Jan 1998 13:02:46 -0500 (EST) Date: Thu, 22 Jan 1998 13:02:46 -0500 (EST) From: Garrett Wollman Message-Id: <199801221802.NAA21506@khavrinen.lcs.mit.edu> To: John Dyson Cc: current@FreeBSD.ORG Subject: cvs commit: src/sys/i386/i386 machdep.c pmap.c vm_machdep.c src/sys/kern init_main.c kern_exit.c kern_fork.c kern_malloc.c kern_proc.c kern_subr.c sys_process.c vfs_bio.c vfs_subr.c src/sys/miscfs/procfs procfs_mem.c src/sys/sys buf.h proc.h ... In-Reply-To: <199801221730.JAA24559@freefall.freebsd.org> References: <199801221730.JAA24559@freefall.freebsd.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk < said: > 1) Start using TSM. Acronym expansion, please? -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 From owner-freebsd-current Thu Jan 22 10:14:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA07063 for current-outgoing; Thu, 22 Jan 1998 10:14:34 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA07044; Thu, 22 Jan 1998 10:14:21 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA09087; Thu, 22 Jan 1998 11:14:20 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA16836; Thu, 22 Jan 1998 11:14:13 -0700 Date: Thu, 22 Jan 1998 11:14:13 -0700 Message-Id: <199801221814.LAA16836@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Garrett Wollman Cc: John Dyson , current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/i386 machdep.c pmap.c vm_machdep.c src/sys/kern init_main.c kern_exit.c kern_fork.c kern_malloc.c kern_proc.c kern_subr.c sys_process.c vfs_bio.c vfs_subr.c src/sys/miscfs/procfs procfs_mem.c src/sys/sys buf.h proc.h ... In-Reply-To: <199801221802.NAA21506@khavrinen.lcs.mit.edu> References: <199801221730.JAA24559@freefall.freebsd.org> <199801221802.NAA21506@khavrinen.lcs.mit.edu> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk > < said: > > > 1) Start using TSM. > > Acronym expansion, please? Type Stable Memory, although I'm not sure what that means either. Do you have any pointers to documentation that might explain this? Nate From owner-freebsd-current Thu Jan 22 10:37:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA08773 for current-outgoing; Thu, 22 Jan 1998 10:37:08 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA08753; Thu, 22 Jan 1998 10:36:54 -0800 (PST) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199801221836.KAA08753@hub.freebsd.org> Subject: Re: cvs commit: src/sys/i386/i386 machdep.c pmap.c vm_machdep.c src/sys/kern init_main.c kern_exit.c kern_fork.c kern_ma In-Reply-To: <199801221814.LAA16836@mt.sri.com> from Nate Williams at "Jan 22, 98 11:14:13 am" To: nate@mt.sri.com (Nate Williams) Date: Thu, 22 Jan 1998 10:36:54 -0800 (PST) Cc: wollman@khavrinen.lcs.mit.edu, dyson@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk Nate Williams wrote: > > < said: > > > > > 1) Start using TSM. > > > > Acronym expansion, please? > > Type Stable Memory, although I'm not sure what that means either. Do > you have any pointers to documentation that might explain this? > i am guessing at http://Gregorio.Stanford.EDU:80/papers/non-blocking-osdi/ http://Gregorio.Stanford.EDU:80/MichaelGreenwald.html jmb From owner-freebsd-current Thu Jan 22 16:39:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06588 for current-outgoing; Thu, 22 Jan 1998 16:39:57 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06578; Thu, 22 Jan 1998 16:39:51 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id TAA00689; Thu, 22 Jan 1998 19:39:45 -0500 (EST) (envelope-from toor) Message-Id: <199801230039.TAA00689@dyson.iquest.net> Subject: Re: cvs commit: src/sys/i386/i386 machdep.c pmap.c vm_machdep.c src/sys/kern init_main.c kern_exit.c kern_fork.c kern_ma In-Reply-To: <199801221836.KAA08753@hub.freebsd.org> from "Jonathan M. Bresler" at "Jan 22, 98 10:36:54 am" To: jmb@FreeBSD.ORG (Jonathan M. Bresler) Date: Thu, 22 Jan 1998 19:39:45 -0500 (EST) Cc: nate@mt.sri.com, wollman@khavrinen.lcs.mit.edu, dyson@FreeBSD.ORG, current@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk Jonathan M. Bresler said: > Nate Williams wrote: > > > < said: > > > > > > > 1) Start using TSM. > > > > > > Acronym expansion, please? > > > > Type Stable Memory, although I'm not sure what that means either. Do > > you have any pointers to documentation that might explain this? > > > > i am guessing at > > http://Gregorio.Stanford.EDU:80/papers/non-blocking-osdi/ > http://Gregorio.Stanford.EDU:80/MichaelGreenwald.html > Good guess. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. From owner-freebsd-current Thu Jan 22 17:23:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10985 for current-outgoing; Thu, 22 Jan 1998 17:23:29 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smokies.binc.net (root@smokies.binc.net [205.173.176.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10967 for ; Thu, 22 Jan 1998 17:23:24 -0800 (PST) (envelope-from subcero@binc.net) Received: from liquid.binc.net (msn-x2-1-25.binc.net [205.173.178.232]) by smokies.binc.net (8.8.5/8.8.5) with SMTP id TAA19174 for ; Thu, 22 Jan 1998 19:23:18 -0600 Date: Thu, 22 Jan 1998 19:23:14 -0600 (CST) From: Andrew Bazan To: FreeBSD-Current@FreeBSD.ORG Subject: PS/2 Mouse Problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk Hi, I recently upgraded my system from 2.2.5-STABLE to 3.0-CURRENT -- did a complete harddrive flush (not really my choice) and reinstalled everything. Ever since I upgraded to -CURRENT, my PS/2 mouse has been giving me an immense amount of trouble. Basically, I don't usually run moused, and the first time I entered X and tried to move my mouse my harddrive made a bad crunching noise for a few seconds, and my mouse didn't move -- after awhile, I got a kernel error. I've CVSUP'd my sources, and I have the latest kernel as of about 3 this afternoon. I've had the problem with all the builds, and have no clue what's going on. I tried running moused to see if that would help anything, but it just crunched my harddrive when I moved the mouse and somehow (???) screwed up /proc so that I get a '/proc size mismatch' when I try to use a program that accesses it. I've tried all the easy solutions I can think of, and I'm wondering if this is a bug I haven't heard about in the kernel, or if it's just a new config issue I have to deal with. Thanks for your time, Andrew From owner-freebsd-current Thu Jan 22 17:35:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11830 for current-outgoing; Thu, 22 Jan 1998 17:35:35 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11820 for ; Thu, 22 Jan 1998 17:35:31 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.8.5/8.8.5) id TAA27091; Thu, 22 Jan 1998 19:35:14 -0600 (CST) From: Kevin Day Message-Id: <199801230135.TAA27091@home.dragondata.com> Subject: Re: PS/2 Mouse Problems In-Reply-To: from Andrew Bazan at "Jan 22, 98 07:23:14 pm" To: subcero@binc.net (Andrew Bazan) Date: Thu, 22 Jan 1998 19:35:13 -0600 (CST) Cc: FreeBSD-Current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk > Hi, > > I recently upgraded my system from 2.2.5-STABLE to 3.0-CURRENT -- did a > complete harddrive flush (not really my choice) and reinstalled > everything. Ever since I upgraded to -CURRENT, my PS/2 mouse has been > giving me an immense amount of trouble. Basically, I don't usually run > moused, and the first time I entered X and tried to move my mouse my > harddrive made a bad crunching noise for a few seconds, and my mouse > didn't move -- after awhile, I got a kernel error. > > I've CVSUP'd my sources, and I have the latest kernel as of about 3 this > afternoon. I've had the problem with all the builds, and have no clue > what's going on. I tried running moused to see if that would help > anything, but it just crunched my harddrive when I moved the mouse and > somehow (???) screwed up /proc so that I get a '/proc size mismatch' when > I try to use a program that accesses it. I've tried all the easy solutions > I can think of, and I'm wondering if this is a bug I haven't heard about > in the kernel, or if it's just a new config issue I have to deal with. > > Thanks for your time, > > Andrew > > You wouldn't happen to be sharing your PS/2 mouse port IRQ with something else, would you? Kevin From owner-freebsd-current Fri Jan 23 04:24:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA26365 for current-outgoing; Fri, 23 Jan 1998 04:24:48 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mhub3.tc.umn.edu (0@mhub3.tc.umn.edu [128.101.131.53]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id EAA26360 for ; Fri, 23 Jan 1998 04:24:46 -0800 (PST) (envelope-from adkin003@tc.umn.edu) Received: from pub-29-b-204.dialup.umn.edu by mhub3.tc.umn.edu; Fri, 23 Jan 98 06:24:44 -0600 Date: Fri, 23 Jan 1998 06:22:39 -0600 (CST) From: dave adkins X-Sender: adkin003@samthedog Reply-To: dave adkins To: freebsd-current@FreeBSD.ORG Subject: proxy arp and ppp-current Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk Hi, Excuse me if this is redundant. I sent it a few days ago and didn't see it show up on the current list. The univerity was having a little trouble with my e-mail host. v1.22 and v1.23 of arp.c don't seem to publish the the ethernet address of the server correctly with proxy arp. The entry, always reads as incomplete. Going back to v1.21 of arp.c makes the problem go away. Running arp.c as arp-test and looking at the hardware address shows that the ethernet address returned by (get_ether_addr) is 0:0:0:0:0:0. dave adkins From owner-freebsd-current Fri Jan 23 06:38:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA05319 for current-outgoing; Fri, 23 Jan 1998 06:38:06 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA05287 for ; Fri, 23 Jan 1998 06:37:56 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.7/8.8.7) with ESMTP id OAA07212; Fri, 23 Jan 1998 14:37:05 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199801231437.OAA07212@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: dave adkins cc: freebsd-current@FreeBSD.ORG Subject: Re: proxy arp and ppp-current In-reply-to: Your message of "Fri, 23 Jan 1998 06:22:39 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jan 1998 14:37:05 +0000 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk > > Hi, > > Excuse me if this is redundant. I sent it a few days ago and didn't see it > show up on the current list. The univerity was having a little trouble > with my e-mail host. > > v1.22 and v1.23 of arp.c don't seem to publish the the ethernet address of > the server correctly with proxy arp. The entry, always reads as > incomplete. Going back to v1.21 of arp.c makes the problem go away. > Running arp.c as arp-test and looking at the hardware address shows that > the ethernet address returned by (get_ether_addr) is 0:0:0:0:0:0. > > dave adkins Can you try version 1.24 (from Jan 21) :-) Cheers. -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Fri Jan 23 06:56:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA07883 for current-outgoing; Fri, 23 Jan 1998 06:56:02 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mhub2.tc.umn.edu (0@mhub2.tc.umn.edu [128.101.131.52]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA07861 for ; Fri, 23 Jan 1998 06:55:57 -0800 (PST) (envelope-from adkin003@tc.umn.edu) Received: from pub-25-a-187.dialup.umn.edu by mhub2.tc.umn.edu; Fri, 23 Jan 98 08:55:53 -0600 Date: Fri, 23 Jan 1998 08:53:47 -0600 (CST) From: dave adkins X-Sender: adkin003@samthedog To: Brian Somers cc: dave adkins , freebsd-current@FreeBSD.ORG Subject: Re: proxy arp and ppp-current In-Reply-To: <199801231437.OAA07212@awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk On Fri, 23 Jan 1998, Brian Somers wrote: > > Can you try version 1.24 (from Jan 21) :-) > tried it. Same behavior as v1.23. Can't seem to get the ether address for the proxy arp. dave adkins From owner-freebsd-current Fri Jan 23 13:25:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16157 for current-outgoing; Fri, 23 Jan 1998 13:25:46 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mailhost (user-38lcbaa.dialup.mindspring.com [209.86.45.74]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA16145 for ; Fri, 23 Jan 1998 13:25:43 -0800 (PST) (envelope-from rlb@mindspring.com) Received: from mindspring.com by mailhost with smtp (Smail3.1.29.1 #1) id m0xvqbe-000G5UC; Fri, 23 Jan 98 16:25 EST Message-ID: <34C90AD2.35D0F115@mindspring.com> Date: Fri, 23 Jan 1998 16:25:38 -0500 From: Ron Bolin X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.6 i86pc) MIME-Version: 1.0 To: FreeBSD Current Mailing List Subject: Current-3.0 bsd.ports.mk Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk In compiling say, "xperfmon++-1.40" from the ports Makefile I get the following error: rlb3:...sysutils/xperfmon>make ===> xperfmon++-1.40 : You have an old tcl installation on your machine. Remove everything that matches /usr/X11R6/*/*tcl* first. I have seen other ports give the same error since early January. What do I need to do to make this work? I even did as the messag reports rm -rf /usr/X11R6/*/*tcl* without success. BTW, I have tclsh8.0 installed. Thanks Ron -- ------------------------------------------------------------------------------- Ron Bolin, Sr. Software Eng, NetChannel Web: http://www.netchannel.net E-mail: rbolin@netchannel.net Web: http://www.gsu.edu/~gs01rlb Ph: 770-729-2929 Ext 249 Hm: 770-992-8877 Web: http://www.mindspring.com/~rlb ------------------------------------------------------------------------------- From owner-freebsd-current Fri Jan 23 14:25:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA22389 for current-outgoing; Fri, 23 Jan 1998 14:25:41 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA22377 for ; Fri, 23 Jan 1998 14:25:32 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.7/8.8.7) with ESMTP id VAA09303; Fri, 23 Jan 1998 21:48:02 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199801232148.VAA09303@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: dave adkins cc: Brian Somers , freebsd-current@FreeBSD.ORG Subject: Re: proxy arp and ppp-current In-reply-to: Your message of "Fri, 23 Jan 1998 08:53:47 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jan 1998 21:48:00 +0000 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk > > > On Fri, 23 Jan 1998, Brian Somers wrote: > > > > > Can you try version 1.24 (from Jan 21) :-) > > > > tried it. Same behavior as v1.23. Can't seem to get the ether address for > the proxy arp. Ok. Version 1.25 does work - it even does alias addresses :-) I'd appreciate if you could check it out (980123 archive). > dave adkins Thanks. -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Fri Jan 23 14:39:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23886 for current-outgoing; Fri, 23 Jan 1998 14:39:10 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from blackhole.iceworld.org (griffin@blackhole.iceworld.org [204.246.64.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23880 for ; Fri, 23 Jan 1998 14:39:07 -0800 (PST) (envelope-from griffin@blackhole.iceworld.org) Received: from localhost (griffin@localhost) by blackhole.iceworld.org (8.8.8/8.8.7) with SMTP id QAA07270 for ; Fri, 23 Jan 1998 16:42:09 -0600 Date: Fri, 23 Jan 1998 16:42:09 -0600 (CST) From: Jimbo Bahooli To: freebsd-current@FreeBSD.ORG Subject: Status of Advansys Scsi Driver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk I was just wondering the status of the Advansys SCSI driver in -current. The driver code seems to be there, but it is not mentioned in LINT and I remember hearing something about that it relied on the new SCSI code that is not integrated. - From owner-freebsd-current Fri Jan 23 21:59:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07432 for current-outgoing; Fri, 23 Jan 1998 21:59:02 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA07420 for ; Fri, 23 Jan 1998 21:58:28 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 16367 invoked by uid 1000); 24 Jan 1998 06:05:17 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-011998 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <34C90AD2.35D0F115@mindspring.com> Date: Fri, 23 Jan 1998 22:05:17 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Ron Bolin Subject: RE: Current-3.0 bsd.ports.mk Question Cc: FreeBSD Current Mailing List Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk On 23-Jan-98 Ron Bolin wrote: > In compiling say, "xperfmon++-1.40" from the ports Makefile I get the > following error: > > > rlb3:...sysutils/xperfmon>make > ===> xperfmon++-1.40 : You have an old tcl installation on your > machine. Remove everything that matches /usr/X11R6/*/*tcl* first. > > I have seen other ports give the same error since early January. What do > I need to do > to make this work? I even did as the messag reports rm -rf > /usr/X11R6/*/*tcl* > without success. BTW, I have tclsh8.0 installed. Check /usr/share/mk/bsd.port*. I forget which one looks for what, but there are only two files it actually is looking for. Rename them (in case you need them) and all will be well. BTW, This is NOT the original intent of the change, just a workaround to get you going... > > Thanks > > Ron > > > -- > -------------------------------------------------------------------------- > ----- > Ron Bolin, Sr. Software Eng, NetChannel Web: > http://www.netchannel.net > E-mail: rbolin@netchannel.net Web: > http://www.gsu.edu/~gs01rlb > Ph: 770-729-2929 Ext 249 Hm: 770-992-8877 Web: > http://www.mindspring.com/~rlb > -------------------------------------------------------------------------- > ----- > > > ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 From owner-freebsd-current Fri Jan 23 22:19:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA08921 for current-outgoing; Fri, 23 Jan 1998 22:19:48 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mhub3.tc.umn.edu (0@mhub3.tc.umn.edu [128.101.131.53]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA08913 for ; Fri, 23 Jan 1998 22:19:45 -0800 (PST) (envelope-from adkin003@tc.umn.edu) Received: from mhub1.tc.umn.edu by mhub3.tc.umn.edu; Fri, 23 Jan 98 22:19:43 -0600 Received: from pub-26-c-166.dialup.umn.edu by mhub1.tc.umn.edu; Fri, 23 Jan 98 22:19:42 -0600 Date: Fri, 23 Jan 1998 22:17:37 -0600 (CST) From: dave adkins X-Sender: adkin003@samthedog To: Brian Somers cc: dave adkins , freebsd-current@FreeBSD.ORG Subject: Re: proxy arp and ppp-current In-Reply-To: <199801232148.VAA09303@awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk On Fri, 23 Jan 1998, Brian Somers wrote: > > Ok. Version 1.25 does work - it even does alias addresses :-) I'd > appreciate if you could check it out (980123 archive). > > > dave adkins I tried v1.27 as of 10:16 pm CST 980123. It works fine. Thanks dave adkins From owner-freebsd-current Fri Jan 23 23:25:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA14336 for current-outgoing; Fri, 23 Jan 1998 23:25:12 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from top.worldcontrol.com (tc1-dialin39.nanospace.com [205.199.198.239]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA14331 for ; Fri, 23 Jan 1998 23:25:09 -0800 (PST) (envelope-from brian@worldcontrol.com) From: brian@worldcontrol.com Received: (qmail 662 invoked by uid 100); 24 Jan 1998 07:19:53 -0000 Message-ID: <19980123231945.59378@top.worldcontrol.com> Date: Fri, 23 Jan 1998 23:19:45 -0800 To: freebsd-current@FreeBSD.ORG Subject: ppp (iij) doesn't recognize carrier loss anymore Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88.13i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk I upgraded from 2.2.5 to -current on Jan 17th. User mode PPP no longer recognizes when my ISP has diconnected due to a timeout. My guess is that CD is not propogating up to ppp. Basically, I find my system sitting with tun0 up, and the IPs set for remote and local and the routing up. However, the modem is offline and CD is down due to the ISP handing up. PPP is just sitting their figuring everything is up. I have to kill it and restart it to get online again. I have never used /etc/rc.serial before, however, I changed it to set port 1 to modem which did not help. I'm also guessing that I could turn on LQR, however, I have losing a connection just because things are going slow. What then has happened. Is there something somewhere I need to config? -- brian From owner-freebsd-current Sat Jan 24 00:17:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA18413 for current-outgoing; Sat, 24 Jan 1998 00:17:15 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA18408 for ; Sat, 24 Jan 1998 00:17:14 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id AAA17110; Sat, 24 Jan 1998 00:01:34 -0700 (MST) Date: Sat, 24 Jan 1998 00:01:34 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199801240701.AAA17110@narnia.plutotech.com> To: Jimbo Bahooli cc: current@FreeBSD.ORG Subject: Re: Status of Advansys Scsi Driver Newsgroups: pluto.freebsd.current In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk In article you wrote: > > I was just wondering the status of the Advansys SCSI driver in > -current. The driver code seems to be there, but it is not mentioned in > LINT and I remember hearing something about that it relied on the new SCSI > code that is not integrated. It is only supported in the CAM SCSI layer. You can find information about CAM at ftp://ftp.FreeBSD.org/pub/FreeBSD/cam. You may also want to search the SCSI list archives at www.FreeBSD.org for past postings about CAM. -- Justin From owner-freebsd-current Sat Jan 24 05:43:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA11510 for current-outgoing; Sat, 24 Jan 1998 05:43:37 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from awfulhak.org (awfulhak.demon.co.uk [158.152.17.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA11504 for ; Sat, 24 Jan 1998 05:43:34 -0800 (PST) (envelope-from brian@Awfulhak.org) Received: from gate.lan.awfulhak.org (localhost [127.0.0.1]) by awfulhak.org (8.8.7/8.8.7) with ESMTP id NAA19647; Sat, 24 Jan 1998 13:38:59 GMT (envelope-from brian@gate.lan.awfulhak.org) Message-Id: <199801241338.NAA19647@awfulhak.org> X-Mailer: exmh version 2.0.1 12/23/97 To: brian@worldcontrol.com cc: freebsd-current@FreeBSD.ORG Subject: Re: ppp (iij) doesn't recognize carrier loss anymore In-reply-to: Your message of "Fri, 23 Jan 1998 23:19:45 PST." <19980123231945.59378@top.worldcontrol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 24 Jan 1998 13:38:59 +0000 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk > I upgraded from 2.2.5 to -current on Jan 17th. > > User mode PPP no longer recognizes when my ISP has diconnected due > to a timeout. My guess is that CD is not propogating up to ppp. > > Basically, I find my system sitting with tun0 up, and the IPs > set for remote and local and the routing up. However, the > modem is offline and CD is down due to the ISP handing up. > > PPP is just sitting their figuring everything is up. I have to > kill it and restart it to get online again. > > I have never used /etc/rc.serial before, however, I changed it > to set port 1 to modem which did not help. > > I'm also guessing that I could turn on LQR, however, I have > losing a connection just because things are going slow. > > What then has happened. Is there something somewhere I need > to config? Check out the FAQ on http://www.FreeBSD.org/FAQ/userppp.html. I haven't heard of any other problems with the current ppp in that area (but there *were* such problems in 2.2.5). Can you supply some diagnostics (some pointers on this are given in the FAQ). The `debug' level will tell you the online/offline status (CD detection) of ppp. Once it goes offline, ppp should terminate. Also, how are you starting ppp ? > -- > brian -- Brian , , Don't _EVER_ lose your sense of humour.... From owner-freebsd-current Sat Jan 24 11:51:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA07477 for current-outgoing; Sat, 24 Jan 1998 11:51:38 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from unix.tfs.net (as1-p155.tfs.net [139.146.210.155]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA07469 for ; Sat, 24 Jan 1998 11:51:34 -0800 (PST) (envelope-from jbryant@unix.tfs.net) Received: (from jbryant@localhost) by unix.tfs.net (8.8.8/8.8.5) id NAA14274 for freebsd-current@freebsd.org; Sat, 24 Jan 1998 13:51:28 -0600 (CST) From: Jim Bryant Message-Id: <199801241951.NAA14274@unix.tfs.net> Subject: apm on toshiba To: freebsd-current@FreeBSD.ORG Date: Sat, 24 Jan 1998 13:51:27 -0600 (CST) Reply-to: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Operating-System: FreeBSD 3.0-CURRENT #0: Thu Jan 1 19:03:58 CST 1998 X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk i just got a toshiba laptop [portege 660cdt] from work, and am planning to run -current... has anything been done with the apm on these to support dim backlighting, and disk spindown? the Li-ion packs last a while, but i would really like to strech it as far as possible... has anyone had any experience with these laptops? any pointers? anything to avoid? also, is the sound driver code supported on these? jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-current Sat Jan 24 12:33:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10896 for current-outgoing; Sat, 24 Jan 1998 12:33:50 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from unix.tfs.net (as1-p155.tfs.net [139.146.210.155]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10886 for ; Sat, 24 Jan 1998 12:33:45 -0800 (PST) (envelope-from jbryant@unix.tfs.net) Received: (from jbryant@localhost) by unix.tfs.net (8.8.8/8.8.5) id OAA14333 for freebsd-current@freebsd.org; Sat, 24 Jan 1998 14:33:42 -0600 (CST) From: Jim Bryant Message-Id: <199801242033.OAA14333@unix.tfs.net> Subject: Non-Delivery Report (fwd) To: freebsd-current@FreeBSD.ORG Date: Sat, 24 Jan 1998 14:33:41 -0600 (CST) Reply-to: jbryant@unix.tfs.net X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# X-files: The truth is that the X-Files is fiction X-Operating-System: FreeBSD 3.0-CURRENT #0: Thu Jan 1 19:03:58 CST 1998 X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk please remove peterh@rih.org from the -current mailing list... every time i send mail to -current, i get one of these... this has been happening since late last year... -jim ----- Forwarded message from Postmaster ----- >From POPmail Sat Jan 24 14:02:04 1998 >Message-Id: <199801241957.NAA14898@unix.tfs.net> >From: "Postmaster" >To: >Date: Sat, 24 Jan 1998 15:00:00 -0500 >Subject: Non-Delivery Report >X-UIDL: 656a0f9a9b9194683dd2d95b1739222d Could not deliver message (ID=33214). Local account 'peterh' is unknown. The first portion of the original message text follows: ------------------------------------------------------- >Received: from hub.freebsd.org by mail.rih.org (AppleShare IP Mail Server 5.0.3) id 33214 via TCP with SMTP; Sat, 24 Jan 1998 15:00:00 -0500 >Received: from localhost (daemon@localhost) > by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA07492; > Sat, 24 Jan 1998 11:51:39 -0800 (PST) > (envelope-from owner-freebsd-current) >Received: by hub.freebsd.org (bulk_mailer v1.6); Sat, 24 Jan 1998 11:51:38 -0800 >Received: (from majordom@localhost) > by hub.freebsd.org (8.8.8/8.8.8) id LAA07477 > for current-outgoing; Sat, 24 Jan 1998 11:51:38 -0800 (PST) > (envelope-from owner-freebsd-current@FreeBSD.ORG) >Received: from unix.tfs.net (as1-p155.tfs.net [139.146.210.155]) > by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA07469 > for ; Sat, 24 Jan 1998 11:51:34 -0800 (PST) > (envelope-from jbryant@unix.tfs.net) >Received: (from jbryant@localhost) > by unix.tfs.net (8.8.8/8.8.5) id NAA14274 > for freebsd-current@freebsd.org; Sat, 24 Jan 1998 13:51:28 -0600 (CST) >From: Jim Bryant >Message-Id: <199801241951.NAA14274@unix.tfs.net> >Subject: apm on toshiba >To: freebsd-current@FreeBSD.ORG >Date: Sat, 24 Jan 1998 13:51:27 -0600 (CST) >Reply-to: jbryant@unix.tfs.net >X-Windows: R00LZ!@# MS-Winbl0wz DR00LZ!@# >X-files: The truth is that the X-Files is fiction >X-Operating-System: FreeBSD 3.0-CURRENT #0: Thu Jan 1 19:03:58 CST 1998 >X-Mailer: ELM [version 2.4ME+ PL32 (25)] >MIME-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Sender: owner-freebsd-current@FreeBSD.ORG i just got a toshiba laptop [portege 660cdt] from work, and am planning to run -current... has anything been done with the apm on these to support dim backlighting, and disk spindown? the Li-ion packs last a while, but i would really like to strech it as far as possible... has anyone had any experience with these laptops? any pointers? anything to avoid? also, is the sound driver code supported on these? jim -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ ----- End of forwarded message from Postmaster ----- -- All opinions expressed are mine, if you | "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" ------------------------------------------------------------------------------ Inet: jbryant@tfs.net AX.25: kc5vdj@wv0t.#neks.ks.usa.noam grid: EM28pw voice: KC5VDJ - 6 & 2 Meters AM/FM/SSB, 70cm FM. http://www.tfs.net/~jbryant ------------------------------------------------------------------------------ HF/6M/2M: IC-706-MkII, 2M: HTX-212, 2M: HTX-202, 70cm: HTX-404, Packet: KPC-3+ From owner-freebsd-current Sat Jan 24 18:00:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA02125 for current-outgoing; Sat, 24 Jan 1998 18:00:21 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from abby.skypoint.net (abby.skypoint.net [199.86.32.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA02120 for ; Sat, 24 Jan 1998 18:00:18 -0800 (PST) (envelope-from bruce@zuhause.mn.org) Received: (from uucp@localhost) by abby.skypoint.net (8.8.7/jl 1.3) with UUCP id UAA16411 for freebsd-current@freebsd.org; Sat, 24 Jan 1998 20:00:17 -0600 (CST) Received: (from bruce@localhost) by zuhause.mn.org (8.8.7/8.8.7) id TAA27057; Sat, 24 Jan 1998 19:57:00 -0600 (CST) Date: Sat, 24 Jan 1998 19:57:00 -0600 (CST) Message-Id: <199801250157.TAA27057@zuhause.mn.org> From: Bruce Albrecht To: freebsd-current@FreeBSD.ORG Subject: Last stable -current? X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk What's the last stable -current? Is it really 97.12.23, as Chris Timmons suggested in an email on January 15th? From owner-freebsd-current Sat Jan 24 18:37:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA04000 for current-outgoing; Sat, 24 Jan 1998 18:37:09 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.133.7.178]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03994 for ; Sat, 24 Jan 1998 18:37:07 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id SAA18798; Sat, 24 Jan 1998 18:36:57 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199801250236.SAA18798@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Bruce Albrecht cc: freebsd-current@FreeBSD.ORG Subject: Re: Last stable -current? In-reply-to: Your message of "Sat, 24 Jan 1998 19:57:00 CST." <199801250157.TAA27057@zuhause.mn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 24 Jan 1998 18:36:56 -0800 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk Yeap Amancio From owner-freebsd-current Sat Jan 24 20:32:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA11772 for current-outgoing; Sat, 24 Jan 1998 20:32:16 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from casa.plan.pixelogix.com (casagate.plan.pixelogix.com [206.129.249.118]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA11767 for ; Sat, 24 Jan 1998 20:32:13 -0800 (PST) (envelope-from phils@casagate.plan.pixelogix.com) Received: from casa.plan.pixelogix.com (localhost [127.0.0.1]) by casa.plan.pixelogix.com (8.8.8/8.8.5) with SMTP id UAA13808 for ; Sat, 24 Jan 1998 20:30:51 -0800 (PST) Message-ID: <34CABFFA.41C67EA6@casagate.plan.pixelogix.com> Date: Sat, 24 Jan 1998 20:30:50 -0800 From: Phil Staub X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-STABLE i386) MIME-Version: 1.0 To: freebsd-current@FreeBSD.ORG Subject: Re: ppp (iij) doesn't recognize carrier loss anymore References: <199801241338.NAA19647@awfulhak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk Brian Somers wrote: [brian@worldcontrol.com's description of non-hangup problems deleted] > > Check out the FAQ on http://www.FreeBSD.org/FAQ/userppp.html. I > haven't heard of any other problems with the current ppp in that > area (but there *were* such problems in 2.2.5). Can you point me to a paragraph in the FAQ or other reference to the problems you alluded to in 2.2.5? I just brought up a ppp server whose ppp session won't die if the user at the client machine kills (i.e., via kill -9) *his* end of the session. Once this has happened, further attempts to dial in fail (the modem never answers) and the ppp process must be manually killed. However, if the idle timeout expires and the connection shuts down that way, the next dial works just fine. In this case, I'm not sure whether the ppp process itself shuts down or not. I'm sure another piece you'll need to know is that I am using mgetty, with the setup instructions essentially copied from the online (at freebsd.org) manual. I've looked in what seemed to be the obvious places (FAQ's, Manual, Man pages) and haven't seen reference to this problem. Can you help? > > Can you supply some diagnostics (some pointers on this are given > in the FAQ). The `debug' level will tell you the online/offline > status (CD detection) of ppp. Once it goes offline, ppp should > terminate. I haven't got this handy, but I'll work on it. > > -- > > brian > > -- > Brian , , > > Don't _EVER_ lose your sense of humour.... -- Phil Staub, KE7HC Senior Software Engineer phils@pixelogix.com Audio Precision, Inc. or phils@audioprecision.com Beaverton, OR 97075, (800) 231-7350