From owner-freebsd-current Sun Jul 22 0:52:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 969E737B428; Sun, 22 Jul 2001 00:52:21 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from blossom.cjclark.org (dialup-209.247.142.29.Dial1.SanJose1.Level3.net [209.247.142.29]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA23275; Sun, 22 Jul 2001 00:52:20 -0700 (PDT) Received: (from cjc@localhost) by blossom.cjclark.org (8.11.4/8.11.3) id f6M7qJI09387; Sun, 22 Jul 2001 00:52:19 -0700 (PDT) (envelope-from cjc) Date: Sun, 22 Jul 2001 00:52:19 -0700 From: "Crist J. Clark" To: hm@freebsd.org Cc: current@freebsd.org Subject: Broken CURRENT Message-ID: <20010722005219.D7701@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Looks like installworld is broken in CURRENT. The /usr/share/examples/isdn/i4runppp directory was not added to etc/mtree/BSD.usr.dist. Who's got the pointy hat? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 2:37:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from ns.marineronline.net (ns.marineronline.net [162.33.182.225]) by hub.freebsd.org (Postfix) with ESMTP id 00F3C37B406 for ; Sun, 22 Jul 2001 02:37:11 -0700 (PDT) (envelope-from capndave@marineronline.net) Received: from Admiral (cc1044731-a.twsn1.md.home.com [24.180.165.79]) by ns.marineronline.net (8.11.1/8.11.1) with SMTP id f6M9OrU58848 for ; Sun, 22 Jul 2001 05:24:58 -0400 (EDT) (envelope-from capndave@marineronline.net) Reply-To: From: "Cap'n Dave" To: Subject: Date: Sun, 22 Jul 2001 05:40:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG For reasonable internet solutions within the Maryland, DC, Northern VA, PA, and DE areas visit us at http://www.marineronline.net/ . For more information call either 410-663-6776 or 800-692-9011. Visit our Site at http://www.capndave.net/ for your boating needs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 2:37:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from ns.marineronline.net (ns.marineronline.net [162.33.182.225]) by hub.freebsd.org (Postfix) with ESMTP id 7832D37B407 for ; Sun, 22 Jul 2001 02:37:11 -0700 (PDT) (envelope-from capndave@marineronline.net) Received: from Admiral (cc1044731-a.twsn1.md.home.com [24.180.165.79]) by ns.marineronline.net (8.11.1/8.11.1) with SMTP id f6M9P9U58855 for ; Sun, 22 Jul 2001 05:25:09 -0400 (EDT) (envelope-from capndave@marineronline.net) Reply-To: From: "Cap'n Dave" To: Subject: Date: Sun, 22 Jul 2001 05:41:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Please add to mailing list For reasonable internet solutions within the Maryland, DC, Northern VA, PA, and DE areas visit us at http://www.marineronline.net/ . For more information call either 410-663-6776 or 800-692-9011. Visit our Site at http://www.capndave.net/ for your boating needs. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 2:42: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from hcshh.hcs.de (hcshh.hcs.de [194.123.40.1]) by hub.freebsd.org (Postfix) with ESMTP id 74E2E37B403; Sun, 22 Jul 2001 02:41:59 -0700 (PDT) (envelope-from hm@hcs.de) Received: from localhost (localhost [127.0.0.1]) by hcshh.hcs.de (Postfix) with ESMTP id 915BDBA03; Sun, 22 Jul 2001 11:41:58 +0200 (CEST) Received: from hcswork.hcs.de (hcswork.hcs.de [172.24.124.5]) by hcshh.hcs.de (Postfix) with ESMTP id 5D1D0BA02; Sun, 22 Jul 2001 11:41:57 +0200 (CEST) Received: by hcswork.hcs.de (Postfix, from userid 200) id 3C0C8529; Sun, 22 Jul 2001 11:41:57 +0200 (METDST) Subject: Re: Broken CURRENT In-Reply-To: <20010722005219.D7701@blossom.cjclark.org> "from Crist J. Clark at Jul 22, 2001 00:52:19 am" To: cjclark@alum.mit.edu Date: Sun, 22 Jul 2001 11:41:57 +0200 (METDST) Cc: hm@freebsd.org, current@freebsd.org Reply-To: hm@hcs.de Organization: HCS Hanseatischer Computerservice GmbH X-Mailer: ELM [version 2.4ME+ PL84 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20010722094157.3C0C8529@hcswork.hcs.de> From: hm@hcs.de (Hellmuth Michaelis) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG From the keyboard of Crist J. Clark: > Looks like installworld is broken in CURRENT. The > /usr/share/examples/isdn/i4runppp directory was not added to > etc/mtree/BSD.usr.dist. > > Who's got the pointy hat? Me. Fix just committed ... Sorry, hellmuth -- Hellmuth Michaelis Tel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbH Fax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 3:11:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from midten.fast.no (midten.fast.no [213.188.8.11]) by hub.freebsd.org (Postfix) with ESMTP id 140ED37B407 for ; Sun, 22 Jul 2001 03:11:17 -0700 (PDT) (envelope-from Tor.Egge@fast.no) Received: from fast.no (IDENT:tegge@midten.fast.no [213.188.8.11]) by midten.fast.no (8.9.3/8.9.3) with ESMTP id MAA01533; Sun, 22 Jul 2001 12:11:13 +0200 (CEST) Message-Id: <200107221011.MAA01533@midten.fast.no> To: david@catwhisker.org Cc: current@FreeBSD.ORG Subject: Re: Interruptable hang starting init in today's -CURRENT From: Tor.Egge@fast.no In-Reply-To: Your message of "Thu, 5 Jul 2001 12:04:18 -0700 (PDT)" References: <200107051904.f65J4I217302@bunrab.catwhisker.org> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Jul_22_12:07:57_2001)--" Content-Transfer-Encoding: 7bit Date: Sun, 22 Jul 2001 12:11:12 +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ----Next_Part(Sun_Jul_22_12:07:57_2001)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Interestingly, "sysctl -a -N" spits out names, but then seems to fall > into a rut: > [....] > net.inet.udp.getcred > net.inet.accf.unloadable > net.inet.accf.373 > net.inet.accf.373 > net.inet.accf.373 [....] > Looks as if it's looping with no termination conditions being matched. When I got the same problem on my -current machine today, I found that net.inet.accf and net.inet.raw had the same oid. The system booted normally after changing the start oid for dynamically assigned sysctl entries from 100 to 256. - Tor Egge ----Next_Part(Sun_Jul_22_12:07:57_2001)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Index: sys/kern/kern_sysctl.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v retrieving revision 1.110 diff -u -r1.110 kern_sysctl.c --- sys/kern/kern_sysctl.c 2001/06/22 19:54:38 1.110 +++ sys/kern/kern_sysctl.c 2001/07/22 09:33:11 @@ -110,10 +110,10 @@ /* * If this oid has a number OID_AUTO, give it a number which * is greater than any current oid. Make sure it is at least - * 100 to leave space for pre-assigned oid numbers. + * 256 to leave space for pre-assigned oid numbers. */ if (oidp->oid_number == OID_AUTO) { - static int newoid = 100; + static int newoid = 256; oidp->oid_number = newoid++; if (newoid == 0x7fffffff) ----Next_Part(Sun_Jul_22_12:07:57_2001)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 7:39:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B27037B401 for ; Sun, 22 Jul 2001 07:39:24 -0700 (PDT) (envelope-from vince@oahu.WURLDLINK.NET) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.11.3/8.11.3) with ESMTP id f6MEdHE38315; Sun, 22 Jul 2001 04:39:17 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Sun, 22 Jul 2001 04:39:16 -1000 (HST) From: Vincent Poy To: David Wolfskill Cc: , Subject: Re: -current kernel hangs? In-Reply-To: <200107201849.f6KIn3k74841@bunrab.catwhisker.org> Message-ID: <20010722043754.M30439-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 20 Jul 2001, David Wolfskill wrote: > >Date: Fri, 20 Jul 2001 10:57:02 +0700 (NOVST) > >From: nnd@mail.nsk.ru > > >>> > With a July 18, 2001 sources, it seems like the kernel hands at > >>> >the entropy harvesting stage.... ctrl-t shows: > > >>> Also (again, for me) "sysctl -N -a" outputs a (non-terminating) stream of > >>> ... > > > I have some kind of "workaround" (see the patch). > >In my config without this patch 'sysctl -a' hungs at net.inet.accf > >and with this patch it successfully run up to the end. > >I can not see what is wrong with the lines disabled by the patch. > > > After building today's -CURRENT OK (and observing that the behavior was > still the same for my custom kernel), I tried building a GENERIC kernel. > Much to my surprise (and different from my experience on 06 July -- > last time I had built a GENERIC kernel for -CURRENT), that kernel did > not exhibit the symptoms. > > I've now managed to circumvent the problem by: > > * Removing the "device pcm" specification in my custom kernel config. > > * Adding the lines > > snd_pcm_load="YES" > snd_maestro_load="YES" > > to /boot/loader.conf > > * Re-building the kernel. (cd /usr/src; make kernel KERNCONF=LAPTOP_30W) > > * Re-booting. > > It took a few tries to get things quite right, but sound works again; > thanks to the patch in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26854, > I'm (still) able to use the keyboard Fn+End chord to mute the sound > during boot (so that process is less disruptive in meetings). (BTW, it > would be nice to get that tiny little patch in before 4.4-R. Please?) > > And yes, Linux emulation still works. Linux emulation is fine... it seems to be sysctl -a will hang on different devices from the information we've seen so far. With me, it hangs when these two are added and everything works fine when these two are gone. # Enable the linux-like proc filesystem support (requires COMPAT_LINUX # and PSEUDOFS) options LINPROCFS options PSEUDOFS COMPAT_LINUX isn't the problem. Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 9: 9:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from solar.phyco.net (c433473-g.adrian1.mi.home.com [24.182.101.49]) by hub.freebsd.org (Postfix) with ESMTP id 3F5FA37B405 for ; Sun, 22 Jul 2001 09:09:08 -0700 (PDT) (envelope-from aja@phyco.net) Received: from localhost (aja@localhost) by solar.phyco.net (8.11.3/8.11.4) with ESMTP id f6MG9ZI06114 for ; Sun, 22 Jul 2001 12:09:35 -0400 (EDT) (envelope-from aja@phyco.net) Date: Sun, 22 Jul 2001 12:09:34 -0400 (EDT) From: Aaron Angel To: Subject: ssh rsa authentication Message-ID: <20010722120707.R6112-100000@solar.phyco.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Not sure if this is actually freebsd-current ralated, but when I was last in 4.3-release, I do recall having used rsa authentication correctly, and I can't find info anywhere else. When I try to log into ssh (from anyway, even locally) using my rsa key, it opens the session, and then immediately closes. It puts an entry in /var/log/messages: fatal: PAM setcred failed[6]: Permission denied" Any ideas? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 11: 1:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 77ED037B401 for ; Sun, 22 Jul 2001 11:01:24 -0700 (PDT) (envelope-from cjc@earthlink.net) Received: from blossom.cjclark.org (dialup-209.247.142.113.Dial1.SanJose1.Level3.net [209.247.142.113]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id LAA23568; Sun, 22 Jul 2001 11:01:22 -0700 (PDT) Received: (from cjc@localhost) by blossom.cjclark.org (8.11.4/8.11.3) id f6MI1Ib00796; Sun, 22 Jul 2001 11:01:18 -0700 (PDT) (envelope-from cjc) Date: Sun, 22 Jul 2001 11:01:18 -0700 From: "Crist J. Clark" To: Aaron Angel Cc: freebsd-current@FreeBSD.ORG Subject: Re: ssh rsa authentication Message-ID: <20010722110118.A323@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu References: <20010722120707.R6112-100000@solar.phyco.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010722120707.R6112-100000@solar.phyco.net>; from aja@phyco.net on Sun, Jul 22, 2001 at 12:09:34PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 22, 2001 at 12:09:34PM -0400, Aaron Angel wrote: > Not sure if this is actually freebsd-current ralated, but when I was last > in 4.3-release, I do recall having used rsa authentication correctly, and > I can't find info anywhere else. > > When I try to log into ssh (from anyway, even locally) using my rsa key, > it opens the session, and then immediately closes. It puts an entry in > /var/log/messages: > > fatal: PAM setcred failed[6]: Permission denied" > > Any ideas? You didn't mergemaster(8) or otherwise update /etc/pam.conf after an upgrade? -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 11: 7:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from Veronica.wmol.com (veronica.wmol.com [208.242.83.241]) by hub.freebsd.org (Postfix) with ESMTP id A54B837B405 for ; Sun, 22 Jul 2001 11:07:42 -0700 (PDT) (envelope-from david@phobia.ms) Received: from rain (081bc122.chartermi.net [24.247.81.122]) by Veronica.wmol.com (Vircom SMTPRS 4.6.189) with ESMTP id for ; Sun, 22 Jul 2001 14:02:51 -0400 Message-ID: <005301c112d8$c2293180$0201a8c0@hill.hom> From: "David Hill" To: Subject: commit Perl 5.6.1 into -current Date: Sun, 22 Jul 2001 14:04:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C112B7.34D6EBE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C112B7.34D6EBE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am suggesting the import of Perl 5.6.1 into -CURRENT before -CURRENT = is -STABLE. Is this a large task? Thanks - David ------=_NextPart_000_0050_01C112B7.34D6EBE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am suggesting the import of Perl = 5.6.1 into=20 -CURRENT before -CURRENT is -STABLE.
 
Is this a large task?
 
Thanks
- David
------=_NextPart_000_0050_01C112B7.34D6EBE0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 19:38: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id D987337B403 for ; Sun, 22 Jul 2001 19:38:01 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6N2buI02044; Mon, 23 Jul 2001 03:37:57 +0100 (BST) (envelope-from brian@lan.Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.4/8.11.4) with ESMTP id f6N2btg14488; Mon, 23 Jul 2001 03:37:55 +0100 (BST) (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200107230237.f6N2btg14488@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Warner Losh Cc: Vincent Poy , current@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Userbase of -current In-Reply-To: Message from Warner Losh of "Sat, 21 Jul 2001 16:11:10 MDT." <200107212211.f6LMBAo78214@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Jul 2001 03:37:55 +0100 From: Brian Somers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > In message Vincent Poy writes: > : Somehow I always thought there were more than 50 people who are > : "really running" current. We do stress test it though and it had > : performed flawlessly over the past 8 years. Question though, does anyone > : happen to know what the largest maxusers variable is that one can define > : in the kernel config file? We have it at 512 but what's the highest > : number people have used reliably? Thanks. > > I've had at least 50 different people talk to me about NEWCARD, which > is only available in current... Sorry, they were all me. I figured I'd present a stronger case that way !!! > Warner -- Brian http://www.freebsd-services.com/ 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 Sun Jul 22 20: 6:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from solar.phyco.net (c433473-g.adrian1.mi.home.com [24.182.101.49]) by hub.freebsd.org (Postfix) with ESMTP id 0F79037B401 for ; Sun, 22 Jul 2001 20:06:15 -0700 (PDT) (envelope-from aja@phyco.net) Received: from localhost (aja@localhost) by solar.phyco.net (8.11.3/8.11.4) with ESMTP id f6N36dm00563; Sun, 22 Jul 2001 23:06:39 -0400 (EDT) (envelope-from aja@phyco.net) Date: Sun, 22 Jul 2001 23:06:38 -0400 (EDT) From: Aaron Angel To: Cc: Subject: Re: ssh rsa authentication In-Reply-To: <20010722195402.B419@blossom.cjclark.org> Message-ID: <20010722230537.Q559-100000@solar.phyco.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > So you have the line, > > sshd session required pam_permit.so Yep. In pam.conf, regarding ssh I have the following lines: sshd auth required pam_nologin.so sshd auth required pam_unix.so try_first_pass sshd account required pam_unix.so sshd password required pam_permit.so sshd session required pam_permit.so To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 22 22:58:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 6BCBE37B403 for ; Sun, 22 Jul 2001 22:58:55 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f6N5xhI06915; Sun, 22 Jul 2001 22:59:43 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200107230559.f6N5xhI06915@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "neckpain@nettaxi.com" Cc: current@freebsd.org Subject: Re: acpica malfunctions In-reply-to: Your message of "Thu, 19 Jul 2001 18:01:25 PDT." <200107200101.SAA06562@mail24.bigmailbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 22 Jul 2001 22:59:43 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Hi. > I'm running -current whose source tree was checked out as > TZ=UTC cvs co -D'2001-07-12' src > on VAIO PCG-C1XE(PentiumII with 64Mbytes of RAM) > and have some problems: > > 1. Acpica modules hangs in > AcpiRsCalculateByteStreamLength() called from > AcpiRsCreateByteStream() called from > AcpiRsSetSrsMethodData() called from > AcpiSetCurrentResources() from somewhere in acpi_pcib.c . > > The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length == 0 > . Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484? I think I should be passing a pointer to the buffer, not a pointer to a pointer. This will make the code "less wrong", but is probably still illegal (depending on the size of the buffer that _CRS is returning). If you could duplicate the printf on line 396 and print crsbuf->Length out, that would be very helpful. Sorry for the delay. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 0:55:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id EB79D37B403 for ; Mon, 23 Jul 2001 00:55:17 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id CAA17664 for ; Mon, 23 Jul 2001 02:50:58 -0700 (PDT) Message-ID: <3B5BD579.400FE65E@elischer.org> Date: Mon, 23 Jul 2001 00:42:49 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: current@freebsd.org Subject: Progress report: KSEs. Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Despite my silence on the topic recently I've been active. step 1: get proc structure broken up, with system still running: done (twice) step 2: push the 'thread' structure into the mutex structure and the sleep queue, and then propogate all the required changes all the way up the kernel. step 3: get all state saved in a per-thread rather than per-process storage. step 4: rewrite all parts of the kernel that assume 1 thread per process. step 5: compile and run first time :-) I'm part way through #2 at the moment. So far it's meant replacing all occurances of proc with thread (and associated logical changes in some places) in the vfs system. and device layers. I'm presently wading around in kern_switch.c :-) The aim of #2 is to get a GENERIC kernel that runs with all the new parts of the proc structure all doing their own jobs, and all the rest of the kernel using the correct parts for what they need, i.e. removing the compatibility macro's e.g. #define p_cpticks p_kse.ke_cpticks but not change the system logic that assumes that there is only one thread per process. (that's #4) the diffs are presently: -rw-r--r-- 1 julian wheel 333041 Jul 23 00:29 kse.diffs.july23 and growing.. I hope to get a running GENERIC kernel in a week or so. here are some snippets from the diffs for a sample of the changes: -------- Index: alpha/alpha/exception.s =================================================================== RCS file: /unused/cvs/freebsd/src/sys/alpha/alpha/exception.s,v retrieving revision 1.12 diff -u -r1.12 exception.s --- alpha/alpha/exception.s 2001/06/08 13:38:02 1.12 +++ alpha/alpha/exception.s 2001/07/20 07:12:37 @@ -139,7 +139,7 @@ beq t1, exception_return /* set the hae register if this process has specified a value */ - ldq s0, GD_CURPROC(globalp) + ldq s0, GD_CURTHREAD(globalp) ldq t1, P_MD_FLAGS(s0) and t1, MDP_HAEUSED beq t1, 3f @@ -255,7 +255,7 @@ br pv, Ler1 Ler1: LDGP(pv) - ldq s0, GD_CURPROC(globalp) /* save curproc in s0 */ + ldq s0, GD_CURTHREAD(globalp) /* save curthread in s0 */ #ifdef SMP ldl s1, P_MD_KERNNEST(s0) subl s1, 1, s1 /* decrement nesting level */ Index: dev/random/randomdev.c =================================================================== RCS file: /unused/cvs/freebsd/src/sys/dev/random/randomdev.c,v retrieving revision 1.28 diff -u -r1.28 randomdev.c --- dev/random/randomdev.c 2001/05/01 08:12:03 1.28 +++ dev/random/randomdev.c 2001/07/22 08:51:29 @@ -201,7 +201,7 @@ } static int -random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct proc *p) +random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct thread *td) { switch (cmd) { /* Really handled in upper layer */ @@ -214,7 +214,7 @@ } static int -random_poll(dev_t dev, int events, struct proc *p) +random_poll(dev_t dev, int events, struct thread *td) { int revents; @@ -223,7 +223,7 @@ if (random_systat.seeded) revents = events & (POLLIN | POLLRDNORM); else - selrecord(p, &random_systat.rsel); + selrecord(curthread, &random_systat.rsel); } return revents; } Index: fs/msdosfs/denode.h =================================================================== RCS file: /unused/cvs/freebsd/src/sys/fs/msdosfs/denode.h,v retrieving revision 1.21 diff -u -r1.21 denode.h --- fs/msdosfs/denode.h 2000/10/22 14:22:17 1.21 +++ fs/msdosfs/denode.h 2001/07/22 09:23:33 @@ -280,6 +280,6 @@ int createde __P((struct denode *dep, struct denode *ddep, struct denode **depp , struct componentname *cnp)); int deupdat __P((struct denode *dep, int waitfor)); int removede __P((struct denode *pdep, struct denode *dep)); -int detrunc __P((struct denode *dep, u_long length, int flags, struct ucred *cr ed, struct proc *p)); +int detrunc __P((struct denode *dep, u_long length, int flags, struct ucred *cr ed, struct thread *td)); int doscheckpath __P(( struct denode *source, struct denode *target)); #endif /* _KERNEL */ Index: fs/procfs/procfs_ctl.c =================================================================== RCS file: /unused/cvs/freebsd/src/sys/fs/procfs/procfs_ctl.c,v retrieving revision 1.30 diff -u -r1.30 procfs_ctl.c --- fs/procfs/procfs_ctl.c 2001/07/05 17:10:42 1.30 +++ fs/procfs/procfs_ctl.c 2001/07/22 09:46:21 @@ -300,7 +300,7 @@ mtx_lock_spin(&sched_lock); if (p->p_stat == SSTOP) - setrunnable(p); + setrunnable(&p->p_thread); /* XXXKSE */ mtx_unlock_spin(&sched_lock); return (0); } @@ -349,7 +349,7 @@ #ifdef FIX_SSTEP FIX_SSTEP(p); #endif - setrunnable(p); + setrunnable(&p->p_thread); /* XXXKSE */ mtx_unlock_spin(&sched_lock); } else { mtx_unlock_spin(&sched_lock); ----- Above you'll see the note /* XXXKSE */ this is a note to myself that I'm doing something to get things going that relies in the assumption of a 1:1 relationship between proc<->thread. All this sort of thing needs to be removed before #4 can be done. -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 1:15: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 45CF937B401; Mon, 23 Jul 2001 01:15:02 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id DAA17775; Mon, 23 Jul 2001 03:08:34 -0700 (PDT) Message-ID: <3B5BD998.3E8A6E7E@elischer.org> Date: Mon, 23 Jul 2001 01:00:24 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: jhb@freebsd.org, current@freebsd.org Subject: mutex blocking queues.. Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Why does the mutex not link blocked processes though the sleep queue linked list entry? Why does it use the run queue entry? In KSEs the sleep queue and run queue enties go into different sub structures and ahve different types so this breaks... do I need to do something sleazy or can I just link them together using the equivalemt of the p_slpq entry? -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 2:54:53 2001 Delivered-To: freebsd-current@freebsd.org Received: from heechee.tobez.org (254.adsl0.ryv.worldonline.dk [213.237.10.254]) by hub.freebsd.org (Postfix) with ESMTP id C5C5F37B406 for ; Mon, 23 Jul 2001 02:54:48 -0700 (PDT) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 74C865450; Mon, 23 Jul 2001 11:54:34 +0200 (CEST) Date: Mon, 23 Jul 2001 11:54:34 +0200 From: Anton Berezin To: David Hill Cc: current@freebsd.org Subject: Re: commit Perl 5.6.1 into -current Message-ID: <20010723115434.A83425@heechee.tobez.org> Mail-Followup-To: Anton Berezin , David Hill , current@freebsd.org References: <005301c112d8$c2293180$0201a8c0@hill.hom> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <005301c112d8$c2293180$0201a8c0@hill.hom>; from david@phobia.ms on Sun, Jul 22, 2001 at 02:04:21PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 22, 2001 at 02:04:21PM -0400, David Hill wrote: > I am suggesting the import of Perl 5.6.1 into -CURRENT before -CURRENT > is -STABLE. It will be done before -current is -stable. > Is this a large task? I guess it depends upon the experience of the person doing that. For me, yes, it is. The plan is to achieve the following goals by this import: 1. Faster build time (in comparison with 5.6.0). 2. Working standalone build - miniperl issues. 3. Support for NOSHARED=yes. 4. Working cross-platform build. 5. Move as many as possible modules to ports (debatable). 6. site directory before core in @INC (highly debatable). =Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 3:41:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 8BF5737B405; Mon, 23 Jul 2001 03:41:41 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15OdAY-000Cto-00; Mon, 23 Jul 2001 12:42:34 +0200 From: Sheldon Hearn To: Anton Berezin Cc: David Hill , current@freebsd.org Subject: Re: commit Perl 5.6.1 into -current In-reply-to: Your message of "Mon, 23 Jul 2001 11:54:34 +0200." <20010723115434.A83425@heechee.tobez.org> Date: Mon, 23 Jul 2001 12:42:34 +0200 Message-ID: <49587.995884954@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 23 Jul 2001 11:54:34 +0200, Anton Berezin wrote: > > Is this a large task? > > I guess it depends upon the experience of the person doing that. For > me, yes, it is. Hmmm, you do yourself a disservice. Mark Murray, rom whom you've taken over this responsibility, had quite a bit of experience with the Perl build and he himself found it an enormous task every time. Good luck! :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 4:21:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from k7.locore.ca (k7.locore.ca [198.96.117.169]) by hub.freebsd.org (Postfix) with ESMTP id 3E2E737B401; Mon, 23 Jul 2001 04:21:15 -0700 (PDT) (envelope-from jake@k7.locore.ca) Received: from k7.locore.ca (localhost [127.0.0.1]) by k7.locore.ca (8.11.4/8.11.4) with ESMTP id f6NBRg985918; Mon, 23 Jul 2001 07:27:42 -0400 (EDT) (envelope-from jake@k7.locore.ca) Message-Id: <200107231127.f6NBRg985918@k7.locore.ca> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Julian Elischer Cc: jhb@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: mutex blocking queues.. In-Reply-To: Message from Julian Elischer of "Mon, 23 Jul 2001 01:00:24 PDT." <3B5BD998.3E8A6E7E@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Jul 2001 07:27:42 -0400 From: Jake Burkholder Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Why does the mutex not link blocked processes though the > sleep queue linked list entry? Why does it use the run queue entry? Because in some cases its necessary for a process to acquire mutexes while its on the sleep queue. If they used the same linkage the queues would get corrupted. > In KSEs the sleep queue and run queue enties go into different > sub structures and ahve different types so this breaks... > do I need to do something sleazy or can I just link them together using the > equivalemt of the p_slpq entry? It seems to me that whatever gets placed on the run queues should also be what goes on the mutex queues. > > -- > +------------------------------------+ ______ _ __ > | __--_|\ Julian Elischer | \ U \/ / hard at work in > | / \ julian@elischer.org +------>x USA \ a very strange > | ( OZ ) \___ ___ | country ! > +- X_.---._/ presently in San Francisco \_/ \\ > v > > 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 Mon Jul 23 5:31: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail21.bigmailbox.com (mail21.bigmailbox.com [209.132.220.195]) by hub.freebsd.org (Postfix) with ESMTP id 7C62137B406; Mon, 23 Jul 2001 05:31:07 -0700 (PDT) (envelope-from neckpain@nettaxi.com) Received: œby mail21.bigmailbox.com (8.8.7/8.8.7) id FAA09442; Mon, 23 Jul 2001 05:31:07 -0700 Date: Mon, 23 Jul 2001 05:31:07 -0700 Message-Id: <200107231231.FAA09442@mail21.bigmailbox.com> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [203.141.100.99] From: "neckpain@nettaxi.com" To: msmith@freebsd.org Cc: neckpain@nettaxi.com, current@freebsd.org Subject: Re: acpica malfunctions Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Jul 22, 2001 at 10:59:43PM -0700, Mike Smith wrote: > > Hi. > > I'm running -current whose source tree was checked out as > > TZ=UTC cvs co -D'2001-07-12' src > > on VAIO PCG-C1XE(PentiumII with 64Mbytes of RAM) > > and have some problems: > > > > 1. Acpica modules hangs in > > AcpiRsCalculateByteStreamLength() called from > > AcpiRsCreateByteStream() called from > > AcpiRsSetSrsMethodData() called from > > AcpiSetCurrentResources() from somewhere in acpi_pcib.c . > > > > The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length == 0 > > . > > Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484? > I think I should be passing a pointer to the buffer, not a pointer to a > pointer. There's no &crsbuf in line 484 (not in rev 1.10, nor 1.11). Assuming you're talking about the one in line 478, it doesn't compile if you change it to crsbuf from &crsbuf, since crsbuf is an ACPI_BUFFER, not an (ACPI_BUFFER *). ------------------------------------------------------------ Shop Smart Compare Prices on Name-Brand Products from Name-Brand Stores!! http://www.smartshop.com/cgi-bin/main.cgi?ssa=4099 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 8:54:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 5DDE237B403 for ; Mon, 23 Jul 2001 08:54:36 -0700 (PDT) (envelope-from max@vega.com) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.4/8.11.4) with ESMTP id f6NFuMT62021 for ; Mon, 23 Jul 2001 18:56:25 +0300 (EEST) (envelope-from max@vega.com) Received: from vega.vega.com (das0-l20.uic-in.net [212.35.189.147]) by mail.uic-in.net (8.11.4/8.11.4) with ESMTP id f6NFsQt10052 for ; Mon, 23 Jul 2001 18:54:28 +0300 (EEST) (envelope-from max@vega.com) Received: (from max@localhost) by vega.vega.com (8.11.4/8.11.3) id f6NFsLk65848 for current@FreeBSD.org; Mon, 23 Jul 2001 18:54:21 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) From: Maxim Sobolev Message-Id: <200107231554.f6NFsLk65848@vega.vega.com> Subject: NFS client unable to recover from server crash To: current@FreeBSD.org Date: Mon, 23 Jul 2001 18:53:05 +0300 (EEST) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I found that after introduction of the new RPC NFS client is no longer able to recover from server crash (both cluent and server are 5-CURRENT systems). After a well known `nfs server not responding' message, client hangs and even though server comes back in a minute or two it doesn't recover and just sits in this state forvewer. All unmount requests gets stuck in the kernel, so as a processes that accessing files from that mount point. This doesn't looks like a right thing and obviously should be fixed before 5.0-RELEASE. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 9:12:27 2001 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 E9A8037B407; Mon, 23 Jul 2001 09:12:14 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 23 Jul 2001 17:12:13 +0100 (BST) To: Maxim Sobolev Cc: current@FreeBSD.org Subject: Re: NFS client unable to recover from server crash In-Reply-To: Your message of "Mon, 23 Jul 2001 18:53:05 +0300." <200107231554.f6NFsLk65848@vega.vega.com> Date: Mon, 23 Jul 2001 17:12:13 +0100 From: Ian Dowse Message-ID: <200107231712.aa22684@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200107231554.f6NFsLk65848@vega.vega.com>, Maxim Sobolev writes: >I found that after introduction of the new RPC NFS client is no longer >able to recover from server crash (both cluent and server are 5-CURRENT >systems). After a well known `nfs server not responding' message, client >hangs and even though server comes back in a minute or two it doesn't >recover and just sits in this state forvewer. All unmount requests gets >stuck in the kernel, so as a processes that accessing files from that >mount point. This doesn't looks like a right thing and obviously should >be fixed before 5.0-RELEASE. I've seen some similar effects, but I don't think it has anything to do with the new RPC code, as that only runs at mount time. It would be useful if you could use tcpdump to see if any requests are being transmitted, and if they are getting responses. Also try running kdgb on the client to get a kernel backtrace of the stuck processes. Is this a UDP or TCP based mount? If you are feeling brave, you could also try the patch below. It is a selection of changes to the kernel NFS code that I have built up over the last few months. I don't think it could solve the hangs, but it should improve the chance of interruptible mounts accepting ^C while waiting, and (just added the other day) umount -f should work while the server is down even if processes are hung. Ian Index: nfs.h =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/nfs/nfs.h,v retrieving revision 1.59 diff -u -r1.59 nfs.h --- nfs.h 2001/04/17 20:45:21 1.59 +++ nfs.h 2001/07/20 13:19:51 @@ -633,6 +633,7 @@ struct mbuf *)); int nfs_adv __P((struct mbuf **, caddr_t *, int, int)); void nfs_nhinit __P((void)); +void nfs_nmcancelreqs __P((struct nfsmount *)); void nfs_timer __P((void*)); int nfsrv_dorec __P((struct nfssvc_sock *, struct nfsd *, struct nfsrv_descript **)); Index: nfs_nqlease.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/nfs/nfs_nqlease.c,v retrieving revision 1.59 diff -u -r1.59 nfs_nqlease.c --- nfs_nqlease.c 2001/05/01 08:13:14 1.59 +++ nfs_nqlease.c 2001/05/01 14:29:22 @@ -952,7 +952,9 @@ } /* - * Called for client side callbacks + * Called for client side callbacks. + * NB: We are responsible for freeing `mrep' in all cases, but note + * that anything that does a 'goto nfsmout' frees it for us. */ int nqnfs_callback(nmp, mrep, md, dpos) @@ -982,8 +984,10 @@ nfsd->nd_md = md; nfsd->nd_dpos = dpos; error = nfs_getreq(nfsd, &tnfsd, FALSE); - if (error) + if (error) { + m_freem(mrep); return (error); + } md = nfsd->nd_md; dpos = nfsd->nd_dpos; if (nfsd->nd_procnum != NQNFSPROC_EVICTED) { Index: nfs_socket.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/nfs/nfs_socket.c,v retrieving revision 1.66 diff -u -r1.66 nfs_socket.c --- nfs_socket.c 2001/05/01 08:13:14 1.66 +++ nfs_socket.c 2001/07/20 13:45:01 @@ -144,7 +144,8 @@ */ #define NFS_CWNDSCALE 256 #define NFS_MAXCWND (NFS_CWNDSCALE * 32) -static int nfs_backoff[8] = { 2, 4, 8, 16, 32, 64, 128, 256, }; +#define NFS_NBACKOFF 8 +static int nfs_backoff[NFS_NBACKOFF] = { 2, 4, 8, 16, 32, 64, 128, 256, }; int nfsrtton = 0; struct nfsrtt nfsrtt; struct callout_handle nfs_timer_handle; @@ -299,11 +300,17 @@ splx(s); } if (nmp->nm_flag & (NFSMNT_SOFT | NFSMNT_INT)) { - so->so_rcv.sb_timeo = (5 * hz); - so->so_snd.sb_timeo = (5 * hz); + so->so_rcv.sb_timeo = (2 * hz); + so->so_snd.sb_timeo = (2 * hz); } else { - so->so_rcv.sb_timeo = 0; - so->so_snd.sb_timeo = 0; + /* + * We would normally set the timeouts to 0 (never time out) + * for non-interruptible mounts. However, nfs_nmcancelreqs() + * can still prematurely terminate requests, so avoid + * waiting forever. + */ + so->so_rcv.sb_timeo = 10 * hz; + so->so_snd.sb_timeo = 10 * hz; } /* @@ -1400,10 +1407,18 @@ for (rep = nfs_reqq.tqh_first; rep != 0; rep = rep->r_chain.tqe_next) { nmp = rep->r_nmp; if (rep->r_mrep || (rep->r_flags & R_SOFTTERM)) - continue; - if (nfs_sigintr(nmp, rep, rep->r_procp)) { - nfs_softterm(rep); continue; + /* + * Test for signals on interruptible mounts. We try to + * maintain normal (uninterruptible) semantics while the + * server is up, but respond quickly to signals when it + * is down. + */ + if (nmp->nm_timeouts >= NFS_NBACKOFF / 2) { + if (nfs_sigintr(nmp, rep, rep->r_procp)) { + nfs_softterm(rep); + continue; + } } if (rep->r_rtt >= 0) { rep->r_rtt++; @@ -1415,7 +1430,7 @@ timeo *= nfs_backoff[nmp->nm_timeouts - 1]; if (rep->r_rtt <= timeo) continue; - if (nmp->nm_timeouts < 8) + if (nmp->nm_timeouts < NFS_NBACKOFF) nmp->nm_timeouts++; } /* @@ -1438,8 +1453,6 @@ rep->r_rexmit = NFS_MAXREXMIT; continue; } - if ((so = nmp->nm_so) == NULL) - continue; /* * If there is enough space and the window allows.. @@ -1447,6 +1460,8 @@ * Set r_rtt to -1 in case we fail to send it now. */ rep->r_rtt = -1; + if ((so = nmp->nm_so) == NULL) + continue; if (sbspace(&so->so_snd) >= rep->r_mreq->m_pkthdr.len && ((nmp->nm_flag & NFSMNT_DUMBTIMR) || (rep->r_flags & R_SENT) || @@ -1510,6 +1525,27 @@ } /* + * Mark all outstanding requests pertaining to a nfs mount with R_SOFTTERM. + * This is used by forced unmounts to terminate any outstanding RPCs. + */ +void +nfs_nmcancelreqs(nmp) + struct nfsmount *nmp; +{ + struct nfsreq *req; + int s; + + s = splnet(); + for (req = nfs_reqq.tqh_first; req != 0; req = req->r_chain.tqe_next) { + if (nmp != req->r_nmp || req->r_mrep != NULL || + (req->r_flags & R_SOFTTERM)) + continue; + nfs_softterm(req); + } + splx(s); +} + +/* * Flag a request as being about to terminate (due to NFSMNT_INT/NFSMNT_SOFT). * The nm_send count is decremented now to avoid deadlocks when the process in * soreceive() hasn't yet managed to send its own request. @@ -1576,7 +1612,7 @@ } else p = (struct proc *)0; while (*statep & NFSSTA_SNDLOCK) { - if (nfs_sigintr(rep->r_nmp, rep, p)) + if (rep != NULL && (rep->r_flags & R_SOFTTERM)) return (EINTR); *statep |= NFSSTA_WANTSND; (void) tsleep((caddr_t)statep, slpflag | (PZERO - 1), @@ -1620,7 +1656,7 @@ else slpflag = 0; while (*statep & NFSSTA_RCVLOCK) { - if (nfs_sigintr(rep->r_nmp, rep, rep->r_procp)) + if (rep != NULL && (rep->r_flags & R_SOFTTERM)) return (EINTR); *statep |= NFSSTA_WANTRCV; (void) tsleep((caddr_t)statep, slpflag | (PZERO - 1), "nfsrcvlk", @@ -1638,6 +1674,9 @@ slptimeo = 2 * hz; } } + /* Always fail if our request has been cancelled. */ + if (rep != NULL && (rep->r_flags & R_SOFTTERM)) + return (EINTR); *statep |= NFSSTA_RCVLOCK; return (0); } Index: nfs_subs.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/nfs/nfs_subs.c,v retrieving revision 1.103 diff -u -r1.103 nfs_subs.c --- nfs_subs.c 2001/07/04 16:20:16 1.103 +++ nfs_subs.c 2001/07/10 21:46:16 @@ -1120,7 +1120,7 @@ nfs_true = txdr_unsigned(TRUE); nfs_false = txdr_unsigned(FALSE); nfs_xdrneg1 = txdr_unsigned(-1); - nfs_ticks = (hz * NFS_TICKINTVL + 500) / 1000; + nfs_ticks = (hz * NFS_TICKINTVL + 999) / 1000; if (nfs_ticks < 1) nfs_ticks = 1; /* Ensure async daemons disabled */ Index: nfs_vfsops.c =================================================================== RCS file: /dump/FreeBSD-CVS/src/sys/nfs/nfs_vfsops.c,v retrieving revision 1.100 diff -u -r1.100 nfs_vfsops.c --- nfs_vfsops.c 2001/06/28 04:10:07 1.100 +++ nfs_vfsops.c 2001/07/20 13:47:21 @@ -624,7 +624,7 @@ splx(s); if ((argp->flags & NFSMNT_TIMEO) && argp->timeo > 0) { - nmp->nm_timeo = (argp->timeo * NFS_HZ + 5) / 10; + nmp->nm_timeo = (argp->timeo * NFS_HZ + 9) / 10; if (nmp->nm_timeo < NFS_MINTIMEO) nmp->nm_timeo = NFS_MINTIMEO; else if (nmp->nm_timeo > NFS_MAXTIMEO) @@ -970,6 +970,10 @@ nmp->nm_state |= NFSSTA_DISMINPROG; while (nmp->nm_inprog != NULLVP) (void) tsleep((caddr_t)&lbolt, PSOCK, "nfsdism", 0); + + /* In the forced case, cancel any outstanding requests. */ + if (flags & FORCECLOSE) + nfs_nmcancelreqs(nmp); /* We hold 1 extra ref on the root vnode; see comment in mountnfs(). */ error = vflush(mp, 1, flags); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 9:48:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 49D5D37B403; Mon, 23 Jul 2001 09:48:33 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f6NGmLP17709; Mon, 23 Jul 2001 09:48:21 -0700 (PDT) (envelope-from dillon) Date: Mon, 23 Jul 2001 09:48:21 -0700 (PDT) From: Matt Dillon Message-Id: <200107231648.f6NGmLP17709@earth.backplane.com> To: Ian Dowse Cc: Maxim Sobolev , current@FreeBSD.ORG Subject: Re: NFS client unable to recover from server crash References: <200107231712.aa22684@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ian, please don't do this. The whole point of having an uninterruptable mount is so the client can survive a server reboot or network failure. Doing this destroys uninterruptable semantics. If you want to flag uninterruptable mounts in a special way when someone tries to umount them then I'm all for it. But for the general case this code is bad news. -Matt : if (nmp->nm_flag & (NFSMNT_SOFT | NFSMNT_INT)) { :- so->so_rcv.sb_timeo = (5 * hz); :- so->so_snd.sb_timeo = (5 * hz); :+ so->so_rcv.sb_timeo = (2 * hz); :+ so->so_snd.sb_timeo = (2 * hz); : } else { :- so->so_rcv.sb_timeo = 0; :- so->so_snd.sb_timeo = 0; :+ /* :+ * We would normally set the timeouts to 0 (never time out) :+ * for non-interruptible mounts. However, nfs_nmcancelreqs() :+ * can still prematurely terminate requests, so avoid :+ * waiting forever. :+ */ :+ so->so_rcv.sb_timeo = 10 * hz; :+ so->so_snd.sb_timeo = 10 * hz; : } : : /* :@@ -1400,10 +1407,18 @@ : for (rep = nfs_reqq.tqh_first; rep != 0; rep = rep->r_chain.tqe_next) { : nmp = rep->r_nmp; : if (rep->r_mrep || (rep->r_flags & R_SOFTTERM)) :- continue; :- if (nfs_sigintr(nmp, rep, rep->r_procp)) { :- nfs_softterm(rep); : continue; :+ /* :+ * Test for signals on interruptible mounts. We try to :+ * maintain normal (uninterruptible) semantics while the :+ * server is up, but respond quickly to signals when it :+ * is down. :+ */ :+ if (nmp->nm_timeouts >= NFS_NBACKOFF / 2) { :+ if (nfs_sigintr(nmp, rep, rep->r_procp)) { :+ nfs_softterm(rep); :+ continue; :+ } : } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 10:19:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from ix.rain.fr (ix.rain.fr [194.51.3.175]) by hub.freebsd.org (Postfix) with ESMTP id 5B0DB37B408 for ; Mon, 23 Jul 2001 10:19:39 -0700 (PDT) (envelope-from tfischer@rain.fr) Received: from rain.fr (localhost [127.0.0.1]) by ix.rain.fr (8.11.4/8.11.4) with ESMTP id f6NHJPs01340 for ; Mon, 23 Jul 2001 19:19:26 +0200 (CEST) (envelope-from tfischer@rain.fr) Message-ID: <3B5C5C9D.32E7E169@rain.fr> Date: Mon, 23 Jul 2001 19:19:25 +0200 From: Tom Fischer Organization: France Telecom Transpac X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: current@FreeBSD.ORG Subject: Re: Userbase of -current References: <200107212211.f6LMBAo78214@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Add a data point for me using -current on my laptop in order to take advantage of cardbus support (thanks Warner!). I update about once every two months, and so far my systems has been running flawlessly. All our other FreeBSD systems (~60) are running various incarnations of -stable... regards, tom tfischer@rain.fr Warner Losh wrote: > > In message Vincent Poy writes: > : Somehow I always thought there were more than 50 people who are > : "really running" current. We do stress test it though and it had > : performed flawlessly over the past 8 years. Question though, does anyone > : happen to know what the largest maxusers variable is that one can define > : in the kernel config file? We have it at 512 but what's the highest > : number people have used reliably? Thanks. > > I've had at least 50 different people talk to me about NEWCARD, which > is only available in current... > > Warner > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- Thomas Fischer Sr Manager: Systems & Applications Support Paris &equant - Global Service Operations - Customer Operations Support Tour Mattei - 207, rue de Bercy - 75012 Paris France Tel: +33 1 53 44 08 03 tfischer@rain.fr Fax: +33 1 53 44 08 46 thomas.c.fischer@equant.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 23 10:46:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id 09E0D37B409 for ; Mon, 23 Jul 2001 10:46:37 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f6NHkY026255 for current@FreeBSD.ORG; Mon, 23 Jul 2001 10:46:34 -0700 Date: Mon, 23 Jul 2001 10:46:34 -0700 From: Brooks Davis To: current@FreeBSD.ORG Subject: Re: installworld failures in calendar Message-ID: <20010723104634.A22052@Odin.AC.HMC.Edu> References: <20010718101806.A25453@Odin.AC.HMC.Edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010718101806.A25453@Odin.AC.HMC.Edu>; from brooks@one-eyed-alien.net on Wed, Jul 18, 2001 at 10:18:06AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 18, 2001 at 10:18:06AM -0700, Brooks Davis wrote: > I've been seeing the following failure in my installworlds for the past > week or so. I've been getting around it with make -k, but it's kinda > annoying. I've looked around some more and I think I know what's going on. The problem appears to be that we started with /usr/share/calendar/ directories of the form de_DE.ISO_8859-1. At some point symlinks were created so you could also use de_DE.ISO8859-1. With the rename of these, we have a problems. directories are created via mtree and it is set up to complain, but not fail if it encounters a link when it expects a directory (and rightly so). The problem is that you end up with a set of links like this: lrwxr-xr-x 1 root wheel 16 Jun 10 10:06 hr_HR.ISO8859-2 -> hr_HR.ISO_= 8859-2 lrwxr-xr-x 1 root wheel 15 Jun 21 01:58 hr_HR.ISO_8859-2 -> hr_HR.ISO= 8859-2 Then install barfs. The solution is to delete de_DE.ISO8859-1 and hr_HR.ISO8859-2. This may deserve an UPDATING entry. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7XGJhXY6L6fI4GtQRAt5VAJ0c62n8jp+T9K+9JXlX+BSa8QpBtgCaAuLu 0M0p4aooOBWa07U1gjQvjik= =IjiP -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 10:47:11 2001 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 DB30C37B419; Mon, 23 Jul 2001 10:46:57 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 23 Jul 2001 18:46:56 +0100 (BST) To: Matt Dillon Cc: Maxim Sobolev , current@FreeBSD.ORG Subject: Re: NFS client unable to recover from server crash In-Reply-To: Your message of "Mon, 23 Jul 2001 09:48:21 PDT." <200107231648.f6NGmLP17709@earth.backplane.com> Date: Mon, 23 Jul 2001 18:46:53 +0100 From: Ian Dowse Message-ID: <200107231846.aa35761@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200107231648.f6NGmLP17709@earth.backplane.com>, Matt Dillon writes: > Ian, please don't do this. The whole point of having an uninterruptable > mount is so the client can survive a server reboot or network failure. > Doing this destroys uninterruptable semantics. Firstly, I have no intention of committing this patch anytime soon, but I think you are mistaken in what it does. Unless I messed up, it will never allow "uninterruptible" mounts to be interrupted by signals or to time out. I set the socket timeout to 10 seconds, but that will have no effect because the code will simply loop around and retry again. It is nfs_sigintr() that detects signals, and it returns immediately unless the NFSMNT_INT mount flag is set. Similarly, the request only times out if rep->r_rexmit >= r_retry, but unless it is a "soft" nfs mount, r_rexmit is clamped at NFS_MAXREXMIT, and r_retry is set to NFS_MAXREXMIT + 1, so this can never happen. The only effect of changing that timeout value (again assuming I have not misread the code) is to allow any request that does get marked R_SOFTTERM to time out within a finite period. For hard mounts, the _only_ way that this can happen is via the new nfs_nmcancelreqs() which is called when you do a forced unmount. No, I haven't gone mad and decided to make all NFS mounts soft to "fix" all NFS problems :-) Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 10:50: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id E2D7D37B408; Mon, 23 Jul 2001 10:49:54 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (mjacob@wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f6NHnlI49596; Mon, 23 Jul 2001 10:49:47 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Mon, 23 Jul 2001 10:49:46 -0700 (PDT) From: Matthew Jacob Reply-To: To: Ian Dowse Cc: Matt Dillon , Maxim Sobolev , Subject: Re: NFS client unable to recover from server crash In-Reply-To: <200107231846.aa35761@salmon.maths.tcd.ie> Message-ID: <20010723104841.S694-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > No, I haven't gone mad and decided to make all NFS mounts soft > to "fix" all NFS problems :-) > I once asked Bob Lyon (who is still at Legato) about what he thought needed to happen to 'fix' NFS (after all, it was he and Rusty Sandberg who did the initial work on all this). His response was, "Fix? You mean as in 'fixing' a cat?" -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 11: 3:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 7B2C837B401 for ; Mon, 23 Jul 2001 11:03:38 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.4/8.11.2) with ESMTP id f6NI2qv99392; Mon, 23 Jul 2001 11:02:52 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3B5BD998.3E8A6E7E@elischer.org> Date: Mon, 23 Jul 2001 11:02:57 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: RE: mutex blocking queues.. Cc: current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 23-Jul-01 Julian Elischer wrote: > Why does the mutex not link blocked processes though the > sleep queue linked list entry? Why does it use the run queue entry? > In KSEs the sleep queue and run queue enties go into different > sub structures and ahve different types so this breaks... > do I need to do something sleazy or can I just link them together using the > equivalemt of the p_slpq entry? You can block on a mutex when processing signals in the catch case in msleep() after you have put the process on the sleep queue: int msleep(ident, mtx, priority, wmesg, timo) { ... p->p_wchan = ident; p->p_wmesg = wmesg; p->p_slptime = 0; p->p_pri.pri_level = priority & PRIMASK; CTR5(KTR_PROC, "msleep: proc %p (pid %d, %s) on %s (%p)", p, p->p_pid, p->p_comm, wmesg, ident); TAILQ_INSERT_TAIL(&slpque[LOOKUP(ident)], p, p_slpq); ... /* * We put ourselves on the sleep queue and start our timeout * before calling CURSIG, as we could stop there, and a wakeup * or a SIGCONT (or both) could occur while we were stopped. * A SIGCONT would cause us to be marked as SSLEEP * without resuming us, thus we must be ready for sleep * when CURSIG is called. If the wakeup happens while we're * stopped, p->p_wchan will be 0 upon return from CURSIG. */ if (catch) { CTR3(KTR_PROC, "msleep caught: proc %p (pid %d, %s)", p, p->p_pid, p->p_comm); p->p_sflag |= PS_SINTR; mtx_unlock_spin(&sched_lock); PROC_LOCK(p); sig = CURSIG(p); mtx_lock_spin(&sched_lock); PROC_UNLOCK_NOSWITCH(p); ... If that proc_lock blocks then we don't want to clobber the sleep queue. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 12: 8:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id C9A8E37B439 for ; Mon, 23 Jul 2001 12:08:25 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.4/8.11.2) with ESMTP id f6NJ7hv00689; Mon, 23 Jul 2001 12:07:43 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200107221011.MAA01533@midten.fast.no> Date: Mon, 23 Jul 2001 12:07:48 -0700 (PDT) From: John Baldwin To: Tor.Egge@fast.no Subject: Re: Interruptable hang starting init in today's -CURRENT Cc: current@FreeBSD.org, david@catwhisker.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 22-Jul-01 Tor.Egge@fast.no wrote: > >> Interestingly, "sysctl -a -N" spits out names, but then seems to fall >> into a rut: >> > [....] >> net.inet.udp.getcred >> net.inet.accf.unloadable >> net.inet.accf.373 >> net.inet.accf.373 >> net.inet.accf.373 > [....] > >> Looks as if it's looping with no termination conditions being matched. > > When I got the same problem on my -current machine today, I found that > net.inet.accf and net.inet.raw had the same oid. Evil. > The system booted normally after changing the start oid for > dynamically assigned sysctl entries from 100 to 256. Hmm, perhaps net.inet.* should be using OID_AUTO instead? *shrug* > - Tor Egge -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 13:15:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by hub.freebsd.org (Postfix) with ESMTP id 2FCAC37B406 for ; Mon, 23 Jul 2001 13:15:26 -0700 (PDT) (envelope-from jcm@freebsd-uk.eu.org) Received: from dogma.freebsd-uk.eu.org ([130.88.200.97] ident=root) by probity.mcc.ac.uk with esmtp (Exim 2.05 #7) id 15Om6u-0003aL-00 for freebsd-current@freebsd.org; Mon, 23 Jul 2001 21:15:24 +0100 Received: (from jcm@localhost) by dogma.freebsd-uk.eu.org (8.11.3/8.11.1) id f6NKFNk56595 for freebsd-current@freebsd.org; Mon, 23 Jul 2001 21:15:23 +0100 (BST) (envelope-from jcm) Date: Mon, 23 Jul 2001 21:15:23 +0100 From: j mckitrick To: freebsd-current@freebsd.org Subject: any problems with parallel port zip drives? Message-ID: <20010723211522.A56537@dogma.freebsd-uk.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Some commits have been in the tree for a month now, and I'm wondering if anyone has had any problem. Please let me know if you have had any timeouts, mode recognition problems, or anything similar. It would be nice to get the commits moved into -stable if everything is working well, especially since 4.4 will be coming up soon. jcm -- o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o | ~~~~~~~~~~~~ Jonathon McKitrick ~~~~~~~~~~~~~ | | "I prefer the term 'Artificial Person' myself." | o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 14:58:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 1E2E437B406; Mon, 23 Jul 2001 14:58:24 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f6NLwCx22117; Mon, 23 Jul 2001 14:58:12 -0700 (PDT) (envelope-from dillon) Date: Mon, 23 Jul 2001 14:58:12 -0700 (PDT) From: Matt Dillon Message-Id: <200107232158.f6NLwCx22117@earth.backplane.com> To: Ian Dowse Cc: Maxim Sobolev , current@FreeBSD.ORG Subject: Re: NFS client unable to recover from server crash References: <200107231846.aa35761@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :Firstly, I have no intention of committing this patch anytime soon, :but I think you are mistaken in what it does. Unless I messed up, :it will never allow "uninterruptible" mounts to be interrupted by Oops, sorry about that. Today is not one of my better days. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 15:13:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 3740B37B405 for ; Mon, 23 Jul 2001 15:13:01 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f6NMCwU52405; Mon, 23 Jul 2001 15:12:58 -0700 (PDT) (envelope-from obrien) Date: Mon, 23 Jul 2001 15:12:58 -0700 From: "David O'Brien" To: Julian Elischer Cc: current@freebsd.org Subject: Re: Progress report: KSEs. Message-ID: <20010723151258.A52202@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <3B5BD579.400FE65E@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5BD579.400FE65E@elischer.org>; from julian@elischer.org on Mon, Jul 23, 2001 at 12:42:49AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jul 23, 2001 at 12:42:49AM -0700, Julian Elischer wrote: > step 1: get proc structure broken up, with system still running: done (twice) Can you post your diff to the proc structure? ... > -random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct proc *p) > +random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct thread *td) This implies `struct thread' has replaced `struct proc'. (I could be wrong, but cannot be sure until you post the `struct proc' and related structure changes/additions) There is no `struct thread' in Jason's KSE paper. Why aren't you following the paper http://people.freebsd.org/~jasone/refs/freebsd_kse/freebsd_kse.html? -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 23 20:10:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from gate.lustig.com (lustig.ne.mediaone.net [24.91.125.166]) by hub.freebsd.org (Postfix) with SMTP id 3122037B401 for ; Mon, 23 Jul 2001 20:10:07 -0700 (PDT) (envelope-from barry@lustig.com) Received: (qmail 37162 invoked from network); 24 Jul 2001 03:10:04 -0000 Received: from gate.lustig.com (HELO lustig.com) (barry@205.246.2.242) by gate.lustig.com with SMTP; 24 Jul 2001 03:10:04 -0000 Message-ID: <3B5CE70C.219DD05C@lustig.com> Date: Mon, 23 Jul 2001 23:10:04 -0400 From: Barry Lustig Organization: Barry Lustig & Associates, Inc. X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org, emulation@freebsd.org Subject: vmware hanging Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Vmware has started hanging on current versions of current. The binary start properly, but when I try and start one of my virtual machines the process hangs in "devbuf". The disk seems to access periodically. I tried ktracing the process but it didn't get very far. Has anyone seen this behavior? I'm going to start cvsupping older version of current to see if I can track down when the problem started occuring. barry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 4: 0:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by hub.freebsd.org (Postfix) with ESMTP id 1FC7B37B405 for ; Tue, 24 Jul 2001 04:00:51 -0700 (PDT) (envelope-from ) Received: from bruno (213-44-199-16.rsv.club-internet.fr [213.44.199.16]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id NAA04564 for ; Tue, 24 Jul 2001 13:00:43 +0200 (MET DST) Message-Id: <200107241100.NAA04564@front4.grolier.fr> Reply-To: "Sea-River" <> From: "Sea-River" <> To: "" Organization: X-Priority: 3 X-MSMail-Priority: Normal Subject: Sea-River Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 24 Jul 2001 12:59:08 +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Untitled Document

Bonjour, vous aimez la pêche et le milieu aquatique ?
Hi, you like the fishing and the environment ?

Gratuit, chaque semaine en français : La Lettre de Sea-River

Gratuit, chaque mois : La Lettre européenne de Sea-River

Free, every month : The Sea-River's European Letter

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 4:58:41 2001 Delivered-To: freebsd-current@freebsd.org Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (Postfix) with ESMTP id 5A52837B40C for ; Tue, 24 Jul 2001 04:58:15 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from nantai.utsunomiya-u.ac.jp by nasu.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/26Jan01-1134AM) id f6OBw5c310891; Tue, 24 Jul 2001 20:58:05 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp by nantai.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/30Jan01-0241PM) id f6OBw5l133713; Tue, 24 Jul 2001 20:58:05 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:SN2r3VE+GcMu/4Bwg25nng77WxV/5mpF@zodiac.mech.utsunomiya-u.ac.jp [160.12.43.7]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id VAA14339; Tue, 24 Jul 2001 21:07:41 +0900 (JST) Message-Id: <200107241207.VAA14339@zodiac.mech.utsunomiya-u.ac.jp> To: freebsd-current@freebsd.org Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Death sentence to KLD screen savers? Comments? Date: Tue, 24 Jul 2001 21:07:40 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is to propose to abolish KLD screen saver modules. KLD screen savers have the following problems/deficiencies. - It is too easy to abuse the power of being run in the kernel mode. The screen saver is invoked periodically once the console becomes idle. It should not spend long time to draw something to the screen. But, we may be tempted to do a bit more elaborate drawing so that we get "interesting" effects. It's too easy to degrade the system performance by staying in the screen saver too long. - While it is easy to manipulate the video board in the KLD module (because we can go anywhere and access anything :-), there are limitations. If you want to perform file I/O (to obtain some bitmaps from files), or want to read some sort of configuration file, there is no straight forward way to do so. I propose to have user-land screen savers instead of KLD screen savers. - The user-land screen saver won't degrade system performance. We can run it at lower priority. Even if we write very complicated graphical screen saver, we have no fear of breaking the system. (Unless we write a buggy program which directly manipulates video card hardware...) - The user-land screen saver can access files if necessary. We shall provide the "screen saver daemon" and a set of "screen saver programs." The screen saver daemon will run in the background and periodically checks if the console is idle. When it finds no activity in the console, it will launch a specified "screen saver program." Screen saver programs are ordinaly user programs which act just like our current KLD screen savers, such as daemon_saver, log_saver, blank_saver, etc, which draw something interesting in the screen. The text-mode screen savers (deamon_saver, snake_saver, star_saver) are written by using ncurses. The graphics-mode screen savers (logo_saver, warp_saver, fire_saver, rain_saver) will be written with libvgl. Blank_saver, apm_saver, fade_saver and green_saver are replaced by programs which performs ioctl to the console to implement the same effect as the current KLD version. I will publish sample implementation once VESA support in -CURRENT stabilizes. Any comments? Kazu PS: the splash screen support has to remain in syscons as the splash screen is put up when the kernel starts up... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 5: 8:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id 16B5037B406 for ; Tue, 24 Jul 2001 05:08:41 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.4/8.11.4) id f6OC8UK10792; Tue, 24 Jul 2001 16:08:30 +0400 (MSD) (envelope-from ache) Date: Tue, 24 Jul 2001 16:08:25 +0400 From: "Andrey A. Chernov" To: Kazutaka YOKOTA Cc: freebsd-current@FreeBSD.ORG Subject: Re: Death sentence to KLD screen savers? Comments? Message-ID: <20010724160822.B10585@nagual.pp.ru> References: <200107241207.VAA14339@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200107241207.VAA14339@zodiac.mech.utsunomiya-u.ac.jp> User-Agent: Mutt/1.3.19i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 24, 2001 at 21:07:40 +0900, Kazutaka YOKOTA wrote: > I propose to have user-land screen savers instead of KLD > screen savers. Good idea. > We shall provide the "screen saver daemon" and a set of "screen saver > programs." The screen saver daemon will run in the background and > periodically checks if the console is idle. When it finds no > activity in the console, it will launch a specified "screen saver > program." No "periodical checks" please. It must wait on poll/select or kqevent or something like, event based, event provided by syscons. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 5:25:23 2001 Delivered-To: freebsd-current@freebsd.org Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (Postfix) with ESMTP id A76F037B407 for ; Tue, 24 Jul 2001 05:25:19 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from nantai.utsunomiya-u.ac.jp by nasu.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/26Jan01-1134AM) id f6OCP5c311653; Tue, 24 Jul 2001 21:25:05 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp by nantai.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/30Jan01-0241PM) id f6OCP5l135065; Tue, 24 Jul 2001 21:25:05 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:LZapKBMRjpVrajD/IwZcNf3l7pYqhuTH@zodiac.mech.utsunomiya-u.ac.jp [160.12.43.7]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id VAA14547; Tue, 24 Jul 2001 21:34:41 +0900 (JST) Message-Id: <200107241234.VAA14547@zodiac.mech.utsunomiya-u.ac.jp> To: "Andrey A. Chernov" Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Death sentence to KLD screen savers? Comments? In-reply-to: Your message of "Tue, 24 Jul 2001 16:08:25 +0400." <20010724160822.B10585@nagual.pp.ru> References: <200107241207.VAA14339@zodiac.mech.utsunomiya-u.ac.jp> <20010724160822.B10585@nagual.pp.ru> Date: Tue, 24 Jul 2001 21:34:40 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >> We shall provide the "screen saver daemon" and a set of "screen saver >> programs." The screen saver daemon will run in the background and >> periodically checks if the console is idle. When it finds no >> activity in the console, it will launch a specified "screen saver >> program." > >No "periodical checks" please. It must wait on poll/select or kqevent or >something like, event based, event provided by syscons. Because there already is the CONS_IDLE ioctl, I thought it's easy for the screen saver daemon to use this ioctl. But, if kqevent is preferred, we can do that. 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 24 5:38:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from nagual.pp.ru (pobrecita.freebsd.ru [194.87.13.42]) by hub.freebsd.org (Postfix) with ESMTP id A1E8A37B401 for ; Tue, 24 Jul 2001 05:38:23 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.11.4/8.11.4) id f6OCcFX11278; Tue, 24 Jul 2001 16:38:15 +0400 (MSD) (envelope-from ache) Date: Tue, 24 Jul 2001 16:38:13 +0400 From: "Andrey A. Chernov" To: Kazutaka YOKOTA Cc: freebsd-current@freebsd.org Subject: Re: Death sentence to KLD screen savers? Comments? Message-ID: <20010724163811.B11093@nagual.pp.ru> References: <200107241207.VAA14339@zodiac.mech.utsunomiya-u.ac.jp> <20010724160822.B10585@nagual.pp.ru> <200107241234.VAA14547@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200107241234.VAA14547@zodiac.mech.utsunomiya-u.ac.jp> User-Agent: Mutt/1.3.19i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 24, 2001 at 21:34:40 +0900, Kazutaka YOKOTA wrote: > > >> We shall provide the "screen saver daemon" and a set of "screen saver > >> programs." The screen saver daemon will run in the background and > >> periodically checks if the console is idle. When it finds no > >> activity in the console, it will launch a specified "screen saver > >> program." > > > >No "periodical checks" please. It must wait on poll/select or kqevent or > >something like, event based, event provided by syscons. > > Because there already is the CONS_IDLE ioctl, I thought it's > easy for the screen saver daemon to use this ioctl. But, if > kqevent is preferred, we can do that. Maybe I am not clear, but periodical checks is time/resources waste. Sleeping on event wait, swapped out is more preferred, not occupes memory, etc. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 8:17:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from kalaid.f2f.com.ua (kalaid.f2f.com.ua [62.149.0.33]) by hub.freebsd.org (Postfix) with ESMTP id 75B3137B40E for ; Tue, 24 Jul 2001 08:14:27 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from mail.uic-in.net (root@[212.35.189.4]) by kalaid.f2f.com.ua (8.11.4/8.11.4) with ESMTP id f6OFFkG00786; Tue, 24 Jul 2001 18:15:46 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from vega.vega.com (root@das0-l82.uic-in.net [212.35.189.209]) by mail.uic-in.net (8.11.4/8.11.4) with ESMTP id f6OE4nt22518; Tue, 24 Jul 2001 17:04:50 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.4/8.11.3) with ESMTP id f6ODlHD72441; Tue, 24 Jul 2001 16:47:17 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3B5D7C80.AFDE3D37@FreeBSD.org> Date: Tue, 24 Jul 2001 16:47:44 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: Ian Dowse Cc: current@FreeBSD.org Subject: Re: NFS client unable to recover from server crash References: <200107231712.aa22684@salmon.maths.tcd.ie> Content-Type: multipart/mixed; boundary="------------B4700A746126E4C5FBEBD274" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------B4700A746126E4C5FBEBD274 Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Ian Dowse wrote: > In message <200107231554.f6NFsLk65848@vega.vega.com>, Maxim Sobolev writes: > >I found that after introduction of the new RPC NFS client is no longer > >able to recover from server crash (both cluent and server are 5-CURRENT > >systems). After a well known `nfs server not responding' message, client > >hangs and even though server comes back in a minute or two it doesn't > >recover and just sits in this state forvewer. All unmount requests gets > >stuck in the kernel, so as a processes that accessing files from that > >mount point. This doesn't looks like a right thing and obviously should > >be fixed before 5.0-RELEASE. > > I've seen some similar effects, but I don't think it has anything > to do with the new RPC code, as that only runs at mount time. It > would be useful if you could use tcpdump to see if any requests > are being transmitted, and if they are getting responses. Also > try running kdgb on the client to get a kernel backtrace of the > stuck processes. Attached please find IP log of typical hanged session. Machines are using the following addresses: 192.168.1.1: NFS server (5-CURRENT) 192.168.1.100: NFS client (5-CURRENT) 192.168.1.50: machine on which tcpdump(8) runs (4-STABLE) 192.168.1.9: ignore this ;) > Is this a UDP or TCP based mount? TCP, I guess. All nfsd(8) options in rc.conf are at their default values and mount_nfs invoked w/o any options as well. > If you are feeling brave, you could also try the patch below. It > is a selection of changes to the kernel NFS code that I have built > up over the last few months. I don't think it could solve the hangs, > but it should improve the chance of interruptible mounts accepting > ^C while waiting, and (just added the other day) umount -f should > work while the server is down even if processes are hung. Could you please look at the attached logs first, maybe it will give you some idea about what's going on here. Thank you! -Maxim --------------B4700A746126E4C5FBEBD274 Content-Type: text/plain; charset=x-user-defined; name="tcplog" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcplog" 16:19:48.499163 192.168.1.100.1005 > 192.168.1.1.111: udp 56 16:19:48.499795 192.168.1.1.111 > 192.168.1.100.1005: udp 28 16:19:48.500973 192.168.1.100.995405925 > 192.168.1.1.2049: 40 null 16:19:48.501182 192.168.1.1.2049 > 192.168.1.100.995405925: reply ok 24 null 16:19:48.502367 192.168.1.100.1003 > 192.168.1.1.111: udp 56 16:19:48.502903 192.168.1.1.111 > 192.168.1.100.1003: udp 28 16:19:48.504286 192.168.1.100.1002 > 192.168.1.1.1021: udp 108 16:19:48.504967 192.168.1.1.1021 > 192.168.1.100.1002: udp 68 16:19:48.507462 192.168.1.100.570982210 > 192.168.1.1.2049: 124 access [|nfs] 16:19:48.507823 192.168.1.1.2049 > 192.168.1.100.570982210: reply ok 120 access c 22087f43 16:19:48.545550 192.168.1.100.570982211 > 192.168.1.1.2049: 92 fsinfo [|nfs] 16:19:48.545923 192.168.1.1.2049 > 192.168.1.100.570982211: reply ok 164 fsinfo [|nfs] 16:19:48.546506 192.168.1.100.570982212 > 192.168.1.1.2049: 92 fsstat [|nfs] 16:19:48.546869 192.168.1.1.2049 > 192.168.1.100.570982212: reply ok 168 fsstat [|nfs] 16:19:48.552783 192.168.1.100.570982213 > 192.168.1.1.2049: 92 fsstat [|nfs] 16:19:48.553173 192.168.1.1.2049 > 192.168.1.100.570982213: reply ok 168 fsstat [|nfs] 16:19:57.840921 192.168.1.100.570982214 > 192.168.1.1.2049: 124 access [|nfs] 16:19:57.841260 192.168.1.1.2049 > 192.168.1.100.570982214: reply ok 120 access c 22087f47 16:19:57.841952 192.168.1.100.570982215 > 192.168.1.1.2049: 120 fsstat [|nfs] 16:19:57.842314 192.168.1.1.2049 > 192.168.1.100.570982215: reply ok 168 fsstat [|nfs] 16:19:57.843095 192.168.1.100.570982216 > 192.168.1.1.2049: 140 readdir [|nfs] 16:19:57.843602 192.168.1.1.2049 > 192.168.1.100.570982216: reply ok 220 readdir 16:19:57.844668 192.168.1.100.570982217 > 192.168.1.1.2049: 132 lookup [|nfs] 16:19:57.845138 192.168.1.1.2049 > 192.168.1.100.570982217: reply ok 236 lookup [|nfs] 16:20:02.658732 192.168.1.100.570982218 > 192.168.1.1.2049: 124 access [|nfs] 16:20:02.659069 192.168.1.1.2049 > 192.168.1.100.570982218: reply ok 120 access c 22087f4b 16:20:02.659787 192.168.1.100.570982219 > 192.168.1.1.2049: 124 access [|nfs] 16:20:02.660088 192.168.1.1.2049 > 192.168.1.100.570982219: reply ok 120 access c 22087f4c 16:20:02.660841 192.168.1.100.570982220 > 192.168.1.1.2049: 132 read [|nfs] 16:20:02.662769 192.168.1.1.2049 > 192.168.1.100.570982220: reply ok 1472 read (frag 3996:1480@0+) 16:20:02.663996 192.168.1.1 > 192.168.1.100: (frag 3996:1480@1480+) 16:20:02.665240 192.168.1.1 > 192.168.1.100: (frag 3996:1480@2960+) 16:20:02.666480 192.168.1.1 > 192.168.1.100: (frag 3996:1480@4440+) 16:20:02.666871 192.168.1.1 > 192.168.1.100: (frag 3996:572@5920) 16:20:02.669625 192.168.1.100.570982221 > 192.168.1.1.2049: 132 read [|nfs] 16:20:02.671544 192.168.1.1.2049 > 192.168.1.100.570982221: reply ok 1472 read (frag 3997:1480@0+) 16:20:02.672786 192.168.1.1 > 192.168.1.100: (frag 3997:1480@1480+) 16:20:02.674024 192.168.1.1 > 192.168.1.100: (frag 3997:1480@2960+) 16:20:02.675264 192.168.1.1 > 192.168.1.100: (frag 3997:1480@4440+) 16:20:02.676506 192.168.1.1 > 192.168.1.100: (frag 3997:1480@5920+) 16:20:02.677226 192.168.1.1 > 192.168.1.100: (frag 3997:928@7400) 16:20:03.061821 192.168.1.100.570982222 > 192.168.1.1.2049: 132 read [|nfs] 16:20:03.063784 192.168.1.1.2049 > 192.168.1.100.570982222: reply ok 1472 read (frag 3998:1480@0+) 16:20:03.065021 192.168.1.1 > 192.168.1.100: (frag 3998:1480@1480+) 16:20:03.066260 192.168.1.1 > 192.168.1.100: (frag 3998:1480@2960+) 16:20:03.067501 192.168.1.1 > 192.168.1.100: (frag 3998:1480@4440+) 16:20:03.068740 192.168.1.1 > 192.168.1.100: (frag 3998:1480@5920+) 16:20:03.069462 192.168.1.1 > 192.168.1.100: (frag 3998:928@7400) 16:20:03.279673 192.168.1.100.570982223 > 192.168.1.1.2049: 132 read [|nfs] 16:20:03.281580 192.168.1.1.2049 > 192.168.1.100.570982223: reply ok 1472 read (frag 3999:1480@0+) 16:20:03.282826 192.168.1.1 > 192.168.1.100: (frag 3999:1480@1480+) 16:20:03.284061 192.168.1.1 > 192.168.1.100: (frag 3999:1480@2960+) 16:20:03.285300 192.168.1.1 > 192.168.1.100: (frag 3999:1480@4440+) 16:20:03.286540 192.168.1.1 > 192.168.1.100: (frag 3999:1480@5920+) 16:20:03.287263 192.168.1.1 > 192.168.1.100: (frag 3999:928@7400) 16:20:03.662599 192.168.1.100.570982224 > 192.168.1.1.2049: 132 read [|nfs] 16:20:03.664578 192.168.1.1.2049 > 192.168.1.100.570982224: reply ok 1472 read (frag 4001:1480@0+) 16:20:03.665810 192.168.1.1 > 192.168.1.100: (frag 4001:1480@1480+) 16:20:03.667049 192.168.1.1 > 192.168.1.100: (frag 4001:1480@2960+) 16:20:03.668302 192.168.1.1 > 192.168.1.100: (frag 4001:1480@4440+) 16:20:03.669527 192.168.1.1 > 192.168.1.100: (frag 4001:1480@5920+) 16:20:03.670249 192.168.1.1 > 192.168.1.100: (frag 4001:928@7400) 16:20:04.184719 192.168.1.100.570982225 > 192.168.1.1.2049: 132 read [|nfs] 16:20:04.186684 192.168.1.1.2049 > 192.168.1.100.570982225: reply ok 1472 read (frag 4003:1480@0+) 16:20:04.187917 192.168.1.1 > 192.168.1.100: (frag 4003:1480@1480+) 16:20:04.189157 192.168.1.1 > 192.168.1.100: (frag 4003:1480@2960+) 16:20:04.190394 192.168.1.1 > 192.168.1.100: (frag 4003:1480@4440+) 16:20:04.191632 192.168.1.1 > 192.168.1.100: (frag 4003:1480@5920+) 16:20:04.192355 192.168.1.1 > 192.168.1.100: (frag 4003:928@7400) 16:20:04.683666 192.168.1.100.570982226 > 192.168.1.1.2049: 132 read [|nfs] 16:20:04.685646 192.168.1.1.2049 > 192.168.1.100.570982226: reply ok 1472 read (frag 4004:1480@0+) 16:20:04.686874 192.168.1.1 > 192.168.1.100: (frag 4004:1480@1480+) 16:20:04.688112 192.168.1.1 > 192.168.1.100: (frag 4004:1480@2960+) 16:20:04.689351 192.168.1.1 > 192.168.1.100: (frag 4004:1480@4440+) 16:20:04.690589 192.168.1.1 > 192.168.1.100: (frag 4004:1480@5920+) 16:20:04.691311 192.168.1.1 > 192.168.1.100: (frag 4004:928@7400) 16:20:05.205775 192.168.1.100.570982227 > 192.168.1.1.2049: 132 read [|nfs] 16:20:05.207743 192.168.1.1.2049 > 192.168.1.100.570982227: reply ok 1472 read (frag 4007:1480@0+) 16:20:05.208982 192.168.1.1 > 192.168.1.100: (frag 4007:1480@1480+) 16:20:05.210219 192.168.1.1 > 192.168.1.100: (frag 4007:1480@2960+) 16:20:05.211460 192.168.1.1 > 192.168.1.100: (frag 4007:1480@4440+) 16:20:05.212695 192.168.1.1 > 192.168.1.100: (frag 4007:1480@5920+) 16:20:05.213417 192.168.1.1 > 192.168.1.100: (frag 4007:928@7400) 16:20:05.727924 192.168.1.100.570982228 > 192.168.1.1.2049: 132 read [|nfs] 16:20:05.729898 192.168.1.1.2049 > 192.168.1.100.570982228: reply ok 1472 read (frag 4009:1480@0+) 16:20:05.731140 192.168.1.1 > 192.168.1.100: (frag 4009:1480@1480+) 16:20:05.732372 192.168.1.1 > 192.168.1.100: (frag 4009:1480@2960+) 16:20:05.733627 192.168.1.1 > 192.168.1.100: (frag 4009:1480@4440+) 16:20:05.734867 192.168.1.1 > 192.168.1.100: (frag 4009:1480@5920+) 16:20:05.735596 192.168.1.1 > 192.168.1.100: (frag 4009:928@7400) 16:20:06.215235 192.168.1.100.570982229 > 192.168.1.1.2049: 132 read [|nfs] 16:20:06.217180 192.168.1.1.2049 > 192.168.1.100.570982229: reply ok 1472 read (frag 4011:1480@0+) 16:20:06.218417 192.168.1.1 > 192.168.1.100: (frag 4011:1480@1480+) 16:20:06.219655 192.168.1.1 > 192.168.1.100: (frag 4011:1480@2960+) 16:20:06.220893 192.168.1.1 > 192.168.1.100: (frag 4011:1480@4440+) 16:20:06.222131 192.168.1.1 > 192.168.1.100: (frag 4011:1480@5920+) 16:20:06.222854 192.168.1.1 > 192.168.1.100: (frag 4011:928@7400) 16:20:06.737395 192.168.1.100.570982230 > 192.168.1.1.2049: 132 read [|nfs] 16:20:06.739366 192.168.1.1.2049 > 192.168.1.100.570982230: reply ok 1472 read (frag 4013:1480@0+) 16:20:06.740602 192.168.1.1 > 192.168.1.100: (frag 4013:1480@1480+) 16:20:06.741844 192.168.1.1 > 192.168.1.100: (frag 4013:1480@2960+) 16:20:06.743077 192.168.1.1 > 192.168.1.100: (frag 4013:1480@4440+) 16:20:06.744315 192.168.1.1 > 192.168.1.100: (frag 4013:1480@5920+) 16:20:06.745039 192.168.1.1 > 192.168.1.100: (frag 4013:928@7400) 16:20:07.236303 192.168.1.100.570982231 > 192.168.1.1.2049: 132 read [|nfs] 16:20:07.238260 192.168.1.1.2049 > 192.168.1.100.570982231: reply ok 1472 read (frag 4015:1480@0+) 16:20:07.239495 192.168.1.1 > 192.168.1.100: (frag 4015:1480@1480+) 16:20:07.240733 192.168.1.1 > 192.168.1.100: (frag 4015:1480@2960+) 16:20:07.241971 192.168.1.1 > 192.168.1.100: (frag 4015:1480@4440+) 16:20:07.243209 192.168.1.1 > 192.168.1.100: (frag 4015:1480@5920+) 16:20:07.243934 192.168.1.1 > 192.168.1.100: (frag 4015:928@7400) 16:20:07.758460 192.168.1.100.570982232 > 192.168.1.1.2049: 132 read [|nfs] 16:20:07.760419 192.168.1.1.2049 > 192.168.1.100.570982232: reply ok 1472 read (frag 4017:1480@0+) 16:20:07.761656 192.168.1.1 > 192.168.1.100: (frag 4017:1480@1480+) 16:20:07.762894 192.168.1.1 > 192.168.1.100: (frag 4017:1480@2960+) 16:20:07.764131 192.168.1.1 > 192.168.1.100: (frag 4017:1480@4440+) 16:20:07.765372 192.168.1.1 > 192.168.1.100: (frag 4017:1480@5920+) 16:20:07.766096 192.168.1.1 > 192.168.1.100: (frag 4017:928@7400) 16:20:08.280622 192.168.1.100.570982233 > 192.168.1.1.2049: 132 read [|nfs] 16:20:08.282568 192.168.1.1.2049 > 192.168.1.100.570982233: reply ok 1472 read (frag 4019:1480@0+) 16:20:08.283807 192.168.1.1 > 192.168.1.100: (frag 4019:1480@1480+) 16:20:08.285043 192.168.1.1 > 192.168.1.100: (frag 4019:1480@2960+) 16:20:08.286281 192.168.1.1 > 192.168.1.100: (frag 4019:1480@4440+) 16:20:08.287520 192.168.1.1 > 192.168.1.100: (frag 4019:1480@5920+) 16:20:08.288244 192.168.1.1 > 192.168.1.100: (frag 4019:928@7400) 16:20:08.779526 192.168.1.100.570982234 > 192.168.1.1.2049: 132 read [|nfs] 16:20:08.781487 192.168.1.1.2049 > 192.168.1.100.570982234: reply ok 1472 read (frag 4021:1480@0+) 16:20:08.782724 192.168.1.1 > 192.168.1.100: (frag 4021:1480@1480+) 16:20:08.783962 192.168.1.1 > 192.168.1.100: (frag 4021:1480@2960+) 16:20:08.785202 192.168.1.1 > 192.168.1.100: (frag 4021:1480@4440+) 16:20:08.786444 192.168.1.1 > 192.168.1.100: (frag 4021:1480@5920+) 16:20:08.787164 192.168.1.1 > 192.168.1.100: (frag 4021:928@7400) 16:20:09.301684 192.168.1.100.570982235 > 192.168.1.1.2049: 132 read [|nfs] 16:20:09.303614 192.168.1.1.2049 > 192.168.1.100.570982235: reply ok 1472 read (frag 4023:1480@0+) 16:20:09.304849 192.168.1.1 > 192.168.1.100: (frag 4023:1480@1480+) 16:20:09.306090 192.168.1.1 > 192.168.1.100: (frag 4023:1480@2960+) 16:20:09.307328 192.168.1.1 > 192.168.1.100: (frag 4023:1480@4440+) 16:20:09.308566 192.168.1.1 > 192.168.1.100: (frag 4023:1480@5920+) 16:20:09.309298 192.168.1.1 > 192.168.1.100: (frag 4023:928@7400) 16:20:09.800611 192.168.1.100.570982236 > 192.168.1.1.2049: 132 read [|nfs] 16:20:09.802577 192.168.1.1.2049 > 192.168.1.100.570982236: reply ok 1472 read (frag 4025:1480@0+) 16:20:09.803818 192.168.1.1 > 192.168.1.100: (frag 4025:1480@1480+) 16:20:09.805054 192.168.1.1 > 192.168.1.100: (frag 4025:1480@2960+) 16:20:09.806294 192.168.1.1 > 192.168.1.100: (frag 4025:1480@4440+) 16:20:09.807532 192.168.1.1 > 192.168.1.100: (frag 4025:1480@5920+) 16:20:09.808256 192.168.1.1 > 192.168.1.100: (frag 4025:928@7400) 16:20:10.322727 192.168.1.100.570982237 > 192.168.1.1.2049: 132 read [|nfs] 16:20:10.324673 192.168.1.1.2049 > 192.168.1.100.570982237: reply ok 1472 read (frag 4027:1480@0+) 16:20:10.325909 192.168.1.1 > 192.168.1.100: (frag 4027:1480@1480+) 16:20:10.327148 192.168.1.1 > 192.168.1.100: (frag 4027:1480@2960+) 16:20:10.328390 192.168.1.1 > 192.168.1.100: (frag 4027:1480@4440+) 16:20:10.329626 192.168.1.1 > 192.168.1.100: (frag 4027:1480@5920+) 16:20:10.330348 192.168.1.1 > 192.168.1.100: (frag 4027:928@7400) 16:20:10.844881 192.168.1.100.570982238 > 192.168.1.1.2049: 132 read [|nfs] 16:20:10.846826 192.168.1.1.2049 > 192.168.1.100.570982238: reply ok 1472 read (frag 4030:1480@0+) 16:20:10.848065 192.168.1.1 > 192.168.1.100: (frag 4030:1480@1480+) 16:20:10.849305 192.168.1.1 > 192.168.1.100: (frag 4030:1480@2960+) 16:20:10.850542 192.168.1.1 > 192.168.1.100: (frag 4030:1480@4440+) 16:20:10.851781 192.168.1.1 > 192.168.1.100: (frag 4030:1480@5920+) 16:20:10.852503 192.168.1.1 > 192.168.1.100: (frag 4030:928@7400) 16:20:11.332183 192.168.1.100.570982239 > 192.168.1.1.2049: 132 read [|nfs] 16:20:11.334119 192.168.1.1.2049 > 192.168.1.100.570982239: reply ok 1472 read (frag 4031:1480@0+) 16:20:11.335357 192.168.1.1 > 192.168.1.100: (frag 4031:1480@1480+) 16:20:11.336595 192.168.1.1 > 192.168.1.100: (frag 4031:1480@2960+) 16:20:11.337834 192.168.1.1 > 192.168.1.100: (frag 4031:1480@4440+) 16:20:11.339072 192.168.1.1 > 192.168.1.100: (frag 4031:1480@5920+) 16:20:11.339794 192.168.1.1 > 192.168.1.100: (frag 4031:928@7400) 16:20:11.854340 192.168.1.100.570982240 > 192.168.1.1.2049: 132 read [|nfs] 16:20:11.856305 192.168.1.1.2049 > 192.168.1.100.570982240: reply ok 1472 read (frag 4034:1480@0+) 16:20:11.857546 192.168.1.1 > 192.168.1.100: (frag 4034:1480@1480+) 16:20:11.858785 192.168.1.1 > 192.168.1.100: (frag 4034:1480@2960+) 16:20:11.860023 192.168.1.1 > 192.168.1.100: (frag 4034:1480@4440+) 16:20:11.861260 192.168.1.1 > 192.168.1.100: (frag 4034:1480@5920+) 16:20:11.861982 192.168.1.1 > 192.168.1.100: (frag 4034:928@7400) 16:20:12.353307 192.168.1.100.570982241 > 192.168.1.1.2049: 132 read [|nfs] 16:20:12.355272 192.168.1.1.2049 > 192.168.1.100.570982241: reply ok 1472 read (frag 4035:1480@0+) 16:20:12.356529 192.168.1.1 > 192.168.1.100: (frag 4035:1480@1480+) 16:20:12.357757 192.168.1.1 > 192.168.1.100: (frag 4035:1480@2960+) 16:20:12.359001 192.168.1.1 > 192.168.1.100: (frag 4035:1480@4440+) 16:20:12.360239 192.168.1.1 > 192.168.1.100: (frag 4035:1480@5920+) 16:20:12.360961 192.168.1.1 > 192.168.1.100: (frag 4035:928@7400) 16:20:12.875403 192.168.1.100.570982242 > 192.168.1.1.2049: 132 read [|nfs] 16:20:12.877354 192.168.1.1.2049 > 192.168.1.100.570982242: reply ok 1472 read (frag 4038:1480@0+) 16:20:12.878594 192.168.1.1 > 192.168.1.100: (frag 4038:1480@1480+) 16:20:12.879843 192.168.1.1 > 192.168.1.100: (frag 4038:1480@2960+) 16:20:12.881071 192.168.1.1 > 192.168.1.100: (frag 4038:1480@4440+) 16:20:12.882309 192.168.1.1 > 192.168.1.100: (frag 4038:1480@5920+) 16:20:12.883031 192.168.1.1 > 192.168.1.100: (frag 4038:928@7400) 16:20:13.397577 192.168.1.100.570982243 > 192.168.1.1.2049: 132 read [|nfs] 16:20:13.399534 192.168.1.1.2049 > 192.168.1.100.570982243: reply ok 1472 read (frag 4039:1480@0+) 16:20:13.400775 192.168.1.1 > 192.168.1.100: (frag 4039:1480@1480+) 16:20:13.402016 192.168.1.1 > 192.168.1.100: (frag 4039:1480@2960+) 16:20:13.403250 192.168.1.1 > 192.168.1.100: (frag 4039:1480@4440+) 16:20:13.404489 192.168.1.1 > 192.168.1.100: (frag 4039:1480@5920+) 16:20:13.405211 192.168.1.1 > 192.168.1.100: (frag 4039:928@7400) 16:20:13.896469 192.168.1.100.570982244 > 192.168.1.1.2049: 132 read [|nfs] 16:20:13.898440 192.168.1.1.2049 > 192.168.1.100.570982244: reply ok 1472 read (frag 4042:1480@0+) 16:20:13.899682 192.168.1.1 > 192.168.1.100: (frag 4042:1480@1480+) 16:20:13.900919 192.168.1.1 > 192.168.1.100: (frag 4042:1480@2960+) 16:20:13.902158 192.168.1.1 > 192.168.1.100: (frag 4042:1480@4440+) 16:20:13.903405 192.168.1.1 > 192.168.1.100: (frag 4042:1480@5920+) 16:20:13.904117 192.168.1.1 > 192.168.1.100: (frag 4042:928@7400) 16:20:14.418588 192.168.1.100.570982245 > 192.168.1.1.2049: 132 read [|nfs] 16:20:14.420525 192.168.1.1.2049 > 192.168.1.100.570982245: reply ok 1472 read (frag 4043:1480@0+) 16:20:14.421763 192.168.1.1 > 192.168.1.100: (frag 4043:1480@1480+) 16:20:14.423001 192.168.1.1 > 192.168.1.100: (frag 4043:1480@2960+) 16:20:14.424238 192.168.1.1 > 192.168.1.100: (frag 4043:1480@4440+) 16:20:14.425478 192.168.1.1 > 192.168.1.100: (frag 4043:1480@5920+) 16:20:14.426201 192.168.1.1 > 192.168.1.100: (frag 4043:928@7400) 16:20:14.917531 192.168.1.100.570982246 > 192.168.1.1.2049: 132 read [|nfs] 16:20:14.919488 192.168.1.1.2049 > 192.168.1.100.570982246: reply ok 1472 read (frag 4046:1480@0+) 16:20:14.920729 192.168.1.1 > 192.168.1.100: (frag 4046:1480@1480+) 16:20:14.921963 192.168.1.1 > 192.168.1.100: (frag 4046:1480@2960+) 16:20:14.923201 192.168.1.1 > 192.168.1.100: (frag 4046:1480@4440+) 16:20:14.924438 192.168.1.1 > 192.168.1.100: (frag 4046:1480@5920+) 16:20:14.925163 192.168.1.1 > 192.168.1.100: (frag 4046:928@7400) 16:20:15.439643 192.168.1.100.570982247 > 192.168.1.1.2049: 132 read [|nfs] 16:20:15.441582 192.168.1.1.2049 > 192.168.1.100.570982247: reply ok 1472 read (frag 4047:1480@0+) 16:20:15.442825 192.168.1.1 > 192.168.1.100: (frag 4047:1480@1480+) 16:20:15.444062 192.168.1.1 > 192.168.1.100: (frag 4047:1480@2960+) 16:20:15.445302 192.168.1.1 > 192.168.1.100: (frag 4047:1480@4440+) 16:20:15.446544 192.168.1.1 > 192.168.1.100: (frag 4047:1480@5920+) 16:20:15.447265 192.168.1.1 > 192.168.1.100: (frag 4047:928@7400) 16:20:15.961781 192.168.1.100.570982248 > 192.168.1.1.2049: 132 read [|nfs] 16:20:15.963732 192.168.1.1.2049 > 192.168.1.100.570982248: reply ok 1472 read (frag 4050:1480@0+) 16:20:15.964985 192.168.1.1 > 192.168.1.100: (frag 4050:1480@1480+) 16:20:15.966227 192.168.1.1 > 192.168.1.100: (frag 4050:1480@2960+) 16:20:15.967467 192.168.1.1 > 192.168.1.100: (frag 4050:1480@4440+) 16:20:15.968706 192.168.1.1 > 192.168.1.100: (frag 4050:1480@5920+) 16:20:15.969429 192.168.1.1 > 192.168.1.100: (frag 4050:928@7400) 16:20:16.449127 192.168.1.100.570982249 > 192.168.1.1.2049: 132 read [|nfs] 16:20:16.451061 192.168.1.1.2049 > 192.168.1.100.570982249: reply ok 1472 read (frag 4051:1480@0+) 16:20:16.452306 192.168.1.1 > 192.168.1.100: (frag 4051:1480@1480+) 16:20:16.453540 192.168.1.1 > 192.168.1.100: (frag 4051:1480@2960+) 16:20:16.454779 192.168.1.1 > 192.168.1.100: (frag 4051:1480@4440+) 16:20:16.456018 192.168.1.1 > 192.168.1.100: (frag 4051:1480@5920+) 16:20:16.456741 192.168.1.1 > 192.168.1.100: (frag 4051:928@7400) 16:20:16.971266 192.168.1.100.570982250 > 192.168.1.1.2049: 132 read [|nfs] 16:20:16.973212 192.168.1.1.2049 > 192.168.1.100.570982250: reply ok 1472 read (frag 4054:1480@0+) 16:20:16.974452 192.168.1.1 > 192.168.1.100: (frag 4054:1480@1480+) 16:20:16.975698 192.168.1.1 > 192.168.1.100: (frag 4054:1480@2960+) 16:20:16.976934 192.168.1.1 > 192.168.1.100: (frag 4054:1480@4440+) 16:20:16.978169 192.168.1.1 > 192.168.1.100: (frag 4054:1480@5920+) 16:20:16.978893 192.168.1.1 > 192.168.1.100: (frag 4054:928@7400) 16:20:17.470237 192.168.1.100.570982251 > 192.168.1.1.2049: 132 read [|nfs] 16:20:17.472204 192.168.1.1.2049 > 192.168.1.100.570982251: reply ok 1472 read (frag 4055:1480@0+) 16:20:17.473445 192.168.1.1 > 192.168.1.100: (frag 4055:1480@1480+) 16:20:17.474683 192.168.1.1 > 192.168.1.100: (frag 4055:1480@2960+) 16:20:17.475923 192.168.1.1 > 192.168.1.100: (frag 4055:1480@4440+) 16:20:17.477161 192.168.1.1 > 192.168.1.100: (frag 4055:1480@5920+) 16:20:17.477885 192.168.1.1 > 192.168.1.100: (frag 4055:928@7400) 16:20:17.992352 192.168.1.100.570982252 > 192.168.1.1.2049: 132 read [|nfs] 16:20:17.994306 192.168.1.1.2049 > 192.168.1.100.570982252: reply ok 1472 read (frag 4058:1480@0+) 16:20:17.995541 192.168.1.1 > 192.168.1.100: (frag 4058:1480@1480+) 16:20:17.996781 192.168.1.1 > 192.168.1.100: (frag 4058:1480@2960+) 16:20:17.998019 192.168.1.1 > 192.168.1.100: (frag 4058:1480@4440+) 16:20:17.999258 192.168.1.1 > 192.168.1.100: (frag 4058:1480@5920+) 16:20:17.999980 192.168.1.1 > 192.168.1.100: (frag 4058:928@7400) 16:20:18.514482 192.168.1.100.570982253 > 192.168.1.1.2049: 132 read [|nfs] 16:20:18.516435 192.168.1.1.2049 > 192.168.1.100.570982253: reply ok 1472 read (frag 4059:1480@0+) 16:20:18.517678 192.168.1.1 > 192.168.1.100: (frag 4059:1480@1480+) 16:20:18.518916 192.168.1.1 > 192.168.1.100: (frag 4059:1480@2960+) 16:20:18.520157 192.168.1.1 > 192.168.1.100: (frag 4059:1480@4440+) 16:20:18.521392 192.168.1.1 > 192.168.1.100: (frag 4059:1480@5920+) 16:20:18.522114 192.168.1.1 > 192.168.1.100: (frag 4059:928@7400) 16:20:19.013392 192.168.1.100.570982254 > 192.168.1.1.2049: 132 read [|nfs] 16:20:19.015371 192.168.1.1.2049 > 192.168.1.100.570982254: reply ok 1472 read (frag 4062:1480@0+) 16:20:19.016608 192.168.1.1 > 192.168.1.100: (frag 4062:1480@1480+) 16:20:19.017847 192.168.1.1 > 192.168.1.100: (frag 4062:1480@2960+) 16:20:19.019088 192.168.1.1 > 192.168.1.100: (frag 4062:1480@4440+) 16:20:19.020325 192.168.1.1 > 192.168.1.100: (frag 4062:1480@5920+) 16:20:19.021047 192.168.1.1 > 192.168.1.100: (frag 4062:928@7400) 16:20:19.535510 192.168.1.100.570982255 > 192.168.1.1.2049: 132 read [|nfs] 16:20:19.537462 192.168.1.1.2049 > 192.168.1.100.570982255: reply ok 1472 read (frag 4063:1480@0+) 16:20:19.538701 192.168.1.1 > 192.168.1.100: (frag 4063:1480@1480+) 16:20:19.539940 192.168.1.1 > 192.168.1.100: (frag 4063:1480@2960+) 16:20:19.541177 192.168.1.1 > 192.168.1.100: (frag 4063:1480@4440+) 16:20:19.542415 192.168.1.1 > 192.168.1.100: (frag 4063:1480@5920+) 16:20:19.543138 192.168.1.1 > 192.168.1.100: (frag 4063:928@7400) 16:20:20.057657 192.168.1.100.570982256 > 192.168.1.1.2049: 132 read [|nfs] 16:20:20.059611 192.168.1.1.2049 > 192.168.1.100.570982256: reply ok 1472 read (frag 4066:1480@0+) 16:20:20.060850 192.168.1.1 > 192.168.1.100: (frag 4066:1480@1480+) 16:20:20.062091 192.168.1.1 > 192.168.1.100: (frag 4066:1480@2960+) 16:20:20.063326 192.168.1.1 > 192.168.1.100: (frag 4066:1480@4440+) 16:20:20.064564 192.168.1.1 > 192.168.1.100: (frag 4066:1480@5920+) 16:20:20.065290 192.168.1.1 > 192.168.1.100: (frag 4066:928@7400) 16:20:20.579917 192.168.1.100.570982257 > 192.168.1.1.2049: 132 read [|nfs] 16:20:20.581857 192.168.1.1.2049 > 192.168.1.100.570982257: reply ok 1472 read (frag 4067:1480@0+) 16:20:20.583095 192.168.1.1 > 192.168.1.100: (frag 4067:1480@1480+) 16:20:20.584332 192.168.1.1 > 192.168.1.100: (frag 4067:1480@2960+) 16:20:20.585571 192.168.1.1 > 192.168.1.100: (frag 4067:1480@4440+) 16:20:20.586811 192.168.1.1 > 192.168.1.100: (frag 4067:1480@5920+) 16:20:20.587538 192.168.1.1 > 192.168.1.100: (frag 4067:928@7400) 16:20:21.101938 192.168.1.100.570982258 > 192.168.1.1.2049: 132 read [|nfs] 16:20:21.103889 192.168.1.1.2049 > 192.168.1.100.570982258: reply ok 1472 read (frag 4070:1480@0+) 16:20:21.105133 192.168.1.1 > 192.168.1.100: (frag 4070:1480@1480+) 16:20:21.106373 192.168.1.1 > 192.168.1.100: (frag 4070:1480@2960+) 16:20:21.107612 192.168.1.1 > 192.168.1.100: (frag 4070:1480@4440+) 16:20:21.108850 192.168.1.1 > 192.168.1.100: (frag 4070:1480@5920+) 16:20:21.109573 192.168.1.1 > 192.168.1.100: (frag 4070:928@7400) 16:20:21.589269 192.168.1.100.570982259 > 192.168.1.1.2049: 132 read [|nfs] 16:20:21.591203 192.168.1.1.2049 > 192.168.1.100.570982259: reply ok 1472 read (frag 4071:1480@0+) 16:20:21.592446 192.168.1.1 > 192.168.1.100: (frag 4071:1480@1480+) 16:20:21.593679 192.168.1.1 > 192.168.1.100: (frag 4071:1480@2960+) 16:20:21.594917 192.168.1.1 > 192.168.1.100: (frag 4071:1480@4440+) 16:20:21.596156 192.168.1.1 > 192.168.1.100: (frag 4071:1480@5920+) 16:20:21.596879 192.168.1.1 > 192.168.1.100: (frag 4071:928@7400) 16:20:22.111394 192.168.1.100.570982260 > 192.168.1.1.2049: 132 read [|nfs] 16:20:22.113350 192.168.1.1.2049 > 192.168.1.100.570982260: reply ok 1472 read (frag 4074:1480@0+) 16:20:22.114588 192.168.1.1 > 192.168.1.100: (frag 4074:1480@1480+) 16:20:22.115837 192.168.1.1 > 192.168.1.100: (frag 4074:1480@2960+) 16:20:22.117067 192.168.1.1 > 192.168.1.100: (frag 4074:1480@4440+) 16:20:22.118309 192.168.1.1 > 192.168.1.100: (frag 4074:1480@5920+) 16:20:22.119029 192.168.1.1 > 192.168.1.100: (frag 4074:928@7400) 16:20:22.610306 192.168.1.100.570982261 > 192.168.1.1.2049: 132 read [|nfs] 16:20:22.612243 192.168.1.1.2049 > 192.168.1.100.570982261: reply ok 1472 read (frag 4075:1480@0+) 16:20:22.613480 192.168.1.1 > 192.168.1.100: (frag 4075:1480@1480+) 16:20:22.614717 192.168.1.1 > 192.168.1.100: (frag 4075:1480@2960+) 16:20:22.615962 192.168.1.1 > 192.168.1.100: (frag 4075:1480@4440+) 16:20:22.617207 192.168.1.1 > 192.168.1.100: (frag 4075:1480@5920+) 16:20:22.617934 192.168.1.1 > 192.168.1.100: (frag 4075:928@7400) 16:20:23.294366 192.168.1.100.570982262 > 192.168.1.1.2049: 132 read [|nfs] 16:20:23.296326 192.168.1.1.2049 > 192.168.1.100.570982262: reply ok 1472 read (frag 4078:1480@0+) 16:20:23.297563 192.168.1.1 > 192.168.1.100: (frag 4078:1480@1480+) 16:20:23.298802 192.168.1.1 > 192.168.1.100: (frag 4078:1480@2960+) 16:20:23.300041 192.168.1.1 > 192.168.1.100: (frag 4078:1480@4440+) 16:20:23.301278 192.168.1.1 > 192.168.1.100: (frag 4078:1480@5920+) 16:20:23.302000 192.168.1.1 > 192.168.1.100: (frag 4078:928@7400) 16:20:23.677814 192.168.1.100.570982263 > 192.168.1.1.2049: 132 read [|nfs] 16:20:23.679778 192.168.1.1.2049 > 192.168.1.100.570982263: reply ok 1472 read (frag 4079:1480@0+) 16:20:23.681014 192.168.1.1 > 192.168.1.100: (frag 4079:1480@1480+) 16:20:23.682252 192.168.1.1 > 192.168.1.100: (frag 4079:1480@2960+) 16:20:23.683493 192.168.1.1 > 192.168.1.100: (frag 4079:1480@4440+) 16:20:23.684727 192.168.1.1 > 192.168.1.100: (frag 4079:1480@5920+) 16:20:23.685451 192.168.1.1 > 192.168.1.100: (frag 4079:928@7400) 16:20:24.176736 192.168.1.100.570982264 > 192.168.1.1.2049: 132 read [|nfs] 16:20:24.178696 192.168.1.1.2049 > 192.168.1.100.570982264: reply ok 1472 read (frag 4082:1480@0+) 16:20:24.179949 192.168.1.1 > 192.168.1.100: (frag 4082:1480@1480+) 16:20:24.181187 192.168.1.1 > 192.168.1.100: (frag 4082:1480@2960+) 16:20:24.182425 192.168.1.1 > 192.168.1.100: (frag 4082:1480@4440+) 16:20:24.183663 192.168.1.1 > 192.168.1.100: (frag 4082:1480@5920+) 16:20:24.184385 192.168.1.1 > 192.168.1.100: (frag 4082:928@7400) 16:20:24.698920 192.168.1.100.570982265 > 192.168.1.1.2049: 132 read [|nfs] 16:20:24.700890 192.168.1.1.2049 > 192.168.1.100.570982265: reply ok 1472 read (frag 4083:1480@0+) 16:20:24.702122 192.168.1.1 > 192.168.1.100: (frag 4083:1480@1480+) 16:20:24.703359 192.168.1.1 > 192.168.1.100: (frag 4083:1480@2960+) 16:20:24.704597 192.168.1.1 > 192.168.1.100: (frag 4083:1480@4440+) 16:20:24.705844 192.168.1.1 > 192.168.1.100: (frag 4083:1480@5920+) 16:20:24.706560 192.168.1.1 > 192.168.1.100: (frag 4083:928@7400) 16:20:25.197800 192.168.1.100.570982266 > 192.168.1.1.2049: 132 read [|nfs] 16:20:25.199768 192.168.1.1.2049 > 192.168.1.100.570982266: reply ok 1472 read (frag 4086:1480@0+) 16:20:25.201017 192.168.1.1 > 192.168.1.100: (frag 4086:1480@1480+) 16:20:25.202245 192.168.1.1 > 192.168.1.100: (frag 4086:1480@2960+) 16:20:25.203483 192.168.1.1 > 192.168.1.100: (frag 4086:1480@4440+) 16:20:25.204721 192.168.1.1 > 192.168.1.100: (frag 4086:1480@5920+) 16:20:25.205445 192.168.1.1 > 192.168.1.100: (frag 4086:928@7400) 16:20:25.719973 192.168.1.100.570982267 > 192.168.1.1.2049: 132 read [|nfs] 16:20:25.721940 192.168.1.1.2049 > 192.168.1.100.570982267: reply ok 1472 read (frag 4088:1480@0+) 16:20:25.723176 192.168.1.1 > 192.168.1.100: (frag 4088:1480@1480+) 16:20:25.724414 192.168.1.1 > 192.168.1.100: (frag 4088:1480@2960+) 16:20:25.725657 192.168.1.1 > 192.168.1.100: (frag 4088:1480@4440+) 16:20:25.726911 192.168.1.1 > 192.168.1.100: (frag 4088:1480@5920+) 16:20:25.727634 192.168.1.1 > 192.168.1.100: (frag 4088:928@7400) 16:20:26.242070 192.168.1.100.570982268 > 192.168.1.1.2049: 132 read [|nfs] 16:20:26.244007 192.168.1.1.2049 > 192.168.1.100.570982268: reply ok 1472 read (frag 4090:1480@0+) 16:20:26.245260 192.168.1.1 > 192.168.1.100: (frag 4090:1480@1480+) 16:20:26.246499 192.168.1.1 > 192.168.1.100: (frag 4090:1480@2960+) 16:20:26.247738 192.168.1.1 > 192.168.1.100: (frag 4090:1480@4440+) 16:20:26.248978 192.168.1.1 > 192.168.1.100: (frag 4090:1480@5920+) 16:20:26.249701 192.168.1.1 > 192.168.1.100: (frag 4090:928@7400) 16:20:26.729437 192.168.1.100.570982269 > 192.168.1.1.2049: 132 read [|nfs] 16:20:26.731400 192.168.1.1.2049 > 192.168.1.100.570982269: reply ok 1472 read (frag 4092:1480@0+) 16:20:26.732635 192.168.1.1 > 192.168.1.100: (frag 4092:1480@1480+) 16:20:26.733876 192.168.1.1 > 192.168.1.100: (frag 4092:1480@2960+) 16:20:26.735110 192.168.1.1 > 192.168.1.100: (frag 4092:1480@4440+) 16:20:26.736355 192.168.1.1 > 192.168.1.100: (frag 4092:1480@5920+) 16:20:26.737072 192.168.1.1 > 192.168.1.100: (frag 4092:928@7400) 16:20:27.390830 192.168.1.100.570982270 > 192.168.1.1.2049: 132 read [|nfs] 16:20:27.392770 192.168.1.1.2049 > 192.168.1.100.570982270: reply ok 1472 read (frag 4094:1480@0+) 16:20:27.394004 192.168.1.1 > 192.168.1.100: (frag 4094:1480@1480+) 16:20:27.395241 192.168.1.1 > 192.168.1.100: (frag 4094:1480@2960+) 16:20:27.396491 192.168.1.1 > 192.168.1.100: (frag 4094:1480@4440+) 16:20:27.397719 192.168.1.1 > 192.168.1.100: (frag 4094:1480@5920+) 16:20:27.398443 192.168.1.1 > 192.168.1.100: (frag 4094:928@7400) 16:20:27.889681 192.168.1.100.570982271 > 192.168.1.1.2049: 132 read [|nfs] 16:20:27.891641 192.168.1.1.2049 > 192.168.1.100.570982271: reply ok 1472 read (frag 4097:1480@0+) 16:20:27.892872 192.168.1.1 > 192.168.1.100: (frag 4097:1480@1480+) 16:20:27.894110 192.168.1.1 > 192.168.1.100: (frag 4097:1480@2960+) 16:20:27.895349 192.168.1.1 > 192.168.1.100: (frag 4097:1480@4440+) 16:20:27.896599 192.168.1.1 > 192.168.1.100: (frag 4097:1480@5920+) 16:20:27.897311 192.168.1.1 > 192.168.1.100: (frag 4097:928@7400) 16:20:28.411817 192.168.1.100.570982272 > 192.168.1.1.2049: 132 read [|nfs] 16:20:28.413749 192.168.1.1.2049 > 192.168.1.100.570982272: reply ok 1472 read (frag 4098:1480@0+) 16:20:28.414993 192.168.1.1 > 192.168.1.100: (frag 4098:1480@1480+) 16:20:28.416228 192.168.1.1 > 192.168.1.100: (frag 4098:1480@2960+) 16:20:28.417467 192.168.1.1 > 192.168.1.100: (frag 4098:1480@4440+) 16:20:28.418706 192.168.1.1 > 192.168.1.100: (frag 4098:1480@5920+) 16:20:28.419430 192.168.1.1 > 192.168.1.100: (frag 4098:928@7400) 16:20:28.933979 192.168.1.100.570982273 > 192.168.1.1.2049: 132 read [|nfs] 16:20:28.935944 192.168.1.1.2049 > 192.168.1.100.570982273: reply ok 1472 read (frag 4101:1480@0+) 16:20:28.937176 192.168.1.1 > 192.168.1.100: (frag 4101:1480@1480+) 16:20:28.938414 192.168.1.1 > 192.168.1.100: (frag 4101:1480@2960+) 16:20:28.939653 192.168.1.1 > 192.168.1.100: (frag 4101:1480@4440+) 16:20:28.940894 192.168.1.1 > 192.168.1.100: (frag 4101:1480@5920+) 16:20:28.941613 192.168.1.1 > 192.168.1.100: (frag 4101:928@7400) 16:20:29.432884 192.168.1.100.570982274 > 192.168.1.1.2049: 132 read [|nfs] 16:20:29.434814 192.168.1.1.2049 > 192.168.1.100.570982274: reply ok 1472 read (frag 4102:1480@0+) 16:20:29.436053 192.168.1.1 > 192.168.1.100: (frag 4102:1480@1480+) 16:20:29.437291 192.168.1.1 > 192.168.1.100: (frag 4102:1480@2960+) 16:20:29.438529 192.168.1.1 > 192.168.1.100: (frag 4102:1480@4440+) 16:20:29.439768 192.168.1.1 > 192.168.1.100: (frag 4102:1480@5920+) 16:20:29.440490 192.168.1.1 > 192.168.1.100: (frag 4102:928@7400) 16:20:29.955047 192.168.1.100.570982275 > 192.168.1.1.2049: 132 read [|nfs] 16:20:29.957010 192.168.1.1.2049 > 192.168.1.100.570982275: reply ok 1472 read (frag 4105:1480@0+) 16:20:29.958244 192.168.1.1 > 192.168.1.100: (frag 4105:1480@1480+) 16:20:29.959484 192.168.1.1 > 192.168.1.100: (frag 4105:1480@2960+) 16:20:29.960722 192.168.1.1 > 192.168.1.100: (frag 4105:1480@4440+) 16:20:29.961959 192.168.1.1 > 192.168.1.100: (frag 4105:1480@5920+) 16:20:29.962681 192.168.1.1 > 192.168.1.100: (frag 4105:928@7400) 16:20:30.477231 192.168.1.100.570982276 > 192.168.1.1.2049: 132 read [|nfs] 16:20:30.479185 192.168.1.1.2049 > 192.168.1.100.570982276: reply ok 1472 read (frag 4106:1480@0+) 16:20:30.480427 192.168.1.1 > 192.168.1.100: (frag 4106:1480@1480+) 16:20:30.481664 192.168.1.1 > 192.168.1.100: (frag 4106:1480@2960+) 16:20:30.482907 192.168.1.1 > 192.168.1.100: (frag 4106:1480@4440+) 16:20:30.484140 192.168.1.1 > 192.168.1.100: (frag 4106:1480@5920+) 16:20:30.484870 192.168.1.1 > 192.168.1.100: (frag 4106:928@7400) 16:20:30.999278 192.168.1.100.570982277 > 192.168.1.1.2049: 132 read [|nfs] 16:20:31.001228 192.168.1.1.2049 > 192.168.1.100.570982277: reply ok 1472 read (frag 4109:1480@0+) 16:20:31.002467 192.168.1.1 > 192.168.1.100: (frag 4109:1480@1480+) 16:20:31.003704 192.168.1.1 > 192.168.1.100: (frag 4109:1480@2960+) 16:20:31.004942 192.168.1.1 > 192.168.1.100: (frag 4109:1480@4440+) 16:20:31.006191 192.168.1.1 > 192.168.1.100: (frag 4109:1480@5920+) 16:20:31.006905 192.168.1.1 > 192.168.1.100: (frag 4109:928@7400) 16:20:31.521445 192.168.1.100.570982278 > 192.168.1.1.2049: 132 read [|nfs] 16:20:31.523379 192.168.1.1.2049 > 192.168.1.100.570982278: reply ok 1472 read (frag 4110:1480@0+) 16:20:31.524616 192.168.1.1 > 192.168.1.100: (frag 4110:1480@1480+) 16:20:31.525864 192.168.1.1 > 192.168.1.100: (frag 4110:1480@2960+) 16:20:31.527095 192.168.1.1 > 192.168.1.100: (frag 4110:1480@4440+) 16:20:31.528333 192.168.1.1 > 192.168.1.100: (frag 4110:1480@5920+) 16:20:31.529056 192.168.1.1 > 192.168.1.100: (frag 4110:928@7400) 16:20:32.008785 192.168.1.100.570982279 > 192.168.1.1.2049: 132 read [|nfs] 16:20:32.010739 192.168.1.1.2049 > 192.168.1.100.570982279: reply ok 1472 read (frag 4113:1480@0+) 16:20:32.011979 192.168.1.1 > 192.168.1.100: (frag 4113:1480@1480+) 16:20:32.013220 192.168.1.1 > 192.168.1.100: (frag 4113:1480@2960+) 16:20:32.014455 192.168.1.1 > 192.168.1.100: (frag 4113:1480@4440+) 16:20:32.015694 192.168.1.1 > 192.168.1.100: (frag 4113:1480@5920+) 16:20:32.016417 192.168.1.1 > 192.168.1.100: (frag 4113:928@7400) 16:20:32.530908 192.168.1.100.570982280 > 192.168.1.1.2049: 132 read [|nfs] 16:20:32.532843 192.168.1.1.2049 > 192.168.1.100.570982280: reply ok 1472 read (frag 4114:1480@0+) 16:20:32.534085 192.168.1.1 > 192.168.1.100: (frag 4114:1480@1480+) 16:20:32.535322 192.168.1.1 > 192.168.1.100: (frag 4114:1480@2960+) 16:20:32.536562 192.168.1.1 > 192.168.1.100: (frag 4114:1480@4440+) 16:20:32.537802 192.168.1.1 > 192.168.1.100: (frag 4114:1480@5920+) 16:20:32.538525 192.168.1.1 > 192.168.1.100: (frag 4114:928@7400) 16:20:33.029836 192.168.1.100.570982281 > 192.168.1.1.2049: 132 read [|nfs] 16:20:33.031797 192.168.1.1.2049 > 192.168.1.100.570982281: reply ok 1472 read (frag 4117:1480@0+) 16:20:33.033030 192.168.1.1 > 192.168.1.100: (frag 4117:1480@1480+) 16:20:33.034268 192.168.1.1 > 192.168.1.100: (frag 4117:1480@2960+) 16:20:33.035507 192.168.1.1 > 192.168.1.100: (frag 4117:1480@4440+) 16:20:33.036747 192.168.1.1 > 192.168.1.100: (frag 4117:1480@5920+) 16:20:33.037480 192.168.1.1 > 192.168.1.100: (frag 4117:928@7400) 16:20:33.551964 192.168.1.100.570982282 > 192.168.1.1.2049: 132 read [|nfs] 16:20:33.553892 192.168.1.1.2049 > 192.168.1.100.570982282: reply ok 1472 read (frag 4118:1480@0+) 16:20:33.555134 192.168.1.1 > 192.168.1.100: (frag 4118:1480@1480+) 16:20:33.556377 192.168.1.1 > 192.168.1.100: (frag 4118:1480@2960+) 16:20:33.557611 192.168.1.1 > 192.168.1.100: (frag 4118:1480@4440+) 16:20:33.558851 192.168.1.1 > 192.168.1.100: (frag 4118:1480@5920+) 16:20:33.559574 192.168.1.1 > 192.168.1.100: (frag 4118:928@7400) 16:20:34.074105 192.168.1.100.570982283 > 192.168.1.1.2049: 132 read [|nfs] 16:20:34.076070 192.168.1.1.2049 > 192.168.1.100.570982283: reply ok 1472 read (frag 4121:1480@0+) 16:20:34.077304 192.168.1.1 > 192.168.1.100: (frag 4121:1480@1480+) 16:20:34.078543 192.168.1.1 > 192.168.1.100: (frag 4121:1480@2960+) 16:20:34.079782 192.168.1.1 > 192.168.1.100: (frag 4121:1480@4440+) 16:20:34.081024 192.168.1.1 > 192.168.1.100: (frag 4121:1480@5920+) 16:20:34.081743 192.168.1.1 > 192.168.1.100: (frag 4121:928@7400) 16:20:34.573018 192.168.1.100.570982284 > 192.168.1.1.2049: 132 read [|nfs] 16:20:34.574935 192.168.1.1.2049 > 192.168.1.100.570982284: reply ok 1472 read (frag 4122:1480@0+) 16:20:34.576172 192.168.1.1 > 192.168.1.100: (frag 4122:1480@1480+) 16:20:34.577411 192.168.1.1 > 192.168.1.100: (frag 4122:1480@2960+) 16:20:34.578649 192.168.1.1 > 192.168.1.100: (frag 4122:1480@4440+) 16:20:34.579888 192.168.1.1 > 192.168.1.100: (frag 4122:1480@5920+) 16:20:34.580611 192.168.1.1 > 192.168.1.100: (frag 4122:928@7400) 16:20:35.095236 192.168.1.100.570982285 > 192.168.1.1.2049: 132 read [|nfs] 16:20:35.097197 192.168.1.1.2049 > 192.168.1.100.570982285: reply ok 1472 read (frag 4125:1480@0+) 16:20:35.098440 192.168.1.1 > 192.168.1.100: (frag 4125:1480@1480+) 16:20:35.099674 192.168.1.1 > 192.168.1.100: (frag 4125:1480@2960+) 16:20:35.100913 192.168.1.1 > 192.168.1.100: (frag 4125:1480@4440+) 16:20:35.102150 192.168.1.1 > 192.168.1.100: (frag 4125:1480@5920+) 16:20:35.102872 192.168.1.1 > 192.168.1.100: (frag 4125:928@7400) 16:20:35.594111 192.168.1.100.570982286 > 192.168.1.1.2049: 132 read [|nfs] 16:20:35.596038 192.168.1.1.2049 > 192.168.1.100.570982286: reply ok 1472 read (frag 4126:1480@0+) 16:20:35.597273 192.168.1.1 > 192.168.1.100: (frag 4126:1480@1480+) 16:20:35.598510 192.168.1.1 > 192.168.1.100: (frag 4126:1480@2960+) 16:20:35.599749 192.168.1.1 > 192.168.1.100: (frag 4126:1480@4440+) 16:20:35.600991 192.168.1.1 > 192.168.1.100: (frag 4126:1480@5920+) 16:20:35.601709 192.168.1.1 > 192.168.1.100: (frag 4126:928@7400) 16:20:36.116230 192.168.1.100.570982287 > 192.168.1.1.2049: 132 read [|nfs] 16:20:36.118205 192.168.1.1.2049 > 192.168.1.100.570982287: reply ok 1472 read (frag 4129:1480@0+) 16:20:36.119443 192.168.1.1 > 192.168.1.100: (frag 4129:1480@1480+) 16:20:36.120681 192.168.1.1 > 192.168.1.100: (frag 4129:1480@2960+) 16:20:36.121919 192.168.1.1 > 192.168.1.100: (frag 4129:1480@4440+) 16:20:36.123156 192.168.1.1 > 192.168.1.100: (frag 4129:1480@5920+) 16:20:36.123880 192.168.1.1 > 192.168.1.100: (frag 4129:928@7400) 16:20:36.638386 192.168.1.100.570982288 > 192.168.1.1.2049: 132 read [|nfs] 16:20:36.640346 192.168.1.1.2049 > 192.168.1.100.570982288: reply ok 1472 read (frag 4130:1480@0+) 16:20:36.641584 192.168.1.1 > 192.168.1.100: (frag 4130:1480@1480+) 16:20:36.642822 192.168.1.1 > 192.168.1.100: (frag 4130:1480@2960+) 16:20:36.644059 192.168.1.1 > 192.168.1.100: (frag 4130:1480@4440+) 16:20:36.645298 192.168.1.1 > 192.168.1.100: (frag 4130:1480@5920+) 16:20:36.646026 192.168.1.1 > 192.168.1.100: (frag 4130:928@7400) 16:20:37.125702 192.168.1.100.570982289 > 192.168.1.1.2049: 132 read [|nfs] 16:20:37.127659 192.168.1.1.2049 > 192.168.1.100.570982289: reply ok 1472 read (frag 4133:1480@0+) 16:20:37.128894 192.168.1.1 > 192.168.1.100: (frag 4133:1480@1480+) 16:20:37.130132 192.168.1.1 > 192.168.1.100: (frag 4133:1480@2960+) 16:20:37.131374 192.168.1.1 > 192.168.1.100: (frag 4133:1480@4440+) 16:20:37.132608 192.168.1.1 > 192.168.1.100: (frag 4133:1480@5920+) 16:20:37.133330 192.168.1.1 > 192.168.1.100: (frag 4133:928@7400) 16:20:37.647833 192.168.1.100.570982290 > 192.168.1.1.2049: 132 read [|nfs] 16:20:37.649804 192.168.1.1.2049 > 192.168.1.100.570982290: reply ok 1472 read (frag 4134:1480@0+) 16:20:37.651041 192.168.1.1 > 192.168.1.100: (frag 4134:1480@1480+) 16:20:37.652278 192.168.1.1 > 192.168.1.100: (frag 4134:1480@2960+) 16:20:37.653516 192.168.1.1 > 192.168.1.100: (frag 4134:1480@4440+) 16:20:37.654753 192.168.1.1 > 192.168.1.100: (frag 4134:1480@5920+) 16:20:37.655478 192.168.1.1 > 192.168.1.100: (frag 4134:928@7400) 16:20:38.146766 192.168.1.100.570982291 > 192.168.1.1.2049: 132 read [|nfs] 16:20:38.148724 192.168.1.1.2049 > 192.168.1.100.570982291: reply ok 1472 read (frag 4137:1480@0+) 16:20:38.149958 192.168.1.1 > 192.168.1.100: (frag 4137:1480@1480+) 16:20:38.151196 192.168.1.1 > 192.168.1.100: (frag 4137:1480@2960+) 16:20:38.152433 192.168.1.1 > 192.168.1.100: (frag 4137:1480@4440+) 16:20:38.153671 192.168.1.1 > 192.168.1.100: (frag 4137:1480@5920+) 16:20:38.154393 192.168.1.1 > 192.168.1.100: (frag 4137:928@7400) 16:20:38.668899 192.168.1.100.570982292 > 192.168.1.1.2049: 132 read [|nfs] 16:20:38.670855 192.168.1.1.2049 > 192.168.1.100.570982292: reply ok 1472 read (frag 4138:1480@0+) 16:20:38.672092 192.168.1.1 > 192.168.1.100: (frag 4138:1480@1480+) 16:20:38.673331 192.168.1.1 > 192.168.1.100: (frag 4138:1480@2960+) 16:20:38.674568 192.168.1.1 > 192.168.1.100: (frag 4138:1480@4440+) 16:20:38.675807 192.168.1.1 > 192.168.1.100: (frag 4138:1480@5920+) 16:20:38.676532 192.168.1.1 > 192.168.1.100: (frag 4138:928@7400) 16:20:39.191013 192.168.1.100.570982293 > 192.168.1.1.2049: 132 read [|nfs] 16:20:39.192967 192.168.1.1.2049 > 192.168.1.100.570982293: reply ok 1472 read (frag 4141:1480@0+) 16:20:39.194213 192.168.1.1 > 192.168.1.100: (frag 4141:1480@1480+) 16:20:39.195441 192.168.1.1 > 192.168.1.100: (frag 4141:1480@2960+) 16:20:39.196681 192.168.1.1 > 192.168.1.100: (frag 4141:1480@4440+) 16:20:39.197920 192.168.1.1 > 192.168.1.100: (frag 4141:1480@5920+) 16:20:39.198645 192.168.1.1 > 192.168.1.100: (frag 4141:928@7400) 16:20:39.689968 192.168.1.100.570982294 > 192.168.1.1.2049: 132 read [|nfs] 16:20:39.691920 192.168.1.1.2049 > 192.168.1.100.570982294: reply ok 1472 read (frag 4142:1480@0+) 16:20:39.693156 192.168.1.1 > 192.168.1.100: (frag 4142:1480@1480+) 16:20:39.694394 192.168.1.1 > 192.168.1.100: (frag 4142:1480@2960+) 16:20:39.695637 192.168.1.1 > 192.168.1.100: (frag 4142:1480@4440+) 16:20:39.696877 192.168.1.1 > 192.168.1.100: (frag 4142:1480@5920+) 16:20:39.697599 192.168.1.1 > 192.168.1.100: (frag 4142:928@7400) 16:20:40.212102 192.168.1.100.570982295 > 192.168.1.1.2049: 132 read [|nfs] 16:20:40.214053 192.168.1.1.2049 > 192.168.1.100.570982295: reply ok 1472 read (frag 4145:1480@0+) 16:20:40.215289 192.168.1.1 > 192.168.1.100: (frag 4145:1480@1480+) 16:20:40.216533 192.168.1.1 > 192.168.1.100: (frag 4145:1480@2960+) 16:20:40.217777 192.168.1.1 > 192.168.1.100: (frag 4145:1480@4440+) 16:20:40.219007 192.168.1.1 > 192.168.1.100: (frag 4145:1480@5920+) 16:20:40.219730 192.168.1.1 > 192.168.1.100: (frag 4145:928@7400) 16:20:40.711030 192.168.1.100.570982296 > 192.168.1.1.2049: 132 read [|nfs] 16:20:40.712981 192.168.1.1.2049 > 192.168.1.100.570982296: reply ok 1472 read (frag 4146:1480@0+) 16:20:40.714217 192.168.1.1 > 192.168.1.100: (frag 4146:1480@1480+) 16:20:40.715454 192.168.1.1 > 192.168.1.100: (frag 4146:1480@2960+) 16:20:40.716694 192.168.1.1 > 192.168.1.100: (frag 4146:1480@4440+) 16:20:40.717933 192.168.1.1 > 192.168.1.100: (frag 4146:1480@5920+) 16:20:40.718657 192.168.1.1 > 192.168.1.100: (frag 4146:928@7400) 16:20:41.233165 192.168.1.100.570982297 > 192.168.1.1.2049: 132 read [|nfs] 16:20:41.235122 192.168.1.1.2049 > 192.168.1.100.570982297: reply ok 1472 read (frag 4149:1480@0+) 16:20:41.236359 192.168.1.1 > 192.168.1.100: (frag 4149:1480@1480+) 16:20:41.237597 192.168.1.1 > 192.168.1.100: (frag 4149:1480@2960+) 16:20:41.238836 192.168.1.1 > 192.168.1.100: (frag 4149:1480@4440+) 16:20:41.240074 192.168.1.1 > 192.168.1.100: (frag 4149:1480@5920+) 16:20:41.240796 192.168.1.1 > 192.168.1.100: (frag 4149:928@7400) 16:20:41.755400 192.168.1.100.570982298 > 192.168.1.1.2049: 132 read [|nfs] 16:20:41.757354 192.168.1.1.2049 > 192.168.1.100.570982298: reply ok 1472 read (frag 4151:1480@0+) 16:20:41.758593 192.168.1.1 > 192.168.1.100: (frag 4151:1480@1480+) 16:20:41.759829 192.168.1.1 > 192.168.1.100: (frag 4151:1480@2960+) 16:20:41.761066 192.168.1.1 > 192.168.1.100: (frag 4151:1480@4440+) 16:20:41.762304 192.168.1.1 > 192.168.1.100: (frag 4151:1480@5920+) 16:20:41.763026 192.168.1.1 > 192.168.1.100: (frag 4151:928@7400) 16:20:42.242621 192.168.1.100.570982299 > 192.168.1.1.2049: 132 read [|nfs] 16:20:42.244567 192.168.1.1.2049 > 192.168.1.100.570982299: reply ok 1472 read (frag 4153:1480@0+) 16:20:42.245801 192.168.1.1 > 192.168.1.100: (frag 4153:1480@1480+) 16:20:42.247041 192.168.1.1 > 192.168.1.100: (frag 4153:1480@2960+) 16:20:42.248280 192.168.1.1 > 192.168.1.100: (frag 4153:1480@4440+) 16:20:42.249522 192.168.1.1 > 192.168.1.100: (frag 4153:1480@5920+) 16:20:42.250240 192.168.1.1 > 192.168.1.100: (frag 4153:928@7400) 16:20:42.764761 192.168.1.100.570982300 > 192.168.1.1.2049: 132 read [|nfs] 16:20:42.766724 192.168.1.1.2049 > 192.168.1.100.570982300: reply ok 1472 read (frag 4155:1480@0+) 16:20:42.767961 192.168.1.1 > 192.168.1.100: (frag 4155:1480@1480+) 16:20:42.769200 192.168.1.1 > 192.168.1.100: (frag 4155:1480@2960+) 16:20:42.770438 192.168.1.1 > 192.168.1.100: (frag 4155:1480@4440+) 16:20:42.771676 192.168.1.1 > 192.168.1.100: (frag 4155:1480@5920+) 16:20:42.772398 192.168.1.1 > 192.168.1.100: (frag 4155:928@7400) 16:20:43.263671 192.168.1.100.570982301 > 192.168.1.1.2049: 132 read [|nfs] 16:20:43.265623 192.168.1.1.2049 > 192.168.1.100.570982301: reply ok 1472 read (frag 4157:1480@0+) 16:20:43.266857 192.168.1.1 > 192.168.1.100: (frag 4157:1480@1480+) 16:20:43.268095 192.168.1.1 > 192.168.1.100: (frag 4157:1480@2960+) 16:20:43.269333 192.168.1.1 > 192.168.1.100: (frag 4157:1480@4440+) 16:20:43.270571 192.168.1.1 > 192.168.1.100: (frag 4157:1480@5920+) 16:20:43.271294 192.168.1.1 > 192.168.1.100: (frag 4157:928@7400) 16:20:43.785839 192.168.1.100.570982302 > 192.168.1.1.2049: 132 read [|nfs] 16:20:43.787797 192.168.1.1.2049 > 192.168.1.100.570982302: reply ok 1472 read (frag 4159:1480@0+) 16:20:43.789033 192.168.1.1 > 192.168.1.100: (frag 4159:1480@1480+) 16:20:43.790270 192.168.1.1 > 192.168.1.100: (frag 4159:1480@2960+) 16:20:43.791511 192.168.1.1 > 192.168.1.100: (frag 4159:1480@4440+) 16:20:43.792746 192.168.1.1 > 192.168.1.100: (frag 4159:1480@5920+) 16:20:43.793469 192.168.1.1 > 192.168.1.100: (frag 4159:928@7400) 16:20:44.307944 192.168.1.100.570982303 > 192.168.1.1.2049: 132 read [|nfs] 16:20:44.309886 192.168.1.1.2049 > 192.168.1.100.570982303: reply ok 1472 read (frag 4161:1480@0+) 16:20:44.311119 192.168.1.1 > 192.168.1.100: (frag 4161:1480@1480+) 16:20:44.312357 192.168.1.1 > 192.168.1.100: (frag 4161:1480@2960+) 16:20:44.313594 192.168.1.1 > 192.168.1.100: (frag 4161:1480@4440+) 16:20:44.314833 192.168.1.1 > 192.168.1.100: (frag 4161:1480@5920+) 16:20:44.315557 192.168.1.1 > 192.168.1.100: (frag 4161:928@7400) 16:20:44.806935 192.168.1.100.570982304 > 192.168.1.1.2049: 132 read [|nfs] 16:20:44.808895 192.168.1.1.2049 > 192.168.1.100.570982304: reply ok 1472 read (frag 4163:1480@0+) 16:20:44.810129 192.168.1.1 > 192.168.1.100: (frag 4163:1480@1480+) 16:20:44.811365 192.168.1.1 > 192.168.1.100: (frag 4163:1480@2960+) 16:20:44.812604 192.168.1.1 > 192.168.1.100: (frag 4163:1480@4440+) 16:20:44.813842 192.168.1.1 > 192.168.1.100: (frag 4163:1480@5920+) 16:20:44.814564 192.168.1.1 > 192.168.1.100: (frag 4163:928@7400) 16:20:45.329023 192.168.1.100.570982305 > 192.168.1.1.2049: 132 read [|nfs] 16:20:45.330977 192.168.1.1.2049 > 192.168.1.100.570982305: reply ok 1472 read (frag 4165:1480@0+) 16:20:45.332209 192.168.1.1 > 192.168.1.100: (frag 4165:1480@1480+) 16:20:45.333450 192.168.1.1 > 192.168.1.100: (frag 4165:1480@2960+) 16:20:45.334684 192.168.1.1 > 192.168.1.100: (frag 4165:1480@4440+) 16:20:45.335925 192.168.1.1 > 192.168.1.100: (frag 4165:1480@5920+) 16:20:45.336648 192.168.1.1 > 192.168.1.100: (frag 4165:928@7400) 16:20:45.827937 192.168.1.100.570982306 > 192.168.1.1.2049: 132 read [|nfs] 16:20:45.829908 192.168.1.1.2049 > 192.168.1.100.570982306: reply ok 1472 read (frag 4168:1480@0+) 16:20:45.831146 192.168.1.1 > 192.168.1.100: (frag 4168:1480@1480+) 16:20:45.832384 192.168.1.1 > 192.168.1.100: (frag 4168:1480@2960+) 16:20:45.833622 192.168.1.1 > 192.168.1.100: (frag 4168:1480@4440+) 16:20:45.834861 192.168.1.1 > 192.168.1.100: (frag 4168:1480@5920+) 16:20:45.835587 192.168.1.1 > 192.168.1.100: (frag 4168:928@7400) 16:20:46.350065 192.168.1.100.570982307 > 192.168.1.1.2049: 132 read [|nfs] 16:20:46.352003 192.168.1.1.2049 > 192.168.1.100.570982307: reply ok 1472 read (frag 4169:1480@0+) 16:20:46.353243 192.168.1.1 > 192.168.1.100: (frag 4169:1480@1480+) 16:20:46.354481 192.168.1.1 > 192.168.1.100: (frag 4169:1480@2960+) 16:20:46.355718 192.168.1.1 > 192.168.1.100: (frag 4169:1480@4440+) 16:20:46.356958 192.168.1.1 > 192.168.1.100: (frag 4169:1480@5920+) 16:20:46.357681 192.168.1.1 > 192.168.1.100: (frag 4169:928@7400) 16:20:46.872207 192.168.1.100.570982308 > 192.168.1.1.2049: 132 read [|nfs] 16:20:46.874158 192.168.1.1.2049 > 192.168.1.100.570982308: reply ok 1472 read (frag 4172:1480@0+) 16:20:46.875396 192.168.1.1 > 192.168.1.100: (frag 4172:1480@1480+) 16:20:46.876635 192.168.1.1 > 192.168.1.100: (frag 4172:1480@2960+) 16:20:46.877874 192.168.1.1 > 192.168.1.100: (frag 4172:1480@4440+) 16:20:46.879113 192.168.1.1 > 192.168.1.100: (frag 4172:1480@5920+) 16:20:46.879836 192.168.1.1 > 192.168.1.100: (frag 4172:928@7400) 16:20:47.359527 192.168.1.100.570982309 > 192.168.1.1.2049: 132 read [|nfs] 16:20:47.361464 192.168.1.1.2049 > 192.168.1.100.570982309: reply ok 1472 read (frag 4173:1480@0+) 16:20:47.362705 192.168.1.1 > 192.168.1.100: (frag 4173:1480@1480+) 16:20:47.363943 192.168.1.1 > 192.168.1.100: (frag 4173:1480@2960+) 16:20:47.365181 192.168.1.1 > 192.168.1.100: (frag 4173:1480@4440+) 16:20:47.366425 192.168.1.1 > 192.168.1.100: (frag 4173:1480@5920+) 16:20:47.367145 192.168.1.1 > 192.168.1.100: (frag 4173:928@7400) 16:20:47.881689 192.168.1.100.570982310 > 192.168.1.1.2049: 132 read [|nfs] 16:20:47.883639 192.168.1.1.2049 > 192.168.1.100.570982310: reply ok 1472 read (frag 4176:1480@0+) 16:20:47.884876 192.168.1.1 > 192.168.1.100: (frag 4176:1480@1480+) 16:20:47.886124 192.168.1.1 > 192.168.1.100: (frag 4176:1480@2960+) 16:20:47.887355 192.168.1.1 > 192.168.1.100: (frag 4176:1480@4440+) 16:20:47.888594 192.168.1.1 > 192.168.1.100: (frag 4176:1480@5920+) 16:20:47.889316 192.168.1.1 > 192.168.1.100: (frag 4176:928@7400) 16:20:48.380611 192.168.1.100.570982311 > 192.168.1.1.2049: 132 read [|nfs] 16:20:48.382551 192.168.1.1.2049 > 192.168.1.100.570982311: reply ok 1472 read (frag 4178:1480@0+) 16:20:48.383793 192.168.1.1 > 192.168.1.100: (frag 4178:1480@1480+) 16:20:48.385027 192.168.1.1 > 192.168.1.100: (frag 4178:1480@2960+) 16:20:48.386269 192.168.1.1 > 192.168.1.100: (frag 4178:1480@4440+) 16:20:48.387507 192.168.1.1 > 192.168.1.100: (frag 4178:1480@5920+) 16:20:48.388230 192.168.1.1 > 192.168.1.100: (frag 4178:928@7400) 16:20:48.902765 192.168.1.100.570982312 > 192.168.1.1.2049: 132 read [|nfs] 16:20:48.904730 192.168.1.1.2049 > 192.168.1.100.570982312: reply ok 1472 read (frag 4184:1480@0+) 16:20:48.905958 192.168.1.1 > 192.168.1.100: (frag 4184:1480@1480+) 16:20:48.907197 192.168.1.1 > 192.168.1.100: (frag 4184:1480@2960+) 16:20:48.908440 192.168.1.1 > 192.168.1.100: (frag 4184:1480@4440+) 16:20:48.909674 192.168.1.1 > 192.168.1.100: (frag 4184:1480@5920+) 16:20:48.910396 192.168.1.1 > 192.168.1.100: (frag 4184:928@7400) 16:20:49.424865 192.168.1.100.570982313 > 192.168.1.1.2049: 132 read [|nfs] 16:20:49.426807 192.168.1.1.2049 > 192.168.1.100.570982313: reply ok 1472 read (frag 4185:1480@0+) 16:20:49.428045 192.168.1.1 > 192.168.1.100: (frag 4185:1480@1480+) 16:20:49.429294 192.168.1.1 > 192.168.1.100: (frag 4185:1480@2960+) 16:20:49.430524 192.168.1.1 > 192.168.1.100: (frag 4185:1480@4440+) 16:20:49.431761 192.168.1.1 > 192.168.1.100: (frag 4185:1480@5920+) 16:20:49.432484 192.168.1.1 > 192.168.1.100: (frag 4185:928@7400) 16:20:49.923798 192.168.1.100.570982314 > 192.168.1.1.2049: 132 read [|nfs] 16:20:49.925723 192.168.1.1.2049 > 192.168.1.100.570982314: reply ok 1472 read (frag 4186:1480@0+) 16:20:49.926953 192.168.1.1 > 192.168.1.100: (frag 4186:1480@1480+) 16:20:49.928193 192.168.1.1 > 192.168.1.100: (frag 4186:1480@2960+) 16:20:49.929433 192.168.1.1 > 192.168.1.100: (frag 4186:1480@4440+) 16:20:49.930670 192.168.1.1 > 192.168.1.100: (frag 4186:1480@5920+) 16:20:49.931393 192.168.1.1 > 192.168.1.100: (frag 4186:928@7400) 16:20:50.446016 192.168.1.100.570982315 > 192.168.1.1.2049: 132 read [|nfs] 16:20:50.447958 192.168.1.1.2049 > 192.168.1.100.570982315: reply ok 1472 read (frag 4187:1480@0+) 16:20:50.449201 192.168.1.1 > 192.168.1.100: (frag 4187:1480@1480+) 16:20:50.450440 192.168.1.1 > 192.168.1.100: (frag 4187:1480@2960+) 16:20:50.451682 192.168.1.1 > 192.168.1.100: (frag 4187:1480@4440+) 16:20:50.452916 192.168.1.1 > 192.168.1.100: (frag 4187:1480@5920+) 16:20:50.453637 192.168.1.1 > 192.168.1.100: (frag 4187:928@7400) 16:20:50.944861 192.168.1.100.570982316 > 192.168.1.1.2049: 132 read [|nfs] 16:20:50.946783 192.168.1.1.2049 > 192.168.1.100.570982316: reply ok 1472 read (frag 4188:1480@0+) 16:20:50.948018 192.168.1.1 > 192.168.1.100: (frag 4188:1480@1480+) 16:20:50.949258 192.168.1.1 > 192.168.1.100: (frag 4188:1480@2960+) 16:20:50.950497 192.168.1.1 > 192.168.1.100: (frag 4188:1480@4440+) 16:20:50.951734 192.168.1.1 > 192.168.1.100: (frag 4188:1480@5920+) 16:20:50.952456 192.168.1.1 > 192.168.1.100: (frag 4188:928@7400) 16:20:51.467055 192.168.1.100.570982317 > 192.168.1.1.2049: 132 read [|nfs] 16:20:51.468997 192.168.1.1.2049 > 192.168.1.100.570982317: reply ok 1472 read (frag 4189:1480@0+) 16:20:51.470234 192.168.1.1 > 192.168.1.100: (frag 4189:1480@1480+) 16:20:51.471471 192.168.1.1 > 192.168.1.100: (frag 4189:1480@2960+) 16:20:51.472709 192.168.1.1 > 192.168.1.100: (frag 4189:1480@4440+) 16:20:51.473946 192.168.1.1 > 192.168.1.100: (frag 4189:1480@5920+) 16:20:51.474669 192.168.1.1 > 192.168.1.100: (frag 4189:928@7400) 16:20:51.989153 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:20:52.065579 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:20:52.215568 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:20:52.505613 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:20:53.075626 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:20:54.205731 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:20:56.456072 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:21:01.026062 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:21:10.096585 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:21:12.946619 ff:ff:ff:ff:0:40 sap 22 > 2:0:0:0:ff:ff sap 1c I (s=4,r=0,R) len=241 4500 00f1 39d0 0000 4011 bbaa c0a8 0132 c0a8 01ff 008a 008a 00dd b7a8 110a 27ba c0a8 0132 008a 00d5 0000 2045 4845 4246 4545 4643 4143 4143 4143 4143 4143 4143 4143 4143 4143 4143 4141 4100 2046 16:21:12.946836 ff:ff:ff:ff:0:40 sap 22 > 2:0:0:0:ff:ff sap 1c I (s=4,r=0,R) len=233 4500 00e9 39d1 0000 4011 bbb1 c0a8 0132 c0a8 01ff 008a 008a 00d5 51b9 110a 27bb c0a8 0132 008a 00cd 0000 2045 4845 4246 4545 4643 4143 4143 4143 4143 4143 4143 4143 4143 4143 4143 4141 4100 2041 16:21:28.107555 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:21:46.108565 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:22:04.149813 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:22:22.180487 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:22:40.131478 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:22:57.769694 arp who-has 192.168.1.1 tell 192.168.1.1 16:22:58.082424 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:22:58.082648 arp who-has 192.168.1.100 tell 192.168.1.1 16:22:58.082967 arp reply 192.168.1.100 is-at 0:80:c8:88:86:b1 16:22:58.083110 192.168.1.1 > 192.168.1.100: icmp: 192.168.1.1 udp port 2049 unreachable 16:23:10.682044 arp who-has 192.168.1.50 tell 192.168.1.9 16:23:10.682103 arp reply 192.168.1.50 is-at 0:40:5:3b:1c:23 16:23:13.907980 192.168.1.50 > 192.168.1.100: icmp: time stamp request 16:23:13.908459 192.168.1.100 > 192.168.1.50: icmp: time stamp reply 16:23:13.908667 192.168.1.50.525 > 192.168.1.100.525: udp 268 16:23:13.910198 192.168.1.100.525 > 192.168.1.50.525: udp 268 16:23:13.910338 ff:ff:ff:ff:0:40 sap 22 > 2:0:0:0:ff:ff sap 1c I (s=4,r=0,R) len=296 4500 0128 39f4 0000 4011 bb4f c0a8 0132 c0a8 01ff 020d 020d 0114 d0cb 1801 bbbd 0a2e 636f 6d00 0000 7665 6761 2e76 6567 612e 636f 6d00 0528 e82f 0628 3cf8 bfbf 1357 0528 6026 0528 0060 0628 0061 16:23:13.910397 192.168.1.50.525 > 192.168.1.255.525: udp 268 16:23:16.293438 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:23:34.244411 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:23:52.195400 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:24:10.146359 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:24:28.137336 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:24:46.088773 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] 16:25:04.039320 192.168.1.100.570982318 > 192.168.1.1.2049: 132 read [|nfs] --------------B4700A746126E4C5FBEBD274-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 8:26: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from blueyonder.co.uk (pcow029o.blueyonder.co.uk [195.188.53.123]) by hub.freebsd.org (Postfix) with ESMTP id 99B7C37B403 for ; Tue, 24 Jul 2001 08:25:52 -0700 (PDT) (envelope-from steve@mail.yahoo.com) Received: from mail.yahoo.com ([62.30.71.240]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 24 Jul 2001 16:16:09 +0100 Received: (from steve@localhost) by mail.yahoo.com (8.11.3/8.11.3) id f6OF7ii00985; Tue, 24 Jul 2001 16:07:44 +0100 (BST) (envelope-from steve) Date: Tue, 24 Jul 2001 16:07:44 +0100 From: Steve Roome To: yokota@zodiac.mech.utsunomiya-u.ac.jp Cc: freebsd-current@freebsd.org, stephen_roome@yahoo.com Subject: Re: Death sentence to KLD screen savers? Comments? Message-ID: <20010724160744.C349@dylan.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, a friend of mine just forwarded this to me. I've just been looking at writing graphical stuff, firstly screen savers for the console using vgl. In fact we were talking about this exact idea just last week. (As my code doesn't like being run in the kernel - because while it's in devel it still does the occasioanal segfault - oops!) So, I've got some work in progress for the application part of this. Are there any plans on how the kernel might go about calling the userland side of this, any docs, need proposals etc ? Personally, I'm in favour, I *hate* the kld interface for screensavers! However, I'm still using 4.3, is there a huge difference with vgl/vesa in -current ? (I assume the userland end would want to use vgl ?) Oh one other thing, it would be nice if a screensaver could be linked to a syscons vty and vgl access could be done without root perms. Or something like that. I particularly like the idea that one could choose their own screensaver if they are logged in and the system can have a default of something else when the tty is waiting on getty. So, I am VERY interested in seeing this move forward and can test things, or perhaps code things, once I've reread the style guide! > I will publish sample implementation once VESA support in -CURRENT > stabilizes. I've got a sample vgl screensaver type app that does a similar thing to fire_saver.c, just not wrapped as a screensaver yet. (It does however use al available CPU right now =)) Steve Roome P.S. I'm not subscribed to this list, so please include me in any replies. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 8:48:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp01.mem.interq.net (smtp01.mem.interq.net [210.157.1.51]) by hub.freebsd.org (Postfix) with ESMTP id 8587E37B409 for ; Tue, 24 Jul 2001 08:48:12 -0700 (PDT) (envelope-from dmnerror7894@hotmail.com) Received: from smtp.members.interq.or.jp (osakaipconnect-ppp-211-125-64-33.interq.or.jp [211.125.64.33]) by smtp01.mem.interq.net (8.9.3/8.9.1/matt89-pop) with SMTP id AAA12951 for ; Wed, 25 Jul 2001 00:47:56 +0900 (JST) Received: from mail.abox6.so-net.ne.jp (mail.abox6.so-net.ne.jp [210.139.254.148]) by mgate08.so-net.ne.jp (8.8.8+3.0Wbeta9/3.6W00101717) with ESMTP id AAA21945; Received: from default (p84c715.spprpc00.ap.so-net.ne.jp [210.132.199.21]) by mail.abox6.so-net.ne.jp (8.8.8/3.7W99081617) with SMTP id AAA15619; Date: Thu, 18 Jan 2001 02:42:02 +0900 (JST) Message-Id: <200101171742.CAA01685@mail.abox6.so-net.ne.jp> From: ts-net To: freebsd-current@freebsd.org Subject: =?ISO-2022-JP?B?GyRCOiMkTkA4M2ghIkpRJCgkRiRfJF4kOyRzJCshKRsoQg==?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG “Ë‘R‚Ėƒ[ƒ‹Žļ—į’v‚ĩ‚Ü‚·B ‚ą‚Ėƒ[ƒ‹‚ÍDMNŽÐ‚É‚æ‚č”zM‚ģ‚ę‚Ä‚Ļ‚č‚Ü‚·B ”zM‰ðœ‚Í‚ą‚ą‚Đ‚į‚ĻŠč‚Ē’v‚ĩ‚Ü‚·B http://dmn1111.tripod.com/?freebsd-current@freebsd.org ‚ą‚Ėƒ[ƒ‹‚ÉŠÖ‚·‚é‹ęî“™‚́A‚ą‚Ėƒ[ƒ‹‚ɕԐM‚đ‚ļA dmn1@lycos.ne.jp ‚Ü‚Å‚ĻŠč‚Ē’v‚ĩ‚Ü‚·B ĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄ “Ë‘R‚Ėƒ[ƒ‹‘å•ÏŽļ—į‚Ē‚―‚ĩ‚Ü‚·B‚Į‚Ī‚ž‚Ļ‹–‚ĩ‰š‚ģ‚ĒB ‚ą‚Ė‚ēˆÄ“ā‚Í‚r‚n‚g‚nEƒTƒCƒhƒrƒWƒlƒXŽwŒü‚Ė•ûŒü‚Ŋ‚Ė“ā—e‚Å‚·‚Ė‚ŁA‹ŧ–Ą‚Ė‚Č‚Ē•û‚Í‘å•Ï\‚ĩ–ó‚ ‚č‚Ü‚đ‚ņA‚ĻŽč”‚Å‚·‚Šíœ‚Č‚ģ‚Á‚ĉš‚ģ‚ĒB ĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄĄ ‚ą‚Ė‚æ‚Ī‚Č•û‚ɍœK‚ū‚ÆŽv‚í‚ę‚Ü‚·B(ŒÂl“I‚ȍl‚Ķ‚ðŠÜ‚ņ‚Å‚Ē‚Ü‚·B) œŽŸ‚ĖŽ–‹Æ“WŠJ‚ð’჊ƒXƒN‚ÅŽn‚ß‚―‚Ē•û(Ž„‚āŒÂlŽ–‹ÆŽŌ‚Å‚Q–{–Ú‚Ė’Œ‚Æ‚ĩ‚ÄŽn‚ß‚Ü‚ĩ‚―B) œĄ‚ĖķŠˆ‚Đ‚įX‚ɃXƒeƒbƒvƒAƒbƒv‚ĩ‚―‚Ē•û(ļ_“IAŒoÏ“I‚É–L‚Đ‚É‚Č‚é‚―‚߂ɁI) œŽ‚ģ‚Ē‚ĻŽq‚ģ‚ņ‚ðˆį‚Ä‚Č‚Š‚į‚āŽû“ü‚ð“ū‚―‚Ē•û(‰œ—lE’U“ß—l‚Š‹Ķ—Í“I‚Å‚ ‚ę‚ΐŽŒũ‚É1•ā‘Oi‚ĩ‚Ü‚·B) œŦ—ˆ‚Ė‚ēŽĐ•Š‚ĖķŠˆ‚ðS”z‚ĩ‚Ä‚Ē‚é•û(”N‹ā–â‘čEŽļ‹Æ—ĶUP“™‚Č‚Į) ƒ|ƒCƒ“ƒg(ŠČŒ‰‚É‚ĩ‚Ü‚·‚Æ) ‡@Œ —˜Žû“ü(‘㗝“X‚Ė‚ÝŽæ“ū‰Â”\) ‡AĪ•i‚Š‚U‚O‚O‚O–œ“_ˆČã ‡B‘ž‚ĖƒTƒCƒhƒrƒWƒlƒX‚Đ‚į‚Ė“]ŒüŽŌ‘―”(M—ŠŦ) ‡CƒOƒ‹[ƒv“ā‚Å‚Í•v•w‚Å‚ĖŽQ‰Á‚Š‘―‚Ē(‰Æ’ë‰~–ž‘ĢiH) ‡D—Ž’ĘŠv–―‚ŠŠų‚É‹N‚ą‚Á‚Ä‚Ē‚éB(ƒlƒbƒgƒrƒWƒlƒX) ĄĄĄĒŠEÅ‘勉‚ĖƒCƒ“ƒ^[ƒlƒbƒgEƒVƒ‡ƒbƒsƒ“ƒOƒ‚[ƒ‹‚Š“ú–{ã—ĪIĄĄĄ ‹M•û‚ā‚ą‚ĖƒVƒ‡ƒbƒsƒ“ƒOƒ‚[ƒ‹‚Ė‘㗝“X‚É‚Č‚Á‚āAķŠU‚É“n‚čŒ…ˆá‚Ē‚Ė‚Š“ū‚ð“ū‘ą‚Ŋ‚é‚ą‚Æ‚Šo—ˆ‚Ü‚·B ŒŧÝAƒƒ‹ƒ}ƒK‚âŒfŽĶ”“™‚ÉŒfÚ‚ģ‚ę‚Ä‚Ē‚éL‚Ė–ņ‚QŠ„‹ß‚­‚Š‚ą‚ĖƒrƒWƒlƒX‚ÉŽQ‰Á‚ģ‚ę‚Ä‚Ē‚é•ûX‚ĖŒfÚL‚Å‚·B ‚ą‚ę‚Đ‚į‚Ė—Ž’Ę‚Š‚Į‚Ī‚Č‚Á‚Ä‚Ē‚­‚Đ‚ð‚Ē‚ŋ‘‚­—‰ð‚ĩŽž‘ã‚Ė—Ž‚ę‚ð“IŠm‚É’Í‚ņ‚Å‚Ļ‚į‚ę‚é‘―‚­‚Ė•ûX‚Š‚ą‚ĖŽdŽ–‚ðŽxŽ‚ĩŽQ‰Á‚ģ‚ę‚Ä‚Ē‚é‚Ė‚Å‚·B ŽQ‰Á‚Č‚ģ‚Á‚―•ûX‚ÍŠFˆę—l‚ÉŽĐ•Š‚ĖŽžŠÔ‚Ė‹–‚·”͈͂Ŗē‚ÉŒü‚Đ‚Á‚ÄŠæ’Ģ‚Á‚Ä‚Ļ‚į‚ę‚Ü‚·B Ą‚Č‚į‚Ü‚ūŽQ‰Á‚·‚é‚Ė‚É’x‚­‚Í‚ ‚č‚Ü‚đ‚ņAĨ”ņŽ‘—ŋ‚ð‚ēŋ‹‚Ē‚―‚ū‚Ŧ‘åĻ‚Ė•û‚Š^–Ę–Ú‚ÉŽæ‚č‘g‚ņ‚Å‚Ē‚é‚ą‚ĖƒrƒWƒlƒX‚ð’m‚Á‚Ä‚­‚ū‚ģ‚ĒB ‚VŒ…ˆČã‚ĖŒŽŽû‚ā[•Š‚ɉ”\‚Å‚·B Œˆ‚ĩ‚Ä‚Ē‚Ē‰ÁŒļ‚ČƒrƒWƒlƒX‚Å‚Í‚ ‚č‚Ü‚đ‚ņB ƒrƒWƒlƒX‚ÉŽg—p‚·‚é‹M•ûę—p‚Ėƒz[ƒ€ƒy[ƒW‚ā‚ē—pˆÓ‚Ē‚―‚ĩ‚Ü‚·B ƒz[ƒ€ƒy[ƒWŒĐ–{@http://www.jp.bigplanet.com ã‹L‚Ėƒz[ƒ€ƒy[ƒW‚Š‚ ‚Č‚―ę—p‚É—pˆÓ‚ģ‚ę‚Ü‚·A‚ā‚ŋ‚ë‚ņƒT[ƒo[‚ā‚Ē‚č‚Ü‚đ‚ņ‚ĩƒƒ“ƒeƒiƒ“ƒX‚âXV‚ā‚·‚Ũ‚Ä–{ŽÐ‚ōs‚Ē‚Ü‚·B ‹M•û‚Š‘㗝“X‚Æ‚ĩ‚ĐŽŒũ‚·‚é‚―‚ß‚ÉŽ„’B‚Í‹Ķ—Í‚ðÉ‚ĩ‚Ý‚Ü‚đ‚ņB ‚ą‚ĖƒrƒWƒlƒX‚Ö‚ĖŽQ‰Á‚͌lE–@l‚ð–â‚Ē‚Ü‚đ‚ņB‚P“ú‚R‚O•Š`‚PŽžŠÔ’öAƒpƒ\ƒRƒ“‚ðŽg‚ĪŽžŠÔ‚ŠŽæ‚ę‚ę‚΂n‚j‚Å‚·I ƒŠƒXƒgƒ‰‚ÅŽļ‹Æ‚ĩ‚―•û‚âŽå•wEƒTƒ‰ƒŠ[ƒ}ƒ“E’†ŽŠé‹Æ‚ĖƒI[ƒi[‚ģ‚ņ‚Š‘ąX‚Æ ŽQ‰Á‚ĩ‚Ä‚Ē‚Ü‚·B(ŒŧŽĀ‚ɐlķŠÏ‚Š•Ï‚í‚é‚Ų‚Į‚ĖŠ“ū‚ð“ū‚Ä‚Ē‚Ü‚·) ‚ą‚ĖƒrƒWƒlƒX‚́u•Ļ‚𔄂évŽ–‚ŠŽû“ü‚ɂ‚ȂŠ‚é‚Æ‚Ē‚Ī‚ū‚Ŋ‚Ė’Pƒ‚ČƒrƒWƒlƒX‚Å ‚Í‚ ‚č‚Ü‚đ‚ņAÚŨ‚ÍŽ‘—ŋ‚ð‚ēŋ‹‚Ėã‚ē——‚­‚ū‚ģ‚ĒB Œ —˜Žû“ü‚ɂ‚Ē‚ďڂĩ‚­‹LÚ‚ĩ‚Ä‚ ‚č‚Ü‚·B •åWŠúŠÔ‚ÍŒĀ’č‚ģ‚ę‚Ä‚Ē‚Ü‚·‚Ė‚Å‹ŧ–Ą‚Š‚ ‚č‚Ü‚ĩ‚―‚įA‚·‚Ū‚ÉŽ‘—ŋ‚ð‚ēŋ‹‰š‚ģ‚ĒB ÚŨ‚ČŽ‘—ŋ‚͉š‹Lƒz[ƒ€ƒy[ƒW‚Ė’†‚ÉŽ‘—ŋŋ‹ƒtƒH[ƒ€‚Š—L‚č‚Ü‚·‚Ė‚Å•K—vŽ–€ ‚ðŒä‹L“ü‚Ėã‚ē‘—M‰š‚ģ‚ĒB ĄƒrƒWƒlƒXŠT—vŋ‹ƒz[ƒ€ƒy[ƒW @@http://www.ts-network.ne.jp/~ts-net/ ĄĄ‚ą‚ĖƒrƒWƒlƒX‚Ė“Á’ĨĄĄ@‘åŠé‹Æ‚ŠƒrƒWƒlƒXƒvƒ‰ƒ“‚ð’ņ‹Ÿ ‡@ ĒŠEÅ‘勉‚ĖuƒCƒ“ƒ^[ƒlƒbƒgEƒVƒ‡ƒbƒsƒ“ƒOƒ‚[ƒ‹v ‡A ĒŠE’†‚Ėˆę—ŽŠé‹Æ‚ŠĪÞ‚ð’ņ‹Ÿ ‡B ƒŠƒXƒNEƒmƒ‹ƒ}EÝŒÉE–K–â”Ė”„@ˆęØ–ģ‚ĩ ‡C Åæ’[‚Ė‚l‚k‚lƒrƒWƒlƒX(ˆę‹ī‘åŠw‘ž‚ŐģŽŪ‚ÉŽö‹Æ‚ÉŽæ‚č“ü‚ę‚Ä‚Ē‚Ü‚·) ‡D ‚Š“ū‚͐ķŠUŒp‘ą(Ž–‹ÆŒ —˜‚͉Ƒ°‚É‚Ė‚Ý‘Š‘ą‰Â”\) ‡E –œ‘S‚Ė‹Ķ—Í‘Ė§ ‡F@‚r‚n‚g‚n(ƒXƒ‚[ƒ‹ƒIƒtƒBƒXEƒz[ƒ€ƒIƒtƒBƒX)‚âƒTƒCƒhƒrƒWƒlƒX‚ʼn”\ ‡G@ŽQ‰Á‚É“Á•Ę‚ČŽ‘Ši‚Í•K—v‚Č‚ĩ ÚŨŽ‘—ŋ‚ð‚ē——’ļ‚Ē‚―ã‚ŁA‹^–â“_‚â‚ēŽŋ–â‚Š‚ē‚ī‚Ē‚Ü‚ĩ‚―‚į‚Ļ‹CŒy‚ɉš‹L‚Ü‚Å ‚Ļ –â ‚Ē‡‚í‚đ‚­‚ū‚ģ‚ĒB ÅŒã‚Ü‚Å‚Ļ“Į‚Ý‚Ē‚―‚ū‚ŦA―‚É‚ ‚č‚Š‚Æ‚Ī‚ē‚ī‚Ē‚Ü‚ĩ‚―B ******************************************************************************** Ts-NET ‚i‚`‚o‚`‚mC‚b‚ ’S“–@‰–āV‚Ä‚éŽq L—p@ƒz[ƒ€ƒy[ƒW@ http://www.ts-network.ne.jp/~ts-net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 10:15: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (sat.dis.org [216.240.44.14]) by hub.freebsd.org (Postfix) with ESMTP id C5F6F37B407 for ; Tue, 24 Jul 2001 10:14:40 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f6NKbx201647; Mon, 23 Jul 2001 13:37:59 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200107232037.f6NKbx201647@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: "neckpain@nettaxi.com" Cc: current@freebsd.org Subject: Re: acpica malfunctions In-reply-to: Your message of "Mon, 23 Jul 2001 05:31:07 PDT." <200107231231.FAA09442@mail21.bigmailbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Jul 2001 13:37:59 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > 1. Acpica modules hangs in > > > AcpiRsCalculateByteStreamLength() called from > > > AcpiRsCreateByteStream() called from > > > AcpiRsSetSrsMethodData() called from > > > AcpiSetCurrentResources() from somewhere in acpi_pcib.c . > > > > > > The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length > == 0 > > > . > > > > Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484? > > I think I should be passing a pointer to the buffer, not a pointer to a > > pointer. > > There's no &crsbuf in line 484 (not in rev 1.10, nor 1.11). > > Assuming you're talking about the one in line 478, it doesn't compile if you > change it to crsbuf from &crsbuf, since crsbuf is an ACPI_BUFFER, not > an (ACPI_BUFFER *). Um. Sorry about the line numbers, and yes, sorry about the confusion there; I just looked at it and it seemed wrong. I'd still like to know the allocation length for that buffer though; my last suspicion is that it doesn't contain any resources at all, and so we're overrunning it when we go to try to stuff an interrupt resource into it. If that's the case, it's easy to fix. If not, then we will have to go hunting snarks. Thanks. Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 11:22:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from APastourelles-102-1-2-26.abo.wanadoo.fr (APastourelles-102-1-2-26.abo.wanadoo.fr [217.128.208.26]) by hub.freebsd.org (Postfix) with ESMTP id 2799C37B401 for ; Tue, 24 Jul 2001 11:22:15 -0700 (PDT) (envelope-from olive@deep-ocean.net) Received: by APastourelles-102-1-2-26.abo.wanadoo.fr (Postfix, from userid 1001) id EDCA925442; Tue, 24 Jul 2001 20:22:13 +0200 (CEST) Date: Tue, 24 Jul 2001 20:22:13 +0200 From: Olivier Cortes To: freebsd-current@freebsd.org Subject: build problem ? Message-ID: <20010724202213.A77937@APastourelles-102-1-2-26.abo.wa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.3-RC i386 up 5 days, 15:23 Organization: Deep-Ocean Network X-URL: http://www.deep-ocean.net/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hi ! i cvsuped 20 minutes ago. when i try to build (-j 6), it says: ------------------------------------------ lex -t -I /usr/build/src/usr.sbin/pcvt/kbdio/lex.l > lex.c yacc: 2 shift/reduce conflicts cp y.tab.c kbdio.c rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/build/obj/usr/build/src/usr.sbin/pcvt/kbdio -I/usr/build/src/usr.sbin/pcvt/kbdio -I/usr/obj/usr/build/src/i386/usr /include kbdio.c lex.c cd /usr/build/src/usr.sbin/pcvt/kbdio; make _EXTRADEPEND echo kbdio: /usr/obj/usr/build/src/i386/usr/lib/libc.a /usr/obj/usr/build/src/i386/usr/lib/libm.a /usr/obj/usr/build/src/i386/usr/lib/liby.a /usr/obj/usr /build/src/i386/usr/lib/libl.a >> .depend ===> usr.sbin/pcvt/demo rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/pcvt/demo/playvt.c cd /usr/build/src/usr.sbin/pcvt/demo; make _EXTRADEPEND echo playvt: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/pcvt/Misc ===> usr.sbin/pcvt/Misc/Doc ===> usr.sbin/pcvt/Misc/Etc ===> usr.sbin/sgsc rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/sgsc/sgsc.c cd /usr/build/src/usr.sbin/sgsc; make _EXTRADEPEND echo sgsc: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/sicontrol rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/build/src/usr.sbin/sicontrol/../../sys -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/sicontro l/sicontrol.c cd /usr/build/src/usr.sbin/sicontrol; make _EXTRADEPEND echo sicontrol: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/spkrtest ===> usr.sbin/stallion ===> usr.sbin/stallion/bootcode ===> usr.sbin/stallion/stlload rm -f .depend mkdep -f .depend -a -nostdinc -DBOOTDIR=\"/usr/libdata/stallion\" -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/stallion/stlload/s tlload.c cd /usr/build/src/usr.sbin/stallion/stlload; make _EXTRADEPEND echo stlload: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/stallion/stlstats rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/stallion/stlstats/stlstats.c cd /usr/build/src/usr.sbin/stallion/stlstats; make _EXTRADEPEND echo stlstats: /usr/obj/usr/build/src/i386/usr/lib/libc.a /usr/obj/usr/build/src/i386/usr/lib/libncurses.a >> .depend ===> usr.sbin/wlconfig rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/wlconfig/wlconfig.c cd /usr/build/src/usr.sbin/wlconfig; make _EXTRADEPEND echo wlconfig: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend ===> usr.sbin/boot0cfg rm -f .depend mkdep -f .depend -a -nostdinc -I/usr/obj/usr/build/src/i386/usr/include /usr/build/src/usr.sbin/boot0cfg/boot0cfg.c cd /usr/build/src/usr.sbin/boot0cfg; make _EXTRADEPEND echo boot0cfg: /usr/obj/usr/build/src/i386/usr/lib/libc.a >> .depend 1 error *** Error code 2 1 error *** Error code 2 1 error ------------------------------ i couln't find the exact error point... i have a full make.out (make -j 6 buildworld) at http://www.deep-ocean.net/~olive/files/make.out if you want to look at it. i know broken builds are frequent under -CURRENT, but i couldn't figure the source of this one. advises are welcome. (at http://www.deep-ocean.net/~olive/files/, i'll put a dmesg.out, my kernel file (renamed kernel.out ; otherwise it is NEPTUNE). It's always good to have them near.) and sorry for my approximate english, it's not my native language. regards, --- Olivier Cortes To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 11:47:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from gifw.genroco.com (genroco.com [205.254.195.202]) by hub.freebsd.org (Postfix) with ESMTP id 6188E37B401 for ; Tue, 24 Jul 2001 11:47:15 -0700 (PDT) (envelope-from hetzels@westbend.net) Received: from gi2.genroco.com (IDENT:root@gi2.genroco.com [192.133.120.3]) by gifw.genroco.com (8.9.3/8.9.3) with ESMTP id NAA10998; Tue, 24 Jul 2001 13:47:13 -0500 Received: from scot.genroco.com (scot.genroco.com [192.133.120.125]) by gi2.genroco.com (8.9.3/8.9.3) with SMTP id NAA19828; Tue, 24 Jul 2001 13:47:09 -0500 Message-ID: <00f001c11471$0cb17160$7d7885c0@genroco.com> From: "Scot W. Hetzel" To: "Olivier Cortes" , References: <20010724202213.A77937@APastourelles-102-1-2-26.abo.wa> Subject: Re: build problem ? Date: Tue, 24 Jul 2001 13:47:07 -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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG From: "Olivier Cortes" > i cvsuped 20 minutes ago. > > when i try to build (-j 6), it says: > > > i couln't find the exact error point... i have a full make.out (make > -j 6 buildworld) at http://www.deep-ocean.net/~olive/files/make.out if > you want to look at it. > > i know broken builds are frequent under -CURRENT, but i couldn't > figure the source of this one. advises are welcome. > When you have a build failure using -j x (x > 1), you need to restart the build without -j in order to get any meaningful info from the build failure. Scot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 12:20:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from gta.com (mailgate.gta.com [199.120.225.4]) by hub.freebsd.org (Postfix) with ESMTP id 1F8AA37B403 for ; Tue, 24 Jul 2001 12:20:55 -0700 (PDT) (envelope-from lab@gta.com) Received: from gta.com (GTA internal mail system) by gta.com id PAA60603; Tue, 24 Jul 2001 15:20:34 -0400 (EDT) Date: Tue, 24 Jul 2001 15:20:34 -0400 (EDT) Message-Id: <200107241920.PAA60603@gta.com> From: Larry Baird To: freebsd-current@freebsd.org Subject: Re: Death sentence to KLD screen savers? Comments? In-Reply-To: <20010724160744.C349@gta.com> User-Agent: tin/1.4.2-20000205 ("Possession") (UNIX) (FreeBSD/3.5-STABLE (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In standard FreeBSD the moving of screen savers to userland may not be a big deal. In Embedded applications it is nice to be able to create very lightweight (read size) screen savers. Hopefully this new mechanism will still allow this. (-; Larry -- ------------------------------------------------------------------------ Larry Baird | http://www.gnatbox.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 12:25: 8 2001 Delivered-To: freebsd-current@freebsd.org Received: from nebula.anchoragerescue.org (cable-115-7-237-24.anchorageak.net [24.237.7.115]) by hub.freebsd.org (Postfix) with ESMTP id 8C1B437B405 for ; Tue, 24 Jul 2001 12:23:38 -0700 (PDT) (envelope-from akbeech@anchoragerescue.org) Received: from galaxy.anchoragerescue.org (galaxy.anchoragerescue.org [24.237.7.95]) by nebula.anchoragerescue.org (Postfix) with SMTP id B11F14FB for ; Tue, 24 Jul 2001 11:23:16 -0800 (AKDT) Content-Type: text/plain; charset="iso-8859-1" From: Beech Rintoul To: freebsd-current@freebsd.org Subject: device.hints Date: Tue, 24 Jul 2001 11:23:16 -0800 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01072411231609.06676@galaxy.anchoragerescue.org> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I want to experiment with current. All went well on the build, but when I try and install the kernel it stops telling me to install a "device.hints" file. What do I need to do? I tried re-compiling the kernel with the "static" line uncomented, but same problem on install. TIA, Beech -- Micro$oft: "Where can we make you go today?" ------------------------------------------------------------------- Beech Rintoul - IT Manager - Instructor - akbeech@anchoragerescue.org /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ ----------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 12:35:21 2001 Delivered-To: freebsd-current@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id EBE3A37B406 for ; Tue, 24 Jul 2001 12:35:17 -0700 (PDT) (envelope-from vince@oahu.WURLDLINK.NET) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.11.3/8.11.3) with ESMTP id f6OJYgW83589; Tue, 24 Jul 2001 09:34:42 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Tue, 24 Jul 2001 09:34:41 -1000 (HST) From: Vincent Poy To: Beech Rintoul Cc: Subject: Re: device.hints In-Reply-To: <01072411231609.06676@galaxy.anchoragerescue.org> Message-ID: <20010724093402.D50475-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 24 Jul 2001, Beech Rintoul wrote: > I want to experiment with current. All went well on the build, but when I try > and install the kernel it stops telling me to install a "device.hints" file. > What do I need to do? I tried re-compiling the kernel with the "static" line > uncomented, but same problem on install. What you need to do is before installing the kernel... cp -p /usr/src/sys/i386/conf/GENERIC.hints /boot/device.hints Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 12:36:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by hub.freebsd.org (Postfix) with ESMTP id E55CC37B401 for ; Tue, 24 Jul 2001 12:36:27 -0700 (PDT) (envelope-from brdavis@odin.ac.hmc.edu) Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) id f6OJaIQ16276; Tue, 24 Jul 2001 12:36:18 -0700 Date: Tue, 24 Jul 2001 12:36:18 -0700 From: Brooks Davis To: Beech Rintoul Cc: freebsd-current@FreeBSD.ORG Subject: Re: device.hints Message-ID: <20010724123618.B14224@Odin.AC.HMC.Edu> References: <01072411231609.06676@galaxy.anchoragerescue.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="rJwd6BRFiFCcLxzm" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01072411231609.06676@galaxy.anchoragerescue.org>; from akbeech@anchoragerescue.org on Tue, Jul 24, 2001 at 11:23:16AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --rJwd6BRFiFCcLxzm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 24, 2001 at 11:23:16AM -0800, Beech Rintoul wrote: > I want to experiment with current. All went well on the build, but when I= try=20 > and install the kernel it stops telling me to install a "device.hints" fi= le. > What do I need to do? I tried re-compiling the kernel with the "static" l= ine=20 > uncomented, but same problem on install. The short answer is that you can copy sys/i386/conf/GENERIC.hints to /boot/device.hints. If you have devices that you have needed to configured in your kernel or with userconfig you may need to add or modify this file somewhat. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --rJwd6BRFiFCcLxzm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Xc4xXY6L6fI4GtQRAgkaAJ4pn0Y4PfGUfqpGKgiVLlDywtq33ACeKOYq t8hw62ocdN6C7FNEaOy8Gsc= =iXCV -----END PGP SIGNATURE----- --rJwd6BRFiFCcLxzm-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 12:53:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.127.132]) by hub.freebsd.org (Postfix) with ESMTP id E10FD37B401 for ; Tue, 24 Jul 2001 12:53:48 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp3.xs4all.nl (8.9.3/8.9.3) with ESMTP id VAA18031; Tue, 24 Jul 2001 21:53:47 +0200 (CEST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.4/8.11.4) id f6OJZG101369; Tue, 24 Jul 2001 21:35:16 +0200 (CEST) (envelope-from wkb) Date: Tue, 24 Jul 2001 21:35:16 +0200 From: Wilko Bulte To: Beech Rintoul Cc: freebsd-current@FreeBSD.ORG Subject: Re: device.hints Message-ID: <20010724213516.A1349@freebie.xs4all.nl> References: <01072411231609.06676@galaxy.anchoragerescue.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01072411231609.06676@galaxy.anchoragerescue.org>; from akbeech@anchoragerescue.org on Tue, Jul 24, 2001 at 11:23:16AM -0800 X-OS: FreeBSD 4.3-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 24, 2001 at 11:23:16AM -0800, Beech Rintoul wrote: > I want to experiment with current. All went well on the build, but when I try > and install the kernel it stops telling me to install a "device.hints" file. > What do I need to do? I tried re-compiling the kernel with the "static" line > uncomented, but same problem on install. Do what it asks you: copy GENERIC.hints into the right spot as boot.hints -- | / o / / _ Arnhem, The Netherlands email: wilko@FreeBSD.org |/|/ / / /( (_) Bulte "Youth is not a time in life, it is a state of mind" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 13:17:19 2001 Delivered-To: freebsd-current@freebsd.org Received: from naboo.ethz.ch (naboo.ethz.ch [129.132.17.66]) by hub.freebsd.org (Postfix) with ESMTP id A420837B401; Tue, 24 Jul 2001 13:17:14 -0700 (PDT) (envelope-from carlo@vis.ethz.ch) Received: by naboo.ethz.ch (Postfix, from userid 224) id 5E16E275B6; Tue, 24 Jul 2001 22:17:13 +0200 (CEST) Subject: GNU smalltalk, can't run version 1.96 To: freebsd-current@freebsd.org Date: Tue, 24 Jul 2001 22:17:13 +0200 (CEST) Cc: freebsd-stable@freebsd.org X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010724201713.5E16E275B6@naboo.ethz.ch> From: carlo@vis.ethz.ch (Carlo Dapor) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dear fellow current people It is a quest for the Holy Grail I have embarked weeks ago. The harbours I have peered are: FreeBSD 4.3 and FreeBSD current. The last version I was able to build and run the tests is version 1.8.5, with some patches, both on 4.3 and current. But what I am not successfull with is neither with 1.96 or 1.95.x. I compiles on 4.3 and current, but at runtime I get a segfault. On 4.3, the offending showstopper is around the definition of primitive 184_185 (or similar), whereas on current it around the definition of primitive 203_204, I think. Interestingly, it compiles and runs smoothly on an SMP Linux 2.2.19. I also tried with gcc 3.0 on current, same result. Has anybody had more luck ? Tell me HOW, please. Ciao, derweil, -- Carlo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 13:51:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from nebula.anchoragerescue.org (cable-115-7-237-24.anchorageak.net [24.237.7.115]) by hub.freebsd.org (Postfix) with ESMTP id 17FA137B401 for ; Tue, 24 Jul 2001 13:51:44 -0700 (PDT) (envelope-from akbeech@anchoragerescue.org) Received: from galaxy.anchoragerescue.org (galaxy.anchoragerescue.org [24.237.7.95]) by nebula.anchoragerescue.org (Postfix) with SMTP id 7418F4FB for ; Tue, 24 Jul 2001 12:51:39 -0800 (AKDT) Content-Type: text/plain; charset="iso-8859-1" From: Beech Rintoul To: freebsd-current@freebsd.org Subject: Re: device.hints Date: Tue, 24 Jul 2001 12:51:39 -0800 X-Mailer: KMail [version 1.2] References: <01072411231609.06676@galaxy.anchoragerescue.org> In-Reply-To: <01072411231609.06676@galaxy.anchoragerescue.org> MIME-Version: 1.0 Message-Id: <0107241251390A.06676@galaxy.anchoragerescue.org> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tuesday 24 July 2001 11:23 am, Beech Rintoul wrote: > I want to experiment with current. All went well on the build, but when I > try and install the kernel it stops telling me to install a "device.hints" > file. What do I need to do? I tried re-compiling the kernel with the > "static" line uncomented, but same problem on install. > > TIA, > > Beech Thanks much :-) Beech -- Micro$oft: "Where can we make you go today?" ------------------------------------------------------------------- Beech Rintoul - IT Manager - Instructor - akbeech@anchoragerescue.org /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ ----------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 14:31:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from APastourelles-102-1-2-26.abo.wanadoo.fr (APastourelles-102-1-2-26.abo.wanadoo.fr [217.128.208.26]) by hub.freebsd.org (Postfix) with ESMTP id A5FEA37B405 for ; Tue, 24 Jul 2001 14:31:43 -0700 (PDT) (envelope-from olive@deep-ocean.net) Received: by APastourelles-102-1-2-26.abo.wanadoo.fr (Postfix, from userid 1001) id 8129E25442; Tue, 24 Jul 2001 23:31:42 +0200 (CEST) Date: Tue, 24 Jul 2001 23:31:42 +0200 From: Olivier Cortes To: freebsd-current@freebsd.org Subject: Re: Re: build problem ? Message-ID: <20010724233142.A81766@APastourelles-102-1-2-26.abo.wa> References: <20010724202213.A77937@APastourelles-102-1-2-26.abo.wa> <00f001c11471$0cb17160$7d7885c0@genroco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00f001c11471$0cb17160$7d7885c0@genroco.com>; from hetzels@westbend.net on Tue, Jul 24, 2001 at 01:47:07PM -0500 X-Operating-System: FreeBSD 4.3-RC i386 up 5 days, 18:54 Organization: Deep-Ocean Network X-URL: http://www.deep-ocean.net/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 24, 2001 at 01:47:07PM -0500, Scot W. Hetzel wrote: > When you have a build failure using -j x (x > 1), you need to restart the > build without -j in order to get any meaningful info from the build failure. fool, fool, fool am i. here it is : -------------------------- mkdep -f .depend -a -nostdinc -DDISASSEMBLER -DNO_X -I/usr/obj/usr/build/src/i 386/usr/include /usr/build/src/usr.bin/doscmd/AsyncIO.c /usr/build/src/usr.bin/ doscmd/ParseBuffer.c /usr/build/src/usr.bin/doscmd/bios.c /usr/build/src/usr.bin /doscmd/callback.c /usr/build/src/usr.bin/doscmd/cpu.c /usr/build/src/usr.bin/do scmd/dos.c /usr/build/src/usr.bin/doscmd/cmos.c /usr/build/src/usr.bin/doscmd/co nfig.c /usr/build/src/usr.bin/doscmd/cwd.c /usr/build/src/usr.bin/doscmd/debug.c /usr/build/src/usr.bin/doscmd/disktab.c /usr/build/src/usr.bin/doscmd/doscmd.c /usr/build/src/usr.bin/doscmd/ems.c /usr/build/src/usr.bin/doscmd/emuint.c /usr/ build/src/usr.bin/doscmd/exe.c /usr/build/src/usr.bin/doscmd/i386-pinsn.c /usr/b uild/src/usr.bin/doscmd/int.c /usr/build/src/usr.bin/doscmd/int10.c /usr/build/s rc/usr.bin/doscmd/int13.c /usr/build/src/usr.bin/doscmd/int14.c /usr/build/src/u sr.bin/doscmd/int16.c /usr/build/src/usr.bin/doscmd/int17.c /usr/build/src/usr.b in/doscmd/int1a.c /usr/build/src/usr.bin/doscmd/int2f.c /usr/build/src/usr.bin/d oscmd/intff.c /usr/build/src/usr.bin/doscmd/mem.c /usr/build/src/usr.bin/doscmd/ mouse.c /usr/build/src/usr.bin/doscmd/net.c /usr/build/src/usr.bin/doscmd/port.c /usr/build/src/usr.bin/doscmd/setver.c /usr/build/src/usr.bin/doscmd/signal.c / usr/build/src/usr.bin/doscmd/timer.c /usr/build/src/usr.bin/doscmd/trace.c /usr/ build/src/usr.bin/doscmd/trap.c /usr/build/src/usr.bin/doscmd/tty.c /usr/build/s rc/usr.bin/doscmd/video.c /usr/build/src/usr.bin/doscmd/xms.c /usr/build/src/usr.bin/doscmd/tty.c:66: font8x8.h: No such file or directory /usr/build/src/usr.bin/doscmd/tty.c:67: font8x14.h: No such file or directory /usr/build/src/usr.bin/doscmd/tty.c:68: font8x16.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/build/src/usr.bin/doscmd. *** Error code 1 Stop in /usr/build/src/usr.bin. *** Error code 1 Stop in /usr/build/src. *** Error code 1 Stop in /usr/build/src. *** Error code 1 Stop in /usr/build/src. --------------------------------------------- yesterday, the kernel didn't compile, but world did. today it's the contrary... thanks for the advice. sure i must have done it BEFORE sending the mail. sorry. Olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 14:40: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from nisser.com (c0039.upc-c.chello.nl [212.187.0.39]) by hub.freebsd.org (Postfix) with ESMTP id C44A637B401; Tue, 24 Jul 2001 14:39:55 -0700 (PDT) (envelope-from roelof@eboa.com) Received: from eboa.com (roelof [10.0.0.2]) by nisser.com (8.11.4/8.11.4) with ESMTP id f6OLdpC06851; Tue, 24 Jul 2001 23:39:51 +0200 (CEST) (envelope-from roelof@eboa.com) Message-ID: <3B5DEB27.DBAB98EB@eboa.com> Date: Tue, 24 Jul 2001 23:39:51 +0200 From: Roelof Osinga Organization: eBOA - Programming the Web X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Carlo Dapor Cc: freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: GNU smalltalk, can't run version 1.96 References: <20010724201713.5E16E275B6@naboo.ethz.ch> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Carlo Dapor wrote: > > Dear fellow current people > > It is a quest for the Holy Grail I have embarked weeks ago. > The harbours I have peered are: FreeBSD 4.3 and FreeBSD current. > ... In case you hadn't heard... Holy Grail is spelt 'squeak' . I can confirm that squeak runs fine on F.BSD 3.x. Haven't had time to reinstall on 4.x. Honestly :). Roelof -- _______________________________________________________________________ eBOAŪ est. 1982 http://eBOA.com/ tel. +31-58-2123014 mailto:info@eBOA.com?subject=Information_request fax. +31-58-2160293 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 15:58:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id BD2EA37B406 for ; Tue, 24 Jul 2001 15:58:55 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id RAA21046 for ; Tue, 24 Jul 2001 17:10:05 -0700 (PDT) Date: Tue, 24 Jul 2001 17:10:04 -0700 (PDT) From: Julian Elischer To: current@freebsd.org Subject: -current logjammed? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I sent a message to here this morning and didn't see it, then again this afternoon. Still haven't seen it come back to me (and no answers) I wonder if I'll see this? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 15:59:48 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 0727437B405 for ; Tue, 24 Jul 2001 15:59:36 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA20797 for ; Tue, 24 Jul 2001 13:01:35 -0700 (PDT) Date: Tue, 24 Jul 2001 13:01:34 -0700 (PDT) From: Julian Elischer To: freebsd-current@freebsd.org Subject: This look familiar to anyone? (bug in 4.11 maybe) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I know this is not a -current problem, but if it was fixed by someone they are likely to be reading here, and not in -stable.. We have a hybrid (4.11+patches) kernel that sometimes crashes. The crash always has teh same symptoms and I'm hoping that they look familiar to someone... The message is below, followed by analysis. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xe6b95cc8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01846d9 stack pointer = 0x10:0xc954de64 frame pointer = 0x10:0xc954de84 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 = 10326 (qftListener) interrupt mask = none trap number = 12 In a VFS operation, %ecx get's corrupted (maybe from an interrupt?) betweeen the instruction where it's loaded with a constant, and the instruction where it's used... It'always the same instruction, though often in DIFFERENT VFS instructions (fsync, bwrite so far) the trap frame usually looks like: #4 0xc0251813 in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10, tf_edi = 0x0, tf_esi = 0x1, tf_ebp = 0xc954de84, tf_isp = 0xc954de50, tf_ebx = 0xc27d6d80, tf_edx = 0xc1344600, tf_ecx = 0xc96145b2, tf_eax = 0xc954de78, tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc01846d9, tf_cs = 0x8, tf_eflags = 0x10286, tf_esp = 0xc954de78, tf_ss = 0xc27d6d80}) at /usr/src/sys/i386/i386/trap.c:443 #5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923 #6 0xc0189be2 in vop_stdbwrite (ap=0xc954deb4) at /usr/src/sys/kern/vfs_default.c:319 the code there looks like: (kgdb) up 5 #5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923 923 rc = VCALL(vp, VOFFSET(vop_strategy), &a); (kgdb) list 918 struct vop_strategy_args a; 919 int rc; 920 a.a_desc = VDESC(vop_strategy); 921 a.a_vp = vp; 922 a.a_bp = bp; 923 rc = VCALL(vp, VOFFSET(vop_strategy), &a); <-------here 924 return (rc); 925 } 926 struct vop_print_args { 927 struct vnodeop_desc *a_desc; In Assembler: 0xc01846cc : mov 0xc029dcc0,%ecx 0xc01846d2 : mov 0x18(%eax),%edx 0xc01846d5 : lea 0xfffffff4(%ebp),%eax 0xc01846d8 : push %eax 0xc01846d9 : mov (%edx,%ecx,4),%eax <<<<< **POW** 0xc01846dc : call *%eax 0xc01846de : add $0x4,%esp 0xc01846e1 : mov 0xfffffff0(%ebp),%eax looking at the regs, dx = 0xc1344600, cx = 0xc96145b2, and C1344600+(4*C96145B2) = 3E6B95CC8 the lower 32 bits of which is the same as the fault address but in the code above we see that %cx was just loaded from location 0xc029dcc0 which contains: (kgdb) x/x 0xc029dcc0 0xc029dcc0 : 0x12 0x12 is the correct offset for a strategy call. so cx got corrupted between the instruction at 0xc01846cc and that at 0xc01846d9. Note that the contents of cx (0xc96145b2) is an address somewhat higher than the kernel stack at the time in question. a dump of ram in that area shows: (kgdb) x/64xw 0xc96145a0 0xc96145a0: 0xc954e900 0xc9709c00 0x00000000 0xc96145a8 0xc96145b0: [0xc9580660] 0xc95c7370 0xc04d7504 0xc04d47d4 0xc96145c0: 0x0000aa26 0x00000020 0x00000000 0x00000000 0xc96145d0: 0xfc812c38 0x00000002 0x00040010 0x00000020 0xc96145e0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc96145f0: 0x00000000 0xc9636a40 0x0001fc93 0x00000000 0xc9614600: 0xc02ed7c0 0xc95b4120 0x00000000 0xc9614608 0xc9614610: 0x00000000 0xc9555548 0x00000000 0xc9614618 0xc9614620: 0x00003f5b 0x00000003 0x00000000 0x00000000 0xc9614630: 0xfe37c115 0x21880000 0x0000000e 0x00000000 0xc9614640: 0x00000000 0x00000000 0x00000000 0x00000000 0xc9614650: 0x00000000 0x00000000 0x00000000 0x00000000 0xc9614660: 0xc9722ae0 0xc961c600 0x00000000 0xc9614668 0xc9614670: 0xc9690660 0xc97091f0 0x00000000 0xc9614678 0xc9614680: 0x0000cabf 0x00000012 0x00000000 0x00000000 0xc9614690: 0xfc8189f2 0x00000002 0x0000001d 0x00000000 This is obviously SOMETHING, but what? And why does %cx point HALF WAY THROUGH an obvious 32 bit pointer? Thoughts of hardware problems do come to mind... but.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 15:59:51 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 79BB037B403 for ; Tue, 24 Jul 2001 15:59:36 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA20929 for ; Tue, 24 Jul 2001 15:20:59 -0700 (PDT) Date: Tue, 24 Jul 2001 15:20:58 -0700 (PDT) From: Julian Elischer To: current@freebsd.org Subject: This look familiar to anyone? (bug in 4.11 maybe) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I know this is not a -current problem, but if it was fixed by someone they are likely to be reading here, and not in -stable.. We have a hybrid (4.11+patches) kernel that sometimes crashes. The crash always has teh same symptoms and I'm hoping that they look familiar to someone... The message is below, followed by analysis. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xe6b95cc8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01846d9 stack pointer = 0x10:0xc954de64 frame pointer = 0x10:0xc954de84 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 = 10326 (qftListener) interrupt mask = none trap number = 12 In a VFS operation, %ecx get's corrupted (maybe from an interrupt?) betweeen the instruction where it's loaded with a constant, and the instruction where it's used... It'always the same instruction, though often in DIFFERENT VFS instructions (fsync, bwrite so far) the trap frame usually looks like: #4 0xc0251813 in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10, tf_edi = 0x0, tf_esi = 0x1, tf_ebp = 0xc954de84, tf_isp = 0xc954de50, tf_ebx = 0xc27d6d80, tf_edx = 0xc1344600, tf_ecx = 0xc96145b2, tf_eax = 0xc954de78, tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc01846d9, tf_cs = 0x8, tf_eflags = 0x10286, tf_esp = 0xc954de78, tf_ss = 0xc27d6d80}) at /usr/src/sys/i386/i386/trap.c:443 #5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923 #6 0xc0189be2 in vop_stdbwrite (ap=0xc954deb4) at /usr/src/sys/kern/vfs_default.c:319 the code there looks like: (kgdb) up 5 #5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923 923 rc = VCALL(vp, VOFFSET(vop_strategy), &a); (kgdb) list 918 struct vop_strategy_args a; 919 int rc; 920 a.a_desc = VDESC(vop_strategy); 921 a.a_vp = vp; 922 a.a_bp = bp; 923 rc = VCALL(vp, VOFFSET(vop_strategy), &a); <-------here 924 return (rc); 925 } 926 struct vop_print_args { 927 struct vnodeop_desc *a_desc; In Assembler: 0xc01846cc : mov 0xc029dcc0,%ecx 0xc01846d2 : mov 0x18(%eax),%edx 0xc01846d5 : lea 0xfffffff4(%ebp),%eax 0xc01846d8 : push %eax 0xc01846d9 : mov (%edx,%ecx,4),%eax <<<<< **POW** 0xc01846dc : call *%eax 0xc01846de : add $0x4,%esp 0xc01846e1 : mov 0xfffffff0(%ebp),%eax looking at the regs, dx = 0xc1344600, cx = 0xc96145b2, and C1344600+(4*C96145B2) = 3E6B95CC8 the lower 32 bits of which is the same as the fault address but in the code above we see that %cx was just loaded from location 0xc029dcc0 which contains: (kgdb) x/x 0xc029dcc0 0xc029dcc0 : 0x12 0x12 is the correct offset for a strategy call. so cx got corrupted between the instruction at 0xc01846cc and that at 0xc01846d9. Note that the contents of cx (0xc96145b2) is an address somewhat higher than the kernel stack at the time in question. a dump of ram in that area shows: (kgdb) x/64xw 0xc96145a0 0xc96145a0: 0xc954e900 0xc9709c00 0x00000000 0xc96145a8 0xc96145b0: [0xc9580660] 0xc95c7370 0xc04d7504 0xc04d47d4 0xc96145c0: 0x0000aa26 0x00000020 0x00000000 0x00000000 0xc96145d0: 0xfc812c38 0x00000002 0x00040010 0x00000020 0xc96145e0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc96145f0: 0x00000000 0xc9636a40 0x0001fc93 0x00000000 0xc9614600: 0xc02ed7c0 0xc95b4120 0x00000000 0xc9614608 0xc9614610: 0x00000000 0xc9555548 0x00000000 0xc9614618 0xc9614620: 0x00003f5b 0x00000003 0x00000000 0x00000000 0xc9614630: 0xfe37c115 0x21880000 0x0000000e 0x00000000 0xc9614640: 0x00000000 0x00000000 0x00000000 0x00000000 0xc9614650: 0x00000000 0x00000000 0x00000000 0x00000000 0xc9614660: 0xc9722ae0 0xc961c600 0x00000000 0xc9614668 0xc9614670: 0xc9690660 0xc97091f0 0x00000000 0xc9614678 0xc9614680: 0x0000cabf 0x00000012 0x00000000 0x00000000 0xc9614690: 0xfc8189f2 0x00000002 0x0000001d 0x00000000 This is obviously SOMETHING, but what? And why does %cx point HALF WAY THROUGH an obvious 32 bit pointer? Thoughts of hardware problems do come to mind... but.. My present line of attack is to change the page-fault handler to leave a 500 byte window untouched on the stack (except for the frame) so that I can try see if an interrupt occured recently, and if so, what it was.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 16: 0:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id C297C37B405; Tue, 24 Jul 2001 15:59:57 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id WAA19999; Mon, 23 Jul 2001 22:54:18 -0700 (PDT) Message-ID: <3B5CEF48.B09A700B@elischer.org> Date: Mon, 23 Jul 2001 20:45:12 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: obrien@freebsd.org Cc: current@freebsd.org Subject: Re: Progress report: KSEs. References: <3B5BD579.400FE65E@elischer.org> <20010723151258.A52202@dragon.nuxi.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Mon, Jul 23, 2001 at 12:42:49AM -0700, Julian Elischer wrote: > > step 1: get proc structure broken up, with system still running: done (twice) > > Can you post your diff to the proc structure? > > ... > > > -random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct proc *p) > > +random_ioctl(dev_t dev, u_long cmd, caddr_t addr, int flags, struct thread *td) > > This implies `struct thread' has replaced `struct proc'. (I could be > wrong, but cannot be sure until you post the `struct proc' and related > structure changes/additions) A thread is blockable and anything that might block (e.g. a syscall,( e.g. ioctl)) needs to talk in terms of the thread rather than the process. so, yes, maybe > 50% of uses of "struct proc *p" get changed to "struct thread *td". The proc structure however still exists. > There is no `struct thread' in Jason's KSE paper. > Why aren't you > following the paper > http://people.freebsd.org/~jasone/refs/freebsd_kse/freebsd_kse.html? Well since I made up the terminology in the paper,... because I changed my mind about it? My original posts said.. "lets call these KSEs etc. tillwe are completely sure what they do and can give them better names. The basic unit turns out to be the thread which can be blocked so calling it a KSEC is plain confusing. As you requested, I include my current version of proc.h at http://www.freebsd.org/~julian this is NOT the version that ran under step #1 but rather as it looks now, half way through step #2. > > -- > -- David (obrien@FreeBSD.org) -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 16: 0:14 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 39EFD37B406; Tue, 24 Jul 2001 15:59:58 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA19555; Mon, 23 Jul 2001 15:26:14 -0700 (PDT) Date: Mon, 23 Jul 2001 15:26:12 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: current@FreeBSD.org Subject: RE: mutex blocking queues.. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG this strikes me as avoidable. I'll think about it.. Until then I guess I'll just have two lists in the thread.. one for sleep and one for mutexes. On Mon, 23 Jul 2001, John Baldwin wrote: > > On 23-Jul-01 Julian Elischer wrote: > > Why does the mutex not link blocked processes though the > > sleep queue linked list entry? Why does it use the run queue entry? > > In KSEs the sleep queue and run queue enties go into different > > sub structures and ahve different types so this breaks... > > do I need to do something sleazy or can I just link them together using the > > equivalemt of the p_slpq entry? > > You can block on a mutex when processing signals in the catch case in msleep() > after you have put the process on the sleep queue: > > int > msleep(ident, mtx, priority, wmesg, timo) > { > ... > p->p_wchan = ident; > p->p_wmesg = wmesg; > p->p_slptime = 0; > p->p_pri.pri_level = priority & PRIMASK; > CTR5(KTR_PROC, "msleep: proc %p (pid %d, %s) on %s (%p)", p, p->p_pid, > p->p_comm, wmesg, ident); > TAILQ_INSERT_TAIL(&slpque[LOOKUP(ident)], p, p_slpq); > ... > /* > * We put ourselves on the sleep queue and start our timeout > * before calling CURSIG, as we could stop there, and a wakeup > * or a SIGCONT (or both) could occur while we were stopped. > * A SIGCONT would cause us to be marked as SSLEEP > * without resuming us, thus we must be ready for sleep > * when CURSIG is called. If the wakeup happens while we're > * stopped, p->p_wchan will be 0 upon return from CURSIG. > */ > if (catch) { > CTR3(KTR_PROC, "msleep caught: proc %p (pid %d, %s)", p, > p->p_pid, p->p_comm); > p->p_sflag |= PS_SINTR; > mtx_unlock_spin(&sched_lock); > PROC_LOCK(p); > sig = CURSIG(p); > mtx_lock_spin(&sched_lock); > PROC_UNLOCK_NOSWITCH(p); > ... > > If that proc_lock blocks then we don't want to clobber the sleep queue. > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 16: 3: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id CB50D37B407; Tue, 24 Jul 2001 16:03:01 -0700 (PDT) (envelope-from julian@elischer.org) Received: from elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA19286; Mon, 23 Jul 2001 11:22:37 -0700 (PDT) Message-ID: <3B5C4D4D.FB83DF26@elischer.org> Date: Mon, 23 Jul 2001 09:14:05 -0700 From: Julian Elischer X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en, hu MIME-Version: 1.0 To: Jake Burkholder Cc: jhb@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: mutex blocking queues.. References: <200107231127.f6NBRg985918@k7.locore.ca> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jake Burkholder wrote: > > > Why does the mutex not link blocked processes though the > > sleep queue linked list entry? Why does it use the run queue entry? > > Because in some cases its necessary for a process to acquire > mutexes while its on the sleep queue. If they used the same > linkage the queues would get corrupted. can this be fixed? > > > In KSEs the sleep queue and run queue enties go into different > > sub structures and ahve different types so this breaks... > > do I need to do something sleazy or can I just link them together using the > > equivalemt of the p_slpq entry? > > It seems to me that whatever gets placed on the run queues > should also be what goes on the mutex queues. it would at first glance, but it is not the case when you think about it.. threads sleep/block, but the process is still on the run queue If you put all threads in the run queue, then when one runs you need to remove all the others from the queue and then add them again if they didn't get run at that quanta.. better to add the 'kse' onto the queue once, and hang all it's runnable threads off it.. > > > > > -- > > +------------------------------------+ ______ _ __ > > | __--_|\ Julian Elischer | \ U \/ / hard at work in > > | / \ julian@elischer.org +------>x USA \ a very strange > > | ( OZ ) \___ ___ | country ! > > +- X_.---._/ presently in San Francisco \_/ \\ > > v > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message -- +------------------------------------+ ______ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ julian@elischer.org +------>x USA \ a very strange | ( OZ ) \___ ___ | country ! +- X_.---._/ presently in San Francisco \_/ \\ v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 16:13:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 654BF37B408 for ; Tue, 24 Jul 2001 16:13:48 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id SAA21193 for ; Tue, 24 Jul 2001 18:11:29 -0700 (PDT) Date: Tue, 24 Jul 2001 18:11:28 -0700 (PDT) From: Julian Elischer To: current@freebsd.org Subject: Re: -current logjammed? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG never mind.. found a logjam in an intermediate host.. On Tue, 24 Jul 2001, Julian Elischer wrote: > > I sent a message to here this morning and didn't see it, > then again this afternoon. Still haven't seen it come back to me > (and no answers) I wonder if I'll see this? > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 16:21:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 1EE1937B406 for ; Tue, 24 Jul 2001 16:21:22 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.4/8.11.2) with ESMTP id f6ONL9v40647; Tue, 24 Jul 2001 16:21:09 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 24 Jul 2001 16:21:07 -0700 (PDT) From: John Baldwin To: Julian Elischer Subject: RE: This look familiar to anyone? (bug in 4.11 maybe) Cc: freebsd-current@FreeBSD.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 24-Jul-01 Julian Elischer wrote: > > In a VFS operation, %ecx get's corrupted (maybe from an interrupt?) > betweeen the instruction where it's loaded with a constant, > and the instruction where it's used... It'always the same instruction, > though often in DIFFERENT VFS instructions (fsync, bwrite so far) > > the trap frame usually looks like: > >#4 0xc0251813 in trap (frame={tf_fs = 0x10, tf_es = 0x10, tf_ds = 0x10, > tf_edi = 0x0, tf_esi = 0x1, tf_ebp = 0xc954de84, > tf_isp = 0xc954de50, tf_ebx = 0xc27d6d80, tf_edx = 0xc1344600, > tf_ecx = 0xc96145b2, tf_eax = 0xc954de78, tf_trapno = 0xc, > tf_err = 0x0, tf_eip = 0xc01846d9, tf_cs = 0x8, tf_eflags = 0x10286, > tf_esp = 0xc954de78, tf_ss = 0xc27d6d80}) > at /usr/src/sys/i386/i386/trap.c:443 >#5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923 >#6 0xc0189be2 in vop_stdbwrite (ap=0xc954deb4) at > /usr/src/sys/kern/vfs_default.c:319 > > > the code there looks like: > > (kgdb) up 5 >#5 0xc01846d9 in bwrite (bp=0xc27d6d80) at vnode_if.h:923 > 923 rc = VCALL(vp, VOFFSET(vop_strategy), &a); > (kgdb) list > 918 struct vop_strategy_args a; > 919 int rc; > 920 a.a_desc = VDESC(vop_strategy); > 921 a.a_vp = vp; > 922 a.a_bp = bp; > 923 rc = VCALL(vp, VOFFSET(vop_strategy), &a); <-------here > 924 return (rc); > 925 } > 926 struct vop_print_args { > 927 struct vnodeop_desc *a_desc; > > In Assembler: > > 0xc01846cc : mov 0xc029dcc0,%ecx > 0xc01846d2 : mov 0x18(%eax),%edx > 0xc01846d5 : lea 0xfffffff4(%ebp),%eax > 0xc01846d8 : push %eax > 0xc01846d9 : mov (%edx,%ecx,4),%eax <<<<< **POW** > 0xc01846dc : call *%eax > 0xc01846de : add $0x4,%esp > 0xc01846e1 : mov 0xfffffff0(%ebp),%eax > > looking at the regs, > dx = 0xc1344600, > cx = 0xc96145b2, > and > C1344600+(4*C96145B2) = 3E6B95CC8 > the lower 32 bits of which is the same as the fault address > > but in the code above we see that %cx was just loaded from > location 0xc029dcc0 which contains: > (kgdb) x/x 0xc029dcc0 > 0xc029dcc0 : 0x12 > > 0x12 is the correct offset for a strategy call. > > so cx got corrupted between the instruction at 0xc01846cc > and that at 0xc01846d9. Very weird. Note that traps and interrupts will save %ecx in the trapframe, so you aren't going to end up with those getting corrupted unless we somehow screw up ecx after popping the frame (or before pushing it). > Note that the contents of cx (0xc96145b2) is an address > somewhat higher than the kernel stack at the time in question. Could be a stack of some other thread. All the 0xc9XXXXX addresses are pointers to automatic variables. The 0xc0[2-4]XXXXX are return addresses. > a dump of ram in that area shows: > (kgdb) x/64xw 0xc96145a0 > 0xc96145a0: 0xc954e900 0xc9709c00 0x00000000 0xc96145a8 > 0xc96145b0: [0xc9580660] 0xc95c7370 0xc04d7504 0xc04d47d4 > 0xc96145c0: 0x0000aa26 0x00000020 0x00000000 0x00000000 > 0xc96145d0: 0xfc812c38 0x00000002 0x00040010 0x00000020 > 0xc96145e0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc96145f0: 0x00000000 0xc9636a40 0x0001fc93 0x00000000 > 0xc9614600: 0xc02ed7c0 0xc95b4120 0x00000000 0xc9614608 > 0xc9614610: 0x00000000 0xc9555548 0x00000000 0xc9614618 > 0xc9614620: 0x00003f5b 0x00000003 0x00000000 0x00000000 > 0xc9614630: 0xfe37c115 0x21880000 0x0000000e 0x00000000 > 0xc9614640: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc9614650: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc9614660: 0xc9722ae0 0xc961c600 0x00000000 0xc9614668 > 0xc9614670: 0xc9690660 0xc97091f0 0x00000000 0xc9614678 > 0xc9614680: 0x0000cabf 0x00000012 0x00000000 0x00000000 > 0xc9614690: 0xfc8189f2 0x00000002 0x0000001d 0x00000000 > > This is obviously SOMETHING, but what? And why does %cx point HALF WAY > THROUGH an obvious 32 bit pointer? > > Thoughts of hardware problems do come to mind... but.. Is it just one machine that does this reliably? -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 17: 8:15 2001 Delivered-To: freebsd-current@freebsd.org Received: from assaris.sics.se (h122n4fls32o892.telia.com [213.64.47.122]) by hub.freebsd.org (Postfix) with ESMTP id 04B4537B405 for ; Tue, 24 Jul 2001 17:08:12 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id CAA03384; Wed, 25 Jul 2001 02:08:07 +0200 (CEST) (envelope-from assar) To: Olivier Cortes Cc: freebsd-current@FreeBSD.ORG Subject: Re: build problem ? References: <20010724202213.A77937@APastourelles-102-1-2-26.abo.wa> <00f001c11471$0cb17160$7d7885c0@genroco.com> <20010724233142.A81766@APastourelles-102-1-2-26.abo.wa> From: Assar Westerlund Date: 25 Jul 2001 02:08:07 +0200 In-Reply-To: Olivier Cortes's message of "Tue, 24 Jul 2001 23:31:42 +0200" Message-ID: <5ly9pdyioo.fsf@assaris.sics.se> Lines: 9 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Olivier Cortes writes: > fool, fool, fool am i. here it is : > > -------------------------- > mkdep -f .depend -a -nostdinc -DDISASSEMBLER -DNO_X -I/usr/obj/usr/build/src/i 386/usr/include Make sure you have usr.bin/doscmd/Makefile version 1.28 (or higher). /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 17:39:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id A420C37B403 for ; Tue, 24 Jul 2001 17:39:31 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.4/8.11.2) with ESMTP id f6P0dMv46205 for ; Tue, 24 Jul 2001 17:39:22 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 24 Jul 2001 17:39:30 -0700 (PDT) From: John Baldwin To: current@FreeBSD.org Subject: Suspend/resume + pccard Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG A while back there was a thread on one of the lists (-developers maybe?) about someone's laptop having issues with newcard and suspend/resume. Today I tested a patch to fix suspend/resume for ACPI and went ahead and tested all the combinations. All of the following worked perfectly fine on my Inspiron 5000e: - APM + oldcard - APM + newcard - ACPI + oldcard - ACPI + newcard This is all with top of the tree -current. All the tests used a wavelan (wi0) for the test pccard (didn't try cardbus with newcard) and suspend/resume was tested both with Fn-Esc (suspend hotkey) and by holding down and releasing the lid switch (equivalent to shutting and opening the lid). -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 18:31:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 292CD37B405 for ; Tue, 24 Jul 2001 18:31:13 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f6P0Xnq05916; Tue, 24 Jul 2001 17:33:49 -0700 (PDT) (envelope-from obrien) Date: Tue, 24 Jul 2001 17:32:17 -0700 From: "David O'Brien" To: Beech Rintoul Cc: freebsd-current@freebsd.org Subject: Re: device.hints Message-ID: <20010724173217.A5825@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <01072411231609.06676@galaxy.anchoragerescue.org> <0107241251390A.06676@galaxy.anchoragerescue.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0107241251390A.06676@galaxy.anchoragerescue.org>; from akbeech@anchoragerescue.org on Tue, Jul 24, 2001 at 12:51:39PM -0800 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 24, 2001 at 12:51:39PM -0800, Beech Rintoul wrote: > > I want to experiment with current. All went well on the build, but when I > > try and install the kernel it stops telling me to install a "device.hints" You should have also read UPDATING. Please start a habit of checking this document if you are going to run -current. 20000825: /boot/device.hints is now required for installkernel to succeed. You should copy GENERIC.hints for your architecture into /boot/device.hints. If and only if you compile hints into your kernel, then this file may be empty. Please note, if you have an empty or missing /boot/device.hints file and you neglected to compile hints into your kernel, no boot messages will appear after the boot loader tries to start the kernel. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 24 20:40:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail3.bigmailbox.com (mail3.bigmailbox.com [209.132.220.34]) by hub.freebsd.org (Postfix) with ESMTP id C9B5837B405; Tue, 24 Jul 2001 20:40:42 -0700 (PDT) (envelope-from neckpain@nettaxi.com) Received: œby mail3.bigmailbox.com (8.8.7/8.8.7) id UAA06939; Tue, 24 Jul 2001 20:40:41 -0700 Date: Tue, 24 Jul 2001 20:40:41 -0700 Message-Id: <200107250340.UAA06939@mail3.bigmailbox.com> X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [203.141.118.85] From: "neckpain@nettaxi.com" To: msmith@freebsd.org Cc: current@freebsd.org Subject: Re: acpi malfunctions Content-Type: multipart/mixed; boundary="----------=_996032440-6836-0" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format... ------------=_996032440-6836-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary In-Reply-To: <200107232037.f6NKbx201647@mass.dis.org>; from msmith@FreeBSD.ORG on Mon, Jul 23, 2001 at 01:37:59PM -0700 On Mon, Jul 23, 2001 at 01:37:59PM -0700, Mike Smith wrote: > > > > 1. Acpica modules hangs in > > > > AcpiRsCalculateByteStreamLength() called from > > > > AcpiRsCreateByteStream() called from > > > > AcpiRsSetSrsMethodData() called from > > > > AcpiSetCurrentResources() from somewhere in acpi_pcib.c . > > > > > > > > The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length > > == 0 > > > > . > > > > > > Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484? > > > I think I should be passing a pointer to the buffer, not a pointer to a > > > pointer. > > > > There's no &crsbuf in line 484 (not in rev 1.10, nor 1.11). > > > > Assuming you're talking about the one in line 478, it doesn't compile if you > > change it to crsbuf from &crsbuf, since crsbuf is an ACPI_BUFFER, not > > an (ACPI_BUFFER *). > > Um. Sorry about the line numbers, and yes, sorry about the confusion > there; I just looked at it and it seemed wrong. > > I'd still like to know the allocation length for that buffer though; my > last suspicion is that it doesn't contain any resources at all, and so > we're overrunning it when we go to try to stuff an interrupt resource > into it. If that's the case, it's easy to fix. If not, then we will > have to go hunting snarks. Attached are what I got from dmesg, and two patches to obtain the dmesg output. The patches are to be applied against acpi_pcib.c and /sys/contrib/dev/acpica/rscalc.c, respectively. The latter lets you go past the RsCalculateByteStreamLength(), but of course the interrupt routing fails. Let me know if there are other places I had to put the printf()'s. Regards. ------------------------------------------------------------ Shop Smart Compare Prices on Name-Brand Products from Name-Brand Stores!! http://www.smartshop.com/cgi-bin/main.cgi?ssa=4099 ------------=_996032440-6836-0 Content-Type: application/octet-stream; name="dmesg" Content-Disposition: inline; filename="dmesg" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDEgVGhlIEZyZWVCU0QgUHJvamVjdC4K Q29weXJpZ2h0IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAx OTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0 aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2Vy dmVkLgpGcmVlQlNEIDUuMC1DVVJSRU5UICMyOiBTYXQgSnVsIDE0IDEyOjQx OjU5IEpTVCAyMDAxCiAgICByb290QGd6bDovdXNyL29iai9rZXJuZWwuMjAw MS4wNy4xMi4wMC4wMC4wMApDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gVFND IGNsb2NrOiAyNjQ2NjMwNTUgSHosIGk4MjU0IGNsb2NrOiAxMTkzMTY2IEh6 CkNMS19VU0VfSTgyNTRfQ0FMSUJSQVRJT04gbm90IHNwZWNpZmllZCAtIHVz aW5nIGRlZmF1bHQgZnJlcXVlbmN5ClRpbWVjb3VudGVyICJpODI1NCIgIGZy ZXF1ZW5jeSAxMTkzMTgyIEh6ClRpbWVjb3VudGVyICJUU0MiICBmcmVxdWVu Y3kgMjY0NjYzMDU1IEh6CkNQVTogUGVudGl1bSBJSS9QZW50aXVtIElJIFhl b24vQ2VsZXJvbiAoMjY0LjY2LU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdp biA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NjZhICBTdGVwcGluZyA9IDEw CiAgRmVhdHVyZXM9MHgxODNmOWZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1Is UEFFLE1DRSxDWDgsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixN TVgsRlhTUj4KcmVhbCBtZW1vcnkgID0gNjcwNDMzMjggKDY1NDcySyBieXRl cykKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAxMDAwIC0gMHgw MDA5ZWZmZiwgNjQ3MTY4IGJ5dGVzICgxNTggcGFnZXMpCjB4MDA0NDgwMDAg LSAweDAzZmU3ZmZmLCA2MjUyMTM0NCBieXRlcyAoMTUyNjQgcGFnZXMpCmF2 YWlsIG1lbW9yeSA9IDYxMDM0NDk2ICg1OTYwNEsgYnl0ZXMpCmJpb3MzMjog Rm91bmQgQklPUzMyIFNlcnZpY2UgRGlyZWN0b3J5IGhlYWRlciBhdCAweGMw MGY2Y2YwCmJpb3MzMjogRW50cnkgPSAweGZkODgwIChjMDBmZDg4MCkgIFJl diA9IDAgIExlbiA9IDEKcGNpYmlvczogUENJIEJJT1MgZW50cnkgYXQgMHhm ZDg4MCsweDExZQpwbnBiaW9zOiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4 YzAwZjZkMjAKcG5wYmlvczogRW50cnkgPSBmMDAwMDpiMzM0ICBSZXYgPSAx LjAKcG5wYmlvczogRXZlbnQgZmxhZyBhdCA0MDAKT3RoZXIgQklPUyBzaWdu YXR1cmVzIGZvdW5kOgpQcmVsb2FkZWQgZWxmIGtlcm5lbCAia2VybmVsIiBh dCAweGMwNDIyMDAwLgpQcmVsb2FkZWQgdXNlcmNvbmZpZ19zY3JpcHQgIi9i b290L2tlcm5lbC5jb25mIiBhdCAweGMwNDIyMDljLgpQcmVsb2FkZWQgZWxm IG1vZHVsZSAibWQua28iIGF0IDB4YzA0MjIwZWMuClByZWxvYWRlZCBlbGYg bW9kdWxlICJzbmRfZHMxLmtvIiBhdCAweGMwNDIyMTg4LgpQcmVsb2FkZWQg ZWxmIG1vZHVsZSAic25kX3BjbS5rbyIgYXQgMHhjMDQyMjIyOC4KUHJlbG9h ZGVkIGVsZiBtb2R1bGUgImFncC5rbyIgYXQgMHhjMDQyMjJjOC4KUHJlbG9h ZGVkIGVsZiBtb2R1bGUgInJhbmRvbS5rbyIgYXQgMHhjMDQyMjM2NC4KUHJl bG9hZGVkIGVsZiBtb2R1bGUgImFjcGljYS5rbyIgYXQgMHhjMDQyMjQwNC4K QUNQSSBkZWJ1ZyBsYXllciAweDAgIGRlYnVnIGxldmVsIDB4MApudWxsOiA8 bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPgptZW06IDxtZW1vcnkgJiBJL08+ ClBlbnRpdW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFibGVkClZFU0E6IGluZm9y bWF0aW9uIGJsb2NrCjU2IDQ1IDUzIDQxIDAwIDAyIDIwIDAxIDAwIDAxIDAw IDAwIDAwIDAwIDIyIDAwIAowMCAwMSAyNyAwMCAwMiAwMiAwMCAwMSAwMCAw MSAwOSAwMSAwMCAwMSAxYiAwMSAKMDAgMDEgMDAgMDEgMDEgMDEgMDIgMDEg MDMgMDEgMDQgMDEgMDUgMDEgMDcgMDEgCjBkIDAxIDBlIDAxIDEwIDAxIDEx IDAxIDEyIDAxIDEzIDAxIDE0IDAxIDE1IDAxIApWRVNBOiAyNCBtb2RlKHMp IGZvdW5kClZFU0E6IHYyLjAsIDI0OTZrIG1lbW9yeSwgZmxhZ3M6MHgwLCBt b2RlIHRhYmxlOjB4YzAyY2ZhMDIgKDEwMDAwMjIpClZFU0E6IE1hZ2ljTWVk aWEgMjU2QVYgIDQ4SwpWRVNBOiBOZW9NYWdpYyBNYWdpY01lZGlhIDI1NkFW ICAwMS4wCnJhbmRvbTogPGVudHJvcHkgc291cmNlPgpVc2luZyAkUElSIHRh YmxlLCA4IGVudHJpZXMgYXQgMHhjMDBmZGY0MApucHgwOiA8bWF0aCBwcm9j ZXNzb3I+IG9uIG1vdGhlcmJvYXJkCm5weDA6IElOVCAxNiBpbnRlcmZhY2UK YWNwaTA6IDxTT05ZICAgTTAgICAgICA+IG9uIG1vdGhlcmJvYXJkCmFjcGlf Y3B1MDogPENQVT4gb24gYWNwaTAKYWNwaV90ejA6IDx0aGVybWFsIHpvbmU+ IG9uIGFjcGkwCmFjcGlfdHowOiBfQ1JUIHZhbHVlIGlzIGFic3VyZCwgaWdu b3JlZCAoMTI3OS45QykKYWNwaV90ejA6IF9QU1YgdmFsdWUgaXMgYWJzdXJk LCBpZ25vcmVkICgxMjc5LjlDKQphY3BpX2J1dHRvbjA6IDxDb250cm9sIE1l dGhvZCBQb3dlciBCdXR0b24gRGV2aWNlPiBvbiBhY3BpMAphY3BpX3BjaWIw OiA8SG9zdC1QQ0kgYnJpZGdlPiBvbiBhY3BpMApwY2kwOiBwaHlzaWNhbCBi dXM9MAoJbWFwWzEwXTogdHlwZSAzLCByYW5nZSAzMiwgYmFzZSA0MDAwMDAw MCwgc2l6ZSAyNCwgZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRl dj0weDcxOTAsIHJldmlkPTB4MDMKCWJ1cz0wLCBzbG90PTAsIGZ1bmM9MAoJ Y2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MApmb3VuZC0+ CXZlbmRvcj0weDgwODYsIGRldj0weDcxOTEsIHJldmlkPTB4MDMKCWJ1cz0w LCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgw MSwgbWZkZXY9MApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDcxMTAs IHJldmlkPTB4MDIKCWJ1cz0wLCBzbG90PTcsIGZ1bmM9MAoJY2xhc3M9MDYt MDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJbWFwWzIwXTogdHlwZSA0 LCByYW5nZSAzMiwgYmFzZSAwMDAwZmNmMCwgc2l6ZSAgNCwgZW5hYmxlZApm b3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDcxMTEsIHJldmlkPTB4MDEK CWJ1cz0wLCBzbG90PTcsIGZ1bmM9MQoJY2xhc3M9MDEtMDEtODAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MAoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwg YmFzZSAwMDAwZmNjMCwgc2l6ZSAgNSwgZW5hYmxlZApmb3VuZC0+CXZlbmRv cj0weDgwODYsIGRldj0weDcxMTIsIHJldmlkPTB4MDEKCWJ1cz0wLCBzbG90 PTcsIGZ1bmM9MgoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MAoJaW50cGluPWQsIGlycT0yNTUKCW1hcFs5MF06IHR5cGUgNCwgcmFu Z2UgMzIsIGJhc2UgMDAwMDEwNDAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQt Pgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHg3MTEzLCByZXZpZD0weDAzCglidXM9 MCwgc2xvdD03LCBmdW5jPTMKCWNsYXNzPTA2LTgwLTAwLCBoZHJ0eXBlPTB4 MDAsIG1mZGV2PTAKCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2Ug ZmVkZmYwMDAsIHNpemUgMTEsIG1lbW9yeSBkaXNhYmxlZAoJbWFwWzE0XTog dHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmZWRmZmMwMCwgc2l6ZSAgOSwgbWVt b3J5IGRpc2FibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTA0ZCwgZGV2PTB4ODAz OSwgcmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9OCwgZnVuYz0wCgljbGFzcz0w Yy0wMC0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCglpbnRwaW49YSwgaXJx PTI1NQoJcG93ZXJzcGVjIDEgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQw CgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGZlZGYwMDAwLCBz aXplIDE1LCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBi YXNlIDAwMDBmYzQwLCBzaXplICA2LCBwb3J0IGRpc2FibGVkCgltYXBbMThd OiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBmY2VjLCBzaXplICAyLCBw b3J0IGRpc2FibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTA3MywgZGV2PTB4MDAx MCwgcmV2aWQ9MHgwMgoJYnVzPTAsIHNsb3Q9OSwgZnVuYz0wCgljbGFzcz0w NC0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCglpbnRwaW49YSwgaXJx PTkKCXBvd2Vyc3BlYyAxICBzdXBwb3J0cyBEMCBEMiBEMyAgY3VycmVudCBE MAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmZWRmZjgwMCwg c2l6ZSAgOSwgbWVtb3J5IGRpc2FibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTM2 YiwgZGV2PTB4ZmYwMSwgcmV2aWQ9MHgwMQoJYnVzPTAsIHNsb3Q9MTAsIGZ1 bmM9MAoJY2xhc3M9MDQtODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJ aW50cGluPWEsIGlycT0yNTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBE MyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFz ZSBmZWRlMDAwMCwgc2l6ZSAxNiwgbWVtb3J5IGRpc2FibGVkCgltYXBbMTRd OiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBmY2UwLCBzaXplICAzLCBw b3J0IGRpc2FibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTRmMSwgZGV2PTB4MTAz NiwgcmV2aWQ9MHgwOAoJYnVzPTAsIHNsb3Q9MTEsIGZ1bmM9MAoJY2xhc3M9 MDctODAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJaW50cGluPWEsIGly cT05Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAK Zm91bmQtPgl2ZW5kb3I9MHgxMTgwLCBkZXY9MHgwNDc1LCByZXZpZD0weDgw CglidXM9MCwgc2xvdD0xMiwgZnVuYz0wCgljbGFzcz0wNi0wNy0wMCwgaGRy dHlwZT0weDAyLCBtZmRldj0wCglpbnRwaW49YSwgaXJxPTI1NQoJcG93ZXJz cGVjIDEgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCnBjaTA6 IDxQQ0kgYnVzPiBvbiBhY3BpX3BjaWIwCmFncDA6IDxJbnRlbCA4MjQ0M0JY ICg0NDAgQlgpIGhvc3QgdG8gUENJIGJyaWRnZT4gbWVtIDB4NDAwMDAwMDAt MHg0MGZmZmZmZiBhdCBkZXZpY2UgMC4wIG9uIHBjaTAKYWdwMDogYWxsb2Nh dGluZyBHQVRUIGZvciBhcGVydHVyZSBvZiBzaXplIDE2TQpwY2liMTogPFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAg c2Vjb25kYXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMg ICAxCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZgpw Y2liMTogICBtZW1vcnkgZGVjb2RlICAgICAweGZlODAwMDAwLTB4ZmVjZmZm ZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZDAwMDAwMC0weGZk ZmZmZmZmCnBjaTE6IHBoeXNpY2FsIGJ1cz0xCgltYXBbMTBdOiB0eXBlIDMs IHJhbmdlIDMyLCBiYXNlIGZkMDAwMDAwLCBzaXplIDI0LCBlbmFibGVkCglt YXBbMTRdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGZlODAwMDAwLCBzaXpl IDIyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNl IGZlYzAwMDAwLCBzaXplIDIwLCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4 MTBjOCwgZGV2PTB4MDAwNSwgcmV2aWQ9MHgyMAoJYnVzPTEsIHNsb3Q9MCwg ZnVuYz0wCgljbGFzcz0wMy0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0w CglpbnRwaW49YSwgaXJxPTkKCXBvd2Vyc3BlYyAxICBzdXBwb3J0cyBEMCBE MSBEMiBEMyAgY3VycmVudCBEMApwY2kxOiA8UENJIGJ1cz4gb24gcGNpYjEK cGNpMTogPGRpc3BsYXksIFZHQT4gYXQgMC4wIChubyBkcml2ZXIgYXR0YWNo ZWQpCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSA3LjAgb24g cGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVs IFBJSVg0IEFUQTMzIGNvbnRyb2xsZXI+IHBvcnQgMHhmY2YwLTB4ZmNmZiBh dCBkZXZpY2UgNy4xIG9uIHBjaTAKYXRhMDogaW9iYXNlPTB4MDFmMCBhbHRp b2Jhc2U9MHgwM2Y2IGJtYWRkcj0weGZjZjAKYXRhMDogbWFzaz0wMyBvc3Rh dDA9NTAgb3N0YXQyPTAwCmF0YTAtbWFzdGVyOiBBVEFQSSBwcm9iZSAwMCAw MAphdGEwLXNsYXZlOiBBVEFQSSBwcm9iZSAwMCAwMAphdGEwOiBtYXNrPTAz IHN0YXQwPTUwIHN0YXQxPTAwCmF0YTAtbWFzdGVyOiBBVEEgcHJvYmUgMDEg YTUKYXRhMDogZGV2aWNlcz0wMQphdGEwOiBhdCAweDFmMCBpcnEgMTQgb24g YXRhcGNpMAphdGExOiBpb2Jhc2U9MHgwMTcwIGFsdGlvYmFzZT0weDAzNzYg Ym1hZGRyPTB4ZmNmOAphdGExOiBtYXNrPTAzIG9zdGF0MD0wMCBvc3RhdDI9 MDAKYXRhMS1tYXN0ZXI6IEFUQVBJIHByb2JlIDAwIDAwCmF0YTEtc2xhdmU6 IEFUQVBJIHByb2JlIDAwIDAwCmF0YTE6IG1hc2s9MDMgc3RhdDA9MDAgc3Rh dDE9MDAKYXRhMTogZGV2aWNlcz0wMAphdGExOiBhdCAweDE3MCBpcnEgMTUg b24gYXRhcGNpMApwY2kwOiA8c2VyaWFsIGJ1cywgVVNCPiBhdCA3LjIgKG5v IGRyaXZlciBhdHRhY2hlZCkKaW50cG0wOiA8SW50ZWwgODIzNzFBQiBQb3dl ciBtYW5hZ2VtZW50IGNvbnRyb2xsZXI+IHBvcnQgMHgxMDQwLTB4MTA0ZiBp cnEgOSBhdCBkZXZpY2UgNy4zIG9uIHBjaTAKaW50cG0wOiBJL08gbWFwcGVk IDEwNDAKaW50cG0wOiBpbnRyIElSUSA5IGVuYWJsZWQgcmV2aXNpb24gMApz bWJ1czA6IDxTeXN0ZW0gTWFuYWdlbWVudCBCdXM+IG9uIGludHNtYjAKc21i MDogPFNNQnVzIGdlbmVyYWwgcHVycG9zZSBJL08+IG9uIHNtYnVzMAppbnRw bTA6IFBNIEkvTyBtYXBwZWQgODAwMCAKcGNpMDogPHNlcmlhbCBidXMsIEZp cmVXaXJlPiBhdCA4LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNtMDogPFlh bWFoYSBEUy0xRSAoWU1GNzQ0KT4gbWVtIDB4ZmVkZjAwMDAtMHhmZWRmN2Zm ZiBpcnEgOSBhdCBkZXZpY2UgOS4wIG9uIHBjaTAKZHMxOiBzZXRtYXAgKDQ2 NjAwMCwgM2RlNCksIG5zZWc9MSwgZXJyb3I9MApwY20wOiBhYzk3IGNvZGVj IGlkIDB4NDE0YjRkMDIgKEFzYWhpIEthc2VpIEFLNDU0MykKcGNtMDogYWM5 NyBjb2RlYyBmZWF0dXJlcyBoZWFkcGhvbmUsIDE4IGJpdCBEQUMsIDE4IGJp dCBBREMsIDUgYml0IG1hc3RlciB2b2x1bWUsIEFLTSAzRCBBdWRpbwpwY206 IHNldG1hcCA0ODYwMDAsIDEwMDA7IDB4YzZlZjcwMDAgLT4gNDg2MDAwCnBj bTogc2V0bWFwIDRhMDAwMCwgMTAwMDsgMHhjNmYwNzAwMCAtPiA0YTAwMDAK cGNtOiBzZXRtYXAgNGIwMDAwLCAxMDAwOyAweGM2ZjE3MDAwIC0+IDRiMDAw MApwY206IHNldG1hcCA0Y2MwMDAsIDEwMDA7IDB4YzZmMjcwMDAgLT4gNGNj MDAwCnBjbTogc2V0bWFwIDRkYzAwMCwgMTAwMDsgMHhjNmYzNzAwMCAtPiA0 ZGMwMDAKcGNtOiBzZXRtYXAgNGVkMDAwLCAxMDAwOyAweGM2ZjQ3MDAwIC0+ IDRlZDAwMApwY2kwOiA8bXVsdGltZWRpYT4gYXQgMTAuMCAobm8gZHJpdmVy IGF0dGFjaGVkKQpwY2kwOiA8c2ltcGxlIGNvbW1zPiBhdCAxMS4wIChubyBk cml2ZXIgYXR0YWNoZWQpCmFjcGlfcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9y IDAuMTIuSU5UQSAoc291cmNlIFxcX1NCXy5MTktCKQpnb3QgNDAgYnl0ZXMg Zm9yIFxcX1NCXy5MTktCLl9DUlMKZ290IDQ0IGJ5dGVzIGZvciBcXF9TQl8u TE5LQi5fUFJTCmFjcGlfcGNpYjA6IHBvc3NpYmxlIGludGVycnVwdHM6ICA5 CkJlZm9yZSB0aGUgY2FsbCB0byBBY3BpU2V0Q3VycmVudFJlc291cmNlcwpn b3QgNDAgYnl0ZXMgZm9yIFxcX1NCXy5MTktCLl9DUlMKZ290IDQ0IGJ5dGVz IGZvciBcXF9TQl8uTE5LQi5fUFJTCkFjcGlSc0NhbGN1bGF0ZUJ5dGVTdHJl YW1MZW5ndGhbICAwXTogSWQ6IDAsIExlbmd0aDogMjQKSVJRIFJlc291cmNl CiAgICBFZGdlIFRyaWdnZXJlZAogICAgQWN0aXZlIEhpZ2gKICAgIFNoYXJl ZAogICAgMSBJbnRlcnJ1cHRzICggMSApCkFjcGlSc0NhbGN1bGF0ZUJ5dGVT dHJlYW1MZW5ndGhbICAxXTogSWQ6IDksIExlbmd0aDogMAphY3BpX3BjaWIw OiBjb3VsZG4ndCByb3V0ZSBpbnRlcnJ1cHQgOSB2aWEgXFxfU0JfLkxOS0Ig LSBBRV9BTUxfSU5WQUxJRF9SRVNPVVJDRV9UWVBFCkFmdGVyIHRoZSBjYWxs IHRvIEFjcGlTZXRDdXJyZW50UmVzb3VyY2VzCmdvdCA0MCBieXRlcyBmb3Ig XFxfU0JfLkxOS0IuX0NSUwpnb3QgNDQgYnl0ZXMgZm9yIFxcX1NCXy5MTktC Ll9QUlMKcGNpYzA6IDxSaWNvaCBSTDVDNDc1IFBDSS1DYXJkQnVzIEJyaWRn ZT4gYXQgZGV2aWNlIDEyLjAgb24gcGNpMApwY2ljMDogTWVtb3J5IG1hcHBl ZCBkZXZpY2UsIHdpbGwgd29yay4KcGNpYzA6IFBDSSBNZW1vcnkgYWxsb2Nh dGVkOiAweDQ0MDAwMDAwCmFjcGlfcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9y IDAuMTIuSU5UQSAoc291cmNlIFxcX1NCXy5MTktCKQpnb3QgNDAgYnl0ZXMg Zm9yIFxcX1NCXy5MTktCLl9DUlMKZ290IDQ0IGJ5dGVzIGZvciBcXF9TQl8u TE5LQi5fUFJTCmFjcGlfcGNpYjA6IHBvc3NpYmxlIGludGVycnVwdHM6ICA5 CkJlZm9yZSB0aGUgY2FsbCB0byBBY3BpU2V0Q3VycmVudFJlc291cmNlcwpn b3QgNDAgYnl0ZXMgZm9yIFxcX1NCXy5MTktCLl9DUlMKZ290IDQ0IGJ5dGVz IGZvciBcXF9TQl8uTE5LQi5fUFJTCkFjcGlSc0NhbGN1bGF0ZUJ5dGVTdHJl YW1MZW5ndGhbICAwXTogSWQ6IDAsIExlbmd0aDogMjQKSVJRIFJlc291cmNl CiAgICBFZGdlIFRyaWdnZXJlZAogICAgQWN0aXZlIEhpZ2gKICAgIFNoYXJl ZAogICAgMSBJbnRlcnJ1cHRzICggMSApCkFjcGlSc0NhbGN1bGF0ZUJ5dGVT dHJlYW1MZW5ndGhbICAxXTogSWQ6IDksIExlbmd0aDogMAphY3BpX3BjaWIw OiBjb3VsZG4ndCByb3V0ZSBpbnRlcnJ1cHQgOSB2aWEgXFxfU0JfLkxOS0Ig LSBBRV9BTUxfSU5WQUxJRF9SRVNPVVJDRV9UWVBFCkFmdGVyIHRoZSBjYWxs IHRvIEFjcGlTZXRDdXJyZW50UmVzb3VyY2VzCmdvdCA0MCBieXRlcyBmb3Ig XFxfU0JfLkxOS0IuX0NSUwpnb3QgNDQgYnl0ZXMgZm9yIFxcX1NCXy5MTktC Ll9QUlMKcGNpYzA6IEZhaWxlZCB0byBhbGxvY2F0ZSBtYW5hZ21lbnQgaXJx CmRldmljZV9wcm9iZV9hbmRfYXR0YWNoOiBwY2ljMCBhdHRhY2ggcmV0dXJu ZWQgNQphY3BpX2VjMDogPGVtYmVkZGVkIGNvbnRyb2xsZXI+IG9uIGFjcGkw CmFjcGlfY21iYXQwOiA8Q29udHJvbCBtZXRob2QgQmF0dGVyeT4gb24gYWNw aTAKYWNwaV9hY2FkMDogPEFDIGFkYXB0ZXI+IG9uIGFjcGkwCmFjcGlfdGlt ZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBvbiBhY3BpMApU cnlpbmcgUmVhZF9Qb3J0IGF0IDIwMwpUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0 MwpUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4MwpUcnlpbmcgUmVhZF9Qb3J0IGF0 IDJjMwpUcnlpbmcgUmVhZF9Qb3J0IGF0IDMwMwpUcnlpbmcgUmVhZF9Qb3J0 IGF0IDM0MwpUcnlpbmcgUmVhZF9Qb3J0IGF0IDM4MwpUcnlpbmcgUmVhZF9Q b3J0IGF0IDNjMwphdGEtOiBhdGEwIGFscmVhZHkgZXhpc3RzLCB1c2luZyBh dGEyIGluc3RlYWQKYXRhLTogYXRhMSBhbHJlYWR5IGV4aXN0cywgdXNpbmcg YXRhMyBpbnN0ZWFkCnNjLTogc2MwIGFscmVhZHkgZXhpc3RzLCB1c2luZyBz YzEgaW5zdGVhZAp2Z2EtOiB2Z2EwIGFscmVhZHkgZXhpc3RzLCB1c2luZyB2 Z2ExIGluc3RlYWQKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxpbmcgUG5Q IGRldmljZXMKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAg ZGV2aWNlcwpvcm0wOiA8T3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAt MHhjYmZmZiwweGRjMDAwLTB4ZGZmZmYgb24gaXNhMAphdGtiZDogdGhlIGN1 cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAwNDcKYXRrYmQ6 IGtleWJvYXJkIElEIDB4NDFhYiAoMikKc2MwOiA8U3lzdGVtIGNvbnNvbGU+ IG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdz PTB4MjAwPgpzYzA6IGZiMCwga2JkMCwgdGVybWluYWwgZW11bGF0b3I6IHNj IChzeXNjb25zIHRlcm1pbmFsKQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBh dCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBp c2EwCmZiMDogdmdhMCwgdmdhLCB0eXBlOlZHQSAoNSksIGZsYWdzOjB4NzAw ZmYKZmIwOiBwb3J0OjB4M2MwLTB4M2RmLCBjcnRjOjB4M2Q0LCBtZW06MHhh MDAwMCAweDIwMDAwCmZiMDogaW5pdCBtb2RlOjI0LCBiaW9zIG1vZGU6Mywg Y3VycmVudCBtb2RlOjI0CmZiMDogd2luZG93OjB4YzAwYjgwMDAgc2l6ZToz MmsgZ3JhbjozMmssIGJ1ZjowIHNpemU6MzJrClZHQSBwYXJhbWV0ZXJzIHVw b24gcG93ZXItdXAKNTAgMTggMTAgMDAgMDAgMDAgMDMgMDAgMDIgNjcgNWYg NGYgNTAgODIgNTUgODEgCmJmIDFmIDAwIDRmIDBkIDBlIDAwIDAwIDA3IDgw IDljIDhlIDhmIDI4IDFmIDk2IApiOSBhMyBmZiAwMCAwMSAwMiAwMyAwNCAw NSAxNCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAgMGYgMDgg MDAgMDAgMDAgMDAgMDAgMTAgMGUgMDAgZmYgClZHQSBwYXJhbWV0ZXJzIGlu IEJJT1MgZm9yIG1vZGUgMjQKNTAgMTggMTAgMDAgMTAgMDAgMDMgMDAgMDIg NjcgNWYgNGYgNTAgODIgNTUgODEgCmJmIDFmIDAwIDRmIDBkIDBlIDAwIDAw IDAwIDAwIDljIDhlIDhmIDI4IDFmIDk2IApiOSBhMyBmZiAwMCAwMSAwMiAw MyAwNCAwNSAxNCAwNyAzOCAzOSAzYSAzYiAzYyAKM2QgM2UgM2YgMGMgMDAg MGYgMDggMDAgMDAgMDAgMDAgMDAgMTAgMGUgMDAgZmYgCkVHQS9WR0EgcGFy YW1ldGVycyB0byBiZSB1c2VkIGZvciBtb2RlIDI0CjUwIDE4IDEwIDAwIDEw IDAwIDAzIDAwIDAyIDY3IDVmIDRmIDUwIDgyIDU1IDgxIApiZiAxZiAwMCA0 ZiAwZCAwZSAwMCAwMCAwMCAwMCA5YyA4ZSA4ZiAyOCAxZiA5NiAKYjkgYTMg ZmYgMDAgMDEgMDIgMDMgMDQgMDUgMTQgMDcgMzggMzkgM2EgM2IgM2MgCjNk IDNlIDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAwIDAwIDAwIDEwIDBlIDAwIGZm IAphdGEyIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MWYwIGlycSAxNCBv biBpc2EwCmF0YTMgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgxNzAgaXJx IDE1IG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4 MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6IDxBVCBL ZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAprYmQwIGF0IGF0a2JkMAprYmQw OiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIpLCBjb25maWc6MHgwLCBmbGFnczow eDNkMDAwMApwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDQ3CnBzbTA6 IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMApwc20wOiBtb2RlbCBH ZW5lcmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwLTAwLCAyIGJ1dHRvbnMK cHNtMDogY29uZmlnOjAwMDAwMDAwLCBmbGFnczowMDAwMDAwMCwgcGFja2V0 IHNpemU6Mwpwc20wOiBzeW5jbWFzazpjMCwgc3luY2JpdHM6MDAKcGNpYzAg ZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZTAtMHgzZTEgb24gaXNhMApw Y2ljMSBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNlMC0weDNlMSBvbiBp c2EwCnBtdGltZXIwIG9uIGlzYTAKcHBjMCBmYWlsZWQgdG8gcHJvYmUgYXQg aXJxIDcgb24gaXNhMApzYzE6IG5vIHZpZGVvIGFkYXB0ZXIgaXMgZm91bmQu CnNjMTogPFN5c3RlbSBjb25zb2xlPiBmYWlsZWQgdG8gcHJvYmUgb24gaXNh MApzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJv YmVkIGlycXMgMApzaW8wOiBpcnEgbWFwczogMHgyMSAweDIxIDB4MjEgMHgy MQpzaW8wOiBwcm9iZSBmYWlsZWQgdGVzdChzKTogMCAxIDIgNCA2IDcgOQpz aW8wIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0 IGZsYWdzIDB4MTAgb24gaXNhMApzaW8xOiBpcnEgbWFwczogMHgyMSAweDIx IDB4MjEgMHgyMQpzaW8xOiBwcm9iZSBmYWlsZWQgdGVzdChzKTogMCAxIDIg NCA2IDcgOQpzaW8xIGF0IHBvcnQgMHgyZjgtMHgyZmYgZmxhZ3MgMHgxMCBv biBpc2EwCnNpbzE6IHR5cGUgODI1MApzcGljMCBmYWlsZWQgdG8gcHJvYmUg YXQgcG9ydCAweDEwYTAgb24gaXNhMAp2Z2ExOiA8R2VuZXJpYyBJU0EgVkdB PiBmYWlsZWQgdG8gcHJvYmUgb24gaXNhMAp2dDAgZmFpbGVkIHRvIHByb2Jl IG9uIGlzYTAKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIFBuUCBkZXZp Y2VzCnVua25vd246IDxQTlAwODAwPiBmYWlsZWQgdG8gcHJvYmUgYXQgcG9y dCAweDYxIG9uIGlzYTAKdW5rbm93bjogPFBOUDAzMDM+IGNhbid0IGFzc2ln biByZXNvdXJjZXMKdW5rbm93bjogPFBOUDAzMDM+IGF0IHBvcnQgMHg2MCBv biBpc2EwCnVua25vd246IDxQTlAwRjEzPiBjYW4ndCBhc3NpZ24gcmVzb3Vy Y2VzCnVua25vd246IDxQTlAwRjEzPiBhdCBpcnEgMTIgb24gaXNhMAp1bmtu b3duOiA8U05ZNjAwMT4gZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgxMDgw LDB4MTA4NCBpcnEgNSwxMCwxMSBvbiBpc2EwCnVua25vd246IDwxNjU1MEEt Y29tcGF0aWJsZSBDT00gcG9ydD4gZmFpbGVkIHRvIHByb2JlIG9uIGlzYTAK dW5rbm93bjogPFNOWTcwMDE+IGZhaWxlZCB0byBwcm9iZSBvbiBpc2EwCnVu a25vd246IDxQTlAwNDAwPiBmYWlsZWQgdG8gcHJvYmUgb24gaXNhMAp1bmtu b3duOiA8UE5QMDQwMD4gZmFpbGVkIHRvIHByb2JlIG9uIGlzYTAKdW5rbm93 bjogPFBOUDA0MDE+IGZhaWxlZCB0byBwcm9iZSBvbiBpc2EwCnVua25vd246 IDxQTlAwNDAwPiBmYWlsZWQgdG8gcHJvYmUgb24gaXNhMApCSU9TIEdlb21l dHJpZXM6CiAwOjAzZTJmZTNmIDAuLjk5ND05OTUgY3lsaW5kZXJzLCAwLi4y NTQ9MjU1IGhlYWRzLCAxLi42Mz02MyBzZWN0b3JzCiAwIGFjY291bnRlZCBm b3IKRGV2aWNlIGNvbmZpZ3VyYXRpb24gZmluaXNoZWQuCklQdjYgcGFja2V0 IGZpbHRlcmluZyBpbml0aWFsaXplZCwgbG9nZ2luZyBkaXNhYmxlZApEVU1N WU5FVCBpbml0aWFsaXplZCAoMDEwMTI0KQpicGY6IGxvMCBhdHRhY2hlZApJ UCBwYWNrZXQgZmlsdGVyaW5nIGluaXRpYWxpemVkLCBkaXZlcnQgZW5hYmxl ZCwgcnVsZS1iYXNlZCBmb3J3YXJkaW5nIGVuYWJsZWQsIGRlZmF1bHQgdG8g ZGVueSwgbG9nZ2luZyBkaXNhYmxlZApicGY6IGZhaXRoMCBhdHRhY2hlZApC UklER0UgMDEwMTMxLCBoYXZlIDIgaW50ZXJmYWNlcwpJUCBGaWx0ZXI6IHYz LjQuMTYgaW5pdGlhbGl6ZWQuICBEZWZhdWx0ID0gcGFzcyBhbGwsIExvZ2dp bmcgPSBlbmFibGVkCmFjcGlfY3B1MDogc2V0IHNwZWVkIHRvIDEwMC4wJQph Y3BpX2NwdTogQ1BVIHRocm90dGxpbmcgZW5hYmxlZCwgOCBzdGVwcyBmcm9t IDEwMCUgdG8gMTIuNSUKYWQwOiBzdWNjZXNzIHNldHRpbmcgVURNQTIgb24g SW50ZWwgY2hpcApDcmVhdGluZyBESVNLIGFkMAphZDA6IDxUT1NISUJBIE1L ODExM01BVC9KMy4wMCBBPiBBVEEtNCBkaXNrIGF0IGF0YTAtbWFzdGVyCmFk MDogNzgxNU1CICgxNjAwNjQxMCBzZWN0b3JzKSwgMTY5MzggQywgMTUgSCwg NjMgUywgNTEyIEIKYWQwOiAxNiBzZWNzL2ludCwgMSBkZXB0aCBxdWV1ZSwg VURNQTMzCmFkMDogcGlvbW9kZT00IGRtYW1vZGU9MiB1ZG1hbW9kZT0yIGNi bGlkPTAKTW91bnRpbmcgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMxYQphZDBz MTogdHlwZSAweGE1LCBzdGFydCA2MywgZW5kID0gNjQyNTk5OSwgc2l6ZSA2 NDI1OTM3IDogT0sKYWQwczI6IHR5cGUgMHhhNSwgc3RhcnQgNjQyNjAwMCwg ZW5kID0gMTYwMDA3MzksIHNpemUgOTU3NDc0MCA6IE9LCnN0YXJ0X2luaXQ6 IHRyeWluZyAvc2Jpbi9pbml0CmFjcGlfYWNhZDA6IE9mZiBMaW5lCnN5c3Rl bSBwb3dlciBwcm9maWxlIGNoYW5nZWQgdG8gJ2Vjb25vbXknCmFjcGlfY3B1 MDogc2V0IHNwZWVkIHRvIDUwLjAlCmFjcGlfYWNhZDA6IE9mZiBMaW5lCmFj cGlfcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTIuSU5UQSAoc291cmNl IFxcX1NCXy5MTktCKQpnb3QgNDAgYnl0ZXMgZm9yIFxcX1NCXy5MTktCLl9D UlMKZ290IDQ0IGJ5dGVzIGZvciBcXF9TQl8uTE5LQi5fUFJTCmFjcGlfcGNp YjA6IHBvc3NpYmxlIGludGVycnVwdHM6ICA5CkJlZm9yZSB0aGUgY2FsbCB0 byBBY3BpU2V0Q3VycmVudFJlc291cmNlcwpnb3QgNDAgYnl0ZXMgZm9yIFxc X1NCXy5MTktCLl9DUlMKZ290IDQ0IGJ5dGVzIGZvciBcXF9TQl8uTE5LQi5f UFJTCkFjcGlSc0NhbGN1bGF0ZUJ5dGVTdHJlYW1MZW5ndGhbICAwXTogSWQ6 IDAsIExlbmd0aDogMjQKSVJRIFJlc291cmNlCiAgICBFZGdlIFRyaWdnZXJl ZAogICAgQWN0aXZlIEhpZ2gKICAgIFNoYXJlZAogICAgMSBJbnRlcnJ1cHRz ICggMSApCkFjcGlSc0NhbGN1bGF0ZUJ5dGVTdHJlYW1MZW5ndGhbICAxXTog SWQ6IDksIExlbmd0aDogMAphY3BpX3BjaWIwOiBjb3VsZG4ndCByb3V0ZSBp bnRlcnJ1cHQgOSB2aWEgXFxfU0JfLkxOS0IgLSBBRV9BTUxfSU5WQUxJRF9S RVNPVVJDRV9UWVBFCkFmdGVyIHRoZSBjYWxsIHRvIEFjcGlTZXRDdXJyZW50 UmVzb3VyY2VzCmdvdCA0MCBieXRlcyBmb3IgXFxfU0JfLkxOS0IuX0NSUwpn b3QgNDQgYnl0ZXMgZm9yIFxcX1NCXy5MTktCLl9QUlMKcGNpYzI6IDxSaWNv aCBSTDVDNDc1IFBDSS1DYXJkQnVzIEJyaWRnZT4gYXQgZGV2aWNlIDEyLjAg b24gcGNpMApwY2ljMjogTWVtb3J5IG1hcHBlZCBkZXZpY2UsIHdpbGwgd29y ay4KcGNpYzI6IENvdWxkIG5vdCBtYXAgcmVnaXN0ZXIgbWVtb3J5CmRldmlj ZV9wcm9iZV9hbmRfYXR0YWNoOiBwY2ljMiBhdHRhY2ggcmV0dXJuZWQgMTIK c2MxOiBubyB2aWRlbyBhZGFwdGVyIGlzIGZvdW5kLgpzaW8wOiBjb25maWd1 cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8w OiBpcnEgbWFwczogMHgxMjUgMHgxMjUgMHgxMjUgMHgxMjUKc2lvMDogcHJv YmUgZmFpbGVkIHRlc3Qocyk6IDAgMSAyIDQgNiA3IDkKTGludXggRUxGIGV4 ZWMgaGFuZGxlciBpbnN0YWxsZWQKQ3JlYXRpbmcgRElTSyBtZDAKbWQwOiBp bnZhbGlkIHByaW1hcnkgcGFydGl0aW9uIHRhYmxlOiBubyBtYWdpYwo= ------------=_996032440-6836-0 Content-Type: application/octet-stream; name="acpi_pcib.c.diff" Content-Disposition: inline; filename="acpi_pcib.c.diff" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9kZXYvYWNwaWNhL2FjcGlfcGNpYi5jCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL2N2cy9zcmMvc3lzL2Rldi9h Y3BpY2EvYWNwaV9wY2liLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTAK ZGlmZiAtdSAtdSAtcjEuMTAgYWNwaV9wY2liLmMKLS0tIHN5cy9kZXYvYWNw aWNhL2FjcGlfcGNpYi5jCTIwMDEvMDcvMDcgMTA6MTI6MDYJMS4xMAorKysg c3lzL2Rldi9hY3BpY2EvYWNwaV9wY2liLmMJMjAwMS8wNy8yNSAwMzowNTo0 NwpAQCAtMzkzLDggKzM5MywxMyBAQAogCQkgICAgICBhY3BpX3N0cmVycm9y KHN0YXR1cykpOwogCS8qIHRoaXMgaXMgbm90IGZhdGFsLCBzaW5jZSBpdCBt YXkgYmUgaGFyZHdpcmVkICovCiAgICAgfQorI2lmIDAKICAgICBERUJVR19Q UklOVChUUkFDRV9SRVNPVVJDRVMsICgiZ290ICVkIGJ5dGVzIGZvciAlcy5f Q1JTXG4iLCBjcnNidWYuTGVuZ3RoLCBhY3BpX25hbWUobG5rZGV2KSkpOwog ICAgIERFQlVHX1BSSU5UKFRSQUNFX1JFU09VUkNFUywgKCJnb3QgJWQgYnl0 ZXMgZm9yICVzLl9QUlNcbiIsIHByc2J1Zi5MZW5ndGgsIGFjcGlfbmFtZShs bmtkZXYpKSk7CisjZWxzZQkvKiBJJ20gbm90IHN1cmUgaG93IHRvIGFjdGl2 YXRlIGRlYnVnZ2luZyBjb2RlICovCisgICAgQWNwaU9zUHJpbnRmKCJnb3Qg JWQgYnl0ZXMgZm9yICVzLl9DUlNcbiIsIGNyc2J1Zi5MZW5ndGgsIGFjcGlf bmFtZShsbmtkZXYpKTsKKyAgICBBY3BpT3NQcmludGYoImdvdCAlZCBieXRl cyBmb3IgJXMuX1BSU1xuIiwgcHJzYnVmLkxlbmd0aCwgYWNwaV9uYW1lKGxu a2RldikpOworI2VuZGlmCiAKICAgICAvKgogICAgICAqIFRoZSBpbnRlcnJ1 cHQgbWF5IGFscmVhZHkgYmUgcm91dGVkLCBzbyBjaGVjayBfQ1JTIGZpcnN0 LiAgV2UgZG9uJ3QgY2hlY2sgdGhlCkBAIC00NzUsOSArNDgwLDE5IEBACiAg ICAgcHJpbnRmKCJcbiIpOwogICAgIGNyc3Jlcy0+RGF0YS5JcnEuSW50ZXJy dXB0c1swXSA9IHByc3Jlcy0+RGF0YS5JcnEuSW50ZXJydXB0c1swXTsKICAg ICBjcnNyZXMtPkRhdGEuSXJxLk51bWJlck9mSW50ZXJydXB0cyA9IDE7CisK KyAgICBBY3BpT3NQcmludGYoIkJlZm9yZSB0aGUgY2FsbCB0byBBY3BpU2V0 Q3VycmVudFJlc291cmNlc1xuIik7CisgICAgQWNwaU9zUHJpbnRmKCJnb3Qg JWQgYnl0ZXMgZm9yICVzLl9DUlNcbiIsIGNyc2J1Zi5MZW5ndGgsIGFjcGlf bmFtZShsbmtkZXYpKTsKKyAgICBBY3BpT3NQcmludGYoImdvdCAlZCBieXRl cyBmb3IgJXMuX1BSU1xuIiwgcHJzYnVmLkxlbmd0aCwgYWNwaV9uYW1lKGxu a2RldikpOworCiAgICAgaWYgKEFDUElfRkFJTFVSRShzdGF0dXMgPSBBY3Bp U2V0Q3VycmVudFJlc291cmNlcyhsbmtkZXYsICZjcnNidWYpKSkgewogCWRl dmljZV9wcmludGYoc2MtPmFwX2RldiwgImNvdWxkbid0IHJvdXRlIGludGVy cnVwdCAlZCB2aWEgJXMgLSAlc1xuIiwKIAkJICAgICAgcHJzcmVzLT5EYXRh LklycS5JbnRlcnJ1cHRzWzBdLCBhY3BpX25hbWUobG5rZGV2KSwgYWNwaV9z dHJlcnJvcihzdGF0dXMpKTsKKworICAgICAgICBBY3BpT3NQcmludGYoIkFm dGVyIHRoZSBjYWxsIHRvIEFjcGlTZXRDdXJyZW50UmVzb3VyY2VzXG4iKTsK KyAgICAgICAgQWNwaU9zUHJpbnRmKCJnb3QgJWQgYnl0ZXMgZm9yICVzLl9D UlNcbiIsIGNyc2J1Zi5MZW5ndGgsIGFjcGlfbmFtZShsbmtkZXYpKTsKKyAg ICAgICAgQWNwaU9zUHJpbnRmKCJnb3QgJWQgYnl0ZXMgZm9yICVzLl9QUlNc biIsIHByc2J1Zi5MZW5ndGgsIGFjcGlfbmFtZShsbmtkZXYpKTsKKwogCWdv dG8gb3V0OwogICAgIH0KICAgICAK ------------=_996032440-6836-0 Content-Type: application/octet-stream; name="rscalc.c.diff" Content-Disposition: inline; filename="rscalc.c.diff" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9jb250cmliL2Rldi9hY3BpY2EvcnNjYWxjLmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvY3ZzL3NyYy9zeXMv Y29udHJpYi9kZXYvYWNwaWNhL3JzY2FsYy5jLHYKcmV0cmlldmluZyByZXZp c2lvbiAxLjEuMS43CmRpZmYgLXUgLXUgLXIxLjEuMS43IHJzY2FsYy5jCi0t LSBzeXMvY29udHJpYi9kZXYvYWNwaWNhL3JzY2FsYy5jCTIwMDEvMDUvMjkg MTk6NTI6MzcJMS4xLjEuNworKysgc3lzL2NvbnRyaWIvZGV2L2FjcGljYS9y c2NhbGMuYwkyMDAxLzA3LzI1IDAzOjA1OjI4CkBAIC0xNTAsNiArMTUwLDcg QEAKICAgICBVSU5UMzIgICAgICAgICAgICAgICAgICBTZWdtZW50U2l6ZTsK ICAgICBBQ1BJX1JFU09VUkNFX0VYVF9JUlEgICAqRXhJcnEgPSBOVUxMOwog ICAgIEJPT0xFQU4gICAgICAgICAgICAgICAgIERvbmUgPSBGQUxTRTsKKyAg ICBpbnQJCQkgICAgbiA9IDA7CiAKIAogICAgIEZVTkNUSU9OX1RSQUNFICgi UnNDYWxjdWxhdGVCeXRlU3RyZWFtTGVuZ3RoIik7CkBAIC0xNTcsNiArMTU4 LDE2IEBACiAKICAgICB3aGlsZSAoIURvbmUpCiAgICAgeworICAgICAgICBB Y3BpT3NQcmludGYoX19mdW5jX18gIlslM2RdOiBJZDogJWQsIExlbmd0aDog JWRcbiIsCisgICAgICAgICAgICBuLCBMaW5rZWRMaXN0LT5JZCwgTGlua2Vk TGlzdC0+TGVuZ3RoKTsKKworICAgICAgICBpZiAoTGlua2VkTGlzdC0+TGVu Z3RoIDw9IDAgfHwgTGlua2VkTGlzdC0+TGVuZ3RoID4gNjU1MzYpCisgICAg ICAgICAgICByZXR1cm5fQUNQSV9TVEFUVVMgKEFFX0FNTF9JTlZBTElEX1JF U09VUkNFX1RZUEUpOworICAgICAgICBpZiAobisrID49IDEwMDAwKSB7Cisg ICAgICAgICAgICBBY3BpT3NQcmludGYoInRvbyBtYW55IGl0ZXJhdGlvbnMg aW4gIiBfX2Z1bmNfXyk7CisgICAgICAgICAgICByZXR1cm5fQUNQSV9TVEFU VVMgKEFFX0FNTF9JTlZBTElEX1JFU09VUkNFX1RZUEUpOworICAgICAgICB9 CisKICAgICAgICAgLyoKICAgICAgICAgICogSW5pdCB0aGUgdmFyaWFibGUg dGhhdCB3aWxsIGhvbGQgdGhlIHNpemUgdG8gYWRkIHRvIHRoZSB0b3RhbC4K ICAgICAgICAgICovCkBAIC0xNzAsNiArMTgxLDEzIEBACiAgICAgICAgICAg ICAgKiBGb3IgYW4gSVJRIFJlc291cmNlLCBCeXRlIDMsIGFsdGhvdWdoIG9w dGlvbmFsLCB3aWxsCiAgICAgICAgICAgICAgKiBhbHdheXMgYmUgY3JlYXRl ZCAtIGl0IGhvbGRzIElSUSBpbmZvcm1hdGlvbi4KICAgICAgICAgICAgICAq LworI2lmZGVmIEFDUElfREVCVUcKKyAgICAgICAgICAgIC8qCisgICAgICAg ICAgICAgKiBJJ20gbm90IHJlYWxseSBzdXJlIGhvdyB0byB1c2UgdGhlIGRl YnVnZ2luZyBjb2RlcywKKyAgICAgICAgICAgICAqIGJ1dCB0aGlzIHdvcmtz IGZvciBtZSBhbnl3YXkuCisgICAgICAgICAgICAgKi8KKyAgICAgICAgICAg IEFjcGlSc0R1bXBJcnEoTGlua2VkTGlzdCk7CisjZW5kaWYKICAgICAgICAg ICAgIFNlZ21lbnRTaXplID0gNDsKICAgICAgICAgICAgIGJyZWFrOwogCg== ------------=_996032440-6836-0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 0:33:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50]) by hub.freebsd.org (Postfix) with ESMTP id 8701637B405 for ; Wed, 25 Jul 2001 00:33:27 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.141.74.Dial1.SanJose1.Level3.net [209.245.141.74]) by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id AAA11439; Wed, 25 Jul 2001 00:29:39 -0700 (PDT) Message-ID: <3B5E758A.AD83D823@mindspring.com> Date: Wed, 25 Jul 2001 00:30:18 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Scot W. Hetzel" Cc: Olivier Cortes , freebsd-current@FreeBSD.ORG Subject: Re: build problem ? References: <20010724202213.A77937@APastourelles-102-1-2-26.abo.wa> <00f001c11471$0cb17160$7d7885c0@genroco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Scot W. Hetzel" wrote: > When you have a build failure using -j x (x > 1), you need to restart the > build without -j in order to get any meaningful info from the build failure. Unless the breakage is a dependency breakage, not a build breakage, in which case omitting the "-j x" will run to completion without errors, telling you squat. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 1: 4:44 2001 Delivered-To: freebsd-current@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id B079137B408 for ; Wed, 25 Jul 2001 01:04:41 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.141.74.Dial1.SanJose1.Level3.net [209.245.141.74]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA10746; Wed, 25 Jul 2001 01:04:28 -0700 (PDT) Message-ID: <3B5E7DB3.97656D3C@mindspring.com> Date: Wed, 25 Jul 2001 01:05:07 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kazutaka YOKOTA Cc: freebsd-current@FreeBSD.ORG Subject: Re: Death sentence to KLD screen savers? Comments? References: <200107241207.VAA14339@zodiac.mech.utsunomiya-u.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kazutaka YOKOTA wrote: > > This is to propose to abolish KLD screen saver modules. > > KLD screen savers have the following problems/deficiencies. [ ... ] > I propose to have user-land screen savers instead of KLD > screen savers. [ ... "performance degradation" ... ] [ ... "file access" ... ] I don't see either of these as being compelling arguments in favor of a user space implementation; I guess this means you want to do file access in your screen saver(s). Now if you could run Windows screen saver modules, you might have a good argument for change, above and beyond "change for the sake of change". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 3:28:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from APastourelles-102-1-2-26.abo.wanadoo.fr (APastourelles-102-1-2-26.abo.wanadoo.fr [217.128.208.26]) by hub.freebsd.org (Postfix) with ESMTP id 5ED4737B405 for ; Wed, 25 Jul 2001 03:28:40 -0700 (PDT) (envelope-from olive@deep-ocean.net) Received: by APastourelles-102-1-2-26.abo.wanadoo.fr (Postfix, from userid 1001) id 42BC925442; Wed, 25 Jul 2001 12:28:39 +0200 (CEST) Date: Wed, 25 Jul 2001 12:28:39 +0200 From: Olivier Cortes To: freebsd-current@freebsd.org Subject: Re: Re: build problem ? Message-ID: <20010725122839.F85594@APastourelles-102-1-2-26.abo.wa> References: <20010724202213.A77937@APastourelles-102-1-2-26.abo.wa> <00f001c11471$0cb17160$7d7885c0@genroco.com> <20010724233142.A81766@APastourelles-102-1-2-26.abo.wa> <5ly9pdyioo.fsf@assaris.sics.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5ly9pdyioo.fsf@assaris.sics.se>; from assar@FreeBSD.ORG on Wed, Jul 25, 2001 at 02:08:07AM +0200 X-Operating-System: FreeBSD 4.3-RC i386 up 6 days, 7:26, 1 user, load averages: 0.49, 0.18, 0.11 Organization: Deep-Ocean Network X-URL: http://www.deep-ocean.net/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jul 25, 2001 at 02:08:07AM +0200, Assar Westerlund wrote: > Olivier Cortes writes: > > fool, fool, fool am i. here it is : > > > > -------------------------- > > mkdep -f .depend -a -nostdinc -DDISASSEMBLER -DNO_X -I/usr/obj/usr/build/src/i 386/usr/include > > Make sure you have usr.bin/doscmd/Makefile version 1.28 (or higher). cvsup should have taken care that, shouldn't it ? anyway, i will wait a bit then cvsup again, then build again. i hope i can become more helpful to this list soon :) olivier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 3:30: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 730A337B408; Wed, 25 Jul 2001 03:29:57 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15PLwL-0000vJ-00; Wed, 25 Jul 2001 12:30:53 +0200 From: Sheldon Hearn To: cokane@FreeBSD.org Cc: current@FreeBSD.org Subject: 3dfx module breaks without /sys symlink Date: Wed, 25 Jul 2001 12:30:53 +0200 Message-ID: <3543.996057053@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Coleman, Could you take a look at the 3dfx module build as handled under the buildkernel target? It breaks on "can't find kernel source" if the /sys symbolic link is broken. It shouldn't need that, right? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 3:45:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id 4D4DB37B405; Wed, 25 Jul 2001 03:45:35 -0700 (PDT) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 716E43E28; Wed, 25 Jul 2001 03:45:34 -0700 (PDT) To: Sheldon Hearn Cc: cokane@FreeBSD.org, current@FreeBSD.org Subject: Re: 3dfx module breaks without /sys symlink In-Reply-To: <3543.996057053@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on "Wed, 25 Jul 2001 12:30:53 +0200" Date: Wed, 25 Jul 2001 03:45:34 -0700 From: Dima Dorfman Message-Id: <20010725104534.716E43E28@bazooka.unixfreak.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sheldon Hearn writes: > > Hi Coleman, > > Could you take a look at the 3dfx module build as handled under the > buildkernel target? It breaks on "can't find kernel source" if the /sys > symbolic link is broken. It shouldn't need that, right? This isn't Coleman's fault; it's a bug in bsd.kmod.mk, which was fixed in r1.86 (or r1.75.2.3 in RELENG_4), and it affects all modules (3dfx is failing because it's first on the list). Are you running a stale -stable (e.g., before 2001/05/18)? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 3:51:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id C686437B401; Wed, 25 Jul 2001 03:51:09 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15PMGk-0006Xg-00; Wed, 25 Jul 2001 12:51:58 +0200 From: Sheldon Hearn To: Dima Dorfman Cc: cokane@FreeBSD.org, current@FreeBSD.org Subject: Re: 3dfx module breaks without /sys symlink In-reply-to: Your message of "Wed, 25 Jul 2001 03:45:34 MST." <20010725104534.716E43E28@bazooka.unixfreak.org> Date: Wed, 25 Jul 2001 12:51:57 +0200 Message-ID: <25151.996058317@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 25 Jul 2001 03:45:34 MST, Dima Dorfman wrote: > This isn't Coleman's fault; it's a bug in bsd.kmod.mk, which was fixed > in r1.86 (or r1.75.2.3 in RELENG_4), and it affects all modules (3dfx > is failing because it's first on the list). Are you running a stale > -stable (e.g., before 2001/05/18)? I'm running -stable as of last week, so no. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 5:55:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id 445DE37B408 for ; Wed, 25 Jul 2001 05:54:58 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac2.wam.umd.edu (IDENT:root@rac2.wam.umd.edu [128.8.10.142]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id IAA09733 for ; Wed, 25 Jul 2001 08:54:53 -0400 (EDT) Received: from rac2.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac2.wam.umd.edu (8.9.3/8.9.3) with SMTP id IAA13346 for ; Wed, 25 Jul 2001 08:54:53 -0400 (EDT) Received: from localhost (culverk@localhost) by rac2.wam.umd.edu (8.9.3/8.9.3) with ESMTP id IAA13342 for ; Wed, 25 Jul 2001 08:54:53 -0400 (EDT) X-Authentication-Warning: rac2.wam.umd.edu: culverk owned process doing -bs Date: Wed, 25 Jul 2001 08:54:53 -0400 (EDT) From: Kenneth Wayne Culver To: freebsd-current@freebsd.org Subject: driver writing newbie Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sorry to post to this forum, but I'm not getting any replies from -hackers or -questions, and I've looked at the webpages on writing device drivers, as well as several other drivers. Here's my problem/question/whatever... I am writing a driver right now for the Hardware monitoring features of the via686a and via686b south bridge chips. I have documentation and have looked at the linux driver to see how things are done. My problem is that I've got the chip probing, and I have the pci_read_config telling me that my device needs a memory port (what's wierd is that I had to use the base register value of the chip instead of PCIR_COMMAND in pci_read_config to get it to tell me that it wanted me to set up a port instead of mem which is 0x70) So I set up the regid as 0x10 (PCIR_MAPS) as outlined in the webpage, and SYS_RES_IOPORT as I found in the pci driver for the es137x sound chip. I've also tried several combinations. So far the only thing I havn't tried is setting the regid to 0x10 (PCIR_MAPS) and using SYS_RES_MEMORY instead of SYS_RES_IOPORT (all these combinations are for use in bus_alloc_resource). The thing is everything I've tried fails to work, so I can't attach my driver because it won't map the resources. Can anyone suggest other things I could try to make this work right? Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 6: 1:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from po4.wam.umd.edu (po4.wam.umd.edu [128.8.10.166]) by hub.freebsd.org (Postfix) with ESMTP id 6566337B407 for ; Wed, 25 Jul 2001 06:01:33 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac2.wam.umd.edu (IDENT:root@rac2.wam.umd.edu [128.8.10.142]) by po4.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA14772 for ; Wed, 25 Jul 2001 09:01:31 -0400 (EDT) Received: from rac2.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac2.wam.umd.edu (8.9.3/8.9.3) with SMTP id JAA15003 for ; Wed, 25 Jul 2001 09:01:30 -0400 (EDT) Received: from localhost (culverk@localhost) by rac2.wam.umd.edu (8.9.3/8.9.3) with ESMTP id JAA14999 for ; Wed, 25 Jul 2001 09:01:30 -0400 (EDT) X-Authentication-Warning: rac2.wam.umd.edu: culverk owned process doing -bs Date: Wed, 25 Jul 2001 09:01:30 -0400 (EDT) From: Kenneth Wayne Culver To: freebsd-current@FreeBSD.ORG Subject: Re: driver writing newbie In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 25 Jul 2001, Kenneth Wayne Culver wrote: > Sorry to post to this forum, but I'm not getting any replies from -hackers > or -questions, and I've looked at the webpages on writing device drivers, > as well as several other drivers. Here's my problem/question/whatever... > > I am writing a driver right now for the Hardware monitoring features of > the via686a and via686b south bridge chips. I have documentation and have > looked at the linux driver to see how things are done. My problem is that > I've got the chip probing, and I have the pci_read_config telling me that > my device needs a memory port (what's wierd is that I had to use the base > register value of the chip instead of PCIR_COMMAND in pci_read_config to > get it to tell me that it wanted me to set up a port instead of mem which > is 0x70) So I set up the regid as 0x10 (PCIR_MAPS) as outlined in the I meant above that the base register is 0x70 for my chip... > webpage, and SYS_RES_IOPORT as I found in the pci driver for the es137x > sound chip. I've also tried several combinations. So far the only thing I > havn't tried is setting the regid to 0x10 (PCIR_MAPS) and using > SYS_RES_MEMORY instead of SYS_RES_IOPORT (all these combinations are for > use in bus_alloc_resource). The thing is everything I've tried fails to > work, so I can't attach my driver because it won't map the resources. > > Can anyone suggest other things I could try to make this work right? > > Ken > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 8:13:36 2001 Delivered-To: freebsd-current@freebsd.org Received: from ms4.kntech.com.tw (ms4.kntech.com.tw [210.200.114.14]) by hub.freebsd.org (Postfix) with ESMTP id 7492137B803 for ; Wed, 25 Jul 2001 08:09:36 -0700 (PDT) (envelope-from jingdian@ms4.kntech.com.tw) Received: from ms4.kntech.com.tw (121-93.kntech.com.tw [210.201.121.93]) by ms4.kntech.com.tw (8.9.3/8.9.3) with ESMTP id XAA19127 for ; Wed, 25 Jul 2001 23:11:16 +0800 Message-ID: <285522001732515168350@ms4.kntech.com.tw> X-EM-Version: 5, 0, 0, 21 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "jingdian@ms4.kntech.com.tw" To: current@freebsd.org Subject: ĶX§@ĨøđšīĢŪŨ Date: Wed, 25 Jul 2001 23:16:08 +0800 MIME-Version: 1.0 Content-type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG =B7=FA=C2I=BCs=A7i=B3=D0=B7N=A7{ =A6X=A7@=A5=F8=B9=BA=B4=A3=AE=D7 =B7=FA=C2I=B3=D0=B7N=AA=BA=A4u=A7@=A6=A8=AD=FB=B3=A3=A5H=BE=D6=A6=B3=AC= =DB=B7=ED=AA=BA=A4u=A7@=AF=E0=A4O=A9M=B8g=C5=E7=AC=B0=B3=CC=A4j=AA=BA=B8=EA= =B2=A3=A1A=A6U=AD=D3=A6=A8=AD=FB=BF=EC=A8=C6=AE=C4=B2v=A9M=B0t=A6X=AB=D7=B0= =AA=A1A=AF=E0=A5H=B3=CC=B5u=AA=BA=AE=C9=B6=A1=A7=B9=A6=A8=B3=CC=BA=EB=BDo=AA= =BA=A7@=AB~=A1A=A4=A3=BD=D7=A6b=A5=F8=B9=BA=BBs=A7@=B0=F5=A6=E6=A1A=C1=D9=AC= O=A6b=B1=C4=B3X=C4=E1=BCv=A1B=B3]=ADp=BDs=BF=E8=A4W=B3=A3=AF=E0=A7@=B3=CC=B7= =A5=A6=DC=AA=BA=B5o=B4=A7=A1C =B7=FA=C2I=AA=BA=B1M=AA=F8=A6b=A9=F3=A9=D3=BF=EC=AC=A1=B0=CA=A5=F8=B9=BA= =A1B=A4=E5=BDZ=BDs=BC=B6=A1B=B3]=ADp=BDs=B1=C6=A1B=B1=C4=B3X=C4=E1=BCv=B5=A5= =A1A=AA=C3=AB=F9=B5=DB=B4=A3=A8=D1=B3=CC=B9=EA=B4f=AA=BA=BB=F9=AE=E6=A4=CE= =B3=CC=BA=EB=BDo=AA=BA=A7@=AB~=AA=BA=B2z=A9=C0=A1A=A6b=AE=C9=AE=C4=BBP=AF=C0= =BD=E8=A4W=A7@=B3=CC=A8=CE=B0t=A6X=A1C=A7=DA=AD=CC=A4=F1=AB=C8=A4=E1=A7=F3= =AD=AB=B5=F8=A7@=AB~=AA=BA=B5=F8=C4=B1=AE=C4=AAG=BBP=A4=E5=A6r=B6=C7=B9F=A1= A=A7=C6=B1=E6=BBP=B6Q=A4=BD=A5q=A7@=AA=F8=B4=C1=A9=CA=B0t=A6X=A1A=B0=F6=BE= i=A5X=A4u=A7@=C0q=AB=B4=A1A=A7=F3=A5[=B9F=A8=EC=B6=C7=B4C=AE=C4=AAG=A1C =B9=EF=A9=F3=A5=D8=ABe=A5=FE=AD=B1=A9=CA=AA=BA=B4=BA=AE=F0=AA=AC=AAp=A1= A=B3\=A6h=AA=BA=A5=F8=B9=BA=B9w=BA=E2=ABK=AA=BA=AC=DB=B7=ED=A6=B3=AD=AD=A1= A=B7=FA=C2I=B0=B5=A8=EC=A5=CE=B3=CC=A6X=B2z=AA=BA=B9w=BA=E2=A7@=B3=CC=A4j=AD= =AD=AB=D7=AA=BA=B5o=B4=A7=A1A=B1N=B8g=B6O=B5o=B4=A7=B7=A5=ADP=A1B=AC=B0=B1= z=AA=BA=B9w=BA=E2=A7=E2=C3=F6=A1A=B4N=ACO=A7=DA=AD=CC=A6=A8=B4N=B7P=AA=BA=A8= =D3=B7=BD=A1C =A1i=AAA=B0=C8=B6=B5=A5=D8=A1j =A1=B4=A4j=AB=AC Event =AC=A1=B0=CA =A5=AE=B8X=B6=E9=BF=CB=A4l=AC=A1=B0=CA=A1B=B1=DF=B7|=A1B=C5S=C0=E7=AC=A1=B0= =CA=2E=2E=2E=2E=2E=2E=20 =B1M=C3D=BAt=C1=BF=B3W=B9=BA=A6w=B1=C6 =B9{=BC=FA=B1=C2=C3=D2=A8=E5=C2=A7 =B1B=C2=A7=AC=A1=B0=CA=A5=F8=B9=BA=B3]=ADp=20 =A4=BD=AFq=A9=CA=AC=A1=B0=CA =AEi=A5=DC=AC=A1=B0=CA =A4j=AB=AC=B3y=B6=D5=AC=A1=B0=CA =A5=F8=B7~=A6~=B7|=A1B=B1=DF=B7| =B0=EA=BB=DA=BCv=AEi =B6=E9=B9C=B7| =B6g=A6~=BCy =A4j=AB=AC=B9B=B0=CA=B7|=2E=2E=2E=2E=2E=2E =A1=B4=A6=E6=BEP=AC=A1=B0=CA =A4u=B0=D3SP=ABP=BEP=AC=A1=B0=CA =A8=C6=A5=F3=A6=E6=BEP =B1M=AE=D7=AC=A1=B0=CA =A6U=C3=FE=A6=E6=BEP=B5o=AA=ED=B7| =B2=A3=AB~=B5o=AA=ED=B7| =AEi=A5=DC=B7|=2E=2E=2E=2E=2E=2E =A1=B4=B4C=C5=E9=BE=E3=A6X =B0O=AA=CC=B7| =B4C=C5=E9=C3=F6=ABY =B4C=C5=E9=B9w=BA=E2=B0=F5=A6=E6=2E=2E=2E=2E=2E=2E =A1=B4=AE=D5=B6=E9=AC=A1=B0=CA =BAt=B0=DB=B7| =BBR=B7| =BAq=B0=DB=A4j=C1=C9=2E=2E=2E=2E=2E=2E =A1=B4=B5=F8=C4=B1=B3]=ADp CIS =B3W=B9=BA=B3]=ADp =B2=A3=AB~=A5]=B8=CB=B3]=ADp =AB=C5=B6=C7=B3=E6=BBs=A7@ =BCs=A7i=AC=DD=AAO =A4j=AB=AC=BF=E9=A5X =A5=AD=AD=B1=B4C=C5=E9=2E=2E=2E=2E=2E=2E =A1i=A5=AD=AD=B1=A4@=AF=EB=A6=AC=B6O=A1j =B3]=ADp=B6O=A5=CE=A1G =AA=A9=AD=B1=B3]=ADp =A8C=AD=B6600=A4=B8=A1]=AE=D1=C4= y=A4=BA=AD=B6=A1^ DM=A1B=AE=FC=B3=F8=B3]=ADp A4=B3=E6=AD=B11000=A4=B8 =A7=B9=BDZ=B6O=A5=CE=A1G A4 1=AD=B6 450=A4=B8 A4 16=AD=B6=A5H=A4W =A8C=AD=B6350=A4=B8 A4 100=AD=B6=A5H=A4W =A8C=AD=B6300=A4=B8 P=2ES=2E=A5h=ADI=B9=CF=A5t=ADp =A8C=B9=CF30=A4=B8 =A8=E4=A5L=AA=BA=B0t=A6X=B6=B5=A5=D8=B2=D3=B8`=A6A=C4=B3 =AC=B0=B1z=AA=BA=B9w=BA=E2=A7=E2=C3=F6=A1I =A7=C6=B1=E6=B6Q=A4=BD=A5q=AF=E0=A6=A8=AC=B0=A7=DA=AD=CC=AA=BA=A6X=A7@=A5=EB= =A6=F1=A1A=C5=FD=A7=DA=AD=CC=AC=B0=B6Q=A4=BD=A5q=BD=E8=B6q=A8=AD=ADq=A7@=B3= =CC=A6X=BEA=AA=BA=A5=F8=B9=BA=A6=D3=A7=F3=B3=D0=A8=CE=C1Z=A1I =A6=ED=A7}=A1G=A5x=A4=A4=A5=AB=A4=E5=A4=DF=B8=F4=A5|=ACq182=B8=B915=BC=D3=A4= =A77 =B9q=B8=DC=A1G04-22912347 =A5=F8=B9=BA=B0=F5=A6=E6 =AA=F4=B1=D2=BB=A8 0922789018 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 8:20:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from ms4.kntech.com.tw (ms4.kntech.com.tw [210.200.114.14]) by hub.freebsd.org (Postfix) with ESMTP id C322637B882 for ; Wed, 25 Jul 2001 08:16:27 -0700 (PDT) (envelope-from jingdian@ms4.kntech.com.tw) Received: from ms4.kntech.com.tw (121-93.kntech.com.tw [210.201.121.93]) by ms4.kntech.com.tw (8.9.3/8.9.3) with ESMTP id XAA19631 for ; Wed, 25 Jul 2001 23:18:17 +0800 Message-ID: <47242001732515239630@ms4.kntech.com.tw> X-EM-Version: 5, 0, 0, 21 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 X-MSMail-Priority: Normal From: "jingdian@ms4.kntech.com.tw" To: current@freebsd.org Subject: ĶX§@ĨøđšīĢŪŨ Date: Wed, 25 Jul 2001 23:23:09 +0800 MIME-Version: 1.0 Content-type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG =B7=FA=C2I=BCs=A7i=B3=D0=B7N=A7{ =A6X=A7@=A5=F8=B9=BA=B4=A3=AE=D7 =B7=FA=C2I=B3=D0=B7N=AA=BA=A4u=A7@=A6=A8=AD=FB=B3=A3=A5H=BE=D6=A6=B3=AC= =DB=B7=ED=AA=BA=A4u=A7@=AF=E0=A4O=A9M=B8g=C5=E7=AC=B0=B3=CC=A4j=AA=BA=B8=EA= =B2=A3=A1A=A6U=AD=D3=A6=A8=AD=FB=BF=EC=A8=C6=AE=C4=B2v=A9M=B0t=A6X=AB=D7=B0= =AA=A1A=AF=E0=A5H=B3=CC=B5u=AA=BA=AE=C9=B6=A1=A7=B9=A6=A8=B3=CC=BA=EB=BDo=AA= =BA=A7@=AB~=A1A=A4=A3=BD=D7=A6b=A5=F8=B9=BA=BBs=A7@=B0=F5=A6=E6=A1A=C1=D9=AC= O=A6b=B1=C4=B3X=C4=E1=BCv=A1B=B3]=ADp=BDs=BF=E8=A4W=B3=A3=AF=E0=A7@=B3=CC=B7= =A5=A6=DC=AA=BA=B5o=B4=A7=A1C =B7=FA=C2I=AA=BA=B1M=AA=F8=A6b=A9=F3=A9=D3=BF=EC=AC=A1=B0=CA=A5=F8=B9=BA= =A1B=A4=E5=BDZ=BDs=BC=B6=A1B=B3]=ADp=BDs=B1=C6=A1B=B1=C4=B3X=C4=E1=BCv=B5=A5= =A1A=AA=C3=AB=F9=B5=DB=B4=A3=A8=D1=B3=CC=B9=EA=B4f=AA=BA=BB=F9=AE=E6=A4=CE= =B3=CC=BA=EB=BDo=AA=BA=A7@=AB~=AA=BA=B2z=A9=C0=A1A=A6b=AE=C9=AE=C4=BBP=AF=C0= =BD=E8=A4W=A7@=B3=CC=A8=CE=B0t=A6X=A1C=A7=DA=AD=CC=A4=F1=AB=C8=A4=E1=A7=F3= =AD=AB=B5=F8=A7@=AB~=AA=BA=B5=F8=C4=B1=AE=C4=AAG=BBP=A4=E5=A6r=B6=C7=B9F=A1= A=A7=C6=B1=E6=BBP=B6Q=A4=BD=A5q=A7@=AA=F8=B4=C1=A9=CA=B0t=A6X=A1A=B0=F6=BE= i=A5X=A4u=A7@=C0q=AB=B4=A1A=A7=F3=A5[=B9F=A8=EC=B6=C7=B4C=AE=C4=AAG=A1C =B9=EF=A9=F3=A5=D8=ABe=A5=FE=AD=B1=A9=CA=AA=BA=B4=BA=AE=F0=AA=AC=AAp=A1= A=B3\=A6h=AA=BA=A5=F8=B9=BA=B9w=BA=E2=ABK=AA=BA=AC=DB=B7=ED=A6=B3=AD=AD=A1= A=B7=FA=C2I=B0=B5=A8=EC=A5=CE=B3=CC=A6X=B2z=AA=BA=B9w=BA=E2=A7@=B3=CC=A4j=AD= =AD=AB=D7=AA=BA=B5o=B4=A7=A1A=B1N=B8g=B6O=B5o=B4=A7=B7=A5=ADP=A1B=AC=B0=B1= z=AA=BA=B9w=BA=E2=A7=E2=C3=F6=A1A=B4N=ACO=A7=DA=AD=CC=A6=A8=B4N=B7P=AA=BA=A8= =D3=B7=BD=A1C =A1i=AAA=B0=C8=B6=B5=A5=D8=A1j =A1=B4=A4j=AB=AC Event =AC=A1=B0=CA =A5=AE=B8X=B6=E9=BF=CB=A4l=AC=A1=B0=CA=A1B=B1=DF=B7|=A1B=C5S=C0=E7=AC=A1=B0= =CA=2E=2E=2E=2E=2E=2E=20 =B1M=C3D=BAt=C1=BF=B3W=B9=BA=A6w=B1=C6 =B9{=BC=FA=B1=C2=C3=D2=A8=E5=C2=A7 =B1B=C2=A7=AC=A1=B0=CA=A5=F8=B9=BA=B3]=ADp=20 =A4=BD=AFq=A9=CA=AC=A1=B0=CA =AEi=A5=DC=AC=A1=B0=CA =A4j=AB=AC=B3y=B6=D5=AC=A1=B0=CA =A5=F8=B7~=A6~=B7|=A1B=B1=DF=B7| =B0=EA=BB=DA=BCv=AEi =B6=E9=B9C=B7| =B6g=A6~=BCy =A4j=AB=AC=B9B=B0=CA=B7|=2E=2E=2E=2E=2E=2E =A1=B4=A6=E6=BEP=AC=A1=B0=CA =A4u=B0=D3SP=ABP=BEP=AC=A1=B0=CA =A8=C6=A5=F3=A6=E6=BEP =B1M=AE=D7=AC=A1=B0=CA =A6U=C3=FE=A6=E6=BEP=B5o=AA=ED=B7| =B2=A3=AB~=B5o=AA=ED=B7| =AEi=A5=DC=B7|=2E=2E=2E=2E=2E=2E =A1=B4=B4C=C5=E9=BE=E3=A6X =B0O=AA=CC=B7| =B4C=C5=E9=C3=F6=ABY =B4C=C5=E9=B9w=BA=E2=B0=F5=A6=E6=2E=2E=2E=2E=2E=2E =A1=B4=AE=D5=B6=E9=AC=A1=B0=CA =BAt=B0=DB=B7| =BBR=B7| =BAq=B0=DB=A4j=C1=C9=2E=2E=2E=2E=2E=2E =A1=B4=B5=F8=C4=B1=B3]=ADp CIS =B3W=B9=BA=B3]=ADp =B2=A3=AB~=A5]=B8=CB=B3]=ADp =AB=C5=B6=C7=B3=E6=BBs=A7@ =BCs=A7i=AC=DD=AAO =A4j=AB=AC=BF=E9=A5X =A5=AD=AD=B1=B4C=C5=E9=2E=2E=2E=2E=2E=2E =A1i=A5=AD=AD=B1=A4@=AF=EB=A6=AC=B6O=A1j =B3]=ADp=B6O=A5=CE=A1G =AA=A9=AD=B1=B3]=ADp =A8C=AD=B6600=A4=B8=A1]=AE=D1=C4= y=A4=BA=AD=B6=A1^ DM=A1B=AE=FC=B3=F8=B3]=ADp A4=B3=E6=AD=B11000=A4=B8 =A7=B9=BDZ=B6O=A5=CE=A1G A4 1=AD=B6 450=A4=B8 A4 16=AD=B6=A5H=A4W =A8C=AD=B6350=A4=B8 A4 100=AD=B6=A5H=A4W =A8C=AD=B6300=A4=B8 P=2ES=2E=A5h=ADI=B9=CF=A5t=ADp =A8C=B9=CF30=A4=B8 =A8=E4=A5L=AA=BA=B0t=A6X=B6=B5=A5=D8=B2=D3=B8`=A6A=C4=B3 =AC=B0=B1z=AA=BA=B9w=BA=E2=A7=E2=C3=F6=A1I =A7=C6=B1=E6=B6Q=A4=BD=A5q=AF=E0=A6=A8=AC=B0=A7=DA=AD=CC=AA=BA=A6X=A7@=A5=EB= =A6=F1=A1A=C5=FD=A7=DA=AD=CC=AC=B0=B6Q=A4=BD=A5q=BD=E8=B6q=A8=AD=ADq=A7@=B3= =CC=A6X=BEA=AA=BA=A5=F8=B9=BA=A6=D3=A7=F3=B3=D0=A8=CE=C1Z=A1I =A6=ED=A7}=A1G=A5x=A4=A4=A5=AB=A4=E5=A4=DF=B8=F4=A5|=ACq182=B8=B915=BC=D3=A4= =A77 =B9q=B8=DC=A1G04-22912347 =A5=F8=B9=BA=B0=F5=A6=E6 =AA=F4=B1=D2=BB=A8 0922789018 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 8:44:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id 016F437B403 for ; Wed, 25 Jul 2001 08:44:47 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac2.wam.umd.edu (IDENT:root@rac2.wam.umd.edu [128.8.10.142]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id LAA23522; Wed, 25 Jul 2001 11:44:21 -0400 (EDT) Received: from rac2.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac2.wam.umd.edu (8.9.3/8.9.3) with SMTP id LAA22398; Wed, 25 Jul 2001 11:44:20 -0400 (EDT) Received: from localhost (culverk@localhost) by rac2.wam.umd.edu (8.9.3/8.9.3) with ESMTP id LAA22394; Wed, 25 Jul 2001 11:44:20 -0400 (EDT) X-Authentication-Warning: rac2.wam.umd.edu: culverk owned process doing -bs Date: Wed, 25 Jul 2001 11:44:20 -0400 (EDT) From: Kenneth Wayne Culver To: Juha.Nurmela@quicknet.inet.fi Cc: freebsd-current@freebsd.org Subject: Re: driver writing newbie In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Well, I could do that, but I'd rather write a complete driver with all the regular interfaces... (open, close, ioctl, and a specific major/minor in the kernel, I'm going to add other chips to this driver eventually) The way you are suggesting just opens /dev/io and uses inb and outb to do some hacking around I believe. Ken On Wed, 25 Jul 2001 Juha.Nurmela@quicknet.inet.fi wrote: > > > Hello Kenneth, > > shouldn't you use 0x70 for the mapping register of HWMon function ? > > With ABit KT7A (686B) > > # pciconf -l > hostb1@pci0:7:4: > class=0x060000 card=0x00000000 chip=0x30571106 rev=0x40 hdr=0x00 > > # pciconf -r pci0:7:4 0x70 > 0x00006001 > > and 0x6000 can be used as an i/o-base by a dirty hack to directly inb() > the monitor data. I stripped it from the NetBSD driver (I think). > > > Juha > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 9: 3:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by hub.freebsd.org (Postfix) with ESMTP id C5ADF37B409; Wed, 25 Jul 2001 09:03:06 -0700 (PDT) (envelope-from mvh@ix.netcom.com) Received: from netcom1.netcom.com (user-2initcl.dialup.mindspring.com [165.121.117.149]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA10343; Wed, 25 Jul 2001 12:02:44 -0400 (EDT) Received: by netcom1.netcom.com (Postfix, from userid 1000) id BFE5413140; Wed, 25 Jul 2001 09:02:28 -0700 (PDT) From: Mike Harding To: carlo@vis.ethz.ch Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org In-reply-to: <20010724201713.5E16E275B6@naboo.ethz.ch> (carlo@vis.ethz.ch) Subject: Re: GNU smalltalk, can't run version 1.96 References: <20010724201713.5E16E275B6@naboo.ethz.ch> Message-Id: <20010725160228.BFE5413140@netcom1.netcom.com> Date: Wed, 25 Jul 2001 09:02:28 -0700 (PDT) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is not entirely an answer, but check out the 'squeak' port, it's a smalltalk VM more like (identical to?) the Xerox one... - Mike H. Date: Tue, 24 Jul 2001 22:17:13 +0200 (CEST) Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset=us-ascii From: carlo@vis.ethz.ch (Carlo Dapor) Sender: owner-freebsd-stable@FreeBSD.ORG List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Precedence: bulk Dear fellow current people It is a quest for the Holy Grail I have embarked weeks ago. The harbours I have peered are: FreeBSD 4.3 and FreeBSD current. The last version I was able to build and run the tests is version 1.8.5, with some patches, both on 4.3 and current. But what I am not successfull with is neither with 1.96 or 1.95.x. I compiles on 4.3 and current, but at runtime I get a segfault. On 4.3, the offending showstopper is around the definition of primitive 184_185 (or similar), whereas on current it around the definition of primitive 203_204, I think. Interestingly, it compiles and runs smoothly on an SMP Linux 2.2.19. I also tried with gcc 3.0 on current, same result. Has anybody had more luck ? Tell me HOW, please. Ciao, derweil, -- Carlo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 9: 4:11 2001 Delivered-To: freebsd-current@freebsd.org Received: from APastourelles-102-1-2-26.abo.wanadoo.fr (APastourelles-102-1-2-26.abo.wanadoo.fr [217.128.208.26]) by hub.freebsd.org (Postfix) with ESMTP id 4104137B40C for ; Wed, 25 Jul 2001 09:03:19 -0700 (PDT) (envelope-from olive@deep-ocean.net) Received: by APastourelles-102-1-2-26.abo.wanadoo.fr (Postfix, from userid 1001) id 8758C2556E; Wed, 25 Jul 2001 18:03:13 +0200 (CEST) Date: Wed, 25 Jul 2001 18:03:13 +0200 From: Olivier Cortes To: freebsd-current@freebsd.org Subject: hum,hum...another build problem... Message-ID: <20010725180313.A87749@APastourelles-102-1-2-26.abo.wa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.3-RC i386 up 6 days, 13:05, 1 user, load averages: 0.01, 0.02, 0.04 Organization: Deep-Ocean Network X-URL: http://www.deep-ocean.net/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi everyone, this time it is the kernel. i know acpica is in heavy dev. but here's my problem : make buildkernel KERNCONF=NEPTUNE: ---------------------- cc -nostdinc -O -pipe -march=pentiumpro -march=pentiumpro -I/usr/obj/usr/build/src/i386/usr/include -c /usr/build/src/sys/i386/acpica/acpi_wakecode.S /usr/build/src/sys/i386/acpica/acpi_wakecode.S:32: machine/specialreg.h: No such file or directory *** Error code 1 Stop in /usr/build/obj/usr/build/src/sys/NEPTUNE. *** Error code 1 Stop in /usr/build/obj/usr/build/src/sys/NEPTUNE. *** Error code 1 Stop in /usr/build/obj/usr/build/src/sys/NEPTUNE. *** Error code 1 Stop in /usr/build/src. *** Error code 1 Stop in /usr/build/src. ---------------------- if you want, you have all files (KERNEL, makekernel.out, dmesg.out) at http://www.deep-ocean.net/~olive/files/. needless to say that my last cvsup is 10 minutes ago. thanks for your advices. as a side note, i resolved the problem of my disks (IBM-DTLA) falling back to PIO4 and hanging the kernel when tagging enabled in /boot/loader.conf : i used to have all my disks in racks. i just put them directly in the box, and all my problem flew away. my builds are much faster : now i can crash many times a day ;-)) regards, Olivier PS: don't pay attention to my strange humor if you don't like it. Sometimes I can't even understand it ;-p To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 9: 7:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from lpr-325.cable.inet.fi (lpr-325.cable.inet.fi [194.251.103.37]) by hub.freebsd.org (Postfix) with ESMTP id 4961637B41D for ; Wed, 25 Jul 2001 09:05:59 -0700 (PDT) (envelope-from Juha.Nurmela@quicknet.inet.fi) Received: from localhost (junki@localhost) by lpr-325.cable.inet.fi (8.11.4/8.11.4) with ESMTP id f6PG6Cd00706; Wed, 25 Jul 2001 19:06:12 +0300 (EEST) (envelope-from Juha.Nurmela@quicknet.inet.fi) Date: Wed, 25 Jul 2001 19:06:12 +0300 (EEST) From: Juha.Nurmela@quicknet.inet.fi X-Sender: junki@lpr-325.cable.inet.fi Reply-To: Juha.Nurmela@quicknet.inet.fi To: Kenneth Wayne Culver Cc: freebsd-current@freebsd.org Subject: Re: driver writing newbie In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 25 Jul 2001, Kenneth Wayne Culver wrote: > Well, I could do that, but I'd rather write a complete driver with all the > regular interfaces... (open, close, ioctl, and a specific major/minor in > the kernel, I'm going to add other chips to this driver eventually) The > way you are suggesting just opens /dev/io and uses inb and outb to do some > hacking around I believe. You are absolutely correct. I was not suggesting this as the proper approach, but as a throw-away checkpoint only (the mapping registers seemed inconsistent between OS/motherboard combinations). I suppose 0x70 is for HWMon and 0x90 is for the SMBus function, in Via 686B. Have you checked NetBSD, the seem to have a framework for temperature alarms etc. Juha To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 9:12: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from naboo.ethz.ch (naboo.ethz.ch [129.132.17.66]) by hub.freebsd.org (Postfix) with ESMTP id 5550737B413; Wed, 25 Jul 2001 09:11:41 -0700 (PDT) (envelope-from carlo@vis.ethz.ch) Received: by naboo.ethz.ch (Postfix, from userid 224) id 77F09275B8; Wed, 25 Jul 2001 18:11:12 +0200 (CEST) Subject: Re: GNU smalltalk, can't run version 1.96 To: mvh@ix.netcom.com (Mike Harding) Date: Wed, 25 Jul 2001 18:11:12 +0200 (CEST) Cc: carlo@vis.ethz.ch, freebsd-current@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: <20010725160228.BFE5413140@netcom1.netcom.com> from "Mike Harding" at Jul 25, 2001 09:02:28 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010725161112.77F09275B8@naboo.ethz.ch> From: carlo@vis.ethz.ch (Carlo Dapor) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks, I have known and used Squeak for a long time. My ineterest in GNU Smalltalk is given to the fact that it comes with a JIT, and it has an early support for Gtk. Squeak is quite strongly Tc/Tkl-based. This is not a flame, whichever widget set is used is not saying anything bad/ good about the application as a whole. Ciao, derweil, -- Carlo > This is not entirely an answer, but check out the 'squeak' port, it's > a smalltalk VM more like (identical to?) the Xerox one... > > - Mike H. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 10: 7:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from APastourelles-102-1-2-26.abo.wanadoo.fr (APastourelles-102-1-2-26.abo.wanadoo.fr [217.128.208.26]) by hub.freebsd.org (Postfix) with ESMTP id 81A6937B407 for ; Wed, 25 Jul 2001 10:07:26 -0700 (PDT) (envelope-from olive@deep-ocean.net) Received: by APastourelles-102-1-2-26.abo.wanadoo.fr (Postfix, from userid 1001) id BBD3025571; Wed, 25 Jul 2001 19:07:23 +0200 (CEST) Date: Wed, 25 Jul 2001 19:07:23 +0200 From: Olivier Cortes To: freebsd-current@freebsd.org Subject: buildkernel [SOLVED] Message-ID: <20010725190723.A88896@APastourelles-102-1-2-26.abo.wa> Mail-Followup-To: Olivier Cortes , freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.3-RC i386 up 6 days, 14:31, 1 user, load averages: 0.22, 0.30, 0.15 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I added some lines to my kernel config file: WITNESS DDB bktr (i have one) all the smb/smbus stuff agp and it compiled fine. now i go for the world. on my computer, it seems to be a long story... ;-) -- Olivier Cortes To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 12:30: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 07C4237B405 for ; Wed, 25 Jul 2001 12:29:53 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15PUMr-0000E5-00 for current@FreeBSD.org; Wed, 25 Jul 2001 21:30:49 +0200 From: Sheldon Hearn To: current@FreeBSD.org Subject: Help wanted: loadable SMBFS Date: Wed, 25 Jul 2001 21:30:49 +0200 Message-ID: <872.996089449@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi folks, This is a copy of a message I sent to cvs-all, requesting help with kernel loadable SMBFS support without the need for LIBICONV statically linked into the kernel. Ciao, Sheldon. ------- Forwarded Message Date: Wed, 25 Jul 2001 21:29:18 +0200 From: Sheldon Hearn To: cvs-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/modules/libiconv Makefile Message-ID: <854.996089358@axl.seasidesoftware.co.za> On Wed, 25 Jul 2001 12:21:06 MST, Sheldon Hearn wrote: > Added files: > sys/modules/libiconv Makefile > Log: > Add build infrastructure for a libiconv loadable kernel module. > > This should allow the use of the smbfs module without the > requirement to rebuild the kernel with LIBICONV. I haven't connected this to the modules build because I can't test that it works. Sure, it loads fine, but I get a reproducible kernel mode page fault in the rl(4) interrupt handler when I actually try to use it. 1) Start with smbfs.ko, libiconv.ko, libmchain.ko neither loaded nor statically linked. 2) Configure an SMB mount as per normal (e.g. edit /etc/fstab and /usr/local/etc/nsmb.conf). 3) Try to mount the share (e.g. mount /smb/mydomain/mypeer). At this point, I get my trap. Of course, I can't get a crash dump, because the DDB panic command dies a horrible death as the kernel squeals about lockmgr locking against itself. If I could get feedback on this from both rl(4) users and users of other NIC drivers, I'd be ecstatic. On the other hand, a functional kernel debugger wouldn't hurt. Ciao, Sheldon. ------- End of Forwarded Message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 13: 8:35 2001 Delivered-To: freebsd-current@freebsd.org Received: from po3.wam.umd.edu (po3.wam.umd.edu [128.8.10.165]) by hub.freebsd.org (Postfix) with ESMTP id A97DB37B40D for ; Wed, 25 Jul 2001 13:08:30 -0700 (PDT) (envelope-from culverk@wam.umd.edu) Received: from rac2.wam.umd.edu (IDENT:root@rac2.wam.umd.edu [128.8.10.142]) by po3.wam.umd.edu (8.9.3/8.9.3) with ESMTP id QAA02800; Wed, 25 Jul 2001 16:08:27 -0400 (EDT) Received: from rac2.wam.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by rac2.wam.umd.edu (8.9.3/8.9.3) with SMTP id QAA17611; Wed, 25 Jul 2001 16:08:27 -0400 (EDT) Received: from localhost (culverk@localhost) by rac2.wam.umd.edu (8.9.3/8.9.3) with ESMTP id QAA17607; Wed, 25 Jul 2001 16:08:27 -0400 (EDT) X-Authentication-Warning: rac2.wam.umd.edu: culverk owned process doing -bs Date: Wed, 25 Jul 2001 16:08:27 -0400 (EDT) From: Kenneth Wayne Culver To: Juha.Nurmela@quicknet.inet.fi Cc: freebsd-current@freebsd.org Subject: Re: driver writing newbie In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I havn't checked, but I'll probably do that soon. Ken On Wed, 25 Jul 2001 Juha.Nurmela@quicknet.inet.fi wrote: > > > On Wed, 25 Jul 2001, Kenneth Wayne Culver wrote: > > > Well, I could do that, but I'd rather write a complete driver with all the > > regular interfaces... (open, close, ioctl, and a specific major/minor in > > the kernel, I'm going to add other chips to this driver eventually) The > > way you are suggesting just opens /dev/io and uses inb and outb to do some > > hacking around I believe. > > You are absolutely correct. I was not suggesting this as the proper > approach, but as a throw-away checkpoint only (the mapping registers > seemed inconsistent between OS/motherboard combinations). I suppose > 0x70 is for HWMon and 0x90 is for the SMBus function, in Via 686B. > > Have you checked NetBSD, the seem to have a framework for temperature > alarms etc. > > > Juha > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 13:18:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with SMTP id 4E82637B405 for ; Wed, 25 Jul 2001 13:18:37 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 92268 invoked from network); 25 Jul 2001 20:18:36 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 25 Jul 2001 20:18:36 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200107241207.VAA14339@zodiac.mech.utsunomiya-u.ac.jp> Date: Wed, 25 Jul 2001 13:18:35 -0700 (PDT) From: John Baldwin To: Kazutaka YOKOTA Subject: RE: Death sentence to KLD screen savers? Comments? Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 24-Jul-01 Kazutaka YOKOTA wrote: > This is to propose to abolish KLD screen saver modules. > > KLD screen savers have the following problems/deficiencies. > > - It is too easy to abuse the power of being run in the kernel > mode. The screen saver is invoked periodically once the console > becomes idle. It should not spend long time to draw something > to the screen. But, we may be tempted to do a bit more elaborate > drawing so that we get "interesting" effects. It's too easy to > degrade the system performance by staying in the screen saver > too long. You can stick the screen saver in a low priority kthread and achieve the same effect. > - While it is easy to manipulate the video board in the KLD module > (because we can go anywhere and access anything :-), there are > limitations. If you want to perform file I/O (to obtain some > bitmaps from files), or want to read some sort of configuration > file, there is no straight forward way to do so. You can use kldload or the loader with the -t 'foo' stuff to load configuration files, etc. that modules can get at. Just pointing out that userland is not the only way of achieving your goals. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 13:58:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id 6F1C937B405; Wed, 25 Jul 2001 13:58:22 -0700 (PDT) (envelope-from vince@oahu.WURLDLINK.NET) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.11.3/8.11.3) with ESMTP id f6PKwCn10514; Wed, 25 Jul 2001 10:58:13 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Wed, 25 Jul 2001 10:58:11 -1000 (HST) From: Vincent Poy To: , Subject: current kernel build fails with src/sys/kern/sys_socket.c v 1.34 2001/07/25 20:14:59 fenner Message-ID: <20010725105545.J50475-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems with the src/sys/kern/sys_socket.c v 1.34 2001/07/25 20:14:59 fenner committed today, kernel build fails in -current as follows: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/kern/sys_socket.c /usr/src/sys/kern/sys_socket.c: In function `soo_ioctl': /usr/src/sys/kern/sys_socket.c:145: too few arguments to function `rtioctl' *** Error code 1 Stop in /usr/obj/usr/src/sys/PELE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. root@pele [10:47am][/usr/src] >> Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 14: 6: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 5312637B405 for ; Wed, 25 Jul 2001 14:06:05 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 0ACB84CE4E; Wed, 25 Jul 2001 17:06:01 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA03767; Wed, 25 Jul 2001 17:06:00 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA09602; Wed, 25 Jul 2001 14:06:00 -0700 (PDT) Message-Id: <200107252106.OAA09602@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: vince@oahu.wurldlink.net Subject: Re: current kernel build fails with src/sys/kern/sys_socket.c v 1.34 2001/07/25 20:14:59 fenner Cc: current@freebsd.org Date: Wed, 25 Jul 2001 14:06:00 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You must have updated in the middle of the commit. Make sure you have rev 1.38 of src/sys/net/route.h . Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 14:16:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id 6203F37B401 for ; Wed, 25 Jul 2001 14:16:50 -0700 (PDT) (envelope-from vince@oahu.WURLDLINK.NET) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.11.3/8.11.3) with ESMTP id f6PLGcG10906; Wed, 25 Jul 2001 11:16:38 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Wed, 25 Jul 2001 11:16:37 -1000 (HST) From: Vincent Poy To: Bill Fenner Cc: Subject: Re: current kernel build fails with src/sys/kern/sys_socket.c v 1.34 2001/07/25 20:14:59 fenner In-Reply-To: <200107252106.OAA09602@windsor.research.att.com> Message-ID: <20010725111508.Q50475-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 25 Jul 2001, Bill Fenner wrote: > You must have updated in the middle of the commit. Make sure you have > rev 1.38 of src/sys/net/route.h . You're right about this one... I looked at the commit messages and cvsup did update route.h from what I saw but somehow I still have 1.37 of the src/sys/net/route.h $FreeBSD: src/sys/net/route.h,v 1.37 2000/07/21 23:26:36 jayanth Exp $ Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 18:14:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 0E21437B401 for ; Wed, 25 Jul 2001 18:14:43 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15PZka-00082f-00 for current@FreeBSD.org; Thu, 26 Jul 2001 03:15:40 +0200 From: Sheldon Hearn To: current@FreeBSD.org Subject: su root broken in -CURRENT Date: Thu, 26 Jul 2001 03:15:38 +0200 Message-ID: <30911.996110138@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi folks, I've completed a pretty clean crossgrade [1] to -CURRENT and find that su is broken. I thought this had been fixed. I have a virgin rev 1.17 /etc/pam.conf, I'm in group wheel, I built world with no funky options, the su binary (built from su rev 1.39) really is setuid root and yet I get the amazingly helpful error message: su: Sorry without being prompted for a password. /var/log/messages contains the infinitely more helpful error message su: pam_authenticate: Permission denied So what's up? Ciao, Sheldon. [1] I can't bring myself to call the process of converting from 4.3-STABLE to 5.0-CURRENT an "upgrade". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 18:45:20 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id E49D737B401 for ; Wed, 25 Jul 2001 18:45:17 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15PaEB-000H3D-00 for current@FreeBSD.org; Thu, 26 Jul 2001 03:46:15 +0200 From: Sheldon Hearn To: current@FreeBSD.org Subject: Re: su root broken in -CURRENT In-reply-to: Your message of "Thu, 26 Jul 2001 03:15:38 +0200." <30911.996110138@axl.seasidesoftware.co.za> Date: Thu, 26 Jul 2001 03:46:15 +0200 Message-ID: <65545.996111975@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 26 Jul 2001 03:15:38 +0200, Sheldon Hearn wrote: > I've completed a pretty clean crossgrade [1] to -CURRENT and find that > su is broken. I thought this had been fixed. > > I have a virgin rev 1.17 /etc/pam.conf, I'm in group wheel, I built > world with no funky options, the su binary (built from su rev 1.39) > really is setuid root and yet I get the amazingly helpful error message: > > su: Sorry Found it. pam_wheel is a whore. It doesn't use getgid() or getegid(), but instead grovels through /etc/group manually. I'm in group wheel by virtue of the fact that my GID specified in the passwd file is 0. I don't have to be in /etc/group. Unless, of course, I want to su. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 19:13: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id 27BF437B405 for ; Wed, 25 Jul 2001 19:12:58 -0700 (PDT) (envelope-from vince@oahu.WURLDLINK.NET) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.11.3/8.11.3) with ESMTP id f6Q2CmT16288 for ; Wed, 25 Jul 2001 16:12:48 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Wed, 25 Jul 2001 16:12:47 -1000 (HST) From: Vincent Poy To: Subject: src/usr.bin/passwd in recent -current seems to hang machine and corrupts passwd database files Message-ID: <20010725161133.I50475-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG /usr/bin/passwd in the latest -current world build with kernel build seems to do the following: # passwd joeuser Changing local password for joeuser. New password: Retype new password: passwd: updating the database... passwd: done # and 5 seconds later, the machine would just freeze solid. With yesterday's buildworld, it would do the same thing except it would panic the kernel and go into the db> prompt. So the only way is to hard reboot which will goto single user mode where fsck would have to be done and then somehow the passwd database is corrupted which requires copying master.passwd.bak from /var/backups to /etc/master.passwd and then run and exit vipw with :wq to rebuild the passwd database. Otherwise, all users besides root will be able to logon and /etc/passwd and /etc/master.passwd will be a bunch of garbled characters. vipw works fine when manually entering the encrypted passwd as a cut and paste from another system. It isn't a hardware issue since I have tried everything from make -j 4 buildworld to running dnetc to even running cpuburn from the /usr/ports/misc collection which had no effect. Only when running passwd would it hang the machine solid 5 seconds later each time and corrupt the password database. The 6/18/2001 current binary snapshot from current.freebsd.org worked without any problems. Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 19:20:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-149.dsl.lsan03.pacbell.net [64.169.104.149]) by hub.freebsd.org (Postfix) with ESMTP id 7699B37B401 for ; Wed, 25 Jul 2001 19:20:46 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A5CE766E04; Wed, 25 Jul 2001 19:20:45 -0700 (PDT) Date: Wed, 25 Jul 2001 19:20:45 -0700 From: Kris Kennaway To: Sheldon Hearn Cc: current@FreeBSD.org Subject: Re: su root broken in -CURRENT Message-ID: <20010725192044.C3833@xor.obsecurity.org> References: <30911.996110138@axl.seasidesoftware.co.za> <65545.996111975@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="GZVR6ND4mMseVXL/" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <65545.996111975@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on Thu, Jul 26, 2001 at 03:46:15AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --GZVR6ND4mMseVXL/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2001 at 03:46:15AM +0200, Sheldon Hearn wrote: >=20 >=20 > On Thu, 26 Jul 2001 03:15:38 +0200, Sheldon Hearn wrote: >=20 > > I've completed a pretty clean crossgrade [1] to -CURRENT and find that > > su is broken. I thought this had been fixed. > >=20 > > I have a virgin rev 1.17 /etc/pam.conf, I'm in group wheel, I built > > world with no funky options, the su binary (built from su rev 1.39) > > really is setuid root and yet I get the amazingly helpful error message: > >=20 > > su: Sorry >=20 > Found it. pam_wheel is a whore. It doesn't use getgid() or getegid(), > but instead grovels through /etc/group manually. >=20 > I'm in group wheel by virtue of the fact that my GID specified in the > passwd file is 0. I don't have to be in /etc/group. >=20 > Unless, of course, I want to su. :-) Isn't this backwards? Code shouldn't be making assumptions about the special meaning of numeric gids. What if you wanted to renumber gid wheel to something else? Kris --GZVR6ND4mMseVXL/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7X358Wry0BWjoQKURAtO2AJ9JLkbLDaZDqyHv/0/vCSjTouWYqwCg9YR8 SUvzwrrYca0j+jCthAjV6Gk= =SYRb -----END PGP SIGNATURE----- --GZVR6ND4mMseVXL/-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 19:40:40 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp-1.enteract.com (smtp-1.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 087E137B406 for ; Wed, 25 Jul 2001 19:40:37 -0700 (PDT) (envelope-from dscheidt@tumbolia.com) Received: from shell-2.enteract.com (shell-2.enteract.com [207.229.143.41]) by smtp-1.enteract.com (Postfix) with ESMTP id 40C7A76A4 for ; Wed, 25 Jul 2001 21:40:36 -0500 (CDT) Date: Wed, 25 Jul 2001 21:40:36 -0500 (CDT) From: David Scheidt X-X-Sender: To: Subject: SMP panic at boot Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG My SMP box, running current from about 24 hours ago, panics on a cold boot, but only if I don't touch a key. If I use the keyboard to do anything, whether to skip the loader twiddler, or to skip the BIOS disk probing, or just to bang my head against it, it boots fine. It will reboot fine once it's booted. What I get on the screen: (transcribed by hand, typos mine) SMP: AP CPU #1 launched! kernel trap 12 with interrupts disabled panic: mutex sched lock recursed at /usr/src/sys/kern/kern/sync.c:807 cpuid =1; lapic.id =01000000 Debugger("panic") And then it hangs, failing to go into ddb. Everytime, as long as I don't touch the keyboard. -- dscheidt@tumbolia.com Bipedalism is only a fad. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 25 21:12:54 2001 Delivered-To: freebsd-current@freebsd.org Received: from femail39.sdc1.sfba.home.com (femail39.sdc1.sfba.home.com [24.254.60.33]) by hub.freebsd.org (Postfix) with ESMTP id B352737B407 for ; Wed, 25 Jul 2001 21:12:52 -0700 (PDT) (envelope-from mdharnois@home.com) Received: from c1030098-a.wtrlo1.ia.home.com ([24.6.200.230]) by femail39.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010726041252.WUA547.femail39.sdc1.sfba.home.com@c1030098-a.wtrlo1.ia.home.com> for ; Wed, 25 Jul 2001 21:12:52 -0700 Received: by c1030098-a.wtrlo1.ia.home.com (Postfix, from userid 1001) id 3075214A02; Wed, 25 Jul 2001 23:14:16 -0500 (CDT) To: freebsd-current@freebsd.org Subject: filesystem errors From: Michael Harnois Date: Wed, 25 Jul 2001 23:14:16 -0500 Message-ID: <8666cgfht3.fsf@mharnois.workgroup.net> Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm tearing my hair out trying to find a filesystem error that's causing me a panic: ufsdirhash_checkblock: bad dir inode. When I run fsck from a single user boot, it finds no errors. When I run it on the same filesystem mounted, it finds errors: but, of course, it then can't correct them -- Michael D. Harnois bilocational bivocational Washburn, Iowa Minneapolis, Minnesota Never, "for the sake of peace and quiet," deny your own experience or convictions. -- Dag Hammarskjold To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 0:19:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (Postfix) with ESMTP id DF28737B405 for ; Thu, 26 Jul 2001 00:19:35 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from nantai.utsunomiya-u.ac.jp by nasu.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/26Jan01-1134AM) id f6Q7JWc360215; Thu, 26 Jul 2001 16:19:32 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp by nantai.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/30Jan01-0241PM) id f6Q7JWl232960; Thu, 26 Jul 2001 16:19:32 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:pSQZYhD0zT1sjwPJVV0gm368l9qs8m3D@zodiac.mech.utsunomiya-u.ac.jp [160.12.43.7]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id QAA25125; Thu, 26 Jul 2001 16:29:08 +0900 (JST) Message-Id: <200107260729.QAA25125@zodiac.mech.utsunomiya-u.ac.jp> To: tlambert2@mindspring.com Cc: freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Death sentence to KLD screen savers? Comments? In-reply-to: Your message of "Wed, 25 Jul 2001 01:05:07 MST." <3B5E7DB3.97656D3C@mindspring.com> References: <200107241207.VAA14339@zodiac.mech.utsunomiya-u.ac.jp> <3B5E7DB3.97656D3C@mindspring.com> Date: Thu, 26 Jul 2001 16:29:07 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >> I propose to have user-land screen savers instead of KLD >> screen savers. > >[ ... "performance degradation" ... ] > >[ ... "file access" ... ] > >I don't see either of these as being compelling arguments >in favor of a user space implementation; I guess this means >you want to do file access in your screen saver(s). Both points/complaints/requests have been raised several times in our mailing lists in the past. (Sorry, I don't keep copies.) Some people don't like cputime eaten up by the screen saver in the kernel... Some peopel want to write "interesting" screen savers... >Now if you could run Windows screen saver modules, you >might have a good argument for change, above and beyond >"change for the sake of change". Personally I am not interested in fancy screen savers :-) But, just want to keep things tidy and keep the system running smoothly. By moving much of the screen saver support from the console driver to the user-land... Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 0:29:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from nasu.utsunomiya-u.ac.jp (nasu.utsunomiya-u.ac.jp [160.12.128.3]) by hub.freebsd.org (Postfix) with ESMTP id 8F56537B405; Thu, 26 Jul 2001 00:29:54 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from nantai.utsunomiya-u.ac.jp by nasu.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/26Jan01-1134AM) id f6Q7Trc360404; Thu, 26 Jul 2001 16:29:53 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp by nantai.utsunomiya-u.ac.jp (8.11.2/1.1.29.3/30Jan01-0241PM) id f6Q7Trl233445; Thu, 26 Jul 2001 16:29:53 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:RUHvQOxYNA2wQ844k+FuoYlBq0NE4FTf@zodiac.mech.utsunomiya-u.ac.jp [160.12.43.7]) by zodiac.mech.utsunomiya-u.ac.jp (8.9.3+3.2W/3.7W/zodiac-May2000) with ESMTP id QAA25220; Thu, 26 Jul 2001 16:39:29 +0900 (JST) Message-Id: <200107260739.QAA25220@zodiac.mech.utsunomiya-u.ac.jp> To: John Baldwin Cc: Kazutaka YOKOTA , freebsd-current@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Death sentence to KLD screen savers? Comments? In-reply-to: Your message of "Wed, 25 Jul 2001 13:18:35 MST." References: Date: Thu, 26 Jul 2001 16:39:29 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >You can stick the screen saver in a low priority kthread and achieve the same >effect. As the screen saver accesses and uses syscons' internal structures and facilities, its operation must be carefully coordinated with syscons. Thus, putting the screen saver in a kthread will require major restructuring in various parts of syscons. It is much easier, at least to me, to just remove much of the KLD screen saver support from syscons to the user-land, than to utilize the kthread :-) >You can use kldload or the loader with the -t 'foo' stuff to load configuratio >n >files, etc. that modules can get at. Um, I know the loader can load arbitrary files in the kernel space with its '-t' option (the splash screen actually uses it to load a bitmap). But, can kldload do similar thing? It donesn't look it can... Kazu >Just pointing out that userland is not the only way of achieving your goals. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 2:13:18 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 0940137B407 for ; Thu, 26 Jul 2001 02:13:14 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15PhDY-000Ixa-00; Thu, 26 Jul 2001 11:14:04 +0200 From: Sheldon Hearn To: Kris Kennaway Cc: current@FreeBSD.org Subject: Re: su root broken in -CURRENT In-reply-to: Your message of "Wed, 25 Jul 2001 19:20:45 MST." <20010725192044.C3833@xor.obsecurity.org> Date: Thu, 26 Jul 2001 11:14:04 +0200 Message-ID: <72885.996138844@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 25 Jul 2001 19:20:45 MST, Kris Kennaway wrote: > Isn't this backwards? Code shouldn't be making assumptions about the > special meaning of numeric gids. What if you wanted to renumber gid > wheel to something else? So? My primary group is 0. In /etc/group, group wheel's numeric value is 0. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 2:22:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from vega.vega.com (dialup2-22.iptelecom.net.ua [212.9.226.86]) by hub.freebsd.org (Postfix) with ESMTP id E36FD37B406; Thu, 26 Jul 2001 02:22:45 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Received: from FreeBSD.org (big_brother.vega.com [192.168.1.1]) by vega.vega.com (8.11.4/8.11.3) with ESMTP id f6PBBbD75699; Wed, 25 Jul 2001 14:11:37 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <3B5EA985.458B39B7@FreeBSD.org> Date: Wed, 25 Jul 2001 14:12:06 +0300 From: Maxim Sobolev Organization: Vega International Capital X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,uk,ru MIME-Version: 1.0 To: current@FreeBSD.org Cc: Julian Elischer , stable@FreeBSD.org Subject: Strange select(2) misbehaviour when linked with -pthread Content-Type: multipart/mixed; boundary="------------45E7A6BD8D2F3ADC6B9063B1" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------45E7A6BD8D2F3ADC6B9063B1 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi, I found that the attached small program behaves very strangely when linked with -pthread - it chews 100% CPU cycles while waiting in select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE systems. *weird* -Maxim P.S. And yes, I know that I ought to use NULL instead of &tv when I want to wait indefinitely in select(2), but it is how some programs work. --------------45E7A6BD8D2F3ADC6B9063B1 Content-Type: text/plain; charset=koi8-r; name="selectbug.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="selectbug.c" #include #include #include #include #include int main() { int retval, fd; u_int32_t timeout; struct timeval tv; fd_set mask; fd = 0; timeout = ~0; tv.tv_sec = timeout/1000; tv.tv_usec = (timeout%1000)*1000; FD_ZERO(&mask); FD_SET(fd, &mask); retval = select(1, &mask, NULL, NULL, &tv); exit(0); } --------------45E7A6BD8D2F3ADC6B9063B1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 3: 4:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (sat.dis.org [216.240.44.14]) by hub.freebsd.org (Postfix) with ESMTP id 2D31837B420 for ; Thu, 26 Jul 2001 03:04:16 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f6OLmI700923 for ; Tue, 24 Jul 2001 14:48:19 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200107242148.f6OLmI700923@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: current@freebsd.org Subject: HEADS UP: ACPI bug Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Jul 2001 14:48:18 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There is a bug in the Intel ACPI CA code which will cause your system to power off upon waking from suspend mode. Iwasaki-san tracked it down and posted a fix to the acpi-jp list (message 1186) for folks that want to patch locally. Intel have adopted the patch, and the next update will fix this problem. (I would assume sometime in the next 2-3 weeks.) Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 3:15:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (sat.dis.org [216.240.44.14]) by hub.freebsd.org (Postfix) with ESMTP id 1709837B401; Thu, 26 Jul 2001 03:15:28 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f6QAGeq00958; Thu, 26 Jul 2001 03:16:41 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200107261016.f6QAGeq00958@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Kazutaka YOKOTA Cc: John Baldwin , freebsd-current@freebsd.org Subject: Re: Death sentence to KLD screen savers? Comments? In-reply-to: Your message of "Thu, 26 Jul 2001 16:39:29 +0900." <200107260739.QAA25220@zodiac.mech.utsunomiya-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Jul 2001 03:16:40 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > It is much easier, at least to me, to just remove much of the KLD > screen saver support from syscons to the user-land, than to utilize > the kthread :-) Just FWIW, I think that moving the screen saver to userspace is an excellent thing to do. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 3:59:39 2001 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 A52E137B406; Thu, 26 Jul 2001 03:59:32 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Jul 2001 11:59:31 +0100 (BST) Date: Thu, 26 Jul 2001 11:59:31 +0100 From: David Malone To: Maxim Sobolev Cc: current@FreeBSD.org, Julian Elischer , stable@FreeBSD.org Subject: Re: Strange select(2) misbehaviour when linked with -pthread Message-ID: <20010726115931.A93134@walton.maths.tcd.ie> References: <3B5EA985.458B39B7@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5EA985.458B39B7@FreeBSD.org>; from sobomax@FreeBSD.org on Wed, Jul 25, 2001 at 02:12:06PM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, Jul 25, 2001 at 02:12:06PM +0300, Maxim Sobolev wrote: > I found that the attached small program behaves very strangely when > linked with -pthread - it chews 100% CPU cycles while waiting in > select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE > systems. *weird* The timeout is too long. At the moment there is an arbitary limit on how long you can wait 'cos the kernel incorrectly uses itimerfix on the timeout passed to select. I have patches to improve the situation and I was waiting for Bruce to review them, but I've been using them at home for ages, so maybe I should just commit them. The patches only have select return an error if the timeout is too long to be implimented using the kernel's counters. > P.S. And yes, I know that I ought to use NULL instead of &tv when I > want to wait indefinitely in select(2), but it is how some programs > work. Or don't work as the case may be ;-) Posix doesn't actually require select to be able to deal with large wait times (I think 31 days was the figure I found in the SUSv2 spec). Have a look at: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18909 for more details. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 4:56:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from vega.vega.com (dialup6-52.iptelecom.net.ua [212.9.227.116]) by hub.freebsd.org (Postfix) with ESMTP id E3E8437B405; Thu, 26 Jul 2001 04:56:42 -0700 (PDT) (envelope-from max@vega.com) Received: (from max@localhost) by vega.vega.com (8.11.4/8.11.3) id f6QBu8X79427; Thu, 26 Jul 2001 14:56:08 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) From: Maxim Sobolev Message-Id: <200107261156.f6QBu8X79427@vega.vega.com> Subject: Re: Strange select(2) misbehaviour when linked with -pthread To: dwmalone@maths.tcd.ie (David Malone) Date: Thu, 26 Jul 2001 14:56:08 +0300 (EEST) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), current@FreeBSD.ORG, julian@elischer.org (Julian Elischer), stable@FreeBSD.ORG In-Reply-To: <20010726115931.A93134@walton.maths.tcd.ie> from "David Malone" at Jul 26, 2001 11:59:31 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > On Wed, Jul 25, 2001 at 02:12:06PM +0300, Maxim Sobolev wrote: > > I found that the attached small program behaves very strangely when > > linked with -pthread - it chews 100% CPU cycles while waiting in > > select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE > > systems. *weird* > > The timeout is too long. At the moment there is an arbitary limit > on how long you can wait 'cos the kernel incorrectly uses itimerfix > on the timeout passed to select. I have patches to improve the > situation and I was waiting for Bruce to review them, but I've been > using them at home for ages, so maybe I should just commit them. > The patches only have select return an error if the timeout is too > long to be implimented using the kernel's counters. I am not sure that the error is what we want to get in this situation. Perhaps more *compatible* solution would be wait indefinitely if timeout is too large. > > P.S. And yes, I know that I ought to use NULL instead of &tv when I > > want to wait indefinitely in select(2), but it is how some programs > > work. > > Or don't work as the case may be ;-) Posix doesn't actually require > select to be able to deal with large wait times (I think 31 days was > the figure I found in the SUSv2 spec). Have a look at: > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18909 > > for more details. Interesting, but this isn't really relevant to my question. I want to know why the program in question behaves difefrently when linked with and without -pthead flag (bug in libc_r?). Also [EINVAL] is not what I'm seeing here, because as you can easily check in my test case tv.tv_sec == 4294976, which is less that 1000000000 - upper limit of our select(2) implementation depicted in PR 18909. -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 26 7:14:16 2001 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 3217037B403 for ; Thu, 26 Jul 2001 07:14:10 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Jul 2001 15:14:09 +0100 (BST) To: Michael Harnois Cc: freebsd-current@freebsd.org, mckusick@mckusick.com Subject: Re: filesystem errors In-Reply-To: Your message of "Wed, 25 Jul 2001 23:14:16 CDT." <8666cgfht3.fsf@mharnois.workgroup.net> Date: Thu, 26 Jul 2001 15:14:09 +0100 From: Ian Dowse Message-ID: <200107261514.aa46454@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <8666cgfht3.fsf@mharnois.workgroup.net>, Michael Harnois writes: >I'm tearing my hair out trying to find a filesystem error that's >causing me a panic: ufsdirhash_checkblock: bad dir inode. > >When I run fsck from a single user boot, it finds no errors. > >When I run it on the same filesystem mounted, it finds errors: but, of >course, it then can't correct them [Kirk, I'm cc'ing you because here the dirhash code sanity checks found a directory entry with d_ino == 0 that was not at the start of a DIRBLKSIZ block. This doesn't happen normally, but it seems from this report that fsck does not correct this. Is it a basic filesystem assumption that d_ino == 0 can only happen at the start of a directory block, or is it something the code should tolerate?] Interesting - this is an error reported by the UFS_DIRHASH code that you enabled in your kernel config. A sanity check that the dirhash code is performing is failing. These checks are designed to catch bugs in the dirhash code, but in this case I think it may be a bug that fsck is not finding this problem, or else my sanity tests are too strict. A workaround is to turn off the sanity checks with: sysctl vfs.ufs.dirhash_docheck=0 or to remove UFS_DIRHASH from your kernel config. You could also try to find the directory that is causing the problems. Copy the following script to a file called dircheck.pl, and try running: chmod 755 dircheck.pl find / -fstype ufs -type d -print0 | xargs ./dircheck.pl That should show up any directories that would fail that dirhash sanity check - there will probably just be one or two that resulted from some old filesystem corruption. Ian #!/usr/local/bin/perl while (defined($dir = shift)) { unless (open(DIR, "$dir")) { print STDERR "$dir: $!\n"; next; } $b = 0; my(%dir) = (); while (sysread(DIR, $dat, 512) == 512) { $off = 0; while (length($dat) > 0) { ($dir{'d_ino'}, $dir{'d_reclen'}, $dir{'d_type'}, $dir{'d_namlen'}) = unpack("LSCC", $dat); $dir{'d_name'} = substr($dat, 8, $dir{'d_namlen'}); $minreclen = (8 + $dir{'d_namlen'} + 1 + 3) & (~3); $gapinfo = ($dir{'d_reclen'} == $minreclen) ? "" : sprintf("[%d]", $dir{'d_reclen'} - $minreclen); if ($dir{'d_ino'} == 0 && $off != 0) { printf("%s off %d ino %d reclen 0x%x type 0%o" . " namelen %d name '%s' %s\n", $dir, $off, $dir{'d_ino'}, $dir{'d_reclen'}, $dir{'d_type'}, $dir{'d_namlen'}, $dir{'d_name'}, $gapinfo); } if ($dir{'d_reclen'} > length($dat)) { die "reclen too long!\n"; } $dat = substr($dat, $dir{'d_reclen'}); $off += $dir{'d_reclen'}; } $b++; } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 8: 7:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with SMTP id ED24337B406 for ; Thu, 26 Jul 2001 08:07:37 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 12944 invoked from network); 26 Jul 2001 15:07:37 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 26 Jul 2001 15:07:37 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200107242148.f6OLmI700923@mass.dis.org> Date: Thu, 26 Jul 2001 08:07:21 -0700 (PDT) From: John Baldwin To: Mike Smith Subject: RE: HEADS UP: ACPI bug Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 24-Jul-01 Mike Smith wrote: > > There is a bug in the Intel ACPI CA code which will cause your system to > power off upon waking from suspend mode. Iwasaki-san tracked it down and > posted a fix to the acpi-jp list (message 1186) for folks that want to > patch locally. > > Intel have adopted the patch, and the next update will fix this problem. > (I would assume sometime in the next 2-3 weeks.) And Peter has committed the patch to the INTEL vendor branch already... -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 8:44:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 7B3F237B403; Thu, 26 Jul 2001 08:44:51 -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.11.3/8.11.3) with ESMTP id f6QFioF65413; Thu, 26 Jul 2001 09:44:50 -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.11.3/8.11.4) with ESMTP id f6QFinw03993; Thu, 26 Jul 2001 09:44:49 -0600 (MDT) (envelope-from imp@harmony.village.org) Message-Id: <200107261544.f6QFinw03993@harmony.village.org> To: David Malone Subject: Re: Strange select(2) misbehaviour when linked with -pthread Cc: Maxim Sobolev , current@FreeBSD.ORG, Julian Elischer , stable@FreeBSD.ORG In-reply-to: Your message of "Thu, 26 Jul 2001 11:59:31 BST." <20010726115931.A93134@walton.maths.tcd.ie> References: <20010726115931.A93134@walton.maths.tcd.ie> <3B5EA985.458B39B7@FreeBSD.org> Date: Thu, 26 Jul 2001 09:44:49 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20010726115931.A93134@walton.maths.tcd.ie> David Malone writes: : Or don't work as the case may be ;-) Posix doesn't actually require : select to be able to deal with large wait times (I think 31 days was : the figure I found in the SUSv2 spec). Have a look at: 31 days, interestingly enough, is very close to the amount of time it takes for a 32 bit counter to wrap in milliseconds. Oh, wait, that's 49 days and a little bit. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 8:51: 5 2001 Delivered-To: freebsd-current@freebsd.org Received: from femail39.sdc1.sfba.home.com (femail39.sdc1.sfba.home.com [24.254.60.33]) by hub.freebsd.org (Postfix) with ESMTP id 803C037B40A for ; Thu, 26 Jul 2001 08:51:00 -0700 (PDT) (envelope-from mdharnois@home.com) Received: from c1030098-a.wtrlo1.ia.home.com ([24.6.200.230]) by femail39.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010726155059.BBAV26875.femail39.sdc1.sfba.home.com@c1030098-a.wtrlo1.ia.home.com> for ; Thu, 26 Jul 2001 08:50:59 -0700 Received: by c1030098-a.wtrlo1.ia.home.com (Postfix, from userid 1001) id 1FC0914A18; Thu, 26 Jul 2001 10:52:26 -0500 (CDT) To: Ian Dowse Cc: freebsd-current@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: filesystem errors References: <200107261514.aa46454@salmon.maths.tcd.ie> From: Michael Harnois Date: Thu, 26 Jul 2001 10:52:25 -0500 In-Reply-To: <200107261514.aa46454@salmon.maths.tcd.ie> (Ian Dowse's message of "Thu, 26 Jul 2001 15:14:09 +0100") Message-ID: <864rrzy9fq.fsf@mharnois.workgroup.net> Lines: 16 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 26 Jul 2001 15:14:09 +0100, Ian Dowse said: > That should show up any directories that would fail that dirhash > sanity check - there will probably just be one or two that > resulted from some old filesystem corruption. The only result it generated was /usr/home/mdharnois off 120 ino 0 reclen 0x188 type 010 namelen 14 name '.fetchmail.pid' [368] and that file is destroted and recreated every couple of minutes. -- Michael D. Harnois bilocational bivocational Washburn, Iowa Minneapolis, Minnesota Sed quis custodiet ipsos custodes? -- Juvenal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 9: 2: 1 2001 Delivered-To: freebsd-current@freebsd.org Received: from cokane.org (ip-216-23-49-109.adsl.one.net [216.23.49.109]) by hub.freebsd.org (Postfix) with ESMTP id E0FF537B43F for ; Thu, 26 Jul 2001 09:01:52 -0700 (PDT) (envelope-from cokane@cokane.org) Received: (from cokane@localhost) by cokane.org (8.11.4/8.11.4) id f6R44Zm10663; Fri, 27 Jul 2001 00:04:35 -0400 (EDT) (envelope-from cokane) Date: Fri, 27 Jul 2001 00:04:35 -0400 From: Coleman Kane To: Sheldon Hearn Cc: Dima Dorfman , current@FreeBSD.org Subject: Re: 3dfx module breaks without /sys symlink Message-ID: <20010727000435.A10534@evil.apt> References: <20010725104534.716E43E28@bazooka.unixfreak.org> <25151.996058317@axl.seasidesoftware.co.za> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <25151.996058317@axl.seasidesoftware.co.za>; from sheldonh@starjuice.net on Wed, Jul 25, 2001 at 12:51:57PM +0200 X-VIM-Settings: vim:ts=4:sw=4:tw=70: X-Operating-System: FreeBSD evil.apt 5.0-CURRENT FreeBSD 5.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I remember getting mails about my driver before, so it's ok. Basically, whenever bsd.kmod.mk is broken, my module (being the first in the list), is always where the error pops up. I'll take a look at it, but you shouldn't be using it on -stable. It is only guaranteed to work on -current, in fact, all my stable patches are out of date since I no longer have been running -stable (and -current is where new features belong). On Wed, Jul 25, 2001 at 12:51:57PM +0200, Sheldon Hearn wrote, and it was p= roclaimed: >=20 >=20 > On Wed, 25 Jul 2001 03:45:34 MST, Dima Dorfman wrote: >=20 > > This isn't Coleman's fault; it's a bug in bsd.kmod.mk, which was fixed > > in r1.86 (or r1.75.2.3 in RELENG_4), and it affects all modules (3dfx > > is failing because it's first on the list). Are you running a stale > > -stable (e.g., before 2001/05/18)? >=20 > I'm running -stable as of last week, so no. >=20 > Ciao, > Sheldon. >=20 --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7YOhSERViMObJ880RAtCVAJ47FhU03fVd0EwUu5X+tnW8s5O60gCfSqoR 9D0rX8etY6SUn7UCM6jlJ88= =mJLb -----END PGP SIGNATURE----- --Dxnq1zWXvFF0Q93v-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 9: 5: 3 2001 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 C9F2E37B405 for ; Thu, 26 Jul 2001 09:05:00 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 26 Jul 2001 17:05:00 +0100 (BST) To: Michael Harnois Cc: freebsd-current@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: filesystem errors In-Reply-To: Your message of "Thu, 26 Jul 2001 10:52:25 CDT." <864rrzy9fq.fsf@mharnois.workgroup.net> Date: Thu, 26 Jul 2001 17:04:59 +0100 From: Ian Dowse Message-ID: <200107261705.aa66786@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <864rrzy9fq.fsf@mharnois.workgroup.net>, Michael Harnois writes: > >The only result it generated was > >/usr/home/mdharnois off 120 ino 0 reclen 0x188 type 010 namelen 14 name '.fetc >hmail.pid' [368] > >and that file is destroted and recreated every couple of minutes. It's the directory (/usr/home/mdharnois), not the file that is the problem. If you recreate the directory: cd /usr/home mv mdharnois mdharnois.old mkdir mdharnois chown mdharnois:mdharnois mdharnois # (or whatever) mv mdharnois.old/* mdharnois/ mv mdharnois.old/.[a-zA-Z0-9]* mdharnois/ rmdir mdharnois.old this problem should go away permanently. Even just creating loads of files in the existing directory might be enough to reuse the bit of the directory that has d_ino == 0. Running ./dircheck.pl /usr/home/mdharnois will check if there is still a problem. However, I'd like to know if this is something that fsck should detect and correct automatically. It is an odd case, because the ffs filesystem code never creates directory entries like this, but I think it will not object to them if it finds them. This kind of ambiguity is probably a bad thing. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 14:33:24 2001 Delivered-To: freebsd-current@freebsd.org Received: from solar.phyco.net (c433473-g.adrian1.mi.home.com [24.182.101.49]) by hub.freebsd.org (Postfix) with ESMTP id 2EFFF37B406 for ; Thu, 26 Jul 2001 14:33:20 -0700 (PDT) (envelope-from aja@phyco.net) Received: from localhost (aja@localhost) by solar.phyco.net (8.11.3/8.11.4) with ESMTP id f6QLXoS37062 for ; Thu, 26 Jul 2001 17:33:51 -0400 (EDT) (envelope-from aja@phyco.net) Date: Thu, 26 Jul 2001 17:33:49 -0400 (EDT) From: Aaron Angel To: Subject: gif devices in -current Message-ID: <20010726173141.V37015-100000@solar.phyco.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG When I compiled/installed -current, and started setting things up again, I noticed that gif devices now expect IPv6 prefix lengths of 128. Most providers use 127, and some even use 64 as prefix lengths for tunnels. I was just curious why the change was made to only support prefix lengths of 128. Is there an RFC that covers this perhaps? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 14:37:32 2001 Delivered-To: freebsd-current@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 34D3E37B401 for ; Thu, 26 Jul 2001 14:37:28 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 2067C4B21; Fri, 27 Jul 2001 06:37:20 +0900 (JST) To: Aaron Angel Cc: freebsd-current@freebsd.org In-reply-to: aja's message of Thu, 26 Jul 2001 17:33:49 -0400. <20010726173141.V37015-100000@solar.phyco.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: gif devices in -current From: itojun@iijlab.net Date: Fri, 27 Jul 2001 06:37:20 +0900 Message-ID: <12098.996183440@itojun.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >When I compiled/installed -current, and started setting things up again, I >noticed that gif devices now expect IPv6 prefix lengths of 128. Most >providers use 127, and some even use 64 as prefix lengths for tunnels. I >was just curious why the change was made to only support prefix lengths of >128. Is there an RFC that covers this perhaps? either of the following works. the other configurations are now considered ambiguous. (the point is, if you specify prefixlen < 128 you don't need to say the peer's address) # ifconfig inet6 A prefixlen X (X can be < 128) # ifconfig inet6 A B prefixlen 128 itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 15: 0:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from solar.phyco.net (c433473-g.adrian1.mi.home.com [24.182.101.49]) by hub.freebsd.org (Postfix) with ESMTP id ADCEB37B401 for ; Thu, 26 Jul 2001 15:00:05 -0700 (PDT) (envelope-from aja@phyco.net) Received: from localhost (aja@localhost) by solar.phyco.net (8.11.3/8.11.4) with ESMTP id f6QM0Rh37339; Thu, 26 Jul 2001 18:00:29 -0400 (EDT) (envelope-from aja@phyco.net) Date: Thu, 26 Jul 2001 18:00:21 -0400 (EDT) From: Aaron Angel To: Cc: Subject: Re: gif devices in -current In-Reply-To: <12098.996183440@itojun.org> Message-ID: <20010726175934.X37289-100000@solar.phyco.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 27 Jul 2001 itojun@iijlab.net wrote: > either of the following works. the other configurations are now > considered ambiguous. (the point is, if you specify prefixlen < 128 > you don't need to say the peer's address) > > # ifconfig inet6 A prefixlen X (X can be < 128) > # ifconfig inet6 A B prefixlen 128 > ah. now, that makes common sense. *hasn't thunk too hard lately*. Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 15:26:29 2001 Delivered-To: freebsd-current@freebsd.org Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by hub.freebsd.org (Postfix) with ESMTP id 0680D37B401 for ; Thu, 26 Jul 2001 15:26:28 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.11.4/8.11.4) id f6QMQRa04926 for freebsd-current@freebsd.org; Thu, 26 Jul 2001 15:26:27 -0700 (PDT) (envelope-from sgk) Date: Thu, 26 Jul 2001 15:26:27 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: make world broken by STDIN_ changes Message-ID: <20010726152627.A4918@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ===> usr.sbin/pcvt/vttest cc -O -pipe -march=k6 -traditional -DUSEMYSTTY -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/pcvt/vttest/main.c /usr/src/usr.sbin/pcvt/vttest/main.c: In function `readnl': /usr/src/usr.sbin/pcvt/vttest/main.c:1942: `STDIN_FILENO' undeclared (first use in this function) /usr/src/usr.sbin/pcvt/vttest/main.c:1942: (Each undeclared identifier is reported only once /usr/src/usr.sbin/pcvt/vttest/main.c:1942: for each function it appears in.) *** Error code 1 -- Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 17: 2:16 2001 Delivered-To: freebsd-current@freebsd.org Received: from reason.levels.unisa.edu.au (reason.levels.unisa.edu.au [130.220.33.11]) by hub.freebsd.org (Postfix) with ESMTP id 14C8037B422 for ; Thu, 26 Jul 2001 17:01:51 -0700 (PDT) (envelope-from cisbjc@reason.levels.unisa.edu.au) Received: from localhost (cisbjc@localhost) by reason.levels.unisa.edu.au (8.9.3/8.9.3) with ESMTP id JAA17415 for ; Fri, 27 Jul 2001 09:31:49 +0930 (CST) Date: Fri, 27 Jul 2001 09:31:49 +0930 (CST) From: Benjamin Close To: freebsd-current@freebsd.org Subject: Recursing on a non-recursive lock Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-981467433-996192039=:24942" Content-ID: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-981467433-996192039=:24942 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi All, For a while now (July 12 first noticed) I've been experiencing a intermittent panic on a non-recursive lock. Whilst I can grab the panic, savecore panics again writing it. It seems to occur only under heavy disk io and hence a make install of XFree86 causes the condition (not always at the same place). Details below: This always occurs sometime before the panic: lock order reversal 1st 0xc907c1fc process lock @ ../../../vm/vm_glue.c:469 2nd 0xc0b4cfb0 lockmgr interlock @ ../../../kern/kern_lock.c:239 Then sometime later (beware, hand transcribed)... recursed on non-recursive lock (sleep mutex) process lock @ ../../../kern_lock:262 first acquired @ ../../../kern/kern_exit.c:327 panic: recurse Debugger("panic") Stopped at Debugger+0x45: pushl %ebx db>trace Debugger(c040a27b) at Debugger+0x45 panic(c040cf28,0,c04ad7fc,c907bca0,0) at panic 0x70 witness_lock(c907bdbc,8,c04087b4,106) at witness_lock+0x356 lockmgr(c04ad7fc,1,0,c907bca0,c90ced88) at lockmgr+0x200 vm_map_lock_read(c04ad7cc,1,c907bca0,c04ad7cc,c027f001) at vm_map_lock_read+01a vm_map_lookup(c90cee04,c9122000,1,c90cee08,c90cedfc) at vm_map_lookup+0x5f vm_fault1(c04ad7cc,c9122000,1,0,0) at vm_fault1+0x90 vm_fault(c04ad7cc,c9122000,1,0,0) at vm_fault+0x96 trap_pfault(c90ceee0,0,c91222ac) at trap_pfault+0x2d1 trap(c0400018,10,c9070010,c907bca0,c90cdd18) at trap+0x774 calltrap() at tcalltrap+0x5 --- trap 0xc, eip = 0xc024aac2, esp = 0xc90cef20, ebp=0xc90cef40 exit1(c907bca0,0,c90cefa0,c03b35a9,c907bca0) at exit1+0x1006 sys_exit(c907bca0,c90cef80,ffffffff,0,80bc608) at sys_exit+0x15 syscall(80b002f,812002f,bfbf002f,80bc608,0) at syscall+0x695 syscall_with_err_pushed() at syscall_with_err_pushed+01b --- syscall ( 1, FreeBSD Elf, sys_exit), eip=0x8093f54, esp=0xbfbfd0e0, ebp=0xbfbfd10c db>show locks exclusive( sleep mutex ) lockmgr ( 0xc0480700 ) locked @ ../../../kern/kern_lock.c:239 exclusive( sleep mutex ) process lock ( 0xc907bdbc ) locked @ ../../../kern/kern_exit.c:327 exclusive ( sx ) proctree (0xc04be5e0) locked @ ../../../kernl/kern_exit.c:282 exclusive (sleep mutex) Giant ( 0xc04c4400) locked @ ../../../vm/vm_fault.c:195 Other useful stuff (tired of transcribing): Fatal trap 12: page fault while in kernel mode fault code = supervisor read, page not present current process = 5756 (ld) If this is not enough to help diagnose the problem, what else can I provide (sadly I can't give symbols as this fault occured compiling the kernel :( The machine is a Dell Inspiron 8000 laptop (dmesg attached) and the problem is getting more frequent with newer kernels. Cheers, Benjamin --0-981467433-996192039=:24942 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=output Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME=output Q29weXJpZ2h0IChjKSAxOTkyLTIwMDEgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIDUuMC1DVVJSRU5UICMwOiBUaHUgSnVsIDI2IDE2 OjM5OjM3IENTVCAyMDAxDQogICAgcm9vdEBkcmFjbzovdXNyL3NyYy9zeXMv aTM4Ni9jb21waWxlL05FV0NBUkQNClRpbWVjb3VudGVyICJpODI1NCIgIGZy ZXF1ZW5jeSAxMTkzMTgyIEh6DQpDUFU6IFBlbnRpdW0gSUlJL1BlbnRpdW0g SUlJIFhlb24vQ2VsZXJvbiAoNjk4LjQ4LU1IeiA2ODYtY2xhc3MgQ1BVKQ0K ICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDY4NiAgU3RlcHBp bmcgPSA2DQogIEZlYXR1cmVzPTB4MzgzZjlmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQs UFNFMzYsTU1YLEZYU1IsU1NFPg0KcmVhbCBtZW1vcnkgID0gMTM0MTI3NjE2 ICgxMzA5ODRLIGJ5dGVzKQ0KYXZhaWwgbWVtb3J5ID0gMTI0NDkzODI0ICgx MjE1NzZLIGJ5dGVzKQ0KUHJlbG9hZGVkIGVsZiBrZXJuZWwgImtlcm5lbCIg YXQgMHhjMDVjNTAwMC4NClByZWxvYWRlZCBzcGxhc2hfaW1hZ2VfZGF0YSAi L2Jvb3Qvc3BsYXNoLmJtcCIgYXQgMHhjMDVjNTA5Yy4NClByZWxvYWRlZCBl bGYgbW9kdWxlICJzbmRfbWFlc3RybzMua28iIGF0IDB4YzA1YzUwZWMuDQpQ cmVsb2FkZWQgZWxmIG1vZHVsZSAic25kX3BjbS5rbyIgYXQgMHhjMDVjNTE5 MC4NClBlbnRpdW0gUHJvIE1UUlIgc3VwcG9ydCBlbmFibGVkDQpXQVJOSU5H OiBEcml2ZXIgbWlzdGFrZTogZGVzdHJveV9kZXYgb24gMTU0LzANClVzaW5n ICRQSVIgdGFibGUsIDEwIGVudHJpZXMgYXQgMHhjMDBmYmMyMA0KYWNwaTA6 IDxERUxMICAgQ1BpIFIgID4gb24gbW90aGVyYm9hcmQNClRpbWVjb3VudGVy ICJBQ1BJIiAgZnJlcXVlbmN5IDM1Nzk1NDUgSHoNCmFjcGlfdGltZXIwOiA8 MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4ODA4LTB4ODBi IG9uIGFjcGkwDQphY3BpX2NwdTA6IDxDUFU+IG9uIGFjcGkwDQphY3BpX2Nw dTogQ0xLX1ZBTCBmaWVsZCBvdmVyZmxvd3MgUF9DTlQgcmVnaXN0ZXINCmFj cGlfY3B1OiBDTEtfVkFMIGZpZWxkIG92ZXJsYXBzIFRIVF9FTiBiaXQNCmFj cGlfdHowOiA8dGhlcm1hbCB6b25lPiBvbiBhY3BpMA0KYWNwaV9hY2FkMDog PEFDIGFkYXB0ZXI+IG9uIGFjcGkwDQphY3BpX2NtYmF0MDogPENvbnRyb2wg bWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwDQphY3BpX2NtYmF0MTogPENvbnRy b2wgbWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwDQphY3BpX2xpZDA6IDxDb250 cm9sIE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMA0KYWNwaV9idXR0b24w OiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMA0KYWNwaV9idXR0b24xOiA8U2xl ZXAgQnV0dG9uPiBvbiBhY3BpMA0KYWNwaV9wY2liMDogPEhvc3QtUENJIGJy aWRnZT4gb24gYWNwaTANCnBjaTA6IDxQQ0kgYnVzPiBvbiBhY3BpX3BjaWIw DQpwY2liMTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBj aTANCnBjaTE6IDxQQ0kgYnVzPiBvbiBwY2liMQ0KcGNpMTogPGRpc3BsYXks IFZHQT4gYXQgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2liMjogPFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwDQpwY2kyOiA8 UENJIGJ1cz4gb24gcGNpYjINCnBjbTA6IDxFU1MgVGVjaG5vbG9neSBNYWVz dHJvMz4gcG9ydCAweGRjMDAtMHhkY2ZmIG1lbSAweGY2ZmZlMDAwLTB4ZjZm ZmZmZmYgaXJxIDUgYXQgZGV2aWNlIDMuMCBvbiBwY2kyDQpwY2liMzogPFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNi4wIG9uIHBjaTINCnBjaTM6IDxQ Q0kgYnVzPiBvbiBwY2liMw0KZnhwMDogPEludGVsIFBybyAxMC8xMDBCLzEw MCsgRXRoZXJuZXQ+IHBvcnQgMHhlY2MwLTB4ZWNmZiBtZW0gMHhmOGUwMDAw MC0weGY4ZWZmZmZmLDB4ZjhmZmYwMDAtMHhmOGZmZmZmZiBpcnEgMTEgYXQg ZGV2aWNlIDQuMCBvbiBwY2kzDQpmeHAwOiBFdGhlcm5ldCBhZGRyZXNzIDAw OjIwOmUwOjY0OjUzOmU3DQppbnBoeTA6IDxpODI1NTUgMTAvMTAwIG1lZGlh IGludGVyZmFjZT4gb24gbWlpYnVzMA0KaW5waHkwOiAgMTBiYXNlVCwgMTBi YXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgYXV0bw0KcGNp MzogPHNpbXBsZSBjb21tcz4gYXQgOC4wIChubyBkcml2ZXIgYXR0YWNoZWQp DQpwY2NiYjA6IDxUSTQ0NTEgUENJLUNhcmRCdXMgQnJpZGdlPiBpcnEgMTEg YXQgZGV2aWNlIDE1LjAgb24gcGNpMg0KcGNpYjI6IGRldmljZSBwY2NiYjAg cmVxdWVzdGVkIHVuc3VwcG9ydGVkIG1lbW9yeSByYW5nZSAweDQ0MDAwMDAw LTB4ZWZmZmZmZmYgKGRlY29kaW5nIDB4ZjIwMDAwMDAtMHhmYmZmZmZmZiwg MHhmZmYwMDAwMC0weGZmZmZmKQ0KcGNjYmIwOiBDb3VsZCBub3QgZ3JhYiBy ZWdpc3RlciBtZW1vcnkNCmRldmljZV9wcm9iZV9hbmRfYXR0YWNoOiBwY2Ni YjAgYXR0YWNoIHJldHVybmVkIDEyDQpwY2NiYjA6IDxUSTQ0NTEgUENJLUNh cmRCdXMgQnJpZGdlPiBpcnEgMTEgYXQgZGV2aWNlIDE1LjEgb24gcGNpMg0K cGNpYjI6IGRldmljZSBwY2NiYjAgcmVxdWVzdGVkIHVuc3VwcG9ydGVkIG1l bW9yeSByYW5nZSAweDQ0MDAwMDAwLTB4ZWZmZmZmZmYgKGRlY29kaW5nIDB4 ZjIwMDAwMDAtMHhmYmZmZmZmZiwgMHhmZmYwMDAwMC0weGZmZmZmKQ0KcGNj YmIwOiBDb3VsZCBub3QgZ3JhYiByZWdpc3RlciBtZW1vcnkNCmRldmljZV9w cm9iZV9hbmRfYXR0YWNoOiBwY2NiYjAgYXR0YWNoIHJldHVybmVkIDEyDQpw Y2kyOiA8c2VyaWFsIGJ1cywgRmlyZVdpcmU+IGF0IDE1LjIgKG5vIGRyaXZl ciBhdHRhY2hlZCkNCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmlj ZSAzMS4wIG9uIHBjaTANCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMA0KYXRh cGNpMDogPEludGVsIElDSDIgQVRBMTAwIGNvbnRyb2xsZXI+IHBvcnQgMHhi ZmEwLTB4YmZhZiBhdCBkZXZpY2UgMzEuMSBvbiBwY2kwDQphdGEwOiBhdCAw eDFmMCBpcnEgMTQgb24gYXRhcGNpMA0KYXRhMTogYXQgMHgxNzAgaXJxIDE1 IG9uIGF0YXBjaTANCnVoY2kwOiA8SW50ZWwgODI4MDFCQS9CQU0gKElDSDIp IFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4YmNlMC0weGJjZmYgaXJx IDExIGF0IGRldmljZSAzMS4yIG9uIHBjaTANCnVzYjA6IDxJbnRlbCA4Mjgw MUJBL0JBTSAoSUNIMikgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2kw DQp1c2IwOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMDogSW50ZWwgVUhDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDENCnVo dWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0K dWtiZDA6IE5PVkFURUsgVVNCIEtleXBhZCwgcmV2IDEuMDAvMS4wMCwgYWRk ciAyLCBpY2xhc3MgMy8xDQprYmQxIGF0IHVrYmQwDQp1aGlkMDogTk9WQVRF SyBVU0IgS2V5cGFkLCByZXYgMS4wMC8xLjAwLCBhZGRyIDIsIGljbGFzcyAz LzENCnVtczA6IE1pY3Jvc29mdCBNaWNyb3NvZnQgSW50ZWxsaU1vdXNlIFxN LS4gd2l0aCBJbnRlbGxpRXllLCByZXYgMS4xMC8xLjAwLCBhZGRyIDMsIGlj bGFzcyAzLzENCnVtczA6IDMgYnV0dG9ucyBhbmQgWiBkaXIuDQphcG0wOiA8 QVBNIEJJT1M+IG9uIG1vdGhlcmJvYXJkDQphcG0wOiBmb3VuZCBBUE0gQklP UyB2MS4yLCBjb25uZWN0ZWQgYXQgdjEuMg0KbnB4MDogPG1hdGggcHJvY2Vz c29yPiBvbiBtb3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGludGVyZmFjZQ0K dG9vIG1hbnkgZGVwZW5kYW50IGNvbmZpZ3MNCnRvbyBtYW55IGRlcGVuZGFu dCBjb25maWdzDQp0b28gbWFueSBkZXBlbmRhbnQgY29uZmlncw0KdG9vIG1h bnkgZGVwZW5kYW50IGNvbmZpZ3MNCm9ybTA6IDxPcHRpb24gUk9NPiBhdCBp b21lbSAweGMwMDAwLTB4Y2ZmZmYgb24gaXNhMA0KYXRrYmRjMDogPEtleWJv YXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24g aXNhMA0KYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGZsYWdzIDB4MSBpcnEgMSBv biBhdGtiZGMwDQprYmQwIGF0IGF0a2JkMA0KcHNtMDogPFBTLzIgTW91c2U+ IGlycSAxMiBvbiBhdGtiZGMwDQpwc20wOiBtb2RlbCBHZW5lcmljIFBTLzIg bW91c2UsIGRldmljZSBJRCAwDQpmZGMwOiA8TkVDIDcyMDY1QiBvciBjbG9u ZT4gYXQgcG9ydCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBp c2EwDQpmZGMwOiBGSUZPIGVuYWJsZWQsIDggYnl0ZXMgdGhyZXNob2xkDQpm ZDA6IDwxNDQwLUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMA0KcG10 aW1lcjAgb24gaXNhMA0KcHBjMDogPFBhcmFsbGVsIHBvcnQ+IGF0IHBvcnQg MHgzNzgtMHgzN2YgaXJxIDcgb24gaXNhMA0KcHBjMDogU01DLWxpa2UgY2hp cHNldCAoRUNQL0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUN CnBwYzA6IEZJRk8gd2l0aCAxNi8xNi84IGJ5dGVzIHRocmVzaG9sZA0KcGxp cDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBwcGJ1czANCmxwdDA6 IDxQcmludGVyPiBvbiBwcGJ1czANCmxwdDA6IEludGVycnVwdC1kcml2ZW4g cG9ydA0KcHBpMDogPFBhcmFsbGVsIEkvTz4gb24gcHBidXMwDQpzYzA6IDxT eXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0Kc2MwOiBW R0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0Kc2lvMCBh dCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gaXNhMA0K c2lvMDogdHlwZSAxNjU1MEENCnNpbzEgYXQgcG9ydCAweDJmOC0weDJmZiBp cnEgMyBvbiBpc2EwDQpzaW8xOiB0eXBlIDE2NTUwQQ0Kc24wOiBpb2FkZHIg aXMgMHgzMDANCnNuMDogdGVzdDEgZmFpbGVkDQp2Z2EwOiA8R2VuZXJpYyBJ U0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhi ZmZmZiBvbiBpc2EwDQp1bmtub3duOiA8UE5QMEYxMz4gY2FuJ3QgYXNzaWdu IHJlc291cmNlcw0KdW5rbm93bjogPFBOUDAzMDM+IGNhbid0IGFzc2lnbiBy ZXNvdXJjZXMNCnVua25vd246IDxQTlAwMjAwPiBjYW4ndCBhc3NpZ24gcmVz b3VyY2VzDQp1bmtub3duOiA8UE5QMDcwMD4gY2FuJ3QgYXNzaWduIHJlc291 cmNlcw0KdW5rbm93bjogPFBOUDA1MDE+IGNhbid0IGFzc2lnbiByZXNvdXJj ZXMNCnVua25vd246IDxTTUNGMDEwPiBjYW4ndCBhc3NpZ24gcmVzb3VyY2Vz DQphZDA6IERNQSBsaW1pdGVkIHRvIFVETUEzMywgbm9uLUFUQTY2IGNvbXBs aWFudCBjYWJsZQ0KYWQwOiA5NTkwTUIgPEhJVEFDSElfREsyM0JBLTEwPiBb MTk0ODUvMTYvNjNdIGF0IGF0YTAtbWFzdGVyIFVETUEzMw0KTW91bnRpbmcg cm9vdCBmcm9tIHVmczovZGV2L2FkMHMyYQ0KV0FSTklORzogLyB3YXMgbm90 IHByb3Blcmx5IGRpc21vdW50ZWQNCi91c3I6IG1vdW50IHBlbmRpbmcgZXJy b3I6IGJsb2NrcyA0MTM5MiBmaWxlcyAzNQ0KbGlucHJvY2ZzIHJlZ2lzdGVy ZWQNCklQIHBhY2tldCBmaWx0ZXJpbmcgaW5pdGlhbGl6ZWQsIGRpdmVydCBk aXNhYmxlZCwgcnVsZS1iYXNlZCBmb3J3YXJkaW5nIGRpc2FibGVkLCBkZWZh dWx0IHRvIGRlbnksIGxvZ2dpbmcgZGlzYWJsZWQNCi9kZXYvdm1tb246IE1v ZHVsZSB2bW1vbjogcmVnaXN0ZXJlZCB3aXRoIG1ham9yPTIwMCBtaW5vcj0w IHRhZz0kTmFtZTogYnVpbGQtNTcwICQNCi9kZXYvdm1tb246IE1vZHVsZSB2 bW1vbjogaW5pdGlhbGl6ZWQNCmZ4cDA6IHByb21pc2N1b3VzIG1vZGUgZW5h YmxlZA0Kdm1uZXQxOiBwcm9taXNjdW91cyBtb2RlIGVuYWJsZWQNCg== --0-981467433-996192039=:24942-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 26 18: 7:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by hub.freebsd.org (Postfix) with ESMTP id 5B1B237B403 for ; Thu, 26 Jul 2001 18:07:26 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 7532B1E164 for ; Thu, 26 Jul 2001 21:07:25 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id VAA00545 for ; Thu, 26 Jul 2001 21:07:25 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id SAA16462; Thu, 26 Jul 2001 18:07:24 -0700 (PDT) Message-Id: <200107270107.SAA16462@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: current@freebsd.org Subject: Lock order reversals that aren't problematic Date: Thu, 26 Jul 2001 18:07:24 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm curious what the long-term plan is for witness(4). For example, it complains about BPF and device locks being reversed when BPF takes the device out of promiscuous mode -- lock order reversal 1st 0xc04c1560 bpf global lock @ /usr/src/sys/net/bpf.c:365 2nd 0xc1302b88 dc1 @ /usr/src/sys/pci/if_dc.c:3251 This is because when traffic is being handed to bpf from the device, the device is locked so witness first sees dc1's lock and then bpf's. The lock reversal occurs when the socket is closed; bpfclose() calls bpf_detachd() which calls ifpromisc() which calls into the device, which obtains its lock, but bpf is already locked.. It's hard to add this case to the blessed_list, since it can be any ethernet driver paired with bpf. Basically, I'm curious if this is a problem that needs to be solved (i.e. the eventual goal is for witness to never print any notices) or if this is expected behavior (i.e. witness is expected to say things and it's up to the developer to determine if a given thing that witness says is a problem). Thanks, Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 27 2:32:17 2001 Delivered-To: freebsd-current@freebsd.org Received: from ms4.kntech.com.tw (ms4.kntech.com.tw [210.200.114.14]) by hub.freebsd.org (Postfix) with ESMTP id 7FD1237B405 for ; Fri, 27 Jul 2001 02:32:12 -0700 (PDT) (envelope-from jingdian@ms4.kntech.com.tw) Received: from y3e1n1 (121-93.kntech.com.tw [210.201.121.93]) by ms4.kntech.com.tw (8.9.3/8.9.3) with ESMTP id RAA01849 for ; Fri, 27 Jul 2001 17:34:23 +0800 Message-Id: <200107270934.RAA01849@ms4.kntech.com.tw> From: jingdian@ms4.kntech.com.tw Subject: =?Big5?B?plinQLSjrtc=?= To: current@freebsd.org Content-Type: text/plain ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; Date: Fri, 27 Jul 2001 17:38:56 +0800 X-Priority: 1 X-Library: Indy 8.009B Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ģĖŦKĐyŠšđwšâ ģĖšë―oŠš§@Ŧ~ ·úÂIŽ°ązķqĻ­­q§@ ĄiŠA°ČķĩĨØĄj ĄīĪjŦŽ Event ŽĄ°Ę ąB§ŽĄ°ĘĨøđšģ]­p Ī―ŊqĐĘŽĄ°Ę ŪiĨÜŽĄ°Ę ĪjŦŽģyķÕŽĄ°Ę ĄīĶæūPŽĄ°Ę Īu°ÓSPŦPūPŽĄ°Ę ąMŪŨŽĄ°Ę ŪiĨÜ·|...... Ąī°OŠĖ·| īCÅéđwšâ°õĶæ...... ĄīŪÕķ鎥°Ę št°Û·| ŧR·| ĄīCIS ģWđšģ]­p ēĢŦ~Ĩ]ļËģ]­p ŦÅķĮģæŧs§@ ĄiĨ­­ąĪ@ŊëĶŽķOĄj ģ]­pķOĨÎĄG ŠĐ­ąģ]­p ĻC­ķ600ĪļĄ]ŪŅÄyĪš­ķĄ^ DMĄBŪüģøģ]­p A4ģæ­ą1000Īļ §đ―ZķOĨÎĄG A4 1­ķ 450Īļ A4 16­ķĨHĪW ĻC­ķ350Īļ A4 100­ķĨHĪW ĻC­ķ300Īļ P.S.Ĩh­IđÏĨt­p ĻCđÏ30Īļ ĻäĨLŠš°tĶXķĩĨØēÓļ`ĶAÄģ ·úÂIŠšąMŠøĶbĐóĐÓŋėŽĄ°ĘĨøđšĄBĪå―Z―sžķĄBģ]­p―sąÆĄBąÄģXÄážvĩĨĄAŠÃŦųĩÛīĢĻŅģĖđęīfŠšŧųŪæĪÎģĖšë―oŠš§@Ŧ~ŠšēzĐĀĄAĶbŪÉŪÄŧPŊĀ―č ĪW§@ģĖĻΰtĶXĄC§Ú­ĖĪņŦČĪá§ó­Ŧĩø§@Ŧ~ŠšĩøÄąŪÄŠGŧPĪåĶrķĮđFĄA§ÆąæŧPķQĪ―Ĩq§@ŠøīÁĐĘ°tĶXĄA°öūiĨXĪu§@ĀqŦīĄA§óĨ[đFĻėķĮīCŪÄŠGĄC đïĐóĨØŦeĨþ­ąĐĘŠšīšŪðŠŽŠpĄAģ\ĶhŠšĨøđšđwšâŦKŠšŽÛ·íĶģ­­ĄA·úÂI°ĩĻėĨÎģĖĶXēzŠšđwšâ§@ģĖĪj­­ŦŨŠšĩoī§ĄAąNļgķOĩoī§·Ĩ­PĄBŽ°ązŠš đwšâ§âÃöĄAīNŽO§Ú­ĖĶĻīN·PŠšĻÓ·―ĄC ·úÂIŽ°ązŠšđwšâ§âÃöĄI §ÆąæķQĪ―ĨqŊāĶĻŽ°§Ú­ĖŠšĶX§@ĨëĶņĄAÅý§Ú­ĖŽ°ķQĪ―Ĩq―čķqĻ­­q§@ģĖĶXūAŠšĨøđšĶÓ§óģÐĻÎÁZĄI Ķí§}ĄGĨxĪĪĨŦĪåĪßļôĨ|Žq182ļđ15žÓĪ§7 đqļÜĄG04-22912347 Ĩøđš°õĶæ ŠôąŌŧĻ 0922789018 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 27 3: 4:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from freevibrator.com (unknown [209.10.247.22]) by hub.freebsd.org (Postfix) with ESMTP id 9203937B403 for ; Fri, 27 Jul 2001 03:04:42 -0700 (PDT) (envelope-from julie2762@freevibrator.com) Received: from mail pickup service by freevibrator.com with Microsoft SMTPSVC; Fri, 27 Jul 2001 06:03:40 -0400 From: julie2762@freevibrator.com To: current@freebsd.org Subject: e-mail confirmation #14852762 Message-ID: X-OriginalArrivalTime: 27 Jul 2001 10:03:40.0544 (UTC) FILETIME=[69406800:01C11683] Date: 27 Jul 2001 06:03:40 -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a confirmation e-mail for your request. You can come anytime and claim your FREE Sex Toys at http://www.freevibrator.com All Free Sex Toys we feature are absolutly free with no purchase necessary whatsoever. (Small reasonable shipping charges apply) Thank You for subscribing to FreeSexToys updates list. This Is OPT-IN list. To make sure that we won't send anything to you in ERROR - You HAVE TO CONFIRM that you would like to be added to our list. To confirm that you want to be added send e-mail to: add@freevibrator.com If you received this e-mail in error (my apologies) or do not wish to be added to our list DO NOTHING. You will NOT be added to our list without Your Confirmation. Freely Yours Julie Aston Julie@freevibrator.com message confirmation ID#0192148527621905011549937 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 27 3:18:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id ADA2C37B403 for ; Fri, 27 Jul 2001 03:18:31 -0700 (PDT) (envelope-from sheldonh@starjuice.net) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.31 #1) id 15Q4iF-000Mvp-00; Fri, 27 Jul 2001 12:19:19 +0200 From: Sheldon Hearn To: Steve Kargl Cc: freebsd-current@freebsd.org Subject: Re: make world broken by STDIN_ changes In-reply-to: Your message of "Thu, 26 Jul 2001 15:26:27 MST." <20010726152627.A4918@troutmask.apl.washington.edu> Date: Fri, 27 Jul 2001 12:19:18 +0200 Message-ID: <88152.996229158@axl.seasidesoftware.co.za> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 26 Jul 2001 15:26:27 MST, Steve Kargl wrote: > ===> usr.sbin/pcvt/vttest > cc -O -pipe -march=k6 -traditional -DUSEMYSTTY -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/pcvt/vttest/main.c > /usr/src/usr.sbin/pcvt/vttest/main.c: In function `readnl': > /usr/src/usr.sbin/pcvt/vttest/main.c:1942: `STDIN_FILENO' undeclared (first use in this function) Yup. I forgot to commit my changes to header.h and Makefile. Sorry for the interruption, folks. I do appreciate how much time mistakes like this end up costing other people. 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 27 5:26: 6 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail25.bigmailbox.com (mail25.bigmailbox.com [209.132.220.211]) by hub.freebsd.org (Postfix) with ESMTP id 6D1DF37B405; Fri, 27 Jul 2001 05:25:53 -0700 (PDT) (envelope-from neckpain@nettaxi.com) Received: œby mail25.bigmailbox.com (8.8.7/8.8.7) id FAA09468; Fri, 27 Jul 2001 05:25:53 -0700 Date: Fri, 27 Jul 2001 05:25:53 -0700 Message-Id: <200107271225.FAA09468@mail25.bigmailbox.com> X-Mailer: MIME-tools 4.104 (Entity 4.116) Mime-Version: 1.0 X-Originating-Ip: [203.141.118.84] From: "neckpain@nettaxi.com" To: msmith@freebsd.org Cc: current@freebsd.org Subject: Re: acpica malfunctions Content-Type: multipart/mixed; boundary="----------=_996236753-9320-0" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format... ------------=_996236753-9320-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary In-Reply-To: <200107232037.f6NKbx201647@mass.dis.org>; from msmith@FreeBSD.ORG on Mon, Jul 23, 2001 at 01:37:59PM -0700 On Mon, Jul 23, 2001 at 01:37:59PM -0700, Mike Smith wrote: > > > > 1. Acpica modules hangs in > > > > AcpiRsCalculateByteStreamLength() called from > > > > AcpiRsCreateByteStream() called from > > > > AcpiRsSetSrsMethodData() called from > > > > AcpiSetCurrentResources() from somewhere in acpi_pcib.c . > > > > > > > > The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length > > == 0 > > > > . > > > > > > Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484? > > > I think I should be passing a pointer to the buffer, not a pointer to a > > > pointer. > > > > There's no &crsbuf in line 484 (not in rev 1.10, nor 1.11). > > > > Assuming you're talking about the one in line 478, it doesn't compile if you > > change it to crsbuf from &crsbuf, since crsbuf is an ACPI_BUFFER, not > > an (ACPI_BUFFER *). > > Um. Sorry about the line numbers, and yes, sorry about the confusion > there; I just looked at it and it seemed wrong. > > I'd still like to know the allocation length for that buffer though; my > last suspicion is that it doesn't contain any resources at all, and so > we're overrunning it when we go to try to stuff an interrupt resource > into it. If that's the case, it's easy to fix. If not, then we will > have to go hunting snarks. Mike, Seems like I managed to solve my problem. Attached is to be applied against sys/dev/acpica/acpi_pcib.c, rev 1.10 . First of all, the list returned in crsbuf was terminated with an element with its Length field equal to zero (and Id field was ACPI_RSTYPE_IRQ). Since AcpiRsCalculateByteStreamLength() expects ACPI_RSTYPE_END_TAG as terminator and doesn't check the validity of Length field (or, in other words, this function doesn't treat it as terminator), the function never returned. And as you suggested, AcpiGetCurrentResources() returned an IRQ resource with no interrupts(NumberOfInterrupts = 0, and no room for Data.Irq.Interrupts[0]). Thus the line 476 in acpi_pcib.c was overwriting the Id field in the next element. The patch tries to allocate another buffer to resize the list, and to modify the last element's Id to ACPI_RSTYPE_END_TAG. I think AcpiRsCalculateByteStreamLength() should just exit the while loop when it found an element with Length = 0, rather than wait for the end tag forever. Thanks. ------------------------------------------------------------ Shop Smart Compare Prices on Name-Brand Products from Name-Brand Stores!! http://www.smartshop.com/cgi-bin/main.cgi?ssa=4099 ------------=_996236753-9320-0 Content-Type: application/octet-stream; name="acpi_pcib.c.diff" Content-Disposition: inline; filename="acpi_pcib.c.diff" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9kZXYvYWNwaWNhL2FjcGlfcGNpYi5jCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL2N2cy9zcmMvc3lzL2Rldi9h Y3BpY2EvYWNwaV9wY2liLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMTAK ZGlmZiAtdSAtdSAtcjEuMTAgYWNwaV9wY2liLmMKLS0tIHN5cy9kZXYvYWNw aWNhL2FjcGlfcGNpYi5jCTIwMDEvMDcvMDcgMTA6MTI6MDYJMS4xMAorKysg c3lzL2Rldi9hY3BpY2EvYWNwaV9wY2liLmMJMjAwMS8wNy8yNyAwMjo0NDoz MgpAQCAtMjY5LDYgKzI2OSw0MSBAQAogICAgIHBjaV9jZmdyZWd3cml0ZShi dXMsIHNsb3QsIGZ1bmMsIHJlZywgZGF0YSwgYnl0ZXMpOwogfQogCitzdGF0 aWMgQUNQSV9TVEFUVVMKK2FjcGlfRW5sYXJnZVJlc291cmNlKEFDUElfQlVG RkVSICpidWZwLCBBQ1BJX1JFU09VUkNFICpjdXJwLCBzaXplX3Qgd2FudCkK K3sKKwlBQ1BJX1JFU09VUkNFCSp0b3A7CisJQUNQSV9SRVNPVVJDRQkqYWxs b2M7CisJc2l6ZV90CQlwOworCXNpemVfdAkJQnVmZmVyU2l6ZTsKKworCWlm IChjdXJwIDwgKHRvcCA9IGJ1ZnAtPlBvaW50ZXIpIHx8CisJICAgIFBPSU5U RVJfQUREKEFDUElfUkVTT1VSQ0UsIHRvcCwgYnVmcC0+TGVuZ3RoIC0gY3Vy cC0+TGVuZ3RoKSA8IGN1cnApCisJCXJldHVybiBBRV9CQURfUEFSQU1FVEVS OworCisJQnVmZmVyU2l6ZSA9IGJ1ZnAtPkxlbmd0aCAtIGN1cnAtPkxlbmd0 aCArIHdhbnQ7CisJaWYgKChhbGxvYyA9IEFjcGlPc0FsbG9jYXRlKEJ1ZmZl clNpemUpKSA9PSBOVUxMKQorCQlyZXR1cm4gQUVfTk9fTUVNT1JZOworCisJ cCA9IChjaGFyICopY3VycCAtIChjaGFyICopdG9wOworCW1lbWNweShhbGxv YywgdG9wLCBwKTsKKworCW1lbWNweSgoY2hhciAqKWFsbG9jICsgcCwgY3Vy cCwgd2FudCk7CisJKFBPSU5URVJfQUREKEFDUElfUkVTT1VSQ0UsIGFsbG9j LCBwKSktPkxlbmd0aCA9IHdhbnQ7CisKKwltZW1jcHkoKGNoYXIgKilhbGxv YyArIHAgKyB3YW50LCAoY2hhciAqKWN1cnAgKyBjdXJwLT5MZW5ndGgsCisJ ICAgIGJ1ZnAtPkxlbmd0aCAtIHAgLSBjdXJwLT5MZW5ndGgpOworCisJYWxs b2MtPkxlbmd0aCArPSB3YW50IC0gY3VycC0+TGVuZ3RoOworCWJ1ZnAtPkxl bmd0aCA9IEJ1ZmZlclNpemU7CisJQWNwaU9zRnJlZShidWZwLT5Qb2ludGVy KTsKKwlidWZwLT5Qb2ludGVyID0gYWxsb2M7CisKKwlyZXR1cm4gQUVfT0s7 Cit9CisKKworCiAvKgogICogUm91dGUgYW4gaW50ZXJydXB0IGZvciBhIGNo aWxkIG9mIHRoZSBicmlkZ2UuCiAgKgpAQCAtNDczLDYgKzUwOCw0MyBAQAog ICAgIGZvciAoaSA9IDA7IGkgPCBwcnNyZXMtPkRhdGEuSXJxLk51bWJlck9m SW50ZXJydXB0czsgaSsrKQogCXByaW50ZigiICAlZCIsIHByc3Jlcy0+RGF0 YS5JcnEuSW50ZXJydXB0c1tpXSk7CiAgICAgcHJpbnRmKCJcbiIpOworCisg ICAgeworCUFDUElfUkVTT1VSQ0UJKnIsICpzOworCXNpemVfdAkJbmV3c2l6 ZTsKKwlpbnQJCWksIGosIG47CisKKwkvKgorCSAqIGZpcnN0IGdyb3cgdGhl IHNpemUgb2YgSVJRIHJlc291cmNlIHNvIHdlIGhhdmUgcm9vbSBmb3IgYW4g SVJRCisJICovCisJbiA9IGNyc3Jlcy0+RGF0YS5JcnEuTnVtYmVyT2ZJbnRl cnJ1cHRzICsKKwkgICAgcHJzcmVzLT5EYXRhLklycS5OdW1iZXJPZkludGVy cnVwdHM7CisJbmV3c2l6ZSA9IChjaGFyICopJihjcnNyZXMtPkRhdGEuSXJx LkludGVycnVwdHNbMF0pIC0gKGNoYXIgKiljcnNyZXMgKworCSAgICBuICog c2l6ZW9mIChjcnNyZXMtPkRhdGEuSXJxLkludGVycnVwdHNbMF0pOworCWlm IChhY3BpX0VubGFyZ2VSZXNvdXJjZSgmY3JzYnVmLCBjcnNyZXMsIG5ld3Np emUpICE9IEFFX09LKQorCSAgICBnb3RvIG91dDsKKworCS8qIGZpeCBjcnNy ZXMgcG9pbnQgdG8gdGhlIHJlc291cmNlIGluIHRoZSBuZXdseSBhbGxvY2F0 ZWQgYnVmZmVyICovCisJYWNwaV9GaW5kSW5kZXhlZFJlc291cmNlKChBQ1BJ X1JFU09VUkNFICopY3JzYnVmLlBvaW50ZXIsCisJICAgIHBydC0+U291cmNl SW5kZXgsICZjcnNyZXMpOworCisJZm9yIChpID0gY3JzcmVzLT5EYXRhLkly cS5OdW1iZXJPZkludGVycnVwdHMsIGogPSAwOyBpIDwgbjsgKytpLCArK2op CisJICAgIGNyc3Jlcy0+RGF0YS5JcnEuSW50ZXJydXB0c1tpXSA9IHByc3Jl cy0+RGF0YS5JcnEuSW50ZXJydXB0c1tqXTsKKwljcnNyZXMtPkRhdGEuSXJx Lk51bWJlck9mSW50ZXJydXB0cyA9IG47CisKKwkvKgorCSAqIGZpbmQgdGhl IGxhc3QgZWxlbWVudChMZW5ndGggPSAwKQorCSAqIGFuZCBzZXQgSWQgdG8g QUNQSV9SU1RZUEVfRU5EX1RBRworCSAqLworCXIgPSBjcnNidWYuUG9pbnRl ciwKKwlzID0gUE9JTlRFUl9BREQoQUNQSV9SRVNPVVJDRSwgY3JzYnVmLlBv aW50ZXIsIGNyc2J1Zi5MZW5ndGgpOworCWZvciAoOyByIDwgczsgciA9IFBP SU5URVJfQUREKEFDUElfUkVTT1VSQ0UsIHIsIHItPkxlbmd0aCkpCisJICAg IGlmIChyLT5MZW5ndGggPT0gMCkgeworCQlyLT5JZCA9IEFDUElfUlNUWVBF X0VORF9UQUc7CisJCWJyZWFrOworCSAgICB9CisgICAgfQorCiAgICAgY3Jz cmVzLT5EYXRhLklycS5JbnRlcnJ1cHRzWzBdID0gcHJzcmVzLT5EYXRhLkly cS5JbnRlcnJ1cHRzWzBdOwogICAgIGNyc3Jlcy0+RGF0YS5JcnEuTnVtYmVy T2ZJbnRlcnJ1cHRzID0gMTsKICAgICBpZiAoQUNQSV9GQUlMVVJFKHN0YXR1 cyA9IEFjcGlTZXRDdXJyZW50UmVzb3VyY2VzKGxua2RldiwgJmNyc2J1Zikp KSB7Cg== ------------=_996236753-9320-0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 27 6:52: 4 2001 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 5DF3C37B405; Fri, 27 Jul 2001 06:51:58 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 27 Jul 2001 14:51:57 +0100 (BST) To: dillon@freebsd.org Cc: current@freebsd.org, stable@freebsd.org Subject: SIGCHLD changes causing fault on nofault entry panics Date: Fri, 27 Jul 2001 14:51:57 +0100 From: Ian Dowse Message-ID: <200107271451.aa00148@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG The panics in exit1() that have been reported on -stable appear to be caused by these commits: REV:1.92.2.4 kern_exit.c 2001/07/25 17:21:46 dillon REV:1.72.2.7 kern_sig.c 2001/07/25 17:21:46 dillon MFC kern_exit.c 1.131, kern_sig.c 1.125 - bring SIGCHLD SIG_IGN signal handling in line with other operating systems. These probably correspond to similar panics seen in -current, but I haven't checked the details. In the vmcore I just got, the panic occurred in the following fragment in exit1(), when dereferencing p_sigacts (which is p_procsig->ps_sigacts). I guess there is a race here if the parent is exiting or something? + if ((p->p_pptr->p_procsig->ps_flag & PS_NOCLDWAIT) + || p->p_pptr->p_sigacts->ps_sigact[_SIG_IDX(SIGCHLD)] == SIG_IGN) { Matt, I will just back out these changes from RELENG_4 shortly until the issue is resolved. The change was non-essential and quite contained, so it's probably better than waiting for a fix. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 27 6:55:37 2001 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 F09F337B406; Fri, 27 Jul 2001 06:55:28 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 27 Jul 2001 14:55:28 +0100 (BST) Date: Fri, 27 Jul 2001 14:55:27 +0100 From: David Malone To: Maxim Sobolev Cc: current@FreeBSD.org, julian@elischer.org, stable@FreeBSD.org, deischen@FreeBSD.org Subject: Re: Strange select(2) misbehaviour when linked with -pthread Message-ID: <20010727145527.A37786@walton.maths.tcd.ie> References: <20010726115931.A93134@walton.maths.tcd.ie> <200107261156.f6QBu8X79427@vega.vega.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107261156.f6QBu8X79427@vega.vega.com>; from sobomax@FreeBSD.org on Thu, Jul 26, 2001 at 02:56:08PM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jul 26, 2001 at 02:56:08PM +0300, Maxim Sobolev wrote: > I am not sure that the error is what we want to get in this situation. > Perhaps more *compatible* solution would be wait indefinitely if timeout > is too large. I guess this could cause problems for programs that use select to time stuff accurately? > Interesting, but this isn't really relevant to my question. I want to > know why the program in question behaves difefrently when linked with > and without -pthead flag (bug in libc_r?). Also [EINVAL] is not what > I'm seeing here, because as you can easily check in my test case > tv.tv_sec == 4294976, which is less that 1000000000 - upper limit of > our select(2) implementation depicted in PR 18909. I think I've found out what is wrong. All timing with the pthreads library is actually implimented using poll, which takes a timeout as an int in ms. The timeout you begin with is 2^32-1 as an unsigned int and gets converted to a timeval and then a timespec and then back to -1 as an int. Netgative timeouts are converted to zero and so the code ends up spinning. I guess what the code should do is set a non-zero timeout if this sort of problem crops up. I think it will just end up trying the timeout again when the short timer expires. Try the patch below. I chose 31 seconds as the timeout 'cos 31 seconds will always be representable in ms in an int. David. --- /tmp/dwmalone/uthread_kern.c Fri Jul 27 14:44:52 2001 +++ uthread/uthread_kern.c Fri Jul 27 14:49:10 2001 @@ -699,6 +699,9 @@ * Calculate the time left for the next thread to * timeout: */ + if (pthread->wakeup_time.tv_sec - ts.tv_sec > 31) + timeout_ms = 31 * 1000; + else timeout_ms = ((pthread->wakeup_time.tv_sec - ts.tv_sec) * 1000) + ((pthread->wakeup_time.tv_nsec - ts.tv_nsec) / 1000000); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 27 7:49:58 2001 Delivered-To: freebsd-current@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 0C84D37B403; Fri, 27 Jul 2001 07:49:55 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f6REni269151; Fri, 27 Jul 2001 07:49:44 -0700 (PDT) (envelope-from dillon) Date: Fri, 27 Jul 2001 07:49:44 -0700 (PDT) From: Matt Dillon Message-Id: <200107271449.f6REni269151@earth.backplane.com> To: Ian Dowse Cc: current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: SIGCHLD changes causing fault on nofault entry panics References: <200107271451.aa00148@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :In the vmcore I just got, the panic occurred in the following :fragment in exit1(), when dereferencing p_sigacts (which is :p_procsig->ps_sigacts). I guess there is a race here if the parent :is exiting or something? : :+ if ((p->p_pptr->p_procsig->ps_flag & PS_NOCLDWAIT) :+ || p->p_pptr->p_sigacts->ps_sigact[_SIG_IDX(SIGCHLD)] == SIG_IGN) { : :Matt, I will just back out these changes from RELENG_4 shortly :until the issue is resolved. The change was non-essential and quite :contained, so it's probably better than waiting for a fix. : :Ian Ok, I'll take a look at it on the weekend and see if I can track down where the panic is coming from. I'll be that p_sigacts can wind up NULL in a reparenting case or something like that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 27 10:27:34 2001 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 38AEE37B401 for ; Fri, 27 Jul 2001 10:27:32 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f6RHRBg44484; Fri, 27 Jul 2001 10:27:11 -0700 (PDT) (envelope-from obrien) Date: Fri, 27 Jul 2001 10:27:05 -0700 From: "David O'Brien" To: Kris Kennaway , current@FreeBSD.ORG Subject: Re: libedit replacement for libreadline Message-ID: <20010727102705.D43542@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20010716013127.A16058@xor.obsecurity.org> <20010716103351.A81876@walton.maths.tcd.ie> <20010716031932.A5930@xor.obsecurity.org> <200107161516.f6GFGCT34314@khavrinen.lcs.mit.edu> <20010716120054.A94139@xor.obsecurity.org> <20010717063825.A21495@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010717063825.A21495@nagual.pp.ru>; from ache@nagual.pp.ru on Tue, Jul 17, 2001 at 06:38:25AM +0400 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Jul 17, 2001 at 06:38:25AM +0400, Andrey A. Chernov wrote: > > > > Personally, I think it's worth it to get rid of a GNU dependency in > > > > the base system, as well as reducing the overall amount of functional > > > > code duplication. > > > > > > I don't, particularly since the two programs which use it are already > > > GNU software, so you haven't actually bought any additional freedom by > > > making such a change. > > > > A third is vinum, which buys some additional freedom :-) > > So lets use it for vinum only leaving gnu soft bug-to-bug compatible with > itself. After re-reading this entire thread, I still agree with Andrey. But is there some reason you are holding back updating libedit for those programs that do use it today (or are non-GPVed and could use libedit)? The LukeM ftp client, needs the fuller NetBSD libedit, so it would be nice to get your patches committed to ours. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 27 12:11:42 2001 Delivered-To: freebsd-current@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-149.dsl.lsan03.pacbell.net [64.169.104.149]) by hub.freebsd.org (Postfix) with ESMTP id 18CCB37B401; Fri, 27 Jul 2001 12:11:39 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 37BBC66B25; Fri, 27 Jul 2001 12:11:38 -0700 (PDT) Date: Fri, 27 Jul 2001 12:11:37 -0700 From: Kris Kennaway To: David O'Brien Cc: Kris Kennaway , current@FreeBSD.ORG Subject: Re: libedit replacement for libreadline Message-ID: <20010727121137.D34272@xor.obsecurity.org> References: <20010716013127.A16058@xor.obsecurity.org> <20010716103351.A81876@walton.maths.tcd.ie> <20010716031932.A5930@xor.obsecurity.org> <200107161516.f6GFGCT34314@khavrinen.lcs.mit.edu> <20010716120054.A94139@xor.obsecurity.org> <20010717063825.A21495@nagual.pp.ru> <20010727102705.D43542@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="OaZoDhBhXzo6bW1J" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010727102705.D43542@dragon.nuxi.com>; from obrien@FreeBSD.ORG on Fri, Jul 27, 2001 at 10:27:05AM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --OaZoDhBhXzo6bW1J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2001 at 10:27:05AM -0700, David O'Brien wrote: > On Tue, Jul 17, 2001 at 06:38:25AM +0400, Andrey A. Chernov wrote: > > > > > Personally, I think it's worth it to get rid of a GNU dependency = in > > > > > the base system, as well as reducing the overall amount of functi= onal > > > > > code duplication. > > > >=20 > > > > I don't, particularly since the two programs which use it are alrea= dy > > > > GNU software, so you haven't actually bought any additional freedom= by > > > > making such a change. > > >=20 > > > A third is vinum, which buys some additional freedom :-) > >=20 > > So lets use it for vinum only leaving gnu soft bug-to-bug compatible wi= th > > itself. >=20 > After re-reading this entire thread, I still agree with Andrey. > But is there some reason you are holding back updating libedit for those > programs that do use it today (or are non-GPVed and could use libedit)? >=20 > The LukeM ftp client, needs the fuller NetBSD libedit, so it would be > nice to get your patches committed to ours. I'm planning to commit it soon. Kris --OaZoDhBhXzo6bW1J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7YbzoWry0BWjoQKURAv8BAKCKV+n1m6ojwLGusn1FVDPOwqD6FACgwFX5 iBhkDmEswwzOGIxK6MG0Ibs= =GYxt -----END PGP SIGNATURE----- --OaZoDhBhXzo6bW1J-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 27 16:55:52 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.com [194.25.134.82]) by hub.freebsd.org (Postfix) with ESMTP id 8A95B37B403 for ; Fri, 27 Jul 2001 16:55:44 -0700 (PDT) (envelope-from D.Rock@t-online.de) Received: from fwd06.sul.t-online.de by mailout05.sul.t-online.de with smtp id 15QHSE-0004N7-03; Sat, 28 Jul 2001 01:55:38 +0200 Received: from server.rock.net (340029380333-0001@[62.155.178.119]) by fmrl06.sul.t-online.com with esmtp id 15QHSA-0dvwMSC; Sat, 28 Jul 2001 01:55:34 +0200 Received: from t-online.de (server [172.23.7.1]) by server.rock.net (8.11.4/8.11.4/Rock) with ESMTP id f6RNtCX03029 for ; Sat, 28 Jul 2001 01:55:12 +0200 (MEST) Message-ID: <3B61FF60.62D9F65C@t-online.de> Date: Sat, 28 Jul 2001 01:55:12 +0200 From: Daniel Rock X-Mailer: Mozilla 4.76 [de] (X11; U; SunOS 5.8 i86pc) X-Accept-Language: de, en MIME-Version: 1.0 To: current@freebsd.org Subject: ACPI: Clock problems in -current Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 340029380333-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, just noticed with a -current from yesterday (today's -current has the same problem). After bootup I will see tons of calcru: negative time of -953757 usec for pid 636 (make) calcru: negative time of -820616 usec for pid 636 (make) microuptime() went backwards (1969.4485199 -> 1969.552693) microuptime() went backwards (1969.4485199 -> 1969.690311) messages, together with processes with a negative CPU usage time. Something is going wrong during setting clock interrupts. A "vmstat -i" shows (among other interrupts): clk irq0 79496 49 rtc irq8 101753 63 which is about half the rate it should be. The latest working kernel I was booting before was from Jul, 13th If I disable ACPI in the kernel the interrupt rate is back to normal. ACPI related boot messages: acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: on acpi0 acpi_button0: on acpi0 acpi_pcib0: on acpi0 pci0: on acpi_pcib0 acpi_cpu0: set speed to 100.0% acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% Mainboard is a GigaByte GA-5AX with F3 BIOS. I will provide further configuration information if needed. -- Daniel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 2:50: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id F124437B405 for ; Sat, 28 Jul 2001 02:49:56 -0700 (PDT) (envelope-from vince@oahu.WURLDLINK.NET) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.11.3/8.11.3) with ESMTP id f6S9nsc13360 for ; Fri, 27 Jul 2001 23:49:55 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Fri, 27 Jul 2001 23:49:54 -1000 (HST) From: Vincent Poy To: Subject: -current kernel panicing Message-ID: <20010727234011.D7031-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm getting a panic in the -current kernel with using kernels built with src/sys/kern/kern_exit.c 1.130 and src/sys/kern/kern_sig.c 1.124 as well as with src/sys/kern/kern_exit.c 1.131 and src/sys/kern/kern_sig.c 1.125. This seems to be a problem that only passwd(1) and chpass(1) seems to cause. vipw appears to work fine as well as everything else. This is what happens: root@pele [10:55pm][~] >> passwd toor Changing local password for toor. New password: Retype new password: passwd: updating the database... passwd: done root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> root@pele [10:55pm][~] >> After here, it just freezes solid for 1 minute then displays on the console... Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal Jul 27 22:57:24 pele /boot/kernel/kernel: 1st 0xda041d9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 27 22:57:24 pele /boot/kernel/kernel: 1st 0xda041d9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd 0xc118de00 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd 0xc118de00 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Then it just hangs completely, not even a db> prompt so had to hard reboot and it goes into single user mode where one would need to fsck all the slices and then I have to: cp -p /var/backups/master.passwd.bak /etc/master.passwd since the password database somehow got corrupted and then ran vipw and :wq! and then shutdown the machine where it would boot normally. Anyone have any ideas how to solve this one or what is causing it since the previous GENERIC kernel from the 6/16/2001 build of -current seemed fine. Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 3: 0:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 1EF1A37B403 for ; Sat, 28 Jul 2001 03:00:24 -0700 (PDT) (envelope-from matt-l@pacbell.net) Received: from fire (1Cust65.tnt1.pasadena.ca.da.uu.net [63.28.226.65]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id DAA14064; Sat, 28 Jul 2001 03:00:18 -0700 (PDT) Message-ID: <000a01c1174b$2f637dc0$6503c23f@XGforce.com> Reply-To: "matt" From: "matt" To: "Vincent Poy" , References: <20010727234011.D7031-100000@oahu.WURLDLINK.NET> Subject: Re: -current kernel panicing Date: Sat, 28 Jul 2001 02:53:40 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Disposition-Notification-To: "matt" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Something wrong in the fs lock code. ====================================== WWW.XGFORCE.COM The Next Generation Load Balance and Fail Safe Server Clustering Software for the Internet. ====================================== ----- Original Message ----- From: "Vincent Poy" To: Sent: Saturday, July 28, 2001 2:49 AM Subject: -current kernel panicing > I'm getting a panic in the -current kernel with using kernels > built with src/sys/kern/kern_exit.c 1.130 and src/sys/kern/kern_sig.c > 1.124 as well as with src/sys/kern/kern_exit.c 1.131 and > src/sys/kern/kern_sig.c 1.125. This seems to be a problem that only > passwd(1) and chpass(1) seems to cause. vipw appears to work fine as well > as everything else. This is what happens: > > root@pele [10:55pm][~] >> passwd toor > Changing local password for toor. > New password: > Retype new password: > passwd: updating the database... > passwd: done > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > root@pele [10:55pm][~] >> > After here, it just freezes solid for 1 minute then displays on > the console... > > Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal > Jul 27 22:57:24 pele /boot/kernel/kernel: lock order reversal > Jul 27 22:57:24 pele /boot/kernel/kernel: 1st 0xda041d9c process lock @ > /usr/src/sys/vm/vm_glue.c:469 > Jul 27 22:57:24 pele /boot/kernel/kernel: 1st 0xda041d9c process lock @ > /usr/src/sys/vm/vm_glue.c:469 > Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd 0xc118de00 lockmgr interlock > @ /usr/src/sys/kern/kern_lock.c:239 > Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd 0xc118de00 lockmgr interlock > @ /usr/src/sys/kern/kern_lock.c:239 > > Then it just hangs completely, not even a db> prompt so had to hard reboot > and it goes into single user mode where one would need to fsck all the > slices and then I have to: > cp -p /var/backups/master.passwd.bak /etc/master.passwd > since the password database somehow got corrupted and then ran vipw and > :wq! and then shutdown the machine where it would boot normally. Anyone > have any ideas how to solve this one or what is causing it since the > previous GENERIC kernel from the 6/16/2001 build of -current seemed fine. > > Cheers, > Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ > Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] > WurldLink Corporation / / / / | / | __] ] > San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] > HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] > Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin > > > > 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 28 4:26:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from mydomain.com (t3o102p2.telia.com [194.255.255.2]) by hub.freebsd.org (Postfix) with ESMTP id 308E537B406; Sat, 28 Jul 2001 04:26:43 -0700 (PDT) (envelope-from world1web@www.com) Date: Sat, 28 Jul 2001 13:26:40 +0100 From: WORLD1-WEB To: WORLD1-WEB@FreeBSD.ORG Subject: INCREDIBLE .. WORLDS NO.1 !! Message-Id: <20010728112643.308E537B406@hub.freebsd.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ladies & Gentlemen, Are you ready to the experience of a lifetime ? As affiliates of the CIL group, we offer you to PLUGIN to the largest SEX-SERVER on the WEB, in order to get more than 3000 MegaBytes of the best and most sensational SEX on the entire Web! Why on earth do you think that thousands of people from 13 countries daily choose to visit 2 particular WebSites ? Very EASY answer! - The largest and most incredible content of LIVE SEX is offered! - State-of-the-art LIVE SHOWS with the wildest and most horny amateurs and pornstars in the world! - Hardcore LIVE SEX that hasnīt crossed your imagination! - Incredible & amazing themes from soft sex to the most bizarre sex! - Beautiful Girls & wild studs from almost every country, allowing you to watch, see & chat with awsome amateurs & pornstars who are blond, who are black, who are Scandinavian, who are Asian, who have BIG tits, who are shaved, who are pregnant who are .... you just name it ! - The best ever made SPY-CAMS, WATCH-CAMS, POOL-CAMS, SHOWER-CAMS, AMATEUR-CAMS ... etc! - Several high quality Interactive Cams & LIVE SEX Chat, where you are in controle ! - Much much more ... too much to mention ! EVERYTHING is offered 100% ANONOMOUSLY & you donīt need to sign-up or have a creditcard ... How simple is that ? PLUGIN now to our MEGA SEX-SERVER through any of the 2 AwardWinning Sites listed below, and get instantly access to more than 3000 MegaBytes of State-of-the-art WebSex! RIGHT HERE AT: http://siam.to/sexywebtv (This Site just has EVERYTHING you can imagine) ... If this Site does not open properly ... please try http://cyberu.to/hotweb Or this one, if you just love true LESBIAN SEX, CHAT and MORE from Sunny Ibiza in Spain: http://siam.to/sexybabestv ... If this Site does not open properly ... please try http://cyberu.to/hotbabes Enjoy your trip to paradise! VERY IMPORTANT HINT: To get DIRECT ACCESS to the webpages in the future, ALLWAYS keep the DIALER on your desktop or elsewhere on your PC ... Its easy, small and 100% harmless. Yours sincerely, WORLD1-WEB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 13: 4:59 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (sat.dis.org [216.240.44.14]) by hub.freebsd.org (Postfix) with ESMTP id 315D337B405 for ; Sat, 28 Jul 2001 13:04:54 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f6SK6RJ01779; Sat, 28 Jul 2001 13:06:28 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200107282006.f6SK6RJ01779@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Rock Cc: current@freebsd.org Subject: Re: ACPI: Clock problems in -current In-reply-to: Your message of "Sat, 28 Jul 2001 01:55:12 +0200." <3B61FF60.62D9F65C@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Jul 2001 13:06:27 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Say set debug.acpi.disable="timer" in the bootloader and see if you still get this. I've already got one report of system time going twice as fast as it should; I'm unsure what's going on here (I don't grok the timecounter code as well as I should, I think)... You could also try building a kernel with CLK_CALIBRATION_LOOP defined and then booting with -v (without the timer disabled). This might be instructive (I don't know for certain that it'll calibrate the ACPI timer, since it may not have been probed yet). Thanks! > Hi, > > just noticed with a -current from yesterday (today's -current has the > same problem). > > After bootup I will see tons of > calcru: negative time of -953757 usec for pid 636 (make) > calcru: negative time of -820616 usec for pid 636 (make) > microuptime() went backwards (1969.4485199 -> 1969.552693) > microuptime() went backwards (1969.4485199 -> 1969.690311) > messages, together with processes with a negative CPU usage time. > > Something is going wrong during setting clock interrupts. > A "vmstat -i" shows (among other interrupts): > clk irq0 79496 49 > rtc irq8 101753 63 > which is about half the rate it should be. > > The latest working kernel I was booting before was from Jul, 13th > > If I disable ACPI in the kernel the interrupt rate is back to normal. > > ACPI related boot messages: > acpi0: on motherboard > acpi0: power button is handled as a fixed feature programming model. > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_cpu0: on acpi0 > acpi_button0: on acpi0 > acpi_pcib0: on acpi0 > pci0: on acpi_pcib0 > acpi_cpu0: set speed to 100.0% > acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% > > Mainboard is a GigaByte GA-5AX with F3 BIOS. > > > I will provide further configuration information if needed. > > > -- > Daniel > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 14:12: 0 2001 Delivered-To: freebsd-current@freebsd.org Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184]) by hub.freebsd.org (Postfix) with ESMTP id 4219C37B403 for ; Sat, 28 Jul 2001 14:11:53 -0700 (PDT) (envelope-from mckusick@mckusick.com) Received: from beastie.mckusick.com (localhost [127.0.0.1]) by beastie.mckusick.com (8.11.4/8.9.3) with ESMTP id f6SJmso06543; Sat, 28 Jul 2001 12:48:54 -0700 (PDT) (envelope-from mckusick@beastie.mckusick.com) Message-Id: <200107281948.f6SJmso06543@beastie.mckusick.com> To: Ian Dowse Subject: Re: filesystem errors Cc: Michael Harnois , freebsd-current@freebsd.org In-Reply-To: Your message of "Thu, 26 Jul 2001 15:14:09 BST." <200107261514.aa46454@salmon.maths.tcd.ie> Date: Sat, 28 Jul 2001 12:48:54 -0700 From: Kirk McKusick Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG To: Michael Harnois cc: freebsd-current@freebsd.org, mckusick@mckusick.com Subject: Re: filesystem errors In-Reply-To: Your message of "Wed, 25 Jul 2001 23:14:16 CDT." <8666cgfht3.fsf@mharnois.workgroup.net> Date: Thu, 26 Jul 2001 15:14:09 +0100 From: Ian Dowse In message <8666cgfht3.fsf@mharnois.workgroup.net>, Michael Harnois writes: >I'm tearing my hair out trying to find a filesystem error that's >causing me a panic: ufsdirhash_checkblock: bad dir inode. > >When I run fsck from a single user boot, it finds no errors. > >When I run it on the same filesystem mounted, it finds errors: but, of >course, it then can't correct them [Kirk, I'm cc'ing you because here the dirhash code sanity checks found a directory entry with d_ino == 0 that was not at the start of a DIRBLKSIZ block. This doesn't happen normally, but it seems from this report that fsck does not correct this. Is it a basic filesystem assumption that d_ino == 0 can only happen at the start of a directory block, or is it something the code should tolerate?] FFS will never set a directory ino == 0 at a location other than the first entry in a directory, but fsck will do so to get rid of an unwanted entry. The readdir routines know to skip over an ino == 0 entry no matter where in the directory it is found, so applications will never see such entries. It would be a fair amount of work to change fsck to `do the right thing', as the checking code is given only the current entry with which to work. I am of the opinion that you should simply accept that mid-directory block ino == 0 is acceptable rather than trying to `fix' the problem. Interesting - this is an error reported by the UFS_DIRHASH code that you enabled in your kernel config. A sanity check that the dirhash code is performing is failing. These checks are designed to catch bugs in the dirhash code, but in this case I think it may be a bug that fsck is not finding this problem, or else my sanity tests are too strict. A workaround is to turn off the sanity checks with: sysctl vfs.ufs.dirhash_docheck=0 or to remove UFS_DIRHASH from your kernel config. You could also try to find the directory that is causing the problems. Copy the following script to a file called dircheck.pl, and try running: chmod 755 dircheck.pl find / -fstype ufs -type d -print0 | xargs ./dircheck.pl That should show up any directories that would fail that dirhash sanity check - there will probably just be one or two that resulted from some old filesystem corruption. Ian #!/usr/local/bin/perl while (defined($dir = shift)) { unless (open(DIR, "$dir")) { print STDERR "$dir: $!\n"; next; } $b = 0; my(%dir) = (); while (sysread(DIR, $dat, 512) == 512) { $off = 0; while (length($dat) > 0) { ($dir{'d_ino'}, $dir{'d_reclen'}, $dir{'d_type'}, $dir{'d_namlen'}) = unpack("LSCC", $dat); $dir{'d_name'} = substr($dat, 8, $dir{'d_namlen'}); $minreclen = (8 + $dir{'d_namlen'} + 1 + 3) & (~3); $gapinfo = ($dir{'d_reclen'} == $minreclen) ? "" : sprintf("[%d]", $dir{'d_reclen'} - $minreclen); if ($dir{'d_ino'} == 0 && $off != 0) { printf("%s off %d ino %d reclen 0x%x type 0%o" . " namelen %d name '%s' %s\n", $dir, $off, $dir{'d_ino'}, $dir{'d_reclen'}, $dir{'d_type'}, $dir{'d_namlen'}, $dir{'d_name'}, $gapinfo); } if ($dir{'d_reclen'} > length($dat)) { die "reclen too long!\n"; } $dat = substr($dat, $dir{'d_reclen'}); $off += $dir{'d_reclen'}; } $b++; } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 15: 6:26 2001 Delivered-To: freebsd-current@freebsd.org Received: from femail44.sdc1.sfba.home.com (femail44.sdc1.sfba.home.com [24.254.60.38]) by hub.freebsd.org (Postfix) with ESMTP id 7BBCA37B401 for ; Sat, 28 Jul 2001 15:06:24 -0700 (PDT) (envelope-from mdharnois@home.com) Received: from c1030098-a.wtrlo1.ia.home.com ([24.6.200.230]) by femail44.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010728220624.JHGU28154.femail44.sdc1.sfba.home.com@c1030098-a.wtrlo1.ia.home.com> for ; Sat, 28 Jul 2001 15:06:24 -0700 Received: by c1030098-a.wtrlo1.ia.home.com (Postfix, from userid 1001) id 2C38D14A02; Sat, 28 Jul 2001 17:07:52 -0500 (CDT) To: Kirk McKusick Cc: Ian Dowse , freebsd-current@freebsd.org Subject: Re: filesystem errors Keywords: entry,mckusick,ino,directory References: <200107281948.f6SJmso06543@beastie.mckusick.com> From: Michael Harnois Date: Sat, 28 Jul 2001 17:07:52 -0500 In-Reply-To: <200107281948.f6SJmso06543@beastie.mckusick.com> (Kirk McKusick's message of "Sat, 28 Jul 2001 12:48:54 -0700") Message-ID: <861yn0907b.fsf@mharnois.workgroup.net> Lines: 22 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (anise) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 28 Jul 2001 12:48:54 -0700, Kirk McKusick said: > FFS will never set a directory ino == 0 at a location other than > the first entry in a directory, but fsck will do so to get rid > of an unwanted entry. The readdir routines know to skip over an > ino == 0 entry no matter where in the directory it is found, so > applications will never see such entries. It would be a fair > amount of work to change fsck to `do the right thing', as the > checking code is given only the current entry with which to > work. I am of the opinion that you should simply accept that > mid-directory block ino == 0 is acceptable rather than trying to > `fix' the problem. I don't have sufficient technical knowledge to know which of you is right; I would just ask that filesystem corruption caused by restarting from a hung system not cause a panic . -- Michael D. Harnois bilocational bivocational Washburn, Iowa Minneapolis, Minnesota Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 15:12:47 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailout00.sul.t-online.de (mailout00.sul.t-online.com [194.25.134.16]) by hub.freebsd.org (Postfix) with ESMTP id 08A7637B401; Sat, 28 Jul 2001 15:12:43 -0700 (PDT) (envelope-from D.Rock@t-online.de) Received: from fwd05.sul.t-online.de by mailout00.sul.t-online.de with smtp id 15QcKA-0003fy-05; Sun, 29 Jul 2001 00:12:42 +0200 Received: from server.rock.net (340029380333-0001@[217.5.82.45]) by fmrl05.sul.t-online.com with esmtp id 15QcK8-23NlfUC; Sun, 29 Jul 2001 00:12:40 +0200 Received: from t-online.de (laptop [172.23.7.128]) by server.rock.net (8.11.4/8.11.4/Rock) with ESMTP id f6SMCRX26339; Sun, 29 Jul 2001 00:12:27 +0200 (MEST) Message-ID: <3B63386C.3D38AC37@t-online.de> Date: Sun, 29 Jul 2001 00:10:52 +0200 From: Daniel Rock X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de, en MIME-Version: 1.0 To: Mike Smith Cc: current@freebsd.org Subject: Re: ACPI: Clock problems in -current References: <200107282006.f6SK6RJ01779@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 340029380333-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith schrieb: > > Say > > set debug.acpi.disable="timer" > > in the bootloader and see if you still get this. I've already got one > report of system time going twice as fast as it should; I'm unsure what's > going on here (I don't grok the timecounter code as well as I should, I > think)... This helps. > > You could also try building a kernel with CLK_CALIBRATION_LOOP defined > and then booting with -v (without the timer disabled). This might be > instructive (I don't know for certain that it'll calibrate the ACPI > timer, since it may not have been probed yet). Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz Calibrating clock(s) ... TSC clock: 300685043 Hz, i8254 clock: 1193195 Hz Calibrating clock(s) ... TSC clock: 300684395 Hz, i8254 clock: 1193192 Hz Calibrating clock(s) ... TSC clock: 300684395 Hz, i8254 clock: 1193192 Hz Timecounter "i8254" frequency 1193190 Hz CPU: AMD-K6(tm) 3D processor (300.68-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping = 0 -- Daniel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 15:15:53 2001 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 9409E37B403 for ; Sat, 28 Jul 2001 15:15:50 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 28 Jul 2001 23:15:49 +0100 (BST) To: Michael Harnois Cc: Kirk McKusick , freebsd-current@freebsd.org Subject: Re: filesystem errors In-Reply-To: Your message of "Sat, 28 Jul 2001 17:07:52 CDT." <861yn0907b.fsf@mharnois.workgroup.net> Date: Sat, 28 Jul 2001 23:15:49 +0100 From: Ian Dowse Message-ID: <200107282315.aa58940@salmon.maths.tcd.ie> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <861yn0907b.fsf@mharnois.workgroup.net>, Michael Harnois writes: > >I don't have sufficient technical knowledge to know which of you is >right; I would just ask that filesystem corruption caused by >restarting from a hung system not cause a panic . I removed the extra sanity check yesterday, so if you have revision 1.3 of ufs_dirhash.c you won't see that panic again. I didn't realise that fsck actually causes these directory entries, but just the fact that it leaves them intact meant that the sanity check was bad. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 15:23:30 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail.nshore.com (unknown [216.12.228.198]) by hub.freebsd.org (Postfix) with ESMTP id 4E50D37B405 for ; Sat, 28 Jul 2001 15:23:27 -0700 (PDT) (envelope-from andrewl@nshore.com) Received: from localhost (andrewl@localhost) by mail.nshore.com (8.11.2/8.11.2) with ESMTP id f6SMH8V32692 for ; Sat, 28 Jul 2001 17:17:08 -0500 Date: Sat, 28 Jul 2001 17:17:08 -0500 (CDT) From: To: Subject: NFS file locking fails from Solaris Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I'm getting a strange problem in the NFS file locking code in -current. (We won't talk about -stable. It has fundamental brokenness.) FreeBSD -current Server -> Solaris 8 Rel 4/01 Client The Solaris client mounts the FreeBSD exported filesystem fine. I can create, delete, and manipulate files fine. However, when I try to use fcntl to lock a file, the Solaris client hangs. Normally, I would just let this go; however, Cadence (the VLSI CAD tool company) requires locks to work in order to use its tools. Therefore, I can't use FreeBSD as a fileserver in my environment. If I monitor the traffic on the line with ethereal, I see the request for the version 4 nlockmgr from the Solaris client to the FreeBSD server. I see the FreeBSD server respond with the correct version and port. However, after this, I start seeing a bunch of SYN/RST packets being thrown around, and I never see a lock request initiated from the Solaris client. It is certainly conceivable that there is something fundamentally broken in the Solaris code even though it works with other Solaris machines. However, I'm a bit out of my depth on this and was hoping to be able to talk to somebody and either get a confirmation that this is a known problem or that it is something that I'm doing wrong in my configuration. Who do I talk to about this? Thanks, Andy L. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 16:20: 7 2001 Delivered-To: freebsd-current@freebsd.org Received: from mass.dis.org (sat.dis.org [216.240.44.14]) by hub.freebsd.org (Postfix) with ESMTP id 6ACE137B401; Sat, 28 Jul 2001 16:20:01 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f6SNLcJ12093; Sat, 28 Jul 2001 16:21:38 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200107282321.f6SNLcJ12093@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Rock Cc: Mike Smith , current@freebsd.org Subject: Re: ACPI: Clock problems in -current In-reply-to: Your message of "Sun, 29 Jul 2001 00:10:52 +0200." <3B63386C.3D38AC37@t-online.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Jul 2001 16:21:38 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Mike Smith schrieb: > > > > Say > > > > set debug.acpi.disable="timer" > > > > in the bootloader and see if you still get this. I've already got one > > report of system time going twice as fast as it should; I'm unsure what's > > going on here (I don't grok the timecounter code as well as I should, I > > think)... > > This helps. Ok. I'll go look at it again. > Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz Hrm. Drat. You're running on an K6, and ACPI is working for you? I'm impressed; I guess this is a fairly new motherboard? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 16:36:43 2001 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id 284EB37B403; Sat, 28 Jul 2001 16:36:41 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.4/8.11.1) id f6SNaeS05062; Sat, 28 Jul 2001 16:36:40 -0700 (PDT) (envelope-from obrien) Date: Sat, 28 Jul 2001 16:36:40 -0700 From: "David O'Brien" To: j@freebsd.org Cc: current@freebsd.org Subject: floppy driver broken? Message-ID: <20010728163640.A4989@dragon.nuxi.com> Reply-To: obrien@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Yesterday's current, w/NODEVFS kernel. # fdformat /dev/fd0.1440 Format 1440K floppy `/dev/fd0.1440'? (y/n): y Processing VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV done. # mount_msdosfs /dev/fd0.1440 /floppy mount_msdosfs: /dev/fd0.1440: Invalid argument # ls -l /dev/fd0.1440 crw-r----- 2 root operator 9, 3 Jul 28 16:29 /dev/fd0.1440 # pkg_add -r mtools Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-current/Latest/mtools.tgz... Done. # mcopy /tmp/foo a: init A: sector size too big Cannot initialize 'A:' Bad target a: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 16:53:37 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailout03.sul.t-online.de (mailout03.sul.t-online.com [194.25.134.81]) by hub.freebsd.org (Postfix) with ESMTP id 1ED2637B405; Sat, 28 Jul 2001 16:53:35 -0700 (PDT) (envelope-from D.Rock@t-online.de) Received: from fwd07.sul.t-online.de by mailout03.sul.t-online.de with smtp id 15Qdtm-00065b-00; Sun, 29 Jul 2001 01:53:34 +0200 Received: from server.rock.net (340029380333-0001@[217.5.82.45]) by fmrl07.sul.t-online.com with esmtp id 15Qdtf-0hSYF6C; Sun, 29 Jul 2001 01:53:27 +0200 Received: from t-online.de (laptop [172.23.7.128]) by server.rock.net (8.11.4/8.11.4/Rock) with ESMTP id f6SNpfX68357; Sun, 29 Jul 2001 01:51:41 +0200 (MEST) Message-ID: <3B634FAE.9DCCEE0F@t-online.de> Date: Sun, 29 Jul 2001 01:50:06 +0200 From: Daniel Rock X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de, en MIME-Version: 1.0 To: Mike Smith Cc: current@freebsd.org Subject: Re: ACPI: Clock problems in -current References: <200107282321.f6SNLcJ12093@mass.dis.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 340029380333-0001@t-dialin.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Smith schrieb: > > > Calibrating clock(s) ... TSC clock: 300684467 Hz, i8254 clock: 1193192 Hz > > Hrm. Drat. > > You're running on an K6, and ACPI is working for you? I'm impressed; I > guess this is a fairly new motherboard? No, it is an at least 3 years old GigaByte GA-5AX (Ali Aladdin V). Even the BIOS is from December 1999. -- Daniel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 17: 7:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [206.40.252.115]) by hub.freebsd.org (Postfix) with ESMTP id E296E37B409; Sat, 28 Jul 2001 17:07:20 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.4/8.11.1) id f6T07K005556; Sat, 28 Jul 2001 17:07:20 -0700 (PDT) (envelope-from obrien) Date: Sat, 28 Jul 2001 17:07:20 -0700 From: "David O'Brien" To: j@freebsd.org Cc: current@freebsd.org Subject: Re: floppy driver broken? Message-ID: <20010728170720.A5538@dragon.nuxi.com> Reply-To: obrien@freebsd.org References: <20010728163640.A4989@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010728163640.A4989@dragon.nuxi.com>; from obrien@freebsd.org on Sat, Jul 28, 2001 at 04:36:40PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Jul 28, 2001 at 04:36:40PM -0700, David O'Brien wrote: > Yesterday's current, w/NODEVFS kernel. Never mind. I forgot the newfs_msdos step. :-( To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 18:50:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from hfep01.dion.ne.jp (hfep01.dion.ne.jp [203.181.105.67]) by hub.freebsd.org (Postfix) with ESMTP id 75D9937B403; Sat, 28 Jul 2001 18:50:01 -0700 (PDT) (envelope-from haro@h4.dion.ne.jp) Received: from localhost ([61.200.140.7]) by hfep01.dion.ne.jp with ESMTP id <20010729014958977.QGHV@hfep01.dion.ne.jp>; Sun, 29 Jul 2001 10:49:58 +0900 To: neckpain@nettaxi.com Cc: msmith@freebsd.org, current@freebsd.org, acpi-jp@jp.freebsd.org Subject: Re: acpica malfunctions In-Reply-To: <200107271225.FAA09468@mail25.bigmailbox.com> References: <200107271225.FAA09468@mail25.bigmailbox.com> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010729104940A.haro@h4.dion.ne.jp> Date: Sun, 29 Jul 2001 10:49:40 +0900 From: Munehiro Matsuda X-Dispatcher: imput version 20000228(IM140) Lines: 91 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thank you for your patch. Now I can boot my SONY PCG-Z505V/BP with acpi_pcib.c rev1.11 + your patch. Here's ACPI related dmesg: acpi0: on motherboard Timecounter "ACPI" frequency 3579545 Hz acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_pcib0: on acpi0 pci0: on acpi_pcib0 acpi_pcib0: matched entry for 0.7.INTD (source \\_SB_.LNKD) acpi_pcib0: possible interrupts: 9 acpi_pcib0: routed interrupt 9 via \\_SB_.LNKD acpi_pcib0: matched entry for 0.12.INTA (source \\_SB_.LNKB) acpi_pcib0: possible interrupts: 9 acpi_pcib0: routed interrupt 9 via \\_SB_.LNKB Thank you, Haro From: "neckpain@nettaxi.com" Date: Fri, 27 Jul 2001 05:25:53 -0700 ::In-Reply-To: <200107232037.f6NKbx201647@mass.dis.org>; from msmith@FreeBSD.ORG on Mon, Jul 23, 2001 at 01:37:59PM -0700 :: ::On Mon, Jul 23, 2001 at 01:37:59PM -0700, Mike Smith wrote: ::> > > > 1. Acpica modules hangs in ::> > > > AcpiRsCalculateByteStreamLength() called from ::> > > > AcpiRsCreateByteStream() called from ::> > > > AcpiRsSetSrsMethodData() called from ::> > > > AcpiSetCurrentResources() from somewhere in acpi_pcib.c . ::> > > > ::> > > > The hang itself occurs at LinkedList->Id == 9 and LinkedList->Length ::> > == 0 ::> > > > . ::> > > ::> > > Can you replace &crsbuf with crsbuf in acpi_pcib.c at line 484? ::> > > I think I should be passing a pointer to the buffer, not a pointer to a ::> > > pointer. ::> > ::> > There's no &crsbuf in line 484 (not in rev 1.10, nor 1.11). ::> > ::> > Assuming you're talking about the one in line 478, it doesn't compile if you ::> > change it to crsbuf from &crsbuf, since crsbuf is an ACPI_BUFFER, not ::> > an (ACPI_BUFFER *). ::> ::> Um. Sorry about the line numbers, and yes, sorry about the confusion ::> there; I just looked at it and it seemed wrong. ::> ::> I'd still like to know the allocation length for that buffer though; my ::> last suspicion is that it doesn't contain any resources at all, and so ::> we're overrunning it when we go to try to stuff an interrupt resource ::> into it. If that's the case, it's easy to fix. If not, then we will ::> have to go hunting snarks. :: ::Mike, ::Seems like I managed to solve my problem. Attached is to be applied against ::sys/dev/acpica/acpi_pcib.c, rev 1.10 . :: ::First of all, the list returned in crsbuf was terminated with an element ::with its Length field equal to zero (and Id field was ACPI_RSTYPE_IRQ). ::Since AcpiRsCalculateByteStreamLength() expects ACPI_RSTYPE_END_TAG as ::terminator and doesn't check the validity of Length field (or, in other words, ::this function doesn't treat it as terminator), the function never returned. :: ::And as you suggested, AcpiGetCurrentResources() returned an IRQ resource ::with no interrupts(NumberOfInterrupts = 0, and no room for ::Data.Irq.Interrupts[0]). Thus the line 476 in acpi_pcib.c was overwriting ::the Id field in the next element. :: ::The patch tries to allocate another buffer to resize the list, and to modify the ::last element's Id to ACPI_RSTYPE_END_TAG. ::I think AcpiRsCalculateByteStreamLength() should just exit the while loop ::when it found an element with Length = 0, rather than wait for the end tag ::forever. :: ::Thanks. :: :: ::------------------------------------------------------------ ::Shop Smart Compare Prices on Name-Brand Products from Name-Brand Stores!! ::http://www.smartshop.com/cgi-bin/main.cgi?ssa=4099 =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: haro@kubota.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 28 19:29:10 2001 Delivered-To: freebsd-current@freebsd.org Received: from oahu.WURLDLINK.NET (oahu.WURLDLINK.NET [216.235.52.1]) by hub.freebsd.org (Postfix) with ESMTP id AC11537B403 for ; Sat, 28 Jul 2001 19:29:03 -0700 (PDT) (envelope-from vince@oahu.WURLDLINK.NET) Received: from localhost (vince@localhost) by oahu.WURLDLINK.NET (8.11.3/8.11.3) with ESMTP id f6T2SpR46483; Sat, 28 Jul 2001 16:28:54 -1000 (HST) (envelope-from vince@oahu.WURLDLINK.NET) Date: Sat, 28 Jul 2001 16:28:50 -1000 (HST) From: Vincent Poy To: matt Cc: Subject: Re: -current kernel panicing In-Reply-To: <000a01c1174b$2f637dc0$6503c23f@XGforce.com> Message-ID: <20010728161828.P7031-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Interesting... I'm running on a cvsup of July 25, 2001 17:00GMT except because of Ian Dowse mentioning in the message thread: SIGCHLD changes causing fault on nofault entry panics, I reverted back to src/sys/kern/kern_exit.c 1.130 and src/sys/kern/kern_sig.c 1.124 to test. Sometimes it will just hang. I noticed that sometimes it will say when it hangs solid: swap_pager: out of swap space swap_pager_getswapspace:failed And this machine does have 512Megs of ram and only 64 is used most of the time. Even swapinfo indicates that it's not using the swap yet. root@pele [4:23pm][/usr/home/vince] >> swapinfo Device 1K-blocks Used Avail Capacity Type /dev/da0s1b 262016 0 262016 0% Interleaved From the following output, it seems like nfs code is at fault but we're not even using nfs at all root@pele [4:24pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da041d9c root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da041d9 root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da041d root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da041 root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep da04 c02bda04 T nfs_curusec root@pele [4:25pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118de00 root@pele [4:27pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118de0 root@pele [4:27pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118de root@pele [4:27pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118d root@pele [4:27pm][/usr/home/vince] >> nm -n /boot/kernel/kernel | grep c118 c03dc118 ? __set_sysuninit_set_sym_M_IFADDR_uninit_sys_uninit c03ec118 d twed_twe_driver_list Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin On Sat, 28 Jul 2001, matt wrote: > Something wrong in the fs lock code. > > ====================================== > WWW.XGFORCE.COM > The Next Generation Load Balance and > Fail Safe Server Clustering Software > for the Internet. > ====================================== > ----- Original Message ----- > From: "Vincent Poy" > To: > Sent: Saturday, July 28, 2001 2:49 AM > Subject: -current kernel panicing > > > > I'm getting a panic in the -current kernel with using > kernels > > built with src/sys/kern/kern_exit.c 1.130 and > src/sys/kern/kern_sig.c > > 1.124 as well as with src/sys/kern/kern_exit.c 1.131 > and > > src/sys/kern/kern_sig.c 1.125. This seems to be a > problem that only > > passwd(1) and chpass(1) seems to cause. vipw appears > to work fine as well > > as everything else. This is what happens: > > > > root@pele [10:55pm][~] >> passwd toor > > Changing local password for toor. > > New password: > > Retype new password: > > passwd: updating the database... > > passwd: done > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > root@pele [10:55pm][~] >> > > After here, it just freezes solid for 1 minute then > displays on > > the console... > > > > Jul 27 22:57:24 pele /boot/kernel/kernel: lock order > reversal > > Jul 27 22:57:24 pele /boot/kernel/kernel: lock order > reversal > > Jul 27 22:57:24 pele /boot/kernel/kernel: 1st > 0xda041d9c process lock @ > > /usr/src/sys/vm/vm_glue.c:469 > > Jul 27 22:57:24 pele /boot/kernel/kernel: 1st > 0xda041d9c process lock @ > > /usr/src/sys/vm/vm_glue.c:469 > > Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd > 0xc118de00 lockmgr interlock > > @ /usr/src/sys/kern/kern_lock.c:239 > > Jul 27 22:57:24 pele /boot/kernel/kernel: 2nd > 0xc118de00 lockmgr interlock > > @ /usr/src/sys/kern/kern_lock.c:239 > > > > Then it just hangs completely, not even a db> prompt > so had to hard reboot > > and it goes into single user mode where one would need > to fsck all the > > slices and then I have to: > > cp -p /var/backups/master.passwd.bak > /etc/master.passwd > > since the password database somehow got corrupted and > then ran vipw and > > :wq! and then shutdown the machine where it would boot > normally. Anyone > > have any ideas how to solve this one or what is > causing it since the > > previous GENERIC kernel from the 6/16/2001 build > of -current seemed fine. > > > > Cheers, > > Vince - vince@WURLDLINK.NET - Vice President > ________ __ ____ > > Unix Networking Operations - FreeBSD-Real Unix for > Free / / / / | / |[__ ] > > WurldLink Corporation > / / / / | / | __] ] > > San Francisco - Honolulu - Hong Kong > / / / / / |/ / | __] ] > > HongKong Stars/Gravis UltraSound Mailing Lists Admin > /_/_/_/_/|___/|_|[____] > > Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC > Network Server Admin > > > > > > > > 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