From owner-freebsd-current Sun Jul 18 4:57: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from fep9.mail.ozemail.net (fep9.mail.ozemail.net [203.2.192.103]) by hub.freebsd.org (Postfix) with ESMTP id 76C4D14D52; Sun, 18 Jul 1999 04:56:53 -0700 (PDT) (envelope-from c9710216@atlas.newcastle.edu.au) Received: from atlas.newcastle.edu.au (slnew52p34.ozemail.com.au [203.108.150.112]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id VAA19798; Sun, 18 Jul 1999 21:54:56 +1000 (EST) Message-ID: <3791BFE4.D18901D3@atlas.newcastle.edu.au> Date: Sun, 18 Jul 1999 21:52:04 +1000 From: obituary X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Problem with cvsup Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been having some trouble with cvsup of late, and unfortunately I'm at a complete loss as to what may be causing it. There are two machines here that I've tried to update. My personal machine runs 4.0-CURRENT and the network firewall that runs 3.2-RELEASE. The cvsup program establishes a connection with a server properly, and everything is fine up until the "Running" phase. It's at this point where the transfer rate falls through the floor. Data is only transferred in short bursts of, say, 5k at a time, once every 10-15 seconds. After about 3 minutes of this behaviour the connection goes completely idle and eventually times out with the error: TreeList failed: Network write failure: Connection timed out The strange thing is that this problem only occurs when I'm using FreeBSD on my firewall box. I initially thought that my firewall rule set could be to blame, so I flushed all the rules and set the default policy to pass all packets. I then tried to cvsup the 3.2-RELEASE box using a direct modem connection to the net (no natd/firewall in the road), but still no luck. The last successful cvsup I did was about a month and a half ago, and at that time the firewall box was a linux machine using IP masquerading. I'd kept the harddrive with the linux setup around "just in case" so I swapped the harddrives, booted linux, and tried a cvsup from my 4.0-CURRENT machine (using linux as the firewall). It worked flawlessly -- and now I'm *really* confused. The FreeBSD 3.2-RELEASE firewall box has worked perfectly for everything I've used it for (web browsing, ftp, mail, news, etc.) and yet it stumbles over cvsup connections?? If anyone can shed some light on my situation (or has experienced similar troubles themselves) I'd be most grateful to hear from you. -jake (obituary) Powered by FreeBSD c9710216@atlas.newcastle.edu.au http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 6: 8:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A8C1914C58; Sun, 18 Jul 1999 06:08:22 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id PAA46915; Sun, 18 Jul 1999 15:07:25 +0200 (CEST) (envelope-from des) To: obituary Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: <3791BFE4.D18901D3@atlas.newcastle.edu.au> From: Dag-Erling Smorgrav Date: 18 Jul 1999 15:07:24 +0200 In-Reply-To: obituary's message of "Sun, 18 Jul 1999 21:52:04 +1000" Message-ID: Lines: 9 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG obituary writes: > If anyone can shed some light on my situation (or has experienced > similar troubles themselves) I'd be most grateful to hear from you. You forgot to attach the output of 'ipfw -a l'. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 9: 3:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from blues.jpj.net (blues.jpj.net [204.97.17.146]) by hub.freebsd.org (Postfix) with ESMTP id 0643814C1D for ; Sun, 18 Jul 1999 09:03:46 -0700 (PDT) (envelope-from trevor@jpj.net) Received: from localhost (trevor@localhost) by blues.jpj.net (right/backatcha) with SMTP id MAA20743; Sun, 18 Jul 1999 12:02:59 -0400 (EDT) Date: Sun, 18 Jul 1999 12:02:59 -0400 (EDT) From: Trevor Johnson To: Thomas Schuerger Cc: freebsd-current@FreeBSD.ORG Subject: Re: ata delay In-Reply-To: <199907171829.UAA18073@wjpserver.cs.uni-sb.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi! Hi, Thomas. > I switched to the ata IDE driver some time ago. Since then, booting > stops for about 30 seconds when the driver is installed. It didn't > happen when using the old wd driver. In /usr/src/sys/i386/conf/LINT it says: # This option allow you to override the default probe time for IDE # devices, to get a faster probe. Setting this below 10000 violate # the IDE specs, but may still work for you (it will work for most # people). # options IDE_DELAY=8000 # Be optimistic about Joe IDE device __ Trevor Johnson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 10:49:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from ozz.etrust.ru (ozz.etrust.ru [195.2.84.116]) by hub.freebsd.org (Postfix) with ESMTP id 13F2114E5A for ; Sun, 18 Jul 1999 10:48:59 -0700 (PDT) (envelope-from osa@etrust.ru) Received: from localhost (localhost [127.0.0.1]) by ozz.etrust.ru (Postfix) with ESMTP id 7134D21B for ; Sun, 18 Jul 1999 21:48:55 +0400 (MSD) Date: Sun, 18 Jul 1999 21:48:55 +0400 (MSD) From: Osokin Sergey To: current@FreeBSD.org Subject: Some problems with atapi-drivers under -current... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! I try to use new atapi-drivers under -current & have some problems. at kernel: controller ata0 device atadisk0 device atapicd0 device atapifd0 I have following devices: IDE0: HDD UDMA (master) IDE1: CD-ROM (master) IDE1: LS-120 (slave) Kernel can't detect my LS-120, it says: .... Jul 18 19:15:39 ozz /kernel: ata-pci0: at device 7.1 on pci0 Jul 18 19:15:39 ozz /kernel: ata-pci0: Busmastering DMA supported Jul 18 19:15:39 ozz /kernel: ata0 at 0x01f0 irq 14 on ata-pci0 Jul 18 19:15:39 ozz /kernel: ata1 at 0x0170 irq 15 on ata-pci0 ........ Jul 18 19:15:40 ozz /kernel: ata1: unwanted interrupt 1 status = 00 ........ Jul 18 19:15:40 ozz /kernel: ata0: master: setting up WDMA2 mode on PIIX3/4 chip OK Jul 18 19:15:40 ozz /kernel: ad0: ATA-3 disk at ata0 as master Jul 18 19:15:40 ozz /kernel: ad0: 2503MB (5126688 sectors), 5086 cyls, 16 heads, 63 S/T, 512 B/S Jul 18 19:15:40 ozz /kernel: ad0: piomode=4, dmamode=2, udmamode=-1 Jul 18 19:15:40 ozz /kernel: ad0: 16 secs/int, 0 depth queue, DMA mode Jul 18 19:15:40 ozz /kernel: acd0: CDROM drive at ata1 as master Jul 18 19:15:40 ozz /kernel: acd0: drive speed 171 - 8250KB/sec, 128KB cache Jul 18 19:15:40 ozz /kernel: acd0: supported read types: CD-R, CD-RW, CD-DA, packet track Jul 18 19:15:40 ozz /kernel: acd0: Audio: play, 255 volume levels Jul 18 19:15:40 ozz /kernel: acd0: Mechanism: ejectable tray Jul 18 19:15:40 ozz /kernel: acd0: Medium: no/blank disc inside, unlocked Jul 18 19:15:40 ozz /kernel: changing root device to wd0s1a & nothing about LS-120... Old drivers (aka wdcX, wcd0 & wfd0) detect all devices & work correct. And another problem: if i use kernel with atapicd0, wcdplay play one track from CD & stop. If i use wcd0, wcdplay play all tracks. Any idea? Rgdz, ïÓÏËÉÎ óÅÒÇÅÊ aka oZZ, osa@etrust.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 12:48:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from gaia.euronet.nl (gaia.euronet.nl [194.134.0.10]) by hub.freebsd.org (Postfix) with ESMTP id B241814EC4 for ; Sun, 18 Jul 1999 12:48:17 -0700 (PDT) (envelope-from freebsd-current@scc.nl) Received: from scones.sup.scc.nl (i055.ztm.euronet.nl [194.134.112.56]) by gaia.euronet.nl (8.8.8/8.8.8) with ESMTP id VAA18009 from for ; Sun, 18 Jul 1999 21:47:38 +0200 (MET DST) Received: (from daemon@localhost) by scones.sup.scc.nl (8.9.3/8.9.3) id VAA23062 for current@FreeBSD.ORG; Sun, 18 Jul 1999 21:30:10 +0200 (CEST) (envelope-from freebsd-current@scc.nl) Received: from GATEWAY by scones.sup.scc.nl with netnews for current@FreeBSD.ORG (current@FreeBSD.ORG) To: current@FreeBSD.ORG Date: Sun, 18 Jul 1999 21:30:07 +0200 From: Marcel Moolenaar Message-ID: <37922B3F.2EA6EE@scc.nl> Organization: SCC vof Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <10556.932242843@critter.freebsd.dk> Subject: Re: please test (linux emulation) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: > > I have no idea how to excercise this piece of code, if somebody > could verify that it still DTRT I would be most grateful. [piece of code snipped] If nobody replies, then I'll run the code with verification (eg the original code) until I know it has been used. If the new code behaves differently than the original code, It will show. That's the best thing I can do right now. -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ Amsterdam, The Netherlands tel: +31 20 4200655 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 12:51:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from arrakis.pcarts.tarnow.pl (boruta.pcarts.tarnow.pl [195.205.11.2]) by hub.freebsd.org (Postfix) with ESMTP id B330814F5B for ; Sun, 18 Jul 1999 12:51:47 -0700 (PDT) (envelope-from adam@pcarts.tarnow.pl) Received: from Detal2 ([195.205.11.41]) by arrakis.pcarts.tarnow.pl (8.8.7/8.8.7) with SMTP id VAA22727 for ; Sat, 17 Jul 1999 21:54:39 +0200 (CEST) Received: by localhost with Microsoft MAPI; Sun, 18 Jul 1999 21:51:55 +0200 Message-ID: <01BED167.C0AF4060.adam@pcarts.tarnow.pl> From: Adam Smaza To: "'freebsd-current@freebsd.org'" Subject: ftp current.freebsd.org Date: Sun, 18 Jul 1999 21:51:54 +0200 X-Mailer: Microsoft Internet e-mail/MAPI - 8.0.0.4211 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 Why can I access current.freebsd.org ? All connections are refused. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 12:58:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id 3B1AB14C3C for ; Sun, 18 Jul 1999 12:58:18 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from altavista.net (dialup4-3.iptelecom.net.ua [212.42.68.98]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id XAA06236 for ; Sun, 18 Jul 1999 23:02:35 +0300 (EEST) Message-ID: <37922F31.103A6A37@altavista.net> Date: Sun, 18 Jul 1999 22:46:57 +0300 From: Maxim Sobolev X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: Question about MTRR on AMD chips Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anybody can clarify starting from which model/revisions MTRR is supported on k6 family chips, because in the list archives I found that it supported starting from k6-II, but when I'm trying to configure it using memcontrol on my k6-II (rev. 0) I'm only get a varionus error massages. Sincerely, Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 12:58:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id 9ACD314C9C for ; Sun, 18 Jul 1999 12:58:22 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from altavista.net (dialup4-3.iptelecom.net.ua [212.42.68.98]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id XAA06240 for ; Sun, 18 Jul 1999 23:02:38 +0300 (EEST) Message-ID: <379231DA.CF6721EB@altavista.net> Date: Sun, 18 Jul 1999 22:58:18 +0300 From: Maxim Sobolev X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: PLIP is still broken :( Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anybody have a plans to fix plip code which is broken a quite awhile (several months or so)? I could send several panic backtraces if anyone will express interest in it. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 13:39:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from kali.brainlink.com (kali.brainlink.com [206.127.58.27]) by hub.freebsd.org (Postfix) with ESMTP id 5EDCF14C58; Sun, 18 Jul 1999 13:39:23 -0700 (PDT) (envelope-from tugrul@brainlink.com) Received: from buddha.brainlink.com (cerebrus.brainlink.com [206.127.58.24]) by kali.brainlink.com (Post.Office MTA v3.5.2 release 221 ID# 0-52824U2500L250S0V35) with ESMTP id com; Sun, 18 Jul 1999 16:36:20 -0400 Received: by buddha.brainlink.com (Postfix, from userid 1000) id DA8A877; Sun, 18 Jul 1999 16:37:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by buddha.brainlink.com (Postfix) with ESMTP id BB1179; Sun, 18 Jul 1999 16:37:24 -0400 (EDT) Date: Sun, 18 Jul 1999 16:37:24 -0400 (EDT) From: Tugrul Galatali To: obituary Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18 Jul 1999, Dag-Erling Smorgrav wrote: > obituary writes: > > If anyone can shed some light on my situation (or has experienced > > similar troubles themselves) I'd be most grateful to hear from you. > > You forgot to attach the output of 'ipfw -a l'. > The exact cvsup command would also be nice I think. Are you using "-P m" as the FAQ hints at if you are behind a firewall? > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 18:37:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from nakaji.tutrp.tut.ac.jp (nakaji.tutrp.tut.ac.jp [133.15.188.118]) by hub.freebsd.org (Postfix) with ESMTP id 0FE8D14A09 for ; Sun, 18 Jul 1999 18:37:10 -0700 (PDT) (envelope-from nakaji@tutrp.tut.ac.jp) Received: from localhost (localhost.tutrp.tut.ac.jp [127.0.0.1]) by nakaji.tutrp.tut.ac.jp (8.9.3/3.7W) with ESMTP id KAA00949 for ; Mon, 19 Jul 1999 10:34:29 +0900 (JST) From: nakaji@tutrp.tut.ac.jp To: current@FreeBSD.ORG Subject: make buildworld -DWANT_AOUT -DCOMPAT3X fails on 4.0-current X-Mailer: Mew version 1.94b39 on XEmacs 21.2 (Toshima) X-Prom-Mew: Prom-Mew 1.93.2 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990719103428M.nakaji@tutrp.tut.ac.jp> Date: Mon, 19 Jul 1999 10:34:28 +0900 X-Dispatcher: imput version 990623(IM117) Lines: 22 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I got this error on last Friday in Japan. The last part of log is following. --->8--->8--->8--->8--->8--->8--->8--- ===> compat/compat3x install -c -o root -g wheel -m 444 libf2c.so.2 libg++.so.4 libstdc++.so.2 /usr/obj/aout/usr/src/tmp/usr/lib/aout/compat usage: install [-CcDps] [-f flags] [-g group] [-m mode] [-o owner] file1 file2 install [-CcDps] [-f flags] [-g group] [-m mode] [-o owner] file1 ... fileN directory install -d [-g group] [-m mode] [-o owner] directory ... *** Error code 64 Stop. (snip) Fri Jul 16 15:21:48 JST 1999 --->8--->8--->8--->8--->8--->8--->8--- The log is made by the command, (date; make buildworld; date) 2>&1 | tee -a make.bw.$(date "+%y%m%d") --- NAKAJI Hiroyuki To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 19:29:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 0D14B1506B for ; Sun, 18 Jul 1999 19:29:47 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-1-17.ucdavis.edu [169.237.16.17]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id TAA17945; Sun, 18 Jul 1999 19:29:35 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id TAA98777; Sun, 18 Jul 1999 19:29:32 -0700 (PDT) (envelope-from obrien) Date: Sun, 18 Jul 1999 19:29:27 -0700 From: "David O'Brien" To: Maxim Sobolev Cc: current@freebsd.org Subject: Re: PLIP is still broken :( Message-ID: <19990718192927.A98757@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <379231DA.CF6721EB@altavista.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <379231DA.CF6721EB@altavista.net>; from Maxim Sobolev on Sun, Jul 18, 1999 at 10:58:18PM +0300 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Does anybody have a plans to fix plip code which is broken a quite > awhile (several months or so)? Since I used it just last week on two -CURRENT boxes, I'd say there is some other problem you are experecing. -- -- David (obrien@NUXI.com -or- 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 Sun Jul 18 19:51:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id 9D28514D2A for ; Sun, 18 Jul 1999 19:51:32 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from altavista.net (dialup2-21.iptelecom.net.ua [212.42.68.212]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id FAA22831; Mon, 19 Jul 1999 05:56:52 +0300 (EEST) Message-ID: <3792935D.D681007E@altavista.net> Date: Mon, 19 Jul 1999 05:54:21 +0300 From: Maxim Sobolev X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: obrien@NUXI.com Cc: current@FreeBSD.ORG Subject: Re: PLIP is still broken :( References: <379231DA.CF6721EB@altavista.net> <19990718192927.A98757@dragon.nuxi.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David O'Brien wrote: > > Does anybody have a plans to fix plip code which is broken a quite > > awhile (several months or so)? > > Since I used it just last week on two -CURRENT boxes, I'd say there is > some other problem you are experecing. I'm also using two -current boxes (P133 and K6-2/300) and when trying to do more or less massive file transfer one of the boxes dying with panic (usually one with a slower processor, but not alvays). Changing ppc flags also doesn't resolve a problem. If you can please try to test it by doing "ping -f -s 8000 other_side" - this test actually bring one side to its knees it several seconds (at lease for me). Some time ago I had rised this question and Bruce Evans told that this problem arise because of switch to newbus. Maybe you can look at his original meassage at: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1692956+1694453+/usr/local/www/db/text/1999/freebsd-current/19990607.freebsd-current -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 20:18:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 1CC9514D7B for ; Sun, 18 Jul 1999 20:18:47 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id FAA17218 for freebsd-current@FreeBSD.ORG; Mon, 19 Jul 1999 05:17:10 +0200 (CEST) (envelope-from olli) Date: Mon, 19 Jul 1999 05:17:10 +0200 (CEST) From: Oliver Fromme Message-Id: <199907190317.FAA17218@dorifer.heim3.tu-clausthal.de> To: freebsd-current@FreeBSD.ORG Subject: Re: ftp current.freebsd.org Organization: Administration Heim 3 Reply-To: freebsd-current@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Adam Smaza wrote in list.freebsd-current: > Why can I access current.freebsd.org ? > All connections are refused. You can use releng3.freebsd.org, it has the same contents. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 20:25:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 30CF015091 for ; Sun, 18 Jul 1999 20:25:32 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id FAA17479 for freebsd-current@FreeBSD.ORG; Mon, 19 Jul 1999 05:25:32 +0200 (CEST) (envelope-from olli) Date: Mon, 19 Jul 1999 05:25:32 +0200 (CEST) From: Oliver Fromme Message-Id: <199907190325.FAA17479@dorifer.heim3.tu-clausthal.de> To: freebsd-current@FreeBSD.ORG Subject: Question about MTRR boot message Organization: Administration Heim 3 Reply-To: freebsd-current@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, There's the following message in my dmesg: "Pentium Pro MTRR support enabled, default memory type is uncacheable" I seriously hope that it does not mean that my memory is not chached... does it? I haven't found any manual pages or other docs about it. (If it matters: I cvsupped and built a -current world yesterday. It's an SMP box (dual Celeron), which seems to run fine so far.) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 20:48:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 6D99F1506E for ; Sun, 18 Jul 1999 20:48:42 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id UAA82554 for ; Sun, 18 Jul 1999 20:47:39 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907190347.UAA82554@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-current@FreeBSD.ORG Subject: Re: Question about MTRR boot message In-reply-to: Your message of "Mon, 19 Jul 1999 05:25:32 +0200." <199907190325.FAA17479@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Jul 1999 20:47:39 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is a nice feature if you happen to have a fast video card . It speed up w= rites = by four times. = Long time ago, tests writing to my Matrox millenium would yield about 20M= B/sec. With MTTR enabled -- wrote a litte hack over here to do it -- the same test generated about 80MB/sec create for dumping raw video to my = Matrox Millenium. The MTTR stuff is an old hack which some motherboards enabled it automatically for you. = So to answer your question , the MTTR stuff is supposed to disabled cachi= ng to your VGA card. Cheers = > Hi, > = > There's the following message in my dmesg: > = > "Pentium Pro MTRR support enabled, default memory type is uncacheabl= e" > = > I seriously hope that it does not mean that my memory > is not chached... does it? I haven't found any manual > pages or other docs about it. > = > (If it matters: I cvsupped and built a -current world > yesterday. It's an SMP box (dual Celeron), which seems > to run fine so far.) > = > Regards > Oliver > = > -- = > Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany > (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) > = > "In jedem St=FCck Kohle wartet ein Diamant auf seine Geburt" > (Terry Pratchett) > = > = > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- = Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 22:17:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 79DDF14EF7 for ; Sun, 18 Jul 1999 22:17:13 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id HAA21639 for freebsd-current@FreeBSD.ORG; Mon, 19 Jul 1999 07:16:59 +0200 (CEST) (envelope-from olli) Date: Mon, 19 Jul 1999 07:16:59 +0200 (CEST) From: Oliver Fromme Message-Id: <199907190516.HAA21639@dorifer.heim3.tu-clausthal.de> To: freebsd-current@FreeBSD.ORG Subject: Re: Question about MTRR boot message Organization: Administration Heim 3 Reply-To: freebsd-current@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG First, thank you for answering my question. Amancio Hasty wrote in list.freebsd-current: > Is a nice feature if you happen to have a fast video card . It speed up writes > by > four times. That particular box of mine contains an ISA VGA graphics card with 256 Kbyte video memory. It's a server, not a desktop machine (in fact it wouldn't need a gfx card at all, but it's more convenient than a serial console). > The MTTR stuff is an old hack which some motherboards enabled it > automatically for you. > > So to answer your question , the MTTR stuff is supposed to disabled caching > to your VGA card. OK, so it has nothing to do with disabling caching for my main memory, which was my concern. :-) Thanks for making that clear. BTW, is there a way to disable that MTRR stuff? Just to be sure... And I really don't need it. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 18 23:41:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by hub.freebsd.org (Postfix) with ESMTP id 8704014E36 for ; Sun, 18 Jul 1999 23:41:21 -0700 (PDT) (envelope-from ernie@spooky.eis.net.au) Received: (from ernie@localhost) by spooky.eis.net.au (8.9.3/8.8.3) id QAA40957 for freebsd-current@freebsd.org; Mon, 19 Jul 1999 16:41:18 +1000 (EST) From: Ernie Elu Message-Id: <199907190641.QAA40957@spooky.eis.net.au> Subject: wi0 almost works with Wavelan Turbo card To: freebsd-current@freebsd.org Date: Mon, 19 Jul 1999 16:41:17 +1000 (EST) X-Mailer: ELM [version 2.4ME+ PL40 (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 I am looking for help with getting a Lucent Wavelan Turbo ISA (Bronze) card running. Having read a few posts about the Wavelan IEEE 802.11 card not working with the wi driver I thought I would give it a go anyway with the turbo card. I installed a Wavelan Turbo PCMCIA card in my Toshiba 2520CDT notebook, and an idetical card with the Wavelan ISA adapter board into an Advantech 6154 Slot PC. Both computers are running FreeBSD 4.0-CURRENT with their IRQ set to 10 in pccard.conf, all other settings are default. It sort of works, the notebook end seems fine, but the Advantech end keeps coming up with the same error on the console every few seconds when there is traffic between them: wi0: oversized packet received (wi_dat_len=24576, wi_status=0x2000) No such error on the laptop. When the error occurs ftp or whatever you were doing stalls for a bit then continues. Any suggestions? - Ernie. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 0: 3:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 63AC615165 for ; Mon, 19 Jul 1999 00:03:07 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id DAA26187; Mon, 19 Jul 1999 03:03:52 -0400 From: Bill Paul Message-Id: <199907190703.DAA26187@skynet.ctr.columbia.edu> Subject: Re: wi0 almost works with Wavelan Turbo card To: ernie@spooky.eis.net.au (Ernie Elu) Date: Mon, 19 Jul 1999 03:03:50 -0400 (EDT) Cc: current@freebsd.org In-Reply-To: <199907190641.QAA40957@spooky.eis.net.au> from "Ernie Elu" at Jul 19, 99 04:41:17 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2142 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Ernie Elu had to walk into mine and say: > I am looking for help with getting a Lucent Wavelan Turbo ISA (Bronze) > card running. What speed is the card, exactly. > Having read a few posts about the Wavelan IEEE 802.11 card not working with > the wi driver I thought I would give it a go anyway with the turbo card. "Not working with the wi driver?" I hope you meant "now working." > I installed a Wavelan Turbo PCMCIA card in my Toshiba 2520CDT notebook, and > an idetical card with the Wavelan ISA adapter board into an Advantech 6154 > Slot PC. I am not familiar with an "Advantech 6154 Slot PC." Please don't assume that everyone automatically knows your hardware by name. Describe it. In detail. > Both computers are running FreeBSD 4.0-CURRENT with their IRQ set > to 10 in pccard.conf, all other settings are default. > > It sort of works, the notebook end seems fine, but the Advantech end keeps > coming up with the same error on the console every few seconds when there is > traffic between them: > > wi0: oversized packet received (wi_dat_len=24576, wi_status=0x2000) > > No such error on the laptop. > > When the error occurs ftp or whatever you were doing stalls for a bit then > continues. > > Any suggestions? No. I never obtained any real documentation from Lucent (they won't release the Hermes programming manual without NDA) and I don't have a turbo WaveLAN card so I'm unable to duplicate your problem on my own equipment. If I can't duplicate the problem and analyze it, I can't even begin to fix it. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 0:40:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by hub.freebsd.org (Postfix) with ESMTP id B700F150C4; Mon, 19 Jul 1999 00:40:08 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id CAA20545; Mon, 19 Jul 1999 02:39:57 -0500 (CDT) Received: from sji-ca4-70.ix.netcom.com(205.186.212.198) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma020541; Mon Jul 19 02:39:55 1999 Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id AAA71407; Mon, 19 Jul 1999 00:39:51 -0700 (PDT) Date: Mon, 19 Jul 1999 00:39:51 -0700 (PDT) Message-Id: <199907190739.AAA71407@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: current@freebsd.org Cc: jkh@freebsd.org Subject: readline/readline.h missing from 4-current snapshots From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The recent current snapshots are missing readline.h. It has been missing since at least the July 4 snap at current/releng3.freebsd.org. Satoshi ------- # tar tvf bindist.tar | grep readline drwxr-xr-x root/wheel 0 Jul 15 04:01 1999 usr/include/readline/ -r--r--r-- root/wheel 202008 Jul 15 04:04 1999 usr/lib/libreadline.a -r--r--r-- root/wheel 138156 Jul 15 04:04 1999 usr/lib/libreadline.so.4 lrwxrwxrwx root/wheel 0 Jul 19 00:20 1999 usr/lib/libreadline.so -> libreadline.so.4 drwxr-xr-x root/wheel 0 Jul 15 04:02 1999 usr/libdata/perl/5.00503/mach/readline/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 0:46: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from spooky.eis.net.au (spooky.eis.net.au [203.12.171.2]) by hub.freebsd.org (Postfix) with ESMTP id 12D301501A for ; Mon, 19 Jul 1999 00:45:49 -0700 (PDT) (envelope-from ernie@spooky.eis.net.au) Received: (from ernie@localhost) by spooky.eis.net.au (8.9.3/8.8.3) id RAA41262; Mon, 19 Jul 1999 17:42:24 +1000 (EST) From: Ernie Elu Message-Id: <199907190742.RAA41262@spooky.eis.net.au> Subject: Re: wi0 almost works with Wavelan Turbo card In-Reply-To: <199907190703.DAA26187@skynet.ctr.columbia.edu> from Bill Paul at "Jul 19, 99 03:03:50 am" To: wpaul@skynet.ctr.columbia.edu (Bill Paul) Date: Mon, 19 Jul 1999 17:42:24 +1000 (EST) Cc: freebsd-current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL40 (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 > Of all the gin joints in all the towns in all the world, Ernie Elu had > to walk into mine and say: > > > I am looking for help with getting a Lucent Wavelan Turbo ISA (Bronze) > > card running. > > What speed is the card, exactly. It runs in 3 modes, I have been testing in high speed mode which is supposed to be 10Mbps also the default mode. It can fall back to 2Mbps when talking to older cards or other 802.11 compatible cards. > > > Having read a few posts about the Wavelan IEEE 802.11 card not working with > > the wi driver I thought I would give it a go anyway with the turbo card. > > "Not working with the wi driver?" I hope you meant "now working." Good point:) > > > I installed a Wavelan Turbo PCMCIA card in my Toshiba 2520CDT notebook, and > > an idetical card with the Wavelan ISA adapter board into an Advantech 6154 > > Slot PC. > > I am not familiar with an "Advantech 6154 Slot PC." Please don't assume that > everyone automatically knows your hardware by name. Describe it. In detail. > It's a slot PC that plugs into an ISA passive backplane, popular with the picobsd crowd. It has the following probed hardware: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #3: Mon Jul 19 15:35:49 EST 1999 root@advantech.eis.net.au:/usr/src/sys/compile/ADVANTECH Timecounter "i8254" frequency 1193182 Hz CPU: AMD-K6(tm) 3D processor (299.52-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x80000800 real memory = 15728640 (15360K bytes) avail memory = 12660736 (12364K bytes) Preloaded elf kernel "kernel" at 0xc02bf000. K6-family MTRR support enabled (2 registers) Probing for PnP devices: npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 ide_pci0: irq 14 at device 1.1 on pci0 rl0: irq 11 at device 17.0 on pci0 rl0: Ethernet address: 00:c0:6c:74:55:92 rl0: autoneg complete, link status good (half-duplex, 10Mbps) vga-pci0: irq 15 at device 20.0 on pci0 isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): wd0: 2446MB (5009760 sectors), 4970 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): , removable, accel, ovlap, dma, iordis wcd0: drive speed 5512KB/sec, 128KB cache wcd0: supported read types: CD-R, CD-RW, CD-DA, packet track wcd0: Audio: play, 256 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: no/blank disc inside, unlocked atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> 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 PC-Card Vadem 469 (5 mem & 2 I/O windows) pcic: controller irq 5 Initializing PC-card drivers: wi changing root device to wd0s1a Card inserted, slot 0 wi0: at 0x240-0x27f irq 10 on isa wi0: Ethernet address: 00:60:1d:04:72:6a > > Both computers are running FreeBSD 4.0-CURRENT with their IRQ set > > to 10 in pccard.conf, all other settings are default. > > > > It sort of works, the notebook end seems fine, but the Advantech end keeps > > coming up with the same error on the console every few seconds when there is > > traffic between them: > > > > wi0: oversized packet received (wi_dat_len=24576, wi_status=0x2000) > > > > No such error on the laptop. > > > > When the error occurs ftp or whatever you were doing stalls for a bit then > > continues. > > > > Any suggestions? > > No. I never obtained any real documentation from Lucent (they won't release > the Hermes programming manual without NDA) and I don't have a turbo WaveLAN > card so I'm unable to duplicate your problem on my own equipment. If I can't > duplicate the problem and analyze it, I can't even begin to fix it. > > -Bill I think the source to their Linux driver for the 802.11 card is at: FTP://FTP.WAVELAN.COM/PUB/SOFTWARE/IEEE/PC_CARD/LINUX/wavelan2_cs-3.10.tar.gz It's supposed to work with the turbo card, according to the one line comment at: http://www.wavelan.com/support/software/index.html There is also a version 4 linux driver for the silver card, thats the one with the WEV encryption. - Ernie. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 1:12: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 525A21501A; Mon, 19 Jul 1999 01:11:55 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id KAA72105; Mon, 19 Jul 1999 10:09:52 +0200 (CEST) (envelope-from des) To: Tugrul Galatali Cc: obituary , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: From: Dag-Erling Smorgrav Date: 19 Jul 1999 10:09:51 +0200 In-Reply-To: Tugrul Galatali's message of "Sun, 18 Jul 1999 16:37:24 -0400 (EDT)" Message-ID: Lines: 9 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tugrul Galatali writes: > The exact cvsup command would also be nice I think. Are you using > "-P m" as the FAQ hints at if you are behind a firewall? Not necessary unless he runs an old version of CVSup. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 1:31:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id DFA1E14D5A for ; Mon, 19 Jul 1999 01:31:38 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id EAA26382; Mon, 19 Jul 1999 04:33:03 -0400 From: Bill Paul Message-Id: <199907190833.EAA26382@skynet.ctr.columbia.edu> Subject: Re: wi0 almost works with Wavelan Turbo card To: ernie@spooky.eis.net.au (Ernie Elu) Date: Mon, 19 Jul 1999 04:33:02 -0400 (EDT) Cc: current@freebsd.org In-Reply-To: <199907190742.RAA41262@spooky.eis.net.au> from "Ernie Elu" at Jul 19, 99 05:42:24 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 6806 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Ernie Elu had to walk into mine and say: > > Of all the gin joints in all the towns in all the world, Ernie Elu had > > to walk into mine and say: > > > > > I am looking for help with getting a Lucent Wavelan Turbo ISA (Bronze) > > > card running. > > > > What speed is the card, exactly. > > It runs in 3 modes, I have been testing in high speed mode which is > supposed to be 10Mbps also the default mode. It can fall back to 2Mbps when > talking to older cards or other 802.11 compatible cards. The only Turbo cards that I know people have tested are the 6Mbps ones. I haven't heard anything about any faster ones from Lucent (I wasn't aware the they had released them yet). Actually, I'm curious to know what sort of performance people have observed with these cards. The tests I've been running with the Aironet 11Mbps cards have shown only about 6Mbps transfer speed between two stations in ad-hoc mode. I wonder if people are actually getting 10 or 11Mbps (even with Windows). > > > I installed a Wavelan Turbo PCMCIA card in my Toshiba 2520CDT notebook, and > > > an idetical card with the Wavelan ISA adapter board into an Advantech 6154 > > > Slot PC. > > > > I am not familiar with an "Advantech 6154 Slot PC." Please don't assume that > > everyone automatically knows your hardware by name. Describe it. In detail. > > > > It's a slot PC that plugs into an ISA passive backplane, popular with the > picobsd crowd. > > It has the following probed hardware: Bleh... you have a RealTek ethernet controller. Please tell me this isn't built onto the board. Couldn't they spend the extra ten cents for something better? > > > Any suggestions? > > > > No. I never obtained any real documentation from Lucent (they won't release > > the Hermes programming manual without NDA) and I don't have a turbo WaveLAN > > card so I'm unable to duplicate your problem on my own equipment. If I can't > > duplicate the problem and analyze it, I can't even begin to fix it. > > > > -Bill > > > I think the source to their Linux driver for the 802.11 card is at: No. This is not "the source to their Linux driver." If you had bothered to actually look at it, you would have found that this archive contains only object code for the parts that actually talk to the Hermes controller. Lucent has created an API library called the HCF (Hardware Control Functions -- Lucent is excessively acronym-happy) for communicating with the Hermes controller. There are really two versions: the full HCF, and the HCF Light. The full HCF is proprietary and Lucent will not release the source for it without an NDA. The HCF Light is available under the GPL, however it lacks several of the features in the full HCF, such as 802.11/Ethernet II frame encapsulation/decapsulation and the ability to download new firmware images to the card (among other things). There is also an HCF Light manual which is a stripped down version of the full HCF manual. The Linux driver was written for Lucent by another company under contract; it uses the proprietary version of the HCF which is distributed in object code form only. Furthermore, only x86 object code is provided. The only source they provide is for the interface code between the HCF ahd the Linux kernel. The FreeBSD driver does not use the HCF or the HCF Light: I spent a fair amount of time figuring out how the Hermes works based on the HCF Light code and wrote my own driver from scratch so that I could escape the clutches of the GPL. The correct thing for Lucent to do would have been to release the driver/firmware API manual for the Hermes controller so that people could design their own interface code instead of forcing the HCF down their throats. The idea behind the HCF is to provide a hardware-independent interface to the Hermes which is easily portable to multiple platforms. This is not a bad idea in general, but in this case the Hermes API is actually so simple that covering it up with the HCF only makes things more complicated. Unfortunately, Lucent won't release the Hermes manual without NDA at this time (if ever). > FTP://FTP.WAVELAN.COM/PUB/SOFTWARE/IEEE/PC_CARD/LINUX/wavelan2_cs-3.10.tar.gz > > It's supposed to work with the turbo card, according to the one line comment at: > http://www.wavelan.com/support/software/index.html All of the WaveLAN/IEEE 802.11 cards support the same programming interface, with one small difference which is that there are more speed selections available on the Turbo cards than on the older 2Mbps ones (the mechanism to set the speed is the same; you're just allowed to specify additional values). So the wi driver is *supposed* to work with the turbo cards, but since I don't actually have any I can't verify this. The only high speed wireless cards I have are the Aironet PC4800 and ISA4800 (for which I'm currently writing another driver) and I don't appear to have any problems with these. I cite them for comparison because they have a very similar programming interface to the WaveLANs (which is surprising really since I thought the Hermes API was proprietary to Lucent; it's possible that all of the people making 802.11 equipment got together and agreed on a general hardware spec, but if so it's news to me). The only thing that I can think of is that the driver is having trouble reading the packet data out of the card at high speed. The way the cards work, data is read from/written to the card 16 bits at a time via I/O registers (these are programmed I/O devices; there's no memory mapping). It's possible that at high speeds, the I/O gets thrown out of whack sometimes. It's actually possible to go back and re-read the frame from the NIC, although I'd much rather figure out the exact cause of the problem and deal with that rather that applying a bandaid to work around the problem (re-reading the received frame would hurt performance). > There is also a version 4 linux driver for the silver card, thats the one with > the WEV encryption. WEP, not WEV, and whether you have encryption or not depends on if it's supported by the firmware in your card, not on the driver (though you do have to do a few things in the driver to turn the encryption on). -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 2: 9:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id A1525150CF for ; Mon, 19 Jul 1999 02:09:05 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id LAA73456; Mon, 19 Jul 1999 11:08:29 +0200 (CEST) (envelope-from des) To: Maxim Sobolev Cc: obrien@NUXI.com, current@FreeBSD.ORG Subject: Re: PLIP is still broken :( References: <379231DA.CF6721EB@altavista.net> <19990718192927.A98757@dragon.nuxi.com> <3792935D.D681007E@altavista.net> From: Dag-Erling Smorgrav Date: 19 Jul 1999 11:08:28 +0200 In-Reply-To: Maxim Sobolev's message of "Mon, 19 Jul 1999 05:54:21 +0300" Message-ID: Lines: 23 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maxim Sobolev writes: > Some time ago I > had rised this question and Bruce Evans told that this problem arise > because of switch to newbus. You misunderstood what Bruce wrote. PLIP has always been broken. It used to be possible to hack around the brokenness by setting the interrupt mask to net instead of tty. With newbus, this hack is no longer possible (it was never correct anyway; it broke printing). The problem with PLIP is that it tries to do splnet stuff in at spltty. If you force the parallell port driver to run at splnet, PLIP works but you get panics when you print because it tries to do spltty stuff at splnet. SLIP and PPPD do black magic with interrupt masks so spltty and splnet become essentially equivalen (or so I understand). They do this because they have the exact same problems as PLIP - they need to do splnet stuff at spltty. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 2:20:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id B202B150CD for ; Mon, 19 Jul 1999 02:20:13 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id LAA15421; Mon, 19 Jul 1999 11:15:24 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Dag-Erling Smorgrav Cc: Maxim Sobolev , obrien@NUXI.com, current@FreeBSD.ORG Subject: Re: PLIP is still broken :( In-reply-to: Your message of "19 Jul 1999 11:08:28 +0200." Date: Mon, 19 Jul 1999 11:15:24 +0200 Message-ID: <15419.932375724@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is actually a deficiency in the ppbus stuff, there is no telling what SPL level the subdriver wants to use, so the interrupt should actually be released back to the system when no subdrivers are open and be grabbed the way the subdriver wants it once it aquires the bus. The ZIP driver would probably want splcam/splbio, the pps wants splabsolutelynobody() (and FAST_IRQ) and plip wants splnet(). In message , Dag-Erling Smorgrav writes: >Maxim Sobolev writes: >> Some time ago I >> had rised this question and Bruce Evans told that this problem arise >> because of switch to newbus. > >You misunderstood what Bruce wrote. PLIP has always been broken. It >used to be possible to hack around the brokenness by setting the >interrupt mask to net instead of tty. With newbus, this hack is no >longer possible (it was never correct anyway; it broke printing). > >The problem with PLIP is that it tries to do splnet stuff in at >spltty. If you force the parallell port driver to run at splnet, PLIP >works but you get panics when you print because it tries to do spltty >stuff at splnet. > >SLIP and PPPD do black magic with interrupt masks so spltty and splnet >become essentially equivalen (or so I understand). They do this >because they have the exact same problems as PLIP - they need to do >splnet stuff at spltty. > >DES >-- >Dag-Erling Smorgrav - des@flood.ping.uio.no > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 2:37:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 2E52A14C19 for ; Mon, 19 Jul 1999 02:37:24 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id TAA28795; Mon, 19 Jul 1999 19:37:02 +1000 Date: Mon, 19 Jul 1999 19:37:02 +1000 From: Bruce Evans Message-Id: <199907190937.TAA28795@godzilla.zeta.org.au> To: des@flood.ping.uio.no, sobomax@altavista.net Subject: Re: PLIP is still broken :( Cc: current@FreeBSD.ORG, obrien@NUXI.com Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >You misunderstood what Bruce wrote. PLIP has always been broken. It >used to be possible to hack around the brokenness by setting the >interrupt mask to net instead of tty. With newbus, this hack is no >longer possible (it was never correct anyway; it broke printing). Or by statically configuring SLIP (which forced tty = net), or maybe by dynamically configuring PPP. The tty = net hack went away with old-bus, so SLIP is broken in much the same way as PLIP. >The problem with PLIP is that it tries to do splnet stuff in at >spltty. If you force the parallell port driver to run at splnet, PLIP >works but you get panics when you print because it tries to do spltty >stuff at splnet. Possible quick fix (hack): change all the spltty()'s in lpt.c to splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing splnet() instead should work OK for lpt and fix if_plip. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 3:13:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id A517514C7F for ; Mon, 19 Jul 1999 03:13:31 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 19 Jul 1999 11:12:29 +0100 (BST) Date: Mon, 19 Jul 1999 11:12:29 +0100 From: David Malone To: freebsd-current@FreeBSD.ORG Subject: Re: Question about MTRR boot message Message-ID: <19990719111229.A5209@walton.maths.tcd.ie> References: <199907190325.FAA17479@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199907190325.FAA17479@dorifer.heim3.tu-clausthal.de>; from Oliver Fromme on Mon, Jul 19, 1999 at 05:25:32AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 19, 1999 at 05:25:32AM +0200, Oliver Fromme wrote: > There's the following message in my dmesg: > > "Pentium Pro MTRR support enabled, default memory type is uncacheable" > > I seriously hope that it does not mean that my memory > is not chached... does it? I haven't found any manual > pages or other docs about it. You'd know all about it if it had disabled the caching of RAM. We had a SMP motherboard which didn't configure MTRR stuff for the second processor, and the FreeBSD workaround was broken at the time. The 450MHz PII ran about 200 times slower than usual! David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 4: 6:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from fep9.mail.ozemail.net (fep9.mail.ozemail.net [203.2.192.103]) by hub.freebsd.org (Postfix) with ESMTP id B81D41513D; Mon, 19 Jul 1999 04:04:57 -0700 (PDT) (envelope-from c9710216@atlas.newcastle.edu.au) Received: from atlas.newcastle.edu.au (slnew55p58.ozemail.com.au [203.108.151.136]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id VAA06445; Mon, 19 Jul 1999 21:03:23 +1000 (EST) Message-ID: <37930553.F2B03BB0@atlas.newcastle.edu.au> Date: Mon, 19 Jul 1999 21:00:35 +1000 From: obituary X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Tugrul Galatali Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Problem with cvsup References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tugrul Galatali wrote: > > On 18 Jul 1999, Dag-Erling Smorgrav wrote: > > > obituary writes: > > > If anyone can shed some light on my situation (or has experienced > > > similar troubles themselves) I'd be most grateful to hear from you. > > > > You forgot to attach the output of 'ipfw -a l'. > > > > The exact cvsup command would also be nice I think. Are you using > "-P m" as the FAQ hints at if you are behind a firewall? The client defaults to multiplexed mode from what I've seen. I've also tried using passive mode "-P -", but no luck there either. My "SUPFLAGS" line as set in /etc/make.conf is: SUPFLAGS= -g -L 2 -z -jake (obituary) Powered by FreeBSD c9710216@atlas.newcastle.edu.au http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 4:35:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 4DEB914CB1; Mon, 19 Jul 1999 04:35:22 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id NAA76665; Mon, 19 Jul 1999 13:30:55 +0200 (CEST) (envelope-from des) To: obituary Cc: Tugrul Galatali , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: <37930553.F2B03BB0@atlas.newcastle.edu.au> From: Dag-Erling Smorgrav Date: 19 Jul 1999 13:30:54 +0200 In-Reply-To: obituary's message of "Mon, 19 Jul 1999 21:00:35 +1000" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG obituary writes: > My "SUPFLAGS" line as set in /etc/make.conf is: > > SUPFLAGS= -g -L 2 -z You still haven't told us what your firewall setup is. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 5:44:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from fep9.mail.ozemail.net (fep9.mail.ozemail.net [203.2.192.103]) by hub.freebsd.org (Postfix) with ESMTP id 0DA7B15132; Mon, 19 Jul 1999 05:44:13 -0700 (PDT) (envelope-from c9710216@atlas.newcastle.edu.au) Received: from atlas.newcastle.edu.au (slnew55p58.ozemail.com.au [203.108.151.136]) by fep9.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id WAA25915; Mon, 19 Jul 1999 22:42:40 +1000 (EST) Message-ID: <37931C99.7038563D@atlas.newcastle.edu.au> Date: Mon, 19 Jul 1999 22:39:53 +1000 From: obituary X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: <3791BFE4.D18901D3@atlas.newcastle.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > obituary writes: > > If anyone can shed some light on my situation (or has experienced > > similar troubles themselves) I'd be most grateful to hear from you. > > You forgot to attach the output of 'ipfw -a l'. Ok, since my original post I've done a little more testing. The problem appears to be related to natd. If natd has been run at any time since booting, the problems occur. I compiled a fresh kernel on the firewall machine (3.2-RELEASE) without firewalling options. Everything worked fine -- I was able to cvsup the firewall box. I then recompiled with the firewalling options enabled, but set the firewall_type="open" and natd_enable="NO" in rc.conf. Once again, everything worked fine. I enabled natd to see if I could cvsup my other machine (4.0-CURRENT) and that's where the trouble started. I couldn't cvsup the CURRENT box *or* the firewall box after enabling natd. I couldn't even cvsup the firewall box after taking the divert rule out! Listing of ipfw -a l: 00100 16 1792 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 1742 663154 divert 8668 ip from any to any via ppp0 65000 9023 1751445 allow ip from any to any 65535 0 0 deny ip from any to any List of options in my kernel: pseudo-device ether #Generic Ethernet pseudo-device loop #Network loopback device pseudo-device ppp 2 #Point-to-point protocol options PPP_BSDCOMP #PPP BSD-compress support options PPP_DEFLATE #PPP zlib/deflate/gzip support options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about # dropped packets options IPDIVERT The command I use for natd is: natd -dynamic -n ppp0 I've also tried the -m option, but it makes no difference. -jake (obituary) Powered by FreeBSD c9710216@atlas.newcastle.edu.au http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 5:49:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id CA88D1513D; Mon, 19 Jul 1999 05:49:45 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id OAA78386; Mon, 19 Jul 1999 14:46:02 +0200 (CEST) (envelope-from des) To: obituary Cc: Dag-Erling Smorgrav , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: <3791BFE4.D18901D3@atlas.newcastle.edu.au> <37931C99.7038563D@atlas.newcastle.edu.au> From: Dag-Erling Smorgrav Date: 19 Jul 1999 14:46:02 +0200 In-Reply-To: obituary's message of "Mon, 19 Jul 1999 22:39:53 +1000" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG obituary writes: > pseudo-device ppp 2 #Point-to-point protocol > options PPP_BSDCOMP #PPP BSD-compress support > options PPP_DEFLATE #PPP zlib/deflate/gzip support Why are you using kernel pppd instead of userland ppp? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 5:56:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 84D7315161; Mon, 19 Jul 1999 05:56:26 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1003) id 960C1F818; Mon, 19 Jul 1999 08:55:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id 8899F9B15; Mon, 19 Jul 1999 08:55:15 -0400 (EDT) Date: Mon, 19 Jul 1999 08:55:15 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: obituary Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup In-Reply-To: <37931C99.7038563D@atlas.newcastle.edu.au> 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, 19 Jul 1999, obituary wrote: > List of options in my kernel: > pseudo-device ether #Generic Ethernet > pseudo-device loop #Network loopback device > pseudo-device ppp 2 #Point-to-point protocol > options PPP_BSDCOMP #PPP BSD-compress support > options PPP_DEFLATE #PPP zlib/deflate/gzip support > > options IPFIREWALL #firewall > options IPFIREWALL_VERBOSE #print information about > # dropped packets > options IPDIVERT > > > The command I use for natd is: > natd -dynamic -n ppp0 > > I've also tried the -m option, but it makes no difference. > Why not use userland ppp (i.e. ppp -alias) instead of kernel-ppp and natd? ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 7: 8:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id B4D5514C92 for ; Mon, 19 Jul 1999 07:08:01 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id KAA26820; Mon, 19 Jul 1999 10:08:58 -0400 From: Bill Paul Message-Id: <199907191408.KAA26820@skynet.ctr.columbia.edu> Subject: Re: wi0 almost works with Wavelan Turbo card To: ernie@spooky.eis.net.au (Ernie Elu) Date: Mon, 19 Jul 1999 10:08:57 -0400 (EDT) Cc: current@freebsd.org In-Reply-To: <199907190750.RAA41315@spooky.eis.net.au> from "Ernie Elu" at Jul 19, 99 05:50:51 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1295 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, Ernie Elu had to walk into mine and say: > I forgot to mention if you want to telnet in and poke around the system just > let me know a login and password you would like and I will set it up. Gee, you know, I'd love to reply to you, but every time I do I get an error: ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to spooky.eis.net.au.: >>> MAIL From: SIZE=1454 <<< 553 ... Access Denied 501 ... Data format error Looks like it doesn't like anything under columbia.edu. It likes freebsd.org though. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 7:21:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from fep8.mail.ozemail.net (fep8.mail.ozemail.net [203.2.192.102]) by hub.freebsd.org (Postfix) with ESMTP id 1B7E914F39; Mon, 19 Jul 1999 07:21:04 -0700 (PDT) (envelope-from c9710216@atlas.newcastle.edu.au) Received: from atlas.newcastle.edu.au (slnew55p58.ozemail.com.au [203.108.151.136]) by fep8.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id AAA12805; Tue, 20 Jul 1999 00:20:53 +1000 (EST) Message-ID: <3793339D.297B21F3@atlas.newcastle.edu.au> Date: Tue, 20 Jul 1999 00:18:05 +1000 From: obituary X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: <3791BFE4.D18901D3@atlas.newcastle.edu.au> <37931C99.7038563D@atlas.newcastle.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > obituary writes: > > pseudo-device ppp 2 #Point-to-point protocol > > options PPP_BSDCOMP #PPP BSD-compress support > > options PPP_DEFLATE #PPP zlib/deflate/gzip support > > Why are you using kernel pppd instead of userland ppp? Why not? Is there some issue regarding kernel pppd that I'm not aware of? I used kernel pppd simply because I assumed the kernel implementation would be more efficient, and I'd had prior experience using pppd (under Linux). -jake (obituary) c9710216@atlas.newcastle.edu.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 7:29:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from fep8.mail.ozemail.net (fep8.mail.ozemail.net [203.2.192.102]) by hub.freebsd.org (Postfix) with ESMTP id 97BF314BE5; Mon, 19 Jul 1999 07:29:25 -0700 (PDT) (envelope-from c9710216@atlas.newcastle.edu.au) Received: from atlas.newcastle.edu.au (slnew55p58.ozemail.com.au [203.108.151.136]) by fep8.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id AAA14767; Tue, 20 Jul 1999 00:28:33 +1000 (EST) Message-ID: <3793356A.EDC63408@atlas.newcastle.edu.au> Date: Tue, 20 Jul 1999 00:25:46 +1000 From: obituary X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: "Chris D. Faulhaber" Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As I explained to DES, I used pppd because I assumed it would be more efficient and I was already familiar with pppd configuration. What I don't understand, however, is that the pppd/natd setup I have here works flawlessly for web browsing, ftp, news/mail retreval, etc., yet it can't seem to handle cvsup connections. Wierd. -jake (obituary) Powered by FreeBSD c9710216@atlas.newcastle.edu.au http://www.freebsd.org "Chris D. Faulhaber" wrote: > > On Mon, 19 Jul 1999, obituary wrote: > > > List of options in my kernel: > > pseudo-device ether #Generic Ethernet > > pseudo-device loop #Network loopback device > > pseudo-device ppp 2 #Point-to-point protocol > > options PPP_BSDCOMP #PPP BSD-compress support > > options PPP_DEFLATE #PPP zlib/deflate/gzip support > > > > options IPFIREWALL #firewall > > options IPFIREWALL_VERBOSE #print information about > > # dropped packets > > options IPDIVERT > > > > > > The command I use for natd is: > > natd -dynamic -n ppp0 > > > > I've also tried the -m option, but it makes no difference. > > > > Why not use userland ppp (i.e. ppp -alias) instead of kernel-ppp and natd? > > ----- > Chris D. Faulhaber | All the true gurus I've met never > System/Network Administrator, | claimed they were one, and always > Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 7:49:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 5E9FB151AC; Mon, 19 Jul 1999 07:49:55 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id QAA81210; Mon, 19 Jul 1999 16:46:17 +0200 (CEST) (envelope-from des) To: obituary Cc: Dag-Erling Smorgrav , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: <3791BFE4.D18901D3@atlas.newcastle.edu.au> <37931C99.7038563D@atlas.newcastle.edu.au> <3793339D.297B21F3@atlas.newcastle.edu.au> From: Dag-Erling Smorgrav Date: 19 Jul 1999 16:46:16 +0200 In-Reply-To: obituary's message of "Tue, 20 Jul 1999 00:18:05 +1000" Message-ID: Lines: 21 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG obituary writes: > Dag-Erling Smorgrav wrote: > > Why are you using kernel pppd instead of userland ppp? > Why not? Is there some issue regarding kernel pppd that I'm not aware > of? I used kernel pppd simply because I assumed the kernel > implementation would be more efficient, and I'd had prior experience > using pppd (under Linux). Yes, in some cases you may save up to 1% CPU power using kernel PPP. On the other hand, userland PPP is actively maintained, whereas nobody's touched kernel PPP for over a year except to keep it in sync with architectural changes in the kernel. Userland PPP has builtin NAT based on libalias (which does all kinds of magic to make active FTP and the like work across NAT). It also has a much nicer configuration syntax (though that may be a matter of personal preference). DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 8:18:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 803C414E74; Mon, 19 Jul 1999 08:18:29 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id RAA81932; Mon, 19 Jul 1999 17:15:53 +0200 (CEST) (envelope-from des) To: obituary Cc: "Chris D. Faulhaber" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: <3793356A.EDC63408@atlas.newcastle.edu.au> From: Dag-Erling Smorgrav Date: 19 Jul 1999 17:15:52 +0200 In-Reply-To: obituary's message of "Tue, 20 Jul 1999 00:25:46 +1000" Message-ID: Lines: 16 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG obituary writes: > What I don't understand, however, is that the pppd/natd setup I have > here works flawlessly for web browsing, ftp, news/mail retreval, etc., > yet it can't seem to handle cvsup connections. Wierd. What version of CVSup do you run? If it's not 16.0, upgrade to 16.0, or make sure you run cvsup with the '-P m' option (*not* '-m'; there is no such option.) Do you run a clean kernel, or do you have any patches? There are SYN rate limiting patches floating around which are known to badly break the TCP/IP stack. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 9:22:42 1999 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 8AF0214D37 for ; Mon, 19 Jul 1999 09:22:39 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id JAA23128; Mon, 19 Jul 1999 09:20:34 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA66166; Mon, 19 Jul 1999 09:20:33 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Mon, 19 Jul 1999 09:20:33 -0700 (PDT) Message-Id: <199907191620.JAA66166@vashon.polstra.com> To: c9710216@atlas.newcastle.edu.au Subject: Re: Problem with cvsup In-Reply-To: <3793356A.EDC63408@atlas.newcastle.edu.au> References: Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [By the way, it was a no-no to cross-post this to two mailing lists. I've removed -stable from the cc line.] In article <3793356A.EDC63408@atlas.newcastle.edu.au>, obituary wrote: > > What I don't understand, however, is that the pppd/natd setup I have > here works flawlessly for web browsing, ftp, news/mail retreval, etc., > yet it can't seem to handle cvsup connections. Wierd. CVSup has a tendency to expose network problems, because it uses TCP in somewhat atypical ways. Still, multiplexed mode is more "normal" than the others. I'm surprised you're having problems using it, even with NAT. If you have some time to spend on this, some tcpdumps might provide a clue. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 10:28:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from hal-pc.org (hal-pc.org [204.52.135.1]) by hub.freebsd.org (Postfix) with ESMTP id 8BF8315149 for ; Mon, 19 Jul 1999 10:28:20 -0700 (PDT) (envelope-from jes@hal-pc.org) Received: from jason (206.180.128.29.dial-ip.hal-pc.org [206.180.128.29]) by hal-pc.org (8.9.1/8.9.0) with SMTP id MAA01752 for ; Mon, 19 Jul 1999 12:27:14 -0459 (CDT) Message-ID: <002b01bed20b$5547e1c0$0500a8c0@local.nullifier.dyn.ml.org> From: "Jason" To: References: <199907190516.HAA21639@dorifer.heim3.tu-clausthal.de> Subject: Re: Question about MTRR boot message Date: Mon, 19 Jul 1999 12:22:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > BTW, is there a way to disable that MTRR stuff? Just to be > sure... And I really don't need it. > > Regards > Oliver Before you go any further worrying about this "just in case", there is nothing for you to worry about. Part of what the MTRR "stuff" does is it stops the L2 cache from cacheing that range of memory. This is typicaly used for video cards, as you have been told, because well, you really never read back from the video card's memory frame buffer, and if you did, for some strange reason, it would only result in a cache miss and would then have to be fetched from main memory. Since your L2 cache isn't wasting space on this area of memory, it can cache something more usefull, and thus give you a speed *increase*. Another part of what MTRR does is allow multiple overlapping writes to the same uncacheable memory range to be combined into a single write, with a good likely hood of a speed increase. Thus, MTRR is GOOD. - Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 10:55:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 8B34815243 for ; Mon, 19 Jul 1999 10:55:22 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id NAA41836; Mon, 19 Jul 1999 13:53:29 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 19 Jul 1999 13:53:29 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Jason Cc: freebsd-current@FreeBSD.org Subject: Re: Question about MTRR boot message In-Reply-To: <002b01bed20b$5547e1c0$0500a8c0@local.nullifier.dyn.ml.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 Mon, 19 Jul 1999, Jason wrote: > Before you go any further worrying about this "just in case", there is > nothing for you to worry about. Part of what the MTRR "stuff" does is it > stops the L2 cache from cacheing that range of memory. This is typicaly used > for video cards, as you have been told, because well, you really never read > back from the video card's memory frame buffer, and if you did, for some > strange reason, it would only result in a cache miss and would then have to > be fetched from main memory. Since your L2 cache isn't wasting space on this > area of memory, it can cache something more usefull, and thus give you a > speed *increase*. > I wrote the K6-2 MTRR support, but I really don't know how to use it. You see, my X server reports: (--) SVGA: PCI: NVidia Riva TNT rev 4, Memory @ 0xef000000, 0xcc000000 But which do I make uncacheable? > > Thus, MTRR is GOOD. > > - Jason > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 11:57:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from fep8.mail.ozemail.net (fep8.mail.ozemail.net [203.2.192.102]) by hub.freebsd.org (Postfix) with ESMTP id 10F7214F38; Mon, 19 Jul 1999 11:57:23 -0700 (PDT) (envelope-from c9710216@atlas.newcastle.edu.au) Received: from atlas.newcastle.edu.au (slnew55p58.ozemail.com.au [203.108.151.136]) by fep8.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id EAA08452; Tue, 20 Jul 1999 04:56:21 +1000 (EST) Message-ID: <3793742E.E0725B51@atlas.newcastle.edu.au> Date: Tue, 20 Jul 1999 04:53:34 +1000 From: obituary X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: <3791BFE4.D18901D3@atlas.newcastle.edu.au> <37931C99.7038563D@atlas.newcastle.edu.au> <3793339D.297B21F3@atlas.newcastle.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Yes, in some cases you may save up to 1% CPU power using kernel PPP. > On the other hand, userland PPP is actively maintained, whereas > nobody's touched kernel PPP for over a year except to keep it in sync > with architectural changes in the kernel. > > Userland PPP has builtin NAT based on libalias (which does all kinds > of magic to make active FTP and the like work across NAT). It also has > a much nicer configuration syntax (though that may be a matter of > personal preference). You've sold me! My family refuse to use anything but M$ Internet Explorer for their web/ftp needs, and the damn thing doesn't support passive mode FTP (neither does their DOS based client for that matter). I had to add a rule to specifically allow TCP traffic on port 20... Thanks for the info. -jake (obituary) Powered by FreeBSD c9710216@atlas.newcastle.edu.au http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 11:58:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 4376B1529A for ; Mon, 19 Jul 1999 11:58:26 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id LAA00499 for ; Mon, 19 Jul 1999 11:52:41 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907191852.LAA00499@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-current@FreeBSD.ORG Subject: Re: Question about MTRR boot message In-reply-to: Your message of "Mon, 19 Jul 1999 05:25:32 +0200." <199907190325.FAA17479@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jul 1999 11:52:41 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > = > There's the following message in my dmesg: > = > "Pentium Pro MTRR support enabled, default memory type is uncacheabl= e" > = > I seriously hope that it does not mean that my memory > is not chached... does it? I haven't found any manual > pages or other docs about it. > = > (If it matters: I cvsupped and built a -current world > yesterday. It's an SMP box (dual Celeron), which seems > to run fine so far.) It means that the default memory type for unmapped memory is = "uncacheable". The message is confusing because typically there is a = mapping for physical memory that overrides the default. I'll probably = remove it. -- = \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 12: 7:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from fep8.mail.ozemail.net (fep8.mail.ozemail.net [203.2.192.102]) by hub.freebsd.org (Postfix) with ESMTP id 8A43C15273; Mon, 19 Jul 1999 12:07:15 -0700 (PDT) (envelope-from c9710216@atlas.newcastle.edu.au) Received: from atlas.newcastle.edu.au (slnew55p58.ozemail.com.au [203.108.151.136]) by fep8.mail.ozemail.net (8.9.0/8.6.12) with ESMTP id FAA11466; Tue, 20 Jul 1999 05:06:57 +1000 (EST) Message-ID: <379376AB.1902B050@atlas.newcastle.edu.au> Date: Tue, 20 Jul 1999 05:04:11 +1000 From: obituary X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: "Chris D. Faulhaber" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup References: <3793356A.EDC63408@atlas.newcastle.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > What version of CVSup do you run? If it's not 16.0, upgrade to 16.0, > or make sure you run cvsup with the '-P m' option (*not* '-m'; there > is no such option.) It's version 16.0. The -m I specified was an natd switch telling it to "try to keep the same port number when altering outgoing packets". I thought the default behaviour may have been confusing CVSup. > Do you run a clean kernel, or do you have any patches? There are SYN > rate limiting patches floating around which are known to badly break > the TCP/IP stack. No patches here. It's a clean 3.2-RELEASE kernel built from the distribution CD sources. -jake (obituary) Powered by FreeBSD c9710216@atlas.newcastle.edu.au http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 12:41:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 7AA7E14C96; Mon, 19 Jul 1999 12:41:51 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id MAA00798; Mon, 19 Jul 1999 12:37:11 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907191937.MAA00798@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Brian F. Feldman" Cc: Jason , freebsd-current@FreeBSD.org Subject: Re: Question about MTRR boot message In-reply-to: Your message of "Mon, 19 Jul 1999 13:53:29 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jul 1999 12:37:11 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I wrote the K6-2 MTRR support, but I really don't know how to use it. > You see, my X server reports: > (--) SVGA: PCI: NVidia Riva TNT rev 4, Memory @ 0xef000000, 0xcc000000 > But which do I make uncacheable? You don't; let the X server do it. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 12:45:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 96CCD14D0D; Mon, 19 Jul 1999 12:45:25 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id MAA41241; Mon, 19 Jul 1999 12:45:16 -0700 (PDT) Message-ID: <3793804C.59E2B600@whistle.com> Date: Mon, 19 Jul 1999 12:45:16 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.8-STABLE i386) MIME-Version: 1.0 To: Peter Jeremy Cc: dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: LOCK overheads (was Re: "objtrm" problem probably found) References: <99Jul14.072823est.40325@border.alcanet.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A bit late, but some more data points..... 90MHz Pentium, FreeBSD 2.2.7 mode 0 60.80 ns/loop nproc=1 lcks=EMPTY mode 1 91.13 ns/loop nproc=1 lcks=no mode 2 91.11 ns/loop nproc=2 lcks=no mode 3 242.59 ns/loop nproc=1 lcks=yes mode 4 242.69 ns/loop nproc=2 lcks=yes mode 5 586.27 ns/loop nproc=1 lcks=no mode 6 586.91 ns/loop nproc=2 lcks=no mode 7 749.28 ns/loop nproc=1 lcks=yes mode 8 746.70 ns/loop nproc=2 lcks=yes mode 9 181.96 ns/loop nproc=1 lcks=EMPTY mode 10 242.56 ns/loop nproc=1 lcks=no mode 11 242.69 ns/loop nproc=2 lcks=no mode 12 343.80 ns/loop nproc=1 lcks=yes mode 13 343.77 ns/loop nproc=2 lcks=yes mode 14 727.79 ns/loop nproc=1 lcks=no mode 15 729.95 ns/loop nproc=2 lcks=no mode 16 850.10 ns/loop nproc=1 lcks=yes mode 17 848.02 ns/loop nproc=2 lcks=yes 200MHz Pentium Pro, -current, same binary as above; mode 0 42.76 ns/loop nproc=1 lcks=EMPTY mode 1 32.01 ns/loop nproc=1 lcks=no mode 2 33.30 ns/loop nproc=2 lcks=no mode 3 191.30 ns/loop nproc=1 lcks=yes mode 4 191.62 ns/loop nproc=2 lcks=yes mode 5 93.12 ns/loop nproc=1 lcks=no mode 6 94.54 ns/loop nproc=2 lcks=no mode 7 195.16 ns/loop nproc=1 lcks=yes mode 8 200.91 ns/loop nproc=2 lcks=yes mode 9 65.83 ns/loop nproc=1 lcks=EMPTY mode 10 90.32 ns/loop nproc=1 lcks=no mode 11 90.33 ns/loop nproc=2 lcks=no mode 12 236.61 ns/loop nproc=1 lcks=yes mode 13 236.70 ns/loop nproc=2 lcks=yes mode 14 120.83 ns/loop nproc=1 lcks=no mode 15 122.12 ns/loop nproc=2 lcks=no mode 16 276.92 ns/loop nproc=1 lcks=yes mode 17 277.19 ns/loop nproc=2 lcks=yes 200MHz pentium Pro, -current, compiled with -current compiler mode 0 35.30 ns/loop nproc=1 lcks=EMPTY mode 1 22.13 ns/loop nproc=1 lcks=no mode 2 22.31 ns/loop nproc=2 lcks=no mode 3 186.26 ns/loop nproc=1 lcks=yes mode 4 186.39 ns/loop nproc=2 lcks=yes mode 5 75.61 ns/loop nproc=1 lcks=no mode 6 78.52 ns/loop nproc=2 lcks=no mode 7 191.46 ns/loop nproc=1 lcks=yes mode 8 191.65 ns/loop nproc=2 lcks=yes mode 9 69.34 ns/loop nproc=1 lcks=EMPTY mode 10 86.68 ns/loop nproc=1 lcks=no mode 11 86.49 ns/loop nproc=2 lcks=no mode 12 237.49 ns/loop nproc=1 lcks=yes mode 13 236.67 ns/loop nproc=2 lcks=yes mode 14 134.96 ns/loop nproc=1 lcks=no mode 15 134.99 ns/loop nproc=2 lcks=no mode 16 276.90 ns/loop nproc=1 lcks=yes mode 17 277.33 ns/loop nproc=2 lcks=yes Not exactly sure what all this means but whatever mode1 17 is, it can sure be expensive.. of course this is a UP machine... julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 13: 4:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from sun.fi (sun.fi [193.65.93.1]) by hub.freebsd.org (Postfix) with ESMTP id C5C5B1526E for ; Mon, 19 Jul 1999 13:04:44 -0700 (PDT) (envelope-from tomppa@sun.fi) Received: from sun9.sun.fi (sun9.sun.fi [193.65.93.9]) by sun.fi (8.8.8/8.8.8) with ESMTP id XAA12771 for ; Mon, 19 Jul 1999 23:04:41 +0300 (EET DST) Received: (from tomppa@localhost) by sun9.sun.fi (8.9.3/8.9.3) id XAA01106; Mon, 19 Jul 1999 23:04:40 +0300 (EET DST) From: Tomi Vainio MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <14227.34008.442998.44420@sun9.sun.fi> Date: Mon, 19 Jul 1999 23:04:40 +0300 (EET DST) To: freebsd-current@freebsd.org Subject: Unusable PS/2 mouse X-Mailer: VM 6.67 under 20.4 "Emerald" XEmacs Lucid Reply-To: tomppa@sun.fi Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have tried to use Logitech PS/2 wheel mouse (model M-S48) but support has been broken for a long time now. I have binded fvwm menus to mouse + keyboard combinations. If I press keyboard and move mouse at the time I will always get these errors and keyboard is lost after this. Jun 20 21:48:36 cat /kernel: psmintr: out of sync (0000 != 0008). Jun 20 21:53:26 cat /kernel: psmintr: out of sync (0000 != 0008). Jun 20 21:53:26 cat /kernel: psmintr: out of sync (0000 != 0008). If I disable sync check (psm flags 0x100) cursor starts warping around the screen. Only way to use X at all is to disable sync and not to use keyboard and mouse at the same time. Tomppa --- clip clip --- Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #21: Mon Jul 19 22:21:51 EEST 1999 tomppa@cat.bert.pp.clinet.fi:/f/local/sup/4.0/sys/compile/CAT Calibrating clock(s) ... TSC clock: 232519399 Hz, i8254 clock: 1193141 Hz Timecounter "i8254" frequency 1193141 Hz CPU: Pentium Pro (232.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xf9ff real memory = 67108864 (65536K bytes) Physical memory chunk(s): 0x00001000 - 0x0009ffff, 651264 bytes (159 pages) 0x00310000 - 0x03ff7fff, 63864832 bytes (15592 pages) fb: new array size 4 avail memory = 61865984 (60416K bytes) Found BIOS32 Service Directory header at 0xc00f99e0 Entry = 0xf0430 (0xc00f0430) Rev = 0 Len = 1 PCI BIOS entry at 0x460 DMI header at 0xc00f51a0 Version 2.0 Table at 0xf51ba, 30 entries, 974 bytes Other BIOS signatures found: ACPI: 00000000 $PnP: 000fcee0 Preloaded elf kernel "kernel" at 0xc02f7000. Pentium Pro MTRR support enabled, default memory type is uncacheable Initializing PnP override table Probing for PnP devices: 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 No Plug-n-Play devices were found pci_open(1): mode 1 addr port (0x0cf8) is 0x80005840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=12378086) npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS version 1.2 pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=12378086) pcib0: on motherboard found-> vendor=0x8086, dev=0x1237, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 found-> vendor=0x8086, dev=0x7000, revid=0x01 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 found-> vendor=0x8086, dev=0x7010, revid=0x00 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[0]: type 4, range 32, base 0000e800, size 4 found-> vendor=0x1011, dev=0x0002, revid=0x23 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=14 map[0]: type 4, range 32, base 0000e000, size 7 map[1]: type 1, range 32, base e3800000, size 7 found-> vendor=0x109e, dev=0x0350, revid=0x11 class=04-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=15 map[0]: type 3, range 32, base e7800000, size 12 found-> vendor=0x102b, dev=0x051b, revid=0x00 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[0]: type 3, range 32, base e6000000, size 24 map[1]: type 1, range 32, base e3000000, size 14 map[2]: type 1, range 32, base e2800000, size 23 found-> vendor=0x9004, dev=0x8178, revid=0x00 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[0]: type 4, range 32, base 0000d800, size 8 map[1]: type 1, range 32, base e2000000, size 12 found-> vendor=0x121a, dev=0x0002, revid=0x02 class=04-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[0]: type 3, range 32, base e4000000, size 24 pci0: on pcib0 WARNING: "bktr" is usurping "bktr"'s cdevsw[] isab0: at device 1.0 on pci0 I/O Recovery Timing: 8-bit 3.5 clocks, 16-bit 3.5 clocks Extended BIOS: disabled Lower BIOS: disabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: IRQ11, B: IRQ9, C: IRQ15, D: IRQ14 MB0: disabled, MB1: chip1: at device 1.1 on pci0 Primary IDE: disabled Secondary IDE: disabled de0: irq 14 at device 9.0 on pci0 de0: 21040 [10Mb/s] pass 2.3 de0: address 00:40:c7:94:07:97 bktr0: irq 15 at device 10.0 on pci0 bti2c0: iicbb0: on bti2c0 iicbus0: on iicbb0 master-only iicsmb0: on iicbus0 smbus0: on iicsmb0 smb0: on smbus0 WARNING: "iic" is usurping "iic"'s cdevsw[] iic0: on iicbus0 smbus1: on bti2c0 smb1: on smbus1 brooktree0: PCI bus latency is 32. bktr0: buffer size 3555328, addr 0x530000 bktr: GPIO is 0x00fffffb Hauppauge Model 56304 D Hauppauge WinCast/TV, Temic PAL tuner. vga-pci0: irq 9 at device 11.0 on pci0 ahc0: irq 11 at device 12.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: internal 50 cable is present, internal 68 cable not present ahc0: external cable is present ahc0: BIOS eeprom is present ahc0: High byte termination Enabled ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: Downloading Sequencer Program... 411 instructions downloaded isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 pas0 at port 0x388 irq 10 drq 5 on isa0 snd0: sb0 at port 0x220 irq 7 drq 1 on isa0 snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] isa_compat: didn't get ports for opl opl0 at port 0x388 on isa0 isa_compat: didn't get ports for opl snd0: WARNING: "snd" is usurping "snd"'s cdevsw[] atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 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:ffffffff psm: status ffffffff c030bee4 c07c14c0 psm: status 1a 03 3c psm: status 1a 03 3c psm: status 1a 03 3c psm: status 10 00 64 psm: data c8 c6 51 psm: data 08 00 00 psm: status 00 03 64 psm0: flags 0x100 irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0-51, 3 buttons psm0: config:00000100, flags:00000000, packet size:3 psm0: syncmask:00, syncbits:00 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 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 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 60 4f 50 83 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 60 4f 50 83 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 sc0: on isa0 sc0: VGA <4 virtual consoles, flags=0x200> sc0: fb0 kbd0 ppc: parallel port found at 0x378 ppc0: 0x87 - 0xc 0x0 0xff 0x10 0x0 0x0 0x5 0x0 0x0 0x8a 0x1f 0xc 0x28 0xab 0x0 0x0 0x0 0x0 0x0 0x0 0x7 0x0 0x0 0xfc 0x0 0x1 0xde 0xfe 0xbe 0x23 0x25 0x43 0x62 ppc0: ECP+EPP SPP ppc0 at port 0x378-0x37f irq 7 drq 3 on isa0 ppc0: W83877F chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port using shared irq7. joy0 at port 0x201 on isa0 joy0: joystick sio0: irq maps: 0x41 0x51 0x41 0x41 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio1: irq maps: 0x41 0x49 0x41 0x41 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A BIOS Geometries: 0:022afe3f 0..554=555 cylinders, 0..254=255 heads, 1..63=63 sectors 1:0104fe3f 0..260=261 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Waiting 8 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. de0: enabling 10baseT port ahc0: Selection Timeout on A:1. 1 SCBs aborted ahc0: Selection Timeout on A:3. 1 SCBs aborted ahc0: Selection Timeout on A:4. 1 SCBs aborted ahc0: Selection Timeout on A:5. 1 SCBs aborted ahc0: Selection Timeout on A:8. 1 SCBs aborted ahc0: Selection Timeout on A:9. 1 SCBs aborted ahc0: Selection Timeout on A:10. 1 SCBs aborted ahc0: Selection Timeout on A:11. 1 SCBs aborted ahc0: Selection Timeout on A:12. 1 SCBs aborted ahc0: Selection Timeout on A:13. 1 SCBs aborted ahc0: Selection Timeout on A:14. 1 SCBs aborted ahc0: Selection Timeout on A:15. 1 SCBs aborted (probe6:ahc0:0:6:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe6:ahc0:0:6:0): ILLEGAL REQUEST asc:24,0 (probe6:ahc0:0:6:0): Invalid field in CDB ahc0: target 6 synchronous at 10.0MHz, offset = 0xf ahc0: target 2 using 16bit transfers ahc0: target 2 synchronous at 10.0MHz, offset = 0x8 ahc0: target 0 synchronous at 20.0MHz, offset = 0xf pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number RD3C8551 pass0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled pass1 at ahc0 bus 0 target 2 lun 0 pass1: Fixed Direct Access SCSI-2 device pass1: Serial Number 09061315 pass1: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled pass2 at ahc0 bus 0 target 6 lun 0 pass2: Removable CD-ROM SCSI-2 device pass2: 10.000MB/s transfers (10.000MHz, offset 15) Considering FFS root f/s. changing root device to da0s3a da1 at ahc0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number 09061315 da1: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 2048MB (4194995 512 byte sectors: 255H 63S/T 261C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number RD3C8551 da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) da0s1: type 0x6, start 63, end = 208844, size 208782 : OK da0s2: type 0x5, start 208845, end = 2313359, size 2104515 : OK da0s3: type 0xa5, start 2313360, end = 8916074, size 6602715 : OK da0s5: type 0xb, start 208908, end = 2313359, size 2104452 : OK start_init: trying /sbin/init Linux-ELF exec handler installed (da0:ahc0:0:0:0): tagged openings now 64 (cd0:ahc0:0:6:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ahc0:0:6:0): NOT READY asc:3a,0 (cd0:ahc0:0:6:0): Medium not present cd0 at ahc0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present -- Sun Microsystems Oy PL 102, Niittymäentie 9, 02201 Espoo, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: Tomi.Vainio@Sun.COM +358 9 52556252 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 13:16:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by hub.freebsd.org (Postfix) with ESMTP id 31FF415239 for ; Mon, 19 Jul 1999 13:16:24 -0700 (PDT) (envelope-from ian@whalley.org) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id QAA11320; Mon, 19 Jul 1999 16:16:19 -0400 Received: from whalley.org (FINISTERRE.watson.ibm.com [9.2.36.73] (may be forged)) by mailhub1.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id QAA09774; Mon, 19 Jul 1999 16:16:18 -0400 Message-ID: <3793877C.BD14AF97@whalley.org> Date: Mon, 19 Jul 1999 16:15:56 -0400 From: Ian Whalley Organization: I(a)nSanity Enterprises X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tomppa@sun.fi, freebsd-current@freebsd.org Subject: Re: Unusable PS/2 mouse References: <14227.34008.442998.44420@sun9.sun.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I have tried to use Logitech PS/2 wheel mouse (model M-S48) but >support has been broken for a long time now. I have binded fvwm menus >to mouse + keyboard combinations. If I press keyboard and move mouse >at the time I will always get these errors and keyboard is lost after >this. >Jun 20 21:48:36 cat /kernel: psmintr: out of sync (0000 != 0008). >Jun 20 21:53:26 cat /kernel: psmintr: out of sync (0000 != 0008). >Jun 20 21:53:26 cat /kernel: psmintr: out of sync (0000 != 0008). >If I disable sync check (psm flags 0x100) cursor starts warping around >the screen. Only way to use X at all is to disable sync and not to >use keyboard and mouse at the same time. Do you have a monitor switch? If so, I bet it is a cybex one. Look in the manual for the 'reset mice' control sequence -- that seems to do the trick for me. Best; Ian. -- Ian Whalley, .sig under construction. Email: @ . org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 13:25:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8877215239; Mon, 19 Jul 1999 13:25:38 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id NAA42849; Mon, 19 Jul 1999 13:24:19 -0700 (PDT) Message-ID: <37938972.1CFBAE39@whistle.com> Date: Mon, 19 Jul 1999 13:24:18 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.8-STABLE i386) MIME-Version: 1.0 To: tarkhil@asteroid.svib.ru Cc: John Polstra , current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Soft-updates feedback References: <199907030501.JAA31071@shuttle.svib.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex Povolotsky wrote: > > About a week ago, I've posted a message here and didn't got positive replies. > > The problem is: > > when I use soft-updates on IDE disks (disk on primary master, disk on > secondary master, CD on primary slave), any active disk-using program > (starting Netscape, starting EXMH) causes all other programs literally to stop > for several seconds (well, 20-30 seconds is quite often!). Turning > soft-updates off causes this nastiness to disappear, but also slows down > disk-active processess. > > Alex. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message I saw this behaviour before.. It was with an IDE disk drive running in PIO mode turning on DMA mode for the disk fixed it. I have no idea as to what was goin wrong, however I suggest that you try a kernel from -current as there has been a lot of change in the areas that might cause this sort of thing. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 14: 3:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from sun.fi (sun.fi [193.65.93.1]) by hub.freebsd.org (Postfix) with ESMTP id 4789D14EE7 for ; Mon, 19 Jul 1999 14:03:43 -0700 (PDT) (envelope-from tomppa@sun.fi) Received: from sun9.sun.fi (sun9.sun.fi [193.65.93.9]) by sun.fi (8.8.8/8.8.8) with ESMTP id AAA12910; Tue, 20 Jul 1999 00:03:12 +0300 (EET DST) Received: (from tomppa@localhost) by sun9.sun.fi (8.9.3/8.9.3) id AAA01286; Tue, 20 Jul 1999 00:03:11 +0300 (EET DST) From: Tomi Vainio MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <14227.37519.683581.802751@sun9.sun.fi> Date: Tue, 20 Jul 1999 00:03:11 +0300 (EET DST) To: Ian Whalley Cc: freebsd-current@FreeBSD.ORG Subject: Re: Unusable PS/2 mouse In-Reply-To: <3793877C.BD14AF97@whalley.org> References: <14227.34008.442998.44420@sun9.sun.fi> <3793877C.BD14AF97@whalley.org> X-Mailer: VM 6.67 under 20.4 "Emerald" XEmacs Lucid Reply-To: tomppa@sun.fi Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ian Whalley writes: > > Do you have a monitor switch? If so, I bet it is a cybex one. Look > in the manual for the 'reset mice' control sequence -- that seems to > do the trick for me. > Hi, Yes, I have monitor switch but it's dummy manual one. I removed it completely and now mouse works without problems. It's quite strange this switch will broke mouse if I don't use it and switch just sits between these wires. It also works with other operating systems. Tomppa -- Sun Microsystems Oy PL 102, Niittymäentie 9, 02201 Espoo, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: Tomi.Vainio@Sun.COM +358 9 52556252 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 14:25:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by hub.freebsd.org (Postfix) with ESMTP id 4B1A814EA5 for ; Mon, 19 Jul 1999 14:25:54 -0700 (PDT) (envelope-from ian@whalley.org) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.9.3/8.9.3/05-14-1999) with ESMTP id RAA05188; Mon, 19 Jul 1999 17:25:44 -0400 Received: from whalley.org (FINISTERRE.watson.ibm.com [9.2.36.73] (may be forged)) by mailhub1.watson.ibm.com (8.8.7/Feb-20-98) with ESMTP id RAA09064; Mon, 19 Jul 1999 17:25:43 -0400 Message-ID: <379397BE.EBA9D1F9@whalley.org> Date: Mon, 19 Jul 1999 17:25:18 -0400 From: Ian Whalley Organization: I(a)nSanity Enterprises X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tomppa@sun.fi, freebsd-current@freebsd.org Subject: Re: Unusable PS/2 mouse References: <14227.34008.442998.44420@sun9.sun.fi> <3793877C.BD14AF97@whalley.org> <14227.37519.683581.802751@sun9.sun.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Yes, I have monitor switch but it's dummy manual one. I removed it >completely and now mouse works without problems. It's quite strange >this switch will broke mouse if I don't use it and switch just sits >between these wires. It also works with other operating systems. Well, the Cybex one I have is not really a dummy manual one, although it was cheap! It supports a subset of the standard high-end Cybex control sequences, one of which is 'reset mouse'. The problem springs, I think, from confusion between (Intellimouse) and (!Intellimouse). The box pretends to be an Intellimouse even when you don't have one [or this is what seems to happen in my case], and so FreeBSD detects that you have an Intellimouse. However, then it all goes wrong, and I don't really know why! Best; I. -- Ian Whalley, .sig under construction. Email: @ . org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 14:35:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from sun.fi (sun.fi [193.65.93.1]) by hub.freebsd.org (Postfix) with ESMTP id 82BC5152A2 for ; Mon, 19 Jul 1999 14:35:51 -0700 (PDT) (envelope-from tomppa@sun.fi) Received: from sun9.sun.fi (sun9.sun.fi [193.65.93.9]) by sun.fi (8.8.8/8.8.8) with ESMTP id AAA12959; Tue, 20 Jul 1999 00:34:37 +0300 (EET DST) Received: (from tomppa@localhost) by sun9.sun.fi (8.9.3/8.9.3) id AAA01386; Tue, 20 Jul 1999 00:34:36 +0300 (EET DST) From: Tomi Vainio MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <14227.39404.738278.955010@sun9.sun.fi> Date: Tue, 20 Jul 1999 00:34:36 +0300 (EET DST) To: Ian Whalley Cc: freebsd-current@FreeBSD.ORG Subject: Re: Unusable PS/2 mouse In-Reply-To: <379397BE.EBA9D1F9@whalley.org> References: <14227.34008.442998.44420@sun9.sun.fi> <3793877C.BD14AF97@whalley.org> <14227.37519.683581.802751@sun9.sun.fi> <379397BE.EBA9D1F9@whalley.org> X-Mailer: VM 6.67 under 20.4 "Emerald" XEmacs Lucid Reply-To: tomppa@sun.fi Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ian Whalley writes: > > The problem springs, I think, from confusion between (Intellimouse) and > (!Intellimouse). The box pretends to be an Intellimouse even when you > don't have one [or this is what seems to happen in my case], and so > FreeBSD detects that you have an Intellimouse. However, then it all > goes wrong, and I don't really know why! > My mouse is always detected as a MouseMan+. Here is couple dmesg logs from boots with and without monitor switch. Tomppa --- monitor switch installed --- atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 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:ffffffff psm: status ffffffff c030bee4 c07c14c0 psm: status 1a 03 3c psm: status 1a 03 3c psm: status 1a 03 3c psm: status 10 00 64 psm: data c8 c6 51 psm: data 08 00 00 psm: status 00 03 64 psm0: flags 0x100 irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0-51, 3 buttons psm0: config:00000100, flags:00000000, packet size:3 psm0: syncmask:00, syncbits:00 sc0: fb0 kbd0 psm0: failed to get status (doopen). --- monitor switch installed --- atkbdc0: at port 0x60-0x6f on isa0 atkbd0: 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:0x0, flags:0x3d0000 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 1a 03 3c psm: status 1a 03 3c psm: status 1a 03 3c psm: status 10 00 64 psm: data c8 c6 51 psm: data 08 00 00 psm: status 00 02 64 psm0: flags 0x100 irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0-51, 3 buttons psm0: config:00000100, flags:00000000, packet size:3 psm0: syncmask:00, syncbits:00 sc0: fb0 kbd0 --- monitor switch NOT installed --- atkbdc0: at port 0x60-0x6f on isa0 atkbd0: 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:0x0, flags:0x3d0000 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 1a 03 3c psm: status 1a 03 3c psm: status 1a 03 3c psm: status 10 00 64 psm: data c8 c6 51 psm: data 08 00 00 psm: status 00 02 64 psm0: flags 0x100 irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0-51, 3 buttons psm0: config:00000100, flags:00000000, packet size:3 psm0: syncmask:00, syncbits:00 sc0: fb0 kbd0 -- Sun Microsystems Oy PL 102, Niittymäentie 9, 02201 Espoo, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: Tomi.Vainio@Sun.COM +358 9 52556252 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 15:15:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id A2FD614E93 for ; Mon, 19 Jul 1999 15:15:34 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id WAA52373 for current@freebsd.org; Mon, 19 Jul 1999 22:44:54 +0100 (BST) (envelope-from nik) Date: Mon, 19 Jul 1999 22:44:54 +0100 From: Nik Clayton To: current@freebsd.org Subject: Moving ipf(1) to ipf(8)? Message-ID: <19990719224454.A52115@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How do, docs/7791 is of the opinion that ipf(1) should be moved to ipf(8), to (among other things) be consistent with ipfw(8). Anyone care to comment one way or the other? N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 16:22:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 3303C14CCD for ; Mon, 19 Jul 1999 16:22:27 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id TAA48477; Mon, 19 Jul 1999 19:21:48 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 19 Jul 1999 19:21:47 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Mike Smith Cc: Jason , freebsd-current@FreeBSD.org Subject: Re: Question about MTRR boot message In-Reply-To: <199907191937.MAA00798@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 19 Jul 1999, Mike Smith wrote: > > I wrote the K6-2 MTRR support, but I really don't know how to use it. > > You see, my X server reports: > > (--) SVGA: PCI: NVidia Riva TNT rev 4, Memory @ 0xef000000, 0xcc000000 > > But which do I make uncacheable? > > You don't; let the X server do it. You didn't teach XFree86 to do our MTRR stuff yet, IIRC, did you? > > -- > \\ The mind's the standard \\ Mike Smith > \\ of the man. \\ msmith@freebsd.org > \\ -- Joseph Merrick \\ msmith@cdrom.com > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 16:26:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 8179414CCD; Mon, 19 Jul 1999 16:26:13 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA02088; Mon, 19 Jul 1999 16:20:56 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907192320.QAA02088@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Brian F. Feldman" Cc: Jason , freebsd-current@FreeBSD.org Subject: Re: Question about MTRR boot message In-reply-to: Your message of "Mon, 19 Jul 1999 19:21:47 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jul 1999 16:20:56 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 19 Jul 1999, Mike Smith wrote: > > > > I wrote the K6-2 MTRR support, but I really don't know how to use it. > > > You see, my X server reports: > > > (--) SVGA: PCI: NVidia Riva TNT rev 4, Memory @ 0xef000000, 0xcc000000 > > > But which do I make uncacheable? > > > > You don't; let the X server do it. > > You didn't teach XFree86 to do our MTRR stuff yet, IIRC, did you? The XFree86 folks are doing that. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 17: 5:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 4F94515166 for ; Mon, 19 Jul 1999 17:04:55 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA13832; Tue, 20 Jul 1999 09:34:24 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA75849; Tue, 20 Jul 1999 09:34:20 +0930 (CST) Date: Tue, 20 Jul 1999 09:34:20 +0930 From: Greg Lehey To: Tomi Vainio Cc: freebsd-current@FreeBSD.ORG Subject: Re: Unusable PS/2 mouse Message-ID: <19990720093420.M72885@freebie.lemis.com> References: <14227.34008.442998.44420@sun9.sun.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <14227.34008.442998.44420@sun9.sun.fi>; from Tomi Vainio on Mon, Jul 19, 1999 at 11:04:40PM +0300 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 19 July 1999 at 23:04:40 +0300, Tomi Vainio wrote: > I have tried to use Logitech PS/2 wheel mouse (model M-S48) but > support has been broken for a long time now. I have binded fvwm menus > to mouse + keyboard combinations. If I press keyboard and move mouse > at the time I will always get these errors and keyboard is lost after > this. > Jun 20 21:48:36 cat /kernel: psmintr: out of sync (0000 != 0008). > Jun 20 21:53:26 cat /kernel: psmintr: out of sync (0000 != 0008). > Jun 20 21:53:26 cat /kernel: psmintr: out of sync (0000 != 0008). > If I disable sync check (psm flags 0x100) cursor starts warping around > the screen. Only way to use X at all is to disable sync and not to > use keyboard and mouse at the same time. ISTR there was a fix for this committed recently. Have you tried updating to a really recent -CURRENT? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 17: 6:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 3CE2F15109; Mon, 19 Jul 1999 17:06:02 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA13842; Tue, 20 Jul 1999 09:35:44 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA75864; Tue, 20 Jul 1999 09:35:41 +0930 (CST) Date: Tue, 20 Jul 1999 09:35:41 +0930 From: Greg Lehey To: Julian Elischer Cc: tarkhil@asteroid.svib.ru, John Polstra , current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Soft-updates feedback Message-ID: <19990720093541.N72885@freebie.lemis.com> References: <199907030501.JAA31071@shuttle.svib.ru> <37938972.1CFBAE39@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <37938972.1CFBAE39@whistle.com>; from Julian Elischer on Mon, Jul 19, 1999 at 01:24:18PM -0700 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 19 July 1999 at 13:24:18 -0700, Julian Elischer wrote: > Alex Povolotsky wrote: >> >> About a week ago, I've posted a message here and didn't got positive replies. >> >> The problem is: >> >> when I use soft-updates on IDE disks (disk on primary master, disk on >> secondary master, CD on primary slave), any active disk-using program >> (starting Netscape, starting EXMH) causes all other programs literally to stop >> for several seconds (well, 20-30 seconds is quite often!). Turning >> soft-updates off causes this nastiness to disappear, but also slows down >> disk-active processess. > > I saw this behaviour before.. > It was with an IDE disk drive running in PIO mode > > turning on DMA mode for the disk fixed it. > I have no idea as to what was goin wrong, however I > suggest that you try a kernel from -current as there has been a lot of > change in the areas that might cause this sort of thing. FWIW, there's something funny in the timing of the IDE driver, even in DMA mode. I find in Vinum that I don't get control back from the driver strategy routine until the request has completed. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 18: 5:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from awfulhak.org (dynamic-102.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.102]) by hub.freebsd.org (Postfix) with ESMTP id 675D5150F0; Mon, 19 Jul 1999 18:05:31 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (root@dev.lan.awfulhak.org [172.16.0.5]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA23356; Mon, 19 Jul 1999 23:50:21 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from dev.lan.awfulhak.org (brian@localhost [127.0.0.1]) by dev.lan.awfulhak.org (8.9.3/8.9.3) with ESMTP id XAA64332; Mon, 19 Jul 1999 23:50:20 +0100 (BST) (envelope-from brian@dev.lan.awfulhak.org) Message-Id: <199907192250.XAA64332@dev.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: obituary Cc: "Chris D. Faulhaber" , freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: Problem with cvsup In-reply-to: Your message of "Tue, 20 Jul 1999 00:25:46 +1000." <3793356A.EDC63408@atlas.newcastle.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Jul 1999 23:50:20 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > As I explained to DES, I used pppd because I assumed it would be more > efficient and I was already familiar with pppd configuration. [.....] Interestingly enough, it's exactly as efficient WRT packets being passed out & in to userland. In one instance, it's all done in ppp(8), and in the other, the ipfw code passes the stuff out to natd(8). Of course this doesn't take into account any dodgy coding in ppp(8) :-] > -jake (obituary) Powered by FreeBSD > c9710216@atlas.newcastle.edu.au 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 Mon Jul 19 18:29:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from rebel.net.au (rebel.rebel.net.au [203.20.69.66]) by hub.freebsd.org (Postfix) with ESMTP id BDB9A150CC for ; Mon, 19 Jul 1999 18:29:31 -0700 (PDT) (envelope-from kkenn@rebel.net.au) Received: from 203.20.69.74 (dialup-4.rebel.net.au [203.20.69.74]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id KAA17104 for ; Tue, 20 Jul 1999 10:57:03 +0930 Received: (qmail 4600 invoked from network); 20 Jul 1999 01:10:03 -0000 Received: from localhost (kkenn@127.0.0.1) by localhost with SMTP; 20 Jul 1999 01:10:03 -0000 Date: Tue, 20 Jul 1999 10:40:03 +0930 (CST) From: Kris Kennaway Reply-To: kkenn@rebel.net.au To: Nik Clayton Cc: current@FreeBSD.ORG Subject: Re: Moving ipf(1) to ipf(8)? In-Reply-To: <19990719224454.A52115@catkin.nothing-going-on.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 Mon, 19 Jul 1999, Nik Clayton wrote: > docs/7791 is of the opinion that ipf(1) should be moved to ipf(8), to > (among other things) be consistent with ipfw(8). > > Anyone care to comment one way or the other? Definitely. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 19: 6: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id 9E53D14C05 for ; Mon, 19 Jul 1999 19:06:04 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:cAnu3iDqMoVlpE7EVsIM/y3sjr/c2Iz+@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id LAA32003; Tue, 20 Jul 1999 11:04:26 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id LAA29067; Tue, 20 Jul 1999 11:08:42 +0900 (JST) Message-Id: <199907200208.LAA29067@zodiac.mech.utsunomiya-u.ac.jp> To: tomppa@sun.fi Cc: Ian Whalley , freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Unusable PS/2 mouse In-reply-to: Your message of "Tue, 20 Jul 1999 00:34:36 +0300." <14227.39404.738278.955010@sun9.sun.fi> References: <14227.34008.442998.44420@sun9.sun.fi> <3793877C.BD14AF97@whalley.org> <14227.37519.683581.802751@sun9.sun.fi> <379397BE.EBA9D1F9@whalley.org> <14227.39404.738278.955010@sun9.sun.fi> Date: Tue, 20 Jul 1999 11:08:41 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The problem springs, I think, from confusion between (Intellimouse) and > > (!Intellimouse). The box pretends to be an Intellimouse even when you > > don't have one [or this is what seems to happen in my case], and so > > FreeBSD detects that you have an Intellimouse. However, then it all > > goes wrong, and I don't really know why! > > >My mouse is always detected as a MouseMan+. Here is couple dmesg logs >from boots with and without monitor switch. We have two separate issues here. One is Logitech mouse support in the psm driver. The psm driver had been unable to handle some wheel mice models, including Logitech M-S48, until recently. It was fixed about a week ago both in -CURRENT and -STABLE. So, you should now be able to use your Logitech mouse, detected as MouseMan+, without the flags 0x100. The second is problems related to switch box products. As Ian summarized beautifully, some "intelligent" switch box products erroneously pretend the IntelliMouse is present even when it is not. This leads to data protocol mismatch and you will see the mouse cursor jumps around the screen and "psmintr: out of sync.." messages The dumb mechanical switch box, like the one you are talking about, may also cause problems. When you switch between computers using this type of switch box, the power to the mouse may be momentarily cut! and the mouse will be reset. After reset, the settings the psm driver set up for the mouse will be lost, and may lead to, again, the protocol mismatch problem. After the reset, the mouse will behave as the generic 2/3 button PS/2 mouse. If you don't switch between computers, I guess you won't have a problem. (But, this defeats the reason why you want to have the switch box in the first place!) People often say "I don't have a problem with this mouse and the dumb switch box in other OSes..." This is true, if these OSes do not have specific drivers for your mouse and are treating the mouse as the generic PS/2 mouse without a wheel. But, I suspect if you install mouse drivers from wheel mouse vendors in W*ndows, you will notice the problem when switching between computers. (No, I don't have a switch box here. I am just guessing :-) Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 22: 9: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtprtp.nortel.com (smtprtp.NortelNetworks.com [192.122.117.66]) by hub.freebsd.org (Postfix) with ESMTP id 31D9415086 for ; Mon, 19 Jul 1999 22:08:49 -0700 (PDT) (envelope-from atrens@nortelnetworks.com) Received: from zcars01t by smtprtp.nortel.com; Tue, 20 Jul 1999 01:07:34 -0400 Received: from hcarp00g.ca.nortel.com by zcars01t; Tue, 20 Jul 1999 01:06:54 -0400 Received: from hcarp00g.ca.nortel.com (hcarp00g.ca.nortel.com [47.196.31.114]) by hcarp00g.ca.nortel.com (8.9.3/8.7.3) with ESMTP id BAA00802 for ; Tue, 20 Jul 1999 01:09:25 -0400 (EDT) Date: Tue, 20 Jul 1999 01:09:24 -0400 (EDT) From: "Andrew Atrens" Reply-To: "Andrew Atrens" To: current@freebsd.org Subject: lockmanager panic Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1268117878-932447364=:725" X-Orig: X-Orig: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --0-1268117878-932447364=:725 Content-type: text/plain; charset="us-ascii" Hi All, My first `panic' since 1995 ! - The title says it all. My system is current as of July 19/99, the last working kernel was built on (or about) June 8 - so I guess something broke between then and now. The panic happens sometime after the disks get mounted but before the network starts up. If it's useful I can pepper my `/etc/rc' file with printf()'s. I've attached gdb traceback info and my dmesg output ... If there's any more data you'd like me to forward, just ask. :) Btw, I'll be in meetings until about 3pm EST tomorrow, err today, so won't be checking mail until then. Cheers, Andrew. -- +-- | Andrew Atrens Nortel Networks, Ottawa, Canada. | | All opinions expressed are my own, not those of any employer. | --+ Heller's Law: The first myth of management is that it exists. Johnson's Corollary: Nobody really knows what is going on anywhere within the organization. --0-1268117878-932447364=:725 Content-type: TEXT/PLAIN; charset="US-ASCII"; name="foob" Content-transfer-encoding: BASE64 Content-ID: Content-Description: gdb -k output Content-Disposition: attachment; filename=foob DQojIGdkYiAtayBrZXJuZWwuMSB2bWNvcmUuMQ0KR05VIGdkYiA0LjE4DQpD b3B5cmlnaHQgMTk5OCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4N CkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2Vu ZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUNCndlbGNvbWUgdG8g Y2hhbmdlIGl0IGFuZC9vciBkaXN0cmlidXRlIGNvcGllcyBvZiBpdCB1bmRl ciBjZXJ0YWluIGNvbmRpdGlvbnMuDQpUeXBlICJzaG93IGNvcHlpbmciIHRv IHNlZSB0aGUgY29uZGl0aW9ucy4NClRoZXJlIGlzIGFic29sdXRlbHkgbm8g d2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBk ZXRhaWxzLg0KVGhpcyBHREIgd2FzIGNvbmZpZ3VyZWQgYXMgImkzODYtdW5r bm93bi1mcmVlYnNkIi4uLg0KSWRsZVBURCAzMTkwNzg0DQppbml0aWFsIHBj YiBhdCAyNzhiNjANCnBhbmljc3RyOiBmcm9tIGRlYnVnZ2VyDQpwYW5pYyBt ZXNzYWdlczoNCi0tLQ0KcGFuaWM6IGxvY2ttZ3I6IHBpZCAtMiwgbm90IGV4 Y2x1c2l2ZSBsb2NrIGhvbGRlciAzMCB1bmxvY2tpbmcNCnBhbmljOiBmcm9t IGRlYnVnZ2VyDQoNCmR1bXBpbmcgdG8gZGV2ICgzLDE5NjYwOSksIG9mZnNl dCAyNjIxNzYNCmR1bXAgMTI3IDEyNiAxMjUgMTI0IDEyMyAxMjIgMTIxIDEy MCAxMTkgMTE4IDExNyAxMTYgMTE1IDExNCAxMTMgMTEyIDExMSAxMTAgMTA5 IDEwOCAxMDcgMTA2IDEwNSAxMDQgMTAzIDEwMiAxMDEgMTAwIDk5IDk4IDk3 IDk2IDk1IDk0IDkzIDkyIDkxIDkwIDg5IDg4IDg3IDg2IDg1IDg0IDgzIDgy IDgxIDgwIDc5IDc4IDc3IDc2IDc1IDc0IDczIDcyIDcxIDcwIDY5IDY4IDY3 IDY2IDY1IDY0IDYzIDYyIDYxIDYwIDU5IDU4IDU3IDU2IDU1IDU0IDUzIDUy IDUxIDUwIDQ5IDQ4IDQ3IDQ2IDQ1IDQ0IDQzIDQyIDQxIDQwIDM5IDM4IDM3 IDM2IDM1IDM0IDMzIDMyIDMxIDMwIDI5IDI4IDI3IDI2IDI1IDI0IDIzIDIy IDIxIDIwIDE5IDE4IDE3IDE2IDE1IDE0IDEzIDEyIDExIDEwIDkgOCA3IDYg NSA0IDMgMiAxIDAgDQotLS0NCiMwICBib290IChob3d0bz0yNjApIGF0IC4u Ly4uL2tlcm4va2Vybl9zaHV0ZG93bi5jOjI5MQ0KMjkxICAgICAgICAgICAg ICAgICAgICAgZHVtcHBjYi5wY2JfY3IzID0gcmNyMygpOw0KKGtnZGIpICBi dA0KIzAgIGJvb3QgKGhvd3RvPTI2MCkgYXQgLi4vLi4va2Vybi9rZXJuX3No dXRkb3duLmM6MjkxDQojMSAgMHhjMDEzNmRlMSBpbiBwYW5pYyAoZm10PTB4 YzAyMzU2ZjQgImZyb20gZGVidWdnZXIiKQ0KICAgIGF0IC4uLy4uL2tlcm4v a2Vybl9zaHV0ZG93bi5jOjUwNQ0KIzIgIDB4YzAxMWNiZjUgaW4gZGJfcGFu aWMgKGFkZHI9LTEwNzE2MzU2NDksIGhhdmVfYWRkcj0wLCBjb3VudD0tMSwg DQogICAgbW9kaWY9MHhjMDI1YTY1NCAiIikgYXQgLi4vLi4vZGRiL2RiX2Nv bW1hbmQuYzo0MzQNCiMzICAweGMwMTFjYjkzIGluIGRiX2NvbW1hbmQgKGxh c3RfY21kcD0weGMwMjViN2M4LCBjbWRfdGFibGU9MHhjMDI1YjYyOCwgDQog ICAgYXV4X2NtZF90YWJsZXA9MHhjMDI3NjMwMCkgYXQgLi4vLi4vZGRiL2Ri X2NvbW1hbmQuYzozMzQNCiM0ICAweGMwMTFjYzVhIGluIGRiX2NvbW1hbmRf bG9vcCAoKSBhdCAuLi8uLi9kZGIvZGJfY29tbWFuZC5jOjQ1Ng0KIzUgIDB4 YzAxMWVjOTcgaW4gZGJfdHJhcCAodHlwZT0zLCBjb2RlPTApIGF0IC4uLy4u L2RkYi9kYl90cmFwLmM6NzENCiM2ICAweGMwMjAyMGQ4IGluIGtkYl90cmFw ICh0eXBlPTMsIGNvZGU9MCwgcmVncz0weGMwMjVhNzRjKQ0KICAgIGF0IC4u Ly4uL2kzODYvaTM4Ni9kYl9pbnRlcmZhY2UuYzoxNTcNCiM3ICAweGMwMjBl NzIwIGluIHRyYXAgKGZyYW1lPXt0Zl9mcyA9IDE2LCB0Zl9lcyA9IDE2LCB0 Zl9kcyA9IDE2LCANCiAgICAgIHRmX2VkaSA9IDEwMjQsIHRmX2VzaSA9IDI1 NiwgdGZfZWJwID0gLTEwNzEyNzQwOTIsIHRmX2lzcCA9IC0xMDcxMjc0MTIw LCANCiAgICAgIHRmX2VieCA9IC0xMDcxNDE1OTM2LCB0Zl9lZHggPSAwLCB0 Zl9lY3ggPSAxOTIwLCB0Zl9lYXggPSAxOCwgDQogICAgICB0Zl90cmFwbm8g PSAzLCB0Zl9lcnIgPSAwLCB0Zl9laXAgPSAtMTA3MTYzNTY0OSwgdGZfY3Mg PSA4LCANCiAgICAgIHRmX2VmbGFncyA9IDU4MiwgdGZfZXNwID0gLTEwNzEz MjM2MTcsIHRmX3NzID0gLTEwNzE0MTI5MzN9KQ0KICAgIGF0IC4uLy4uL2kz ODYvaTM4Ni90cmFwLmM6NTM0DQojOCAgMHhjMDIwMjMzZiBpbiBEZWJ1Z2dl ciAobXNnPTB4YzAyMzg5M2IgInBhbmljIikgYXQgbWFjaGluZS9jcHVmdW5j Lmg6NjQNCiM5ICAweGMwMTM2ZGQ4IGluIHBhbmljIChmbXQ9MHhjMDIzN2Q4 MCAibG9ja21ncjogcGlkICVkLCBub3QgJXMgJWQgdW5sb2NraW5nIikNCiAg ICBhdCAuLi8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzo1MDMNCiMxMCAweGMw MTMyODFjIGluIGxvY2ttZ3IgKGxrcD0weGMzMzFjMmM4LCBmbGFncz02LCBp bnRlcmxrcD0weDAsIHA9MHgwKQ0KICAgIGF0IC4uLy4uL2tlcm4va2Vybl9s b2NrLmM6MzkxDQojMTEgMHhjMDFlNDNkMSBpbiByZWxwYnVmIChicD0weGMz MzFjMmEwLCBwZnJlZWNudD0weDApIGF0IC4uLy4uL3N5cy9idWYuaDoyOTgN CiMxMiAweGMwMWU0NTBmIGluIHZtX3BhZ2VyX2NoYWluX2lvZG9uZSAobmJw PTB4YzMzMWMyYTApDQogICAgYXQgLi4vLi4vdm0vdm1fcGFnZXIuYzo1MjUN CiMxMyAweGMwMTU4MGRiIGluIGJpb2RvbmUgKGJwPTB4YzMzMWMyYTApIGF0 IC4uLy4uL2tlcm4vdmZzX2Jpby5jOjI1NzcNCiMxNCAweGMwMWVjYTA5IGlu IGFkX2ludGVycnVwdCAocmVxdWVzdD0weGMwYTE4MWMwKQ0KICAgIGF0IC4u Ly4uL2Rldi9hdGEvYXRhLWRpc2suYzo3MDQNCiMxNSAweGMwMWViN2MxIGlu IGF0YWludHIgKGRhdGE9MHhjMDljNDAwMCkgYXQgLi4vLi4vZGV2L2F0YS9h dGEtYWxsLmM6NTY0DQoNCihrZ2RiKSB1cA0KIzEgIDB4YzAxMzZkZTEgaW4g cGFuaWMgKGZtdD0weGMwMjM1NmY0ICJmcm9tIGRlYnVnZ2VyIikNCiAgICBh dCAuLi8uLi9rZXJuL2tlcm5fc2h1dGRvd24uYzo1MDUNCjUwNSAgICAgICAg ICAgICBib290KGJvb3RvcHQpOw0KKGtnZGIpIHVwDQojMiAgMHhjMDExY2Jm NSBpbiBkYl9wYW5pYyAoYWRkcj0tMTA3MTYzNTY0OSwgaGF2ZV9hZGRyPTAs IGNvdW50PS0xLCANCiAgICBtb2RpZj0weGMwMjVhNjU0ICIiKSBhdCAuLi8u Li9kZGIvZGJfY29tbWFuZC5jOjQzNA0KNDM0ICAgICAgICAgICAgIHBhbmlj KCJmcm9tIGRlYnVnZ2VyIik7DQooa2dkYikgdXANCiMzICAweGMwMTFjYjkz IGluIGRiX2NvbW1hbmQgKGxhc3RfY21kcD0weGMwMjViN2M4LCBjbWRfdGFi bGU9MHhjMDI1YjYyOCwgDQogICAgYXV4X2NtZF90YWJsZXA9MHhjMDI3NjMw MCkgYXQgLi4vLi4vZGRiL2RiX2NvbW1hbmQuYzozMzQNCjMzNCAgICAgICAg ICAgICAgICAgKCpjbWQtPmZjbikoYWRkciwgaGF2ZV9hZGRyLCBjb3VudCwg bW9kaWYpOw0KKGtnZGIpIHVwDQojNCAgMHhjMDExY2M1YSBpbiBkYl9jb21t YW5kX2xvb3AgKCkgYXQgLi4vLi4vZGRiL2RiX2NvbW1hbmQuYzo0NTYNCjQ1 NiAgICAgICAgICAgICAgICAgZGJfY29tbWFuZCgmZGJfbGFzdF9jb21tYW5k LCBkYl9jb21tYW5kX3RhYmxlLA0KKGtnZGIpIHVwDQojNSAgMHhjMDExZWM5 NyBpbiBkYl90cmFwICh0eXBlPTMsIGNvZGU9MCkgYXQgLi4vLi4vZGRiL2Ri X3RyYXAuYzo3MQ0KNzEgICAgICAgICAgICAgICAgICBkYl9jb21tYW5kX2xv b3AoKTsNCihrZ2RiKSB1cA0KIzYgIDB4YzAyMDIwZDggaW4ga2RiX3RyYXAg KHR5cGU9MywgY29kZT0wLCByZWdzPTB4YzAyNWE3NGMpDQogICAgYXQgLi4v Li4vaTM4Ni9pMzg2L2RiX2ludGVyZmFjZS5jOjE1Nw0KMTU3ICAgICAgICAg ICAgICAgICBkYl90cmFwKHR5cGUsIGNvZGUpOw0KKGtnZGIpIHVwDQojNyAg MHhjMDIwZTcyMCBpbiB0cmFwIChmcmFtZT17dGZfZnMgPSAxNiwgdGZfZXMg PSAxNiwgdGZfZHMgPSAxNiwgDQogICAgICB0Zl9lZGkgPSAxMDI0LCB0Zl9l c2kgPSAyNTYsIHRmX2VicCA9IC0xMDcxMjc0MDkyLCB0Zl9pc3AgPSAtMTA3 MTI3NDEyMCwgDQogICAgICB0Zl9lYnggPSAtMTA3MTQxNTkzNiwgdGZfZWR4 ID0gMCwgdGZfZWN4ID0gMTkyMCwgdGZfZWF4ID0gMTgsIA0KICAgICAgdGZf dHJhcG5vID0gMywgdGZfZXJyID0gMCwgdGZfZWlwID0gLTEwNzE2MzU2NDks IHRmX2NzID0gOCwgDQogICAgICB0Zl9lZmxhZ3MgPSA1ODIsIHRmX2VzcCA9 IC0xMDcxMzIzNjE3LCB0Zl9zcyA9IC0xMDcxNDEyOTMzfSkNCiAgICBhdCAu Li8uLi9pMzg2L2kzODYvdHJhcC5jOjUzNA0KNTM0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBpZiAoa2RiX3RyYXAgKHR5cGUsIDAsICZmcmFtZSkp DQooa2dkYikgdXANCiM4ICAweGMwMjAyMzNmIGluIERlYnVnZ2VyIChtc2c9 MHhjMDIzODkzYiAicGFuaWMiKSBhdCBtYWNoaW5lL2NwdWZ1bmMuaDo2NA0K NjQgICAgICAgICAgICAgIF9fYXNtIF9fdm9sYXRpbGUoImludCAkMyIpOw0K KGtnZGIpIHVwDQojOSAgMHhjMDEzNmRkOCBpbiBwYW5pYyAoZm10PTB4YzAy MzdkODAgImxvY2ttZ3I6IHBpZCAlZCwgbm90ICVzICVkIHVubG9ja2luZyIp DQogICAgYXQgLi4vLi4va2Vybi9rZXJuX3NodXRkb3duLmM6NTAzDQo1MDMg ICAgICAgICAgICAgICAgICAgICBEZWJ1Z2dlciAoInBhbmljIik7DQooa2dk YikgbA0KNDk4ICAgICAgICAgICAgIHByaW50ZigibGFwaWMuaWQgPSAlMDh4 XG4iLCBsYXBpYy5pZCk7DQo0OTkgICAgICNlbmRpZg0KNTAwDQo1MDEgICAg ICNpZiBkZWZpbmVkKEREQikNCjUwMiAgICAgICAgICAgICBpZiAoZGVidWdn ZXJfb25fcGFuaWMpDQo1MDMgICAgICAgICAgICAgICAgICAgICBEZWJ1Z2dl ciAoInBhbmljIik7DQo1MDQgICAgICNlbmRpZg0KNTA1ICAgICAgICAgICAg IGJvb3QoYm9vdG9wdCk7DQo1MDYgICAgIH0NCjUwNw0KKGtnZGIpIHVwDQoj MTAgMHhjMDEzMjgxYyBpbiBsb2NrbWdyIChsa3A9MHhjMzMxYzJjOCwgZmxh Z3M9NiwgaW50ZXJsa3A9MHgwLCBwPTB4MCkNCiAgICBhdCAuLi8uLi9rZXJu L2tlcm5fbG9jay5jOjM5MQ0KMzkxICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHBhbmljKCJsb2NrbWdyOiBwaWQgJWQsIG5vdCAlcyAl ZCB1bmxvY2tpbmciLA0KKGtnZGIpIGwNCjM4NiAgICAgICAgICAgICBjYXNl IExLX1JFTEVBU0U6DQozODcgICAgICAgICAgICAgICAgICAgICBpZiAobGtw LT5sa19leGNsdXNpdmVjb3VudCAhPSAwKSB7DQozODggICAgICNpZiAhZGVm aW5lZChNQVhfUEVSRikNCjM4OSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgaWYgKGxrcC0+bGtfbG9ja2hvbGRlciAhPSBwaWQgJiYNCjM5MCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGxrcC0+bGtfbG9ja2hvbGRl ciAhPSBMS19LRVJOUFJPQykNCjM5MSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBwYW5pYygibG9ja21ncjogcGlkICVkLCBub3QgJXMg JWQgdW5sb2NraW5nIiwNCjM5MiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcGlkLCAiZXhjbHVzaXZlIGxvY2sgaG9sZGVyIiwN CjM5MyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bGtwLT5sa19sb2NraG9sZGVyKTsNCjM5NCAgICAgI2VuZGlmDQozOTUgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENPVU5UKHAsIC0xKTsNCihrZ2Ri KSBwcmludCAqbGtwDQokMSA9IHtsa19pbnRlcmxvY2sgPSB7bG9ja19kYXRh ID0gMH0sIGxrX2ZsYWdzID0gMTAyNCwgbGtfc2hhcmVjb3VudCA9IDAsIA0K ICBsa193YWl0Y291bnQgPSAwLCBsa19leGNsdXNpdmVjb3VudCA9IDEsIGxr X3ByaW8gPSAyMCwgDQogIGxrX3dtZXNnID0gMHhjMDIzYWY2MCAiYnVmd2Fp dCIsIGxrX3RpbW8gPSAwLCBsa19sb2NraG9sZGVyID0gMzB9DQooa2dkYikg cHJpbnQgcGlkDQokMiA9IC0yDQooa2dkYikgdXANCiMxMSAweGMwMWU0M2Qx IGluIHJlbHBidWYgKGJwPTB4YzMzMWMyYTAsIHBmcmVlY250PTB4MCkgYXQg Li4vLi4vc3lzL2J1Zi5oOjI5OA0KMjk4ICAgICAgICAgICAgIGxvY2ttZ3Io JihicCktPmJfbG9jaywgTEtfUkVMRUFTRSwgTlVMTCwgY3VycHJvYyk7DQoo a2dkYikgbA0KMjkzICAgICBCVUZfVU5MT0NLKHN0cnVjdCBidWYgKmJwKQ0K Mjk0ICAgICB7DQoyOTUgICAgICAgICAgICAgaW50IHM7DQoyOTYNCjI5NyAg ICAgICAgICAgICBzID0gc3BsYmlvKCk7DQoyOTggICAgICAgICAgICAgbG9j a21ncigmKGJwKS0+Yl9sb2NrLCBMS19SRUxFQVNFLCBOVUxMLCBjdXJwcm9j KTsNCjI5OSAgICAgICAgICAgICBzcGx4KHMpOw0KMzAwICAgICB9DQozMDEN CjMwMiAgICAgLyoNCihrZ2RiKSBwcmludCAqYnANCiQzID0ge2JfaGFzaCA9 IHtsZV9uZXh0ID0gMHgwLCBsZV9wcmV2ID0gMHgwfSwgYl92bmJ1ZnMgPSB7 dHFlX25leHQgPSAweDAsIA0KICAgIHRxZV9wcmV2ID0gMHgwfSwgYl9mcmVl bGlzdCA9IHt0cWVfbmV4dCA9IDB4YzMzMWMwMTAsIA0KICAgIHRxZV9wcmV2 ID0gMHhjMDI5YTk5Y30sIGJfYWN0ID0ge3RxZV9uZXh0ID0gMHgwLCB0cWVf cHJldiA9IDB4YzA5ZGEwMjh9LCANCiAgYl9mbGFncyA9IDUxMiwgYl9xaW5k ZXggPSAwLCBiX3VudXNlZDEgPSAwICdcMDAwJywgYl94ZmxhZ3MgPSAwICdc MDAwJywgDQogIGJfbG9jayA9IHtsa19pbnRlcmxvY2sgPSB7bG9ja19kYXRh ID0gMH0sIGxrX2ZsYWdzID0gMTAyNCwgDQogICAgbGtfc2hhcmVjb3VudCA9 IDAsIGxrX3dhaXRjb3VudCA9IDAsIGxrX2V4Y2x1c2l2ZWNvdW50ID0gMSwg bGtfcHJpbyA9IDIwLCANCiAgICBsa193bWVzZyA9IDB4YzAyM2FmNjAgImJ1 ZndhaXQiLCBsa190aW1vID0gMCwgbGtfbG9ja2hvbGRlciA9IDMwfSwgDQog IGJfZXJyb3IgPSAwLCBiX2J1ZnNpemUgPSA4MTkyLCBiX2Jjb3VudCA9IDgx OTIsIGJfcmVzaWQgPSAwLCANCiAgYl9kZXYgPSAweDNmYzA5LCBiX2RhdGEg PSAweGM2M2MwYTAwICIiLCANCiAgYl9rdmFiYXNlID0gMHhjNjNlMDAwMCA8 QWRkcmVzcyAweGM2M2UwMDAwIG91dCBvZiBib3VuZHM+LCANCiAgYl9rdmFz aXplID0gMTMxMDcyLCBiX2xibGtubyA9IDMxLCBiX2Jsa25vID0gMjU2LCBi X29mZnNldCA9IDI1Mzk1MiwgDQogIGJfaW9kb25lID0gMHhjMDFlNDQ1NCA8 dm1fcGFnZXJfY2hhaW5faW9kb25lPiwgYl9pb2RvbmVfY2hhaW4gPSAweDAs IA0KICBiX3ZwID0gMHgwLCBiX2RpcnR5b2ZmID0gMCwgYl9kaXJ0eWVuZCA9 IDgxOTIsIGJfcmNyZWQgPSAweDAsIGJfd2NyZWQgPSAweDAsIA0KICBiX3Bi bGtubyA9IDg4NTEwNywgYl9zYXZlYWRkciA9IDB4MCwgYl9kcml2ZXIxID0g MHgwLCBiX2RyaXZlcjIgPSAweDAsIA0KICBiX2NhbGxlcjEgPSAweDAsIGJf Y2FsbGVyMiA9IDB4MCwgYl9wYWdlciA9IHtwZ19zcGMgPSAweDAsIHBnX3Jl cXBhZ2UgPSAwfSwgDQogIGJfY2x1c3RlciA9IHtjbHVzdGVyX2hlYWQgPSB7 dHFoX2ZpcnN0ID0gMHhjMzMzZjdhOCwgdHFoX2xhc3QgPSAweGMzMzNmMzM4 fSwgDQogICAgY2x1c3Rlcl9lbnRyeSA9IHt0cWVfbmV4dCA9IDB4YzMzM2Y3 YTgsIHRxZV9wcmV2ID0gMHhjMzMzZjMzOH19LCANCiAgYl9wYWdlcyA9IHsw eGMwNDk4YjAwLCAweGMwNDk4YjMwLCAweGMwNDk3MzYwLCAweGMwNDk3Mzkw LCAweGMwNDk1YmMwLCANCiAgICAweGMwNDk0M2YwLCAweGMwNGI2YzIwLCAw eGMwNDk0NDUwLCAweGMwNDkyYzgwLCAweGMwNDk0NGIwLCAweGMwNDk5ZGMw LCANCiAgICAweGMwNDliNWYwLCAweGMwNDk5ZTIwLCAweGMwNDljZTUwLCAw eGMwNDliNjgwLCAweGMwNDk5ZWIwLCANCiAgICAweDAgPHJlcGVhdHMgMTYg dGltZXM+fSwgYl9ucGFnZXMgPSAxMCwgYl9kZXAgPSB7bGhfZmlyc3QgPSAw eDB9LCANCiAgYl9jaGFpbiA9IHtwYXJlbnQgPSAweDAsIGNvdW50ID0gMH19 DQooa2dkYikgcHJpbnQgY3VycHJvYw0KJDQgPSAwDQooa2dkYikgcHJpbnQg cw0KJDUgPSAxMDc0MzE1MzI4DQooa2dkYikgdXANCiMxMiAweGMwMWU0NTBm IGluIHZtX3BhZ2VyX2NoYWluX2lvZG9uZSAobmJwPTB4YzMzMWMyYTApDQog ICAgYXQgLi4vLi4vdm0vdm1fcGFnZXIuYzo1MjUNCjUyNSAgICAgICAgICAg ICByZWxwYnVmKG5icCwgTlVMTCk7DQooa2dkYikgbA0KNTIwICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBiaW9kb25lKGJwKTsNCjUyMSAgICAgICAg ICAgICAgICAgICAgIH0NCjUyMiAgICAgICAgICAgICB9DQo1MjMgICAgICAg ICAgICAgbmJwLT5iX2ZsYWdzIHw9IEJfRE9ORTsNCjUyNCAgICAgICAgICAg ICBuYnAtPmJfZmxhZ3MgJj0gfkJfQVNZTkM7DQo1MjUgICAgICAgICAgICAg cmVscGJ1ZihuYnAsIE5VTEwpOw0KNTI2ICAgICB9DQo1MjcNCjUyOCAgICAg LyoNCjUyOSAgICAgICogICAgICBnZXRjaGFpbmJ1ZjoNCihrZ2RiKSBwcmlu dCAqbmJwDQokNiA9IHtiX2hhc2ggPSB7bGVfbmV4dCA9IDB4MCwgbGVfcHJl diA9IDB4MH0sIGJfdm5idWZzID0ge3RxZV9uZXh0ID0gMHgwLCANCiAgICB0 cWVfcHJldiA9IDB4MH0sIGJfZnJlZWxpc3QgPSB7dHFlX25leHQgPSAweGMz MzFjMDEwLCANCiAgICB0cWVfcHJldiA9IDB4YzAyOWE5OWN9LCBiX2FjdCA9 IHt0cWVfbmV4dCA9IDB4MCwgdHFlX3ByZXYgPSAweGMwOWRhMDI4fSwgDQog IGJfZmxhZ3MgPSA1MTIsIGJfcWluZGV4ID0gMCwgYl91bnVzZWQxID0gMCAn XDAwMCcsIGJfeGZsYWdzID0gMCAnXDAwMCcsIA0KICBiX2xvY2sgPSB7bGtf aW50ZXJsb2NrID0ge2xvY2tfZGF0YSA9IDB9LCBsa19mbGFncyA9IDEwMjQs IA0KICAgIGxrX3NoYXJlY291bnQgPSAwLCBsa193YWl0Y291bnQgPSAwLCBs a19leGNsdXNpdmVjb3VudCA9IDEsIGxrX3ByaW8gPSAyMCwgDQogICAgbGtf d21lc2cgPSAweGMwMjNhZjYwICJidWZ3YWl0IiwgbGtfdGltbyA9IDAsIGxr X2xvY2tob2xkZXIgPSAzMH0sIA0KICBiX2Vycm9yID0gMCwgYl9idWZzaXpl ID0gODE5MiwgYl9iY291bnQgPSA4MTkyLCBiX3Jlc2lkID0gMCwgDQogIGJf ZGV2ID0gMHgzZmMwOSwgYl9kYXRhID0gMHhjNjNjMGEwMCAiIiwgDQogIGJf a3ZhYmFzZSA9IDB4YzYzZTAwMDAgPEFkZHJlc3MgMHhjNjNlMDAwMCBvdXQg b2YgYm91bmRzPiwgDQogIGJfa3Zhc2l6ZSA9IDEzMTA3MiwgYl9sYmxrbm8g PSAzMSwgYl9ibGtubyA9IDI1NiwgYl9vZmZzZXQgPSAyNTM5NTIsIA0KICBi X2lvZG9uZSA9IDB4YzAxZTQ0NTQgPHZtX3BhZ2VyX2NoYWluX2lvZG9uZT4s IGJfaW9kb25lX2NoYWluID0gMHgwLCANCiAgYl92cCA9IDB4MCwgYl9kaXJ0 eW9mZiA9IDAsIGJfZGlydHllbmQgPSA4MTkyLCBiX3JjcmVkID0gMHgwLCBi X3djcmVkID0gMHgwLCANCiAgYl9wYmxrbm8gPSA4ODUxMDcsIGJfc2F2ZWFk ZHIgPSAweDAsIGJfZHJpdmVyMSA9IDB4MCwgYl9kcml2ZXIyID0gMHgwLCAN CiAgYl9jYWxsZXIxID0gMHgwLCBiX2NhbGxlcjIgPSAweDAsIGJfcGFnZXIg PSB7cGdfc3BjID0gMHgwLCBwZ19yZXFwYWdlID0gMH0sIA0KICBiX2NsdXN0 ZXIgPSB7Y2x1c3Rlcl9oZWFkID0ge3RxaF9maXJzdCA9IDB4YzMzM2Y3YTgs IHRxaF9sYXN0ID0gMHhjMzMzZjMzOH0sIA0KICAgIGNsdXN0ZXJfZW50cnkg PSB7dHFlX25leHQgPSAweGMzMzNmN2E4LCB0cWVfcHJldiA9IDB4YzMzM2Yz Mzh9fSwgDQogIGJfcGFnZXMgPSB7MHhjMDQ5OGIwMCwgMHhjMDQ5OGIzMCwg MHhjMDQ5NzM2MCwgMHhjMDQ5NzM5MCwgMHhjMDQ5NWJjMCwgDQogICAgMHhj MDQ5NDNmMCwgMHhjMDRiNmMyMCwgMHhjMDQ5NDQ1MCwgMHhjMDQ5MmM4MCwg MHhjMDQ5NDRiMCwgMHhjMDQ5OWRjMCwgDQogICAgMHhjMDQ5YjVmMCwgMHhj MDQ5OWUyMCwgMHhjMDQ5Y2U1MCwgMHhjMDQ5YjY4MCwgMHhjMDQ5OWViMCwg DQogICAgMHgwIDxyZXBlYXRzIDE2IHRpbWVzPn0sIGJfbnBhZ2VzID0gMTAs IGJfZGVwID0ge2xoX2ZpcnN0ID0gMHgwfSwgDQogIGJfY2hhaW4gPSB7cGFy ZW50ID0gMHgwLCBjb3VudCA9IDB9fQ0KKGtnZGIpIHByaW50ICpicA0KJDcg PSB7Yl9oYXNoID0ge2xlX25leHQgPSAweDAsIGxlX3ByZXYgPSAweDB9LCBi X3ZuYnVmcyA9IHt0cWVfbmV4dCA9IDB4MCwgDQogICAgdHFlX3ByZXYgPSAw eDB9LCBiX2ZyZWVsaXN0ID0ge3RxZV9uZXh0ID0gMHhjMzMxYzJhMCwgDQog ICAgdHFlX3ByZXYgPSAweGMwMjlhOTljfSwgYl9hY3QgPSB7dHFlX25leHQg PSAweDAsIHRxZV9wcmV2ID0gMHhjMDlkYTIyOH0sIA0KICBiX2ZsYWdzID0g MjYyMjA4LCBiX3FpbmRleCA9IDAsIGJfdW51c2VkMSA9IDAgJ1wwMDAnLCBi X3hmbGFncyA9IDAgJ1wwMDAnLCANCiAgYl9sb2NrID0ge2xrX2ludGVybG9j ayA9IHtsb2NrX2RhdGEgPSAwfSwgbGtfZmxhZ3MgPSAxMDI0LCANCiAgICBs a19zaGFyZWNvdW50ID0gMCwgbGtfd2FpdGNvdW50ID0gMCwgbGtfZXhjbHVz aXZlY291bnQgPSAxLCBsa19wcmlvID0gMjAsIA0KICAgIGxrX3dtZXNnID0g MHhjMDIzYWY2MCAiYnVmd2FpdCIsIGxrX3RpbW8gPSAwLCBsa19sb2NraG9s ZGVyID0gMzB9LCANCiAgYl9lcnJvciA9IDAsIGJfYnVmc2l6ZSA9IDgxOTIs IGJfYmNvdW50ID0gODE5MiwgYl9yZXNpZCA9IDAsIGJfZGV2ID0gMHhkNDAy LCANCiAgYl9kYXRhID0gMHhjNjNjMGEwMCAiIiwgYl9rdmFiYXNlID0gMHhj NjNjMDAwMCAiIiwgYl9rdmFzaXplID0gMTMxMDcyLCANCiAgYl9sYmxrbm8g PSAzMTY4MCwgYl9ibGtubyA9IDAsIGJfb2Zmc2V0ID0gMCwgDQogIGJfaW9k b25lID0gMHhjMDEzNDdhNCA8cGh5c3dha2V1cD4sIGJfaW9kb25lX2NoYWlu ID0gMHgwLCBiX3ZwID0gMHgwLCANCiAgYl9kaXJ0eW9mZiA9IDAsIGJfZGly dHllbmQgPSAwLCBiX3JjcmVkID0gMHgwLCBiX3djcmVkID0gMHgwLCBiX3Bi bGtubyA9IDAsIA0KICBiX3NhdmVhZGRyID0gMHg4MDY4YTAwLCBiX2RyaXZl cjEgPSAweDAsIGJfZHJpdmVyMiA9IDB4MCwgYl9jYWxsZXIxID0gMHgwLCAN CiAgYl9jYWxsZXIyID0gMHgwLCBiX3BhZ2VyID0ge3BnX3NwYyA9IDB4MCwg cGdfcmVxcGFnZSA9IDB9LCBiX2NsdXN0ZXIgPSB7DQogICAgY2x1c3Rlcl9o ZWFkID0ge3RxaF9maXJzdCA9IDB4YzMzM2YxNDAsIHRxaF9sYXN0ID0gMHhj MzMzZjBhOH0sIA0KICAgIGNsdXN0ZXJfZW50cnkgPSB7dHFlX25leHQgPSAw eGMzMzNmMTQwLCB0cWVfcHJldiA9IDB4YzMzM2YwYTh9fSwgDQogIGJfcGFn ZXMgPSB7MHhjMDQ5MmNlMCwgMHhjMDQ5NWQxMCwgMHhjMDQ4NTU0MCwgMHhj MDQ5NWQ3MCwgMHhjMDQ5ODMyMCwgDQogICAgMHhjMDQ5NmI1MCwgMHhjMDQ5 YjM4MCwgMHhjMDQ5Y2JiMCwgMHhjMDU2ZTY0MCwgMHhjMDU2ZTY3MCwgMHhj MDU2ZTZhMCwgDQogICAgMHhjMDU2Y2VkMCwgMHhjMDU2YjcwMCwgMHhjMDU2 Y2YzMCwgMHhjMDU2Y2Y2MCwgMHhjMDU2Yjc5MCwgDQogICAgMHgwIDxyZXBl YXRzIDE2IHRpbWVzPn0sIGJfbnBhZ2VzID0gNCwgYl9kZXAgPSB7bGhfZmly c3QgPSAweDB9LCANCiAgYl9jaGFpbiA9IHtwYXJlbnQgPSAweDAsIGNvdW50 ID0gMH19DQooa2dkYikgcHJpbnQgbmJwDQokOCA9IChzdHJ1Y3QgYnVmICop IDB4YzMzMWMyYTANCihrZ2RiKSBwcmludCBicA0KJDkgPSAoc3RydWN0IGJ1 ZiAqKSAweGMzMzFjMTU4DQooa2dkYikgdXANCiMxMyAweGMwMTU4MGRiIGlu IGJpb2RvbmUgKGJwPTB4YzMzMWMyYTApIGF0IC4uLy4uL2tlcm4vdmZzX2Jp by5jOjI1NzcNCjI1NzcgICAgICAgICAgICAgICAgICAgICgqYnAtPmJfaW9k b25lKSAoYnApOw0KKGtnZGIpIGwNCjI1NzIgICAgICAgICAgICB9DQoyNTcz DQoyNTc0ICAgICAgICAgICAgLyogY2FsbCBvcHRpb25hbCBjb21wbGV0aW9u IGZ1bmN0aW9uIGlmIHJlcXVlc3RlZCAqLw0KMjU3NSAgICAgICAgICAgIGlm IChicC0+Yl9mbGFncyAmIEJfQ0FMTCkgew0KMjU3NiAgICAgICAgICAgICAg ICAgICAgYnAtPmJfZmxhZ3MgJj0gfkJfQ0FMTDsNCjI1NzcgICAgICAgICAg ICAgICAgICAgICgqYnAtPmJfaW9kb25lKSAoYnApOw0KMjU3OCAgICAgICAg ICAgICAgICAgICAgc3BseChzKTsNCjI1NzkgICAgICAgICAgICAgICAgICAg IHJldHVybjsNCjI1ODAgICAgICAgICAgICB9DQoyNTgxICAgICAgICAgICAg aWYgKExJU1RfRklSU1QoJmJwLT5iX2RlcCkgIT0gTlVMTCAmJiBiaW9vcHMu aW9fY29tcGxldGUpDQooa2dkYikgcHJpbnQgYnANCiQxMCA9IChzdHJ1Y3Qg YnVmICopIDB4YzMzMWMyYTANCihrZ2RiKSBwcmludCAqYnVmDQokMTEgPSB7 Yl9oYXNoID0ge2xlX25leHQgPSAweDAsIGxlX3ByZXYgPSAweGMzM2MzNDhj fSwgYl92bmJ1ZnMgPSB7DQogICAgdHFlX25leHQgPSAweDAsIHRxZV9wcmV2 ID0gMHhjMzMxZDliOH0sIGJfZnJlZWxpc3QgPSB7DQogICAgdHFlX25leHQg PSAweGMzMzNkMjgwLCB0cWVfcHJldiA9IDB4YzMzMWQ5YzB9LCBiX2FjdCA9 IHt0cWVfbmV4dCA9IDB4MCwgDQogICAgdHFlX3ByZXYgPSAweGMwOWRhMjI4 fSwgYl9mbGFncyA9IDEzNTMyOCwgYl9xaW5kZXggPSAzLCANCiAgYl91bnVz ZWQxID0gMCAnXDAwMCcsIGJfeGZsYWdzID0gMSAnXDAwMScsIGJfbG9jayA9 IHtsa19pbnRlcmxvY2sgPSB7DQogICAgICBsb2NrX2RhdGEgPSAwfSwgbGtf ZmxhZ3MgPSAwLCBsa19zaGFyZWNvdW50ID0gMCwgbGtfd2FpdGNvdW50ID0g MCwgDQogICAgbGtfZXhjbHVzaXZlY291bnQgPSAwLCBsa19wcmlvID0gMjAs IGxrX3dtZXNnID0gMHhjMDIzYWY2MCAiYnVmd2FpdCIsIA0KICAgIGxrX3Rp bW8gPSAwLCBsa19sb2NraG9sZGVyID0gLTF9LCBiX2Vycm9yID0gMCwgYl9i dWZzaXplID0gODE5MiwgDQogIGJfYmNvdW50ID0gODE5MiwgYl9yZXNpZCA9 IDAsIGJfZGV2ID0gMHgzZmMwMCwgDQogIGJfZGF0YSA9IDB4YzMzY2QwMDAg IiRcMjAxXDAwMSIsIGJfa3ZhYmFzZSA9IDB4YzMzY2QwMDAgIiRcMjAxXDAw MSIsIA0KICBiX2t2YXNpemUgPSA4MTkyLCBiX2xibGtubyA9IDI0MCwgYl9i bGtubyA9IDI0MCwgYl9vZmZzZXQgPSAxMjI4ODAsIA0KICBiX2lvZG9uZSA9 IDAsIGJfaW9kb25lX2NoYWluID0gMHgwLCBiX3ZwID0gMHhjNzYwY2VjMCwg Yl9kaXJ0eW9mZiA9IDAsIA0KICBiX2RpcnR5ZW5kID0gMCwgYl9yY3JlZCA9 IDB4MCwgYl93Y3JlZCA9IDB4MCwgYl9wYmxrbm8gPSA4MzU2MjAsIA0KICBi X3NhdmVhZGRyID0gMHgwLCBiX2RyaXZlcjEgPSAweDAsIGJfZHJpdmVyMiA9 IDB4MCwgYl9jYWxsZXIxID0gMHgwLCANCiAgYl9jYWxsZXIyID0gMHgwLCBi X3BhZ2VyID0ge3BnX3NwYyA9IDB4MCwgcGdfcmVxcGFnZSA9IDB9LCBiX2Ns dXN0ZXIgPSB7DQogICAgY2x1c3Rlcl9oZWFkID0ge3RxaF9maXJzdCA9IDB4 MCwgdHFoX2xhc3QgPSAweDB9LCBjbHVzdGVyX2VudHJ5ID0gew0KICAgICAg dHFlX25leHQgPSAweDAsIHRxZV9wcmV2ID0gMHgwfX0sIGJfcGFnZXMgPSB7 MHhjMDRlMmU3MCwgMHhjMDRlMmVhMCwgDQogICAgMHgwIDxyZXBlYXRzIDMw IHRpbWVzPn0sIGJfbnBhZ2VzID0gMiwgYl9kZXAgPSB7bGhfZmlyc3QgPSAw eDB9LCANCiAgYl9jaGFpbiA9IHtwYXJlbnQgPSAweDAsIGNvdW50ID0gMH19 DQooa2dkYikgcHJpbnQgcw0KJDEyID0gMTA3NDMxNTMyOA0KKGtnZGIpIHVw DQojMTQgMHhjMDFlY2EwOSBpbiBhZF9pbnRlcnJ1cHQgKHJlcXVlc3Q9MHhj MGExODFjMCkNCiAgICBhdCAuLi8uLi9kZXYvYXRhL2F0YS1kaXNrLmM6NzA0 DQo3MDQgICAgICAgICAgICAgYmlvZG9uZShyZXF1ZXN0LT5icCk7DQooa2dk YikgbA0KNjk5ICAgICAgICAgICAgICAgICB9DQo3MDAgICAgICAgICAgICAg fQ0KNzAxDQo3MDIgICAgICAgICAgICAgVEFJTFFfUkVNT1ZFKCZhZHAtPmNv bnRyb2xsZXItPmF0YV9xdWV1ZSwgcmVxdWVzdCwgY2hhaW4pOw0KNzAzICAg ICAgICAgICAgIHJlcXVlc3QtPmJwLT5iX3Jlc2lkID0gcmVxdWVzdC0+Ynl0 ZWNvdW50Ow0KNzA0ICAgICAgICAgICAgIGJpb2RvbmUocmVxdWVzdC0+YnAp Ow0KNzA1ICAgICAgICAgICAgIGRldnN0YXRfZW5kX3RyYW5zYWN0aW9uKCZh ZHAtPnN0YXRzLCByZXF1ZXN0LT5kb25lY291bnQsDQo3MDYgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgREVWU1RBVF9UQUdfTk9ORSwN CjcwNyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAocmVx dWVzdC0+ZmxhZ3MgJiBBUl9GX1JFQUQpID8gDQo3MDggICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgREVWU1RBVF9SRUFEIDogREVWU1RB VF9XUklURSk7DQooa2dkYikgcHJpbnQgcmVxdWVzdA0KJDEzID0gKHN0cnVj dCBhZF9yZXF1ZXN0ICopIDB4YzBhMTgxYzANCihrZ2RiKSBwcmludCAqcmVx dWVzdA0KJDE0ID0ge2RldmljZSA9IDB4YzA5ZGEwMDAsIGJsb2NrYWRkciA9 IDg4NTEwNywgYnl0ZWNvdW50ID0gMCwgDQogIGRvbmVjb3VudCA9IDgxOTIs IGN1cnJlbnRzaXplID0gODE5MiwgcmVzdWx0ID0gMCwgZmxhZ3MgPSA0LCAN CiAgZGF0YSA9IDB4YzYzYzBhMDAgIiIsIGJwID0gMHhjMzMxYzJhMCwgdGFn ID0gMCAnXDAwMCcsIGNoYWluID0gew0KICAgIHRxZV9uZXh0ID0gMHgwLCB0 cWVfcHJldiA9IDB4YzA5YzQwMzB9fQ0KKGtnZGIpIHByaW50IGNoYWluDQpO byBzeW1ib2wgImNoYWluIiBpbiBjdXJyZW50IGNvbnRleHQuDQooa2dkYikg cHJpbnQgYWRwDQokMTUgPSAoc3RydWN0IGFkX3NvZnRjICopIDB4YzA5ZGEw MDANCihrZ2RiKSBwcmludCAqYWRwDQokMTYgPSB7Y29udHJvbGxlciA9IDB4 YzA5YzQwMDAsIGF0YV9wYXJtID0gMHhjMGEwOGYwMCwgc2xpY2VzID0gMHhj MGExYTAwMCwgDQogIHVuaXQgPSAxNiwgbHVuID0gMSwgY3lsaW5kZXJzID0g MTYzODMsIGhlYWRzID0gMTYgJ1wwMjAnLCBzZWN0b3JzID0gNjMgJz8nLCAN CiAgdG90YWxfc2VjcyA9IDE2NTE0MDY0LCB0cmFuc2ZlcnNpemUgPSA4MTky LCBudW1fdGFncyA9IDAsIGZsYWdzID0gMTAsIA0KICBxdWV1ZSA9IHtxdWV1 ZSA9IHt0cWhfZmlyc3QgPSAweDAsIHRxaF9sYXN0ID0gMHhjMDlkYTAyOH0s IA0KICAgIGxhc3RfcGJsa25vID0gODg1MTA3LCBpbnNlcnRfcG9pbnQgPSAw eDAsIHN3aXRjaF9wb2ludCA9IDB4MH0sIHN0YXRzID0gew0KICAgIGRldl9s aW5rcyA9IHtzdHFlX25leHQgPSAweGMwYTA4ZDAwfSwgZGV2aWNlX251bWJl ciA9IDIsIA0KICAgIGRldmljZV9uYW1lID0gImFkIiwgJ1wwMDAnIDxyZXBl YXRzIDEzIHRpbWVzPiwgdW5pdF9udW1iZXIgPSAxLCANCiAgICBieXRlc193 cml0dGVuID0gOTIxNiwgYnl0ZXNfcmVhZCA9IDE0NTk3MTIsIG51bV9yZWFk cyA9IDI0NywgDQogICAgbnVtX3dyaXRlcyA9IDQsIG51bV9vdGhlciA9IDAs IGJ1c3lfY291bnQgPSAxLCBibG9ja19zaXplID0gNTEyLCANCiAgICB0YWdf dHlwZXMgPSB7MCwgMCwgMH0sIGRldl9jcmVhdGlvbl90aW1lID0ge3R2X3Nl YyA9IDIsIHR2X3VzZWMgPSAyNzU2NX0sIA0KICAgIGJ1c3lfdGltZSA9IHt0 dl9zZWMgPSAyLCB0dl91c2VjID0gMTkwMDI3fSwgc3RhcnRfdGltZSA9IHt0 dl9zZWMgPSAyMywgDQogICAgICB0dl91c2VjID0gNTk3ODM3fSwgbGFzdF9j b21wX3RpbWUgPSB7dHZfc2VjID0gMTMsIHR2X3VzZWMgPSA2NzcwM30sIA0K ICAgIGZsYWdzID0gREVWU1RBVF9OT19PUkRFUkVEX1RBR1MsIGRldmljZV90 eXBlID0gREVWU1RBVF9UWVBFX0lGX0lERSwgDQogICAgcHJpb3JpdHkgPSAz ODR9fQ0KKGtnZGIpIHVwDQojMTUgMHhjMDFlYjdjMSBpbiBhdGFpbnRyIChk YXRhPTB4YzA5YzQwMDApIGF0IC4uLy4uL2Rldi9hdGEvYXRhLWFsbC5jOjU2 NA0KNTY0ICAgICAgICAgICAgICAgICBpZiAoYWRfaW50ZXJydXB0KGFkX3Jl cXVlc3QpID09IEFUQV9PUF9DT05USU5VRVMpDQooa2dkYikgbA0KNTU5ICAg ICAgICAgLyogZmluZCAmIGNhbGwgdGhlIHJlc3BvbnNpYmxlIGRyaXZlciB0 byBwcm9jZXNzIHRoaXMgaW50ZXJydXB0ICovDQo1NjAgICAgICAgICBzd2l0 Y2ggKHNjcC0+YWN0aXZlKSB7DQo1NjEgICAgICNpZiBOQVRBRElTSyA+IDAN CjU2MiAgICAgICAgIGNhc2UgQVRBX0FDVElWRV9BVEE6DQo1NjMgICAgICAg ICAgICAgaWYgKChhZF9yZXF1ZXN0ID0gVEFJTFFfRklSU1QoJnNjcC0+YXRh X3F1ZXVlKSkpDQo1NjQgICAgICAgICAgICAgICAgIGlmIChhZF9pbnRlcnJ1 cHQoYWRfcmVxdWVzdCkgPT0gQVRBX09QX0NPTlRJTlVFUykNCjU2NSAgICAg ICAgICAgICAgICAgICAgIHJldHVybjsNCjU2NiAgICAgICAgICAgICBicmVh azsNCjU2NyAgICAgI2VuZGlmDQo1NjggICAgICAgICBjYXNlIEFUQV9BQ1RJ VkVfQVRBUEk6DQooa2dkYikgcHJpbnQgc2NwDQokMTcgPSAoc3RydWN0IGF0 YV9zb2Z0YyAqKSAweGMwOWM0MDAwDQooa2dkYikgcHJpbnQgKnNjcA0KJDE4 ID0ge3VuaXQgPSAwLCBsdW4gPSAwLCBkZXYgPSAweGMwOWM0MzAwLCBpb2Fk ZHIgPSA0OTYsIGFsdGlvYWRkciA9IDEwMTQsIA0KICBibWFkZHIgPSA1MzI0 OCwgZG1hdGFiID0gezB4YzBhMDcwMDAsIDB4YzBhMDkwMDB9LCBmbGFncyA9 IDAsIGRldmljZXMgPSAzLCANCiAgc3RhdHVzID0gODggJ1gnLCBlcnJvciA9 IDAgJ1wwMDAnLCBhY3RpdmUgPSAzLCBhdGFfcXVldWUgPSB7dHFoX2ZpcnN0 ID0gMHgwLCANCiAgICB0cWhfbGFzdCA9IDB4YzA5YzQwMzB9LCBhdGFwaV9x dWV1ZSA9IHt0cWhfZmlyc3QgPSAweDAsIA0KICAgIHRxaF9sYXN0ID0gMHhj MDljNDAzOH19DQooa2dkYikgcHJpbnQgYWRfcmVxdWVzdA0KJDE5ID0gKHN0 cnVjdCBhZF9yZXF1ZXN0ICopIDB4MA0KKGtnZGIpIHVwDQpJbml0aWFsIGZy YW1lIHNlbGVjdGVkOyB5b3UgY2Fubm90IGdvIHVwLg0KKGtnZGIpIHF1aXQN Cg0KDQo= --0-1268117878-932447364=:725 Content-type: TEXT/PLAIN; charset="US-ASCII"; name="foob2" Content-transfer-encoding: BASE64 Content-ID: Content-Description: dmesg output Content-Disposition: attachment; filename=foob2 Q29weXJpZ2h0IChjKSAxOTkyLTE5OTkgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk4MiwgMTk4NiwgMTk4OSwgMTk5MSwgMTk5Mw0K CVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEu IEFsbCByaWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIDQuMC1DVVJSRU5UICMy OiBUdWUgSnVsIDIwIDAwOjIzOjAxIEVEVCAxOTk5DQogICAgcm9vdEBjaHVy Y2hpbGw6L3Vzci9sb2NhbC9zcmMvY3ZzL3N5cy9jb21waWxlL0NIVVJDSElM TA0KVGltZWNvdW50ZXIgImk4MjU0IiAgZnJlcXVlbmN5IDExOTMxODIgSHoN ClRpbWVjb3VudGVyICJUU0MiICBmcmVxdWVuY3kgMzMyNzU1MzgyIEh6DQpD UFU6IEFNRC1LNih0bSkgM0QgcHJvY2Vzc29yICgzMzIuNzYtTUh6IDU4Ni1j bGFzcyBDUFUpDQogIE9yaWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9IDB4 NThjICBTdGVwcGluZyA9IDEyDQogIEZlYXR1cmVzPTB4ODAyMWJmPEZQVSxW TUUsREUsUFNFLFRTQyxNU1IsTUNFLENYOCxQR0UsTU1YPg0KICBBTUQgRmVh dHVyZXM9MHg4MDAwMDgwMDxTWVNDQUxMLDNETm93IT4NCnJlYWwgbWVtb3J5 ICA9IDEzNDIwMTM0NCAoMTMxMDU2SyBieXRlcykNCmF2YWlsIG1lbW9yeSA9 IDEyNzMyODI1NiAoMTI0MzQ0SyBieXRlcykNClByZWxvYWRlZCBlbGYga2Vy bmVsICJrZXJuZWwiIGF0IDB4YzAyZjkwMDAuDQpQcmVsb2FkZWQgZWxmIG1v ZHVsZSAic3BsYXNoX2JtcC5rbyIgYXQgMHhjMDJmOTA5Yy4NClByZWxvYWRl ZCBzcGxhc2hfaW1hZ2VfZGF0YSAiL2Jvb3QvZm9vYnMuYm1wIiBhdCAweGMw MmY5MTQwLg0KVkVTQTogdjIuMCwgNDA5NmsgbWVtb3J5LCBmbGFnczoweDAs IG1vZGUgdGFibGU6MHhjMDI5OTE2MiAoMTAwMDAyMikNClZFU0E6IEFUSSBN QUNINjQNCks2LWZhbWlseSBNVFJSIHN1cHBvcnQgZW5hYmxlZCAoMiByZWdp c3RlcnMpDQpQcm9iaW5nIGZvciBQblAgZGV2aWNlczoNCkNTTiAxIFZlbmRv ciBJRDogWU1IMDAyMCBbMHgyMDAwYTg2NV0gU2VyaWFsIDB4ZmZmZmZmZmYg Q29tcCBJRDogUE5QYjAyZiBbMHgyZmIwZDA0MV0NCm1zc19hdHRhY2ggPFlh bWFoYSBTQTI+MSBhdCAweDUzMCBpcnEgNSBkbWEgMDoxIGZsYWdzIDB4MTEN CnNldHRpbmcgdXAgeWFtYWhhIHJlZ2lzdGVycw0Kc2V0IHlhbWFoYSBtYXN0 ZXIgdm9sdW1lIHRvIG1heA0KcGNtMSAoQ1M0MjN4L1lhbWFoYS9BRDE4MTYg PFlhbWFoYSBTQTI+IHNuIDB4ZmZmZmZmZmYpIGF0IDB4NTMwLTB4NTM3IGly cSA1IGRycSAwIGZsYWdzIDB4MTEgb24gaXNhDQpucHgwOiA8bWF0aCBwcm9j ZXNzb3I+IG9uIG1vdGhlcmJvYXJkDQpucHgwOiBJTlQgMTYgaW50ZXJmYWNl DQpwY2liMDogPEFjZXJMYWJzIE0xNTQxIChBbGFkZGluLVYpIFBDSSBob3N0 IGJyaWRnZT4gb24gbW90aGVyYm9hcmQNCnBjaTA6IDxQQ0kgYnVzPiBvbiBw Y2liMA0KcGNpYjE6IDxBY2VyTGFicyBNNTI0MyBQQ0ktUENJIGJyaWRnZT4g YXQgZGV2aWNlIDEuMCBvbiBwY2kwDQpwY2kxOiA8UENJIGJ1cz4gb24gcGNp YjENCmNoaXAxOiA8QWNlckxhYnMgTTUyMzcgKEFsYWRkaW4tVikgVVNCIGNv bnRyb2xsZXI+IGlycSAxMCBhdCBkZXZpY2UgMi4wIG9uIHBjaTANCmNoaXAy OiA8QWNlckxhYnMgTTE1eDMgUG93ZXIgTWFuYWdlbWVudCBVbml0PiBhdCBk ZXZpY2UgMy4wIG9uIHBjaTANCmlzYWIwOiA8QWNlckxhYnMgTTE1MzMgcG9y dGFibGUgUENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSA3LjAgb24gcGNpMA0K ZWQwOiA8TkUyMDAwIFBDSSBFdGhlcm5ldCAoUmVhbFRlayA4MDI5KT4gaXJx IDExIGF0IGRldmljZSAxMC4wIG9uIHBjaTANCmVkMDogYWRkcmVzcyAwMDo0 MDowNTo1OTozMDpmMCwgdHlwZSBORTIwMDAgKDE2IGJpdCkgDQp2Z2EtcGNp MDogPEFUSSBtb2RlbCA0NzUwIGdyYXBoaWNzIGFjY2VsZXJhdG9yPiBhdCBk ZXZpY2UgMTEuMCBvbiBwY2kwDQphdGEtcGNpMDogPEFjZXJMYWJzIEFsYWRk aW4gSURFIGNvbnRyb2xsZXI+IGlycSAwIGF0IGRldmljZSAxNS4wIG9uIHBj aTANCmF0YS1wY2kwOiBCdXNtYXN0ZXJpbmcgRE1BIHN1cHBvcnRlZA0KYXRh MCBhdCAweDAxZjAgaXJxIDE0IG9uIGF0YS1wY2kwDQphdGExIGF0IDB4MDE3 MCBpcnEgMTUgb24gYXRhLXBjaTANCmlzYTA6IDxJU0EgYnVzPiBvbiBtb3Ro ZXJib2FyZA0KZmRjMDogPE5FQyA3MjA2NUIgb3IgY2xvbmU+IGF0IHBvcnQg MHgzZjAtMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNhMA0KZmRjMDogRklGTyBl bmFibGVkLCA4IGJ5dGVzIHRocmVzaG9sZA0KZmQwOiA8MTQ0MC1LQiAzLjUi IGRyaXZlPiBhdCBmZGMwIGRyaXZlIDANCmF0a2JkYzA6IDxrZXlib2FyZCBj b250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MC0weDZmIG9uIGlzYTAN CmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwDQpwc20w OiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzANCnBzbTA6IG1vZGVs IEdlbmVyaWMgUFMvMiBtb3VzZSwgZGV2aWNlIElEIDANCnZnYTA6IDxHZW5l cmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYjAtMHgzZGYgaW9tZW0gMHhhMDAw MC0weGJmZmZmIG9uIGlzYTANCnNjMDogPFN5c3RlbSBjb25zb2xlPiBvbiBp c2EwDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25zb2xlcywgZmxhZ3M9MHgy MDA+DQpzaW8wIGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgb24gaXNhMA0K c2lvMDogdHlwZSAxNjU1MEENCnNpbzEgYXQgcG9ydCAweDJmOC0weDJmZiBp cnEgMyBvbiBpc2EwDQpzaW8xOiB0eXBlIDE2NTUwQQ0KcHBjMCBhdCBwb3J0 IDB4Mzc4LTB4MzdmIGlycSA3IG9uIGlzYTANCnBwYzA6IEdlbmVyaWMgY2hp cHNldCAoRVBQL05JQkJMRSkgaW4gQ09NUEFUSUJMRSBtb2RlDQpscHQwOiA8 Z2VuZXJpYyBwcmludGVyPiBvbiBwcGJ1cyAwDQpscHQwOiBJbnRlcnJ1cHQt ZHJpdmVuIHBvcnQNCmF0YTA6IG1hc3Rlcjogc2V0dGluZyB1cCBVRE1BMiBt b2RlIG9uIEFsYWRkaW4gY2hpcCBPSw0KYWQwOiA8UVVBTlRVTSBGSVJFQkFM TCBFTDUuMUEvQTA4LjExMDA+IEFUQS00IGRpc2sgYXQgYXRhMCBhcyBtYXN0 ZXINCmFkMDogNDg5Mk1CICgxMDAxODg5MCBzZWN0b3JzKSwgMTA2MDIgY3ls cywgMTUgaGVhZHMsIDYzIFMvVCwgNTEyIEIvUw0KYWQwOiBwaW9tb2RlPTQs IGRtYW1vZGU9MiwgdWRtYW1vZGU9Mg0KYWQwOiAxNiBzZWNzL2ludCwgMCBk ZXB0aCBxdWV1ZSwgRE1BIG1vZGUNCmF0YTA6IHNsYXZlOiBzZXR0aW5nIHVw IFVETUEyIG1vZGUgb24gQWxhZGRpbiBjaGlwIE9LDQphZDE6IDxRVUFOVFVN IEZJUkVCQUxMIENSOC40QS9BNVUuMTAwMD4gQVRBLTQgZGlzayBhdCBhdGEw IGFzIHNsYXZlIA0KYWQxOiA4MDYzTUIgKDE2NTE0MDY0IHNlY3RvcnMpLCAx NjM4MyBjeWxzLCAxNiBoZWFkcywgNjMgUy9ULCA1MTIgQi9TDQphZDE6IHBp b21vZGU9NCwgZG1hbW9kZT0yLCB1ZG1hbW9kZT0yDQphZDE6IDE2IHNlY3Mv aW50LCAwIGRlcHRoIHF1ZXVlLCBETUEgbW9kZQ0KYWNkMDogPEhQIENELVdy aXRlcisgNzIwMC9WOjAwMy4wMT4gQ0RST00gZHJpdmUgYXQgYXRhMSBhcyBt YXN0ZXINCmFjZDA6IGRyaXZlIHNwZWVkIDM0NCAtIDEwMzRLQi9zZWMsIDc2 OEtCIGNhY2hlDQphY2QwOiBzdXBwb3J0ZWQgcmVhZCB0eXBlczogQ0QtUiwg Q0QtUlcsIENELURBLCBwYWNrZXQgdHJhY2sNCmFjZDA6IHN1cHBvcnRlZCB3 cml0ZSB0eXBlczogQ0QtUiwgQ0QtUlcsIHRlc3Qgd3JpdGUNCmFjZDA6IEF1 ZGlvOiBwbGF5LCAxMjggdm9sdW1lIGxldmVscw0KYWNkMDogTWVjaGFuaXNt OiBlamVjdGFibGUgdHJheQ0KYWNkMDogTWVkaXVtOiBuby9ibGFuayBkaXNj IGluc2lkZSwgdW5sb2NrZWQsIGxvY2sgcHJvdGVjdGVkDQphdGExOiB1bndh bnRlZCBpbnRlcnJ1cHQgMSBzdGF0dXMgPSA1MA0KYWNkMTogPE5FQyBDRC1S T00gRFJJVkU6MjczLzQuMjU+IENEUk9NIGRyaXZlIGF0IGF0YTEgYXMgc2xh dmUgDQphY2QxOiBkcml2ZSBzcGVlZCA2ODlLQi9zZWMsIDI1NktCIGNhY2hl DQphY2QxOiBzdXBwb3J0ZWQgcmVhZCB0eXBlczogQ0QtREENCmFjZDE6IEF1 ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscw0KYWNkMTogTWVjaGFuaXNt OiBlamVjdGFibGUgdHJheQ0KYWNkMTogTWVkaXVtOiBuby9ibGFuayBkaXNj IGluc2lkZSwgdW5sb2NrZWQNCmNoYW5naW5nIHJvb3QgZGV2aWNlIHRvIHdk MHMyYQ0KcGFuaWM6IGxvY2ttZ3I6IHBpZCAtMiwgbm90IGV4Y2x1c2l2ZSBs b2NrIGhvbGRlciAzMCB1bmxvY2tpbmcNCnBhbmljOiBmcm9tIGRlYnVnZ2Vy DQoNCmR1bXBpbmcgdG8gZGV2ICgzLDE5NjYwOSksIG9mZnNldCAyNjIxNzYN CmR1bXAgMTI3IDEyNiAxMjUgMTI0IDEyMyAxMjIgMTIxIDEyMCAxMTkgMTE4 IDExNyAxMTYgMTE1IDExNCAxMTMgMTEyIDExMSAxMTAgMTA5IDEwOCAxMDcg MTA2IDEwNSAxMDQgMTAzIDEwMiAxMDEgMTAwIDk5IDk4IDk3IDk2IDk1IDk0 IDkzIDkyIDkxIDkwIDg5IDg4IDg3IDg2IDg1IDg0IDgzIDgyIDgxIDgwIDc5 IDc4IDc3IDc2IDc1IDc0IDczIDcyIDcxIDcwIDY5IDY4IDY3IDY2IDY1IDY0 IDYzIDYyIDYxIDYwIDU5IDU4IDU3IDU2IDU1IDU0IDUzIDUyIDUxIDUwIDQ5 IDQ4IDQ3IDQ2IDQ1IDQ0IDQzIDQyIDQxIDQwIDM5IDM4IDM3IDM2IDM1IDM0 IDMzIDMyIDMxIDMwIDI5IDI4IDI3IDI2IDI1IDI0IDIzIDIyIDIxIDIwIDE5 IDE4IDE3IDE2IDE1IDE0IDEzIDEyIDExIDEwIDkgOCA3IDYgNSA0IDMgMiAx IDAgDQo= --0-1268117878-932447364=:725-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 22:50:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from asteroid.svib.ru (asteroid.svib.ru [195.151.166.145]) by hub.freebsd.org (Postfix) with ESMTP id DE1AD151A0; Mon, 19 Jul 1999 22:50:17 -0700 (PDT) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (shuttle.svib.ru [195.151.166.144]) by asteroid.svib.ru (8.9.3/8.9.3) with ESMTP id JAA03467; Tue, 20 Jul 1999 09:50:06 +0400 (MSD) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (minas-tirith.pol.ru [127.0.0.1]) by shuttle.svib.ru (8.9.3/8.8.8) with ESMTP id JAA14910; Tue, 20 Jul 1999 09:50:15 +0400 (MSD) (envelope-from tarkhil@shuttle.svib.ru) Message-Id: <199907200550.JAA14910@shuttle.svib.ru> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer Cc: current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Soft-updates feedback In-reply-to: Your message "Mon, 19 Jul 1999 13:24:18 PDT." <37938972.1CFBAE39@whistle.com> Reply-To: tarkhil@asteroid.svib.ru X-URL: http://freebsd.svib.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jul 1999 09:50:14 +0400 From: Alex Povolotsky Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG <37938972.1CFBAE39@whistle.com>Julian Elischer writes: >I saw this behaviour before.. >It was with an IDE disk drive running in PIO mode > >turning on DMA mode for the disk fixed it. From my DMESG: ide_pci0: rev 0x06 on pci0.7.1 wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 1625MB (3329424 sectors), 3303 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (atapi): , removable, intr, dma, iordis acd0: drive speed 1377KB/sec, 256KB cache acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa wdc1: unit 0 (wd2): , DMA, 32-bit, multi-block-16 wd2: 4892MB (10018890 sectors), 10602 cyls, 15 heads, 63 S/T, 512 B/S DMA seems to be ON. But it didn't help :-( Alex. -- Alexander B. Povolotsky [ICQ 18277558] [2:5020/145] [http://freebsd.svib.ru] [tarkhil@asteroid.svib.ru] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 19 23:35:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from knecht.sendmail.org (knecht.sendmail.org [209.31.233.160]) by hub.freebsd.org (Postfix) with ESMTP id 649101501F; Mon, 19 Jul 1999 23:35:30 -0700 (PDT) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (root@flamingo.mckusick.com [209.31.233.178]) by knecht.sendmail.org (8.9.3/8.9.3) with ESMTP id XAA13887; Mon, 19 Jul 1999 23:35:25 -0700 (PDT) Received: from flamingo.McKusick.COM (mckusick@localhost.concentric.net [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id VAA18341; Mon, 19 Jul 1999 21:59:56 -0700 (PDT) Message-Id: <199907200459.VAA18341@flamingo.McKusick.COM> To: "Andrew Atrens" Subject: Re: lockmanager panic Cc: current@freebsd.org, peter@freebsd.org, dg@root.com In-reply-to: Your message of "Tue, 20 Jul 1999 01:09:24 EDT." Date: Mon, 19 Jul 1999 21:59:51 -0700 From: Kirk McKusick Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Please be sure that you are running with vm/swap_pager.c at version 1.120 or later. In particular, you should have two calls to the macro BUF_KERNPROC in that file. If you are missing those two calls, you will get the panic. If you do have those two calls in that code, then (and *only* then) try the following patch to see if it helps. It is making use of BUF_KERNPROC for cases in which it is not intended, but if it gets around your current problem, then gives a good indication of what to look for as a real fix. Kirk McKusick Index: vm_pager.c =================================================================== RCS file: /usr/ncvs/src/sys/vm/vm_pager.c,v retrieving revision 1.51 diff -c -r1.51 vm_pager.c *** vm_pager.c 1999/07/05 12:50:54 1.51 --- vm_pager.c 1999/07/20 06:33:59 *************** *** 550,555 **** --- 550,556 ---- nbp->b_flags = B_CALL | (bp->b_flags & B_ORDERED) | flags; nbp->b_rcred = nbp->b_wcred = proc0.p_ucred; nbp->b_iodone = vm_pager_chain_iodone; + BUF_KERNPROC(nbp); crhold(nbp->b_rcred); crhold(nbp->b_wcred); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 0: 4:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from sun.fi (sun.fi [193.65.93.1]) by hub.freebsd.org (Postfix) with ESMTP id A75711507C for ; Tue, 20 Jul 1999 00:04:26 -0700 (PDT) (envelope-from tomppa@sun.fi) Received: from sun9.sun.fi (sun9.sun.fi [193.65.93.9]) by sun.fi (8.8.8/8.8.8) with ESMTP id KAA13519 for ; Tue, 20 Jul 1999 10:02:46 +0300 (EET DST) Received: (from tomppa@localhost) by sun9.sun.fi (8.9.3/8.9.3) id KAA02137 for freebsd-current@FreeBSD.ORG; Tue, 20 Jul 1999 10:02:44 +0300 (EET DST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <14228.7847.314690.223108@sun9.sun.fi> In-Reply-To: <19990720093420.M72885@freebie.lemis.com> References: <14227.34008.442998.44420@sun9.sun.fi> <19990720093420.M72885@freebie.lemis.com> From: Tomi Vainio To: Greg Lehey Subject: Re: Unusable PS/2 mouse Date: Tue, 20 Jul 1999 10:00:55 +0300 (EET DST) Reply-To: tomppa@sun.fi X-Mailer: VM 6.67 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey writes: > > ISTR there was a fix for this committed recently. Have you tried > updating to a really recent -CURRENT? > I'm using current cvsupped on last Sunday. Kazutaka YOKOTA writes: > > One is Logitech mouse support in the psm driver. The psm driver had > been unable to handle some wheel mice models, including Logitech > M-S48, until recently. It was fixed about a week ago both in -CURRENT > and -STABLE. So, you should now be able to use your Logitech mouse, > detected as MouseMan+, without the flags 0x100. > My mouse works very well without the switch box. > 2/3 button PS/2 mouse. If you don't switch between computers, I guess > you won't have a problem. (But, this defeats the reason why you want > to have the switch box in the first place!) > If I don't switch between computers mouse won't work either. Probably this switch is just badly designed so it will drain all needed voltage from wire. Tomppa -- Sun Microsystems Oy PL 102, Niittymäentie 9, 02201 Espoo, Finland Tomi Vainio (System Support Engineer) +358 9 52556300 hotline email: Tomi.Vainio@Sun.COM +358 9 52556252 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 0:16:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id CE7201507C; Tue, 20 Jul 1999 00:16:38 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id AAA12395; Tue, 20 Jul 1999 00:13:19 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907200713.AAA12395@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: tarkhil@asteroid.svib.ru Cc: Julian Elischer , current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Soft-updates feedback In-reply-to: Your message of "Tue, 20 Jul 1999 09:50:14 +0400." <199907200550.JAA14910@shuttle.svib.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jul 1999 00:13:19 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Have you checked your syslog to see if you are getting disk errors? Also, I noticed that you have a VIA chipset and I know that at least with the Bt848 driver they have caused havoc. I would stick to Intel PCI chipsets. Not sure if your motherboard supports or not do you have the latest microcode for your VIA chipset? Cheers -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 3:32:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from gera.nix.nns.ru (ns.nns.ru [194.135.102.10]) by hub.freebsd.org (Postfix) with ESMTP id 4A995152D1; Tue, 20 Jul 1999 03:32:23 -0700 (PDT) (envelope-from root@nns.ru) Received: from localhost (root@localhost) by gera.nix.nns.ru (8.9.1a/8.7.3) with ESMTP id OAA11310; Tue, 20 Jul 1999 14:30:51 +0400 (MSD) Date: Tue, 20 Jul 1999 14:30:50 +0400 (MSD) From: "Mike Ju. Volkov" X-Sender: root@gera To: current@FreeBSD.ORG Cc: stable@FreeBSD.ORG Subject: Aurel VORTEX Sound Card 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 Dose anybody install sound card Diamond Monster Sound II (based on Aurel VORTEX chipset) and make it propertly work ? Tell me how you did it, pls! ---------------------------------------------------------------------- Mike Ju. Volkov AKA Commander mike@nns.ru tel.: 232-3644 ICQ# 5173328 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 6: 9:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtprtp.nortel.com (smtprtp.NortelNetworks.com [192.122.117.66]) by hub.freebsd.org (Postfix) with ESMTP id 27506152D9; Tue, 20 Jul 1999 06:09:35 -0700 (PDT) (envelope-from atrens@nortelnetworks.com) Received: from zcars01t by smtprtp.nortel.com; Tue, 20 Jul 1999 09:06:33 -0400 Received: from hcarp00g.ca.nortel.com by zcars01t; Tue, 20 Jul 1999 09:06:15 -0400 Received: from hcarp00g.ca.nortel.com (hcarp00g.ca.nortel.com [47.196.31.114]) by hcarp00g.ca.nortel.com (8.9.3/8.7.3) with ESMTP id JAA02370; Tue, 20 Jul 1999 09:13:37 -0400 (EDT) Date: Tue, 20 Jul 1999 09:13:37 -0400 (EDT) From: "Andrew Atrens" Reply-To: "Andrew Atrens" To: Kirk McKusick Cc: current@freebsd.org, peter@freebsd.org, dg@root.com Subject: Re: lockmanager panic In-Reply-To: <199907200459.VAA18341@flamingo.McKusick.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orig: X-Orig: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think I'm up to date :) ... Unfortunately I won't be able to try out your fix until this evening :( ... Cheers, Andrew. -- $ ident swap_pager.c swap_pager.c: $Id: swap_pager.c,v 1.121 1999/07/16 05:11:35 alc Exp $ $ grep BUF_KERNPROC swap_pager.c BUF_KERNPROC(bp); BUF_KERNPROC(bp); On Mon, 19 Jul 1999, Kirk McKusick wrote: > Date: Mon, 19 Jul 1999 21:59:51 -0700 > From: Kirk McKusick > To: "Atrens, Andrew (A.B.) [EXCHANGE:SKY:1U33:BNR]" > Cc: current@freebsd.org, peter@freebsd.org, dg@root.com > Subject: Re: lockmanager panic > > Please be sure that you are running with vm/swap_pager.c > at version 1.120 or later. In particular, you should have > two calls to the macro BUF_KERNPROC in that file. If you > are missing those two calls, you will get the panic. If > you do have those two calls in that code, then (and *only* > then) try the following patch to see if it helps. It is > making use of BUF_KERNPROC for cases in which it is not > intended, but if it gets around your current problem, then > gives a good indication of what to look for as a real fix. > > Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 7:32:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from trooper.velocet.ca (trooper.velocet.net [209.167.225.226]) by hub.freebsd.org (Postfix) with ESMTP id 1D4D215312; Tue, 20 Jul 1999 07:32:10 -0700 (PDT) (envelope-from dgilbert@trooper.velocet.ca) Received: (from dgilbert@localhost) by trooper.velocet.ca (8.9.3/8.9.3) id KAA60194; Tue, 20 Jul 1999 10:31:14 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14228.34865.674677.16792@trooper.velocet.ca> Date: Tue, 20 Jul 1999 10:31:13 -0400 (EDT) To: tarkhil@asteroid.svib.ru Cc: Julian Elischer , current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Soft-updates feedback In-Reply-To: <199907200550.JAA14910@shuttle.svib.ru> References: <37938972.1CFBAE39@whistle.com> <199907200550.JAA14910@shuttle.svib.ru> X-Mailer: VM 6.71 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [on IDE bus lockups] I found that my IDE cdrom regularly caused lockups of FreeBSD in the 5-10 second variety. I would suspect that any misbehaving IDE device can do this. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 8: 5:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.clientlogic.com (ns.clientlogic.com [207.51.66.75]) by hub.freebsd.org (Postfix) with ESMTP id 7BFE31532D; Tue, 20 Jul 1999 08:05:05 -0700 (PDT) (envelope-from ChrisMic@clientlogic.com) Received: by site0s1 with Internet Mail Service (5.5.2448.0) id ; Tue, 20 Jul 1999 11:05:02 -0400 Message-ID: <6C37EE640B78D2118D2F00A0C90FCB4401105AC1@site2s1> From: Christopher Michaels To: 'Amancio Hasty' , tarkhil@asteroid.svib.ru Cc: Julian Elischer , current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: RE: Soft-updates feedback Date: Tue, 20 Jul 1999 11:07:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FWIW, I have a VIA chipset in my machine that is running -STABLE and I don't have such problems. I don't know if I have the same chipset as you tho, as I'm not at the machine to check my dmesg. I put an decent about of stress on the drives and don't seem to have any lockups at all, slowdowns yes, lockups no. I have the VIA MVP3 chipset, and my 2 of my drives are in DMA mode and one is in PIO mode. -Chris > -----Original Message----- > From: Amancio Hasty [SMTP:hasty@rah.star-gate.com] > Sent: Tuesday, July 20, 1999 3:13 AM > To: tarkhil@asteroid.svib.ru > Cc: Julian Elischer; current@FreeBSD.ORG; stable@FreeBSD.ORG > Subject: Soft-updates feedback > > Have you checked your syslog to see if you are getting disk errors? > > Also, I noticed that you have a VIA chipset and I know that > at least with the Bt848 driver they have caused havoc. I would > stick to Intel PCI chipsets. > > Not sure if your motherboard supports or not do you have > the latest microcode for your VIA chipset? > > Cheers > -- > > Amancio Hasty > hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 10:12:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id A23EE14EAB for ; Tue, 20 Jul 1999 10:12:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA05617; Tue, 20 Jul 1999 10:11:35 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Jul 1999 10:11:35 -0700 (PDT) From: Matthew Dillon Message-Id: <199907201711.KAA05617@apollo.backplane.com> To: "Reginald S. Perry" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Panics on my SMP system References: <199906130048.RAA15241@trane.lambdawerks.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi there, : : I recently had a crash on my SMP system. Actually, I have had a :number of crashes over the past six months, but have just recently had :time to configure the system to get the crash dumps. Like a good :citizen, I filed a problem report (kern/12127). I have now gotten :another crash. I have attached the backtrace from the crash dump. If :you refer to kern/12127, you will get all of the gory details about my :setup.I would like to know two things. Should I file a separate :problem report for this crash? Second, is there somewhere that I :should upload the vmcores and the kernel.debug for the relevant :developer to examine? : :Thanks, : -Reggie How old is your -CURRENT source tree ? Fixes to the pipe code have been made, though they are not 100% complete. If your -CURRENT source tree is more then a few days old I recommend updating it. A number of significant reliability fixes have gone in, including fixes to the pipe code and fixes to certain atomic operations that weren't atomic. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 10:38:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (Postfix) with ESMTP id 13B44153B0 for ; Tue, 20 Jul 1999 10:38:49 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.9.3/8.9.1) id KAA04068 for freebsd-current@freebsd.org; Tue, 20 Jul 1999 10:42:56 -0700 (PDT) (envelope-from kargl) From: "Steven G. Kargl" Message-Id: <199907201742.KAA04068@troutmask.apl.washington.edu> Subject: is dumpon/savecore broken? To: freebsd-current@freebsd.org Date: Tue, 20 Jul 1999 10:42:56 -0700 (PDT) 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 During the boot process I see dumpon: crash dumps to /dev/da0s1b (4, 131073) checking for core dump...savecore: can't find device 13/131073 Jul 20 10:18:00 troutmask savecore: can't find device 13/131073 Doing additional network setup: portmap. My /etc/fstab file contains: /dev/da0s1b none swap sw 0 0 The machine has 256 MB of memory, and da0s1b is 500 MB in size. It seems that the the major device number is reset from 4 to 13. troutmask:kargl[225] swapinfo Device 1K-blocks Used Avail Capacity Type /dev/#B13:0x20001 511872 0 511872 0% Interleaved -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 10:57:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 23519153A2 for ; Tue, 20 Jul 1999 10:57:35 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id TAA21541; Tue, 20 Jul 1999 19:55:44 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Steven G. Kargl" Cc: freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? In-reply-to: Your message of "Tue, 20 Jul 1999 10:42:56 PDT." <199907201742.KAA04068@troutmask.apl.washington.edu> Date: Tue, 20 Jul 1999 19:55:44 +0200 Message-ID: <21539.932493344@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907201742.KAA04068@troutmask.apl.washington.edu>, "Steven G. Kar gl" writes: > >During the boot process I see > dumpon: crash dumps to /dev/da0s1b (4, 131073) > checking for core dump...savecore: can't find device 13/131073 >It seems that the the major device number is reset from 4 to 13. >troutmask:kargl[225] swapinfo >Device 1K-blocks Used Avail Capacity Type >/dev/#B13:0x20001 511872 0 511872 0% Interleaved Yes, all dev_t's which make it out of the kernel have cmajor numbers now. Try this change to savecore: /ddname = find_dev/s/BLK/CHR/ -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 11: 5:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (Postfix) with ESMTP id CEB1A153B1 for ; Tue, 20 Jul 1999 11:05:23 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.9.3/8.9.1) id LAA04373; Tue, 20 Jul 1999 11:09:36 -0700 (PDT) (envelope-from kargl) From: "Steven G. Kargl" Message-Id: <199907201809.LAA04373@troutmask.apl.washington.edu> Subject: Re: is dumpon/savecore broken? In-Reply-To: <21539.932493344@critter.freebsd.dk> from Poul-Henning Kamp at "Jul 20, 1999 07:55:44 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 20 Jul 1999 11:09:35 -0700 (PDT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Poul-Henning Kamp: > In message <199907201742.KAA04068@troutmask.apl.washington.edu>, "Steven G. Kar > gl" writes: > > > >During the boot process I see > > > dumpon: crash dumps to /dev/da0s1b (4, 131073) > > checking for core dump...savecore: can't find device 13/131073 > > >It seems that the the major device number is reset from 4 to 13. > > Yes, all dev_t's which make it out of the kernel have cmajor > numbers now. > > Try this change to savecore: > > /ddname = find_dev/s/BLK/CHR/ > Thanks, Poul. I forgot to mention that this is after a "make world" and new kernel from today (1000 PST). -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 11:50:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 44168153A2 for ; Tue, 20 Jul 1999 11:50:52 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA06381; Tue, 20 Jul 1999 11:49:50 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Jul 1999 11:49:50 -0700 (PDT) From: Matthew Dillon Message-Id: <199907201849.LAA06381@apollo.backplane.com> To: "Steven G. Kargl" Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? References: <199907201809.LAA04373@troutmask.apl.washington.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > dumpon: crash dumps to /dev/da0s1b (4, 131073) :> > checking for core dump...savecore: can't find device 13/131073 :> :> >It seems that the the major device number is reset from 4 to 13. :> :> Yes, all dev_t's which make it out of the kernel have cmajor :> numbers now. :> :> Try this change to savecore: :> :> /ddname = find_dev/s/BLK/CHR/ :> : :Thanks, Poul. : :I forgot to mention that this is after a "make world" and new kernel :from today (1000 PST). : :-- :Steve A checklist for people who want kernel cores: * make sure that dumpdev is set to point to your swap partition in your /etc/rc.conf * make sure your swap partition is large enough to hold the crash dump. If you have 256MB of ram, your swap partition must be at least 256MB in size. * make sure /var/crash has sufficient space to hold the dump (note: /var/crash *can* be a softlink to a directory in some other partition if /var does not have sufficient space) /var/crash must nominally have sufficient space to hold the crash dump (a file of the same size as the amount of memory you have), *and* the kernel image. Normally you give it a lot more space so you store several crash dumps in it at once. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 12: 3:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (Postfix) with ESMTP id D34BD14DF6 for ; Tue, 20 Jul 1999 12:03:28 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.9.3/8.9.1) id MAA04538; Tue, 20 Jul 1999 12:06:26 -0700 (PDT) (envelope-from kargl) From: "Steven G. Kargl" Message-Id: <199907201906.MAA04538@troutmask.apl.washington.edu> Subject: Re: is dumpon/savecore broken? In-Reply-To: <199907201849.LAA06381@apollo.backplane.com> from Matthew Dillon at "Jul 20, 1999 11:49:50 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 20 Jul 1999 12:06:26 -0700 (PDT) Cc: phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Matthew Dillon: > :> > dumpon: crash dumps to /dev/da0s1b (4, 131073) > :> > checking for core dump...savecore: can't find device 13/131073 > :> > :> >It seems that the the major device number is reset from 4 to 13. > :> > :> Yes, all dev_t's which make it out of the kernel have cmajor > :> numbers now. > :> > :> Try this change to savecore: > :> > :> /ddname = find_dev/s/BLK/CHR/ > :> > : > :Thanks, Poul. > : > :I forgot to mention that this is after a "make world" and new kernel > :from today (1000 PST). > : > > A checklist for people who want kernel cores: > [Matt's check list deleted which I meet] > /var/crash must nominally have sufficient space to hold the crash > dump (a file of the same size as the amount of memory you have), > *and* the kernel image. Normally you give it a lot more space so > you store several crash dumps in it at once. Matt, AFAICT, the problem is due to the translation of /dev/da0s1b to major and minor numbers. dumpon takes /dev/da0s1b and translates it to (4,131073) in my case. savecore uses sysctl kern.dumpdev to determine the dump device. kern.dumpdev is set to (13,131073). Thus, dumpon uses bmajor and savecore uses cmajor device numbers. I also note that savecore grovels around in /dev/kmem which scares the heck out of me as far as my hacking abilities go ;-) -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 12:14:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 5D42D15395 for ; Tue, 20 Jul 1999 12:14:31 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA25464 for ; Tue, 20 Jul 1999 12:13:23 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 20 Jul 1999 12:13:23 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: freebsd-current@freebsd.org Subject: New amd problems, hung mounts 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 Thanks to some help off the list I think that the problems with amd hanging in 'siobi' state is solved. Now that it's been reliable enough to put into production, I'm seeing some interesting problems. After it's been running for 24 hours, then the web traffic is turned off I get some mounted directories that won't unmount. I can't unmount them with amq, or umount. On a tip I loaded up lsof to see if there were any files open on those systems, here is what I found (sorry about the formatting). 31# mount /dev/wd0s1a on / (local, writes: sync 341 async 4211) /dev/wd0s1f on /usr (local, writes: sync 5195 async 34714) /dev/wd0s1e on /var (local, writes: sync 296 async 6940) procfs on /proc (local) pid157@hostname:/usr/amd/Hold on /usr/amd/Hold pid157@hostname:/usr/amd/Interfaces on /usr/amd/Interfaces Web001:/Space/209.132.28 on /usr/amd/realmounts/Web001/Space/209.132.28 Web001:/Space/209.132.30 on /usr/amd/realmounts/Web001/Space/209.132.30 Web005:/Space/209.132.45 on /usr/amd/realmounts/Web005/Space/209.132.45 Web005:/Space/209.132.46 on /usr/amd/realmounts/Web005/Space/209.132.46 Web006:/Space/209.132.48 on /usr/amd/realmounts/Web006/Space/209.132.48 Web006:/Space/209.132.51 on /usr/amd/realmounts/Web006/Space/209.132.51 Web007:/Space/209.132.52 on /usr/amd/realmounts/Web007/Space/209.132.52 Web007:/Space/209.132.53 on /usr/amd/realmounts/Web007/Space/209.132.53 Web006:/Space/209.132.50 on /usr/amd/realmounts/Web006/Space/209.132.50 22# /usr/local/sbin/lsof -N -R COMMAND PID PPID USER FD TYPE DEVICE SIZE/OFF NODE NAME httpd 58179 13616 simplenet 4r VREG 255,12189698 193 572486 /usr/amd/realmounts/Web006/Space/209.132.50/176/Server/Documents/.htaccess httpd 58202 13616 simplenet cwd VDIR 255,4784130 96 844036 /usr/amd/realmounts/Web001/Space/209.132.28/145/Server/Documents/error httpd 58402 13616 simplenet cwd VDIR 255,4784130 96 844036 /usr/amd/realmounts/Web001/Space/209.132.28/145/Server/Documents/error PID 13616 was an httpd process, as were the other PID's. After I killed that process the files were no longer open according to lsof, however the filesystems were still mounted, and I am still unable to umount them by hand. All of the hosts that these "stuck" filesystems are on are up, and nfs-mountable from the sun systems in our office. Any comments or suggestions on things to try are welcome. One item that may be of interest is that while I am running portmapper (amd won't run without it) I'm not running rpc.statd, since it didn't seem like it was needed. I'm thinking that I'll start it up though, and see if that helps. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 13: 6:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id DA65514E71 for ; Tue, 20 Jul 1999 13:06:38 -0700 (PDT) (envelope-from hibma@skylink.it) Received: from heidi.plazza.it (va-170.skylink.it [194.185.55.170]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id WAA17894; Tue, 20 Jul 1999 22:06:33 +0200 Received: from localhost (localhost.plazza.it [127.0.0.1]) by heidi.plazza.it (8.8.8/8.8.5) with SMTP id WAA01737; Tue, 20 Jul 1999 22:00:47 +0200 (CEST) Date: Tue, 20 Jul 1999 22:00:47 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@heidi.plazza.it Reply-To: Nick Hibma To: Matthew Dillon Cc: "Steven G. Kargl" , Poul-Henning Kamp , freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? In-Reply-To: <199907201849.LAA06381@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG And how do you create dumps from a kernel that hasn't finished booting (not gotten to the stage of reading rc.conf)? 'dumps on' in kernel config does not seem to do the job. Nick > A checklist for people who want kernel cores: > > * make sure that dumpdev is set to point to your swap partition > in your /etc/rc.conf > > * make sure your swap partition is large enough to hold the crash > dump. If you have 256MB of ram, your swap partition must be > at least 256MB in size. > > * make sure /var/crash has sufficient space to hold the dump > (note: /var/crash *can* be a softlink to a directory in some > other partition if /var does not have sufficient space) > > /var/crash must nominally have sufficient space to hold the crash > dump (a file of the same size as the amount of memory you have), > *and* the kernel image. Normally you give it a lot more space so > you store several crash dumps in it at once. Nick -- e-Mail: hibma@skylink.it To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 13:30:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 51AED153A2 for ; Tue, 20 Jul 1999 13:30:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA06800; Tue, 20 Jul 1999 13:30:44 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Jul 1999 13:30:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199907202030.NAA06800@apollo.backplane.com> To: Nick Hibma Cc: "Steven G. Kargl" , Poul-Henning Kamp , freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :And how do you create dumps from a kernel that hasn't finished booting :(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel :config does not seem to do the job. : :Nick You can do it manually from /etc/rc. If it doesn't even get that far, you used to be able to specify it in the kernel config but I do not know if that is possible any more. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 13:36:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id 9D5E7153CC for ; Tue, 20 Jul 1999 13:36:35 -0700 (PDT) (envelope-from dscheidt@tumbolia.com) Received: (qmail 81206 invoked from network); 20 Jul 1999 20:36:22 -0000 Received: from shell-3.enteract.com (dscheidt@207.229.143.42) by pop3-3.enteract.com with SMTP; 20 Jul 1999 20:36:22 -0000 Date: Tue, 20 Jul 1999 15:36:22 -0500 (CDT) From: David Scheidt X-Sender: dscheidt@shell-3.enteract.com To: Matthew Dillon Cc: "Steven G. Kargl" , Poul-Henning Kamp , freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? In-Reply-To: <199907201849.LAA06381@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Jul 1999, Matthew Dillon wrote: > > * make sure your swap partition is large enough to hold the crash > dump. If you have 256MB of ram, your swap partition must be > at least 256MB in size. Is there any reason that savecore(8) can't write compressed crashdumps? (Other than no one haveing ever written the the code, of course.) In other words, if I wrote this would it get committed? David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 13:36:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.54]) by hub.freebsd.org (Postfix) with ESMTP id 09805153CD for ; Tue, 20 Jul 1999 13:36:47 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.9.3/8.9.1) id NAA04840; Tue, 20 Jul 1999 13:40:52 -0700 (PDT) (envelope-from kargl) From: "Steven G. Kargl" Message-Id: <199907202040.NAA04840@troutmask.apl.washington.edu> Subject: Re: is dumpon/savecore broken? In-Reply-To: <199907202030.NAA06800@apollo.backplane.com> from Matthew Dillon at "Jul 20, 1999 01:30:44 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 20 Jul 1999 13:40:52 -0700 (PDT) Cc: hibma@skylink.it (Nick Hibma), phk@critter.freebsd.dk (Poul-Henning Kamp), freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Matthew Dillon: > > :And how do you create dumps from a kernel that hasn't finished booting > :(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel > :config does not seem to do the job. > : > :Nick > > You can do it manually from /etc/rc. If it doesn't even get that far, > you used to be able to specify it in the kernel config but I do not know > if that is possible any more. > I think that is Nick's point. You can no longer specify a dump device in the kernel config file. troutmask:root[203] config TROUTMASK config: line 41: root/dump/swap specifications obsolete On the other hand, you should have kernel.old or a fixit floppy available. -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 13:36:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by hub.freebsd.org (Postfix) with ESMTP id 9C978153CB; Tue, 20 Jul 1999 13:36:40 -0700 (PDT) (envelope-from jobaldwi@vt.edu) Received: from john.baldwin.cx (207-172-143-122.s59.as1.hgt.md.dialup.rcn.com [207.172.143.122]) by smtp3.erols.com (8.8.8/8.8.5) with ESMTP id QAA08344; Tue, 20 Jul 1999 16:36:26 -0400 (EDT) Message-Id: <199907202036.QAA08344@smtp3.erols.com> 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 In-Reply-To: <199907200713.AAA12395@rah.star-gate.com> Date: Tue, 20 Jul 1999 16:36:24 -0400 (EDT) From: John Baldwin To: Amancio Hasty Subject: Re: Soft-updates feedback Cc: stable@FreeBSD.ORG, current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 20-Jul-99 Amancio Hasty wrote: > Have you checked your syslog to see if you are getting disk errors? > > Also, I noticed that you have a VIA chipset and I know that > at least with the Bt848 driver they have caused havoc. I would > stick to Intel PCI chipsets. > > Not sure if your motherboard supports or not do you have > the latest microcode for your VIA chipset? Huh? Excerpt from my dmesg: Probing for devices on PCI bus 0: chip0: rev 0x04 on pci0.0.0 chip1: rev 0x00 on pci0.1.0 chip2: rev 0x41 on pci0.7.0 ide_pci0: rev 0x06 on pci0.7.1 chip3: rev 0x10 on pci0.7.3 bktr0: rev 0x01 int a irq 9 on pci0.9.0 bti2c0: iicbb0: on bti2c0 iicbus0: on iicbb0 master-only smbus0: on bti2c0 Hauppauge WinCast/TV, Philips NTSC tuner, dbx stereo. What types of havoc should I be looking for? Haven't had any since December when I bought the new motherboard. Oh, and here's uname -a: FreeBSD john.baldwin.cx 3.2-STABLE FreeBSD 3.2-STABLE #3: Thu Jul 1 21:08:59 EDT 1999 root@john.baldwin.cx:/usr/source/src/sys/compile/JOHN i386 More info available on request. > Cheers > -- > > Amancio Hasty > hasty@rah.star-gate.com --- John Baldwin -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/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 Jul 20 13:46:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 43699153FD for ; Tue, 20 Jul 1999 13:46:24 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id WAA22118; Tue, 20 Jul 1999 22:42:48 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: David Scheidt Cc: Matthew Dillon , "Steven G. Kargl" , freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? In-reply-to: Your message of "Tue, 20 Jul 1999 15:36:22 CDT." Date: Tue, 20 Jul 1999 22:42:47 +0200 Message-ID: <22116.932503367@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dav id Scheidt writes: >On Tue, 20 Jul 1999, Matthew Dillon wrote: > >> >> * make sure your swap partition is large enough to hold the crash >> dump. If you have 256MB of ram, your swap partition must be >> at least 256MB in size. > >Is there any reason that savecore(8) can't write compressed crashdumps? >(Other than no one haveing ever written the the code, of course.) In >other words, if I wrote this would it get committed? I'm pretty sure it would. I think the lack of libz has prevented it in the past. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 13:46:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id EABDD153DC for ; Tue, 20 Jul 1999 13:46:22 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA06906; Tue, 20 Jul 1999 13:45:53 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Jul 1999 13:45:53 -0700 (PDT) From: Matthew Dillon Message-Id: <199907202045.NAA06906@apollo.backplane.com> To: David Scheidt Cc: "Steven G. Kargl" , Poul-Henning Kamp , freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Tue, 20 Jul 1999, Matthew Dillon wrote: : :> :> * make sure your swap partition is large enough to hold the crash :> dump. If you have 256MB of ram, your swap partition must be :> at least 256MB in size. : :Is there any reason that savecore(8) can't write compressed crashdumps? :(Other than no one haveing ever written the the code, of course.) In :other words, if I wrote this would it get committed? : :David Scheidt A crash dump would have to uncopmressed to gdb it. If you have sufficient space to hold a crash dump, just point /var/crash at that space. If you compress it right off the bat then someone is going to have to uncompress it to look at it. I sometimes compress crash dumps if I want to save them after I'm through gdb'ing them. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 13:47:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 1CBAA155C2 for ; Tue, 20 Jul 1999 13:43:36 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id VAA18205; Tue, 20 Jul 1999 21:14:29 +0100 (BST) (envelope-from nik) Date: Tue, 20 Jul 1999 21:14:27 +0100 From: Nik Clayton To: Kris Kennaway Cc: Nik Clayton , current@FreeBSD.ORG Subject: Re: Moving ipf(1) to ipf(8)? Message-ID: <19990720211427.A4523@catkin.nothing-going-on.org> References: <19990719224454.A52115@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Kris Kennaway on Tue, Jul 20, 1999 at 10:40:03AM +0930 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 20, 1999 at 10:40:03AM +0930, Kris Kennaway wrote: > On Mon, 19 Jul 1999, Nik Clayton wrote: > > > docs/7791 is of the opinion that ipf(1) should be moved to ipf(8), to > > (among other things) be consistent with ipfw(8). > > > > Anyone care to comment one way or the other? > > Definitely. Assuming I did this, what's the approved method? Myself, I'd just # mv ipf.1 ipf.8 # cvs remove ipf.1 # cvs add ipf.8 # cvs commit -m "Renamed ipf.1 to ipf.8" ipf.1 ipf.8 [... check for any other man pages that refer to ipf(1) and update them accordingly ...] which properly reflects that (until the change) ipf.8 didn't exist. I *would not* use a repository copy for this. I'm aware that some people's opinions of when you repository copy and when you don't are different, however. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 13:56:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id BC05A14C3D for ; Tue, 20 Jul 1999 13:56:01 -0700 (PDT) (envelope-from dscheidt@tumbolia.com) Received: (qmail 92665 invoked from network); 20 Jul 1999 20:54:41 -0000 Received: from shell-3.enteract.com (dscheidt@207.229.143.42) by pop3-3.enteract.com with SMTP; 20 Jul 1999 20:54:41 -0000 Date: Tue, 20 Jul 1999 15:54:41 -0500 (CDT) From: David Scheidt X-Sender: dscheidt@shell-3.enteract.com To: Matthew Dillon Cc: "Steven G. Kargl" , Poul-Henning Kamp , freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? In-Reply-To: <199907202045.NAA06906@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Jul 1999, Matthew Dillon wrote: > > A crash dump would have to uncopmressed to gdb it. If you have > sufficient space to hold a crash dump, just point /var/crash at that > space. If you compress it right off the bat then someone is going to > have to uncompress it to look at it. savecore saving compressed crash dumps is handy on production machines with lots of memory. I run a bunch of HP/UX boxes that don't have 4 gigs in /var/crash, because they never crash, except of course when they do. It is very useful to be able to save the dump, even if I have to analyze it somewhere else. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 14: 0:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id EA72A153E1 for ; Tue, 20 Jul 1999 14:00:13 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA71869; Tue, 20 Jul 1999 17:00:04 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 20 Jul 1999 17:00:04 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Poul-Henning Kamp Cc: "Steven G. Kargl" , freebsd-current@FreeBSD.org Subject: Re: is dumpon/savecore broken? In-Reply-To: <21539.932493344@critter.freebsd.dk> 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, 20 Jul 1999, Poul-Henning Kamp wrote: > In message <199907201742.KAA04068@troutmask.apl.washington.edu>, "Steven G. Kar > gl" writes: > > > >During the boot process I see > > > dumpon: crash dumps to /dev/da0s1b (4, 131073) > > checking for core dump...savecore: can't find device 13/131073 > > >It seems that the the major device number is reset from 4 to 13. > > >troutmask:kargl[225] swapinfo > >Device 1K-blocks Used Avail Capacity Type > >/dev/#B13:0x20001 511872 0 511872 0% Interleaved > > Yes, all dev_t's which make it out of the kernel have cmajor > numbers now. > > Try this change to savecore: > > /ddname = find_dev/s/BLK/CHR/ No, that's wrong. You cannot do buffered-type IO on a cdev. I committed a workaround, and now it works. There's no easy way around this, except possibly making kern.dumpdev a string (makes quite a bit of sense there...) > > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: 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 Jul 20 14: 4:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 8DE2E150B9; Tue, 20 Jul 1999 14:04:16 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id XAA22289; Tue, 20 Jul 1999 23:03:07 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Brian F. Feldman" Cc: "Steven G. Kargl" , freebsd-current@FreeBSD.org Subject: Re: is dumpon/savecore broken? In-reply-to: Your message of "Tue, 20 Jul 1999 17:00:04 EDT." Date: Tue, 20 Jul 1999 23:03:07 +0200 Message-ID: <22287.932504587@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , "Bria n F. Feldman" writes: >> /ddname = find_dev/s/BLK/CHR/ > >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed >a workaround, and now it works. There's no easy way around this, except >possibly making kern.dumpdev a string (makes quite a bit of sense there...) Indeed. a dev_t should never be exported as such from the kernel anymore, in particular not for bdevs. dumps and swap are the two offenders left. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 14: 8:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id E9BBE14C3D for ; Tue, 20 Jul 1999 14:08:49 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA71999; Tue, 20 Jul 1999 17:08:17 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 20 Jul 1999 17:08:17 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Poul-Henning Kamp Cc: "Steven G. Kargl" , freebsd-current@FreeBSD.org Subject: Re: is dumpon/savecore broken? In-Reply-To: <22287.932504587@critter.freebsd.dk> 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, 20 Jul 1999, Poul-Henning Kamp wrote: > In message , "Bria > n F. Feldman" writes: > > >> /ddname = find_dev/s/BLK/CHR/ > > > >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed > >a workaround, and now it works. There's no easy way around this, except > >possibly making kern.dumpdev a string (makes quite a bit of sense there...) > > Indeed. a dev_t should never be exported as such from the kernel > anymore, in particular not for bdevs. dumps and swap are the two > offenders left. Should I commit a similar workaround for the swap code too? Quite simple to do... > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: 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 Jul 20 14:11:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from rah.star-gate.com (216-200-29-190.snj0.flashcom.net [216.200.29.194]) by hub.freebsd.org (Postfix) with ESMTP id 25A26150B9; Tue, 20 Jul 1999 14:11:50 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.3/8.8.8) with ESMTP id OAA00966; Tue, 20 Jul 1999 14:11:04 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199907202111.OAA00966@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: John Baldwin Cc: stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: Soft-updates feedback In-reply-to: Your message of "Tue, 20 Jul 1999 16:36:24 EDT." <199907202036.QAA08344@smtp3.erols.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Jul 1999 14:11:03 -0700 From: Amancio Hasty Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Glad that is working out for you. I am not into PCI low level bugs they are very difficult to indentify and in certain cases impossible to fix. To give you a little hint: 1.68 25 May 1999 Roger Hardiman Due to differences in PCI bus implementations from various motherboard chipset manufactuers, the Bt878/Bt879 has 3 PCI bus compatibility modes. These are NORMAL PCI 2.1 for proper PCI 2.1 compatible chipsets. INTEL 430 FX for the Intel 430 FX chipset. SIS VIA CHIPSET for certain SiS and VIA chipsets. Older Intel and non-Intel chipsets may also benefit from either 430_FX or SIS/VIA mode. ---------------------------- Usually, the kind of problems that I have heard of is systems hanging hard for instance with the Bt848 driver. The bottom line is that if it is working for you great. -- Amancio Hasty hasty@rah.star-gate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 14:12: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id D400315196; Tue, 20 Jul 1999 14:11:43 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id XAA22436; Tue, 20 Jul 1999 23:10:44 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Brian F. Feldman" Cc: "Steven G. Kargl" , freebsd-current@FreeBSD.org Subject: Re: is dumpon/savecore broken? In-reply-to: Your message of "Tue, 20 Jul 1999 17:08:17 EDT." Date: Tue, 20 Jul 1999 23:10:44 +0200 Message-ID: <22434.932505044@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , "Bria n F. Feldman" writes: >On Tue, 20 Jul 1999, Poul-Henning Kamp wrote: > >> In message , "Bria >> n F. Feldman" writes: >> >> >> /ddname = find_dev/s/BLK/CHR/ >> > >> >No, that's wrong. You cannot do buffered-type IO on a cdev. I committed >> >a workaround, and now it works. There's no easy way around this, except >> >possibly making kern.dumpdev a string (makes quite a bit of sense there...) >> >> Indeed. a dev_t should never be exported as such from the kernel >> anymore, in particular not for bdevs. dumps and swap are the two >> offenders left. > >Should I commit a similar workaround for the swap code too? Quite >simple to do... Please so, but I would appreciate if you would do me the favour of hiding the guts of this monstrosity in kern/kern_conf.c in a function called dev2budev() ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 14:39:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id AED35153BD for ; Tue, 20 Jul 1999 14:39:54 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA72574; Tue, 20 Jul 1999 17:38:03 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 20 Jul 1999 17:38:03 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Poul-Henning Kamp Cc: "Steven G. Kargl" , freebsd-current@FreeBSD.org Subject: Re: is dumpon/savecore broken? In-Reply-To: <22434.932505044@critter.freebsd.dk> 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, 20 Jul 1999, Poul-Henning Kamp wrote: > >Should I commit a similar workaround for the swap code too? Quite > >simple to do... > > Please so, but I would appreciate if you would do me the favour of > hiding the guts of this monstrosity in kern/kern_conf.c in a function > called dev2budev() ? I did so. I'm working out why this did not fix pstat now... > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: 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 Jul 20 14:54: 4 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id E1DD914CF8 for ; Tue, 20 Jul 1999 14:54:01 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA72853; Tue, 20 Jul 1999 17:52:50 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 20 Jul 1999 17:52:50 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: "Reginald S. Perry" , freebsd-current@FreeBSD.org Subject: Re: Panics on my SMP system In-Reply-To: <199907201711.KAA05617@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Jul 1999, Matthew Dillon wrote: > > How old is your -CURRENT source tree ? Fixes to the pipe code > have been made, though they are not 100% complete. > > If your -CURRENT source tree is more then a few days old I recommend > updating it. A number of significant reliability fixes have gone in, > including fixes to the pipe code and fixes to certain atomic operations > that weren't atomic. What's happing with regard to your pipe write locking fixes? I still apply those to my kernels... > > -Matt Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: 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 Jul 20 15: 0:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5103B153B6; Tue, 20 Jul 1999 15:00:30 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA07707; Tue, 20 Jul 1999 14:59:26 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Jul 1999 14:59:26 -0700 (PDT) From: Matthew Dillon Message-Id: <199907202159.OAA07707@apollo.backplane.com> To: "Brian F. Feldman" Cc: "Reginald S. Perry" , freebsd-current@FreeBSD.ORG Subject: Re: Panics on my SMP system References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Tue, 20 Jul 1999, Matthew Dillon wrote: : :> :> How old is your -CURRENT source tree ? Fixes to the pipe code :> have been made, though they are not 100% complete. :> :... : :What's happing with regard to your pipe write locking fixes? I still :apply those to my kernels... : : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ I ran into a possible panic with them and haven't had time to get back to it (e.g. research the problem), especially without commit privs. I expect to revisit them when the SMP locks migrate inward sufficiently that the pipe code can be moved out of the big giant lock. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 15:14:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (Postfix) with ESMTP id E958915412 for ; Tue, 20 Jul 1999 15:13:46 -0700 (PDT) (envelope-from schuerge@wurzelausix.CS.Uni-SB.DE) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999070600) with ESMTP id AAA25192 for ; Wed, 21 Jul 1999 00:13:26 +0200 (CEST) Received: from wurzelausix.cs.uni-sb.de (wurzelausix.cs.uni-sb.de [134.96.247.1]) by cs.uni-sb.de (8.9.3/1999031900) with ESMTP id AAA22332 for ; Wed, 21 Jul 1999 00:13:26 +0200 (CEST) Received: (from schuerge@localhost) by wurzelausix.cs.uni-sb.de (8.9.1/8.9.1/wjp-SVR4/1998063000) id AAA29228 for freebsd-current@freebsd.org; Wed, 21 Jul 1999 00:13:21 +0200 (CEST) From: Thomas Schuerger Message-Id: <199907202213.AAA29228@wurzelausix.cs.uni-sb.de> Subject: kernel compilation problems To: freebsd-current@freebsd.org Date: Wed, 21 Jul 1999 00:13:20 +0200 (CEST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! I'm currently having problems compiling my kernel: ... ... ... sh ../../conf/newvers.sh STARFIRE cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf vers.c linking kernel vfs_init.o: In function `vfs_register': vfs_init.o(.text+0x8a1): undefined reference to `sysctl(void, float, short)' *** Error code 1 1 error Exit 2 Any ideas? Ciao, Thomas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 17: 0: 0 1999 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 5700E14C45 for ; Tue, 20 Jul 1999 16:59:39 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id QAA00975; Tue, 20 Jul 1999 16:58:49 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id QAA70000; Tue, 20 Jul 1999 16:58:49 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Tue, 20 Jul 1999 16:58:49 -0700 (PDT) Message-Id: <199907202358.QAA70000@vashon.polstra.com> To: nik@nothing-going-on.demon.co.uk Subject: Re: Moving ipf(1) to ipf(8)? In-Reply-To: <19990720211427.A4523@catkin.nothing-going-on.org> References: <19990719224454.A52115@catkin.nothing-going-on.org> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <19990720211427.A4523@catkin.nothing-going-on.org>, Nik Clayton wrote: > > Assuming I did this, what's the approved method? > > Myself, I'd just > > # mv ipf.1 ipf.8 > # cvs remove ipf.1 > # cvs add ipf.8 > # cvs commit -m "Renamed ipf.1 to ipf.8" ipf.1 ipf.8 > [... check for any other man pages that refer to ipf(1) and update > them accordingly ...] > > which properly reflects that (until the change) ipf.8 didn't exist. I > *would not* use a repository copy for this. When in doubt, ask the repo-man. :-) There's enough history in the file that _if_ it were going to be renamed, a repository copy should be used. (I don't like them either, but they're What We Do.) However, you shouldn't rename the file, because it is in the contrib tree. The whole point of contrib is that it must stay as nearly identical to the author's distributions as possible, so that imports of new versions aren't painful. I think you should lobby the author to rename the file in his own tree. Then the problem goes away when the next release is imported. Meanwhile, if you want to install it into man8, you could do it with special rules in "src/sbin/ipf/Makefile". Something like this (untested) should do the trick: MAN8= ipf.8 CLEANFILES+= ipf.8 ipf.8: ipf.1 cp ${.ALLSRC} ${.TARGET} and delete the MAN1 line for ipf.1. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 18:53:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 45AE3153D3 for ; Tue, 20 Jul 1999 18:53:19 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id TAA45544; Tue, 20 Jul 1999 19:50:35 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA90011; Tue, 20 Jul 1999 19:50:34 -0600 (MDT) Message-Id: <199907210150.TAA90011@harmony.village.org> To: tomppa@sun.fi Subject: Re: Unusable PS/2 mouse Cc: Ian Whalley , freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Jul 1999 00:34:36 +0300." <14227.39404.738278.955010@sun9.sun.fi> References: <14227.39404.738278.955010@sun9.sun.fi> <14227.34008.442998.44420@sun9.sun.fi> <3793877C.BD14AF97@whalley.org> <14227.37519.683581.802751@sun9.sun.fi> <379397BE.EBA9D1F9@whalley.org> Date: Tue, 20 Jul 1999 19:50:34 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <14227.39404.738278.955010@sun9.sun.fi> Tomi Vainio writes: : My mouse is always detected as a MouseMan+. Here is couple dmesg logs : from boots with and without monitor switch. I had problems with the my Kensignton mouse in a box, but some fixes were made to -current that fixed the problems. A workaround is to set flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a plain old 2 button (or in my case 3 button) mouse. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 19:41: 4 1999 Delivered-To: freebsd-current@freebsd.org Received: from mtiwmhc02.worldnet.att.net (mtiwmhc02.worldnet.att.net [204.127.131.37]) by hub.freebsd.org (Postfix) with ESMTP id 731C81540F for ; Tue, 20 Jul 1999 19:40:47 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: from earth.fxp ([12.77.192.177]) by mtiwmhc02.worldnet.att.net (InterMail v03.02.07.07 118-134) with ESMTP id <19990721023857.JGMI8676@earth.fxp>; Wed, 21 Jul 1999 02:38:57 +0000 Date: Tue, 20 Jul 1999 22:38:56 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@earth.fxp To: Warner Losh Cc: tomppa@sun.fi, Ian Whalley , freebsd-current@FreeBSD.ORG Subject: Re: Unusable PS/2 mouse In-Reply-To: <199907210150.TAA90011@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 Tue, 20 Jul 1999, Warner Losh wrote: > I had problems with the my Kensignton mouse in a box, but some fixes > were made to -current that fixed the problems. A workaround is to set > flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a > plain old 2 button (or in my case 3 button) mouse. > For my Kensington (on -stable) I used 'flags 0x10' (NOCHECKSYNC) to kill the out of sync messages. The only side effect I've seen is that the cursor speed is faster [than with using the serial port connector]. ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 19:43:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from wenet.net (pm3-37.ppp.wenet.net [206.15.85.37]) by hub.freebsd.org (Postfix) with ESMTP id DB1FD15415 for ; Tue, 20 Jul 1999 19:43:13 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by wenet.net (8.9.3/8.9.1) with ESMTP id TAA00643; Tue, 20 Jul 1999 19:43:01 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Tue, 20 Jul 1999 19:43:00 -0700 (PDT) From: Alex Zepeda To: Kazutaka YOKOTA Cc: freebsd-current@FreeBSD.ORG Subject: Re: Unusable PS/2 mouse In-Reply-To: <199907200208.LAA29067@zodiac.mech.utsunomiya-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Jul 1999, Kazutaka YOKOTA wrote: > One is Logitech mouse support in the psm driver. The psm driver had > been unable to handle some wheel mice models, including Logitech > M-S48, until recently. Perhaps it's worth getting another mouse in this situation. My $30 Logitech wheeled mouse (M-C48) works great with FreeBSD and has for as long as I've owned it. This seems to be the going attitude WRT CD-ROMS :^) - alex You wear guilt, like shackles on your feet, Like a halo in reverse - Depeche Mode To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 20:27:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id DBE661540E for ; Tue, 20 Jul 1999 20:27:17 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:5zfks15wmjHhRN+7n1Yx42VQzVk1SulH@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id MAA03605; Wed, 21 Jul 1999 12:25:28 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id MAA26263; Wed, 21 Jul 1999 12:29:45 +0900 (JST) Message-Id: <199907210329.MAA26263@zodiac.mech.utsunomiya-u.ac.jp> To: paul@originative.co.uk Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Unusable PS/2 mouse In-reply-to: Your message of "Tue, 20 Jul 1999 20:00:32 +0100." References: Date: Wed, 21 Jul 1999 12:29:45 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Is there any support for the wheel in FreeBSD/X, the moused man page seems >to suggest there is but I've not managed to get it to do anything yet. > >Paul. You will find the following URL useful to utilize the wheel in the X environment. http://www.inria.fr/koala/colas/mouse-wheel-scroll/ Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 20:46:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id B62A615415 for ; Tue, 20 Jul 1999 20:46:24 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:Rc8XLg8ZKa8EeI5dGWl0UylasEdZxsU4@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id MAA04228; Wed, 21 Jul 1999 12:45:04 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id MAA27216; Wed, 21 Jul 1999 12:49:22 +0900 (JST) Message-Id: <199907210349.MAA27216@zodiac.mech.utsunomiya-u.ac.jp> To: "Chris D. Faulhaber" Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Kensington mouse (was: Re: Unusable PS/2 mouse) In-reply-to: Your message of "Tue, 20 Jul 1999 22:38:56 -0400." References: Date: Wed, 21 Jul 1999 12:49:21 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Tue, 20 Jul 1999, Warner Losh wrote: > >> I had problems with the my Kensignton mouse in a box, but some fixes >> were made to -current that fixed the problems. A workaround is to set >> flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a >> plain old 2 button (or in my case 3 button) mouse. >> > >For my Kensington (on -stable) I used 'flags 0x10' (NOCHECKSYNC) to kill >the out of sync messages. The only side effect I've seen is that the >cursor speed is faster [than with using the serial port connector]. Which model is it? Kensington sells quite a number of mouse/trackball products. The model Warner talked about is "Kensington Mouse in a Box Scroll". It has a wheel between two buttons. Is that the one you are talking about? (The problem regarding "Kensington Mouse in a Box Scroll" was fixed in both -CURRENT and -STABLE about a week ago.) If not, would you give -v option to the boot command when you boot the kernel and send me /var/run/dmesg.out, so that I can diagnose what the psm driver is doing to the mouse? Kazu yokota@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 Jul 20 20:59:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 0C95D14FA5 for ; Tue, 20 Jul 1999 20:59:18 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1003) id BE9AEF818; Tue, 20 Jul 1999 23:59:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id A8EFA9B15; Tue, 20 Jul 1999 23:59:16 -0400 (EDT) Date: Tue, 20 Jul 1999 23:59:16 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: Kazutaka YOKOTA Cc: freebsd-current@freebsd.org Subject: Re: Kensington mouse (was: Re: Unusable PS/2 mouse) In-Reply-To: <199907210349.MAA27216@zodiac.mech.utsunomiya-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 21 Jul 1999, Kazutaka YOKOTA wrote: > > >On Tue, 20 Jul 1999, Warner Losh wrote: > > > >> I had problems with the my Kensignton mouse in a box, but some fixes > >> were made to -current that fixed the problems. A workaround is to set > >> flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a > >> plain old 2 button (or in my case 3 button) mouse. > >> > > > >For my Kensington (on -stable) I used 'flags 0x10' (NOCHECKSYNC) to kill > >the out of sync messages. The only side effect I've seen is that the > >cursor speed is faster [than with using the serial port connector]. > > Which model is it? Kensington sells quite a number of mouse/trackball > products. > > The model Warner talked about is "Kensington Mouse in a Box Scroll". > It has a wheel between two buttons. Is that the one you are talking > about? > > (The problem regarding "Kensington Mouse in a Box Scroll" was fixed in > both -CURRENT and -STABLE about a week ago.) > > If not, would you give -v option to the boot command when you boot the > kernel and send me /var/run/dmesg.out, so that I can diagnose what the > psm driver is doing to the mouse? > My apologies, I was inferring that I also had a "Kensington Mouse in a Box Scroll" (Model: MOSUI) ... After removing the flags from psm, the mouse is working great. This is stable cvsupped last weekend (July 15th or so). Excellent work! Thanks, Chris ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 22:44:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E5DFC151CE for ; Tue, 20 Jul 1999 22:44:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA18779; Tue, 20 Jul 1999 22:44:21 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Jul 1999 22:44:21 -0700 (PDT) From: Matthew Dillon Message-Id: <199907210544.WAA18779@apollo.backplane.com> To: freebsd-current@FreeBSD.ORG Subject: Arg! MFS broken References: <15920.932533681@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm getting really annoyed with this dev_t stuff. I wish you people would have tested a bit more before committing it all. MFS is badly broken when used in a diskless configuration. I am trying to track it all down but it is very, very frustrating. Also BOOTP seems to be broken -- rootdev is not being setup any more and I can't figure out which commit broke it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 20 23:50:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 999B114E44 for ; Tue, 20 Jul 1999 23:50:19 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA46170; Wed, 21 Jul 1999 00:50:14 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA00735; Wed, 21 Jul 1999 00:50:11 -0600 (MDT) Message-Id: <199907210650.AAA00735@harmony.village.org> To: "Chris D. Faulhaber" Subject: Re: Unusable PS/2 mouse Cc: tomppa@sun.fi, Ian Whalley , freebsd-current@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Jul 1999 22:38:56 EDT." References: Date: Wed, 21 Jul 1999 00:50:11 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Chris D. Faulhaber" writes: : > flags 0x20 (the NOIDPROBE) which forces it to behave as if it were a 0x200 (one of these days I'll learn to shift by 9) : For my Kensington (on -stable) I used 'flags 0x10' (NOCHECKSYNC) to kill : the out of sync messages. The only side effect I've seen is that the : cursor speed is faster [than with using the serial port connector]. I found that my scroll mouse went totally nuts when I tried that. It worked better, but still sucked pretty bad when it came to button events. Yokota-san was kind enough to send me a fix once I was able to send him enough data to see what was going on. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 1:18:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 30C3414D61 for ; Wed, 21 Jul 1999 01:18:44 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id KAA24177; Wed, 21 Jul 1999 10:17:59 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG Subject: Re: Arg! MFS broken In-reply-to: Your message of "Tue, 20 Jul 1999 22:44:21 PDT." <199907210544.WAA18779@apollo.backplane.com> Date: Wed, 21 Jul 1999 10:17:59 +0200 Message-ID: <24175.932545079@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907210544.WAA18779@apollo.backplane.com>, Matthew Dillon writes: > > I'm getting really annoyed with this dev_t stuff. I wish you people > would have tested a bit more before committing it all. s/you people/Poul-Henning/ Well, I tested as best I could. I don't have the luxury of large test facilities nor boundless time, but I'm doing things as well as I can. > MFS is badly broken when used in a diskless configuration. I am trying > to track it all down but it is very, very frustrating. > > Also BOOTP seems to be broken -- rootdev is not being setup any more > and I can't figure out which commit broke it. I'm sorry, I don't have either in my arsenal currently. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 3:31:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 287BA14F61 for ; Wed, 21 Jul 1999 03:31:46 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id TAA32104; Wed, 21 Jul 1999 19:29:57 +0900 (JST) Message-Id: <199907211029.TAA32104@rina.naklab.dnj.ynu.ac.jp> To: dillon@apollo.backplane.com Cc: Poul-Henning Kamp , freebsd-current@FreeBSD.ORG Cc: Seigo Tanimura Subject: Re: Arg! MFS broken From: Seigo Tanimura In-Reply-To: Your message of "Tue, 20 Jul 1999 22:44:21 -0700 (PDT)" References: <199907210544.WAA18779@apollo.backplane.com> X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 21 Jul 1999 19:29:57 +0900 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Jul 1999 22:44:21 -0700 (PDT), Matthew Dillon said: dillon> MFS is badly broken when used in a diskless configuration. I am trying dillon> to track it all down but it is very, very frustrating. I saw that on my ordinary (non-diskless :-) box last night. The second mfs mounting paniced, while the first one worked fine. Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 6: 4:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from solaris.matti.ee (solaris.matti.ee [194.126.98.135]) by hub.freebsd.org (Postfix) with ESMTP id 70EFC14E7B for ; Wed, 21 Jul 1999 06:04:31 -0700 (PDT) (envelope-from vallo@matti.ee) Received: from myhakas.matti.ee (myhakas.matti.ee [194.126.114.87]) by solaris.matti.ee (8.9.3/8.9.3) with ESMTP id QAA18627; Wed, 21 Jul 1999 16:03:59 +0300 (EET DST) Received: by myhakas.matti.ee (Postfix, from userid 1000) id 62D671FB4; Wed, 21 Jul 1999 16:04:13 +0300 (EEST) Date: Wed, 21 Jul 1999 16:04:13 +0300 From: Vallo Kallaste To: Greg Lehey Cc: freebsd-current@freebsd.org Subject: Can't open /dev/vinum/Control: Operation not supported by device Message-ID: <19990721160413.A330@myhakas.matti.ee> Reply-To: vallo@matti.ee Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Organization: =?iso-8859-1?Q?AS_Matti_B=FCrootehnika?= Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Something broke the vinum roughly between 18-21 July. Vinum refuses to get up my striped volume with message: Can't open /dev/vinum/Control: Operation not supported by device This is output from command: vinum read /dev/wd0 /dev/wd1 All subsequent commands fail with same message. The debug control device is in place, as are all others. The older kernel and module from July 16 work well. I've just built the world and kernel from fresh sources. -- Vallo Kallaste vallo@matti.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 7:11: 4 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id EABA014E5E for ; Wed, 21 Jul 1999 07:10:58 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from vega. (dialup2-45.iptelecom.net.ua [212.42.68.236]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id RAA29560 for ; Wed, 21 Jul 1999 17:15:16 +0300 (EEST) Received: from altavista.net (big_brother [192.168.1.1]) by vega. (8.9.3/8.9.3) with ESMTP id RAA10116 for ; Wed, 21 Jul 1999 17:09:14 +0300 (EEST) (envelope-from sobomax@altavista.net) Message-ID: <3795D441.170481E4@altavista.net> Date: Wed, 21 Jul 1999 17:08:01 +0300 From: Maxim Sobolev Reply-To: sobomax@altavista.net Organization: Vega International Capital X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: ru,uk,en MIME-Version: 1.0 To: current@freebsd.org Subject: VIA Appolo IDE controller handling in new ata driver Content-Type: multipart/mixed; boundary="------------A04ED3844B4A94E309A531C7" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------A04ED3844B4A94E309A531C7 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Currently VIA Apollo IDE controller in the new ata driver handled as "Generic UDMA" controller, but AFAIK this controller was designed to be fully compatible with the Intel PIIX4 chip. To test if I'm right I made a minor change in dma initialisation code to initialise it exactly as PIIX4 controller and made some benchmarks using bonnie disk benchmarking program. I found that while transfer rates changes insignificantly (probably my HDD imposes limit here - Quantum FB 2.1ST is not a very fast one) but CPU utilisation drops drastically. Maybe it would make sense to initialise VIA Apollo like PIIX4 at least until someone will write "native" code? Any opinions? You can find my benchmarks at: http://homepages.go.com/~sobomax/piix4_vs_generic.pdf Sincerely, Maxim -- "We believe in the Power and the Might!" (Manowar, 1996) ---------------------------------------- Maxim V. Sobolev, Financial Analyst, Vega International Capital Phone: +380-(44)-246-6396 Fax: +380-(44)-220-8715 E-mail: sobomax@altavista.net ICQ: #42290709 ---------------------------------------- --------------A04ED3844B4A94E309A531C7 Content-Type: text/plain; charset=koi8-r; name="ata.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ata.diff" --- ata-dma.c.orig Wed Jul 21 15:59:34 1999 +++ ata-dma.c Wed Jul 21 15:58:11 1999 @@ -83,6 +83,8 @@ type = pci_get_devid(scp->dev); switch(type) { + case 0x05711106: + printf("ata%d: %s\n", scp->lun, "VIA Apolo IDE controller (PIIX4 mode)"); case 0x71118086: /* Intel PIIX4 */ if (udmamode >= 2) { --- ata-all.c.orig Wed Jul 21 15:59:23 1999 +++ ata-all.c Wed Jul 21 15:58:12 1999 @@ -186,9 +186,9 @@ return "Promise Ultra/33 IDE controller"; case 0x522910b9: return "AcerLabs Aladdin IDE controller"; -#if 0 case 0x05711106: return "VIA Apollo IDE controller"; +#if 0 case 0x06401095: return "CMD 640 IDE controller"; case 0x06461095: --------------A04ED3844B4A94E309A531C7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 7:43:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 23471154AC for ; Wed, 21 Jul 1999 07:43:40 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id AAA20790; Thu, 22 Jul 1999 00:41:20 +1000 Date: Thu, 22 Jul 1999 00:41:20 +1000 From: Bruce Evans Message-Id: <199907211441.AAA20790@godzilla.zeta.org.au> To: current@FreeBSD.ORG, sobomax@altavista.net Subject: Re: VIA Appolo IDE controller handling in new ata driver Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Currently VIA Apollo IDE controller in the new ata driver handled as >"Generic UDMA" controller, but AFAIK this controller was designed to be >fully compatible with the Intel PIIX4 chip. To test if I'm right I made No, they are quite different. See the old driver for 500 lines of differences. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 10:29: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id 8F3EB154FD for ; Wed, 21 Jul 1999 10:29:00 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from vega. (dialup2-41.iptelecom.net.ua [212.42.68.232]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id UAA14699; Wed, 21 Jul 1999 20:34:14 +0300 (EEST) Received: from altavista.net (big_brother [192.168.1.1]) by vega. (8.9.3/8.9.3) with ESMTP id UAA13143; Wed, 21 Jul 1999 20:28:11 +0300 (EEST) (envelope-from sobomax@altavista.net) Message-ID: <3796032A.CA81015C@altavista.net> Date: Wed, 21 Jul 1999 20:28:10 +0300 From: Maxim Sobolev Reply-To: sobomax@altavista.net Organization: Vega International Capital X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: ru,uk,en MIME-Version: 1.0 To: Bruce Evans Cc: current@FreeBSD.ORG Subject: Re: VIA Appolo IDE controller handling in new ata driver References: <199907211441.AAA20790@godzilla.zeta.org.au> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > >Currently VIA Apollo IDE controller in the new ata driver handled as > >"Generic UDMA" controller, but AFAIK this controller was designed to be > >fully compatible with the Intel PIIX4 chip. To test if I'm right I made > > No, they are quite different. See the old driver for 500 lines of > differences. But why it is actually works for me? Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 11:10:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from orbit.flnet.com (orbit.flnet.com [205.240.232.32]) by hub.freebsd.org (Postfix) with ESMTP id E04391552F for ; Wed, 21 Jul 1999 11:10:09 -0700 (PDT) (envelope-from henrich@orbit.flnet.com) Received: (from henrich@localhost) by orbit.flnet.com (8.8.5/8.8.4) id OAA09815 for freebsd-current@freebsd.org; Wed, 21 Jul 1999 14:09:32 -0400 (EDT) Date: Wed, 21 Jul 1999 11:09:32 -0700 From: Charles Henrich To: freebsd-current@freebsd.org Subject: 4.0-current [/usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps"] Message-ID: <19990721110932.G7548@orbit.flnet.com> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i X-Operating-System: FreeBSD 2.2-BETA_A X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've recently upgraded to 4.0 from 3.2-stable and now whenever I try and compile something I get: /usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps" *** Error code 1 It can be a simple test program, or the kernel.. Does anyone have any ideas? Thanks! -Crh Charles Henrich Manex Visual Effects henrich@flnet.com http://orbit.flnet.com/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 15:56:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.t.dk (freesbee.t.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with SMTP id D8E6C14C46 for ; Wed, 21 Jul 1999 15:56:07 -0700 (PDT) (envelope-from ncbp@freesbee.t.dk) Received: (qmail 7370 invoked by uid 1002); 21 Jul 1999 22:54:17 -0000 Date: Thu, 22 Jul 1999 00:54:17 +0200 From: "Niels Chr. Bank-Pedersen" To: freebsd-current@freebsd.org Subject: Re: Can't open /dev/vinum/Control: Operation not supported by device Message-ID: <19990722005417.A7201@bank-pedersen.dk> Mail-Followup-To: freebsd-current@freebsd.org References: <19990721160413.A330@myhakas.matti.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.2i In-Reply-To: <19990721160413.A330@myhakas.matti.ee>; from Vallo Kallaste on Wed, Jul 21, 1999 at 04:04:13PM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 21, 1999 at 04:04:13PM +0300, Vallo Kallaste wrote: > > Hello > > Something broke the vinum roughly between 18-21 July. Vinum refuses to > get up my striped volume with message: > > Can't open /dev/vinum/Control: Operation not supported by device > > This is output from command: vinum read /dev/wd0 /dev/wd1 > > All subsequent commands fail with same message. The debug control device > is in place, as are all others. The older kernel and module from July > 16 work well. I've just built the world and kernel from fresh sources. I see _exactly_ the same here. Havent had time to look more into it though. > Vallo Kallaste > vallo@matti.ee /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, Tele Danmark NET, IP-section. "Hey, are any of you guys out there actually *using* RFC 1149?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 16:24:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id E0E8D14FB0 for ; Wed, 21 Jul 1999 16:24:29 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id IAA23959; Thu, 22 Jul 1999 08:51:45 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA95554; Thu, 22 Jul 1999 08:51:43 +0930 (CST) Date: Thu, 22 Jul 1999 08:51:42 +0930 From: Greg Lehey To: Vallo Kallaste Cc: freebsd-current@freebsd.org Subject: Re: Can't open /dev/vinum/Control: Operation not supported by device Message-ID: <19990722085142.B84734@freebie.lemis.com> References: <19990721160413.A330@myhakas.matti.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990721160413.A330@myhakas.matti.ee>; from Vallo Kallaste on Wed, Jul 21, 1999 at 04:04:13PM +0300 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 21 July 1999 at 16:04:13 +0300, Vallo Kallaste wrote: > > Hello > > Something broke the vinum roughly between 18-21 July. Vinum refuses to > get up my striped volume with message: > > Can't open /dev/vinum/Control: Operation not supported by device > > This is output from command: vinum read /dev/wd0 /dev/wd1 > > All subsequent commands fail with same message. The debug control device > is in place, as are all others. The older kernel and module from July > 16 work well. I've just built the world and kernel from fresh sources. This must be collateral damage. I haven't changed vinum in weeks. I'll build a new world and fix it, but it'll take a few hours. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 17:21:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 6979514D8B for ; Wed, 21 Jul 1999 17:21:22 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id 584FE1912; Thu, 22 Jul 1999 02:19:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id 553B449FC; Thu, 22 Jul 1999 02:19:39 +0200 (CEST) Date: Thu, 22 Jul 1999 02:19:37 +0200 (CEST) From: Andrzej Bialecki To: Matthew Dillon Cc: Nick Hibma , "Steven G. Kargl" , Poul-Henning Kamp , freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? In-Reply-To: <199907202030.NAA06800@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 20 Jul 1999, Matthew Dillon wrote: > > :And how do you create dumps from a kernel that hasn't finished booting > :(not gotten to the stage of reading rc.conf)? 'dumps on' in kernel > :config does not seem to do the job. > : > :Nick > > You can do it manually from /etc/rc. If it doesn't even get that far, > you used to be able to specify it in the kernel config but I do not know > if that is possible any more. I remember doing this once or twice from DDB - writing appropriate values to _dumpdev, as they appeared on running system. Of course, the system can be in such state that this could equally well do more harm than good... :-/ Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 17:32:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id E8AAE15556 for ; Wed, 21 Jul 1999 17:32:10 -0700 (PDT) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id TAA18447; Wed, 21 Jul 1999 19:30:37 -0500 (CDT) Date: Wed, 21 Jul 1999 19:30:37 -0500 From: "Matthew D. Fuller" To: Andrzej Bialecki Cc: Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? Message-ID: <19990721193036.B12369@futuresouth.com> References: <199907202030.NAA06800@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Andrzej Bialecki on Thu, Jul 22, 1999 at 02:19:37AM +0200 X-OS: FreeBSD Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 22, 1999 at 02:19:37AM +0200, a little birdie told me that Andrzej Bialecki remarked > On Tue, 20 Jul 1999, Matthew Dillon wrote: > > > > You can do it manually from /etc/rc. If it doesn't even get that far, > > you used to be able to specify it in the kernel config but I do not know > > if that is possible any more. > > I remember doing this once or twice from DDB - writing appropriate values > to _dumpdev, as they appeared on running system. > > Of course, the system can be in such state that this could equally well > do more harm than good... :-/ But lemme guess... This won't work with a system that panics before it gets around to probing the harddrives... This is one of my present problems :( -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ FutureSouth Communications | ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 17:35:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 0E17814C0F for ; Wed, 21 Jul 1999 17:35:01 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id 5BEBC1912; Thu, 22 Jul 1999 02:33:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id 5B08649FC; Thu, 22 Jul 1999 02:33:37 +0200 (CEST) Date: Thu, 22 Jul 1999 02:33:35 +0200 (CEST) From: Andrzej Bialecki To: "Matthew D. Fuller" Cc: Matthew Dillon , freebsd-current@FreeBSD.ORG Subject: Re: is dumpon/savecore broken? In-Reply-To: <19990721193036.B12369@futuresouth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 21 Jul 1999, Matthew D. Fuller wrote: > On Thu, Jul 22, 1999 at 02:19:37AM +0200, a little birdie told me > that Andrzej Bialecki remarked > > On Tue, 20 Jul 1999, Matthew Dillon wrote: > > > > > > You can do it manually from /etc/rc. If it doesn't even get that far, > > > you used to be able to specify it in the kernel config but I do not know > > > if that is possible any more. > > > > I remember doing this once or twice from DDB - writing appropriate values > > to _dumpdev, as they appeared on running system. > > > > Of course, the system can be in such state that this could equally well > > do more harm than good... :-/ > > But lemme guess... > This won't work with a system that panics before it gets around to > probing the harddrives... > > This is one of my present problems :( Then use remote GDB - it works miracles, I can tell you, it's just like debugging any other user space program. See the section in the handbook on that. Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 17:42:55 1999 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 2442B155C0 for ; Wed, 21 Jul 1999 17:42:50 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id RAA06490; Wed, 21 Jul 1999 17:42:45 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id RAA73145; Wed, 21 Jul 1999 17:42:45 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Wed, 21 Jul 1999 17:42:45 -0700 (PDT) Message-Id: <199907220042.RAA73145@vashon.polstra.com> To: henrich@flnet.com Subject: Re: 4.0-current [/usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps"] In-Reply-To: <19990721110932.G7548@orbit.flnet.com> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <19990721110932.G7548@orbit.flnet.com>, Charles Henrich wrote: > I've recently upgraded to 4.0 from 3.2-stable and now whenever I try and > compile something I get: > > /usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps" > *** Error code 1 That symbol should be defined in "/usr/lib/libc.so.3". Do a "nm" on the library and see if that's the case. If not, then you must have an old libc. (How did that happen?) If the symbol _is_ defined there, your ldconfig path might be wrong such that cc isn't using the correct library. Type "ldd /usr/bin/cc" to see which libraries it's really finding. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 20:26:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by hub.freebsd.org (Postfix) with ESMTP id 7728F1553F for ; Wed, 21 Jul 1999 20:26:23 -0700 (PDT) (envelope-from a.ponnampalam@utoronto.ca) Received: from 24.64.177.58.on.wave.home.com ([24.64.177.58] EHLO utoronto.ca ident: NO-IDENT-SERVICE [port 1162]) by bureau6.utcc.utoronto.ca with ESMTP id <464233-6100>; Wed, 21 Jul 1999 23:25:07 -0400 Message-ID: <37968F7D.62AA2C34@utoronto.ca> Date: Wed, 21 Jul 1999 23:26:53 -0400 From: Anandha Ponnampalam X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org Subject: mounting ntfs partition Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, how do i mount an ntfs partition sitting on a logical drive within an extended partition? Is it different from 3.2 Stable? thankx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 21:37:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from knecht.sendmail.org (knecht.sendmail.org [209.31.233.160]) by hub.freebsd.org (Postfix) with ESMTP id 2F7E714D29; Wed, 21 Jul 1999 21:37:19 -0700 (PDT) (envelope-from mckusick@flamingo.McKusick.COM) Received: from flamingo.McKusick.COM (root@flamingo.mckusick.com [209.31.233.178]) by knecht.sendmail.org (8.9.3/8.9.3) with ESMTP id VAA22897; Wed, 21 Jul 1999 21:35:06 -0700 (PDT) Received: from flamingo.McKusick.COM (mckusick@localhost.concentric.net [127.0.0.1]) by flamingo.McKusick.COM (8.9.3/8.9.0) with ESMTP id TAA23419; Wed, 21 Jul 1999 19:18:36 -0700 (PDT) Message-Id: <199907220218.TAA23419@flamingo.McKusick.COM> To: "Andrew Atrens" Subject: Re: lockmanager panic Cc: current@freebsd.org, peter@freebsd.org, dg@root.com In-reply-to: Your message of "Tue, 20 Jul 1999 14:31:30 EDT." Date: Wed, 21 Jul 1999 19:18:31 -0700 From: Kirk McKusick Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been unable to produce the panic on my test machine. My current stumbling block is that I do not know how to create the `modeule' files, specifically /modules/vn.ko. My previous patch is *not* a valid solution, but does indicate to me that the problem probably lies in a missing BUF_KERNPROC in the vnode driver before it starts an async I/O. Unfortunately, I am departing in 6.5 hours on a six week vacation. And I have no intent on taking my laptop (or any other high tech computer gear beyond my scuba diving computer) with me. Peter proved quite adept at finding the missing BUF_KERNPROC in the paging code, so I am hopeful that he can apply his wizardry here as well. If the problem has not been resolved by the time of my return (August 30th) I promise to track down the problem on my return. Kirk McKusick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 21:54:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id A78B414E40 for ; Wed, 21 Jul 1999 21:53:55 -0700 (PDT) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id AAA15757; Thu, 22 Jul 1999 00:53:09 -0400 (EDT) Message-ID: <19990722005308.A14871@netmonger.net> Date: Thu, 22 Jul 1999 00:53:08 -0400 From: Christopher Masto To: current@freebsd.org Cc: julian@whistle.com Subject: ide_pci.c DMA broken Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Revision 1.36 of sys/pci/ide_pci.c causes DMA problems and a panic on my laptop: [...] Considering FFS root f/s. changing root device to wd0s1a Card inserted, slot 0 wd0s1: type 0xa5, start 63, end = 12398399, size 12398337 : OK wd0s4: type 0xa0, start 12398400, end = 12670559, size 272160 : OK wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 start_init: trying /sbin/init wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 wd0: DMA failure, DMA status 5 spec_getpages: preposterous offset 0xffffff1c19d3fc00 vm_fault: pager read error, pid 1 (\M^P\M^A\M-b) wd0: DMA failure, DMA status 5 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x768d2d fault code = supervisor read, page not present instruction pointer = 0x8:0x768d2d stack pointer = 0x10:0xc63ddd04 frame pointer = 0x10:0xeb000000 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 = 1 (\M^P\M^A\M-b) interrupt mask = net tty bio cam Unfortunately, I don't have a serial console attached and the dmesg buffer is cut off after any ide_pci messages on the bad boot. I'll be able to get that information tomorrow if the cause of this problem isn't clear without it. I do have the full messages from a successful boot (the only change was backing ide_pci.c to 1.35): Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Thu Jul 22 00:22:46 EDT 1999 root@habanero.netmonger.net:/usr/local/usr-src/sys/compile/HABANERO Calibrating clock(s) ... TSC clock: 298385463 Hz, i8254 clock: 1193041 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/P55C (quarter-micron) (298.42-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x582 Stepping = 2 Features=0x8001bf real memory = 67043328 (65472K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00314000 - 0x03febfff, 63799296 bytes (15576 pages) sio0: gdb debugging port avail memory = 61865984 (60416K bytes) Found BIOS32 Service Directory header at 0xc00f6d60 Entry = 0xfd7f0 (0xc00fd7f0) Rev = 0 Len = 1 PCI BIOS entry at 0x214 Other BIOS signatures found: ACPI: 00000000 $PnP: 000f6d90 Preloaded elf kernel "kernel" at 0xc02fb000. Intel Pentium detected, installing workaround for F00F bug Math emulator present Initializing PnP override table Probing for PnP devices: 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 No Plug-n-Play devices were found pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71008086) npx0: on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 174155346 bytes/sec bzero() bandwidth = 719942404 bytes/sec apm0: on motherboard apm: found APM BIOS version 1.2 pci_open(1): mode 1 addr port (0x0cf8) is 0x80003b54 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71008086) pcib0: on motherboard found-> vendor=0x8086, dev=0x7100, revid=0x01 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 found-> vendor=0x8086, dev=0x7110, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[0]: type 4, range 32, base 0000fcd0, size 4 found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=d, irq=9 map[0]: type 4, range 32, base 0000fce0, size 5 found-> vendor=0x8086, dev=0x7113, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 found-> vendor=0x10c8, dev=0x0004, revid=0x01 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[0]: type 3, range 32, base fd000000, size 24 map[1]: type 1, range 32, base fea00000, size 21 map[2]: type 1, range 32, base fed00000, size 20 found-> vendor=0x104d, dev=0x8009, revid=0x01 class=0c-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[0]: type 1, range 32, base fecffc00, size 9 found-> vendor=0x1180, dev=0x0475, revid=0x00 class=06-07-00, hdrtype=0x02, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=255 pci0: on pcib0 isab0: at device 7.0 on pci0 ide_pci0: at device 7.1 on pci0 intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: primary master fastDMAonly disabled, pre/post enabled, intel_piix_status: IORDY sampling enabled, intel_piix_status: fast PIO enabled intel_piix_status: primary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 24 from port: 0000fcd2 ide_pci: ide0:0 has been configured for DMA by BIOS intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 1 status: 04 from port: 0000fcda uhci0: irq 9 at device 7.2 on pci0 uhci0: USB version 1.0, chip rev. 1 usb0: on uhci0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: at device 7.3 on pci0 intpm0: I/O mapped 2180 intpm0: intr IRQ 9 enabled revision 0 using shared irq9. intsmb0: smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 8000 vga-pci0: irq 9 at device 8.0 on pci0 pcic0: at device 10.0 on pci0 PCI Config space: 00: 04751180 02100007 06070000 00020000 10: 00000000 020000dc 00000000 00000000 20: 00000000 00000000 00000000 00000000 30: 00000000 00000000 00000000 008001ff 40: 8030104d 000003e1 00000000 00000000 50: 00000000 00000000 00000000 00000000 60: 00000000 00000000 00000000 00000000 70: 00000000 00000000 00000000 00000000 80: 00000000 00000000 04630463 00000000 90: 00000000 00000000 00000000 00000000 Cardbus Socket registers: 00: f000ff53: f000ff53: f000e2c3: f000ff53: 10: f000ff53: f000ff54: f000ac16: f000ff53: ExCa registers: 00: fb 77 c5 86 c4 c0 c8 02 08 e8 40 91 88 fe 28 e0 10: 8a 66 03 38 e0 72 02 88 e0 bf 05 00 c4 5e 04 50 20: b4 02 cd 13 5b 73 0a 4f 74 1c 30 e4 cd 13 93 eb 30: eb 0f b6 c3 01 46 08 73 03 ff 46 0a d0 e3 00 5e isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 6194MB (12685680 sectors), 13424 cyls, 15 heads, 63 S/T, 512 B/S wd0: ATA INQUIRE valid = 0007, dmamword = 0007, apio = 0003, udma = 0407 wdc1: not probed (disabled) atkbdc0: at port 0x60-0x6f on isa0 atkbd0: 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:0x0, flags:0x3d0000 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: status 10 00 64 psm: data 08 00 00 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 vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 05 f0 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 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sc0: fb0 kbd0 sio0: irq maps: 0x449 0x459 0x449 0x449 sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 sio0: type 16550A sio1: irq maps: 0x441 0x449 0x441 0x441 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: irq maps: 0x41 0x441 0x41 0x41 sio2 at port 0x3e8-0x3ef irq 10 on isa0 sio2: type 16550A ppc: parallel port found at 0x378 ppc: chipset forced to generic ppc0: ECP SPP ECP+EPP SPP ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip: irq 7 plip0: on ppbus 0 bpf: lp0 attached lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 mss_probe: no address supplied, try default 0x530 mss_detect error, busy still set (0xff) sb_probe: no address supplied, try defaults (0x220,0x240) pcm0 at port 0x220 irq 5 drq 1 on isa0 ESS1868 (rev 11) device combination doesn't support shared irq3 intr_connect(irq3) failed, result=-1 device combination doesn't support shared irq4 intr_connect(irq4) failed, result=-1 device combination doesn't support shared irq5 intr_connect(irq5) failed, result=-1 device combination doesn't support shared irq7 intr_connect(irq7) failed, result=-1 device combination doesn't support shared irq9 intr_connect(irq9) failed, result=-1 device combination doesn't support shared irq10 intr_connect(irq10) failed, result=-1 device combination doesn't support shared irq12 intr_connect(irq12) failed, result=-1 device combination doesn't support shared irq14 intr_connect(irq14) failed, result=-1 PC-Card Intel 82365 (5 mem & 2 I/O windows) pcic: controller irq 11 Initializing PC-card drivers: ep BIOS Geometries: 0:0345ef3f 0..837=838 cylinders, 0..239=240 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering MFS root f/s. No MFS image available as root f/s. IP packet filtering initialized, divert disabled, rule-based forwarding enabled, logging limited to 100 packets/entry DUMMYNET initialized (990504) bpf: tun0 attached bpf: sl0 attached bpf: ppp0 attached new masks: bio 40084240, tty 4003149a, net 4007149a bpf: lo0 attached Considering FFS root f/s. changing root device to wd0s1a Card inserted, slot 0 wd0s1: type 0xa5, start 63, end = 12398399, size 12398337 : OK wd0s4: type 0xa0, start 12398400, end = 12670559, size 272160 : OK start_init: trying /sbin/init And here's the config file: machine i386 cpu I586_CPU ident HABANERO maxusers 64 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor controller isa0 controller pnp0 # PnP support for ISA controller pci0 #controller pccard0 controller fdc0 at isa? port IO_FD1 irq 6 drq 2 disk fd0 at fdc0 drive 0 #controller ata0 #device atadisk0 # ATA disk drives #device atapicd0 # ATAPI CDROM drives #device atapist0 # ATAPI tape drives controller wdc0 at isa? port IO_WD1 irq 14 flags 0xa0ffa0ff disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? disable port IO_WD2 irq 15 disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 # atkbdc0 controls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? irq 12 # Options for psm: #options PSM_HOOKAPM #options PSM_RESETAFTERSUSPEND device vga0 at isa? port ? conflicts # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? device npx0 at nexus? port IO_NPX irq 13 device apm0 at nexus? flags 0x20 # Advanced Power Management device sio0 at isa? port IO_COM1 flags 0x90 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? port 0x3e8 irq 10 # Parallel port device ppc0 at isa? port? flags 0x40 irq 7 controller ppbus0 device lpt0 at ppbus? device plip0 at ppbus? device ppi0 at ppbus? device ep0 at isa? port 0x300 irq 10 # SMB Bus controller smbus0 controller intpm0 controller alpm0 device smb0 at smbus? # PCCARD controller card0 device pcic0 at card? #device pcic0 options PCIC_RESUME_RESET # Sound device pcm0 at isa? port ? irq 5 drq 1 flags 0x0 #controller snd0 #device sb0 at isa? port 0x220 irq 5 drq 1 #device sbxvi0 at isa? drq 5 #device sbmidi0 at isa? port 0x330 #device awe0 at isa? port 0x620 # USB controller uhci0 controller ohci0 controller usb0 #controller umass0 device ums0 device ukbd0 device ulpt0 device uhid0 device ugen0 pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 32 pseudo-device gzip # Exec gzipped a.out's pseudo-device snp 3 # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing # This provides support for System V shared memory and message queues. # options SYSVSHM options SYSVMSG options SYSVSEM # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be # aware of the legal and administrative consequences of enabling this # option. The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. pseudo-device bpf 4 #Berkeley packet filter #options NETATALK options MSGBUF_SIZE=16384 options DDB #options DDB_UNATTENDED options BREAK_TO_DEBUGGER options SOFTUPDATES options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=100 options ICMP_BANDLIM options DUMMYNET options USER_LDT #options VM86 #options VESA options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L I really don't know crap about what's going on in that part of the kernel, but I'll do whatever I can to help track this down. Or perhaps it will be intuitively obvious from this report. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- 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 Jul 21 23:33:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (castles520.castles.com [208.214.165.84]) by hub.freebsd.org (Postfix) with ESMTP id BF0F11559E for ; Wed, 21 Jul 1999 23:33:46 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id XAA01058; Wed, 21 Jul 1999 23:29:11 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907220629.XAA01058@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bruce Evans Cc: des@flood.ping.uio.no, sobomax@altavista.net, current@FreeBSD.ORG, obrien@NUXI.com Subject: Re: PLIP is still broken :( In-reply-to: Your message of "Mon, 19 Jul 1999 19:37:02 +1000." <199907190937.TAA28795@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Jul 1999 23:29:11 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >The problem with PLIP is that it tries to do splnet stuff in at > >spltty. If you force the parallell port driver to run at splnet, PLIP > >works but you get panics when you print because it tries to do spltty > >stuff at splnet. > > Possible quick fix (hack): change all the spltty()'s in lpt.c to > splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing > splnet() instead should work OK for lpt and fix if_plip. What about vpo? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 21 23:39:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 4756514FEB for ; Wed, 21 Jul 1999 23:39:49 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-3-32.ucdavis.edu [169.237.17.32]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id XAA53261; Wed, 21 Jul 1999 23:39:48 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id XAA04178; Wed, 21 Jul 1999 23:39:45 -0700 (PDT) (envelope-from obrien) Date: Wed, 21 Jul 1999 23:39:44 -0700 From: "David O'Brien" Cc: henrich@flnet.com, current@freebsd.org Subject: Re: 4.0-current [/usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps"] Message-ID: <19990721233944.A3046@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <19990721110932.G7548@orbit.flnet.com> <199907220042.RAA73145@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <199907220042.RAA73145@vashon.polstra.com>; from John Polstra on Wed, Jul 21, 1999 at 05:42:45PM -0700 X-Operating-System: FreeBSD 4.0-CURRENT Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I've recently upgraded to 4.0 from 3.2-stable and now whenever I try and > > compile something I get: > > > > /usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps" > > *** Error code 1 There was a time peroid during the gcc -> egcs transition in -CURRENT one would get this error. But a ``make world'' should have given you a consistant libc to linke with... Are you sure your /usr/src is clean of *.o files? Are you using -DNOCLEAN or any other non-standard options in your ``make world''? -- -- David (obrien@NUXI.com -or- 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 Thu Jul 22 2: 7:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35]) by hub.freebsd.org (Postfix) with ESMTP id 26F34156BA for ; Thu, 22 Jul 1999 02:07:28 -0700 (PDT) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id LAA22681 for ; Thu, 22 Jul 1999 11:07:25 +0200 (MEST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma022672; Thu, 22 Jul 99 11:07:25 +0200 Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id LAA06487 for ; Thu, 22 Jul 1999 11:07:22 +0200 (MET DST) Received: (qmail 913 invoked by uid 666); 22 Jul 1999 09:07:44 -0000 Date: Thu, 22 Jul 1999 11:07:44 +0200 From: Jos Backus To: freebsd-current@freebsd.org Subject: rootfs clean flag/mount problem Message-ID: <19990722110744.A754@hal.mpn.cp.philips.com> Reply-To: Jos Backus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After booting single-user after a crash: # mount wd0s1a on / (local, read-only) # fsck -p /dev/rwd0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/rwd0s1a: clean, 12881 free (409 frags, 1559 blocks, 1.3% fragmentation) # mount -u / WARNING: R/W mount of / denied. Filesystem is not clean - run fsck mount: Operation not permitted # Just exiting the shell doesn't work; a reboot is needed to go multi-user. -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 2:24: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id DE81514EF5 for ; Thu, 22 Jul 1999 02:24:02 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id LAA28889; Thu, 22 Jul 1999 11:21:45 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Jos Backus Cc: freebsd-current@FreeBSD.org Subject: Re: rootfs clean flag/mount problem In-reply-to: Your message of "Thu, 22 Jul 1999 11:07:44 +0200." <19990722110744.A754@hal.mpn.cp.philips.com> Date: Thu, 22 Jul 1999 11:21:45 +0200 Message-ID: <28887.932635305@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Have you rebuilt your fsck after the last commit ? In message <19990722110744.A754@hal.mpn.cp.philips.com>, Jos Backus writes: >After booting single-user after a crash: > ># mount >wd0s1a on / (local, read-only) ># fsck -p >/dev/rwd0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS >/dev/rwd0s1a: clean, 12881 free (409 frags, 1559 blocks, 1.3% fragmentation) ># mount -u / >WARNING: R/W mount of / denied. Filesystem is not clean - run fsck >mount: Operation not permitted ># > >Just exiting the shell doesn't work; a reboot is needed to go multi-user. > >-- >Jos Backus _/ _/_/_/ "Reliability means never > _/ _/ _/ having to say you're sorry." > _/ _/_/_/ -- D. J. Bernstein > _/ _/ _/ _/ >Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 2:31:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id 13AB514F21 for ; Thu, 22 Jul 1999 02:31:24 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from vega. (dialup2-56.iptelecom.net.ua [212.42.68.247]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id MAA06241; Thu, 22 Jul 1999 12:35:27 +0300 (EEST) Received: from altavista.net (big_brother [192.168.1.1]) by vega. (8.9.3/8.9.3) with ESMTP id MAA17100; Thu, 22 Jul 1999 12:27:47 +0300 (EEST) (envelope-from sobomax@altavista.net) Message-ID: <3796E410.6CC268EC@altavista.net> Date: Thu, 22 Jul 1999 12:27:44 +0300 From: Maxim Sobolev Reply-To: sobomax@altavista.net Organization: Vega International Capital X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: ru,uk,en MIME-Version: 1.0 To: Bruce Evans Cc: des@flood.ping.uio.no, current@FreeBSD.ORG, obrien@NUXI.com Subject: Re: PLIP is still broken :( References: <199907190937.TAA28795@godzilla.zeta.org.au> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Bruce Evans wrote: > Possible quick fix (hack): change all the spltty()'s in lpt.c to > splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing > splnet() instead should work OK for lpt and fix if_plip. It doesn't help much because I'm not using lpt device in my kernel so lpt.c never get compiled in it ;). Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 2:47:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id AAB5214ECA for ; Thu, 22 Jul 1999 02:47:30 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id LAA72475; Thu, 22 Jul 1999 11:45:37 +0200 (CEST) (envelope-from des) To: sobomax@altavista.net Cc: Bruce Evans , current@FreeBSD.ORG, obrien@NUXI.com Subject: Re: PLIP is still broken :( References: <199907190937.TAA28795@godzilla.zeta.org.au> <3796E410.6CC268EC@altavista.net> From: Dag-Erling Smorgrav Date: 22 Jul 1999 11:45:36 +0200 In-Reply-To: Maxim Sobolev's message of "Thu, 22 Jul 1999 12:27:44 +0300" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Maxim Sobolev writes: > Bruce Evans wrote: > > Possible quick fix (hack): change all the spltty()'s in lpt.c to > > splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing > > splnet() instead should work OK for lpt and fix if_plip. > It doesn't help much because I'm not using lpt device in my kernel so > lpt.c never get compiled in it ;). ppc.c DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 2:56:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id 77783155C8 for ; Thu, 22 Jul 1999 02:56:41 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from vega. (dialup3-60.iptelecom.net.ua [212.42.69.251]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id NAA08575; Thu, 22 Jul 1999 13:02:39 +0300 (EEST) Received: from altavista.net (big_brother [192.168.1.1]) by vega. (8.9.3/8.9.3) with ESMTP id MAA17265; Thu, 22 Jul 1999 12:55:01 +0300 (EEST) (envelope-from sobomax@altavista.net) Message-ID: <3796EA74.8E15E5B7@altavista.net> Date: Thu, 22 Jul 1999 12:55:00 +0300 From: Maxim Sobolev Reply-To: sobomax@altavista.net Organization: Vega International Capital X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: ru,uk,en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Bruce Evans , current@FreeBSD.ORG, obrien@NUXI.com Subject: Re: PLIP is still broken :( References: <199907190937.TAA28795@godzilla.zeta.org.au> <3796E410.6CC268EC@altavista.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > Maxim Sobolev writes: > > Bruce Evans wrote: > > > Possible quick fix (hack): change all the spltty()'s in lpt.c to > > > splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing > > > splnet() instead should work OK for lpt and fix if_plip. > > It doesn't help much because I'm not using lpt device in my kernel so > > lpt.c never get compiled in it ;). > > ppc.c But ppc.c doesn't contain spltty()'s in it... -Max To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 3: 6: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35]) by hub.freebsd.org (Postfix) with ESMTP id A895614DE1 for ; Thu, 22 Jul 1999 03:06:01 -0700 (PDT) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id MAA04505 for ; Thu, 22 Jul 1999 12:04:14 +0200 (MEST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma004503; Thu, 22 Jul 99 12:04:14 +0200 Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id MAA15922 for ; Thu, 22 Jul 1999 12:04:13 +0200 (MET DST) Received: (qmail 490 invoked by uid 666); 22 Jul 1999 10:04:35 -0000 Date: Thu, 22 Jul 1999 12:04:35 +0200 From: Jos Backus To: Poul-Henning Kamp Cc: Nick Hibma , freebsd-current@FreeBSD.org Subject: Re: rootfs clean flag/mount problem Message-ID: <19990722120435.A422@hal.mpn.cp.philips.com> Reply-To: Jos Backus References: <19990722110744.A754@hal.mpn.cp.philips.com> <28887.932635305@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <28887.932635305@critter.freebsd.dk>; from Poul-Henning Kamp on Thu, Jul 22, 1999 at 11:21:45AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 22, 1999 at 11:21:45AM +0200, Poul-Henning Kamp wrote: > Have you rebuilt your fsck after the last commit ? It turns out fsck was last built on Tuesday morning. I just rebuilt/reinstalled it and everything appears peachy again. fsck had not been updated yesterday because the make world I ran yesterday didn't complete, this because of a panic I have started seeing recently (a kernel built on 7-7 doesn't exhibit this panic). Of course I was running X at the time. Meanwhile I have put DDB back in so maybe I'll be able to come up with some more info. Thanks for the quick response and sorry about the false alert. -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 5:47:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 3531E14D47 for ; Thu, 22 Jul 1999 05:47:24 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id LAA21207; Thu, 22 Jul 1999 11:41:32 +0200 (MET DST) Date: Thu, 22 Jul 1999 11:41:30 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Jos Backus Cc: freebsd-current@FreeBSD.ORG Subject: Re: rootfs clean flag/mount problem In-Reply-To: <19990722110744.A754@hal.mpn.cp.philips.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 Current from when? I remember having to reboot after a crash first before the filesystem was accepted as clean. but that is gone. And I have crashed a CURRENT machine fairly often lately. Nick On Thu, 22 Jul 1999, Jos Backus wrote: > After booting single-user after a crash: > > # mount > wd0s1a on / (local, read-only) > # fsck -p > /dev/rwd0s1a: FILESYSTEM CLEAN; SKIPPING CHECKS > /dev/rwd0s1a: clean, 12881 free (409 frags, 1559 blocks, 1.3% fragmentation) > # mount -u / > WARNING: R/W mount of / denied. Filesystem is not clean - run fsck > mount: Operation not permitted > # > > Just exiting the shell doesn't work; a reboot is needed to go multi-user. > > -- > Jos Backus _/ _/_/_/ "Reliability means never > _/ _/ _/ having to say you're sorry." > _/ _/_/_/ -- D. J. Bernstein > _/ _/ _/ _/ > Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 6:11:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 2E80D151EA for ; Thu, 22 Jul 1999 06:10:53 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id PAA27196 for current@freebsd.org; Thu, 22 Jul 1999 15:08:51 +0200 (CEST) Date: Thu, 22 Jul 1999 15:08:51 +0200 From: Martin Cracauer To: current@freebsd.org Subject: DDB: How to find address of static symbol? Message-ID: <19990722150850.A27165@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I want to examine and switch a variable in ddb. The variable is static to a source file, I don't have a symbol in ddb. I see the address of the symbol with `nm /kernel | grep symname`, but the addresses listed here are obviously subject to file-specific offsets. The addresses show up twice and I can verify that the data is wrong when I just use the hex address in ddb. How can I get an address suitable for ddb? What are the offsets to add to the symbol addresses I get from nm? Thanks Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 6:23:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 6705615212 for ; Thu, 22 Jul 1999 06:23:47 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id PAA28698; Thu, 22 Jul 1999 15:23:38 +0200 (MET DST) Date: Thu, 22 Jul 1999 15:23:37 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Martin Cracauer Cc: current@FreeBSD.ORG Subject: Re: DDB: How to find address of static symbol? In-Reply-To: <19990722150850.A27165@cons.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 what about putting a break point at the beginning of the routine. Once you are there, you should be able to access it and set it. I think. But then again, a lot of people tell me that I am not very good at that. Nick On Thu, 22 Jul 1999, Martin Cracauer wrote: > I want to examine and switch a variable in ddb. The variable is static > to a source file, I don't have a symbol in ddb. > > I see the address of the symbol with `nm /kernel | grep symname`, but > the addresses listed here are obviously subject to file-specific > offsets. The addresses show up twice and I can verify that the data is > wrong when I just use the hex address in ddb. > > How can I get an address suitable for ddb? What are the offsets to add > to the symbol addresses I get from nm? > > Thanks > Martin > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Martin Cracauer http://www.cons.org/cracauer/ > Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 7:24:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 2761314DAF for ; Thu, 22 Jul 1999 07:24:21 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id AAA25033; Fri, 23 Jul 1999 00:23:59 +1000 Date: Fri, 23 Jul 1999 00:23:59 +1000 From: Bruce Evans Message-Id: <199907221423.AAA25033@godzilla.zeta.org.au> To: cracauer@cons.org, current@FreeBSD.ORG Subject: Re: DDB: How to find address of static symbol? Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I want to examine and switch a variable in ddb. The variable is static >to a source file, I don't have a symbol in ddb. You should have static symbols in ddb, except in the following broken cases: 1) elf kernel booted with -d. There are no symbols at the initial breakpoint because elf symbols are loaded by a sysinit. 2) elf kernel booted directly by boot2. Static symbols require special handling which seems to only be done in boot/loader. I don't use boot/loader, so I had to fix this. I use the pre-kld method of loading elf symbols (ddb/db_elf.c). This also fixes (1). It probably breaks symbols in modules. >I see the address of the symbol with `nm /kernel | grep symname`, but >the addresses listed here are obviously subject to file-specific >offsets. The addresses show up twice and I can verify that the data is >wrong when I just use the hex address in ddb. The symbol values are offset in the file. but not in memory. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 7:46:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 4680E151FC for ; Thu, 22 Jul 1999 07:46:40 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id QAA27441; Thu, 22 Jul 1999 16:43:59 +0200 (CEST) Date: Thu, 22 Jul 1999 16:43:59 +0200 From: Martin Cracauer To: Bruce Evans Cc: cracauer@cons.org, current@FreeBSD.ORG Subject: Re: DDB: How to find address of static symbol? Message-ID: <19990722164358.A27395@cons.org> References: <199907221423.AAA25033@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199907221423.AAA25033@godzilla.zeta.org.au>; from Bruce Evans on Fri, Jul 23, 1999 at 12:23:59AM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <199907221423.AAA25033@godzilla.zeta.org.au>, Bruce Evans wrote: > >I want to examine and switch a variable in ddb. The variable is static > >to a source file, I don't have a symbol in ddb. > > You should have static symbols in ddb, except in the following broken > cases: Ops, I did assume this isn't done due to the problem of multiple uses of the same static symbol name and hence I didn't try. In fact it works for me. Thanks. Now down with that FPU thing :-) Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 8:35: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 59DEF14CC1 for ; Thu, 22 Jul 1999 08:35:02 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id BAA29693; Fri, 23 Jul 1999 01:32:22 +1000 Date: Fri, 23 Jul 1999 01:32:22 +1000 From: Bruce Evans Message-Id: <199907221532.BAA29693@godzilla.zeta.org.au> To: Jos.Backus@nl.origin-it.com, phk@critter.freebsd.dk Subject: Re: rootfs clean flag/mount problem Cc: freebsd-current@FreeBSD.ORG, nick.hibma@jrc.it Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Have you rebuilt your fsck after the last commit ? > >It turns out fsck was last built on Tuesday morning. I just >rebuilt/reinstalled it and everything appears peachy again. I suppose current fsck's don't work with old kernels. This is more annoying than ps not working. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 8:46:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 0C6D5152E9 for ; Thu, 22 Jul 1999 08:46:44 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id RAA30150; Thu, 22 Jul 1999 17:42:46 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: Jos.Backus@nl.origin-it.com, freebsd-current@FreeBSD.ORG, nick.hibma@jrc.it Subject: Re: rootfs clean flag/mount problem In-reply-to: Your message of "Fri, 23 Jul 1999 01:32:22 +1000." <199907221532.BAA29693@godzilla.zeta.org.au> Date: Thu, 22 Jul 1999 17:42:46 +0200 Message-ID: <30148.932658166@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907221532.BAA29693@godzilla.zeta.org.au>, Bruce Evans writes: >>> Have you rebuilt your fsck after the last commit ? >> >>It turns out fsck was last built on Tuesday morning. I just >>rebuilt/reinstalled it and everything appears peachy again. > >I suppose current fsck's don't work with old kernels. This >is more annoying than ps not working. You suppose wrong. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 9:15:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from orbit.flnet.com (orbit.flnet.com [205.240.232.32]) by hub.freebsd.org (Postfix) with ESMTP id 6D36515314 for ; Thu, 22 Jul 1999 09:15:44 -0700 (PDT) (envelope-from henrich@orbit.flnet.com) Received: (from henrich@localhost) by orbit.flnet.com (8.8.5/8.8.4) id MAA07609; Thu, 22 Jul 1999 12:14:25 -0400 (EDT) Date: Thu, 22 Jul 1999 09:14:24 -0700 From: Charles Henrich To: John Polstra Cc: current@freebsd.org Subject: Re: 4.0-current [/usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps"] Message-ID: <19990722091424.A7368@orbit.flnet.com> References: <19990721110932.G7548@orbit.flnet.com> <199907220042.RAA73145@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907220042.RAA73145@vashon.polstra.com>; from John Polstra on Wed, Jul 21, 1999 at 05:42:45PM -0700 X-Operating-System: FreeBSD 2.2-BETA_A X-PGP-Fingerprint: 1024/F7 FD C7 3A F5 6A 23 BF 76 C4 B8 C9 6E 41 A4 4F Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On the subject of Re: 4.0-current [/usr/libexec/ld-elf.so.1: cc: Undefined symbol "mkstemps"], John Polstra stated: > That symbol should be defined in "/usr/lib/libc.so.3". Do a "nm" on the > library and see if that's the case. If not, then you must have an old libc. > (How did that happen?) That was it, thanks! -Crh Charles Henrich Manex Visual Effects henrich@flnet.com http://orbit.flnet.com/~henrich To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 9:16:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 3844E153C4 for ; Thu, 22 Jul 1999 09:16:24 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id CAA32368; Fri, 23 Jul 1999 02:15:00 +1000 Date: Fri, 23 Jul 1999 02:15:00 +1000 From: Bruce Evans Message-Id: <199907221615.CAA32368@godzilla.zeta.org.au> To: bde@zeta.org.au, mike@smith.net.au Subject: Re: PLIP is still broken :( Cc: current@FreeBSD.ORG, des@flood.ping.uio.no, obrien@NUXI.com, sobomax@altavista.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> Possible quick fix (hack): change all the spltty()'s in lpt.c to >> splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing >> splnet() instead should work OK for lpt and fix if_plip. > >What about vpo? vpo uses only polled mode. I think its "interrupt" handler is attached to a cam software interrupt handler of timeout handler. In any case, it is not attached to ppcintr(), so ppc's interrupt class doesn't affect it. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 9:53:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 70DE3155F5 for ; Thu, 22 Jul 1999 09:52:57 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id SAA27830; Thu, 22 Jul 1999 18:51:16 +0200 (CEST) Date: Thu, 22 Jul 1999 18:51:16 +0200 From: Martin Cracauer To: Bruce Evans Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? Message-ID: <19990722185115.A27722@cons.org> References: <199907121144.VAA07535@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199907121144.VAA07535@godzilla.zeta.org.au>; from Bruce Evans on Mon, Jul 12, 1999 at 09:44:59PM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <199907121144.VAA07535@godzilla.zeta.org.au>, Bruce Evans wrote: > >I'm going to work on FreeBSD's floating point support, but I need to > >test my changes on systems using the FPU emulators (non-GPL and GPL). > > > >Is there any way to use these emulators on a system that has a > >hardware FPU? > > Toggling `npx_exists' using ddb used to work. Now, toggling it off > on i586 systems causes a panic in the i586-optimised copy routines. This particular problem has a hook in npx.c: device npx0 [...] flags 7 seems to do the trick (disables usage of FPU-optimized mem stuff). I am now able to switch "npx_exists" between npx_probe1() and npx_attach(), which let me run with the emulator on a Pentium. But only from serial kgdb, since as you noted in your other message, symbols are not available to ddb in ELF kernels started with -d. I assume you use kdb_init() from db_elf.c, you how do you call it given that you neither have the symbol (not loaded yet) nor the address (`nm /kernel` output not useful)? [Throwing an egg after the chicken that fails to produce the egg] Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 10:16:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 7E12314C02 for ; Thu, 22 Jul 1999 10:16:47 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id DAA03332; Fri, 23 Jul 1999 03:13:37 +1000 Date: Fri, 23 Jul 1999 03:13:37 +1000 From: Bruce Evans Message-Id: <199907221713.DAA03332@godzilla.zeta.org.au> To: bde@zeta.org.au, cracauer@cons.org Subject: Re: Using float emulator on a system with FPU? Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I am now able to switch "npx_exists" between npx_probe1() and >npx_attach(), which let me run with the emulator on a Pentium. > >But only from serial kgdb, since as you noted in your other message, >symbols are not available to ddb in ELF kernels started with -d. > >I assume you use kdb_init() from db_elf.c, you how do you call it >given that you neither have the symbol (not loaded yet) nor the >address (`nm /kernel` output not useful)? The boot loader passes the relevant addresses. To use this, replace ddb_kld.c by ddb_elf.c in /sys/conf/files. Bruce diff -c2 db_elf.c~ db_elf.c *** db_elf.c~ Thu Jan 28 22:05:22 1999 --- db_elf.c Sat May 8 15:58:30 1999 *************** *** 39,55 **** */ ! #if defined(__ELF__) && defined(__alpha__) #include "opt_ddb.h" - #include #include #include - #include ! #include #include - #include #include --- 39,53 ---- */ ! #ifdef __ELF__ #include "opt_ddb.h" #include #include ! #include + #include #include #include *************** *** 81,88 **** --- 79,88 ---- int i; + #if 0 if (ALIGNED_POINTER(symtab, long) == 0) { printf("DDB: bad symbol table start address %p\n", symtab); return; } + #endif symtab_start = symtab_end = NULL; *************** *** 162,169 **** --- 162,171 ---- * Now, sanity check the symbols against the string table. */ + #if 0 if (symtab_start == NULL || strtab_start == NULL || ALIGNED_POINTER(symtab_start, long) == 0 || ALIGNED_POINTER(strtab_start, long) == 0) goto badheader; + #endif for (symp = symtab_start; symp < symtab_end; symp++) if (symp->st_name + strtab_start > strtab_end) *************** *** 216,220 **** * Lookup the symbol with the given name. */ ! db_sym_t X_db_lookup(stab, symstr) db_symtab_t *stab; --- 218,222 ---- * Lookup the symbol with the given name. */ ! c_db_sym_t X_db_lookup(stab, symstr) db_symtab_t *stab; *************** *** 228,231 **** --- 230,234 ---- strtab = db_elf_find_strtab(stab); + strtab = (char *)stab->end + 4; if (strtab == NULL) return ((db_sym_t)0); *************** *** 244,248 **** * provided threshold). */ ! db_sym_t X_db_search_symbol(symtab, off, strategy, diffp) db_symtab_t *symtab; --- 247,251 ---- * provided threshold). */ ! c_db_sym_t X_db_search_symbol(symtab, off, strategy, diffp) db_symtab_t *symtab; *************** *** 262,268 **** --- 265,273 ---- if (symp->st_name == 0) continue; + #if 0 if (ELF_ST_TYPE(symp->st_info) != STT_OBJECT && ELF_ST_TYPE(symp->st_info) != STT_FUNC) continue; + #endif if (off >= symp->st_value) { *************** *** 310,322 **** X_db_symbol_values(symtab, sym, namep, valuep) db_symtab_t *symtab; ! db_sym_t sym; const char **namep; db_expr_t *valuep; { ! Elf_Sym *symp = (Elf_Sym *)sym; char *strtab; if (namep) { strtab = db_elf_find_strtab(symtab); if (strtab == NULL) *namep = NULL; --- 315,328 ---- X_db_symbol_values(symtab, sym, namep, valuep) db_symtab_t *symtab; ! c_db_sym_t sym; const char **namep; db_expr_t *valuep; { ! const Elf_Sym *symp = (const Elf_Sym *)sym; char *strtab; if (namep) { strtab = db_elf_find_strtab(symtab); + strtab = (char *)symtab->end + 4; if (strtab == NULL) *namep = NULL; *************** *** 336,340 **** X_db_line_at_pc(symtab, cursym, filename, linenum, off) db_symtab_t *symtab; ! db_sym_t cursym; char **filename; int *linenum; --- 342,346 ---- X_db_line_at_pc(symtab, cursym, filename, linenum, off) db_symtab_t *symtab; ! c_db_sym_t cursym; char **filename; int *linenum; *************** *** 375,381 **** { if (ksym_end > ksym_start) X_db_sym_init(ksym_start, ksym_end, "kernel"); } ! #endif --- 381,395 ---- { + #ifdef __i386__ + if (bootinfo.bi_esymtab != bootinfo.bi_symtab) + db_add_symbol_table( + (char *)bootinfo.bi_symtab + 4, + (char *)bootinfo.bi_symtab + 4 + *(int *)bootinfo.bi_symtab, + "kernel", (char *)bootinfo.bi_symtab); + #else if (ksym_end > ksym_start) X_db_sym_init(ksym_start, ksym_end, "kernel"); + #endif } ! #endif /* __ELF__ */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 10:44:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (Postfix) with ESMTP id 73D3E14C02 for ; Thu, 22 Jul 1999 10:44:23 -0700 (PDT) (envelope-from schuerge@wjpserver.CS.Uni-SB.DE) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999070600) with ESMTP id TAA01547 for ; Thu, 22 Jul 1999 19:43:47 +0200 (CEST) Received: from wjpserver.cs.uni-sb.de (wjpserver.cs.uni-sb.de [134.96.247.42]) by cs.uni-sb.de (8.9.3/1999031900) with ESMTP id TAA15874 for ; Thu, 22 Jul 1999 19:43:46 +0200 (CEST) Received: (from schuerge@localhost) by wjpserver.cs.uni-sb.de (8.9.3/8.9.3/wjp-SVR4/1999052600) id TAA00970 for freebsd-current@freebsd.org; Thu, 22 Jul 1999 19:43:46 +0200 (MET DST) From: Thomas Schuerger Message-Id: <199907221743.TAA00970@wjpserver.cs.uni-sb.de> Subject: Still kernel compilation failures To: freebsd-current@freebsd.org Date: Thu, 22 Jul 1999 19:43:46 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL57 (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 Hi! I updated the source tree, built and installed the world today and tried to make a new kernel. Compilation stops when it comes to linking: ... cc -c -x assembler-with-cpp -DLOCORE -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../i386/i386/support.s cc -c -x assembler-with-cpp -DLOCORE -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf ../../i386/i386/swtch.s cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf setdef0.c cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf setdef1.c sh ../../conf/newvers.sh STARFIRE cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -include opt_global.h -elf vers.c linking kernel vfs_init.o: In function `vfs_register': vfs_init.o(.text+0x8a1): undefined reference to `sysctl(void, float, short)' *** Error code 1 1 error Exit 2 What am I doing wrong? Any help is greatly appreciated. Ciao, Thomas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 14:17:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 1966714C10 for ; Thu, 22 Jul 1999 14:17:26 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA24388; Thu, 22 Jul 1999 17:15:08 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Thu, 22 Jul 1999 17:15:07 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Thomas Schuerger Cc: freebsd-current@FreeBSD.org Subject: Re: Still kernel compilation failures In-Reply-To: <199907221743.TAA00970@wjpserver.cs.uni-sb.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 22 Jul 1999, Thomas Schuerger wrote: > Hi! > > I updated the source tree, built and installed the world today > and tried to make a new kernel. Compilation stops when it > comes to linking: > > ... > vfs_init.o: In function `vfs_register': > vfs_init.o(.text+0x8a1): undefined reference to `sysctl(void, float, short)' > *** Error code 1 > 1 error > Exit 2 > > > What am I doing wrong? Any help is greatly appreciated. > Put -O back in the COPTFLAGS. > > Ciao, > Thomas. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: 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 Jul 22 14:32:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 493E715723 for ; Thu, 22 Jul 1999 14:31:53 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id XAA28671 for current@freebsd.org; Thu, 22 Jul 1999 23:31:01 +0200 (CEST) Date: Thu, 22 Jul 1999 23:31:00 +0200 From: Martin Cracauer To: current@freebsd.org Subject: Anyone using the none-GPL FPU emulator in -current? Message-ID: <19990722233100.A28609@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems the non-GPL floating point emulator is completely broken in 4.0-current. While it still boots the kernel and brings up the system, it seems to cause every floating-point using userlevel program to coredump (i.e. ping). The people in the recent thread about dropping non-FPU machines should be aware that - if they need to distribute the OS in non-GPL compatible ways - they need to repair the emulator first. Is anyone here using the non-GPL math emulator in 4.0? Installing a 4.0 snapshot on a FPU-less machine counts! Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 14:55:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id DCAF114F29 for ; Thu, 22 Jul 1999 14:54:59 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40356>; Fri, 23 Jul 1999 07:35:10 +1000 Date: Fri, 23 Jul 1999 07:53:39 +1000 From: Peter Jeremy Subject: `stale FS getpages' messages To: current@FreeBSD.ORG Message-Id: <99Jul23.073510est.40356@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've just received the following kernel messages (running a kernel from cvs-cur 5476 - about last Thursday): vnode_pager: *** WARNING *** stale FS getpages No strategy for buffer at 0xc1c03aa8 : 0xc6168380: type VREG, usecount 3, writecount 0, refcount 0, flags (VOBJBUF) tag VT_PROCFS, type 5, pid 36, mode 0x180, flags 0 : 0xc6168380: type VREG, usecount 3, writecount 0, refcount 0, flags (VOBJBUF) tag VT_PROCFS, type 5, pid 36, mode 0x180, flags 0 vnode_pager_getpages: I/O read error vm_fault: pager read error, pid 39554 (sylk1) pid 39554 (sylk1), uid 0: exited on signal 11 (core dumped) Looking at my core dump, it seems that sylk1 had mmap()d /proc/36/regs (FWIW, this is mfs) and caused the problem by trying to de-reference the first word of the mmap'd region. Accessing the data using a read(2) works correctly. I believe this behaviour is undesirable. If I can successfully mmap() a region (the actual parameters were PROT_READ, MAP_SHARED), I should be able to read the mmap'd region. Unfortunately, I don't understand the filesystem/vnode layering well enough to be able to easily identify what's missing. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 15: 0: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id DF3421565D for ; Thu, 22 Jul 1999 14:59:00 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id VAA35747; Thu, 22 Jul 1999 21:48:27 +0100 (BST) (envelope-from nik) Date: Thu, 22 Jul 1999 21:48:27 +0100 From: Nik Clayton To: John Polstra Cc: nik@nothing-going-on.demon.co.uk, current@freebsd.org Subject: Re: Moving ipf(1) to ipf(8)? Message-ID: <19990722214827.A35411@catkin.nothing-going-on.org> References: <19990719224454.A52115@catkin.nothing-going-on.org> <19990720211427.A4523@catkin.nothing-going-on.org> <199907202358.QAA70000@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907202358.QAA70000@vashon.polstra.com>; from John Polstra on Tue, Jul 20, 1999 at 04:58:49PM -0700 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 20, 1999 at 04:58:49PM -0700, John Polstra wrote: > In article <19990720211427.A4523@catkin.nothing-going-on.org>, > Nik Clayton wrote: > > Assuming I did this, what's the approved method? > > > > Myself, I'd just > > > > # mv ipf.1 ipf.8 > > # cvs remove ipf.1 > > # cvs add ipf.8 > > # cvs commit -m "Renamed ipf.1 to ipf.8" ipf.1 ipf.8 > > [... check for any other man pages that refer to ipf(1) and update > > them accordingly ...] > > > > which properly reflects that (until the change) ipf.8 didn't exist. I > > *would not* use a repository copy for this. > > When in doubt, ask the repo-man. :-) > > There's enough history in the file that _if_ it were going to be > renamed, a repository copy should be used. (I don't like them either, > but they're What We Do.) I'm curious -- why are they what we do? When I've used CVS on other projects, it always made more sense to 'cvs remove' and 'cvs add'. That way, if you checked out files by date stamp, and chose a date prior to the renaming, the files you got back accurately reflected the state of the repository at that time. If you repo copy then the file will always have existed with the new name, even when other files (such as Makefiles) would refer to the old name. No? > However, you shouldn't rename the file, because it is in the contrib > tree. The whole point of contrib is that it must stay as nearly > identical to the author's distributions as possible, so that imports > of new versions aren't painful. Duly noted. > I think you should lobby the author to rename > the file in his own tree. Then the problem goes away when the next > release is imported. Will do. > Meanwhile, if you want to install it into man8, you could do it with > special rules in "src/sbin/ipf/Makefile". Something like this > (untested) should do the trick: > > MAN8= ipf.8 > CLEANFILES+= ipf.8 > > ipf.8: ipf.1 > cp ${.ALLSRC} ${.TARGET} > > and delete the MAN1 line for ipf.1. I'll experiment with that (current task: get new laptop working with Coda. . .) N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 15:12:20 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 527DC14F29 for ; Thu, 22 Jul 1999 15:12:12 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id IAA22899; Fri, 23 Jul 1999 08:12:04 +1000 Date: Fri, 23 Jul 1999 08:12:04 +1000 From: Bruce Evans Message-Id: <199907222212.IAA22899@godzilla.zeta.org.au> To: cracauer@cons.org, current@FreeBSD.ORG Subject: Re: Anyone using the none-GPL FPU emulator in -current? Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >It seems the non-GPL floating point emulator is completely broken in >4.0-current. > >While it still boots the kernel and brings up the system, it seems to >cause every floating-point using userlevel program to coredump (i.e. >ping). ping uses sqrt(), so it was broken by not preserving FreeBSD defaults for TARGET_FLAGS in egcs (-mno-fancy-math-387 is specially for our broken emulator but is no longer the default). >Is anyone here using the non-GPL math emulator in 4.0? Installing a >4.0 snapshot on a FPU-less machine counts! Clearly there aren't many 4.0 users who actually need an emulator. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 15:26:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (Postfix) with ESMTP id 5AFC514DCC; Thu, 22 Jul 1999 15:26:25 -0700 (PDT) (envelope-from schuerge@wjpserver.CS.Uni-SB.DE) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999070600) with ESMTP id AAA02912; Fri, 23 Jul 1999 00:25:53 +0200 (CEST) Received: from wjpserver.cs.uni-sb.de (wjpserver.cs.uni-sb.de [134.96.247.42]) by cs.uni-sb.de (8.9.3/1999031900) with ESMTP id AAA18428; Fri, 23 Jul 1999 00:25:52 +0200 (CEST) Received: (from schuerge@localhost) by wjpserver.cs.uni-sb.de (8.9.3/8.9.3/wjp-SVR4/1999052600) id AAA02759; Fri, 23 Jul 1999 00:25:52 +0200 (MET DST) From: Thomas Schuerger Message-Id: <199907222225.AAA02759@wjpserver.cs.uni-sb.de> Subject: Re: Still kernel compilation failures In-Reply-To: from "Brian F. Feldman" at "Jul 22, 1999 05:15:07 pm" To: "Brian F. Feldman" Date: Fri, 23 Jul 1999 00:25:52 +0200 (MET DST) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL57 (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 > > ... > > vfs_init.o: In function `vfs_register': > > vfs_init.o(.text+0x8a1): undefined reference to `sysctl(void, float, short)' > > *** Error code 1 > > 1 error > > Exit 2 > > > > > > What am I doing wrong? Any help is greatly appreciated. > > > > Put -O back in the COPTFLAGS. It works now. Is there any explaination why -O is required? :) Ciao, Thomas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 15:30: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 8CEEC1560B for ; Thu, 22 Jul 1999 15:29:53 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id AAA28868; Fri, 23 Jul 1999 00:29:09 +0200 (CEST) Date: Fri, 23 Jul 1999 00:29:08 +0200 From: Martin Cracauer To: Bruce Evans Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Proposed floating point changes (Re: Using float emulator on a system with FPU?) Message-ID: <19990723002908.A28851@cons.org> References: <199907121144.VAA07535@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=GvXjxJ+pjyke8COw X-Mailer: Mutt 0.95.1i In-Reply-To: <199907121144.VAA07535@godzilla.zeta.org.au>; from Bruce Evans on Mon, Jul 12, 1999 at 09:44:59PM +1000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii In <199907121144.VAA07535@godzilla.zeta.org.au>, Bruce Evans wrote: > >Guessing from LINT's comments, you had to leave out npx and include > >one of the emulators, but -current's config refuses to config a kernel > >file without npx support. > > This was broken by adding "mandatory" to the npx line in file.i386. > > >I also tried to add "disable" to npx's config line, which compiles and > >runs ok, but still uses the hardware FPU (timing and exception test). > > This may be because npx0 now attaches to nexus, but "disable" only works > for isa devices. It's annoying that userconfig doesn't support displaying > or changing npx0. BTW, PCI devices are no longer displayed by userconfig. The following diff makes FPU and FPU emulators selectable from userconfig. npx0 is still mandatory, but it gets an additional flag bit 0x08, which requests the hardware FPU to be ignored and an emulator to be used if one is compiled in. If none is compiled into the kernel, a warning is printed and the hardware FPU is used. The diff also contains the FPE trapcode stuff, which is now found to run with GPL_MATH_EMUL (although actualy computing of error codes isn't done in this case) and not to make things worse for (non-GPL) MATH_EMUL. I plan to commit this, unless someone objets (the impressive-looking trapcode table is only 127 bytes in size, to pre-comment on one issue). Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="diff.fpetrapcode-4" Index: i386/conf/LINT =================================================================== RCS file: /home/CVS-FreeBSD/src/sys/i386/conf/LINT,v retrieving revision 1.617 diff -c -r1.617 LINT *** LINT 1999/07/09 04:29:56 1.617 --- LINT 1999/07/22 22:16:32 *************** *** 956,973 **** options SC_NO_SYSMOUSE # ! # The Numeric Processing eXtension driver. This should be configured if ! # your machine has a math co-processor, unless the coprocessor is very ! # buggy. If it is not configured then you *must* configure math emulation ! # (see above). If both npx0 and emulation are configured, then only npx0 ! # is used (provided it works). device npx0 at nexus? port IO_NPX flags 0x0 irq 13 # # `flags' for npx0: ! # 0x01 don't use the npx registers to optimize bcopy ! # 0x02 don't use the npx registers to optimize bzero # 0x04 don't use the npx registers to optimize copyin or copyout. # The npx registers are normally used to optimize copying and zeroing when # all of the following conditions are satisfied: # I586_CPU is an option --- 956,975 ---- options SC_NO_SYSMOUSE # ! # The Numeric Processing eXtension driver. In addition to this, you ! # may configure a math emulator (see above). If your machine has a ! # hardware FPU and the kernel configuration includes the npx device ! # *and* a math emulator compiled into the kernel, the hardware FPU ! # will be used, unless it is found to be broken or unless "flags" to ! # npx0 includes "0x08", which requests preference for the emulator. device npx0 at nexus? port IO_NPX flags 0x0 irq 13 # # `flags' for npx0: ! # 0x01 don't use the npx registers to optimize bcopy. ! # 0x02 don't use the npx registers to optimize bzero. # 0x04 don't use the npx registers to optimize copyin or copyout. + # 0x08 use emulator even if hardware FPU is available. # The npx registers are normally used to optimize copying and zeroing when # all of the following conditions are satisfied: # I586_CPU is an option *************** *** 978,983 **** --- 980,988 ---- # The flags can be used to control cases where it doesn't work or is slower. # Setting them at boot time using userconfig works right (the optimizations # are not used until later in the bootstrap when npx0 is attached). + # Flag 0x08 does not imply any settings of the other flags, you may run + # with FPU preference set to emulator, but still using the i586 optimized + # memory routines. # # *************** *** 1149,1154 **** --- 1154,1160 ---- # higher priority console). This replaces the COMCONSOLE option. # 0x40 reserve this unit for low level console operations. Do not # access the device in any normal way. + # 0x80 use this port for serial line gdb support in ddb. # # PnP `flags' (set via userconfig using pnp x flags y) # 0x1 disable probing of this device. Used to prevent your modem Index: i386/i386/trap.c =================================================================== RCS file: /home/CVS-FreeBSD/src/sys/i386/i386/trap.c,v retrieving revision 1.139 diff -c -r1.139 trap.c *** trap.c 1999/06/18 14:32:16 1.139 --- trap.c 1999/07/22 19:13:55 *************** *** 360,366 **** break; case T_DIVIDE: /* integer divide fault */ ! ucode = FPE_INTDIV_TRAP; i = SIGFPE; break; --- 360,366 ---- break; case T_DIVIDE: /* integer divide fault */ ! ucode = FPE_INTDIV; i = SIGFPE; break; *************** *** 382,393 **** #endif /* NISA > 0 */ case T_OFLOW: /* integer overflow fault */ ! ucode = FPE_INTOVF_TRAP; i = SIGFPE; break; case T_BOUND: /* bounds check fault */ ! ucode = FPE_SUBRNG_TRAP; i = SIGFPE; break; --- 382,393 ---- #endif /* NISA > 0 */ case T_OFLOW: /* integer overflow fault */ ! ucode = FPE_INTOVF; i = SIGFPE; break; case T_BOUND: /* bounds check fault */ ! ucode = FPE_FLTSUB; i = SIGFPE; break; Index: i386/i386/userconfig.c =================================================================== RCS file: /home/CVS-FreeBSD/src/sys/i386/i386/userconfig.c,v retrieving revision 1.148 diff -c -r1.148 userconfig.c *** userconfig.c 1999/07/09 04:29:54 1.148 --- userconfig.c 1999/07/22 19:52:10 *************** *** 458,464 **** {"apm", "Advanced Power Management", FLG_FIXED, CLS_MISC}, {"labpc", "National Instruments Lab-PC/Lab-PC+", 0, CLS_MISC}, ! {"npx", "Math coprocessor", FLG_INVISIBLE, CLS_MISC}, {"lkm", "Loadable PCI driver support", FLG_INVISIBLE, CLS_MISC}, {"vga", "Catchall PCI VGA driver", FLG_INVISIBLE, CLS_MISC}, {"chip", "PCI chipset support", FLG_INVISIBLE, CLS_MISC}, --- 458,464 ---- {"apm", "Advanced Power Management", FLG_FIXED, CLS_MISC}, {"labpc", "National Instruments Lab-PC/Lab-PC+", 0, CLS_MISC}, ! {"npx", "Math coprocessor", FLG_IMMUTABLE, CLS_MISC}, {"lkm", "Loadable PCI driver support", FLG_INVISIBLE, CLS_MISC}, {"vga", "Catchall PCI VGA driver", FLG_INVISIBLE, CLS_MISC}, {"chip", "PCI chipset support", FLG_INVISIBLE, CLS_MISC}, Index: i386/include/ieeefp.h =================================================================== RCS file: /home/CVS-FreeBSD/src/sys/i386/include/ieeefp.h,v retrieving revision 1.5 diff -c -r1.5 ieeefp.h *** ieeefp.h 1997/02/22 09:34:41 1.5 --- ieeefp.h 1999/07/22 19:13:55 *************** *** 72,77 **** --- 72,78 ---- #define FP_X_OFL 0x08 /* overflow */ #define FP_X_UFL 0x10 /* underflow */ #define FP_X_IMP 0x20 /* (im)precision */ + #define FP_X_STK 0x40 /* stack fault */ /* * FP registers Index: i386/include/trap.h =================================================================== RCS file: /home/CVS-FreeBSD/src/sys/i386/include/trap.h,v retrieving revision 1.7 diff -c -r1.7 trap.h *** trap.h 1997/02/22 09:35:19 1.7 --- trap.h 1999/07/22 19:13:55 *************** *** 76,88 **** #define ILL_ALIGN_FAULT T_ALIGNFLT #define ILL_FPOP_FAULT T_FPOPFLT /* coprocessor operand fault */ ! /* codes for SIGFPE/ARITHTRAP */ #define FPE_INTOVF_TRAP 0x1 /* integer overflow */ #define FPE_INTDIV_TRAP 0x2 /* integer divide by zero */ #define FPE_FLTDIV_TRAP 0x3 /* floating/decimal divide by zero */ #define FPE_FLTOVF_TRAP 0x4 /* floating overflow */ #define FPE_FLTUND_TRAP 0x5 /* floating underflow */ ! #define FPE_FPU_NP_TRAP 0x6 /* floating point unit not present */ #define FPE_SUBRNG_TRAP 0x7 /* subrange out of bounds */ /* codes for SIGBUS */ --- 76,104 ---- #define ILL_ALIGN_FAULT T_ALIGNFLT #define ILL_FPOP_FAULT T_FPOPFLT /* coprocessor operand fault */ ! /* ! * codes for SIGFPE/ARITHTRAP ! * ! */ ! /* portable macros */ ! #define FPE_INTDIV 1 /* integer divide by zero */ ! #define FPE_INTOVF 2 /* integer overflow */ ! #define FPE_FLTDIV 3 /* floating point divide by zero */ ! #define FPE_FLTOVF 4 /* floating point overflow */ ! #define FPE_FLTUND 5 /* floating point underflow */ ! #define FPE_FLTRES 6 /* floating point inexact result */ ! #define FPE_FLTINV 7 /* invalid floating point operation */ ! #define FPE_FLTSUB 8 /* subscript out of range */ ! ! /* old FreeBSD macros, deprecated */ #define FPE_INTOVF_TRAP 0x1 /* integer overflow */ #define FPE_INTDIV_TRAP 0x2 /* integer divide by zero */ #define FPE_FLTDIV_TRAP 0x3 /* floating/decimal divide by zero */ #define FPE_FLTOVF_TRAP 0x4 /* floating overflow */ #define FPE_FLTUND_TRAP 0x5 /* floating underflow */ ! #define FPE_FPU_NP_TRAP 0x6 /* floating point unit not present ! * - won't happen in practice ! */ #define FPE_SUBRNG_TRAP 0x7 /* subrange out of bounds */ /* codes for SIGBUS */ Index: i386/isa/npx.c =================================================================== RCS file: /home/CVS-FreeBSD/src/sys/i386/isa/npx.c,v retrieving revision 1.73 diff -c -r1.73 npx.c *** npx.c 1999/05/15 17:58:58 1.73 --- npx.c 1999/07/22 22:14:19 *************** *** 86,91 **** --- 86,92 ---- #define NPX_DISABLE_I586_OPTIMIZED_BCOPY (1 << 0) #define NPX_DISABLE_I586_OPTIMIZED_BZERO (1 << 1) #define NPX_DISABLE_I586_OPTIMIZED_COPYIO (1 << 2) + #define NPX_PREFER_EMULATOR (1 << 3) #ifdef __GNUC__ *************** *** 396,429 **** npx_attach(dev) device_t dev; { - #ifdef I586_CPU int flags; ! #endif device_print_prettyname(dev); if (npx_irq13) { printf("using IRQ 13 interface\n"); } else { - if (npx_ex16) - printf("INT 16 interface\n"); #if defined(MATH_EMULATE) || defined(GPL_MATH_EMULATE) ! else if (npx_exists) { printf("error reporting broken; using 387 emulator\n"); hw_float = npx_exists = 0; } else printf("387 emulator\n"); #else ! else ! printf("no 387 emulator in kernel!\n"); #endif } npxinit(__INITIAL_NPXCW__); #ifdef I586_CPU ! if (resource_int_value("npx", 0, "flags", &flags) != 0) ! flags = 0; ! ! if (cpu_class == CPUCLASS_586 && npx_ex16 && timezero("i586_bzero()", i586_bzero) < timezero("bzero()", bzero) * 4 / 5) { if (!(flags & NPX_DISABLE_I586_OPTIMIZED_BCOPY)) { --- 397,440 ---- npx_attach(dev) device_t dev; { int flags; ! ! if (resource_int_value("npx", 0, "flags", &flags) != 0) ! flags = 0; device_print_prettyname(dev); if (npx_irq13) { printf("using IRQ 13 interface\n"); } else { #if defined(MATH_EMULATE) || defined(GPL_MATH_EMULATE) ! if (npx_ex16) { ! if (!(flags & NPX_PREFER_EMULATOR)) ! printf("INT 16 interface\n"); ! else { ! printf("FPU exists, but flags request " ! "emulator\n"); ! hw_float = npx_exists = 0; ! } ! } else if (npx_exists) { printf("error reporting broken; using 387 emulator\n"); hw_float = npx_exists = 0; } else printf("387 emulator\n"); #else ! if (npx_ex16) { ! printf("INT 16 interface\n"); ! if (flags & NPX_PREFER_EMULATOR) { ! printf("emulator requested, but none compiled " ! "into kernel, using FPU\n"); ! } ! } else ! printf("no 387 emulator in kernel and no FPU!\n"); #endif } npxinit(__INITIAL_NPXCW__); #ifdef I586_CPU ! if (cpu_class == CPUCLASS_586 && npx_ex16 && npx_exists && timezero("i586_bzero()", i586_bzero) < timezero("bzero()", bzero) * 4 / 5) { if (!(flags & NPX_DISABLE_I586_OPTIMIZED_BCOPY)) { *************** *** 494,513 **** #endif } /* * Preserve the FP status word, clear FP exceptions, then generate a SIGFPE. * * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now * depend on longjmp() restoring a usable state. Restoring the state * or examining it might fail if we didn't clear exceptions. - * - * XXX there is no standard way to tell SIGFPE handlers about the error - * state. The old interface: - * - * void handler(int sig, int code, struct sigcontext *scp); * ! * is broken because it is non-ANSI and because the FP state is not in ! * struct sigcontext. * * XXX the FP state is not preserved across signal handlers. So signal * handlers cannot afford to do FP unless they preserve the state or --- 505,693 ---- #endif } + /* + * The following mechanism is used to ensure that the FPE_... value + * that is passed as a trapcode to the signal handler of the user + * process does not have more than one bit set. + * + * Multiple bits may be set if the user process modifies the control + * word while a status word bit is already set. While this is a sign + * of bad coding, we have no choise than to narrow them down to one + * bit, since we must not send a trapcode that is not exactly one of + * the FPE_ macros. + * + * The mechanism has a static table with 127 entries. Each combination + * of the 7 FPU status word exception bits directly translates to a + * position in this table, where a single FPE_... value is stored. + * This FPE_... value stored there is considered the "most important" + * of the exception bits and will be sent as the signal code. The + * precedence of the bits is based upon Intel Document "Numerical + * Applications", Chapter "Special Computational Situations". + * + * The macro to choose one of these values does these steps: 1) Throw + * away status word bits that cannot be masked. 2) Throw away the bits + * currently masked in the control word, assuming the user isn't + * interested in them anymore. 3) Reinsert status word bit 7 (stack + * fault) if it is set, which cannot be masked but must be presered. + * 4) Use the remaining bits to point into the trapcode table. + * + * The 6 maskable bits in order of their preference, as stated in the + * above referenced Intel manual: + * 1 Invalid operation (FP_X_INV) + * 1a Stack underflow + * 1b Stack overflow + * 1c Operand of unsupported format + * 1d SNaN operand. + * 2 QNaN operand (not an exception, irrelavant here) + * 3 Any other invalid-operation not mentioned above or zero divide + * (FP_X_INV, FP_X_DZ) + * 4 Denormal operand (FP_X_DNML) + * 5 Numeric over/underflow (FP_X_OFL, FP_X_UFL) + * 6 Inexact result (FP_X_IMP) */ + + static char fpetable[128] = { + 0, + FPE_FLTINV, /* 1 - INV */ + FPE_FLTUND, /* 2 - DNML */ + FPE_FLTINV, /* 3 - INV | DNML */ + FPE_FLTDIV, /* 4 - DZ */ + FPE_FLTINV, /* 5 - INV | DZ */ + FPE_FLTDIV, /* 6 - DNML | DZ */ + FPE_FLTINV, /* 7 - INV | DNML | DZ */ + FPE_FLTOVF, /* 8 - OFL */ + FPE_FLTINV, /* 9 - INV | OFL */ + FPE_FLTUND, /* A - DNML | OFL */ + FPE_FLTINV, /* B - INV | DNML | OFL */ + FPE_FLTDIV, /* C - DZ | OFL */ + FPE_FLTINV, /* D - INV | DZ | OFL */ + FPE_FLTDIV, /* E - DNML | DZ | OFL */ + FPE_FLTINV, /* F - INV | DNML | DZ | OFL */ + FPE_FLTUND, /* 10 - UFL */ + FPE_FLTINV, /* 11 - INV | UFL */ + FPE_FLTUND, /* 12 - DNML | UFL */ + FPE_FLTINV, /* 13 - INV | DNML | UFL */ + FPE_FLTDIV, /* 14 - DZ | UFL */ + FPE_FLTINV, /* 15 - INV | DZ | UFL */ + FPE_FLTDIV, /* 16 - DNML | DZ | UFL */ + FPE_FLTINV, /* 17 - INV | DNML | DZ | UFL */ + FPE_FLTOVF, /* 18 - OFL | UFL */ + FPE_FLTINV, /* 19 - INV | OFL | UFL */ + FPE_FLTUND, /* 1A - DNML | OFL | UFL */ + FPE_FLTINV, /* 1B - INV | DNML | OFL | UFL */ + FPE_FLTDIV, /* 1C - DZ | OFL | UFL */ + FPE_FLTINV, /* 1D - INV | DZ | OFL | UFL */ + FPE_FLTDIV, /* 1E - DNML | DZ | OFL | UFL */ + FPE_FLTINV, /* 1F - INV | DNML | DZ | OFL | UFL */ + FPE_FLTRES, /* 20 - IMP */ + FPE_FLTINV, /* 21 - INV | IMP */ + FPE_FLTUND, /* 22 - DNML | IMP */ + FPE_FLTINV, /* 23 - INV | DNML | IMP */ + FPE_FLTDIV, /* 24 - DZ | IMP */ + FPE_FLTINV, /* 25 - INV | DZ | IMP */ + FPE_FLTDIV, /* 26 - DNML | DZ | IMP */ + FPE_FLTINV, /* 27 - INV | DNML | DZ | IMP */ + FPE_FLTOVF, /* 28 - OFL | IMP */ + FPE_FLTINV, /* 29 - INV | OFL | IMP */ + FPE_FLTUND, /* 2A - DNML | OFL | IMP */ + FPE_FLTINV, /* 2B - INV | DNML | OFL | IMP */ + FPE_FLTDIV, /* 2C - DZ | OFL | IMP */ + FPE_FLTINV, /* 2D - INV | DZ | OFL | IMP */ + FPE_FLTDIV, /* 2E - DNML | DZ | OFL | IMP */ + FPE_FLTINV, /* 2F - INV | DNML | DZ | OFL | IMP */ + FPE_FLTUND, /* 30 - UFL | IMP */ + FPE_FLTINV, /* 31 - INV | UFL | IMP */ + FPE_FLTUND, /* 32 - DNML | UFL | IMP */ + FPE_FLTINV, /* 33 - INV | DNML | UFL | IMP */ + FPE_FLTDIV, /* 34 - DZ | UFL | IMP */ + FPE_FLTINV, /* 35 - INV | DZ | UFL | IMP */ + FPE_FLTDIV, /* 36 - DNML | DZ | UFL | IMP */ + FPE_FLTINV, /* 37 - INV | DNML | DZ | UFL | IMP */ + FPE_FLTOVF, /* 38 - OFL | UFL | IMP */ + FPE_FLTINV, /* 39 - INV | OFL | UFL | IMP */ + FPE_FLTUND, /* 3A - DNML | OFL | UFL | IMP */ + FPE_FLTINV, /* 3B - INV | DNML | OFL | UFL | IMP */ + FPE_FLTDIV, /* 3C - DZ | OFL | UFL | IMP */ + FPE_FLTINV, /* 3D - INV | DZ | OFL | UFL | IMP */ + FPE_FLTDIV, /* 3E - DNML | DZ | OFL | UFL | IMP */ + FPE_FLTINV, /* 3F - INV | DNML | DZ | OFL | UFL | IMP */ + FPE_FLTSUB, /* 40 - STK */ + FPE_FLTSUB, /* 41 - INV | STK */ + FPE_FLTUND, /* 42 - DNML | STK */ + FPE_FLTSUB, /* 43 - INV | DNML | STK */ + FPE_FLTDIV, /* 44 - DZ | STK */ + FPE_FLTSUB, /* 45 - INV | DZ | STK */ + FPE_FLTDIV, /* 46 - DNML | DZ | STK */ + FPE_FLTSUB, /* 47 - INV | DNML | DZ | STK */ + FPE_FLTOVF, /* 48 - OFL | STK */ + FPE_FLTSUB, /* 49 - INV | OFL | STK */ + FPE_FLTUND, /* 4A - DNML | OFL | STK */ + FPE_FLTSUB, /* 4B - INV | DNML | OFL | STK */ + FPE_FLTDIV, /* 4C - DZ | OFL | STK */ + FPE_FLTSUB, /* 4D - INV | DZ | OFL | STK */ + FPE_FLTDIV, /* 4E - DNML | DZ | OFL | STK */ + FPE_FLTSUB, /* 4F - INV | DNML | DZ | OFL | STK */ + FPE_FLTUND, /* 50 - UFL | STK */ + FPE_FLTSUB, /* 51 - INV | UFL | STK */ + FPE_FLTUND, /* 52 - DNML | UFL | STK */ + FPE_FLTSUB, /* 53 - INV | DNML | UFL | STK */ + FPE_FLTDIV, /* 54 - DZ | UFL | STK */ + FPE_FLTSUB, /* 55 - INV | DZ | UFL | STK */ + FPE_FLTDIV, /* 56 - DNML | DZ | UFL | STK */ + FPE_FLTSUB, /* 57 - INV | DNML | DZ | UFL | STK */ + FPE_FLTOVF, /* 58 - OFL | UFL | STK */ + FPE_FLTSUB, /* 59 - INV | OFL | UFL | STK */ + FPE_FLTUND, /* 5A - DNML | OFL | UFL | STK */ + FPE_FLTSUB, /* 5B - INV | DNML | OFL | UFL | STK */ + FPE_FLTDIV, /* 5C - DZ | OFL | UFL | STK */ + FPE_FLTSUB, /* 5D - INV | DZ | OFL | UFL | STK */ + FPE_FLTDIV, /* 5E - DNML | DZ | OFL | UFL | STK */ + FPE_FLTSUB, /* 5F - INV | DNML | DZ | OFL | UFL | STK */ + FPE_FLTRES, /* 60 - IMP | STK */ + FPE_FLTSUB, /* 61 - INV | IMP | STK */ + FPE_FLTUND, /* 62 - DNML | IMP | STK */ + FPE_FLTSUB, /* 63 - INV | DNML | IMP | STK */ + FPE_FLTDIV, /* 64 - DZ | IMP | STK */ + FPE_FLTSUB, /* 65 - INV | DZ | IMP | STK */ + FPE_FLTDIV, /* 66 - DNML | DZ | IMP | STK */ + FPE_FLTSUB, /* 67 - INV | DNML | DZ | IMP | STK */ + FPE_FLTOVF, /* 68 - OFL | IMP | STK */ + FPE_FLTSUB, /* 69 - INV | OFL | IMP | STK */ + FPE_FLTUND, /* 6A - DNML | OFL | IMP | STK */ + FPE_FLTSUB, /* 6B - INV | DNML | OFL | IMP | STK */ + FPE_FLTDIV, /* 6C - DZ | OFL | IMP | STK */ + FPE_FLTSUB, /* 6D - INV | DZ | OFL | IMP | STK */ + FPE_FLTDIV, /* 6E - DNML | DZ | OFL | IMP | STK */ + FPE_FLTSUB, /* 6F - INV | DNML | DZ | OFL | IMP | STK */ + FPE_FLTUND, /* 70 - UFL | IMP | STK */ + FPE_FLTSUB, /* 71 - INV | UFL | IMP | STK */ + FPE_FLTUND, /* 72 - DNML | UFL | IMP | STK */ + FPE_FLTSUB, /* 73 - INV | DNML | UFL | IMP | STK */ + FPE_FLTDIV, /* 74 - DZ | UFL | IMP | STK */ + FPE_FLTSUB, /* 75 - INV | DZ | UFL | IMP | STK */ + FPE_FLTDIV, /* 76 - DNML | DZ | UFL | IMP | STK */ + FPE_FLTSUB, /* 77 - INV | DNML | DZ | UFL | IMP | STK */ + FPE_FLTOVF, /* 78 - OFL | UFL | IMP | STK */ + FPE_FLTSUB, /* 79 - INV | OFL | UFL | IMP | STK */ + FPE_FLTUND, /* 7A - DNML | OFL | UFL | IMP | STK */ + FPE_FLTSUB, /* 7B - INV | DNML | OFL | UFL | IMP | STK */ + FPE_FLTDIV, /* 7C - DZ | OFL | UFL | IMP | STK */ + FPE_FLTSUB, /* 7D - INV | DZ | OFL | UFL | IMP | STK */ + FPE_FLTDIV, /* 7E - DNML | DZ | OFL | UFL | IMP | STK */ + FPE_FLTSUB, /* 7F - INV | DNML | DZ | OFL | UFL | IMP | STK */ + }; + + #define ENCODE(_sw, _cw) (fpetable[(_sw & ~_cw & 0x3f) | (_sw & 0x40)]) + /* * Preserve the FP status word, clear FP exceptions, then generate a SIGFPE. * * Clearing exceptions is necessary mainly to avoid IRQ13 bugs. We now * depend on longjmp() restoring a usable state. Restoring the state * or examining it might fail if we didn't clear exceptions. * ! * The error code chosen will be one of the FPE_... macros. It will be ! * sent as the second argument to old BSD-style signal handlers and as ! * "siginfo_t->si_code" (second argument) to SA_SIGINFO signal handlers. * * XXX the FP state is not preserved across signal handlers. So signal * handlers cannot afford to do FP unless they preserve the state or *************** *** 520,525 **** --- 700,706 ---- void *dummy; { int code; + u_long cw; struct intrframe *frame; if (npxproc == NULL || !npx_exists) { *************** *** 535,540 **** --- 716,722 ---- outb(0xf0, 0); fnstsw(&curpcb->pcb_savefpu.sv_ex_sw); + fnstcw(&cw); fnclex(); /* *************** *** 554,568 **** * just before it is used). */ curproc->p_md.md_regs = INTR_TO_TRAPFRAME(frame); - #ifdef notyet /* * Encode the appropriate code for detailed information on * this exception. */ ! code = XXX_ENCODE(curpcb->pcb_savefpu.sv_ex_sw); ! #else ! code = 0; /* XXX */ ! #endif trapsignal(curproc, SIGFPE, code); } else { /* --- 736,746 ---- * just before it is used). */ curproc->p_md.md_regs = INTR_TO_TRAPFRAME(frame); /* * Encode the appropriate code for detailed information on * this exception. */ ! code = ENCODE(curpcb->pcb_savefpu.sv_ex_sw, cw); trapsignal(curproc, SIGFPE, code); } else { /* --GvXjxJ+pjyke8COw-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 20:13: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from scrooge.ee.swin.oz.au (scrooge.ee.swin.oz.au [136.186.4.20]) by hub.freebsd.org (Postfix) with SMTP id 2614F14D01 for ; Thu, 22 Jul 1999 20:12:56 -0700 (PDT) (envelope-from dtc@scrooge.ee.swin.oz.au) Received: (from dtc@localhost) by scrooge.ee.swin.oz.au (8.6.9/8.6.9) id NAA17593; Fri, 23 Jul 1999 13:13:56 +1000 From: Douglas Thomas Crosher Message-Id: <199907230313.NAA17593@scrooge.ee.swin.oz.au> Subject: Re: Proposed floating point changes (Re: Using float emulator on a system with FPU?) To: cracauer@cons.org (Martin Cracauer) Date: Fri, 23 Jul 1999 13:13:56 +1000 (EST) Cc: freebsd-current@freebsd.org In-Reply-To: <19990723002908.A28851@cons.org> from "Martin Cracauer" at Jul 23, 99 00:29:08 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 579 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > + * The macro to choose one of these values does these steps: 1) Throw > + * away status word bits that cannot be masked. 2) Throw away the bits > + * currently masked in the control word, assuming the user isn't > + * interested in them anymore. 3) Reinsert status word bit 7 (stack Throwing away the status bits is rather restricting. This restriction could be avoided by passing back the status word within the third argument. A library function could be provided to implement your error code mapping while not limiting the kernel interface. Regards Douglas Crosher To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 21:10:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 1EAA114C28 for ; Thu, 22 Jul 1999 21:10:23 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id AAA32179; Fri, 23 Jul 1999 00:10:10 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 23 Jul 1999 00:10:10 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Thomas Schuerger Cc: freebsd-current@FreeBSD.org Subject: Re: Still kernel compilation failures In-Reply-To: <199907222225.AAA02759@wjpserver.cs.uni-sb.de> 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 Fri, 23 Jul 1999, Thomas Schuerger wrote: > > > ... > > > vfs_init.o: In function `vfs_register': > > > vfs_init.o(.text+0x8a1): undefined reference to `sysctl(void, float, short)' > > > *** Error code 1 > > > 1 error > > > Exit 2 > > > > > > > > > What am I doing wrong? Any help is greatly appreciated. > > > > > > > Put -O back in the COPTFLAGS. > > It works now. Is there any explaination why -O is required? :) Noone compiles without -O, so(/and) it's not supported. My take is that EGCS says "Hey, I am in optimization level foobar! I can optimize for unused code. Hmm... that's unused, so...". Either that or its debugging support is really uNFed up. > > > Ciao, > Thomas. > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: 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 Jul 22 21:15:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id AA21814C4A; Thu, 22 Jul 1999 21:15:40 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Thu, 22 Jul 1999 21:12:03 -0700 From: "David Schwartz" To: "Brian F. Feldman" , "Thomas Schuerger" Cc: Subject: RE: Still kernel compilation failures Date: Thu, 22 Jul 1999 21:12:03 -0700 Message-ID: <000001bed4c1$84ba96b0$021d85d1@youwant.to> 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 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Noone compiles without -O, so(/and) it's not supported. My take is > that EGCS says "Hey, I am in optimization level foobar! I can optimize > for unused code. Hmm... that's unused, so...". Either that or its > debugging support is really uNFed up. Actually, more likely at high enough optimization levels, syscall is an internal. At low levels, it would have to be an actual function. No such function exists. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 21:26:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 9523514CCB; Thu, 22 Jul 1999 21:26:33 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id OAA01541; Fri, 23 Jul 1999 14:24:29 +1000 Date: Fri, 23 Jul 1999 14:24:29 +1000 From: Bruce Evans Message-Id: <199907230424.OAA01541@godzilla.zeta.org.au> To: green@FreeBSD.ORG, schuerge@wjpserver.CS.Uni-SB.DE Subject: Re: Still kernel compilation failures Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> > Put -O back in the COPTFLAGS. >> >> It works now. Is there any explaination why -O is required? :) > >Noone compiles without -O, so(/and) it's not supported. My take is It is supported, but someone broke it. >that EGCS says "Hey, I am in optimization level foobar! I can optimize >for unused code. Hmm... that's unused, so...". Either that or its >debugging support is really uNFed up. -O works because optimisation removes an unused reference to a nonexistent variable. The variable once existed and was used. It still exists under a different name. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 22 21:34:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 454561569D for ; Thu, 22 Jul 1999 21:34:17 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id AAA32642; Fri, 23 Jul 1999 00:33:56 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 23 Jul 1999 00:33:56 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Bruce Evans Cc: schuerge@wjpserver.CS.Uni-SB.DE, freebsd-current@FreeBSD.org Subject: Re: Still kernel compilation failures In-Reply-To: <199907230424.OAA01541@godzilla.zeta.org.au> 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 Fri, 23 Jul 1999, Bruce Evans wrote: > >> > Put -O back in the COPTFLAGS. > >> > >> It works now. Is there any explaination why -O is required? :) > > > >Noone compiles without -O, so(/and) it's not supported. My take is > > It is supported, but someone broke it. Since when? Every so often someone comes along (from a pool of maybe 5 people who _don't_ use -O) and complains about it being broken. If anyone developing it actually used it, it wouldn't be broken. As it stands, there's no good reason not to have -O. > > >that EGCS says "Hey, I am in optimization level foobar! I can optimize > >for unused code. Hmm... that's unused, so...". Either that or its > >debugging support is really uNFed up. > > -O works because optimisation removes an unused reference to a nonexistent > variable. The variable once existed and was used. It still exists under > a different name. So I was right (in my way that totally denies any type of actual understanding ;)? You're the one to have delved deep into GCC :) > > Bruce > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: 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 Jul 22 22:17:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 1F638156B2; Thu, 22 Jul 1999 22:17:47 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id PAA07691; Fri, 23 Jul 1999 15:16:02 +1000 Date: Fri, 23 Jul 1999 15:16:02 +1000 From: Bruce Evans Message-Id: <199907230516.PAA07691@godzilla.zeta.org.au> To: bde@zeta.org.au, green@FreeBSD.org Subject: Re: Still kernel compilation failures Cc: freebsd-current@FreeBSD.org, schuerge@wjpserver.CS.Uni-SB.DE Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> It is supported, but someone broke it. > >Since when? Every so often someone comes along (from a pool of maybe 5 >people who _don't_ use -O) and complains about it being broken. If My last fix for a -O related bug was on 1999/05/13 for brooktree.c (memcmp() was used, but memcmp() doesn't exist in the kernel unless the kernel is compiled with -O and without -fno-builtin). I didn't check that -O actually worked :-). >So I was right (in my way that totally denies any type of actual understanding >;)? You're the one to have delved deep into GCC :) I just read the buggy code. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 0:15:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from gidgate.gid.co.uk (gidgate.gid.co.uk [193.123.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 916FC14CB7; Fri, 23 Jul 1999 00:15:45 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.8.8/8.8.7) id IAA09059; Fri, 23 Jul 1999 08:12:18 +0100 (BST) (envelope-from rb) Message-Id: <3.0.6.32.19990723081216.007a75b0@192.168.255.1> X-Sender: rbmail@192.168.255.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 23 Jul 1999 08:12:16 +0100 To: Bruce Evans From: Bob Bishop Subject: Re: Still kernel compilation failures Cc: green@FreeBSD.ORG, schuerge@wjpserver.CS.Uni-SB.DE, freebsd-current@FreeBSD.ORG In-Reply-To: <199907230424.OAA01541@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 14:24 23/07/99 +1000, Bruce Evans wrote: >>> > Put -O back in the COPTFLAGS. >>> >>> It works now. Is there any explaination why -O is required? :) >> >>Noone compiles without -O, so(/and) it's not supported. My take is > >It is supported, but someone broke it. > >>that EGCS says "Hey, I am in optimization level foobar! I can optimize >>for unused code. Hmm... that's unused, so...". Either that or its >>debugging support is really uNFed up. > >-O works because optimisation removes an unused reference to a nonexistent >variable. The variable once existed and was used. It still exists under >a different name. So you're saying that both the compiler and the code are broken? -- Bob Bishop +44 118 977 4017 rb@gid.co.uk fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 5:23:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from viking.sophos.com (viking.sophos.com [193.82.145.128]) by hub.freebsd.org (Postfix) with ESMTP id EAE28156F3 for ; Fri, 23 Jul 1999 05:23:29 -0700 (PDT) (envelope-from gjvc@trafalgar.sophos.com) Received: from trafalgar.sophos.com (trafalgar.sophos.com [193.82.145.143]) by viking.sophos.com (MAILER-DAEMON) with SMTP id 187AD45C14 for ; Fri, 23 Jul 1999 12:23:37 +0000 (GMT) Received: (qmail 19116 invoked by uid 540); 23 Jul 1999 12:24:19 -0000 Date: Fri, 23 Jul 1999 12:24:19 +0000 From: George Cox To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Adding route to aliased IP address Message-ID: <19990723122419.A18945@sophos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i X-Operating-System: FreeBSD/i386 4.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Watcha, When an aliased interface is brought up, no route is added for it. This means that packets from an aliased IP address on one interface do not reach other IP addresses on that interface. Adding a 'route add 127.0.0.1' in the startup scripts would fix it. Is there any place that this route command should go in the current startup scripts which I'm ignorant of? :-) Danke! gjvc -- [gjvc] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 6:31:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id A92E714CC6 for ; Fri, 23 Jul 1999 06:31:07 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id PAA26363 for ; Fri, 23 Jul 1999 15:20:26 +0200 (MET DST) Date: Fri, 23 Jul 1999 15:20:26 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: FreeBSD current mailing list Subject: PR 9334: 2048 Bytes/sector media - ever solved Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I remember seeing some patches going into current or at least floating around on the mailing lists on fixing problems with non-512 bytes sector sizes. What's the status on that? Nick PR 9334: cp fails for 2048 Bytes/sector media When I insert a 640 MB (2048 Bytes/sector) OD into the drive, mount it on /od and try to copy a file from the OD to the harddisk I potentially get: [101] gradalis:~> cp /od/sane-1.00.tar.gz . cp: ./sane-1.00.tar.gz: Bad address [102] gradalis:~> The console then shows: dscheck: b_bcount 25600 is not on a sector boundary (ssize 2048) spec_getpages: I/O read failure: (error code=22) size: 25600, resid: 25600, a_count: 24830, valid: 0x0 nread: 0, reqpage: 0, pindex: 200, pcount: 7 vm_fault: pager read error, pid 9518 (cp) -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 9:53: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 06F0915063; Fri, 23 Jul 1999 09:52:58 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id CAA05031; Sat, 24 Jul 1999 02:52:47 +1000 Date: Sat, 24 Jul 1999 02:52:47 +1000 From: Bruce Evans Message-Id: <199907231652.CAA05031@godzilla.zeta.org.au> To: bde@zeta.org.au, rb@gid.co.uk Subject: Re: Still kernel compilation failures Cc: freebsd-current@FreeBSD.ORG, green@FreeBSD.ORG, schuerge@wjpserver.CS.Uni-SB.DE Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>-O works because optimisation removes an unused reference to a nonexistent >>variable. The variable once existed and was used. It still exists under >>a different name. > >So you're saying that both the compiler and the code are broken? Only the code. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 11:14: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 7785514BF9 for ; Fri, 23 Jul 1999 11:13:59 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id LAA25783 for ; Fri, 23 Jul 1999 11:13:17 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 23 Jul 1999 11:13:17 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: freebsd-current@freebsd.org Subject: PMAP_SHPGPERPROC 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 Using two -current machines, both dated 7/16 I got the following message in my log file, which I think explains the weird spontaneous reboots I've been getting. /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC Having read LINT I see the following: # Set the number of PV entries per process. Increasing this can # stop panics related to heavy use of shared memory. However, that can # (combined with large amounts of physical memory) cause panics at # boot time due the kernel running out of VM space. # # If you're tweaking this, you might also want to increase the sysctls # "vm.v_free_min", "vm.v_free_reserved", and "vm.v_free_target". So I increased from the default 200 to 300, and rebooted without incident. I have 512 megs of ram in both machines, running dual PIII 500's. So far I haven't seen any more of those error messages, although they tend to show up after the machines have been in service for a while. More than anything else I'm looking for some guidance on what I'm dealing with here, and possible causes for it to be getting so far out of whack. To start with, what are pv entries? And how high is "safe" to go with this PMAP_SHPGPERPROC value if I get some more of those error messages? These boxen's sole job at this point is to process scripts for this third party CGI scripting language called miva. I would be very ready to attribute blame for the problem to miva itself, or a rampant user script, but it would be nice to know where to look. Also, in case it matters these boxes are heavy amd/nfs client consumers, mounting all of the remote user directories to get the data from. Finally, I'm also seeing a lot of these periodically: /kernel: in_rtqtimo: adjusted rtq_reallyold to 1600 however I seem to recall from previous experience with the Intel etherexpress cards that some of those are normal. Any help, ideas or suggestions are welcome and appreciated. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 11:35:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 3DE8114F6D for ; Fri, 23 Jul 1999 11:35:28 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id OAA22144 for ; Fri, 23 Jul 1999 14:34:14 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA00753; Fri, 23 Jul 1999 14:33:43 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id OAA52589 for freebsd-current@freebsd.org; Fri, 23 Jul 1999 14:33:43 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199907231833.OAA52589@bb01f39.unx.sas.com> Subject: inetd looping (from cvs-all) To: freebsd-current@freebsd.org Date: Fri, 23 Jul 1999 14:33:43 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL43 (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 Hi, From the discussion on cvs-all about inetd, I'd like to add the following: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 198 root 105 0 908K 584K RUN 141.8H 95.70% 95.70% inetd This is on a system running: 4.0-19990712-SNAP There are NO messages in /var/log/messages. The -l option doesn't seem to work, and the -d option seems to cause inetd to lock up. I'll be updating this machine early next week if we don't have a solution by then, and I'll put the debugger on it. Thanks, John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 12:37:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from solaris.matti.ee (solaris.matti.ee [194.126.98.135]) by hub.freebsd.org (Postfix) with ESMTP id 4EC8A1539D for ; Fri, 23 Jul 1999 12:37:13 -0700 (PDT) (envelope-from vallo@matti.ee) Received: from myhakas.matti.ee (myhakas.matti.ee [194.126.114.87]) by solaris.matti.ee (8.9.3/8.9.3) with ESMTP id WAA19016 for ; Fri, 23 Jul 1999 22:35:14 +0300 (EET DST) Received: by myhakas.matti.ee (Postfix, from userid 1000) id 7368A1F78; Fri, 23 Jul 1999 22:05:08 +0300 (EEST) Date: Fri, 23 Jul 1999 22:05:08 +0300 From: Vallo Kallaste To: freebsd-current@freebsd.org Subject: world builds but doesn't install Message-ID: <19990723220508.A83138@myhakas.matti.ee> Reply-To: vallo@matti.ee Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Organization: =?iso-8859-1?Q?AS_Matti_B=FCrootehnika?= Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello After Greg fixed vinum, I went ahead and tried to build latest current. All is well but the world doesn't install: make -DCLOBBER -DNOGAMES installworld Skipping directory `ufs/ufs' vm/default_pager.h -> vm/default_pager.ph vm/pmap.h -> vm/pmap.ph vm/swap_pager.h -> vm/swap_pager.ph vm/vm.h -> vm/vm.ph vm/vm_extern.h -> vm/vm_extern.ph vm/vm_inherit.h -> vm/vm_inherit.ph vm/vm_kern.h -> vm/vm_kern.ph vm/vm_map.h -> vm/vm_map.ph vm/vm_object.h -> vm/vm_object.ph vm/vm_page.h -> vm/vm_page.ph vm/vm_pageout.h -> vm/vm_pageout.ph vm/vm_pager.h -> vm/vm_pager.ph vm/vm_param.h -> vm/vm_param.ph vm/vm_prot.h -> vm/vm_prot.ph vm/vm_zone.h -> vm/vm_zone.ph vm/vnode_pager.h -> vm/vnode_pager.ph *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Whats more interesting, the July 19 sources which built and installed fine before now doesn't install anymore. Exactly same message. I've downloaded the fresh sources just to be sure I haven't screwed something. No difference. I don't understand for what the .ph suffix stands for and what the install procedure does in this phase, it seems doing some perl stuff. What's happening? -- Vallo Kallaste vallo@matti.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 14:13:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 13ABB14E53 for ; Fri, 23 Jul 1999 14:13:44 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 117mdc-000Cvp-00; Fri, 23 Jul 1999 23:13:52 +0200 From: Sheldon Hearn To: "John W. DeBoskey" Cc: freebsd-current@FreeBSD.ORG Subject: Re: inetd looping (from cvs-all) In-reply-to: Your message of "Fri, 23 Jul 1999 14:33:43 -0400." <199907231833.OAA52589@bb01f39.unx.sas.com> Date: Fri, 23 Jul 1999 23:13:52 +0200 Message-ID: <49712.932764432@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 23 Jul 1999 14:33:43 -0400, "John W. DeBoskey" wrote: > PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > 198 root 105 0 908K 584K RUN 141.8H 95.70% 95.70% inetd [...] > There are NO messages in /var/log/messages. > > The -l option doesn't seem to work, and the -d option seems > to cause inetd to lock up. I can't comment on the -d option locking up, other than that it may have conspired with a bug to produce a far too busy inetd. :-) I introduced a bug in inetd.c rev 1.57, where code intended to serve dgram services was used for servicing stream services as well. I believe that DES fixed this problem a few hours ago. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 14:59:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 00686153B3 for ; Fri, 23 Jul 1999 14:59:21 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id XAA00554 for freebsd-current@FreeBSD.ORG; Fri, 23 Jul 1999 23:58:42 +0200 (CEST) (envelope-from olli) Date: Fri, 23 Jul 1999 23:58:42 +0200 (CEST) From: Oliver Fromme Message-Id: <199907232158.XAA00554@dorifer.heim3.tu-clausthal.de> To: freebsd-current@FreeBSD.ORG Subject: Permissions still broken on current.freebsd.org Organization: Administration Heim 3 Reply-To: freebsd-current@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, The permissions of new -current snapshots on current.freebsd.org are still broken. :-( If everything else fails, I'd suggest to set up a cronjob to fix the permissions, until the cause of the problem is found. Putting up snapshots without letting us download them is no good... Regards Oliver (desperate mirror admin ;-) -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 15:11:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from magnesium.net (toxic.magnesium.net [204.188.6.238]) by hub.freebsd.org (Postfix) with SMTP id BE12315677 for ; Fri, 23 Jul 1999 15:11:17 -0700 (PDT) (envelope-from unfurl@magnesium.net) Received: (qmail 66613 invoked by uid 1001); 23 Jul 1999 22:11:15 -0000 Date: Fri, 23 Jul 1999 15:11:15 -0700 From: Bill Swingle To: freebsd-current@FreeBSD.ORG Subject: Re: Permissions still broken on current.freebsd.org Message-ID: <19990723151115.B66437@dub.net> References: <199907232158.XAA00554@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199907232158.XAA00554@dorifer.heim3.tu-clausthal.de>; from Oliver Fromme on Fri, Jul 23, 1999 at 11:58:42PM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 23, 1999 at 11:58:42PM +0200, Oliver Fromme wrote: > Hi, > > The permissions of new -current snapshots on > current.freebsd.org are still broken. :-( I just talked to Jordan about this. He thought that he had fixed this problem and said he would get to it later this afternoon. Eep! -Bill -- -=| Bill Swingle - unfurl@dub.net - unfurl@freebsd.org - bill@cdrom.com -=| "Computers are useless. They can only give you answers" Pablo Picasso To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 15:17: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 61E08156AD for ; Fri, 23 Jul 1999 15:16:47 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA28318 for ; Fri, 23 Jul 1999 15:15:31 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 23 Jul 1999 15:15:31 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: freebsd-current@freebsd.org Subject: Re: PMAP_SHPGPERPROC: related to pagedaemon? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 23 Jul 1999, Doug wrote: > Using two -current machines, both dated 7/16 I got the following > message in my log file, which I think explains the weird spontaneous > reboots I've been getting. > > /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC In my efforts to track this down today I have been monitoring the logs like a hawk. When this message started appearing again (now with the PMAP_SHPGPERPROC set to 300 in the kernel config file) I took a look at the system and what it was doing. I was very disturbed to find that according to 'ps' pagedaemon was eating up 67% of the cpu. This is a dual-PIII 500 machine, and I'm not sure if 'ps' is reporting 67% of one CPU (my first guess) or 67% of both. I captured the output of 'ps -aulx' to a file, here is the bit about pagedaemon, line wrapped for readability. USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 2 66.7 0.0 0 0 ?? RL 10:12AM 5:15.52 (pagedaemon) UID PPID CPU PRI NI WCHAN 0 0 265 -18 0 - There were no other unusual symptoms, except that the miva (CGI) processes that the box is supposed to be processing were backed way up. Normally they complete very quickly (roughly 3 per second) with little or no backlog. I've increased the PMAP_SHPGPERPROC setting in the kernel config file to 400 and recompiled just in case the system panics again, however with it set to 300 as it is now it recovers ok. Once again, any thoughts or suggestions welcome. Thanks, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 15:28:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 27F2F15677 for ; Fri, 23 Jul 1999 15:28:19 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA28527 for ; Fri, 23 Jul 1999 15:24:24 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 23 Jul 1999 15:24:23 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: freebsd-current@FreeBSD.ORG Subject: Re: Permissions still broken on current.freebsd.org In-Reply-To: <199907232158.XAA00554@dorifer.heim3.tu-clausthal.de> 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 Fri, 23 Jul 1999, Oliver Fromme wrote: > Hi, > > The permissions of new -current snapshots on > current.freebsd.org are still broken. :-( Also, in case anyone cares the INSTALL.TXT file seems to be missing, at least on the snaps from the 8th or so. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 15:28:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from ipt2.iptelecom.net.ua (ipt2.iptelecom.net.ua [212.42.68.2]) by hub.freebsd.org (Postfix) with ESMTP id 23CC115751; Fri, 23 Jul 1999 15:28:31 -0700 (PDT) (envelope-from sobomax@altavista.net) Received: from altavista.net (dialup2-16.iptelecom.net.ua [212.42.68.207]) by ipt2.iptelecom.net.ua (8.9.3/8.9.3) with ESMTP id BAA28325; Sat, 24 Jul 1999 01:32:03 +0300 (EEST) Message-ID: <3798ECB1.2AE159E2@altavista.net> Date: Sat, 24 Jul 1999 01:29:05 +0300 From: Maxim Sobolev X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org, brian@freebsd.org Subject: [Fwd: Tun interface related panic] Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, It seems that in some specific conditions user level ppp (PPP Version 2.22 - $Date: 1999/06/23 16:48:19 $) trying to incorrectly write to the tun device causing a panic if revision prior to 1.61 (current) or 1.51.2.1 (stable) of if_tun.c is used. In this tun revisions some belts against this undesirable behavior has been introduced, but all oldest kernels are potentially affected. In my conditions this was a 100% reproducible crash (now it is less harmful - just a message like "Error: ip_Input: deflink: wrote 0, got Input/output error" in the ppp log) but someone using oldest kernel with this revision of ppp can got his machine crashed. Following our last mailing related to this bug (it was in the -stable list because I discovered this panic on my -stable box). For more info look for the subject in the -stable list or contact me by e-mail. -Maxim Alfred Perlstein wrote: > On Fri, 23 Jul 1999, Maxim Sobolev wrote: > > > Alfred Perlstein wrote: > > > > > [Piece of debug print skipped....] > > > oops, ok, I wasn't clear, I need to know the contents of the structs > > > that those pointers point to, try this: > > > > > > print *uio > > > print *top > > > print **mp > > > > > > in, the meanwhile, try this patch: > > > > > > cvs diff: Diffing . > > > Index: if_tun.c > > > =================================================================== > > > RCS file: /home/ncvs/src/sys/net/if_tun.c,v > > > retrieving revision 1.51 > > > diff -u -r1.51 if_tun.c > > > --- if_tun.c 1999/01/17 20:53:47 1.51 > > > +++ if_tun.c 1999/07/23 20:42:34 > > > @@ -521,7 +521,7 @@ > > > > > > TUNDEBUG("%s%d: tunwrite\n", ifp->if_name, ifp->if_unit); > > > > > > - if (uio->uio_resid < 0 || uio->uio_resid > TUNMRU) { > > > + if (uio->uio_resid <= 0 || uio->uio_resid > TUNMRU) { > > > TUNDEBUG("%s%d: len=%d!\n", ifp->if_name, ifp->if_unit, > > > uio->uio_resid); > > > return EIO; > > > > > > please please tell me if it works for you so I can file a proper PR. > > > > Yeah! It works! It seems that I'm the one who have detected this problem because > > I'm using latest ppp snapshot instead of standard one. I just tested ppp from > > -stable and discovered that it doesn't make this panic (version of libalias doesn't > > matter though). However it would be great if you can commit this patch because new > > version of ppp have some really nice features on which I rely hardly. This also > > rising a question to the Brian Somers or any other who can look and find what is > > wrong with the current ppp (PPP Version 2.22 - $Date: 1999/06/23 16:48:19 $). > > Anyway, to have some belts in the kernel should not make any harm. Following is the > > ppp output which probably before your patch would kill my box (I never seen this > > message before - so to speak..): > > > > TCP/IP: IN UDP: 208.147.89.229:18422 ---> 192.168.1.1:7070 > > Error: ip_Input: deflink: wrote 0, got Input/output error > > I don't work on ppp, you should be sure Brian is notified of this problem. > I appreciate your help in tracking this down, the patch has been put into > -stable and -current for it. > > > > > If you still want to see prints, you can see it at the end of this message. > > (kgdb) up > > #5 0xc01630f9 in tunwrite (dev=13312, uio=0xc2d15f14, flag=1) > > at ../../net/if_tun.c:559 > > 559 top->m_pkthdr.len = tlen; > > (kgdb) print *uio > > $1 = {uio_iov = 0xc2d15f0c, uio_iovcnt = 1, uio_offset = 38962, uio_resid = 0, > > uio_segflg = UIO_USERSPACE, uio_rw = UIO_WRITE, uio_procp = 0xc2cc32e0} > > (kgdb) print *top > > Cannot access memory at address 0x0. > > (kgdb) print **mp > > perfect, they were extremely helpful in tracking down this problem, I > assumed that uio->res_id was zero ( it was the only thing that made sense) > however I just needed to verify. > > > > > In the case if my assistance in debugging ppp will be necessary please let me know. > > Talk to Brian. > > hrm, also can you fix your mailer to wrap at 70 chars? > > -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 15:53:59 1999 Delivered-To: freebsd-current@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 923DD14C2E for ; Fri, 23 Jul 1999 15:53:55 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA25976; Fri, 23 Jul 1999 15:53:06 -0700 (PDT) Message-Id: <199907232253.PAA25976@implode.root.com> To: Doug Cc: freebsd-current@FreeBSD.ORG Subject: Re: PMAP_SHPGPERPROC: related to pagedaemon? In-reply-to: Your message of "Fri, 23 Jul 1999 15:15:31 PDT." From: David Greenman Reply-To: dg@root.com Date: Fri, 23 Jul 1999 15:53:06 -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG PMAP_SHPGPERPROC controls the default number of struct pv_entry that the system allocates kernel virtual memory for. A pv_entry is a data structure that tracks physical to virtual page translations. For example, suppose the system wants to page out a specific page of memory. It needs to know all the processes that have that mapped so that it can efficiently remove it from all of the processes page tables. For pages that are usually not shared between processes (like stack pages, for example), then there is only one pv_entry. For pages that are shared, then there is one pv_entry for each mapping of it, and thus the number of pv_entries can become quite large - perhaps hundreds or thousands of times the total number of pages in the system, depending on how much sharing is going on. Due to various complications in the VM system, the kernel wants the virtual memory for the pv_entry structs preallocated...so setting this too high will waste kernel virtual memory to the point where no more can be allocated (causing the system to crash, usually at bootup time), and too few can lead to running out of them if there is a large amount of page sharing. I don't know what's going on with your system, but it's definately unusual to hit this limit under normal circumstances. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com >On Fri, 23 Jul 1999, Doug wrote: > >> Using two -current machines, both dated 7/16 I got the following >> message in my log file, which I think explains the weird spontaneous >> reboots I've been getting. >> >> /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC > > In my efforts to track this down today I have been monitoring the >logs like a hawk. When this message started appearing again (now with the >PMAP_SHPGPERPROC set to 300 in the kernel config file) I took a look at >the system and what it was doing. I was very disturbed to find that >according to 'ps' pagedaemon was eating up 67% of the cpu. This is a >dual-PIII 500 machine, and I'm not sure if 'ps' is reporting 67% of one >CPU (my first guess) or 67% of both. > > I captured the output of 'ps -aulx' to a file, here is the bit >about pagedaemon, line wrapped for readability. > >USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND >root 2 66.7 0.0 0 0 ?? RL 10:12AM 5:15.52 (pagedaemon) > >UID PPID CPU PRI NI WCHAN >0 0 265 -18 0 - > > There were no other unusual symptoms, except that the miva (CGI) >processes that the box is supposed to be processing were backed way up. >Normally they complete very quickly (roughly 3 per second) with little or >no backlog. > > I've increased the PMAP_SHPGPERPROC setting in the kernel config >file to 400 and recompiled just in case the system panics again, however >with it set to 300 as it is now it recovers ok. Once again, any thoughts >or suggestions welcome. > >Thanks, > >Doug > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 16:28: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 7DBCB14F11 for ; Fri, 23 Jul 1999 16:27:54 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id QAA28962; Fri, 23 Jul 1999 16:24:06 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 23 Jul 1999 16:24:06 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: David Greenman Cc: freebsd-current@FreeBSD.ORG Subject: Re: PMAP_SHPGPERPROC: related to pagedaemon? In-Reply-To: <199907232253.PAA25976@implode.root.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 Fri, 23 Jul 1999, David Greenman wrote: > PMAP_SHPGPERPROC controls the default number of struct pv_entry that the > system allocates kernel virtual memory for. Thank you very much for the explanation, that makes things much more clear. > I don't know what's going on with your system, but it's definately unusual > to hit this limit under normal circumstances. *Nod* well, we do a lot of "unusual" things around here. :) Given your explanation I think that the culprit is probably apache. The virtual host file has approximately 16k hosts. The VSZ on each process is about 51M, and the RSS is around 31M. At any given time there are usually 10-15 running. However the boxes have 512M of physical ram so they don't swap. Apache is forking off several CGI engine processes per second, so that's probably (at least to my limited understanding) where we're hitting this limit. It only seems to be happening with certain customer's scripts, two of them in particular are exiting with either a sig 10 or a sig 6 right around the time I'm seeing these pv entry errors. I'm not sure if it's related or not, I'm still looking into it. Thanks again, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 16:34:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 4D8D614F11 for ; Fri, 23 Jul 1999 16:34:32 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA01256; Fri, 23 Jul 1999 16:27:37 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907232327.QAA01256@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: dg@root.com Cc: Doug , freebsd-current@FreeBSD.ORG Subject: Re: PMAP_SHPGPERPROC: related to pagedaemon? In-reply-to: Your message of "Fri, 23 Jul 1999 15:53:06 PDT." <199907232253.PAA25976@implode.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Jul 1999 16:27:37 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't know what's going on with your system, but it's definately unusual > to hit this limit under normal circumstances. I managed to generate this by configuring Apache to start several hundred servers (maybe many hundred, it was a little while back). Ultimately, the system became unresponsive (interrupts were happening OK but nothing in user space seemed to be running). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 16:35:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5C9FE15799 for ; Fri, 23 Jul 1999 16:35:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA28303; Fri, 23 Jul 1999 16:34:59 -0700 (PDT) (envelope-from dillon) Date: Fri, 23 Jul 1999 16:34:59 -0700 (PDT) From: Matthew Dillon Message-Id: <199907232334.QAA28303@apollo.backplane.com> To: Doug Cc: freebsd-current@FreeBSD.ORG Subject: Re: PMAP_SHPGPERPROC: related to pagedaemon? References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Using two -current machines, both dated 7/16 I got the following :> message in my log file, which I think explains the weird spontaneous :> reboots I've been getting. :> :> /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC : :... : : I've increased the PMAP_SHPGPERPROC setting in the kernel config :file to 400 and recompiled just in case the system panics again, however :with it set to 300 as it is now it recovers ok. Once again, any thoughts :or suggestions welcome. : :Thanks, : :Doug Very weird. The system should definitely not be spontaniously rebooting due to this, at least not without generating a panic message. The pmap_collect message is just a warning. I'm not sure what could be causing the pageout daemon overhead. It sounds like it ought to be the pmap_collect() function (i386/i386/pmap.c) but the only way we could tell for sure would be for you to compile up a profiled kernel which you may not want to do on a production system. The failure case for the pmap stuff occurs when you have a lot of processes sharing a lot of data, usually via mmap, where the dataset fits in memory. Thus the system would run out of pv entries before running out of physical memory. In regards to your CGI execution: One thing to look out for is what is called a cascade failure. This can be a problem on web servers running CGI's. The problem occurs when a large number of CGI's are run simultaniously and slow the system down enough that new CGI's are being forked faster then existing CGI's can complete. The solution to this sort of problem is to limit the number of simultanious executions of a particular CGI by using, for example, SysV semaphores within the CGI or implementing the limit within the web server. Note that you do not want to cause one type of CGI to be blocked because too many of another type is running. This sort of limit is best implemented on a per-CGI-binary basis. Whatever you do, make sure the web server limits the maximum number of CGI's that can be running simultaniously to some number that you know the machine can handle to prevent the machine from crashing due to this sort of cascade failure. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 17:38:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 0F30314F01 for ; Fri, 23 Jul 1999 17:38:27 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id RAA29635; Fri, 23 Jul 1999 17:37:05 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Fri, 23 Jul 1999 17:37:05 -0700 (PDT) From: Doug X-Sender: doug@dt011n65.san.rr.com To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG Subject: Re: PMAP_SHPGPERPROC: related to pagedaemon? In-Reply-To: <199907232334.QAA28303@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 23 Jul 1999, Matthew Dillon wrote: > :> Using two -current machines, both dated 7/16 I got the following > :> message in my log file, which I think explains the weird spontaneous > :> reboots I've been getting. > :> > :> /kernel: pmap_collect: collecting pv entries -- suggest increasing PMAP_SHPGPERPROC > : > :... > : > : I've increased the PMAP_SHPGPERPROC setting in the kernel config > :file to 400 and recompiled just in case the system panics again, however > :with it set to 300 as it is now it recovers ok. Once again, any thoughts > :or suggestions welcome. > : > :Thanks, > : > :Doug > > Very weird. The system should definitely not be spontaniously rebooting > due to this, at least not without generating a panic message. The > pmap_collect message is just a warning. *Nod* I am not 100% _sure_ that this is the reason for the panic, however in more than one case this was the last message in the log, followed very closely (never more than a minute or two) by the first message of the boot. Given that it takes so long for our machines to do the memory POST test, there is at least a correlative relationship. Also, prior to increasing the limit to 300 today one of the machines that I was testing on entered this state that I now know to be massive pagerdaemon chugging, and then locked up and eventually panic'ed while I was working on it. > I'm not sure what could be causing the pageout daemon overhead. I sent a followup to DG's post re our apache configuration, which is my mostly likely candidate. > It > sounds like it ought to be the pmap_collect() function (i386/i386/pmap.c) > but the only way we could tell for sure would be for you to compile up > a profiled kernel which you may not want to do on a production system. Well, the way we have the network set up if one box blows up there are 2-3 others there to take the load, so if you think that it will really be beneficial I can probably swing permission to do this. Give me precise steps to follow re how to set it up and how to test it and I'll do what I can on Monday. I'm familiar with stuff like gdb, DDB, etc. but never done any profiling. > The failure case for the pmap stuff occurs when you have a lot of > processes sharing a lot of data, usually via mmap, where the dataset > fits in memory. Thus the system would run out of pv entries before > running out of physical memory. Yeah, the boxes aren't even close to swap'ing, with c. 200M of physical ram free. > In regards to your CGI execution: One thing to look out for is what is > called a cascade failure. *Nod* I appreciate the warning. It's to solve this exact problem that we're setting up this new network of boxes to do nothing other than processing miva CGI. Unfortunately we don't have that kind of fine grained control over the scripts themselves since the idea here is to allow the customers to throw up whatever they want without interaction from us. However I have a feeling that the actual panic is caused by this kind of cascade failure, or symptoms that arise out of it. Now that I finally have a complete 'ps' output while it's locked up I will have a better idea what limits to set if increasing the number of PMAP_SHPGPERPROC's doesn't do the trick. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 18:43: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id CB86F15708 for ; Fri, 23 Jul 1999 18:42:55 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA06891; Sat, 24 Jul 1999 11:11:53 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA42560; Sat, 24 Jul 1999 11:11:51 +0930 (CST) Date: Sat, 24 Jul 1999 11:11:51 +0930 From: Greg Lehey To: Vallo Kallaste Cc: freebsd-current@FreeBSD.ORG Subject: Re: world builds but doesn't install Message-ID: <19990724111151.L84734@freebie.lemis.com> References: <19990723220508.A83138@myhakas.matti.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990723220508.A83138@myhakas.matti.ee>; from Vallo Kallaste on Fri, Jul 23, 1999 at 10:05:08PM +0300 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Friday, 23 July 1999 at 22:05:08 +0300, Vallo Kallaste wrote: > > Hello > > After Greg fixed vinum, I went ahead and tried to build latest > current. All is well but the world doesn't install: > > make -DCLOBBER -DNOGAMES installworld > > vm/vm_zone.h -> vm/vm_zone.ph > vm/vnode_pager.h -> vm/vnode_pager.ph > *** Error code 1 > Stop. > > Whats more interesting, the July 19 sources which built and > installed fine before now doesn't install anymore. Exactly same > message. I've downloaded the fresh sources just to be sure I > haven't screwed something. No difference. I don't understand > for what the .ph suffix stands for and what the install > procedure does in this phase, it seems doing some perl stuff. > What's happening? Good question. I just did a make world, and it went fine. And the UDMA brokenness is gone again. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 23 19:53:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from awfulhak.org (dynamic-29.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.29]) by hub.freebsd.org (Postfix) with ESMTP id C725015731; Fri, 23 Jul 1999 19:53:09 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (root@keep.lan.Awfulhak.org [172.16.0.8]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id DAA08140; Sat, 24 Jul 1999 03:52:41 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from keep.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id DAA03879; Sat, 24 Jul 1999 03:52:57 +0100 (BST) (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199907240252.DAA03879@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Maxim Sobolev Cc: current@freebsd.org, brian@freebsd.org, jmg@freebsd.org Subject: Re: [Fwd: Tun interface related panic] In-reply-to: Your message of "Sat, 24 Jul 1999 01:29:05 +0300." <3798ECB1.2AE159E2@altavista.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 24 Jul 1999 03:52:56 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, I found the culprit in ppp. I'm committing a change now. Thanks for the report ! > Hi folks, > > It seems that in some specific conditions user level ppp (PPP Version > 2.22 - $Date: 1999/06/23 16:48:19 $) trying to incorrectly write to the > tun device causing a panic if revision prior to 1.61 (current) or > 1.51.2.1 (stable) of if_tun.c is used. In this tun revisions some belts > against this undesirable behavior has been introduced, but all oldest > kernels are potentially affected. In my conditions this was a 100% > reproducible crash (now it is less harmful - just a message like "Error: > ip_Input: deflink: wrote 0, got Input/output error" in the ppp log) but > someone using oldest kernel with this revision of ppp can got his > machine crashed. Following our last mailing related to this bug (it was > in the -stable list because I discovered this panic on my -stable box). > For more info look for the subject in the -stable list or contact me by > e-mail. > > -Maxim > > Alfred Perlstein wrote: > > > On Fri, 23 Jul 1999, Maxim Sobolev wrote: > > > > > Alfred Perlstein wrote: > > > > > > > [Piece of debug print skipped....] > > > > oops, ok, I wasn't clear, I need to know the contents of the structs > > > > that those pointers point to, try this: > > > > > > > > print *uio > > > > print *top > > > > print **mp > > > > > > > > in, the meanwhile, try this patch: > > > > > > > > cvs diff: Diffing . > > > > Index: if_tun.c > > > > =================================================================== > > > > RCS file: /home/ncvs/src/sys/net/if_tun.c,v > > > > retrieving revision 1.51 > > > > diff -u -r1.51 if_tun.c > > > > --- if_tun.c 1999/01/17 20:53:47 1.51 > > > > +++ if_tun.c 1999/07/23 20:42:34 > > > > @@ -521,7 +521,7 @@ > > > > > > > > TUNDEBUG("%s%d: tunwrite\n", ifp->if_name, ifp->if_unit); > > > > > > > > - if (uio->uio_resid < 0 || uio->uio_resid > TUNMRU) { > > > > + if (uio->uio_resid <= 0 || uio->uio_resid > TUNMRU) { > > > > TUNDEBUG("%s%d: len=%d!\n", ifp->if_name, ifp->if_unit, > > > > uio->uio_resid); > > > > return EIO; > > > > > > > > please please tell me if it works for you so I can file a proper PR. > > > > > > Yeah! It works! It seems that I'm the one who have detected this problem because > > > I'm using latest ppp snapshot instead of standard one. I just tested ppp from > > > -stable and discovered that it doesn't make this panic (version of libalias doesn't > > > matter though). However it would be great if you can commit this patch because new > > > version of ppp have some really nice features on which I rely hardly. This also > > > rising a question to the Brian Somers or any other who can look and find what is > > > wrong with the current ppp (PPP Version 2.22 - $Date: 1999/06/23 16:48:19 $). > > > Anyway, to have some belts in the kernel should not make any harm. Following is the > > > ppp output which probably before your patch would kill my box (I never seen this > > > message before - so to speak..): > > > > > > TCP/IP: IN UDP: 208.147.89.229:18422 ---> 192.168.1.1:7070 > > > Error: ip_Input: deflink: wrote 0, got Input/output error > > > > I don't work on ppp, you should be sure Brian is notified of this problem. > > I appreciate your help in tracking this down, the patch has been put into > > -stable and -current for it. > > > > > > > > If you still want to see prints, you can see it at the end of this message. > > > (kgdb) up > > > #5 0xc01630f9 in tunwrite (dev=13312, uio=0xc2d15f14, flag=1) > > > at ../../net/if_tun.c:559 > > > 559 top->m_pkthdr.len = tlen; > > > (kgdb) print *uio > > > $1 = {uio_iov = 0xc2d15f0c, uio_iovcnt = 1, uio_offset = 38962, uio_resid = 0, > > > uio_segflg = UIO_USERSPACE, uio_rw = UIO_WRITE, uio_procp = 0xc2cc32e0} > > > (kgdb) print *top > > > Cannot access memory at address 0x0. > > > (kgdb) print **mp > > > > perfect, they were extremely helpful in tracking down this problem, I > > assumed that uio->res_id was zero ( it was the only thing that made sense) > > however I just needed to verify. > > > > > > > > In the case if my assistance in debugging ppp will be necessary please let me know. > > > > Talk to Brian. > > > > hrm, also can you fix your mailer to wrap at 70 chars? > > > > -Alfred -- 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 Jul 23 20:28:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 7CAA414E30 for ; Fri, 23 Jul 1999 20:28:48 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA07154 for ; Sat, 24 Jul 1999 12:56:00 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA42818 for FreeBSD-current@FreeBSD.ORG; Sat, 24 Jul 1999 12:55:59 +0930 (CST) Date: Sat, 24 Jul 1999 12:55:59 +0930 From: Greg Lehey To: FreeBSD current users Subject: top/ps breakage in today's -CURRENT? Message-ID: <19990724125558.N84734@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I cvsupped at 20:30 UTC yesterday (23 July) and built a world and a kernel from the sources. I get the following from top: last pid: 476; load averages: 1.44, 1.44, 1.22 30 processes: 2 running, 28 sleeping CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 15M Active, 51M Inact, 20M Wired, 5756K Cache, 3171K Buf, 576K Free Swap: 256M Total, 256M Free ps and vmstat also don't report any CPU times. I've checked libkvm, and yes, it got installed as well. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 0:20:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by hub.freebsd.org (Postfix) with ESMTP id 5676114F4A for ; Sat, 24 Jul 1999 00:20:39 -0700 (PDT) (envelope-from gjp@noop.colo.erols.net) Received: from localhost ([127.0.0.1] helo=noop.colo.erols.net) by noop.colo.erols.net with esmtp (Exim 2.12 #1) id 117w6t-000Loy-00 for freebsd-current@freebsd.org; Sat, 24 Jul 1999 03:20:43 -0400 To: freebsd-current@freebsd.org From: "Gary Palmer" Subject: Patch for Alpha/AXP Date: Sat, 24 Jul 1999 03:20:43 -0400 Message-ID: <83883.932800843@noop.colo.erols.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does this look right? Without this patch, my AXP was memory faulting every time it booted, in the dev2udev routine. Thanks Index: alpha/alpha/cons.c =================================================================== RCS file: /home/ncvs/src/sys/alpha/alpha/cons.c,v retrieving revision 1.11 diff -u -r1.11 cons.c --- cons.c 1999/06/22 14:13:16 1.11 +++ cons.c 1999/07/24 07:18:25 @@ -88,9 +88,8 @@ }; static dev_t cn_dev_t; /* seems to be never really used */ -static udev_t cn_udev_t; SYSCTL_OPAQUE(_machdep, CPU_CONSDEV, consdev, CTLFLAG_RD, - &cn_udev_t, sizeof cn_udev_t, "T,dev_t", ""); + &cn_dev_t, sizeof cn_dev_t, "T,dev_t", ""); static int cn_mute; @@ -185,7 +184,6 @@ cdp->d_open = cnopen; cn_tp = (*cdp->d_devtotty)(cn_tab->cn_dev); cn_dev_t = cn_tp->t_dev; - cn_udev_t = dev2udev(cn_dev_t); } static void @@ -206,7 +204,6 @@ cn_phys_open = NULL; cn_tp = NULL; cn_dev_t = 0; - cn_udev_t = dev2udev(cn_dev_t); } /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 0:25:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id EA17114F6C; Sat, 24 Jul 1999 00:25:43 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:HNLmcRjb4qdA/kiKKujfXfDJncO/JVAX@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id QAA18350; Sat, 24 Jul 1999 16:25:06 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id QAA18269; Sat, 24 Jul 1999 16:29:24 +0900 (JST) Message-Id: <199907240729.QAA18269@zodiac.mech.utsunomiya-u.ac.jp> To: "Gary Palmer" Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Patch for Alpha/AXP In-reply-to: Your message of "Sat, 24 Jul 1999 03:20:43 -0400." <83883.932800843@noop.colo.erols.net> References: <83883.932800843@noop.colo.erols.net> Date: Sat, 24 Jul 1999 16:29:23 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Does this look right? Without this patch, my AXP was memory faulting >every time it booted, in the dev2udev routine. I am afraid this is not quite right. Bruce, Doug and I are currently in discussion to fix this. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 1:23:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 6E59014BFF; Sat, 24 Jul 1999 01:23:41 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id KAA44342; Sat, 24 Jul 1999 10:20:39 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Gary Palmer" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Patch for Alpha/AXP In-reply-to: Your message of "Sat, 24 Jul 1999 03:20:43 EDT." <83883.932800843@noop.colo.erols.net> Date: Sat, 24 Jul 1999 10:20:39 +0200 Message-ID: <44340.932804439@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, looks right. In message <83883.932800843@noop.colo.erols.net>, "Gary Palmer" writes: > >Does this look right? Without this patch, my AXP was memory faulting >every time it booted, in the dev2udev routine. > >Thanks > > >Index: alpha/alpha/cons.c >=================================================================== >RCS file: /home/ncvs/src/sys/alpha/alpha/cons.c,v >retrieving revision 1.11 >diff -u -r1.11 cons.c >--- cons.c 1999/06/22 14:13:16 1.11 >+++ cons.c 1999/07/24 07:18:25 >@@ -88,9 +88,8 @@ > }; > > static dev_t cn_dev_t; /* seems to be never really used */ >-static udev_t cn_udev_t; > SYSCTL_OPAQUE(_machdep, CPU_CONSDEV, consdev, CTLFLAG_RD, >- &cn_udev_t, sizeof cn_udev_t, "T,dev_t", ""); >+ &cn_dev_t, sizeof cn_dev_t, "T,dev_t", ""); > > static int cn_mute; > >@@ -185,7 +184,6 @@ > cdp->d_open = cnopen; > cn_tp = (*cdp->d_devtotty)(cn_tab->cn_dev); > cn_dev_t = cn_tp->t_dev; >- cn_udev_t = dev2udev(cn_dev_t); > } > > static void >@@ -206,7 +204,6 @@ > cn_phys_open = NULL; > cn_tp = NULL; > cn_dev_t = 0; >- cn_udev_t = dev2udev(cn_dev_t); > } > > /* > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 1:41:16 1999 Delivered-To: freebsd-current@freebsd.org Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by hub.freebsd.org (Postfix) with ESMTP id 60D3C14DF9 for ; Sat, 24 Jul 1999 01:41:15 -0700 (PDT) (envelope-from gjp@noop.colo.erols.net) Received: from localhost ([127.0.0.1] helo=noop.colo.erols.net) by noop.colo.erols.net with esmtp (Exim 2.12 #1) id 117xJ7-000MQT-00; Sat, 24 Jul 1999 04:37:25 -0400 To: Kazutaka YOKOTA Cc: freebsd-current@freebsd.org From: "Gary Palmer" Subject: Re: Patch for Alpha/AXP In-reply-to: Your message of "Sat, 24 Jul 1999 16:29:23 +0900." <199907240729.QAA18269@zodiac.mech.utsunomiya-u.ac.jp> Date: Sat, 24 Jul 1999 04:37:24 -0400 Message-ID: <86208.932805444@noop.colo.erols.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kazutaka YOKOTA wrote in message ID <199907240729.QAA18269@zodiac.mech.utsunomiya-u.ac.jp>: > > >Does this look right? Without this patch, my AXP was memory faulting > >every time it booted, in the dev2udev routine. > > I am afraid this is not quite right. > > Bruce, Doug and I are currently in discussion to fix this. Hrm. Why does the AXP cons.c track udev_t while the x86 verson doesn't? As best as I can tell, the AXP doesn't seem to need it any more than the x86 does, unless I've missed something. Thanks, Gary To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 1:51:28 1999 Delivered-To: freebsd-current@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id 5DADB14F4A; Sat, 24 Jul 1999 01:51:25 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:NtBWbCkOTDx1lPdwF0nXoZh4zhyhsGtr@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id RAA18489; Sat, 24 Jul 1999 17:50:12 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id RAA19619; Sat, 24 Jul 1999 17:54:30 +0900 (JST) Message-Id: <199907240854.RAA19619@zodiac.mech.utsunomiya-u.ac.jp> To: "Gary Palmer" Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Patch for Alpha/AXP In-reply-to: Your message of "Sat, 24 Jul 1999 04:37:24 -0400." <86208.932805444@noop.colo.erols.net> References: <86208.932805444@noop.colo.erols.net> Date: Sat, 24 Jul 1999 17:54:29 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> I am afraid this is not quite right. >> >> Bruce, Doug and I are currently in discussion to fix this. > >Hrm. Why does the AXP cons.c track udev_t while the x86 verson >doesn't? As best as I can tell, the AXP doesn't seem to need it any >more than the x86 does, unless I've missed something. As dev_t is now a struct, we cannot track dev_t for SYSCTL. It has to be udev_t. sys/i386/i386/cons.c should be doing the same as the alpha version, rather than vice versa. To quote Bruce: "alpha/alpha/cons.c should be identical with i386/i386/cons.c and not in a machine-dependent place. All current differences are bugs" :-) Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 4:13:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from esmeralda.xaa.iae.nl (esmeralda.xaa.iae.nl [194.151.75.9]) by hub.freebsd.org (Postfix) with ESMTP id 74A271578D for ; Sat, 24 Jul 1999 04:13:12 -0700 (PDT) (envelope-from freebsd@xaa.iae.nl) Received: from ariel.xaa.iae.nl (ariel.xaa.iae.nl [194.151.75.10]) by esmeralda.xaa.iae.nl (Postfix) with ESMTP id 6FB611B6 for ; Sat, 24 Jul 1999 13:11:04 +0200 (MET DST) Received: by ariel.xaa.iae.nl (Postfix, from userid 1008) id DAFDA1968; Sat, 24 Jul 1999 13:10:59 +0200 (CEST) Date: Sat, 24 Jul 1999 13:10:59 +0200 From: Mark Huizer To: freebsd-current@freebsd.org Subject: Re: Arg! MFS broken Message-ID: <19990724131059.A375@ariel.xaa.iae.nl> References: <199907210544.WAA18779@apollo.backplane.com> <24175.932545079@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <24175.932545079@critter.freebsd.dk>; from Poul-Henning Kamp on Wed, Jul 21, 1999 at 10:17:59AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > MFS is badly broken when used in a diskless configuration. I am trying > > to track it all down but it is very, very frustrating. > > > > Also BOOTP seems to be broken -- rootdev is not being setup any more > > and I can't figure out which commit broke it. > > I'm sorry, I don't have either in my arsenal currently. I found that trying to build a PicoBSD floppy was a sure way of crashing my current box :-( Perhaps that is a nice testing environment? Mark -- Nice testing in little China... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 9:28:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 50D3C14C93 for ; Sat, 24 Jul 1999 09:28:40 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id JAA05159 for ; Sat, 24 Jul 1999 09:27:38 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <3799E979.CC187EDF@gorean.org> Date: Sat, 24 Jul 1999 09:27:37 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: wd0 DMA errors Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My boxes at work are -current from 7/16. They both use IDE disks since other than system stuff the disk I/O for the real work is all NFS. In the daily logs this morning I see this: > wd0: interrupt timeout (status 58 error 0) > wd0: wdtimeout() DMA status 4 Can anyone shed some light on what that is, and how bad it is? I won't have access to the box itself till monday, but it would be nice to have some answers ready when I go in. Thanks, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 10: 1:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id CFB9615116 for ; Sat, 24 Jul 1999 10:01:29 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id SAA10052 for ; Sat, 24 Jul 1999 18:47:40 +0200 (MET DST) Date: Sat, 24 Jul 1999 18:47:37 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: FreeBSD current mailing list Subject: PR 12634 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 PR 12634 mentions the increase of MAXSYMLINKS (src/sys/sys/param.h) to 64. Any opinions? Nick http://www.freebsd.org/cgi/query-pr.cgi?pr=12634 -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 10:15:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B93451513D for ; Sat, 24 Jul 1999 10:15:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA35602; Sat, 24 Jul 1999 10:14:27 -0700 (PDT) (envelope-from dillon) Date: Sat, 24 Jul 1999 10:14:27 -0700 (PDT) From: Matthew Dillon Message-Id: <199907241714.KAA35602@apollo.backplane.com> To: Nick Hibma Cc: FreeBSD current mailing list Subject: Re: PR 12634 References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :PR 12634 mentions the increase of MAXSYMLINKS (src/sys/sys/param.h) to :64. : :Any opinions? : :Nick :http://www.freebsd.org/cgi/query-pr.cgi?pr=12634 Wellll.... 32 really ought to be enough. Looking at your PR I think you are decoupling your directories a little too much and should perhaps reduce the number of symlinks you use. For example, instead of having /public -> site/public -> domain/public -> this/public -> jhs.no_domain why not simply have /public be a symlink to /site/domain/this/public ? While increasing the number would not hurt except, as you say, when dealing with loops, I would hate to change it based on this particular setup because I think this setup could be optimized considerably to get well under the current limit of 32. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 10:19:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 4A0AB1513D for ; Sat, 24 Jul 1999 10:19:19 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id TAA10196; Sat, 24 Jul 1999 19:19:13 +0200 (MET DST) Date: Sat, 24 Jul 1999 19:19:10 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Matthew Dillon Cc: FreeBSD current mailing list Subject: Re: PR 12634 In-Reply-To: <199907241714.KAA35602@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :PR 12634 mentions the increase of MAXSYMLINKS (src/sys/sys/param.h) to > :64. > : > :Any opinions? > : > :Nick > :http://www.freebsd.org/cgi/query-pr.cgi?pr=12634 > > Wellll.... 32 really ought to be enough. Looking at your PR I think It's not my PR. I am just asking for opinions on his proposal. > you are decoupling your directories a little too much and should > perhaps reduce the number of symlinks you use. For example, > instead of having /public -> site/public -> domain/public -> this/public > -> jhs.no_domain why not simply have /public be a symlink to > /site/domain/this/public ? > > While increasing the number would not hurt except, as you say, when > dealing with loops, I would hate to change it based on this particular > setup because I think this setup could be optimized considerably to > get well under the current limit of 32. That was what I thought as well. You probably end up drowning the NFS server in stat()-s I guess. Other envvironments, single machine environments, it's bad design. Cheers, Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 10:35:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 9ECFB15157 for ; Sat, 24 Jul 1999 10:35:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA35707; Sat, 24 Jul 1999 10:32:31 -0700 (PDT) (envelope-from dillon) Date: Sat, 24 Jul 1999 10:32:31 -0700 (PDT) From: Matthew Dillon Message-Id: <199907241732.KAA35707@apollo.backplane.com> To: Nick Hibma Cc: FreeBSD current mailing list Subject: Re: PR 12634 References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : > : > Wellll.... 32 really ought to be enough. Looking at your PR I think : :It's not my PR. I am just asking for opinions on his proposal. Oops, sorry! s/you/him/g : > dealing with loops, I would hate to change it based on this particular : > setup because I think this setup could be optimized considerably to : > get well under the current limit of 32. : :That was what I thought as well. You probably end up drowning the NFS :server in stat()-s I guess. Other envvironments, single machine :environments, it's bad design. : :Cheers, : :Nick Yah. It's one of those things where sometimes the proper answer is to enforce more discipline. I remember hitting the softlinks=20 limit on a NeXT machine years ago. A simple, minor reorganization solved the problem in about 60 seconds. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 11:27:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (Postfix) with ESMTP id E7ACA15132 for ; Sat, 24 Jul 1999 11:27:09 -0700 (PDT) (envelope-from schuerge@wjpserver.CS.Uni-SB.DE) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999070600) with ESMTP id UAA11134 for ; Sat, 24 Jul 1999 20:26:57 +0200 (CEST) Received: from wjpserver.cs.uni-sb.de (wjpserver.cs.uni-sb.de [134.96.247.42]) by cs.uni-sb.de (8.9.3/1999031900) with ESMTP id UAA07412 for ; Sat, 24 Jul 1999 20:26:57 +0200 (CEST) Received: (from schuerge@localhost) by wjpserver.cs.uni-sb.de (8.9.3/8.9.3/wjp-SVR4/1999052600) id UAA15612 for freebsd-current@freebsd.org; Sat, 24 Jul 1999 20:26:56 +0200 (MET DST) From: Thomas Schuerger Message-Id: <199907241826.UAA15612@wjpserver.cs.uni-sb.de> Subject: IDE_DELAY To: freebsd-current@freebsd.org Date: Sat, 24 Jul 1999 20:26:56 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL57 (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 Hi! I've set the option IDE_DELAY=1500 and compiled and installed my kernel (I even did config -r before that), but when booting, the IDE driver still waits for about half a minute before continuing, instead for about 1.5 seconds. Has anyone succeeded in setting the IDE delay? SCSI_DELAY works just fine... Ciao, Thomas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 11:37:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from arrakis.pcarts.tarnow.pl (boruta.pcarts.tarnow.pl [195.205.11.2]) by hub.freebsd.org (Postfix) with ESMTP id 16DBB15132 for ; Sat, 24 Jul 1999 11:37:16 -0700 (PDT) (envelope-from adam@pcarts.tarnow.pl) Received: from Detal2 ([195.205.11.41]) by arrakis.pcarts.tarnow.pl (8.8.7/8.8.7) with SMTP id UAA09310 for ; Fri, 23 Jul 1999 20:39:23 +0200 (CEST) Received: by localhost with Microsoft MAPI; Sat, 24 Jul 1999 20:36:42 +0200 Message-ID: <01BED614.3CC6BCE0.adam@pcarts.tarnow.pl> From: Adam Smaza To: "'freebsd-current@FreeBSD.ORG'" Subject: ODP: IDE_DELAY Date: Sat, 24 Jul 1999 20:36:39 +0200 X-Mailer: Microsoft Internet e-mail/MAPI - 8.0.0.4211 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 Try more then 2000, in my computer IDE_DELEY work fine Hi! I've set the option IDE_DELAY=1500 and compiled and installed my kernel (I even did config -r before that), but when booting, the IDE driver still waits for about half a minute before continuing, instead for about 1.5 seconds. Has anyone succeeded in setting the IDE delay? SCSI_DELAY works just fine... Ciao, Thomas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 11:38:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 77EB7151A8 for ; Sat, 24 Jul 1999 11:38:50 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id UAA28051; Sat, 24 Jul 1999 20:38:35 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199907241838.UAA28051@freebsd.dk> Subject: Re: IDE_DELAY In-Reply-To: <199907241826.UAA15612@wjpserver.cs.uni-sb.de> from Thomas Schuerger at "Jul 24, 1999 8:26:56 pm" To: schuerge@wjpserver.CS.Uni-SB.DE (Thomas Schuerger) Date: Sat, 24 Jul 1999 20:38:35 +0200 (CEST) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Thomas Schuerger wrote: > Hi! > > I've set the option > > IDE_DELAY=1500 > > and compiled and installed my kernel (I even did config -r > before that), but when booting, the IDE driver still waits > for about half a minute before continuing, instead for > about 1.5 seconds. Has anyone succeeded in setting the > IDE delay? SCSI_DELAY works just fine... What driver are you using (ata/wd) ?? This option is only valid for the wd driver, there should be no delays with the ata driver, except if bad behaving HW is present... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 12: 9:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from fanf.noc.demon.net (fanf.noc.demon.net [195.11.55.83]) by hub.freebsd.org (Postfix) with ESMTP id 7026614F1F for ; Sat, 24 Jul 1999 12:09:52 -0700 (PDT) (envelope-from fanf@demon.net) Received: from fanf by fanf.noc.demon.net with local (Exim 3.02 #13) id 11879x-0005gA-00; Sat, 24 Jul 1999 20:08:37 +0100 To: Doug@gorean.org From: Tony Finch Cc: current@freebsd.org Subject: Re: PMAP_SHPGPERPROC: related to pagedaemon? In-Reply-To: References: <199907232253.PAA25976@implode.root.com> Message-Id: Date: Sat, 24 Jul 1999 20:08:37 +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug wrote: > > *Nod* well, we do a lot of "unusual" things around here. :) Given >your explanation I think that the culprit is probably apache. The virtual >host file has approximately 16k hosts. *ouch* You should take a gander at http://www.apache.org/docs/vhosts/mass.html Tony. -- f.a.n.finch dot@dotat.at fanf@demon.net Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 13:28:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id 3B02A151E3 for ; Sat, 24 Jul 1999 13:28:20 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id B508A1913; Sat, 24 Jul 1999 22:28:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id B214949DF; Sat, 24 Jul 1999 22:28:09 +0200 (CEST) Date: Sat, 24 Jul 1999 22:28:09 +0200 (CEST) From: Andrzej Bialecki To: Mark Huizer Cc: freebsd-current@freebsd.org Subject: Re: Arg! MFS broken In-Reply-To: <19990724131059.A375@ariel.xaa.iae.nl> 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 Sat, 24 Jul 1999, Mark Huizer wrote: > > > > > MFS is badly broken when used in a diskless configuration. I am trying > > > to track it all down but it is very, very frustrating. > > > > > > Also BOOTP seems to be broken -- rootdev is not being setup any more > > > and I can't figure out which commit broke it. > > > > I'm sorry, I don't have either in my arsenal currently. > I found that trying to build a PicoBSD floppy was a sure way of crashing > my current box :-( Perhaps that is a nice testing environment? Then you should investigate this further, because it looks like some bug in vn(4) code - picobsd build doesn't do anything unusual except that... Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 13:39: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id A589114CE2 for ; Sat, 24 Jul 1999 13:38:56 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id WAA47366; Sat, 24 Jul 1999 22:36:31 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Andrzej Bialecki Cc: Mark Huizer , freebsd-current@FreeBSD.ORG Subject: Re: Arg! MFS broken In-reply-to: Your message of "Sat, 24 Jul 1999 22:28:09 +0200." Date: Sat, 24 Jul 1999 22:36:30 +0200 Message-ID: <47364.932848590@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Andrze j Bialecki writes: >On Sat, 24 Jul 1999, Mark Huizer wrote: > >> > >> > > MFS is badly broken when used in a diskless configuration. I am trying >> > > to track it all down but it is very, very frustrating. >> > > >> > > Also BOOTP seems to be broken -- rootdev is not being setup any more >> > > and I can't figure out which commit broke it. >> > >> > I'm sorry, I don't have either in my arsenal currently. >> I found that trying to build a PicoBSD floppy was a sure way of crashing >> my current box :-( Perhaps that is a nice testing environment? > >Then you should investigate this further, because it looks like some bug >in vn(4) code - picobsd build doesn't do anything unusual except that... I built a release (which also uses vn(4)) yesterday, so to some extent of the concept vn(4) works. I'm very interested in a traceback of this panic... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 13:46:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id C960714DB2 for ; Sat, 24 Jul 1999 13:46:11 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id 11C951913; Sat, 24 Jul 1999 22:45:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id 0EA2D49DF; Sat, 24 Jul 1999 22:45:04 +0200 (CEST) Date: Sat, 24 Jul 1999 22:45:04 +0200 (CEST) From: Andrzej Bialecki To: Poul-Henning Kamp Cc: Mark Huizer , freebsd-current@FreeBSD.ORG Subject: Re: Arg! MFS broken In-Reply-To: <47364.932848590@critter.freebsd.dk> 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 Sat, 24 Jul 1999, Poul-Henning Kamp wrote: > In message , Andrze > j Bialecki writes: > >On Sat, 24 Jul 1999, Mark Huizer wrote: > > > >> > > >> > > MFS is badly broken when used in a diskless configuration. I am trying > >> > > to track it all down but it is very, very frustrating. > >> > > > >> > > Also BOOTP seems to be broken -- rootdev is not being setup any more > >> > > and I can't figure out which commit broke it. > >> > > >> > I'm sorry, I don't have either in my arsenal currently. > >> I found that trying to build a PicoBSD floppy was a sure way of crashing > >> my current box :-( Perhaps that is a nice testing environment? > > > >Then you should investigate this further, because it looks like some bug > >in vn(4) code - picobsd build doesn't do anything unusual except that... > > I built a release (which also uses vn(4)) yesterday, so to some extent > of the concept vn(4) works. I'm very interested in a traceback of > this panic... If interrupted at (in)appropriate place, picobsd build process can leave vn(4) configured but left without underlying file. I shoudl probably test various scenarios here, like: * vn configured, remove file, unconfig vn * vn configured, mounted, unconfigure vn etc, etc.. vn(4) should be foolproof , at least it shouldn't panic the system. But you're right, we need a trace first... Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 16: 7:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from reliam.teaser.fr (reliam.teaser.fr [194.51.80.12]) by hub.freebsd.org (Postfix) with ESMTP id D54D415043 for ; Sat, 24 Jul 1999 16:07:09 -0700 (PDT) (envelope-from nsouch@teaser.fr) Received: from teaser.fr (ppp1087-ft.teaser.fr [194.206.156.40]) by reliam.teaser.fr (8.9.3/8.9.3) with ESMTP id BAA25275; Sun, 25 Jul 1999 01:06:18 +0200 (MET DST) Received: (from nsouch@localhost) by teaser.fr (8.9.3/8.9.1) id AAA06506; Sun, 25 Jul 1999 00:56:36 +0200 (CEST) (envelope-from nsouch) Message-ID: <19990725005636.15023@breizh.teaser.fr> Date: Sun, 25 Jul 1999 00:56:36 +0200 From: Nicolas Souchu To: Poul-Henning Kamp Cc: Dag-Erling Smorgrav , Maxim Sobolev , obrien@NUXI.com, current@FreeBSD.ORG Subject: Re: PLIP is still broken :( References: <15419.932375724@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <15419.932375724@critter.freebsd.dk>; from Poul-Henning Kamp on Mon, Jul 19, 1999 at 11:15:24AM +0200 X-Operating-System: FreeBSD breizh 4.0-CURRENT FreeBSD 4.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 19, 1999 at 11:15:24AM +0200, Poul-Henning Kamp wrote: > > >This is actually a deficiency in the ppbus stuff, there is no >telling what SPL level the subdriver wants to use, so the interrupt This is changing. I'm currently working on porting ppbus to newbus. >should actually be released back to the system when no subdrivers What do you exactly call back to the system? Not served? If so, this is the current behaviour of the generic ppbus interrupt dispatcher (eg ppb_intr()) >are open and be grabbed the way the subdriver wants it once it >aquires the bus. But the newbus which relies on the old machdep intr stuff doesn't seem to offer such a service. Doesn't it? Why was the SLIP hack removed then? And I noticed the PPP workaround is still alive in net/ppp_tty.c... Nicholas. -- nsouch@teaser.fr / nsouch@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 16: 7:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from reliam.teaser.fr (reliam.teaser.fr [194.51.80.12]) by hub.freebsd.org (Postfix) with ESMTP id 1797F1516D for ; Sat, 24 Jul 1999 16:07:09 -0700 (PDT) (envelope-from nsouch@teaser.fr) Received: from teaser.fr (ppp1087-ft.teaser.fr [194.206.156.40]) by reliam.teaser.fr (8.9.3/8.9.3) with ESMTP id BAA05842; Sun, 25 Jul 1999 01:06:21 +0200 (MET DST) Received: (from nsouch@localhost) by teaser.fr (8.9.3/8.9.1) id BAA06538; Sun, 25 Jul 1999 01:08:07 +0200 (CEST) (envelope-from nsouch) Message-ID: <19990725010807.06199@breizh.teaser.fr> Date: Sun, 25 Jul 1999 01:08:07 +0200 From: Nicolas Souchu To: Bruce Evans Cc: des@flood.ping.uio.no, sobomax@altavista.net, current@FreeBSD.ORG, obrien@NUXI.com Subject: Re: PLIP is still broken :( References: <199907190937.TAA28795@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199907190937.TAA28795@godzilla.zeta.org.au>; from Bruce Evans on Mon, Jul 19, 1999 at 07:37:02PM +1000 X-Operating-System: FreeBSD breizh 4.0-CURRENT FreeBSD 4.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 19, 1999 at 07:37:02PM +1000, Bruce Evans wrote: > >>You misunderstood what Bruce wrote. PLIP has always been broken. It >>used to be possible to hack around the brokenness by setting the >>interrupt mask to net instead of tty. With newbus, this hack is no >>longer possible (it was never correct anyway; it broke printing). Or we shall consider changing isa_compat.c if we choose splnet for lpt. > >Or by statically configuring SLIP (which forced tty = net), or maybe >by dynamically configuring PPP. The tty = net hack went away with >old-bus, so SLIP is broken in much the same way as PLIP. > >>The problem with PLIP is that it tries to do splnet stuff in at >>spltty. If you force the parallell port driver to run at splnet, PLIP >>works but you get panics when you print because it tries to do spltty >>stuff at splnet. > >Possible quick fix (hack): change all the spltty()'s in lpt.c to >splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing >splnet() instead should work OK for lpt and fix if_plip. This seems good until the intr stuff handle dynamic update of a interrupt spl. Is there some work in progress on that? > >Bruce > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-current" in the body of the message > -- nsouch@teaser.fr / nsouch@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 16:36: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 2F36F14E93 for ; Sat, 24 Jul 1999 16:36:00 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id JAA10442; Sun, 25 Jul 1999 09:35:36 +1000 Date: Sun, 25 Jul 1999 09:35:36 +1000 From: Bruce Evans Message-Id: <199907242335.JAA10442@godzilla.zeta.org.au> To: bde@zeta.org.au, nsouch@teaser.fr Subject: Re: PLIP is still broken :( Cc: current@FreeBSD.ORG, des@flood.ping.uio.no, obrien@NUXI.com, sobomax@altavista.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>Possible quick fix (hack): change all the spltty()'s in lpt.c to >>splnet()'s. lpt isn't a tty driver; it just abuses spltty(). Abusing >>splnet() instead should work OK for lpt and fix if_plip. > >This seems good until the intr stuff handle dynamic update of a interrupt spl. >Is there some work in progress on that? Not much. ppc needs to do most of the work by registering its interrupt with the correct interrupt maskptr for the currently attached device. This may involve unregistering the interrupt when the device changes. The generic code could help here by supporting atomic changing of interrupt maskptrs without unregistering the interrupt. Otherwise, the generic code is missing mainly update of the interrupt masks when an interrupt is unregistered. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 16:47:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id C642914D45 for ; Sat, 24 Jul 1999 16:47:33 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id QAA79453 for ; Sat, 24 Jul 1999 16:44:51 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: freebsd-current@FreeBSD.ORG Subject: Re: Permissions still broken on current.freebsd.org In-reply-to: Your message of "Fri, 23 Jul 1999 23:58:42 +0200." <199907232158.XAA00554@dorifer.heim3.tu-clausthal.de> Date: Sat, 24 Jul 1999 16:44:51 -0700 Message-ID: <79450.932859891@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Already done.. :) > Hi, > > The permissions of new -current snapshots on > current.freebsd.org are still broken. :-( > > If everything else fails, I'd suggest to set > up a cronjob to fix the permissions, until the > cause of the problem is found. Putting up > snapshots without letting us download them is > no good... > > Regards > Oliver > (desperate mirror admin ;-) > > -- > Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany > (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) > > "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" > (Terry Pratchett) > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 16:53:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from pechter.dyndns.org (bg-tc-ppp896.monmouth.com [209.191.51.82]) by hub.freebsd.org (Postfix) with ESMTP id A10AE14D45 for ; Sat, 24 Jul 1999 16:53:12 -0700 (PDT) (envelope-from pechter@pechter.dyndns.org) Received: (from pechter@localhost) by pechter.dyndns.org (8.9.3/8.9.3) id TAA10489 for freebsd-current@freebsd.org; Sat, 24 Jul 1999 19:46:53 -0400 (EDT) (envelope-from pechter) From: Bill Pechter Message-Id: <199907242346.TAA10489@pechter.dyndns.org> Subject: FreeBSD-current and Netscape Java To: freebsd-current@freebsd.org Date: Sat, 24 Jul 1999 19:46:52 -0400 (EDT) Reply-To: bpechter@shell.monmouth.com X-Phone-Number: 908-389-3592 X-OS-Type: FreeBSD 3.0-Stable X-Mailer: ELM [version 2.4ME+ PL43 (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 Are there any tricks to getting Java in Netscape running with FreeBSD --current. I've suddenly noticed it's not working (tried 4.08 and 4.6 with Fortify 1.4.4 applied and it's no-go even with the classpath set correctly...) Bill --- bpechter@shell.monmouth.com|pechter@pechter.dyndns.org Three things never anger: First, the one who runs your DEC, The one who does Field Service and the one who signs your check. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 17:16:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from dt011n65.san.rr.com (dt011n65.san.rr.com [204.210.13.101]) by hub.freebsd.org (Postfix) with ESMTP id 6C68314EE7 for ; Sat, 24 Jul 1999 17:16:35 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt011n65.san.rr.com (8.8.8/8.8.8) with ESMTP id RAA07596; Sat, 24 Jul 1999 17:14:46 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <379A56F6.DE183324@gorean.org> Date: Sat, 24 Jul 1999 17:14:46 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tony Finch Cc: current@freebsd.org Subject: Re: PMAP_SHPGPERPROC: related to pagedaemon? References: <199907232253.PAA25976@implode.root.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Tony Finch wrote: > > Doug wrote: > > > > *Nod* well, we do a lot of "unusual" things around here. :) Given > >your explanation I think that the culprit is probably apache. The virtual > >host file has approximately 16k hosts. > > *ouch* Yeah, tell me about it. > You should take a gander at http://www.apache.org/docs/vhosts/mass.html Thank you for the suggestion, but I think that this would not be an acceptable option on the basis of the logging requirements. Also, this setup presupposes some things about the directory structure(s) that wouldn't be compatible with our setup. Thanks again, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 18:34:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from rebel.net.au (rebel.rebel.net.au [203.20.69.66]) by hub.freebsd.org (Postfix) with ESMTP id 352B61500E for ; Sat, 24 Jul 1999 18:34:43 -0700 (PDT) (envelope-from kkenn@rebel.net.au) Received: from 203.20.69.77 (dialup-7.rebel.net.au [203.20.69.77]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id LAA13598 for ; Sun, 25 Jul 1999 11:04:41 +0930 Received: (qmail 21037 invoked from network); 25 Jul 1999 01:34:36 -0000 Received: from localhost (kkenn@127.0.0.1) by localhost with SMTP; 25 Jul 1999 01:34:36 -0000 Date: Sun, 25 Jul 1999 11:04:36 +0930 (CST) From: Kris Kennaway Reply-To: kkenn@rebel.net.au To: current@freebsd.org Subject: Unkillable processes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've got myself two processes which can't be gotten rid of by SIGKILL: kkenn 92724 32.0 0.8 5736 356 ?? RN 6:25PM 136:52.96 kvt -T Terminal - kkenn 1103 0.0 0.0 5740 388 ?? TWN - 0:00.00 (kvt) (kvt is the KDE 1.1.1 xterm) I am able to trigger this by attempting to paste the contents of a large buffer from xemacs (v21.1 from ports) into the pico editor from pine4. Any ideas before I recompile kvt with -g and try and track down what it's doing? Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 18:39:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id D497D1500E for ; Sat, 24 Jul 1999 18:39:12 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id UAA06405; Sat, 24 Jul 1999 20:38:12 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907250138.UAA06405@celery.dragondata.com> Subject: Re: Unkillable processes In-Reply-To: from Kris Kennaway at "Jul 25, 1999 11:04:36 am" To: kkenn@rebel.net.au Date: Sat, 24 Jul 1999 20:38:12 -0500 (CDT) 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 > I've got myself two processes which can't be gotten rid of by SIGKILL: > > kkenn 92724 32.0 0.8 5736 356 ?? RN 6:25PM 136:52.96 kvt -T Terminal - > kkenn 1103 0.0 0.0 5740 388 ?? TWN - 0:00.00 (kvt) > > (kvt is the KDE 1.1.1 xterm) > > I am able to trigger this by attempting to paste the contents of a large > buffer from xemacs (v21.1 from ports) into the pico editor from pine4. > > Any ideas before I recompile kvt with -g and try and track down what it's > doing? > > Kris > > For one, do another 'ps' with the 'l' option, so you can see what it's stuck on. The second process is a zombie, which isn't killable until the parent tells it to go away. (Which could very possibly be the first kvt) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 18:45:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from rebel.net.au (rebel.rebel.net.au [203.20.69.66]) by hub.freebsd.org (Postfix) with ESMTP id 7F59E14DF2 for ; Sat, 24 Jul 1999 18:45:37 -0700 (PDT) (envelope-from kkenn@rebel.net.au) Received: from 203.20.69.77 (dialup-7.rebel.net.au [203.20.69.77]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id LAA13741 for ; Sun, 25 Jul 1999 11:15:29 +0930 Received: (qmail 21666 invoked from network); 25 Jul 1999 01:45:25 -0000 Received: from localhost (kkenn@127.0.0.1) by localhost with SMTP; 25 Jul 1999 01:45:25 -0000 Date: Sun, 25 Jul 1999 11:15:24 +0930 (CST) From: Kris Kennaway Reply-To: kkenn@rebel.net.au To: Kevin Day Cc: current@FreeBSD.ORG Subject: Re: Unkillable processes In-Reply-To: <199907250138.UAA06405@celery.dragondata.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 Sat, 24 Jul 1999, Kevin Day wrote: > For one, do another 'ps' with the 'l' option, so you can see what it's stuck > on. UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 1000 1103 1086 29 75 20 5740 384 - TWN ?? 0:00.00 (kvt) 1000 1109 1103 0 4 0 1504 0 ttywri IWs+ p1 0:00.00 (tcsh) 1000 92724 1086 279 105 20 5736 356 - RN ?? 139:40.13 kvt -T Termi 1000 92743 92724 2 18 0 1576 0 pause IWs p8 0:00.00 (tcsh) > The second process is a zombie, which isn't killable until the parent tells > it to go away. (Which could very possibly be the first kvt) Both still present empty terminal windows on my desktop and were spawned from the KDE panel. The second one was running a copy of pine and was in the same state as the other initially, until I kill -KILL'ed the pine process, at which point it changed to what it is now. Kris > Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 18:52: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id D60B014D07 for ; Sat, 24 Jul 1999 18:51:56 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id UAA23051; Sat, 24 Jul 1999 20:51:37 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907250151.UAA23051@celery.dragondata.com> Subject: Re: Unkillable processes In-Reply-To: from Kris Kennaway at "Jul 25, 1999 11:15:24 am" To: kkenn@rebel.net.au Date: Sat, 24 Jul 1999 20:51:37 -0500 (CDT) Cc: toasty@dragondata.com (Kevin Day), current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sat, 24 Jul 1999, Kevin Day wrote: > > > For one, do another 'ps' with the 'l' option, so you can see what it's stuck > > on. > > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > 1000 1103 1086 29 75 20 5740 384 - TWN ?? 0:00.00 (kvt) > 1000 1109 1103 0 4 0 1504 0 ttywri IWs+ p1 0:00.00 (tcsh) > > 1000 92724 1086 279 105 20 5736 356 - RN ?? 139:40.13 kvt -T Termi > 1000 92743 92724 2 18 0 1576 0 pause IWs p8 0:00.00 (tcsh) > > > The second process is a zombie, which isn't killable until the parent tells > > it to go away. (Which could very possibly be the first kvt) > > Both still present empty terminal windows on my desktop and were spawned > from the KDE panel. The second one was running a copy of pine and was in > the same state as the other initially, until I kill -KILL'ed the pine > process, at which point it changed to what it is now. > > Kris Well, since the CPU time in the active process (92724) went up since your last e-mail, and it's in the RUN state (a - in the WCHAN and a R in the STAT), it looks like the process is just spinning, eating CPU. The tcsh listed below that is a zombie of the running kvt. If you can somehow kill that kvt, the tcsh will go away. The top kvt (1103) is also a zombie, waiting for it's parent to reap it. Whatever process 1086 is decided not to clean it up, you may want to see what it's doing. Will process 92724 die if you kill -9 it? This seems to be more of a kvt bug than a freebsd bug. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 19:21:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from rebel.net.au (rebel.rebel.net.au [203.20.69.66]) by hub.freebsd.org (Postfix) with ESMTP id 7B7C815012 for ; Sat, 24 Jul 1999 19:21:35 -0700 (PDT) (envelope-from kkenn@rebel.net.au) Received: from 203.20.69.77 (dialup-7.rebel.net.au [203.20.69.77]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id LAA14048 for ; Sun, 25 Jul 1999 11:50:32 +0930 Received: (qmail 26983 invoked from network); 25 Jul 1999 02:20:06 -0000 Received: from localhost (kkenn@127.0.0.1) by localhost with SMTP; 25 Jul 1999 02:20:06 -0000 Date: Sun, 25 Jul 1999 11:50:05 +0930 (CST) From: Kris Kennaway Reply-To: kkenn@rebel.net.au To: Kevin Day Cc: current@FreeBSD.ORG Subject: Re: Unkillable processes In-Reply-To: <199907250151.UAA23051@celery.dragondata.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 Sat, 24 Jul 1999, Kevin Day wrote: > > > For one, do another 'ps' with the 'l' option, so you can see what it's stuck > > > on. > > > > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > > 1000 1103 1086 29 75 20 5740 384 - TWN ?? 0:00.00 (kvt) > > 1000 1109 1103 0 4 0 1504 0 ttywri IWs+ p1 0:00.00 (tcsh) > > > > 1000 92724 1086 279 105 20 5736 356 - RN ?? 139:40.13 kvt -T Termi > > 1000 92743 92724 2 18 0 1576 0 pause IWs p8 0:00.00 (tcsh) > > > > > The second process is a zombie, which isn't killable until the parent tells > > > it to go away. (Which could very possibly be the first kvt) > > > > Both still present empty terminal windows on my desktop and were spawned > > from the KDE panel. The second one was running a copy of pine and was in > > the same state as the other initially, until I kill -KILL'ed the pine > > process, at which point it changed to what it is now. > > > > Kris > > Well, since the CPU time in the active process (92724) went up since your > last e-mail, and it's in the RUN state (a - in the WCHAN and a R in the > STAT), it looks like the process is just spinning, eating CPU. Correct. Yet I cannot kill -9 it. > The tcsh listed below that is a zombie of the running kvt. If you can > somehow kill that kvt, the tcsh will go away. I can't kill -9 any of the processes listed above. > The top kvt (1103) is also a zombie, waiting for it's parent to reap it. > Whatever process 1086 is decided not to clean it up, you may want to see > what it's doing. That's kfm. > Will process 92724 die if you kill -9 it? No. Yet it continues to run and chew up CPU.. > This seems to be more of a kvt bug than a freebsd bug. :) I don't doubt it's mediated by KDE in some way, but I didn't think it was possible for processes to trap or ignore SIGKILLs and continue to run (chew up CPU). Zombie processes I can deal with, even if the window manager continues to present a window for them :-) Kris > Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 23:12:12 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id D93A114E14 for ; Sat, 24 Jul 1999 23:12:06 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id PAA11097; Sun, 25 Jul 1999 15:41:15 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id PAA51434; Sun, 25 Jul 1999 15:41:09 +0930 (CST) Date: Sun, 25 Jul 1999 15:41:09 +0930 From: Greg Lehey To: Kevin Day Cc: kkenn@rebel.net.au, current@FreeBSD.ORG Subject: Re: Unkillable processes Message-ID: <19990725154108.A51019@freebie.lemis.com> References: <199907250151.UAA23051@celery.dragondata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907250151.UAA23051@celery.dragondata.com>; from Kevin Day on Sat, Jul 24, 1999 at 08:51:37PM -0500 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 24 July 1999 at 20:51:37 -0500, Kevin Day wrote: >> On Sat, 24 Jul 1999, Kevin Day wrote: >> >>> For one, do another 'ps' with the 'l' option, so you can see what it's stuck >>> on. >> >> UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND >> 1000 1103 1086 29 75 20 5740 384 - TWN ?? 0:00.00 (kvt) >> 1000 1109 1103 0 4 0 1504 0 ttywri IWs+ p1 0:00.00 (tcsh) >> >> 1000 92724 1086 279 105 20 5736 356 - RN ?? 139:40.13 kvt -T Termi >> 1000 92743 92724 2 18 0 1576 0 pause IWs p8 0:00.00 (tcsh) >> >>> The second process is a zombie, which isn't killable until the parent tells >>> it to go away. (Which could very possibly be the first kvt) >> >> Both still present empty terminal windows on my desktop and were spawned >> from the KDE panel. The second one was running a copy of pine and was in >> the same state as the other initially, until I kill -KILL'ed the pine >> process, at which point it changed to what it is now. > > Well, since the CPU time in the active process (92724) went up since your > last e-mail, and it's in the RUN state (a - in the WCHAN and a R in the > STAT), it looks like the process is just spinning, eating CPU. Right. > The tcsh listed below that is a zombie of the running kvt. There aren't any zombies here. It's a child of the kvt. It's not a zombie. Take a look at the STAT field (and ps(1)): process Process 1103 is stopped (debug?). That's the T. It's also swapped (W) and nice (N), which you can also see from the NI (nice) field. Process 1109 is idle, swapped and a foreground process of a process group. Process 92724 is runnable, nice and running (no WCHAN). I really don't understand why you can't stop this one. Process 92743 is idle, swapped and a session leader. > This seems to be more of a kvt bug than a freebsd bug. :) I don't see that either. The fact that process 1103 is stopped is one thing; is there a gdb process in sight? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 24 23:22:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id B934B15081 for ; Sat, 24 Jul 1999 23:22:14 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id BAA55777; Sun, 25 Jul 1999 01:21:03 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907250621.BAA55777@celery.dragondata.com> Subject: Re: Unkillable processes In-Reply-To: <19990725154108.A51019@freebie.lemis.com> from Greg Lehey at "Jul 25, 1999 03:41:09 pm" To: grog@lemis.com (Greg Lehey) Date: Sun, 25 Jul 1999 01:21:03 -0500 (CDT) Cc: toasty@dragondata.com (Kevin Day), kkenn@rebel.net.au, current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Saturday, 24 July 1999 at 20:51:37 -0500, Kevin Day wrote: > >> On Sat, 24 Jul 1999, Kevin Day wrote: > >> > >>> For one, do another 'ps' with the 'l' option, so you can see what it's stuck > >>> on. > >> > >> UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > >> 1000 1103 1086 29 75 20 5740 384 - TWN ?? 0:00.00 (kvt) > >> 1000 1109 1103 0 4 0 1504 0 ttywri IWs+ p1 0:00.00 (tcsh) > >> > >> 1000 92724 1086 279 105 20 5736 356 - RN ?? 139:40.13 kvt -T Termi > >> 1000 92743 92724 2 18 0 1576 0 pause IWs p8 0:00.00 (tcsh) > >> > > Well, since the CPU time in the active process (92724) went up since your > > last e-mail, and it's in the RUN state (a - in the WCHAN and a R in the > > STAT), it looks like the process is just spinning, eating CPU. > > Right. > > > The tcsh listed below that is a zombie of the running kvt. > > There aren't any zombies here. > > It's a child of the kvt. It's not a zombie. Take a look at the STAT > field (and ps(1)): process Good point, i didn't notice that, i saw the ()'s from his first message, > Process 92724 is runnable, nice and running (no WCHAN). I really > don't understand why you can't stop this one. The only time I've seen this is when my console is getting flooded with 'vm_fault: pager error' messages for that process. Otherwise, there's no reason why a running process can't be killed, correct? Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message